Содержание курса
Инфраструктура (ландшафт) для организации проектной деятельности
Инжиниринг бизнес-процессов заказчика. 1. Применение UML Activity
Инжиниринг бизнес-процессов заказчика. 2. Применение BPMN. Предварительный расчет ресурсоемкости проекта.
Разработка логической структуры данных целевой Информационной системы(ИС)
Моделирование поведения целевой системы. Моделирование процессов управления
Формирование спецификаций требований на создание целевой ИС
Управление изменениями требований и организация эффективного взаимодействия в команде производства ИТ продукта
Организация процессов проектирования в производстве ИТ-продукта
В качестве следующего шага на пути формирования проектного решения определим процессы, которые должны проистекать внутри разрабатываемой системы и окружать ее из вне. Поддерживая непрерывность процесса проектирования, будем отталкиваться от функций, которые мы выявили на предыдущем этапе.
Как всегда, обозначим цели текущего шага: на основании выявленных функций, определить сценарии использования/применения, разрабатываемого целевого продукта.
На текущем этапе проектирования воспользуемся Алгоритмизацией, еще одним приемом дисциплины «Системный Анализ».
Рассмотренные нами ранее модели в большей степени отражали статику, ведь в итоге формализованные функции воплощают свойства системы, которые можно использовать. Теперь внесем немного динамики, моделируя действия. Важное отличие алгоритмов от используемых нами ранее диаграмм IDEF0, это возможность организовывать условные переходы, то есть в зависимости от выполнения некоего условия на определенном шаге сценария, предпринимать далее те или иные варианты действий. В том числе задействовать сервисы, выявленные на прошлом этапе.
Концепция инжиниринга бизнес-процессов подразумевает осмысление различных моделей текущего состояния системы и прогнозирования будущих с целью достижения существенных улучшений по ключевым показателям: стоимость, качество, скорость, ресурсоемкость и прочее. В зависимости от актуальных условий может использоваться:
1) Экстраполяционная модель. Основывается на анализе существующих трендов. Проецирует текущие тенденции в будущее.
Проблема: Не учитывает неожиданных изменений среды (кризисов, революций).
2) Сценарная модель. Разработка нескольких возможных сценариев будущего в зависимости от изменений среды. Учитывает влияние критических факторов и неопределённости.
Проблема: Высокая сложность построения и анализа сценариев.
3) Игра с нулевой суммой. Анализ будущего через призму конфликтов между различными элементами среды. Применяется в геополитике, экономике и социальной сфере.
Проблема: Пессимистичный взгляд, акцент на конфликтах.
4) Эволюционная модель. Будущее рассматривается как процесс естественного отбора систем. Успешные системы выживают за счёт адаптации к изменениям среды.
Проблема: Длительный процесс изменений, невозможность предсказать скорость трансформаций.
1. Понятие бизнес-процесса
Любое процессное моделирование начинается с идентификации ключевых бизнес-процессов.
Термин | Значение |
Бизнес-процесс | это регулярно повторяющаяся последовательность взаимосвязанных мероприятий (операций, процедур, действий), при выполнении которых: используются ресурсы, создается ценность для потребителя, которая передается потребителю в виде результата. |
Бизнес-процессы лежат в основе деятельности любой организации, а потому их отражение в документации иллюстрирует, как именно компания создает, доставляет и поддерживает свой продукт или услугу.
Выполняя инжиниринг деловых процессов предприятия важно охватить всю картину организации целиком для моделирования, анализа, получения обратной связи, внесения корректировок и т.д. И качественное описание бизнес-процессов дает в руки инструмент, который позволяет выполнить следующие задачи:
1) Четко определить зоны ответственности руководителей на всех уровнях (формализация функциональной структуры предприятия);
2) Оптимизировать взаимодействия структурных подразделений предприятия за счёт стыковки процессов по входам/выходам (выявление “провисаний” в процессах);
3) Анализировать возможные изменения в организации (моделирование изменений);
4) Тиражировать и масштабировать стандарты деятельности (например, клонирование филиалов);
5) Обучать сотрудников (быстрая и стандартизированная адаптация новичков);
6) Автоматизировать процессы (замена ручных процессов, цифровыми двойниками);
7) Анализировать и оптимизировать деятельности (реинжиниринг деловой активности);
8) Выполнять внутренний аудит (контроль);
9) Развивать культуру процессного управления;
Для понимания того, насколько качественно организованы бизнес-процессы используют метрики эффективности (или KPI — ключевые показатели эффективности). Это количественные показатели, с помощью которых измеряют, насколько хорошо процесс выполняет свою функцию, достигает целей и приносит ценность бизнесу.
Метрики эффективности бизнес-процесса могут быть следующими:
Время выполнения (Cycle Time) — сколько времени занимает выполнение процесса.
Производительность (Throughput) — сколько единиц результата создаётся за определённый период.
Качество (Quality) — доля успешных результатов без ошибок.
Стоимость выполнения (Cost) — затраты на выполнение процесса.
Удовлетворённость клиента (Customer Satisfaction) — насколько клиент доволен результатом.
Прочее …
2. Классификация бизнес-процессов.
Для того, чтобы анализировать текущее состояние организации, осознанно управлять стратегией развития, эффективно распределять ресурсы и усилия для улучшая бизнес-процессов, по традиции введем их классификацию:
1) Основными бизнес-процессами являются процессы, ориентированные на производство товара или оказание услуги, являющиеся целевыми объектами создания предприятия и обеспечивающие получение дохода.
Так, для библиотеки основным бизнес-процессом является активности, связанные с предоставлением книг читателям.
2) Сопутствующие процессы — процессы, ориентированные на производство товара или оказание услуги, являющиеся результатами сопутствующей основному производству производственной деятельности и также обеспечивающие получение дохода.
Так, для библиотеки процесс проведения культурных мероприятий на собственной базе является сопутствующим процессом.
3) Вспомогательные бизнес-процессы — процессы, предназначенные для обеспечения выполнения основной деятельности и поддержания ее специфических черт.
Так, в библиотеке вспомогательным бизнес-процессом является процесс обновления библиотечного фонда.
4) Обеспечивающие бизнес-процессы — процессы, предназначенные для жизнеобеспечения всех остальных бизнес-процессов и ориентированные на поддержку их универсальных черт.
На предприятиях любой отрасли — это процесс финансового обеспечения деятельности, процесс кадрового обеспечения, инженерно-технического обеспечения и т. п.
5) Бизнес-процессы управления — это процессы, охватывающие весь комплекс функций управления на уровне каждого бизнес-процесса и бизнес-системы в целом.
Это процессы стратегического, оперативного и текущего планирования, формирования и осуществления управленческих воздействий.
6) Бизнес-процессы развития — это процессы совершенствования производимого товара или услуги, технологий, модификации оборудования.
Например, это проведение научно-исследовательских и аналитических работ (НИОКР) в области цифровизации бумажных носителей, процесс технической модернизации способов доступа к изданиям и т. п.
Подобное структурирование помогает выстраивать и развивать бизнес-архитектуру предприятия. Видеть полную картину и осознанно формировать стратегии развития.
3. Способы моделирования бизнес-процессов
Существуют разные конструкторские стандарты, регламентирующие представление бизнес-процессов в документации. Основные блоки, используемые для составления схем алгоритмов бизнес-процессов, представлены еще в нормативных документах ЕСПД, главным образом это:
ГОСТ 19.003-80 Схемы алгоритмов и программ. Обозначения условные графические
ГОСТ 19.701-90 Схемы алгоритмов, программ, данных и систем. Условные Обозначения и правила выполнения
Со временем базовые стандарты были адаптированы, например, BPMN, ARIS, ISO 9001 и стали использоваться вместо или в дополнение к традиционным.
Основные составляющие, которые определяют структуру, логику и эффективность любого бизнес-процесса, чаще всего представлены в виде следующих элементов:
Входы (Inputs) — то, с чего начинается процесс: ресурсы, данные, материалы, необходимые для инициации активности.
Действия (Activities) — последовательность задач, выполняемых для преобразования входов в результат.
Время и последовательность — очерёдность шагов, сроки, зависимости между этапами;
Роли (Roles) — участники процесса (сотрудники, системы, подразделения).
Ресурсы (Resources) — оборудование, системы, материалы, бюджет.
Выходы (Outputs) — результат работы процесса (продукт, услуга, информация).
Контрольные точки (Control Points) — места, где происходят проверки, согласования, принятие ключевых решений, этапы контроля выполнения процесса.
Цели и метрики (Goals & Metrics) — ожидаемый результат и показатели эффективности.
Документы — бумажные и электронные формы, сопроводительные данные, которые "движутся" по процессу
Мы будем использовать графические изображения бизнес-процессов при помощи алгоритмических диаграмм (деловое моделирование).
При разработке диаграмм данного типа важно учитывать следующие аспекты:
Во-первых, диаграммы должны достаточно подробно и точно описывать логику процесса. Но описание должно быть настолько подробным и точным, насколько это требуется в каждом конкретном проекте.
Во-вторых, диаграммы должны быть одинаково понятны различными группами стекхолдеров. Это, в первую очередь, люди бизнеса, чью работу они моделируют, а также исполнители: бизнес-аналитики, разработчики и прочие.
Итак, на данном шаге мы строим модели бизнес-процессов.
3.1. Диаграмма Деятельности - (Activity в UML)
Описывает поведение в форме графа деятельности. Показывает поток управления и поток данных между различными действиями, а также точки ветвления, условия, параллельное выполнение задач и конечный результат процесса.
Основные элементы диаграммы деятельности:
1) Начальное состояние (Initial Node). Отмечает начало выполнения процесса. Обозначается заполненным чёрным кругом.
Пример: Пользователь открывает приложение.
2) Действие (Action). Конкретное действие или задача в процессе. Обозначается прямоугольником со скруглёнными углами.
Пример: Ввод данных пользователем.
3) Поток управления/переход (Control Flow). Показывает направление выполнения процесса. Обозначается стрелкой.
Пример: Переход от действия «ввод данных» к действию «проверка данных»
4) Решение/ветвление (Decision Node). Точка выбора между несколькими вариантами развития процесса. Обозначается ромбом.
Пример: Если данные корректны — переходим к следующему шагу, иначе — выводим сообщение об ошибке.
5) Объединение (Merge Node). Слияние нескольких веток в одну. Позволяет вернуться к общему сценарию после выполнения альтернативных путей.
Пример: После проверки данных продолжаем процесс независимо от результата.
6) Параллельное выполнение (Fork Node).Разделяет процесс на несколько параллельных действий. Обозначается линией, из которой выходят несколько стрелок.
Пример: Отправка уведомлений по почте и SMS одновременно.
7) Синхронизация (Join Node). Слияние нескольких параллельных процессов в один поток. Обозначается линией, в которую входят несколько стрелок.
Пример: После отправки уведомлений продолжаем выполнение основного процесса.
8) Объектный поток (Object Flow). Передача данных между действиями. Обозначается пунктирной стрелкой.
Пример: Передача информации о заявке в систему распределения.
9) Конечное состояние (Final Node). Завершение процесса. Обозначается кругом с вложенным чёрным кругом.
Пример: Процесс завершён после успешной выдачи книги.
По существу, эта диаграмма представляет собой блок-схему, которая наглядно показывает, как поток управления переходит от одной деятельности к другой.
Поскольку на диаграмме отображаются последовательности действий – операций, то последовательность всегда начинается со значка “Начало” – начальное состояние. А заканчивается значком “Конец”, заключительное состояние. На классической диаграмме activity должен быть только один значок начало и может быть один или несколько знаков окончания. Эти элементы определяют Границы Бизнес-процесса.
Граница бизнес-процесса – это наступление конкретного события и/или времени, которые служат сигналом для начала исполнения бизнес-процесса или указывают на его окончание.
Между значками начала и окончанием, на диаграмме располагается блок-схема, которая наглядно показывает, как поток управления переходит от одной деятельности к другой. Для организации условных переходов используют элемент «Разветвления управлением», каждый переходы из которого, определяется неким условием.
Вход бизнес-процесса – это ресурс, который необходим для исполнения бизнес-процесса
Выход бизнес-процесса – это продукт, услуга, информация, документ или иной другой результат исполнения операций бизнес-процесса.
В терминологии процессного управления – тот, кто обеспечивает вход бизнес-процесса, называется Поставщиком бизнес-процесса. Получатель результата бизнес-процесса называется Потребителем.
Поскольку бизнес-процессы чаще всего имеют большую разветвленную структуру, то воспринимать такие дебри сложно и неудобно. Рационально разделить это древо на ветки.
Каждый сценарий может быть представлен в виде одной бизнес-транзакции, единицы деловой активности, производящей конкретный результат (деньги, документы, обязательства и прочее), в предсказуемый (ограниченный) промежуток времени.
Таким образом под бизнес-транзакцией понимается совокупность работ, направленных на создание определенной ценности (выходящего ресурса), необходимой потребителю. Для выполнения этой деятельности используются входящие ресурсы.
Логично предположить, что все бизнес-процессы в организации взаимосвязаны между собой через систему входов и выходов. В идеальной ситуации, выход одного бизнес-процесса автоматически поступает в другой бизнес-процесс, что служит сигналом для его исполнения и так продолжается по всей цепочке.
В ИТ системах для транзакций бизнес-процессов важно принимать во внимание следующие их характеристики:
весь процесс должен быть атомарным, транзакция выполняется целиком или не выполняется вовсе. Если один из шагов завершился с ошибкой — все предыдущие действия откатываются.
информация о процессе должна быть надежно зафиксирована (например, в базе данных);
экземпляр процесса сопровождается транзакционным идентификатором и его легко различить от других;
При выявлении бизнес-транзакций выбор подхода к их проектированию зависит от их сложности, что требует их классификации:
1) Простая бизнес-транзакция. Выполняется быстро и без сложных условий.Завершается успехом или откатом.
Пример: Доставка книги с места хранения.
2) Сложная (длительная) бизнес-транзакция. Включает несколько последовательных шагов. Может содержать точки отката или промежуточные статусы.
Пример: Оформление брони на библиотечное помещение для проведения в нем мероприятия (проверка истории взаимодействия с клиентом, подтверждение надежности клиента, поиск свободных помещений на указанные сроки, подписание договора).
3) Согласованная (компенсируемая) бизнес-транзакция. В случае неудачи выполняются компенсирующие действия (отмена, возврат средств).
Пример: Если при бронировании помещения клиент отменяет бронь, деньги автоматически возвращаются на счёт, бронь снимается с помещения.
Следующий аспект.
При конструировании или фиксации бизнес-процесса важно понимать, кто же несет ответственность за выполнение каждой операции. Для решения этой проблемы операции располагают на разных дорожках, каждая из которых логически связана с конкретным исполнителем.
Термин | Значение |
Дорожки бизнес-процессов (Swimlanes) | это способ визуализации бизнес-процесса с разделением ролей, зон ответственности и участников процесса. Дорожки помогают наглядно показать, кто выполняет каждое действие в процессе и как задачи передаются между участниками. |
Визуально дорожки представляют собой горизонтальные или вертикальные области на диаграмме бизнес-процессов, в которых отображаются действия, связанные с определённой ролью или подразделением.
Использование дорожек бизнес-процессов позволяет достичь:
Четкое распределение зон ответственности между участниками процесса.
Упрощение анализа процесса за счёт визуального разделения ролей.
Обнаружение узких мест, задержек и дублирования задач.
Определение границ взаимодействия между участниками процесса.
Упрощение согласования и описания процессов внутри организации.
На диаграммах делового моделирования могут использоваться отступления, от канонических нотаций UML. На рисунке ниже представлена бизнес-транзакция, реализующая функцию «Обработка заявок читателей», выявленной на прошлом этапе и “покрывающей” Пользовательскую историю US03.
Как видно на рисунке, можно использовать элементы хранилищ данных, с указанием потоков данных, которые в момент выполнения операции записывают в них информацию или считывают из них. Это очень помогает при проектировании нагруженных, транзакционных процессов, когда наблюдается конкуренция за ресурсы и необходимо распределить нагрузку между операциями.
Вместо дорожек исполнителей могут использоваться значки, указывающие на исполнителя, соединенного стрелкой с действиями, которые он производит. Значок Начало процесса на диаграмме может быть не один, а несколько и прочее.
Теперь определим требования, которые необходимо соблюдать чтобы создавать качественные диаграммы.
Каждый сценарий деловой активности должен удовлетворять тем же параметрам, что и обычное требование к системе, но приспособленные для описания поведения системы, а не её статичных характеристик:
Единичность — сценарий описывает один и только один вариант поведения системы.
Завершенность — сценарий полностью определен в одном месте и содержит всю информацию, необходимую для его корректного восприятия всеми заинтересованными лицами.
Непротиворечивость — сценарий не противоречит другим сценариям.
Связность (последовательность) – сценарий дополняет другие сценарии и составляет с ними единую картину будущей системы
Отслеживаемость — сценарий полностью или частично соответствует деловым нуждам, как заявлено заинтересованными лицами и задокументировано в перечне историй.
Атомарность — сценарий нельзя разделить на более мелкие сценарии без потери конкретного полезного результата.
Актуальность — сценарий не стал устаревшим с течением времени.
Реализуемость — сценарий может быть реализован в рамках проекта.
Рассмотрим теперь подробнее, как применить на практике деловое моделирование в нашем конкретном проекте Библиотека.
Как обсуждалось в предыдущей части, на основании выявленных функций системы, мы должны описать бизнес-процессы или точнее бизнес-транзакции, которые принимают на вход какие-то ресурсы или данные, используя их выполняют определенные регламентированные действия и выдают результат заинтересованным лицам.
Например, мы выявили и формализовали функцию «Учет изданий», которая “покрывает” Пользовательскую историю US01. Основной целью функции выступает регистрация в библиотечном фонде экземпляра издания.
Входящим параметром в данном процессе будет экземпляр издания. Например, конкретная единица книги. Смотри рисунок ниже. Попадая в руки сотрудника библиотеки, экземпляр должен быть учтен в номерном фонде. А для этого он должен быть классифицирован и каталогизирован, чтобы любой неискушенный читатель смог успешно осуществить поисковые активности. При этом логично предположить, что если аналогичное издание уже раньше поступало в библиотеку, то с высокой долей вероятности все вышеописанные активности с ним уже производились и мы можем воспользоваться результатами ранее проведенной работы.
Поэтому при получении конкретной единицы книги, в первую очередь сотрудник библиотеки должен проверить, а не заводил ли он ранее карточку для подобного издания. И если заводили, использовать эту информацию и для новой книги. В противном случае придется заводить подробную карточку на издание с полной классификацией, каталогизацией и прочей бюрократией.
Ну и венцом всей этой деятельности должен стать заполненный формуляр конкретного экземпляра книги.
Таким образом, на вход бизнес-транзакции поступила единица книги, на выходе образовался формуляр карточки в библиотечном каталоге, с полной информацией об этой книге. Для выполнения активной используются хранилища данных: «Книги», «Классификаторы», «Авторы». Действия выполняют «Библиотекарь» и непосредственно сама целевая система.
Выходящий параметр процесса – «Формуляр книги», будет использован далее в качестве входящего параметра в процессе выдачи издания читателю.
Обратите внимание на то, что все элементы Действие (Action) на диаграмме подписаны стереотипами (значение в двойных угловых скобках), означающих тот или иной компонент ПО. Например, <<форма карточки>>, <<список для выбора>>, <<процедура>>. Это в дальнейшем поможет команде подсчитать количество компонентов ПО, которое необходимо реализовать в продукте для реализации рассматриваемого бизнес-процесса. Понимая сколько ресурсов необходимо затратить на реализацию каждого из них, можно подсчитать приблизительную ресурсоемкость работ. Подробнее этот прием мы будем разбирать чуть позже в конце раздела.
Моделируя таким образом, существующие у заказчика бизнес-процессы, можно выявить и нивелировать такие проблемы как:
1) Дублирование функций различными подразделениями.
Когда несколько исполнителей выполняют одни и те же функции, но, например, в разных подразделениях. Можно предположить, что автоматизация этого процесса позволит уменьшить объем работ сотрудников и сократить места выполнения процесса, перенаправив потоки данных.
2) Неэффективное распределение обязанностей между исполнителями.
Например, когда исполнители циклически передают друг другу результаты своей работы. При подобной организации труда, возникновение затора на одном рабочем месте неминуемо вызывает простой на связанном.
3) Наличие процессов, производящие невостребованные продукты.
Если продукт процесса не используется далее никакими заинтересованными лицами, то вероятно в нем нет необходимости.
4) «Провисание» зон ответственности на стыке процессов.
Когда один исполнитель вроде выполнил свою функцию и выдал результат, но передача его на следующий этап не регламентирована, и следующий в цепочке исполнитель не готов использовать это результат по тем или иным причинам.
5) Пересечение полномочий в процессах и т.д.
Например, когда ресурс поступает на вход бизнес-процесса, в котором исполнителем является не конкретный сотрудник, а подразделение. При этом если нет четкого регламента распределения в подразделении входящих ресурсов между сотрудниками, может возникнуть проблема невыполненных обязательств.
6) Прочее…
Есть и другие нотации описания бизнес-процессов. Инструмент BPMN мы рассмотрим в следующей части.
