Unify.RU
О компанииРешенияПродуктыДемо

Темп разработки как один из ключевых факторов успеха проекта BPM

BPM — это, во-первых, возможность заниматься бизнес-процессами планомерно и постоянно, а не в режиме «шоковой терапии», который предлагал традиционный реинжиниринг. Во-вторых, BPM располагает более мощным арсеналом программного обеспечения. Если инструментарий реинжиниринга ограничивался средствами рисования IDEF и DFD диаграмм, то в BPM-системе моделированием бизнес-процесса дело только начинается. BPM-система непосредственно управляет исполнением бизнес-процесса, раздавая поручения управленцам, и отслеживает выполнение шагов бизнес-процесса. (Подробнее о BPM-системах: www.bpms.ru.)

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

Стремление совершенствовать бизнес-процессы не однократным «большим скачком», а постепенно, присутствовало и раньше, но для этого необходимо, чтобы каждый шаг не затягивался во времени. А именно это, к сожалению, и происходило: изменение бизнес-процесса влекло за собой перепрограммирование (или перенастройку, что почти то же самое) корпоративной информационной системы, выпуск новых должностных инструкций, переобучение специалистов. В режиме такой «перманентной революции» предприятие жить не может; тот, кто пережил реинжиниринг один раз, не захочет подвергнуться ему снова.

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

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

Узкое место проектов BPM

Опыт проектов BPM показывает, что моделирование бизнес-процессов в них выполняется действительно быстро, однако разработка пользовательских интерфейсов и стыковка бизнес-процессов с существующими приложениями по-прежнему остается трудоемким занятием. В результате в реальных проектах на долю моделирования бизнес-процесса приходится меньшая часть трудозатрат, а большая — до 75-80% — приходится на разработку интерфейсов к шагам бизнес-процесса. Из-за недостаточного темпа разработки интерфейсов оказывается скомпроментированной стержневая идея BPM — идея перенастройки бизнес-процессов «в реальном времени».

Конкретизируем: о каких интерфейсах бизнес-процесса идет речь?

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

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

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

Стандартные подходы к разработке интерфейсов

Что касается стыковки с приложениями, начиная от ERP- и CRM-систем и заканчивая собственными программами и базами данных, то тут магистральное решение — это вебсервисы и SOA, сервис-ориентированная архитектура. Как правило, BPM-системы предоставляют возможность обращаться к вебсервисам без ручного программирования.

Таким образом, с вызовом вебсервисов проблем не возникает, но как обстоит дело с другой стороны — со стороны предоставления вебсервисов? Все поставщики ERP, например, уже заявили о своей поддержке этой технологии, так что со временем к их системам можно будет обращаться через веб-сервисы. Но к сожалению, на сегодняшний день вебсервисы — это лишь отдельные островки в океане разнообразных систем с собственными, уникальными интерфейсами. Пусть даже в ERP-системах со временем появятся вебсервисы и они, таким образом, станут готовы к интеграции. Но даже тогда останется множество так называемых «унаследованных» систем и отдельных программ — тех, что продолжают эксплуатироваться, решают возложенные на них задачи, но чье дальнейшее развитие прекращено.

Вторая стандартная ситуация: если внешняя система хранит свои данные в базе данных, и контекст бизнес-процесса требует доступ к ним только на чтение, то можно воспользоваться прямым доступом к базе, например, через JDBC.

В остальных случаях разработчикам приходится проявлять изобретательность, вплоть до стыковки с унаследованными системами через файловый обмен.

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

Далее: Разработка композитных веб-приложений при помощи Unify NXJ ActiveForms...

О компании | Решения | Продукты | Демо | Скачать | Купить | Партнерам | вузам | Карта сайта