Как процессы и архитектуры могут принести пользу компаниям

Третий год подряд трек BPM-EA на конференции ACM SAC представляет ряд интересных выступлений в области управления бизнес-процессами (BPM) и корпоративных архитектур (EA) вместе.

Наше объяснение состоит в том, что управлять информационными активами компании намного сложнее, чем просто применять методологию. Следует учитывать несколько точек зрения. Создание оптимального сочетания методов, решений и технологий для решения проблем предприятия - вопрос времени и опыта.

Бизнес-процессы, корпоративные архитектуры, моделирование систем и программного обеспечения, безусловно, являются важными аспектами в разработке и реализации поведения компании. Мы утверждаем, что эти вклады не используются в полной мере, потому что их взаимодополняемость и комбинация используются редко. Затем цель состоит в том, чтобы собрать вклад, который обеспечит интеграцию и сотрудничество между этими дисциплинами и методами.

Я сообщаю здесь краткую сводку вкладов в трек.

Надежный прогнозный мониторинг бизнес-процессов

Мы хотим спрогнозировать PPI (индикатор производительности процесса), который сообщает о правильном выполнении процесса, и мы хотим оценить надежность этих прогнозов, также учитывая изменчивость сценария. Мы хотим, чтобы прогноз поступал как можно скорее, например, в начале выполнения процесса. Вместо того, чтобы использовать определение надежности на основе ML (например, точность двоичного классификатора для успешного и неудачного выполнения процесса), мы рассматриваем надежность как функцию количества возможных путей, которые все еще возможны при выполнении процесса, или времени прошло с начала по отношению к расчетному общему времени выполнения всего процесса.

Управляемость бизнес-процессов с использованием временных переменных

Нас интересует выполнимость (существование: существует хотя бы одно выполнение, удовлетворяющее ограничениям?) И управляемость (универсальность: можем ли мы доказать, что все выполнения удовлетворяют ограничениям?) Выполнения бизнес-процессов по отношению к существующим временным ограничениям для процесса (или задача) исполнение. Существует компромисс между выразительной силой временных ограничений и их управляемостью.

Предложение вводит упрощенный язык процесса, основанный на временных и временных ограничениях. Этот язык позволяет задавать временные правила и шаблоны и позволяет проверять строгую управляемость (определение правил на основе точных временных меток) и динамическую управляемость (более слабый, но более реалистичный уровень управляемости).

Гибридная модель с точки зрения поведения и данных

Мы стремимся объединить ограничения процесса с функциями моделирования, связанного с данными. Это шаг к многопрофильному анализу предприятия. Традиционные подходы к интеллектуальному анализу процессов не сосредотачиваются на аспекте данных. Даже в рамках ERP-систем вам не хватает разделения и ясности модели, которые могут потребоваться. Данных процесса (т.е. выполнения) также недостаточно, поскольку они сглаживают процесс в последовательность событий, забывая о структуре:

Поэтому мы представляем гибридную модель, которая явно рассматривает модель процесса и модель данных (как связь сущность или диаграмму классов UML), и мы показываем, как связать их вместе.

Оптимизация взаимодействия с клиентами с помощью Process Mining и рекомендаций с учетом последовательности

Мы хотим рассматривать путь клиента как историю, описывающую взаимодействие между клиентом и услугами, предлагаемыми компанией. Существующие подходы не ориентированы на непрерывный процесс. Поэтому мы сосредотачиваем внимание на извлечении (из каждого случая) всех соответствующих событий, которые составляют важные шаги на пути к покупке, а затем, применяя алгоритмы kNN, мы генерируем рекомендации для пользователей по дальнейшим услугам или покупкам.

Статический анализ приложений, управляемых процессами

Под приложениями, управляемыми процессами, мы подразумеваем любое программное приложение, которое имеет внутренний набор шагов, основанный на процессах, и условные зависимости между задачами. Статический анализ широко применяется как для процессов, так и для кода. Но здесь мы обращаемся к связи между ними. У нас могут быть ситуации, когда статический анализ процесса BPMN верен, а также анализ кода дает положительные результаты. И наоборот, несоответствие может произойти в сопоставлении между ними. Например, версии кода и версии процессов, типизация данных, значения, аномалии потока данных. Интегрированный набор инструментов будет оптимальным для совместной работы проектировщиков процессов и разработчиков программного обеспечения.

Метамодель наукоемких процессов

Интеллектуальные процессы ориентированы на сотрудничество и достижение цели, событийно-ориентированные, возникающие и непредсказуемые, гибкие и, как правило, неповторяемые.

Как мы можем использовать моделирование процессов для этих процессов? Они не могут быть полностью указаны во время разработки, также потому, что большая часть знаний является неявной, и во многих случаях причины шагов принятия решений пользователями неизвестны. Самым важным активом в этой среде является Case, то есть аспекты статуса, контекста и среды, а также поведение, связанное с выполнением. Поведение определяется во время выполнения, потому что вы не можете применить его статически. Второй важный актив - это сами Знания, которые должны охватывать цели, показатели, тактику и бизнес-правила. Несколько других компонентов важны, и они составляют исчерпывающую метамодель, которая может помочь в спецификации таких случаев, которые, как правило, трудно оценить.

Пошаговая проверка эволюционирующих рабочих процессов

Тот факт, что рабочий процесс процессов развивается во времени, создает интересные проблемы для проверки. Способы развития процесса могут быть разными: изменение объектов, задач, потоков. Мы можем определить набор возможных ограничений эволюции и проверить модель с помощью различных стратегий: восходящего построения (когда изменения распространяются от корневого узла), спинового и инкрементального. Инкрементальные методы могут автоматически построить модель дерева процессов из входного процесса, а затем управлять развитием процесса, обновляя модель дерева и проверяя только затронутые части процесса (см. Рисунок ниже).

Поэтапная проверка намного эффективнее для количества действий, так как нужно проверять только новое изменение. Вместо этого спин более эффективен в отношении времени и краев.

В итоге…

Я думаю, что самый важный вывод, исходящий из этого разнообразного набора материалов и связанного с ними обсуждения, которое они подняли, заключается в том, что существует множество возможностей для еще не использованных методов, чтобы внести свой вклад в оптимизацию операций предприятия и бизнеса.

Я с нетерпением жду возможности собрать больше и поделиться ими в будущем. Между тем, если вы нашли полезные приемы, которыми хотите поделиться, не стесняйтесь комментировать эту историю, и я свяжусь с вами.

Эта история опубликована в The Startup, крупнейшем предпринимательском издании Medium, за которым следят +445 678 человек.

Подпишитесь, чтобы получать наши главные новости здесь.