Уже не первый год я не перестаю удивляться сценарию внедрения системы управления бизнес-процессами BPMS, разыгрываемому вендорами таких систем. Выглядит это примерно так. После успешной презентации своего решения они собирают команду заинтересованных лиц со стороны заказчика и начинают обучать его рисованию бизнес-процессов в нотации BPMN. Обычно в такую команду входят ИТ-начальники, а также эксперты и руководители функциональных подразделений заказчика. В общем все те люди, которые рисовать процессы скорее всего не будут, ни на бумаге, ни в рисовалках диаграмм, ни в навернутом BPMS инструменте, обещающем реализацию концепции model-driven development. Далее, пару недель эти люди что-то пытаются сделать и потом из тех или иных соображений принимается решение о приобретении или отказе в приобретении рассматриваемой системы. Возможной причиной такого развития событий является отсутствие в организации собственных бизнес-аналитиков (Впрочем, у поставщиков решения их тоже обычно нет, потому как продавец и аналитик – это довольно разные должности. Вряд ли хороший аналитик долго протянет в системе мотивации, выстроенный для sales).
Впервые я наблюдал такую деятельность в исполнении сотрудников «голубого гиганта» еще в те времена, когда эта компания не приобрела Lombardi. Причем, в моей практике это был наиболее успешный вариант. Уважаемые коллеги все нам доходчиво объяснили и рассказали про Process Server, но разумеется не добились того, чтоб кто-то со стороны заказчика начал бы рисовать BPEL сценарии. Немного огорчившись они попросили сделать пилотный проект на какой-нибудь реальной задачи. Затем, за пару недель им удалось набросать какие-то сценарии, а за следующие шесть месяцев даже синтегрировать прототип с интерфейсами унаследованных систем. На самом деле, это вполне неплохой сценарий, т.к. в ходе его поставщики сделали несколько правильных вещей:
Во-первых, выяснили и зафиксировали постановку задачи. Отчасти в этом была и наша заслуга. Аналитики с архитекторами тем и занимаются, что из вороха картинок, текстовых описаний и с энтузиазмом рассказанных бизнес-заказчиком историй делают внятные постановки, включающие список действующих лиц, описание вариантов использования и верхнеуровневую модель предметной области.
Во-вторых, наши коллеги не стали кого попало учить работе в своем замечательном инструменте, заставлять разбираться в витиеватых блок-схемах, средствах мэппинга данных и прочих инструментах. Потому как бизнес-заказчик или ИТ-начальник разобраться во всем этом все равно не сумеет, а нормальному разработчику проще написать код на любимом языке программирования. Вместо этого они быстро разобрались в функциональных ролях участников проекта и рассказали каждому из них соответствующую историю. Архитекторам про SOA, безопасникам про управление доступом, функциональным руководителям про красивые дашборды, отображающие статистику по продукту в режиме близком к онлайн.
В-третьих, они сделали работающий прототип и смогли его показать. В общем, мы им крайне признательны за подтверждение концепции. На основании убедительного пилота мы инициировал в компании внедрение open-source решения для быстрого запуска новых продуктов и услуг на базе Galssfish ESB и запустили на нем потом сотни разнообразных сценариев.
Сейчас эта уважаемая компания занимается проведением двухдневных хакатонов, на которых собирает функциональных заказчиков и амбициозных разработчиков. Утром первого дня заказчики формулируют задачи, а вечером второго получают работающие прототипы. (Я еще не видел в сети отчетов с последнего такого мероприятия и если потому буду признателен если кто-то готов поделиться конкретикой.) На сегодняшний день такая форма работы стала вполне реальной. Нет проблем набросать работающий макет пользовательского интерфейса, реализовать пару процессных сценариев и визуализировать набор показателей. Думаю, в ближайшие пару лет анализ, проектирование и прототипирование сольются в единую активность. В крайнем случае, уточнять постановки, улучшать дизайн и обновлять прототип можно будет короткими недельными итерациями. Заодно появиться время выявлять, формулировать и решать открытые вопросы.
Собственно говоря, из приведенных выше соображений мне и кажется важным и востребованным развитие имитационных решений типа БП Симулятор ссылкой на который я недавно поделился в фейсбуке.
Этот конкретный продукт концентрируется на количественных характеристиках. В сложных системах, реализующих клиентский сервис важнее возможность «проиграть» механику работы решения. Добавлять удалять и модифицировать объекты в коллекциях данных, разыгрывать сложные взаимодействия между акторами, ресурсами и экземплярами процесса, испытывать прототипы на тестовых выборках данных. Но это уже абсолютно не сложная задача. Если у вас есть необходимые сервисы с программными RESTful интерфейсами, вручную собрать все вместе можно уже сейчас. Если у Вас есть PaaS с возможностью поднимать такие микросервисы по запросу, то набросать прототип решения можно за несколько часов. В общем грядущая итерация подходов к проектированию информационных систем будет интересна всем. И тем, кто ни разу в жизни не писал ФТ и ТЗ и тем, кто делал это на протяжении десятков лет и наивно рассчитывает на продолжение. Одним словом:
“Дорогие наши заказчики, ждем вас в недалеком будущем на воркшопах и хакатонах! Айтишников с собой можете даже не брать. Ну разве что, если потребуется интеграция с унаследованными приложениями, то пару человек приводите. Однако, без работающих и доступных в сети RESTful интерфейсов я их на своё мероприятие не пущу ;-)”
Верхняя картинка позаимствована отсюда
Спасибо за внимание к сервису БП Симулятор. Насчет бизнес-анализа у вендоров немного другая ситуация. Емкость рынка ПО для BPM мала, на продажах лицензий и сопровождении не заработать, но хорошо продается консалтинг. Поэтому основной продукт для продажи бизнес-консалтинг и к нему уже пристегиваются готовые решения от вендора.
Спасибо за интересный сервис и замечание относительно консалтинга. И в продолжение темы очевидный вопрос: использует ли уже кто-либо БП Симулятор в консалтинговых проектах? Готовы ли они поделиться опытом, сценариями проведения симуляций и другими материалами?
У меня нет такой информации. Два сценария использования этого сервиса: инструмент для проведения лабораторных работ в образовании и инструмент бизнес-анализа непосредственно на местах с целью формирования оптимальной ресурсной базы процесса.
Но мне приходилось участвовать во внедрениях других вендоров и без пилотных проектов ну никак не удавалось поставить систему.
В свое время мы практиковали автоматизацию простого бизнес-процесса за 1 час прямо перед клиентом.
В реальном времени системный аналитик «закатывал» в BPMS процесс согласования отпуска.
Все просто — форма, структура данных и простейшая логика процесса.
Отрезвление наступало позже, когда Заказчик понимал, сколько сил и затрат нужно вложить в интеграцию BPMS с существующими системами.
В одном из крайних проектов, ИТ-департамент почти год готовился к интеграции, что бы BPMS встала «легко» и быстро — за несколько месяцев на основном бизнес-процессе.
Интеграция — вредная метафора, подразумевающая совместный труд двух команд по копанию туннеля с одной стороны и строительству моста с другой — в надежде, что однажды они встретятся ) Кстати, я думаю что проблема на стороне BPMS. Вместо синхронных вызовов чужих API надо было предоставлять свои. И пусть потом заказчик интегрируется в них хоть всю жизнь. Но чрезмерное увлечение SOA не позволило архитекторам BPMS в свое время сделать правильный выбор
«Вряд ли хороший аналитик долго протянет в системе мотивации, выстроенный для sales»
Не протянет. Более того — не пойдет в такую компанию. Потому что зачем терять квалификацию, когда существует настоящая работа, в больших интересных проектах?