Современная концепция BPM сформировалась в 2003‒2004 гг. как органичное сочетание процессной методологии (связь со стратегией, ценность для клиента, кросс-функциональность), технологий (графическое моделирование, исполнение движком, мониторинг и аналитика) и подхода к реализации (непрерывное усовершенствование, аджайл, тесное взаимодействие бизнеса и ИТ). Идеи витали в воздухе — было ясно, что реинжиниринг не вполне оправдал возлагавшиеся на него надежды, и концепция была поддержана практически единодушно как консультантами по управлению, так и ИТ-компаниями.
В результате сформировался класс программного обеспечения BPMS — эта аббревиатура изначально расшифровывалась как Business Process Management System, затем, с легкой руки Gartner, System превратилась в Suite. На рынке BPMS представлены как «гранды» (IBM, Oracle, SAP, Software AG), так и десятки компаний ‒ узких специалистов (pure-play vendors). Появление программных продуктов Open Source стало свидетельством зрелости рынка.
На фоне общей поддержки концепции BPM аналитики обещали двузначные цифры роста рынка. Если суммировать их предсказания за прошедшие годы, то рынок BPM должен был бы быть в стратосфере, но в реальности мы этого не наблюдаем. В соответствии с моделью жизненного цикла инноваций Джеффри Мура, BPM забуксовал на переходе от завоевания поддержки компаний-энтузиастов к получению признания большинства.
Рынок BPM систематически отставал от прогнозов, а предложения вендоров превышало спрос. С этим надо было что-то делать — такое положение дел не могло устроить ни вендоров, вложившихся в разработку, ни аналитические агентства, чьи прогнозы оказались под вопросом.
Может быть, ошибочной была сама концепция BPM? Для сравнения: за 10 лет увлечения реинжинирингом было накоплено достаточно опыта применения, чтобы выявить и сильные, и слабые его стороны. BPM же практикуется уже почти 15 лет, но каких-то существенных изъянов в нем не обнаружилось и новой процессной парадигмы за это время не предложено.
Если только не считать таковой концепцию кейс-менеджмента (ACM, Adaptive Case Management).
Процессы для клерков и для креативных сотрудников: ACM
Приверженцы этой концепции заявили, что на смену клеркам, выполняющим механическую работу по утвержденным регламентам, в современном мире пришли креативные работники умственного труда (knowledge workers), которым нужны не традиционные жестко определенные процессы, а более гибкие и динамичные формы работы — кейсы.
Ничего особенно нового в кейсах нет: когда в организацию приходит письмо и начальник «расписывает» его замам, а те, в свою очередь, ставят задачи подчиненным — это и есть кейс, т. е. просто «дело» на русском канцелярском. Или когда пользователь пишет заявку в техподдержку вида «не печатается отчет» — это ведь может означать что угодно, от закончившегося картриджа в принтере до планового обновления SAP. На верхнем уровне можно представить работу над заявкой в виде процесса — ввести первую и вторую линию техподдержки, определить нормативные сроки и SLA — но сами действия по устранению проблемы будут планироваться на ходу. Про кейс говорят, что он «развертывается во времени» — вы не можете заранее определить все, с чем столкнетесь, поэтому планируете только первый шаг, а по его результатам смотрите, что делать дальше.
В чем-то сторонники ACM были правы: на тот момент все больше производств и стандартных услуг выводилось на аутсорсинг в страны с дешевой рабочей силой, а в Штатах оставались управление, разработка, маркетинг и продвижение, т. е. в основном творческая работа. Поэтому при взгляде из США могло сложиться впечатление, что традиционные процессы уже неактуальны. Но если взглянуть шире, становится понятно, что рутинная работа переместилась географически, но не исчезла.
В реальной жизни есть место работе и по шаблону, и творческой, они комбинируются и сочетаются друг с другом. В конечном счете и процессы, и кейсы порождают задачи, управляемые одинаково: у каждой задачи есть исполнитель, контрольный срок, контекст в виде данных и документов. Различается только способ появления задач: в одном случае они порождаются автоматически согласно схеме процесса, в другом исполнитель сам решает, что делать дальше и кому надо делегировать подзадачи.
В условиях, когда между традиционными потоками работ и кейсами нет непроницаемого барьера, отдельные средства для управления только кейсами оказались невостребованными. В итоге производители BPMS включили поддержку кейсов в свои продукты, и бизнес-процесс стал трактоваться расширительно — это и работа, выполняемая по шаблону, и планируемая «на лету». Отдельная ниша для систем ACM не сложилась.
В поисках правильного лейбла: iBPMS & Low-code
Если товар под старым лейблом продается плохо, а нового нет — надо обновить лейбл. В начале
Вендоры, бывшие в числе «любимчиков» Gartner, с энтузиазмом поддержали это движение (кто сказал «сговор»?!), но надо признать, что такого единодушного признания, как исходная концепция BPMS, новинка не получила, и рейтинги iBPMS выпускает только Gartner. Хотя по факту все те BPM-вендоры, которые продолжали активно развивать свои продукты, добавили в них и мобильность, и «облака», и поддержку социального взаимодействия, и функциональность кейс-менеджмента.
Через несколько лет компания Forrester, вечный конкурент Gartner, предложила новый лейбл: Low-code, или системы с минимальным кодированием.
Ключевых идей в этой концепции можно выделить две: во-первых, центр тяжести усилий по разработке процессных бизнес-приложений переносится с программистов на аналитиков. Действительно, BPMS-системы, ориентированные на программистов, плохо соответствуют методологии BPM и из-за этого демонстрируют ограниченный успех. С точки зрения бизнеса это выглядит как всего лишь еще одна ИТ-система: раньше процессы кодировали в АБС или ERP, теперь в BPMS — что изменилось-то? (Тем более что АБС и ERP никуда не делись.) Чтобы BPM дал эффект, должен измениться стиль взаимодействия между бизнесом и ИТ, старая модель «бизнес пишет ТЗ и перебрасывает его через стену в ИТ-отдел» должна смениться аджайлом с его быстрыми итерациями и тесной вовлеченностью бизнеса в проектирование бизнес-процессов.
Чтобы этого добиться, нужно минимизировать объем кодирования, максимально использовав программирование от графических моделей и сделав среду разработки максимально дружественной по отношению к «гражданским» разработчикам. Другими словами, это должен быть не Eclipse, java и XML, а разработка от диаграммы BPMN, простой и удобный редактор форм, и желательно, чтобы все это было реализовано в браузере.
Во-вторых, системы Low-code не зациклены на процессах, ведь при всей важности процессной логики, корпоративные приложения состоят не только из нее. Сложилась странная ситуация: в любой системе BPMS есть средства проектирования базы данных и редакторы экранных форм, но воспользоваться ими, чтобы разработать традиционное приложение для ведения банального учета, например, нельзя — вы должны все делать через бизнес-процессы. Это нелогично, и в системах Low-code это ограничение снято.
При этом использование реляционных баз данных здесь нецелесообразно, ведь скорость внесения изменений — не самая их сильная сторона. Например, в графовой базе добавить атрибут можно мгновенно, без реконфигурирования. Также графовая база умеет отвечать на запросы вида «покажи все процессы и задачи, связанные с данным бизнес-объектом — машиной, клиентом, товаром...».
Еще одна особенность систем Low-code, отличающая их и от традиционных корпоративных систем, и от BPMS: в качестве пользователя здесь рассматриваются не только внутренние (сотрудники компании), но и внешние (клиенты, поставщики, партнеры). Это радикально меняет требования к визуальной привлекательности и эргономике пользовательского интерфейса.
Идея минимального кодирования не нова — SQL в свое время создавался под этим же флагом: иметь возможность обращаться к БД без программирования, на языке, максимально близком к естественному человеческому. Также можно вспомнить аббревиатуру RAD — Rapid Application Development. Так что системы Low-code продолжают давнюю традицию.
Идея Low-code оказалась удачной — ее хорошо восприняли и заказчики, и вендоры. Кое-кто пошел дальше, заявив о Zero-code или No-code, но это больше похоже на маркетинговый шум, чем на работающую технологию.
Если говорить об отечественной практике, то тема Low-code в России сейчас на подъеме. В качестве примера можно привести Comindware Business Application Platform — настоящая Low-code-платформа для управления бизнес-процессами и цифровой трансформации предприятия. В основе Comindware Business Application Platform — графовая база данных для гибкого управления бизнес-процессами (BPMS), кейсами (ACM), работы с данными и документами, социального взаимодействия.
BPM и цифровая трансформация
Концепция BPM- и BPM-систем, предложенная без малого 15 лет назад, выдержала проверку временем. Но проблема тех, кто ее предложил и развивал тогда, в том, что они «бежали впереди паровоза» — пусть концепция у вас правильная, но большого спроса на нее не будет, пока есть более простые способы повышения эффективности бизнеса, начиная с банального сокращения персонала и наведения порядка в управленческом учете.
Только в последние два года ситуация для энтузиастов BPM стала меняться в лучшую сторону. Связано это с повсеместным острым интересом бизнеса к цифровой трансформации. Происходит что-то невообразимое: мы привыкли к тому, что ИТ-отрасль предлагает бизнесу свои игрушки, а он от них большей частью отмахивается, а сейчас требования бизнеса к ИТ зачастую опережают предложение.
Человек, однажды воспользовавшийся услугами Яндекс-такси или сервисом Google docs, уже не будет прежним. И когда он приходит к себе на работу, у него возникают вопросы: «Какого черта?! Почему в туалете почти неделю течет кран, а моя бумажная заявка ходит неизвестно где? Почему я не могу сфотографировать на смартфон, отправить заявку одной кнопкой так же, как я одной кнопкой вызываю такси, и на смартфон же получить отчет о том, что кран починен или заменен?» (Кстати, это реальный кейс.)
Или логистическая компания объявляет программу цифровой трансформации, заявив в качестве цели: наш клиент — это человек со смартфоном. В идеале мы должны сделать так, чтобы он мог воспользоваться нашим сервисом, не отрываясь от дивана. (Сейчас у компании в офисе — ряды окошек, в которые экспедиторы должны подавать бумажные документы.)
Цифровые клиенты, цифровые услуги — все начинают думать, а многие — уже и действовать в этом направлении. А вторым шагом приходит понимание, что необходимое условие — цифровые бизнес-процессы: пусть вы построили цифровой «фасад» вашего бизнеса, но если в итоге все попадает в бэк-офис, где люди работают по старинке в соответствии с письменными регламентами, то ничего не будет. И естественным образом возникает интерес к цифровым бизнес-процессам, т. е. ко всем тем наработкам, которые BPM предложил еще 15 лет назад и с тех пор последовательно развивал.
Таким образом, сегодня можно говорить о «втором пришествии» BPM — второй волне интереса к процессной методологии и информационным технологиям, поддерживаемым стремлением современного бизнеса к цифровизации своих операций.
Для специалистов по BPM это означает две новости. Первая— хорошая: много новых процессов! Новые исполнители — софтверные боты, роботы-ассистенты, роботизированная техника... Новые модели предоставления услуг, с максимальным переносом в онлайн.
Вторая новость — очень хорошая: это надолго! Речь ведь не идет о том, чтобы заменить старые «аналоговые» бизнес-процессы на новые «цифровые» и на этом успокоиться — прогресс в области цифровизации ускоряется! Вчера это были приложения на смартфонах и «облака», сегодня — элементы искусственного интеллекта, чат-боты, интернет вещей, завтра — беспилотный транспорт и самые разнообразные роботы. Все это потребует массовой и быстрой перестройки бизнес-процессов, а значит, спрос на компетенции и информационные технологии BPM будет продолжать расти.
15 февраля 2018 г. я выступил на конференции CNews «BPM 2018: Как помочь бизнесу измениться» и рассказал, что означает тренд цифровой трансформации с точки зрения BPM, пришествии Low-code платформ и о критериях, определяющих платформу как настоящий Low-code. Видеозапись моего доклада доступна к просмотру на блоге Comindware.
СПЕЦПРОЕКТ КОМПАНИИ COMINDWARE
