• Серия voir-pages
  • стр. 08 / 26
  • отдел 1 из 8
  • реализовано 0 станций

Операции — это не «следить, чтобы работало». Это конвейер из пяти станций, мониторинг и эскалация без самообмана.

Операционный отдел в VOIR AI держит повторяющиеся процессы: задача входит в регламент, разбирается в план, исполняется с журналом действий, проходит независимый контроль и уходит в отчёт владельцу. Сверху над лентой — мониторная шина: пробы по расписанию, а не «когда кто-то заметил». Снизу — шина эскалации: всё, что станция не решила сама, уходит человеку, а не теряется молча. Ниже — честная картина: что отдел должен делать по целевой архитектуре, что уже работает у нас внутри как собственный инструмент, и как отдел встроен в цикл AI CEO.

Продукт VOIR AI · реализовано ноль станций Экосистема Marisova · диспетчер задач и журнал решений

Смотреть конвейер отдела Статусы честно

Демонстрация · конвейер отдела

Одна задача, пять станций, три обслуживающих контура

Конвейер без шины эскалации выглядит идеально и врёт: в нём каждая задача доходит до отчёта. Реальная схема другая. На любой станции работа может остановиться — не хватает данных, нет доступа, решение выходит за грейд автономии роли. Тогда задача уходит вниз, на шину эскалации, и дальше владельцу вместе с описанием того, что именно не получилось. Сверху ленту сопровождает мониторная шина: пробы идут по расписанию, а не по факту чьего-то внимания. Ниже — та же структура, что описана текстом в разделе «Пять станций».

Структурные числа страницы: 5 станций конвейера, 3 обслуживающих контура, 8 отделов в архитектуре, 0 реализованных станций в продукте.

Конвейер · задача → станции → эскалация → отчёт → следующий прогон

Демонстрация · подготовленный сценарий
TRG PLN EXE CHK RPT Регламент План Исполнение Контроль Отчёт демо: 0 демо: 0 демо: 0 демо: 0 демо: 0 возврат на доработку MON · МОНИТОРНАЯ ШИНА ESC · ШИНА ЭСКАЛАЦИИ CYC · ПЕТЛЯ СЛЕДУЮЩЕГО ПРОГОНА IN Задача на входе RPT Прогон закрыт ESC Эскалация владельцу СТАТИЧНАЯ СХЕМА · движение отключено
  1. INЗадача входит на ленту от AI CEO вместе с критериями готовности, зафиксированными до старта. Без критериев задача на ленту не принимается: контролировать будет нечего.
  2. TRGСтанция регламента: процесс сверяется с записанным — шаги, владелец каждого шага, вход и выход, что считается готовым. Если регламента нет, он создаётся и фиксируется до начала работы.
  3. PLNСтанция плана: задача разбирается на шаги с зависимостями и сроками, исполнители назначены, артефакт каждого шага назван заранее.
  4. EXEСтанция исполнения: шаги выполняются, каждое действие пишется в журнал — что сделано, чем, когда, какой артефакт получен. Журнал — часть результата, а не служебная информация.
  5. CHKСтанция контроля: результат сверяется с критериями регламента ролью, которая работу не выполняла. Вердикт — VERIFIED или возврат на доработку с перечнем расхождений.
  6. RPTСтанция отчёта: прогон сводится в отчёт владельцу — что сделано, что отклонено, что сорвалось по сроку, какое решение осталось за человеком.
  7. MONМониторная шина: пробы по расписанию спускаются к станциям и проверяют, что контур жив. Отклонение фиксируется с доказательством; решение о вмешательстве принимает человек или станция по заранее записанному правилу.
  8. ESCШина эскалации: задача, которую станция не смогла решить сама, уходит владельцу с описанием шага и причины. Молча отбросить задачу станция не может — эскалация записывается как результат шага.
  9. CYCПетля следующего прогона: отчёт меняет регламент. Замечания контроля, сорванные сроки и эскалации возвращаются на станцию TRG, и следующий прогон идёт по исправленному процессу.

Демонстрация использует заранее подготовленный сценарий и не подключена к живому AI-сервису. Счётчики «демо» под станциями считают только точки этого сценария: в статичном кадре и при отключённой анимации они равны нулю. Это не SLA, не пропускная способность и не данные о реальных процессах клиентов — клиентов у проекта нет.

Целевая архитектура

Пять станций: вход, работа, выход, артефакт

Станция — не «этап работы вообще», а контракт: что входит, что делается, что выходит и какой артефакт остаётся после шага. Если у станции нет артефакта, её невозможно проверить независимо, а значит невозможно и улучшить. У всех пяти станций на этой странице один статус: в продукте VOIR AI они не реализованы.

TRG 01 / 05
Целевая архитектура

Регламент

  • входповторяющийся процесс или задача, для которой процесса ещё нет
  • выходзаписанный регламент: шаги, владельцы, критерий готовности каждого шага

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

артефактрегламент процесса: шаги, владелец каждого шага, вход и выход, критерий готовности, условия эскалации

PLN 02 / 05
Целевая архитектура

План

  • входзадача от AI CEO, регламент, ограничения по сроку и ресурсу
  • выходплан прогона: шаги, зависимости, исполнители, названные артефакты

План отличается от списка дел тем, что в нём видны зависимости: что нельзя начать, пока не закончено другое, и что произойдёт, если шаг сорвётся. Артефакт каждого шага называется заранее — до исполнения, а не придумывается после. Иначе невозможно отличить сделанную работу от отчёта о ней.

артефактплан прогона с зависимостями и сроками, назначенные исполнители, перечень ожидаемых артефактов по шагам

EXE 03 / 05
Целевая архитектура

Исполнение

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

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

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

CHK 04 / 05
Целевая архитектура

Контроль

  • входартефакт шага, журнал исполнения, критерии готовности из регламента
  • выходвердикт: VERIFIED или возврат на доработку с перечнем расхождений

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

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

RPT 05 / 05
Целевая архитектура

Отчёт

  • входпроверенные артефакты, вердикты контроля, эскалации, срывы сроков
  • выходотчёт владельцу и правки регламента на следующий прогон

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

артефактотчёт владельцу: сделано, отклонено, сорвано, эскалировано; список правок регламента на следующий прогон

Мониторинг

Мониторная шина: что проверяется по расписанию

Мониторинг, который включается только когда кто-то заметил проблему, — это не мониторинг, а реакция по факту. Шина MON устроена иначе: у каждой пробы есть расписание, измеряемая величина, порог и заранее записанная реакция. Ниже — целевая архитектура контура наблюдения; каждая проба объявлена до того, как может понадобиться.

каждый шаг

Жив ли контур

Проба на станцию: отвечает ли процесс, движется ли лента, не остановился ли прогон на одном шаге. Измеряется факт движения, а не наличие «зелёного» статуса.

порог: простой дольше заданного · реакция: запись в журнал и эскалация

каждый прогон

Соблюдён ли регламент

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

порог: любое расхождение · реакция: возврат на станцию TRG

по расписанию

Не устарел ли результат

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

порог: расхождение с текущим состоянием · реакция: пересчёт и пометка в отчёте

каждая эскалация

Не копятся ли нерешённые

Шина ESC разбирается: каждая эскалация должна получить решение человека и отметку о закрытии. Эскалация без ответа — это не «ждем», а потерянная задача, и шина обязана это показать.

порог: эскалация без решения · реакция: повторное уведомление владельца

каждый отчёт

Не ложно-зелёный ли гейт

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

порог: гейт без негативного контроля · реакция: пометка «не проверено» в отчёте

Расписание и пороги — параметры целевой архитектуры, а не статистика: они задают ритм наблюдения, в котором сбой обнаруживается пробой, а не жалобой. Реальных данных о том, какие интервалы работают лучше, у проекта нет, потому что продукт не запущен; выдумывать «среднее время обнаружения» мы не будем. Как отдел получает задачи на вход и кто ставит критерии — описано в разделе «Цикл AI CEO» и на странице AI CEO.

Автоматизация рутины

Из чего состоит записанный процесс

Автоматизировать можно только то, что записано. «Сделай как в прошлый раз» — не регламент: в прошлый раз могло повезти. Поэтому станция TRG требует одинакового набора полей у любого процесса, который претендует на повторяемость. Процесс без этих полей остаётся ручной работой, и мы говорим об этом прямо, а не называем его автоматизацией.

01

Шаги и порядок

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

02

Владелец каждого шага

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

03

Вход и выход шага

Что шаг принимает на вход и какой артефакт оставляет. Артефакт называется до исполнения: если формулировать его после, легко выдать за результат то, что просто получилось.

04

Критерий готовности

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

05

Условия эскалации

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

06

Порядок пересмотра

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

Отчётность

Отчёт: что в нём есть и чего нет намеренно

Отчёт операционного отдела существует не для того, чтобы показать объём работы. Его задача — дать владельцу возможность принять решение: что остановить, что повторить, где не хватает данных. Поэтому состав отчёта объявлен заранее, и половина его строк — про то, что не получилось.

Что входит в отчёт

  • Сделанные шаги и артефакты каждого — со ссылкой на место, где артефакт лежит
  • Вердикты независимого контроля: что проверено, чем именно проверено, что подтверждено
  • Отклонённые артефакты с перечнем расхождений, а не общей формулировкой «не прошло»
  • Сорванные сроки и зависимости, которые из-за этого сдвинулись
  • Эскалации: какие решения остались за человеком и на каком шаге
  • Правки регламента, которые этот прогон предложил на следующий
  • Открытые вопросы и явные отметки «нет данных» там, где данных действительно нет

Чего в отчёте нет намеренно

  • Выдуманных процентов эффективности и «ускорения в разы» — измерять пока нечего
  • Сглаженных формулировок: «в целом выполнено» вместо перечня расхождений
  • Скрытых эскалаций: решение человека не подаётся как автоматический результат
  • Зелёных статусов без доказательства: у каждого «проверено» называется инструмент проверки
  • Метрик, которые нельзя перепроверить по журналу исполнения
  • Чужих заслуг: если работу сделала другая роль, в отчёте названа она

Правки регламента — не приложение к отчёту, а его главная выходная часть: именно они замыкают петлю CYC и делают следующий прогон лучше предыдущего. Отчёт, после которого процесс не изменился, остаётся протоколом намерений. Устройство приёмки, через которую проходят артефакты, описано на странице «Цикл AI CEO»; роли, которые выполняют шаги, — на странице «AI-сотрудники».

Статусы

Честная матрица: продукт и экосистема — разные вещи

Самая частая ошибка таких страниц — показать внутренний рабочий инструмент так, будто это возможность продукта. Мы разделяем два столбца. Первый: что реализовано в продукте VOIR AI (сейчас — ни одной станции конвейера). Второй: что уже работает у нас внутри экосистемы Marisova как собственные инструменты. Второй столбец не продаётся и клиенту не предоставляется.

Статус функций операционного отдела на 2 ноября 2026 года. Проверено по коду, конфигурации и живым URL — не по планам.
Функция В продукте VOIR AI В экосистеме Marisova (внутреннее)
Регламенты процессов (TRG) не реализовано
Целевая архитектура: записанный процесс с критериями		 работает
Регламенты существуют как файлы задач и описания конвейеров в нашем рабочем каталоге: у задачи есть постановка, границы и критерий закрытия. Клиентам как сервис не предоставляется
План прогона (PLN) не реализовано
Целевая архитектура: план с зависимостями и сроками		 работает
Очередь задач с состояниями: в работе, заблокировано, выполнено, отказано. Порядок и блокировки видны, но это наш внутренний диспетчер, а не продукт
Исполнение с журналом (EXE) не реализовано
Целевая архитектура: артефакт шага плюс журнал действий		 работает
Каждая задача оставляет отчёт о выполнении и записи в журнале решений; отчёты проверяются отдельно от исполнителя. Внутренний инструмент
Независимый контроль (CHK) не реализовано
Целевая архитектура: вердикт роли, не выполнявшей работу		 работает
Практика независимой приёмки существует: заявленное проверяется по диску, git и живым URL, а не по отчёту исполнителя. Продуктом не является
Отчёт владельцу (RPT) не реализовано
Целевая архитектура: отчёт прогона с правками регламента		 работает
Отчёты по задачам пишутся в единый каталог результатов и читаются владельцем; часть — с явными отметками о блокерах. Внутренний контур
Мониторинг по расписанию (MON) не реализовано
Целевая архитектура: пробы, пороги, записанная реакция		 работает
Планировщик запускает наблюдателя и пробы работоспособности по расписанию; есть живой журнал срабатываний. Наши собственные инструменты
Эскалация человеку (ESC) не реализовано
По архитектуре — обязательный выход станции		 работает
Правило соблюдается фактически: необратимые действия и действия на проде требуют подтверждения, блокировки задач фиксируются явно, а не замалчиваются
Операционный дашборд для клиента не реализовано
Целевая архитектура: состояние процессов в одном месте		 прототип
Локальная карта состояния внутренних процессов существует как прототип для нас. Это не клиентский интерфейс и не публичный сервис

Метка работает относится к нашим внутренним инструментам, которые мы используем в своих проектах. Это не функция продукта VOIR AI и не обещание клиенту. Никаких цифр о пропускной способности, SLA или «ускорении рутины» здесь нет намеренно: клиентов у проекта нет, продукт не запущен. Фактический статус проекта публикуется на странице «О платформе»; устройство платформы — на странице AI Operating System.

Связь с AI CEO

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

Операции в VOIR AI — исполнительная часть цикла AI CEO. Задачу принимает AI CEO, он же решает, что уходит в операции: настройка повторяющегося процесса, контроль сроков, разбор сбоя в цепочке исполнения. Он же сводит результат в отчёт владельцу. Артефакты отдела проходят независимую приёмку ролью, которая работу не выполняла. Таблица ниже — что именно делает отдел на каждом из пяти шагов цикла.

  1. 01 Постановка задачи Отдел получает бриф и критерии готовности, зафиксированные до старта: какой процесс берём, что считается результатом, какие ограничения по доступам и необратимым действиям. Сам себе задачи операции не ставят — иначе отдел начинает «оптимизировать» то, что никто не просил менять.
  2. 02 Анализ и распределение AI CEO решает, какая часть работы уходит в операции, и распределяет её по ролям отдела: регламент — одной роли, план и зависимости — другой, исполнение и журнал — третьей, контроль — четвёртой. Фиксируется грейд автономии: что роль делает сама, а что обязательно уходит на подтверждение владельца.
  3. 03 Исполнение Роли ведут задачу по станциям: регламент, план, исполнение, артефакты. Каждая роль ведёт след действий и отдаёт артефакт дальше вместе с источниками фактов или явной отметкой «нет данных». Необратимые действия и действия на живых системах на этом шаге требуют подтверждения человека.
  4. 04 Независимая проверка Роль QA, которая не вела этот прогон, сверяет артефакты с критериями шага 1: существует ли артефакт на диске, воспроизводима ли проверка, нет ли ложно-зелёного гейта, честно ли отражены блокеры. Вердикт — VERIFIED или REJECT с перечнем расхождений.
  5. 05 Приёмка и отчёт AI CEO сводит проверенные артефакты в один отчёт владельцу: что сделано, что отклонено, что сорвалось по сроку, какие решения остались за человеком, какие правки регламента предлагаются на следующий прогон. Отклонённые артефакты и срывы попадают в отчёт как есть, без сглаживания.

Роли отдела в целевой архитектуре

PRC

Процессный инженер

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

SCH

Диспетчер расписания

Ведёт станции PLN и EXE: разбирает задачу на шаги с зависимостями, назначает исполнителей, держит журнал исполнения и следит за тем, чтобы срыв шага был виден сразу, а не в конце прогона.

OBS

Наблюдатель контура

Ведёт шину MON: пробы по расписанию, пороги, доказательства отклонений. Не чинит сам — фиксирует и передаёт на станцию исполнения или владельцу вместе с тем, чем именно измерено.

Артефакты, которые оставляет отдел

  • Регламент процессашаги, владельцы, вход и выход, критерий готовности, условия эскалации
  • План прогоназависимости, сроки, назначенные исполнители, ожидаемые артефакты
  • Журнал исполненияпоследовательность действий, время, источники, отметки об эскалациях
  • Вердикт контроляперечень проверенных критериев и чем именно проверен каждый
  • Журнал отклонений мониторингапробы, пороги, факт отклонения, доказательство, реакция
  • Реестр эскалацийчто ушло человеку, на каком шаге, какое решение принято, закрыто ли
  • Отчёт прогонасделано, отклонено, сорвано, эскалировано, правки регламента

Точки взаимодействия с соседними отделами

  • AI CEO → операции Задача приходит с критериями готовности и грейдами автономии. Без них станция контроля не может вынести вердикт, а процесс превращается в работу «на глаз».
  • Разработка → операции AI-агенты и интеграции дают отделу инструменты исполнения; операции в ответ требуют от них журнала действий и явных ошибок, а не тихого fallback.
  • Операции → поддержка Сбой в цепочке исполнения, найденный мониторной шиной, уходит в поддержку как инцидент с описанием и доказательством, а не как «что-то не работает».
  • Операции → маркетинг и продажи Сроки и зависимости из плана прогона — вход для маркетинга и продаж: обещать клиенту дату можно только тогда, когда она видна в плане.
  • Операции → владелец и QA Все артефакты станций уходят на независимую приёмку, а необратимые действия — на эскалацию владельцу. Роль не объявляет прогон закрытым самостоятельно.

Как устроен отдельный исполнитель — на странице AI-агенты; как штаб собирает несколько отделов под одну задачу — на странице AI-команды; роли по всем отделам — на странице AI-сотрудники.

Границы

Чего операционный отдел не делает никогда

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

Не чинит молча

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

Не подменяет результат похожим

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

Не доверяет зелёному гейту

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

Не выдумывает метрики и клиентов

Ни SLA, ни процентов успешных прогонов, ни «ускорения рутины в разы», ни отзывов и логотипов. Если данных нет — стоит отметка «нет данных». На этой странице нет ни одной цифры эффективности, потому что продукт не запущен.

Не выполняет необратимое без человека

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

Не принимает свою работу сам

Самопроверка роли остаётся, но в отчёт идёт только вердикт независимой приёмки. Регламент или журнал, не дошедшие до контроля, для отчёта не существуют.

Вопросы

Что спрашивают про AI-операции

Операционный отдел уже работает?

Как продукт VOIR AI — нет. Все пять станций конвейера на этой странице описывают целевую архитектуру: в коде продукта не реализована ни одна. Демонстрация ленты показывает заранее подготовленный сценарий и не подключена к живому AI-сервису. Отдельно существует экосистема Marisova, где диспетчер задач, журнал решений, наблюдатель за сессиями и пробы работоспособности существуют как наши собственные инструменты. Продуктом VOIR AI они не являются и клиентам не предоставляются.

Что значит статус «Целевая архитектура»?

Это честная отметка того, что функция описана в проекте, но не реализована в продукте. Мы разделяем два статуса: «Целевая архитектура» — так отдел должен работать по проекту VOIR AI; и «работает в экосистеме» — инструмент уже существует и используется нами внутри. Смешивать их нельзя: второй статус не означает, что эту возможность получает клиент.

Мониторинг сам чинит сбои?

Нет, и это архитектурное решение, а не временное ограничение. Мониторная шина обнаруживает отклонение и фиксирует его с доказательством; решение о вмешательстве принимает человек или станция исполнения по заранее записанному правилу. Автоматическое «починить всё само» — это ровно тот сценарий, при котором сбой маскируется, а не устраняется: система отчитывается зелёным, а работа стоит.

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

Она уходит на шину эскалации ESC и дальше владельцу — вместе с описанием того, что именно не получилось, на каком шаге и почему. Задача не отбрасывается молча и не помечается выполненной. Эскалация — нормальный выход станции, а не аварийный сценарий: регламент обязан описывать условия, при которых шаг передаётся человеку, и эти условия объявляются до начала работы.

Какие метрики показывает конвейер?

Никаких метрик эффективности на этой странице нет намеренно: ни SLA, ни процентов успешных прогонов, ни времени обнаружения сбоя, ни «ускорения рутины». Счётчики «демо» под станциями считают только точки подготовленного демонстрационного сценария, а в статичном кадре и при отключённой анимации равны нулю. Структурные числа — пять станций, три обслуживающих контура, восемь отделов в архитектуре, ноль реализованных станций.

Как операционный отдел связан с AI CEO?

Отдел не ставит себе задачи сам. Задачу и критерии готовности принимает AI CEO, он же распределяет работу между ролями отдела — процессным инженером, диспетчером расписания и наблюдателем контура, — сводит результат в отчёт владельцу и решает, что менять в следующем цикле. Артефакты станций проходят независимую приёмку ролью QA, которая этот прогон не вела. Подробно — на страницах AI CEO и Цикл AI CEO.

Можно ли использовать операционный отдел отдельно от платформы?

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

Куда идти из этой страницы

Операционный отдел — один из восьми: задачу ставит AI CEO, инструменты даёт разработка, а сроки из плана читают маркетинг и продажи.

Процесс

Цикл AI CEO

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

Открыть → Исполнители

AI-агенты

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

Открыть → Связки отделов

AI-команды

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

Открыть →

Посмотреть тарифы Задать вопрос о платформе