Наверх

Такой нужный Workflow. Интеграция приложений

Время чтения: 3 минуты
4
Такой нужный Workflow. Интеграция приложений

Согласовать командировку, а потом отразить отчетность в ERP, написать статью и опубликовать ее на внутреннем сайте... Знакомо? Тогда читаем блог.

Часто бывают ситуации, когда автоматизация предприятия происходит не сразу, а постепенно, в течение нескольких лет. При отсутствии больших средств, вначале автоматизируются наиболее критичные участи (как правило – это бухгалтерия), а потом все остальное, причем опять не сразу, а по частям. В итоге, когда дело доходит до автоматизации документооборота, предприятие уже имеет целый «зоопарк» различного ПО.

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

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

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

согласование служебной записки - синхронизация служебной записки в ERP - публикация сведений на сайт

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

Чтобы прокомментировать, или зарегистрируйтесь