Оценка зрелости системы управления бизнес-процессами компании
Оценка зрелости системы управления бизнес-процессами компании
В статье Владимира Репина представлена методика оценки зрелости системы управления бизнес-процессами: структура разделов, примеры критериев, формулы для расчета. По представленной методике проводилась оценка в нескольких компаниях. Статья может быть полезной для сравнительного анализа и разработки собственной методики оценки зрелости в области процессного управления.
Объекты и цели оценки зрелости
Каждый объект, способный к изменению, может проходить через несколько этапов или уровней зрелости. Так же их можно назвать этапами жизненного цикла. Для чего нам нужно определять конкретный этап или уровень? Например, мы принимаем первое решение относительно возможности использования этого объекта для достижения наших целей. Второе решение – что нужно и как именно сделать, чтобы зрелось объекта соответствовала нашим целям. Например, вы наблюдаете, как созревают яблоки. Если сорвать их незрелыми, то мы не получим ни пользы, ни удовольствия. Если дать им перезреть, то есть риск снижения вкусовых качеств и повреждения птицами и проч.
Для чего собственнику оценивать зрелость его компании? Цели могут быть разные. Например, чтобы убедиться в том, что:
• создана система регулярного менеджмента и ей можно передать функции оперативного управления (уход от ручного управления);
• компания готова для привлечения стратегического инвестора/выхода на биржу/к продаже;
• создана культура инноваций и развития, которая обеспечит устойчивый рост в ближайшие годы;
• прочее.
Применительно к бизнесу, объектами оценки зрелости могут выступать:
- компания в целом;
- система управления компанией в целом;
- различные подсистемы в рамках системы управления (например, подсистема управления персоналом);
- отдельные бизнес-процессы (причем, различного масштаба).
В статье речь пойдет об оценке зрелости СУБП – Системы управления бизнес-процессами компании. Я считаю, что это такая же подсистема управления организацией, как, например, система управления персоналом или финансами. Приведу определение. СУБП – это:
Совокупность методов, инструментов, ресурсов и внедренных бизнес-процессов, направленная на эффективное развитие Компании на основе управления каждым значимым бизнес-процессом в рамках его жизненного цикла.
Система управления персоналом помогает адекватно управлять персоналом, обеспечивая бизнес человеческими ресурсами. Система управления финансами – обеспечивает возможность ведения деятельности компании (ликвидность, наличие оборотного капитала). СУБП же дает возможность целенаправленно изменять, совершенствовать бизнес-процессы и поддерживать их текущую результативность и эффективность. Другими словами, СУБП – это системная практика работы с бизнес-процессами компании. Можно сказать, что СУБП – это подсистема, призванная развивать другие подсистемы управления.
Представим, что бизнес действует, но процессы никто и никогда специально не анализировал, не выстраивал. В этом случае можно утверждать, что СУБП в организации нет.
Может ли вообще существовать бизнес без целенаправленного управления деятельностью как совокупностью бизнес-процессов? Практика дает однозначный ответ — «Да». Причем такой бизнес часто бывает вполне успешным. Как это возможно? Вероятно, ответ надо искать в следующем – в уровне сложности продукта (услуги), в уровне сложности бизнеса, включая внешнюю среду организации (в широком смысле). Бизнес может быть успешным в силу внешних обстоятельств (отсутствие эффективных конкурентов) на определенном временном интервале. Кроме того, мало кто из собственников задумывается о системной работе с бизнес-процессами, если поставленные цели и так достигаются достаточно легко.
Я утверждаю, что Система управления бизнес-процессами нужна компании, которая:
a) достигла определенного уровня развития (этапа жизненного цикла);
b) находится в условиях конкуренции, требующей целенаправленного изменения бизнес-процессов для повышения их результативности и эффективности, сокращения сроков и повышения качества.
Короче говоря, если собственнику требуются стабильное качество, адекватные сроки выполнения и экономическая эффективность (снижение затрат), то ему нужна система работы с бизнес-процессами. Если собственник убежден, что использование СУБП целесообразно, то нужно ее создать и целенаправленно развивать.
Оценка зрелости СУБП может помочь понять текущий уровень развития практики работы с бизнес-процессами и наметить пути ее развития.
Далее в статье я буду говорить о методике оценки зрелости СУБП, как подсистемы общей системы управления организацией.
Хотел бы обратить внимание на следующий аспект. Использованная Методика не предполагает проведение оценки уровня зрелости каждого бизнес-процесса по отдельности. Уровень зрелости отдельного процесса – это результат приложения усилий руководства компании, владельца процесса (руководителя, ответственного за процесс) и, в определенной степени, — работы СУБП. Но оценка уровня зрелости всех процессов компании затруднена по нескольким причинам:
- процессов слишком много (несколько тысяч на операционном уровне);
- существует иерархия процессов;
- каждый бизнес-процесс обладает своей спецификой.
Рассмотрим простой пример. Оцениваемый процесс состоит из семи подпроцессов. Три из них оценены на максимальный балл, а четыре – на «0». Как оценить уровень зрелости процесса в целом? Можно ли считать зрелым процесс, у которого часть подпроцессов являются абсолютно незрелыми? Я считаю, что нет, нельзя. С какого уровня начинать оценку? Как агрегировать результаты оценки по иерархии процессов вверх до уровня категорий? Методика, дающая ответы на эти вопросы, была разработана мной (вместе с некоторыми коллегами) в рамках проекта на Челябинском трубопрокатном заводе (Группа ЧТПЗ), но оказалась слишком сложной.
Вернемся к аналогии. Можно оценивать каждого отдельного сотрудникам компании и потом делать какие-то усреднения и выводы, а можно оценивать зрелость системы управления персоналом. Это весьма разные вещи. Сотрудники приходят и уходят, а система остается. Бизнес-процессы развиваются от версии к версии. Поэтому я считают целесообразным оценивать зрелость именно СУБП, а не всех бизнес-процессов компании.
Существующие подходы к оценке зрелости
Известно множество подходов к оценки процессной зрелости, причем как отдельных процессов, так и процессной зрелости организации в целом. Например, модель PEMM Майкла Хаммера (см. статью – «Оценка уровня зрелости процесса по методике PEMM Майкла Хаммера») или ГОСТ Р ИСО/МЭК 15504 (см. статью – «Оценка уровня зрелости процесса по методике ГОСТ Р ИСО/МЭК 15504-2»).
Если наша цель – провести оценку в конкретной компании, а не абстрактно рассуждать о различных существующих подходах, то нам потребуется методика, включающая конкретные вопросы, на которые нужно ответить для получения результата. Однако, существующие «методы» оценки не дают ответ на вопрос, как именно должно быть измерено соответствие конкретному критерию. Возьмем, например, несколько вопросов из Госта 15504:
• «осуществление процесса регулируется для соответствия планам»;
• «определены цели измерения процесса на основании информационных потребностей процесса»;
• «собраны, проанализированы и доложены результаты измерений для мониторинга степени, до которой достигнуты количественные цели осуществления процесса»;
• «идентифицированы возможности улучшений, вытекающих из новых технологий и концепций процесса»;
• «реализация всех согласованных изменений управляется с целью обеспечить, что любое вмешательство в осуществление процесса понято и проведено» …
Очевидно, что представленные выше формулировки сложно назвать адекватными задаче. Если задавать такие вопросы обычным руководителям обычной компании, то тебя просто не поймут.
Критерии оценки должны быть достаточно просты и понятны. Вопросы должны давать возможность четкого ответа «Да» или «Нет», основанного не на субъективном мнении, а на фактах.
Один и с коллегами (Виталий Елиферов и др.) я проводил оценку как отдельных процессов, так и системы управления для различных организаций. Применяемые нами методы варьировались от простой анкеты оценки процесса, до комплексной оценки системы управления. Однако, степень субъективности оценки меня не всегда удовлетворяла.
Например, если спросить любого руководителя, фиксирует ли он отклонения при выполнении процесса, то вряд ли кто-то осознанно скажет: «Нет». То есть ответ всегда будет «Да». Вроде бы, налицо элемент управления бизнес-процессом. Но это не так. Если сам процесс ни разу не был представлен в виде схемы? Если никто не знает, что такое правильный, корректный ход процесса, а что такое отклонение?
Если не определено, какое отклонение считать значимым? Как в этом случае нужно оценивать ответ руководителя? И так во всем… Нужен метод, который снижает уровень субъективности до приемлемого и измеряет реальную практику работы с бизнес-процессами, а не то, что руководители считают или выдают за таковую.
Результаты оценки по такому методу должны давать возможность анализировать динамику развития СУБП компании, сравнивать состояние СУБП различных компаний и делать практические выводы. Поэтому в какой-то момент я решил разработать собственную Методику оценки зрелости СУБП, и она была создана.
Методика оценки зрелости СУБП
Оценка СУБП проводится по десяти направлениям, которые представлены в списке ниже. Почему именно они? Структуру СУБП компании можно рассматривать по-разному. За годы работы в области процессного управления я пришел именно к такой структуре и использую ее в своей практической работе (консалтинг по построению СУБП в компаниях):
- Архитектура бизнес-процессов.
- Управление бизнес-процессами по целям и показателям.
- Система стимулирования руководителей на улучшение бизнес-процессов по КПЭ.
- Практика описания и анализа бизнес-процессов.
- Практика оптимизации бизнес-процессов и внедрения изменений.
- Автоматизация бизнес-процессов (в BPMS).
- Стандартизация бизнес-процессов.
- Контроль и аудит бизнес-процессов.
- Корпоративная система обучения персонала методам процессного управления.
- Процессный офис.
С определенной точки зрения, некоторые из представленных выше аспектов могут рассматриваться как часть других подсистем управления, например, «Управление информационными технологиями» или «Внутренний аудит». Дело в том, что в определенных случаях сложно провести четкие, формальные границы между подсистемами управления. Так что оценка зрелости СУБП частично затрагивает оценку зрелости системы управления компанией в целом и, в некоторой степени, ряд других подсистем. Но я рассматриваю эти пересечения скорее как плюс, а не как минус структуры СУБП, ведь подсистемы работают в одной компании и должны быть тесно связаны между собой.
Для каждого из десяти разделов определен состав подразделов. Например, вот структура для подраздела «Архитектура бизнес-процессов» (Таблица 1):
Для чего нужны веса? Для полноты и широкого охвата необходимо рассмотреть различные аспекты СУБП, как системы. Некоторые из них являются более важными, другие – менее. Тем не менее, все они характеризуют состояние СУБП. Если взять какой-то один критерий (подраздел), то оценка будет неточной. Использование нескольких критериев дает возможность повысить точность оценки. Веса вводятся для того, чтобы менее значимые, но тоже важные критерии, не искажали общий результат оценки. Выбор весов проводится один раз, например, путем опроса экспертов на стадии разработки методики. В последующем веса уже не должны меняться.
Приведу пример метода оценки по подразделу «Реестр процессов» (Таблица 2). Этот критерий характеризует полноту процессной архитектуры компании. В случае, если процессы соответствующего уровня определены в архитектуре бизнес-процессов компании, то указанное в таблице значение включается в общую сумму по каждому типу и по каждому уровню. Рассчитывается суммарное значение и, затем, оценка по подразделу.
Категории и группы – это почти стандартные названия, используемые при построении архитектуры процессов компании (полный глоссарий в статье приводить не планируется).
Приведу еще пример подразделов для раздела «Стандартизация бизнес-процессов» — см. Таблицу 3.
Например, оценка по подразделу «Наличие ВНМД по стандартизации бизнес-процессов» осуществляется при помощи следующей Таблицы 4 (ВНДМ – внутренний нормативно-методический документ компании – регламент, положение, инструкция).
Стоит отметить, что в данном случае уже имеет место некоторая субъективность. Что значит «фрагментарный стандарт»? Для меня это понятно – в нем отсутствуют или плохо проработаны необходимые фазы управления жизненным циклом ВНМД компании. Например, не описаны требования по вводу ВНДМ в действие и т.д. Для проведения оценки по данному критерию необходимо использовать соответствующий чек-лист.
Еще пример. Оценка по подразделу «Качество ВНМД» осуществляется следующим образом:
Вообще, критерии для оценки, использованные в Методике, можно разделить на следующие группы:
- счетные критерии, например:
a. N процессов из M обладают каким-то свойством;
b. 25% < доля инструкций, формируемых автоматически ≤ 50%. - критерии, основанные на фактах, например:
a. «Работа с корректирующими и предупреждающими действиями не автоматизирована» (все на бумаге, в MS Word и MS Outlook). - критерии, измеряемые при помощи чек-листов, например:
a. контроль качества графической схемы процесса (с расчетом среднего количества ошибок на одну схему). - критерии, рассчитываемые как среднее значение субъективной оценки многими руководителями какого-то аспекта СУБП по простой шкале: низкая эффективность, средняя эффективность, высокая эффективность; очень высокая эффективность (практически в каждом разделе есть подраздел с субъективной оценкой руководителями).
Далее. Оценка по каждому разделу осуществляется по формуле:
Рассмотрим пример оценки по разделам и расчет общей оценки зрелости СУБП, представленный в Таблице 5.
Сумма баллов — 36.
Коэффициент неравномерности – 0,95.
Оценка зрелости СУБП – 34 балла.
Коэффициент неравномерности вводится для того, чтобы несколько занизить оценку в случае, если по каким-то разделам оценка высокая, а по другим — низкая. Например, практика описания процессов – 9, а практика внедрения изменения – 1. Так быть не должно. Какой смысл описывать процессы, если эта работа не сопровождается внедрением изменений? Коэффициент неравномерности можно сделать еще более жестким, например, используя размах вместо среднеквадратичного отклонения. Но это на усмотрение компании.
Общая оценка зрелости СУБП может составлять от 0 до 100 баллов. Предлагается использовать следующие уровни оценки СУБП компании (см. таблицу 6).
Пример результатов оценки зрелости СУБП
Результаты оценки зрелости СУБП целесообразно представлять визуально, например, при помощи следующих диаграмм. На рисунке 1 представлены результаты оценки в виде ползунковой диаграммы (шкалы) для вымышленной компании. С учетом коэффициента неравномерности, получено 13 баллов – уровень оценки СУБП компании «Очень низкий».
На рисунке 2 представлены диаграммы оценки процессной зрелости этой условной компании в N-ом году и план развития СУБП на N+1 год.
Для развития СУБП в N+1 году необходимо разработать план мероприятий как по каждому аспекту СУБП, так и по системе управления бизнес-процессами в целом. Мероприятия, включенные в план, получают определенные приоритеты. Определяется бюджет развития СУБП на следующий год.
Повторная оценка СУБП проводится через год по той же Методике. Сопоставление оценок позволяется сделать выводы о динамике развития СУБП компании.
Резюме
В статье представлена авторская Методика оценки зрелости Системы управления бизнес-процессами компании.
Основные принципы и критерии оценки, включенные в данную Методику, были применены автором при проведении аудита системы управления ГК «Сибпроект» и других компаний.
Далее методика была доработана в рамках проекта создания корпоративной системы оценки процессной зрелости Челябинского трубопрокатного завода (Группа ЧТПЗ). Частично Методика применялась при создании системы оценки организационной зрелости компании «Ярмарка».
Затем структура Методики была уточнена при проведении оценки зрелости СУБП компании «Пакер».
Законченный вид Методика приобрела в рамках проекта оценки зрелости СУБП «Иркутской нефтяной компании».
В настоящее время, по ходу практической работы, я вношу изменения и дополнения в Методику, в том числе в части форм чек-листов, состава и формулировок анкет и проч.
Методику можно применять для оценки текущего уровня зрелости системы управления бизнес-процессами компании (практики работы с процессами) и определения путей ее совершенствования.
В.В. Репин,
к.т.н., доцент, консультант по управлению, Генеральный директор ООО «Владимир Репин Менеджмент», Советник Директора АО «СО-ЕЭС».
Январь 2020 г.
Компетенции для BPM-проекта: структура, развитие, подтверждение
Компетенции для BPM-проекта: структура, развитие, подтверждение
Компетенции для BPM-проекта
В 2013 году компания Gartner предложила модель компетенций, которые необходимы для успешного выполнения BPM-проекта в компании (BPM – Business Process Management). Для внедрения процессного управления, согласно этой модели, проектной команде необходимы компетенции по трем направлениям: трансформационные, операционные и технические. Рассмотрим их подробнее (см. таблицу 1).
Трансформационные компетенции
Успех проекта оптимизации бизнес-процесса во многом зависит от… выбора этого процесса. Выбрав процесс, эффект от оптимизации которого минимален, мы никогда не окупим потраченные ресурсы. Но как сделать выбор? Почему конкретный процесс должен быть выбран? Как такой выбор повлияет на достижение стратегических целей? Опыт и чутьё полезны, но кроме них необходимы четкие критерии выбора и подходящая методика. Процесс – узкое место. Процесс – ключевой фактор для цифровой трансформации. Процесс многократно повторяется и может быть тиражирован в регионы, филиалы и т.п. «Умение готовить бизнес-обоснование и наличие видения» — первая необходимая компетенция для руководителя.
Вторая трансформационная компетенция – это управление проектами. Можно просто описывать процессы, а можно описывать в срок с конкретным результатом и внедрением изменений. Это вполне очевидно. Но, к сожалению, довольно часто BPM-проект начинается и идет полупартизанским методом, потому что «… у нас очень сложно оформить что-то как проект…».
Третья компетенция «Знание организационной структуры и корпоративной культуры» является одной из ключевых, на мой взгляд. Понятно, что знание орг. структуры – это не столько знание схемы, сколько реальных людей с их возможностями и связями. Без этих знаний и умений в подборе союзников для проекта и нейтрализации оппонентов, определения реальных возможностей и скорости изменений, BPM-проект вряд ли состоится.
Еще две трансформационные компетенции тесно связаны с третьей. Это – коммуникации и методы управления изменениями. Если вы сформулировали проблему и выявили ее причины, собрали совещание, обсудили проблему, протоколом распределили задачи исполнителям, то можно сказать, что уровень коммуникаций и управления изменениями в компании… низкий. Дело в том, что наличие протокола и закрепления задач по отдельным исполнителям совершенно не означает, что:
• протокол содержит обдуманный план действий;
• задачи будут выполнены и проконтролированы (зависит от культуры исполнения);
• исполнители будут работать как единая команда;
• другие сотрудники компании будут уведомлены о планируемых изменениях;
• четко сформулированы и практически использованы критерии оценки результативности изменений.
Для быстрых и успешных изменений бизнес-процессов нужны правильная организация и соответствующая корпоративная культура.
Операционные компетенции
Некоторые сотрудники компании в начале освоения методов процессного управления путают входы процесса с инициирующими событиями, выходы – с бизнес-результатом и показателями и т.п. Поэтому «Выявление бизнес-процессов» является важнейшим умением для сотрудников, включенных в рабочую группу BPM-проекта.
Вторая компетенция – это «Моделирование, анализ и проектирование бизнес-процессов». Одна довольная обширна. Нужно уметь моделировать процессы «как есть» в современных нотациях (например, eEPC или BPMN) с использованием различных программных продуктов (например, BizAgi или Camunda Modeler, ARIS, Business Studio и проч.). Нужно владеть методами анализа процессов, например: анализ ограничений, времени выполнения, потерь. Нужно знать принципы и методы оптимизации процессов, например: вертикальное и горизонтальное сжатие процесса, устранение узких мест и др. Рассматриваемая компетенция является ключевой.
«Регулирование и организация процессной работы» — эти умения необходимы для эффективной организации команды проекта. Например, нужно уметь организовывать и проводить моделирующие сессии, выполнять анализ процесса, готовить и проводить презентации предлагаемых изменений бизнес-заказчику и т.п.
«Управление эффективностью процессов» — умение, необходимое для измерения процессов. Без изменений нет улучшений. Проектная команда должна уметь измерять показатели процесса в текущем состоянии («как есть») и процесса после внедрения изменений («как должно быть»). Для оперативного управления процессом так же нужны показатели, для разработки и использования которых необходимы соответствующие знания и опыт.
Последняя компетенция в группе операционных компетенций – «Подбор инструментов, поддерживающих методологию BPM». Выбор адекватного инструмента важен для успешного выполнения проекта. Например, нецелесообразно долго выбирать и настраивать сложный инструмент, если проект короткий, а решение по масштабному внедрению в компании не принято. Есть риск, что «весь пар проектной команды уйдет в свисток». Можно полгода обосновывать покупку системы ARIS, а можно взять бесплатный Camunda Modeler и быстро решить поставленную задачу, показав хороший результат.
К сожалению, некоторые руководители считают, что покупка системы для описания процессов сразу даст результат – улучшения. Это не так. Описание процесса в каком-либо формате без анализа, расчетов и обоснования изменений не дает существенного результата с точки зрения повышения производительности, эффективности и времени. Давайте на примере. Принципиальная схема радиоэлектронного устройства содержит набор элементов. Наивно было бы думать, что путем их визуального расположения на схеме без расчета параметров работы мы получим нужный результат на выходе. Но для схемы бизнес-процесса это делают сплошь и рядом, выпуская регламенты на основе схем без каких-либо расчетов производительности и времени выполнения процессов, без учета взаимодействия с другими процессами и загрузки ресурсов в других процессах! Еще одна аналогия – это разработка печатной платы. Там детали нужно разместить в соответствии с принципиальной схемой, но с учетом их размеров, теплового режима работы и проч. Схема процесса на бумаге отличается от реально запущенного процесса также, как принципиальная электрическая схема от работающей печатной платы.
Технические компетенции
Допустим, вы описали процессы. Что дальше? Как проектировать новые, эффективные и цифровые процессы? С практикой 70-х годов далеко не уедешь. Проектная команда должна, как минимум, четко представлять себе возможности современных средств автоматизации и тенденции их развития. Первая техническая компетенция – это «Архитектура и дизайн решения». Сотрудники должны знать, как устроена типичная BPMS (возможно, даже Low-code система), что она может делать, а что — нет.
Вторая техническая компетенция – «Знание программного обеспечения BPM». Процессы можно проектировать по-разному. Для регламентов верхнего и среднего уровня будет достаточно довольно общего, аналитического описания. Но для настройки BPMS такие модели не годятся. Нужно проектировать исполняемые процессы, а для этого надо знать, как работает BPM-система.
Конечная цель почти любого BPM-проекта – это автоматизация процессов, поэтому компетенция «Разработка приложений от модели и по аджайлу» является крайне важной. Хотя бы кто-то из участников проектной группы должен ей владеть.
Для создания эффективного процесса недостаточно только сформировать его схему. Как будет работать процесс при реальной нагрузке на входе и недостатке ресурсов? Как обеспечить необходимые показатели производительности, времени и затрат? Для этого требуется компетенция под названием «Имитационное моделирование и оптимизация процессов». Ряд современных программных продуктов позволяют создавать и использовать имитационные модели процессов для расчета необходимых показателей до внедрения, что может помочь заметно сэкономить.
Для создания результата, который нужен потребителю, умение «Проектирование взаимодействия с пользователями» является весьма важным. Кроме того, команда проекта может использовать методы CJM (Customer Journey Mapping).
Структура компетенций по ролям
Как отмечал Ицхак Адизес, в природе не бывает людей, обладающих всеми компетенциями одновременно. Но эту проблему можно решить, формируя команду проекта из сотрудников, компетенции которых взаимно дополняют друг друга. С учетом опыта реальных проектов можно рассмотреть следующую ролевую структуру BPM-проекта:
- Бизнес-заказчик – руководитель верхнего уровня (ГД, Зам. ГД, директор департамента).
- Владелец процесса — руководитель верхнего или среднего уровня. Он может быть так же бизнес-заказчиком, а для компаний среднего и небольшого размера – одновременно руководителем проекта.
- Руководитель BPM-проекта – руководитель среднего уровня или нижнего уровня, ведущий специалист.
- Эксперт в предметной области – руководитель среднего или нижнего уровня, ведущий специалист, специалист, внешний привлеченный отраслевой эксперт.
- Процессный методолог – руководитель или ведущий специалист в структуре Процессного офиса (методически курирует проект).
- Бизнес-аналитик – сотрудник Процессного офиса.
Команда BPM-проекта может включать несколько экспертов в предметной области. Курировать работу команды может Процессный методолог – руководитель или ведущий специалист, входящий в структуру Процессного офиса. Для крупных проектов может назначаться руководитель проекта на полное рабочее время. Для относительно несложных проектов роль руководителя проекта может выполнять начальник (или ведущий специалист) структурного подразделения, совмещая управление проектом со своей текущей деятельностью. В некоторых случаях (чаще для средних и небольших компаний) руководителем проекта может стать непосредственно владелец процесса.
Рассмотрим необходимые уровни «прокачки» компетенций по каждой роли BPM-проекта. Ниже представлено экспертное мнение автора статьи. Еще раз хочу подчеркнуть, что нерационально требовать, например, от бизнес-аналитика уровня понимания бизнес-видения и знания организации, как от топ-менеджера. С другой стороны, странно было бы требовать от топ-менеджера детального знания нотации BPMN и т.п.
В статье я часто употребляю термин «компетенция». В Википедии приводится следующее определение: «Профессиональная компетенция — способность успешно действовать на основе практического опыта, умения и знаний при решении профессиональных задач». В Трудовом кодексе РФ термина «компетенция» нет, но определяется «квалификация», которая понимается как совокупность «знаний-умений-навыков».
В чем разница между «умением» и «навыком»? Рассмотрим определения:
• умение – реализация способности осмысленно выполнять какую-либо работу, требующую теоретических знаний и практических навыков;
• навык – это сочетание стереотипных физических действий и мыслительных операций, которые выполняются в необходимой последовательности как часть определенного вида работы.
Структура трансформационных компетенций представлена в следующей Таблице 1 и на Диаграмме 1. Уровни «прокачки» каждой компетенции показаны по шкале от 1 до 5 баллов и определены следующим образом:
• Уровень 1: Достаточный. Компетенции приближаются к базовым требованиям стандарта.
• Уровень 2: Удовлетворительный. Компетенции полностью удовлетворяют стандарту.
• Уровень 3: Хороший. Компетенции полностью удовлетворяют и по ряду аспектов превышают требования стандарта, четко выражены.
• Уровень 4: Очень хороший. Компетенции по многим аспектам превышают требования стандарта, четко выражены, сохраняются в течение длительного периода.
• Уровень 5: Отличный. Компетенции на уровне лучших отраслевых практик, существенно превышают требования стандарта, четко выражены, сохраняются в течение длительного периода.
Под стандартами в данном случае подразумеваются внутренние стандарты компании, полностью или частично основанные на внешних стандартах.
Структура операционных компетенций представлена в следующей Таблице 3 и на Диаграмме 2.
Структура технических компетенций представлена в следующей Таблице 4 и на Диаграмме 3.
Если коротко, то можно предложить для обсуждения следующее видение:
• у бизнес-заказчика (владельца процесса) должны быть очень хорошие (хорошие) трансформационные компетенции. При этом операционные могут быть удовлетворительные (достаточные), а технические – достаточные (ну не должен Зам. ГД уметь писать скрипты на C#);
• руководитель проекта должен обладать очень хорошими (хорошими) трансформационными, хорошими операционными и очень хорошими техническими компетенциями (особенно для проектов, ориентированных исключительно на автоматизацию бизнес-процессов);
• эксперту в предметной области (специалисту структурного подразделения) требуется удовлетворительные трансформационные, достаточные (удовлетворительные) операционные и технические компетенции (т.е. не обязательно его детально учить настройкам BPMS, если только он потом не будет лично настраивать систему в своем подразделении);
• процессный методолог должен обладать очень хорошими трансформационными компетенциями (местами хорошими), отличными и очень хорошими операционными компетенциями, очень хорошими и хорошими техническими компетенциями. Это самый сложный случай. Найти такого методолога весьма сложно, но он стоит своих денег;
• бизнес-аналитик должен обладать удовлетворительными (местами, хорошими) трансформационными компетенциям. Операционными компетенции должны быть очень хорошие. Технические – хорошие (удовлетворительные).
Из представленных выше таблиц видно, что набор компетенций и необходимая глубина их освоения разные. Как их оценить? Для решения этой задачи можно использовать шкалы оценки.
Шкалы для оценки компетенций
Рассмотрим шкалы оценки трансформационных компетенций (разработаны автором статьи). Шкала для первой компетенции «Умение готовить бизнес-обоснование и наличие видения» представлена на рис.1. Шкалу следует читать так: требования к компетенциям суммируются слева направо. Например, на втором уровне сотрудник не только «Умеет оценивать ROI, привлекательность для бизнеса», но и «Может определять и оценивать риски для бизнеса».
Шкала оценки по компетенции «Управление проектами» представлена на рис.2.
Шкала оценки по компетенции «Знание организационной структуры и корпоративной культуры» представлена на рис.3.
Шкала оценки по компетенции «Коммуникации» представлена на рис.4.
Шкала оценки по компетенции «Методы управления изменениями» представлена на рис.5.
Теперь перейдем к шкалам оценки операционных компетенций. На рис. 6 представлена шкала оценки по компетенции «Выявление бизнес-процессов».
На следующем рисунке 7 представлена шкала оценки по компетенции «Моделирование, анализ и проектирование бизнес-процессов».
Шкала для компетенции «Регулирование и организация процессной работы» представлена на рис. 8.
На следующем рисунке 9 представлена шкала оценки по компетенции «Управление эффективностью процессов».
На следующем рис. 10 представлена шкала оценки для компетенции «Подбор инструментов, поддерживающих методологию BPM».
Шкала для компетенции «Архитектура и дизайн решения» представлена на рис. 11.
На следующем рис. 12 представлена шкала оценки для компетенции «Знание программного обеспечения BPM».
На следующем рис. 13 преставлена шкала оценки для компетенции «Разработка приложений от модели и по аджайлу».
Шкала для компетенции «Имитационное моделирование и оптимизация процессов» представлена на рис. 14.
Шкала для компетенции «Проектирование взаимодействия с пользователями» представлена на рис. 15.
Для каждого уровня каждой шкалы должны быть разработаны контрольные вопросы (как минимум, 2-3), ответы на которые позволят подтвердить достижение соответствующего уровня сотрудником. Создание таких вопросов (критериев) сопряжено, как минимум, с рядом проблем:
• возможность неоднозначной интерпретации вопроса;
• субъективность оценивающего субъекта;
• недостаточная квалификация оценивающего субъекта (например, оценивать знание нотации BPMN не может человек, который никогда не видел ни одной модели в этой нотации);
• недостаточно четкие (противоречивые) стандарты, на основании которых могут быть сформулированы вопросы;
• неоднозначная и противоречивая «лучшая» отраслевая практика.
Тем не менее, работать в этом направлении нужно, иначе от идеи оценивать и развивать компетенции участников команды по внедрению BPM-проекта придется отказаться.
Приведу пример контрольных вопросов (система критериев оценки с весами) для первого и второго уровня шкалы «Моделирование, анализ и проектирование бизнес-процессов».
Чтобы перейти на соответствующий уровень по шкале оценки нужно набрать от 75% до 100% по текущему уровню и не менее 50% по следующему уровню.
Например, по Уровню 2 получено 78%, по Уровню 3 – 42%, а по Уровню 4 – 80% (см. Таблицу 7). В этом случае, в качестве подтвержденного может быть выбран только Уровень 2, так как хорошее знание принципов и/или лучших практик не является основанием для высокой оценки конкретных практических навыков базового уровня.
При разработке шкал и критериев целесообразно использовать доступные источники по этой теме.
Учебные программы и материалы для развития компетенций
Для развития требуемых BPM-компетенций внутри компании нужны учебные программы и материалы, но какие именно? Целесообразно рассмотреть следующие базовые учебные программы (см. таблицу 8).
Очевидно, что некоторые из указанных программ уже могут использоваться в компании (проводилось обучение). Необходимо выяснить несколько вопросов:
• кто и когда был обучен?
• каковы реальные полученные сотрудниками знания, навыки, умения?
• планируется ли включать этих сотрудников в команды по BPM-проектам?
Хотел бы обратить внимание, что программы по одной теме могут быть разные по длительности, сложности и содержанию в зависимости от того, кого мы будем учить. Для создания «достаточных» умений годится короткая обзорная программа и простые упражнения. Для «Хороших» — подробная программа со сложными упражнениями, «домашними заданиями» и тестами. То есть можно иметь несколько уровней сложности по конкретной программе и соответствующую систему заданий, тестов и аттестации (возможно с последующей выдачей внутренних сертификатов, значков и т.п.)
Глядя на количество курсов, представленных в таблице 7, можно подумать, что получилась программа MBA. Чтобы не измучить людей теорией, каждый курс должен быть максимально практическим – обязательно нужно в него включать:
• конкретные документированные методики;
• примеры;
• сложные и полезные практические задания (а не просто рефлексию после вопроса типа: «Посмотрите на лампочку – что вы чувствуете?»).
Отмечу, что если речь идет о коротком и простом проекте, то такое сложное и длительное обучение является излишним. Если же речь идет о системном внедрении технологий процессного управления в крупной компании, то и системное развитие компетенций сотрудников является необходимым.
Для развития компетенций руководителей и сотрудников я провожу для компаний семинары и тренинги по различным программам, в том числе:
- «Внедрение системы управления бизнес-процессами», 2 дня.
- «Стандартизация бизнес-процессов», 2 дня.
- «Моделирование бизнес-процессов в нотации BPMN», 2 дня.
- «Описание, анализ и регламентация процессов в Business Studio», 2 дня.
- «Имитационное моделирование и анализ процессов в Business Studio», 2 дня.
- Прочие специальные программы, составленные по запросам заказчиков.
Кроме того, я провожу моделирующие сессии по описанию и анализу процессов, а также рабочие сессии по разбору результатов работы временных рабочих групп по описанию и анализу процессов в нотации BPMN.
Одновременно с разработкой учебных программ необходимо создать систему подтверждения компетенций. Она может включать систему тестов для каждого уровня и роли в проекте. Частично можно подтверждать компетенции с использованием внешних сервисов. Рассмотрим два из них.
Подтверждение компетенций
Организация ABPMP Russian Chapter разработала профессиональный стандарт «Специалист по процессному управлению», который утвержден приказом Министерства труда и социальной защиты Российской Федерации от «17» апреля 2018 г. № 248н. Так называемая «Функциональная карта вида профессиональной деятельности», представленная в Стандарте, включает следующие «Обобщенные трудовые функции»:
• A. Регламентация процессов подразделений организации или разработка административных регламентов подразделений организации, уровень квалификации 6.
• B. Проектирование и внедрение кросс-функциональных процессов организации или административных регламентов организации, уровень квалификации 6.
• C. Проектирование и внедрение системы процессного управления организации, уровень квалификации 7.
• D. Проектирование и трансформация процессной архитектуры организации, уровень квалификации 7.
Для подтверждения компетенции Процессного методолога и бизнес-аналитика можно использовать тест, разработанный ABPMP Russian Chapter в соответствии с требованиями профессионального Стандарта. Пройти тест «на здравом смысле» не получится – для правильных ответов на многие вопросы нужно не просто знать теорию, но иметь опыт практического использования соответствующих методик и инструментов.
Рассмотрим другой сложный, но полезный путь развития и подтверждения компетенций в области BPM – это прохождение сертификации OMG CERTIFIED EXPERT IN BPM™ 2 (OCEB™ 2). Структура тестов представлена на следующем рисунке 16.
К числу участников BPM-проектов относятся и представители бизнеса, и технические специалисты. Очевидно, что они используют на практике различные наборы методов и инструментов, поэтому программа OCEB 2 разделена на два направления после базового. Это сделано для того, чтобы была возможность проходить сертификацию среднего и продвинутого уровня в зависимости от вашей профессиональной ориентации. Сертификация на каждом уровне требует сертификации на нижестоящих уровнях.
Базовый уровень OCEB 2 требует от участника BPM-проекта определенных знаний и умений. Экзамен этого уровня, в первую очередь, охватывает базовые концепции и термины бизнеса в целом, целеполагания и планирования, управления бизнес-процессами. Далее тест включает область моделирования бизнес-процессов с использованием нотации BPMN 2 (40% теста). Экзамен завершается темами качества процессов, организации процессной работы, разработки системы показателей для управления процессами.
В случае успешной сдачи экзамена вы получаете сертификат, который действует в течение 5 лет. Это вполне разумно и справедливо, так как знания забываются, а не используемые каждый день навыки могут быть потеряны.
Для чего проходить тесты OCEB 2? Для меня лично важны следующие возможности:
• получить признание профессионализма в области BPM;
• систематизировать свои знания в области BPM и узнать что-то новое;
• понять и использовать структуру вопросов для построения внутрикорпоративной системы тестирования;
• ознакомиться с лучшей литературой по теме (на английском языке);
• подтянуть свой английский.
Кроме сертификации по проф.стандарту и OCEB 2, можно пройти учебные курсы и сертификацию у поставщиков различных BPM-систем. Конечно, желательно изучать ту систему, которую предполагается использовать в компании. Но если решение пока не принято, то можно использовать свободно (бесплатно) распространяемые BPM-системы и методические материалы к ним (например, российская RUNA WFE и др.). К сожалению, пока в книжных сетях практически нет учебных курсов (методических пособий) для самостоятельного изучения современных BPM-систем.
Итак, можно отметить следующие возможности по подтверждению компетенций для BPM-проекта:
• внутрикорпоративная система сертификации;
• сертификация по специальности «Специалист по процессному управлению»;
• сертификация OMG OCEB 2;
• сертификация у поставщиков программного обеспечения для BPM;
• сертификация специализированных тренинговых компаний.
В.В. Репин,
к.т.н., доцент, консультант по управлению, Генеральный директор ООО «Владимир Репин Менеджмент», Советник Зам. Председателя Правления АО «СО-ЕЭС».
Декабрь 2019 г.
Нотация BPMN как внутренний стандарт компании для проектирования бизнес-процессов: «за» и «против»
Нотация BPMN как внутренний стандарт компании для проектирования бизнес-процессов: «за» и «против»
В статье Владимира Репина обсуждаются вопросы использования нотации BPMN в качестве корпоративного стандарта проектирования бизнес-процессов компании. Рассматриваются аргументы «За» и «Против» применения. Представлены предложения по организации обучения сотрудников. Приводится практический пример внедрения нотации на крупном предприятии. Обсуждаются «подводные камни» использования нотации BPMN на первых этапах проекта.
Какие нотации используют компании для описания процессов сегодня?
Многие успешные компании, внедряющие технологии автоматизации бизнес-процессов, используют нотацию BPMN. Многие, но не все… Более того, в РФ существует огромное количество средних и крупных предприятий, на которых вообще отсутствует принятый корпоративный стандарт проектирования бизнес-процессов. Какими средствами они «рисуют» процессы? Чаще всего в MS Visio используют набор объектов для «Простой блок-схемы». Бывают ситуации хуже, когда в компании одновременно применяют 3-4 разных подхода к описанию процессов, причем все они нестандартные и реализованы в различных «нотациях» и программных продуктах, включая MS Excel и Power Point.
Интересно, почему, когда речь заходит о необходимости описать процессы, все (кроме узкого круга профи) хватаются за эту «Простую блок-схему» с ромбиками? Возможный ответ – этому учили в школе на уроках информатики. Вдолбили, так сказать. Если бы в школе учили описывать исполняемые процессы в BPMN, то вряд ли чья-то рука потянулась к блок-схеме родом из 70-х. Но пока этого, увы, нет.
К чему приводит такая практика проектирования бизнес-процессов? Во-первых, схемы процессов понятны весьма узкому кругу лиц, а не всем сотрудникам компании. Во-вторых, такие схемы, чаще всего, носят аналитический характер. Это означает, что процесс описан весьма укрупненно, без деталей. Таки схемы нельзя «исполнить». Если попытаться выполнить работу как указано на схеме, то сразу возникнут вопросы, ответов на которые схема не дает. Это звучит странно – как схема, предназначенная для описания алгоритмов, дает сбои при описании процессов для бизнеса? Конечно, ответ заключен не в наборе используемых значков нотации. Причина — в идеологии формирования схемы.
Сегодня тренд цифровизации бизнеса явно набирает обороты. Но может ли компания, которая даже не имеет внутреннего стандарта моделирования и обученных сотрудников, быть успешной в цифровой трансформации? Сомнительно. Для начала, придется научиться быстро и эффективно проектировать процессы своими силами (создать внутренние компетенции), либо заплатить большие деньги внешним провайдерам.
Ситуацию с использованием устаревших подходов частично усугубляет наличие в крупных компаниях действующих систем электронного документооборота. То, что в них творится, назвать автоматизацией бизнес-процессов можно весьма условно. Большинство руководителей это понимает, но не знает возможностей современной BPMS (Business Process Management System) в части автоматизации процессов и, особенно, применения концепции «Документ без документа». Вообще, относительно недавно вступил в стадию умирания бумажный документооборот, а теперь и электронный документооборот должен умереть, оставив вместо себя автоматизированные процессы с нужным набором данных. В BPMS, если потребуются, документы можно формировать автоматически, так сказать, «налету».
Использование нотации BPMN в качестве корпоративного стандарта дает возможность не только проектировать процессы, но и внедрять в массы идеологию исполняемых процессов в купе с новыми ИТ-технологиями, такими как PM (Process Mining), RPA (Robotic Process Automation) и проч. Рассмотрим аргументы «За» и «Против» использования нотации BPMN в качестве корпоративного стандарта.
Почему нотация BPMN: «За» и «Против»
Руководителям компании нужно объяснить, что BPMN – это не просто значки другого, незнакомого вида и цвета. Это – инженерный стандарт проектирования исполняемых бизнес-процессов, обладающий следующими преимуществами (плюсами):
• наглядность, понятность и красота схем;
• после базового обучения можно начинать с использования ограниченного набора объектов;
• BPMN — стандарт ISO с 2013 года;
• BPMN де-факто использует большинство разработчиков BPMS.
Да, BPMN – сложный стандарт. Однако, даже начинающие при использовании ограниченного набора объектов и понимания сути метода (исполняемый процесс, токен, экземпляр) могут проектировать вполне качественные схемы. Более того, применение сложных семантических конструкций без действительной практической необходимости может только осложнить работу, привести к созданию неоправданно сложных схем или вообще исказить смысл процесса до неузнаваемости. С чем бы сравнить? Это как неопытный спортсмен, не освоивший базовую технику бросков, начинает пытаться применять сложные и опасные приемы. Я уверен, что можно обучить сотрудников, так сказать, использовать верхушку айсберга. Этого на первых порах будет достаточно. Крайне важно, чтобы сотрудники компании научились формировать наглядные, понятные и красивые схемы. Много раз на практике наблюдал ситуацию, когда запутанная, уродливая схема после соответствующей доработки становится красивой, а главное, понятной участникам процесса и внутреннему заказчику – руководителю.
Что важно донести до руководителей?
В первую очередь, нужно довести до сведения руководителя компании, что нотация BPMN – это лучший инженерный стандарт для проектирования процессов. Вряд ли в ближайшее время появится какой-то другой стандарт. Если поставлена цель цифровизации компании, то навык проектирования исполняемых процессов с использованием нотации BPMN будет одним из ключевых.
Далее важно объяснить руководителю разницу между общей, аналитической схемой и схемой исполняемого процесса. Для этого потребуется раскрыть понятие токена и экземпляра процесса. Более сложные аспекты, связанные с межпроцессным взаимодействием, можно будет объяснить на примерах компании несколько позже (чтобы поначалу не вызвать отторжения к подходу в целом из-за сложности этого конкретного метода).
BPMN – сложный стандарт. Но в рамках первичного ознакомления достаточно дать руководителям минимально необходимые знания семантики и метода моделирования бизнес-процессов. Это сделать вполне реально, например, в рамках проведения моделирующих (рабочих) сессий по описанию и анализу бизнес-процессов компании.
По ходу вовлечения, руководителям обязательно нужно показывать возможности, ограничения и условия эффективного использования современных решений класса BPMS, PM, RPA, AI и проч. Но надо четко понимать, что передаваемая и, можно сказать, культивируемая в умах менеджеров идеология исполняемых бизнес-процессов является базой для пропаганды новых информационных технологий.
Как обучать сотрудников нотации BPMN?
Это не так уж и сложно. Нужно:
- найти хорошего специалиста, который умеет преподавать тему, и обсудить с ним учебную программу;
- подготовить учебные и методические материалы;
- выбрать инструмент моделирования;
- разработать внутренний стандарт применения нотации BPMN для проектирования бизнес-процессов;
- организовать обучение;
- организовать работу по практическому закреплению навыков моделирования процессов.
В настоящее время специалистов, хорошо знающих BPMN, на рынке уже достаточно много. Но важно, чтобы такой специалист мог научить использовать нотацию на простых и понятных примерах, без использования «птичьего языка» (сленга ИТ-специалистов – профессиональных внедренцев BPMS). Кстати, я категорически против так называемого «каскадного» обучения, когда одного сотрудника отправляют на тренинг, а он потом пытается учить всех остальных. Результат – множество ошибок, а главное, — искаженное понимание темы.
Обучение проектированию процессов в нотации BPMN я провожу по книге «Моделирование бизнес-процессов в нотации BPMN. Пособие для начинающих. Часть I». Как правило, в течение 4-6 часов слушатели делают практические задания, осваивая элементы нотации от простого к сложному. Затем, они выполняют комплексное практическое задание по проектированию трех связанных между собой процессов. Проводится презентация результатов, анализ схем по чек-листу и разбор ошибок. Для такого обучения достаточно одного дня.
Далее выдаются практические задания, которые слушатели делают в течение недели. Затем проводится рабочая сессия по представлению и разбору схем процессов («домашние задания» я проверяю заранее). После 2-3 сессий участники приобретают навык формирования вполне адекватных схем в нотации BPMN.
На следующем этапе развития можно использовать книгу Игоря Федоров «Нотация BPMN 2.0. Стандарт ISO/IEC 19510:2013 для создания исполняемых моделей бизнес-процессов», сам стандарт и множество практически полезных материалов в сети Интернет.
Идеальным вариантом освоения BPMN является практикум с использованием, собственно, BPMS (например, такой практикум проводит А.А. Белайчук, Президент ABPMP Russian Chapter, с использованием системы BizAgi). Однако, в ряде случаев это сделать технически и организационно сложно. Приходится начинать с простого. Но, как минимум, демонстрацию движения токенов вдоль схемы исполняемого процесса сделать крайне полезно.
Внедрение нотации BPMN как корпоративного стандарта проектирования процессов в Иркутской нефтяной компании
В качестве примера рассмотрим кейс внедрения нотации BPMN в «Иркутской нефтяной компании» («ИНК»), в которой я уже более 1,5 лет сопровождаю проект создания и развития Системы управления бизнес-процессами. Информацию любезно предоставил Юрий Андреевич Федосеев, начальник отдела оптимизации бизнес-процессов и стандартизации ООО «ИНК» (ОБПиС).
За время проекта в «ИНК» удалось сделать многое:
• разработан и внедрен стандарт «Моделирование бизнес-процессов»;
• установлен и настроен инструмент проектирования и анализа процессов (Business Studio 4.2);
• обучено 259 руководителей и специалистов;
• сформировано более 226 схем в BPMN;
• внешние подрядчики (в т.ч. крупные консалтинговые компании) обязаны представлять результаты работы в виде схем BPMN с учетом требований стандарта компании;
• внедрены регламенты сквозных процессов, разработанные на основе схем процессов в нотации BPMN;
• внедряется система оценки процессной зрелости компании;
• проект на стадии выбора BPMS.
Самое главное, что в «ИНК» активно формируется процессное мышление у руководителей и специалистов. Высокая практическая оценка используемых методов и инструментов подтверждается большим количеством запросов от подразделений в ОБПиС с просьбой провести анализ и оптимизацию их процессов. Юрий Федосеев отмечает: «В проектах оптимизации мы преимущественно используем базовый набор элементов нотации (стартовые и конечные события, события отправки и приема сообщения, таймеры, шлюзы и/или… Несмотря на сложность, базовые элементы и логика нотации хорошо воспринимается сотрудниками на обучении. Освоение происходит быстро. Все бизнес-аналитики отдела прошли подготовку по программе Внутренних тренеров, что позволило организовывать качественное обучение для небольших групп на постоянной основе. Мы не ставим перед собой цель описать все процессы Компании. Ценность нашей работы – в помощи, внутреннем консалтинге. Наши клиенты – подразделения, которые хотят разобраться в своей работе и в том, как лучше взаимодействовать с другими в рамках сквозных процессов. И моделирование – это наш основной инструмент в этом деле…».
«Оптимизация процессов Электроснабжения» — так назывался один из проектов «ИНК», в рамках которого использовалась технология описания и анализа процессов в нотации BPMN. По ходу проекта было сформировано 59 процессов в нотации BPMN. Описание и анализ процессов позволил выявить 10 критичных зон безответственности и последствия, к которым наличие этих зон может привести. Прогнозный экономический эффект от устранения зон безответственности составляет около 78,6 млн. рублей в год.
Второй проект с использованием BPMN, как корпоративного стандарта проектирования процессов «ИНК», — это «Оптимизация процессов Капитального строительства». В рамках данного проекта в условиях жестких ограничений удалось выстроить слаженную и эффективную работу подразделений. Основные результаты моделирования процессов на текущей фазе проекта: прозрачный процесс капитального строительства, оперативный доступ сотрудников к схемам процессов и регламентам через корпоративный портал.
Подводные камни внедрения нотации BPMN в качестве корпоративного стандарта
В некоторых компаниях при использовании нотации BPMN для проектирования процессов возникают определенные трудности. Работа организована неэффективно. На выходе получаются поверхностные схемы аналитического характера, которые невозможно использовать для анализа и принятия решений. Некоторые причины такой ситуации:
• плохое обучение – как следствие, непонимание исполняемых процессов и формирование аналитических схем;
• архитектурные решения низкого качества – проектирование процессов нижнего уровня без понимания системы процессов в целом;
• попытка формально «перерисовать» в BPMN старые схемы с сохранением их недостатков;
• схемы огромного размера с ошибками (семантика, логика);
• низкая степень мотивации участников процесса (или обратная мотивация – желание скрыть реальную картину);
• моделирование ради моделирования.
Резюме
Хочу отметить, что навык проектирования процессов в нотации BPMN – это только один из многих навыков второй группы компетенций («Операционные») модели Gartner 2013 года, которые необходимы для успешного выполнения BPM-проекта в компании. Это означает, что руководители не должны ожидать «процессно-цифрового чуда» только от того, что они заставили необученных сотрудников с низким уровнем внутренней мотивации «рисовать» схемы процессов. Другими словами, внедрение Системы управления бизнес-процессами компании – это не только проектирование процессов, но их активное улучшение и внедрение изменений, создание методов и инструментов управления бизнес-процессами.
Если руководство компании поставило цель трансформировать систему управления с использованием современных процессных технологий, то навык проектирования и анализа исполняемых процессов является одним из ключевых. Нотация BPMN в этом случае может и должна быть выбрана в качестве внутреннего корпоративного стандарта проектирования бизнес-процессов.
В.В. Репин,
к.т.н., доцент, консультант по управлению, Генеральный директор ООО «Владимир Репин Менеджмент», Советник Зам. Председателя Правления АО «СО-ЕЭС».
Ноябрь 2019 г.
Разработка в Business Studio ТЗ на автоматизацию бизнес-процессов в BPMS
Разработка в Business Studio ТЗ на автоматизацию бизнес-процессов в BPMS
В статье Владимира Репина представлен пример описания бизнес-процесса и настройки среды моделирования Business Studio для создания технического задания на автоматизацию бизнес-процесса в BPMS. Обсуждаются вопросы вовлечения руководителей и сотрудников подразделений компании в работу по проектированию исполняемых процессов и формированию ТЗ на автоматизацию.
Возможная постановка задачи
Довольно распространенной является ситуация, когда в компании есть много схем бизнес-процессов, созданных в MS Visio. Беглый анализ показывает, что они явно неисполняемые, содержат логические ошибки, операции разного масштаба и проч. На рис. 1 представлен пример такой схемы процесса, предоставленный заказчиком.
В целом, схема вполне нормальная, но содержит две логических ошибки. С точки зрения архитектуры, схему можно покритиковать за то, что наиболее важная часть процесса, создающая реальную ценность, показана в виде одной операции. Все остальное – это планирование работы, контроль, согласование и утверждение результатов.
Постановка задачи. Необходимо с использованием Business Studio:
а) перевести все подготовленные схемы в универсальный формат, при этом:
б) создать архитектуру бизнес-процессов компании;
с) сделать процессы исполняемыми;
д) подготовить ТЗ на автоматизацию процессов в BPMS.
Поставленная задача может быть решена путем использования программного продукта Business Studio и нотации BPMN.
В данном случае, я привел пример только одной схемы. Если бы речь шла об автоматизации одного процесса, то не было бы никакого смысла переводить схему из MS Visio сначала в Business Studio, а потом в BPMS. Но совсем другое дело, когда нужно подготовить сначала модели нескольких процессов, взаимосвязанных с точки зрения технологии и входов-выходов.
Если рассматривать/автоматизировать N процессов, не продуманных в единой архитектуре, можно упустить ряд важных деталей и не получить решение бизнес-задачи в целом. Поэтому роль среды моделирования при разработке и автоматизации нескольких взаимосвязанных процессов кардинально возрастает.
Специалист по Business Studio Иван Глебов, считает, что «дополнительным положительным результатом использования среды моделирования Business Studio для формирования ТЗ является документирование функциональной архитектуры информационных систем, используемых для автоматизации бизнес-процессов. Архитектура информационных систем формируется в разделе «Программные продукты» среды моделирования Business Studio».
Перевод схемы в нотацию BPMN в Business Studio
Схему, представленную на рис. 1, можно было бы разделить на три-четыре части и сформировать отдельные модели. Но я не пошел на этот радикальный шаг, а просто перерисовал диаграмму в Business Studio в нотации BPMN, устранив логические ошибки и некоторые, на мой взгляд, лишние операции. Полученная схема представлена на рис. 2.
Замечу, что можно использовать полученную схему для создания имитационной модели процесса. Такая модель в Business Studio применяется для валидации процесса, то есть проверки, будет ли процесс на практике стабильно выдавать результат с установленными характеристиками по стоимости, времени и качеству. К слову, практически в каждой BPMS можно тестировать подготовленные схемы (т.е. запускать токены и смотреть, дойдет ли процесс до конца), но вот запускать имитацию и получать статистические параметры процесса для его анализа и оптимизации – нельзя.
Фрагмент схемы показан на рис. 3. Использованы маркеры операций, чтобы показать, какая операция будет выполняться пользователем в интерфейсе BPMS (Business process management system), а какая может быть выполнена скриптом (соответствующий маркер и серая заливка).
Не все операции процесса при переводе в исполняемый формат сохраняются в том виде, как на оригинальной схеме в MS Visio. При разработке модели процесса для BPMS многие действия рационально объединить в рамках одной операции.
Так же показаны информационные системы, которые в текущий момент используются для выполнения операций процесса, например, «АИС «Управление планом ПИР». Кроме того, в качестве примера, показана возможность отобразить документооборот на схеме процесса и используемые для хранения документов базы данных компании.
Стоит упомянуть, что возможен импорт схем, созданных в MS Visio, в Business Studio. Но в данном случае было быстрее нарисовать «правильную» схему заново, чем редактировать схему, полученную после импорта. Но этот пример не говорит о том, что так поступать нужно всегда. Функция импорта полезна.
Настройка аналитики по бизнес-процессу и формирование ТЗ на автоматизацию
Для того, чтобы схему процесса можно было передавать для настройки BPMS, процесс должен быть исполняемым. Это означает, что токен, запустивший процесс, «добежит» до конца процесса при любом возможном сценарии. Важно, чтобы при формировании схемы процесса соблюдалась семантика нотации BPMN. В противном случае, схема не будет универсальной и пригодной для настройки исполняемого процесса в любой BPMS.
Кроме того, для настройки BPMS требуется дополнительная информация, которая не представлена на схеме. Необходимо определить, какие аналитические данные нужны автоматизации процесса в конкретной исполняемой системе. Затем настроить Business Studio путем расширения объектной модели с использованием модуля Meta Edit так, чтобы можно было удобно вносить данные через интерфейс системы. На рис. 4 показан пример возможной настройки. Для каждой операции процесса доступна закладка «ТЗ на автоматизацию», которая содержит ряд полей (атрибутов), которые необходимо заполнить.
Например, можно выбрать тип операции процесса: «в интерфейсе BPMS», «сценарий», «ручная операция» и т.д. Можно указать, что требуется настройка нормативного времени выполнения операции и указать это время. Можно добавить, что нужно измерять фактическое время выполнения т.п. Так же есть атрибут, показывающий необходимость интеграции с другой системой и проч.
После занесения информации по всем операциям процесса, можно автоматически сформировать готовое Техническое задание на автоматизацию бизнес-процесса. Для этого в Business Studio настраивается специальный шаблон отчета. Возможна выгрузка в MS Word или в MS Visio в зависимости от требований проекта. На рисунках 5 и 6 показаны фрагменты такого ТЗ. В данном случае, ТЗ сформировано в весьма упрощенной, демонстрационной форме.
Какая еще аналитика может и должна быть собрана при подготовке к автоматизации процесса в BPMS? В своей статье Андрей Чепакин предлагает следующую структуру:
- Схема инициации процесса.
1.1. Роль «Инициатор бизнес-процесса».
1.2. Мотив инициации бизнес-процесса.
1.3. Способы запуска бизнес-процесса. - Схема создания ценности.
2.1. Типизация клиентов/заказчиков бизнес-процесса.
2.2. Составляющие ценности, формируемой процессом, по типам клиентов.
2.3. Сценарии использования процесса его клиентами. - Схема работы процесса.
3.1. Спецификация входов процесса.
3.2. Спецификация выходов процесса.
3.3. Определение единицы потока и ее состояний.
3.4. Ролевая модель процесса.
3.5. Спецификация метрик и показателей процесса. - Схема данных процесса.
4.1. Спецификация данных процесса.
4.2. Определение источников данных для процесса. - Схема контроля процесса.
5.1. Спецификация контролируемых метрик и показателей.
5.2. Способы сбора и обработки данных.
5.3. Способы доставки информации владельцам процесса. - Схема обратной связи процесса.
6.1. Способы доставки обратной связи участникам процесса.
6.2. Способы получения обратной связи от клиентов процесса.
6.3. Способы доставки обратной связи высшему руководству. - Схема компетенций процесса.
7.1. Требования к перечню участников процесса.
7.2. Требования к компетенциям участников процесса.
7.3. Реестр возможностей снижения требований к компетенциям.
Обратите внимание, что графическая схема процесса содержит только часть информации, необходимой для автоматизации, а главное, последующего управления и развития бизнес-процесса. Так, например, необходимо заранее определить показатели, которые нужно собирать, способ их измерения и способ доведения до руководителей (план/факт, отклонения, визуализация цветом и т.п.).
Интересные мысли по аналитике высказывает Денис Котов в своей статье. Он рекомендует включать в ТЗ на автоматизацию процессов в BPMS (кроме схемы) следующую информацию:
• Модель данных.
• Объекты системы (например, договор, закупочная процедура или клиент).
• Данные процесса (информация, относящаяся к конкретному экземпляру процесса).
• Отчеты.
• Автоматизации: эскалации руководителям, расчеты («математика»), бизнес-правила, проверка из базы данных, триггеры, интеграции.
Многие специалисты считают, что модель данных, кроме схемы, является ключевой для эффективного решения задачи автоматизации процесса в BPMS. В текущей версии Business Studio, к сожалению, нельзя создать графическую модель структуры данных, как это можно быть сделать, например, в ERWin (ER модель — entity-relationship model, модель «сущность — связь» — модель данных, позволяющая описывать концептуальные схемы предметной области). В Business Studio можно только описать атрибуты для всех документов, которые используются в моделях бизнес-процессов, как показано на рис. 7.
Иван Глебов отмечает, «что хотя в настоящий момент в среде Business Studio нет возможности графически моделировать структуру данных для ТЗ, но зато в ней есть возможность давать детальное описание атрибутов документов, используемых в процессах, что позволяет достаточным образом смоделировать необходимую структуру данных в «текстово-табличном» виде. При этом, посредством MetaEdit, таблицу атрибутов документа можно дополнить колонкой, в которой, при необходимости, можно указать другой документ в бизнес-модели, с которым атрибут документа должен иметь связь при автоматизации документа в информационной системе».
Кто будет настраивать BPMS?
Настройка любой BPMS включает, как минимум:
- создание модели организационной структуры компании;
- создание графической модели процесса;
- определение участников процесса и их прав;
- определение необходимых данных;
- настройка показателей для контроля и управления процессом;
- создание экранных форм;
- проверка процесса и публикация на исполняемом сервере.
К более сложным задачам настройки относятся такие задачи, как: написание скриптов, создание различных плагинов, создание сложных экранных форм и, наконец, интеграция со внешними системами.
Можно ли научить руководителей и сотрудников подразделений всем указанным выше аспектам? Да, можно. Но это, на мой взгляд, нерационально. Сотрудники компании должны понимать, что означает исполняемый процесс, и знать основные функциональные возможности конкретной системы BPM. Но учить их нюансам настройки системы долго и дорого.
Достаточно иметь команду специалистов, хорошо знающих BPMS (количество зависит от масштаба проекта, конечно). При этом важно, что руководители и сотрудники подразделений могут проектировать исполняемые процессы на уровне, приемлемом для последующей быстрой настройки BPMS.
Важно, что сотрудники компании вовлекаются в «процессную работу», получают навыки проектирования эффективных процессов и заинтересованы в совместном результате.
На рис. 8 показано возможное видение организации работы различных команд в рамках проекта описания, оптимизации и автоматизации бизнес-процессов компании.
Может быть создано несколько команд, состоящих из сотрудников разных подразделений, которые проектируют бизнес-процессы в Business Studio, проводят анализ и формулируют требования и пожелания (например, автоматизировать выполнение конкретных операций или применить RPA). Участникам рабочих групп не нужно знать нюансы настройки BPMS, поэтому они могут сосредоточиться на проектировании эффективных бизнес-процессов. Такой подход может существенно ускорить работу по оптимизации и автоматизации бизнес-процессов компании.
Однако, есть сторонники другой точки зрения. Ее суть заключается в том, что дублировать схемы процессов в разных системах крайне нежелательно, а нужно проектировать и автоматизировать бизнес-процессы сразу в BPMS. Ниже я сделал попытку сравнить два похода. Вы можете использовать это сравнение для анализа и принятия решений по методу, который будете использовать в своей компании.
Сравнение двух подходов. Таблица.
№ | Требуемые компетенции | Руководители и специалисты подразделений | ИТ-специалисты | Руководители и специалисты подразделений | ИТ-специалисты |
1 | Создание графических схем в нотации BPMN | Да | Да | Да | Да |
2 | Понимание сути исполняемого процесса (токены, экземпляры) | Да | Да | Да | Да |
3 | Знание методов теории ограничений (TOC) | Да | Нет | Да | Да |
4 | Знание методов Lean (поиск потерь) | Да | Нет | Да | Да |
5 | Знание методов управления процессом по целям и показателям | Да | Нет | Да | Да |
6 | Знание пользовательского интерфейса и базового функционала BPMS | Да | Да | Да | Да |
7 | Знание архитектуры и детального функционала BPMS | Нет | Да | Да | Да |
8 | Настройка модели данных (ER-модель, понимание локальных переменных процесса, умение настраивать модель данных) | Нет | Да | Да | Да |
9 | Настройка скриптов (C#, Java script) | Нет | Да | Да | Да |
10 | Создание экранных форм | Нет | Да | Да | Да |
11 | Настройка интеграции с другими системами | Нет | Да | Нет | Да |
В случае Варианта I (столбцы 3-4) руководители и специалисты подразделений владеют компетенциями:
• по описанию и анализу бизнес-процесса;
• по использованию базового функционала BPMS на уровне пользователей.
При этом бизнес-пользователей не нужно учить несвойственным и ненужным им аспектам.
Например, менеджера по продажам, цель которого продавать товар компании, не нужно учить программировать скрипты на C# или создавать ER-модель.
В свою очередь ИТ специалистов не нужно специально учить методам анализа и оптимизации процессов (TOC, Lean, KPI).
В случае Варианта II (столбцы 5-6) руководители и специалисты подразделений должны овладеть специальными компетенциями (см. красный шрифт) на весьма глубоком уровне.
Могут ли бизнес-пользователи проектировать процессы сразу в графическом редакторе BPMS? Да, могут. При этом они, в любом случае, должны в какой-то форме фиксировать требования к дальнейшей, более сложной настройке исполняемого процесса. Вопрос – где именно? На клочке бумаги, устно или все-таки в формализованном, структурированном виде?
Еще один момент. В BPMS нужно сразу выполнять настройки, а не фиксировать требования к ним. Например, необходимо настроить шлюз с проверкой условий скриптом и т.п. Такие навыки уже выходят за границы компетенции бизнес-пользователей.
Приведу пример. В моей книге «Моделирование бизнес-процессов в нотации BPMN. Пособие для начинающих. Часть I» представлены модели трех процессов. Первый процесс называется «Подача заявки на оплату». В компании может быть одновременно инициировано несколько экземпляров этого процесса. Второй процесс – «Согласование графика платежей на неделю». Он запускается по таймеру и выполняется один раз в неделю. Третий процесс называется «Оплата счетов». Он инициируется процессом «Согласование графика платежей на неделю». Модели процессов были созданы в Business Studio в нотации BPMN. Используя семантику BPMN, я показал на схеме, что каждый экземпляр процесса «Подача заявки на оплату» должен получить сообщения из процессов «Согласование графика платежей на неделю» и «Оплата счетов». Далее эти три схемы были переданы в качестве ТЗ специалисту по Elma, который быстро настроил исполняемые процессы в этой системе (большое спасибо!). При настройке нужно было решить несколько задач, явно выходящих за пределы компетенций бизнес-пользователя, а именно: дополнение структуры данных, создание переменных процессов, создание скриптов на C#, управляющих отправкой сообщений, доработкой модели процесса с учетом технологических особенностей работы скриптов.
Добавлю, что в силу архитектурных ограничений в BPMS невозможно создавать архитектуру бизнес-процессов компании в целом и использовать ее для решения таких задач, как: обоснование реорганизации компании, формирование регламентирующих документов и проч.
Стоит отметить, что компетенции участников проекта должны в разумной степени пересекаться, как показано на рисунке 9.
В идеальном случае, руководители и специалисты функциональных подразделений должны хорошо владеть методами процессного управления и развития бизнеса и знать общие возможности настройки и использования BPMS. В свою очередь, ИТ-специалисты, профессионально владея настройками BPMS, должны в достаточной степени знать предметную область и методы анализа и развития бизнес-процессов.
В.В. Репин,
к.т.н., доцент, консультант по управлению, тренер,
Генеральный директор ООО «Владимир Репин Менеджмент»
Июнь 2019 г.
Сценарии выполнения сквозного процесса
Сценарии выполнения сквозного процесса
В статье Владимира Репина рассмотрена методика формирования модели сквозного процесса масштаба компании в среде Business Studio. Приводится пример модели в нотации IDEF0. Рассматриваются сценарии выполнения сквозного процесса. Представленная методика может быть использована при работе с любым программным продуктом, предназначенным для проектирования архитектуры бизнес-процессов организации.
Введение
С точки зрения повышения эффективности бизнеса важно уметь строить и использовать для оптимизации модель сквозного процесса масштаба компании.
В качестве примера я выбрал процесс «Разработка нового изделия: от идеи до постановки на производство» и создал его модель в Business Studio.
Обращаю внимание, что у меня не было цели создавать модель «идеального» процесса с претензией на «лучшую практику». Цель построения модели – показать возможности методологии моделирования сквозных процессов масштаба компании в среде Business Studio.
Модель сквозного процесса в нотации IDEF0
На рис. 1 представлена контекстная модель этого процесса. Видно, что стрелки приходят «ниоткуда» и уходят в «никуда». Понятно, что у сквозного процесса есть внутренние поставщики и потребители (процессы). Но на контекстной диаграмме Business Studio, увы, нельзя показать междиаграммные ссылки на другие процессы модели (техническое ограничение). С этим придется мириться. С другой стороны, в данном случае важно разработать модель отдельного сквозного процесса, а не всей компании.
Сквозной процесс строится из кусков – функциональных процессов подразделений разного уровня. Предполагается, что перед тем, как начать строить модель сквозного процесса, вы четко понимаете структуру процессов (функций), выполняемых в подразделениях. Более того, желательно иметь все эти процессы в виде иерархического справочника в Business Studio (только реестр, диаграммы можно сгенерировать, но они будут без связей).
На модели А0 сквозного процесса можно использовать блоки (процессы), которых нет в функциональной модели (реестрах функциональных процессов подразделений). Почему так?
Дело в том, что видение сквозного процесса масштаба компании, его структуры является предметом для обсуждения и согласования топ-менеджеров, например, в рамках проведения Процессного комитета (создание которого рекомендует BPM CBOK).
Другими словами, группировка процессных категорий на диаграмме А0 сквозного процесса (см. рис. 2) может отличатся от существующих структурных подразделений компании. Это две большие разницы.
Рассмотрим диаграмму процесса «Разработка нового продукта» (рис. 2). Видно, что рассматриваемый сквозной процесс является весьма масштабным. Он состоит из блоков (процессных категорий), которые сами по себе являются сложными.
Очевидно, что процесс такого уровня сложности невозможно представить в виде какой-то одной цепочки операций (Work Flow – поток работ, в нотации eEPC или BPMN), выполняемых конкретными сотрудниками. (Теоретически, это сделать можно, но модель будет включать несколько тысяч шагов и сотни шлюзов, что сделает ее абсолютно нечитаемой и практически неприменимой).
Если мы декомпозируем, например, «Выполнение НИОКР», то, скорее всего, на диаграмме увидим процессы, которые тоже нерационально представлять в виде диаграмм Work Flow.
Очевидно, что сквозной процесс такого масштаба нуждается в постоянном административном управлении. Поэтому наличие на схеме блока «Управление разработкой новых и изменением текущих продуктов» представляется вполне оправданным.
На рис. 2 некоторые блоки показаны розовым цветом. Это сделано специально, чтобы обратить ваше внимание на тот факт, что эти процессы (полностью или частично) выполнятся не только в рамках рассматриваемого сквозного процесса, но и задействованы при выполнении других процессов.
Пример. Внутри блока «Разработка технологии производства нового продукта» находятся следующие подпроцессы:
• Управление разработкой технологии производства.
• Разработка НТД по продукту.
• Тестирование новых видов сырья и упаковки.
• Разработка нормативов по новому продукту.
• …
Например, «Тестирование новых видов сырья и упаковки» может проводиться не только в рамках сквозного процесса создания нового продукта, а по ходу выполнения рутинной функциональной деятельности в случае необходимости смены поставщика сырья по каким-то причинам. Продукт останется тот же, но сырье будет от другого поставщика. С точки зрения технолога, в любом случае, надо тестировать, подойдет ли новое сырье или нет.
На рис. 3 показана диаграмма процесса «Разработка требований к новому продукту».
Семь процессов, представленные на диаграмме, выполняются последовательно только в идеальном случае (кроме блока «Анализ необходимости внесения изменений в существующий продукт»).
В реальности часть из них может работать одновременно, с разными задачами. Видно, что возможны возвраты и переделки, например, «Анализ возможности и необходимости создания нового продукта», «Разработка ТЗ на новый продукт» и «Принятие решения по новому продукту».
Если рассматривать блоки деятельности, представленные на схеме 3, как Work Flow (т.е. на следующем уровне), то для каждого такого процесса возможные различные условия:
• старта в части запуска предыдущими процессами;
• завершения в части запуска других процессов.
Сценарии выполнения сквозного процесса
На рис. 4 цветом показаны различные сценарии последовательного запуска процессов. На практике, конечно, их гораздо больше, чем три.
Желтый сценарий – «идеальный», когда всё делается с первого раза и продукт получается удачный.
Оранжевый сценарий – когда нужна консультация с клиентом с последующей повторной оценкой идей, а также, повторное выполнение разработки требований и принятия решений по результатам выпуска опытных партий продукта.
Третий, розовый сценарий запускается при получении рекламаций, анализ которых может потребовать радикальных мер, приводящих к созданию, по сути, нового продукта и т.д.
Очевидно, что сценариев выполнения сквозного процесса в части блока «Разработка требований к новому продукту» может быть множество.
Зачем нужна информация о том, какие процессы в рамках конкретного сценария должны запускаться? Ответ может быть следующий:
• для понимания процесса и возможностей его оптимизации;
• для определения требований в рамках регламентации сквозного процесса;
• для автоматизации сквозного процесса в BPMS системе – нужна архитектура процессов и понимание того, при каких условиях и с какими данными эти процессы будут последовательно запускаться в работу.
Часто бывает, что при построении модели выхватывают какой-то один сценарий или микс 2-3 сценариев. При этом забывают о том, что возможны и другие сценарии. Результат – рыхлая, фрагментарная модель, которая никуда не годится (процесс не может быть выполнен).
Попытка регламентировать, а уж тем более автоматизировать такой «дырявый» сценарий приведет к тому, что постоянно будет требоваться ручное управление. При этом я не хочу сказать, что для начала автоматизации нужно знать всё. Нет. Можно начинать автоматизировать процесс по частям. Но при этом понимание архитектуры сквозного процесса в целом поможет существенно сократить время на последующие переделки.
Для анализа некоторых возможных сценариев выполнения сквозного процесса можно построить соответствующую матрицу – см. пример ниже.
Таблица. Сценарии выполнения сквозного процесса. Пример.
№ | Наименование процесса | Сценарий А | Сценарий Б | Сценарий В |
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. | Заключение договоров с поставщиками | — | + | — |
6.3. | Закупка, монтаж и пуско-наладка оборудования | — | + | — |
6.4. | Модернизация оборудования | + | — | — |
6.5. | Сертификация продукта | + | + | — |
6.6. | Внесение изменений в НТД | + | + | + |
6.7. | Внесение изменений в НМД | + | + | — |
6.8. | Определение цены на новый продукт | + | + | — |
6.9. | Обучение производственного персонала | + | + | — |
6.10 | Обучение сбытового персонала | + | + | — |
Некоторые процессы в этой таблице требуют декомпозиции еще на один уровень, прежде чем их можно будет описать в формате Work Flow (например, в нотации BPMN).
Анализ сценариев
Далее, если все процессы будут описаны в формате Work Flow, можно будет для каждого процесса рассчитать показатели выполнения одного экземпляра:
• минимальное, нормативное, максимальное время выполнения;
• затраты на выполнение.
(Кстати, для целей анализа времени выполнения и затрат можно использовать функционал имитационного моделирования в Business Studio).
Затем, с учетом среднего количества запусков каждого процесса (возможны итерационные повторения), можно рассчитать показатели конкретного сценария сквозного процесса в целом:
• общее время выполнения;
• совокупные затраты.
Полученную информацию можно использовать для анализа эффективности производства нового продукта. Например, при заданном размере планируемой партии может оказаться, что затраты на выполнение соответствующего сценария сквозного процесса будут больше, чем маржа от производства этой партии под конкретный заказ клиента. В этом случае, нужно будет принять решение о целесообразности разработки и производства этого нового продукта.
Если не брать в расчет стоимость всех процессов сценария, а только учесть стоимость сырья и материалов и разнести накладные (как это может сделать планово-экономический отдел), то картина окажется совершенно другой. Как следствие – будет принято ошибочное управленческое решение.
Также, результаты анализа можно использовать для определения целей и показателей оптимизации процессов, входящих в сценарий с точки зрения сокращения времени и затрат сквозного процесса в целом. Можно будет выявить процессы, которые являются узким местом как по времени, так и по затратам.
Очевидно, что общие показатели для «сквозного процесса в целом» (а не отдельного типового сценария) будут, в значительной мере, «средней температурой по больнице». Выбор и расчет показателей для сквозного процесса такого масштаба является весьма сложной задачей.
Резюме. Если цель проекта – повышение эффективности сквозного процесса, то можно и нужно сразу браться за его описание и анализ, не пытаясь создать полную, комплексную архитектуру процессов в Business Studio. Используя функциональные возможности системы, можно:
• построить архитектуру сквозного процесса;
• описать всего его подпроцессы в нотации BPMN и увязать их по входам/выходам и условиям запуска;
• провести анализ процессов с использование движка имитационного моделирования (или без него), определить время выполнения процессов и соответствующие затраты;
• построить матрицу сценариев выполнения сквозного процесса;
• выполнить анализ и оптимизацию сквозного процесса;
• регламентировать сквозной процесс;
• разработать систему целей и показателей для управления сквозным процессом (для основных сценариев);
• разработать техническое задание на автоматизацию сквозного процесса.
В.В. Репин,
к.т.н., доцент, консультант по управлению, тренер,
Генеральный директор ООО «Владимир Репин Менеджмент»
Март 2019 г.
Нотации моделирования процессов в Business Studio: «Процедура», eEPC и BPM. Что выбрать?
Нотации моделирования процессов в Business Studio: «Процедура», eEPC и BPM. Что выбрать?
В статье Владимира Репина рассмотрены три нотации моделирования бизнес-процессов, при помощи которых можно создавать графические диаграммы с использованием продукта Business Studio: «Процедура», eEPC, BPMN. Обсуждаются преимущества и недостатки каждой нотации. Приводится сравнительный анализ и рекомендации по выбору нотации для описания бизнес-процессов компании.
Введение
Многие компании используют программный продукт Business Studio для описания бизнес-процессов на операционном уровне с целью их последующего анализа и оптимизации, регламентации и автоматизации.
В Business Studio представлено три нотации, которые можно для этого использовать: «Процедура», eEPC, BPMN.
Цель статьи – кратко рассмотреть ключевые преимущества и недостатки каждой нотации, а также сравнить их между собой при помощи ряда критериев.
Такой анализ и сравнение может быть полезен при выборе нотации моделирования бизнес-процессов для использования в проекте построения системы управления бизнес-процессами компании.
Нотация «Процедура»
На рис. 1 представлен пример диаграммы бизнес-процесса, сформированной в нотации «Процедура». В этой старой нотации (1974 г.) используется весьма ограниченный набор графических элементов, в том числе: стартовое и завершающее события – овал, операция процесса – четырехугольник, операция принятия решения или шлюз типа «исключающее «ИЛИ» (кто как использует) – ромб, стрелка с одним наконечником («Связь предшествования») – для отображения потока работы, стрелка с двумя наконечниками – для отображения потока объектов (в первую очередь, документов).
Рассмотрим ключевые преимущества и недостатки нотации «Процедура».
Преимущества:
• внешняя простота;
• интеграция с IDEF0 по потокам объектов;
• возможность использования междиаграммных ссылок для интеграции моделей в архитектуре.
Недостатки:
• морально устарела;
• примитивная семантика, в т.ч. отсутствие нормального аппарата шлюзов и событий;
• отсутствие визуальных значков для моделирования движения документов и статусов;
• нельзя использовать промежуточные события;
• некорректная работа имитации;
• невозможность экспорта моделей в BPMS для автоматизации.
Одним из существенных преимуществ «Процедуры» является внешняя простота. Если цель диаграммы процесса – передача информации только для людей (без имитации и автоматизации), то это является большим преимуществом. Другими словами, если вы создаете аналитическую диаграмму процесса, не предполагая делать из нее модель для расчетов или передавать на автоматизацию в BPMS, то «Процедура» вам подходит.
При использовании «Процедуры» весьма удобно, что стрелки с диаграммы в нотации IDEF0 мигрируют на диаграмму в «Процедуре» автоматически. Кроме того, на «Процедуре» можно использовать междиаграммные ссылки, напрямую увязывая процессы между собой по входам/выходам и условиям старта/завершения.
На этом преимущества «Процедуры» заканчиваются. Семантика этой морально устаревшей нотации не позволяет удобно моделировать сколько-нибудь сложные ситуации, которые возможны в реальных бизнес-процессах. В «Процедуре» нет логических операторов (кроме «ромба»). Нельзя использовать промежуточные события. Нет значков документов. Имитация в нотации «Процедура» работает некорректно. Это значит, что невозможно адекватно анализировать процесс и обосновывать решения по его оптимизации. Так же следует отметить, что из «Процедуры» невозможен корректный экспорт в BPM-системы для последующей автоматизации.
Нотация eEPC
На рис. 2. представлен пример диаграммы процесса в нотации eEPC. Это тот же процесс, который был описан в «Процедуре» выше.
Особенностью нотации eEPC является использование событий до и после каждой операции процесса, наличие логических операторов и визуальное представление потоков документов (информации) на схеме. Рассмотрим преимущества и недостатки нотации eEPC.
Преимущества:
• простота и понятность для исполнителей;
• возможность отображения потока объектов (документов) со статусами;
• адекватное межпроцессное взаимодействие (процессные интерфейсы);
• возможность корректной имитации.
Недостатки:
• ресурсоемка при моделировании + размер диаграммы;
• ограниченная семантика;
• отсутствуют дорожки;
• устарела с точки зрения автоматизации.
Диаграммы в нотации eEPC всегда занимают намного больше места, чем диаграммы в нотациях «Процедура» и BPMN. Кроме того, моделирование в eEPC занимает в несколько раз больше времени, чем в других нотациях.
Нотация eEPC имеет весьма ограниченную семантику. Это приводит к тому, что для сложных практических случаев приходится искать обходные пути для того, чтобы показать нужные аспекты на диаграмме.
В тоже время диаграмма в нотации eEPC является вполне понятной большинству сотрудников. На ней можно отобразить потоки документов, причем со статусами. Можно использовать значок процессного интерфейса для интеграции с другими диаграммами в рамках общей модели компании.
Важным плюсом нотации eEPC является возможность корректной имитации процессов. Полученные расчеты можно использовать для анализа процесса и обоснования действия по его оптимизации.
В целом, конечно, нотация eEPC, как и «Процедура», безнадежно устарела. Особенно с точки зрения использования моделей процессов для настройки BPM-систем.
Нотация BPMN
На рис. 3. представлена схема процесса в нотации BPMN.
Это тот же самый процесс, который был представлен выше в нотациях «Процедура» и eEPC.
Рассмотрим преимущества и недостатки нотации BPMN вообще, и с точки зрения моделирования процессов в Business Studio, в частности.
Преимущества:
• международный стандарт ISO с 2013 года;
• «де факто» принята всеми разработчиками BPMS;
• семантика, позволяющая описывать сложные практические ситуации;
• возможность отображения потока объектов (документов) со статусами;
• возможность импорта диаграмм из MS Visio;
• возможность экспорта для автоматизации в BPMS.
Недостатки:
• сложная семантика;
• неадекватное межпроцессное взаимодействие в части информационных потоков (задача решается);
• не вся семантика BPMN поддерживается при имитационном моделировании.
Безусловно, нотация BPMN на сегодня обладает наиболее сложной и развитой семантикой, позволяющей описывать процессы с учетом их реальной специфики. Она является международным стандартом с 2013 года и «де факто» принята большинством вендоров (разработчиков) систем автоматизации бизнес-процессов (BPMS).
На схеме в нотации BPMN можно использовать события и логические операторы (в т.ч. весьма сложные). С точки зрения использования человеком, схему можно сделать нагляднее за счет визуализации движения документов со статусами.
В Business Studio можно импортировать схемы процессов в нотации BPMN, разработанные в MS Visio. Из Business Studio возможен экспорт моделей для настройки исполняемых процессов в BPMS.
Недостатком нотации BPMN можно считать весьма сложную семантику, интуитивно непонятную сотрудникам подразделений без специального обучения. Однако, при использовании ограниченного количество маркеров (событий, шлюзов, операций) можно сделать диаграмму в нотации BPMN вполне читаемой и понятной.
В текущей версии Business Studio проблемой является интеграция моделей процессов в нотации BPMN между собой и с моделями вышестоящего уровня (в IDEF0). Стыковку моделей между собой по входам/выходам и синхронизацию по событиям приходится делать исключительно вручную без какой-либо автоматизации. Это ведет к риску потери важной информации и дезинтеграции модели. Возможно, в следующих версиях Business Studio эта проблема будет решена.
Отдельно стоит подчеркнуть, что нотация BPMN, реализованная в текущей версии Business Studio, позволяет достаточно корректно (с точки зрения реальных практических кейсов) выполнять имитацию процессов. Более того, можно использовать граничные события типа «Системная ошибка» и другие в рамках имитации. Так же можно имитировать прерывание операции процесса по граничному событию-таймеру (правда, для этого приходится пока создавать несколько искусственную конструкцию на схеме соответствующего подпроцесса).
Попробуем сравнить рассматриваемые нотации по набору критериев.
Сравнительный анализ нотаций
Сравнение нотаций можно сделать по трем группам критериев:
- Внешний вид диаграмм.
- Интеграция.
- Семантика и имитация.
В следующей таблице 1 представлено сравнение по группе критериев «Внешний вид диаграмм». Максимальный балл -10.
В таблице 2 представлена оценка нотаций по критерию «Интеграция».
В таблице 3 представлено сравнение нотаций по группе критериев «Семантика и интеграция».
Выводы
Итоговая оценка нотаций в баллах представлена на следующей диаграмме:
Диаграмма. Итоговая оценка нотаций в баллах.
По совокупности критериев, я рекомендую использовать нотацию BPMN для описания, анализа и регламентации бизнес-процессов на операционном уровне. На сегодня — BPMN – лучшая нотация!
Если, всё-таки, по каким-то причинам вам придется делать выбор между «Процедурой» и eEPC, и если не нужна имитация, то лучшим выбором станет нотация «Процедура». Но если предполагается серьезно заниматься имитацией процессов, то лучше выбрать нотацию eEPC, чем «Процедуру».
Успехов вам при описании и оптимизации бизнес-процессов!
В.В. Репин,
к.т.н., доцент, консультант по управлению, тренер,
Генеральный директор ООО «Владимир Репин Менеджмент»
Январь 2019 г.
Использование имитационной модели процесса в Business Studio для анализа и обоснования проекта оптимизации
Использование имитационной модели процесса в Business Studio для анализа и обоснования проекта оптимизации
В статье представлены результаты имитационного моделирования процесса «Рассмотрение и согласование оперативных заявок» в среде Business Studio. Выполнен анализ процесса «как есть». Определены направления оптимизации процесса. Разработана модель «как должно быть». Путем имитации процесса определен потенциальный экономический эффект от возможного проекта оптимизации, в т.ч. за счет автоматизации в BPMS. Статья может быть интересна специалистам в области организационного развития, использующим модели процессов в нотации BPMN в среде Business Studio.
Введение
В рамках проектов оптимизации необходимо не только представить заказчику целевую графическую диаграмму процесса, но и выполнить определенный расчет при помощи модели. Такой расчет дает возможность обосновать экономический эффект и снизить неопределенность в принятии решений.
Измерение – это совокупность снижающих неопределенность наблюдений. И если учесть тот факт, что многие решения, например стоит ли внедрять новую ИС, принимаются компаниями в условиях неопределенности, то даже незначительное ее снижение способствует более удачному выбору.
Проводя имитационное моделирование бизнес-процесса, мы снижаем неопределенность в части трудоемкости процесса, его оптимальности, вариативности. Можем боле объективно судить о способах его оптимизации, особенно выходя на автоматизацию.
В данной статье рассматривается имитационная модель реального процесса «Рассмотрение и согласование оперативных заявок». крупной промышленной компании. Используемый инструмент имитационного моделировании – Business Studio 4.2.
Заявки на вывод в ремонт оборудования подаются с целью предварительной проработки возможности вывода в ремонт, в т.ч. с учетом:
• режима работы оборудования;
• текущей схемы;
• ранее разрешенных заявок;
• совмещения работ различных подразделений на данном и смежном оборудовании.
Цель процесса – эффективное управление оборудованием за счет обоснованного, корректного и оперативного вывода в ремонт. Формально, результат процесса – это согласованная, утвержденная заявка, внесённая в сменное задание.
Автоматизация процесса практически отсутствует.
Цель анализа модели состояла в определении и обосновании путей оптимизации процесса путем расчета средней длительности (одного экземпляра процесса) и суммарных затрат на выполнение процесса за месяц. Результаты имитационного моделирования и анализа представлены ниже.
Исходная модель процесса для анализа «как есть» (80% заявок, поступающих в процесс, содержат ошибки).
Диаграмма процесса «как есть» представлена на рис.1. Участниками процесса являются:
• Инициатор подачи заявки.
• Оперативный персонал, в оперативном ведении у которого находится оборудование.
• Технический руководитель объекта.
• Оперативный персонал, в оперативном управлении у которого находится оборудование.
Стоимость рабочего времени указанных ресурсов была определена. Так, например, стоимость одного человека-часа инициатора подачи заявки составляет 212 рублей в час.
На рис. 2 показана интенсивность запуска процесса (нагрузка на процесс). В месяц поступает около 1200 оперативных заявок на обработку. Фактически, заявки могут готовиться в любое время, но процесс запускается только в период с 16 до 18-00 ежедневно. В другое время заявки просто не рассматриваются.
На схеме процесса показано время выполнения каждой операции. Например, для операции «Рассмотреть и согласовать заявку (совместимость)» сверху указано «Норм.Константа (0:05:00)». Это означает, что нормативное время выполнения данной операции составляет 5 минут. Там, где снизу операции написано «Ож.Константа…» это означает время ожидания выполнения из-за, например, отсутствия ресурса и проч.
Обратим внимание, что время выполнения первой операции процесса «Оформить оперативную заявку» не является константой. Около 64% всех заявок оформляется 5 минут. В 27% случаев необходимо собирать данные для заявки, а это занимает 15 минут. В 9% случаев сбор данных занимает 20 минут.
Такое дискретное распределение было выбрано, т.к. реальный закон распределения времени формирования заявок неизвестен, учета нет. Со слов экспертов по процессу «в 20-30% случаев заявка формируется 15-20 минут из-за необходимости сбора данных». Довольно неточное определение, к сожалению.
На схеме процесса (см. рис. 1) красным цветом показана вероятность перехода по соответствующим стрелкам после шлюзов. Так, например, переход по стрелке «да» после шлюза «Имеются критичные ошибки в заявке?» будет осуществляться с вероятностью 80% и т.п.
Имитация процесса проводилась для одного месяца – ноября 2018 г. По результатам имитации получены следующие данные:
• среднее время выполнения одного экземпляра процесса — 2 часа 40 минут;
• суммарная стоимость процесса за месяц – 128 тыс. рублей.
Анализ отчета по результатам имитации, сгенерированного Business Studio, показывает, что самая дорогая операция в рамках одного экземпляра процесса – это операция «Оформить оперативную заявку». Она стоит 32 рубля.
Измененная схема процесса — 10% заявок с ошибками.
В первом варианте модели 80% заявок поступают с ошибками. Это приводят к тому, что процесс практически сразу завершается неудовлетворительным результатом (отказом от обработки заявки), т.е. фактически работает вхолостую. Возможно, в действительности это не совсем так, но со слов участников всё выглядит именно таким образом.
Было принято решение выполнить имитацию для случая полной загрузки процесса — когда только 10% заявок имеют критические ошибки (требуется их переделка). Кстати, устранение ошибок при оформлении заявок – это первое необходимое действие по оптимизации процесса.
По результатам имитации для случая с 10% ошибочных заявок получены следующие данные:
• среднее время выполнения одного экземпляра процесса – 1 день и 6 часов (!);
• суммарная стоимость процесса за месяц – 320 тыс. рублей.
Видно, что поскольку процесс работает «в полную силу», во время имитации периодически возникает очередь на обработку заявок. Иногда длинна этой очереди достигает 10 часов. Если бы все заявки были корректными и не отклонялись, реальный процесс сразу бы стал нежизнеспособным (сотрудники «разгребали» бы заявки почти целый рабочий день и более).
Оптимизация процесса
Итак, какие же проблемы можно отметить в результате имитации процесса. Прежде всего это:
• ошибки при формировании заявок и долгий (относительно) поиск данных для их заполнения;
• 47% операций процесса – это операции типа «Передать» или «Получить, которые не добавляют никакой ценности (ни с точки зрения инициатора, ни с точки зрения компании);
• практически полностью ручной труд, ручная передача информации, риск ошибок (человеческий фактор);
• ключевые операции процесса не автоматизированы (сбор данных и выполнение расчетов выполняются вручную);
• данные, необходимые для выполнения процесса, дезинтегрированы (находятся в разных базах данных и программных продуктах, на бумаге);
• внутри процесса возникают (неоправданные) задержки.
На рис. 4 визуально показаны некоторые предложения по оптимизации процесса путем автоматизации и устранения операций, не добавляющих ценность.
Полный список предложений следующий:
• заполнение заявок должно выполняться без ошибок и без ожидания данных (данные должны быть доступны в функциональной информационной системе);
• необходимо сокращение времени формирования заявок до 3 минут в 80% случаев;
• необходимо устранить операции типа «Передать» и «Получить»;
• необходима автоматизация самого процесса в системе класса BPM (Business Process Management);
• ряд операций необходимо сделать полностью автоматическими, например, «Сформировать/Внести заявку в сменное задание»;
• требуется создание единой базы данных в рамках функциональной ИС по управлению работой и обслуживанием оборудования;
• для всех операций необходимо сокращение времени выполнения операций за счет автоматизации.
С учетом сформулированных выше предложений по оптимизации была сформирована следующая схема процесса (см. рис. 5). Нас схеме показаны зеленые значки – ИС – функциональная информационная система, поддерживающая выполнение процесса. Оранжевые значки – BPMS, в которой реализован процесс. Значок человечка в левом верхнем углу операции означает, что она выполняется с использование экранных форм BPMS. Значок шестеренки означает, что операция выполняется полностью автоматически информационными системами.
По результатам имитации оптимизированного процесса получены следующие данные:
• среднее время выполнения одного экземпляра процесса – 1 час 34 минуты;
• суммарная стоимость процесса за месяц – 106 тыс. рублей.
Кстати, после оптимизации процесса операция «Оформить оперативную заявку» перестала быть самой дорогой…
Выводы по результатам имитационного моделирования процесса
В следующей таблице показано сравнение двух вариантов: «нагруженного» корректными заявками процесса «как есть» и процесса после оптимизации.
Таблица. Сравнение процессов «как есть» и «как должно быть».
№ | Процесс | Средняя длительность одного экземпляра процесса | Стоимость процесса за год |
1 | Процесс «как есть» | 1 800 минут | 3,84 млн. рублей |
2 | Процесс «как должно быть» | 94 минуты | 1,27 млн. рублей |
Улучшение процесса | Сокращение длительности в 19 раз | Сокращение затрат на 67%, 2,57 млн. рублей |
Таким образом, потенциальный годовой эффект от оптимизации процесса «Рассмотрение и согласование оперативных заявок» может составит 2,57 млн. рублей.
Если предположить, что автоматизация этого процесса в BPMS (включая стоимость лицензий и настройку) одновременно с автоматизацией в функциональной информационной системе составит 300 тыс. рублей (процесс, в общем-то, простой), то эффективность такого проекта составит 856%. Даже если взять в расчет риски ошибок в расчетах и увеличения стоимости работ по проекту, эффект все равно может быть достаточно велик.
Однако, это эффект может остаться на бумаге в том случае, если не произойдет:
• увеличение объемов добычи при сохранении численности обслуживающих подразделений;
• сохранения объемов добычи при сокращении численности обслуживающих подразделений.
Речь идет от том, бумажный эффект может стать реальным в случае, если сотрудники будут использовать высвобожденное за счет оптимизации процесса время на выполнение другой полезной работы, либо высвобожденная численность сотрудников будет сокращена.
В.В. Репин,
к.т.н., доцент, консультант по управлению, тренер,
Генеральный директор ООО «Владимир Репин Менеджмент»
Ю.А. Федосеев
Начальник отдела оптимизации бизнес-процессов и стандартизации
ООО «ИНК»
А.Э. Мельникова
Ведущий специалист по стандартизации отдела оптимизации бизнес-процессов и стандартизации
ООО «ИНК»
Декабрь 2018 г.
Добавить комментарий Отменить ответ
Деловая игра «Процессный пазл»
Деловая игра «Процессный пазл»
В статье Владимира Репина рассматривается деловая игра «Процессный пазл», предназначенная для наглядной иллюстрации разницы между функциональным и процессным подходом к управлению, мотивирования руководителей компании на внедрение системы процессного управления.
Введение
Многие руководители и специалисты в области орг. развития сталкиваются с задачей, как быстро и наглядно объяснить собственникам и топ-менеджерам разницу между функциональным и процессным управлением, показать преимущества процессного управления и обсудить ключевые решения, которые нужно принять для его внедрения в компании.
Игровой способ подачи информации является одним из наиболее эффективных, особенно для людей, перегруженных работой. Они могут на время отвлечься от проблем и заняться принятием решений в легкой игровой манере, пробуя различные возможные варианты.
Автором статьи была разработана и опробована на практике игра для руководителей под названием «Процессный пазл». Цель игры – наглядная практическая иллюстрация преимуществ процессного управления и обсуждение ключевых управленческих решений, которые необходимо принять в случае его внедрения в компании.
Исходные условия
Для игры используются заранее заготовленные карточки с бизнес-процессами некоторой компании. По условиям задачи эта организация производит и продает оптом чайники. По заявкам клиентов в конструкцию чайников могут вноситься изменения. Необходимо изменение технологии производства, поиск новых поставщиков сырья и т.п.
Организационная структура компании представлена на рис. 1.
В каждом структурном подразделении и для руководителей верхнего уровня определены «функциональные процессы». Это процессы, которые от начала до конца выполняются в рамках структурного подразделения под полным контролем его руководителя. И это не абстрактно сформулированные функции, например, «Маркетинг» или «Производить продукцию», а вполне четкие процессы с реальными входами и выходами. Но они локализованы внутри подразделений и не являются сквозными или, другим словами, – межфункциональными.
Большинство процессов на схеме рис. 2 приблизительного одного масштаба. Но некоторые из них явно являются процессами следующего уровня декомпозиции (предупреждать игроков об этом не нужно).
Есть один процесс, который явно не вписывается в традиционный функционал подразделения. Этот процесс основан на реальном примере из практики и включен специально, чтобы проиллюстрировать тот факт, что «функциональные процессы» могут быть довольно странными и находиться в явно неподходящих для них структурных подразделениях. Уверен, что читатель сам легко найдет этот процесс среди прочих.
Еще есть некоторые процессы, которые начинаются со слова «Участие…». В ряде случаев, эти процессы просто некорректно выделены со слов сотрудников, для которых они по каким-то причинам субъективно важны.
Кстати, для зарегистрированных пользователей портала FineXpert.ru доступен файл MS Visio со всеми представленными в статье схемами.
На рис. 3 показан пример оформления карточек с функциональными процессами. Карточки нужно распечатать и вырезать – для этого служит пунктирная линия. Так же нужно распечатать несколько пустых карточек, которые понадобятся во время игры.
Порядок игры
Количество участников игры – от 3 до 6-8 человек (если участников больше, то целесообразно подготовить два комплекта карточек). Целесообразно сдвинуть 4 стола, чтобы удобно было раскладывать карточки. Если в компании есть плоттер, то можно заранее распечатать схему, представленную рис. 2. Если нет, то достаточно просто распечатать схему орг. структуры (3-4 шт.).
Сценарий деловой игры «Процессный пазл»:
- Подготовить карточки, схемы и рабочие столы.
- Создать рабочие группы по 6-8 руководителей.
- Кратко рассказать кейс («компания производит чайники», функциональные процессы), раздать карточки (предварительно перемешав их, как карты). Если играют топ-менеджеры крупной компании, то карточки можно предварительно разложить по функциональным подразделениям для экономии времени. Но это делать нежелательно. Первичное раскладывание карточек нужно для первого знакомства с компанией. Обязательно нужно сказать, что реструктуризация компании не предполагается, т.е. нельзя менять схему орг. структуры.
- Задание № 1. Необходимо разложить карточки с процессами по функциональной принадлежности, в т.ч. для руководителей верхнего уровня (10-12 минут).
- Задание № 2. В группе создать две подгруппы по 3-4 человека.
a. Задание для подгруппы № 1 – собрать пазл – сквозной процесс «Подготовка технико-коммерческого предложения для клиента». Можно слегка намекнуть на возможные границы этого процесса, но не делать всю работу за участников.
b. Задание для подгруппы № 2 — собрать пазл – сквозной процесс «Разработка нового изделия (от идеи до постановки на производство»).
c. Объявить для всех, что если кому-то потребуется карточка, но она уже занята другой группой, то можно взять пустую карточку и написать на ней необходимое название (такое же, как на существующей карточке!). - По факту готовности сквозных процессов:
a. сфотографировать выложенные группами «пазлы»;
b. вывести фото с пазлами на большой экран (через проектор); если группа одна, то можно обсуждать результаты работы прямо на рабочем столе;
c. группы докладывают результаты сборки сквозных процессов из функциональных процессов;
d. ведущий находит несоответствия в сквозных процессах, удаляя ненужные или добавляя нужные процессы, объясняет допущенные ошибки. - Подведение итогов игры.
Ниже на фото показано, как это всё выглядит «в живую» во время игры.
Кроме указанных выше двух сквозных процессов с использованием карточек можно выложить еще несколько сквозных процессов, например, «Согласование договора».
На следующем фото представлен результат сборки сквозного процесса «Подготовка технико-коммерческого предложения для клиента». Это один из возможных вариантов. Участники должны увидеть, что процесс выполняется в нескольких функциональных подразделениях компании.
Для тех топ-менеджеров, которые много читали западных авторов и полагают, что в компании легко определить единый сквозной процесс от «Заказа до оплаты отгруженного товара», можно поставить задачу собрать этот сквозной процесс. В случае удачной выкладки (можно дать группе 15 минут) целесообразно задать вопрос о том, кто и каким образом будет управлять таким длинным процессом, и как исполнители процесса будут распределены по функциональным подразделениям. Возможно, кто-то предложит плоскую «бирюзовую» орг. структуру. Впрочем, данная игра, на мой взгляд, не имеет целью убедить руководителей в необходимости радикально изменять структуру, и уж тем более, создавать супер-мега сквозные бизнес-процессы.
В качестве опции, после выкладки сквозных процессов можно предложить участникам игры сделать еще следующее:
- выложить еще несколько ключевых сквозных бизнес-процессов компании;
- определить, какие процессы являются чисто функциональными, и не вошли ни в один сквозной процесс (можно пометить карточки с такими процессами красными стикерами);
- определить, какие процессы не соответствуют по уровню остальным (слишком детальные);
- определить, какие процессы (даже функциональные!) вовсе не являются процессами и выделены вследствие субъективного видения руководителей компании;
- предложить разработать систему целей и показателей для управления сквозными процессами;
- предложить продумать возможные направления изменения организационной структуры компании.
По итогам проведения игры важно, на мой взгляд, обсудить с участниками следующие ключевые моменты:
- обсудить понятие границ процесса (по входам/выходам и условиям старта и завершения процесса (необходимо объяснить понятие событий разного типа);
- обсудить понятие уровня декомпозиции; затронуть наличие в пазле неадекватных процессов (типа «Участие в ….» и т.п.).
- отметить момент, что некоторые функциональные процессы могут быть многократно использованы в нескольких сквозных процессах в связи с чем возможен конфликт по ресурсам;
- обсудить, кто из руководителей в этом учебном примере может стать владельцем сквозного процесса; отметить подробно проблемы в определении ответственности и полномочий владельцев процессов;
- обсудить ключевые решения, которые должны принять топ-менеджеры для практического внедрения процессного управления в организации:
a. определение ключевых сквозных бизнес-процессов;
b. определение владельцев процессов и наделение их реальными полномочиями и ответственностью.
Заключение
Вы можете использовать игру в том виде, как она разработана с существующим набором карточек (см. файл MS Visio). Либо — провести анализ деятельности структурных подразделений вашей компании, выявить функциональные процессы, подготовить новые карточки и организовать игру с учетом вашей специфики. Но делать это нужно аккуратно, четко понимая, какие именно функциональные процессы вы определили (соответствие по уровням), какие «ошибочные» пазлы специально включили в состав карточек.
Сделать всё это вы можете сами силами внутреннего подразделения орг. развития (Процессный офис, отдел СМК) или пригласить автора статьи с его коллегами-консультантами. Мы проводим необходимое количество встреч с руководителями верхнего уровня, определяем функциональные процессы, готовим сценарий и модерируем игру.
Так же можно провести игру в рамках 1-дневного тренинга по процессному управлению для топ-менеджмента.
Автор будет признателен за отзывы по результатам игр, которые вы проведете, а так же за проверенные практикой предложения по дополнению (возможно, изменению) сценария игры.
Успехов при внедрении системы процессного управления!
В.В. Репин,
к.т.н., доцент, консультант по управлению, тренер,
Генеральный директор ООО «Владимир Репин Менеджмент»
Ноябрь 2018 г.
Добавить комментарий Отменить ответ
Базовые понятия процессного управления
Базовые понятия процессного управления
Что понимается под процессным управлением? Чем оно является, а чем – нет? В статье Владимира Репина рассмотрены базовые понятия процессного управления, необходимые для практической работы, а так же семь критериев, которые помогут быстро оценить уровень развития процессного управления в вашей компании.
Введение
Статья написана для тех руководителей, которые сомневаются в необходимости использования практики процессного управления (Business Process Management) в своем функциональном подразделении и компании в целом. Для тех, кто уже использует эти методы, материал может быть полезным с точки зрения систематизации знаний.
В статье я буду использовать рабочее определение процесса, как целенаправленной деятельности, по определенной технологии преобразующей входы в выходы (результаты), представляющие ценность для клиента.
Можно найти множество различных определений процесса. Ряд определений вполне обоснованно можно критиковать. Но я буду использовать именно это определение.
Если в вашей компании никто еще не говорит о процессном управлении, то вы можете начать его использовать в рамках своего функционального подразделения, независимо от каких-то глобальных инициатив или проектов руководства. Для этого нужно просто определить процессы, которые на 100% находятся в зоне вашего контроля, и начать ими управлять.
Большего эффекта можно достигнуть от изменения сквозных (межфункциональных) процессов организации. Для того, чтобы начать с ними работать, нужно желание топ-менеджеров компании и более сложный методический поход.
Начнем с простых вопросов и рассмотрим более подробно, что же представляет собой процесс, как объект управления.
Процесс, как объект управления
На рисунке 1 схематично представлен процесс, как объект управления.
Прежде всего, необходимо установить границы процесса. Для этого нужно определить входы и выходы, а так же условия начала и завершения процесса.
Входы и выходы — это информационные или материальные объекты: файлы с информацией, документы на бумажном носителе, материалы для производства и т.п. Требования к каждому входу/выходу должны быть четко определены (специфицированы) в документах и согласованы со всеми заинтересованными сторонами (с поставщиками и потребителями процесса, руководством вышестоящего уровня и, в некоторых случаях, с государством).
Кроме входов/выходов важно определить условия начала и завершения процесса. Процесс может «запускаться» в определенное время («по таймеру») или при получении управляющего сообщения (например, устного распоряжения руководителя). Наличие готовых (например, сложенных горкой) входов еще не означает, что процесс нужно запускать. Так же необходимо четко определить условия завершения процесса, т.е. в каких случаях можно считать, что процесс завершен. Например, документы переданы, товар упакован и помещен на место хранения, клиент подтвердил получение документа и т.п. Опять же, условия завершения не являются выходами процесса. Не надо путать.
На рис. 1. показано, что процесс выполняется по определенной технологии. По сути, это продуманный алгоритм выполнения последовательности действий, приводящий к получению результата с заданными, повторяющимися характеристиками. Для практического выполнения этого алгоритма нужны ресурсы – люди, оборудование, информационные системы и проч. Они связаны между собой в том смысле, что отсутствие необходимого оборудования или людей повлечет за собой изменение алгоритма работы. Наоборот, цель изменения (оптимизации) процесса может повлечь за собой изменения в требованиях к ресурсам.
Технология выполнения процесса хранится, как минимум, в виде знаний и навыков в головах сотрудников, которые его выполняют. Как правило, знания о технологии выполнения процесса фиксируют в регламентах (положениях, инструкциях). Кроме того, требования к выполнению процесса могут быть «зашиты» в информационные системы, которые используются для автоматизации процесса.
Слева на рис. 1. Слева показан график нагрузки на процесс. Входы, которые нужно обрабатывать, поступают в процесс с определенной интенсивностью в течение определенного времени. Например, необходимо обрабатывать партию из 5 деталей каждые 2 минуты. В этом случае график нагрузки будет дискретным – с равномерным интервалом. Другой пример – суточный график количества посетителей для супермаркета. Поскольку посетителей много, то график будет практически непрерывным и на нем будут видны периоды пиковой нагрузки.
Итак, нагрузка на процесс – это количество входов, которое нужно обработать за единицу времени. Однако, возможности процесса ограничены, в первую очередь, по ресурсам. Используемая технология выполнения процесса и ресурсы (оборудование, люди) определяют производительность процесса – возможность преобразовывать определенное количество входов в выходы за единицу времени. На рис. 1 снизу показан график производительности процесса. На нем видны ступеньки. Это может быть, например, из-за того, что вводилось/выводилось из эксплуатации оборудование, добавляли людей в рабочие смены и т.п.
Что будет со входами, которые процесс не в состоянии пропустить через себя из-за ограничений по производительности? Они встанут в очередь – см. соответствующий график на рис. 1. (если, конечно, им не расхочется быть преобразованными в этом процессе – например, когда вы стоите в очереди на кассу и вдруг решаете, что не будете больше стоять).
С учетом нагрузки на процесс и его производительности мы получаем график выходов (результатов) процесса. На рис. 2 показан пример, показывающий, как связаны входы, производительность, очередь и выходы процесса (при условии, что нет брака). По горизонтальной шкале показы часы суток. По вертикальной – количество единиц (входы и т.п.).
На рис. 1 над процессом показаны цели и показатели, а так же владелец процесса. Цели и показатели нужны для управления процессом. Производительность является одним из ключевых показателей. Кроме нее, важно измерять план/факт по количеству выходов процесса, эффективность (отношение результата к затраченным на его получение ресурсам), показатели качества (например, уровень дефектов в выходах процесса). Для организации, как системы ориентированной на достижение целей во внешней среде, важно не просто преобразовывать входы в выходы, а делать это эффективно, т.е. с прибылью для себя. Это означает, что крайне важно измерять и улучшать показатели эффективности процесса.
Владелец процесса – это руководитель, который полностью отвечает за весь процесс – от начала до конца. Ему подчиняются все ресурсы процесса. Но вот цели процесса и показатели, по которым он управляется, владелец процесса сам себе ставить не может. Это должны делать руководители вышестоящего уровня, которые понимают роль этого процесса в общей системе работы организации и в состоянии правильно установить цели и выбрать показатели для измерения степени их достижения (на практике с этим всем часто бывают проблемы).
Если процесс целиком проходит внутри функционального подразделения, то проблем с выбором владельца процесса нет – это руководитель подразделения, либо сотрудник, которому делегированы соответствующие полномочия (заместитель, ведущий специалист).
Если процесс сквозной, то задача существенно усложняется. Нужно формулировать правила определения владельца процесса, определять его ответственность и полномочия.
Важно отметить, что если руководителя назвали владельцем процесса, но при этом он ничем не рискует (премией, зарплатой, должностью), то это вовсе не владелец, а просто его имитация.
Управление процессами в масштабах организации начинается тогда, когда ключевые сквозные процессы получили своих владельцев и эти владельцы начали что-то реально изменять, сокращая затраты, повышая производительность и качество работы, удовлетворенность клиентов сквозных процессов. В противном случае говорить, что в компании «внедрено процессное управление» нельзя. Никто никакими процессами не управляет. В лучшем случае, внедрено «описание процессов» в какой-то там среде моделирования (на сегодня, большая часть такого софта – «рисовалки», по большому счету).
Отдельная история – это автоматизация сквозных процессов. Условно говоря, она может быть функциональная и процессная. При функциональной автоматизации «процессное управление» не наступает, т.к. мы имеем те же раздробленные по подразделениям небольшие функциональные процессы, только автоматизированные в какой-то системе.
При процессной автоматизации (в BPMS или СЭД) процессное управление так же может не наступить в случае, если за администрирование процесса в информационной системе отвечает технический специалист, но владелец сквозного процесса не назначен (или ничего реально не делает с точки зрения управления и развития процесса).
Еще раз, я утверждаю, что ключевым критерием внедрения «процессного управления» является наличие системы управления и развития сквозными процессами. Как минимум, это означает, что в организации есть реально работающие владельцы процессов. Причем они могут это делать без автоматизации в BPMS или СЭД, хотя «на коленках» управлять процессами гораздо сложнее.
Работа с локальным процессами функциональных подразделений имеет смысл и может принести положительные практические результаты. Но значительные системные эффекты возможны только при оптимизации сквозных процессов, так как большая часть проблем возникает из-за раздробленности процесса на небольшие функциональные кусочки и потери синергии от взаимодействия участников. Проще говоря, функциональные колодцы «рвут» процессы по живому, что приводит к росту затрат, увеличению длительность выполнения и снижению качества результатов работы в масштабах компании.
Как же можно понять, в какой степени в вашей организации используется практика управления процессами на межфункциональном уровне? Можно предложить ряд простых критериев для оценки.
Семь критериев оценки уровни развития процессного управления
Существует большое количество методов оценки уровня процессной зрелости организации. Часть из них даже утверждены как стандарты. Однако, все они достаточно сложны и весьма теоретичны, что делает невозможным их быстрое практическое применение.
Ниже представлена таблица с семью критериями, по которым можно быстро и достаточно легко оценить уровень развития существующей в вашей организации практики управления бизнес-процессами. Данные критерии сформулированы на основании моего практического опыта внедрения процессного подхода к управлению.
По каждому критерию сформулированы характеристики «левой» и «правой» части шкалы оценки. Если таблица будет понятна, то вы сможете сформулировать характеристики для промежуточных «делений шкалы» и оценить «уровень зрелости процессного управления» в вашей компании.
Таблица. Критерии оценки уровня развития процессного управления
№ | Критерий | Левый край шкалы | Правый край шкалы |
1 | Бизнес-процесс, как объект управления | Сквозные процессы не определены. Руководители подразделений управляют своими локальными, функциональными процессами. | Определены ключевые сквозные процессы организации. Для каждого процесса назначен владелец процесса. Ответственность и полномочия владельца процесса четко определены. |
2 | Цели и показатели для управления бизнес-процессом | Показателей для процессов практически нет. Считаются только показатели структурных единиц (подразделения, сотрудники). | Полный набор показателей для комплексной оценки сквозных процессов. Ряд показателей используется в качестве KPI для стимулирования владельца процесса и участников процесса. |
3 | Технология выполнения бизнес-процесса | В основном, в головах участников. Частично – в регламентах (положениях, инструкциях). | Полностью актуальная информация о технологии в регламентах сквозных процессов (в т.ч. в гипертекстовом виде), многие требования «зашиты» в BPMS, СЭД |
4 | Внедрение изменений в бизнес-процессе | Не системно, время от времени | Системное, целенаправленное развитие на основе понимания жизненного цикла процесса |
5 | Вовлеченность руководителей в управление процессами | Практически отсутствует. | Руководители активно участвует в управлении и развитии сквозных процессов. |
6 | Процессная интеграция в компании | В разных частях системы управления практикуются различные походы к работе с процессами. Единой архитектуры процессов нет. | Есть архитектура бизнес-процессов компании. Все инициативы и проекты (в т.ч. автоматизация) синхронизируются на единой процессной платформе организации. |
7 | Цифровой образ бизнес-процесса | Отсутствует. | Ключевые сквозные процессы имеют цифровые образы в информационной системе. |
Заключение
Методы процессного управления можно применять в рамках функционального подразделения, но наибольший эффект можно получить при управлении сквозными бизнес-процессами.
Степень развития методов процессного управления может быть разной. Существует множество методик оценки. Можно быстро оценить степень развития процессного управления по семи критериям, предложенным в данной статье.
Вовлечение руководителей в практику работы с процессами является первым важным шагом на пути изменения системы управления компании с ориентацией ее на сквозные бизнес-процессы и клиентов.
Обучение руководителей путем проведения различного рода деловых игр, например, игры на определение границ и структуры сквозных бизнес-процессов компании «Процессный пазл», может стать хорошей отправной точкой для внедрения процессного управления в организации.
В.В. Репин,
к.т.н., доцент, консультант по управлению, тренер,
Генеральный директор ООО «Владимир Репин Менеджмент»
Ноябрь 2018 г.
Добавить комментарий Отменить ответ
И снова о SADT: в чем были неправы Марка и МакГоуэн?
И снова о SADT: в чем были неправы Марка и МакГоуэн?
В статье Владимира Репина рассмотрены недостатки методологии SADT с точки зрения создания инженерной модели бизнеса (ИМБ). Сформулированы новые правила использования SADT, позволяющие создать такую модель. Статья адресована специалистам, которые разрабатывают архитектуру бизнес-процессов своих компаний с использованием нотации IDEF0 в инструменте Business Studio (и не только).
Введение
Более 15 лет назад, когда IDS Sheer вывел на рынок методологию ARIS, для моделирования процессов верхнего уровня в ней использовалась нотация VAD (Value Added Chain – цепочка создания ценности). Маркетологи, продвигавшие ARIS, заявляли, что нотация IDEF0 (SADT) безнадежно устарела, т.к. представляла собой «функциональный взгляд на организацию», а VAD – «процессный взгляд»… Они были неправы. Сегодня становится очевидно, что скорее умрет VAD в том виде, как он реализован в ARIS. Это просто набор значков, по сути, представляющий собой субъективное видение реестра бизнес-процессов компании. Вокруг выбора состава этих значков много шаманства с бубном (типа разделения процессов на основные и вспомогательные и т.п.), но инженерного подхода там точно нет.
Практически единственной и, казалось бы, доступной (в силу своей кажущейся простоты) методологией построения моделей сложных систем является SADT (Structured Analysis & Design Technique), на основе которой в 1963 году был создан американский стандарт IDEF0 (разрешен в России в виде РД IDEF0 – 2000).
Классической книгой по SADT до сих пор считается книга Дэвида А. Марки и Клемента МакГоуэна с предисловием Дугласа Т. Росса «Методология структурного анализа и проектирования». Ниже в статье я буду цитировать авторов этого фундаментального труда (другого такого же на русском языке не издавалось).
Речь пойдет о моделировании сложных систем. И вот первая цитата (курсив автора статьи):
«Под словом «система» мы понимаем совокупность взаимодействующих компонент и взаимосвязей между ними… Под термином «моделирование» мы понимаем процесс создания точного описания системы. Особенно трудным оказывается описание систем средней сложности, таких, как система коммутаций в телефонных сетях, управление аэровоздушными перевозками или движением подводной лодки, сборка автомобилей, челночные космические рейсы, функционирование перерабатывающих предприятий. С точки зрения человека, эти системы описать достаточно трудно, потому что они настолько велики, что практически невозможно перечислить все их компоненты со своими взаимосвязями… Наша неспособность дать простое описание, а следовательно, и обеспечить понимание таких систем делает их проектирование и создание трудоемким и дорогостоящим процессом и повышает степень их ненадежности. С ростом технического прогресса адекватное описание систем становится все более актуальной проблемой. SADT (аббревиатура выражения Structured Analysis and Design Technique — методология структурного анализа и проектирования) — это методология, разработанная специально для того, чтобы облегчить описание и понимание искусственных систем, попадающих в разряд средней сложности».
Что можно сказать? Крупная организация (от 1000 человек, например) – это сложная система. Разработка комплексной модели бизнес-процессов организации – это создание модели сложной системы.
Приведу простой пример. Владельцы компании приняли решение построить новый завод. Для строительства завода нужна проектно-сметная документация (ПСД) и проч. Без ПСД строить нельзя (если речь не идет о сарае, конечно). Бизнесу это очевидно и он готов платить большие деньги за проект завода: генплан, цеха, дороги, коммуникации, размещение оборудования и т.п. Но вот архитектура бизнес-процессов, которые будут на этом заводе создавать ценность, в этот список не попадает. Бизнес редко готов платить реальные деньги за некий «виртуальный» результат – какой-то там проект архитектуры бизнес-процессов. Вот стены и железки – это другое дело. Их можно потрогать руками, а бизнес-процессы как увидеть? Результаты всем известны – при вводе в эксплуатацию нового завода куча денег (причем незапланированных) уходит на запуск и отладку тех самых бизнес-процессов…
Конечно, есть исключения. К ним относятся полностью роботизированные производства с минимальны количеством персонала. Но такие примеры в России являются пока крайне редкими. Представьте себе завод автомат, где всю работу выполняют роботы, или компанию, где информационная система принимает заказы клиентов и управляет отгрузкой со склада без участия человека? Как там обойтись без бизнес-процессов? Никак. По сути, бизнес-процессы – это и есть те самые алгоритмы, по которым должны работать роботы, информационные системы, беспилотники и т.п., причем активно взаимодействуя между собой.
Убежден, что архитектура бизнес-процессов организации, построенная в виде инженерной модели, основанной на четких правилах и стандартах, является необходимым инструментом для управления современным (в ближайшем будущем – цифровым) бизнесом.
Возникает вопрос, а годится ли методология SADT для построения архитектуры бизнес-процессов организации, как сложной системы? Причем не на уровне красивой презентации «ландшафтной карты процессов» для руководства, а на уровне сложной, комплексной инженерной модели? Обсуждению этого вопроса и посвящена данная статья.
Архитектура бизнес-процессов организации и проблемы ее построения
Итак, цель состоит в построении архитектуры бизнес-процессов компании. Приведу рабочее определение, взятое из одного из проектов:
Архитектура бизнес-процессов — «совокупность взаимосвязанных или взаимодействующих БП компании, представленная в виде иерархического списка и графических моделей в нотациях IDEF0 и BPMN в программном продукте «Х».
Данное определение не раскрывает всей сложности задачи. По факту, построенная архитектура процессов крупной организации это:
• иерархическая модель бизнес-процессов, включающая 5-6 уровней декомпозиции;
• уровни 1-3 (уровень 0 – контекстная диаграмма), местами до 4, описаны в нотации IDEF0;
• уровни 4-6 и ниже описаны в нотации BPMN;
• общее количество «процессов» (разного уровня) на диаграммах 1-6 уровней – 262 144 (если считать по 8 объектов на каждом уровне).
Последняя цифра не должна никого вводить в заблуждение или пугать. Это транзакции -элементарные действия, выполняемые отдельными сотрудниками или информационными системами. Много это или мало? По сравнению с численностью транзисторов на кристалле последней модификации Intel – это очень мало… По сравнению с численностью сотрудников… много? Не факт. Если в вашем холдинге работает 10 тыс. человек, то это всего лишь 26 транзакций на человека. Очевидно, что сотрудник выполняет гораздо больше элементарных действий во время повседневной работы (а значит для полного описания системы нужен еще уровень 7 или, даже 8).
Конечно, глубина описания должна определятся практическими задачами, ключевыми из которых являются:
• утверждение зон ответственности владельцев процессов (руководителей верхнего уровня) за счет определения границ бизнес-процессов (стыковки по входам/выходам);
• определения целей и показателей для управления бизнес-процессами для решения задачи стратегического и оперативного управления (невозможно определить адекватные показатели для процесса, границы которого размыты);
• регламентация бизнес-процессов (причем в виде гипертекстовых документов на web-портале компании);
• автоматизации системы синхронизованных между собой бизнес-процессов (в BPM-приложениях, СЭД);
• архитектурная интеграция различных подсистем управления на основе единой процессной модели (процессы в разных подсистемах и ИС не должны существовать перпендикулярно друг другу);
• создание базы знаний о работе компании, в т.ч. системы стандартизации бизнес-процессов (включая элементы дополненной и виртуальной реальности).
Если же вы хотите создать полную цифровую модель бизнеса (что пока, конечно, утопия), то придется переходить на уровни 7-8. Но в ближайшем будущем, при использовании технологий Big Data, BPM, ERP, MES и искусственного интеллекта такая задача уже не будет казаться утопией…
Многие компании при построении архитектуры ограничиваются иерархическим списком. Это плохо. Комплексная модель со связями и список – это как готовый, собранный автомобиль или куча как попало разложенных на поле его комплектующих.
Модель архитектуры должна быть строгой, инженерной, а не субъективным списком в презентации Power Point, составленным как результат политического консенсуса между руководителями верхнего уровня.
Еще один аспект – это «критерии выделения бизнес-процессов». Так часто формулируют заказчики. Проблема в том, что четких критериев определения бизнес-процессов, которые можно использовать практически… не существует. Проблема в субъективности. Можно предложить ряд критериев, но субъективное представление людей о процессах всё равно останется субъективным. Когда перед вами десять автомобилей с десятью шоферами-экспедиторами – это объективная реальность (можно потрогать). А бизнес-процессы, которые этот парк может выполнять – вещь весьма субъективная хотя бы потому, что договоренность людей о структуре, границах и показателях этих процессов является субъективной.
По моему убеждению, борьба должна идти НЕ за «выделение» процессов (слово-то какое!), а полноту архитектуры бизнес-процессов с точки зрения выполнения всех задач бизнеса. При этом крайне важно четко определить границы каждого процесса и интегрировать его в систему. Границы процессов – это результат договоренности руководителей. Они могут и должны изменяться. Главное – полнота и связность архитектуры бизнес-процессов.
Посмотрите на рис. 1. На нем представлена цифровая модель здания.
Современное здание – это сложная система? Да, безусловно. Можно ли спроектировать здание в виде карандашного эскиза («ландшафтная карта бизнес-процессов»), а потом построить его в металле и бетоне? Очевидно, что нет. Таким образом, для технических систем мы имеем нормальный инженерный подход с 3D-проектированием, а для бизнеса, по сути, профанацию. Нормально ли это?
Кстати, если вы внимательно посмотрите на так называемое «программное обеспечение для моделирования бизнес-процессов» (даже импортное), то увидите там идеологическое отставание функционала, как минимум, на 15-20 лет. Например, ни в одной такой системе невозможно быстро отключить те или иные «слои», чтобы увидеть те аспекты модели, которые интересуют аналитика в данный момент. Или, например, автоматически сформировать диаграмму всех процессов одного уровня со всеми связями между ними, отследить движение конкретного документа через систему или увидеть в виде анимации последовательность запуска процессов в рамках конкретного сценария… (ограниченные возможности такого рода есть в некоторых системах для Process Mining). Создание моделей сложных организационных систем в современном софте для бизнес-моделирования исключительно неудобно и трудоемко!
Но вернемся к перечню требований, которому должна удовлетворять инженерная модель архитектуры бизнес-процессов организации:
- иерархическая модель, включающая связанные между собой схемы бизнес-процессов на 1-7 уровнях (по «горизонтали» и «вертикали»);
- все бизнес-процессы имеют реальные связи (не абстрактно-обобщенные) со всеми другими бизнес-процессами, с которыми они взаимодействуют;
- все связи должны базироваться на потоках реальных объектов (информация, документы, материальные ресурсы), используемых в организации;
- бизнес-процессы должны быть стыкованы по входам/выходам в соответствии со своим уровнем иерархии (процесс нижнего уровня не может быть поставщиком, например, процесса уровня +3);
- бизнес-процессы, описанные в нотации BPMN, должны быть синхронизованы между собой по событиям (там где это необходимо).
Посмотрим, насколько методология SADT годится для построения архитектуры бизнес-процессов организации в виде инженерной модели бизнеса (ИМБ).
Проблемы использования SADT для построения архитектуры бизнес-процессов
Практически ни в одной статье или книге, затрагивающей нотацию IDEF0, вы не найдете примеры моделей хотя бы средней сложности. Как правило, все ограничивается «детскими» примерами 1-2 уровня иерархии, где всё очевидно. Количество блоков ограничено, стрелок мало и т.п. Даже «комплексные модели» в нотации IDEF0, предлагаемые некоторыми поставщиками софта в виде примеров моделирования (демо-модели, лучшие практики), на поверку не выдерживают никакой критики. Это не модели организаций, это муляжи, или лучше сказать, симулякры моделей организаций, как сложных систем.
Вопрос, почему сложилась такая ситуация, сам по себе интересен… К сожалению, у меня нет уверенности, что кто-то когда-то сделал при помощи IDEF0 что-то большое и действительно серьезное… А в статьях можно писать что угодно. Те же Марка и МакГоуэн пишут про использование IDEF0 для проектирования связанных между собой подсистем подводной лодки, но никаких реальных примеров не приводят…
Так какие же особенности SADT делают невозможным создание с ее помощью действительно четкой инженерной модели бизнеса? (Предполагается, что читатель статьи знаком со стандартом IDEF0 и каким-либо программным продуктом, в котором можно формировать диаграммы процессов).
Количество объектов
Во-первых, хотел бы отметить требование по количеству процессов на одной диаграмме. Ограничение SADT – от 3 до 6 объектов. Цитата: «Диаграмма ограничивается 3-6 блоками для того, чтобы детализация осуществлялась постепенно. Вместо одной громоздкой модели используется несколько небольших взаимосвязанных моделей, значения которых взаимно дополняют друг друга, делая понятной структуризацию сложного объекта…».
Но практика создания моделей организации показывает, что 6 – это слишком мало (8-10 – нормально). Если жестко следовать ограничениям SADT, то появляются псевдо-уровни, усложняющие модель без практической необходимости (особенно при использовании в методологии цикла PDCA, рекомендованного РД РФ по IDEF0). Возможно, ограничение в 6 объектов было уместно, когда чертежи делали вручную на кульмане. Но сейчас это требование, на мой взгляд, устарело.
Смысл стрелок на диаграммах
Теперь рассмотрим интерпретацию стрелок на диаграммах SADT. Для начала приведу несколько цитат:
• «Дуги на SADT-диаграмме изображаются одинарными линиями со стрелками на концах. Для функциональных SADT-диаграмм дуга представляет множество объектов…»
• «Таким образом, SADT-диаграммы не являются ни блок-схемами, ни просто диаграммами потоков данных. Это предписывающие диаграммы, представляющие входные-выходные преобразования и указывающие правила этих преобразований . Дуги на них изображают интерфейсы между функциями системы, а также между системой и ее окружающей средой…»
• «Дуга в SADT редко изображает один объект. Обычно она символизирует набор объектов…»
• «…дуги SADT изображают иерархические наборы данных…».
Снимите крышку с системного блока своего компьютера. Что вы там видите? Набор функциональных блоков, связанных шлейфами. Их минимальное количество… Откройте капот вашего автомобиля. Так же картина – почти все провода, управляющие агрегатами, связаны в жгуты и убраны в защитные гофрированные трубки. Почему инженера так поступают? Почему не соединяют устройства напрямую кучей проводков? Потому, что такая система имела бы высокую сложность, крайне низкую надежность и ремонтопригодность. Внутри вашего компьютера был бы огромный, запутанный клубок проводов!
Еще одна цитата: «Представьте себе толстый телефонный кабель. Если вы разрубите его пополам, то увидите, что главный кабель состоит из нескольких меньших кабелей, которые, в свою очередь, состоят из еще меньших кабелей, и т.д. вплоть до отдельных проводов. Дуги SADT могут рассматриваться как кабели, соединяющие, разъединяющие и переносящие многообразие объектов. Вот почему дуги имеют разветвления и соединения…»
Итак, дуга SADT или стрелка на диаграмме IDEF0, например в Business Studio, — это труба по которой движется поток объектов: информация, документы, материальные ресурсы. Еще раз обращаю ваше внимание: «…кабели, соединяющие, разъединяющие и переносящие многообразие объектов..».
Но проблема в том, что SADT допускает соединение двух процессов несколькими стрелками! Это означает, что между двумя железными ящиками с разным функционалом может быть несколько разных кабелей, вместо одного!
Количество стрелок
SADT ограничивает количество стрелок с каждой стороны процесса числом 6. Т.е. я могу провести шесть стрелок от одного процесса к другому. И здесь мы наблюдаем одно из самых методически плохо проработанных мест в SADT. Методом выбора стрелок и их именования является метод… пристального взгляда! Еще одна цитата:
«Иногда можно обнаружить две дуги, которые начинаются и кончаются в одних и тех же местах диаграммы…В этом случае посмотрите на эти две дуги внимательно. Может оказаться, что их следует объединить в одну. Если вы можете придумать хорошее наименование, объединяющее названия этих дуг, объедините их. Если наличие двух дуг имеет определенный смысл, не объединяйте их. Объединение скрывает детали, поэтому не делайте это механически. Исчезновение деталей повредит диаграмме…
Вы можете обнаружить также дугу, описывающую два совершенно различных набора данных. В этом случае изучите дугу, чтобы оценить, приведет ли разделение ее на две к прояснению важных для диаграммы деталей. Будьте очень осторожны и старайтесь сохранить равновесие между стремлением к детализации и сохранением наглядности диаграммы…».
Что-ж, очевидно, что это не методология, а набор довольно сомнительных рекомендаций, которые сразу превращают инженерную работу над моделью в шаманство с бубном.
Те, кто практически участвовал в проекте создания модели крупной организации в IDEF0, знают сколько копий было поломано и нервов потрачено на обсуждение смысла стрелок и их названий. Некоторые участники таких проектов просто пытались перечислять в названии стрелок все объекты, которые по ним перемещаются. Это хотя бы интуитивно понятно, но, конечно, запрещено методологией SADT.
Однонаправленность стрелок
Еще одной «засадой» SADT является тот факт, что стрелки (дуги) являются однонаправленными. Но кабель, соединяющий два блока (процесса), может передавать объекты в двух направлениях (если, конечно, он соответствующим образом сконструирован). В SADT так делать нельзя.
Это приводит к тому, что между двумя взаимодействующими процессами должны быть, как минимум, показаны две стрелки связи. Т.е. наличие однонаправленных стрелок на диаграммах просто удваивает их необходимое для отображения связи количество. Хотя можно было бы просто рисовать у стрелки два наконечника и проблема отображения двусторонней связи была бы решена…
Тоннельные стрелки
Крупнейшая провокация SADT – это тоннельные стрелки. Неопытные пользователи IDEF0 один раз вкусив «прелесть» тоннельных стрелок начинают их использовать даже… на диаграмме А0. В итоге разваливается вся модель.
Как же Марка и МакГоуэн обосновывают наличие тоннельных стрелок в методологии SADT? Вот некоторые цитаты (много, но по делу):
• «Тоннельные дуги, имеющие скрытый приемник, кончаются скобками, чтобы отразить тот факт, что такая дуга идет к какой-то другой части модели или выходит из нее или что она не будет более в этой модели рассматриваться…. Хотя мы неоднократно сталкивались с полезным применением этой методики, советуем применять ее с большой осторожностью. При неправильном использовании она быстро становится прикрытием плохого моделирования. Поэтому мы рекомендуем ее только опытным SADT-аналитикам, да и то редко…»
• «Тоннельные» обозначения были введены в SADT после нескольких лет интенсивного использования этой методологии в ряде областей. Опыт показал, что при описании сложных систем требуется большое число дуг для корректного и подробного представления системы (Прим. автора статьи: т.е. они увидели недостатки методологии SADT, но пошли не по тому пути!).
• «Тоннельные» обозначения используются для того, чтобы избежать хаотического заполнения нежелательными подробностями диаграмм высокого уровня. (Прим. автора статьи: но они же сами писали про необходимость ветвления и слияния дуг!).
• «… мы рекомендуем сначала проводить дуги сквозь границы блоков, а затем определять, в каких случаях это снижает качество описания (Прим. автора статьи: вот только как померить это качество?!). Только после этого можно помещать дуги в тоннели для улучшения читабельности модели…» (Прим. автора статьи: читабельность модели – идеальный критерий, чтобы сделать из инженерной модели симулякр).
Лично я считаю тоннельные стрелки наиболее слабым местом методологии SADT. Последствие их применения – создание модели, которая никакого отношения к инженерному походу не имеет. Однако, например в Business Studio, специально добавлен функционал так называемых «междиаграммных ссылок» (МДС), который делает перемещение между диаграммами, связанными тоннельными стрелками, простым и удобным. Но такая возможность искушает пользователей и они забывают про системность, соединяя блоки системы (процессы на уровнях 3 и 4) напрямую. Вспомните аналогию пука проводов, торчащих из ящика…
Создавать сначала модель объектов, а потом процессов
Приведу еще некоторые важные цитаты:
• «Чем лучше проанализированы объекты системы, тем полнее функциональные диаграммы будут описывать работу системы. Из этого следует, что декомпозиция данных должна начинаться раньше и проводиться согласованно с декомпозицией функций. Хорошая декомпозиция данных является ключом к хорошей декомпозиции функций..».
• «…Вот почему SADT предусматривает дополнительное описание полной иерархии объектов системы посредством формирования глоссария для каждой диаграммы модели и объединения этих глоссариев в Словарь данных. Таким образом, Словарь данных, важное дополнение модели, становится основным хранилищем полной иерархии объектов системы..».
• «Списки объектов системы, создаваемые в ходе моделирования, в SADT принято называть «списками данных»» Термин «данные» здесь употребляется как синоним слова «объект»… Составление списка данных является начальным этапом создания каждой диаграммы функциональной SADT-модели. Правило заключается в том, чтобы вначале составить список данных, а потом список функций…
• «В современных аналитических методах слишком часто уделяется повышенное внимание функциям в ущерб данным. Начиная с составления списка данных, вы сможете избежать перехода к немедленной функциональной декомпозиции. Списки данных помогут выполнить более глубокий анализ и при этом не концентрироваться на функциях системы, избегая пробелов, которые часто возникают из предвзятых представлений о функциональных декомпозициях».
В последней цитате речь идет о крайней субъективности в определении структуры процессов при отсутствии понимания реальных объектов преобразования (информация, документы, материальные ресурсы).
Например, при моделировании в нотации IDEF0 в среде Business Studio многие бизнес-аналитики рисуют стрелки на диаграммах, но вообще не привязывают к ним объекты из справочника «Объекты деятельности». В результате модель оказывается крайне субъективной и оторванной от реальности.
Исключение составляет ситуация, когда сначала создают документ в справочнике «Объекты деятельности», а потом переносят его на диаграмму. Автоматически создается стрелка с тем же названием. По данной стрелке передается документ, на основе которого стрелка была создана. Но такой способ годится только на самом нижнем уровне описания в нотации IDEF0. Если применять его на А0, то вы получите лес стрелок и абсолютно нечитаемую диаграмму.
Кстати, в Business Studio 4.2. (текущая версия на момент написания статьи) сформировать иерархический справочник объектов деятельности невозможно – только линейный список. Либо приходится создавать псевдо-иерархию за счет использования папок.
Надо отметить, что создание иерархического справочника объектов деятельности представляет собой весьма сложную методическую задачу. Чего стоит только наличие дублирующих друг друга справочников в различных информационных системах компании…
Но без создания иерархических справочников объектов деятельности создать инженерную модель бизнеса невозможно.
Как можно доработать SADT для решения указанных проблем?
Сформулируем некоторые практические правила использования SADT для создания действительно инженерной архитектурной модели бизнеса (в Business Studio):
- два процесса на схеме (в случае двустороннего взаимодействия между ними) могут соединяться только двумя стрелками («правило двух стрелок» — туда и обратно); стрелки (трубы) именуются, например, следующим образом: БП1.И1-БП2.В1 (исходящая стрелка 1 Бизнес-процесса 1 поступает как входящая стрелка 1 в Бизнес-процесс 2);
- на каждом уровне модели (до уровня BPMN) определяются процессы управления;
- по каждой стрелке должны двигаться реальные объекты из справочников (информация, документы, материальные ресурсы);
- внешние ссылки разрешены только на диаграмме А0;
- использование междиаграммных ссылок (МДС) запрещено на всех диаграммах (исключение может быть только одно – когда создано две отдельных модели в IDEF0 (у каждой своя контекстная диаграмма) и их нужно связать между собой. Но в этом случае допускаются только МДС на диаграмме А0).
На рисунке 2 представлена модель компании (промышленное производство), сформированная на основе представленных выше правил (кроме «правила двух стрелок» — пока выбрано некоторое промежуточное решение).
Использованы разные цвета для стрелок, по которым движутся объекты разного типа:
• красные стрелки — управляющие воздействия (ограничения, планы, приказы и т.п.);
• серые стрелки – отчетность всех видов, проекты планов и т.п.;
• синие стрелки – информационные и материальные потоки;
• розовые стрелки – запросы на предоставление сервисов (входы в обеспечивающие процессы);
• зеленые – ресурсы для выполнения процессов и результаты сервисов (оборудование, ИТ-сервисы, персонал и т.п.).
Стрелки одного типа частично наложены друг на друга для сохранения визуальной наглядности диаграммы.
Вверху рисунка 2 показана процессная категория «Управление бизнесом». Из этого четырехугольника выходят стрелки красного цвета – стрелки управления, которые входят сверху во все остальные категории процессов.
Ниже показаны так называемые основные процессы, которые участвуют в создании продукта (оказании услуг). Процессные категории данного типа связаны между собой стрелками синего цвета. При построении диаграммы была сделана попытка минимизировать количество стрелок между объектами.
Еще ниже представлен четырехугольник категории «Инженерно-техническое обеспечение». Из него выходят стрелки зеленого цвета – ресурсы, необходимые для выполнения остальных процессов (оборудование, ЗИП и проч.). На диаграмме видно, что эти зеленые стрелки заходят во все остальные процессы снизу в соответствии с методологией SADT.
Справа внизу показана категория «Обеспечение операционной деятельности» — внутри все процессы обеспечения, такие как «Управление персоналом», «Административно-хозяйственное обеспечение» и другие. Видно, что выходом категории также являются зеленые стрелки, передающие ресурсы (например, персонал).
Важно, что все реально взаимодействующие бизнес-процессы связаны между собой реальными потоками объектов.
Если бы в Business Studio была возможность включать/выключать отображение различных типов стрелок (например, показать только управление и отчетность), то модель можно было разрабатывать и смотреть по слоям. Такое решение было бы намного удобнее.
Представленная на рисунке 2 модель может показаться сложной. Но она имеет то преимущество, что все взаимодействующие процессы связаны стрелками, по которым движутся реальные объекты (информация, документы, материальные объекты). Это означает, что:
• можно четко определить входы/выходы процессов и зоны ответственности руководителей;
• для каждого процесса можно определить цели и показатели;
• процессы можно синхронизовать между собой.
Выводы
По итогам анализа недостатков методологии SADT можно сделать следующие выводы:
• методология SADT в классическом варианте содержит ряд допущений, которые не позволяют использовать ее для создания инженерной модели бизнеса (ИМБ);
• за счет отмены тоннельных стрелок и введения новых правил моделирования можно скорректировать методологию SADT и сделать ее применимой для создания ИМБ;
• существующие системы бизнес-моделирования (такие, как ARIS или Business Studio) крайне неудобны для создания сложной ИМБ;
• есть основания полагать, что ИМБ может служить платформой для создания полной цифровой модели бизнеса путем интеграции подсистем управления и ряда функциональных приложений на единой процессной платформе.
В.В. Репин,
к.т.н., доцент, консультант по управлению, тренер,
Генеральный директор ООО «Владимир Репин Менеджмент»
Ноябрь 2018 г.