Проектирование бизнес-процессов: регламентация потоков работ (Workflow)

Лекция: Проектирование бизнес-процессов: регламентация потоков работ (Workflow) Лекция по курсу «Моделирование бизнес-процессов» Цели моделирования бизнеспроцессов  Описание и регламентация бизнес-процессов (БП) – построение регламентов (корпоративных правил) выполнения бизнеспроцесса  Анализ БП – поиск оптимальной схемы функционирования бизнес-процессов  Автоматизация БП:   разработка КИС – цель: наладить оптимальное информационное взаимодействие между участниками БП построение BPMS – цель: построение автоматизированной СУБП Проектирование бизнеспроцесса (БП)  Проектирование БП – это выработка правил выполнения БП и системы показателей, определяющих его эффективность  Проектирование БП включает в себя:      определение управленческих, материальных и информационных потоков работ, установление правил принятия решений в БП установление правил обработки исключительных ситуаций в БП (эскалации, возможность изменения стандартного поведения, оптимизация загрузки персонала – ручная и автоматическая и т.п.) разработка системы показателей эффективности БП и нормативов выполнения БП предварительный анализ эффективности бизнеспроцесса на основе моделей БП Задачи проектирования бизнеспроцессов  Регламентация бизнес-процесса  Предварительный анализ эффективности бизнес-процесса  Оценка и принятие решения о внедрении бизнес-процесса Методы регламентации бизнеспроцессов  Слабо формализованные:   Текстовое описание Табличное описание  Строго формализованные:   Моделирование бизнес-процессов Построение бизнес-правил Задачи регламентации деятельности  упорядочивание процесса:  установление правил того, что и как мы будем делать  унификация процесса:    внедрение единых подходов к выполнению работы в различных подразделениях, занятых схожей работой облегчает управление оптимизирует взаимодействие между подразделениями Эволюция регламентов: от простого к сложному  1-й уровень. Текстовые регламенты  2-й уровень. Графические схемы на основе структурного и системного подхода (статические модели)  3-й уровень. Исполняемая модель (в BPM-системах) Текстовые регламенты  традиционная форма – быстрая разработка  слабая формализация  крайне затруднена или невозможна семантическая верификация  крайне затруднен поиск полезной информации  затруднен анализ и обновление регламента Табличные регламенты  модификация текстовых регламентов  более формализован  затруднен контроль целостности при разработке Модели (схемы) бизнеспроцессов  контроль семантической целостности – естественная часть разработки  поиск информации соответствует структуре процесса  анализ и обновление регламента на основе структурного подхода Бизнес-правила  формализация принятия решений в бизнес-процессе:   в точках разветвления процесса (например, при определенных условиях необходима дополнительная проверка кредитора) при нештатных ситуациях в процессе (например, что делать, если в течении процесса заказ был аннулирован или он «завис» у какого-либо сотрудника) Слабо формализованная регламентация  Текст «Отдел продаж отвечает за проверку кредитоспособности клиента»  Таблица Функция Орг. единица Проверка кредитоспособности Отдел продаж Отношение Отвечает Строго формализованная регламентация  Модель Проверка Кредитоспособности Отвечает Отдел продаж  Бизнес-правило ЕСЛИ: Сумма кредита > 1 000 000 р. ТО: Выполнять доп. проверку Модели потоков работ  в отличии от моделей информационных потоков (IDEF0) в основе имеют поток управления, показывающий последовательность выполнения работ (activity), а не поток информации (материалов), переходящий от работы к работе  например, блок-схема, цепочка добавленной стоимости, EPC, IDEF3 и т.п.  позволяют наиболее естественным образом описывать процесс и потому особенно подходят для регламентации Описание потока работ бизнес-процесса  описания (модели) процесса должны содержать:  последовательность выполняемых операций,  ответственность за выполнение операций,  информационные и материальные потоки процесса, Модели потоков работ в ARIS  Цепочка добавленной стоимости/ценности (Value-Added Chain),  Цепочка процесса, управляемая событиями (Event-driven Chain, EPC),  Офисный процесс (Office process),  Процессная цепочка (Process Chain Diagram, PCD),  Диаграмма BPMN Цепочка добавленной стоимости Процесс 1 Процесс 2 Процесс 3  определяет логическую последовательность процессов, выполняемых при создании продукта или услуги (добавленной ценности, стоимости) для клиента  цель: выявить максимальное количество производительных процессов Цепочка процесса, управляемая событиями (EPC)  Event-driven Process Chain (EPC) – нотация моделирования, созданная проф. А.-В. Шеером в рамках методологии ARIS, как средство более точной идентификации бизнес-логики процесса  отличительная особенность – определение потока работ на основе событий, возникающих во время выполнения процесса  основная логика цепочки: происходящие события вызывают выполнение определенных действий (функций) процесса, что в свою очередь приводит к возникновению новых событий Пример EPC Правила построения EPC (1)  Цепочка EPC формируется путем чередования событий и функций – происходящие события вызывают выполнение функций, что приводит к возникновению новых событий  например, событие «Клиент обратился в фирму» приводит к выполнению сотрудниками фирмы функции «Консультирование клиента», результатом чего является возникновение события «Клиент сформировал требования к компьютеру»  Цепочка EPC всегда начинается и заканчивается событиями Правила построения EPC (2)  Каждое событие может иметь не более одного, а функция – обязательно по одному входному/выходному потоку управления. Поэтому для обозначения альтернативных и/или параллельных потоков на развилках и слияниях потока работ должны использоваться знаки бизнес-логики (правила):    - логическое «И» для обозначения параллельных потоков, - логческое «исключающее ИЛИ» для обозначения альтернативных потоков другие логические операции Правила построения EPC (3)  На альтернативных развилках перед значком «искл. ИЛИ» всегда должна стоять функция, а после – альтернативные события. При слиянии наоборот – до «искл. ИЛИ» стоят альтернативные события, после стоит функция. Окружение функции  определяет исполнителя функции и входные/выходные информационные сущности (носители): Заказ клиента Менеджер по продажам Начальник отдела продаж Оформление плана-графика accepts План-график Правила построения EPC (4)  За каждой функцией должен быть закреплен ответственный исполнитель (тип связи – «выполняет»), и такой исполнитель должен быть только один для функции.  Остальные типы связей между функцией и оргединицей могут быть использованы нелимитированно. Заказ клиента Менеджер по продажам Начальник отдела продаж Оформление плана-графика accepts План-график Полная модель EPC Обратился клиент Прайс-лист Выбор конфигурац ии клиентом Менеджер по продажам Заявка клиента Клиент выбрал конфигур... Проверка выполнимости заявки клиента Поступили комплектующ ие по отложенной... Заявка невыполни ма Заявка выполнима Менеджер по продажам Заявка клиента Менеджер по продажам Оформление заказа Заказ оформлен Клиент изменил заявку под имеющиеся... Заказ клиента Согласовани е заявки с клиентом Клиент согласился ожидать комплектую... Рабочий день окончен Менеджер по продажам принимает Начальник отдела продаж Менеджер по продажам Начальник отдела продаж Оформление планаграфика План-график оформлен Заявка клиента Оформление заявки на докупку комплектующих Заявка оформлена Заказ клиента принимает Клиент отказался от заказа Планграфик Заявка на закупку