Автоматизация бизнес-процессов или что такое «Сложность». Часть 1

image


Про автоматизацию бизнес-процессов (БП) написано много. В литературе, да и в интернете, хорошо описаны преимущества автоматизации повседневных рутинных процессов посредством Business Process Management (BPM), а также Workflow Management Systems (WMS).


Цель этой статьи — пойти дальше и рассмотреть, что же конкретно подразумевает под собой слово "Автоматизация" и почему увеличение требований к моделям процессов непременно приводит к увеличению сложности самой системы, и как с этим бороться.



В начале статьи остановлюсь на теоретических основах классификации БП по степени их устойчивости к изменениям и затем коснусь технического аспекта моделирования БП.


В середине статьи попытаюсь объяснить, почему системы получаются сложными, на примере похожих по звучанию понятий "Сложность" и "сложный", но имеющих разные смысловые значения.


В конце статьи приведу конкретные примеры борьбы со Сложностью на примере моделирования адаптивных БП.


Итак, для полной ясности, о чём идёт речь, привожу классификацию БП по степени их устойчивости к изменениям, по структуре процессы различаются от чётко структурированных до коллаборативных.


Рисунок 1: степени устойчивости БП к изменениям [источник Vos 1997, S. 40]


image


Из рисунка 1 видно, что структурированные процессы эффективно поддерживаются обычными WMS и BPM, тогда как полу-структурированные и коллаборативные требуют более гибких IT решений.


Tут главное понимать, что к каждому из перечисленных классов должен применяться свой подход при моделировании БП. Нельзя гаечным ключом крутить шурупы, а отверткой пытаться затянуть гайки.


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


image

Рисунок 2: технические концепции [источник Aalst u. a. 2005, S. 158]


Во избежание путаницы приведу основную идею каждой концепции:


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


SOA – это сервисы, которые имеют интерфейсы согласно стандарту OASIS. Это обеспечивает упрощённый способ общения между сервисами.


Case Management oder Adaptive Case Management (ACM) — поддерживают непредсказуемые сценарии. Эти системы эффективны для не повторяющихся и уникальных бизнес-сценариев.


Ad-hoc-Workflow – процессы, в модель которых встроена возможность изменения потока работ "на лету" (также в уже запущенной инстанции процесса).


Groupware – ПО для поддержки взаимодействия между людьми, совместно работающими над решением общих задач.


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


С категориями и инструментарием более-менее разобрались, остаётся разобраться с внешними факторами; вроде как всё правильно сделали — шуруп закручиваем отвёрткой, а гайки ключом, но что-то всё равно "туго" идёт. Может, вкручиваем шуруп в бетон или отвёртка прокручивается.


Почему одни процессы лёгкие, а другие бывают сложными при моделирования и реализации?


Возможно, кто-то сразу ответит: "… потому что разные требования к процессам. При возрастании требований к функционалу процессов, возрастает и их сложность".


Для начала необходимо разделить два понятия "сложный" (англ. complicated; нем. kompliziert, Kompliziertheit ) и "Сложность" (англ. Complex; нем. komplex, Komplexität). Очень часто эти два термина принимают за одно и тоже, но между ними есть существенная смысловая разница.


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

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


Понятие "Сложность" — это скорее состояние системы, когда при известных компонентах конечный результат не предсказуем.

Примером "Сложности" служит футбол или оркестр. На футболе, при всех известных параметрах игроков и тактики, исход игры предсказывать невозможно. Как и в оркестре — результат зависит также ещё и от многих внешних составляющих. Так, например, звучание оркестра не зависит напрямую от партитуры и умения музыкантов, сюда добавляются такие факторы, как акустика помещения, электрическое усиление звука, сама публика и даже визуальное восприятие.

Другими словами:


Когда система (дело, проект — не зависит от контекста) вызывает Сложность, то для её преодоления потребуются новые знания, которые нужно будет понять (переосмыслить, принять, изменить точку наблюдения, измениться самому).


Когда система (дело, проект — не зависит от контекста) сложная, то потребуется приложить усилия с уже имеющимися знаниями.


Из вышеизложенного следует интересная формулировка работы проект-менеджера:


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

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


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


Этот пункт значительно актуален, если срок жизни инстанции БП > периода релиза модели БП. Другими словами, у меня появляется возможность поддерживать эволюцию данного бизнес-процесса "на лету" — без перезапуска инстанции БП.


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


Согласно рис. 2 воспользуюсь принципом Ad-Hoc Workflow. Этот принцип хорошо подходит для задач, когда начальная модель БП известна и последующие изменения применяются как к запущенным, так и ко всем последующим инстанциям БП.


Сформулирую основные правила эволюции предьявляемые к Ad-Hoc процессам:


  • Инстанция БП всегда запускается только в последней версии, запустить устаревшею версию БП невозможно (этим самым препятствуя попадания процесса в dead lock)
  • Возможность параллельного существования нескольких версий одного и того же БП
  • Переход к новой версии возможно запретить, таким образом давая возможность инстанции закончить первоначальный воркфлоу

Теперь можно перейти к структурному примеру изменения модели БП. Два самых распространённых сценариев при изменении модели БП следующие:


  1. добавления нового task в модель
  2. удаление существующего task из модели

Добавление нового Task


Необходимо добавить таск 3 в модель БП.


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


Пунктирные линии показывают перемещение токенов между версиями БП:


add new task


Удаление существующего Task


Необходимо удалить таск 2 из модели БП. Удаление происходит в три шага, версия 2 — промежуточная, конечная версия — версия 3.


Шаг 1: токены перемещаются из версии 1 в версию 2. Во второй версии таск 2 для новых инстанций уже недоступен. Инстанции, запущенные из версии 1, и которые уже начали выполнения таска 2, закончат его выполнение.


Шаг 2: в версии 2 таск 2 постепенно "отмирает", так как инстанций в версии 1 больше не запускаются и поток токенов в таск 2 из версии 1 прекратится ( второе правило эволюции БП).


Шаг 3: после полного "отмирания" таска 2, добавляется версия 3 — уже окончательная, без таска 2, который с уверенностью уже не потребуется.


(Пунктирные линии показывают перемещение токенов между версиями БП).


delete task


В этой статье был рассмотрен переход от "Сложности" при изменениях в модели БП к сложной задаче моделирования адаптируемых БП "на лету".


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


Также может быть полезна статья «Все что вы хотели узнать о BPM, но боялись спросить» sshikov, где автор описывает технические проблемы при реализации изменений модели БП.


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


Спасибо за внимание!

Ads
AdBlock has stolen the banner, but banners are not teeth — they will be back

More

Comments 15

    0
    Хорошая тема. Мне на самом деле почему-то почти не попадались публикации, где бы рассматривались вопросы миграции вот в таком вот плане. Т.е. мигрировать вроде бы и можно — а практически получается, что ряд изменений процесса приводят к невозможности миграции запущенных экземпляров.
      0
      Действительно, тема как вы подметили практически не освещена в русскоязычном сегменте. Поэтому был удивлен прочитав вашу статье по этой тематике, что и послужило одним из импульсом для продолжения данной темы. Буду рад услышать ваше мнение о прототипе в следующей части статьи.
        0
        Как то странно выглядит логика удаления таска 2.
        Мне кажется, в версии 2 (промежуточной) надо от таска 2 переходить не к завершению БП, а к таску 3. Иначе нарушается логика всего бизнес процесса.
          0
          Вы правы! Исправил.
          0
          По моим наблюдениям матрицы более полно и просто описывают бизнес-процессы, хотя менее наглядно. Как-нибудь напишу свои соображения как формализировать БП с помощью матриц.
            0
            интересно, может подскажите ссылки на источники?
              0
              К сожалению все в голове: математика, конечные автоматы, графы, булевая логика, статистика, вероятности.

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

              Например, возьмем простой случай — договора. Можно написать матрицу сочетания типа клиента (ЮЛ, ФЛ) и тарифного плана (к примеру есть план Стандарт и VIP).

              Теперь допустим имеются такие слова: «для всех договоров ЮЛ» делаем действие1. Для всех «договоров Стандарт» делаем действие2.

              На матрице сразу видно противоречие, что «для договоров ЮЛ с тарифом Стандарт» будет непонятно какое выполнять действие — 1 или 2. И сразу будет видна вероятность попасть на противоречие.

                0
                Для объекта — понятно, как можно составить матрицу.
                Но как быть с бизнес процессом в целом? БП может разветвляться и ветви выполняются без синхронизации. Например, синхронизация в самом конце. Ведь для такого процесса понадобится ОЧЕНЬ большая матрица… И представить процесс как набор матриц отдельных шагов или объектов наверно не получится. По крайней мере я не представляю, как.
                  0
                  Ведь для такого процесса понадобится ОЧЕНЬ большая матрица


                  Согласен, если количество значений параметров N, то для анализа сочетаний нужна матрица N*N. Но зато будет видна вся картина. Алгоритм элементарный, только данных много.
                    0
                    Даже простой БП может содержать больше 100 значений параметров. Проанализировать матрицу 100*100 человеку уже крайне тяжело. А многие реальные процессы могут содержать тысячи значений параметров.
                    Так что матрица заменить BPMN не может. Ведь с диаграммами в первую очередь работают люди, а они не могут воспринимать гигантские матрицы.
                    Разве что жить в них могут. :)))
                      0
                      100*100 человеку уже крайне тяжело

                      Вручную тяжело, а вот если автоматизировать, то быстро.

                      Даже матрица 10 000 * 10 000 будет содержать 100 000 000 клеток (100 млн) — для персонального компьютера это не предел. Даже в памяти легко поместится.
                        0
                        Так диаграммы и нужны в первую очередь для того, чтобы на них смотреть «вручную».
                        Описание бизнес процесса надо сначала придумать (создать), и только потом верифицировать, запускать на выполнение и т.п. И придумывают описание БП «вручную». Я допускаю, что есть люди, которые могут создать описание БП в виде матрицы 1000*1000. Но таких явно ОЧЕНЬ мало. А все остальные используют BPMN.
            0
            Логично был бы в этом примере принцип дизъюнкции, т.к. «договора ЮЛ с тарифом Стандарт» входят в оба множества, но все зависит от конкретного контекста.

            Матричный подход напомнил мне сразу Decision Management — стандарта DMN 1.1, который активно используется внутри BPM процессов как Business Rule Task.
              0
              Да, хорошо бы было бы, если система сама находила у себя противоречия такого толка. Особенно актуально при внедрении новых изменений
                0
                Рад бы вам помочь, но лекарства от всех болезней пока не придумали, иначе в апеках продовалась бы всего одна таблетка

            Only users with full accounts can post comments. Log in, please.