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

Конечно хорошо, когда данные структурированы и лежат в БД в нормализованном виде: можно удобно и быстро извлекать, группировать, сравнивать. Чтобы делать это еще быстрее, поверх СУБД накрутили 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 тянул собственную СУБД много лет, но в итоге с дистанции сошел.

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

Текст ниже - полная версия моей статьи, опубликованной в журнале “Открытые системы”, №8, 2012.

BPMN вошел в моду. Заказчики требуют BPMN, так как это, по их мнению, современная, а значит, априори более совершенная процессная нотация.

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

Итак, что же такое BPMN -

«Еще одна нотация» или «Та самая нотация»?

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

Когда: 7 ноября, с 17:00 до 21:00.

Где: РосНОУ, Москва, ул.Радио, 22.

Условия участия: бесплатно, для всех желающих при условии регистрации.

Неконференция - это интересно, приходите! Креатив и драйв гарантированы.

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

Между тем схема процесса и схема данных – это два ключевых аспекта архитектуры любого процессного приложения, а моделирование процессов и моделирование данных являются для процессного инженера ключевыми компетенциями. Причем не только ключевыми, но и равноправными. » читать дальше

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 - это уже вопрос уже не завтрашнего, а вчерашнего дня. При том, что и завтрашний день обещает много интересного и полезного.

Рассмотрим достаточно типичный бизнес-процесс:

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

Первая версия процессной диаграммы: » читать дальше

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

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

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

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

Недавний опрос на ebizQ «What is the most important question to ask when starting a BPM project?» собрал рекордное число откликов. При этом Питер не уточнил роль – какая сторона задает вопрос? Поскольку большинство активных участников (писателей) форума – BPM-вендоры или консультанты, то вопрос они формулировали так, как бы они его задали потенциальному клиенту. Большинство сошлось на том, что самые главные вопросы – о контексте, целях и метриках успеха проекта BPM, (с чем я полностью согласен).

Но давайте оборотимся на себя: какой самый сложный вопрос потенциальный клиент может задать BPM-вендору?

Для меня самый сложный вопрос – «Что я с этого буду иметь?»

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

В прошлой заметке я констатировал, что на верхнем уровне процессного анализа с точки зрения BPMN мы имеем дело не с процессами, а с семействами процессов.

К сожалению, BPMN не предоставляет средств для моделирования на этом уровне. Чаще всего аналитики прибегают к IDEF0, мне как-то больше по душе DFD - но так или иначе, тот факт, что приходится пользоваться двумя нотациями, не радует.

Поэтому я рисую DFD-диаграммы с помощью палитры BPMN. Получается примерно так:

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