В статье Владимира Репина рассмотрена методика формирования модели сквозного процесса масштаба компании в среде Business Studio. Приводится пример модели в нотации IDEF0. Рассматриваются сценарии выполнения сквозного процесса. Представленная методика может быть использована при работе с любым программным продуктом, предназначенным для проектирования архитектуры бизнес-процессов организации.
Введение
С точки зрения повышения эффективности бизнеса важно уметь строить и использовать для оптимизации модель сквозного процесса масштаба компании.
В качестве примера я выбрал процесс «Разработка нового изделия: от идеи до постановки на производство» и создал его модель в Business Studio.
Обращаю внимание, что у меня не было цели создавать модель «идеального» процесса с претензией на «лучшую практику». Цель построения модели — показать возможности методологии моделирования сквозных процессов масштаба компании в среде Business Studio.
Модель сквозного процесса в нотации IDEF0
На рис. 1 представлена контекстная модель этого процесса. Видно, что стрелки приходят «ниоткуда» и уходят в «никуда». Понятно, что у сквозного процесса есть внутренние поставщики и потребители (процессы). Но на контекстной диаграмме Business Studio, увы, нельзя показать междиаграммные ссылки на другие процессы модели (техническое ограничение). С этим придется мириться. С другой стороны, в данном случае важно разработать модель отдельного сквозного процесса, а не всей компании.
Рис. 1. Диаграмма процесса «Разработка нового продукта». Контекст.
Сквозной процесс строится из кусков — функциональных процессов подразделений разного уровня. Предполагается, что, перед тем, как начать строить модель сквозного процесса, вы четко понимаете структуру процессов (функций), выполняемых в подразделениях. Более того, желательно иметь все эти процессы в виде иерархического справочника в Business Studio (только реестр, диаграммы можно сгенерировать, но они будут без связей).
На модели А0 сквозного процесса можно использовать блоки (процессы), которых нет в функциональной модели (реестрах функциональных процессов подразделений). Почему так?
Дело в том, что видение сквозного процесса масштаба компании, его структуры является предметом для обсуждения и согласования топ-менеджеров, например, в рамках проведения Процессного комитета (создание которого рекомендует BPM CBOK).
Другими словами, группировка процессных категорий на диаграмме А0 сквозного процесса (см. рис. 2) может отличатся от существующих структурных подразделений компании. Это две большие разницы.
Рассмотрим диаграмму процесса «Разработка нового продукта» (рис. 2). Видно, что рассматриваемый сквозной процесс является весьма масштабным. Он состоит из блоков (процессных категорий), которые сами по себе являются сложными.
Рис. 2. Диаграмма процесса «Разработка нового продукта».
Очевидно, что процесс такого уровня сложности невозможно представить в виде какой-то одной цепочки операций (Work Flow — поток работ, в нотации eEPC или BPMN), выполняемых конкретными сотрудниками. (Теоретически, это сделать можно, но модель будет включать несколько тысяч шагов и сотни шлюзов, что сделает ее абсолютно нечитаемой и практически неприменимой.)
Если мы декомпозируем, например, «Выполнение НИОКР», то, скорее всего, на диаграмме увидим процессы, которые тоже нерационально представлять в виде диаграмм Work Flow.
Очевидно, что сквозной процесс такого масштаба нуждается в постоянном административном управлении. Поэтому наличие на схеме блока «Управление разработкой новых и изменением текущих продуктов» представляется вполне оправданным.
На рис. 2 некоторые блоки показаны розовым цветом. Это сделано специально, чтобы обратить ваше внимание на тот факт, что эти процессы (полностью или частично) выполнятся не только в рамках рассматриваемого сквозного процесса, но и задействованы при выполнении других процессов.
На рис. 3 показана диаграмма процесса «Разработка требований к новому продукту».
Рис. 3. Диаграмма процесса «Разработка требований к новому продукту».
Семь процессов, представленные на диаграмме, выполняются последовательно только в идеальном случае (кроме блока «Анализ необходимости внесения изменений в существующий продукт»).
В реальности часть из них может работать одновременно, с разными задачами. Видно, что возможны возвраты и переделки, например, «Анализ возможности и необходимости создания нового продукта», «Разработка ТЗ на новый продукт» и «Принятие решения по новому продукту».
Если рассматривать блоки деятельности, представленные на схеме 3, как Work Flow (т. е. на следующем уровне), то для каждого такого процесса возможные различные условия:
- старта в части запуска предыдущими процессами;
- завершения в части запуска других процессов.
Сценарии выполнения сквозного процесса
На рис. 4 цветом показаны различные сценарии последовательного запуска процессов. На практике, конечно, их гораздо больше, чем три.
Рис. 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 и увязать их по входам/выходам и условиям запуска;
- провести анализ процессов с использование движка имитационного моделирования (или без него), определить время выполнения процессов и соответствующие затраты;
- построить матрицу сценариев выполнения сквозного процесса;
- выполнить анализ и оптимизацию сквозного процесса;
- регламентировать сквозной процесс;
- разработать систему целей и показателей для управления сквозным процессом (для основных сценариев);
- разработать техническое задание на автоматизацию сквозного процесса.
Опубликовано по материалам:
http://www.finexpert.ru/view/stsenarii_vypolneniya_skvoznogo_protsessa/956
Март 2019 г.
Поделиться: