Литература:

• Статьи
• Обзоры
• Форумы
• Стандарты
• Книги
• Авторы

Автор: Vickesh Dhookie

Оригинал статьи: «BPM: Knowing the Future Means Knowing the Past»
Part I: www.ebizq.net/topics/bpm/features/10697.html
Part II: www.ebizq.net/topics/human_centric_bpm/features/10702.html

В этой статье тема происхождения Business Process Management (BPM) рассматривается в духе Дарвиновской теории эволюции. В течение лет эволюция BPM разворачивалась по двум параллельным путям, а именно: бизнес и технологии. В области бизнеса развитие шло от систем контроля качества (TQM, Total Quality Management) через реинжиниринг бизнес-процессов (BPR, Business Process Re-engineering) к BPM, а в области технологий – от автономных (standalone) приложений (и здесь я сгруппировал приложения для работы с изображениями) к автоматизации потоков работ (workflow applications) и в конце концов к системам управления бизнес-процессами (BPMS, Business Process Management Suite).

Эти две параллельные эволюции в итоге сошлись друг с другом благодаря недостающему звену model driven architecture, и мы видим, что, смоделировав бизнес-процесс, можно получить преконфигурированное приложение, покрывающее от 80% до 90% бизнес-требований – оставшиеся 10%-20% требуют задействования имеющихся активов и итеграции в специализированные бизнес-системы организации.

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

После Второй мировой войны два пионера TQM переехали в Японию, где им удалось убедить топ-менеджеров в важности контроля качества. В течении следующих 20 лет США фокусировалось на маркетинге, объемах выпуска и финансовой эффективности, в то время как японские менеджеры подняли качество на беспрецедентную высоту. Очень скоро японским товарам стали отдавать предпочтение перед американскими, и это инициировало революцию качества в начале 80-х.

Революция качества дала рождение термину Total Quality Management, под которым понимается интеграция принципов качества в систему управления организации. В начале 90-х принципы управления качеством стали прокладывать путь в отрасль услуг, и пионерами в этом стали Ritz-Carlton Hotel и FedEx.

TQM можно определить следующим образом:

• Total – означает вовлечение в деятельность всех и каждого в компании.
• Quality – обеспечение соответствия требованиям клиента.
• Management – понимание того, что качеством можно и нужно управлять и что это непрерывный процесс усовершенствования.

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

Принцип 1

Клиенто-ориентированная организация – организации зависят от своих клиентов и следовательно обязаны понимать их текущие и будущие потребности, соответствовать требованиям клиента и стремиться превосходить его ожидания.

Принцип 2

Лидерство – лидер задает единство цели, направления и внутренней обстановки организации. Они создают обстановку, в которой люди способны оказаться полностью вовлечены в достижение целей организации.

Принцип 3

Вовлечение людей – люди на всех уровнях составляют суть организации и полная их вовлеченность дает возможность использовать их способности для блага организации.

Принцип 4

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

Принцип 5

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

Принцип 6

Непрерывное усовершенствование – непрерывное усовершенствование есть постоянная цель организации.

Принцип 7

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

Принцип 8

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

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

• Фундаментальный пересмотр и радикальное перепроектирование бизнес-процессов с целью достижения значительных улучшений в критических современных показателях эффективности, таких как стоимость, качество, обслуживание и скорость (Хаммер и Чампи).
• Изобретение новых стратегий работы, деятельность по определению реально существующего процесса и реализация изменения во всей сложности его технологической, человеческой и организационной составляющих (Томас Дэвенпорт).

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

Основные принципы TQM, которые были унаследованы BPR, следующие:

• клиент на первом месте,
• взгляд от процесса,
• польза от партнерства с клиентами и поставщиками,
• продвижение командного стиля через декомпозицию работ.

Посмотрев на сходство между TQM и BPR, давайте сравним эти две управленческие дисциплины. Если сравнить основные линии, то мы увидим, что TQM фокусируется на улучшении уже существующего, в то время как BPR игнорирует существующее в настоящее время и начинает с чистого листа. Подход TQM по природе итерационный, что означает разбиение проекта на управляемые этапы и реализацию каждого из низ в рамках непрерывного усовершенствования. С другой стороны, BPR принял радикальный подход, при котором огромный проект масштаба предприятия выполняется «большим скачком» с небольшим успехом или без такового. Основное предположение TQM заключается в том, что существующие процессы являются здравыми и просто требуют улучшения, в то время как основное предположение BPR – существующие процессы не годятся и нуждаются в радикальном перепроектировании.

В рамках инициативы TQM изменения в организации происходят непрерывно, и постоянное изменение должно стать частью культуры организации, в то время как BPR-инициатива рассматривает изменение организации как однократное упражнение.

Роль ИТ в инициативах TQM случайна, и значимая автоматизация не проводится, то время как в инициативах BPR ИТ рассматривается как основная сила, способствующая процессам в организации.

Рассмотрим вовлечение ИТ в сравнении с трансформацией бизнеса для циклов бизнес-эволюции, как показано на рис. 1. При движении слева направо увеличивается масштаб трансформации бизнеса и вместе с этим – степень вовлечения ИТ.

Рис. 1

По мере того как системы управления бизнес-процессами (BPMS, Business Process Management Suite) становятся все более зрелыми, становится все более очевидным, как роли бизнеса и ИТ сливаются и как эти системы предоставляют бизнес-платформы.

Теперь мы рассмотрим характеристики инициатив BPR, их недостатки и выясним что следует иметь в виду для обеспечения их успеха.

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

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

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

Один из основных недостатков BPR – его полное игнорирование людей, что приводило к существенной недооценки сопротивления переменам внутри организации. В сочетании с недостаточной поддержкой менеджментом и преувеличенными ожиданиями по отношению к потенциальной выгоде, это привело к плохому послужному списку BPR.

Еще сильнее его ухудшила реализация универсальных так называемых «процессов – лучших практик» (best practice) без учета специфических нужд конкретной компании и реализация BPR как однократного проекта без достаточной координации со стратегией и долгосрочными перспективами.

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

1. Первое чему следует уделить внимание – это спонсор из числа высшего руководства. Спонсорство является ключом в силу природы подобных мероприятий: их радикальности и охвата организации в целом. Если с самого начала не будет обеспечено спонсорство со стороны высшего руководства, то сложности, которые возникнут на пути, приведут к провалу.
2. Соответствие инициативы стратегии организации в целом гарантируют, что в результате усилий стратегия и может и будет реализована на операционном уровне.
3. Для реализации проекта должна быть подобрана сильная и разносторонняя команда. В идеале команда должна включать людей бизнеса, которые реально вовлечены в операции.
4. Должно быть составлено бизнес-обоснование, четко определяющее возврат инвестиций и то каким образом будут уменьшены издержки, увеличены продажи и/или увеличена производительность.
5. Должны быть использованы проверенные методологии – они повышают вероятность успеха, позволяя учиться на прошлых ошибках.
6. С начала проекта подобного рода необходимо управлять восприимчивостью перемен в организации. Один из ключевых вопросов – это сокращения. Частое общение с персоналом критически важно чтобы подобные мероприятия были приняты в организации. В инициативах BPM мы наблюдаем сдвиг от повышения эффективности за счет сокращения рабочих мест к повышению эффективности за счет повышения производительности.

Последнее требование, которое мы рассмотрим,– показывать результаты быстро. Одна из самых частых критик начала 90-х в адрес проектов BPR – они требовали слишком много времени для демонстрации результатов. Инициативы BPM, благодаря итерационной природе, результаты могут быть получены намного быстрее и с минимальным отклонением от бизнес-требований.

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

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

Если мы рассмотрим два вышеприведенных определения, мы увидим три ключевые момента в определении BPM.

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

Второй ключевой момент определения BPM – то, что это новая софтверная технология. Это не вполне истинно, так как базовые концепции и принципы, которые BPMS объединяют в единой платформе или инфраструктуре организации, существовали в течение многих лет, единственная разница в том, что теперь они упакованы в единое предложение.

Третий и последний ключевой момент определения BPM – это новый способ реализации. Вероятно, максимальный прогресс, который приносит BPM,– бизнес теперь имеет возможность если не упразднить, то радикально упростить решение, проблемы хождений по кругу («round trip») при внедрении бизнес-приложений. Благодаря возможностям, предоставляемым современными BPMS, бизнес имеет возможность смоделировать бизнес-процесс и в течение минут получить преконфигурированное приложение, дающее возможность подтвердить соответствие бизнес-требований. Это открывает путь к более итеративному сбору бизнес-требований и полноценной реализации Model Driven Architecture.

В заключительной части описания бизнес-эволюции мы рассмотрим BPR в сравнении с BPM. Отправная точка сравнения – взгляд на текущие бизнес-процессы организации. С позиции образа мыслей BPR, процессы фундаментально неправильны и необходимо разработать полностью новый набор процессов, в то время как образ мыслей BPM больше соответствует TQM, бизнес-процессы берутся такими, какие есть, и автоматизируются в рамках непрерывного и инкрементного улучшения. Один ключевой момент, который необходимо держать в уме,– к автоматизации процессов необходимо приступать как можно раньше, поскольку реализация MDA в рамках BPMS сегодня позволяет очень быстро вычистить узкие места или потери в рамках процесса, и нет необходимости в выполнении широкомасштабного анализа процессов, прежде чем приступать к автоматизации.

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

Третье различие – BPR определяет организацию как совокупность функциональных ям (silo’s) и основывается на функциях, в то время как BPM определяет сквозные функции организации и основывается на результатах.

Четвертое различие – в проекте BPR проходит где-то от 6 до 24 месяцев до того, как проект начинает давать хоть в каком-то виде возврат от инвестиций, в то время как проекты BPM сейчас способны показывать возврат от инвестиций всего лишь за 90 дней.

Пятое различие – в проектах BPR совместная работа бизнеса и ИТ опциональна, а в проектах BPM совместная работа критически важна, так как BPMS – это связующее звено между ролями бизнеса и ИТ, обеспечивающее организации адаптивность и гибкость.

Шестое различие – BPR в сущности концентрировался на снижении затрат, в то время как BPM фокусируется на оптимизации активов или на возможности увеличить производительность при использовании тех же ресурсов.

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

Завершающий пункт сопоставления – в рамках инициативы BPR потоки работ и интеграция корпоративных приложений использовались в рамках собственных автономных сред. В случае BPM изобретены BPMS, предоставляющие единую платформу организации, которая объединяет прежде автономные среды.

После того как мы установили разницу между BPR и BPM, мы обратим наше внимание на три основные, развивавшиеся годами процессные методологии.

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

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

Третья методология – теория ограничений (Theory of Constraints). Основная идея – поднимать или эксплуатировать ограничения, добиваясь большей пропускной способности и увеличения производительности. Конечный результат этой методологии – определение максимального объема, который можно прогнать через данный процесс, прежде чем процесс скатится до хаотического состояния. Механизм, используемый для этого BPMS – эскалация и соглашения об уровнях обслуживания (SLA, Service Level Agreement). BPMS позволяет указать для шага процесса SLA. Если этот SLA не выдерживается, может быть запущена процедура эскалации, гарантирующая, что ограничения будут учтены скорее раньше, чем позже.

Завершая этот раздел BPM, мы обсудим Business Process Modeling Notation (BPMN). Работа над BPMN первоначально была начата в рамках Business Process Management Initiative, главной задачей которого было разработать нотацию моделирования, которая была бы доступна для понимания всеми заинтересованными лицами, т.е. бизнес-пользователями, бизнес-аналиткиами, техническими аналитиками и разработчиками. BPMN играет ключевую роль в реализации MDA и поэтому я кратко опишу основной набор элементов.

Рис. 2.

Как показано на рис. 2, основные элементы BPMN это:

• Объекты потока (Flow Objects): обозначают начало и конец диаграммы бизнес-процесса (BPD, Business Process Diagram), какие задачи и шаги выполняются в рамках BPD и по какому маршруту направляется поток работ поток. Объекты потока состоят из:
• Событий (Events). Событие – это нечто «случающееся» в рамках процесса. События влияют на протекание процесса и обычно имеют причину (триггер) или воздействие (результат). События обозначаются кружками с пустым центром, который позволяет разместить внутри маркер для определения различных типов триггеров или результатов. События делятся на три типа согласно тому, когда они воздействуют на поток: старт, конец процесса и промежуточное.
• Активностей (Activities). Активность – это обобщенный термин для работы, выполняемой в компании. Активность может быть атомарной или неатомарной (составной). Типы активностей, являющихся частью модели процесса: процесс (Process), подпроцесс (Sub-Process) и задача (Task). Задачи и Подпроцессы обозначаются скругленными прямоугольниками.
• Ворота (Gateways). Ворота служат для управления расхождением и схождением потока последовательности (Sequence Flow). То есть, ими задаются ветвления, развилки, слияния и объединения маршрутов. Элемент, помещенный внутрь ромба, обозначает тип управляющего поведения.
• Соединительные объекты (Connecting Objects): обозначают направление течения процесса в рамках диаграммы бизнес-процесса и состоят из:
• Потока последовательности (Sequence Flow). Поток последовательности – это сплошная линия с заполненной треугольной стрелкой, которая показывает порядок исполнения активностей (Activity) в процессе.
• Потока сообщений (Message Flow). Поток сообщений показывает течение сообщений между двумя участниками, готовыми к тому чтобы его отправить и принять. В BPMN два участника (например, организации или бизнес-роли) отображаются на диаграмме двумя разными пулами (Pool).
• Ассоциаций (Association). Ассоциация – сплошная линия с открытой стрелкой, которая используется для связывания объектов потока (Flow Objects) с информацией. Объект потока может быть ассоциирован с текстовыми и графическими объектами, не являющимися объектами потока.
• Плавательные дорожки (Swimlanes). Эти элементы служат контейнерами для организаций, подразделений или ролей и состоят из:
• Пулов (Pool). Пул представляет участника процесса. Пул может содержать одну или более дорожек; он также может служить «дорожкой» и графическим контейнером для отделения набора активностей от других пулов, обычно в контексте ситуации B2B.
• Дорожек (Lanes). Дорожка – это вертикальное или горизонтальное деление внутри пула. Дорожки используются для организации и категоризации активностей (Activity).
• Артефакты (Artifacts). Артефакты позволяют добавить к диаграмме мета-данные и состоят из:
• Объектов данных (Data Objects). Объекты данных рассматриваются в качестве артефактов (Artifact), поскольку они не оказывают какого-либо прямого воздействия на потоки последовательности (Sequence Flow) или потоки сообщений (Message Flow), но предоставляют информацию о том, какие активности должны быть выполнены и что эти активности делают.
• Текстовых аннотаций (Text Annotations). Текстовые аннотации – это способ, которым автор может сообщить читателю диаграммы дополнительную информацию.
• Групп (Group). Группа - группировка активностей, которая не влияет на поток последовательности (Sequence Flow). Группировка может использоваться для целей документирования или анализа. Группы могут также использоваться для указания активностей распределенной транзакции, охватывающей больше одного пула (Pool).

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

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

Первая составная часть эволюции – это изолированные приложения (standalone applications), и в одну группу с этими приложениями я также поместил приложения для работы с изображениями/документами. Если мы посмотрим на основную направленность изолированных приложений, то это было определение последовательности событий, которые традиционно были либо ручными, либо специальными приложениями. Воздействие изолированных приложений было ограниченным определенным подразделением (functional silo) как следствие того, что такие приложения являлись точечными решениями. Возможности изолированных приложений в части отчетности были очень ограниченными, и в большинстве случаев приходилось ждать пакета отчетов в конце месяца, что приводило к очень замедленному решению проблем. Что касается способности менять и адаптировать процессы, то это занимало несколько недель, если не месяцев, так как требовалась разработка специфичного кода в соответствии с полным циклом разработки систем. С точки зрения архитектуры, отталкивающейся от модели (MDA, Model-Driven Architecture), изолированные приложения не обладали какими-либо возможностями моделирования и в силу этого были не способны реализовать MDA.

Вторая составляющая эволюции – workflow-приложения, в основном ориентированные на маршрутизацию работ. Она началась с приложений для управления изображениями и документами, в которых организации стали хранить все свои документы в электронном формате. Они быстро поняли, что им необходимо направлять эти документы к контролерам, лицам принимающим решения и т.д. По своему типу workflow-приложения были тесно связаны с интегрированными с ними приложениями, так как использовались частные API. Воздействие workflow-приложений на организацию было таким же, как и у изолированных приложений, так как эти решения по-прежнему ориентировались на подразделение. Возможности в части отчетности по-прежнему приводили к реакции на проблему пост-фактум, хотя возможности создавать отчеты в короткое время и улучшились. Способность workflow-приложений менять и адаптировать процессы по-прежнему измеряется неделями, так как специфический код должен быть разработан и протестирован в рамках жизненного цикла. С точки зрения MDA, workflow-приложения обладают некоторыми возможностями моделирования, однако по-прежнему для того, чтобы удовлетворить бизнес-требованиям, требуется значительный объем специфической разработки.

Завершающая составляющая эволюции – это BPM, который нацелен на процесс управления жизненным циклом – включая бизнес-процессы, эскалации, SLA и т.д. С точки зрения типа приложения, для интеграции с корпоративными приложениями и интеграции между предприятиями через веб-сервисы BPMS использует стандартные адаптеры. Воздействие на организацию – вдоль цепочки создания ценности и в масштабах предприятия, что гарантирует управление процессом от запуска до завершения. BPMS способен предоставлять панель управления и отчетность в реальном времени, что в итоге позволяет организации реагировать на проблемы с упреждением, теперь они могут устраняться как только возникла нештатная ситуация или ошибка в процессе. Это дает возможность выявлять, избегать или парировать проблемы до их появления. Способность BPMS изменять и адаптировать процессы очень высока и в большинстве случаев может выполняться в течении часов, если не минут. Моделирование бизнес-процессов – одна из основных составных частей BPMS, и почти все BPMS сделали выбор в пользу BPMN. Положив моделирование в основу, BPMS способны полноценно реализовать MDA.

Этим завершается наша технологическая эволюция и теперь, когда описаны и бизнес-, и технологические эволюции, пора обсудить недостающее звено и тот клей, который в действительности соединил вместе бизнес и технологию на данном цикле эволюции – архитектуре, отталкивающейся от модели (model driven architecture).

Рис. 3.

На рисунке 3 изображен континуум архитектуры, отталкивающейся от модели, и по мере того, как мы двигаемся слева направо, способность исполнения модели растет вместе со способностью автоматически генерировать код.

Начнем с левой части рисунка 3, стадии «только код» (code only); это обычно имело место во времена ассемблера и мэйнфреймов, когда в одном монолитном приложении писали страницы и страницы кода. Естественно это делало поддержку и доработку кода чрезвычайно сложной и привело к визуализации кода (code visualization) , когда код стали разбивать на модули или пакеты, и с ошибками кода стали разбираться при помощи диаграмм модулей.

Сейчас мы находимся на стадии «движения туда и обратно» (round-tripping), и удивительно, что почти 80 или 90 процентов организаций все еще находятся на этой стадии континуума. Они сначала посылают бизнес-аналитика, который моделирует бизнес-процесс, передают системному аналитику, который моделирует процесс в терминах технологии и наконец передают разработчику, который создает приложение, которое в большинстве случаев оказывается не на 100% корректным, так как рынок за прошедшее время мог измениться.

С изобретением workflow-приложений мы стали двигаться к моделе-центрической стадии и приобретать лучшее понимание концепции модели, в которой можно графически смоделировать процесс и фрагменты кода будут сгенерированы автоматически. Однако при этом удовлетворялись не все требования. В результате по-прежнему от 70 до 80 процентов приложения приходилось кастомизировать.

Завершающий этап континуума архитектуры, отталкивающейся от модели – это то, где сейчас находятся BPMS. Можно просто смоделировать процесс и получить автоматически сгенерированное заранее сконфигурированное приложение, тем самым устраняя эффект «движения туда-обратно» (round-tripping) и отвечать бизнес-требованиям на 80-90 процентов. По-прежнему необходимые 10-20 процентов кастомизации состоят из интеграции с существующими частными бизнес-приложениями.

Об авторе

Викеш консультировал все основные банки Южной Африки, страховую компанию, правительство и горнодобывающую компанию. Начав в области разработки, которая стала солидной основой для накопления знаний в области процессов, бизнес-анализа и управления процессов, в течение последних нескольких лет его интересы сместились в область BPM (Business Process Management) и ECM (Enterprise Content Management), где он работал с FileNet, Tibco/Staffware, Microsoft SharePoint portal и IBM Webspehere.

Комментарии