Клубок начинается не на тридцатом сценарии, а на первом сценарии без имени и владельца. Число здесь второстепенно: тридцать аккуратно названных и описанных сценариев с явным ответственным управляются спокойно, а восемь безымянных, собранных тремя разными людьми за два года, уже неуправляемы. Разница не в объёме, а в том, существует ли карта запусков и человек, который за неё отвечает.
Проблема в том, что переход в это состояние не сопровождается событием. Никто не объявляет «с сегодняшнего дня мы не понимаем свою автоматизацию». Просто в какой-то момент на вопрос «что сломается, если выключить вот этот сценарий» перестаёт быть ответ, и компания начинает обходить собственную автоматизацию стороной: вместо правки существующего сценария собирают новый, потому что так безопаснее.
Ниже — шесть симптомов с порогами, при которых пора вмешиваться, расчёт годовых потерь от клубка и три процедуры, которые лечат его силами своего сотрудника за двадцать часов: карта на одном листе, правило именования и карантин на тридцать дней.
Шесть симптомов и порог по каждому
Симптомы известны и звучат банально, поэтому их пропускают. Полезны они становятся, когда к каждому приделан измеримый порог: не «кажется, у нас многовато дублей», а «два сценария пишут в одну сущность — значит, разбираемся сегодня».
| Симптом | Порог, при котором пора вмешиваться | Что это значит на самом деле |
|---|---|---|
| Два сценария делают почти одно и то же, но чуть по-разному | Два и более сценария пишут в одну сущность одной системы | Данные расходятся, и никто не знает, какой из двух результатов верный |
| Есть сценарии, назначение которых никто не помнит | Больше 10 % парка. В модельных 30 сценариях таких семь — 23 % | Парк рос быстрее, чем описывался; часть сценариев работает вхолостую |
| Кто-то регулярно перезапускает прогон руками | Больше двух ручных перезапусков в неделю по одному сценарию | Сценарий не капризный, а сломанный: нет ретраев и очереди необработанного |
| Клиент получает письмо, а отправителя не знает никто | Один случай — уже симптом | Реестра сценариев не существует, и найти источник можно только перебором |
| Никто не берётся оценить последствия отключения узла | Нет ответа за 10 минут по любому сценарию из парка | Карты запусков нет, и любое изменение делается вслепую |
| Правка вносится сразу в боевой контур | Хоть одна правка за месяц без копии и без записи | Версий нет: откатиться после неудачной правки будет нечем |
Таблица-сравнение из шести строк в две колонки. Слева симптом, справа порог: дубли — два сценария пишут в одну сущность; сценарии без владельца — больше 10 % парка (в модели 7 из 30); ручные перезапуски — больше двух в неделю по одному сценарию; письмо от неизвестного отправителя — один случай; нет ответа о последствиях отключения — 10 минут; правка в боевом контуре — один случай за месяц. Строки с превышенным порогом отмечены сплошной заливкой, остальные штриховкой. Внизу подпись «в модельном парке превышено четыре порога из шести». Чертёжный стиль, подписи по-русски.
Во что клубок обходится за год
Считаем на том же модельном парке: 30 сценариев, 150 000 операций в месяц, внутренний час 1 100 ₽, час инженера подрядчика 3 500 ₽, цена операции 0,15 ₽. Клубок — это не отдельная строка бюджета, а надбавка, размазанная по остальным: лишние операции, лишние часы и лишняя работа подрядчика.
Самая крупная строка здесь — не аварии, а пересборка. Пять раз в год кто-то не находит нужный сценарий и собирает новый: так парк растёт быстрее процессов, а число дублей увеличивается, и следующий поиск становится ещё дороже. Это и есть механизм, за счёт которого клубок затягивается сам собой. Полная структура расходов на парк сценариев — с подпиской, доработками и часами владельца — разобрана в отдельном материале о стоимости владения за год; здесь считается только надбавка за беспорядок.
Карта на одном листе: два часа и один сотрудник
Карта запусков — это не схема архитектуры и не документация. Это один лист, на котором видно, кто кого запускает и в какие объекты систем пишут два сценария сразу. Собирается за два часа силами человека, который в конструкторе разбирается, но программистом не является. Никаких инструментов, кроме таблицы и листа бумаги, не нужно.
- 1Выписать все сценарии в один столбец — 20 минут
Включая выключенные и черновики. Выключенные важны отдельно: они не работают, но продолжают держать выданные под них доступы к вашим системам.
- 2Против каждого — чем запускается — 30 минут
Четыре варианта: событие в системе, расписание, вебхук извне, другой сценарий. Последний вариант — самый интересный: именно из него растут цепочки, о которых никто не помнит.
- 3Провести стрелки «кто кого запускает» — 20 минут
Сценарий, который вызывает другой сценарий, соединяется стрелкой. На этом шаге обычно обнаруживается цепочка из трёх звеньев, о которой в компании знал один человек, и он в отпуске.
- 4Отметить узлы, в которые пишут два и более сценария — 20 минут
Одна сущность в одной системе — сделка, задача, остаток, письмо клиенту. Каждый такой узел обводится: это готовый или будущий дубль, и разбирать надо именно их, а не весь парк подряд.
- 5Пометить сценарии без входящих стрелок и без владельца — 15 минут
Кандидаты в карантин. Не в удаление: пока неизвестно, что сломается, выключать без процедуры нельзя.
- 6Подписать владельца у каждого сценария — 15 минут
Фамилия, а не отдел и не «маркетинг». Отдел не разбирает упавший прогон в пятницу вечером, это делает человек. Сценарии, у которых фамилия не нашлась, попадают в карантин вместе с предыдущим пунктом.
Ценность карты в том, что она отвечает на единственный вопрос, ради которого всё затевалось: что сломается, если выключить конкретный узел. По карте это видно за десять секунд — по входящим и исходящим стрелкам. Второй эффект появляется на четвёртом шаге: обведённые узлы дают точный список мест, где данные расходятся, и именно там обычно и лежит причина расхождений в отчётности, которые до этого списывали на человеческий фактор. Часть обведённых узлов после разбора логичнее закрыть готовым решением каталога — распределением заявок или автозаполнением карточки в CRM, — чем держать под них два конкурирующих сценария.
Карта связей на одном листе. Слева колонка источников запуска: событие в системе, расписание, вебхук извне, другой сценарий. В центре — тридцать небольших прямоугольников-сценариев, соединённых стрелками «кто кого запускает», среди них видна цепочка из трёх звеньев. Справа колонка систем-приёмников: 1С, amoCRM, почта клиенту, склад. Три узла приёмников обведены двойной рамкой с подписью «пишут два сценария — будущий дубль». Семь прямоугольников помечены биркой «нет владельца — карантин». У каждого прямоугольника подпись с фамилией владельца. Внизу пометка «два часа, один сотрудник».
Правило именования и карантин на 30 дней
Половина проблем клубка лечится одним правилом именования, потому что имя — это единственное, что видит человек в списке из тридцати строк. Рабочая формула короткая: источник, действие, приёмник, владелец. Например: «Сайт · заявка → сделка в amoCRM · Иванов». К ней две запретных строки: в имени не бывает слов «новый», «тест», «копия», «финальный», «версия 2» — они устаревают в тот же месяц и через год означают ровно противоположное. Группировать сценарии надо по процессу, а не по системе: человек ищет «всё про заявки с сайта», а не «всё, что трогает amoCRM».
Дальше — карантин для тех сценариев, назначение которых не смог объяснить ни один сотрудник. Процедура нужна потому, что удалять их страшно, а оставлять дорого, и в этом состоянии они живут годами.
- 1Не удалять. Перевести в выключенное состояние, в описании записать дату выключения и фамилию того, кто выключил.
- 2Оставить заглушку там, где сценарий что-то принимал. Вместо обработки она пишет в журнал «сюда пришло событие» — так вы узнаете, что кому-то этот вход всё-таки был нужен.
- 3Объявить публично. Список выключенных сценариев с датой — в общий рабочий канал, а не в личную переписку с ИТ. Ответ «а это было моё, верните» приходит в первые три дня.
- 4Ждать 30 дней. Календарный месяц покрывает большинство месячных циклов; если сценарий связан с квартальной отчётностью, срок карантина — 100 дней.
- 5По истечении срока: пусто в журнале заглушки и ни одной жалобы — удалять вместе с подключениями.
Остановленный сценарий продолжает существовать как учётная запись с правами: токен к CRM, ключ к учётной системе, доступ к почтовому ящику. При инвентаризации такие доступы находятся регулярно, в том числе оформленные на почту уволенных сотрудников. Поэтому в карточке карантина всегда две галочки: сценарий остановлен и выданные под него доступы отозваны. Первая галочка снижает счёт за операции, вторая снижает риск, и без неё уборка остаётся косметической.
Когда нужен отдельный ответственный — и когда карту делать не надо
Порог считается через часы, а не через число сценариев. Парк требует примерно 25–30 минут в месяц на сценарий: разбор прогонов, мелкие правки, ответы коллегам. Для тридцати сценариев это те самые 14 часов в месяц, которые мы разбирали в расчёте стоимости владения. Отсюда три ступени.
- До 18 сценариев — около 8 часов в месяц. Роль исполняется в фоне тем, кто собирал сценарии, и этого достаточно. Нужны только имена по правилу и паспорт на полстраницы у каждого сценария.
- От 18 до 40 сценариев — 8–19 часов в месяц. Роль назначается явно: фамилия, часы в графике, замещающий на время отпуска. Без этого шага парк переходит в клубок в течение года почти гарантированно.
- Больше 40 сценариев — свыше 19 часов в месяц. Это полставки, и её надо либо оформить, либо передать подрядчику по договору поддержки: что в такой договор входит и как считаются сроки реакции, мы описали на отдельной странице. Держать такой парк «в свободное время» не получается ни у кого: часы всё равно тратятся, но за счёт основной работы человека.
И честная часть: карта нужна не всем и не всегда. Три ситуации, в которых её рисовать не стоит. Первая — парк меньше восьми сценариев, собранных одним человеком за последние полгода: здесь хватит списка в таблице, а два часа лучше потратить на паспорта. Вторая — вы через месяц переезжаете на другую платформу: тогда нужна инвентаризация под переезд, она подробнее и решает другую задачу. Третья, самая важная: если запутан сам процесс, карта сценариев его не распутает. Клубок в автоматизации часто оказывается точным отражением клубка в работе компании — четыре согласования там, где хватило бы одного, и три системы, где данные ведутся параллельно. В этом случае перерисовывание сценариев только закрепит беспорядок, и начинать надо с описания процесса, а не с конструктора.
Сценарий без имени и фамилии владельца — это не автоматизация, а долг, по которому платят часами.
