План развития до должности операционного директора (COO)

Роль COO: зона ответственности, компетенции и KPI

Зачем компании COO и когда он нужен

COO (Chief Operating Officer, операционный директор) — руководитель, который отвечает за ежедневную управляемость бизнеса и превращение стратегии в стабильное выполнение: люди, процессы, качество, сроки, себестоимость, масштабирование.

COO чаще всего появляется, когда:

Компания растёт и ручное управление “через основателя” начинает ломаться.

Результат зависит от нескольких функций сразу (продажи, производство, логистика, поддержка, IT), и между ними возникают разрывы.

Нужны предсказуемые сроки и качество (SLA, контрактные обязательства, регуляторика).

Прибыльность “утекает” в операционных потерях: переделки, простои, брак, штрафы, возвраты.

COO — это не “администратор” и не “директор по всем вопросам”. Это лидер, который строит операционную систему, чтобы компания выполняла обещания клиентам и масштабировалась без потери маржи и качества.

> Для ориентира по общепринятому определению роли можно использовать: Chief operating officer

Место COO в системе управления

COO обычно является вторым лицом после CEO и соединяет стратегические цели с операционной реальностью.

Типовое распределение фокуса между C-level ролями:

| Роль | Главный фокус | Типовые вопросы | |---|---|---| | CEO | Видение, стратегия, рост, ключевые ставки | “Куда идём и за счёт чего выиграем?” | | COO | Исполнение стратегии, операционная эффективность, масштаб | “Как стабильно производим/доставляем/обслуживаем и улучшаем?” | | CFO | Финансовая устойчивость, контроль, инвестиции | “Какой P&L, кэш, риски, окупаемость?” | | CTO/CIO | Технологии и ИТ-платформа | “Какая архитектура и как технологии ускоряют бизнес?” | | CHRO | Кадры, культура, система управления людьми | “Какие компетенции, мотивация, оргструктура?” |

В разных компаниях контур COO отличается:

В производстве COO часто отвечает за производство, качество, цепочки поставок.

В сервисе и IT COO чаще отвечает за delivery, поддержку, операционные метрики, операционную модель.

В e-commerce COO может вести фулфилмент, логистику, клиентский сервис, операционную аналитику.

Ключевой признак правильного контура: COO отвечает за сквозной результат, который нельзя обеспечить одной функцией.

!Схема показывает, как COO связывает стратегию с процессами, людьми и данными, превращая это в измеримые результаты.

Зона ответственности COO

Ниже — типовые зоны ответственности COO. Важно: конкретный список зависит от отрасли и уровня зрелости компании.

Операционная результативность (performance)

Выполнение планов по объёму/выручке через операционную способность (мощности, пропускная способность, ресурсы).

Управление себестоимостью, операционными потерями и производительностью.

Обеспечение стабильности: “работает каждый день одинаково хорошо”.

Процессы и стандарты (process excellence)

Описание и стандартизация ключевых процессов “от клиента до денег”.

Управление улучшениями: устранение узких мест, сокращение циклов, снижение вариативности.

Внедрение подходов бережливого производства/управления (при необходимости): Lean manufacturing

Качество и клиентский опыт (quality & CX)

Построение системы качества: стандарты, контроль, разбор причин дефектов.

Управление метриками качества сервиса: скорость реакции, соблюдение SLA, доля повторных обращений.

Снижение количества “пожаров” и рекламаций.

Масштабирование (scaling)

Рост без деградации: качество, сроки, нагрузка на команды.

Тиражирование моделей (филиалы, регионы, новые продукты/линейки) через стандарты и обучение.

Межфункциональная координация (cross-functional)

Синхронизация продаж, производства/доставки, поддержки, финансов, IT.

Управление конфликтами приоритетов через единые правила и метрики.

Риски, непрерывность и соответствие (risk & continuity)

Операционные риски: простои, инциденты, безопасность, критические поставщики.

Планирование непрерывности: резервирование, сценарии, управление инцидентами.

Что обычно не является прямой зоной ответственности COO

Это зависит от компании, но чаще всего COO не является владельцем:

Инвесторских отношений и привлечения капитала (обычно CEO/CFO).

Финальной продуктовой стратегии (обычно CEO/CPO), но COO влияет через данные выполнения и возможности операций.

Юридической функции (обычно CLO/юристы), но COO отвечает за то, чтобы операции реально соблюдали требования.

Как договориться о границах ответственности

Чтобы избежать “серых зон”, используют матрицу ответственности RACI:

R (Responsible) — исполнитель.

A (Accountable) — владелец результата.

C (Consulted) — консультант.

I (Informed) — информируемый.

Справка по инструменту: Responsibility assignment matrix (RACI)

Компетенции COO

Компетенции COO — это сочетание управленческой зрелости, системности и умения принимать решения на данных.

Системное мышление и операционная архитектура

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

Умение проектировать операционную модель: роли, контуры управления, регулярные встречи, правила эскалаций.

Понимание “что измеряем и почему”: связь метрик с управленческими решениями.

Управление процессами и улучшениями

Декомпозиция сквозных процессов и выявление узких мест.

Навык строить стандарты, которые работают, а не “лежат в папке”.

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

Управление людьми и лидерство

Постановка целей, управление исполнением, обратная связь.

Создание культуры ответственности и прозрачности.

Развитие руководителей: COO масштабирует себя через сильный слой лидеров.

Финансовая грамотность для управленческих решений

Понимание P&L, unit-экономики, драйверов маржи.

Умение отличать “рост объёма” от “роста прибыльности” и настраивать баланс.

Управление изменениями

Планирование изменений без разрушения текущих операций.

Коммуникации: зачем меняем, что меняется в ролях и правилах.

Работа с сопротивлением и внедрение новых стандартов.

Data-driven подход и цифровые инструменты

Управление на данных: регулярные дашборды, единые определения метрик.

Сильное взаимодействие с IT/BI: данные должны быть пригодны для решений.

Ниже — пример “карты компетенций” COO, которую удобно использовать для самооценки.

| Компетенция | Поведенческие индикаторы | Артефакты (что можно показать) | |---|---|---| | Операционная система управления | Регулярные циклы управления, ясные правила эскалаций | Регламент управления, календарь ритмов, протоколы решений | | Процессы и улучшения | Сокращает цикл, снижает потери, убирает узкие места | Карты процессов, портфель улучшений, результаты пилотов | | Лидерство | Сильная команда, ясные ожидания, ответственность | Структура, KPI руководителей, план развития лидеров | | Финансы | Решения через экономику, а не интуицию | Модель себестоимости, драйверы маржи, бизнес-кейсы | | Change management | Изменения внедряются и удерживаются | План внедрения, коммуникации, контроль соблюдения стандартов | | Аналитика | Единые метрики, прозрачные дашборды | Словарь метрик, BI-дашборды, отчёты по отклонениям |

KPI COO: как выбирать и не ломать организацию

KPI COO нужны не “для отчёта”, а чтобы:

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

Управлять балансом скорость–качество–себестоимость.

Делать ответственность измеримой и сопоставимой между подразделениями.

Принципы хорошей системы KPI

Баланс показателей: нельзя оптимизировать только скорость или только стоимость.

Разделение результатов и драйверов: одни метрики фиксируют итог, другие помогают им управлять заранее.

Управляемость: у владельца KPI должны быть рычаги влияния.

Единые определения: метрики считаются одинаково во всех командах.

Для баланса удобно мыслить в логике сбалансированной системы показателей: Balanced scorecard

Примеры KPI для COO (универсальный шаблон)

Список ниже — не “обязательный набор”, а конструктор. Выбирайте то, что связано с вашим бизнесом и контуром ответственности.

| Направление | KPI | Как понимать простыми словами | Примечание | |---|---|---|---| | Надёжность поставки/исполнения | OTIF (On Time In Full) | Доля заказов, выполненных вовремя и полностью | Ключевой KPI в логистике/поставках | | Скорость | Lead time / Cycle time | Сколько времени проходит от запроса до результата | Важно фиксировать единое начало/конец отсчёта | | Качество | Defect rate / % переделок | Доля дефектов или повторной работы | Снижает скрытые затраты и улучшает срок | | Сервис | SLA compliance | Доля соблюдённых сроков ответа/решения | Важно в поддержке и IT/service delivery | | Производительность | Output per FTE | Выпуск/результат на одного сотрудника | Требует корректной нормализации | | Себестоимость | Cost per unit | Стоимость на единицу продукта/заказа/операции | Связать с драйверами: труд, логистика, брак | | Устойчивость операций | Кол-во критических инцидентов | Сколько раз операции “падали” критично | Хорошо дополнять разбором причин | | Люди | Текучесть в ключевых ролях | Потери людей там, где это бьёт по операциям | Обычно в паре с причинами ухода | | Улучшения | Доля процессов со стандартом | Процент ключевых процессов, где есть и соблюдается стандарт | Важно мерить не “наличие документа”, а применение |

Как связать KPI COO с целями компании

Практичный подход:

Зафиксировать 3–5 бизнес-целей на период (например, рост выручки, рост маржи, снижение возвратов).

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

Выбрать 5–9 KPI COO, из которых:

- 2–3 отражают итог (например, OTIF, cost per unit). - 2–3 показывают ранние сигналы (например, цикл, загрузка мощностей, доля переделок на этапе). - 1–3 отражают устойчивость системы (инциденты, текучесть в ключевых ролях, соблюдение стандартов).

Если компания использует OKR, COO часто отвечает за ключевые инициативы исполнения и метрики результата: OKR

Анти-примеры KPI (что часто ломает операции)

Один KPI на всё (например, “снизить расходы”), который провоцирует скрытые потери.

KPI, где люди не могут влиять на результат (например, зависимость от маркетинга/рынка без рычагов у операций).

Много показателей без приоритета: отчётность растёт, управление не улучшается.

Метрики без единого определения: команды спорят о цифрах вместо улучшений.

Типичные ошибки в роли COO

Подмена операционного управления “ручным тушением пожаров” без построения системы.

Улучшения без владельца процесса и без закрепления стандарта.

Оптимизация локальных участков вместо сквозного результата.

KPI без баланса (скорость против качества, экономия против устойчивости).

Недооценка коммуникаций: изменения не объяснены, поэтому не приняты.

Как использовать эту статью в вашем плане развития к COO

Эта статья — базовая рамка для всего курса: она задаёт язык роли, ответственность и способ измерять результат.

Практическая последовательность, чтобы “приземлить” материал на вашу ситуацию:

Описать контур COO в вашей компании: какие направления относятся к операциям и где сейчас разрывы.

Выделить 3–5 сквозных процессов, которые определяют результат (например, “лид → заказ → доставка → деньги”).

Сформировать черновой набор KPI (5–9) и проверить его на баланс, управляемость и единые определения.

Согласовать границы ответственности с CEO и ключевыми директорами через RACI.

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

Бизнес-модель и операционная стратегия компании

Зачем COO разбираться в бизнес-модели

В предыдущей статье мы определили роль COO как руководителя, который превращает стратегию в устойчивое исполнение через людей, процессы, качество, сроки и себестоимость. Чтобы это делать не «в вакууме», COO должен понимать бизнес-модель компании: как именно компания создаёт ценность, доставляет её клиенту и зарабатывает.

Операционная стратегия отвечает на вопрос: какие операционные решения и компромиссы нужны, чтобы бизнес-модель работала предсказуемо и с нужной маржой. Если бизнес-модель обещает «доставка за 2 часа», а операции построены как для «доставка за 3 дня», компания будет терять деньги и доверие клиентов.

Полезная отправная точка для терминов:

Бизнес-модель

Операционная стратегия

Бизнес-модель простыми словами

Бизнес-модель — это логика того, как компания:

создаёт ценность для клиента;

доставляет эту ценность (через продукт, сервис, каналы, партнёров);

получает выручку и несёт затраты;

защищает прибыльность (за счёт преимуществ и управляемости).

Важно различать:

Стратегию (где и как выигрываем на рынке).

Бизнес-модель (как устроена экономика и механизм доставки ценности).

Операционную модель (как внутри организованы люди, процессы, технологии, чтобы это выполнять).

Операционную стратегию (какие операционные приоритеты и решения выбраны, чтобы поддержать бизнес-модель).

Канва бизнес-модели как общий язык для COO

Один из самых удобных способов «разложить» бизнес-модель — Business Model Canvas. Он помогает договориться между CEO, продуктом, финансами и операциями, что именно мы обещаем рынку и за счёт чего это должно работать.

Источник: Business Model Canvas

Девять блоков бизнес-модели

Ниже — практическое объяснение блоков (в формулировках, полезных для COO).

| Блок | Вопрос | Что важно COO увидеть заранее | |---|---|---| | Сегменты клиентов | Кому продаём | Разные сегменты могут требовать разных SLA, ассортимента и логистики | | Ценностное предложение | Почему покупают | Какие параметры критичны: скорость, цена, качество, надёжность, удобство | | Каналы | Как клиент покупает и получает | Онлайн/офлайн/партнёры меняют процессы, точки контроля и затраты | | Отношения с клиентами | Как поддерживаем контакт | Самообслуживание vs персональный сервис — разная нагрузка на поддержку | | Потоки доходов | За что платят | Подписка, транзакции, сервисные пакеты — разные требования к биллингу и учёту | | Ключевые ресурсы | Что нужно, чтобы работать | Люди, мощности, IT, данные, бренд — где узкие места и риски | | Ключевые активности | Что делаем ежедневно | Производство, доставка, внедрение, поддержка, контроль качества | | Ключевые партнёры | Что отдаём внешним | Где зависимость, SLA партнёров, риски срыва и качество | | Структура затрат | На что уходит деньги | Драйверы себестоимости: труд, логистика, брак, простои, возвраты |

От бизнес-модели к операционной стратегии

Операционная стратегия: что это на практике

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

Обычно она фиксирует:

операционные приоритеты (например, скорость важнее стоимости или наоборот);

целевой уровень сервиса (например, SLA, OTIF, точность прогнозирования);

принципы проектирования процессов и сети (централизация/децентрализация, стандартизация/гибкость);

требования к качеству и управлению рисками;

роль технологий и данных (автоматизация, единые определения метрик).

Связанный концепт, полезный для «сквозного взгляда»: Цепочка создания ценности

Типовые операционные компромиссы

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

| Компромисс | Вариант A | Вариант B | Чем платим | |---|---|---|---| | Скорость vs стоимость | Быстро | Дёшево | Скорость часто требует буферов: запасов, людей, мощностей | | Стандартизация vs гибкость | Единый процесс | Индивидуальная настройка | Гибкость повышает сложность и вероятность ошибок | | Централизация vs локальность | Один центр | Много точек | Центр дешевле, локальность быстрее к клиенту | | Make vs buy | Делать внутри | Отдать партнёру | Партнёр снижает CAPEX, но добавляет зависимость и риски | | Качество «сразу» vs контроль «на выходе» | Встроенное качество | Финальный контроль | Финальный контроль ловит дефекты поздно и дороже |

Экономика бизнес-модели и операционные рычаги COO

COO не обязан быть CFO, но должен уверенно читать экономику бизнеса и связывать её с операционными решениями.

Юнит-экономика: минимальный набор для COO

Во многих моделях полезно смотреть на маржинальный вклад (сколько остаётся после переменных затрат на единицу продажи):

Где:

— маржинальный вклад (contribution margin) на единицу;

— цена продажи единицы (товар, заказ, транзакция, подписка);

— переменные затраты на эту единицу (доставка, комиссия, переменный труд, расходники, эквайринг и т.д.).

Как это применяет COO:

если падает , COO ищет операционные драйверы в (например, рост возвратов, переработки, лишние километры, недозагрузка смен);

если хороший, но «денег нет», COO проверяет конвертацию в денежный поток через циклы выполнения, запасы и дебиторку (совместно с CFO).

Драйверы затрат, которые чаще всего «живут» в операциях

Производительность: выпуск на FTE, загрузка мощностей.

Потери качества: брак, переделки, рекламации, повторные обращения.

Вариативность: нестабильные сроки, «пожары», скачки нагрузки.

Сеть и логистика: маршрутизация, плечо доставки, складская модель.

Прозрачность данных: из-за плохих данных компания платит за неверные решения.

Как COO переводит бизнес-модель в операционную систему

Чтобы связать бизнес-модель и реальное управление, COO строит операционную систему: процессы, оргструктуру, управленческие ритмы и KPI (это напрямую продолжает рамку из предыдущей статьи).

Практичная последовательность «от обещания к управлению»

Зафиксировать ценностное предложение в измеримых параметрах.

Определить сквозной поток создания ценности «от запроса до денег».

Выбрать операционные приоритеты и компромиссы.

Спроектировать операционную модель (роли, процессы, технологии, партнёры).

Назначить владельцев сквозных процессов и правила эскалаций.

Ввести KPI и ритмы управления (ежедневные/еженедельные обзоры), чтобы система была управляемой.

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

Примеры: как разные бизнес-модели требуют разных операций

E-commerce с обещанием «быстро и удобно»

Ценность: скорость доставки, наличие, простой возврат.

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

Операционные решения: распределённые склады ближе к спросу, стандарты упаковки, сильная логистика последней мили.

Риски: стоимость сервиса «съедает» маржу без контроля возвратов и точности прогнозирования.

B2B сервис по подписке (SaaS/аутсорсинг)

Ценность: предсказуемый результат и соблюдение SLA.

Операционная стратегия: управление мощностями, очередями, инцидентами, качеством обслуживания.

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

Метрики: соблюдение SLA и стабильность поставки (см. Соглашение об уровне обслуживания).

Производственная компания с фокусом на себестоимость

Ценность: стабильное качество при низкой цене.

Операционная стратегия: эффективность, стандартизация, снижение потерь.

Операционные решения: бережливые практики, контроль качества на ранних этапах, работа с поставщиками.

Риски: чрезмерная экономия может разрушить качество и сроки.

Как проверить согласованность бизнес-модели и операций

Ниже — быстрый чек-лист, который COO может использовать для диагностики.

| Вопрос | Хороший признак | Плохой признак | |---|---|---| | Ценность измерима? | Есть 2–4 измеримых параметра обещания | «Мы про качество» без метрик и стандартов | | Компромиссы зафиксированы? | Понятно, что важнее: скорость/стоимость/качество | Каждое подразделение оптимизирует своё | | Процессы сквозные? | Есть владельцы end-to-end процессов | Много локальных KPI, сквозной результат провисает | | Экономика связана с операциями? | Драйверы затрат и качества прозрачны | Финансы «прыгают», причины неясны | | Данные едины? | Словарь метрик и один источник правды | Споры о цифрах вместо решений |

Как использовать материал в вашем плане развития к COO

Возьмите текущую бизнес-модель компании и опишите её в логике 9 блоков.

Переведите ценностное предложение в измеримые параметры (скорость, качество, стоимость, надёжность).

Зафиксируйте 3–5 ключевых операционных компромиссов и проверьте, что они реально отражены в процессах, оргструктуре и KPI.

Сопоставьте выбранные KPI COO из предыдущей статьи с блоками «ценность» и «затраты»: каждый KPI должен либо защищать обещание клиенту, либо защищать маржу, либо устойчивость системы.

Процессы и эффективность: диагностика, оптимизация, регламенты

Как эта тема связана с ролью COO и операционной стратегией

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

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

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

диагностика процессов на фактах (а не на мнениях)

оптимизация сквозного потока (а не отдельных участков)

закрепление результата через регламенты, стандарты и управленческие ритмы

Что такое процесс и почему COO смотрит на него сквозным образом

Процесс — это повторяемая последовательность действий, которая превращает вход (запрос, заказ, сырьё, обращение) в выход, ценный для клиента или бизнеса.

Для COO критично различать:

функцию (отдел/команда: продажи, склад, поддержка)

сквозной процесс (end-to-end), который проходит через несколько функций (например, лид → договор → отгрузка → деньги)

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

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

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

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

Как выбрать процессы для диагностики: фокус COO

Диагностировать всё сразу нельзя. COO выбирает 3–5 процессов, которые определяют обещание клиенту и экономику.

Признаки процесса, с которого стоит начинать

процесс напрямую влияет на ценностное предложение (скорость, надёжность, качество)

процесс «несёт» основные потери (переделки, возвраты, простои, штрафы, рекламации)

процесс вызывает межфункциональные конфликты и ручные эскалации

процесс является ограничением роста (не хватает мощностей/пропускной способности)

Как зафиксировать границы процесса

Практика: задайте две формулировки.

Старт процесса — событие, которое однозначно запускает работу (например, «заказ оплачен» или «договор подписан»)

Финиш процесса — событие, которое означает завершение ценности и фиксацию результата (например, «доставка подтверждена» или «инцидент закрыт и подтверждён клиентом»)

Так вы избегаете ситуации, когда разные команды считают цикл по-разному и спорят о цифрах.

Диагностика процесса: как находить реальные причины, а не симптомы

Диагностика — это не «обсудить проблему», а собрать факты, описать поток и доказать, где и почему теряется результат.

Принципы диагностики для будущего COO

Сначала измеряем, потом улучшаем: иначе вы не поймёте, стало ли лучше.

Смотрим на поток целиком: локальная оптимизация часто ухудшает общий результат.

Отличаем вариативность от нормы: среднее значение без разброса вводит в заблуждение.

Фиксируем определения метрик: один словарь метрик для всех (связь с системой KPI из первой статьи).

Минимальный набор фактов, который стоит собрать

| Категория | Что собираем | Зачем это COO | |---|---|---| | Объём | сколько входов/заказов/обращений | понять нагрузку и сезонность | | Сроки | время цикла и ожиданий по этапам | найти задержки и очереди | | Качество | доля дефектов/переделок/повторов | оценить скрытую стоимость и причины срыва сроков | | Ресурсы | кто и сколько времени тратит | понять, где узкое место и перегруз | | Потери | ошибки, простои, возвраты, лишние согласования | сформировать список улучшений с экономическим эффектом |

Карта процесса: базовый артефакт COO

Чтобы договориться, «как оно работает на самом деле», используйте один из форматов.

Swimlane-диаграмма: удобно видеть стыки функций и возвраты.

Value Stream Mapping (карта потока создания ценности): удобно разложить время на работу и ожидание.

BPMN (нотация моделирования бизнес-процессов): полезно для сложной логики и автоматизации.

Справка:

Value stream mapping

Business Process Model and Notation

SIPOC: быстрый способ согласовать контекст

SIPOC — это простая рамка описания процесса на верхнем уровне:

Suppliers — поставщики входа

Inputs — входы

Process — основные шаги

Outputs — выходы

Customers — потребители выхода

Она помогает быстро выявить, кто на кого влияет и где появляются «серые зоны ответственности».

Справка: SIPOC

Как находить узкие места и причины

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

Подход полезно мыслить через Theory of constraints: система ограничена своим самым слабым звеном.

Чтобы перейти от симптомов к причинам, используйте инструменты.

| Инструмент | Что делает | Когда применять | |---|---|---| | 5 Why (5 «почему») | помогает докопаться до первопричины | когда причина кажется «очевидной», но повторяется | | Диаграмма Исикавы | структурирует причины по категориям (люди, методы, материалы, оборудование, измерения, среда) | когда причин много и они смешаны | | Принцип Парето | показывает «главные 20% причин», дающие «80% эффекта» | когда нужно приоритизировать проблемы | | FMEA | оценивает риски отказов по критичности и вероятности | когда цена ошибки высокая (качество, безопасность, SLA) |

Справка:

Five whys

Ishikawa diagram

Pareto principle

Failure mode and effects analysis

Оптимизация процесса: от «как есть» к «как должно быть»

Оптимизация — это проектирование лучшего потока, исходя из операционной стратегии (скорость, стоимость, качество, устойчивость) и закрепление результата.

Типовые источники потерь (практика Lean)

В Lean manufacturing часто используют идею, что часть действий не добавляет ценности. Для офисных и сервисных процессов это обычно выглядит так:

ожидание (очередь на согласование, зависимость от другого отдела)

переделка (ошибки входных данных, неполные требования)

лишние передачи (много точек «перекинуть задачу»)

избыточный контроль «на выходе» вместо встроенного качества

лишние действия (дублирование отчётности, ручной перенос данных)

Как проектировать улучшения, чтобы не сломать систему

Улучшения должны быть связаны с KPI и компромиссами из операционной стратегии. Например, нельзя улучшать скорость любой ценой, если бизнес-модель держится на марже.

Практичный порядок работы:

Сформулировать проблему в измеримых терминах: что именно ухудшается и как это видно в метриках.

Построить карту как есть и отметить потери: ожидания, возвраты, дефекты, «ручные костыли».

Найти ограничение (узкое место) и подтвердить фактами.

Определить первопричины (5 Why, Исикава) и выбрать 3–7 гипотез улучшений.

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

Спланировать внедрение поэтапно: пилот → масштабирование → закрепление стандартом.

Как приоритизировать улучшения: портфель COO

COO управляет не одной инициативой, а портфелем улучшений. Удобная логика отбора:

| Критерий | Вопрос | Пример | |---|---|---| | Влияние на ценность | улучшение укрепит обещание клиенту? | рост соблюдения SLA | | Влияние на экономику | снизит переменные затраты или потери? | меньше переделок → меньше труда | | Скорость эффекта | как быстро увидим результат? | изменения правил передачи задач | | Риск | есть ли риск остановить операции? | изменения в критическом IT-контуре | | Масштабируемость | можно ли тиражировать? | единый стандарт для всех филиалов |

Для системного цикла улучшений применяют:

PDCA (Plan–Do–Check–Act)

Kaizen как культура непрерывных улучшений

Six Sigma и подход DMAIC для задач, где критичны качество и снижение вариативности

!Схема показывает, как улучшения превращаются в устойчивый стандарт

Регламенты и стандарты: как закреплять улучшения

Оптимизировать — недостаточно. Если не закрепить изменения, процесс «откатится» к привычному поведению.

Термины, которые важно различать

Политика — правило верхнего уровня, что допустимо и недопустимо (например, «клиенту отвечаем не позднее 2 часов в рабочее время»).

Регламент — описание кто что делает и в каком порядке, включая роли, входы/выходы, сроки, точки контроля.

SOP (Standard Operating Procedure) — пошаговая инструкция выполнения операции (часто на уровне рабочего места).

Стандарт работы (standard work) — согласованный лучший способ выполнять работу, который измеряется и улучшается.

Справка: Standard operating procedure

Иерархия документации (чтобы не утонуть в бумагах)

Хорошая практика — строить «пирамиду»:

политика и принципы (коротко)

регламенты сквозных процессов (как устроено взаимодействие)

SOP/инструкции (как делать конкретные операции)

шаблоны и чек-листы (чтобы исполнителю было проще)

Что должен содержать хороший регламент

Чтобы регламент был управленческим инструментом, а не формальностью, проверьте наличие обязательных блоков.

| Блок | Содержание | Зачем | |---|---|---| | Цель процесса | какую ценность создаём и для кого | связывает процесс с бизнес-моделью | | Границы | старт/финиш, входы/выходы | единый расчёт сроков и KPI | | Роли и ответственность | владелец процесса, исполнители, согласующие | убирает «серые зоны» | | SLA/сроки | нормы по этапам и правила приоритетов | снижает очереди и конфликты | | Точки контроля качества | где проверяем и что считаем дефектом | снижает переделки | | Эскалации | когда и кому поднимать проблему | ускоряет решение инцидентов | | Метрики | 3–7 ключевых метрик процесса | управление на данных | | Изменения | кто обновляет, как версионируем | стандарт живёт, а не устаревает |

Связь с первой статьёй курса: роли и ответственность лучше фиксировать через Responsibility assignment matrix (RACI).

Почему регламенты часто «не работают»

Типовые причины:

регламент описывает «как должно быть», но не «как есть», и люди не узнают реальность

в регламенте нет владельца, метрик и цикла обновления

документ невозможно применить: длинный, без примеров, без шаблонов и чек-листов

нет обучения и контроля соблюдения, поэтому стандарт не закрепляется

Управление эффективностью: как COO превращает процессы в управляемую систему

Процессы становятся управляемыми, когда у них есть владельцы, стандарты, метрики и регулярные ритмы управления.

Система управления процессом: минимальная «операционная ОС»

владелец процесса (Accountable)

набор метрик результата и драйверов (связь с KPI COO)

дашборд или регулярный отчёт с едиными определениями

ритм разборов отклонений (например, еженедельно)

механизм улучшений (портфель инициатив, PDCA)

аудит соблюдения стандарта (проверяем не документ, а практику)

Баланс метрик: скорость, качество, стоимость, устойчивость

Чтобы оптимизация не превратилась в «выжали скорость — потеряли качество», полезно держать баланс:

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

качество: доля переделок, повторные обращения, дефекты

стоимость: cost per unit / трудозатраты на единицу

устойчивость: критические инциденты, нагрузка на ключевые роли, текучесть

Эта логика напрямую продолжает принципы KPI из первой статьи: метрики должны быть управляемыми, сбалансированными и одинаково определёнными.

Как использовать материал в вашем плане развития к COO

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

Зафиксируйте границы процесса (старт/финиш) и владельца процесса.

Постройте карту как есть (swimlane или VSM) и соберите базовые факты по срокам, качеству и потерям.

Найдите ограничение и первопричины, сформируйте 3–7 улучшений и приоритизируйте их по влиянию и риску.

Опишите целевое состояние и закрепите его через регламент + SOP + метрики + ритмы управления.

Это создаёт у вас портфолио артефактов, которое можно показать как доказательство компетенций COO: карта процесса, метрики, план улучшений, регламенты и результаты внедрения.

Финансы для COO: юнит-экономика, бюджет, управленческая отчетность

Почему COO нужны финансы, даже если есть CFO

В предыдущих статьях курса мы зафиксировали, что COO отвечает за устойчивое исполнение стратегии: сроки, качество, себестоимость, масштабируемость, а также за систему KPI и управляемость процессов. Финансы для COO — это не «ведение бухгалтерии», а язык, который связывает операционные решения с результатом в P&L, кэше и рисках.

Если COO оптимизирует процессы (скорость, стабильность, качество), но не понимает:

какие затраты переменные, а какие фиксированные

что является драйвером маржи

как операции влияют на оборотный капитал и денежный поток

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

Формально финансовый контур обычно ведёт CFO, но COO должен уметь:

читать управленческий P&L и понимать, что в нём «движет» результат

строить и защищать бюджеты (ресурсы, мощности, проекты)

связывать отклонения в финансах с первопричинами в процессах

Справочно по дисциплине управленческого учёта: Management accounting.

!Диаграмма причинно-следственной связи между операциями и финансовым результатом

Юнит-экономика: минимальный набор, который обязан понимать COO

Что такое «юнит» и зачем он нужен

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

Примеры юнитов:

заказ

отгрузка

доставка

обращение в поддержку

час работы специалиста

активный клиент в месяц (для подписки)

Правильный юнит помогает COO отвечать на вопросы:

«Сколько нам стоит выполнить одну единицу обещания клиенту?»

«Где именно в процессе “утекает” маржа?»

«Как изменится экономика при росте объёма?»

Переменные и фиксированные затраты: различие, которое влияет на решения

Для COO критично различать:

переменные затраты — растут примерно пропорционально объёму (доставка, упаковка, сдельная оплата, эквайринг, расходники)

фиксированные затраты — в краткосрочном периоде не зависят от объёма (аренда, управленческий персонал, часть IT, амортизация)

Одна и та же статья может быть «условно-переменной» (например, персонал в сменах): ступенчато растёт при достижении порога мощности.

Маржинальный вклад (contribution margin)

Чтобы понять, «окупается ли» выполнение юнита, используют маржинальный вклад:

Где:

— маржинальный вклад на один юнит (сколько остаётся, чтобы покрыть фиксированные затраты и прибыль)

— цена (выручка) на один юнит

— переменные затраты на один юнит

Если падает, COO ищет, какие элементы ухудшились из-за операций:

рост возвратов и повторных доставок

увеличение доли ручного труда

увеличение брака и переделок

потери от несоблюдения SLA (штрафы, компенсации)

Справочно: Contribution margin.

Точка безубыточности на уровне юнита

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

Где:

— объём юнитов в точке безубыточности

— фиксированные затраты за период

— маржинальный вклад на один юнит

Интерпретация для COO:

если улучшение повышает (например, снижает переменные затраты или дефекты), точка безубыточности снижается

если рост требует добавления фиксированных затрат (новая площадка, управленческий слой), точка безубыточности повышается

Справочно: Break-even (economics)).

Как связать юнит-экономику с процессами и KPI

В статье про процессы мы говорили, что улучшения нужно измерять фактами и закреплять стандартом. Финансовый слой добавляет правило: каждая ключевая метрика процесса должна иметь понятный финансовый «след».

Практичные связки:

defect rate → переделки → рост трудозатрат → рост

lead time и ожидания → незавершёнка/запасы → рост оборотного капитала

OTIF/SLA → штрафы/компенсации → прямые потери маржи

output per FTE → производительность → стоимость труда на юнит

Бюджет для COO: как планировать ресурсы и не «убить» выполнение

Бюджет COO — это, по сути, план операционной способности

Бюджет в управленческом смысле — это план ресурсов и затрат, согласованный с планом объёма и уровнем сервиса.

Справочно: Budget.

Для COO бюджет обычно включает:

фонд оплаты труда операционных команд

расходы на подрядчиков и партнёров (логистика, колл-центры, аутсорс)

операционные расходы (склады, транспорт, расходники, инструменты)

инвестиции в мощность и автоматизацию (CAPEX) и их эффект на себестоимость

Драйверный бюджет: лучший формат для операционного управления

Опасный сценарий: бюджет «по статьям», где спор идёт за суммы, а не за операционные предпосылки.

Для COO полезнее драйверный подход: бюджет строится от объёма и нормативов.

Типовые драйверы:

объём: заказы, обращения, тоннаж, отгрузки

производительность: юнитов на FTE, время обработки, пропускная способность

качество: доля переделок, возвраты

уровень сервиса: SLA, количество смен, буферы по мощности

сеть: количество складов/точек/маршрутов

COO должен уметь показать связь вида:

«Если объём вырастет на 20%, то при текущем lead time и производительности нам нужно +N FTE или автоматизация, иначе упадёт SLA и вырастут компенсации»

Годовой бюджет и rolling forecast

Для управления операциями часто недостаточно бюджета «раз в год», потому что объём, сезонность и узкие места меняются.

Два типовых инструмента:

годовой бюджет как базовый контракт по ресурсам

скользящий прогноз (rolling forecast) как регулярное уточнение планов по драйверам (объём, загрузка, стоимость)

Справочно по прогнозированию: Forecasting.

Бюджет улучшений и проектов: как COO защищает инвестиции

Улучшения и автоматизация конкурируют за ресурсы. Чтобы это не превращалось в «верю/не верю», COO оформляет бизнес-кейс.

Минимальный шаблон бизнес-кейса для COO:

Проблема в измеримых терминах (метрика процесса и финансовый эффект)

Предлагаемое решение (что меняем в процессе/системе/организации)

Инвестиции и расходы (разово и регулярно)

Эффект (снижение , снижение дефектов, повышение пропускной способности, снижение штрафов)

Риски внедрения и план поэтапного запуска (пилот → масштабирование)

Управленческая отчётность: что должен уметь читать и собирать COO

Управленческая отчётность отличается от бухгалтерской

Бухгалтерская отчётность нужна для регуляторов и внешних пользователей. Управленческая нужна для решений внутри компании.

Для COO ключевые отчёты обычно такие:

управленческий P&L (доходы и расходы за период)

отчёт о движении денежных средств (cash flow)

показатели оборотного капитала

операционные дашборды (KPI процессов), связанные с финансовыми строками

Справочно:

Income statement

Cash flow

Working capital

P&L: какие строки COO должен уметь «раскладывать» на процессы

На практике COO чаще всего влияет на:

себестоимость (COGS) и операционные расходы

потери качества (возвраты, списания, гарантийные затраты)

стоимость выполнения (cost per unit)

Справочно: Cost of goods sold.

Чтобы отчётность стала управляемой, нужно:

единые определения статей и аллокаций (как распределяем общие расходы)

регулярный разбор отклонений план–факт не только в деньгах, но и в драйверах

Анализ отклонений: как связать «минус в P&L» с первопричинами

Управленчески полезный разбор отклонений (variance analysis) обычно строится так:

Что изменилось в результате (например, маржа снизилась на X)

Что изменилось в объёме (юнитов стало больше/меньше)

Что изменилось в цене/миксе (доли сегментов, тарифов)

Что изменилось в себестоимости на юнит (труд, логистика, брак)

Какие операционные причины стоят за изменениями (узкие места, переделки, простои, ошибки входа)

Справочно: Variance analysis.

Денежный поток и оборотный капитал: где операции «съедают» кэш

Компания может быть прибыльной по P&L и испытывать дефицит денег. COO должен понимать, как операции влияют на кэш через оборотный капитал.

Цикл конвертации денег (cash conversion cycle)

Один из удобных показателей — цикл конвертации денег:

Где:

— сколько дней деньги «связаны» в операциях

— дни хранения запасов (inventory)

— дни до получения оплаты от клиентов (receivables)

— дни до оплаты поставщикам (payables)

Интерпретация для COO:

высокий часто связан с прогнозированием, планированием, сетью складов и качеством процесса пополнения

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

низкий может требовать переговоров, но COO влияет косвенно через стабильность поставок и качество взаимодействия с поставщиками

Справочно: Cash conversion cycle.

!Схема, показывающая как операции влияют на оборотный капитал

Типовые финансовые решения COO и как их считать без «магии»

Решение о буферах сервиса: скорость vs стоимость

Из статьи про операционную стратегию: обещание клиенту всегда требует компромиссов. Финансовая логика помогает сделать компромисс явным.

Когда COO добавляет буферы (запасы, смены, резервные мощности), он обычно выигрывает в SLA и стабильности, но платит ростом затрат.

Практичный способ обсуждения:

что будет с OTIF/SLA при текущих мощностях

сколько стоит «добавить надёжности» (люди, склад, подрядчики)

сколько стоит «не добавить» (штрафы, потери клиентов, возвраты, деградация качества)

Make vs buy: делать внутри или отдавать партнёру

Для COO это часто решение про:

контроль качества и сроков

зависимость от SLA партнёра

структуру затрат (переменные vs фиксированные)

Финансовая рамка:

сравнивать cost per unit и риски вариативности

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

Инвестиции в автоматизацию: эффект должен быть в драйверах

Типовая ошибка: автоматизацию защищают «словами про удобство». Для COO зрелый подход — привязка к драйверам:

снижение времени обработки → рост пропускной способности → меньше найма

снижение ошибок → меньше переделок → ниже

лучшее планирование → меньше запасов → ниже и выше кэш

Как использовать материал в вашем плане развития к COO

Выберите юнит для ключевого сквозного процесса (из статьи про процессы) и посчитайте его , , .

Зафиксируйте 5–10 операционных драйверов бюджета (объём, производительность, качество, уровень сервиса) и привяжите к статьям затрат.

Составьте «мост» между 3–5 KPI процесса и строками P&L: что именно в операции должно измениться, чтобы изменился финансовый результат.

Добавьте к операционному дашборду 1–2 метрики оборотного капитала (например, или ) и разберите, какие причины в процессах на них влияют.

Эти артефакты дополнят ваш профиль будущего COO: вы показываете не только умение улучшать процессы, но и умение управлять экономикой исполнения.

Люди и оргструктура: команды, мотивация, управление руководителями

Почему «люди и структура» — центральная тема для COO

В предыдущих статьях курса мы разобрали:

роль COO, его зоны ответственности и KPI

связь бизнес-модели и операционной стратегии (какие компромиссы компания выбирает)

процессы, эффективность, стандарты и управление улучшениями

финансы для COO: юнит-экономика, бюджет и управленческая отчётность

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

Базовые понятия: команда, роль, ответственность, оргструктура

Оргструктура — это способ, которым компания распределяет:

роли и зоны ответственности

полномочия на принятие решений

уровни управления (кто кому подчиняется)

взаимодействия между подразделениями

Команда — группа людей, которые регулярно взаимодействуют и несут общую ответственность за измеримый результат.

Роль — ожидаемый вклад человека (что он должен обеспечивать), включая границы полномочий.

Ответственность — зафиксированный «владелец результата» (кто отвечает за то, чтобы это было сделано и работало).

Связь с предыдущими темами:

процессы требуют владельцев сквозного результата (end-to-end)

KPI должны быть управляемыми (у владельца есть рычаги)

финансовые эффекты (себестоимость, потери, производительность) становятся управляемыми только если понятно, кто отвечает за драйверы

Роль COO в управлении людьми

COO редко является «главным HR», но почти всегда отвечает за операционную управляемость людей.

Типовые задачи COO в людях:

собрать сильную команду руководителей операций

назначить владельцев ключевых процессов и результатов

выстроить регулярный ритм управления (планирование, разборы, эскалации)

обеспечить стандарты работы и дисциплину исполнения

настроить мотивацию так, чтобы она поддерживала операционную стратегию (скорость, качество, стоимость, устойчивость)

Как выбирать оргструктуру под бизнес-модель и операционную стратегию

Из статьи про операционную стратегию: компания всегда делает компромиссы (скорость vs стоимость, стандартизация vs гибкость и т.д.). Оргструктура должна поддерживать выбранные приоритеты, иначе KPI начнут конфликтовать.

Критерии хорошей оргструктуры для операций

Ясность ответственности: на каждый сквозной результат есть владелец.

Минимум «серых зон»: меньше ситуаций «это не наш участок».

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

Снижение потерь на стыках: меньше передач, пересогласований и ожиданий.

Соответствие масштабу: структура не должна ломаться при росте объёма.

!Иллюстрация показывает, как функциональные команды и владельцы сквозных процессов одновременно обеспечивают управляемость по функциям и по end-to-end результату.

Типовые варианты оргструктур и когда они «заходят»

| Тип структуры | Как устроено | Когда подходит | Типовые риски для COO | |---|---|---|---| | Функциональная | отделы по функциям (склад, доставка, поддержка) | стабильные операции и понятные границы | конфликты на стыках, нет владельца сквозного результата | | Дивизиональная | разделение по регионам/филиалам/направлениям | разная локальная специфика и сеть | дублирование, сложнее стандартизировать | | Матричная | двойное подчинение (функция + проект/продукт) | нужны и стандарты, и гибкость | рост конфликтов приоритетов, требуется сильное управление | | Процессная (value stream) | команды вокруг потоков «от клиента до денег» | критичны сроки, качество, предсказуемость | риск «размыть» экспертизу функций без центра компетенций |

Термин value stream (поток создания ценности) связан с картами потока из статьи про процессы: Value stream mapping.

Практичный принцип: «двойная оптика» COO

В зрелых операциях часто нужен баланс:

функциональные руководители отвечают за ресурсы, стандарты, экспертизу

владельцы сквозных процессов отвечают за end-to-end результат (срок, качество, стоимость выполнения)

Чтобы это не превратилось в хаос, нужны ясные правила ответственности.

Ответственность и полномочия: как договориться «кто за что отвечает»

COO важно отделять:

владельца результата (кто отвечает за итог)

исполнителей (кто выполняет шаги)

консультантов (кто влияет экспертизой)

информируемых (кто должен знать)

Для фиксации удобно использовать матрицу RACI: Responsibility assignment matrix (RACI).

Где RACI особенно полезен COO

сквозные процессы «заказ → доставка → деньги»

инциденты и сбои (кто принимает решение, кто устраняет, кто информирует клиента)

изменения регламентов и стандартов (кто утверждает, кто обновляет, кто обучает)

взаимодействие операций с продажами, продуктом, IT и финансами

Команда COO: какие роли чаще всего нужны

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

Типовые роли в контуре COO:

руководители ключевых функций (производство, логистика, сервис/поддержка)

руководитель планирования/диспетчеризации (очереди, мощности, графики)

руководитель качества и разборов причин (дефекты, рекламации, SLA)

операционная аналитика/BI (дашборды, единые определения метрик)

операционная эффективность (портфель улучшений, стандартизация, аудит соблюдения)

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

Управление руководителями: как COO масштабирует себя

COO не должен быть «самым умным диспетчером». Его задача — построить управляемый слой руководителей.

Основные практики управления руководителями

регулярные 1:1 с руководителями (препятствия, решения, развитие)

единый цикл постановки целей и разборов отклонений

стандарты управления (как проводим планёрки, как ведём протокол решений)

развитие руководителей через делегирование и «владение результатом», а не через микроменеджмент

Что такое «управленческий ритм» в операциях

Управленческий ритм — это регулярные встречи и артефакты, которые делают выполнение предсказуемым.

Примерный набор ритмов (адаптируется под бизнес):

ежедневный короткий разбор выполнения и инцидентов

еженедельный разбор метрик процесса и отклонений план–факт

ежемесячный разбор мощности, качества, затрат и портфеля улучшений

квартальный пересмотр операционных приоритетов и ресурсов

Для компаний с выраженным планированием спроса и мощности полезен процесс S&OP: Sales and operations planning.

Как COO оценивает руководителей

Оценка не должна сводиться к «нравится/не нравится». Практично смотреть на сочетание:

результат по KPI (с учётом баланса скорость–качество–стоимость)

способность управлять системой (стандарты, дисциплина, прогнозируемость)

качество решений (на данных, с учётом рисков)

развитие команды (замены, наставничество, текучесть в ключевых ролях)

Общий термин дисциплины: Performance management.

Мотивация: как не «сломать» операции бонусами и KPI

Мотивация в операциях — это не только деньги. Но переменная часть (бонус) часто становится сильным сигналом поведения.

Принцип COO: мотивация должна поддерживать операционную стратегию

Если стратегия требует надёжности и качества, а бонус платится только за скорость или экономию, система будет стабильно производить дефекты, переделки и скрытые потери.

Связь с предыдущими статьями:

из статьи про KPI: нужен баланс метрик и единые определения

из статьи про финансы: экономия «на бумаге» может увеличить переменные затраты через потери качества

Конструктор метрик для мотивации операционных команд

Практика: держите 3–5 метрик, чтобы не перегрузить систему.

итог результата (например, OTIF или SLA)

качество (дефекты, переделки, рекламации)

стоимость выполнения (cost per unit или трудозатраты на юнит)

устойчивость (критические инциденты, безопасность, текучесть в ключевых ролях)

Ключевое правило: у мотивации должны быть управляемые метрики, иначе это превращается в лотерею.

Типовые ошибки мотивации, которые часто видит COO

бонус только за снижение затрат без метрик качества и сроков

метрики, которыми легко «манипулировать» (переносить закрытия, менять классификацию дефектов)

слишком много KPI без приоритета

общий бонус «для всех» без привязки к контролируемому вкладу

Организационная культура в операциях: что реально влияет на результат

Культура — это набор привычек, которые проявляются каждый день.

Для COO критичны:

культура ответственности (владелец результата известен)

культура прозрачности (проблемы поднимают рано, а не прячут)

культура улучшений (проблема рассматривается как повод улучшить стандарт)

Здесь полезна логика непрерывных улучшений: Kaizen.

Как связать людей, процессы, KPI и финансы в одну систему

COO строит «замкнутый контур управления», где элементы усиливают друг друга.

процессы описаны и имеют владельцев

KPI процесса связаны с финансовыми строками (через драйверы)

руководители регулярно разбирают отклонения и запускают улучшения

улучшения закрепляются стандартом (регламент, SOP, обучение)

мотивация поддерживает нужное поведение и не поощряет «читерство»

Как использовать материал в вашем плане развития к COO

Опишите текущую оргструктуру операций и найдите 3–5 «серых зон», где нет владельца результата.

Назначьте владельцев ключевых сквозных процессов и зафиксируйте RACI на стыках функций.

Определите минимальный управленческий ритм (ежедневный, еженедельный, ежемесячный) и артефакты: дашборды, протоколы решений, реестр улучшений.

Проверьте мотивацию: какие KPI реально стимулируются и не противоречат ли они операционной стратегии.

Сформируйте «профиль руководителя операций» (ожидаемые компетенции и результаты) и план развития ключевых руководителей.

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

Зачем COO проектное управление и управление изменениями

В предыдущих статьях курса мы разобрали:

роль COO и KPI (как измеряется выполнение)

связь бизнес-модели и операционной стратегии (какие компромиссы компания выбирает)

процессы, улучшения и стандарты (как менять поток работы)

финансы для COO (как изменения отражаются в P&L и кэше)

людей и оргструктуру (кто обеспечивает выполнение и как закреплять ответственность)

Проектное управление и управление изменениями связывают всё это в практику внедрения.

COO выигрывает не от того, что у компании есть хорошие идеи, а от того, что:

изменения доходят до внедрения без остановки операций

риски и зависимости управляются заранее

результат закрепляется стандартом и метриками, а не держится на энтузиазме

Справочно:

Project management

Change management

Проект, продукт, процесс и операционный стандарт

Для COO важно различать несколько сущностей.

| Сущность | Простое определение | Пример | Чем управляет COO | |---|---|---|---| | Процесс | повторяемая работа | обработка заказов | стабильность, скорость, качество, cost per unit | | Проект | временная работа ради изменения | внедрение WMS на складе | сроки, бюджет, риски, эффект | | Продукт | то, что создаёт ценность на рынке | сервис доставки, SaaS-модуль | совместно с продуктом: способность операций выполнить обещание | | Стандарт | закреплённый лучший способ работы | регламент + SOP + обучение | удержание изменений в повседневности |

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

Как COO выбирает, что внедрять: портфель изменений

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

Чтобы портфель не превратился в хаос, COO вводит правила отбора инициатив.

Критерии отбора инициатив

Удобно оценивать каждую инициативу по нескольким осям.

| Критерий | Вопрос | Пример управленческого вывода | |---|---|---| | Влияние на ценность | укрепляем ли обещание клиенту | проект повышает SLA, значит имеет приоритет | | Финансовый эффект | влияет ли на маржу, переменные затраты, потери | снижение дефектов уменьшает переделки и | | Риск для операций | есть ли шанс остановить основной поток | сначала пилот и параллельный контур | | Срок эффекта | когда увидим результат | быстрые изменения правил приоритизации раньше IT-проекта | | Зависимости | от кого зависит (IT, поставщики, юристы) | без владельцев зависимостей проект не стартует |

Принцип COO: ограничения по мощности на изменения

Операции ограничены не только ресурсами на выполнение, но и ресурсами на изменения.

Если перегрузить организацию внедрениями, появляются:

падение качества исполнения текущих операций

рост ошибок и сопротивления

саботаж через “не успеваем”, даже если люди не против идеи

Практическое правило: лучше меньше проектов, но с доведением до стандарта.

Минимальная “операционная система” проектного управления

COO не обязан быть профессиональным руководителем проектов в терминологии PMI, но обязан обеспечить управляемость.

Артефакты, которые дают управляемость

Паспорт проекта (Project Charter)

План работ и контрольные точки

RAID-лог: риски, допущения, проблемы, зависимости

Роли и ответственность (обычно через RACI)

План коммуникаций и внедрения

Метрики эффекта и план закрепления стандарта

Связь с предыдущими статьями:

RACI описана в теме про роль COO и людей: Responsibility assignment matrix (RACI)

Паспорт проекта: что обязательно фиксировать

Паспорт проекта нужен, чтобы убрать размытые ожидания и спор “что мы вообще делаем”.

Проблема и цель

Область проекта

Метрики успеха

Владелец результата

Команда и ключевые роли

Ограничения и допущения

Риски и зависимости

План по этапам и контрольные точки

Важно: метрики успеха должны быть связаны с KPI операций и финансовыми драйверами из предыдущих статей.

Управление сроками и объемом: как не утонуть в “почти готово”

Треугольник ограничений

У любого проекта есть три связанных ограничения:

объём работ (что именно делаем)

сроки (когда)

ресурсы/стоимость (какими силами и за сколько)

Если меняется одно, обычно меняется одно из остальных. Задача COO не допускать скрытых изменений объёма.

Управление зависимостями и критическим путём

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

Полезная концепция: критический путь, то есть цепочка задач, которая определяет срок проекта.

Critical path method

COO может не строить идеальные сетевые графики, но обязан иметь:

список зависимостей с владельцами

правила эскалации, если зависимость срывается

Риски: как COO управляет неопределённостью

Риск, проблема и допущение

Чтобы команда не путала термины:

Риск: может случиться в будущем

Проблема (issue): уже случилось и влияет на проект

Допущение: мы считаем, что это правда, но должны проверить

Матрица риска: вероятность и влияние

Один из самых понятных подходов: оценивать риск по двум параметрам.

вероятность (насколько вероятно)

влияние (насколько больно для сроков, качества, бюджета, операций)

Иногда используют упрощённый показатель “экспозиция риска”:

Где:

— условная “сила” риска для приоритизации

— оценка вероятности (например, по шкале 1–5)

— оценка влияния (например, по шкале 1–5)

Смысл: риски с высокой вероятностью и высоким влиянием должны быть наверху списка и иметь план действий.

Справочно:

Risk management

План реакции на риск

Для каждого существенного риска COO требует один из вариантов.

избежать (меняем план так, чтобы риск исчез)

снизить (уменьшаем вероятность или влияние)

перенести (например, на поставщика по контракту)

принять (но тогда нужен триггер и план, что делаем при наступлении)

Ключевой момент: у риска должен быть владелец и дата пересмотра.

Подходы к управлению проектами: когда “водопад”, когда “agile”

COO важно выбирать подход под тип задачи, а не “по моде”.

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

Справочно:

Waterfall model

Agile software development

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

Управление изменениями: как сделать так, чтобы новое реально заработало

Проект может быть завершён формально, но изменение не внедрено. Для COO важно управлять принятием изменения.

Карта заинтересованных сторон

COO должен видеть, кого изменение затрагивает.

кто меняет привычную работу

кто теряет влияние или контроль

кто получает выгоду

кто будет “первой линией” поддержки после запуска

Сопротивление изменениям: нормальная реакция системы

Сопротивление обычно возникает не потому, что люди “плохие”, а потому что:

непонятно, зачем это нужно

есть риск потери статуса или дохода

нет навыков и времени на обучение

предыдущие изменения “не долетали” и сформировали цинизм

Одна из известных моделей изменения: Kotter's 8-step change model

План внедрения

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

Коммуникации

Обучение и материалы

Изменение регламентов и SOP

Поддержка в первые недели

Контроль соблюдения нового стандарта

Важно: если регламенты не обновлены, через месяц никто не вспомнит “как теперь правильно”.

!Диаграмма показывает, что внедрение не заканчивается запуском и требует этапа закрепления

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

Governance: кто и как принимает решения

COO выстраивает структуру управления проектами, чтобы решения принимались быстро и прозрачно.

Типовая структура:

спонсор (обычно CEO/COO) принимает ключевые решения и защищает проект

руководитель проекта управляет планом и командой

владельцы процессов отвечают за внедрение в операционной реальности

IT, финансы, HR, безопасность участвуют по зонам ответственности

Ритм контроля

Контроль должен быть регулярным и одинаковым для портфеля.

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

контрольные точки по этапам: готовность к пилоту, готовность к запуску

разбор результата после запуска: метрики эффекта и причины отклонений

Статус-отчёт: что важно COO, а не “процент готовности”

“80% готово” почти неуправляемо, если не ясно, что в оставшихся 20%.

COO полезнее видеть:

выполненные контрольные точки

список открытых рисков и проблем с владельцами

список зависимостей и что блокирует критический путь

решения, которые нужны от руководства

прогноз даты запуска и основания прогноза

Запуск и после запуска: гиперзабота и закрепление

Go-live без остановки операций

Чтобы не разрушить основную деятельность, COO обычно требует:

пилот на ограниченном сегменте

план отката (rollback), если запуск критично ломает поток

резервирование ресурсов на период запуска

правила приоритизации инцидентов

Гиперзабота

Гиперзабота — это короткий период усиленной поддержки, чтобы новое поведение стало нормой.

Часто включает:

выделенный канал обращений

ежедневный разбор проблем

быстрые правки инструкций и шаблонов

мониторинг ключевых метрик процесса

Закрепление результата через стандарт

Из статьи про процессы: улучшение удерживается только когда есть стандарт.

COO проверяет, что после проекта:

обновлены регламенты и SOP

обучены новые и текущие сотрудники

метрики внесены в регулярные дашборды

назначен владелец процесса, который отвечает за соблюдение стандарта

есть аудит выполнения (проверяем практику, а не наличие документа)

Типовые ошибки внедрений, которые должен предотвращать COO

Проект не привязан к KPI и финансовым драйверам, поэтому “не ясно, зачем”

Нет владельца результата на стороне операций, проект остаётся “IT-историей”

Нет управления зависимостями, и всё срывается на стыках

Запуск без пилота и без плана отката, из-за чего страдают клиенты

Нет гиперзаботы и закрепления стандартом, поэтому всё возвращается “как было”

Мотивация и KPI людей противоречат новому процессу, и система сопротивляется

Как использовать материал в вашем плане развития к COO

Выберите одну инициативу улучшения (из портфеля процессов) и оформите паспорт проекта с метриками успеха.

Соберите RAID-лог и назначьте владельцев рисков и зависимостей.

Опишите план внедрения: коммуникации, обучение, обновление регламентов, гиперзабота.

Настройте ритм контроля: еженедельный статус и контрольные точки готовности.

После запуска сравните метрики “до/после” и закрепите результат стандартом и аудитом соблюдения.

Это даст вам практическое доказательство компетенций будущего COO: вы умеете не только придумать улучшение, но и довести его до устойчивого результата в ежедневных операциях.

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

Зачем нужен личный трек развития к роли COO

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

COO нанимают и повышают не за «понимаю, как надо», а за три вещи:

Опыт в управлении сквозным результатом (скорость, качество, стоимость, устойчивость)

Кейсы с измеримым эффектом и понятной логикой решений

Коммуникации на уровне CEO/CFO/CTO/HR и руководителей функций

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

!Схема показывает, какие уровни опыта и артефактов обычно ведут к роли COO

Как определить целевой профиль COO именно для вашей компании

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

Быстрый способ зафиксировать контур

Опишите бизнес-модель и операционную стратегию компании (из предыдущей статьи про бизнес-модель).

Выпишите 3–5 сквозных процессов, которые создают ценность и деньги (из статьи про процессы).

Зафиксируйте, какие функции чаще всего входят в контур COO в вашей отрасли.

Сверьте ожидания с CEO: какую проблему должен решить COO.

Результат, который должен получиться

Таблица ожиданий по роли (как документ для разговора с руководством).

| Блок | Что зафиксировать | Пример формулировки | |---|---|---| | Цель роли | зачем нужен COO | «Стабилизировать выполнение, снизить потери качества, подготовить масштабирование» | | Контур ответственности | какие функции и процессы входят | «Delivery, поддержка, качество, планирование мощности, операционная аналитика» | | KPI результата | что считаем успехом | «SLA, OTIF, cost per unit, дефекты, инциденты, текучесть в ключевых ролях» | | Ожидаемые изменения | что должно стать “по-другому” | «Ритмы управления, стандартизация, понятные эскалации, портфель улучшений» |

Если границы ответственности не согласованы, роль COO часто превращается в «директора по тушению пожаров». Для фиксации границ используйте RACI из первой статьи: Responsibility assignment matrix (RACI).

Стратегия набора опыта: что именно нужно “добыть”, чтобы быть COO

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

Управление сквозным процессом end-to-end

Это развитие из логики статьи про процессы: вы отвечаете не за участок, а за результат “от входа до выхода”.

Признаки, что опыт засчитывается как end-to-end:

есть единые границы процесса (старт и финиш)

есть метрики результата и драйверы

есть владельцы этапов и понятные эскалации

есть улучшения, закрепленные стандартом

Управление экономикой исполнения

Из статьи про финансы: COO должен связывать операции и деньги.

Что важно уметь показать:

какие операционные драйверы влияют на маржу и переменные затраты

как вы делали разбор отклонений план–факт и находили операционные причины

как вы защищали ресурсы или инвестиции через бизнес-кейс

Справочная база по управленческому учету: Management accounting.

Управление руководителями и оргсистемой

Из статьи про людей и оргструктуру: COO масштабируется через слой руководителей.

Опыт, который “считается”:

выстроенные управленческие ритмы (ежедневные, еженедельные, ежемесячные)

договоренность о зонах ответственности и правилах взаимодействия

развитие руководителей, делегирование владения результатом

Управление изменениями и портфелем внедрений

Из статьи про проекты и изменения: COO должен доводить изменения до стандарта.

Опыт, который “считается”:

портфель проектов и приоритизация инициатив

управление рисками и зависимостями (RAID-лог)

план внедрения, обучение, гиперзабота, аудит соблюдения стандарта

Справочно: Project management и Change management.

Портфель кейсов: как собирать доказательства компетенций COO

Одна из типовых ошибок кандидатов на COO: рассказывать «чем занимался» вместо «какой результат сделал и как». Вам нужен портфель из 5–8 кейсов, где каждый демонстрирует один или два ключевых навыка COO.

Структура кейса, которая понятна CEO и C-level

Оформляйте каждый кейс одинаково, в формате «одной страницы».

Контекст

Проблема в измеримых терминах

Гипотеза причин

Решение и почему оно выбрано

Внедрение и контроль

Результат в метриках

Что закрепили стандартом

Что бы сделали иначе

Важно: метрики кейса должны быть связаны с темами курса.

метрики процесса (сроки, SLA, дефекты) из статьи про процессы

финансовый след (cost per unit, переменные затраты, потери) из статьи про финансы

управляемость (владельцы, ритмы, RACI) из статей про роль COO и оргструктуру

Какие кейсы лучше всего показывают “уровень COO”

стабилизация исполнения (снижение инцидентов, рост соблюдения SLA)

снижение потерь качества (дефекты, переделки, возвраты)

рост пропускной способности без пропорционального роста штата

внедрение системы управления (ритмы, KPI, единые определения метрик)

кросс-функциональный проект с зависимостями (IT, финансы, продажи)

Мини-шаблон “реестра кейсов”

| Кейс | Сквозной процесс | Метрика “до” | Метрика “после” | Финансовый эффект | Что закрепили | |---|---|---:|---:|---:|---| | Сокращение цикла обработки | лид → заказ → отгрузка | 7 дней | 3 дня | меньше ручного труда | регламент + SOP + дашборд | | Снижение дефектов | производство/сервис → качество | 4.5% | 2.1% | меньше переделок | контроль качества на раннем этапе |

Коммуникации COO: как говорить с CEO, CFO, CTO и руководителями функций

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

Карта стейкхолдеров и ожиданий

Стейкхолдеры это те, на кого влияет результат вашей работы, и кто влияет на ваш результат. Справочно: Stakeholder (corporate)).

Практичный артефакт: таблица «ожидания и обмен».

| Стейкхолдер | Что ему важно | Что ему нужно от вас | Что вам нужно от него | Риск конфликта | |---|---|---|---|---| | CEO | рост и предсказуемость | выполнение стратегии | ясные приоритеты | размытые цели | | CFO | маржа и кэш | управление драйверами затрат | правила аллокаций, данные | спор о цифрах | | CTO/CIO | стабильность и архитектура | понятные требования и приоритизация | сроки, ресурсы, SLA | “IT виноват” | | Руководители функций | автономия и ресурсы | ясные правила взаимодействия | владельцы процессов, KPI | локальная оптимизация |

Протокол разговора “операционно и на данных”

Чтобы обсуждение не превращалось в эмоции, держите структуру:

Что видим в метриках (единые определения)

Что это значит для клиента и денег

Где узкое место в потоке

Какие варианты решения и компромиссы

Какой выбор предлагаете и какие риски

Какие решения нужны от стейкхолдера

Это напрямую продолжает подходы из статей про KPI, процессы и финансы.

Коммуникации в конфликтах

COO часто выступает медиатором между функциями. Рабочие принципы:

отделяйте людей от проблемы

фиксируйте единые определения метрик до обсуждения причин

переводите спор в плоскость компромиссов операционной стратегии

завершайте разговор решением, владельцем и сроком

Для развития навыка полезны практики активного слушания: Active listening.

Личный бренд и “упаковка” результата

Личный бренд в корпоративной среде это не самопиар, а предсказуемая репутация. Для будущего COO полезно быть известным как человек, который:

делает выполнение стабильным

договаривается между функциями

управляет на данных

доводит изменения до стандарта

Артефакты, которые повышают доверие к вам как к COO

дашборды KPI со словарем метрик

карта сквозного процесса и владелец процесса

регламент и SOP, которые реально используются

“мост” между KPI процесса и строками P&L

паспорт проекта и RAID-лог по внедрениям

портфель инициатив и правила приоритизации

Эти артефакты напрямую следуют из предыдущих статей курса и превращаются в ваше портфолио.

Карьерный план к COO: как построить реалистичный трек

Карьерное развитие это управляемый переход между типами ответственности. Справочно: Career development.

Логика трека: от роли к доказательствам

Сильный план строится от целевого контура COO к пробелам.

Зафиксируйте целевой контур COO в вашей компании (раздел выше).

Оцените текущий опыт по 4 слоям (процесс, финансы, люди, изменения).

Найдите 2–3 разрыва, которые больше всего мешают быть COO.

Выберите проекты, которые закрывают разрывы и дают измеримый эффект.

Согласуйте с руководителем: что именно вы берете в ответственность и как это будет измеряться.

Пример развития на 12 месяцев

Ниже пример, как можно собрать план так, чтобы он дал и результат компании, и ваш рост.

| Период | Фокус | Что сделать | Артефакты | Метрики успеха | |---|---|---|---|---| | 0–3 месяца | Диагностика и быстрые улучшения | выбрать 1 сквозной процесс, собрать факты, убрать 2–3 источника потерь | карта процесса, словарь метрик, план улучшений | сокращение цикла, снижение дефектов | | 3–6 месяцев | Система управления | владельцы процесса, ритмы, регламенты, дашборды | RACI, регламент, SOP, календарь ритмов | стабильность SLA, меньше эскалаций | | 6–9 месяцев | Финансовая связка | драйверный бюджет, мост KPI → P&L, бизнес-кейс на автоматизацию | драйверы бюджета, бизнес-кейс | снижение cost per unit, эффект в марже | | 9–12 месяцев | Масштабирование и изменения | портфель инициатив, внедрение, гиперзабота, аудит стандарта | паспорт проекта, RAID-лог, аудит | устойчивость после внедрения |

Как обсуждать повышение до COO: разговор на языке роли

Цель разговора не «дайте должность», а «давайте закроем риск/ограничение бизнеса, и я беру ответственность». Опирайтесь на то, что мы разбирали в первой статье про роль COO и KPI.

Что важно принести в диалог:

согласованный контур ответственности (что входит, что не входит)

5–9 KPI COO, сбалансированных по скорости, качеству, стоимости и устойчивости

портфель кейсов с эффектом

план на 90 дней: что будет сделано, какие решения нужны от CEO, какие риски

Типовые ошибки в личном треке развития к COO

вы берете много задач, но без end-to-end ответственности, и не видно результата

у вас есть проекты, но нет закрепления стандартом, и эффект откатывается

вы улучшаете процесс, но не связываете это с экономикой и приоритетами стратегии

вы конфликтуете со стейкхолдерами вместо того, чтобы фиксировать компромиссы и правила

вы не “упаковываете” результаты в артефакты, и ваш вклад трудно оценить

Как использовать материал статьи на практике

Зафиксируйте целевой контур COO и ожидания от роли в вашей компании.

Составьте матрицу пробелов: какие из 4 слоев опыта вам не хватает больше всего.

Сформируйте портфель из 5–8 кейсов по шаблону «одной страницы».

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

Сделайте 12-месячный план, где каждый квартал дает артефакты и измеримый эффект.

Так вы соединяете все темы курса в одну линию: стратегия → процессы → метрики → финансы → люди → изменения → доказуемый опыт и рост до COO.