Система управления бизнес процессами диссертация

Все ресурсы в архиве электронных ресурсов защищены авторским правом, все права сохранены.

Наблюдателя интересует, что делает система,при этом он абстрагируется от её внутреннего устройства и от деталей реализации, рассматривает отношения системы как целого с объектами среды, лежащими вне её. По мнению Ю.Г.Маркова, «функцией системы можно назвать все то, что можно узнать о системе, не касаясь еёвнутреннего содержания, абстрагируясь от него» [71].

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

В функциональноориентированной ИТ системе исполнитель играет активную роль — определяет порядок выполнения функций, а система играет вспомогательную — автоматизирует необходимые операции. Если какой-либо сценарий исполнения не был выявлен при проектировании информаци-74онной системы, то исполнитель может подправить ситуацию. Как следствие, пользователь должен держать в голове все сценарии исполнения процесса, так что работа в такой системе требует подготовки и обучения.Таким образом, при проектировании функционально-ориентированной информационнойсистемы критично выявить все её функции, однако не столь важно, если не будут выявлены всесценарии исполнения процесса.

Соответственно, проектирование функционально ориентированной системы требует меньших временных затрат.Системы, базирующиеся на процессахОпределим информационную систему, базирующуюся на процессах (process aware), каксистему, при проектировании которой использовалась модель бизнес-процессов [82]. Например, внедрение большинства систем управления ресурсами предприятия (ERP) начинается смоделирования процессов, но можно ли говорить, что эти ERP-системы создавались для реализации процессного подхода? В подобной ситуации моделирование, как правило, производитсяоднократно для целей написания технического задания, схема быстро теряет актуальность. Изменить схему процесса, единожды заложенную в такую систему, становится затруднительно.Процессно-ориентированные системыПроцессно-ориентированные системы (process oriented), организуют взаимодействиеучастников друг с другом и с информационными системами таким образом, что задания, включающие информацию и документы, передаются между участниками (людьми и системами) всоответствии с формализованными процедурными правилами [27].

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

Процессно-ориентированные системынацелены на получение синергетического эффекта от скоординированных действий организационных единиц компании. Можно говорить, что процессно-ориентированные системы создаются для реализации процессного подхода.Системы, управляемые модельюМоделью бизнес-процесса называется формализованное (графическое, табличное, тексто-75вое, символьное) описание, отражающее реально существующую или предполагаемую деятельность предприятия [83]. Это шаблон, на основании которого в системе создаются экземплярыбизнес-процесса. Нотация (язык моделирования) – есть система условных обозначений, принятая в моделях конкретного типа.

Таким образом, модель можно рассматривать как совокупность символов (принадлежащих к нотации), адекватно описывающих работы, образующиепроцесс и отношения между ними.Исследователи и разработчики программного обеспечения давно стремятся создавать абстракции, помогающие разрабатывать информационные системы в терминах целей своего проекта, а не используемой компьютерной среды [84]. Вначале, создавались языки программирования, скрывающие детали операционных систем, сейчас речь идёт о разработке бизнес приложений в терминах понятий предметной области.

Таким образом, разработчик оказывается защищён от сложностей компьютерной среды, сокращается объем ручного труда на кодирование,отладку и перенос программ. Компьютерные системы, разработка которых ведётся в терминахпредметной области, которая подвергается автоматизации, называются моделеориентированными (model driven) [85].Исполняемая модель бизнес-процессаИсполняемая модель бизнес-процесса – это предметно-ориентированное описание участников процесса: людей и машин, а также порядка и времени выполнения ими операций и действий, которое может быть использовано для автоматизации взаимодействия участников друг сдругом и машинами без дополнительного кодирования и программирования.Исполняемая модель описывает динамику поведения организационной системы. Можнопредположить, что она существенно сложнее, объёмнее, чем диаграмма бизнес-процесса, используемая с целью аналитического описания бизнес-процесса.

Исполняемая модель процессавключает несколько проекций (слоёв), каждый из которых описывает отдельные аспекты организационной системы, а все вместе они описывают динамику её поведения.Моделеориентированная разработка ИТ систем на основе СУБПСуть моделеориентированной разработки процессно-ориентированных систем заключается в том, что непосредственно из визуальной, графической модели бизнес процесса, созданной в стандартной для отрасли нотации моделирования бизнес-процессов BPMN, генерируетсяисполняемый программный код. Благодаря тому, что за основу берётся визуальная модель бизнес процесса, центр тяжести в разработке перемещается с программиста на бизнес аналитика.При необходимости внести изменения в порядок исполнения бизнес процесса, соответствующие коррекции проводятся аналитиком непосредственно в модели процесса.

Таким образом,76бизнес-аналитик получает средство для разработки системы автоматизации бизнес-процессов,которое потребует минимального привлечения программистов.Системы управления бизнес-процессов реализуют т.н. замкнутый цикл разработки иадаптации бизнес-процесса к изменениям внешних условий, включающий следующие стадии,показанные на рисунке 2.6:­Моделирование бизнес-процессов в графической нотации BPMN;­Исполнение бизнес-процессов, сбор статистики периода исполнения;­Анализ статистики периода исполнение;­Изменение в исходной модели бизнес-процессов с целью его оптимизации.МОДЕЛИРОВАНИЕИСПОЛНЕНИЕBPMBPMИЗМЕНЕНИЕМОДЕЛИBPMАНАЛИЗРисунок 2.6 — Замкнутый цикл разработки БПИсточник: составлено автором.Среда СУБП позволяет собрать полную статистику периода выполнения бизнес процесса,измерить реальные значения ключевых показателей эффективности. Благодаря этому, решениеоб изменении процесса принимается на стадии анализа с учётом реально измеренных показателей.

Если изменение, вносимое в модель, привело к улучшению показателей, то они закрепляются в модели. Но, если изменение не может доказать свои преимущества, то от него можноотказаться. Таким образом, в модели закрепляются только те изменения, которые могут напрактике доказать свою эффективность.Благодаря замкнутому циклу МоделированиеИсполнениеАнализ Моделирование,СУБП реализуют новую парадигму разработки информационных систем — на смену длинномуциклу разработки приходит короткий и замкнутый цикл. Традиционно разработка ИТ системвключает следующие этапы, показанные на рисунке 2.7:­Анализ исходных данных­Описание бизнес-процессов организации «как есть»;77­Реинжиниринг процессов, создание модели «как должно быть»;­Подготовка тех-задания­Разработка — кодирование задачи;­Тестирование, выявление ошибок, отладка программы­Внедрение и эксплуатацияРисунок 2.7 — Традиционный «длинный» цикл разработки ИТ приложенийИсточник: составлено автором.Из практики известно, что подобный цикл имеет большую длительность — нередко проектирование и разработка затягиваются на долгие месяцы или годы.

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

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

Многие заказчики задают вопрос,зачем вообще моделировать процессы, если модели очень скоро перестают быть актуальными.В случае применения СУБП используется короткий и замкнутый цикл разработки, как показанона рисунке 2.8. Поскольку от разработки модели до её тестирования проходит мало времени,становится возможным взять за основу модель «как есть». Затем в несколько итераций, путёмнебольших изменений перейти к модели «как должно быть».BPMBPMBPMДолжностныеинструкцииНачалоРазработкапрототипа3-4 недели1-я итерация2-3 неделиBPMBPMBPMBPMBPM2-я итерация2-3 неделиBPM3-я итерация2-3 неделиРисунок 2.8 — Короткий — замкнутый цикл разработки с использованием СУБПИсточник: составлено автором.78Поскольку изменения в модель «как есть» вносятся на основе анализа объективных результатов работы текущей схемы бизнес-процесса, уменьшается зависимость результата от квалификации и опыта консультанта, т.е., улучшения бизнес-процессов носят более объективныйхарактер.

Изменения вносятся в модель, а не в программный код, поэтому модель не теряет актуальности. Эта новая парадигма разработки в точности отражает и поддерживает один из основополагающих принципов процессного управления — Постоянное Улучшение Процесса(Continuous Process Improvement).

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

Ксожалению, текстовая форма описания процессов лишена подобной наглядности, поэтому зачастую содержит неточности, разрывы и несогласованности. Разработка с использованием СУБПблизка по подходам современной методологии экстремального программирования. Обоим присущи следующие особенности:–Короткий цикл обратной связи;–Разработка через тестирование;–Игра в планирование;–Заказчик всегда рядом;–Непрерывный, а не пакетный процесс;–Непрерывная интеграция;–Частые небольшие релизы;–СУБП предлагает ИТ следующие преимущества:–Устраняется разрыв между моделью бизнес процесса и её ИТ реализацией;–Развитие информационных систем выполняется силами экспертов по бизнесу;–Сокращается объем программируемых модулей;Выбор процесса для реализации в СУБПВо многих проектах, где предполагается создание СУБП, постановкой задачи объявляетсяавтоматизация работы какого-либо департамента.

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