Workflow, BPMS, крупные компании и наш опыт

В процессе обсуждения предыдущей статьи про No-Code и Low-Code поднялась тема BPMS. Это очень большая, сложная и интересная тема, которую невозможно охватить за раз. Поэтому просто немного расскажу о нашем опыте, по возможности простым языком и с прицелом на широкую аудиторию.

Меня зовут Константин Митин, я сооснователь и руководитель компании itMegastar/itMegagroup. Когда-то был простым разработчиком, работал в L3, дорос до тим-лида, затем и до руководителя филиала разработки крупной ИТ-компании. Теперь я в itMegastar.

В самом начале стоит отметить, что разработка и внедрение информационных систем в крупных компаниях — это сложный и многогранный процесс. Для него не существует и не может существовать «серебряной пули», то есть какого-то волшебного инструмента либо волшебного метода, который легко и просто решит все проблемы.

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

Рассказывая о нашем опыте, я попробую показать участникам проекта, что происходит в невидимых для них областях. Поэтому я расскажу немного о той платформе, с которой сам когда-то начинал. После чего мы посмотрим на логику разработчика и те проблемы, которые ему приходится решать. Затем посмотрим, а при чём здесь BPMN (Business Process Model and Notation) и BPMS (Business Process Management System). И перейдём к примеру разворота новой информационной системы в крупной компании. В качестве BPMS будет Camunda.

Из личного опыта.

Когда я начинал работать простым программистом, мне довелось поработать с платформой Lotus Notes/Domino. Это нишевый продукт для крупных компаний (хотя бы от 4 тысяч сотрудников), который позволял автоматизировать совместную работу и выстраивать электронный документооборот на базе высокоэффективных геораспределенных информационных систем с серьёзными инструментами криптозащиты, развитым функционалом контроля доступа и селективной мастер-мастер репликацией данных. Приложения Lotus Notes/Domino могли работать на очень плохих каналах связи, вплоть до того, что один сервер мог напрямую позвонить другому серверу по телефону и передать ему сколько-то гигабайт данных. Плюс способность без последствий уходить в «оффлайн» для целых сегментов сети, не говоря уже о рабочих местах пользователя.

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

В глубине платформы использовалась документоориентированная NoSQL база данных. Понятия «схемы базы данных» там не существовало, документ — это просто набор полей (и далеко не в JSON). В рамках одного документа поля могли иметь одно и то же имя, но разные типы, база данных не возражала.

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

Здесь же возникала интересная и неожиданная проблема. Работая с таким инструментом, сотрудник очень быстро переставал быть «простым» программистом, от него уже требовалось глубокое понимание и способность к программированию распределенных систем (параллельное программирование будет попроще). Если человек с таким справлялся, то благодаря платформе он мог в одиночку работать, как целый отдел программистов. Справлялись, конечно, не все.

Высокая эффективность работы и высокая требовательность к квалификации в результате приводили к кошмару для HR. Представьте, что в городе-миллионнике всего 6-10 специалистов, они все друг с другом знакомы и знают, на каких условиях, где и кто работает. И каждый отвечает за критичные сервисы в своих компаниях. Когда кто-то из них менял работодателя, начиналась моментальная цепная реакция на рынке.

С точки зрения бизнеса — это очень небезопасная и плохая ситуация. Это плата за «волшебные» инструменты. В англоязычной литературе есть выражение «bus factor». Представьте, что ваш ключевой сотрудник выходит из офиса и его насмерть сбивает автобус. Из-за таких рисков часто «плата за волшебство» может быть неприемлемой для бизнеса.

А какая задача-то?

Теперь отложим в сторону инструмент разработки и поймём, какую задачу мы будем решать. Для простоты возьмём систему типа «Служебные записки». Это некоторая абстракция над целым классом документов, от заявок на отпуск, выделение ресурсов до поручений.

Первое, с чем вы столкнётесь в таких системах, так это с понятием «начальник». Например, нашу служебную записку должен подписать непосредственный руководитель сотрудника. В чем проблема?

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

И вот человек хочет в отпуск. С кем он должен его согласовать? Допустим, с непосредственным руководителем. А с каким? Зависит от компании.

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

Кстати, согласование тоже может быть непростым. Хорошо, когда на какой-то стадии согласует один человек. А если нет? У нас же уже звучало слово «заместитель»? Значит согласуют два человека, для этапа хватает подписи одного из них, разновидность параллельного согласования. Бывает ещё последовательное согласование, либо согласование нужного количества из всех параллельных согласующих.

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

Пусть наши бизнес-аналитики, бизнес-технологи, технические писатели (там трактат можно написать, расписывая логику), программисты и тестировщики во главе с руководителями проектов (бизнесовым и техническим) уже поработали над этим. То есть алгоритмы согласованы, реализованы и протестированы, хорошо работают (вряд ли) и доступны, как API (Application Programming Interface - программный интерфейс приложения).

Все же ещё немного.

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

В итоге мы получили какой-то workflow для нашего документа, нам известны этапы согласования и ответственные за этапы. Что происходит дальше?

Дальше приходит программист и «хардкодит» все это. То есть жёстко зашивает логику процесса в программный код. Благо ответственных за этапы мы уже по API получаем. Иными словами, реализуется «кнопочное workflow». В рамках небольшого проекта и небольшой компании этого могло бы и хватить. Но тут приходит кто-нибудь из бизнес-заказчиков и говорит что-то вроде: «Нужно добавить согласование функционального руководителя». Мы же его выкинули из процесса? Вот он внезапно нашёл способ вернуться.

Процессы в большой компании меняются постоянно. Код придётся постоянно дорабатывать и изменять. От этого код «устаёт», в нём начинает возникать больше ошибок, в какой-то момент на продуктиве могут возникать критические ошибки.

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

Здесь же сразу встаёт другая проблема, о которой уже подозревают люди, знакомые с BPMN. Дело в том, что BPMN работает в совсем иной парадигме, которая не будет укладываться в вышеописанную систему настраиваемого workflow.

В первом случае мы тащим документ по процессу, а BPMN работает с «описанием процесса», «экземпляром процесса» и «задачами пользователя». В рамках BPMN у документа не будет статуса «согласования у руководителя», вместо этого у экземпляра процесса один из токенов породит задачу пользователя «согласовать заявку».

Это два очень разных подхода, которые требуют разного проектирования, в том числе и UI/UX. Беда в том, что люди привыкли думать в рамках естественного (бумажного) workflow, а специалисты по оптимизации процессов в рамках BPMN. Как итог мы получаем интерфейс системы с UI/UX, заточенный под естественный workflow, а описание самого процесса в BPMN, и здоровенный блок кода, который адаптирует первое ко второму.

На заметку руководителям проекта, бизнес-аналитикам и UI/UX специалистам.

При проектировании новой системы очень важно, чтобы все её части гармонировали друг с другом. Если вы используете BPMN и BPMS, то и интерфейсы системы должны быть в концепции BPMS. Только тогда она будет масштабируемой и легко расширяемой.

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

Следующий момент, легко сказать: «Делай так, остальное неправильно». Но ведь нужно ещё согласовывать БТ (бизнес требования), ФТ (функциональные требования), ТЗ (техническое задание), макеты и прочие с бизнес-заказчиками, а они зачастую не мыслят в рамках BPMN. Бизнес-аналитикам и UI/UX специалистам тоже приходится не сладко. Как и руководителю проекта, он вообще почти во всем участвует.

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

Это позволит сэкономить ресурсы программистов на реализацию «конфигуратора workflow», им выступит сама BPMS. Но вот работа руководителей проектов, бизнес-аналитиков, системных аналитиков, архитекторов, технических лидеров, UI/UX специалистов, QA специалистов, DevOps инженеров, бизнес-заказчиков, специалистов поддержки, специалистов по обучению и прочих заинтересованных сторон никуда при этом не денется.

Если вам обещают обратное, обещая, что BPMS будет «серебряной пулей», не верьте этому. Вместо этого просто разберите на пальцах, а что нужно будет делать, когда вам придётся запускать новый бизнес-процесс с автоматизацией. Например, у нас уже есть заявки на отпуска, а мы теперь хотим и заявки на командировки. Какие специалисты при этом будут задействованы, что им придётся делать. Можете даже запросить составить смету работ от подрядчика на второй (виртуальный) этап работ.

Как для нас выглядело реальное внедрение?

Нужно было реализовать портал по обработке заявок определённого вида в одной из крупных компаний. В качестве BPMS ещё до нас выбрали Camunda, специалистов по ней у нас не было, их обещал предоставить наш партнёр, позвавший нас в этот проект.

На вход мы получили какое-то БТ и бизнес-аналитика из компании заказчика, какую-то архитектурную схему, которую потом пришлось несколько доделать, и Camunda в нагрузку. А ещё на проекте со стороны заказчика практически сразу поменялся руководитель проекта. Почему так? А просто у проекта были сжатые сроки, БТ слишком долго собирали. Ну и это была где-то пятая попытка внедрить бизнес-процесс по этим заявкам в компанию. Предыдущие — провалились.

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

Конечно, мы начали с проектирования. Ведь кроме Camunda и портала там была куча сторонних систем. Например, нужно SSO через AD FS, а ещё есть сервис ЭЦП (заявки подписывались), со своим отдельным AD FS. Подписанные документы нужно было как-то визуализировать, это ещё один сервис. Нужно было использовать сервис архива кадровых документов. Нужно было использовать сервис архива финансовых документов. Кроме этого, был SAP PI, SAP HR, SAP ERP, и ещё немного иных сервисов и команд, в том числе и внешних. Плюс DevOps и архитектурные комитеты.

То есть с каждой внешней системой нужно проработать интеграции, потоки данных, согласовать API и алгоритмы взаимодействия. Где-то можно слать запросы напрямую, где-то нужна синхронизация данных (выгоднее хранить у себя проекцию данных). Часть процессов в одной системе сильно завязана на процессы в других системах. А где же Camunda?

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

Чтобы все это обсудить, согласовать и прочее, было проведено несколько сотен встреч с нашим участием, в которых кроме нас было от 2-5 человек до 10-20. Это только встречи с нашим участием, но ведь были и другие.

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

В процессе проектирования оказывается, что кто-то чего-то не может. Например, сотрудники нашего партнёра не смогли внятно объяснить, как Camunda хранит данные и можно ли туда сложить все данные по заявкам и работать с данными через API Camunda.

Для того, чтобы разобраться с BPMN и технической документации Camunda у меня ушло 2 недели работы в фоне. Это не какие-то тайные знания. В сети полно материалов по BPMN, по работе с Camunda, как с BPMS, техническое описание Camunda есть на их сайте. После этого стало понятно, что компетенция сотрудников нашего партнёра минимальная, мы просто перестали с ними работать (через какое-то время отдел по работе с Camunda у партнёра исчез). Вместо этого наш разработчик за неделю научился работать с Camunda. Я просто показал ему, что и где изучить, а дальше он смог сам.

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

Нельзя не сказать о том, что с Camunda тоже бывают проблемы. Это open source продукт, в котором после обновления может внезапно отвалиться какой-то функционал. Иногда приходилось разбираться, почему у одного что-то работает, а у другого — нет. О ситуации рассказали нашим DevOps, они осознали, что везде, включая продуктив, должна стоять конкретная сборка, в которой мы уверены.

Как существовал проект?

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

Поэтому, когда мы слышим, что достаточно просто внедрить BPMS либо ERP систему, а после все начнёт решаться само собой, мы начинаем улыбаться. Эти инструменты несколько облегчают работу объединённой команды, но не более того.