Заказчику нужно срочно привести в порядок процесс заключения договоров - что называется, “уже вчера”.

Но для этого надо заключить договор с консультантом BPM

Из серии “непридуманные истории”.

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

Потом, лет 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 тянул собственную СУБД много лет, но в итоге с дистанции сошел.

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

Бизнес похож на войну, война похожа на шахматы. Конечно любая аналогия хромает, но почему бы не поиграть в аналогии для развлечения?

Бизнесмен: мы принимаем решения на основе предварительной оценки окупаемости или возврата на инвестиции (ROI).

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

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

Бизнесмен: у нас тоже есть стратегия компании.

Шахматист: мы это называем планом на игру. Только у нас его составляет и выполняет один игрок, а у вас через каждые несколько ходов подводится баланс выигранного/потерянного материала и, в зависимости от результата, за стол может сесть новый генеральный директор. Интересно было бы посмотреть на вашу команду за шахматной доской.

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

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

Военный: мы тоже считаем темпы операций. Классический пример: время мобилизации и развертывания в начале войны стали краеугольным камнем знаменитого плана Шлиффена немецкого Генштаба на войну, которую потом назвали Первой мировой. Загонять противника “под флажок” мы тоже умеем: наводнить его штабы противоречивой информацией и дезинформации, совершать ходы, которых он не ожидает, чтобы он не успевал переваривать информацию и в результате постараться добиться паралича управления войсками.

Бизнесмен: так, кажется я начинаю понимать что это за business agility, о которой в последнее время столько разговоров…

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

BPMInstitute анонсировал презентацию: “Secrets of a Business Process Consultant Shhhhh…Processes, Tools and Techniques that the Pros Use“. Сама презентация на мой вкус слишком пафосна, но один слайд стоит поместить в мемориз (даю вольный перевод, оригинал в английской версии):

Вы когда-нибудь слышали такое -

• “Вам придется вернуться, когда здесь будет Ирина - никто кроме нее не знает что с этим делать”
• “Мы всегда так делали”
• “Они не делают это по-нашему”
• “Это не моя работа”
• “Они только что послали меня к вам, а теперь вы посылаете меня обратно?”
• “Зачем такие сложности?”
• “Вам надо вернуться к ___ за подписью”
• “Когда я подавал ___ в прошлый раз, этого не требовалось”
• “В их департаменте это делается по-другому”
• “Так: кто бы не сказал вам что это неправильно, на самом деле это правильно”

Точнее, это было очень смешно в 90-е; современные процессные дисциплины не доставляют так, как реинжиниринг и ISO 9000. В качестве иллюстрации - подборка комиксов “Dilbert” от Скотта Адамса на околопроцессные темы. » читать дальше