Содержание к диссертации
Введение
1. Сущность и проблемы процессного подхода к управлению предприятием 11
1.1. Анализ понятия «бизнес-процесс». Классификация бизнес-процессов 11
1.2. Анализ эволюции процессного подхода к управлению предприятием 15
1.3. Принципы организации и функционирования систем управления бизнес-процессами 20
1.4. Формальная схема управления динамичными бизнес-процессами 30
1.5. Проблемы внедрения процессного подхода на основе ВРМ-систем 37
Выводы по главе 1 39
2. Разработка методики построения схем бизнеспроцессов в ВРМ-системах на основе case-моделей 40
2.1. Преобразование моделей AllFusion Process Modeler в язык BPEL 44
2.2. Преобразование моделей ARIS в язык BPEL 65
2.3. Преобразование моделей AllFusion Process Modeler и ARIS в модели ВРМ-систем, ориентированных на потоки работ 81
2.4. Автоматизированное преобразование моделей бизнес-процессов 84
Выводы по главе 2 91
3. Метод процессного управления предприятием на основе ВРМ-системы 92
3.1. Этапы проекта внедрения ВРМ-системы и жизненный цикл разработки бизнес-процесса 93
3.2. Выбор бизнес-процессов для ВРМ-проекта 100
3.3. Анализ и проектирование бизнес-процессов при внедрении процессного управления на основе ВРМ-системы 106
3.4. Реализация бизнес-процессов в ВРМ-системе 113
3.5. Тестирование бизнес-процессов при внедрении процессного управления на основе ВРМ-системы 114
3.6. Алгоритм определения пути в BPEL-процессах 117
3.7. Внедрение и сопровождение бизнес-процессов, разработанных в ВРМ-системе 119
3.8. Методика процессного управления, включающего самообслуживание клиентов 121
3.9. Оценка трудоемкости внесения изменений в схему бизнес-процесса 124
Выводы по главе 3 127
4. Процессное управление сервисным центром на основе врм-систем Oracle bpel process manager и UNIFY NXJ 128
4.1. Анализ работы сервисного центра 128
4.2. Преобразование еЕРС-модели в ВРМ-систему Unify NXJ 135
4.3. Преобразование IDEFO-модели в язык BPEL 144
Выводы по главе 4 150
Заключение 151
Список использованных источников
- Анализ понятия «бизнес-процесс». Классификация бизнес-процессов
- Преобразование моделей AllFusion Process Modeler в язык BPEL
- Этапы проекта внедрения ВРМ-системы и жизненный цикл разработки бизнес-процесса
- Преобразование еЕРС-модели в ВРМ-систему Unify NXJ
Введение к работе
Актуальность проблемы. В условиях постоянно меняющихся внешней среды и внутренней структуры бизнеса однократная процедура реинжиниринга становится неприемлемым способом улучшения бизнес-процессов, т.к. его трудоемкость не позволяет быстро перестраивать работу предприятия в ответ на изменчивые требования рынка. Корпоративные информационные системы, внедряемые по результатам реинжиниринга, позволяют настроить любые бизнес-процессы, но последующие изменения в ходе эксплуатации зачастую требуют много времени, что сдерживает развитие бизнеса.
Второй проблемой, обуславливающей сложность внесения изменений в бизнес-процессы, является отсутствие интеграции разнородных приложений и информационных систем, поддерживающих деятельность предприятия. Задачу интеграции программных приложений решать чрезвычайно сложно, особенно с учетом того, что появляются дополнительные системы, решающие новые задачи бизнеса. Но даже удовлетворительная реализация интеграции, избавляющая от дублирования корпоративных данных, не решает проблему координации использования отдельных компонентов информационного пространства.
В-третьих, функции, выполняемые сотрудниками предприятия, по-прежнему оказываются формализованными только на уровне должностных инструкций и регламента процесса, являющихся обязательными элементами процессного подхода к управлению предприятием. При внесении любых изменений в эти документы необходимо уведомить и обучить сотрудников новому способу ведения дел. Для более качественного исполнения бизнес-процесса требуется назначение заданий персоналу в автоматическом режиме с использованием программно-аппаратных средств в соответствии с текущей схемой бизнес-процессов.
Четвертое препятствие на пути динамичного изменения бизнес-процессов предприятия заключается в различном понимании схемы процесса бизнес-аналитиками и программистами, решающими задачу автоматизации процесса. Соответственно это ведет к неадекватной реализации бизнес-процесса в программных системах.
В связи с этим возникла потребность в таких системах, которые позволяют решать указанные проблемы и корректировать существующие процессы в необходимом темпе. Так, на рубеже XX и XXI вв. появились концепция и технология Business Process Management (ВРМ) - управления бизнес-процессами. Если внутренние (локальные) системы функциональных подразделений поддерживают их работу в рамках функционального подхода к управлению предприятием, то ВРМ-система является инструментарием процессного управления, который по мере выполнения бизнес-процесса в соответствии с его моделью нужные функции поручает соответствующему подразделению или автоматизирующей его работу прикладной системе. Т.е., с точки зрения ВРМ, разработка бизнес-процесса заключается не только в создании его модели, но и конструировании интерфейсов к его функциям, шагам, а исполнение бизнес-процесса такой системой состоит в автоматизированной раздаче заданий сотрудникам и программам. При исполнении бизнес-процесса в ВРМ-системе на его модели отображается, на каком шаге он находится. Внедрение решения на основе ВРМ-системы позволит предприятию получить дополнительное конкурентное преимущество. Причем, как заявил аналитик из фирмы AMR Research Эрик Астволд, вопрос не в том, будет ли компания использовать технологию ВРМ, а в том, когда она сумеет сделать это [2].
Внедрение новой технологии ВРМ требует применения научно обоснованного подхода, методов, которые позволили бы максимально использовать накопленный на предприятии опыт по описанию и управлению бизнес-процессами.
Актуальность диссертационной работы определяется существующей сложностью в переходе на новый уровень в процессном управлении предприятием на основе систем управления бизнес-процессами (Business Process Management System, BPMS). Причем подобные трудности свойственны как предприятиям, ранее не описывавшим свои бизнес-процессы, так и достаточно зрелым организациям, четко следующим регламенту установленных процессов. Неотъемлемой частью такого перехода является разработка бизнес-процессов в ВРМ-системе.
Целью исследования является разработка метода процессного управления на основе ВРМ-систем, заключающегося в использовании построенных в процессе реинжиниринга моделей бизнес-процессов на базе известных CASE-средств и обеспечивающего формализованную разработку бизнес-процессов.
Для достижения поставленной цели необходимо решить следующие задачи:
1. Разработать схему управления бизнес-процессами, соответствующую современным требованиям динамичности изменения бизнес-среды предприятия.
2. Обосновать возможность управления бизнес-процессами с использованием ВРМ-систем на основе анализа сущности и эволюции процессного подхода, принципов организации и функционирования ВРМ-систем, прикладного системного анализа.
3. Разработать методику построения схем бизнес-процессов в ВРМ-системах на основе преобразования описаний бизнес-процессов, выполненных с использованием традиционных методологий, в исполняемые ВРМ-системой языки.
4. Разработать метод процессного управления предприятием с использованием ВРМ-системы на основе методологий моделирования и анализа бизнес-процессов, информационных технологий, технологий разработки программного обеспечения и методик преобразования, полученных на предыдущем этапе данной диссертационной работы.
5. Апробировать предлагаемый метод в реальных условиях действующего предприятия.
Научная новизна работы заключается в следующем:
1. Предложен и разработан новый метод процессного управления на основе ВРМ-систем, обеспечивающий использование существующего на предприятии задела в виде уже описанных бизнес-процессов и формализующий решение задач, связанных с этапами разработки приложений в ВРМ-системах.
2. Разработана методика построения схем бизнес-процессов в ВРМ-системах на основе CASE-моделей, позволяющая сократить стадию анализа и проектирования за счет исключения этапа обследования деятельности предприятия и формирования моделей бизнес-процессов в BPMS, соответствующих исходным CASE-моделям.
3. Предложен алгоритм автоматизированного преобразования CASE-моделей бизнес-процессов в ВРМ-модели на основе рекурсивной обработки XML-документов моделей и разработанных правил преобразования. Данный алгоритм позволяет ускорить разработку моделей в BPMS.
4. Предложена процедура выявления бизнес-процессов, совместимых с концепцией ВРМ, на основе сформулированных требований к процессам и их расширенной классификации.
5. Разработана методика процессного управления предприятием на основе BPMS, включающая элементы самообслуживания, обеспечивающая легкое ведение дел с компанией за счет выполнения клиентами некоторых операций в удобном для них месте (через веб-портал) и удобное время (в режиме 24/7).
6. Предложена модель оценки трудоемкости внесения изменений в схемы бизнес-процессов в ВРМ-системах, которая посредством выделения и анализа видов изменений показывает источники эффективности управления и совершенствования бизнес-процессов на основе BPMS по сравнению с управлением на основе традиционных корпоративных информационных систем.
Основные положения, выносимые на защиту:
1. Метод процессного управления предприятием на основе ВРМ-систем позволяет: использовать существующий на предприятии задел в описании бизнес-процессов; выбрать совместимые с концепцией ВРМ процессы; выбрать отвечающую требованиям ВРМ модель разработки бизнес-приложений; решать задачи этапов разработки бизнес-приложений на основе BPMS; получать первые работоспособные версии приложений бизнес-процессов в кратчайшие сроки.
2. Разработанная методика построения схем бизнес-процессов в ВРМ-системах на основе CASE-моделей позволяет получить ВРМ-модели бизнес-процессов, соответствующие исходным CASE-моделям, без повторного обследования деятельности предприятия и сократить стадию анализа и проектирования при разработке бизнес-приложения в BPMS.
3. Алгоритм автоматизированного преобразования моделей бизнес-процессов в системы ВРМ позволяет часть преобразования выполнить в автоматическом режиме посредством рекурсивной обработки XML-документов процессов.
4. Результаты применения разработанного метода показали его работоспособность и эффективность, в частности сокращение длительности получения первой версии бизнес-приложения, обеспечивающего исполнение бизнес-процесса, что отвечает требованиям управления бизнес-процессами динамически изменяющихся предприятий.
Практическая значимость. Разработанные метод, методики, алгоритмы и программная реализация представляют собой новый инструментарий разработки и внедрения на предприятии процессного управления на базе BPMS. Использование метода позволяет существенно сократить длительность разработки бизнес-приложения на базе BPMS и тем самым обеспечивает возможность своевременного управления бизнес-процессами.
Результаты диссертационной работы используются в учебном процессе при проведении лекционных и лабораторных занятий по курсу «Методы и средства управления бизнес-процессами».
Реализация результатов работы. Результаты работы были использованы при выполнении проекта внедрения системы управления бизнес-процессами ООО «Игрем», г. Томск, а также в проектах 000 «Бизнес-Консоль», г. Москва.
Апробация диссертационной работы. Результаты проведенного исследования отражены в научных статьях, тезисах. Основные положения диссертационной работы докладывались и обсуждались на следующих конференциях и симпозиумах:
? Международная научно-практическая конференция «Прогрессивные технологии развития», г. Тамбов, 2004 г.;
? 9-й Российско-корейский международный симпозиум по науке и технологии (KORUS-2005), г. Новосибирск, 2005 г.;
? 3-я Всероссийская научная конференция «Управление и информационные технологии (УИТ-2005)», г. Санкт-Петербург, 2005 г.;
? Международная научно-практическая конференция «Наука на рубеже тысячелетий», г. Тамбов, 2005 г.;
? IV и V Всероссийская научно-практическая конференция студентов, аспирантов и молодых ученых «Молодежь и современные информационные технологии», г. Томск, 2006 г., 2007 г.;
? XII и XIII Международная научно-практическая конференция студентов, аспирантов и молодых ученых «Современные техника и технологии», г. Томск, 2006 г., 2007 г.
Публикации. По теме диссертационной работы опубликовано 10 тезисов докладов и 2 статьи.
Методы исследования. Для решения поставленных задач в диссертационной работе использованы методы структурного анализа бизнес-процессов, прикладного системного анализа. Также в основу теоретических исследований легли некоторые положения из области методологии разработки программного обеспечения.
Структура и объем работы. Диссертационная работа состоит из введения, четырех глав, заключения, трех приложений. Основной текст изложен на 161 страницах, общий объем работы - 171 страниц. Диссертация включает 67 рисунков, 19 таблиц. Список использованной литературы содержит 130 источников.
Во введении обосновывается актуальность проблемы процессного управления на основе ВРМ-систем, формулируется цель исследования и его задачи, раскрываются элементы научной новизны и практическая значимость.
Первая глава диссертации посвящена анализу сущности процессного подхода к управлению предприятием и его проблем. Определены принципы организации и функционирования систем ВРМ. Показана формальная схема процесса управления динамичными бизнес-процессами.
Вторая глава содержит разработанную методику построения схем бизнес-процессов в ВРМ-системах на основе преобразования CASE-моделей, а также описание предложенного автором алгоритма автоматизированного преобразования.
В третьей главе сформулирован и разработан метод процессного управления предприятием на основе программных систем управления бизнес-процессами, который заключается в формализации этапов разработки бизнес-процессов в ВРМ-системе и решении задач, связанных с данными этапами, посредством разработки вспомогательных методик.
Четвертая глава посвящена использованию разработанного метода на примере реализации управления бизнес-процессом обслуживания клиентов сервисного центра в ВРМ-системах.
В заключении приведены основные научные и практические результаты, достигнутые в ходе диссертационного исследования и решения поставленных задач.
В приложения вынесены А) возможные связи между элементами диаграммы ARIS VACD, представленные в удобной табличной форме; Б) некоторые элементы реализации управления бизнес-процессом обслуживания клиентов сервисного центра, проиллюстрированные снимками с экранных форм BPMS и не вошедшие в основной материал; В) акт внедрения результатов диссертационной работы.
Анализ понятия «бизнес-процесс». Классификация бизнес-процессов
Сегодня для управления предприятием используется процессный подход, пришедший на смену функциональному и получивший широкое распространение в последние годы. Под процессным подходом понимают представление деятельности предприятия в виде сети взаимосвязанных и взаимодействующих процессов и управления процессами на основе цикла Деминга PDCA (Plan-Do-Check-Act) [3]. При таком подходе объектом управления является процесс, или бизнес-процесс, а моделирование деятельности предприятия осуществляется на основе моделирования его бизнес-процессов.
Бизнес-процесс определяется как логически завершенный набор взаимосвязанных и взаимодействующих видов деятельности, поддерживающий деятельность организации и реализующий ее политику, направленную на достижение поставленных целей. Стандарт ИСО 9000 [4], регламентирующий наличие, документируемость и измеряемость качества бизнес-процессов, определяет процесс как совокупность взаимосвязанных и взаимодействующих видов деятельности, преобразующих входы в выходы, представляющие ценность для потребителя. Процесс может выполняться в пределах одной организационной единицы, охватывать несколько единиц или даже несколько различных организаций [5, 6,7].
Хаммер М., один из известнейших в мире специалистов в области бизнеса, автор концепции реинжиниринга бизнес-процессов, дает такое определение:
Бизнес-процесс - это организованный комплекс взаимосвязанных действий, которые в совокупности дают ценный для клиента результат [8].
При этом каждое слово несет смысловую нагрузку: комплекс действий (а не одно); взаимосвязанность действий (нет лишних действий); организованность действий (есть организованная схема, которая предписывает, как все отдельные составляющие общей работы должны стыковаться воедино ради достижения итоговой цели, и обеспечивает повторяемость, предсказуемость и управляемость); совокупность действий (объединение общей целью, а не ориентация исключительно на свою операцию вне связи с остальными); ценный для клиента результат (выполнение действий не самоценно, а направленно именно на эту цель).
В [9, 10] сведено еще 13 определений бизнес-процесса различных специалистов. Но на взгляд автора данной диссертационной работы, приведенных определений достаточно, и они в полной мере отражают суть для поставленных целей.
Таким образом, важным шагом управления предприятием является структуризация его деятельности в терминах бизнес-процессов, т.е. выделение и классификация бизнес-процессов.
По отношению к получению добавленной ценности продукта или услуги выделяют следующие классы процессов [5, 11]: основные процессы (добавляющие ценность); обеспечивающие процессы (добавляющие стоимость).
Основные бизнес-процессы ориентированы на производство товаров или оказание услуг, составляющих основную деятельность организации и обеспечивающих получение дохода. Примерами таких процессов на предприятии являются процессы маркетинга, производства, хранения, поставки и сервисного обслуживания продукции.
Обеспечивающие бизнес-процессы не добавляют ценность продукта или услуги для потребителя, но увеличивают их стоимость. Они необходимы для деятельности предприятия и предназначены для поддержки выполнения основных бизнес-процессов. К таким процессам относятся управление персоналом, техническое обслуживание оборудования, бюджетное управление, административно-хозяйственная деятельность и др.
Бизнес-процессы можно также классифицировать по видам деятельности или составу работ [11]: планирование деятельности (например, планирование производства готовой продукции); осуществление деятельности - собственно выполнение работы (например, изготовление продукции); регистрация фактической информации по выполнению процесса (производственный, управленческий, бухгалтерский учет); контроль и анализ исполнения плановых показателей; принятие управленческих решений. Элементами этого процесса являются оперативное (ежедневное) управление - принятие решения по отклонениям и стратегическое управление - изменение планов и стратегии развития. Выходом данного процесса являются изменения в планах работы, решение о переподготовке персонала, изменения документации (положений, регламентов, должностных инструкций и т.д.), решения о покупке или продаже оборудования или даже целых направлений в бизнесе. Группа процессов управления является одной из самых сложных для описания вследствие трудностей формализации деятельности руководителей по принятию решений.
Перечисленные процессы связаны между собой входами и выходами, как показано на рисунке 1.1. Например, процесс контроля и анализа имеет входы от процессов планирования деятельности и регистрации фактической информации. Обработав информацию, полученную на входах, процесс контроля и анализа передает результат процессу принятия решений (например, отклонение факта от плана).
Преобразование моделей AllFusion Process Modeler в язык BPEL
Для формирования методики преобразования бизнес-процессов из AUFusion Process Modeler (ранее BPwin) в BPEL необходимо выделить характерные конструкции диаграмм BPwin и поставить им в соответствие конструкции BPEL. Поскольку BPwin поддерживает три методологии (IDEFO, DFD, IDEF3), необходимо рассмотреть преобразование из них отдельно.
Преобразование IDEFO-модели в язык BPEL Конструкциями диаграммы IDEF0 являются: блок (activity) - прямоугольник, содержащий имя и номер и используемый для описания функции, действия, этапа, шага; единица бизнес-процесса, элементарное действие, совершаемое его участникам или производимое автоматически программно-аппаратным обеспечением, направленное на достижение конечного результата бизнес-процесса [97]; декомпозиция (если действие не элементарное, выполняется его детализация); граничные стрелки; стрелки при простой передаче данных между блоками (функциями); слияние и ветвление стрелок; обратная связь; механизм и управление.
Блок BPwin, являющий собой в модели какое либо действие, в BPEL также будет действием, описанным с помощью какого-либо блока, в зависимости от контекста. В общем случае блок BPwin может быть преобразован в один из двух блоков BPEL: peopleActivity, если действие выполняется человеком (работником, партнером, клиентом), или invoke, если действие осуществляется веб-сервисом.
Процесс на контекстной диаграмме относится к организации в целом и включает в себя множество других процессов. Поскольку не все процессы выбираются для автоматизации, то нет необходимости описывать контекстную диаграмму средствами BPEL. С помощью средств ВРМ автоматизируются процессы, описываемые диаграммой-потомком для контекстной диаграммы, или их подпроцесссы, то есть диаграммы BPEL строятся для этих процессов. Все составляющие процесса BPEL заключаются в один объединяющий блок, называемый контейнером, в качестве которого могут выступать блок sequence или блок flow. При выборе контейнера рекомендуется придерживаться следующего правила: если процесс содержит много ветвлений и слияний, то в качестве контейнера процесса следует выбрать структуру flow; если процесс в основном прямой (последовательный), - sequence. Кроме того, необходимо учитывать особенности программных продуктов, в которых выполняется построение процессов. Например, Oracle BPEL Process Manager плохо поддерживает отображение связей links внутри flow.
Блок BPwin, подлежащий декомпозиции, детализируется на нижнем уровне иерархии несколькими блоками. Возможен последовательный, параллельный или комбинированный порядок выполнения блоков (шагов) на диаграмме-потомке. На диаграмме BPwin порядок отображается посредством стрелок, причем из контекста становится понятно, всегда ли существует тот или иной поток или в зависимости от каких-то условий.
Для описания нескольких, строго последовательных действий в BPEL существует элемент sequence. Он содержит в себе один или более блоков, выполняющихся в порядке упоминания. Sequence является аналогом операторных скобок в языках программирования. Использование блока sequence упрощает BPEL-поток путем группировки последовательно выполняемых функциональных структур и возможности свернуть их в один элемент.
Если два или несколько действий BPwin осуществляются одновременно, то на языке BPEL они должны быть заключены в структурный блок flow. Эта конструкция обеспечивает параллелизм и синхронизацию заключенных в ней шагов.
Sequence и flow - это контейнеры, состоящие из других вложенных блоков произвольной глубины. Например, на рисунке 2.5 показан свернутый блок sequence и его содержимое в развернутом виде.
Дополнительное поведение этих структур, как и других элементов BPEL, можно задать с помощью блока scope. Он содержит в себе единственный (первичный) блок, который описывает нормальное поведение процесса и может представлять собой сложную структуру с вложениями произвольной глубины, как то: sequence и flow. Введение scope, с одной стороны, позволит избежать необозримости диаграммы BPEL; с другой стороны, даст возможность ввести локальные переменные, обработчики событий, компенсаторы, корреляторы, обработчики ошибок.
Кроме того, возможно вынести диаграмму-потомка в отдельный процесс (который может быть как BPEL-процессом, так и процессом, построенным в соответствии со стандартами SOA [64], а также процессом, реализованным в приложении, обращение к которому выполняется посредством специального адаптера). Поскольку язык BPEL задуман для координации (оркестровки) веб-сервисов, то каждый из шагов бизнес-процесса, описанного в BPwin, можно представить в виде таких сервисов, а на BPEL возложить обращение к ним (их вызов). Тогда получается, что декомпозицию блока BPwin в BPEL можно реализовать путем " SOAP (Simple Object Access Protocol) для обмена данными между приложениями, WSDL (Web Services Description Language) для описания программных интерфейсов сервисов и UDDI (Universal Description Discovery & Integration) для хранения и получения WSDL-описаний. создания сервиса для диаграммы-потомка в виде BPEL-ироцесса, а для обращения в этому сервису в родительской BPEL-диаграмме необходимо добавить partnerLink, связанный с полученным процессом-сервисом, и блок его вызова invoke. Кроме того, важно определить, сколько времени выполняется сервис, т.к. от этого зависит, будет он синхронным или асинхронным.
Синхронный веб-сервис обеспечивает немедленный ответ на запрос. При этом для получения запроса и выдачи ответа используется одна и та же операция. Сервер BPEL позволяет задать максимальное время ожидания синхронного ответа, значение которого по умолчанию составляет 60 секунд. Если за это время ответ не получен, происходит отказ. Асинхронный способ обмена сообщениями применяется, когда, например, сервис может потребовать длительного времени обработки заявки клиента (от нескольких минут до нескольких дней). При этом для получения запроса и выдачи ответа используются разные однонаправленные операции. Асинхронный сервис обеспечивает более надежную, отказоустойчивую и масштабируемую архитектуру.
Этапы проекта внедрения ВРМ-системы и жизненный цикл разработки бизнес-процесса
На основе накопленного опыта продвижения и внедрения ВРМ специалисты выделили три фазы внедрения ВРМ на предприятии [106, 107]:
1. Доказательство концепции (Proof of a Concept) - поставщик демонстрирует работоспособность ВРМ на условном или реальном процессе.
2. Пилотный проект (Pilot) - поставщик и заказчик совместно реализуют управление реальным процессом. Попутно заказчик с помощью исполнителя создает центр компетенции ВРМ. Центр компетенции ВРМ - это человек или группа людей, которые знакомы с бизнес-процессами предприятия и в то же время являющиеся опытными пользователями ВРМ-системы. Но в то же время, по мнению Gartner, во многих компаниях ИТ-подразделення эволюционируют в центры компетенции ВРМ [93]. Таким образом, идеальным кандидатом для работы в центре компетенции ВРМ является бизнес-специалист, имеющий навыки в сфере разработки ПО.
3. Продуцирование (Production) - заказчик раздвигает сферу применения ВРМ (вглубь: новые версии процесса, вширь: новые процессы).
Следует отметить, что первая фаза может не включать в себя непосредственной разработки бизнес-процесса, т.е. разрабатываемый метод затрагивает только вторую и третью фазы внедрения ВРМ. Метод может быть полезен как поставщикам ВРМ на этапе пилотного проекта, так и сотрудникам центра компетенции ВРМ на этапе Production при продвижении вширь.
В настоящее время доказательство концепции (Proof of a Concept) выполняется не только непосредственно при контакте предприятия и поставщика, но также проводятся конференции, семинары, посвященные процессному управлению и подходу к его реализации с помощью BPMS, с участием специалистов, имеющих опыт внедрения ВРМ, и предприятий, использующих ВРМ в своей деятельности. В последствии, когда руководители предприятий будут достаточно компетентны в этих вопросах, можно ожидать, что необходимость в первой фазе отпадет.
Необходимо отметить, что те же специалисты настоятельно рекомендуют не относиться к внедрению ВРМ как к традиционному ИТ-проекту. Основная причина заключаются в том, что нет такой точки, когда можно сказать, что бизнес-процесс реализован, и закрыть проект, т.к. ВРМ подразумевает постоянное внесение изменений. Кроме того, появляется потребность в реализации все новых процессов средствами ВРМ. Отсутствие методов, регламентирующих процедуры разработки процессов в ВРМ-системах, ведет к неудовлетворительной деятельности центров компетенции, что соответствует невысокому уровню зрелости в соответствии с моделью зрелости процессов разработки ПО (Capability Maturity Model, СММ) [108].
В рамках предлагаемого метода процессного управления на основе BPMS формализация разработки бизнес-процесса определяет следующие этапы: анализ и проектирование бизнес-процесса, реализация бизнес-процесса в ВРМ-системе, тестирование и отладка, внедрение и сопровождение бизнес-процесса, разработанного в ВРМ-системе.
Аналогия с этапами разработки ПО обусловлена следующим. Схема бизнес-процесса в ВРМ-системе кроме графического представления имеет вид кода на языке программирования (например, BPEL) и время от времени требует работы непосредственно с кодом, а не только с диаграммой. Поэтому при внедрении ВРМ полезно использовать практики, применяющиеся в технологии разработки программного обеспечения. В связи с этим необходимо выполнить анализ существующих методов разработки ПО, понять, насколько они совместимы с концепцией ВРМ и смогут ли обеспечить разработку ВРМ-процессов. Если имеющиеся методы окажутся неприемлемыми, требуется выбрать наиболее подходящие и выполнить их модификацию либо (если последнее окажется затруднительно или нерационально) разработать новые методы.
Последовательность предлагаемых этапов разработки образует жизненный цикл бизнес-процесса. В программной инженерии определены различные модели жизненного цикла [109, 110], Это классическая модель (синонимы - каскадная, водопадная), инкрементная, модель быстрой разработки приложений (Rapid Application Development, RAD), спиральная, модель Microsoft Solutions Framework (MSF), унифицированный процесс (Unified Software Development Process, USDP), экстремальное программирование (eXtreme Programming, XP).
Очевидно, что водопадная модель является наиболее неподходящей для разработки бизнес-процессов, т.к. однократный проход не предусматривает внесение изменений в схему процесса.
Инкрементная модель в результате каждого прохода дает поставляемый инкремент - рабочий продукт, который постепенно наращивает функциональность, при этом все требования должны быть определены в начале разработки. Но в управлении бизнес-процессами условия постоянно меняются, а концепция ВРМ как раз и предназначена для реализации этих изменений, что позволило упростить процедуру анализа требований, т.к. требования не критичны для успеха ВРМ-проекта. Таким образом, необходимость описания всех требований к бизнес-процессу в начале проекта несовместима с концепцией ВРМ. Значит, инкрементная модель не может быть использована при разработке ВРМ-процесса.
Модель быстрой разработки приложений RAD также основана на инкрементной стратегии разработки ПО. В этой модели интерес представляет такой отдельно выделенный этап как бизнес-моделирование, заключающийся в моделировании информационного потока между бизнес-функциями. Также RAD предполагает повторное использование компонент, в качестве которых с точки зрения ВРМ могут выступать веб-сервисы. Но, как и любая инкрементная модель, RAD требует полного определения требований. Поэтому данная модель не может быть использована для разработки ВРМ-процессов.
В настоящее время для разработки ПО все чаще используются облегченные (lightweight), или гибкие (agile), технологии. В частности, при использовании гибкого моделирования, определяется разумный объем моделирования, когда его достаточно для того, чтобы изучить и документировать систему, но не настолько много, чтобы тяжесть моделей замедлила развитие проекта. [111] Очевидно, что при разработке бизнес-процесса, должны использоваться облегченные процессы. Причем, сама концепция ВРМ, поддерживаемая BPMS, регулирует эти требования: модель, созданная в BPMS, всегда будет соответствовать необходимому оптимуму. Также при разработке ВРМ-процессов находят применение и другие гибкие методики. Например, методика «Активное использование заинтересованных лиц» воплощается в жизнь за счет того, что предприятие само должно разрабатывать свои бизнес-процессы с помощью собственного центра компетенции. Исключением является этап пилотного проекта, но и там необходимо активное участие самого предприятия.
Преобразование еЕРС-модели в ВРМ-систему Unify NXJ
Поскольку события в данной модели отражают статусы заказа, то согласно методике преобразования, каждое событие - есть факт добавления данных в заказ, связанный с экземпляром бизнес-процесса. Теперь следует указать, какие операнды будут видны исполнителям на каждом из шагов бизнес-процесса. Т.к. данные заказа связаны с каждым шагом процесса, то в самом простом случае, на начальной итерации разработки бизнес-процесса, можно ограничиться тем, что все операнды будут доступны на каждом шаге бизнес-процесса, но будут заполняться исполнителями по мере необходимости. Следует сгруппировать операнды по наборам «Данные клиента», «Данные об устройстве», «Данные заказа». Потом можно сделать доступными только те поля, которые содержат необходимую на конкретном шаге бизнес-процесса информацию (только для чтения) и которые на этом шаге требуется заполнить исполнителем.
Дополнительно можно перенести описание Description из AR1S в Description и instructions системы Unify NXJ для шагов бизнес-процесса, чтобы проинструктировать исполнителя. Таким образом, модель бизнес-процесса в Unify NXJ, полученная в результате преобразования из модели еЕРС, выглядит следующим образом (рисунок 4.9). Данную модель можно загрузить на сервер и запустить на исполнение движком ВРМ-системы, инициируя экземпляр бизнес-процесса. При этом будут создаваться автоматические формы для исполнителей (например, рисунок 4.10).
В соответствии с предложенным методом это была первая итерация на фазе проектирования, где в большей степени задействованы рабочие процессы анализа и проектирования.
Первым же улучшением полученного бизнес-процесса может стать уведомление клиента об отказе в ремонте и окончании ремонта по электронной почте. Тогда требуется внести следующие изменения: создать операнд «Email», добавить его к данным клиента, установить действие SendNotificationByOperand на событие ProcessFinished для соответствующих функций процесса.
На следующей итерации предлагается применить методику процессного управления, включающего самообслуживание клиентов (раздел 3.8). В построенные модели клиент вовлечен пассивно. Но нередко бывает, что менеджер среди прочих дел вовремя не позвонит клиенту с уведомлением о результатах диагностики или об окончании ремонта. К тому же в модели отсутствует шаг, связанный с последним уведомлением. Предполагается, что дата, указанная в операнде «срок» (исполнения заказа), будет точно соблюдена. Иначе клиенту самому придется дозваниваться, узнавать о состоянии своего заказа. В таком случае и рекомендуется использовать методику процессного управления, включающего самообслуживание клиентов.
В данном случае инициация экземпляра бизнес-процесса клиентом не требуется, т.к. клиент все равно должен прийти в СЦ, чтобы принести неисправное устройство. Но это было бы приемлемо, если бы СЦ занимался выездным ремонтом крупной техники на объектах клиентов. Согласно методике самообслуживания клиентов, после диагностики необходимо уведомить клиента о ее результатах и условиях ремонта с тем, чтобы он принял решение о дальнейших действиях. В данном случае следует заменить исполнителя шага «Согласовать условия ремонта с клиентом» с Менеджера на самого клиента. Тогда, поскольку задание будет поручаться клиенту, шаг следует переименовать в «Рассмотреть условия ремонта». Кроме того, как рекомендуется в методике раздела 3.8, можно добавить шаг «Посмотреть состояние заказа», который будет всегда активен и позволит клиенту отслеживать состояние своего заказа (рисунок 4.11).
Чтобы задание поручалось именно одному конкретному клиенту, аутентификация должна быть настроена через базу данных, в которую при инициации бизнес-процесса добавляется новый пользователь - клиент. Это может быть реализовано, согласно USDP, на следующей итерации на фазе построения, где основной рабочий процесс - реализация. Кроме того, еще одна итерация фазы построения должна быть посвящена разработке интерфейсных форм вместо создаваемых автоматически, предусматривающей копирование и извлечение информации из базы данных.
Итак, рекомендуемая последовательность преобразования еЕРС - ВРМ (II2M): функции; исполнители; события; логические операторы; входы/выходы. Итак, показано, как методика преобразования ARIS - ВРМ позволяет трансформировать модели бизнес-процессов в ВРМ-систему и на этой основе создавать работающий бизнес-процесс. Некоторые другие моменты работы в ВРМ-системе Unify NXJ, соответствующие контуру управления бизнес-процессами, раскрыты в приложении Б. Таким образом, метод процессного управления на основе ВРМ-системы позволяет автоматизировать и улучшить бизнес-процесс, делая его производительнее и прозрачнее для клиента, что увеличивает конкурентоспособность предприятия.
Задание исполнителю на языке BPEL состоит из блока people Activity (или Human Task), который представляет собой контейнер, включающий блоки assign, invoke, receive с соответствующим partnerLink, связанным с сервисом заданий.
Как уже сказано выше, устройство (неисправное, отремонтированное), бумажная квитанция являются материальными объектами и не преобразуются в ВРМ. Стрелки-управление, стрелки-механизмы, показывающие, с помощью чего выполняются функции процесса (информационная система, инструменты, телефон, электронная почта), также не преобразуются.
Согласно методике, приведенной в разделе 2.1, поток данных, ведущий от границы диаграммы к блоку в комплексе с самим этим блоком («Принять заказ на ремонт») в данном случае преобразуется в блок receive с соответствующим partnerLink. Остальные блоки IDEF0 в данном случае преобразуются в задания с помощью контейнера Human Task (рисунок 4.12).
