Такой нужный Workflow. Интеграция приложений
Согласовать командировку, а потом отразить отчетность в ERP, написать статью и опубликовать ее на внутреннем сайте... Знакомо? Тогда читаем блог.
Часто бывают ситуации, когда автоматизация предприятия происходит не сразу, а постепенно, в течение нескольких лет. При отсутствии больших средств, вначале автоматизируются наиболее критичные участи (как правило – это бухгалтерия), а потом все остальное, причем опять не сразу, а по частям. В итоге, когда дело доходит до автоматизации документооборота, предприятие уже имеет целый «зоопарк» различного ПО.
Известно, что автоматизация даст максимальный эффект и лояльность пользователей тогда, когда данные будут вводиться только один раз и там, где это удобно, а в дальнейшем будут использоваться многократно различными приложениями, которые в этих данных нуждаются. При этом часть приложений имеют весьма скудные возможности по интеграции с ними, да и организовать интеграцию всего со всем напрямую весьма нетривиальная задача, к тому же требующая постоянного слежения за ее жизнеспособностью.
Представьте простейшую ситуацию: на предприятии есть ERP-система и электронный архив документов. Служебные записки хранятся в электронном архиве. Из этих служебных записок нужно выбрать записки на оплату и занести сведения из них в ERP систему. Допустим ИТ-специалисты предприятия решили данную ситуацию и теперь синхронизация документов производится автоматически. Но вот, спустя месяц, генеральный директор попросил, чтобы на внутреннем сайте отображались отчеты обо всех служебных записках на оплату. Придется делать еще и интеграцию электронного архива или ERP-системы с внутренним порталом и после модификаций проверять работоспособность прежних механизмов интеграции. А если потом появятся новые требования, то опять придется все изменять.
В данной ситуации я порекомендовал бы обратить внимание на Workflow. Ведь по сути мы имеем бизнес-процесс прохождения типового документа, состоящий из следующих этапов:
В описанной ситуации достаточно было бы добавить еще один этап в маршрут Workflow и задача, поставленная генеральным директором, была бы решена.
Подобных примеров может быть множество. Вот некоторые из них:
● публикация новости на сайт;
● автоматическое создание учетных записей на почтовом сервере, в ECM и/или ERP-системе и в остальных системах, работающих в организации, после приема на работу нового сотрудника;
● обновление прайс-листа на сайте;
● утверждение отпуска сотрудника с автоматическим отражением сведений в системе планирования работ;
● создание документов в ERP после их согласования;
● импорт документов, пришедших по электронной почте;
● автоматическая регистрация обращений в службу поддержки;
● и т.д.
Преимущества Workflow здесь очевидны:
● универсальная архитектура – независимо от сложности и количества приложений, действующих на предприятии, все они участвуют в одном процессе и получают данные, необходимые для этого процесса cпомощью Workflow;
● гибкие возможности для настройки - можно создавать свои виды этапов (например, «Публикация документа на портал», «Синхронизация с ERP» и т.д.), задавать произвольный порядок выполнения этапов и правила перехода между этапами;
● внося изменения в процесс нет необходимости проверять работоспособность остальных процессов;
● нет необходимости реализации точечной интеграции каждого приложения с каждым.
Комментарии 4
Workflow систем ECM и интеграция приложений вещий разные и их нельзя и даже преступно рассматривать как одно и тоже (по крайней мере, в рамках больших информационных систем). Для интеграции приложений нужны решения класса ESB (Enterprise Service Bus) или в терминологии MS EAI (Enterprise Application Integration). У них язык стандартизованный для описания бизнес-процессов есть (BPEL) и коннекторы ко многим и распространенным системам. Да и производительность другого уровня. А интегрировать все со всем по отдельности... количество связей и как следствие логических и архитектурных ошибок будет слишком много. Вот.
Ну отчего же преступно? Естественно, Workflow не стоит рассматривать как специализированный инструмент для объединения различного ПО организации в единую информационную систему, но некоторые функции подобного "интегратора" Workflow может выполнять. Этих функций будет достаточно множеству организаций, особенно, если ECM у них есть (или скоро будет), а свободных средств на специалзированные решения нет.
Напомню также, что данная запись блога является продолжением цикла "Такой нужный Workflow...." и в ней, как и в предыдущей, я рассматриваю лишь одну сторону Workflow. Ни в одной из записей блога данного цикла я не утверждаю, что это основная и уж тем более единственная возможность данного механизма.
Мне тоже кажется, что рассматривать Workflow как средство глобальной интеграции приложений не совсем верно. Процесс публикации не сайт - это не этап процесса, а средство интеграции. Для реализации рассмотренных целей все-таки эффективнее на мой взгляд идти от SOA, сервисов подписки на события различных систем и т.п. Безусловно, Workflow на своем пути может встретить перемещение информации из одной системы в другую, но это должно отражать именно этапы бизнес-процесса, а не технические моменты интеграции.
WF становится BPM, когда к его функционалу добавляют функции работы с сервисами по технологии SOA. В современных отечественных СЭД интеграция реализуется на уровне COM - объектов. Имеет смысл выделять области WF, когда БП касаются работы с исполнителями, и BPM, когда включается формирование запросов на обработку во внешние системы, получение ответов и формирование результатов.