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

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

На блоге Gartner появилась заметка Janelle Hill “Do You Understand the Difference Between Workflow and BPM?“. Как замечено в комментариях, это хороший ответ тем, кто считает, что “BPM - это Workflow на стероидах”.

По мнению Gartner, идеальная BPMS реализует 10 технологий, из которых Workflow - всего лишь одна:

1. Процессный движок (Process Execution and State Management Engine) - компонента, реализующая Workflow.
2. Среда разработки, основанная на графических моделях (Model-Driven Development Environment). Но в workflow-системах тоже обычно есть графические средства моделирования. Менее мощные (обычно только оркестровка без хореографии), не следующие стандартам (BPMN), но есть. Получается не 1/10, а 2/10.
3. Управление документами и контентом (Document and Content Management). Спорно. На мой взгляд, есть структурированные данные, есть неструктурированный контент и есть процессы, и для управления ими придуманы, соответственно, DBMS, ECM и BPMS. Без необходимости границы лучше соблюдать, ничего не следует  делать “заодно” - ни управлять контентом в BPMS, ни управлять процессами в ECM. Мы же не включаем в BPMS управление данными, не дублируем DBMS - почему с контентом должно быть по-другому? 2/9.
4. Средства совместной работы пользователей и групп (User and Group Collaboration). Да, конечно, но рассматривать это как часть BPMS? А что, совместной работы вне процессов не бывает? Конечно бывает, например, в проектах. Получается, для процессов свои средства совместной работы, а для проектов - свои? Абсурд. 2/8.
5. Средства интеграции (System Connectivity). Действительно, в BPMS работа, выполняемая людьми, работа с документами и действия, выполняемые автоматизированными системами, трактуются единообразно, без перекоса в сторону первых (что характерно для систем human workflow) или вторых (системы docflow). Кстати, пункты 3 и 4 я бы поместил сюда - в виде средств интеграции с системами управления контентом и средствами совместной работы.
6. Бизнес-события, бизнес-аналитика и мониторинг (Business Events, BI and BAM). Строго говоря, к BPMS относится только последнее, а первые два могут использоваться независимо.
7. Имитационное моделирование и оптимизация (Inline  and Offline Simulation and Optimization). Похоже, только Gartner знает, что они имеют в виду под “inline and offline”, но по существу возражений нет.
8. Машина бизнес-правил (Business Rules Engine). В теории она может использоваться как единое хранилище глобальных переменных любой (лучше каждой) корпоративной системой. Но на практике в основном используется BPMS.
9. Средства управления и системное администрирование (System Management and Administration). В том или ином виде это есть в любой системе: 3/8.
10. Каталог-репозиторий процессных компонент (Process Component Registry/Repository). С одной стороны, в Workflow-системе тоже можно найти каталог процессов в том или ином виде. С другой стороны, репозиторий процессов в рамках BPMS, в отрыве от репозитория сервисов SOA, тоже не лучшая идея. 4/8.

Итоговый счет у меня получился не столь разгромный - 4:8, а не 1:10. Но сама идея подсчета очков порочна: на чашу весов BPM есть что положить кроме технологий. Прежде чем сравнивать BPMS с Workflow, надо сказать, что BPM != BPMS. BPM - это:

1. Методология: иерархия целей организации, цепочка создания ценностей, сквозные бизнес-процессы, выявление процессов, цикл непрерывного усовершенствования.
2. Реализация: программа, понимаемая как серия проектов; гибкая разработка (agile).
3. Технология (BPMS).

Если нет компетенции в методологии или реализации, проект BPM обречен даже с самой лучшей BPMS.

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

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

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

• Непрерывное улучшение? Ерунда, надо тщательнее проектировать, а главное - тщательнее составлять требования!
• Схема процесса? Настоящая программа - это код, а не “стрелки-квадратики”.
• Наше дело автоматизация, а что именно автоматизировать пусть скажет бизнес.
• Гибкая разработка? Наши пользователи не согласятся работать с системой, в которой нет всего что им нужно.

И поскольку Workflow - это только технология, то с ним им гораздо комфортнее, чем с непонятным, разрекламированным и переусложненным (с их точки зрения) BPM.

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

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

Возвращаясь к технологиям, я бы не сказал, что BPMS кладет Workflow на лопатки. Но это ему и не нужно, потому что тут есть еще один важный аспект: BPMS - это следующее поколение технологий. XML и Интернет, тонкий клиент, современные стандартные платформы (J2EE или .NET), стандартные нотации (BPMN, BPEL) вместо проприетарных. В быстро меняющемся мире ИТ даже относительно небольшое технологическое отставание фатально: если основная масса разработчиков начинает воспринимать какое-то направление как устаревшее, то оно достаточно быстро маргинализируется просто потому, что никто добровольно с ним работать не хочет. Поэтому нравятся вам Workflow-системы или нет - останутся жить только те из них, которые смогут влиться в мейнстрим: перейти на современную платформу, сменить нотацию, добавить недостающие функции из списка Gartner, т.е. превратиться в BPMS.

В очередной раз на очередном форуме всплыл этот вопрос:

“Правда можно многие задачи BPM решать с помощью документооборота, также, как и с помощью БД. Правда получится не сильно хорошо…”

Это явный FAQ, поэтому дам-ка я на него развернутый ответ. Сам вопрос переформулирую для общности.

Вопрос - Как разграничить области применения СУБД, ECM и BPMS? Как их сочетать?

Ответ - Вообще говоря, у нас есть:

1. структурированная информация, с которой лучше всего умеют работать СУБД
2. неструктурированная информация (документы), для которой предназначены ECM
3. процессная информация, под которую заточены BPMS

(BPMS используют СУБД, а ECM может использовать СУБД или файловую систему, но мы от этого абстрагируемся.)

Каждый из троицы СУБД-ECM-BPMS способен при необходимости подменить любого из двух собратьев, но естественно, в той или иной степени ублюдочным cпособом:

• СУБД умеют хранить документы в текстовых и двоичных полях, но до полной функциональности ECM не дотягивают (например, в части навигации, поиска по контексту, версионности, разграничения доступа, интеграции с MS Office).
• В СУБД иногда хранят процессную информацию, например создавая для этого таблицу, каждая запись которой описывает очередной шаг обработки документа. Понятно, что это очень примитивное описание по сравнению с диаграммой процесса в BPMS.
• В ECM встраивают workflow-движки, но полноценной BPMS такая реализация проигрывает из-за проприетарных нотации, платформы, средств интеграции, а главное, из-за отсутствия поддержки методологии непрерывного усовершенствования. Проще говоря, в ECM можно реализовать бизнес-процесс, но трудно менять его в требуемом темпе.
• Структурированные данные можно загнать в файл Excel, а файл - в ECM.
• У BPMS есть типизированные атрибуты для хранения структурированных данных, но пользоваться ими можно только в ограниченных объемах - по производительности такой механизм и близко не стоит с непосредственным хранением в СУБД.
• BPMS позволяет прицепить к экземпляру процесса документы, но, как и в случае хранения их в СУБД, сервис по сравнению с ECM будет убогий. К тому же возникает вопрос: как добираться до документов после того, как процесс завершился?

Таким образом, если вы планируете инфраструктуру на перспективу, то вам понадобятся все три компоненты. Если же перед вами стоит задача, ограниченная по функциональности, ресурсам и/или срокам, то вы можете поискать решение “для бедных”, скомпенсировав отсутствие компоненты за счет имеющихся в наличии.

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