Как и зачем переходить от статусов к процессам

В корпоративных системах есть понятие статуса. В CRM это “холодный”, “горячий”, “новый”, “закрыт”. В документообороте — “Зарегистрирован”, “На согласовании” и “Исполнен”. Через статусы можно эмулировать бизнес-процессы, но до определенной степени. О том, как (и зачем) переходить от “статусов-стадий” к процессам читайте в этой статье. Она сложная, приготовьтесь.

6 проблем статусов

Статусы — это способ контролировать состояния заявок, договоров, сделок. Они отлично работают пока статусов немного, статусы не влияют друг на друга. Статусы работают, пока могут перепрыгивать туда-сюда по воле пользователя или строго в одном направлении. Но при усложнении логики у статусов появляются проблемы. Статусы можно воспринимать как FSM, конечный автомат (см. вики).

1. Нужно помнить прошлое

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

Однажды окажется, что в предыдущее состояние переходить нельзя.

У разработчика будет 2 пути:

• Выразить факт прохождения статуса “Новый” через атрибут сущности. Например:  есть “Документ” ,  добавляем атрибут “Был в статусе “Новый”. При попытке перевести “Документ” в статус “Новый” проверяем атрибут.
• Добавить дополнительную таблицу пройденных статусов и проверять в ней.

Если развивать эту мысль, то при любой смене статуса нужно перепроверить все атрибуты.

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

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

2. Нужно N-состояний одновременно

Одного статуса может не хватить. Добавление дополнительного состояния заставит разработчика пересмотреть и переписать всеавтоматизации, завязанные на статусы.

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

3. Рекурсия

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

4. Комплексный рост сложности и скорости разработки

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

• 2 атрибута и 2 статуса дают 4 перестановки.
• 3 атрибута и 3 статуса дают 27 перестановок.
• 5 атрибутов и 5 статусов дают 3125 перестановок.

5. Доказательство проходимости и сложность тестирования

Тестировать статусы сложно — на каждую перестановку нужно писать тест. А если поменялись статусы или атрибуты, то нужно всё перепроверять и\или переписывать.

6. Несколько сущностей меняют статусы друг другу

Представьте:

• Из одного документа нужно родить 4 новых,
• Прогнать их независимо
• Переопределить статус основного, в зависимости от результатов обработки указанных 4 документов

Это много кода и тестов, которые не имеют ценности.

---

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

Переходим к процессам

Нужно вводить отдельную сущность — экземпляр процесса и процесс.

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

В этом смысле это классическое сравнение FSM и сетей Петри. На эту тему написано несколько научных статей, например эта. 

Для сложной структуры нужна правильная модель предметной области. BPM-движки или BPMS-системы (например Camunda) все предлагают такую структуру:

• Deal — бизнесовая сущность. Она может участвовать в большом количестве Process Instances. Во всех процессах бизнес-сущности свои.
• Process Instance — конкретный запуск процесса по сущности.
• Process Definition — описание процесса, которое содержит все возможные варианты его развития.
• Activity Definition — описание конкретной задачи(статуса), которое может быть достигнуто в процессе.
• Activity — конкретная задача, которая выполняется сейчас, с возможными переходами.

В случае со статусами понятия логически существуют, но они размазаны по сущности как атрибуты или хранятся в коде:

Алгоритм перехода

Для описания процессов будем использовать BPMN — это простая и понятная нотация, которая к тому же исполнима. Это значит, что существует софт, который возьмёт за вас заботу о Process Definition, Activity Definition, Process Instance и всем вокруг. Останется позаботиться об конкретных Activity и описании процессов.

1. Стадии как промежуточные события

Представим, что у нас есть сущность, которая проходит статусную модель:

Нарисуем её в формате BPMN:

Для каждого статуса используем промежуточное событие. Из промежуточного события не может выходить больше 1 потока управления, поэтому в таких местах ставим развилки.

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

Судя по схеме, кандидатами на стартовое событие это A, а завершающее — это F.

В BPMN стартовое событие не может иметь входящих потоков управления. Статус A выполнял 2 функции — старт процесса и показывал выполнение какой-то работы. Нарисуем это:

2. Разбираемся с развилками

Статусы — это отражение того, что-то то было выполнено или должно быть выполнено, но в неявном виде. А при создании процесса мы должны вытащить это явно на диаграмму.
Почему после статуса E можем перейти в статус C или статус F? Кто-то или что-то принимает решение, что нужно перейти куда-то. Если это решение принимает человек, то изобразим это так:

Если решение принимает скрипт, то можно изобразить так:

Сделаем тоже самое со статусами C->D  или C-A1:

3. Выясняем, почему меняются статусы

Между А1 и B  что-то происходит, из-за чего сущность меняет свой статус. Нарисуем:

4. Уточняем бизнес-смысл происходящего

Необходимо понять смысл каждого квадратика.

Мы перестаём перещелкивать статусы, а начинаем делать работу в рамках процесса.

5. Проверяем квадратики: достаточность информации

Берём 2 квадратика и задаём вопрос — действительно ли после выполнения первого квадратика возможно выполнить второй:

Добавляет задачи, которые пропустили:

6. Проверяем квадратики: а что если?

У каждого квадратика подразумеваем успешное выполнение. А что если задача будет выполнена не успешно — например при проверке контрагента он оказался плохой? Нарисуйте такие развилки и реакции на них:

Поздравляю, теперь у вас есть первая версия процесса.

Что мы получаем и чем платим

Процесс избавляет вас от проблем:

• Прошлое не нужно помнить — за счёт наличия маркера текущих Activity вы знаете состояние процесса. Не нужно сохранять это состояние на сущность. Это разделяет сущность от её процессов, что дает возможность развиваться независимо.
• N-состояний — за счёт process definition и activity definition, а так же независимости сущности от процесса, возможно иметь сколько угодно одновременно состояний в процессе.
• Рекурсия — не страшна, т.к. мы знаем все возможные переходы и нам не больно их учитывать. Всегда знаем путь, по которому сущность дошла до текущего состояния.
• Рост сложности — избавлены от него, т.к. данные разделены и от процесса, есть понятие Activity, являющееся кирпичиком процесса. Activity может добавляться\редактироваться независимо от остальных элементов процесса.
• Доказательство проходимости — подпроцессы на BPMN это подмножество сетей Петри. Существует возможность математически доказать,что сеть Петри проходима.
• Несколько сущностей — process definition могут включать в себя другие process definition, в которых обрабатываются другие сущности.

За это мы платим:

• Дорого в реализации — нужно врубиться в технологии BPMS, понять как работает BPMN. У меня на онлайн-курсе 1204 можно сократить стоимость и срок осмысления.
• Нужно врубаться в процессы — подход с процессами требует от айтишников понимания процессов и бизнеса.

Где хороши статусы

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

В итоге

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

Как вам статья? Приходилось ли работать со статусами и страдать? Напишите в комментарии и поделитесь статей в соц.сетях.