Содержание
-
Моделирование бизнес-процессов
Бабенко В. В. ©2013, bvv
-
Вопросы курса: Чем процессный подход в управлении может помочь менеджеру? Терминологическая основа моделирования БП. Как можно смоделировать бизнес-процессы – основные нотации и методологии? Какие программные продукты можно и нужно использовать при моделировании бизнес-процессов?
-
Основные положения андрагогики: взрослому человеку, который обучается, — обучающемуся (а не обучаемому) принадлежит ведущая роль в процессе обучения (Главный – учащийся!); он, являясь сформировавшейся личностью, ставит перед собой конкретные цели обучения, стремится к самоуправлению (Управляет – учащийся!); взрослый человек обладает профессиональным и жизненным опытом, знаниями, умениями, навыками, которые должны быть использованы в процессе обучения (Новое – отталкиваясь от уже известного!); взрослый ищет скорейшего применения полученным при обучении знаниям и умениям (В новых знаниях ищи практическую ценность!); процесс обучения в значительной степени определяется временными, пространственными, бытовыми, профессиональными, социальными факторами, которые либо ограничивают, либо способствуют ему (Время можешь спланировать только ты!); процесс обучения организован в виде совместной деятельности обучающегося и обучающего на всех его этапах (Результат дает только активное взаимодействие!).
-
Литература: Елиферов В.Г., Репин В.В. Бизнес-процессы: Регламентация и управление. – М.: ИНФРА-М, 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
-
В чем польза моделирования БП:
Работа над моделью позволяет лучше узнать процесс Модели в разных нотациях позволяют провести анализ с разными целевыми установками Модели БП позволяют сформировать общее видение задач в команде и упрощают диалог «заказчик - исполнитель» Большинство нотаций стандартизировано, то есть, специалистам все понятно без дополнительных комментариев
-
Вопросы, которые интересуют пользователей при моделировании бизнес-процессов
-
Чего следует остерегаться:
Создание моделей ради моделей – глупое украшательство! Модели БП не должны быть излишне сложными. Главная цель любого моделирования – абстрагирование от несущественных деталей. Не следует добиваться «самой правильной модели» - процесс описания БП очень субъективен. Главный критерий качества – выразительность и информативность.
-
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 (IDEF0, Structured Analyze and Design Technique – Метод структурного анализа и проектирования. Функциональное моделирование. DFD (Data Flow Diagrams) – Диаграммы потоков данных. Моделирование потоков данных. ERD (Entity-Relationship Diagrams) – Диаграммы «сущность - связь». Моделирование структуры данных. UML (Universal Modeling Language) – Универсальный язык моделирования. Объектное моделирование. BPMN (Business Process Modeling Notation) – комплексный язык моделирования ARIS eEPC (EventDrive Process Chain) – язык моделирования на основе событий
-
Основные источники информации о БП: Опрос (интервью) специалистов и экспертов Техническая документация по процессу и регламентные документы Наблюдение процесса
-
Метод структурного анализа и проектирования SADT (Structured Analyze and Design Technique) IDEF0
-
Цели функционального моделирования БП (SADT)
выявить входящие в процесс отдельные операции (подпроцессы) и связать их посредством объектов-факторов в непротиворечивую последовательную (ранжированную по доминированию в процессе) модель; выявить все внутренние связи между отдельными операциями процесса с учетом системности модели (последнее подразумевает возможность наличия связей, несводимых к особенностям процесса на более крупном уровне моделирования (эмерджентность)): выявить все внешние (терминальные) связи бизнес-процесса, отражающие его взаимодействие с внешней средой; выявить и ранжировать все факторы, влияющие на работу процесса; оценить эффективность и слабости функционирования процесса.
-
Формат представления функции (процесса) в SADT
-
Графические примитивы SADT-диаграмм
Функции-блоки – прямоугольники. Названия – глаголами или отглагольными существительными. Объекты-дуги – входящими или исходящими из блоков стрелками. Управления – входят сверху (часто окрашены в красный цвет). Входы – входят слева. Выходы – выходят справа. Механизмы – входят снизу. Подписи существительными. Допускается отсутствие входов и механизмов.
-
Базовые принципы SADT
Декомпозиция – любую функцию-блок можно представить как цепочку более детально описанных функций. Как следствие, понятия «процесс» и «функция» - это одно и то же. Итерационность – моделирование осуществляется циклами декомпозиции. Начальный уровень – контекстная диаграмма (одна функция-процесс). Каждая диаграмма декомпозиции содержит от 2 до 6 блоков-функций. Декомпозиции завершаются при достижении требуемой точности. Точка зрения – весь процесс моделирования (все уровни) осуществляются с точки зрения одного субъекта. Запрещается переход на другую точку зрения.
-
Любая SADT-модель процесса – это набор диаграмм, каждая из которых – графическая конструкция с комментариями на листе А4-альбом Диаграмм может быть любое количество Программы для построения: AllFusion Business Process Modeler (BPWin) Visio Бумага и карандаш
-
Первый уровень декомпозиции типичной диаграммы (процесс «Управление хозяйственной деятельностью»)
-
Отношение по входу
-
Отношение по управлению
-
Отношение по механизму
-
Обратная связь по управлению
-
Обратная связь по входу
-
Этапы SADT-моделирования:
Сбор информации Изучение документации к процессу Наблюдение процесса Опрос экспертов Составление списка объектов (дуг) Составление списка функций (блоков) Составление диаграммы первого уровня Составление контекстной диаграммы Оценка достаточности диаграммы и необходимости декомпозиции Декомпозиция требуемой функции Внешняя экспертиза модели
-
Составление диаграммы: 1. Ранжирование и наименование блоков функций
-
Составление диаграммы: 2. Отрисовка объектов-дуг для первой функции
-
Составление диаграммы: 3. Отрисовка объектов-дуг для второй функции
-
Составление диаграммы: 4. Отрисовка объектов-дуг для второй функции
-
Составление диаграммы: 5. Поиск обратных связей
-
Значение обратных связей в функциональной модели БП
признак управляемости бизнес-процесса признак достаточно хорошего понимания процесса автором проявление эмерджентности своеобразный критерий истинности
-
Дополнительные правила синтаксиса диаграмм
Дуги-стрелки могут разветвляться. Каждое ответвление может иметь свое уточненное название Дуги-стрелки могут сливаться. Объединяющая стрелка должна иметь свое, отличие от входящих в нее стрел, название. Все терминальные стрелки на диаграмме декомпозиции должны быть отражены на родительской функции. Предыдущее правило может быть искусственно нарушено в целях упрощения диаграммы. Такая стрелка называется «тоннельной» и ее окончание берется с скобку (круглую или квадратную).
-
Пример тоннелирования дуг-стрелок
-
Навигация по модели: рамочный контекст (стандарт IDEF0) и нумерация блоков
-
UML – Unified Modeling Language (Унифицированный Язык Моделирования)
Графический язык моделирования общего назначения, предназначенный для спецификации, визуализации, проектирования и документирования всех артефактов, создаваемых в ходе разработки.
-
UML:«классические» диаграммы
-
UML:диаграммы прецедентов (диаграммы использования,Use Case)
Отражают функциональность системы или процесса Просты в составлении и хорошо читаются Перечисляют функции и абстрагируются от алгоритмов их реализации (принцип «черного ящика») эктор прецедент
-
Назначение диаграммы прецедентов
Определить общие границы функциональности проектируемой системы в контексте моделируемой предметной области. Специфицировать требования к функциональному поведению проектируемой системы в форме вариантов использования. Разработать исходную концептуальную модель системы для ее последующей детализации в форме логических и физических моделей. Подготовить исходную документацию для взаимодействия разработчиков системы с ее заказчиками и пользователями
-
Эктор (actor)
Любая внешняя по отношению к проектируемой системе сущность, которая взаимодействует с системой и использует ее функциональные возможности для достижения определенных целей или решения частных задач Примеры экторов: кассир, клиент банка, банковский служащий, продавец магазина, менеджер отдела продаж, пассажир авиарейса, водитель автомобиля, сотовый телефон, программа – диспетчер транзакций
-
На диаграмме может быть не менее одного эктора Каждый эктор должен взаимодействовать не менее чем с одним прецедентом Отношение «эктор» - «прецедент» интерпретируется как ассоциация Иногда это отношение рассматривается как коммуникация Можно утверждать, что каждый прецедент предоставляет каждому эктору некий завершенный сервис, имеющий самостоятельную ценность
-
Прямые отношения «эктор»- «эктор» нежелательны. Допустимы только отношения генерализации Отношениеобобщения(generalization relationship) предназначено для спецификации того факта, что один элемент модели является специальным или частным случаем другого элемента модели
-
Вопросы для идентификации актеров в системе
Какие организации или лица будут использовать систему Кто будет получать пользу от использования системы Кто будет использовать информацию от системы Будет ли использовать система внешние ресурсы Может ли один пользователь играть несколько ролей при взаимодействии с системой Могут ли различные пользователи играть одну роль при взаимодействии с системой
-
Прецедент (Вариант использования, use case)
Представляет собой общую спецификацию совокупности выполняемых системой действий с целью предоставления некоторого наблюдаемого результата, который имеет значение для одного или нескольких актеров Отвечает на вопрос «Что должна выполнять система?», не отвечая на вопрос «Как она должна выполнять это?» Имена – отглагольное существительное или глагол в неопределенной форме
-
Между прецедентами используются отношения: включения расширения ассоциации Это прецедент-сотрудничество
-
UML:диаграммы прецедентов (Use Case)
Включение, использование (include, uses) - означает, что в некоторой точке базового прецедента содержится поведение другого дочернего прецедента. Включаемый прецедент не существует сам по себе, а является всего лишь частью родительского прецедента.
-
Обобщение, расширение (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-моделирования: Концептуальный Логический (инфологический) Физический (датологический)
-
концептуальная инфологическая
-
Датологическая Привязка к СУБД Типизация атрибутов Серверная бизнес-логика (индексы, триггеры, хранимые процедуры)
-
Основные группы команд (подразделы 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 Студенты Можно так: SELECTDISTINCTФамилияFROM Студенты
-
Усложняем: SELECTDISTINCTФамилияFROM СтудентыORDER BYФамилия Сортировка по указанному атрибуту (атрибутам) Можно так: SELECTDISTINCTФамилияFROM СтудентыORDER BYФамилияDESC
-
При сравнении и сортировке строковых литералов за основу берется «вес» букв в таблицах кодировки ASCII.
-
Добавляем критерии фильтрации (отбора): SELECTDISTINCTФамилияFROM СтудентыWHEREДата_Рождения , =, Можно сравнивать любые поля, в том числе и строковые. Строки и даты берутся в апострофы:
-
Важный предикат LIKE позволяет проводить простой синтаксический поиск: Найти всех студентов, фамилии которых заканчиваются на букву 'о' SELECT * FROM Студенты WHERE ФамилияLIKE'%o' Трафаретные символы (шаблоны, джокеры) SELECT * FROM Студенты WHERE ФамилияLIKE'%-%' Найти всех студентов, фамилии которых состоят из двух слов
-
Запросы часто связывают таблицы по ключам: Найти какие оценки и по каким предметам получил студент Иванов в 2012 году: select название, оценка from студенты, Учебные_Предметы, Учебные_Предметы_Студенты where фамилия=‘Иванов’and СтудентыID=ID and Ext,yst_GhtlvtnsIDP=IDP and Дата_Получения’01/01/2012’
Нет комментариев для данной презентации
Помогите другим пользователям — будьте первым, кто поделится своим мнением об этой презентации.