Моделирование бизнеспроцессов Бабенко В. В. © 2013, bvv
• Вопросы курса: 1. Чем процессный подход в управлении может помочь менеджеру? 2. Терминологическая основа моделирования БП. 3. Как можно смоделировать бизнеспроцессы – основные нотации и методологии? 4. Какие программные продукты можно и нужно использовать при моделировании бизнес-процессов?
• Основные положения андрагогики: 1. взрослому человеку, который обучается, — обучающемуся (а не обучаемому) принадлежит ведущая роль в процессе обучения (Главный – учащийся!); 2. он, являясь сформировавшейся личностью, ставит перед собой конкретные цели обучения, стремится к самоуправлению (Управляет – учащийся!); 3. взрослый человек обладает профессиональным и жизненным опытом, знаниями, умениями, навыками, которые должны быть использованы в процессе обучения (Новое – отталкиваясь от уже известного!); 4. взрослый ищет скорейшего применения полученным при обучении знаниям и умениям (В новых знаниях ищи практическую ценность!); 5. процесс обучения в значительной степени определяется временными, пространственными, бытовыми, профессиональными, социальными факторами, которые либо ограничивают, либо способствуют ему (Время можешь спланировать только ты!); 6. процесс обучения организован в виде совместной деятельности обучающегося и обучающего на всех его этапах (Результат дает только активное взаимодействие!).
• Литература: • Елиферов В. Г. , Репин В. В. Бизнес-процессы: Регламентация и управление. – М. : ИНФРА-М, 2005 • • Буч Г. , Рамбо Д. , Джекобсон А. Язык UML: руководство пользователя. – М. : ДМК, 2000. Бабич А. В. Введение в UML. – Электронный ресурс. Режим доступа: http: //www. intuit. ru/department/se/intuml (07. 01. 10) Андерсен Бьёрн. Бизнес-процессы. Инструменты совершенствования / - М. : РИА «Стандарты и качество» , 2003. - 272 с. Хаммер Х. , Чампи Д. Реинжиниринг корпорации. Манифест революции в бизнесе. Робсон М. , Уллах Ф. Практическое руководство по реинжинирингу бизнес-процессов/Пер. с англ. — М. : Аудит, ЮНИТИ, 1997. - 224 с. Марка Д. А. , Мак. Гоуэн К. SADT — методология структурного анализа и проектирования. - М. : Метатехнология, 1993 Лемке Дж. Microsoft Office Visio 2003 Официальный учебный курс / М. Эком, 2006 Бабенко В. В. Практический анализ бизнес-процессов. Сборник задач и упражнений. – Сыктывкар, 2010
В чем польза моделирования БП: 1. Работа над моделью позволяет лучше узнать процесс 2. Модели в разных нотациях позволяют провести анализ с разными целевыми установками 3. Модели БП позволяют сформировать общее видение задач в команде и упрощают диалог «заказчик - исполнитель» 4. Большинство нотаций стандартизировано, то есть, специалистам все понятно без дополнительных комментариев
• Вопросы, которые интересуют пользователей при моделировании бизнес-процессов
Чего следует остерегаться: • Создание моделей ради моделей – глупое украшательство! • Модели БП не должны быть излишне сложными. Главная цель любого моделирования – абстрагирование от несущественных деталей. • Не следует добиваться «самой правильной модели» - процесс описания БП очень субъективен. Главный критерий качества – выразительность и информативность.
• 7 «золотых» правил моделирования БП: 1. Составляйте, уточняйте, подтверждайте схемы вместе с «владельцами» / «участниками» бизнес-процессов. 2. Используйте визуальные подходы описания бизнес-процессов, способствующие повышению эффективности работы в группе. 3. Используйте язык, понятный «владельцам» / «участникам» бизнес-процесса. 4. Создавайте схемы деятельности, а не организационных структур 5. Избегайте излишней детализации бизнеспроцессов, особенно на схеме «как есть» . 6. Избегайте составления схемы бизнеспроцесса ради схемы, не ведущей к дальнейшему анализу и действиям. 7. Не смешивайте понятия «как есть» , «как должно быть» , «как будет» .
Процессный подход • Бизнес-процесс - набор связанных процедур, направленных на достижение определенного результата. • Аксиома: Любую осмысленную деятельность (в том числе управленческую) можно представить в виде набора бизнес-процессов. • БП – отражение системности природных и социальных объектов • Процессный подход используется: – В менеджменте (методология BPR) – В управлении качеством (TQM) – В программно-компьютерном моделировании управленческих методов
• Система бизнес-процессов редко хорошо соответствует организационной структуре. • Если соответствие – это процессная организация бизнеса, в противном случае функциональная
• Бизнес-процессы можно выделить явно в любой организации. Но: • они очень фрагментированы; • они не формализованы и не описаны; • не всегда понятно, кто же отвечает за результат; • никто не владеет ситуацией в целом; • по мере выполнения бизнес-процесса слишком часто происходит передача ответственности, и никто не несет ответственности за бизнес-процесс в целом; • недостаточность или переизбыток точек контроля; • информационное обеспечение бизнеспроцессов неэффективно (целостность, полнота, своевременность поступления).
“Каноническая модель” бизнес-процесса
Бизнес-процесс: определения и связанные термины • Ресурсы БП – информация, финансы, материалы, персонал, оборудование, инфраструктура, программное обеспечение необходимые для выполнения БП • Вход БП – ресурс, обеспечиваемый внешним поставщиком • Выход БП – результат (продукт, услуга) действия БП • Владелец (хозяин) БП – должностное лицо, имеющее в своем распоряжении необходимые ресурсы, управляющее БП и несущее ответственность за результаты БП • Показатели (метрики) БП – качественные и количественные характеристики определяющие оперативную и итоговую эффективность БП
Бизнес-процесс: определения и связанные термины • Потребитель (клиент) БП – субъект, получающий результат БП: – Внутренний – находящийся в рамках одной системы БП (в рамках одной организации) – Внешний – использующий конечные результаты работы организации • Регламент БП – документ, регулирующий работу БП • Операция (работа, функция) БП – часть БП, имеющая вход и выход • Модель БП – графическое, текстовое или комбинированное формальное описание БП или системы БП, выполненное с аналитическими или коммуникационными целями Это основные БП Это вспомогательные БП
• Упрощенная классификация БП:
CASE-моделирование • Часто используется термин CASE: Computer Aided System Engineering. • В современном толковании – это практически все методы моделирования и описания бизнеспроцессов (независимо от целей)
Декомпозиция БП как отражение его системности
• Современное управление – это компьютерная поддержка определенного стандарта. • Базовые стандарты управления: • MRP (Material Requirements Planning) - планирование поставок материалов, исходя из данных о комплектации производимой продукции и плана продаж. • ERP (Enterprise Resource Planning), MRPII (Manufacture Resource Planning) - финансово-ориентированное планирование ресурсов предприятия, необходимых для получения, изготовления, отгрузки и учета заказов потребителей на основе интеграции всех отделов и подразделений компании. • SCM (Supply Chain Management) - управление цепочками поставок. Реализация бизнес-процессов на базе внешних предприятий и торговых площадок. • CRM (Customer Relationship Management) - управление взаимоотношениями с заказчиками. Комплекс методов и средств, нацеленный на завоевание, удовлетворение требований и сохранение платежеспособных клиентов. • ERPII (Enterprise Resource & Relationship Processing). CSRP (Customer Synchronize Resource Planning) - управление ресурсами и взаимоотношениями предприятия. Объединяет в себе 3 вышеперечисленные технологии.
Средства описания (нотации) БП Все нотации – вербально-графические конструкции • SADT (IDEF 0, Structured Analyze and Design Technique – Метод структурного анализа и проектирования. Функциональное моделирование. • DFD (Data Flow Diagrams) – Диаграммы потоков данных. Моделирование потоков данных. • ERD (Entity-Relationship Diagrams) – Диаграммы «сущность - связь» . Моделирование структуры данных. • UML (Universal Modeling Language) – Универсальный язык моделирования. Объектное моделирование. • BPMN (Business Process Modeling Notation) – комплексный язык моделирования • ARIS e. EPC (Event. Drive Process Chain) – язык моделирования на основе событий
• Основные источники информации о БП: – Опрос (интервью) специалистов и экспертов – Техническая документация по процессу и регламентные документы – Наблюдение процесса
• Метод структурного анализа и проектирования SADT (Structured Analyze and Design Technique) • IDEF 0
Цели функционального моделирования БП (SADT) выявить входящие в процесс отдельные операции (подпроцессы) и связать их посредством объектов-факторов в непротиворечивую последовательную (ранжированную по доминированию в процессе) модель; выявить все внутренние связи между отдельными операциями процесса с учетом системности модели (последнее подразумевает возможность наличия связей, несводимых к особенностям процесса на более крупном уровне моделирования (эмерджентность)): выявить все внешние (терминальные) связи бизнес-процесса, отражающие его взаимодействие с внешней средой; выявить и ранжировать все факторы, влияющие на работу процесса; оценить эффективность и слабости функционирования процесса.
Формат представления функции (процесса) в SADT
Графические примитивы SADT-диаграмм • Функции-блоки – прямоугольники. Названия – глаголами или отглагольными существительными. • Объекты-дуги – входящими или исходящими из блоков стрелками. Управления – входят сверху (часто окрашены в красный цвет). Входы – входят слева. Выходы – выходят справа. Механизмы – входят снизу. Подписи существительными. • Допускается отсутствие входов и механизмов.
Базовые принципы SADT • Декомпозиция – любую функцию-блок можно представить как цепочку более детально описанных функций. Как следствие, понятия «процесс» и «функция» - это одно и то же. • Итерационность – моделирование осуществляется циклами декомпозиции. Начальный уровень – контекстная диаграмма (одна функция-процесс). Каждая диаграмма декомпозиции содержит от 2 до 6 блоков-функций. Декомпозиции завершаются при достижении требуемой точности. • Точка зрения – весь процесс моделирования (все уровни) осуществляются с точки зрения одного субъекта. Запрещается переход на другую точку зрения.
• Любая SADT-модель процесса – это набор диаграмм, каждая из которых – графическая конструкция с комментариями на листе А 4 -альбом • Диаграмм может быть любое количество • Программы для построения: – All. Fusion Business Process Modeler (BPWin) – Visio – Бумага и карандаш
Первый уровень декомпозиции типичной диаграммы (процесс «Управление хозяйственной деятельностью» )
Отношение по входу
Отношение по управлению
Отношение по механизму
Обратная связь по управлению
Обратная связь по входу
Этапы SADT-моделирования: 1. Сбор информации – – – 2. 3. 4. 5. 6. 7. 8. Изучение документации к процессу Наблюдение процесса Опрос экспертов Составление списка объектов (дуг) Составление списка функций (блоков) Составление диаграммы первого уровня Составление контекстной диаграммы Оценка достаточности диаграммы и необходимости декомпозиции Декомпозиция требуемой функции Внешняя экспертиза модели
Составление диаграммы: 1. Ранжирование и наименование блоков функций
Составление диаграммы: 2. Отрисовка объектов-дуг для первой функции
Составление диаграммы: 3. Отрисовка объектов-дуг для второй функции
Составление диаграммы: 4. Отрисовка объектов-дуг для второй функции
Составление диаграммы: 5. Поиск обратных связей
Значение обратных связей в функциональной модели БП • признак управляемости бизнеспроцесса • признак достаточно хорошего понимания процесса автором • проявление эмерджентности • своеобразный критерий истинности
Дополнительные правила синтаксиса диаграмм • Дуги-стрелки могут разветвляться. Каждое ответвление может иметь свое уточненное название • Дуги-стрелки могут сливаться. Объединяющая стрелка должна иметь свое, отличие от входящих в нее стрел, название. • Все терминальные стрелки на диаграмме декомпозиции должны быть отражены на родительской функции. • Предыдущее правило может быть искусственно нарушено в целях упрощения диаграммы. Такая стрелка называется «тоннельной» и ее окончание берется с скобку (круглую или квадратную).
Пример тоннелирования дуг-стрелок
Навигация по модели: рамочный контекст (стандарт IDEF 0) и нумерация блоков
UML – Unified Modeling Language (Унифицированный Язык Моделирования) • Графический язык моделирования общего назначения, предназначенный для спецификации, визуализации, проектирования и документирования всех артефактов, создаваемых в ходе разработки.
UML: «классические» диаграммы
UML: диаграммы прецедентов (диаграммы использования, Use Case) • Отражают функциональность системы или процесса • Просты в составлении и хорошо читаются • Перечисляют функции и абстрагируются от алгоритмов их реализации (принцип «черного ящика» ) эктор прецедент
Назначение диаграммы прецедентов • Определить общие границы функциональности проектируемой системы в контексте моделируемой предметной области. • Специфицировать требования к функциональному поведению проектируемой системы в форме вариантов использования. • Разработать исходную концептуальную модель системы для ее последующей детализации в форме логических и физических моделей. • Подготовить исходную документацию для взаимодействия разработчиков системы с ее заказчиками и пользователями
Эктор (actor) • Любая внешняя по отношению к проектируемой системе сущность, которая взаимодействует с системой и использует ее функциональные возможности для достижения определенных целей или решения частных задач • Примеры экторов: кассир, клиент банка, банковский служащий, продавец магазина, менеджер отдела продаж, пассажир авиарейса, водитель автомобиля, сотовый телефон, программа – диспетчер транзакций
• На диаграмме может быть не менее одного эктора • Каждый эктор должен взаимодействовать не менее чем с одним прецедентом • Отношение «эктор» - «прецедент» интерпретируется как ассоциация • Иногда это отношение рассматривается как коммуникация • Можно утверждать, что каждый прецедент предоставляет каждому эктору некий завершенный сервис, имеющий самостоятельную ценность
• Прямые отношения «эктор» - «эктор» нежелательны. • Допустимы только отношения генерализации • Отношение обобщения (generalization relationship) предназначено для спецификации того факта, что один элемент модели является специальным или частным случаем другого элемента модели
Вопросы для идентификации актеров в системе • Какие организации или лица будут использовать систему • Кто будет получать пользу от использования системы • Кто будет использовать информацию от системы • Будет ли использовать система внешние ресурсы • Может ли один пользователь играть несколько ролей при взаимодействии с системой • Могут ли различные пользователи играть одну роль при взаимодействии с системой
Прецедент (Вариант использования, use case) • Представляет собой общую спецификацию совокупности выполняемых системой действий с целью предоставления некоторого наблюдаемого результата, который имеет значение для одного или нескольких актеров • Отвечает на вопрос «Что должна выполнять система? » , не отвечая на вопрос «Как она должна выполнять это? » • Имена – отглагольное существительное или глагол в неопределенной форме
• Между прецедентами используются отношения: • включения • расширения • ассоциации Это прецедент-сотрудничество
UML: диаграммы прецедентов (Use Case) • Включение, использование (include, uses) означает, что в некоторой точке базового прецедента содержится поведение другого дочернего прецедента. Включаемый прецедент не существует сам по себе, а является всего лишь частью родительского прецедента.
UML: диаграммы прецедентов (Use Case) • Обобщение, расширение (extends) - это отношение, в котором объекты специализированного элемента (потомка) могут быть подставлены вместо объектов обобщенного элемента (родителя, или предка). Стрелка всегда указывает на предка.
Порядок разработки диаграммы прецедентов • Определить границы системы • Выделить экторов. Эктор - это не физическое лицо, а ролевой пользователь. Например, в ситуации использования ПК, разумней из одного эктора «пользователь» , сделать несколько: «администратор ОС» , «инсталлятор ПО» и т. п. • Определить прецеденты. Они должны олицетворять завершенное действие (сервис) системы и быть равномасштабными. • Связать прецеденты с экторами • Помните, что прецеденты – понятие неформальное. Выделенный прецедент не отдельный алгоритм, а возможность достижения конкретного результата в системе. • Допустима декомпозиция отдельных прецедентов
Типичные ошибки при разработке диаграмм прецедентов • Превращение прецедентов в диаграмму активностей за счет желания отразить все функциональные действия • Инициатором действий является разрабатываемая система • Задание слишком кратких имен прецедентам • Описание прецедентов в терминологии, непонятной пользователям системы или заказчику • Отсутствие описаний альтернативных последовательностей действий и исключительных ситуаций • Тратится слишком много времени на решение вопросов о том, какие отношения использовать на диаграмме
UML: Use Case – бизнес-процесс «Покупка в Интернет-магазине»
UML: Use Case – пример (сайт UMLjokes. com)
UML: Use Case - пример
UML: Use Case - пример
• BPMN (Business Process Modeling Notation) - использует набор интуитивно понятных элементов, которые связываются по определенным правилам для описания БП. • Спецификация BPMN определяет, как диаграммы, описывающие бизнеспроцесс, могут быть трансформированы в исполняемые модели на языке BPEL (Business Process Execution Language, язык на основе XML).
• Простейшая BPMN-модель: процесс “Производство”
• Типичная BPMN-модель «Экзамен в вузе» • Тип взаимодействия: collaboration Свернутый пул Шлюз Подпроцесс Поток управления Клик! Документы Операция Событие Развернутый пул Поток сообщений
• Разворачивание подпроцесса:
• Графический алфавит BPMN: Нетипизированная операция (задача, работа) Типизированные операции (задачи, работы):
• Графический алфавит BPMN: События: Начальные Промежуточные Завершающие
• Графический алфавит BPMN: Шлюзы:
Диаграммы потоков данных (DFD, Data Flow Diagrams) • Описывают бизнес-процесс в терминах движения документов • Могут создавать самостоятельные модели или конкретизировать на отдельных декомпозициях SADT-модели • Наследуют синтаксические принципы SADT • Используются при проектировании информационных систем и для детального анализа потока документов
Конструктивы DFD-диаграмм
• Потоки данных – объекты, передающие информацию от одной части системы к другой. Обычно это документы в разных форматах. • Процесс – аналог функции-блока в SADT. Принимает или производит потоки данных. Именуется глаголом и имеет уникальный номер. В отличие от SADTдиаграмм, здесь акцент на алгоритм обработки информации • Хранилище данных – любое устройство (база данных, архив. . ), сохраняющее информацию в промежуточном состоянии. Фактически временной срез данных. • Внешняя сущность (терминатор) – объект, находящийся за условными границами процесса и создающий (потребляющий) информацию. Не может влиять на работу процесса.
Пример DFD-диаграммы
Контекстная диаграмма DFD
Первая декомпозиция DFD-диаграммы
Моделирование структур хранения данных в терминах «сущность-связь» ERD-моделирование (Entity-Relationship Modeling)
ERD-нотация • В сравнении с другими методами моделирования отличается следующим: – Весьма строгая, основывается на реляционной алгебре – Допускает кодогенерацию – Имеет особую важность при проектировании информационных систем – Концептуально близка к объектным моделям
ERD-модели • Реляционная модель представления
• SQL-язык полностью ориентирован на реляционную модель представления данных • Базовое понятие – таблица, она же сущность • Несколько таблиц связаны отношениями (реляциями) через пару ключей: «первичный» «вторичный»
Связь «один-к-одному» • Пусть есть 2 таблицы: • Атрибуты одной дополняют вторую. Найти связанную информацию можно по общей колонке - ключу • Преимущества: более компактные таблицы • Недостатки: более сложные запросы выборок
Связь «один-ко-многим» • Студент Иванов может получить любое количество оценок:
Связь «многие-ко-многим» • В реляционной логике такая связь невозможна • Необходимо разбить на две связи «один-ко-многим» , то есть ввести новую сущность.
ERD-модели • Важнейший целевой артефакт для проектирования систем. • Значение для реинжиниринга и управления? • Три уровня ER-моделирования: – Концептуальный – Логический (инфологический) – Физический (датологический)
ERD-модели • концептуальная • инфологическая
ERD-модели • Датологическая – Привязка к СУБД – Типизация атрибутов – Серверная бизнес-логика (индексы, триггеры, хранимые процедуры)
• Основные группы команд (подразделы SQL): – DDL – язык определения данных (CREATE TABLE, ALTER TABLE, DROP TABLE, CREATE INDEX, ALTER INDEX, DROP INDEX); – DML – язык манипулирования данными (INSERT, UPDATE, DELETE); – DQL – язык запросов (только один оператор SELECT); – DCL – язык управления данными (GRANT, REVOKE ); – команды управления транзакциями (COMMIT, ROLLBACK, SAVEPOINT, SET TRANSACTION);
ERD-модель учебной базы «Оценки студентов»
• Минимально возможная конструкция запроса: • SELECT * FROM Студенты • Возвращает полностью всю таблицу – все строки со всеми атрибутами-колонками Полностью аналогична: SELECT №_Зачетки, Имя_Отчество, Фамилия, Дата_Рождения, Номер_Телефона FROM Студенты Можно переставить порядок: SELECT Фамилия, Имя_Отчество, Дата_Рождения, №_Зачетки, Номер_Телефона FROM Студенты Можно так: SELECT DISTINCT Фамилия FROM Студенты
• Усложняем: • SELECT DISTINCT Фамилия FROM Студенты ORDER BY Фамилия • Сортировка по указанному атрибуту (атрибутам) Можно так: SELECT DISTINCT Фамилия FROM Студенты ORDER BY Фамилия DESC
• При сравнении и сортировке строковых литералов за основу берется «вес» букв в таблицах кодировки ASCII.
• Добавляем критерии фильтрации (отбора): • SELECT DISTINCT Фамилия FROM Студенты WHERE Дата_Рождения <’ 01. 1995’ • Where присутствует почти всегда и только один раз! • Можно использовать любые операторы сравнения: =, <, >, <=, >=, <> Можно сравнивать любые поля, в том числе и строковые. Строки и даты берутся в апострофы:
• Важный предикат LIKE позволяет проводить простой синтаксический поиск: • Найти всех студентов, фамилии которых заканчиваются на букву 'о' • SELECT * FROM Студенты WHERE Фамилия LIKE '%o' Найти всех студентов, фамилии которых состоят из двух слов • SELECT * FROM Студенты WHERE Фамилия LIKE '%-%' Трафаретные символы (шаблоны, джокеры)
• Запросы часто связывают таблицы по ключам: • Найти какие оценки и по каким предметам получил студент Иванов в 2012 году: • select название, оценка from студенты, Учебные_Предметы, Учебные_Предметы_Студенты where фамилия=‘Иванов’ and Студенты. ID=ID and Ext, yst_Ghtlvtns. IDP=IDP and Дата_Получения<’ 31/12/2012’ and Дата_Получения>’ 01/01/2012’
Скачать презентацию Моделирование бизнеспроцессов Бабенко В В 2013 bvv
Моделирование бизнес-процессов.ppt