Компании стремятся к оптимизации деятельности и, логично, что растет спрос на услуги по описанию, анализу бизнес-процессов и предложению улучшений. В этом может помочь бизнес-аналитик, который знает и использует методологии улучшения процессов в соответствии с профстандартом и BABOK (Business Analysis Body of Knowledge , свод знаний по бизнес-анализу). 

Всем привет! Меня зовут Диана. Я ведущий аналитик в ИТ-компании SimbirSoft и работаю в бизнес-анализе уже более 9 лет. Начинала как аналитик процессов (специалист процессного управления, специалист организационного развития — единого наименования этой должности не существует). У меня накопился опыт работы над проектами в разных отраслях и компаниях. Хочу поделиться, как применение методологий для улучшения процессов помогают компаниям достичь их конечной цели — масштабировать бизнес, оптимизировать деятельность и повысить результативность работы. 

Статья будет особенно полезна аналитикам, которые хотят перейти в ИТ-сферу, так как все они в своей работе сталкиваются с задачей анализа процессов на разном уровне их абстракции (то есть детализации). Также материал пригодится менеджерам, стремящимся улучшать процессы в зоне своей ответственности.

Содержание

Кратко о методологиях для менеджмента качества

СМК или Процессный подход: что это такое?

Классификация процессов

Показатели здоровья процессов

Кейс: как улучшить процессы в компании

Процесс улучшения качества процессов цикличен и на верхнем уровне абстракции состоит из этапов, показанных на картинке ↓

Кратко о методологиях для менеджмента качества

Аналитикам важно знать методологии, направленные на системные улучшения деятельности, чтобы быть проводниками позитивных изменений в компаниях. В статье рассказываю о популярных методологиях, которые сама применяла в своей профессиональной деятельности и считаю их взаимодополняющими и способными принести экономический эффект бизнесу: СМК (процессный подход), LEAN и ТОС. 

Нормативной основой СМК является ISO 9001 «Система менеджмента качества. Требования». В России действует его русифицированный близнец — ГОСТ Р ИСО 9001-2015. Они оба базируются на следующих семи принципах: 

  1. Ориентация на клиентов

  2. Лидерство

  3. Вовлеченность персонала

  4. Процессный подход

  5. Улучшения

  6. Решения на фактах

  7. Менеджмент взаимоотношений.

До сих пор бытует мнение, что процессный подход = регламентация. И если описать все процессы, создать регламенты и раздать их исполнителям — то будет счастье (но это не так). Процессный подход — это полный управленческий цикл работы с процессами. Регламентация же служит фундаментом для улучшения, но не панацеей для любого проекта. Регламенты и показатели процессов начинают работать тогда, когда выстроена система контроля по ним и на команду возложена ответственность за неисполнение регламентов и показателей процессов.  

СМК или Процессный подход: что это такое? 

Процессный подход основан на управлении организацией как набором взаимосвязанных процессов, а не отдельных функций или функциональных подразделений. Это позволяет вносить изменения в деятельность компании более системно. У процессного подхода есть следующие принципы:

  1. Любая организация — система взаимосвязанных процессов.

  2. Каждый процесс имеет определенные и однозначные границы.

  3. Каждый процесс производит продукт.

  4. Для производства продуктов процесс использует входы, которые, в свою очередь, являются результатами других процессов.

  5. У каждого продукта (как результата процесса) есть один или несколько клиентов (внутренних и/или внешних).

  6. У каждого процесса есть только один владелец.

  7. Клиенты процесса определяют требования к продуктам.

  8. Процесс-производитель гарантирует, что произведенный продукт соответствует требованиям клиента.

  9. Каждый процесс — это компания внутри компании.

  10. Управление процессами осуществляется системно.

  11. Управление бизнес-процессами осуществляется с одной целью.

Чаще всего анализ процессов включает в себя их моделирование. Первый шаг — создание карты процессов компании (верхний уровень абстракции). Для этого необходимо классифицировать процессы.

Классификация процессов

Анализ деятельности компаний начинается с классификации их процессов, чтобы понимать, какие из них:

  • приносят прибыль;

  • служат «помощниками»;

  • устанавливают правила игры. 

Компании, применяющие процессный подход, вправе самостоятельно определить классификацию процессов, но чаще всего выделяют следующие типы процессов на верхнем уровне управления процессами (уровне абстракции):

  • Управленческие — задают правила/методологию и цели.

  • Основные — составляют цепочку создания ценности конечного потребителя.

  • Вспомогательные/поддерживающие/обеспечивающие — обеспечивают вышеперечисленные процессы необходимыми ресурсами и условиями.

  • Процессы развития — помогают компании удерживать позиции на рынке при динамических внешних условиях.

Вышеперечисленные процессы чаще всего составляют карту процессов организации. Составление такой карты — один из первых шагов в переходе к процессному управлению бизнесом.

После составления карты, каждый из этих процессов декомпозируется на более мелкие. Выделяют три уровня абстракции:

  1. Высокий (или согласовательный) — процессы этого уровня строятся для общего понимания процесса (чаще для топ-менеджмента). Они не имеют ветвлений, описываются без использования терминов, без указания ответственных лиц и информационных систем. 

  2. Средний (или аналитический) — строятся для непосредственных участников процесса или руководителей среднего звена. Процессы на этом уровне могут служить инструкцией, так как содержат ветвления, информацию об информационных системах, исполнителях, артефактах, а также подпроцессах, которые декомпозированы до задач.

  3. Низкий (или исполняемый) — строятся для исполнения в BPMS (Business Process Management System — система управления бизнес-процессами). Содержат то же, что и на среднем уровне, а также информацию о составе групп и ролей, бизнес-правилах, пользовательском интерфейсе, KPI, скриптах и сервисных задачах. 

Декомпозицию процессов производит аналитик с верификацией со стороны бизнеса. Решая данную задачу, очень советую помнить три принципа:

  1. Принцип «фокус на цели». Четко понимать цель декомпозиции. Ответьте себе на вопрос: «зачем я хочу разложить мой процесс на более мелкие части (или наоборот, не разделять процесс на более мелкие части, а остановиться на более высоком уровне декомпозиции), что мне это даст, как от этого увеличится ценность моей модели процесса?»

  2. Принцип «мышка-слон». Он заложен в самом определении термина декомпозиции — разделение чего-либо сложного и большого на маленькие и относительно простые (примерно одного уровня сложности) части. То есть на одно уровне не могут быть процессы/подпроцессы разного уровня сложности («мышки» и «слоны»).

  3. Принцип «А4». Носит рекомендательный характер и заключается в том, что если итоговый результат моделирования будет использоваться в печатном варианте, то крайне желательно, чтобы модель процесса помещалась и была читаема на листе формата А4.

После того, как процессы определены и смоделированы в соответствии с принципами декомпозиции, необходимо определить владельца процесса и распределить ответственность между участниками. Также важно определить показатели, по которым владелец сможет точно и вовремя определить уровень «здоровья» и актуальности процесса.

Показатели здоровья процессов

Для каждого процесса целевые показатели могут быть различны (например, для продаж — различные виды прибыли и удовлетворенность покупателей; для ИТ — уровень сервиса, TTM (time to market — время от начала разработки идеи до конечного запуска решения и его выхода на рынок); для маркетинга — конверсия и т.д). Стоит отметить, что при формировании показателей необходимо учитывать требования к конечному продукту/выходу процесса со стороны потребителя этого выхода. 

Прошу обратить внимание, что у всех процессов есть единый важный показатель здоровья — отношение фактической производительности к плановой.

Рисунок 1. Процесс как «черный ящик»
Рисунок 1. Процесс как «черный ящик»

Посмотрим на рисунок 1:

  1. У клиента есть потребность. 

  2. Есть бизнес-процесс, который должен своим выходом (результатом/продуктом) закрыть потребность клиента.

  3. У этого процесса есть Владелец, который определил правила исполнения процесса и метрики. По ним он регулярно отслеживает функционирование процесса. Владелец также обеспечил процесс необходимыми ресурсами: сотрудники, их рабочие места, информационные системы и базы данных, техника и прочее.

  4. У каждого ресурса есть своя нормальная производительность, при которой он работает стабильно и с заданным качеством. 

Нормальная производительность ресурса = нормальное количество задач (нагрузка) ресурса в единицу времени. 

Фактическая производительность ресурса = фактическая нагрузка ресурса в единицу времени. 

В свою очередь, нормальная производительность процесса = суммарная нормальная производительность ресурсов. 

Фактическая производительность процесса = суммарной фактической производительности ресурсов. 

  1. Если фактическая производительность > нормальной производительности, то формируется очередь задач → процесс тормозит либо выдает некачественный результат, и, как следствие, нужно увеличивать производительность или количество ресурсов. 

Однако постоянное увеличение количества ресурсов тоже не самое лучшее решение, так как ресурсы стоят денег, а у процесса есть показатель эффективности — отношение результативности к затратам. Увеличение количества ресурсов может сделать процесс нерентабельным. 

Исходя из написанного выше, для улучшения процесса в первую очередь стоит решить, как повысить производительность имеющихся ресурсов. 

Для этого нужно выяснить, за счет чего это можно сделать. Возможно, наш ресурс нагружен операциями, которые можно сократить. Для выявления данных неоптимальностей можно и нужно использовать различные методологии

Я хочу сконцентрироваться на двух самых известных: бережливое производство (LEAN) и теория ограничения систем (ТОС).

Кейс: как улучшить процессы в компании

Представь, что ты бизнес-аналитик в компании, которая специализируется на системах безопасности. Перед компанией стоит амбициозная цель: кратно увеличить количество обслуживаемых объектов и среднюю стоимость договоров, и, как следствие, добиться роста компании в целом. 

Для этого необходимо: 

  • навести порядок в процессах; 

  • провести улучшения в процессах. 

Примерный план действий, который может меняться в зависимости от видения и целей руководства компании:

  1. Изучить имеющуюся нормативную документацию в компании, выделить перечень процессов. Сформировать драфт перечня процессов с декомпозицией.

  2. Совместно с руководством компании упорядочить процессы и распределить ответственность. 

  3. Приоритезировать процессы для дальнейших работ по ним. Приоритет определяет руководство компании, но аналитик вправе предложить на рассмотрение свое видение, например исходя из результатов SWOT, PEST, анализа рисков и других аналитических методов.

  4. Описать процессы в том состоянии, в котором они есть сейчас (As is). С помощью визуального анализа схем определить потенциальные точки улучшений.

  5. Определить метрики (или актуализировать, если они существовали ранее) процессов и порядок их мониторинга.

  6. Проанализировать процессы, сформировать и приоритезировать перечень точек улучшений, взять их в работу.

Пункты 1-5 разберу ниже, так как они относятся только к процессному управлению. Пункт 6 относится к этапу улучшений процессов и его можно проводить по ТОС или Lean методологии, и его разберу во второй части статьи.

После выполнения пунктов 1-2 была сформирована карта процессов (рис.2) и матрица ответственности (таблица 1).

Рисунок 2. Карта процессов
Рисунок 2. Карта процессов
Таблица 1. Фрагмент матрицы ответственности
Таблица 1. Фрагмент матрицы ответственности

Где:

В — владелец процесса: устанавливает правила, метрики, отвечает за результат перед клиентом и руководством

И — исполнитель процесса: фактически исполняет процесс по установленным правилам, отвечает за результат перед Владельцем 

К — контролирующий: осуществляет контроль за ходом и результатом процесса. Часть функции Владельца процесса. Выделяется в матрице, если Владелец делегировал это полномочие кому-либо

У — участник процесса — помогает в исполнении процесса, но не отвечает за результат (вносит данные, консультирует и пр).

После согласования приоритетов работы по процессам определили, что, исходя из целей компании, начинать нужно с процессов поиска клиентов и продажи услуг. Был проведен ряд встреч с владельцами и исполнителями данных процессов для их декомпозиции и распределения ответственности. На рисунках 3 и 4 представлена декомпозиция процессов до третьего уровня в нотации IDEF (I-CAM DEFinition или Integrated DEFinition — методологии семейства ICAM (Integrated Computer-Aided Manufacturing) для решения задач моделирования сложных систем), т.к. не требует высокой детализации. Для более глубокой декомпозиции процессов используются другие нотации (рисунок 5):

  • BPMN — Business Process Model and Notation (Модель бизнес-процессов и нотация).

  • CFFC— cross-functional flowchart (кросс-функциональная блок-схема). 

  • EPC — Event-Driven Process Chain (событийная цепочка процессов). 

Стоит отметить, что обо всех используемых нотациях и прочих правилах процессного управления в компании желательно заранее договориться с руководством компании и прописать в нормативном документе.

Рисунок 3.
Рисунок 3.
Рисунок 4.
Рисунок 4.
Рисунок 5.
Рисунок 5.

После того, как модель процесса согласована, необходимо сформировать по ней метрики. Метрики процесса можно классифицировать на метрики качества результата, результативности и эффективности. 

Примеры возможных метрик для процесса обработки входящих заявок.

Метрики качества результата: 

  • доля заявок на осмотр, соответствующих требованиям;

  • наличие уточнений по задаче от исполнителя;

  • количество верно классифицированных заявок.

Метрики результативности:

  • доля обработанных заявок клиентов за период;

  • доля необработанных заявок клиентов за период.

Метрики эффективности:

  • среднее время обработки одной заявки от клиента;

  • средняя стоимость обработки одной заявки от клиента;

  • доля заявок, обработанных в срок;

  • количество обработанных заявок клиентов за период план/факт в %.

Метрики должны быть согласованы и вменены в ответственность Владельцу процесса с указанием периодичности их мониторинга. По данным метрикам может производиться аудит процесса, также они являются основой для поиска точек улучшений в процессах. 

А о том, как можно использовать LEAN и ТОС для проведения улучшений в процессах, обязательно расскажу в следующей части статьи.

Подписывайся на наши соцсети и блог, где мы публикуем другие полезные материалы:

Telegram

ВКонтакте

Дзен

Комментарии (2)


  1. MEGA_Nexus
    07.07.2025 08:27

    Статья хорошая, но сама тема не очень популярная в IT. Процессники крепко ассоциируются с большими бюрократическими компаниями, что вызывает дополнительный негатив, хотя по факту сама стандартизация (внедрение регламентов) - это полезная активность.


    1. AVF_613
      07.07.2025 08:27

      Процессники крепко ассоциируются с большими бюрократическими компаниями

      В том то и дело, что для большинства людей СМК=бюрократия. Описывать процессы "картинками" в 2025 году, на мой взгляд, это дикость... На поддержку моделей уходит уйма времени, да и бизнес не очень в них разбирается. В своих "Видах деятельности" руководители разбираются, дак и нужно с них начинать... а рисовать какие то процессы, это не их работа.

      Системный подход, он сам по себе не подразумевает бюрократию, он должен устранять дублирование и неоднозначность информации. А тут без автоматизации невозможно...

      Связи объектов СМК (в контексте аудита)
      Связи объектов СМК (в контексте аудита)

      LEAN и ТОС хороши для общего представления, как управлять организацией, но это больше "культурные" понятия, чем инструменты.

      Для примера, можно взять кусочек модели из статьи:

      Что бы автоматизировать этот кусок, нужно, как минимум, разработать спецификации Объектов (сущностей), Форм (пользовательских), ну и "стрелочки" назвать и определить правила перехода по ним.. итд

      Описание процесса
      процесс

      В своё время, N лет назад, делал презентацию, как можно это (процесс автоматизации процессов) реализовать в рамках компании:

      Презентация
      Анекдот

      "Знакомый на работу устраивался. Сварщиком. Собеседование в отделе HR. Мастер цеха пришёл и сидят вместе с девочкой–кадровичкой общаются. Мастер спрашивает что варил, разряд и прочие тонкости. Вопросов много задавал, знакомый отвечал и рассказывал. Девочка слушала.

      Побеседовали минут двадцать. Мастер говорит девочке прямо при знакомом: "Ну, специалист, вроде, толковый — прошу оформить к нам." Девочка: "Подождите! Надо пройти ещё психологический тест!" - Мастер: "А что за тест?" Девочка: "Ну, психологический! Мы должны понять же, человек подходит нам или нет, как Вы не понимаете?"

      Мастер: "Так а что в этом тесте то?"

      Девочка: "Ну, линии там, круглешочки, картинки показываем человеку, а на основании его ответов составляем картину совместимости, даём руководству ясное представление о работнике, которого принимаем."

      Мастер: "Давай бумажку — я за него нарисую."

      Девочка оху..вает слегка, но даёт лист А4 и ручку. Мастер выводит на ней контуры (без анатомических подробностей!) ...уя, протягивает её и спрашивает:"Что я нарисовал?"
      Девочка краснеет, но говорит: "Член."

      Мастер девочке говорит: "Света! Будь добра, оформи человека без всей этой твоей х..йни, пока я всем не сказал, что ты деталь НВ–46–39–00 из каталога нашего завода с х..ем путаешь."

      ПС: статья, больше обзорная... для Инженера СМК, в 2025, бесполезная, всё это и в институте рассказывали, а как с этим идти в ИТ непонятно. Лучше про стат методы расскажите (Новая экономика Э.Деминга).