Современная концепция 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

Если товар под старым лейблом продается плохо, а нового нет — надо обновить лейбл. В начале 2010-х Джим Сайнур из Gartner предложил новую аббревиатуру: Intelligent BPMS. По сути, речь шла о том, что современные BPMS обязаны были соответствовать общим ИТ-трендам, наметившимся к этому моменту: SMAC — Social, Mobile, Analytics, Cloud, т. е. поддержка социального взаимодействия, доступ с мобильного устройства, «облака», «продвинутая аналитика» (с последней ясности было меньше).

Вендоры, бывшие в числе «любимчиков» 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, но это больше похоже на маркетинговый шум, чем на работающую технологию.

BPM и цифровая трансформация

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

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

Человек, однажды воспользовавшийся услугами Яндекс-такси или сервисом Google docs, уже не будет прежним. И когда он приходит к себе на работу, у него возникают вопросы: «Какого черта?! Почему в туалете почти неделю течет кран, а моя бумажная заявка ходит неизвестно где? Почему я не могу сфотографировать на смартфон, отправить заявку одной кнопкой так же, как я одной кнопкой вызываю такси, и на смартфон же получить отчет о том, что кран починен или заменен?» (Кстати, это реальный кейс.)

Или логистическая компания объявляет программу цифровой трансформации, заявив в качестве цели: наш клиент — это человек со смартфоном. В идеале мы должны сделать так, чтобы он мог воспользоваться нашим сервисом, не отрываясь от дивана. (Сейчас у компании в офисе — ряды окошек, в которые экспедиторы должны подавать бумажные документы.)

Цифровые клиенты, цифровые услуги — все начинают думать, а многие — уже и действовать в этом направлении. А вторым шагом приходит понимание, что необходимое условие — цифровые бизнес-процессы: пусть вы построили цифровой «фасад» вашего бизнеса, но если в итоге все попадает в бэк-офис, где люди работают по старинке в соответствии с письменными регламентами, то ничего не будет. И естественным образом возникает интерес к цифровым бизнес-процессам, т. е. ко всем тем наработкам, которые BPM предложил еще 15 лет назад и с тех пор последовательно развивал.

Таким образом, сегодня можно говорить о «втором пришествии» BPM — второй волне интереса к процессной методологии и информационным технологиям, поддерживаемым стремлением современного бизнеса к цифровизации своих операций.

Для специалистов по BPM это означает две новости. Первая— хорошая: много новых процессов! Новые исполнители — софтверные боты, роботы-ассистенты, роботизированная техника… Новые модели предоставления услуг, с максимальным переносом в онлайн.

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

Текст ниже - перевод отличной статьи из блога Скотта Фрэнсиса.

 
Нам в BP3 множество раз приходилось идти спасать проекты BPM, которые до этого не удалось запустить большим консалтинговым компаниям широкого профиля. Я решил, что будет полезно объяснить, почему подобные провалы происходят и как нам удается избежать подобных ловушек. Для начала, что мы обычно наблюдаем в таких проектах.

1. Невероятно детальные спецификации софта, игнорирующие собственные возможности используемой платформы.
2. В контракте поименно закреплены ресурсы (исполнители).
3. Контракт охватывает все или большинство спецификаций, связывает поставщика конкретным описанием реализации и устраняет любые сомнения о желаемом продукте.
4. Контракт очень жесткий, с требовательными спецификациями, штрафами за низкую производительность и очень низкими средними ставками исполнителей, участвующих в проекте.

» читать дальше

Мой дед Иван Феофанович Орленко был военным летчиком-торпедоносцем. Воевал на Балтике в 1944-1945, закончил войну командиром полка. (Пользуясь случаем, рекомендую тем, кто интересуется военной историей, сайт моего брата Олега Белайчука.)

На фотографии дед в центре с орденом Ушакова и двумя Красного знамени. А на борту машины можно разглядеть маркировку - это американский Бостон A-20G, поставлявшийся в СССР по ленд-лизу.

Среди множества историй, которые дед рассказывал (а он и книгу написал), запомнилась история про технику для военного и для мирного времени. Перескажу своими словами, как запомнил:

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

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

Почему все счастливые семьи счастливы одинаково, а несчастные несчастливы по-своему. Что такое канонiчный BPM, а что - BPM-ересь.

Мой доклад на BPM-конференции AHConferences. Впервые - вместе с полной аудиозаписью выступления:

(Продолжение. Начало тут.)

Конечно хорошо, когда данные структурированы и лежат в БД в нормализованном виде: можно удобно и быстро извлекать, группировать, сравнивать. Чтобы делать это еще быстрее, поверх СУБД накрутили OLAP и гиперкубы, а чтобы не потеряться в лабиринте баз данных, которые создает под себя каждая прикладная система, придумали MDM.

Но не все и не всегда возможно структурировать, и в 90-е случилось еще одно просветление: есть данные, а есть контент - вордовые документы, экселевые таблички, сканы факсов, писем и заявлений. До определенного момента никто теорией не заморачивался - ну файлы и файлы. На заре цивилизации ПиСи обменивались файлами через “флопинет”, потом юзеры познакомились с сетевыми дисками и “электронкой” и продемонстрировали, что нет такого диска и такого канала, который нельзя забить многомегабайтными пдф-ами и сканами. У сисадминов появился термин “файлопомойка” (грубый народ, что возьмешь), ИТ-директора стали употреблять красивый термин “корпоративный архив”.

Так или иначе, что с помойкой, что с архивом, но что-то делать было надо. Просто объявить файлы корпоративным контентом недостаточно. Для начала, надо его хранить централизованно, а не как обычно - куча версий одного и того же документа на локальных дисках и в почтовых ящиках юзеров, у каждого со своими правками, которые не понятно как сливать друг с другом. Надо обеспечить аккуратное разграничение доступа и версионность - не в последнюю очередь для защиты юзера от него же самого, чтоб не потер невзначай. Надо уметь искать по тексту и по ключевым словам. Ну и доступ надо обеспечить, в идеале, откуда угодно - и из веб-портала, и из проводника Windows, и из iPad.

Напрашивается идея выделить отдельный класс софта с перечисленным функционалом для обслуживания сущности под названием контент. Почему отдельный? Да потому что чем бы вы не занимались - регистрировали заказ в ERP, или выполняли задание в BPMS, или управляли проектом с помощью MS Project - вам везде потребуется контент и стандартный функционал для работы с ним. Ситуация в точности та же, что и с DBMS, и с BPMS: чем прикручивать этот функционал то там, то здесь, лучше один раз взяться и сделать как следует.

Итак, нам нужна инфраструктура уже как минимум из трех компонент: DBMS для структурированных данных, ECM для неструктурированного контента, BPMS для процессов. Но вот какая штука: не в интересах производителей софта замыкаться в своих рамках - все эти системы свою прямую работу, понятно, выполняют лучше всех, но при этом могут работать еще и за соседа. “Изя, чтобы ты делал, если бы стал королем? - Я бы жил лучше, чем король! - ? - Потому что я бы еще немножко шил.”

В результате в СУБД можно “немножко” реализовать и процессы (через смену состояний объекта и/или возможные переходы), и хранение контента (через binary поля); BPMS норовят похранить в себе, как в черном ящике, и данные, и контент; ECM претендует и на хранение вообще всего, а не только неструктурированного контента, и на то, что в нем можно автоматизировать процессы. Все подобные проявления, конечно же, следует категорически осудить.

И в частности, реализацию процессов в ECM, которую у нас называют документооборотом. (Есть еще слово workflow, но оно ругательное иностранное и поэтому широкими массами трудящихся заказчиков не воспринимается.) Документооборот в разумных пределах - вещь вполне осмысленная: в конце концов, в уважающей себя организации должны как-то учитываться официальные входящие и исходящие.

Беда в том, что особо ретивые автоматизаторы на этом не останавливаются. Хотите автоматизировать прием на работу - не вопрос, это ведь, в их трактовке, движение документа “заявление о приеме на работу”. Закупки? Тем более понятно, это ничто иное, как документ “Заявка на приобретение”. Какие еще структуры данных, какие схемы процессов? Все можно сделать с помощью вордового документа, его состояний и списка согласующих.

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

Не меньший бред - взгляд на процесс от документа. Типа есть бумажка - есть процесс, нет бумажки - нет процесса. Из непридуманного: “Мы хотим, чтобы система контролировала, что в пакете документов, который мы отправляем в министерство, запрашивая разрешение, присутствовали все необходимые документы. А если какого документа нет, пусть система нас предупредит.” Какие документы, о чем предупредить?! О работе надо думать, причем думать надо было полгода назад, чтобы успеть провести исследование для этого документа! А документ - это всего лишь красиво оформленные данные, которые мы предварительно собрали. Или (второй вариант) отсканированная бумага с подписью. И все!

В общем, концепция документооборота это вот что:

1. Была организация, работавшая по старинке и управлявшаяся с помощью бумажек: приказов, распоряжений, служебок.
2. Пришли автоматизаторы, продали организации персоналки и MS Office, сотрудники стали бумажки делать с помощью текстовых редакторов и принтеров. В результате документов стало на порядок больше - раньше машбюро хоть как-то ограничивало этот поток, а с вордом и лазерным принтером можно столько бумажек наплодить - ого-го!
3. Чтобы справиться с этим потопом, автоматизаторы предложили бумажки хранить в компьютерах, в компьютерах же пересылать с одного рабочего места на другое и с помощью тех же компьютеров делать в них пометки, накладывать резолюции и т.п.

Вот за это я и не люблю термин “автоматизация” - за ним зачастую скрывается стремление продолжать делать ровно то же самое, что делали раньше, только с помощью компьютера. Получается консервация отсталости.

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

Резюмирую: ECM так же плохо подходит для управления бизнес-процессами, как BPMS - для хранения контента. Документооборот, как прикладное решение, разработанное поверх ECM-системы, имеет смысл в ограниченной области канцелярской деятельности, но эту канцелярскую работу надо по возможности сокращать, как не добавляющую ценность, а не распространять на всю деятельность компании.

Когда-то очень давно, на другой планете, когда компьютеры ЭВМ были размером с двустворчатый шкаф, а программы набивали на перфокарты с помощью “лягушек”, никакого программного обеспечения не было, а была “математика”.

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

ОК, сказано-сделано. Лет через 10 - к середине 80-х - появились коммерческие СУБД, в которых, в принципе, было все нужное для жизни. Появление 1) СУБД и 2) стандартного SQL стало мощным толчком для разработки бизнес-приложений - прошло еще лет пять, и буйным цветом расцвели ERP, чуть позже - CRM, PLM и прочие.

Правда нельзя сказать чтобы СУБД так уж гладко вошли в жизнь программистов. Сегодняшняя молодежь уже не представляет, что данными можно управляться как-то по-другому, а в свое время было достаточно много критиков, заявлявших “вот еще, придумали какие-то СУБД на нашу голову. Да я на ISAM-файлах сделаю алгоритм, который уделает вашу СУБД.”

Но победила точка зрения, что структурирование данных подчиняется своим законам и в общем-то не зависит от алгоритмов обработки. Грамотно спроектированная БД позволяет реализовывать хоть такие алгоритмы, хоть эдакие - в отличие от “программ, работающих на ISAM-файлах”. Кое-кто и посей день тащится от этой идеи. И вправду изящной, и что важнее - правильной, но не окончательной.

Сначала некоторое уточнение внесло ООП, в котором на вопрос “что важнее - члены или методы класса” ответ однозначный: методы. Данные могут быть структурированы любым способом, главное - поведение объекта. Это отличается от подхода к разработке корпоративных систем, в котором алгоритмы пляшут от данных, и который, если разобраться, восходит еще к мейнфреймам и коболу. В результате получили: с одной стороны - СУБД с приматом данных, с другой - ОО-алгоритмы с приматом поведения. Пришлось создавать науку под названием Object-Relational Mapping, чтобы технологично связать одно с другим.

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

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

Второй аспект - необходимость плотной совместной работы над процессом и бизнеса, и ИТ. Методология разработки, которая худо-бедно справляется с автоматизацией учета - ТЗ, проектирование, кодирование,… короче, старый добрый водопад - тут однозначно не справляется.

Как только созрело это понимание, появился отдельный класс софта для управления процессов, включающего примерно тот же набор средств, что и для управления данными: графическое моделирование, исполнение, мониторинг и анализ. Так возникли BPMS. Как раньше с SQL, появление стандартной процессной нотации BPMN сильно поспособствовало распространению технологий и идей BPM. История, таким образом, повторилась.

Примерно в это же время наметился кризис в разработке приложений: давнее соперничество между концепциями “best of breed” и “single vendor” закончилось победой первой за неявкой противника. Ведь сегодня single vendor-ов уже фактически нет, а то, что преподносится в качестве таковых софтверными мега-вендорами, является слабосвязными наборами программных продуктов, собранными в результате слияний и поглощений.

Чтобы сделать из этого набора настоящий single vendor программный продукт, надо переписать, во-первых, каждый новый поглощаемый кусок, чтобы он органично встраивался в нашу мега-систему. И что еще хуже, придется что-то пере/до-писать и в той части, куда мы встраиваемся. Ясно, что с ростом масштаба мега-системы переваривание каждого нового кусочка требует все больших затрат - грубо говоря, они растут по квадрату от размеров системы. Так никаких ресурсов не хватит - даже у самого мощного вендора. Что мы собственно и наблюдаем.

Выход из этого тупика бесконечного переписывания был предложен в виде SOA. Понятно, что от архитектурной идеи до удачной реализации путь неблизкий, но альтернативы вроде как нет. Ну не считать же альтернативой очередное предложение “все переписать, но на этот раз правильно”. Это мальчишество в чистом виде - можно все переписать, но когда через n месяцев эта титаническая работа будет выполнено, какое предложение тут же возникнет? Правильно - “все переписать”.

Идеи BPMS и SOA естественным образом дополняют друг друга: реализация SOA превращает ERP и другие корпоративные системы в контейнеры функций, доступных извне, например, через WS API, а BPMS является естественным потребителем этих функций, использующим их для построения бизнес-процессов.

Но эта идея не пришлась по вкусу производителям корпоративных систем - ведь она грозит упростить их продукты и превратить в товар массового потребления с соответствующим увеличением конкуренции и падением маржи. “Открытость к интеграции” в их интерпретации - вещь весьма оригинальная: “Из нашей системы можно вызвать все что угодно. - А как вызвать извне вашу систему? - А зачем это вам?!”. Молодцы, чо! Представили себе зоопарк систем, каждая из которых готова вызывать функцию соседа, но не дает вызвать свою… душераздирающее зрелище.

Но впрямую отрицать идею инструментального управления бизнес-процессами все же чревато - заказчики не поймут - и производители ERP и CRM стали встраивать процессные движки в свои системы. Можно из них извлечь пользу? Безусловно. Способны ли они заменить специализированные BPMS? Сомнительно. Вспоминаются 90-е годы, когда в России были буквально сотни бухгалтерских программ. Многие из них работали на собственных самопальных СУБД, и это преподносилось как достоинство: “купив нашу программу, вы сможете не только автоматизировать бухгалтерию, но сами разрабатывать базы данных для любых задач”. Ну и где сейчас эти самопальные СУБД?

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

Из-за этого шансов успешно конкурировать с независимыми разработчиками BPMS у разработчиков прикладных систем нет, в долгосрочной перспективе. Прогресс в этой области не останавливается: надо обеспечивать поддержку стандартов (BPMN, WS, REST), надо реализовывать модную функциональность (мобильность, социальность, облака), надо или реализовывать самим, либо обеспечивать бесшовную интеграцию с дополнительными сервисами (BRMS, CEP, BAM)… надо или участвовать в гонке, или сходить с дистанции. SAP тянул собственную СУБД много лет, но в итоге с дистанции сошел.

В общем, история продолжается. Оставайтесь на связи, будет интересно.

Gartner, Pega и IBM начинают форсить новые аббревиатуры:

• IBO = Intelligent Business Operations
• iBPMS = Intelligent Business Process Management Suite

Судя по отзывам экспертов, особой концептуальной новизны не наблюдается - скорее идет эволюционный процесс интеграции смежных технологий: BPMS, BAM, BRE, CEP, ACM… Похоже кое-кто решил, что настало время переклеивать новые лейблы поверх старых BPM/BPMS.

Посмотрим что из этого получится - я лично не уверен, что рынок примет эту маркетинговую игру. Попытки заявить о создании “post-BPM” решения предпринимались  (Intalio) и предпринимаются (Metasonic), но без особого успеха. Правда в этот раз за дело взялись тяжеловесы.

Хотелось бы видеть прорывы в технологии и методологии, а не в акронимах. С этой точки зрения мне более интересна инициатива bpmNEXT. Цитирую меморандум Брюса Силвера и Натаниеля Палмера:

Мы оба не согласны с тем, что BPM мертв… или что BPM устал. На самом деле инновации, связанные с облаками, событийной аналитикой, кейс-менеджментом, мобильными приложения и социальными сетями питают инновации в области BPM с интенсивностью, которой мы не наблюдали годами.

Для сравнения, 10 лет назад в процессном управлении произошел достаточно радикальный пересмотр и методологии, и технологии:

• непрерывное усовершенствование вместо однократного реинжиниринга
• интегрированные BPM Suite вместо разрозненных средств моделирования и workflow-движков
• Agile разработка вместо “водопада”

Сейчас же речь идет не о “вместо”, а о “в дополнение”, так что разговоры о “смерти BPM” - это либо спекуляция, либо провокация.

И очень хорошо - хватит уже начинать с чистого листа: TQM, реинжиниринг, BPM… Это разрушает рынок, так как порождает у потенциальных заказчиков чувство неуверенности. Какой смысл браться за реализацию нового акронима, когда предыдущий, с которым те же самые консультанты носились последние годы, так легко сдали в утиль?

Когда же мы говорим о пост-BPM как о расширении, это заставляет тех заказчиков, которые все еще “сидят на берегу”, осознать, что “базовый уровень” BPM - это уже вопрос уже не завтрашнего, а вчерашнего дня. При том, что и завтрашний день обещает много интересного и полезного.

16.05.12 сообщество BPMS.ru при поддержке МЭСИ провело очередной мастер-класс из серии “BPMS в действии”: методологию S-BPM и систему Metasonic представляла компания “Логика бизнеса 2.0″. Запись мастер-класса выложена на youtube.

Илья Машков с коллегами провели мастер-класс на высоком уровне, и собравшиеся наконец-то смогли поближе познакомиться с концепцией и системой, о которых до сих пор информация была в основном рекламного, а не технического характера. Выкладываю свое выступление в ходе дискуссии на прошедшем мастер-классе в “причесанном” виде.

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

» читать дальше

Сообщество BPMS.ru регулярно проводит семинары, на которых обсуждаются различные аспекты BPM и BPMS. Главное достоинство этих мероприятий - атмосфера серьезного профессионального разговора.

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

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

Предпочтительный формат мастер-класса - живая демонстрация создания проекта “с нуля”. Что не удастся показать вживую - про то рассказать словами. Время на доклад - 1 час.

Подчеркну, что речь пойдет о технике, а методологические аспекты останутся за рамками. Не потому что они менее важны - как раз наоборот - просто их, а также проектные аспекты BPM мы многократно рассматривали на семинарах BPMS.ru (и будем рассматривать в дальнейшем). В результате получился некоторый дисбаланс: участники семинаров высказываются в том духе, что полезно углубленно рассмотреть инструментарий.

Первый мастер-класс пройдет в среду 14 декабря, начало в 19 часов, регистрация на bpms.ru. Обсуждать можно там же, а также на linkedin и facebook.

Желающих выступить с докладом и презентовать любимую систему BPMS у организаторов достаточно. На первом мастер-классе собиралась выступить компания Элевайз с системой Элма, но в последний момент они отказались, чем подвели организаторов и 100+ зарегистрировавшихся на мероприятие.

Вместо Элевайза 14 декабря выступлю я с демонстрацией системы BizAgi BPM Suite. Приходите, будет интересно. Я подобные демонстрации регулярно провожу для потенциальных заказчиков - равнодушных не бывает.

В планах - демонстрация Oracle, отечественной Runa, IBM (ex-Lombardi) и других систем. Оставайтесь на связи.

Спонсор одного из наших BPM-проектов как-то сказал в самом начале, когда мы только обсуждали возможный проект: “моим сотрудникам не нужно чтобы их контролировали, им нужно чтобы им помогали”. В тот момент я заспорил, но потом понял - он прав!

В самом деле: что мы имеем в виду, когда говорим о контроле за бизнес-процессами? И надо ли считать параноиками участников процесса, когда они подозревают, что на самом деле цель всей этой затеи - контролировать их самих?

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

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

Это сложные задачи. Реально сложные.

И тут появляется специалист по бизнес-процессам, который, не разбираясь ни в чем конкретно, берется улучшить что угодно. Но если все на что он способен - это нарисовать примитивный workflow, то толку не будет.

Пример:

• Небольшая торговая компания, специализирующаяся на товарах «с изюминкой» - гаджетах, прикольных подарках, дизайнерских аксессуарах для ванн и т.п.
• Группа процессов под названием «Управление ассортиментом»: несколько сотрудников постоянно мониторят интернет, ходят на выставки, заглядывают в магазины конкурентов - ищут новые идеи, бренды, новых поставщиков. С одной стороны, в силу специализации компании ассортимент должен постоянно пополняется модными штучками, а с другой - ассортимент не может быть слишком большим, его надо постоянно прореживать.
• Эти несколько человек ежемесячно оценивают до тысячи кандидатов на включение в ассортимент. Компания выработала трехступенчатое сито отбора: сначала экспертная экспресс-оценка, бракующая большинство идей. Затем переговоры с поставщиком, проработка логистики и оценка возможной прибыльности. Затем - раз в месяц - ранжирование идей, прошедших первую и вторую квалификацию, и отбор кандидатов на пробную закупку и реализацию с учетом имеющегося на данный момент бюджета на расширение ассортимента.
• Параллельно, также примерно раз в месяц, весь текущий ассортимент анализируется с точки зрения фактической продаваемости, разнообразия и т.д.

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

Что тут можно сделать, если идти по пути наименьшего сопротивления? Ну например, можно автоматизировать оценку кандидатов на включение в ассортимент - сделать процесс из пяти последовательных шагов:

1. узнать цены у поставщика
2. узнать условия поставки
3. оценить продаваемость
4. назначить рейтинг
5. принять решение о пробной закупке

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

Во вторых, какой в смысл в такой схеме, если все шаги выполняет один человек? Это ведь махровый микроменеджмент. Что, разве проблема тут в том, чтобы проконтролировать последовательность задач? Ясно ведь, что не в этом, а в том, чтобы уследить за сворой одновременно и асинхронно протекающих процессов: сотнями процессов, проходящими первый этап квалификации, десятками - второй, процессами отбора в и отсева из ассортиментами. А для этого нужно реализовать не workflow, а достаточно сложное межпроцессное взаимодействие.

Люди хотят не чтобы их контролировали под видом процессов, а чтобы им помогли контролировать действительно сложные процессы.

Если вы им это дадите - противодействия не будет, люди с благодарностью будут пользоваться BPM-системой. Проверено на практике.

Но по пути вам придется преодолеть их недоверие - изначально внизу никто ничего хорошего от словосочетания «бизнес-процесс» не ждет. Вот как я это делаю в разговорах с людьми:

Представьте себе, что у вас появился робот-помощник. Безотказный и безошибочный. Он возьмет на себя самую нудную, канцелярскую часть вашей работы. Например, вы сможете ему сказать:

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

Кто, скажите мне, откажется от такого помощника?

К тому же BPM-робот безопасен, потому что он подчиняется законам - хотя и не тем, что у Айзимова.

Законы робототехники BPM:

1. Робот никогда не сможет сделать все то, что можете сделать вы.
2. Робот будет делать только часть того, что делаете вы.
3. Робот будет делать только ту часть вашей работы, которую вы сами не захотите делать.