Chief Operating Officer (COO) / Операционный директор

Зачем эта роль

COO существует, потому что у компании должен быть один человек, который держит операционную производственную среду как готовый сервис для тех, кто производит ценность для внешнего клиента. Без COO производственные роли (CVD, PM, FDE, AIA) тратят значительную часть энергии не на клиента, а на то, чтобы достроить себе инфраструктуру: получить доступы, договориться о регламентах, восстановить потерянные знания, выровнять стандарты работы между разными аккаунтами. Это паразитная нагрузка, которая в неструктурированной компании ложится на плечи CVD-руководителей и снижает их способность работать с клиентом.

COO снимает эту нагрузку. Его роль — не быть заметным. Когда COO работает хорошо, операционная среда «невидима»: CVD не думает о IT, PMO, регламентах и стандартах клиентского пути; всё это работает само. Когда COO работает плохо, это сразу видно как поток внутренних блокеров.

В отличие от производственных ролей, COO — Administrator в логике PAEI. Его сильная сторона — систематизация, стандартизация, наведение порядка. Его слабая сторона (в смысле того, что НЕ должно быть в его зоне) — продуктовое творчество и работа с клиентом. Он удерживает компанию в работающем производственном состоянии, не двигает её на новые рынки.

Что входит в операционную производственную среду

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

• IT — корпоративная IT-инфраструктура компании: рабочие места, корпоративные аккаунты, сервисы, доступы, базовая инфобез-гигиена. Через подчинённого System Administrator. Это техническая основа, на которой работает вся ежедневная деятельность команды и клиентских проектов.
• PMO (Project Management Office) — стандарты ведения проектов: шаблоны запуска, форматы отчётности, чек-листы эскалации, регламент разбора по итогам. Это инфраструктура для PM, чтобы каждый проект шёл по проверенной механике.
• Customer Path / стандарты клиентского пути — единые форматы работы с клиентом между аккаунтами компании. Шаблон квартального обзора, форма tNPS-опроса, протокол передачи аккаунта от CSO к CVD. Это стандарты, которыми CVD пользуются вместо изобретения форматов заново для каждого клиента.
• Internal Knowledge — управление знаниями компании. База SOP/регламентов в Notion, шаблоны типовых ситуаций, поддержание актуальности, процесс пополнения. Это память компании, делающая её менее зависимой от конкретных людей.

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

Кадровая функция (рекрутинг, оформление, адаптация, удержание) находится под GM, не под COO. Это сознательное разделение: COO держит производственную операционку, GM — юридическо-финансово-кадровую дееспособность компании. COO координируется с GM по плану найма (какие роли нужны в дивизионах, в каком темпе), но кадровый pipeline ведёт GM через HR Manager.

NOTA как нулевой клиент Digital Shift

COO — внутренний заказчик применения методологического стека Digital Shift к самой компании. NOTA является «нулевым клиентом» собственной методологии: компания применяет к себе те же дисциплины, которые потом продаёт клиентам. COO заказывает у PO Digital Shift применение блоков, относящихся к управлению знаниями, операционным процессам и стандартизации клиентского пути, и доводит их до работающей конфигурации внутри NOTA.

Это даёт CVD на проектах работающую референс-конфигурацию: «методология работает у нас самих, можем показать клиенту, как мы это делаем».

COO и PO Digital Shift: разделение ролей

COO и PO Digital Shift — обе работают с методологическим стеком компании, обе влияют на то, как организована работа. Но они работают на разных сторонах одной системы и решают разные задачи. Это разделение критично, потому что иначе функция методологии будет либо размыта между двумя ролями, либо концентрироваться в одной с потерей профессионального качества.

Короткая формулировка:

• PO Digital Shift владеет методологическим стеком как продуктом: что в стеке есть, какие блоки добавить, какие переработать, что в стеке больше не работает. Горизонт — эволюция продукта на годы.
• COO владеет процессами и регламентами компании: как стек применяется внутри NOTA, какие SOP нужны, какие стандарты клиентского пути ввести, как организован PMO, IT, Internal Knowledge. Горизонт — операционная управляемость на месяцы и кварталы.

В чём это проявляется:

Когда это важно понимать:

• Когда CVD приносит паттерн с проекта — решает PO Digital Shift, входит ли паттерн в стек
• Когда нужно внедрить стандарт работы внутри компании (например, общий формат квартального обзора с клиентом) — решает COO, как это раскатать
• COO — главный внутренний потребитель PO Digital Shift: NOTA как нулевой клиент применяет стек первой, до внешних клиентов
• Эволюция методологии — итеративный диалог между ними: PO Digital Shift проектирует, COO внедряет внутри, обратная связь корректирует и продукт, и внедрение

COO и System Administrator: разделение ролей

COO и System Administrator — обе работают с IT-средой компании. Но они работают на разных уровнях ответственности. Без чёткого разделения либо COO втягивается в технические заявки и теряет стратегический фокус, либо Sysadmin остаётся без управления и IT превращается в реактивную функцию.

Короткая формулировка:

• COO держит IT-стратегию и стандарты компании: какие корпоративные системы используются, как организована инфобез-политика, какой бюджет на IT, какой стек развивается. Горизонт — устойчивость IT-среды на месяцы и кварталы.
• System Administrator ведёт операционный IT-контур: заявки, инциденты, доступы, реестр инфраструктуры, ежедневная коммуникация с вендорами. Горизонт — каждый IT-инцидент и заявка по мере появления.

В чём это проявляется:

Когда это важно понимать:

• Когда возникает стратегический IT-вопрос (новый сервис, изменение стека, серьёзный инфобез-инцидент) — решает COO, не Sysadmin
• Когда нужно решить инцидент или обработать заявку — это зона Sysadmin под управлением COO
• COO отвечает перед CVD за итог (IT не блокирует работу); Sysadmin отвечает перед COO за исполнение

Продукт должности

Операционная производственная среда компании — работающая IT-инфраструктура, стандартизованные процессы delivery (PMO), единые стандарты клиентского пути и систематизированные знания компании, которыми CVD-руководители пользуются как готовой инфраструктурой, не строя её с нуля. Накопленные знания компании передаваемы и снижают зависимость от конкретных людей. NOTA как нулевой клиент Digital Shift применяет к себе блоки методологического стека, доводя их до работающей конфигурации и формируя референс для внешних внедрений. CVD получает производственную среду «невидимой» — фокусируется на клиенте, не достраивая инфраструктуру вручную.

Главный потребитель и его требования

Главный потребитель: CVD-руководители (получают рабочую производственную инфраструктуру как готовый сервис).

CVD-руководитель получает от COO не «обещания, что когда-нибудь будет», а работающую среду, в которой он может фокусироваться на клиенте. Конкретные требования:

• IT-инфраструктура «невидима». CVD не должен думать о доступах, VPN, корпоративных системах, рабочих ноутбуках. Всё работает или восстанавливается за часы, не за дни. Sysadmin под COO ведёт операционный IT-контур, COO держит стандарты и стратегию.
• Процессы delivery помогают, а не мешают. Регламент проектного офиса (PMO) даёт PM работающие шаблоны запуска, отчётности, разбора по итогам — и не превращается в бюрократию для отчёта.
• Стандарты клиентского пути единые между аккаунтами. Когда CVD ведёт несколько клиентов, базовые форматы (шаблон квартального обзора, форма tNPS-опроса, протокол передачи аккаунта от CSO) — общие для компании, а не каждый CVD изобретает заново.
• Знания компании передаваемы. CVD ожидает, что в Notion есть SOP/регламент по типовой ситуации; находит его за минуты, не за дни. Если нет — есть процесс его создания.
• Кросс-CVD стандарты качества работают. Когда два CVD работают на одном клиенте (один ведёт аккаунт, другой подключается с компетенциями своего дивизиона), есть единый минимум стандартов работы и quality gate, не нужно заново договариваться по каждому случаю.
• Эскалации к COO решаются предсказуемо. Когда у CVD возникает операционный блокер, который он не может решить внутри своего дивизиона, COO принимает блокер, классифицирует, ставит срок устранения. Блокер не «теряется», даже если решение требует времени.

Вторичный потребитель: CEO — получает невидимость операционки. В рутинном режиме CEO не должен заниматься внутренними производственными проблемами компании; он подключается только при стратегических решениях (бюджет, изменение оргструктуры, кризисы). Когда CEO начинает регулярно тратить время на операционные блокеры — это сигнал, что COO работает плохо.

Run / Change / Disrupt

Run (поддержание потока)

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

• Контроль операционных блокеров CVD: ежедневный мониторинг реестра, разбор причин, постановка задач на устранение
• Управление подчинённым: System Administrator (операционный IT-контур)
• Курирование PMO: контроль регламентов проектного офиса, шаблонов, чек-листов; реакция на сигналы от PM о пробелах в инфраструктуре
• Поддержание стандартов клиентского пути: единые форматы работы с клиентом, согласованные с CVD-руководителями; контроль применения
• Управление internal knowledge: контроль базы SOP/регламентов в Notion, поддержание её актуальности, процесс пополнения новыми SOP
• Координация кросс-CVD стандартов качества: когда два дивизиона работают на одном клиенте, COO держит quality gate; разбор спорных случаев
• Координация с GM по плану найма: какие роли нужны в дивизионах, в каком темпе; обратная связь GM о фактической комплектации команд
• Ежеквартальный чек-ин CVD ↔ COO ↔ CEO с разбором CVD Satisfaction Score и операционных блокеров

Change (улучшение того, как роль работает)

То, что COO делает на горизонте квартала, чтобы операционка становилась лучше:

• Анализ паттернов в реестре операционных блокеров — какие категории доминируют, где системные проблемы
• Развитие internal knowledge как актива: какие SOP создать, какие переработать, какие удалить как устаревшие
• Эволюция стандартов клиентского пути по обратной связи от CVD
• Внедрение блоков методологического стека Digital Shift в работу NOTA как нулевого клиента (по согласованию с PO Digital Shift)
• Развитие компетенций System Administrator — рост, наставничество, обучение
• Эволюция IT-стандартов и инфобез-политики компании по мере роста и появления новых требований
• Корректировка кросс-CVD стандартов качества по фактической динамике совместных проектов

Disrupt (переизобретение роли)

То, что меняет саму конфигурацию роли в системе:

• AI-усиление операционки: автоматическое выявление операционных блокеров из транскриптов встреч, AI-ассистент для генерации SOP по типовым ситуациям, автоматическая проверка соответствия регламентам
• Превращение internal knowledge в самообновляющуюся систему: SOP/регламенты обновляются автоматически по факту изменений в работе, не вручную
• Переход от «COO держит регламенты» к «компания работает по работающему методологическому стеку» — внедрение блоков Digital Shift достигает зрелости, при которой стандарты не нужно отдельно администрировать
• AI-усиление IT: автоматическая обработка типовых заявок, превентивный мониторинг IT-инцидентов, автогенерация инвентарных записей
• Сокращение размера операционного аппарата за счёт AI: меньше людей в PMO/Internal Knowledge/IT при той же или большей пропускной способности

Метрики

COO измеряется композитом из 3 метрик, покрывающих все три ноги EEQ (Effectiveness / Efficiency / Quality). Все метрики ориентированы на восприятие со стороны главного потребителя — CVD-руководителей.

Логика композита: одна метрика — итоговый замер главного обещания (нет операционных блокеров и они быстро решаются). Вторая — детализация одного из критических каналов блокеров (IT). Третья — голос потребителя в стандартизованной форме (восприятие CVD операционки COO в целом). Метрики дополняют друг друга по треугольнику «факт / детализация / восприятие». Если факт-метрика низкая, но восприятие тоже низкое — значит блокеры не фиксируются в реестре, а дискомфорт CVD проявляется как фоновый. Если IT-детализация высокая, но общая факт-метрика по IT низкое — значит инциденты есть, но не доходят до уровня блокирования бизнеса (это норма).

Полный список метрик с определениями и порогами — в свойстве Metrics ниже.

🟢 Full Zone of Genius (зона полной автономии)

Решения, которые COO принимает сам, без согласования с кем-либо. Это широкая зона в производственно-операционных вопросах, ограниченная границей с производственными ролями (CVD), стратегическими (CEO), продуктовыми (PO Digital Shift) и юридическо-финансово-кадровыми (GM).

• Структура и регламенты PMO. Какие шаблоны запуска проекта использовать, как структурировать чек-лист эскалации, как проводить разбор по итогам проекта. CVD получает результат как готовый сервис, не диктует процесс.
• Стандарты IT-инфраструктуры компании (внутри согласованного бюджета). Какие корпоративные системы использовать, как организован доступ, как структурирован onboarding в IT, какая базовая инфобез-политика. Sysadmin реализует под управлением COO.
• Структура и формат internal knowledge. Как организована база SOP/регламентов в Notion, какие категории, как структурированы шаблоны, кто и в каком темпе обновляет. COO решает сам.
• Стандарты клиентского пути компании. Когда несколько CVD приходят с разными практиками работы с клиентом, COO решает, какую из них взять как стандарт компании, в какой форме раскатать, как валидировать.
• Кросс-CVD стандарты качества. Базовая модель quality gate при работе двух дивизионов на одном клиенте, процедура разрешения спорных случаев по операционным вопросам. CEO утверждает рамку, COO внутри неё держит конкретные правила.
• Организация ежеквартального чек-ина CVD ↔ COO ↔ CEO. Формат, повестка, формат разбора метрик. COO готовит, CEO модерирует, CVD участвуют.
• Кадровые решения внутри своего подчинённого (System Administrator). Найм, ротация, увольнение, развитие. COO принимает решения сам, координируясь с GM/HR Manager по процедурным аспектам и с CEO по бюджетным.
• Решение по приоритезации операционных блокеров. Какой блокер срочный, какой может ждать, какой системный и требует переработки процесса целиком. COO решает по контексту.

Принцип: всё, что касается как организована производственная операционная среда компании внутри согласованной стратегии — это зелёная песочница COO. Зрелость COO измеряется тем, насколько CEO может не вмешиваться в его операционку в рутинном режиме.

🟡 Decisions Requiring Collaboration (коллегиальные решения)

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

• Годовой бюджет операционки (расходы на IT, PMO, internal knowledge, оплата подчинённого) → с CEO и GM. Как: COO формулирует план на основе текущей операционной нагрузки и стратегии компании, GM проверяет влияние на финансовую модель, CEO утверждает на годовом плане; план становится basis для рамочных решений COO внутри года.
• План найма по производственным дивизионам → с GM и CVD-руководителями. Как: CVD приносят прогнозы по своим дивизионам, COO агрегирует производственные потребности, GM формулирует общий план найма (включая бюджет ФОТ), CEO утверждает.
• Изменения оргструктуры компании (новые роли, изменение подчинения, реорганизация дивизионов) → с CEO и Diwan. Как: COO формулирует операционное обоснование, CEO выносит на Diwan, решение принимается на стратегическом уровне.
• Внедрение блоков методологического стека Digital Shift внутри NOTA как нулевого клиента → с PO Digital Shift. Как: COO формулирует, какой блок нужно внедрить и зачем (по обратной связи от CVD), PO Digital Shift валидирует готовность блока, помогает с адаптацией; COO внедряет.
• Превращение локальной практики CVD в стандарт компании → с этим CVD и (при кросс-применимости) другими CVD-руководителями. Как: COO видит, что у CVD появилась рабочая практика, обсуждает применимость с другими CVD, при согласии раскатывает на компанию; при разногласиях выносит на CEO.
• Стандартизация процессов работы с клиентом (общий формат QBR, общая форма tNPS-опроса, шаблон диагностики клиента) → с CVD-руководителями. Как: COO формулирует предложение стандарта, собирает обратную связь от CVD, итерирует, утверждает финальную версию после согласования.
• Серьёзные изменения в стандартах работы CVD (новый общий регламент, изменение принципов взаимодействия CVD ↔ COO) → с всеми CVD-руководителями. Как: COO выносит на ежеквартальный чек-ин, обсуждение коллективное, решение принимает CEO при разногласиях.
• Операционные регламенты, затрагивающие финансовую или кадровую сторону (регламент платежей, согласование расходов, командировки, корпоративные карты, регламенты внутренних коммуникаций по HR-темам) → с GM. Как: GM формулирует финансовую/кадровую часть, COO внедряет как операционный регламент компании.
• Серьёзные инфобез-инциденты или изменения IT-стека → с CEO и (при стратегическом масштабе) Shareholders. Как: COO формулирует риск/изменение, варианты реакции, рекомендацию; CEO принимает решение.

🔴 Decisions That Should Never Be Made (зона запрета)

Решения, которые COO не принимает ни в одиночку, ни в коллаборации.

• Работа с клиентом по конкретному проекту или аккаунту. Это зона CVD. COO держит инфраструктуру, в которой CVD ведёт клиента; не вмешивается в стратегию аккаунта, не общается с ЛПР клиента, не принимает решений по конкретным проектам.
• Привлечение новых клиентов и продажи. Это зона CSO и CVD. COO не участвует в воронке продаж и не делает коммерческих предложений.
• Эволюция методологического стека компании (что добавить в стек, как переработать, что в стеке больше не работает). Это зона PO Digital Shift. COO внедряет существующие блоки внутри NOTA, но не решает, что войдёт в стек.
• Технические решения внутри проектов клиентов. Это зона FDE и AIA. COO держит общую IT-инфраструктуру компании, но не выбирает технологии, на которых работают клиентские проекты.
• Управленческие решения внутри клиентских проектов (структура спринтов, ритуалы, делегирование). Это зона PM. COO держит общий регламент проектного офиса, но не вмешивается в управление конкретным проектом.
• Кадровая функция компании (рекрутинг, оформление, адаптация, удержание, кадровые ритуалы, eNPS, оффбординг). Это зона GM через HR Manager. COO координируется с GM по плану найма, но не ведёт кадровый pipeline.
• Стратегические решения о направлении развития компании (выход на новые рынки, запуск новых продуктовых линий, M&A). Это зона CEO и Diwan. COO участвует в обсуждении как член C-Suite, но не принимает решение.
• Кадровые решения по найму C-Suite ролей (новый CSO, CVD, PO Digital Shift, GM). Это зона CEO и Shareholders. COO может высказать мнение по операционной совместимости, но решение не его.
• Маркетинговая стратегия компании. Это зона CMO. COO держит инфраструктуру, в которой работает маркетинг, но не определяет позиционирование, рынки или содержание сообщений.
• Финансовая стратегия компании, инвестиционные решения, стратегия P&L. Это зона GM и CEO. COO работает в рамках утверждённого годового бюджета, но не определяет финансовую модель компании.
• Культура компании, ценности, идентичность команды. Это зона CEO. COO держит производственные стандарты и регламенты, не культуру.

Принцип: красная песочница COO — это граница с производственным контуром (CVD, PM, FDE, AIA, проекты клиентов), граница с продуктовым контуром (PO Digital Shift, методологический стек), граница с коммерческим контуром (CSO, CMO), граница со стратегическим контуром (CEO, Diwan), граница с юридическо-финансово-кадровым контуром (GM, Accountant, HR Manager) и граница с культурой (CEO). COO держит производственную операционную среду внутри компании; попытка зайти в любой из этих контуров подменяет другие роли и снижает качество системы.

Цикл PDCA

COO управляет двумя вложенными циклами с разной частотой. Внешний цикл — управление производственной операционной средой компании целиком; внутренний — управление каждым операционным блокером по мере его появления.

Цикл управления операционным блокером (короткий, по факту блокера)

• Plan — фиксация блокера: запись в реестр CVD Operational Blockers, классификация (IT / PMO / Customer Path / Internal Knowledge / Кросс-CVD стандарты / Прочее), определение, разовая ситуация или системная.
• Do — устранение блокера: постановка задачи подчинённому или себе, сопровождение до закрытия, коммуникация с CVD-заявителем; при кадровых блокерах — координация с GM/HR Manager как смежной зоной.
• Check — закрытие блокера: фиксация даты решения, подтверждение от CVD, что блокер устранён; самоконтроль времени до решения относительно цели.
• Act — корректировка процесса: если блокер системный — постановка задачи на изменение процесса/регламента; если разовый — фиксация в копилку прецедентов.

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

• Plan — годовой/квартальный план: согласованный с CEO и GM годовой бюджет операционки, согласованная с CVD-руководителями стратегия стандартизации, реестр приоритетов на квартал.
• Do — ведение операционки: курирование System Administrator, управление PMO, поддержание internal knowledge, внедрение блоков Digital Shift по согласованию с PO Digital Shift, координация кросс-CVD стандартов качества, координация с GM по плану найма.
• Check — квартальный замер метрик домена; ежеквартальный чек-ин CVD ↔ COO ↔ CEO под модерацией CEO; разбор паттернов блокеров и разрезов CVD Satisfaction Score.
• Act — корректировка операционной среды: переработка регламентов с системными блокерами, обновление стандартов клиентского пути, инициирование внедрения новых блоков Digital Shift, эволюция кросс-CVD стандартов качества.

Внутренний цикл (блокер) питает внешний (среда): паттерны в реестре блокеров формируют картину системных проблем, которая определяет приоритеты квартала. Внешний цикл задаёт рамки для внутреннего: согласованный бюджет и стратегия определяют допуски, в которых COO решает по конкретным блокерам.