Вчера в разговоре с клиентом не смог четко объяснить, в чем разница между шаблоном и паттерном.

Фактически речь идет о двух способах решения задач:

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

Какое-то мутноватое получается объяснение, не так ли? Добавляет путаницы то, что английские “template” и “pattern” зачастую оба переводят как “шаблон”, и смысл при этом частично теряется.

Думая о том, как это можно объяснить “на пальцах”, нашел аналогию в шахматах:

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

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

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

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

Паттерны в BPM - это типовые фрагменты процессов или межпроцессного взаимодействия (некоторые примеры).

Уместно спросить: от чего больше пользы? Мое мнение - от паттернов:

• Шаблоны специфичны (один процесс - один шаблон), паттерны универсальны. Хороший паттерн можно использовать в самых разных бизнес-процессах независимо от отраслевой специфики.
• Польза от шаблона на практике оказывается меньше ожидаемой. Как правило, позаимствовать удается только магистральный путь (happy path), а дьявол оказывается в деталях - в обходных путях, в обработке нештатных ситуаций.
• Эффект от использования правильного паттерна может быть очень большим. Например, в нашей практике был случай, когда процесс, изображенный на 6 склеенных друг с другом листах формата А4, за счет использования правильного паттерна удалось свести к изящной конструкции из 15 процессных шагов.
• Что касается антипаттерна, его польза в том, что в нужный момент он предостережет вас от ошибки. Цена ошибки теоретически может быть любой, и иногда реально большой.

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

Еще один часто задаваемый вопрос из форума.

Вопрос - В случае изменения шаблона бизнес-процесса (добавили/удалили активити) что происходит с реальными начатыми по этому шаблону (в предыдущей версии) бизнес-процессами? Что происходит в связи с этим с аналитикой?

Ответ - Большинство BPMS в такой ситуации завершат начатые экземпляры бизнес-процесса по старому шаблону, а новые будут создавать по новому. Это можно считать удовлетворительным решением только если изменение шаблона - плановое. Если же, как часто бывает, процесс зашел в тупик из-за того, что в шаблоне в данном месте не предусмотрели переход или развилку, то все что вам остается, это аварийно завершить данный экземпляр процесса и начать его снова по новому шаблону. Аналитика при этом накрывается.

Однако системы, которые позволяют модифицировать схему процесса “на лету”, существуют. Рекомендуемое чтение по теме:

• Статья Glen Smith из Appian на ebizq.net рассказывает почему важно иметь такую возможность с методологической точки зрения. Если над вами не довлеет жесткая необходимость выявить процесс до мельчайших деталей всех возможных исключений, то вы можете быстрее запустить его в эксплуатацию.
• Keith Svenson из Fujitsu обращает внимание на то, что изменение схему “на лету” принципиально очень сложно реализовать в системах, в которых для исполнения процесса используется BPEL. Fujtsu Interstage BPM позволяет вам отредактировать схему экземпляра процесса точно так же, как и схему шаблона, и при желании, сохранить полученную схему в качестве новой версии шаблона.

За информацией о последней версии конкретной BPMS обращайтесь к отчету BPTrends.

Если редактор бизнес-процессов (моделер) реализован в виде десктопного приложения (а именно так обстоит дело в большинстве систем), то это принципиально ограничивает возможность исправления процесса “на лету”. Если экземпляр процесса застрял, то необходимо иметь возможность оперативно, в онлайне исправить схему. То есть моделер должен быть реализован в виде тонкого клиента. К примеру, в Fujitsu Interstage имеется и десктопная версия моделера, и онлайновая в виде апплета.

В Oracle BPMS (aka BEA AquaLogic BPM aka Fuego) выбран другой путь. В палитре этой системы есть специальный “магический” активити, который может забрать на себя управление с любого активити и/или передать на любой активити. Это решает большую часть проблемы - отсутствие на схеме необходимого перехода.

Но не стоит полагаться только на инструментарий - надо грамотно проектировать схему процесса.

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

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

“Правда можно многие задачи 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 можно и потом прикрутить.