Несколько подразделений участвуют в исполнении одного заказа. Чтобы управлять его сроком и результатом, руководителю нужно видеть их общую работу, передачи между участниками и ответственность за итог. Для этого нужна карта процессов.
1. Роль процессов в системе управления
Оргструктура и процессная архитектура отвечают на разные управленческие вопросы:
Организационная структура и карта процессов дополняют друг друга. Руководители подразделений управляют людьми и ресурсами, а владелец процесса отвечает за согласованную работу участников и общий результат в пределах предоставленных ему полномочий.
Логика управления
Стратегия → Бизнес— результат → Процесс → Показатели → Изменения
2. Для чего организации нужны процессы
Процессный подход решает пять ключевых управленческих задач:
Связать стратегию с исполнением
Стратегические цели реализуются через конкретную деятельность подразделений и их совместную работу.
Логика управления должна быть прослеживаемой:
стратегическая цель → требуемый бизнес-результат → процессы → показатели → изменения и инициативы.
Пример «ИнтерПоляриса».
В стратегии на 2027–2029 годы своевременное исполнение заказов связано с финансовой устойчивостью: срывы сроков могут приводить к штрафам, дополнительным расходам на банковские гарантии и кассовым разрывам. В рассматриваемой модели эту задачу поддерживает УП-3 «Управление и реализация проектов»: его цель — исполнить проекты в установленный срок в рамках запланированных ресурсов. Примеры показателей — соблюдение договорных сроков и выполнение бюджета.
Процессная архитектура позволяет определить, через какие именно процессы должна реализовываться стратегия.
Управлять конечным результатом, а не только работой подразделений
Заказчик оценивает конечный результат: продукт получен вовремя и соответствует требованиям, услуга оказана, проблема решена. Отдельные отчёты подразделений ещё не показывают, достигнут ли этот результат.
При функциональном управлении типичная проблема возникает на стыках подразделений: локальные показатели выполнены, но общий результат не достигнут.
Процесс позволяет рассматривать цепочку создания результата целиком.
Пример из рассматриваемой модели: основная цепочка создания результата
Основные выходы одного процесса используются другими процессами. Это укрупнённая логика связей: отдельные работы могут выполняться параллельно, а результаты — возвращаться на доработку. Детальные карты раскрывают условия передачи и приёмки. УП-3 «Управление и реализация проектов» координирует исполнение заказа от запуска проекта до завершения договорных обязательств.
Закрепить ответственность за межфункциональный результат
Для процесса можно определить:
-
ожидаемый результат;
-
потребителя результата;
-
владельца процесса и его полномочия;
-
показатели;
-
ключевые границы и взаимодействия.
Это снижает число ситуаций, когда проблема находится «между подразделениями» и ответственность за итоговый результат размыта.
Для владельца определяют, какие данные он получает, какие решения вправе принимать, как согласует изменения с руководителями подразделений и кому передаёт вопрос, если участники не могут договориться. Например, при задержке документов должно быть понятно, кто собирает участников, согласует действия для восстановления срока и выносит на решение руководства спор о приоритетах.
В рассматриваемой модели этот принцип уже показан через связку «процесс — владелец — результат — показатель»
Выход процесса и требования к нему следует описывать отдельно. Комплект технической документации — выход разработки. Пример требований: комплект принят получателем к согласованной дате и соответствует требованиям, необходимым для следующего этапа работы. Формулировка «документы выданы» сама по себе не подтверждает готовность заказа к дальнейшему исполнению.
Для такой проверки полезно сопоставить согласованную дату, фактическую передачу и приёмку результата. Объём выполненной работы показывает, сколько сделано; выполнение согласованных требований — результативность. Чтобы оценить эффективность, результат сопоставляют с затраченными ресурсами: временем сотрудников, деньгами, материалами. Например, снижение переделок может уменьшить затраты на подготовку принятого комплекта документов.
Создать основу для измерения и совершенствования
Процесс становится объектом управленческого цикла:
цель → показатель → исполнение → контроль → анализ → улучшение.
Без согласованной карты процессов можно измерять множество показателей подразделений и при этом упускать сроки, качество и затраты всей цепочки исполнения заказа.
Создать основу для стандартизации и автоматизации
Чтобы оценить пользу регламентации, бережливых инструментов, автоматизации или искусственного интеллекта, заранее определяют, какую работу нужно изменить и какой бизнес-показатель должен улучшиться. Для устойчивого эффекта нужны также исполнение принятого порядка, обучение участников и проверка результата.
Например, если комплект документов долго ждёт согласования, сначала выясняют, где он задерживается, кто принимает решение и сколько времени занимает ожидание. Затем определяют, какое изменение сократит задержку, и по каким данным это проверить. Программа должна поддержать выбранный порядок работы. Её внедрение само по себе ещё не показывает улучшения результата.
В противном случае существует риск автоматизировать существующую сложность и неэффективность.
3. Что считать процессами верхнего уровня
На верхнем уровне карты выделяют крупные процессы или группы процессов, через которые компания создаёт результат, управляет деятельностью и обеспечивает её ресурсами. Каждый такой объект затем раскрывают подробнее. Например, «Управление закупками» может включать выбор поставщика, заключение договора, заказ материалов и контроль исполнения.
В классификации APQC различаются категория, группа процессов, процесс, деятельность и задача. Это пример иерархии описания, которую адаптируют под свою организацию. В приведённой ниже модели верхние объекты называются процессами; внутри них объединены несколько видов деятельности. Три категории — управляющие, основные и обеспечивающие — группируют эти объекты по их назначению.
Карта процессов верхнего уровня должна отвечать прежде всего на вопрос:
Из каких крупных областей деятельности складывается работа организации и каким образом они совместно обеспечивают реализацию стратегии и создание ценности?
Она не должна превращаться в перечень всех операций или копию организационной структуры.
Пример модели ИнтерПоляриса
В примере модели «ИнтерПоляриса» выделены 10 процессов: 3 управляющих, 5 основных и 2 обеспечивающих. Это конкретный вариант группировки работы производственной компании. Число 10 не является нормой для других организаций.
Модель связывает работу нескольких подразделений. Например, ОБП-2 «Разработка изделий» объединяет конструкторский отдел, метрологическую службу, подготовку технической документации, разработку систем управления и исследовательские работы. УП-3 «Управление и реализация проектов» связывает проектное управление с производством, технологами, контролем качества, правовым и другими блоками.
4. Принципы выделения процессов верхнего уровня
При формировании процессной архитектуры рекомендуется руководствоваться следующими принципами.
Принцип 1. Отталкиваться от модели бизнеса, а не от оргструктуры
Процессы определяются исходя из того, как работает бизнес, а не из того, какие организационные единицы существуют сегодня.
Принцип 2. Выделять процессы через результат и создаваемую ценность
Для каждого объекта верхнего уровня должно быть возможно ответить:
какой существенный результат он обеспечивает и кто является потребителем этого результата?
Принцип 3. Обеспечивать связь со стратегией
Процессная архитектура должна содержать все существенные виды деятельности, необходимые для реализации стратегии и бизнес-модели.
Принцип 4. Соблюдать единый уровень абстракции
На одном уровне должны находиться сопоставимые по масштабу объекты.
Некорректно, например, одновременно выделять:
«управление продуктами» — «продажи» — «исполнение заказа» — «выставление счета».
Последний объект существенно более детальный.
Принцип 5. Обеспечивать полноту архитектуры
Вся существенная деятельность компании должна иметь место в системе процессов:
-
деятельность по созданию ценности для клиента;
-
управленческая деятельность;
-
обеспечивающая деятельность;
-
деятельность по развитию организации.
Проверьте полноту на нескольких реальных заказах и решениях руководства. Найдите, где на карте отражены финансы, договорная работа, риски, управление документами и развитие. Эти виды деятельности могут входить в крупные процессы, но для них должны быть понятны результат и ответственность. Само наличие трёх категорий ещё не подтверждает полноту карты.
Принцип 6. Минимизировать пересечения и неоднозначность границ
Процессная архитектура должна позволять однозначно определить, где находится ответственность за существенный бизнес-результат.
Полностью исключить взаимодействие процессов невозможно и не требуется. Необходимо исключить систематическое дублирование и неясность ответственности.
Принцип 7. Не подчинять границы процессов границам подразделений
Ключевые процессы часто являются сквозными.
В примере «ИнтерПоляриса» основные связи исполнения заказа показаны так:
тендер или запрос → договор → разработка документации → закупка → производство → контроль и испытания → отгрузка и завершение проекта.
Это обзорная цепочка. Условия передачи документов и изделий, параллельные работы и возвраты на доработку раскрываются при детализации.
Принцип 8. Каждый объект верхнего уровня должен быть управляемым
Для процесса верхнего уровня должны быть определимы:
-
назначение;
-
ключевой результат;
-
показатели;
-
основные взаимосвязи;
-
ответственный руководитель и его полномочия.
Принцип 9. Не перегружать верхний уровень деталями
Верхнеуровневая архитектура предназначена прежде всего для руководителей.
На ней не требуется показывать:
-
все операции;
-
документы;
-
роли исполнителей;
-
исключения;
-
детальные информационные потоки.
Должны быть видны структура бизнеса и системообразующие связи.
Принцип 10. Не делать количество процессов нормативом
Процессов должно быть минимально необходимое количество, достаточное для адекватного представления бизнеса.
Большое число объектов может быть признаком избыточной детализации. Слишком малая детализация может скрывать существенную деятельность. Проверять нужно полноту, сопоставимость масштаба и управляемость каждого объекта, а не число само по себе.
Практическая иллюстрация принципов на рассматриваемой модели
5. Как проверить карту и работу руководителя
Возьмите один завершённый заказ или проект и разберите ход его исполнения. Для самопроверки используйте собственный эпизод, для оценки коллеги — наблюдаемую работу, для собеседования — реальный пример кандидата.
-
Какой общий результат требовался и по каким данным видно, что он достигнут?
-
Где работа переходила между подразделениями, возникали задержки или переделки и кто согласовывал действия участников?
-
Какое решение изменило результат и чем это подтверждается?
Ищите объяснение собственных решений человека: на какие данные он опирался, почему выбрал конкретное действие, что сделал или поручил и какой результат получил. План с датами, история согласования документов, данные по срокам, переделкам или затратам помогут проверить рассказ.
Рассказ «мы описали процессы и внедрили систему» показывает выполненные мероприятия. Для оценки владения компетенцией нужно понять, какую проблему решили и как изменилась работа. Один удачный пример не доказывает устойчивый навык: проверьте его на других эпизодах.
Первый шаг — разобрать одну цепочку исполнения заказа. Для каждого крупного участка запишите результат, его получателя, требования к приёмке, владельца и основные показатели. Отметьте передачи между участниками и выберите одну проблему, которую будете устранять.
После изменения порядка работы сравните результат с исходной ситуацией и решите, что закрепить, а что пересмотреть. Так карта процессов становится основой конкретных решений руководителя.
Методические материалы
APQC — уровни классификации процессов и их взаимосвязи
ISO — методическое пояснение процессного подхода 2015 года
СЕОдня в социальных сетях:
VK • Telegram • MAX • YouTube • Дзен
