В предыдущей статье Логика бизнес-процессов - часть 2 были рассмотрены основные категории бизнес-задач, перспективные модели, условия корректировки бизнес-процессов.
В этой части я расскажу о том, как приступить созданию схем бизнес-процессов, если у программиста ещё мало опыта в этом виде разработки.
Напомню, что любой программист силён знаниями алгоритмизации. Программист может не знать специфику бизнеса заказчика, но опыт построения алгоритмов пригодится в консультировании заказчика по вопросам оптимизации бизнес-процессов.
Итак, что делать если задачу по составлению бизнес-схем поставили и надо приступать к работе?
Способ создания схемы бизнес-процесса и полезные рекомендации
Можно воспользоваться простым планом, отображённым в следующей схеме:
Об источниках рабочих функций сотрудников я рассказывал в первой части серии статей Логика бизнес-процессов. Из них можно составить схемы функционала "КАК ЕСТЬ" с помощью приемов, о которых я расскажу в этой статье позже.
Текстовый регламент "КАК НАДО" возникает на основе правил оптимальной алгоритмизации и корректирующих факторов, о которых я говорил во второй части серии этих статей.
Реализация схем в коде бизнес-приложения происходит после формализации с помощью выбранной нотации. В этой статье я выбрал для примеров алгоритмов нотацию 1С.
Перед началом рассмотрения примеров повторю некоторые полезные рекомендации:
- каждое действие в схеме должно быть выражено в повелительном наклонении, должны быть определены: ответственный, пусковое событие, срок исполнения и форма выдачи результата
- при создании действия нужно проверять "что произойдет, если результат выполнения действий будет отрицательным" - например, "согласовать договор с клиентом" - а, что произойдет, если согласовать не удастся?
- при составлении сложных алгоритмов нужно делить процесс на подпроцессы - это добавляет уровни вложенности, но упрощает визуальное представление
- нужно проверять, чтобы во всех вариантах процессных линий были точки выхода или возврат на линию с точкой выхода
- если в разных ветках есть одинаковые группы действий, то имеет смысл создать из такой группы один подпроцесс, вызываемый в нескольких местах.
Рассмотренные далее примеры, приводятся в упрощенных вариантах и выполнены, в основном, в одном уровне.
Примеры алгоритмов бизнес-процессов
1. В этом примере используется условие с вариантами результатов Да/Нет, что позволяет работать в режиме повторов (цикла).
Как видно на схеме, можно неограничено вносить изменения в документ - в случае несогласования документа наступает действие по обработке замечаний.
Этот бизнес-процесс может быть вложенным подпроцессом, как показано в следующем примере.
2. Пример бизнес-процесса "согласование договора с клиентом" использует не только вложенный подпроцесс, но и проверку решения клиента с учётом нескольких вариантов.
В схеме предусмотрены точки завершения процесса с отрицательным и положительным результатом. Вариантов решения может быть неограниченное количество, в данном случае их три.
Вложенный подпроцесс согласования документа принимает вводные условия клиента и возвращает согласованный руководством исполнителя вариант для повторного согласования с клиентом.
3. Пример процесса "Подготовка договора" предусматривает работу трёх возможных циклов:
- повторы при отрицательном утверждении руководителем
- доработка формулировок при юридической проверке
- утверждение руководителем существенных изменений при юридической проверке.
4. Пример бизнес-процесса "Маркетинговое мероприятие", кроме предусмотренного цикла согласования мероприятия, использует приём запуска параллельных процессов в одном из которых, запускается даже вложенный подпроцесс "Согласование договора".
Алгоритм предусматривает две точки завершения и точку слияния параллельных процессов в одну процессную линию перед действием "Анализ эффективности".
Как видно из примерных моделей, самыми распространёнными приёмами являются:
- ветвление с условием Да/Нет
- использование точки выбора вариантов, если их много (в классическом программном коде это реализуется с помощью оператора switch или вложенными многократно условиями if else)
- запуск параллельных процессов с помощью точек разделения - количество процессов не ограничено
- создание нескольких точек выхода с разными результатами.
В случае устаревания бизнес-процесса, его заменяют новой модернизированной версией, а старый в документированном виде помещают в архивный репозиторий.
В следующих статьях этой серии речь пойдет о декомпозиции бизнес-процессов и их оптимизации.
автор публикации: Демешин С.В.