Как перейти от первых проектов к успешной автоматизации сотен процессов с помощью гибкого пошагового подхода.
Нам часто задают такие вопросы:
— Как масштабировать внедрение Camunda в рамках всей компании?
— Как создать корпоративную платформу для управления процессами?
Мы видим, как масштабно Camunda используется в таких компаниях, как Goldman Sachs (3000 процессов, 8000 пользователей в день), Societe Generale (600 процессов, 60 000 завершённых задач в месяц, 7500 активных пользователей) или 24Hour Fitness (800 процессов, 230 миллионов выполнений активностей в день). Как нам достичь такого уровня?
Вот почему я написал этот блог-пост. Спойлер: если вы хотите создать корпоративную платформу — не начинайте с корпоративной платформы!
История успеха из реальной жизни
Давайте разберёмся, почему, и начнём с истории успеха из реальной жизни, с которой многие наши клиенты могут себя ассоциировать. Речь пойдёт о страховой компании с примерно 7000 сотрудниками, за прогрессом которой я наблюдал последние пять лет. К сожалению, я не могу назвать её.
В 2014 году они собрали команду для автоматизации обработки определённых видов страховых случаев по автогражданке. На тот момент существующий процесс обработки заявлений был в основном ручным и охватывал несколько подразделений. Это позволило легко обосновать бизнес-кейс для проекта и заручиться поддержкой топ-менеджмента. Дополнительным фактором стала стратегическая инициатива по усилению «процессной ориентации» — на тот момент это была горячая тема для страховых компаний.
В рамках проекта они:
выбрали инструмент для управления процессами,
смоделировали процесс,
реализовали полное решение,
интегрировали его с существующим пользовательским интерфейсом,
интегрировали с существующей SOA-инфраструктурой,
выгрузили релевантные данные в хранилище данных,
и запустили процесс в эксплуатацию и начали его сопровождение.
Проект прошёл относительно гладко и занял около 12 месяцев.
После этого команда была реорганизована в отдельное подразделение. Ей поручили помогать другим командам в проектировании и разработке решений на основе процессов. В первые два-три года они выполняли значительную часть работ по реализации, но со временем трансформировались во внутреннюю консультативную группу, которая «просто» помогала командам стартовать.
Они естественным образом стали центром компетенций по вопросам и обсуждениям, связанным с процессами, и тем самым не только сохраняли накопленный опыт, но и способствовали его распространению по всей организации. Сейчас они ведут внутренний блог о BPM, организуют собственные обучающие курсы и ежегодное внутреннее мероприятие, где разные команды делятся лучшими практиками.
Хотя они разработали ряд инструментов поверх Camunda, они никогда не навязывали их другим. И хотя в 2015 году они начали эксплуатацию централизованной BPM-платформы, впоследствии отказались от этой модели, позволив командам запускать собственные движки. Они по-прежнему предоставляют переиспользуемые компоненты поверх Camunda — например, для интеграции с Active Directory или взаимодействия с внутренней ESB — но эти компоненты распространяются в виде дополнительных библиотек для команд, создающих свои решения.
К концу 2019 года у них в продакшене работало почти 100 различных решений на базе процессов. И довольны были не только участники команды по процессам, но и руководство.
Я ожидаю, что из таких историй можно будет выделить несколько типичных моделей. Эти модели и истории помогут другим пользователям учиться на чужом опыте. У вас есть своя история, которой вы готовы поделиться? Пожалуйста, свяжитесь со мной!
Элементы успешного пути внедрения
Из приведённого выше примера, а также из множества других историй, можно извлечь ряд полезных уроков:
Начинайте с проекта, а не с программы.
Не запускайте крупные и стратегические инициативы слишком рано. Двигайтесь шаг за шагом, пока не будете готовы к масштабированию.
Сдерживайте искушение создать собственную платформу.
Получите одобрение от лица, принимающего решения. Это гораздо проще сделать, когда ваш процесс решает реальную проблему.
Пусть полученный опыт формирует вашу целевую модель, не полагайтесь вслепую на «лучшие практики» консалтинговых компаний.
Позвольте опытным людям участвовать в последующих проектах.
Фиксируйте лучшие практики и обеспечивайте обмен знаниями.
Предоставляйте переиспользуемые компоненты, если они повышают продуктивность, но в виде библиотек, которые команды хотят использовать, а не обязаны.
Постройте внутреннюю модель консалтинга, возможно, в форме центра компетенций. По крайней мере, найдите и поддерживайте одного известного энтузиаста внутри компании, который будет продвигать тему.
Определите траектории обучения для новых сотрудников или команд.
Обеспечьте проектам свободу действий и возможность принимать собственные решения.
Давайте подробнее рассмотрим некоторые из этих аспектов.
Этапы на пути внедрения
На основе сотен реальных проектов за последние годы мы выделили простую и эффективную модель внедрения инструментов для управления процессами в организации (наша консалтинговая команда описала её как best practice под названием путь к успеху клиента):
Начните с пилотного проекта. Его цель — определить и проверить архитектуру и технологический стек. Очень часто такой пилот делается в формате proof-of-concept (POC). Однако важно довести его до выхода в продуктив, чтобы получить реальный опыт на всех этапах жизненного цикла решения. Выберите такой сценарий, в котором можно показать хотя бы часть преимуществ автоматизации процессов (например, повышение эффективности, результативности, соответствия требованиям), — это заинтересует многих, включая лиц, принимающих решения, ведь им важны измеримые результаты.
Вскоре после успешного пилота стоит взяться за маяковый проект. У него должен быть более широкий и реалистичный охват, и он должен лучше демонстрировать архитектуру, инструменты и ценность автоматизации процессов для других сотрудников и команд вашей организации. Обязательно выберите значимый бизнес-кейс. Будьте осторожны, чтобы не попасть в «политически самоубийственные» проекты.
И только после этого наступает этап масштабирования использования Camunda по всей компании. Но и здесь стоит двигаться постепенно. Не выходите на широкий охват до тех пор, пока не накопите достаточно релевантного опыта хотя бы в нескольких проектах.
Начинайте с проекта, а не с программы!
Это настолько важно, что я сознательно повторяю это на протяжении всего поста: с самого начала сосредоточьтесь на том, чтобы приносить бизнес-ценность с помощью проектов по автоматизации процессов. Это значит две вещи:
Делайте конкретные проекты и избегайте стратегических платформенных инициатив как можно дольше. Слишком ранний акцент на стратегию создаёт высокий риск того, что вы долгое время не будете приносить никакой бизнес-ценности и застрянете в построении сложной платформы, не понимая её реального применения.
Отдавайте предпочтение гибким подходам к разработке, при которых процессные решения создаются итеративно и поэтапно. Это позволит вам быстро учиться и корректировать курс. Это очень положительная и мотивирующая спираль, которая хорошо зарекомендовала себя у многих клиентов.
Не застревайте в крупных платформенных инициативах
«Мы хотим построить корпоративную BPM-платформу (или платформу для автоматизации процессов) на базе Camunda — как нам это сделать?» — это очень распространённый вопрос, и у него обычно две мотивации. Во-первых, вы не хотите быть слишком зависимыми от Camunda. Во-вторых, вам может потребоваться интеграция с внутренними системами компании, которую смогут использовать все проекты. Некоторые компании даже собирают целый стек интеграции или SOA из компонентов разных вендоров.
Такой путь опасен по ряду причин: создать собственную платформу — это сложно, и это отвлекает от задачи доставки бизнес-ценности. Это мешает учёту опыта последующих проектов, ведь архитектурные решения принимаются слишком рано. Кроме того, такая платформа сложна в поддержке: её трудно обновлять, устранять баги, добавлять функциональность из новых версий. И наконец, по собственноручно собранной платформе нельзя просто так погуглить решение проблемы — а по известным open-source-продуктам можно.
Все подобные инициативы, которые мне доводилось видеть, сталкивались с трудностями — особенно если запускались слишком рано. Не стоит думать о создании собственной платформы, пока у вас не будет в продакшене нескольких проектов, чтобы реально понять общие характеристики и перепроверить ценность и применимость платформы в каждом случае.
Разумеется, в первых проектах вам всё же придётся сделать кое-что, чтобы удовлетворить операционные команды или архитекторов предприятия. Например, вы можете интегрировать решение с вашей инфраструктурой аутентификации и авторизации или убедиться, что инструменты для работы с процессами отправляют логи в вашу централизованную систему логирования.
Что стоит и чего не стоит делать при повторном использовании
Повторное использование может быть очень разумным решением — оно экономит усилия и снижает издержки. Если все ваши процессные решения должны взаимодействовать с вашей системой обмена сообщениями (а то и с мейнфреймом!), вам точно не захочется изобретать это заново в каждом проекте.
Но вместо того чтобы строить собственную платформу, можно использовать другой, гораздо более успешный подход. Представьте себе переиспользуемые компоненты или библиотеки как внутренние open-source проекты. Вы предлагаете их всей компании и обеспечиваете определённую поддержку. Если библиотека хороша — большинство с радостью будет её применять. Но никто не обязан это делать, за исключением, возможно, самых первых проектов, где такие библиотеки развиваются параллельно с реализацией. Если проекту нужна дополнительная функциональность — он не оказывается в тупике, а может создать pull request или просто форкнуть проект. Такая модель масштабируется куда лучше и не мешает командам быть продуктивными.
Camunda активно развивает поддержку именно такого подхода к переиспользованию — например, через каталог воркеров. Это позволит регистрировать внешние задачи-воркеры, которые затем легко можно использовать повторно в моделях процессов через графический редактор. Эти воркеры (или, если угодно, коннекторы) могут, например, подключать Camunda к вашей RPA-системе. Такой подход повышает продуктивность разработчиков, не ограничивая их только этими коннекторами. Он делает акцент на полезных рекомендациях, а не на жёстких ограничениях.
Почти во всех инициативах по работе с процессами появляется идея выделять «фрагменты процессов», которые можно переиспользовать в разных бизнес-процессах. Я настроен к этому скептически. Если это делается внутри одной команды — всё нормально. Но если предполагается делиться фрагментами между командами, то лучше не использовать «фрагменты процессов», а выделить полноценные сервисы с чётко определённой функцией и API. Наличие процесса внутри станет просто деталями реализации. Здесь уместна концепция ограниченных контекстов (bounded contexts), если вы знакомы с DDD. И это уже подводит нас к микросервисам.
Управление децентрализованными движками процессов
Вместо централизованных платформ я выступаю за подход, при котором каждая команда запускает свой собственный движок — особенно в контексте микросервисной архитектуры. Главное преимущество здесь — масштабируемость за счёт изоляции команд. Это означает, что при использовании микросервисов вы сознательно соглашаетесь на «зоопарк» установок Camunda! Обычно для команд это не проблема — они просто используют официальную документацию Camunda, а также ваши внутренние best practices или примеры.
Но как получить общее представление о том, что реально запущено? Как убедиться, что все установки Camunda содержат важные патчи? Все ли движки работают стабильно? И если вы используете корпоративную версию, вам нужно собирать метрики с разных движков, чтобы контролировать соблюдение лицензионных ограничений.
Обычно такие вопросы задают центр компетенций, внутренний евангелист Camunda или архитектор предприятия, ответственный за Camunda.
В недавнем proof-of-concept мы проверили одну простую идею: мы автоматически собирали необходимые данные с разных движков внутри компании. Для этого можно использовать стандартный REST API Camunda и забирать данные через endpoints метрик и версий. Скриншот и исходный код можно найти на GitHub.
Разумеется, нужно централизованно регистрировать адреса этих endpoints. Но это, на самом деле, хороший повод для центра компетенций наладить контакт с пользователями Camunda. В качестве альтернативы данные можно отправлять в сборщик (harvester) — например, с помощью простого плагина для процессного движка.
Используйте облако для упрощения развертывания
Развёртывание и управление гораздо проще при использовании управляемых сервисов. Запуск множества движков становится очень лёгким с Camunda Cloud, так как в ней уже встроена панель управления (control plane). Она показывает всю описанную выше информацию в одном месте. Более того, она позволяет обновлять или патчить движки автоматически или по нажатию кнопки.
Мониторинг сквозных бизнес-процессов
Когда использование Camunda масштабируется, полная картина сквозного бизнес-процесса, как правило, выходит за рамки одного движка процессов. Возможно, процесс разбит между разными микросервисами, использующими разные движки Camunda или сторонние решения. Какие-то шаги могут выполняться устаревшим ПО. В любом случае вам всё равно нужно иметь сквозную видимость процесса.
Попытка загнать всех в один движок Camunda не работает — это ограничивает независимость команд.
Большинство компаний полагаются на BI-системы или хранилища данных для получения общей картины. Это допустимый подход, но, как сообщают клиенты, он сложен в настройке и, как правило, не отражает бизнес-процессную логику. Существующие инструменты для наблюдаемости или распределённого трассирования слишком технические. Поэтому мы добавили мониторинг событий процессов (process events monitoring) в наш инструмент визуализации и отчётности Camunda Optimize.
Действуйте пошагово и избегайте «аналитического паралича», например, если пытаетесь заранее обсудить сквозной мониторинг со всеми заинтересованными сторонами.
Создайте Центр Компетенций (COE)
Если одна команда занимается пилотным проектом, а возможно и флагманским, она не только глубоко освоит технологию и архитектуру, но и получит несколько уроков на практике. Эти уроки чрезвычайно ценны, и важно, чтобы они были использованы в следующих проектах.
Один из вариантов — чтобы эти люди просто продолжили разрабатывать решения в составе команды. Это действительно очень эффективно, но не масштабируется. Также можно разделить команду и отправить специалистов в разные проекты, что, как я видел, хорошо работает, но требует определённой гибкости в распределении ресурсов. Третий вариант — тот, что описан во вводном примере: преобразовать проектную команду в центр компетенций (COE).
COE может быть создан как специализированный COE по Camunda, но чаще это общий COE по автоматизации процессов. В этом случае его задача расширяется: оценка технологий workflow и помощь в выборе подходящего инструмента для конкретной задачи. Обычно такие COE также управляют технологиями роботизации процессов (RPA) или маршрутизации задач на основе навыков.
COE создаёт и поддерживает внутренние лучшие практики. В качестве основы можно использовать Camunda Docs и Camunda Best Practices. Далее стоит задокументировать решения, ограничения или дополнения, актуальные для вашей компании. Например, вы можете захотеть, чтобы проекты всегда использовали отдельный дистрибутив Camunda Run, обрабатывали внешние задачи через REST и добавляли формы в виде HTML-фрагментов. Можно описать, как Camunda легко интегрируется с вашей центральной Active Directory. Также можно указать на несколько внутренних проектов, обеспечивающих интеграцию с RabbitMQ, SOAP Web Services и FTP.
Один клиент (крупный банк) рассказал мне, как за два года они разработали «портал самообслуживания» внутри COE. Этот портал содержит руководства по началу работы, шаблоны Maven-проектов и некоторые переиспользуемые компоненты в виде поддерживаемых библиотек. Такая структура позволяет большинству проектов запускаться самостоятельно, включая проекты, выполняемые крупными офшорными IT-интеграторами. Вначале им пришлось самостоятельно разработать первые шесть решений на workflow, но теперь уже семь дополнительных проектов были выполнены в режиме самообслуживания, что подтверждает правильность выбранного направления.
COE также может развивать сообщество просто за счёт своей доступности для общения. Кроме того, можно добавить форум, Slack-канал или регулярные очные или онлайн-встречи. Выбор подходящего инструмента сильно зависит от культуры вашей компании.
Также стоит инвестировать в внутренний маркетинг, так как важно, чтобы другие проекты знали о COE. Возможно, вы даже захотите публично рассказать о вашем кейсе и выступить в качестве референса для Camunda, ведь я часто слышу, как клиенты ищут информацию о Camunda и находят описание кейса в своей собственной компании. COE также может развивать внутреннее сообщество, просто будучи доступным для общения.
Кроме того, можно завести форум, Slack-канал или организовывать регулярные встречи — очные или онлайн. Выбор формата зависит от культуры вашей компании. Также стоит вложиться во внутренний маркетинг, ведь важно, чтобы другие проекты знали о существовании COE. Возможно, вы даже захотите публично рассказать о своём кейсе и выступать в роли референса для Camunda — я часто слышу, как сотрудники гуглят “Camunda” и находят описание её использования… в своей же компании.
Управление архитектурными решениями
Я уже ясно дал понять, что не сторонник жёсткой стандартизации. Командам проектов нужна определённая свобода в выборе правильных инструментов. Во многих случаях даже лучше, если команда сможет, например, сама решить, нужен ли им вообще движок рабочего процесса. Ваш центр экспертизы (COE) и маяковые проекты могли создать достаточно внутреннего маркетинга, чтобы люди знали о преимуществах такого инструмента, поэтому им нужно дать возможность принять решение.
Но, конечно, рискованно позволять каждой команде выбирать что угодно в данный момент, так как это быстро превращается в следование трендам, моде, личным предпочтениям или просто желанию “попробовать что-то давно интересовавшее”. Важно, чтобы все понимали, что определённые технологические решения — это обязательство на годы, а иногда и десятилетия. Эти решения и связанное с ними сопровождение влияют не только на текущую команду.
Что хорошо работает — это сочетание свободы выбора с ответственностью за эксплуатацию и поддержку решения в продакшене, известное как «ты построил — ты и эксплуатируешь». Этот важный принцип делает команду осознанной в том, что с них спрашивают за принятые решения. Когда это действительно работает, команды принимают более разумные решения и с большей вероятностью выберут «скучные» технологии.
Другой распространённый подход — создание архитектурного совета, который устанавливает некие ограничительные рамки. В идеале он не навязывает произвольные стандарты, а поддерживает список одобренных инструментов и фреймворков. Если команда хочет использовать что-то, чего пока нет в списке, она должна обсудить это с советом. Команда должна представить фреймворк и объяснить, почему им именно этот инструмент нужен. Это может привести к плодотворному обсуждению. Команды могут узнать об альтернативах, которые лучше подходят, или получить вопросы по поддержке, о которых они не думали. Но, конечно, они также могут убедить совет и получить зелёный свет.
Я также видел более жёсткий контроль у заказчиков, особенно по поводу промежуточных технологий, которые легко могут быть использованы неправильно. Например, если команда хочет использовать RPA, им нужно обосновать это решение, потому что это увеличит технический долг.
Управление восприятием: что такое решение на базе Camunda?
Клиенты используют Camunda для самых разных задач. Одна из тенденций — создавать решения, которые по сути являются Java-приложениями с встроенным workflow. Внутри компании такие приложения могут восприниматься как «проекты Camunda», даже если часть с workflow в приложении относительно невелика. Хотя в этом нет ничего плохого, есть определённый риск. Может получиться так, что будут строиться огромные индивидуальные приложения. Это значит, что на их запуск в продакшен может уйти много времени. Или проекты могут стать очень дорогими, а иногда даже отменяться из-за проблем в процессе разработки. Все эти факторы никак не связаны с Camunda, но так как проекты ассоциируются с брендом Camunda, это может повредить восприятию автоматизации workflow как те
мы. Следите за этим риском, хотя нам нравится, что вы говорите о Camunda внутри компании :-)
Хорошая новость в том, что с ростом числа клиентов, которые переходят к использованию Camunda как самостоятельного движка workflow (например, с Camunda Cloud или Camunda Run + External Tasks), этот риск снижается.
Роли и развитие навыков
В первые годы компании я проводил много proof of concept и часто встречал мотивированных и очень умных разработчиков. Как и во многих других софтверных компаниях, в начале мы в основном работали с ранними энтузиастами. А потом однажды у меня был консалтинговый проект для одной из крупнейших телекоммуникационных компаний в мире. Я общался с несколькими разработчиками, которым было абсолютно всё равно на Camunda. Они просто хотели выполнить работу и получить зарплату, а Camunda в проект попала по каким-то корпоративным директивам. И честно говоря, это были хорошие люди, но не особо выдающиеся программисты. И это абсолютно нормально! Мне, как заядлому фанату и «зависимому» от workflow-движков, пришлось осознать, что есть и обычные люди.
Тогда я понял, что нужно различать разные группы разработчиков:
Rockstar-разработчики — это ранние энтузиасты, которые иногда творят чудеса. Они очень мотивированы и увлечены. Просто дайте им руководство по Camunda, и не мешайте — они сами найдут всё в интернете. Такие люди, скорее всего, будут в первых проектах и, возможно, в центре компетенций (COE). Но с ними есть и сложности: им всегда хочется использовать самые новые технологии и иногда они склонны к избыточному усложнению. И будьте осторожны, их легко отвлечь — ой, смотри, белка!
Профессиональные разработчики — это обученные инженеры-программисты. Они продуктивны в своей среде с индивидуальным набором инструментов (язык программирования, IDE, CI/CD и т.д.). Чтобы быть продуктивными с Camunda, им нужно изучить основы BPMN и получить хорошее понимание концепций Camunda и API. В зависимости от архитектуры и стека вы можете предложить им курс Camunda BPM для Java-разработчиков или более полиглотный курс по Camunda BPM и микросервисам. Важно дать профессионалам свободу, необходимую для продуктивной работы.
Low-Code разработчики — это не обученные программисты, часто с бизнес-бэкгрундом. Они пришли в разработку через Microsoft Office, макросы или RPA. Обычно они полностью посвящают себя созданию решений в этих средах. Для многих компаний ключ к масштабированию автоматизации процессов — дать таким «гражданским разработчикам» возможность моделировать исполняемые workflow. Некоторые компании (например, Goldman Sachs) сами инвестируют в поддержку low-code разработчиков для работы с Camunda. В будущем Camunda будет расширять поддержку, например, возможностью пошагового исполнения workflow прямо в моделере, выбором коннекторов из каталога или упрощением создания выражений. Low-code разработчикам часто нужен специализированный курс, адаптированный под их рабочую среду.
Citizen Developers — тоже не программисты, чаще конечные пользователи с некоторой IT-грамотностью, которые хотят решить актуальную проблему с помощью доступных технологий. Их можно подключить к работе с Camunda через платформу для low-code разработчиков, но обычно заказчики больше сосредоточены именно на low-code разработчиках в своих инициативах.
Но, конечно, дело не только в разработчиках:
Бизнес-аналитики должны научиться моделировать BPMN. Хотя они могут использовать разные методы (например, творческие техники) для выявления и обсуждения моделей процессов, они должны уметь создавать BPMN-модель как входные данные для разработки, а также понимать все модели, созданные разработчиками. Мы рекомендуем пройти курс по BPMN 2.0.
Операционные специалисты должны понимать, что нужно для развертывания и поддержки Camunda, а также как устранять неполадки. Для этого у нас есть курс Camunda BPM DevOps.
Корпоративные архитекторы должны понимать роль Camunda в общей архитектуре. Хотя я выступаю против чрезмерного проектирования архитектуры на ранних этапах, важно вовлекать архитекторов в процесс с самого начала, чтобы обеспечить их поддержку. В сложных политических ситуациях лучше дождаться конкретного «маячного» проекта, чтобы показать его архитектурной группе.
Некоторые заказчики отмечают, что у них есть эксперты по методологиям workflow, которые хорошо проверяют, насколько рационально построен тот или иной процесс. Они постоянно пытаются упростить дизайн workflow. Обычно такие специалисты организованы в центре компетенций.
Конечно, роли и обязанности могут варьироваться, и каждый человек «живет» своей ролью по-своему. Поэтому, хотя базовое понимание ролей и необходимых навыков важно для масштабирования внедрения Camunda, нужно помнить, что это лишь ориентиры. Я видел бизнесменов, которые сами программируют умный дом и мыслят как разработчики. Видел разработчиков, которые отлично общаются и могли бы без проблем заниматься бизнес-анализом. Но также видел разработчиков, которые боятся общаться с людьми, и бизнес-подразделения, которые едва умеют включать компьютер.
Важно, что хороший курс обучения будет эффективен только если знания сразу же применяются в реальном проекте. Постарайтесь провести обучение как можно ближе к старту проекта.
Кроме того, стоит организовать коучинг на рабочем месте. Его могут проводить Camunda, партнеры или, вероятно, ваш собственный центр компетенций. Часто дистанционное консультирование хорошо работает для таких задач.
Архитектура процессов и ландшафты
«Прежде чем мы даже сможем выбрать процесс для POC, нам нужно зафиксировать все бизнес-процессы в компании и разместить их на ландшафте процессов. Иначе мы не видим полной картины и не можем правильно расставить приоритеты»!
С таким мышлением мы сталкиваемся слишком часто, и оно опасно. Не только потому, что усилия по фиксации этих процессов быстро выходят из-под контроля и в инициативу вовлекается слишком много людей, но, что важнее, у вас пока нет достаточного опыта в методологии автоматизации процессов и BPMN, чтобы создавать модели нужного качества. Это приводит к процессным моделям, которые в лучшем случае бесполезны, а в худшем — становятся препятствиями.
Иногда компании хотят сохранить прошлые наработки: «Эй, мы уже анализировали этот процесс три года назад в рамках нашей программы качества и соответствия. Модель у нас есть, давайте просто используем её для этого проекта по автоматизации». Ни в коем случае!
Архитектура процессов и ландшафты имеют своё место, но это более высокий уровень взгляда на процессы, и они лишь слабо связаны с исполняемыми BPMN-воркфлоу. Начав работу с Camunda, стоит отделить первые проекты от подобных инициатив, чтобы проект мог развиваться, учиться и принимать собственные решения, не увязая в бесконечных политических или методологических обсуждениях. Как только у вас будет больше нескольких живых проектов и появится опыт с BPMN, можно начать согласовывать разные направления внутри компании.
Я видел, что лучше всего работают бережливые подходы. Например, простая страница в Confluence может служить точкой входа в ландшафт процессов, показывая базовую структуру с ссылками на высокоуровневые описания процессов. Оттуда можно напрямую перейти к исполняемым моделям в системе контроля версий или в Cawemo.
Наличие архитектора процессов, который контролирует эту процессную архитектуру, имеет смысл, когда внедрение масштабируется, но не раньше.
Содействие сотрудничеству
Гораздо важнее блестящей архитектуры процессов — практический подход, который позволяет всем ключевым участникам совместно работать над дизайном воркфлоу. Что касается инструментов, это может быть что угодно — от простых страниц в Confluence с плагином BPMN до специализированных решений на основе Git и bpmn.io для совместного моделирования. Чаще всего я вижу модели на общих файловых системах, открываемые в Camunda Modeler или, конечно, в Cawemo — нашем инструменте для совместного моделирования процессов. Всё это может работать, если у участников есть чёткое понимание, как это должно происходить. В идеале в этом может помочь ваш Центр компетенций (COE).
Старайтесь не внедрять инструменты только потому, что они уже используются в бизнес-подразделениях. Очень часто такие инструменты не поддерживают BPMN или вовсе не подходят для совместной работы с исполняемыми моделями.
Конечно, необходимо создать культуру, которая поддерживает сотрудничество и открытую дискуссию. Никогда не получится просто «перебросить» модели бизнес-аналитиков в ИТ для реализации.
Часть этого — обеспечить всем важным участникам доступ к процессным моделям и соответствующим инструментам. Слишком часто я вижу компании, которые не хотят выдавать лицензии каждому разработчику, что ведёт к срыву процесса. Если стоимость лицензий становится препятствием, рассмотрите лёгкие решения.
Не забывайте про экономику проектов
Важно сосредоточиться на создании бизнес-ценности в проектах по автоматизации процессов. Кроме того, нужны механизмы для приоритизации кандидатов на автоматизацию, которые станут основой для решения, чем заниматься дальше. В этом посте я не буду углубляться в управление портфелем проектов — это довольно сложная тема, и у разных клиентов она организована по-разному. К тому же, это заслуживает отдельного блога, а этот пост и так достаточно длинный. Просто убедитесь, что вы оцениваете потенциал проектов до того, как начать их реализацию.
Отмечу, что для выбора пилотного или опорного проекта не всегда нужны такие строгие правила, так как здесь часто решают технические соображения. Но вскоре после их завершения каждый проект должен быть оправдан цифрами и бизнес-ценностью, а не только техническим энтузиазмом.
Заключение
Этот пост должен дать вам хорошее понимание того, как выглядит успешный путь внедрения. В качестве общего правила следует децентрализовать как можно больше и предпочитать гибкий пошаговый подход, который позволяет учиться в процессе, ведь дьявол всегда кроется в деталях, а каждая ситуация имеет свои уникальные вызовы.
Желаю удачи в вашем пути и успехов с Camunda!
Подписывайтесь на наш телеграм-канал BPM Developers — про бизнес-процессы: новости, гайды, полезная информация и юмор.