1 © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 2 Разработка архитектуры бизнес-процессов компании в Business Studio Владимир Репин Москва, 2019 год © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 3 В книге представлена практическая методика формирования архитектуры бизнеспроцессов компании в среде Business Studio с использованием нотации IDEF0. Книга может быть полезной как при выполнении проекта разработки архитектуры процессов, так и для изучения особенностей применения нотации IDEF0. Представленные методические подходы могут быть адаптированы и использованы при проектировании архитектуры процессов в ARIS и другом программном обеспечении. © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 4 СОДЕРЖАНИЕ 1. ВВЕДЕНИЕ. ЗАЧЕМ НУЖНА АРХИТЕКТУРА ПРОЦЕССОВ КОМПАНИИ? . 6 1.1. 1.2. 1.3. 1.4. 1.5. 1.6. ДЛЯ КОГО И ДЛЯ ЧЕГО НАПИСАНА ЭТА КНИГА ...................................................................................................... 6 ФУНКЦИОНАЛЬНЫЙ И ПРОЦЕССНЫЙ ПОДХОД К УПРАВЛЕНИЮ ............................................................................... 6 НЕОБХОДИМЫЕ ОПРЕДЕЛЕНИЯ ......................................................................................................................... 8 ИЕРАРХИЧЕСКОЕ ПРЕДСТАВЛЕНИЕ БИЗНЕС-ПРОЦЕССОВ....................................................................................... 11 ЦЕЛИ СОЗДАНИЯ АРХИТЕКТУРЫ БИЗНЕС-ПРОЦЕССОВ .......................................................................................... 14 ТРЕБОВАНИЯ К АРХИТЕКТУРЕ БИЗНЕС-ПРОЦЕССОВ КАК К ОБЪЕКТУ УПРАВЛЕНИЯ...................................................... 15 2. МЕТОДИКА ПОСТРОЕНИЯ АРХИТЕКТУРЫ ПРОЦЕССОВ: ОБЩИЙ ОБЗОР ....................................................................................................................................... 17 2.1. 2.2. 2.3. 3. ПОШАГОВАЯ МЕТОДИКА ПОСТРОЕНИЯ АРХИТЕКТУРЫ БИЗНЕС-ПРОЦЕССОВ КОМПАНИИ ........................................... 17 ИНСТРУМЕНТ BUSINESS STUDIO ....................................................................................................................... 18 ТРЕБОВАНИЯ К РЕСУРСАМ ............................................................................................................................... 18 РАЗРАБОТКА МОДЕЛИ ОРГАНИЗАЦИОННОЙ СТРУКТУРЫ ....................... 20 3.1. 3.2. 3.3. 3.4. ФОРМИРОВАНИЕ СПРАВОЧНИКА ОРГ. СТРУКТУРЫ КОМПАНИИ ............................................................................. 20 ФОРМИРОВАНИЕ ДИАГРАММЫ ОРГСТРУКТУРЫ КОМПАНИИ................................................................................. 24 РЕКОМЕНДАЦИИ ПО ИМЕНОВАНИЮ ПОДРАЗДЕЛЕНИЙ И ДОЛЖНОСТЕЙ ................................................................. 27 РЕКОМЕНДАЦИИ ПО СОЗДАНИЮ И ИМЕНОВАНИЮ РОЛЕЙ ................................................................................... 27 4. ФОРМИРОВАНИЕ РЕЕСТРОВ ФУНКЦИОНАЛЬНЫХ БИЗНЕСПРОЦЕССОВ ПОДРАЗДЕЛЕНИЙ И ОСНОВНЫХ СПРАВОЧНИКОВ ................... 28 4.1. 4.2. 4.3. 4.4. ФОРМИРОВАНИЕ РЕЕСТРОВ ФУНКЦИОНАЛЬНЫХ БИЗНЕС-ПРОЦЕССОВ ................................................................... 28 СПРАВОЧНИК «ОБЪЕКТЫ ДЕЯТЕЛЬНОСТИ» ....................................................................................................... 35 ФОРМИРОВАНИЕ СПРАВОЧНИКОВ ДОКУМЕНТОВ, ИНФОРМАЦИИ И МАТЕРИАЛЬНЫХ РЕСУРСОВ ................................ 36 ФОРМИРОВАНИЕ СПРАВОЧНИКОВ ПРОГРАММНЫХ ПРОДУКТОВ, БАЗ ДАННЫХ, ТЕРМИНОВ ....................................... 39 5. РАЗРАБОТКА КОНТЕКСТНОЙ МОДЕЛИ БИЗНЕСА В НОТАЦИИ IDEF0 ... 40 6. МЕТОДЫ ГРУППИРОВКИ БИЗНЕС-ПРОЦЕССОВ НА ВЕРХНЕМ УРОВНЕ49 6.1. 6.2. ВАРИАНТ 1. МОДЕЛИ ФУНКЦИОНАЛЬНЫХ БИЗНЕС-ПРОЦЕССОВ ПОДРАЗДЕЛЕНИЙ .................................................. 49 ВАРИАНТ 2. МОДЕЛЬ БИЗНЕС-ПРОЦЕССОВ КОМПАНИИ НА ОСНОВЕ ФУНКЦИОНАЛЬНЫХ БИЗНЕС-ПРОЦЕССОВ ПОДРАЗДЕЛЕНИЙ ....................................................................................................................................................... 51 6.3. ВАРИАНТ 3. МОДЕЛЬ БИЗНЕС-ПРОЦЕССОВ КОМПАНИИ НА ОСНОВЕ ГРУППИРОВКИ ПО БАЗОВЫМ ФУНКЦИЯМ БИЗНЕСА (ЦЕПОЧКЕ СОЗДАНИЯ ЦЕННОСТИ) ................................................................................................................................. 51 6.4. ВАРИАНТ 4. ОТДЕЛЬНЫЕ МОДЕЛИ СКВОЗНЫХ БИЗНЕС-ПРОЦЕССОВ ...................................................................... 59 7. ПРАВИЛА ИСПОЛЬЗОВАНИЯ НОТАЦИИ IDEF0 ................................................ 62 7.1. 7.2. 7.3. 7.4. 7.5. 7.6. 7.7. 7.8. 7.9. 7.10. 8. КРАТКИЕ СВЕДЕНИЯ О НОТАЦИИ ...................................................................................................................... 62 ПРОЦЕССЫ И СТРЕЛКИ НА ДИАГРАММЕ ............................................................................................................ 63 ВЕТВЛЕНИЕ И СЛИЯНИЕ СТРЕЛОК ..................................................................................................................... 65 СТРЕЛКИ ДЛЯ УПРАВЛЕНИЯ И ОТЧЕТНОСТИ ....................................................................................................... 66 ОБРАТНАЯ СВЯЗЬ ПО ИНФОРМАЦИИ И УПРАВЛЕНИЮ .......................................................................................... 70 ВНЕШНИЕ ССЫЛКИ ........................................................................................................................................ 71 ТУННЕЛЬНЫЕ СТРЕЛКИ И МЕЖДИАГРАММНЫЕ ССЫЛКИ ...................................................................................... 72 СТРЕЛКИ СНИЗУ (СТРЕЛКИ «МЕХАНИЗМОВ»)..................................................................................................... 74 ДЕКОМПОЗИЦИЯ ПРОЦЕССА ........................................................................................................................... 75 ВЫХОДЫ НА ВЫШЕСТОЯЩУЮ ДИАГРАММУ ....................................................................................................... 77 РАЗРАБОТКА МОДЕЛИ БИЗНЕС-ПРОЦЕССОВ В НОТАЦИИ IDEF0 ............ 82 © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 5 8.1. МОДЕЛЬ БИЗНЕС-ПРОЦЕССОВ КОМПАНИИ НА ОСНОВЕ ФУНКЦИОНАЛЬНЫХ БИЗНЕС-ПРОЦЕССОВ ПОДРАЗДЕЛЕНИЙ. ИНЖЕНЕРНЫЙ ВАРИАНТ. ............................................................................................................................................. 82 8.2. МОДЕЛЬ БИЗНЕС-ПРОЦЕССОВ КОМПАНИИ НА ОСНОВЕ ФУНКЦИОНАЛЬНЫХ БИЗНЕС-ПРОЦЕССОВ ПОДРАЗДЕЛЕНИЙ. ЭСКИЗНЫЙ ВАРИАНТ. .................................................................................................................................................. 88 8.3. МОДЕЛЬ БИЗНЕС-ПРОЦЕССОВ КОМПАНИИ НА ОСНОВЕ ФУНКЦИОНАЛЬНЫХ БИЗНЕС-ПРОЦЕССОВ ПОДРАЗДЕЛЕНИЙ. ИНЖЕНЕРНЫЙ ВАРИАНТ. ДЕКОМПОЗИЦИЯ..................................................................................................................... 92 8.4. МОДЕЛЬ БИЗНЕС-ПРОЦЕССОВ КОМПАНИИ НА ОСНОВЕ ГРУППИРОВКИ ПО БАЗОВЫМ ФУНКЦИЯМ БИЗНЕСА (ЦЕПОЧКЕ СОЗДАНИЯ ЦЕННОСТИ) .............................................................................................................................................. 103 8.5. МОДЕЛЬ СКВОЗНОГО БИЗНЕС-ПРОЦЕССА ........................................................................................................ 108 9. ИНТЕГРАЦИЯ МОДЕЛЕЙ ПРОЦЕССОВ НА РАЗНЫХ УРОВНЯХ................ 119 9.1. 9.2. ИНТЕГРАЦИЯ МОДЕЛЕЙ В НОТАЦИИ IDEF0 И НОТАЦИИ BPMN ......................................................................... 119 ИНТЕГРАЦИЯ МОДЕЛЕЙ В НОТАЦИИ BPMN МЕЖДУ СОБОЙ ............................................................................... 124 10. ЗАКЛЮЧЕНИЕ .............................................................................................................. 130 11. СПИСОК РЕКОМЕНДУЕМОЙ ЛИТЕРАТУРЫ .................................................... 131 © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 6 1. Введение. Зачем нужна архитектура процессов компании? 1.1. Для кого и для чего написана эта книга Вы держите перед собой книгу - краткое практическое пособие по построению архитектуры бизнес-процессов компании с использованием нотаций IDEF0, BPMN и программного продукта Business Studio. В книге достаточно подробно разобраны правила использования нотации IDEF0. Нотация BPMN рассматривается только в части интеграции схем BPMN в общую архитектуру процессов компании. Читателям, которые хотели бы начать использовать BPMN, рекомендую обратиться к книге [3] в «Списке рекомендуемой литературы». Книга посвящена системному подходу к построению архитектуры процессов, а не методу описания некоторых абстрактных упрощенных процессов в нотации IDEF0. Материал требует внимательного, вдумчивого изучения. Архитектура бизнес-процессов является частью общей модели бизнеса и представляет собой базу, платформу для системного внедрения технологий процессного управления в компании. Кроме построения архитектуры, другие методы и инструменты внедрения Системы управления бизнес-процессами компании рассматриваться не будут, так как по этой теме есть ряд вполне актуальных книг (см., например, [1]). Данная книга поможет вам: 1. научиться использовать нотацию IDEF0 для проектирования бизнес-процессов; 2. освоить базовый функционал программы Business Studio в части создания моделей процессов в нотации IDEF0; 3. построить архитектуру бизнес-процессов своей компании, используя представленные в книге методики и рекомендации. Книгу могут использовать как подготовленные читатели (специалисты по орг. развитию, бизнес-аналитики), так и все желающие изучить метод проектирования бизнеспроцессов с использованием нотации IDEF0 (нотация BPMN рассматривается только в части интеграции с моделями в IDEF0). Представленные подходы могут быть использованы при построении архитектуры бизнес-процессов в других нотациях (например, в ARIS VAD) и программных продуктах после некоторой адаптации. Применение методики создания архитектуры бизнес-процессов в книге показано на упрощенном примере некоторой торгово-производственной компании. 1.2. Функциональный и процессный подход к управлению Кратко остановимся на различиях между функциональным и процессным подходом к управлению. На рис. 1 слева показан взгляд на процессы, выполняемые в функциональных подразделениях организации. Можно назвать эти процессы функциональными. Причем это именно процессы, имеющие четкие границы, а не просто © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 7 абстрактные функции типа «Маркетинг» или «Производство». Функциональный процесс – это полноценный процесс, имеющий входы и выходы, технологию и ресурсы. Но выполняется он целиком в рамках конкретного функционального подразделения (отдела, департамента). Функциональный взгляд Процессный взгляд Сквозной бизнес-процесс А 1 2 3 Сквозной бизнес-процесс Б 1 1 2 3 2 4 2 3 3 1 Функциональные процессы 4 Рис. 1. Функциональный и процессный взгляд. Как правило, функциональный процесс сам по себе не создает законченный результат ни для компании в целом, ни для ее клиентов. Этот результат носит промежуточный, частичный характер. Только несколько функциональных процессов, определенным образом взаимодействующих между собой, могут создавать результат, действительно важный для организации и/или ее клиентов (в широком смысле). Справа на рисунке 1 показано, как из функциональных процессов «собраны» два сквозных процесса – А и Б. Часть функциональных процессов невозможно (либо нерационально) отнести к сквозным процессам, но их можно определенным образом сгруппировать в рамках архитектуры. (Чуть ниже я дам определение сквозного процесса). Суть процессного управления в масштабах компании – определение сквозных процессов и организация управления этими процессами за счет назначения владельцев процессов, определения их ответственности и полномочий, выполнения проектов оптимизации процессов, разработки и использования соответствующих целей и показателей для оперативного управления процессами, автоматизации процессов. При этом никто не мешает руководителям подразделений применять базовые методы процессного управления к своим функциональным процессам. Четкое определение их границ, регламентация и автоматизация помогут повысить эффективность работы организации. Эффект, безусловно, будет. Но не такого масштаба, как от оптимизации и управления сквозными процессами масштаба компании в целом или ее крупных сегментов. © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 8 1.3. Необходимые определения При построении архитектуры все участники проекта и вовлеченные сотрудники компании должны говорить на одном языке, т.е. использовать одни и те же термины, вкладывая в них соответствующие смыслы. В качестве рабочего варианта можно предложить следующую систему терминов. Архитектура бизнес-процессов - совокупность определенных в компании взаимосвязанных бизнес-процессов различного уровня, представленных в виде моделей в нотациях IDEF0 и BPMN (eEPC), созданных с использованием программного продукта Business Studio (ARIS, iGrafx, Elma и т.п.). Приведу еще определение архитектуры системы из Википедии: Архитектура системы — принципиальная организация системы, воплощенная в её элементах, их взаимоотношениях друг с другом и со средой, а также принципы, направляющие её проектирование и эволюцию. Если во втором определении заменить слово «элемент» на «бизнес-процесс», то получится хорошее определение архитектуры бизнес-процессов компании. Далее в книге вы сможете ознакомиться как раз с принципами методологии построения такой системы с использованием нотации IDEF0 и программного продукта Business Studio. Можно дать и другие определения архитектуры. Вам важно выбрать какое-то одно и постоянно использовать его при выполнении проекта. Построение архитектуры возможно только с учетом функциональных особенностей и ограничений соответствующего программного продукта. Возможности построения архитектуры в Power Point, на бумаге или в виде липких желтых листочков на стене офиса не рассматриваются в качестве серьезного варианта, хотя могут использоваться на первых порах в рамках групповой работы. Архитектура состоит из процессов. Приведу рабочее определение: Бизнес-процесс – устойчивая, целенаправленная совокупность взаимосвязанных видов деятельности, которая по определенной технологии преобразует входы в выходы, представляющие ценность для потребителя. На рис. 2 бизнес-процесс схематично представлен, как объект управления. Предложенная схема является универсальной и может применяться для процесса любого уровня сложности там, где это целесообразно. Чтобы определить бизнес-процесс, необходимо установить его границы. Для этого нужно определить входы и выходы, а также условия начала и завершения процесса (события). Для процессов большого масштаба (например, «Продажа» в крупной компании), определять стартовые и завершающие события можно весьма укрупненно, для содержательного анализа. Для процессов на нижнем уровне (т.н. операционных © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 9 процессов), определение четких стартовых и завершающих событий является обязательным, в том числе для решения задачи автоматизации. Замечу, что при создании графических диаграмм в нотации IDEF0, понятие «Событие» не используется, так как нотация IDEF0 не является нотаций типа Work Flow 1. Владелец процесса Цели и показатели для управления процессом Входы (нагрузка на процесс) Условия начала БИЗНЕС-ПРОЦЕСС Клиент Технология Входы Выходы Ресурсы Очередь Условия завершения Выходы (результат) Регламенты Производительность Рис. 2. Бизнес-процесс, как объект управления. Входы и выходы - это информационные или материальные объекты: файлы с информацией, документы на бумажном носителе, материалы для производства и т.п. Требования к каждому входу/выходу должны быть четко определены (специфицированы) в документах и согласованы со всеми заинтересованными сторонами: с поставщиками и потребителями процесса, руководством вышестоящего уровня и, в некоторых случаях, с государством. Кроме входов/выходов важно определить условия начала и завершения процесса. Процесс может «запускаться» в определенное время («по таймеру») или при получении управляющего сообщения (например, устного распоряжения руководителя). Наличие готовых (например, сложенных горкой) входов еще не означает, что процесс нужно запускать. Так же необходимо четко определить условия завершения процесса, т.е. в каких случаях можно считать, что процесс завершен. Например, документы переданы, товар упакован и помещен на место хранения, клиент подтвердил получение документа и т.п. Опять же, условия завершения не являются выходами процесса. На рис. 2 показано, что бизнес-процесс выполняется по определенной «технологии». По сути, это продуманная система действий, выполнение которых приводит к получению результата с заданными, повторяющимися характеристиками. Для практического выполнения нужны ресурсы – люди, оборудование, информационные системы и проч. Они связаны между собой в том смысле, что отсутствие необходимого оборудования или людей повлечет за собой изменение технологии. Наоборот, цель изменения (оптимизации) бизнес-процесса может повлечь за собой изменения в требованиях к ресурсам. 1 Work Flow – поток работы. © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 10 Технология выполнения бизнес-процесса хранится, как минимум, в виде знаний и навыков в головах сотрудников, которые его выполняют. Как правило, знания о технологии выполнения процесса фиксируются в регламентах (положениях, инструкциях). Кроме того, требования к выполнению процесса могут быть «зашиты» в информационные системы, которые используются для автоматизации. Но как показывает практика, наличие автоматизации процессов не исключает необходимости создания системы регламентов, по которым выполняется работа. Сотрудники компании должны иметь к ним быстрый и легкий доступ, например, через внутренний web-портал. Слева на рис. 2 показан график нагрузки на бизнес-процесс. Объекты («Входы»), которые нужно обрабатывать, поступают с определенной интенсивностью в течение определенного времени. Например, необходимо обрабатывать партию из 5 деталей каждые 2 минуты. В этом случае график нагрузки будет дискретным – с равномерным интервалом. Другой пример – суточный график количества посетителей для супермаркета, на котором будут видны периоды пиковой нагрузки. Итак, нагрузка на бизнес-процесс – это количество объектов, поступающих на вход процесса, которое нужно обработать за единицу времени. Однако, возможности процесса ограничены, в первую очередь, по ресурсам. Используемая технология выполнения процесса и ресурсы (оборудование, люди) определяют производительность процесса – возможность преобразовывать определенное количество объектов за единицу времени. На рис. 2 снизу показан график производительности процесса. На нем видны ступеньки. Это может быть, например, из-за того, что вводилось/выводилось из эксплуатации оборудование, добавляли людей в рабочие смены и т.п. Что будет с объектами, которые бизнес-процесс не в состоянии пропустить через себя из-за ограничений по производительности? Они встанут в очередь – см. соответствующий график на рис. 2. Нагрузка на процесс и его текущая производительность определяют, сколько входящих объектов могут быть обработаны на единицу времени. На рис. 2 справа показан график выходов (результатов) процесса. На рис. 2 показаны цели и показатели, а также владелец бизнес-процесса. Цели и показатели нужны для управления процессом. Производительность является одним из ключевых показателей. Кроме нее, важно измерять результативность (план/факт по полученным результатам), эффективность (отношение результата к затраченным на его получение ресурсам), показатели качества (например, уровень дефектов в выходах процесса). Для организации, как системы ориентированной на достижение целей во внешней среде, важно не просто преобразовывать входы в выходы, а делать это эффективно, т.е. с прибылью для себя. Это означает, что крайне важно измерять и улучшать показатели эффективности процесса. Ответственным за это является владелец процесса: Владелец бизнес-процесса – руководитель, который имеет в своем распоряжении выделенные ресурсы, управляет ходом бизнес-процесса, несет ответственность за достижение поставленных целей. Владельцу подчиняются все выделенные ресурсы процесса. От используемого в компании метода распределения ресурсов зависит степень самостоятельности владельца © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 11 процесса: от мониторинга процесса, до полноценного управления всеми ресурсами (вплоть до привлечения инвестиций). Цели процесса и показатели, которые служат для измерения этих целей, владелец процесса сам себе определять не имеет права. Это должны делать руководители вышестоящего уровня, которые понимают роль этого процесса в общей системе работы организации и в состоянии правильно установить цели и выбрать показатели для измерения степени их достижения (на практике с этим часто бывают проблемы). 1.4. Иерархическое представление бизнес-процессов Для управления традиционной функционально-иерархической организацией человеку нужны иерархические архитектурные представления, в том числе представление выполняемой деятельности (бизнес-процессов). Это одна из видов моделей, на основе которых принимаются решения, например, могут использоваться: финансовая модель, модель здания, геофизическая модель и проч. Модель не должна быть слишком сложной. Эта сложность может стать препятствием для анализа, обоснования и внедрения изменений. Обратимся к рис. 3. - на нем показана пирамида. Наверху пирамиды – один синий четырехугольник («Контекстная диаграмма бизнеса»). Он символизирует компанию в целом, как сложную систему. Она состоит из подсистем – так называемых категорий бизнес-процессов. Каждая из категорий декомпозирована на группы процессов (на рисунке, для простоты, показана декомпозиция только одной категории). Контекстная диаграмма бизнеса Категории бизнеспроцессов Группы процессов Процессы Операционные процессы Рис. 3. Иерархия бизнес-процессов в компании. © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 12 Группа процессов, в свою очередь, декомпозирована на процессы, один из которых разделен на операционные процессы. Каждый операционный процесс включает в себя поток операций (на схеме этот уровень не показан) и так далее. Визуально на рис. 3 показаны четырехугольники различного размера. Чем ближе к основанию пирамиды, тем они меньше. Этот означает, что бизнес-процессы различных уровней отличаются по масштабу. Тем не менее, к каждому из них применимы подходы, как к объекту управления (см. рис. 2). Замечу, что количество процессов при переходе сверху-вниз растет в геометрической прогрессии. На четвертом уровне количество операций процессов (шагов, задач) в средней и крупной организации может достигать нескольких тысяч. На рис. 3 не показаны связи между бизнес-процессами, так как это чрезмерно усложнило бы схему. Но вы мысленно можете представить себе большое количество стрелок, соединяющих между собой четырехугольники. Это представление будет одним из возможных для понимания сути иерархической архитектуры бизнес-процессов компании как сложной системы. Бизнес-процессы - элементы различных уровней иерархии - нужно как-то их называть. Можно, например, использовать способ, представленный организацией APQC (American Productivity & Quality Center) 2 в так называемой модели Cross Industry Process Classification Framework (PCF). В рамках этой модели определены следующие уровни процессной архитектуры (перевод автора): Уровень 1 – Категория – представляет наиболее высокий уровень процессов в организации. Уровень 2 – Процессная группа – указывает на следующий уровень процессов и представляет собой группу процессов. Уровень 3 – Процесс - это следующий уровень декомпозиции после процессной группы. Он может включать ключевые элементы, необходимые для выполнения процесса так же, как и элементы, связанные с вариантами и переделками. Уровень 4 - Операция - показывает ключевые события, возникающие при выполнении процесса. Уровень 5 - Задача - представляет собой следующий уровень иерархической декомпозиции после операций. Задачи являются более раздробленными и в значительной степени зависят от отрасли. Видно, что в APQC, по сути, нет четких определений уровней. Есть лишь некоторое их описание. Взяв названия уровней из APQC, в ряде проектов я использовал следующие определения: Категория бизнес-процессов - совокупность групп бизнес-процессов, объединенных по критериям общности поставленных целей и единства методов создания ценности для потребителей. 2 Американский центр производительности и качества. © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 13 Группа бизнес-процессов - совокупность процессов, объединенных по критериям общности поставленных целей и единства методов создания ценности для потребителей. Процесс - совокупность взаимосвязанных операционных процессов, выполняемая одним или несколькими субъектами (подразделение, должность, роль). Операционный процесс - ограниченная совокупность операций, выполняемая одним и более субъектами (должность, роль). Операция процесса - ограниченная совокупность транзакций, выполняемая одним субъектом (должность, роль) или модулем информационной системы/программного продукта. Транзакция - часть операции, которая может быть выполнена только целиком, либо вообще не выполнена. Видно, что категории процессов определены через группы и т.д. На практике это приводит к сложностям при идентификации элементов архитектуры на верхних уровнях. Стройной теории в данном случае нет, но задача построения архитектуры практически решается в различных средствах моделирования, причем часто используются именно термины «Категория», «Процессная группа» и т.д. С технической точки зрения проще и удобнее было бы вообще не вводить определения для процессов разных уровней иерархии, а просто называть «Процесс 1-ого уровня», «Процесс 2-ого уровня» и т.п. При этом принципиально важными являются следующие три момента: 1. на определенных уровнях сверху (1-3, иногда 1-4) для описания процессов могут использоваться модели только структурного типа (например, нотация IDEF0); 2. с некоторого уровня (4 или ниже) для описания процессов используется принципиально другой тип моделей – Work Flow (например, нотации eEPC или BPMN); 3. необходимо корректно увязывать между собой структурные модели (IDEF0) и модели типа Work Flow (eEPC и BPMN) в рамках единой архитектуры бизнеспроцессов организации. Выше я использовал термин «структурная модель». Приведу общее определение из Википедии: «Структура — определённая взаимосвязь, взаиморасположение составных частей, строение, устройство чего-либо». В философии «Структура — совокупность связей между частями объекта». Поэтому нужно сделать следующее определение: Структурная модель бизнес-процесса – модель, включающая в себя части процесса и связи между этими частями, представляющие собой однонаправленный поток объектов (информация, документы, материальные ресурсы). Модель Work Flow бизнес-процесса - модель, включающая в себя части процесса и связи между этими частями, показывающие последовательность выполнения частей процесса во времени. © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 14 1.5. Цели создания архитектуры бизнес-процессов Архитектура бизнес-процессов может и должна рассматриваться как инструмент управления компанией. Цели использования архитектуры бизнес-процессов для различных категорий заинтересованных лиц могут быть следующие. Топ-менеджмент и собственники компании: • архитектурная интеграция различных подсистем управления на основе единой процессной модели компании; • четкое определение структуры и границ бизнес-процессов (в т.ч. сквозных), зон ответственности руководителей на всех уровнях и возможность их объективного изменения; • возможность анализа и обоснования изменений в организационной структуре и бизнес-процессах; • возможность управлять бизнес-процессами, в т.ч. за счет определения целей и показателей; • создание единой процессной платформы для всех проектов и инициатив по изменению деятельности компании, в первую очередь, по автоматизации системы синхронизованных между собой бизнес-процессов (в BPM-приложениях, СЭД); • наличие актуальной регламентной базы по бизнес-процессам; • накопление знаний по выполнению и совершенствованию бизнес-процессов. Руководители и специалисты: • четкое определение структуры и границ выполняемых бизнес-процессов, своих зон ответственности; • возможность управлять бизнес-процессами, в т.ч. за счет определения целей и показателей; • возможность быстрого доступа к актуальной нормативной базе по бизнеспроцессам; • возможность использовать модели процессов для разработки требований к автоматизации и настройке систем класса BPMS, СЭД и др.; • возможность использования базы знаний для совершенствования бизнеспроцессов; • возможность обучать новых сотрудников. Процессный офис (Отдел организационного развития): • архитектурная интеграция различных подсистем управления на основе единой процессной модели компании; • создание единой процессной платформы для всех проектов и инициатив по изменению деятельности, в первую очередь, по автоматизации системы синхронизованных между собой бизнес-процессов (в BPM-приложениях, СЭД и др.); • возможность анализа бизнес-процессов (в т.ч. с использованием имитационного моделирования) и разработки новых версий процессов в рамках проектов развития; © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 15 • • поддержание актуальной регламентной базы по бизнес-процессам; накопление знаний по выполнению и совершенствованию бизнес-процессов. 1.6. Требования к архитектуре бизнес-процессов как к объекту управления Архитектура бизнес-процессов компании сама по себе является сложной системой, т.е. объектом, требующим управления. В рамках архитектуры приходится использовать модели разного типа. Как правило, на 1-4 уровне используются диаграммы процессов структурного типа, например, сформированные в нотации IDEF0. На нижележащих уровнях используются диаграммы класса Work Flow, например, разработанные в нотации BPMN (eEPC). На структурных диаграммах в нотации IDEF0 стрелки используются для моделирования потоков информационных и материальных объектов. На диаграммах в нотации BPMN базовый тип связи – это стрелка типа Sequence flow (поток управления). Стрелки такого типа показывают хронологический порядок, в котором выполняются операции процесса. Кроме того, на схемах в нотации BPMN можно дополнительно показывать потоки информации. Переход от диаграммы одного типа к диаграммам другого типа сопряжен с рядом проблем методического характера, которые можно практически решить с учетом возможностей конкретной среды моделирования, в частности, Business Studio. Еще одной практической проблемой является неравномерный рост иерархии сверхувниз. Это означает, что некоторые «ветки» архитектуры могут быть глубже других. Для их адекватного описания приходится использовать структурные диаграммы в нотации IDEF0 на большем количестве уровней, чем 3. Поэтому один бизнес-процесс может быть представлен несколькими уровнями диаграмм в архитектуре процессов. В следующей таблице представлены уровни архитектуры бизнес-процессов, их названия, возможное количество уровней диаграмм. Таблица 1. Уровни бизнес-процессов. Уровень в архитектуре Уровень 0 Уровень 1 Уровень 2 Уровень 3 Уровень 4 Уровень 5 Уровень 6 Описание Контекстная диаграмма бизнеса Категории процессов Группы процессов Процессы Операционные процессы Операции Транзакции Возможное количество уровней диаграмм Используемая нотация моделирования 1 IDEF0 1 1 1-2 1-2 1 1 IDEF0 IDEF0 IDEF0 BPMN BPMN BPMN Тип диаграммы Структурная диаграмма Диаграмма потока работы Из таблицы 1 видно, что на уровне 3 «Процессы» может быть два уровня диаграмм. Так же это возможно на уровне 4 «Операционные процессы». Обратите внимание начиная с уровня 4, для формирования графических схем используется нотация BPMN. Сформулируем практические требования, которым должна удовлетворять архитектура бизнес-процессов для достижения всех целей, связанных с ее использованием. Ниже в книге проводится обоснование этих правил и соответствующие примеры. Пока предлагаю только ознакомиться с ними. По ходу чтения книги или после полного освоения, © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 16 представленного в ней материала, вы можете вернуться и осмыслить эти правила, находясь на более глубоком уровне понимания вопроса. Таблица 2. Требования к архитектуре бизнес-процессов. № 1 2 3 4 5 6 7 Требование Иерархическая модель, включающая связанные между собой схемы бизнес-процессов на 1-6 уровнях Все бизнес-процессы имеют реальные связи (не абстрактно-обобщенные) со всеми другими бизнеспроцессами, с которыми они взаимодействуют Все связи между бизнес-процессами должны представлять собой потоки реально существующих объектов (информация, документы, материальные ресурсы), которые используются в организации Бизнес-процессы должны быть связаны по входам/выходам в соответствии со своим уровнем иерархии Движение объекта не должно прерываться в одной, а потом возобновляться в другой части архитектуры Должны отсутствовать потоки, соединяющие напрямую бизнес-процессы, находящиеся в разных иерархических ветках архитектуры Бизнес-процессы, описанные в нотации BPMN, должны быть корректно синхронизованы между собой по событиям Краткая формулировка требования (принципа) Иерархия Реальность связей Потоки объектов Соответствие по масштабу Непрерывность движения объекта Отсутствие междиаграммных ссылок Синхронизация по событиям Эти требования, по сути, говорят о том, что все бизнес-процессы в архитектуре должны быть корректно увязаны между собой по входам/выходам потоками информации и материальных объектов, а также синхронизованы по условиям начала и завершения. Говоря «все», я не подразумеваю связи каждого процесса со всеми остальными. Речь идет только о тех процессах, которые реально взаимодействуют между собой. Если архитектура будет построена не с использованием реального потока объектов, а при помощи некоторых абстрактных, обобщенных стрелок, то практически определить границы бизнес-процессов в рамках модели не получится. Замечу, что в Business Studio технически можно определить руководителей, ответственных за выполнение процессов, без определения входов/выходов процессов. Для этого достаточно иметь реестр процессов в виде справочника. Назначение ответственных осуществляется путем определения связи между субъектом (должность, роль) и процессом (через интерфейс системы). Однако с точки зрения практики, такое назначение будет довольно абстрактным до тех пор, по четко не будут определены границы соответствующих процессов. Для определения границ нужно четко определить, какие документы (информация) и материальные ресурсы пересекают эти границы. Нужно определить спецификации, показатели оценки, методы и средства измерения. Но надо четко понимать, что детальное определение границ всех процессов по входам/выходам может повлечь за собой большой объем работы по идентификации и занесению в среду моделирования соответствующей информации о процессах (например, по ходу так называемой «паспортизации процессов»). При создании архитектуры процессов компании нужно четко понимать возможности и знать ограничения, связанные как с используемой нотацией, таки и функционалом Business Studio. © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 17 2. Методика построения архитектуры процессов: общий обзор 2.1. Пошаговая методика построения архитектуры бизнес-процессов компании Общая методика построения архитектуры бизнес-процессов компании в Business Studio включает в себя следующие этапы: 1. Разработка модели организационной структуры компании. 2. Формирование реестров функциональных бизнес-процессов подразделений и основных справочников. 3. Создание контекстной модели бизнеса в нотации IDEF0 (уровень «0»). 4. Разработка моделей (или реестров) категорий бизнес-процессов в нотации IDEF0 (уровень «1»). 5. Разработка моделей (или реестров) процессных групп в нотации IDEF0 (уровень «2»). 6. Разработка моделей (или реестров) процессов в нотации IDEF0 (уровень «3»). 7. Разработка моделей операционных процессов в нотации BPMN (уровни «4» и «5»). 8. Перегруппировка объектов в справочниках объектов деятельности (если будет принято такое решение). Методика разработана с учетом ее применения в конкретной среде моделирования, а именно – в Business Studio. При использовании другого программного обеспечения Методику необходимо скорректировать. Этап 1. Для каждого бизнес-процесса в архитектуре должны быть определены исполнители и ответственные. Ими могут являться подразделения, должности или роли. Поэтому на первом этапе целесообразно создать модель организационной структуры компании в Business Studio. Этап 2. Необходимо выполнить анализ деятельности подразделений и определить реестр бизнес-процессов (2-3 уровня представления) для каждого функционального подразделения. Реестры заносят в Business Studio в виде иерархического справочника. Заполняются справочники документов, информации, материальных ресурсов, информационных систем, баз данных, терминов. Группировка объектов в справочниках осуществляется на основе структуры функциональных подразделений. Таким образом, получаем реестры функциональных процессов подразделений. Этап 3. Разрабатывается контекстная модель бизнеса (диаграмма А-0, уровень «0») (или отдельного сквозного процесса 3). Для этого определяются и группируются поставщики и потребители компании, а также другие субъекты, которые с ней взаимодействуют. Определяются входы/выходы для бизнеса компании в целом. Этап 4. Выполняется анализ деятельности компании. Выбирается принцип группировки категорий процессов. Разрабатывается диаграмма А0 (уровень 1). 3 В зависимости от выбранного метода. Об этом будет сказано ниже. © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 18 Этап 5. Разрабатываются модели для каждой процессной категории, включающие группы процессов. При определении групп процессов используются реестры функциональных процессов подразделений, разработанные на Этапе 2. Этап 6. Разрабатываются модели процессов для каждой процессной группы. Процессы переносятся из реестров функциональных процессов подразделений. Этап 7. Разрабатываются модели операционных процессов для каждого процесса. Операционные процессы могут создаваться непосредственно в процессной модели или переноситься из реестров функциональных процессов подразделений. Этап 8. Выполняется перегруппировка объектов в справочниках (кроме справочника «Процессы») для перехода от функциональной к выбранному типу процессной модели. Новая группировка осуществляется в соответствии со структурой категорий и групп процессов компании. На каждом этапе работы возникает ряд практических нюансов и проблемы, которые будут рассмотрены ниже. 2.2. Инструмент Business Studio Разработка архитектуры бизнес-процессов осуществляется в программном продукте Business Studio. Данный программный продукт позволяет создать модель организации, в том числе: модель организационной и ролевой структуры, модели бизнес-процессов, модель объектов деятельности (в виде справочника), модель целей и показателей (в виде справочника и диаграмм стратегических карт). Формирование диаграммы процессов в Business Studio 4 осуществляется при помощи движка MS Visio, встроенного в интерфейс системы. Business Studio позволяет формировать сложные диаграммы бизнес-процессов и увязывать их между собой по входам/выходам. Для дальнейшей работы с книгой вам потребуется Business Studio. Связавшись с автором ([email protected]), можно получить временную полнофункциональную версию системы на срок один месяц для разработки архитектуры бизнес-процессов вашей компании. Вы можете делать задания, представленные в книге, на учебном примере, либо сразу выполнять эти задания для своей компании. 2.3. Требования к ресурсам Для того, чтобы выполнить проект разработки архитектуры бизнес-процессов вашей компании, как минимум, необходимы: 1. Решение Генерального директора (или собственника). 2. Сформированная временная рабочая группа (ВРГ) из 3-5 человек, включая руководителя проекта. © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 19 3. Установленная среда моделирования процессов Business Studio. 4. Ресурс рабочего времени (в рамках проекта): a. Генеральный директор – 6-8 часов. b. Руководители департаментов – 6-8 часов (на каждого). c. Руководители отделов – 12-16 часов (на каждого). d. Участники рабочей группы – от 80 часов (на каждого). 5. Помещение для проведения совещаний ВРГ, проектор, принтер и проч. Проект должен быть инициирован лично первым лицом компании и получить статус приоритетного. Руководителям верхнего и среднего уровня должна быть поставлена задача активно участвовать в разработке архитектуры путем передачи информации о выполняемой деятельности (интервью, ответы на информационные запросы) и участия в совещаниях и презентациях по обсуждению проекта архитектуры бизнес-процессов компании по мере необходимости. © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 20 3. Разработка модели организационной структуры 3.1. Формирование справочника орг. структуры компании Итак, мы приступаем к практической части. Откройте Business Studio. Вы видите интерфейс следующего вида (см. рис. 4). Наверху представлена лента вкладок, которую можно свернуть. В меню «Главная» есть кнопка «Навигатор объектов». Ей можно воспользоваться, если вы случайно закрыли Навигатор. В Навигаторе справа видны закладки: «Процессы», «Субъекты», «Объекты деятельности», «Управление». Это основные справочники Business Studio. Кроме них, в системе много других справочников, которые можно посмотреть, перейдя в меню «Справочники» и нажав кнопку «Все справочники». На Этапе 1 создания архитектуры бизнес-процессов нам потребуется справочник «Субъекты». Необходимо кликнуть по нему левой кнопкой мышки. Откроется справочник субъектов – тоже пока пустой. Рис 4. Business Studio. Пустые справочники. Справочник «Субъекты» в Business Studio служит для описания организационной структуры и структуры ролей. В этом справочнике создается и поддерживается в актуальном состоянии модель организационной структуры компании. Объекты модели © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 21 компании, которые можно создавать в справочнике «Субъекты» в Business Studio принято называть «Субъекты». Таблица 3. Типы субъектов в справочнике «Субъекты». Субъект Изображение Описание Папка Папка для группировки объектов в справочнике Должность Должность, занимаемой сотрудником или несколькими сотрудниками Подразделение Структурное подразделение (департамент, отдел, бюро, группа) Роль Группа должностей или подразделений (например, «Инициатор оплаты счета», «Руководитель, утверждающий план проекта»), выполняющих идентичные действия в рамках бизнес-процесса Внешний субъект Внешняя организация или (поставщик, клиент, государство) её представителя Для начала создадим субъект «Компания» (см. рис. 5). Для этого поместите курсор на любую часть белого поля и нажмите правую кнопу мышки. В появившемся меню выберите «Добавить» и «Подразделение». Присвойте название «Компания» созданному субъекту. Кроме подразделения можно добавить должность, внешнего субъекта и роль. Папки могут использоваться для группировки, например, ролей при создании ролевой структуры компании. Рис. 5. Создание субъекта типа «Подразделение». Выделите мышкой субъект «Компания» в справочнике «Субъекты», по правой кнопке выберите «Добавить» и «Должность», как показано на рисунке 6. Созданный субъект назовите «Генеральный директор». © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 22 Если вы выберите команду «Добавить на этот уровень», то должность появится в справочнике на одном уровне с подразделением «Компания». Так делать в данном случае не нужно. То, что должность находится ниже структурного подразделения по иерархии – нормально. Такой подход к формированию модели организационной структуры используется в Business Studio. К нему просто нужно привыкнуть. Рис. 6. Создание субъекта типа «Должность». Под субъектом «Генеральный директор» создайте следующие подразделения: 1. Департамент продаж. 2. Департамент закупок. 3. Производственный департамент. 4. Технологический департамент. 5. Инженерно-технический департамент. 6. Финансовый департамент. 7. Юридический департамент. 8. Департамент по работе с персоналом. После того, как вы создадите все департаменты, нужно упорядочить их так, как в списке. Для этого выделите мышкой «Департамент продаж». Нажмите правую кнопку мыши и выберите «Свойства». На закладке «Основные» найдите «№ п/п». Поставьте там © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 23 цифру «1» (см. рис. 7). Нажмите кнопку «Сохранить», распложенную слева. Она сохраняется объект модели, не закрывая окно ввода. Напротив, кнопка «Сохранить», расположенная справа, сразу закрывает окно после сохранения. Не закрывая окно, выберите мышкой в справочнике субъект «Департамент закупок». В «№ п/п» поставьте цифру 2. Нажмите левую кнопку «Сохранить». Далее присвойте каждому субъекту номер в соответствии с представленным выше списком. После этого нажмите кнопку «Обновить дерево» в Навигаторе. Рис 7. Сортировка подразделений в справочнике «Субъекты». Рис. 8. Структура департаментов после сортировки. © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 24 Как вы видите, список департаментов в справочнике соответствуют списку, представленному в книге. Далее в справочнике «Субъекты» вам нужно последовательно создать несколько уровней подразделений и должностей, как показано на схеме организационной структуры компании (см. рисунок 10). Фрагмент готового справочника орг. структуры компании показан на рисунке 9. Рис. 9. Фрагмент готового справочника орг. структуры компании. 3.2. Формирование диаграммы оргструктуры компании После того, как вы создали в справочнике все субъекты в соответствии со схемой, представленной на рис.10, необходимо сформировать диаграмму орг. структуры в Business Studio. Для этого нужно два раза кликнуть мышкой по субъекту «Компания». Первичную настройку можно не выполнять. Диаграмма, которую вы увидите, будет разительно отличаться от схемы орг. структуры, представленной на рис. 10. Необходимо ее доработать в части: • расположения названий внутри пиктограмм субъектов (подразделения, должности); • цветов; • расположения объектов на диаграмме. Для того, чтобы схема орг. структуры (автоматически сформированная Business Studio) уместилась на лист формата А4, пришлось существенно изменить ее вручную, передвигая объекты. © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 25 Компания Генеральный директор Департамент продаж Департамент закупок Производственный департамент Технологический департамент Инженернотехнический департамент Финансовый департамент Юридический департамент Департамент по работе с персоналом Директор по продажам Директор по закупкам Директор по производству Главный технолог Главный инженер Финансовый директор Главный юрисконсульт Директор по персоналу Отдел маркетинга Отдел закупок Диспетчерский отдел Цех № 1 Технологический отдел Лаборатория Отдел главного механика Финансовоэкономический отдел Договорной отдел Отдел подбора персонала Учебный центр Начальник отдела маркетинга Начальник отдела закупок Начальник диспетчерского отдела Начальник цеха №1 Начальник технологического отдела Заведующей лабораторией Главный механик Завхоз Начальник финансовоэкономического отдела Начальник договорного отдела Начальник отдела подбора персонала Начальник учебного центра Диспетчер Мастер Технолог Лаборант Инженермеханик Шофер Экономист Менеджер Менеджер по подбору персонала Менеджер учебного центра Административнохозяйственный отдел Дизайнер Менеджер по логистике Маркетолог Менеджер по закупкам Рабочий Отдел контроля качества Слесарь Бухгалтерия Юридический отдел Отдел кадров Отдел продаж Склад Цех № 2 Начальник отдела контроля качества Отдел главного энергетика Главный бухгалтер Начальник юридического отдела Начальник отдела кадров Начальник отдела продаж Начальник склада Начальник цеха №2 Контролер качества Главный энергетик Старший бухгалтер Юрист Инспектор по кадрам Инженерэнергетик Бухгалтер Страший менеджер по продажам Кладовщик Мастер Менеджер по продажам Карщик Рабочий Грузчик © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 26 Рис. 10. Организационная структура компании. © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 27 Вы можете ознакомиться подробнее с функционалом формирования и настройки орг. диаграмм, внимательно изучив «Справку» Business Studio (меню «Помощь/Вызов справки»). Детальное рассмотрение функционала Business Studio выходит за рамки этой книги. Кстати, верхняя «Лента вкладок» была свернута для экономии места. Это легко сделать самостоятельно. 3.3. Рекомендации по именованию подразделений и должностей При формировании справочника организационной и ролевой структуры («Субъекты») в Business Studio необходимо придерживаться определенных правил: • моделирование организационной структуры всегда начинается с субъекта типа «Подразделение». Далее субъекты типов «Подразделение» и «Должность» чередуются в иерархическом порядке; • допускается показывать в справочнике должность подчиненного сразу под должностью руководителя, если в подразделении не определены нижестоящие структурные подразделения (пример: для «Начальник отдела…» подчиненный объект модели - субъект «Специалист...»); • требования к формулировке названий подразделений: o название подразделения указывается с заглавной буквы без точки в конце; o в названии не должны повторяться названия подразделений вышестоящего уровня (например, «Отдел … Управления ... Департамента»); o сокращения не допускаются; • требования к формулировке названий должностей: o название должности указывается с заглавной буквы без точки в конце; o в названии руководящей должности должно быть указано название управляемого подразделения со строчной буквы (например, «Руководитель департамента по продажам»); o для должности, не являющейся руководящей, использование названия подразделения в названии должности не допускается; o сокращения не допускаются. 3.4. Рекомендации по созданию и именованию ролей Роли создаются отдельно от иерархического списка подразделений и должностей в справочнике «Субъекты» и группируются по папкам. Названия папок должны соответствовать названиям категорий бизнес-процессов (или сквозных процессов). Внутри папок для группировки ролей возможно создание папок нижележащего уровня. В этом случае названия папок должны соответствовать названиям процессов следующего уровня (процессные группы, процессы). Для бизнес-процессов ниже уровня «Процессы» группировка ролей по папкам не выполняется. Присваивание ролей для должности осуществляется через вкладку «Роли субъекта» для субъекта типа «Должность». Одна должность может быть связана с несколькими ролями и на одну роль могут быть назначены разные должности. При создании ролей в Business Studio необходимо придерживаться определенных правил: © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 28 • • • • • • • в названии роли допускается использование оборотов «Менеджер по…» (в случае, если такое название отсутствует в штатном расписании) и «Сотрудник, ответственный за …»; название роли должно отражать основную функцию роли в процессе (Пример: «Менеджер по регистрации претензий по качеству готовой продукции…»); если две роли имеют похожие формулировки, но относятся к разным бизнеспроцессам, то название каждой роли должно подчеркивать принадлежность к конкретному бизнес-процессу (пример: «Регистратор приказов по персоналу» и «Регистратор приказов по основной деятельности»); название роли должно иметь следующую структуру: существительное + «конкретизирующее дополнение»; количество слов в названии роли не должно превышать 8 слов, не включая предлоги, союзы и междометия (пример: «Регистратор приказов по основной деятельности»); исключениями из предыдущих пунктов являются устоявшиеся названия, принятые в бизнес-среде (пример: «Системный администратор»); в названиях ролей допускаются только общепринятые сокращения информационных систем (например, 1С) и сокращения из глоссария Business Studio. 4. Формирование реестров функциональных бизнес-процессов подразделений и основных справочников 4.1. Формирование реестров функциональных бизнес-процессов После формирования модели орг. структуры можно приступить к анализу деятельности функциональных подразделений компании. Участники ВРГ (временной рабочей группы) должны ознакомиться с нормативно-методическими документами, регламентирующими деятельность подразделений. Затем проводятся интервью с руководителями подразделений, цель которых – собрать информацию и сформировать реестры бизнес-процессов функциональных подразделений. Функциональные бизнеспроцессы можно заносить сразу в Business Studio следующим образом - см. рис. 11. Обратите внимание на следующее: 1. В справочнике «Процессы» создана папка «Функциональные бизнес-процессы». 2. В этой папке созданы папки следующего уровня в соответствии с организационной структурой – указаны названия Департаментов и отделов. 3. В папке отдела (в данном примере – это нижний уровень) создана модель в нотации IDEF0, диаграмма А-0 названа «Контекст», диаграмма А0 названа «Процессы отдела…»; 4. Определены функциональные бизнес-процессы отделов. © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 29 Рис.11. Группировка функциональных бизнес-процессов компании. Обратите внимание на следующие особенности используемого метода: • папки с названием должностей сотрудников не создаются и функциональные процессы уровня сотрудников в этих папках не определяются; • для формализации процессов, выполняемых руководителями (целеполагание, планирование, организация, контроль, принятие решений и проч.), созданы специальные папки с соответствующими названиями. Кстати индексы А1 и т.п., которые вы видите, автоматически созданы системой Business Studio с учетом принятых правил использования нотации IDEF0. При желании, эти индексы можно изменить или вообще отключить. Сокращение ТКП означает «Технико-коммерческое предложение». Сокращение ГП означает «Готовая продукция». © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 30 В Business Studio для каждого процесса должны быть определены исполнители. Для этого нужно открыть по правой кнопке «Свойства» процесса, найти слева вкладку «Основные» и в списке «Субъекты» выбрать соответствующее подразделение из справочника «Субъекты» (или перетащить из справочника «Субъекты» мышкой). Так же нужно выбрать тип связи «выполняет». На рис. 12 показан пример. Мышкой выбрать процесс «А1 Сбор информации о рынке». По правой кнопке открыты его свойства. Из справочника «Субъекты» выбран «Отдел маркетинга», выбран тип связи «выполняет». Так можно сделать для всех определенных функциональных бизнес-процессов. Рис. 12. Назначение исполнителей бизнес-процессов. Для примера разберем функциональные процессы отдела маркетинга. После обработки интервью, в Business Studio получился следующий реестр процессов этого отдела: 1. А1 Сбор информации о рынке. 2. А2 Проведение опросов клиентов. 3. А3 Анализ цен конкурентов. 4. А4 Формирование рекомендаций по ассортименту и ценам. 5. А5 Размещение рекламных объявлений. 6. А6 Анализ удовлетворенности клиентов. © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 31 7. А7 Разработка дизайна нового продукта. 8. А8 Участие в инициативах по повышению производительности. 9. А9 Переписывание цен конкурентов на выставках. То, что вы получили такой реестр после интервью, не означает, что он является правильными и исчерпывающим. Практика показывает, что приходится запрашивать дополнительную информацию и уточнять реестр еще 2-3 раза. Проблема состоит в субъективности восприятия структуры и границ процессов у руководителей и сотрудников до внедрения процессного управления в компании. Каждый процесс в этом полученном списке (реестре) должен удовлетворять следующим критериям: • соответствие по масштабу; • не быть разовой работой (поручением, проектом); • не являться частью процесса из этого же списка. Общее требование – количество бизнес-процессов в списке не должно превышать 8-9. Если внимательно посмотреть на представленный выше список процессов отдела маркетинга, то сразу видно, что: 1) процесс «А2 Проведение опросов клиентов» является подпроцессом для процесса «А6 Анализ удовлетворенности клиентов»; 2) процесс «А8 Участие в инициативах по повышению производительности», собственно, процессом не является – его можно спокойно удалить из списка; 3) процесс «А9 Переписывание цен конкурентов на выставках» является подпроцессом для процесса «А3 Анализ цен конкурентов»; 4) процесс «А6 Анализ удовлетворенности клиентов» дублируется с таким же процессом в отделе продаж – нужно выяснить почему. Скорее всего, можно будет создать один процесс в рамках Департамента продаж в целом. Далее надо внимательно посмотреть на список функциональных бизнес-процессов отдела – вполне возможно, что будет целесообразно объединить некоторые процессы. Это даст возможность сократить количество процессов в реестре отдела до приемлемого количества (лучше до 3-5). Группировка должна быть не формальной, а реальной. То есть, если процессы связанны по входам/выходам и служат для получения одного результата, их можно смело сгруппировать. На следующем этапе, при формировании диаграмм в IDEF0, будет наглядно видно, как они увязаны в единый бизнес-процесс. На рис. 13 показан результат работы с реестрами отделов маркетинга и продаж. Что изменилось: 1) создан объект «Процессы департамента продаж»; в нем создан подпроцесс «А1 Анализ удовлетворенности клиентов», в который перенесен процесс «Проведение опросов клиентов»; в дальнейшем нужно будет внимательно изучить, какие еще подпроцессы входят в процесс «А1 Анализ удовлетворенности клиентов»; 2) перегруппированы процессы отдела маркетинга; 3) перегруппированы и частично переименованы процессы отдела продаж. © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 32 Вам необходимо в Business Studio выполнить соответствующие действия, либо просто продолжить читать книгу. Для того, чтобы перенести объект, нужно выделить его мышкой и, нажав и не отпуская ее левую кнопку, перенести объект в необходимой место, отпустить левую кнопку мышки. Когда система запросит подтверждение переноса, нажмите «ДА». Рис. 13. Группировка функциональных бизнес-процессов департамент по продажам. На рис. 13 видно, что, например, иерархия процессов отдела маркетинга «растет» неравномерно. Почему это плохо? Это может означать, что процессы, представленные на одном уровне модели, имеют различный масштаб. Это говорит о том, что работа по определению процессов проведена недостаточно тщательно. Важно сформулировать правило «роста иерархии»: «Если в реестре бизнес-процессов одного уровня у какого-то процесса определены подпроцессы (на один уровень вниз), то у всех остальных так же должны быть определены подпроцессы (на один уровень вниз). Если у вас получается неравномерная иерархия, это с большой вероятностью свидетельствует об ошибке выделения процессов. Процессы, если это возможно, нужно перегруппировать, чтобы иерархия была равномерной. Использовать это правило нужно вдумчиво и аккуратно. Обратите внимание, что если у всех процессов определены подпроцессы на один уровень вниз, а у какого-то одного на 2 уровня в низ, то этот факт не рассматривается как проблема. Но целесообразно обратить внимание на те ветки архитектуры, которые «растут» быстрее других. Возможно, стоит подумать и перегруппировать процессы. © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 33 Количество бизнес-процессов на каждом уровне не может быть меньше 2-х (кроме контекстной диаграммы) и больше 8-9. В некоторых компаниях принимают решение допускают наличие 10 процессов на одном уровне (диаграмме в нотации IDEF0). На следующих рисунках 14-15 показаны реестры после проведения дополнительного анализа (путем интервьюирования и обработки информации) и выравнивания глубины функциональных бизнес-процессов отдела маркетинга и продаж. Рис. 14. Функциональные бизнес-процессы отдела маркетинга после выравнивания уровней иерархии. Обратите внимание, что процессы были существенно перегруппированы и названия изменены. Возникли некоторые процессы, информации о которых ранее не было. Точнее она просто не была получена от руководителя и сотрудников отдела маркетинга, либо была зафиксирована некорректно. Процесс «Переписывание цен конкурентов на выставках» был удален из реестра (информация о нем осталась в рабочих материалах проекта). Если бы мы его оставили в качестве подпроцесса для «Сбор информации о конкурентах», то пришлось бы в соответствии с правилом равномерного роста иерархии декомпозировать все подпроцессы А1.1 – А1.4. (см. рис. 14. В дальнейшем, при детальной проработке процессов нижнего уровня, этот процесс, возможно, будет использован. © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 34 Рис. 15. Функциональные бизнес-процессы отдела продаж после выравнивания уровней иерархии. На рисунках видно, что нераскрытыми остались папки с процессами руководителей. Что это за процессы? Это процессы, которые входят в стандартный цикл управления по целям: целеполагание, планирование, организация, мониторинг и контроль, анализ отклонений, принятие и контроль исполнения решений, анализ результатов выполнения процесса за период. Для директора по продажам был получен следующий реестр бизнес-процессов (см. рис. 16): Рис. 16. Процессы директора по продажам. Некоторые процессы из этого списка вызывают сомнения: • «Подписание ТКП для клиента» - это не процесс, а операция в рамках сквозного процесса «Формирование ТКП для клиента». • «Проведение переговоров с ключевыми клиентами» - это, возможно, подпроцесс для процесса «Привлечение новых клиентов». © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 35 • • «Согласование спец. скидок для клиентов» - это не процесс; вполне вероятно, то это одна из операций процесса «Проведение переговоров» или «Разработка спецификаций к договору». «Участие в еженедельных совещаниях у Генерального директор» - вообще не процесс. Кроме того, в реестре процессов директора по продажам нет процессов, связанных с контролем, анализом выполнения планов продаж, управления персоналом департамента по продажам и т.п. На следующем рисунке показан измененный вариант реестра процессов. Рис. 17. Процессы директора по продажам. В моделях процессов используются документы и информация. В Business Studio для их описания служит справочник «Объекты деятельности», который рассмотрен ниже. 4.2. Справочник «Объекты деятельности» В навигаторе Business Studio найдите справочник «Объекты деятельности». В следующей таблице представлены условные обозначения, используемые в этом справочнике. Таблица 4. Условные обозначения справочника «Объекты деятельности» Название Изображение элемента Описание Папка Папка для группировки объектов в справочнике Документы Объект типа «Документы» Бумажные документы Объект типа «Бумажный документ» Электронные документы Объект типа «Электронный документ» ТМЦ Объект типа «ТМЦ» (материальные объекты) Информация Объект типа «Информация» Программные продукты Объект типа «Программные продукты» Базы данных Объект типа «Базы данных» Термины Объект типа «Термины» © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 36 4.3. Формирование справочников материальных ресурсов документов, информации и По ходу обработки информации, полученной при проведении интервью и из внутренних нормативных документов, необходимо формировать в Business Studio справочники документов и материальных ресурсов, т.е. объектов, которые будут использоваться на диаграммах бизнес-процессов в нотации IDEF0. В качестве вспомогательного временного хранилища информации можно использовать файл MS Excel. На рисунке 18 показана начальная структура справочника «Документы». Рис. 18. Структура справочника «Документы». В справочнике «Объекты деятельности» в разделе «Документы/Электронный документ» создана структура папок в соответствии с организационной структурой компании. Поскольку в справочнике документов нельзя перемещать папки вверх-вниз, как в справочнике «Процессы», приходится перед названием каждой папки ставить номер. В папке «01_Отдел маркетинга» показаны документы, которые используются при выполнении деятельности. В папке «02_Отдел продаж» - документы отдела продаж. В Business Studio можно к каждому документу в справочнике привязать реальную форму документа, например, в виде файла docx или pdf. Это означает, что все документы в справочнике можно четко специфицировать. Это важно для последующей стыковки © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 37 процессов по входам/выходам и автоматического формирования регламентирующих документов из Business Studio. Сформулируем правила, которых нужно придерживаться при построении справочника «Документы/Электронный документ». Документ создается в этом справочнике, если: 1) документ существует в электронном виде (файл MS Word или Excel, документ информационной системы и т.п.); 2) форма документа официально утверждена в каком-либо нормативно-методическом документе компании; 3) документ создается при выполнении деятельности соответствующего отдела или поступает извне организации в этот отдел 4. Как быть, если документ сначала формируется в электронной форме, а потом распечатывается и существует уже в бумажной форме? Для этого есть раздел справочника «Бумажный документ». Там нужно создать такую же структуру папок и показать документ под тем же названием. Такое дублирование необходимо только в том случае, если в дальнейшем вы предполагаете отслеживать путь документа через все процессы и выявлять операции, при выполнении которых форма документа изменяется с электронной на бумажную и наоборот. Так же это может быть удобно для анализа доли бумажных документов в обороте. Можно ли в справочнике создавать иерархические структуры документов? Да, можно. Но надо понимать, как это будет использоваться. В данном случае, я рекомендую создавать и показывать отдельно все реально существующие в компании документы. Любая группировка документов будет субъективной (так же, как и любая группировка процессов). Если мы создадим субъективную группировку процессов, а потом помножим ее на субъективную группировку документов, то получим крайне субъективную модель системы. Как быть, если документ не имеет официальной формы, т.е. нечетко структурирован, каждый раз разный и т.п.? Как быть с информацией в виде текста, отправляемого по email? Чтобы не захламлять справочник документов, нужно воспользоваться справочником «Информация». На рисунке 19 представлена структура этого справочника. 4 Формально документ может поступать как входящий, например, в секретариат. Но в справочнике он показывает по принадлежности к конкретному подразделению, либо к компании в целом. © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 38 Рис 19. Структура справочника «Информация». Далее рассмотрим справочник ТМЦ – товарно-материальных ценностей, он строится по такому-же принципу, как и предыдущие два справочника – см. рис. 20. Рис 20. Структура справочника «ТМЦ». В справочнике «ТМЦ» структура папок по отделам выглядит, на первый взгляд, довольно странно. Принцип разнесения материальных объектов по папкам применен такой: ТМЦ попадает в папку подразделения в случае, если она там создается в первый раз или поступает от внешнего по отношению к организации субъекта. Например, сырье попадает от внешнего поставщика на склад. Поэтому оно показано в папке «Департамент закупок/склад». Вы можете предложить и использовать другой способ группировки, если считаете целесообразным. Если структура, например, готовой продукции (или материалов) сложная, то можно создавать промежуточные папки для группировки. Сама по себе разработка классификатора ТМЦ компании является отдельной и сложной задачей. С другой стороны, не очевидно, что надо создавать такой справочник, если цель – описание процессов на нижнем уровне под автоматизацию, например. Дело в том, что на схемах в нотации BPMN не показывают потоки материальных объектов. Понятно, что приведенный пример является весьма упрощенным, однако важны заложенные в методику принципы построения справочника. Напомню, что структура данного функционального справочника является промежуточной при создании © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 39 архитектуры бизнес-процессов компании. На следующих этапах работы она будет изменена. 4.4. Формирование справочников программных продуктов, баз данных, терминов На рисунке 21 представлена структура справочников «Программные продукты» и «Базы данных». В первом справочнике возможно создание иерархического списка «Информационная система/Модуль ИС/Функция ИС». Группировать программное обеспечение по папкам функциональных подразделений, на мой взгляд, нерационально, т.к. в большинстве случаев оно используется сразу множеством подразделений. Что касается баз данных, то заполнение данного справочника в большей степени зависит от методического решения, выбранного для описания процессов на уровне Work Flow. К этому вопросу мы еще вернемся ниже. Рис 21. Структура справочников «Программные продукты» и «Базы данных». © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 40 5. Разработка контекстной модели бизнеса в нотации IDEF0 Итак, приступим к созданию процессной модели компании. Для этого нужно, прежде всего, создать новую модель в справочнике «Процессы» и сформировать контекстную модель компании. В справочнике «Процессы» создайте новую модель в нотации IDEF0 5. Диаграмму А-0 нужно назвать «Контекст», так как она представляет собой контекстную диаграмму в соответствии с требованиями нотации IDEF0. Единственный четырехугольник на схеме А-0 надо назвать «Бизнес компании» (см. рис. 22). В рамках модели он будет представлять собой всю деятельность компании, рассмотренную с процессной точки зрения. Видно, что на диаграмме включена сетка. Я всегда предпочитаю включать сетку, чтобы при вставке новых объектов, выравнивать их по линиям. Следующим шагом необходимо определить входы и выходы компании в целом, как бизнеса. Важнейшая методическая проблема – это количество входов/выходов. Если рассматривать конкретные документы в качестве входов/выходов, то их можно насчитать сотни, а для крупной компании – тысячи. Вторая проблема в том, что люди бизнеса оперируют такими сущностными категориями, как «спрос», «новые клиенты», «прибыль», «риск» и т.п. Им не интересно, что какой-то документ в каком-то там частном случае пересекает границу компании. Если предположить, что основным читателем схем верхнего уровня (в т.ч. контекстной модели) являются собственники и топ-менеджеры бизнеса, то это означает, что схема должна быть понятна, в первую очередь, им. С другой стороны, при использовании нотации IDEF0 надо четко понимать, что стрелки на диаграммах – это «трубы», по которым перемещаются реальные информационные и материальные объекты. Эти объекты должны иметь четкие спецификации. В противном случае, согласование границ бизнес-процессов по входам/выходам и определение зон ответственности менеджеров будет невозможно. Модель будет весьма абстрактной. Сформулируем требования к контекстной диаграмме бизнеса: • ограниченное количество стрелок с каждой стороны 6 (рекомендую не более 6-8); • схема должна быть понятной собственникам и топ-менеджерам; • к стрелкам должны быть привязаны реальные объекты. На следующем рисунке показана контекстная диаграмма бизнеса пока без связей с внешним окружением. 5 Integration Definition Function Modeling (IDEF0) – американский стандарт. Есть Российский РД IDEF 0 – 2000. 6 В [7] дается такая рекомендация: «Наш опыт показывает, что диаграммы из 4-5 блоков с не более чем пятью дугами, касающимися каждого блока, приближаются к оптимальным по объему информации, которые можно быстро донести до широкой аудитории…» © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 41 © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 42 Рис. 22. Создание контекстной модели компании. Шаг 1. © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 43 Определим поставщиков и входы. На рисунке 23 показаны все возможные поставщики и все возможные входы (всегда слева). Как такое возможно? А вдруг мы что-то забыли? Рисовать новую стрелку? И почему стрелки так называются? Альтернативный способ представления входов показан на рис. 24. Сравните эти два рисунка. На первом рисунке использован системный подход к построению модели, на втором – подход «Абы как стрелки нарисовать» без всяких принципов и правил. Потребности и платежеспособный спрос Клиенты Ресурсы Поставщики Конкуренты Информация о продуктах и сервисах Бизнес компании Человеческие ресурсы Общество Информация об изменениях внешней среды Внешняя среда Капитал Собственники 0 Рис. 23. Создание контекстной модели компании. Шаг 2. Входы. Сервисная компания Крупные клиенты Услуги по ремонту Запросы от клиентов по ГП Заказы на поставку. План аудита СМК Претензии по качеству продукции Орган по сертификации Юридические документы Поставщики металла Металл в листах Бизнес компании Арматура Подшипники, масла, ветошь, Торг-12 Поставщики ЗИП ООО «Ромашка» Конкуренты Кадровое агентство Упаковка. Накладные Прайс-листы Резюме кандидатов ФНС Предписания 0 Рис. 24. Неправильный подход. На рис. 24 показан подход, когда каждый руководитель, участвующий в разработке архитектуры, пытается вспомнить, от каких организаций что-то получает его подразделение. Это, кончено, путь в никуда. Архитектуру процессов так построить невозможно. Проблема многих пользователей Business Studio заключается в том, что они начинают рисовать квадратики и стрелки, используя доступный функционал, но не отдавая себе отчета, что именно и для чего они «рисуют» на схеме, к чему это может привести. В дальнейшем, они просто перестают пользоваться моделью в нотации IDEF0. Очевидно, что нужно сделать контекстную диаграмму бизнеса максимально обобщенной и понятной. Но при этом, должны быть показаны все взаимодействующие субъекты. Возникает противоречие. Как быть? Нужно типизировать всех субъектов, сократив количество типов до минимума. Технически, для отображения субъектов, взаимодействующих с организацией, можно использовать справочник «Внешние ссылки» - см. рис. 23. В этом справочнике созданы следующие объекты: © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 44 • • • • • • Клиенты – все организации (физические лица), которые являются потенциальными или действующим клиентами компании. Поставщики – все организации, которые поставляют компании продукты и оказывают услуги. Конкуренты – все организации, прямо или косвенно конкурирующие с компанией по ее продуктам и сервисам. Общество – группа людей, обладающих общими интересами, ценностями и целями 7 - поставляет компании человеческие ресурсы и информацию. Внешняя среда – все остальное окружение бизнеса (география, климат, прочие организации и т.п.) – поставляет информацию, необходимую для адаптации бизнеса к изменяющимся внешним условиям. Собственники – юридические владельцы бизнеса – поставляют капитал в любой форме. От каждой внешней ссылки показана только одна входящая в блок «Бизнес компании» стрелка. В рамках предлагаемой мной Методики по каждой стрелке от внешнего субъекта перемещается множество информационных и материальных объектов. Объекты находятся в справочнике «Объекты деятельности» Business Studio. О том, как их привязывать к стрелкам, расскажу ниже. Пока запомните правило: Стрелки в IDEF0 – это трубы, соединяющие элементы системы, по которым в одну сторону движется поток информационных и материальных объектов. Т.е. стрелка, сама по себе, указывает только на тот факт, что два элемента архитектуры связаны между собой однонаправленным потоком объектов. Название стрелок должно быть кратким и отражать основную суть взаимодействия. Нельзя указывать в названии стрелки перечень всех движущихся объектов. Даже если получится их перечислить, надпись будет слишком длинной и будет плохо читаться. Функционал Business Studio позволяет создавать внешние ссылки на диаграмме любого уровня в любой нотации, но в рамках данной Методики: Использование внешних ссылок разрешено только на диаграмме А0. Для чего введено такое правило? Оно означает, что в рамках данной модели, взаимодействие с внешними субъектами возможно только через интерфейс процесса верхнего уровня. Если привести аналогию технических систем, то это означает, что два больших железных ящика, набитых аппаратурой, могут взаимодействовать между собой только через один толстый кабель (шлейф, трубу и т.п.) – см. рис 25. Прямые связи между ящиками в виде тысячи тонких проводов, соединяющие отдельные внутренние блоки разных функциональных подсистем, крайне нерациональны. 7 Человеческие общества характеризуются моделью отношений (социальных отношений) между людьми, которая может быть описана как совокупность таких отношений между его субъектов. © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 45 Рис. 25. Взаимодействие технических систем. На следующем рис. 26 показаны, так называемые, управляющие воздействия. К ним принято относить информацию управляющего характера (утвержденные планы, приказы, распоряжения) и ограничивающего характера (законы, правила, регламенты). Бизнес, как объект управления, преобразует входы в выходы в соответствии с данным управляющим воздействиями и ограничениями. Ни одна система не может существовать без управления. Поэтому в модели IDEF0 всегда должна быть хотя бы одна стрелка сверху у каждого объекта. Собственники Видение, цели Государство Законы, стандарты Общество Культура Бизнес компании 0 Рис. 26. Создание контекстной модели компании. Шаг 3. Управляющие воздействия. (Стрелки слева не показаны). © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 46 На рис. 26 показаны внешние ссылки: Собственники, Государство, Общество. Стрелка от собственников названа «Видение, цели». Основное управляющее воздействие со стороны собственников по отношению к бизнесу – это целеполагание. Конечно, собственник может заниматься оперативным управлением внутри компании, но это уже другая роль. Государство создает ограничения для бизнеса за счет системы законов и стандартов, т.е. документы, которые движутся по стрелке «Законы, стандарты» - это конкретные законы в области деятельности компании и соответствующие стандарты (Гражданский кодекс РФ можно не указывать – и так понятно, что он действует). Общество создает ограничения для бизнеса в части культуры, в т.ч. принятых ценностей и норм поведения, национальных традиций делового оборота и проч. Таким образом показано, что бизнес, как система, целенаправленно работает в рамках установленных ограничений. Запомните еще одно важное правило: Если объект одновременно является управляющим и используется для выполнения процесса, то стрелка, по которой этот объект движется, показывается только сверху. Это правило необходимо, чтобы исключить дублирование стрелок слева и сверху, споров о том, с какой стороны процесса лучше эту стрелку нарисовать. Теперь определим выходы бизнеса. Они показаны на рис. 27. Готовая продукция. Сервис Заказы. Ресурсы Информация для конкурентов Бизнес компании Человеческие ресурсы Информация для внешней среды 0 Дивиденды. Капитал Клиенты Поставщики Конкуренты Общество Внешняя среда Собственники Рис. 27. Создание контекстной модели компании. Шаг 4. Выходы. (Стрелки слева и сверху не показаны). Как видно на рис. 27, использованы те же внешние ссылки, что и при описании входов. Дело в том, что взаимодействие субъектов практически всегда двустороннее. Если бы я не показал какую-то внешнюю ссылку справа, это означало бы, что с соответствующим субъектом нет никакого взаимодействия. Стрелка от элемента диаграммы «Бизнес компании» к внешней ссылке «Клиенты» называется «Готовая продукция. Сервис». По этой стрелке может перемещаться множество информационных и материальных объектов, в т.ч. рекламные буклеты, письма, коммерческие предложения, проекты договоров, счета на оплату и т.п. Очевидно, что «сервис» по стрелке перемещаться не может (это деятельность). Но документы, его сопровождающие, - да. © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 47 От «Бизнеса компании» к «Поставщикам» по стрелке «Заказы. Ресурсы» могут перемещаться запросы цен, проекты договоров, информация об оплате и т.д. Можно сказать, что мы системно описали интерфейсы взаимодействия бизнеса с внешними субъектами. Построенная контекстная модель (см. рис. 28) является универсальной, т.е. годится для любого бизнеса. Возможна ли ее адаптация? Да, в части разумного переименования внешних ссылок и стрелок. Например, вместо стрелки «Готовая продукция. Сервис», можно написать «Вертолеты. Сервис по ремонту. Запчасти», или «Трубы большого диаметра», или «Оказанный сервис по ремонту оборудования» и т.п. На рис. 28 изменен цвет стрелок, входящих сверху (управляющие воздействия). Цветовое кодирование стрелок делает диаграммы в нотации IDEF0 намного информативнее. В рамках предлагаемой Методики построения архитектуры бизнеспроцессов с использованием нотации IDEF0 цветовое кодирование стрелок используется для отображения потоков разного типа. Подробнее об этом будет сказано ниже. В нотации IDEF0 принято так же рисовать стрелки, которые входят процесс снизу. Это, так называемые, «механизмы» - оборудование, ИТ-системы, измерительный инструмент и… персонал. В Business Studio можно нарисовать стрелки снизу, но это будет только картинка. Реальная связь субъектов с процессом (владельцы, исполнители и проч.) осуществляется через интерфейс (см. рис. 12. Назначение исполнителей бизнеспроцессов). Мы будем рисовать стрелки снизу, но только для оборудования и прочих систем – то есть всё, кроме персонала. Почему стрелки снизу не показаны на контекстной диаграмме бизнеса? Как можно что-то производить без оборудования? Когда мы рассматриваем бизнес в целом, оборудование поступает слева от поставщиков. Специальный процесс в системе (или внешний сервис) отвечает за монтаж и запуск оборудования в работу. Это происходит уже внутри системы. Поэтому стрелки снизу на контекстной диаграмме бизнеса не показаны. Если ситуация в вашем бизнесе другая (например, практикуется получение оборудования в аренду), то можно использовать стрелки снизу. Следующим шагом нужно декомпозировать элемент «Бизнес компании на уровень ниже. Диаграмма этого уровня имеет индекс А0 (напомню, контекстная диаграмма – А-0 – «А дефис 0»). На ней должны быть представлены категории процессов. Диаграмма А0 является важнейшей диаграммой при построении архитектуры бизнеспроцессов. Но как ее построить? Существуют различные способы построения процессной модели бизнеса на верхнем уровне. Об этом я расскажу в следующем разделе. © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 48 Собственники Видение, цели Клиенты Государство Законы, стандарты Общество Культура Потребности и платежеспособный спрос Готовая продукция. Сервис Ресурсы Заказы. Ресурсы Поставщики Конкуренты Информация о продуктах и сервисах Информация для конкурентов Бизнес компании Человеческие ресурсы Общество Человеческие ресурсы Информация об изменениях внешней среды Внешняя среда Собственники NODE: А-0 Информация для внешней среды Капитал TITLE: 0 Дивиденды. Капитал Контекст Рис 28. Контекстная модель компании. © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. Клиенты Поставщики Конкуренты Общество Внешняя среда Собственники NO.: 1.1 49 6. Методы группировки бизнес-процессов на верхнем уровне В данном разделе я рассмотрю возможные подходы к построению процессной архитектуры компании и сравню «плюсы» и «минусы» каждого варианта. Речь пойдет о методе группировки процессов на модели верхнего уровня (А0). Ранее уже были построены реестры функциональных бизнес-процессов в Business Studio, при этом графические диаграммы не формировались. Теперь надо принять решение о методе создания процессной модели компании с использованием уже определенных функциональных процессов подразделений. 6.1. Вариант 1. Модели функциональных бизнес-процессов подразделений Вариант 1 предполагает следующие действия: • создание моделей (диаграмм) для функциональных процессов подразделений (одна или несколько моделей); • стыковка моделей функциональных процессов подразделений по входам/выходам. Рис. 29 поясняет идею создания процессной модели компании в виде набора взаимодействующих моделей функциональных процессов подразделений. Модель функциональных процессов подразделения А Модель функциональных процессов подразделения Б Модель функциональных процессов подразделения С Рис. 29. Процессная модель компании как набор моделей функциональных процессов подразделений. Контекстная диаграмма для бизнеса в целом в данном случае не используется. В Business Studio создается несколько моделей в нотации IDEF0 – по количеству структурных подразделений верхнего уровня (см. рис. 30). В рамках каждой модели создается своя контекстная диаграмма. Далее каждая модель связывается с другими моделями на уровне А0 (не А-0!) при помощи так называемых междиаграммных ссылок - стрелок, которые как бы «пронзают пространство» и передают поток объектов между диаграммами разных иерархических веток модели. К сожалению, в Business Studio невозможно связывать при помощи МДС разные контекстные диаграммы. Это ограничение делает неудобным стыковку функциональных моделей между собой. Приходится показывать МДС на диаграмме А0. Это приводит к тому, что управляющие воздействия попадают не на уровень А-0 (контекстная диаграмма функционального) процесса, а сразу на уровень А0. Но, возможно, в следующих релизах Business Studio проблема будет решена. © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 50 Рис. 30. Вид справочника после создания функциональных процессов структурных подразделений. В чем преимущества такого подхода? В первую очередь в том, для каждого функционального бизнес-процесса уже определен руководитель, в чью зону ответственности попадает процесс. Не нужно определять владельцев процессов и выделять им какие-то ресурсы – они уже и так есть. Владелец процесса в этом случае тождественно равняется руководителю структурного подразделения. Минусы указанного подхода: 1) архитектура бизнес-процессов компании в целом не создается; 2) никакие сквозные процессы в организации не определяются – не видны результаты, важные для бизнеса в целом; 3) количество двунаправленных взаимодействий (стрелок) в модели может стать огромным. Второй пункт означает, что менеджменту компании не нужно ничего менять. Да, будут упорядочены функциональные процессы, в том числе за счет технической стыковки по входам/выходам в среде Business Studio. Почему я употребляю слово «технической»? Потому что в сложившейся деятельности организации взаимодействие между подразделениями уже налажено в достаточной для выполнения работы степени (если бы это было не так, то организация не смогла бы работать). Другой вопрос в четкости этих границ, эффективности взаимодействия, наличии зон безответственности и т.п. Кроме того, «стыковка процессов подразделений по входам/выходам» - это, в первую очередь, чисто менеджерская задача на организацию совместных совещаний руководителей подразделений, обсуждение и утверждения форм, сроков и требований к взаимодействию во внутренних нормативно-методических документах. Эта задача может быть решена и без Business Studio. Другое дело, что в Business Studio можно автоматизировать формирование этих регламентирующих документов. Вернемся к обсуждению функциональной модели процессов подразделений (и шире, модели вообще). Если ее создание не приводит к изменениям в реальной деятельности, то нужно ли создавать такую модель? Если нет изменений, то нет и развития, ведущего к достижению стратегических целей и повышению эффективности. Поэтому при создании функциональной модели процессов подразделений нужно ставить четкую цель – для чего это нужно. Это утверждение относится ко всем моделям и методикам, представленным ниже. © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 51 6.2. Вариант 2. Модель бизнес-процессов компании на основе функциональных бизнес-процессов подразделений Вариант 2 отличается от Варианта 1 тем, что формируется общая процессная модель компании, но представленные в ней процессы являются чисто функциональными процессами структурных подразделений. При этом используется уже созданная нами контекстная диаграмма бизнеса. На рис. 31 представлена идея создания единой процессной модели компании на основе функциональных процессов структурных подразделений. Реестр функциональных процессов подразделения А Реестр функциональных процессов подразделения Б Реестр функциональных процессов подразделения С Реестр функциональных процессов подразделения ... Процессная модель компании Процессы подразделения А Процессы подразделения Б Процессы подразделения С Процессы подразделения ... Рис. 31. Формирование процессной модели компании на основе моделей функциональных процессов структурных подразделений. В данном подходе важно, что функциональные модели структурных подразделений целиком входят в процессную модель компании. Если подразделений верхнего уровня в компании много, то схема получится весьма загруженной. Плюс такого подхода – это наличие единой иерархической модели процессов организации. Собственник или Генеральный директор компании легко может найти в такой модели любой процесс любого подразделения, при этом сразу увидеть границы каждого процесса. Минусы такие же, как и в предыдущем случае. 6.3. Вариант 3. Модель бизнес-процессов компании на основе группировки по базовым функциям бизнеса (цепочке создания ценности) Данный вариант позволяет создать процессную модель компании путем перегруппировки функциональных процессов структурных подразделений по © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 52 определенным правилам. Перед тем, как их сформулировать, нужно отметить недостатки чисто функционального взгляда на бизнес-процессы. Практически всегда организационная структура компании формируется под конкретных живых людей – руководителей. Все они отличаются своими управленческими навыками. Кого-то можно назвать «сильным управленцем», кого-то – «слабым». Понятно, что это весьма субъективные и относительные формулировки. Тем не менее, сильный руководитель берет на себя больше работы и ресурсов, чем слабый. В результате, в его структурном подразделении может оказаться много процессов, которые должны быть, похорошему, в отдельном структурном подразделении. Так же часто может сказываться «кадровый голод», когда просто некого назначать на должности – приходится их совмещать. Иногда, это следствие экономии и т.п. Рассмотрим примеры объединения (в рамках одного структурного подразделения) существенно разнородных функциональных процессов: • маркетинг и продажи; • управление технологией и контроль качества; • закупка и склад готовой продукции; • разработка нового изделия и производство. Проблема в том, что в рамках одного подразделения один функциональный процесс будет выполняться и развиваться в ущерб другому. Например, классическое противоречие маркетинга и продаж. Менеджерам по продажам невыгодно экспериментировать с новыми видами продукции – есть риск не продать и не получить премию. Другой пример, когда директора по производству стимулируют по показателю загрузки мощностей и тут же поручают ему контролировать качество продукции. С точки зрения собственника, в организации должны быть все бизнес-процессы, необходимые для эффективного выполнения маркетинга, продаж, логистики и т.п. При этом, в силу сложного пути развития организации, процессы могут быть раздроблены по различным функциональным подразделениям. Хотя точка зрения собственника тоже субъективна, но он видит систему в целом – ее суть, цели и стратегические направления развития. Поэтому на вопрос: «А зачем собственнику процессная структура компании?» можно дать такой ответ: «Чтобы увидеть все базовые функции бизнеса независимо от существующей организационной структуры и конкретных людей». Если собственника (генерального директора) устраивает такой ответ, то это значит, что он готов к изменениям организационной структуры компании, в том числе минимизации «роли личности в истории» (отказу от «незаменимых» руководителей и стандартизации процессов управления). Если собственник (Генеральный директор) говорит: «Нет», значит он не готов к изменениям и его устраивает существующая модель управления компанией. Итак, сформулирую первый принцип группировки процессов при создании архитектуры: Группировка функциональных процессов структурных подразделений на диаграмме А0 выполняется с точки зрения базовых функций бизнеса в целом. © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 53 Тогда возникает второй вопрос, а как определить эти базовые функции бизнеса в целом? Кстати, эти функции ничем не будут отличаться от так называемых «категорий процессов» - крупных объектов деятельности. Например, в документе Cross Industry Process Classification Framework APQC представлены следующие процессные категории, которые можно выделить для практически любого крупного бизнеса: 1. Развитие видения и стратегии (Develop Vision and Strategy). 2. Развитие и управление продуктами и услугами (Develop and Manage Products and Services). 3. Маркетинг и продажи продуктов и услуг (Market and Sell Products and Services). 4. Поставка продуктов (Deliver Physical Products). 5. Оказание сервисов (Deliver Services). 6. Управление обслуживанием потребителей (Manage Customer Service). 7. Управление и развитие человеческого капитала (Develop and Manage Human Capital). 8. Управление информационными технологиями (Manage Information Technology (IT)). 9. Управление финансовыми ресурсами (Manage Financial Resources). 10. Приобретение, создание и управление активами (Acquire, Construct, and Manage Assets). 11. Управление корпоративными рисками, соответствием требованиям, устранением последствий и устойчивостью (Manage Enterprise Risk, Compliance, Remediation, and Resiliency. 12. Управление внешними связями (Manage External Relationships). 13. Развитие и управление бизнес-способностями (Develop and Manage Business Capabilities). 8 Обратимся к понятию цепочки создания ценности (или сети создания ценности бизнеса). Не обойтись без Википедии: «Цепо́чка це́нности (англ. Value chain) — это инструмент стратегического анализа, направленный на подробное изучение деятельности организации с целью стратегического планирования. Идея цепочки ценности была предложена Майклом Портером в книге «Конкурентное преимущество 9» для выявления источников конкурентного преимущества с помощью анализа отдельных видов деятельности компании. Цепочка ценности «разделяет деятельность компании на стратегически важные виды деятельности с целью изучить издержки и существующие и возможные средства дифференциации». Однако, в англоязычной версии Википедии можно найти другое определение: Цепочка ценности – это набор операций, который компания, действующая в определенной отрасли, выполняет для того, чтобы поставлять продукт или оказывать 8 Другими словами, управление организационным развитием. 9 Porter M. E., Competitive Advantage: Creating and Sustaining Superior Performance (New York: Free Press, 1985). © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 54 сервис, ценный для рынка. (A value chain is a set of activities that a firm operating in a specific industry performs in order to deliver a valuable product or service for the market). Стратегически важный вид деятельности, ключевая функция бизнеса или «категория бизнес-процессов» – это, на мой взгляд, одно и то же. Какие ключевые виды деятельности (базовые функции бизнеса) могут быть выделены в компании? В следующей таблице представлены различные варианты. Таблица 5. Базовые функции бизнеса для различных компаний. Вид деятельности компании Торгово-производственная компания. Вариант 1 Торгово-производственная компания. Вариант 2 Сетевой ритейл Сетевой ритейл + оптовая торговля Оптовая торговля Транспортная компания Системная интеграция Базовые функции бизнеса Управление бизнесом Маркетинг Продажи Закупка 10 Производство Управление технологией Транспортная логистика Складская логистика Контроль качества Управление бизнесом Продажи Логистика Закупка Производство Управление технологией производства и контроль качества Развитие продукции и услуг Управление бизнесом Управление товарными категориями Розничные продажи Развитие торговой сети Закупка и поставка товара Обеспечение деятельности магазинов Управление бизнесом Коммерческая деятельность Закупка Продажа Транспортная и складская логистика Управление бизнесом Маркетинг и реклама Развитие ассортимента Продажа Закупка и доставка Складская логистика Производство образцов Контроль качества и технологическое обеспечение Процессы управления Процессы развития Маркетинг Продажа Ценообразование и контроль тарифов Оказание услуг экспедирования Организация перевозок Расчеты с клиентами Управление бизнесом Поддержание отношений с клиентами 10 У М. Портера «Закупка» показана во вспомогательных процессах. С моей точки зрения, это – основной процесс. © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 55 Бизнес-центр Нефтяная компания Предпродажная подготовка (пресейл) Подготовка и проведение конкурсов Управление проектами Проектирование Закупка ТМЦ, программного обеспечения и услуг Внедрение решений Сопровождение и гарантийное обслуживание Управление бизнесом Продажа услуг бизнес-центра Администрирование бизнес-центра Техническое обслуживание бизнес-центра Управление бизнесом Продажа и логистика нефтепродуктов Поиск и разведка, пробная эксплуатация месторождения Бурение скважин Капитальное строительство Эксплуатация месторождений Переработка газа Закупка и логистика ТМЦ и услуг Так называемые «вспомогательные функции» (например, «Управление персоналом») в таблице не показаны, так как их структура во многом является одинаковой для разных бизнесов. Базовые функции – это, по сути, основные процессы компании. Сформулирую второй принцип группировки процессов при создании архитектуры бизнес-процессов компании: Определение базовых функций бизнеса выполняется на основе анализа цепочки создания ценности. На рис. 32 показана идея формирования процессной модели компании на основе анализа цепочек создания ценности. Необходимо сначала определить категории процессов (базовые функции бизнеса) с использованием методов стратегического анализа, а затем «разнести» по ним функциональные процессы, взятые из реестров процессов подразделений. Реестр функциональных процессов подразделения А Реестр функциональных процессов подразделения Б Реестр функциональных процессов подразделения С Реестр функциональных процессов подразделения ... Процессная модель компании Категория процессов 1 Видение базовых функций бизнеса (видов деятельности в цепочке создания ценности) Категория процессов 2 Категория процессов 3 Категория процессов ... Рис. 32. Формирование процессной модели компании на основе цепочки создания ценности. © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 56 Сложность метода состоит в том, что при данном подходе все функциональные процессы подразделений должны быть «разнесены» по категориям процессов процессной модели компании и ниже на соответствующих уровнях. При этом, как я уже говорил выше, полученные категории и группы процессов будут включать в себя бизнес-процессы, выполняемые в разных функциональных подразделениях. Нельзя будет сходу определить руководителя, который должен отвечать за конкретную категорию процессов. Еще раз хочу подчеркнуть, что необходимо принять решение: или модель функциональных процессов структурных подразделений, или процессная модель на основе цепочки создания ценности. 11 И в том, и в другом случае за процессы 3-4 уровня всегда есть ответственные. Но в случае процессной модели их может не быть для 1-2 уровня иерархии. Этот факт может побудить топ-менеджмент заняться анализом эффективности орг. структуры и, возможно, реорганизацией компании. Еще одним вариантом является принцип группировки процессов на верхнем уровне по жизненному циклу основного продукта компании. Например, на верхнем уровне можно выделить следующие категории процессов: 1. Управление бизнесом. 2. Маркетинг. 3. Выполнение научно-исследовательских и опытно-конструкторских работ. 4. Закупка. 5. Производство. 6. Поставка, установка и ввод в эксплуатацию. 7. Сервис и обеспечение запасными частями. 8. Утилизация. В целом, такой взгляд можно рассматривать как один из возможных вариантов представления цепочки создания ценности. Теперь необходимо сказать несколько слов о вспомогательных бизнес-процессах. К их числу обычно относят: • инженерно-техническое обеспечение; • энергообеспечение; • ИТ-обеспечение; • управление персоналом; • бухгалтерский учет; • юридическое обеспечение; • обеспечение безопасности; • административно-хозяйственное обеспечение; • делопроизводство; • прочие. Проблема заключается в том, что представить на модели верхнего уровня одновременно категорию процессов «Управление бизнесом», все категории основных и 11 Есть еще третий вариант, о котором речь пойдет ниже. Это – сквозные бизнес-процессы. © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 57 вспомогательных процессов одновременно затруднительно. На диаграмме будет слишком много элементов. С учетом того, что диаграмма будет выполнена в нотации IDEF0, появится множество стрелок и модель станет нечитаемой. В случае, если не показывать ее руководству компании, то так делать можно. Но мы рассмотрим возможные альтернативные варианты представления. На рис. 33 показан вариант, когда на диаграмме показывают всего три объекта: Процессы управления, Основные процессы, Вспомогательные процессы. Если бы речь шла только о простой картинке (как на рисунке) и реестрах (перечнях) процессов в MS Excel, то так делать можно. Если цель – создание комплексной модели со всеми связями в Business Studio, такой подход приведет к существенному усложнению процесса моделирования за счет возникновения вспомогательного, формального уровня иерархии. Еще одним аргументом «против» является тот факт, что никому в голову ни придет назначать «Директора по основным процессам» и «Директора по вспомогательным процессам». Слишком крупные зоны ответственности. А вот назначить руководителя на реальную, пусть и большую, функцию бизнеса – можно. Процессная модель компании Процессы управления Основные процессы Вспомогательные процессы Рис. 33. Метод группировки при помощи трех объектов (не рекомендую). С учетом сказанного, можно сформулировать архитектуры бизнес-процессов компании: третий принцип построения Уровень архитектуры бизнес-процессов, по возможности, должен соответствовать уровню менеджмента в компании. Для классической торгово-производственной компании можно использовать следующую схему построения архитектуры бизнес-процессов на верхнем уровне: © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 58 Процессная модель компании Управление бизнесом Категория процессов... Категория процессов... Категория процессов... Категория процессов... Инженернотехническое обеспечение Обеспечение операционной деятельности Рис. 34. Метод группировки бизнес-процессов для торгово-производственной компании. Обратите внимание, что обязательно должна быть определена категория процессов «Управление бизнесом». Объектом управления для этой категории будут служить все остальные категории процессов, т.е. весь бизнес. Внутри этой категории – процессы, выполняемые топ-менеджментом (Генеральный директор, Совет директоров). Обратите внимание еще на четвертый принцип формирования моделей бизнеспроцессов на 1-3 (иногда 4-ом) уровне: На каждой диаграмме 1-3 уровня обязательно должен быть представлен процесс «Управление процессом…». Странно было бы моделировать бизнес-процессы без управления. Поэтому, какой бы метод вы не выбрали, не забудьте задать себе вопрос: «А где у нас процессы управления?». Говоря о процессах управления, хочу привести практический пример. В некоторых компаниях используют принцип описания процессов на основе цикла управления – см. рис. 35: © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 59 Планирование процесса 1 Выполнение процесса 2 Контроль и анализ процесса 3 Улучшение процесса 4 Рис. 35. Метод описания бизнес-процесса на основе цикла управления (не рекомендую). К чему приводит такой подход к описанию процессов? Блок «Выполнение процесса» декомпозируют на подпроцессы «выполнения». Затем каждый подпроцесс декомпозируют снова по циклу управления и т.д. Фактически, получается удвоение уровней иерархии, которое крайне осложняет процесс моделирования. В некоторой компании при наличии 4 уровней управления было получено 8 уровней иерархии в архитектуре. Это путь в никуда. Но вернемся к рассмотрению метода группировки по цепочке создания ценности. На рис. 34 отдельно выделена категория вспомогательных процессов «Инженернотехническое обеспечение». Почему? Для производственной компании это, как правило, мощный процесс, непосредственно влияющий на возможность производства. С учетом значимости этого процесса специально создана отдельная категория на верхнем уровне. Все вспомогательные процессы, не относящиеся к инженерно-техническому обеспечению, сгруппированы в категорию «Обеспечение операционной деятельности». 6.4. Вариант 4. Отдельные модели сквозных бизнес-процессов Рассмотрим еще один интересный вариант группировки процессов. Как это ни странно, данный способ группировки может быть выбран менеджментом исключительно из практических соображений. Особенности метода: • никакая иерархическая архитектура бизнес-процессов компании не создается; • последовательно выбираются сквозные бизнес-процессы, формируются их модели и организуется реальное управление. Еще раз обращаю внимание на этот момент – сквозные бизнес-процессы определяются по мере организации реального (не бумажного) управления этими процессами. Это значит, что назначаются владельцы процессов с четко определенными полномочиями (выделенными ресурсами) и ответственностью (за достижение установленных целей и © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 60 показателей). Для них модели сквозных процессов сразу становятся реальным практическим инструментом управления. В предыдущих случаях, при построении процессной архитектуры бизнеса на основе цепочки создания ценности, модель может оказаться настолько далекой от текущей реальности, что менеджмент не понимает, что с ней делать и с какого конца начать проводить изменения. Есть риск, что эти изменения в организационной структуре (на основе понимания базовых функций бизнеса - категорий процессов) могут не наступить никогда. Процессная архитектура бизнеса будет жить своей жизнью, а реальный бизнес – своей. На рис. 36 показан рассматриваемый вариант группировки. Обратите внимание, что функциональные бизнес-процессы структурных подразделений разносятся по сквозным бизнес-процессам. При этом допустима ситуация, когда функциональный процесс остается в реестре подразделения, так как может использоваться в разных сквозных бизнес-процессах. Кроме того, на рисунке показано, что сквозные процессы могут быть различного масштаба. Выбор сквозных бизнес-процессов осуществляется Генеральным директором, Советом директоров или Процессным комитетом в зависимости от системы принятия решений, используемой в компании. В Business Studio никакая иерархия сквозных процессов не создается. Они просто представляются линейным списком в отдельной папке «Сквозные процессы» в справочнике «Процессы». Далее для каждого сквозного процесса создается отдельно своя модель. Кстати, при таком подходе для описания процессов можно использовать сразу нотацию BPMN, правда, только для сквозных процессов очень незначительного масштаба. Приведу примеры сквозных бизнес-процессов с указанием масштаба (большой, средний, малый): • разработка нового изделия: от идеи до постановки на производство (большой); • разработка технико-коммерческого предложения для клиента (средний); • согласование проекта договора (средний); • поиск и подбор нового сотрудника (средний); • отправка сотрудника в командировку (малый). © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 61 Реестр функциональных процессов подразделения А Процессная модель компании Сквозной бизнес-процесс 1 Реестр функциональных процессов подразделения Б Реестр функциональных процессов подразделения С Сквозной бизнес-процесс 2 Сквозной бизнес-процесс 3 Сквозной бизнес-процесс ... Реестр функциональных процессов подразделения ... Рис. 36. Группировка на основе сквозных бизнес-процессов. Все представленные выше сквозные процессы - разного масштаба, но это не означает, что какой-то из них не является важным для компании. Вопрос только в приоритетах с точки зрения собственников и топ-менеджмента. Мы рассмотрели возможные принципы группировки процессов на верхнем уровне. Перед тем, как приступить к формированию соответствующих моделей в Business Studio, необходимо изучить базовые правила формирования моделей процессов в нотации IDEF0. © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 62 7. Правила использования нотации IDEF0 7.1. Краткие сведения о нотации Для построения архитектуры бизнес-процессов я буду использовать методологию SADT (Structured Analysis and Design Technique) — методологию структурного анализа и проектирования. Информация из Википедии: «SADT возникла в конце 60-х годов ХХ века. Часть теорий, относящихся к методологии и языку описания систем, были названы их автором, Дугласом Т. Россом «Методологией структурного анализа и проектирования». Исходная работа над SADT началась в 1969 г. Первое её крупное приложение было реализовано в 1973 г. при разработке большого аэрокосмического проекта. В 1974 г. SADT была еще улучшена и передана одной из крупнейших европейских телефонных компаний. Появление SADT на рынке произошло в 1975 г. после годичного оформления в виде продукта. К 1981 г. SADT уже использовали более чем в 50 компаниях при работе более чем над 200 проектами, включавшими более 2000 людей и охватывавшими более десятка предметных областей, в том числе телефонные сети, аэрокосмическое производство, управление и контроль, учет материально-технических ресурсов и обработку данных…» Собственно, нотация IDEF0 как стандарт «была разработана на основе подхода SADT в 1981 году департаментом Военно-воздушных сил США в рамках программы автоматизации промышленных предприятий… В результате поиска соответствующих решений родилась методология функционального моделирования IDEF0. С 1981 года стандарт IDEF0 претерпел несколько незначительных изменений, в основном, ограничивающего характера, и последняя его редакция была выпущена в декабре 1993 года Национальным институтом по стандартам и технологиям США». Классической книгой по SADT (IDEF0) до сих пор считается книга Дэвида А. Марки и Клемента МакГоуэна с предисловием Дугласа Т. Росса «Методология структурного анализа и проектирования». С использованием SADT (IDEF0) можно проектировать сложные системы. Цитата из книги: «Под словом «система» мы понимаем совокупность взаимодействующих компонент и взаимосвязей между ними... Под термином «моделирование» мы понимаем процесс создания точного описания системы. Особенно трудным оказывается описание систем средней сложности, таких, как система коммутаций в телефонных сетях, управление аэровоздушными перевозками или движением подводной лодки, сборка автомобилей, челночные космические рейсы, функционирование перерабатывающих предприятий. С точки зрения человека, эти системы описать достаточно трудно, потому что они настолько велики, что практически невозможно перечислить все их компоненты со своими взаимосвязями… Наша неспособность дать простое описание, а, следовательно, и обеспечить понимание таких систем делает их проектирование и создание трудоемким и дорогостоящим процессом и повышает степень их ненадежности. С ростом технического прогресса адекватное описание систем становится все более актуальной проблемой. SADT (аббревиатура выражения Structured Analysis and Design Technique методология структурного анализа и проектирования) - это методология, разработанная специально для того, чтобы облегчить описание и понимание искусственных систем, попадающих в разряд средней сложности». В рамках нотации IDEF0 сформулирован ряд требований и рекомендации по ее использованию. При описании отдельного абстрактного процесса (системы) достаточно © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 63 низкого уровня (масштаба) можно использовать все предлагаемые нотацией возможности. Но попытка использовать те же возможности при построении иерархической архитектуры большой компании приводят к дезинтеграции модели и невозможности ее практического применения. В рамках данной книги я предлагаю читателю несколько измененную методологию IDEF0 для проектирования архитектуры бизнес-процессов организации. Например, предлагаю полностью отказаться от использования туннельных стрелок в рамках одной модели и проч. Таким образом, методология становится более жесткой – не допускает стрелок в «никуда», абстрактных потоков и т.п. В рамках подхода все должно быть четко и однозначно. Это дает возможность построить инженерную модель процессов бизнеса: Инженерная модель процессов бизнеса – архитектура бизнес-процессов, в которой каждый процесс представлен в виде графической схемы и показано взаимодействие процессов между собой по входам/выходам. Программный продукт Business Studio практически полностью поддерживает нотацию IDEF0 и может быть использован для проектирования организации, как сложной системы, создания инженерной модели бизнеса. С другой стороны, я не навязываю свою точку зрения и не предлагаю жестко использовать ряд предлагаемых мной ограничений. В любом случае, вы должны четко понимать последствия используемых принципов и правил моделирования, возможности и ограничения моделей разного типа. 7.2. Процессы и стрелки на диаграмме На рис.37 показана диаграмма процесса в нотации IDEF0, подготовленная для учебных целей. Вы можете выполнять соответствующие настройки в Business Studio для тренировки или просто внимательно прочитать данный раздел. На диаграмме представлено четыре процесса, в т.ч. блок «Управление процессом» (пока специально показан без стрелок). Процесс простой и линейный. Напомню, что в IDEF0 можно рассматривать стрелки, как трубы, по которым движется поток объектов – информация и материальные ресурсы. В Business Studio есть отдельный справочник стрелок, а также справочник «Объекты деятельности». Объекты из этого справочника нужно привязывать к стрелкам. Этот вопрос подробнее рассмотрим ниже. Можно ли сказать, что стрелка является «входом» или «выходом» процесса? Нет, так говорить некорректно. Стрелка может является входящей или исходящей. А вот объект (например, документ в электронной форме), может быть входом для одного процесса и выходом для другого. © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 64 Управление процессом СТРЕЛКА А Бизнес-процесс А СТРЕЛКА Б’ СТРЕЛКА Б Бизнес-процесс Б СТРЕЛКА В Бизнес-процесс В СТРЕЛКА Г Рис. 37. Модель в IDEF0. (1). Объекты на диаграмме расположены в диагональном порядке за исключением блока «Управление процессом». В стандарте рекомендуется использовать способ по «порядку доминирования» (первый процесс определяет деятельность второго и т.д). Поскольку это только рекомендация, можно располагать объекты в диагональном порядке, например, по движению продукта (услуги) через цепочку создания ценности. В любом случае, такой порядок расположения просто удобен при создании диаграмм в нотации IDEF0. Обратите внимание, что из блока деятельности «Бизнес-процесс А» выходит две стрелки с разными названиями: «Б» и «Б’». Последняя стрелка перечеркнута красным крестом. Почему? Напомню, что в нотации IDEF0 рекомендуется использовать не более 45 стрелок с каждой стороны (на практике их может быть 6-8). В противном случае модель становится слишком сложной и нечитаемой. Но я предлагаю ввести жесткое ограничение и формулирую следующий принцип: Если между двумя процессами есть реальное взаимодействие, то на диаграмме эти процессы могут быть связаны в одном направлении только одной стрелкой. В нашем примере это означает, что стрелку «Б’» нужно удалить. Все объекты, которые передаются от Бизнес-процесса А к Бизнес-процессу Б должны быть привязаны только к одной стрелке. Если принять это правило, то рекомендация в 8 стрелок с одной стороны процесса означает, что на диаграмме может быть максимум 9 процессов. Если их будет больше, то при условии ограничения по количеству стрелок, не получится соединить один процесс со всеми остальными хотя бы одной стрелкой. В рамках предлагаемого мной подхода: Можно рисовать до восьми стрелок с каждой стороны процесса. © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 65 При этом, между двумя взаимодействующими процессами не может быть больше одной стрелки связи в одном направлении (этот принцип был сформулирован чуть выше). Это означает, что на диаграмме не должно быть больше девяти процессов. На практике возникает проблема, связанная с именованием стрелок на диаграммах. Она состоит в том, что объекты деятельности, которые перемещаются по стрелке, могут быть существенно разные. Много времени уходит на обсуждение возможных названий стрелок и споры, какое из этих названий лучше отражает смысл общего потока объектов. Поэтому я формулирую еще один принцип: Стрелка может именоваться по названию одного из объектов, который по ней движется, со знаком «+». То есть, например, если по стрелке движется 10 разных документов, то мы можем назвать стрелку «Счет для клиента +». Для имени перед плюсом желательно выбирать название основного потока – например, выбранного по количеству документов этого типа в общем потоке документов. Не стоит долго спорить из-за названий – это непродуктивно. 7.3. Ветвление и слияние стрелок На следующем рис.38 появилось несколько новых стрелок (блок «Управление процессом» не показан для экономии места). СТРЕЛКА А Бизнес-процесс А СТРЕЛКА Б СТРЕЛКА Ж Бизнес-процесс Б СТРЕЛКА Д СТРЕЛКА В Бизнес-процесс В СТРЕЛКА Г Рис. 38. Модель в IDEF0. (2). Стрелки «Д» и «Ж» выделены жирным. Это означает, что по ним перемещаются материальные объекты. Введем правило: Стрелка показывается жирным синим цветом, если по ней перемещаются материальные объекты. Важно подчеркнуть, что кроме материальных объектов по таким стрелкам могут перемещаться информация и документы. Нельзя создавать специальные стрелки только для материальных потоков. © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 66 Так же на рис. 38 показано, что Стрелка А разветвляется там, где расположен зеленый кружок (не является элементом нотации – он нужен, чтобы вы обратили внимание). Сегмент стрелки, распложенный справа от точки ветвления, и стрелка, уходящая вниз к блоку «Бизнес-процесс Б», не именованы. Это означает, что Стрелка А ветвится – разделяется на две, причем по каждой стрелке движется тот же поток объектов, что и по Стрелке А. Возможен другой вариант ветвления стрелок, как показано на следующем рис. 39. Бизнес-процесс А СТРЕЛКА А1 СТРЕЛКА Б СТРЕЛКА А СТРЕЛКА А2 Бизнес-процесс Б СТРЕЛКА Ж СТРЕЛКА Г1 СТРЕЛКА Д СТРЕЛКА В Бизнес-процесс В СТРЕЛКА Г2 СТРЕЛКА Г Рис. 39. Модель в IDEF0. (3). Стрелка А ветвится на две стрелки – Стрелку А1 и Стрелку А2. Часть объектов, которые двигались по Стрелке А, должны пойти по Стрелке А1, часть – по Стрелке А2. Можно представить себе трубу большого диаметра, которая разветвилась на две трубы поменьше. Как это правильно сделать в Business Studio? Сначала нужно создать две новые стрелки А1 и А2, в потом привязать их к наконечнику Стрелки А. Аналогичная ситуация со Стрелкой Г. Из блока «Бизнес-процесс Б» выходит Стрелка Г1, из блока «Бизнес-процесс В» - Стрелка Г2. Обе стрелки объединяются в одну Стрелку Г. Это означает, что потоки объектов, которые двигались по стрелкам Г1 и Г2, теперь двигаются по Стрелке Г. Использовать ветвление и слияние стрелок очень важно для того, чтобы можно было создать иерархическую архитектуру бизнес-процессов компании. Дело в том, что на моделях верхнего уровня должны быть представлены не только крупные блоки деятельности («базовые функции бизнеса» - категории процессов), но и потоки объектов. Причем эти потоки объектов также должны быть укрупненными или, говоря другими словами, агрегированными. Механизм ветвления/слияния стрелок нужен именно для того, чтобы потоки объектов по масштабу соответствовали бизнес-процессам, представленным на диаграмме соответствующего уровня. 7.4. Стрелки для управления и отчетности На следующем рис. 40 представлены потоки управления. В блок «Управление процессом» входит стрелка «Управление» с вышестоящей диаграммы. Показана © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 67 исходящая Стрелка У1, которая разделяется на три: Стрелку У1.1., Стрелку У1.2., Стрелку У1.3. Как можно интерпретировать данную схему? Цели, планы, приказы, распоряжения, задачи – это информационные объекты, которые могут перемещаться по трем стрелкам «У…» от блока «Управление процессов» в соответствующий блок «Бизнес-процесс…». Причем, поскольку Стрелка У разделена на три стрелки У.1.N, то каждый бизнес-процесс получает свое управляющее воздействие. УПРАВЛЕНИЕ Управление процессом СТРЕЛКА У1 СТРЕЛКА У1.1. Бизнес-процесс А СТРЕЛКА А1 СТРЕЛКА Б СТРЕЛКА А СТРЕЛКА А2 СТРЕЛКА У1.2. Бизнес-процесс Б СТРЕЛКА Ж СТРЕЛКА Г1 СТРЕЛКА Д СТРЕЛКА У1.3. СТРЕЛКА В Бизнес-процесс В СТРЕЛКА Г2 СТРЕЛКА Г Рис. 40. Модель в IDEF0. (3). На рисунке зеленым овалом обведено место, где стрелки управления визуально наложены друг на друга. Хочу обратить ваше внимание, что такой способ представления позволяет сделать схему более читаемой. Настоятельно рекомендую его использовать. В Business Studio вы можете привязать к Стрелке У три документа из справочника «Объекты деятельности/Электронный документ». Например, это будут: План 1, План 2 и План 3. Далее, открыв свойства Стрелки У1.1., вы можете использовать команду «Копировать с сегментов», чтобы выбрать из трех документов один – План 1, который должен перемещаться по Стрелке У1.1. от блока «Управление процессов» в блок «Бизнеспроцесс А». Копирование с сегментов – это удобный инструмент разделения (объединения) потока объектов по стрелкам. Иначе пришлось бы для Стрелок У1.1., У1.2. и У1.3. вручную привязывать объекты из справочника «Объекты деятельности». На рис. 41 показано, как можно «копировать с сегментов». © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 68 Рис. 41. Функционал «копирования с сегментов» Business Studio. Нужно открыть Свойства стрелки. В списке «Список объектов» нажать гиперссылку «Копировать с сегментов». В появившемся окне оставить галочку только для «План 1» и нажать кнопку «Выбрать». В результате к Стрелке У1.1. будет привязан только один объект – План 1. Напомню, что в Business Studio к стрелкам можно привязывать неограниченное количество объектов деятельности. Как нужно использовать данный функционал? На диаграмме нижнего уровня, сформированной в нотации IDEF0 (это 3-й или 4-й уровень иерархии) к стрелкам привязываются реальные объекты деятельности – документы, информация, материальные ресурсы. При переходе к диаграмме вышестоящего уровня стрелки нужно укрупнять, сохраняя непрерывным поток объектов. Это означает, что на диаграмме А0 к стрелкам может быть привязано несколько десятков (возможно, сотен) различных документов. Таким образом, диаграммы остаются читаемыми, но в любой момент можно понять, какие конкретно документы «входят» в процесс и «выходят» из него. Это исключительно важно для определения реальных границ процессов, стыковки процессов по входам/выходам и четкого определения зон ответственности руководителей. Замечу, что здесь я привожу только одно методическое решение. Вы можете разработать и использовать другой способ работы со стрелками и объектами деятельности в Business Studio. Еще одна возможность – агрегирование объектов деятельности в справочнике, например, можно использовать один объект «Документы для оформления договора» вместо десяти отдельных документов. Но такой способ имеет два недостатка: © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 69 1. сложность и весьма высокая степень субъективности при создании иерархического справочника объектов; 2. не всегда можно будет использовать «копирование с сегментов» (либо это делать будет неудобно). Также для решения указанной задачи можно использовать функционал Business Studio «Набор объектов». На рис.42 показаны стрелки, по которым движется поток объектов – отчетность по выполнению процессов, проекты планов и прочая информация. УПРАВЛЕНИЕ СТРЕЛКА О1 Управление процессом СТРЕЛКА У1 СТРЕЛКА У1.1. Бизнес-процесс А СТРЕЛКА А1 СТРЕЛКА А СТРЕЛКА О1.1. СТРЕЛКА А2 СТРЕЛКА У1.2. СТРЕЛКА Б Бизнес-процесс Б СТРЕЛКА Ж СТРЕЛКА Г1 СТРЕЛКА Д СТРЕЛКА У1.3. СТРЕЛКА О1.2. СТРЕЛКА В Бизнес-процесс В СТРЕЛКА Г2 СТРЕЛКА Г СТРЕЛКА О1.3. Рис. 42. Модель в IDEF0. (4). На рис. 42 видно, что три стрелки Стрелка О.1.1, Стрелка О1.2 и Стрелка О1.3. объединяются в одну Стрелку О1. Так же, как и при ветвлении стрелок, при слиянии можно использовать функцию «Копировать с сегментов», чтобы объединить потоки объектов, перемещающиеся по разным стрелкам, в единый поток для Стрелки О1. Так же обратите внимание на две особенности. Данные стрелки в нотации IDEF0 принято называть стрелками обратной связи по информации. При формировании диаграммы такие стрелки должны обходить все объекты деятельности снизу и слева. Как показывает практика, диаграмма в этом случае становится более читаемой. Кроме того, видно, что стрелки частично наложены друг на друга. Это также сделано для повышения визуальной наглядности диаграммы. Вторая особенность состоит в том, что стрелки в данном случае серого цвета. Я специально выбрал этот цвет для стрелок, которые показывают поток объектов, связанных с отчетностью перед процессом «Управлять процессом». © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 70 Итак, на схеме есть стрелки управления и стрелки отчетности. Мы получили контур управления процессами: есть управляющее воздействие и есть обратная связь от управляемого объекта. Это очень важно, так как мы моделируем систему управления бизнес-процессами компании. 7.5. Обратная связь по информации и управлению Дополним диаграмму еще некоторыми стрелками – см. рис. 43 (отмечены зелеными овалами). Во-первых, это Стрелка У3.1. Она представляет собой обратную связь по управлению. При моделировании в нотации IDEF0 такие стрелки должны «обходить» все объекты диаграммы справа и сверху. Это правило не жесткое, но лучше его придерживаться. На рисунке показана еще одна Стрелка Г3 – это обратная связь по информации. Как я уже говорил, стрелки обратной связи по информации желательно показывать снизу и слева. УПРАВЛЕНИЕ СТРЕЛКА О1 Управление процессом СТРЕЛКА У1 СТРЕЛКА У1.1. Бизнес-процесс А СТРЕЛКА А1 СТРЕЛКА А СТРЕЛКА У3.1. СТРЕЛКА О1.1. СТРЕЛКА А2 СТРЕЛКА У1.2. СТРЕЛКА Б Бизнес-процесс Б СТРЕЛКА Ж СТРЕЛКА Г1 СТРЕЛКА Д СТРЕЛКА О1.2. СТРЕЛКА У1.3. СТРЕЛКА В Бизнес-процесс В СТРЕЛКА Г2 СТРЕЛКА Г СТРЕЛКА О1.3. СТРЕЛКА Г3 Рис. 43. Модель в IDEF0. (5). Как быть, если по стрелке движутся объекты, которые нужны как для управления, так и для использования в процессе (информационный вход)? Сформулирует правило: Если по стрелке движутся объекты, необходимые для управления и для выполнения процесса, то к процессу присоединяется только одна стрелка – сверху. © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 71 Это правило позволяет не только упростить внешний вид диаграммы, но и меньше спорить о том, с какой стороны нужно нарисовать стрелку. 7.6. Внешние ссылки На следующем рис. 44 показано некорректное использование внешних ссылок на диаграмме. Дело не в том, что внешняя ссылка имеет название конкретной организации (ООО «Ромашка»). Просто ранее я ввел правило, что внешние ссылки разрешены только на контекстной диаграмме (А-0). Если использовать внешние ссылки где попало, то модель очень быстро потеряет системность и «развалится» - диаграммы будут соединены напрямую потоками низкого уровня (вспомните рисунок с железными ящиками). Это не инженерный подход. УПРАВЛЕНИЕ СТРЕЛКА О1 Управление процессом СТРЕЛКА У1 СТРЕЛКА У1.1. Бизнес-процесс А СТРЕЛКА А1 СТРЕЛКА А СТРЕЛКА У3.1. СТРЕЛКА О1.1. СТРЕЛКА У1.2. СТРЕЛКА Б СТРЕЛКА А2 Бизнес-процесс Б СТРЕЛКА Ж СТРЕЛКА Г1 СТРЕЛКА Д СТРЕЛКА О1.2. СТРЕЛКА У1.3. СТРЕЛКА В Бизнес-процесс В ООО "Ромашка" СТРЕЛКА Р СТРЕЛКА Г2 СТРЕЛКА Г СТРЕЛКА О1.3. СТРЕЛКА Г3 Рис.44. Модель в IDEF0. (6). В некоторых компаниях используют внешние ссылки для «моделирования взаимодействия подразделений с процессами» или, что того хуже, чтобы показать связь с процессами, находящимися в другой части модели. Эти ошибки показаны на рис. 45. Стрелка Отдел продаж ПРОЦЕСС Стрелка Стрелка Директор Процесс согласования договора Рис.45. Ошибки при использовании внешних ссылок. © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 72 7.7. Туннельные стрелки и междиаграммные ссылки В нотации IDEF0 присутствует понятие туннельной стрелки. Этот механизм был предложен разработчиками для того, чтобы иметь возможность показать нужные «входы/выходы» на диаграмме процесса, не интегрируя их в общую модель стандартным образом. Туннельная стрелка приходит в процесс не с диаграммы вышестоящего уровня, а как бы ниоткуда, из «туннеля». Конечно, соответствующая стрелка должна уходить в туннель на какой-то другой диаграмме, но поиск этой диаграммы в модели и создание соответствующей стрелки оставались на совести бизнес-аналитика. По факту работа, вероятно, строилась так: «Забыл стрелку? Не знаешь, откуда она идет? Не понимаешь, как ее агрегировать с другими стрелками в диаграмме? Забудь об этой проблеме и нарисуй туннельную стрелку». Понятно, что при таком подходе теряется системность модели в целом. Не нужно заниматься грамотным агрегированием стрелок (и соответственно потоков объектов) – достаточно нарисовать несколько туннельных стрелок. Сознательное использование туннельных стрелок возможно только для чернового, промежуточного, эскизного варианта модели. В финальной версии модели их быть не должно. В качестве исключения возможна ситуация, когда вы просто моделируете отдельный процесс небольшого масштаба, а не создаете архитектуру бизнес-процессов компании. На рис.46 показаны туннельные стрелки в Business Studio. Ситуация 1: если стрелка начинается с незакрашенного кружка, то это означает, что стрелка: 1) не привязана ни к одному процессу на данной диаграмме, как исходящая; 2) не будет показана на диаграмме вышестоящего уровня. Ситуация 2: если стрелка имеет выколотый (незакрашенный) наконечник, то это означает, что стрелка не будет показана на диаграмме нижележащего уровня. В терминах нотации IDEF0, эта стрелка не будет «мигрировать» на нижний уровень. Ситуация 3: если стрелка начинается с незакрашенного кружка, то это означает, что стрелка не будет показана на диаграмме нижележащего уровня. Ситуация 4: стрелка имеет выколотый (незакрашенный) наконечник, то это означает, что стрелка: 1) не привязана ни к одному процессу на данной диаграмме, как входящая; 2) не будет показана на диаграмме вышестоящего уровня. 1 2 СТРЕЛКА Введем важное правило: 3 ПРОЦЕСС 4 СТРЕЛКА Рис.46. Туннельные стрелки. На готовой диаграмме процесса не может быть туннельных стрелок. Если на диаграмме остались туннельные стрелки, то это может означать, что: либо работа над диаграммой не закончена, либо бизнес-аналитик просто забыл про эту стрелку. © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 73 Теперь поговорим о так называемых междиаграммных ссылках – сокращенно – МДС. Это элемент функционала Business Studio. Междиаграммная ссылка представляет собой ссылку на другой процесс модели. Если к значку МДС привязать стрелку на одной диаграмме, то соответствующие МДС и стрелка автоматически появляются на другой, соответствующей диаграмме. На рис. 47 показана Стрелка М и междиаграммная ссылка на процесс под названием «Другая модель». МДС перечеркнута красным крестом. В предлагаемой мной методологии действует принцип: Использование междиаграммных ссылок в модели запрещено. Исключение составляет ситуация, когда мы при помощи МДС увязываем по входам/выходам разные модели бизнес-процессов, каждая из которых имеет свою контекстную диаграмму. УПРАВЛЕНИЕ СТРЕЛКА О1 Управление процессом СТРЕЛКА У1 СТРЕЛКА У1.1. Бизнес-процесс А СТРЕЛКА А1 СТРЕЛКА А СТРЕЛКА У3.1. СТРЕЛКА О1.1. СТРЕЛКА У1.2. СТРЕЛКА Б Бизнес-процесс Б СТРЕЛКА А2 СТРЕЛКА Ж СТРЕЛКА Г1 СТРЕЛКА Д СТРЕЛКА О1.2. Другая модель СТРЕЛКА У1.3. СТРЕЛКА В СТРЕЛКА М Бизнес-процесс В СТРЕЛКА Г2 СТРЕЛКА Г СТРЕЛКА О1.3. СТРЕЛКА Г3 Рис. 47. Модель в IDEF0. (7). Во многих компаниях я наблюдал картину непродуманного использования МДС на диаграммах IDEF0. Говорить о системной модели бизнеса в этом случае не приходится. Поэтому в предлагаемой мной методологии использовать туннельные стрелки и МДС запрещено. © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 74 7.8. Стрелки снизу (стрелки «механизмов») На рис. 48 появился новый блок деятельности «Бизнес-процесс обеспечения». Конечно, рисовать процессы обеспечения прямо вот так на диаграмме – плохо. (Все обеспечивающие процессы в виде одного блока могут быть на диаграмме А0, но не на диаграммах процессных категорий, групп и т.д.). Но для учебных целей вполне возможно. Из блока «Бизнес-процесс обеспечения» выходит Стрелка ОБ1. Ее можно было бы назвать, например, «ИТ-сервис» или «Инфраструктура». Стрелка входит в блок «Бизнеспроцесс Б» снизу в соответствии с требованиями нотации IDEF0. Кроме того, она покрашена в зеленый цвет, чтобы явно выделить на диаграмме стрелки «обеспечения». Другой пример, если мы хотим показать, что какой-то процесс обеспечивает другой персоналом, то соответствующая стрелка снизу также должна быть зеленого цвета. УПРАВЛЕНИЕ СТРЕЛКА О1 Управление процессом СТРЕЛКА У1 СТРЕЛКА У1.1. Бизнес-процесс А СТРЕЛКА А1 СТРЕЛКА А СТРЕЛКА У3.1. СТРЕЛКА О1.1. СТРЕЛКА Б СТРЕЛКА У1.2. Бизнес-процесс Б СТРЕЛКА А2 СТРЕЛКА Ж СТРЕЛКА Г1 СТРЕЛКА Д СТРЕЛКА У1.3. СТРЕЛКА О1.2. СТРЕЛКА У1.4. СТРЕЛКА У2.1. СТРЕЛКА В Бизнес-процесс обеспечения Бизнес-процесс В СТРЕЛКА ОБ1 СТРЕЛКА Г2 СТРЕЛКА Г СТРЕЛКА О1.4. СТРЕЛКА О1.3. СТРЕЛКА Г3 Рис.48. Модель в IDEF0. (8). Для того, чтобы какой-то процесс обеспечивал другой процесс ресурсами, от процесса-заказчика должен поступать соответствующий запрос («заявка»). Поэтому на диаграмме создана Стрелка У2.1., которая выходит из блока «Бизнес-процесс Б» и поступает как управляющее воздействие в блок «Бизнес-процесс обеспечения». Напомню правило, что из блока «Бизнес-процесс Б» в блок «Бизнес-процесс обеспечения» не может поступать больше одной стрелки. Так что Стрелка У2.1. может содержать не только «Заявку», но и, например, «План обслуживания» и «Соглашение по уровням сервиса» и т.п. © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 75 7.9. Декомпозиция процесса Выберем «Бизнес-процесс Б» на диаграмме и выполним его декомпозицию, нажав синюю стрелку вниз («Перейти на уровень элемента») на панели инструментов Business Studio. Получим следующую диаграмму (рис. 49). Все стрелки, входящие в блок «Бизнеспроцесс Б» были автоматически перенесены на диаграмму нижнего уровня. Этот механизм часто называют «миграцией стрелок». Теперь необходимо показать процессы на диаграмме и привязать к ним соответствующие стрелки. СТРЕЛКА У1.2. СТРЕЛКА У3.1. СТРЕЛКА Б СТРЕЛКА Ж СТРЕЛКА А2 СТРЕЛКА Г1 СТРЕЛКА В СТРЕЛКА Д СТРЕЛКА У2.1. СТРЕЛКА ОБ1 NODE: TITLE: Бизнес-процесс Б СТРЕЛКА О1.2. NO.: 1.1 Рис. 49. Модель в IDEF0. (9). Хотел бы предостеречь от использования копирования стиля стрелок. Если так делать, то можно поменять не только внешний вид, но смысл стрелки. Например, сделать туннельную стрелку внешне похожей на обычную. Потом придется потратить время на поиск ошибки на диаграмме. Строить модель можно следующим образом: 1) определить и создать на диаграмме требуемые блоки деятельности (процессы), в том числе обязательно создать «Процесс управления процессом…»; 2) привязать стрелки к процессу управления; 3) создать стрелки управления и отчетности для всех блоков деятельности; 4) привязать существующие стрелки к блокам; при необходимости создать новые стрелки; 5) привязать к каждой стрелке (там, где их нет) соответствующие объекты из справочника «Объекты деятельности»; © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 76 6) еще раз внимательно посмотреть на диаграмму; подвигать стрелки и их названия так, чтобы диаграмма стала визуально нагляднее; 7) проверить правильность построения диаграммы с учетом сформулированных в Методологии правил. Названия стрелок на диаграмме располагаются так, чтобы схема процесса выглядела как можно нагляднее. Если ввести жесткие правила расположения стрелок, то это может привести в обратному, нежелательному результату. Минимально необходимые требования по работе со стрелками на диаграммах в нотации IDEF0 (включаются в «Соглашение по моделированию»): • стрелки должны быть названы существительными с большой буквы; точки в конце названия не ставятся; • в названии стрелки ставится знак «+», если по стрелке перемещается более одного объекта (в учебном примере знаки «+» не поставлены); • названия стрелок не должны перекрываться, в том числе блоками деятельности; • названия стрелок должны быть расположены по горизонтали (за исключением стрелок снизу); • названия стрелок должны быть распложены так, чтобы можно было быстро визуально идентифицировать соответствующую стрелку; • стрелки, приходящие с диаграммы верхнего уровня должны начинаться от левого края диаграммы; стрелки, уходящие на диаграмму верхнего уровня должны заканчиваться у правого края диаграммы; названия таких стрелок должны быть расположены ближе к краям диаграммы. На следующем рис. 50 представлена готовая диаграмма Бизнес-процесса Б. СТРЕЛКА У1.2. СТРЕЛКА У3.1. СТРЕЛКА БО1 Управление Бизнес-процессом Б СТРЕЛКА У2.1. СТРЕЛКА О1.2. СТРЕЛКА БУ1 СТРЕЛКА БУ1.1. СТРЕЛКА Б Бизнес-процесс Б 1.1. СТРЕЛКА Д СТРЕЛКА БО1.1. СТРЕЛКА ПФ1 СТРЕЛКА БУ1.2. СТРЕЛКА Г1 Бизнес-процесс Б 1.2. СТРЕЛКА А2 СТРЕЛКА БУ1.3. СТРЕЛКА БО1.2. СТРЕЛКА ПФ2 Бизнес-процесс Б 1.3. СТРЕЛКА В СТРЕЛКА Ж СТРЕЛКА БО1.3. СТРЕЛКА ОБ1 Рис.50. Модель в IDEF0. (9). © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 77 Все стрелки, входящие с диаграммы вышестоящего уровня привязаны к блокам деятельности. Все стрелки, уходящие на диаграмму вышестоящего уровня, привязаны к соответствующим блокам. Показаны стрелки управления и стрелки отчетности. Снизу к блокам привязаны стрелки ресурсного обеспечения. В целом, диаграмма процесса готова к согласованию и утверждению. 7.10. Выходы на вышестоящую диаграмму В реальном проекте в работу по моделированию бизнес-процессов могут быть вовлечены руководители подразделений. В силу недостаточной осознанностей действий при работе с моделью (даже несмотря на проведенное обучение и наличие «Соглашения по моделированию») сотрудники допускают критические ошибки. Вероятно, это объясняется недостатком опыта моделирования и слабой внутренней мотивацией сделать качественную модель процесса. На рис.51 показана модель, «испорченная» таким «неумелым» сотрудником. СТРЕЛКА У1.2. СТРЕЛКА У3.1. СТРЕЛКА БО1 Управление Бизнес-процессом Б СТРЕЛКА У2.1. СТРЕЛКА БУ1 СТРЕЛКА О1.2. Заявка на расходные материалы СТРЕЛКА БУ1.1. СТРЕЛКА Б ОТХОДЫ Бизнес-процесс Б 1.1. СТРЕЛКА Д СТРЕЛКА БО1.1. СТРЕЛКА ПФ1 СТРЕЛКА БУ1.2. БРАК СТРЕЛКА Г1 Отчет по выполнению проекта оптимизации остатков на промежуточном СТРЕЛКА БУ1.3.складе инструмента за 2019 год Бизнес-процесс Б 1.2. СТРЕЛКА А2 СТРЕЛКА БО1.2. СТРЕЛКА ПФ2 Бизнес-процесс Б 1.3. СТРЕЛКА В СТРЕЛКА Ж СТРЕЛКА БО1.3. СТРЕЛКА ОБ1 Рис. 51. Модель в IDEF0. (10). Как правило, сотрудник вспоминает, что «он предоставляет такой-то важный документ руководителю или направляет запрос в….». Но такого документа на схеме нет. Сотрудник не понимает (или, скорее, не хочет понимать) разницу между стрелкой и объектом из справочника «Объекты деятельности» и рисует на диаграмме всё, что считает важным, интуитивно приравнивая стрелку документу. В результате на диаграмме рис. 51 созданы четыре новых стрелки, причем все они являются туннельными – имеют выколотые наконечники. Если убрать туннелирование средствами Business Studio (нажать на панели кнопку «Туннель конца»), то все эти стрелки будут автоматически показаны на диаграмме вышестоящего уровня. © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 78 Всего с данной диаграммы наверх будет уходить девять (!) стрелок. То есть на диаграмме вышестоящего уровня из блока «Бизнес-процесс Б» будет выходить девять стрелок. Это уже нарушение рекомендаций по моделированию. Что же делать? Давайте разбираться. Стрелка «Заявка на расходные материалы» явно создана по названию одного документа. Скорее всего, этот документ можно привязать к Стрелке У2.1., удалив стрелку «Заявка на расходные материалы». Рассмотрим стрелки материальных потоков «Отходы» и «Брак». На диаграмме у нас уже есть Стрелка Ж, показывающая материальный поток и выходящая на диаграмму вышестоящего уровня. Стрелки «Отходы» и «Брак» можно объединить с ней. Стрелка «Отчет по выполнению проекта оптимизации остатков на промежуточном складе инструмента за 2019 год» - вообще никуда не годится. Ее нужно удалить с диаграммы. Если очень хочется, соответствующий документ можно пустить по Стрелке БО1.3. в блок «Управление Бизнес-процессом Б», а через него потом по Стрелке О1.2. на диаграмму вышестоящего уровня. После указанных изменений диаграмма будет выглядеть следующим образом (см. рис.52). СТРЕЛКА У1.2. СТРЕЛКА У3.1. СТРЕЛКА БО1 Управление Бизнес-процессом Б СТРЕЛКА У2.1. СТРЕЛКА О1.2. СТРЕЛКА БУ1 СТРЕЛКА БУ1.1. СТРЕЛКА Б Бизнес-процесс Б 1.1. ОТХОДЫ СТРЕЛКА Д СТРЕЛКА БО1.1. СТРЕЛКА ПФ1 СТРЕЛКА БУ1.2. Бизнес-процесс Б 1.2. БРАК СТРЕЛКА А2 СТРЕЛКА Г1 СТРЕЛКА БУ1.3. СТРЕЛКА БО1.2. СТРЕЛКА ПФ2 Бизнес-процесс Б 1.3. СТРЕЛКА В СТРЕЛКА Ж СТРЕЛКА БО1.3. СТРЕЛКА ОБ1 Рис.52. Модель в IDEF0. (11). Хотел бы обратить внимание, что в Business Studio можно создать стрелку, перетащив, например, документ из справочника «Объекты деятельности» на диаграмму. Новая стрелка получит название документа и к ней автоматически будет привязан этот объект. Но документ и стрелка – это абсолютно разные объекты модели. Они хранятся в разных справочниках Business Studio. Это важно понимать. Поэтому введу еще одно важное правило: © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 79 Стрелки без привязанных к ним объектов деятельности в завершенной модели компании недопустимы. Как быть, если с нашей диаграммы наверх уходит заведомо больше стрелок, чем восемь? Такая ситуация, скорее всего, сложилась из-за того, что стрелки рассматривались тождественно документам, а не как «трубы», по которым может двигаться несколько объектов деятельности. Это первое, на что нужно обратить внимание. Далее нужно воспользоваться методом агрегирования, как показано на следующем рис. 53. Бизнес-процесс А СТРЕЛКА А СТРЕЛКА Б СТРЕЛКА А1 Бизнес-процесс Б СТРЕЛКА А2 Бизнес-процесс В СТРЕЛКА 10 Бизнес-процесс А1 СТРЕЛКА 1 СТРЕЛКА 11 СТРЕЛКА 2 СТРЕЛКА 12 Бизнес-процесс Б1 СТРЕЛКА 3 СТРЕЛКА А Бизнес-процесс А2 СТРЕЛКА А1 СТРЕЛКА 4 СТРЕЛКА 13 СТРЕЛКА 5 СТРЕЛКА 14 СТРЕЛКА 6 СТРЕЛКА 15 СТРЕЛКА Б Бизнес-процесс А3 Бизнес-процесс Б2 СТРЕЛКА Б СТРЕЛКА 7 СТРЕЛКА 8 СТРЕЛКА 16 СТРЕЛКА 9 СТРЕЛКА 17 Бизнес-процесс Б3 СТРЕЛКА 18 Рис. 53. Агрегирование стрелок. Вариант 1 (нежелательный). Сверху показан процесс, который включает три блока: «Бизнес-процесс А», «Бизнеспроцесс Б» и «Бизнес-процесс В». Ниже слева условно показана декомпозиция Бизнеспроцесса А. Видно, что пять стрелок объединяются в одну Стрелку А и четыре стрелки – в одну Стрелу Б. На диаграмме верхнего уровня Стрелка А разделяется на Стрелку А1 и Стрелку А2. Стрелка Б ветвится и поступает в два блока «Бизнес-процесс Б» и «Бизнеспроцесс В.». Справа на схеме показана декомпозиция Бизнес-процесса Б. На ней Стрелка А1 разделяется на пять стрелок, а Стрелка Б – на четыре стрелки. Можно ли так делать? Да, можно. Но если внимательно посмотреть на три схемы, то видно, что это нерационально. Сначала мы агрегируем четыре стрелки в Стрелку А, потом разделяем Стрелку А1 на пять стрелок. Как уже не раз говорилось выше, стрелки можно рассматривать как трубы, по которым движутся объекты. По одной стрелке может двигаться множество объектов. Поэтому нет никакого смысла в создании трех стрелок 12-3, вместо одной. Такие места на рис.53 выделены красными овалами. © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 80 Измененные схемы процессов показаны на рис. 54. Бизнес-процесс А СТРЕЛКА А СТРЕЛКА Б СТРЕЛКА А1 Бизнес-процесс Б СТРЕЛКА А2 Бизнес-процесс В СТРЕЛКА А1.1. Бизнес-процесс А1 СТРЕЛКА 1.1.А СТРЕЛКА А Бизнес-процесс А2 Бизнес-процесс Б1 СТРЕЛКА Б1.1. СТРЕЛКА А1 СТРЕЛКА 1.2.А Бизнес-процесс Б2 СТРЕЛКА А1.2. СТРЕЛКА 1.1.Б СТРЕЛКА Б1.2. СТРЕЛКА Б Бизнес-процесс А3 СТРЕЛКА Б СТРЕЛКА 1.3.А СТРЕЛКА А1.3. СТРЕЛКА 1.2.Б Бизнес-процесс Б3 СТРЕЛКА Б1.3. Рис. 54. Агрегирование стрелок. Вариант 2 (рекомендуемый). Приведу еще один пример некорректного агрегирования стрелок, но теперь на примере стрелок управления – см. рис. 54 (для упрощения на диаграмме показаны только стрелки управления). Управление бизнес-процессом Управление бизнес-процессом План по БП А Оперативные решение по БП А Планы по бизнеспроцессу + План по Бизнеспроцессу А + Регламент выполнения БП А План по БП Б Бизнес-процесс А Нормы расхода Бизнес-процесс А План контрольных проверок План по Бизнеспроцессу Б + Приказы по персоналу Бизнес-процесс Б Требования к оформлению отчета План по БП В Бизнес-процесс Б Бизнес-процесс В План по Бизнеспроцессу В + Бизнес-процесс В Рис. 55. Агрегирование стрелок управления. Видно, что из блока «Управление бизнес-процессом» выходит девять стрелок. Это не только нерационально, но и запрещено правилами Методологии. Справка показан корректный вариант использования стрелок. © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 81 На следующем рис. 56 показано, что при наведении и фиксации курсора на стрелке (без клика по стрелке), примерно через 2 секунды появляется всплывающий список объектов, которые перемещаются по стрелке. В данном примере – это план, распоряжение и регламент выполнения бизнес-процесса. Рис.56. Всплывающий список объектов. По итогам рассмотрения сформулирую следующее правило: За пределы диаграммы не может уходить более восьми стрелок. Если при моделировании получается, что наверх выходят, например, 10 стрелок, то нужно их агрегировать до допустимого количества. В противном случае, при возвращении на диаграмму вышестоящего уровня будет нарушено правило по ограничению стрелок, выходящий из одной стороны блока деятельности. Но лучше, конечно, минимизировать количество стрелок, который мигрируют на диаграмму вышестоящего уровня. Мы рассмотрели базовые правила использования нотации IDEF0, необходимые для создания диаграмм бизнес-процессов. Введены некоторые более жесткие правила, которые позволяют сделать модель системной, максимально снизить субъективность. В следующем разделе вы сможете применить полученные знания для построения моделей А0 (категории процессов). © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 82 8. Разработка модели бизнес-процессов в нотации IDEF0 8.1. Модель бизнес-процессов компании на основе функциональных бизнес-процессов подразделений. Инженерный вариант. Прежде всего построим функциональную модель компании с использованием уже созданных реестров функциональных процессов подразделений. Для этого в Business Studio скопируем модель компании в целом, изменим название контекстной диаграммы и откроем контекстную модель. После нажатия кнопки «Перейти на уровень элемента» сформируется диаграмма А0. На нее мигрируют стрелки с контекстной диаграммы – см. рис. 58. На диаграмме пришлось немного отредактировать визуальный вид названий, так как они загораживали стрелки. Для этого в Business Studio есть функция «Работа с текстовыми метками» - см. рис. 57. Рис. 57. Работа с текстовыми метками. Так же хотел бы обратить внимание, что включена сетка – по ней удобнее выравнивать элементы, расположенные на диаграмме. © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 83 Рис. 58. Диаграмма А0. (1) © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 84 Теперь необходимо из реестров функциональных процессов подразделений перенести процессы в модель компании. Но с чего начать? На диаграмме А0 нужно создать столько элементов (процессов), сколько в компании крупных структурных подразделений. Если их больше 8-10, то целесообразно рассмотреть различные варианты группировки, либо увеличить размер диаграммы. Но надо понимать, что при этом возникнут сложности с документированием моделей в печатном виде. На рис. 59 показан результат моделирования функциональных процессов подразделений на диаграмме А0. Схема получилась сложная, поэтому пришлось поместить ее на лист формата А3. Это плохой вариант с точки зрения документирования. Но при создании диаграммы А0 – модели бизнеса в целом - можно сделать исключение. На построенной схеме показаны ВСЕ связи между структурными подразделениями компании. Это не эскиз в карандаше или некая абстрактная модель организации, а инженерная модель со всеми необходимыми связями. Не нужно пугаться большого количества стрелок на диаграмме. По каждой стрелке, как уже я говорил выше, передаются конкретные документы. Напомню, что для вашего проекта нужно будет принять решение о целесообразности использования именного этого сложного метода построения модели. Возможно, вам подойдет более простой, эскизный метод моделирования (о нем будет сказано ниже). При создании диаграммы А0, представленной на рис. 59, нужно обратить внимание на следующие практические моменты: • объекты деятельности именованы по названию структурных подразделений верхнего уровня, например, «Процессы департамента продаж» и т.п. • формирование схемы удобно проводить в следующей последовательности: 1. создание процессов на диаграмме; 2. привязка стрелок, мигрировавших с верхнего уровня; 3. создание системообразующих связей между объектами: стрелки управления и информации, стрелки материальных потоков; 4. создание стрелок административного управления и отчетности; 5. создание стрелок запросов на ресурсы и стрелок поставки ресурсов. • стрелки управления показаны красным цветом, причем стрелки управления между департаментами, участвующими в основных процессах, сделаны толще, т.к. представляют собой системообразующие связи; • стрелки отчетности показаны серым цветом; • стрелки материальных потоков показаны синим цветом и сделаны толще; • стрелки запросов на ресурсы показаны коричневым цветом для того, чтобы визуально отличить запросы на ресурсы от штатных стрелок управления; • стрелки ресурсов, входящие снизу, показаны зеленым цветом (кроме стрелок материальных потоков – они показываются жирным синим); названия этих стрелок выровнены по вертикали для повышения читаемости диаграммы; «ресурсные» стрелки проведены снизу диаграммы для повышения ее читаемости – в результате внешне получилось что-то похожее на «системную шину» или шлейф питания компьютера; © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 85 Видение, Культура цели Законы, стандарты Информация об изменениях внешней среды Информация для внешней среды Управление компанией Планы + Потребности и платежеспособный спрос Информация о продуктах и сервисах ТМЦ для УК + Финансы для УК + Сервис для УК + Процессы департамента продаж Юр. сервис для УК + Планы ДП + Персонал для УК + Отчеты + Информация на сайте + Заявки на пр-во + Заявки ДП на сервис + Заявки ДП на персонал+ Заявки ДП на юр. сервис + Заявки на отгрузку ГП+ Информация для конкурентов Ресурсы ТМЦ для ДП + Финансы для ДП + Сервис для ДП + Персонал для ДП + Юр. сервис для ДП + Счета на оплату+ Отчеты ДП + Заявки ДП на оплату + Заявки на ТМЦ+ Планы ДЗ + Процессы департамента закупок Заказы на ТМЦ + ГП по склада + Сырье со склада + Заявки ДЗ на сервис + Заявки ДЗ на персонал + Заявки ДЗ на юр. сервис + Заказы. Ресурсы ТМЦ + ТМЦ для ДЗ + Планы ДПр + Потребность в сырье + Процессы производственного департамента Заявки на ремонт оборудования + Заявки ДПр на персонал + Заявки ДПр на юр. сервис + ГП +ДПр на оплату + Заявки Процессы технологического департамента Нормы + Заявки ТД на оплату + Заявки ТД на сервис + ЗаявкиТД ТДнанаюр. персонал Заявки сервис + + Заявки ФД на сервис + Заявки ФД на персонал + Заявки ФД на юр. сервис + Сервис для ТД + Планы ИТД + Отчеты ДПр + Заявки на сервис + Персонал для ТД + Информация об оплате + Официальная отчетность + Заявки ФД на ТМЦ + Финансовые ресурсы + Процессы финансового департамента Заявки ТД на ТМЦ + ТМЦ для ТД + Капитал Лаб. оборудование+ Персонал для ДПр + ТМЦ для ДПр + Заявки на оплату + Финансы для ДПр + Планы ФД + Юр. сервис для ДПр + Отчеты ДПр + Готовая продукция. Сервис Планы ТД + Финансы для ТД + Информация о выполнении заказа + Юр. сервис для ТД + Сервис для ДЗ + Юр. сервис для ДЗ + Финансы для ДЗ + Заявки ДЗ на оплату + Персонал для ДЗ + Отчеты ДЗ + Оборудование + Заявки ИТД на ТМЦ + Заявки ИТД на оплату + Процессы инженернотехнического департамента Сервис + Сервис внутр. + Заявки ИТД на персонал + Заявки ИТД на юр. сервис + Заявки ДЮ на сервис + Процессы департамента по работе с персоналом Заявки ДРП на юр. сервис + Заявки ДРП на ТМЦ + Персонал + Заявки ДРП на оплату + Сервис для ДПР + Персонал для ДРП + Отчеты ДРП + ТМЦ для ДРП + Заявки ДРП на сервис + Финансы для ДРП + Персонал для ДЮ + Юр. сервис для ДЮ + Сервис для ДЮ + ТМЦ для ДЮ + Сервис для ИТД + Заявки на персонал + Отчеты ДЮ + Финансы для ДЮ + Дивиденды. Капитал Планы ДРП + Заявки ДЮ на персонал + Человеческие ресурсы Персонал для ИТД + ТМЦ для ИТД + Юр. сервис + Финансы для ИТД + Заявки ДЮ на ТМЦ + Заявки ДЮ на оплату + Процессы юридического департамента Исправное оборудование + Юр. сервис для ИТД + Отчеты ИТД + Планы ДЮ + Заявки на юр. сервис + Юр. сервис для ДРП + ТМЦ для ФД + Финансы для ФД + Сервис для ФД + Персонал для ФД + Юр. сервис для ФД + Отчеты ФД + © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. Человеческие ресурсы 86 Рис. 59. Диаграмма А0. (2) © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 87 • • • • • • объединение стрелок использовано для того, чтобы избежать чрезмерного количество исходящих и входящих стрелок; использовано наложение стрелок одного типа друг на друга для повышения визуальной наглядности схемы; по возможности, применено равномерное распределение стрелок (одинаковое расстояние между стрелками ресурсов, например); названия стрелок сделаны с учетом представленной выше рекомендации – краткое название ключевого потока, перемещающегося по стрелке, и знак «+»; там, где между двумя объектам деятельности уже была создана стрелка, вторая стрелка не создавалась; такой подход может показаться на первый взгляд, несколько странным, но с его помощью можно существенно сократить количество стрелок на диаграмме; кроме того, он является требованием рассматриваемой Методологии; использованы сокращения названий департаментов для экономии места на диаграмме. Возможно, кому-то не понравится название объектов в виде «Процессы департамента…». В этом случае можно написать «Деятельность департамента…». Гораздо хуже будет назвать объект просто «Департамент…». Хотя это не меняет сути дела, поскольку в данном случае мы говорим о функциональной модели организации, построенной на основе существующей организационной структуры 12. Трудоемкость создания диаграммы. На разработку диаграммы А0, представленной на рис. 59, ушло около одного рабочего дня (без учета времени, потраченного на сбор и анализ данных о компании; без привязки документов к стрелкам). Поэтому нельзя говорить о какой-то чрезмерно высокой трудоемкости создания такого рода схем. Методология, настойчивость и аккуратность – вот залог успеха при формировании таких моделей. Естественно, функционал среды моделирования может либо упростить, либо сделать работу сложнее. Но не более того. 12 Строго говоря, иерархическая модель функций компании может весьма отличаться от иерархической модели организационной структуры. Дело заключается в выбранном методе построения этой модели. © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 88 8.2. Модель бизнес-процессов компании на основе функциональных бизнес-процессов подразделений. Эскизный вариант. Если нет задачи или возможности создавать комплексную инженерную модель бизнеса, то можно применить метод эскизного моделирования на верхнем уровне. Видно, что основную сложность диаграмме, представленной на рис. 59 придают стрелки запросов на ресурсы и стрелки, показывающие потоки ресурсов (стрелки снизу). Если убрать с диаграммы все эти стрелки (см. рис. 60), то она станет существенно проще. Но возникает вопрос, как показать, например, запросы из всех процессов («заявки на оплату») в процесс Финансового департамента? Как показать, что Финансовый департамент обеспечивает все остальные процессы финансовыми ресурсами (практически это выражается в оплате счетов в соответствии с заранее утвержденными бюджетами)? Ответ простой - если такой задачи нет, то и показывать ничего не нужно. Ограничение – в Business Studio не будут формироваться полные положения о подразделениях. На рис. 60 использован некорректный 13 способ – я писал о нем выше. Создана и использована внешняя ссылка под названием «Все процессы». К чему может привести такое использование внешних ссылок? На диаграмме показано, что все процессы «как бы представляют заявки» и «как бы получают» запрашиваемые ресурсы. Это условность, абстракция, эскизное представление. Очевидно, что при таком подходе отследить реальный поток документов между структурными подразделениями и процессами будет невозможно. Это не является проблемой в том случае, если такая цель перед моделью не ставилась. Но в данном случае нужно четко понимать, что разные инструменты используются для разных задач. Эскизная модель компании, выполненная в карандаше на листке бумаги, хороша для продумывания стратегии, модели компании и обсуждения на стратегических сессиях в рамках принятия ключевых решений. Но для решения таких задач, как создание единой базы данных по бизнес-процессам, автоматического формирования регламентов и создания единой платформы для автоматизации бизнеспроцессов, эскизная модель может оказаться непригодной. Впрочем, это зависит от степени «эскизности» этой модели. 13 Корректный или некорректный - можно определить только по отношению к выбранной вами Методологии. © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 89 Видение, цели Культура Законы, стандарты Информация об изменениях внешней среды Информация для внешней среды Управление компанией Отчеты + Планы + Планы ДП + Потребности и платежеспособный спрос Информация о продуктах и сервисах Информация на сайте + Процессы департамента продаж Отчеты ДП + Информация для конкурентов Заявки на пр-во + Счета на оплату + Заявки на отгрузку ГП+ Заявки на ТМЦ Все процессы Ресурсы Планы ДЗ + Процессы департамента закупок ТМЦ Все процессы Заказы на ТМЦ + ГП по склада + Сырье со склада + Планы ДПр + Потребность в сырье + Отчеты ДЗ + Процессы производственного департамента Все процессы Капитал Процессы финансового департамента ГП + Готовая продукция. Сервис Планы ТД + Планы ФД + Заявки на оплату Заказы. Ресурсы Заявки на ремонт оборудования + Отчеты ДПр + Лаб. оборудование+ Нормы + Процессы технологического департамента Официальная отчетность + Информация об оплате + Финансовые ресурсы Отчеты ФД + Планы ИТД + Все процессы Заявки на сервис Все процессы Планы ДЮ + Заявки на юр. сервис Все процессы Процессы юридического департамента Отчеты ДПр + Юр. сервис Оборудование + Все процессы Процессы инженернотехнического департамента Человеческие ресурсы Заявки на персонал Все процессы Процессы департамента по работе с персоналом Сервис Отчеты ИТД + Все процессы Исправное оборудование + Дивиденды. Капитал Планы ДРП + Отчеты ДЮ + Сервис + Персонал Все процессы Отчеты ДРП + © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. Человеческие ресурсы 90 Рис. 60. Диаграмма А0. Эскизный вариант модели. © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 91 На следующем рис. 61 показана цепочка причинно-следственных связей, которая может возникнуть при создании эскизной модели бизнес-процессов. В результате, проект разработки архитектуры будет сорван или растянут на чрезмерно длительный срок. Кратко рассмотрим эту причинно-следственную связь. Создание эскизной модели архитектуры процессов Дезинтеграция модели. Ни одна задача не решена В обсуждение вовлекаются все руководители (без понимания задач и метода) Много замечаний на уточнение состава и границ процессов, потоков объектов Использование «заглушек», «подпорок» и костылей Рис 61. Проблемы создания эскизной модели архитектуры бизнес-процессов. Как правило, руководителей отделов мало волнуют понятия «архитектура», «система», «эскиз». Для них важно, чтобы их зона ответственности была четко определена, и на нее никто «не посягал». Для этого, с их точки зрения, в модели должны быть показаны все документы, выходящие в их процесс и исходящие из него, соответствующие поставщики и потребители. Поэтому по ходу вовлечения руководителей в обсуждение эскизной модели возникает много замечаний типа: «А где «Это»? А где «То»?». Вероятно, именно по этой причине профессор В. Шеер, в свое время, в нотации Value Added Chain фактически отказался от моделирования связей между процессами. Те стрелки, которые есть на модели ARIS VAD, являются весьма условными. Далее возникает ситуация, когда рабочая группа аналитиков пытается отобразить все доработки в части уточнения границ процессов по потокам документов на эскизной модели. Но эта модель изначально не была предназначена для этого! Попытка переделывать эскизную модель в инженерную «на ходу» приводит к использованию, мягко говоря, неидеальных методических решений. В результате получается, всё-таки, дезинтегрированная модель относительно низкого качества. Поэтому если вы решили разрабатывать эскизную модель процессов, то нельзя: • вовлекать в ее обсуждение всех руководителей подразделений; • допускать попытки уточнения модели, которые могут привести к ее усложнению и переходу к инженерному типу модели. Но кто же в этом случае будет согласовывать эскизную модель? Один из вариантов – создание Экспертного совета, включающего весьма узкий круг лиц, в том числе руководителя компании. © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 92 8.3. Модель бизнес-процессов компании на основе функциональных бизнес-процессов подразделений. Инженерный вариант. Декомпозиция. Теперь выполним декомпозицию блока деятельности «Процессы департамента продаж» и построим соответствующую модель. На рис. 62 показана схема под названием «Процессы департамента продаж». В данном случае, на схеме всего три объекта деятельности – «Процессы управления ДП», «Процессы отдела маркетинга» и «Процессы отдела продаж». На схеме видно, что в выбранной модели ведения бизнеса все заявки на ресурсы, предоставляемые обеспечивающими процессами, выходят из блока «Процессы управления ДП». Входами в блок являются серые стрелки типа «Отчет …+», по которым, в том числе, из отделов поступают заявки (например, на оплату или подбор нового сотрудника). Снизу схемы видны зеленые стрелки ресурсов. Они мигрируют с диаграммы вышестоящего уровня. Каждая из стрелок ветвится на соответствующую стрелку, входящую снизу в блоки процессов отделов. Далее выполним декомпозицию блока «Процессы отдела продаж» - соответствующая схема показана на рис. 63. На ней выделены следующие процессы: • Привлечение новых клиентов. • Заключение договоров реализации ГП. • Управление заказами клиентов. • Претензионная работа с клиентами. • Выполнение промо-акций. Названия процессов были взяты из реестра процессов функциональных процессов Департамента продаж. В Business Studio эти процессы были созданы в папке «Функциональные бизнес-процессы». Обратите внимание на слияние стрелок «Проекты договоров +», «Счета и информация +» и «Ответы на претензии клиентов +». Они объединяются в стрелу «Счета на оплату +». Как могут договора превращаться в счета? Это следствие принятого выше правила, которое говорит о том, что если между процессами есть взаимодействие, то используется только одна стрелка в одном направлении. Возможно, при работе с моделью (в том числе путем нескольких итераций) получится назвать стрелки корректнее. Но состав документов, которые по этим стрелкам будут двигаться, от изменения названий стрелок на схеме не изменится. Поэтому «борьба» за названия стрелок представляется мне не настолько важной и актуальной. © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 93 Планы ДП + Отчеты ОМ и ОП + Отчеты ДП + Заявки ДП на оплату + Заявки ДП на юр. сервис + Заявки ДП на сервис + Заявки ДП на персонал+ Процессы управления ДП Планы ОМ и ОП + Планы ОМ + Информация на сайте + Реклама + Потенциальные клиенты + Юр. сервис для ДП + Прайс-лист + Счета на оплату+ Заявки на отгрузку ГП+ Заявки на пр-во + ТМЦ для ОП ДП + Финансы для ОП ДП + Сервис для ОП ДП + Персонал для ДП + Юр. сервис для ОП ДП + Процессы отдела продаж Заявки на ГП + Отчеты ОП + Сервис для ДП + Заявки на исследования + Планы ОП + Персонал для ОП ДП + Персонал для ОМ ДП + Информация о выполнении заказа + ТМЦ для ОМ ДП + Потребности и платежеспособный спрос Юр. сервис для ОМ ДП + Отчеты ОМ + Финансы для ОМ ДП + Процессы отдела маркетинга Потребности + Сервис для ОМ ДП + Информация о продуктах и сервисах Финансы для ДП + ТМЦ для ДП + Рис. 62. Диаграмма А1. «Процессы департамента продаж». © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 94 Планы ОП + Отчеты по процессам ОП + Управление процессами отдела продаж План по процессу привлечения новых клиентов + Потенциальные клиенты + Информация о предложениях конкурентов + Запросы клиентов + Отчеты ОП + Прайс-лист Планы по процессам ОП + Заявки на исследования + Привлечение новых клиентов Клиенты в CRM + Отчет по процессу привлечения новых клиентов + Согласованные договора + План по процессу заключения договоров реализации ГП + Заключение договоров реализации ГП Проекты договоров + План по процесса управления заказами клиентов + Договора с клиентами + План по процессу претензионной работы с клиентами + Отчет по процессу заключения договором реализации ГП + Заявки на ГП + Прайс-лист + Управление заказами клиентов Информация о выполнении заказа + Счета на оплату+ Счета и информация + Заявки на пр-во + Заявки на отгрузку ГП+ Отчет по процессу управления заказами клиентов + Претензии клиентов + Информация о продуктах и сервисах Претензионная работа с клиентами Ответы на претензии клиентов + Отчет по процессу претензионной работы с клиентами + Информация об условиях поставки POS-материалов + План по процессу выполнения промоакций Выполнение промоакций Заявки на POSматериалы + POSматериалы + Отчет по процессу выполнения промо-акций + Сервис для ОП ДП + Персонал для ОП ДП + Финансы для ОП ДП + Юр. сервис для ОП ДП + ТМЦ для ОП ДП + © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 95 Рис. 63. Диаграмма «Процессы отдела продаж». © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 96 На следующих рис. 64 и 65 показаны диаграммы процессов «Привлечение новых клиентов» и «Поиск потенциальных клиентов» соответственно. Подпроцессы, представленные на диаграмме «Поиск потенциальных клиентов», являются уже достаточно простыми объектами деятельности. Декомпозиция этих блоков на диаграмму в нотации IDEF0 не представляется целесообразной. Каждый такой подпроцесс нужно описывать в нотации формата Work Flow: eEPC или BPMN. Возникает вопрос, что делать со стрелками, входящими и исходящими из блоков на диаграмме «Поиск потенциальных клиентов»? На диаграмме в нотации Work Flow можно и нужно показывать только документы (информацию), которые используются при выполнении процесса, т.е. его входы и выходы. На схеме в нотации Work Flow нецелесообразно будет показывать документы, связанные с управлением (планы и регламенты) и используемыми ресурсами. Например, план по процессу «Выполнить консультацию клиента по телефону» предполагает выполнение звонков пятистам клиентам в течение месяца. Это означает, что нужно будет выполнить 500 экземпляров этого процесса. Но на диаграмме процесса «Выполнить консультацию клиента по телефону» этот план, как вход просто не нужен – его невозможно будет осмысленно привязать к какой-либо операции процесса. Также не получится отобразить тот факт, что исполнитель выполнил, например, 498 звонков. Т.е. деятельность исполнителя по планированию, контролю исполнения и формированию отчета по процессу останется «за кадром». Отчет получится «как бы ниоткуда». Либо все-таки нужно будет определять процессы планирования, контроля и отчетности и показывать их в модели. Вообще говоря, это делать целесообразно, если мы хотим спроектировать и автоматизировать процессы управления бизнес-процессами. Некоторые этапы таких процессов могут быть автоматизированы, например, в BPMS. Первый вариант решения проблемы. На предыдущих диаграммах для описания «процессов управления процессами» служили блоки «Процессы управления…» и «Управлять процессом…». Если последовательно использовать данный подход, то на последней (самой нижней) диаграмме в нотации IDEF0 будет всего два блока: «Управлять процессом…» и «Выполнять процесс…». Второй вариант решения проблемы. Если мы опишем процесс «Выполнить консультацию клиента по телефону» в нотации IDEF0 (вместо BPMN), то на этой диаграмме можно будет показать такие блоки деятельности, как: • планировать выполнение процесса; • получать, оприходовать и выдавать в работу ресурсы (например, бумагу для принтера); • выполнять процесс; • контролировать и учитывать ход и результаты выполнения каждого экземпляра процесса; • формировать отчет по результатам выполнения нескольких экземпляров процесса за период. Все указанные блоки далее нужно будет декомпозировать на модели в нотации, например, BPMN. Аналогичным образом придется поступить для всех процессов на уровне, предшествующем диаграммам типа Work Flow (BPMN). Это нерационально ввиду дублирования и «захламления» модели совершенного одинаковыми, по сути, схемами. © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 97 План по процессу привлечения новых клиентов + Управление процессом привлечения новых клиентов Отчеты по процессу привлечения новых клиентов + Отчет по процессу привлечения новых клиентов + Заявки на исследования + Планы по процессам привлечения клиентов + Планы по процессу поиска потенциальных клиентов + Запросы клиентов + Поиск потенциальных клиентов Отчеты по процессу поиска потенциальных клиентов + Информация для заключения договора с клиентом после консультаций + Клиенты для переговоров + Планы по процессу проведения переговоров + Планы по процессу формирования ТКП для клиентов + Клиенты в CRM + Проведение переговоров Потенциальные клиенты + Планы по процессу проведения переговоров с ключевыми клиентами + Информация для заключение договора с клиентом после переговоров + Запрос ТКП + Отчеты по процессу проведения переговоров + Формирование ТКП для клиетов Информация о предложениях конкурентов + Информация для заключение договора с клиентом после ТКП + Ключевые клиенты для переговоров + Отчеты по процессу формирования ТКП для клиентов + Проведение переговоров с ключевыми клиентами Информация для заключение договора с ключевым клиентом после переговоров + Отчеты по процессу проведения переговоров с ключевыми клиентами + Сервис для ОП ДП + Персонал для ОП ДП + Финансы для ОП ДП + Юр. сервис для ОП ДП + ТМЦ для ОП ДП + © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 98 Рис. 64. Диаграмма «Привлечение новых клиентов» © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 99 Планы по процессу поиска потенциальных клиентов + Управлять процессом поиска потенциальных клиентов Отчеты по процессам поиска потенциальных клиентов + Отчеты по процессу поиска потенциальных клиентов + Планы по процессам поиска потенциальных клиентов + Планы по телефонным консультациям + Телефоны клиентов + Звонок от клиента + Потенциальные клиенты + Выполнить консультацию клиента по телефону Необходима консультация Отчеты по консультация клиента по по e-mail телефону + + E-mail Клиента + Запросы клиентов + Письмо от клиента + Информация для заключения договора с клиентом после консультаций + Планы по консультациям по E-mail + Планы по работе на ФБ + Выполнить консультацию клиента по e-mail Информация о необходимости телефонной консультации + Отчеты по консультациям по E-mail + Запрос от клиента на ФБ + Клиенты для переговоров + Сформировать ответ на вопрос потенциального клиента в группе на ФБ Информация о необходимости контакта с клиентом + Отчеты по работе на ФБ + Сервис для ОП ДП + Персонал для ОП ДП + Юр. сервис для ОП ДП + ТМЦ для ОП ДП + Финансы для ОП ДП + © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 100 Рис. 65. Диаграмма «Поиск потенциальных клиентов» © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 101 Третий вариант решения проблемы. Поскольку все «процессы управления процессом» на нижнем уровне являются типовыми, то можно их вообще вынести из общей модели и описать отдельно. Далее обязать каждого сотрудника следовать установленным в моделях требованиям при выполнении конкретных бизнес-процессов, за которые они отвечают. Так же можно создать систему нормативов для длительности выполнения операций процесса, процесса в целом, определить контрольные точки для измерения, создать систему мониторинга и контроля процесса по показателям. На рис. 66 показана модель процесса «Выполнить консультацию клиента по телефону». Эта модель выполнена в нотации BPMN. Пример сделан совсем простым, чтобы не переносить фокус внимания с вопросов построения архитектуры бизнеспроцессов на вопросы использования нотации BPMN (или другой нотации Work Flow, которая поддерживается в Business Studio: eEPC или «Процедура»). Еще раз подчеркну, что эта книга написана не про моделирование процессов в нотации BPMN, а про разработку архитектуры бизнес-процессов в Business Studio, в первую очередь с использованием нотации IDEF0. Если хотите научиться моделировать именно в BPMN, то рекомендую ознакомиться с соответствующей литературой (см. раздел в конце книги). На рис. 66 показан весьма простой процесс с примитивной логикой. В данном контексте это только учебный пример. Но очень важно то, что процесс интегрирован с моделью вышестоящего уровня по информационным потокам и событиям. Процесс может запускаться либо звонком клиента, либо двумя другими процессами. В свою очередь сам процесс может запускать на выполнение три других процесса. Нужно ли было показывать в виде свернутых пулов другие процессы, или достаточно было просто нарисовать на диаграмме абстрактный алгоритм обработки звонка? Уверен, что «да, нужно». Дело в том, что нас интересует непрерывность выполнения работы в рамках системы бизнес-процессов. Вполне вероятно, что в перспективе нужно будет определить сквозной процесс масштаба компании, в который данный небольшой процесс входит как составляющая часть. В любом случае, если мы хотим устранить разрывы между процессами и возникающие при этом проблемы (зоны безответственности, задержки процесса, потери ресурсов и т.п.), то нам нужно четко стыковать процессы по входам/выходам и синхронизовать по событиям. Если при моделировании в Business Studio мы это не сделаем, то все равно потом придется это делать при согласовании регламентов, настройке процессов в BPMS и т.п. Итак, я рассмотрел метод построения архитектуры бизнес-процессов компании на основе реестров функциональных бизнес-процессов подразделений. Как вы видите, на нижнем уровне могут получится мелкие, фрагментарные процессы, которые по отдельности не имеют ценности с точки зрения бизнеса в целом. Важно, чтобы при построении архитектуры бизнес-процессов своей компании в Business Studio, вы четко понимали, что делаете, какую методологию используете. К сожалению, периодически приходится наблюдать ситуацию, когда часть модели создана, по сути, путем описания функций подразделений, а часть – в виде «дырявых» и урезанных сквозных процессов (т.е. определенных без какой-либо системы, без понимания возможных сценариев и проч.). Последующая переделка такой «рыхлой» модели весьма трудоемка. © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 102 Сформировать ответ на вопрос потенциального клиента в группе на ФБ Выполнить консультацию клиента по e-mail Клиент Менеджер по продажам Выполнить консультацию клиента по телефону Звонок клиента Нет. Клиент сам позвонил Да Позвонить клиенту Да Нужна телефонная консультация (после запроса по e-mail) Вопрос клиента Проконсультиро вать клиента Клиент новый? Нет Документ Нужна телефонная консультация (после запроса на ФБ) Карточка клиента Уточнить вопрос клиента Представиться и уточнить статус клиента Нужно позвонить клиенту? Выяснить, кто менеджер и переключить звонок Документ 1С 1С Звонок клиента обработан Контактные данные клиента Звонок переключен Карточка клиента Получить контактные данные клиента и занести в CRM Результаты Нужна консультация по e-mail Результат Нужно обработки заключить звонка? договор Информация для заключения договора Документ телефонных переговоров 1С Подготовка к проведению переговоров Подготовка проекта договора с клиентом Выполнить консультацию клиента по e-mail Ответить на вопросы постоянного клиента по телефону Рис. 66. Диаграмма «Выполнить консультацию клиента по телефону» © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. Нужно провести Информация для переговоры переговоров с клиентом Вопрос клиента 103 8.4. Модель бизнес-процессов компании на основе группировки по базовым функциям бизнеса (цепочке создания ценности) В данном разделе показан пример формирования инженерной модели бизнеса компании на основе определения базовых функций бизнеса (цепочки создания ценности). На рис. 67 показан пример диаграммы А0. Чтобы уместить диаграмму на один лист формата А4, пришлось сделать ее весьма плотной с точки зрения компоновки стрелок. Если нет ограничений по размеру листа, например, используется принтер А3 или вообще принято решение смотреть диаграммы только на мониторах 24” и выше, то диаграмму можно сделать более читаемой. На рис. 67 представлены следующие базовые функции бизнеса: 1. Управление компанией. 2. Маркетинг, реклама и разработка новых видов продукции. 3. Продажи. 4. Закупка. 5. Производство. 6. Логистика. 7. Управление технологией и качеством. 8. Инженерно-техническое обеспечение. 9. Обеспечение операционной деятельности. Базовые функции бизнеса и категории процессов, определенные на основе анализа цепочек создания ценности компании, с моей точки зрения, представляют собой одни и те же сущности. На рис. 67 видно, что структура базовых функций бизнеса не совпадает со структурой организационных подразделений компании. Напомню, что этот факт всегда вызывает проблемы с точки зрения определения руководителей, которые должны отвечать за каждую категорию процессов (и далее – группу, процесс и проч.). В рамках представленного примера, сложно с ходу выбрать ответственного за категорию «Маркетинг, реклама и разработка новых видов продукции» или «Обеспечение операционной деятельности». Но, как я говорил выше, этот факт может стать началом серьезного обсуждения необходимости изменения организационной структуры компании, в том числе по выводу сервисных подразделений в ОЦО. В Википедии ОЦО определяется так: Общий центр обслуживания (ОЦО, англ. shared services center, также единый центр обслуживания, ЕЦО) — специально созданное подразделение в структуре крупной компании или учреждения, в которое передаются определённые бизнес-процессы всей организации (например, бухгалтерский учёт, управление кадрами). Например, плохо, когда бухгалтерия создает сложности для бизнеса вместо того, чтобы упрощать жизнь бизнес-подразделениям за счет скорости и простоты обслуживания. © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 104 Видение, цели Культура Законы, стандарты Информация об изменениях внешней среды Информация для внешней среды Управление компанией Отчеты + Планы + Планы для маркетинга, рекламы + Планы на упр. тех. + Информация на сайте + Ассортимент и цены + Документация по новому продукту + Заявки на ТМЦ для маркетинга + Информация для конкурентов Договора, счета + Заявки на отгрузку ГП + Прогноз продаж + Заявки на ТМЦ + Заявки поставщикам + Планы для обесп.+ Заявки на сервисы + Обеспечение операционной деятельности Планы для логистики + Заявки на ремонт + Сырье и материалы + Заявки на инж.тех сервис от обесп. + Заявки на ремонт а/т + Логистика Отчеты по логистике + Материалы + Готовая продукция + ЗИП, ГСМ + Информация об оплате + Официальная отчетность + Сервис по обесп. + Отчеты по обесп. + Инж.техническийСервис по обесп. сервис для обесп. + для обесп. + Рис. 67. Диаграмма А0. Построение модели на основе определения базовых функций бизнеса. © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. Готовая продукция. Сервис Заявки на обесп. сервис от логистики + Оборудование после ТОиР Инж. технический сервис + Заявки на ТМЦ для обесп. + Заявки на ТМЦ от инж.тех + Заявки на обесп. сервис от инж.тех + Заявки на отпуск сырья + Готовая продукция на склад + Заявки на обесп. сервис от производства + Отчеты по производству + Информация о качестве ГП + Сервис по обесп. для логистики + Инж.технический сервис для инж.тех + Капитал Человеческие ресурсы Сервис по обесп. для инж.тех + Отчеты по инж.тех + Производство Заказы. Ресурсы Заявки на ТМЦ для логистики + Потребность в сырье + Счет от поставщиков + Заявки на инж.тех. сервис + Инженернотехническое обеспечение Планы для производства + Сервис по обесп. для производства + Отчеты по закупкам + Заявки на доставку + Заявки на инж.тех сервис от закупок + Заявки на обесп. сервис от закупок + Закупка Сервис по обесп. для закупки + Отчеты по продажам + Инж.технический сервис для закупок + Продажи Планы для инж. тех. + Ресурсы Технология, нормы + Планы для закупки + Заявки на инж.тех сервис от продаж + Заявки на обесп. сервис от продаж + Заявки на обесп. сервис от маркетинга + Запросы клиентов + Заявки на инж.тех сервис от маркетинга + Информация по продажам + Инж.технический сервис для маркетинга, рекламы + Сервис по обесп. для маркетинга + Потребности и платежеспособный спрос Управление технологией и качеством Планы для продаж + Клиенты и продукты + Отчеты по маркетингу, рекламе + Инж.технический сервис для продаж + Маркетинг, реклама и разработка новых видов продукции Сервис по обесп. для продаж + Информация о продуктах и сервисах Спрос + Человеческие ресурсы Дивиденды. Капитал 105 Вернемся к рисунку 67. В некоторых бизнесах выделяют еще категорию процессов «Управление цепочкой поставок» и др. Главное, чтобы общее количество категорий на схеме не превышало 8-12 (12 – это крайний случай – не рекомендую). Технически, при построении диаграммы были использованы те же приемы, что и при создании диаграммы, представленной на рис. 59. На рис. 68 представлена модель базовой функции бизнеса «Маркетинг, реклама и разработка новых видов продукции». На диаграмме показаны четыре группы процессов, включая «Управление…». При внимательном содержательном анализе диаграммы возникает вопрос, входит ли, например, деятельность по разработке технологии производства нового продукта в группу процессов «Разработка новых видов продукции». Если «да», то означает ли это, что эту деятельность нельзя будет показывать внутри базовой функции бизнеса «Управление технологией и качеством» (см. рис. 67)? Или эту деятельность целесообразно продублировать в разных частях модели? В чем здесь проблема? Дело в том, что один и тот же процесс может запускаться в разных ситуациях для решения разных задач, но при этом с типовыми входами и стандартизованными выходами. Что я имею в виде? Процесс разработки технологии производства может запускаться как при создании нового продукта, так и при модернизации существующего, изменении технологии при переходе на другие марки оборудования/сырья и проч. Проблема в том, что таких, условно говоря, «неуникальных» процессов в компании много. Возникает вполне практическая задача многократного использования типовых процессов в различных контекстах запуска (технически для этого в Business Studio могут использоваться так называемые «процессы-ссылки»). Это очевидно. Но совершенно не очевидно, как методически правильно показать эту историю в иерархической структуре процессов, созданной в нотации IDEF0. В связи с этой проблемой, меня уже давно посещает мысль, что невозможно создать иерархическую процессную модель деятельности компании, в которой бы все процессы «встали на свое место» и не повторялись в разных частях модели. Эта проблема отсутствует при построении модели деятельности на основе реестров функциональных процессов подразделений. Но как только мы начинаем говорить о «базовых функциях бизнеса», а уж тем более – о сквозных процессах, создать общую процессную модель компании становится сложно, не дублируя рад процессов в различных ветках процессного дерева. Обратимся к математике. Существует так называемая «Теорема о причёсывании ежа». Она утверждает (см. Википедию), что «на сфере невозможно выбрать касательное направление в каждой точке, которое определено во всех точках сферы и непрерывно зависит от точки. Неформально говоря, невозможно причесать свернувшегося клубком ежа так, чтобы у него не торчала ни одна иголка». Другими словами, не существует непрерывного касательного векторного поля на сфере, которое нигде не обращается в ноль. Создание процессной архитектуры организации (не реестров функциональных процессов подразделений) – это задача, которая должна решаться в многомерном пространстве. Построить плоскую иерархическую модель компании, не дублируя процессы в разных ветках - это, вероятно, тоже самое, что попытка причесать ёжа. © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 106 Планы для маркетинга, рекламы + Отчеты по маркетингу, рекламе, разработке новых видов продукции + Управление процессами маркетинга, рекламы и разработки новых видов продукции Отчеты по маркетингу, рекламе + Заявки на обесп. сервис от маркетинга + Заявки на инж.тех сервис от маркетинга + Заявки на ТМЦ для маркетинга + Планы и решения + Планы для маркетинга + Результаты маркетинговых исследований База потенциальных клиентов + Маркетинг Сервис обесп. для маркетинга + Предложения поставщиков рекламы + Планы для рекламы + Реклама и трейдмаркетинг Клиенты и продукты + Лиды с сайта и сетей + Информация на сайте + Планы для разработки новых видов продукции + Отчеты по рекламе + Информация по продуктам конкурентов + Сервис обесп. для рекламы + Пожелания клиентов + Документация по новому продукту + Разработка новых видов продукции Планы для управления ассортиментом и ценами + Управление ассортиментом и ценами Отчеты по управлению ассортиментом + Инж.технический сервис для маркетинга, рекламы + Инж.технический сервис для ассорт. + Сервис обесп. для упр. ассорт + Сервис по обесп. для маркетинга + Сервис обесп. для разработки + Отчеты по разработке новых видов продукции + Инж.технический сервис для разработки + Информация о продуктах и сервисах Инж.технический сервис для маркетинга + Отчеты по маркетингу + Сегменты для рекламы+ Инж.технический сервис для рекламы + Спрос + Информация по продажам + © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. Ассортимент и цены + 107 Рис. 68. Диаграмма процесса «Маркетинг, реклама и разработка новых видов продукции». © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 108 8.5. Модель сквозного бизнес-процесса С точки зрения повышения эффективности бизнеса важно уметь создавать модели сквозных бизнес-процессов. Но сквозной процесс масштаба компании невозможно сразу описать в формате Work Flow – модель получится слишком сложной (может включать несколько сот и даже тысяч операций). Поэтому в данном случае я покажу возможный способ построения архитектуры сквозного процесса масштаба компании в нотации IDEF0. В качестве примера взят процесс «Разработка нового изделия: от идеи до постановки на производство» и создана его модель в Business Studio. Обращаю внимание, что у меня не было цели создать «идеальный» процесс с претензией на «лучшую практику». Цель создания данной модели – показать возможности методологии моделирования архитектуры сквозных бизнес-процессов масштаба компании в Business Studio в нотации IDEF0. На рис. 69 представлена контекстная модель этого процесса. Видно, что стрелки приходят «ниоткуда» и уходят в «никуда». Понятно, что у сквозного процесса есть внутренние поставщики и потребители (процессы). Но на контекстной диаграмме Business Studio, увы, нельзя показать междиаграммные ссылки на другие процессы модели. С этим придется смириться. С другой стороны, в данном случае важно разработать именно модель сквозного процесса, а не всей компании. В остальном, при построении модели учитывались все требования Методологии, рассмотренные в этой книге выше. Напомню, что сквозной процесс строится из кусков – функциональных процессов подразделений разного уровня. Но на модели А0 можно использовать элементы, которых нет в функциональной модели (реестрах функциональных процессов подразделений). Почему так? Дело в том, что видение сквозного процесса масштаба компании, его структуры являются предметом обсуждения и согласования топ-менеджеров, например, в рамках проведения Процессного комитета (создание которого рекомендует BPM CBOK). Другими словами, группировка процессных категорий на диаграмме А0 сквозного процесса (см. рис. 69) может отличатся от существующих структурных подразделений компании. Это две большие разницы. Рассмотрим диаграмму процесса «Разработка нового продукта» (рис. 70). Видно, что рассматриваемый сквозной процесс является весьма масштабным. Он состоит из блоков (процессных категорий), которые сами по себе являются сложными. Очевидно, что процесс такого уровня сложности невозможно представить в виде цепочки операций (Work Flow). Более того, если мы декомпозируем, например, «Выполнение НИОКР», то, скорее всего, на диаграмме увидим процессы, которые тоже нерационально представлять в виде диаграмм Work Flow в силу высокого уровня сложности. Очевидно, что сквозной процесс такого масштаба нуждается в постоянном управлении. Поэтому наличие на схеме блока «Управление разработкой новых и изменением текущих продуктов» представляется вполне оправданным. © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 109 Стратегия компании + Клиенты Пожелания клиентов + Новый продукт, поставленный на производство + Результаты маркетинговых исследований + Результаты анализа рекламаций + Разработка нового продукта Отчеты по разработке новых продуктов + Новые идеи от сотрудников + Сотрудники Сырье и материалы + Потребность в ресурсах + 0 Ресурсы для разработки нового продукта + Рис. 69. Диаграмма процесса «Разработка нового продукта». Контекст. © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 110 Стратегия компании + Отчеты по разработке нового продукта + Управление разработкой новых и изменением текущих продуктов Потребность в ресурсах + Отчеты по разработке новых продуктов + Планы по разработке нового продукта + План по разработке требований + Пожелания клиентов + Результаты анализа рекламаций + Результаты маркетинговых исследований + Новые идеи от сотрудников + Разработка требований к новому продукту Решение по запуску в серию + ТЗ на новый продукт + План по НИОКР + Отчеты по разработке требований + Выполнение НИОКР Отчеты по НИОРК + Изменения требований после НИОКР + Сырье и материалы + КД на новый продукт + План по разработке технологии производства + Разработка технологии производства нового продукта Отчеты по разработке технологии + Изменение требований по технологии + План по производству опытных партий + Технология производства + Подготовка и производство пробных партий нового продукта Отчеты по производству пробных партий + Результаты тестирования опытной партии + План по запуску нового продукта в производство + Запуск нового продукта в серийное производство Новый продукт, поставленный на производство + Отчеты по запуску продукта в серию + Ресурсы для разработки нового продукта + © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 111 Рис. 70. Диаграмма процесса «Разработка нового продукта». © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 112 На рис. 70 некоторые процессы показаны розовым цветом. Это сделано для иллюстрации, чтобы обратить ваше внимание на тот факт, что эти процессы (полностью или частично) выполняются не только в рамках рассматриваемого сквозного процесса. Пример. Внутри блока «Разработка технологии производства нового продукта» находятся следующие подпроцессы: • Управление разработкой технологии производства. • Разработка НТД по продукту. • Тестирование новых видов сырья и упаковки. • Разработка нормативов по новому продукту. Например, «Тестирование новых видов сырья и упаковки» может проводиться не в рамках создания нового продукта, а по ходу выполнения рутинной функциональной деятельности в случае необходимости смены поставщика сырья по каким-то причинам. Продукт останется тем же, но сырье будет от другого поставщика. С точки зрения технолога, в любом случае, надо тестировать, «пойдет» ли новое сырье или нет. На рис. 71 показана диаграмма процесса «Разработка требований к новому продукту». Семь процессов, представленные на диаграмме, могут работать одновременно, с разными задачами. Видно, что возможны возвраты и переделки (например, ТЭО 14, ТЗ 15 или принятия решений). Если рассматривать процессы, представленные на схеме рис. 69, на следующем уровне в виде Work Flow моделей, то для каждой такой модели возможны различные условия: • старта в части запуска предыдущими процессами; • завершения. На рис. 72 цветом показаны различные сценарии последовательного запуска процессов. На диаграмме в нотации IDEF0 нельзя показать поток работ. Поэтому эти цветные линии носят вспомогательный, поясняющий характер. Для иллюстрации можно было бы представить 7 схем формата Work Flow на одном листе и попытаться соединить их линиями – связями предшествования. Но проблема в том, что это сделать не всегда возможно. Очевидно, что сценариев выполнения сквозного процесса в части блока «Разработка требований к новому продукту» может быть множество. Но для примера я показал только три возможных. Желтый сценарий – «идеальный», когда все делается с первого раза и результат получается удачный. Оранжевый сценарий – когда нужна консультация с клиентом с последующей повторной оценкой идей, а также повторное выполнение разработки требований и принятия решений по результатам выпуска опытных партий продукта. Третий, розовый сценарий запускается при получении рекламаций, анализ которых может потребовать радикальных мер, приводящих к созданию, по сути, нового продукта и т.д. 14 ТЭО – технико-экономическое обоснование. 15 ТЗ – техническое задание. © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 113 План по разработке требований + Отчеты по процессам разработки требований + Управление разработкой требований к новому продукту Отчеты по разработке требований + Планы по процессам разработки требований + Планы по поиску + Результаты маркетинговых исследований + Поиск идей по новым продуктам Планы по оценке и отбору + Идеи + Отчеты по поиску идей + Пожелания клиентов + Новые идеи от сотрудников + Оценка и отбор идей по новым продуктам Отчеты по оценке и отбору + Планы по консультациям с клиентами + Отобранные идеи + Проведение консультаций с постоянными клиентами по новому продукту Планы по анализу ТЭО + Отчеты по консультациям с клиентами + Решения клиентов + Анализ возможности и необходимости создания нового продукта Планы по анализу внесения изменений + ТЭО по новому продукту + Отчеты по анализу ТЭО + Результаты анализа рекламаций + Решения по изменениям продукта + Анализ необходимости внесения изменений в существующий продукт Инф. для Отчеты по анализу внесения изменений + изменения + Планы по разработке требований + Разработка ТЗ на новый продукт Планы по принятию решений по новому продукту + ТЗ на новый продукт + Отчеты по разработке ТЗ + Принятие решения по новому продукту Изменения требований после НИОКР + Изменение требований по технологии + Результаты тестирования опытной партии + Отчеты по принятию решений + Ресурсы для разработки нового продукта + © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. Решение по запуску в серию + 114 Рис. 71. Диаграмма процесса «Разработка требований к новому продукту». © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 115 План по разработке требований + Отчеты по процессам разработки требований + Управление разработкой требований к новому продукту Отчеты по разработке требований + Планы по процессам разработки требований + Планы по поиску + Результаты маркетинговых исследований + Поиск идей по новым продуктам Планы по оценке и отбору + Идеи + Отчеты по поиску идей + Пожелания клиентов + Новые идеи от сотрудников + Оценка и отбор идей по новым продуктам Отчеты по оценке и отбору + Планы по консультациям с клиентами + Отобранные идеи + Проведение консультаций с постоянными клиентами по новому продукту Планы по анализу ТЭО + Отчеты по консультациям с клиентами + Решения клиентов + Анализ возможности и необходимости создания нового продукта Планы по анализу внесения изменений + ТЭО по новому продукту + Отчеты по анализу ТЭО + Результаты анализа рекламаций + Решения по изменениям продукта + Анализ необходимости внесения изменений в существующий продукт Инф. для Отчеты по анализу внесения изменений + изменения + Планы по разработке требований + Разработка ТЗ на новый продукт Планы по принятию решений по новому продукту + ТЗ на новый продукт + Отчеты по разработке ТЗ + Принятие решения по новому продукту Изменения требований после НИОКР + Изменение требований по технологии + Результаты тестирования опытной партии + Отчеты по принятию решений + Ресурсы для разработки нового продукта + © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. Решение по запуску в серию + 116 Рис. 72. Диаграмма процесса «Разработка требований к новому продукту». Сценарии. © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 117 Зачем нужна информация о том, какие процессы в рамках какого сценария должны запускаться? Ответ может быть следующий: • для понимания сквозного процесса и возможности его оптимизации; • для определения требований в рамках регламентации сквозного процесса; • для автоматизации сквозного процесса в BPMS системе – нужна архитектура процессов и понимание того, при каких условиях и с какими данными эти процессы будут последовательно запускаться в работу. Часто бывает, что при построении модели выхватывают какой-то один сценарий или микс 2-3 сценариев. При этом забывают о том, что возможны и часто случаются другие сценарии. Попытка регламентировать, а уж тем более автоматизировать такой «дырявый» сценарий приведет к тому, что постоянно будет требоваться ручное управление. При этом я не хочу сказать, что для начала автоматизации нужно знать всё. Нет. Можно начинать автоматизировать процесс по частям. При этом понимание архитектуры сквозного процесса в целом поможет существенно сократить время на последующие переделки. Для анализа некоторых возможных сценариев выполнения сквозного процесса можно построить соответствующую матрицу – см. пример ниже. Таблица 6. Сценарии выполнения сквозного процесса. Пример. № Наименование процесса 1 1.1. 1.2. 1.3. 1.4. 2 2.1. 2.2. 2.3. 2.4. 2.5. 2.6. 2.7. 2.8. 3 3.1. 3.2. 3.3. 3.4. 3.5. 3.6. 4 4.1. 4.2. 4.3. 4.4. 5 5.1. 5.2. 5.3. 5.4. 5.5. 5.6. 6 6.1. 6.2. Управление разработкой новых и изменением текущих продуктов Планирование разработки новых видов продукции Управление проектом разработки нового вида продукции Анализ инвестиционной привлекательности новых видов продукции Формирование отчетов по разработке новых видов продукции Разработка требований к новому продукту Управление разработкой требований к новому продукту Поиск идей по новым продуктам Оценка и отбор идей по новым продуктам Проведение консультаций с постоянными клиентами по новому продукту Анализ возможности и необходимости создания нового продукта Анализ необходимости внесения изменений в существующий продукт Разработка ТЗ на новый продукт Принятие решения по новому продукту Выполнение НИОКР Управление процессами НИОКР Анализ инновационных технологи и продуктов конкурентов Разработка/изменение дизайна продукта Выполнение научно-исследовательских работ Выполнение опытно-конструкторских работ Проведение верификации на компьютерной модели Разработка технологии производства нового продукта Управление разработкой технологии производства Разработка НТД по продукту Тестирование новых видов сырья и упаковки Разработка нормативов по новому продукту Подготовка и производство пробных партий нового продукта Управление подготовкой и производство пробных партий Подготовка оборудования Подготовка остатки Закупка сырья для пробных партий Изготовление пробной партии Тестирование пробной партии Запуск нового продукта в серийное производство Управление запуском серийного производства нового продукта Заключение договоров с поставщиками Сценарий А Сценарий Б Сценарий В + + + + + + + + - + + + + + + + + + + + + + + + + + + + + + - + + + + + + + - + + + + + + + + + + - + + + + + + + + + + + - + - + + - © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 118 6.3. 6.4. 6.5. 6.6. 6.7. 6.8. 6.9. 6.10 Закупка, монтаж и пуско-наладка оборудования Модернизация оборудования Сертификация продукта Внесение изменений в НТД Внесение изменений в НМД Определение цены на новый продукт Обучение производственного персонала Обучение сбытового персонала + + + + + + + + + + + + + + + - Некоторые процессы в этой таблице требуют декомпозиции еще на один уровень, прежде чем их можно будет описать в формате Work Flow (например, в нотации BPMN). Далее, если все процессы будут описаны в формате Work Flow, можно будет для каждого процесса рассчитать показатели выполнения одного экземпляра: • минимальное, нормативное, максимальное время выполнения; • затраты на выполнение. Затем, с учетом среднего количества запусков каждого процесса (возможны итерационные повторения), можно рассчитать средние показатели конкретного сценария сквозного процесса: • общее время выполнения; • совокупные затраты. Результаты анализа можно использовать для анализа эффективности производства нового продукта. Например, при заданном размере планируемой партии может оказаться, что затраты на выполнение соответствующего сценария сквозного процесса будут больше, чем маржа от производства этой партии под заказ клиента. В этом случае нужно будет принимать решение о целесообразности разработки и производства этого нового продукта. Если не брать в расчет стоимость всех процессов сценария, а только учесть стоимость сырья и материалов и разнести накладные (как это может сделать плановоэкономический отдел), то картина может оказаться совершенно другой. Также результаты анализа можно использовать для определения целей и показателей оптимизации процессов, входящих в сценарий с точки зрения сокращения времени и затрат. Можно будет выявить процессы, которые являются узким местом как по времени, так и по затратам. Очевидно, что общие показатели для «сквозного процесса в целом» (а не отдельного типового сценария) будут, в значительной мере, «средней температурой по больнице». Выбор и расчет показателей для сквозного процесса такого масштаба является весьма сложной задачей. Резюме. Если цель проекта – повышение эффективности сквозного процесса, то можно и нужно сразу браться за его описание и анализ, не пытаясь создать полную, комплексную архитектуру процессов в Business Studio. © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 119 9. Интеграция моделей процессов на разных уровнях В данном разделе рассматриваются практические вопросы интеграции моделей в общую архитектуру бизнес-процессов компании при использовании среды Business Studio. 9.1. Интеграция моделей в нотации IDEF0 и нотации BPMN Рассмотрим схемы, представленные на рис. 73. Слева показан фрагмент схемы процесса в нотации IDEF0. На нем представлено два подпроцесса: «Подпроцесс А» и «Подпроцесс Б». На диаграмме в нотации IDEF0 показаны входящие и исходящие стрелки для каждого блока. Напомню, что по стрелкам перемещаются объекты деятельности – документы, информация, материальные ресурсы. При декомпозиции подпроцессов с использованием нотации BPMN, необходимо: • определить все объекты, движущиеся по стрелкам на диаграмме в нотации IDEF0, которые являются входящими для подпроцессов; • определить все объекты, движущиеся по стрелкам на диаграмме в нотации IDEF0, которые являются исходящими для подпроцессов; • показать эти объекты (документы и информацию) на схемах подпроцессов. Далее необходимо определить процессы-поставщики и процессы-потребители этих документов и показать их на схеме подпроцессов в виде свернутых пулов. Затем связать свернутые пулы стрелками с соответствующими операциями на схеме и показать, какие именно документы передаются в подпроцесс из других процессов и, наоборот, из подпроцесса в другие подпроцессы. На рис. 74 показано, как может выглядеть, например, схема Подпроцесса Б по ходу выполнения такой работы. Обратите внимание, что на рис. 74 из свернутого пула «Подпроцесс А» передается Документ в операцию № 4 Подпроцесса Б. Именно этот Документ перемещается по стрелке «Поток И» на диаграмме вышестоящего уровня, представленной в нотации IDEF0. Необходимо сделать следующие замечания относительно использования стрелок типа Message Flow («Поток сообщений») на диаграммах Business Studio. На рис. 75 показан пример использования, когда Процесс Б передает в Процесс А «Данные для расчета». Использована стрелка типа Message Flow, к которой пунктиром (связь типа Association) присоединен объект из справочника Business Studio «Объекты деятельности». © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 120 Роль А Подпроцесс А ПОТОК Ж 1 3 Старт Стоп УПРАВЛЕНИЕ ПОТОК Д УПРАВЛЕНИЕ Б Роль Б УПРАВЛЕНИЕ А 2 ПОТОК Б2 Подпроцесс А Продпроцесс Б ПОТОК Г ПОТОК А2 Продпроцесс Б ПОТОК Б1 4 5 Старт Роль В ПОТОК А ПОТОК Б ПОТОК И Роль Б ПОТОК А1 Рис. 73. Интеграция моделей в нотации IDEF0 и BPMN. Часть 1. © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 6 Стоп 121 Процесс ??? Процесс ??? Подпроцесс А Продпроцесс Б Роль Б Документ 4 5 Роль В Старт 6 Стоп Процесс ??? Рис. 74. Интеграция моделей в нотации IDEF0 и BPMN. Часть 2. Строго говоря, если следовать нотации BPMN, то у операции «Собрать данные» нужно было бы указать маркер получения сообщения. Это означало бы, что Процесс Б отправляет, а операция «Собрать данные» получает сообщение, которое управляет ходом процесса. Но в данном контексте, конкретно в системе Business Studio такая картинка интерпретируется просто: выход Процесса Б является входом для операции «Собрать данные» Процесса А, не более. То есть никакое управляющее сообщение не передается. Другими словами, операция «Собрать данные» не ждет получения какого-то сообщения. Просто показано, что один процесс является поставщиком другого по входам/выходам, и всё. Очевидно, что в данном случаем мы наблюдаем нарушение семантики BPMN. Зато при использовании такого решения все входы/выходы и информация об их поставщиках/потребителях будет выгружаться в регламенты выполнения бизнеспроцессов, автоматически сформированные в Business Studio. © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 122 Рис. 75. Использование стрелки типа Message Flow («Поток сообщений») для отображения информационных потоков между процессами. На рис. 76, напротив, показана ситуация, когда стрелка типа Message Flow используется для отправки сообщения под названием «Запрос отправлен» в другой процесс в соответствии с семантикой BPMN. Это означает, что Процесс Y должен ждать получения этого сообщения для продолжения своей штатной работы. Для того, чтобы не путать две разные возможности использования стрелок типа Message Flow в Business Studio, на схеме рис. 76 показано промежуточное событие отправки сообщения. Таким образом, с учетом использования именно Business Studio можно договориться использовать указанные способы моделирования для отображения разных смысловых ситуаций: простое взаимодействие по принципу вход/выход и отправка/получение управляющих процессами сообщений. © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 123 Процесс Х Процесс Y Подпроцесс В Роль А Документ Б A Роль Б Старт В Г Функция Запрос отправлен Д Стоп Документ Процесс Z Рис. 76. Использование стрелки типа Message Flow для отображения отправки управляющих сообщений. Говоря об отображении межпроцессного взаимодействия путем отправки/получения управляющих сообщений, следует обратить внимание еще на одну проблему, представленную на рис. 77. При моделировании процесса бизнес-аналитик отправил сообщение из процесса нижнего уровня в процесс, который на 2-3 уровня выше в архитектуры процессов компании. Чем это плохо? Тем, что небольшой операционный процесс не может «запускать» процесс верхнего уровня, в который сам входит. Кроме того, этот процесс («Закупка») описан в нотации IDEF0. ЗАКУПКА Роль Б Роль А Занесение потенциальных поставщиков в базу Документ 1 2 Документ Б 3 4 Рис. 77. Отправка сообщения «На деревню дедушке». © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 124 Можно сформулировать следующе правило: При моделировании в Business Studio, процесс в нотации BPMN может отправлять/получать сообщения только в процессы/из процессов, описанных так же в нотации BPMN. Далее рассмотрим аспекты интеграции моделей процессов, разработанных в нотации BPMN. 9.2. Интеграция моделей в нотации BPMN между собой На рис. 78 показана диаграмма процесса «Занесение потенциальных поставщиков в базу». Операции № 2 декомпозирована на следующий уровень (тоже в нотации BPMN). На схеме процесса «Занесение потенциальных поставщиков в базу» поток работы идет последовательно, линейно. Но на нижнем уровне показано, что операция 2 запускается путем получения сообщения от операции 1. В свою очередь операция 2 запускает операцию 3. Это некорректно. Совершенно не нужно показывать события отправки/получения сообщений между процессами, которые запускаются последовательно в рамках процесса вышестоящего уровня. ЗАКУПКА Занесение потенциальных поставщиков в базу Роль А Документ 1 2 Роль Б Документ Б 3 4 1 Роль А 2 А Б С 3 Рис. 78. Некорректное использование сообщений. © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 125 Рассмотрим теперь вопрос взаимодействия между процессами, описанными в нотации BPMN в Business Studio, с точки зрения информационных потоков более подробно. На рис. 79 показана диаграмма процесса, на которой представлено движение документов. Так, например, Документ выходит из операции «Подготовить проект документа» и поступает в операцию «Внести корректировки и согласовать с инициатором». Такое представление на модели процесса кажется очевидным. Но так ли это на самом деле? В реальности документ переходит от одной операции процесса к другой посредством: • отправки по электронной почте; • передачи через систему электронного документооборота или BPMS; • передачи через файл-сервер компании; • передачи через базу данных информационной системы (например, EPR); • физически руками исполнителей. Руководитель Контролер Инициатор Пример. Вариант I Нужно согласовать документ Подготовить проект документа С замечаниями Получить уведомление о согласовании Согласовать изменения Документ согласован Документ Проект Документ Внести корректировки и согласовать с инициатором Согласован Проект Документ Документ С замечаниями Документ Согласовать документ Рис. 79. Пример движения документов внутри процесса. Вариант I. Последний вариант встречается в современных компаниях существенно реже. В любом случае, документ попадает из одной операции в другую не мгновенно, а через некоторое, условно говоря, хранилище данных и документов. Причем хотел бы обратить внимание, что одна операция (процесс) может «положить» данный документ в хранилище, а другая операция (процесс) – «взять» его в нужное время. Таким образом, формат представления движения документов (информации) на модели (рис. 79), строго говоря, не соответствует реальности. Но с точки зрения прослеживаемости движения документов между процессами (вход/выход) и формирования регламентов в Business Studio, такой подход вполне можно использовать (а детали физической реализации обмена изложить в описании операции и вывести в отчет). На рис.80 показан альтернативный вариант представления модели движения документов на схеме процесса. Показано, что документы сначала попадают в хранилища © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 126 данных (в Business Studio – это базы данных из справочника «Объекты деятельности»), а затем из этих хранилищ передаются в соответствующие операции процессов. Пример. Вариант II Контролер Инициатор С замечаниями Нужно согласовать документ С замечаниями Подготовить проект документа СЭД Документ С замечаниями Документ Документ согласован Согласован Документ Проект Внести корректировки и согласовать с инициатором Документ Документ Проект СЭД Проект Документ Документ Руководитель Получить уведомление о согласовании Документ Проект СЭД Согласовать изменения С замечаниями Документ СЭД Документ Согласовать документ СЭД Согласован Документ Рис. 80. Пример движения документов внутри процесса. Вариант II. Такой формат представления является более адекватным реальности, но имеет два недостатка: • диаграмма процесса существенно усложняется; • входы/выходы процессов в регламентах Business Studio будут «оборваны», т.е. нельзя будет показать из какого процесса «входит» документ, и в какой процесс «уходит». С точки зрения создания архитектуры процессов в Business Studio и задачи формирования регламентов формат диаграммы с базами данных (рис. 80) неудобен, хоть и более правилен теоретически. В реальном проекте вы в праве выбирать решение, которое считаете наиболее удобным практически – в зависимости от ваших задач. Рассмотрим еще один пример, связанный с моделированием движения документов. На рис. 81 показана диаграмма процесса, на которой две операции «Подготовить отчет» и «Выполнить анализ данных» обмениваются Документом, при этом обе эти операции декомпозированы на следующий уровень. На рис. 81 справа показано, как выглядит обмен документами между этими подпроцессами. В Business Studio, как я уже писал выше, приходится использовать свернутые пулы и стрелки типа Message Flow для моделирования такой ситуации. Если моделировать движение документов (информации) через базы данных, то не получится отследить поставщиков/потребителей в регламентах, как было сказано выше. © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 127 Выполнить анализ данных Подготовить отчет Процесс Б Исполнитель Данные для отчета Собрать данные Подготовить отчет Документ Обработать данные Выполнить расчеты Заполнить шаблон отчета Нужно подготовить отчет Проект отчета подготовлен Ежедневно, 9-00 Подготовить отчет А2.3 Выполнить анализ данных Документ Выполнить анализ данных Анализ выполнен Документ Процесс С Руководитель Руководитель Исполнитель Процесс А Документ Выполнить анализ данных А Выполнить анализ данных Б Нужно выполнить анализ данных Рис. 81. Пример движения документов. Декомпозиция. © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. Принять решения по КД Анализ данных выполнен 128 Теперь рассмотрим, как быть с событиями при декомпозиции – см. рис. 82. Операция «Подготовить отчет» декомпозирована на нижний уровень. На диаграмме «Процесс А» у этой операции нет никаких стартовых и завершающих событий. Процесс Б Данные для отчета Подготовить отчет Собрать данные Ежедневно, 9-00 Руководитель Исполнитель Процесс А Выполнить анализ данных Документ Анализ выполнен Документ Процесс С Выполнить анализ данных Исполнитель Подготовить отчет Документ Обработать данные Выполнить расчеты Заполнить шаблон отчета Нужно подготовить отчет Проект отчета подготовлен Рис. 82. Декомпозиция. События. Процесс в нотации BPMN должен начинаться с одного или более событий. Поэтому на диаграмме процесса «Подготовить отчет» использовано стартовое событие неопределенного типа, названное «Нужно подготовить отчет». Так же создано завершающее процесс событие – «Проект отчета подготовлен». Рассмотрим еще одну ситуацию, представленную на рис. 83. После операции «Подготовить отчет» показан шлюз типа «Исключающее ИЛИ», который маршрутизирует процесс по двум возможным веткам. Но события так же отсутствуют, как в предыдущем примере. © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 129 Процесс Б Данные для отчета Да Собрать данные Подготовить отчет Нет Нужны дополнительные данные? Ежедневно, 9-00 Руководитель Исполнитель Процесс А Выполнить анализ данных Документ Анализ выполнен Документ Процесс С Выполнить анализ данных Исполнитель Подготовить отчет Документ Обработать данные Выполнить расчеты Нужны дополнительные данные Заполнить шаблон отчета Нужно подготовить отчет Проект отчета подготовлен Рис. 83. Декомпозиция. Шлюз и события. При декомпозиции на схеме нижнего уровня показан шлюз «ИЛИ» и два альтернативных события, завершающие процесс: «Проект отчета подготовлен» (ветка «Нет» на диаграмме вышестоящего уровня) и «Нужны дополнительные данные» (ветка «Да» на диаграмме вышестоящего уровня). В результате можно увязать диаграммы между собой с точки зрения шлюзов и событий. Отмечу, что правила интеграции моделей должны быть прописаны в документе «Соглашение по моделированию» компании. Каждый участник процесса моделирования должен понимать эти правила. Процессный офис осуществляет методический контроль схем бизнес-процессов и их интеграции в общую модель компании. © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 130 10. Заключение В книге представлена Методология построения архитектуры бизнес-процессов компании с использованием нотации IDEF0 и программного продукта Business Studio. По итогам рассмотрения можно сделать следующие выводы: 1. построение и, особенно, поддержание в актуальном состоянии инженерной архитектурной модели бизнеса в текущей версии среды Business Studio 16 является достаточно трудоёмким, но вполне возможным; 2. построение и использование эскизной модели бизнеса вполне допустимо, но только при наличии четкой методологии ее создания; 3. классическая методология IDEF0 является неудобной для создания комплексной, многоуровневой модели бизнеса; ситуация не улучшается даже в случае изменений методологии в сторону большей строгости путем введения ряда ограничений (предложены мной в данной книге); тем не менее: 4. в случае создания в Business Studio архитектуры бизнес-процессов компании в нотации IDFE0 рекомендуется применять представленные в книге методики и примеры, так это позволит сделать вашу модель качественной и пригодной для дальнейшего практического использования; 5. возможно, в будущем на рынке появятся программные продукты, позволяющие создавать инженерную архитектурную модель бизнес-процессов компании быстро и эффективно, одновременно решая задачу комплексной автоматизации бизнеспроцессов. Желаю вам удачи в создании и практическом использовании архитектуры бизнеспроцессов вашей компании! 16 На начало 2019 года – это версия 4.2. © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 131 11. Список рекомендуемой литературы 1. Репин В.В. Бизнес-процессы. Моделирование, внедрение, управление. М.: Манн, Иванов и Фербер, 2014. 2. Репин В.В. Бизнес по правилам: регламенты должны работать. М.: ИНФРА-М, 2018. 3. Репин В.В. «Моделирование бизнес-процессов в нотации BPMN. Пособие для начинающих. Часть I». М.: Перо, 2019 г. ISBN 9785001222699 84 стр. 4. Федоров И.Г. «Нотация BPMN 2.0. Стандарт ISO/IEC 19510:2013 для создания исполняемых моделей бизнес-процессов: учебник». Серия: Серия «К 110-летию РЭУ им. Г.В. Плеханова». Изд-во РЭУ им. Г. В. Плеханова, 2018 г. ISBN 978-57307-1183-9. 5. В.Е.Пятецкий, Л.Н. Калошина, М.А. Поддубный. «Моделирование и регламентация бизнес-процессов с использованием Business Studio 4». Практикум. МИСиС, Москва, 2017 г. 6. РД IEEF0-2000 Методология функционального моделирования IDEF0. 7. Дэвид Д. Марка и Клемент Мак Гоуэн. Предисловие Дугласа Т. Росса. «Методология структурного анализа и проектирования SADT Structured Analysis & Design Technique». 8. Стандарт ISO/IEC 19510 Information technology - Object Management Group Business Process Model and Notation (нотация BPMN). © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 132 Об авторе книги Владимир Репин, консультант по управлению, тренер, к.т.н., доцент, Генеральный директор ООО «Владимир Репин Менеджмент», член ABPMP Russian Chapter. Провел 365 семинаров и тренингов в 67 городах России и стран СНГ. Обучил 4529 человек, автор 6 книг по бизнеспроцессам. Область профессиональных интересов - внедрение процессного подхода к управлению, в том числе: • • • • • • • • • • построение системы управления бизнес-процессами компании; разработка архитектуры бизнес-процессов; комплексная поставка и настройка программного продукта Business Studio, проведение тренингов по системе; моделирование, анализ и оптимизация процессов; оптимизация и автоматизация бизнес-процессов на платформе Elma и др.; регламентация и стандартизация процессов; разработка целей и показателей для управления процессами; обучение руководителей и специалистов методам процессного управления; организация работы Процессного офиса; экспертно-методическое сопровождение проектов внедрения процессного управления (экспертиза моделей процессов и проектов регламентов, проведение скайп-консультаций и проч.) С автором книги можно связаться по e-mail: [email protected]. © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г. 133 © В.В. Репин, 2018-2022 г. Экземпляр слушателя тренинга по Business Studio для ОАО «Сладонеж», сентябрь 2022 г.
