Регламент изменений — это маршрут заявки из пяти шагов, тестовый контур и календарь дней, когда в систему не вносят ничего. Нужен он не ради порядка в бумагах: работающие системы ломаются в основном не от аварий, а от быстрых правок, сделанных в обход — по звонку, в пятницу вечером, сразу в рабочую систему и без записи о том, что именно поменяли.
Обход выглядит выгодным со всех сторон: заявка — это дни ожидания, а звонок знакомому разработчику — двадцать минут, правка мелкая, бюджет не тратится. Цена всплывает через неделю, когда что-то считается неправильно, и полдня уходит на вопрос, менялось ли вообще что-нибудь в системе.
Сквозной пример прежний: оптовая компания на 60 человек, внедрение за 1 200 000 ₽, четыре связанных куска — ассистент в клиентском канале, классификатор обращений, автозаполнение CRM и обмен с 1С:УТ. На втором году эксплуатации сюда приходит 3–5 заявок на изменения в месяц; ниже — как эти заявки должны ходить.
Маршрут заявки: пять шагов и одна подпись
Заявку подаёт кто угодно: если право просить есть только у руководителей, половина полезных мелочей не будет озвучена. А бюджет утверждает всегда один человек, и его имя известно всем заранее. Смешение этих правил — самая частая причина, по которой маршрут не работает.
| Шаг | Кто делает | Что именно | Срок | Результат |
|---|---|---|---|---|
| 1. Заявка | Любой сотрудник | Описывает словами, что происходит сейчас и что должно происходить. Технического решения не предлагает | — | Карточка с автором, датой и ожидаемым результатом |
| 2. Отбор | Владелец процесса | Решает, нужно ли это бизнесу, и назначает приоритет. Отклонение — обязательно с причиной | 2 рабочих дня | «В работу», «в очередь» или «отклонено, потому что» |
| 3. Оценка | Подрядчик | Часы, что затронет, какие риски, план отката | 2 рабочих дня | Оценка в часах и деньгах с описанием влияния |
| 4. Утверждение | Тот, у кого бюджет | Согласует часы. Один человек на всю компанию, а не по ситуации | 2 рабочих дня | Письменное согласие с указанием суммы |
| 5. Приёмка | Автор заявки вместе с владельцем процесса | Проверяет результат на тестовом контуре по описанию из шага 1 | — | Отметка в журнале изменений и выкладка в окно |
Пятый шаг пропускают чаще остальных, и зря: принимать правку должен тот, кто её попросил, — только он знает, что имел в виду. Приёмка руководителем, который видит задачу впервые, заканчивается формальным «работает» и повторной заявкой через месяц. Общий срок маршрута — 6–8 рабочих дней, и это число стоит объявить: ожидание без срока люди обходят.
Тестовый контур: сколько стоит второй экземпляр
Правка не выкладывается сразу в рабочую систему по одной причине: последствия изменения почти никогда не ограничиваются тем местом, куда его внесли. Условие скидки трогает расчёт в документах, документы уходят в обмен, обмен наполняет отчёты. Проверить это на глаз нельзя, а на копии — можно за полтора часа.
Отдельный экземпляр системы, устроенный так же, как рабочий, но работающий на копии данных и со своими адресами внешних сервисов. Обновляется из вчерашнего резерва по расписанию. Нужен трижды: для приёмки изменений, для прогона перед обновлением смежных систем и для разбора инцидента, когда воспроизвести проблему на рабочей базе нельзя.
- Второй экземпляр сервиса и место под копию базы — около 3 500 ₽ в месяц на российском хостинге.
- Настройка автоматического обновления копии и подмены внешних адресов — 4 часа инженера, 12 000 ₽ по ставке 3 000 ₽/час. Разово.
- Проверка раз в месяц, что копия свежая, — 1 час, 3 000 ₽. Итого 6 500 ₽ в месяц, или 78 000 ₽ в год.
- У копии свои ключи и свои адреса: контур, подключённый к боевой CRM и ЭДО, опаснее его отсутствия — прогон отправит тестовые документы реальным контрагентам.
Тот же контур закрывает подготовку к чужим обновлениям — прогон обмена по чек-листу разобран в материале о том, что делать, когда обновление ломает обмен. Одна инфраструктура на две задачи, поэтому 78 000 ₽ в год редко бывают спорной строкой.
Окно изменений и стоп-дни
Окно изменений — это заранее назначенное время, в которое выкладывают накопленные правки: например, вторник и четверг с 19:00. Стоп-дни — обратное: периоды, когда не выкладывают ничего, кроме исправления действующих аварий. Логика простая: цена ошибки в системе непостоянна, и в некоторые дни она умножается на десять.
| Период | Что запрещено | Что остаётся разрешено | Кто может снять запрет |
|---|---|---|---|
| Первые пять рабочих дней закрытия месяца | Любые правки, затрагивающие документы, цены, расчёты и обмен | Исправление аварий по открытому инциденту | Владелец процесса вместе с главным бухгалтером |
| Сезонный пик продаж | Правки в клиентском контуре и в сценариях ассистента | Правки внутренних отчётов и справочников | Владелец процесса |
| Отчётный период: квартал, год | Правки в учётном контуре и в обмене с ЭДО и госсистемами | Ничего, кроме аварий | Директор |
| Пятница после 15:00 и предпраздничные дни | Выкладка любых изменений | Подготовка, оценка и прогон на тестовом контуре | Руководитель подразделения |
| Отпуск администратора системы | Правки, которые некому принять и некому откатить | Работы, у которых есть второй ответственный | Владелец процесса |
Правило «не в пятницу после обеда» звучит как суеверие, а это арифметика реакции: правка, выложенная в 17:00 в пятницу, проявляется в понедельник, когда откатывать поздно — за выходные накопились новые документы. То же с закрытием месяца: после сформированной отчётности откат превращается из двадцати минут в работу на день.
План отката: четыре строки до правки, а не после
План отката — это часть заявки, а не действие в момент паники. Пишет его подрядчик на шаге оценки, читает владелец процесса на шаге утверждения. Четыре строки, каждая с конкретикой; формулировка «в случае чего восстановим из резервной копии» планом не является, потому что означает потерю всей работы, сделанной после начала правки.
- 1Что откатываем. Не «вернём как было», а объект и версия: сценарий обмена версии 14 от 3 сентября, настройка расчёта скидки. Если объект не назван, откатывать будут по памяти.
- 2Чем откатываем. Снимок базы, экспорт сценария, копия настройки — с указанием, где лежит и у кого доступ. Хранилище доступно администратору системы, а не только инженеру подрядчика.
- 3Кто решает и по какому признаку. Имя и измеримый триггер: расхождение счётчиков больше 1 % за час, три обращения от менеджеров по одной теме. Решение «по ощущению» принимается на час позже нужного.
- 4Сколько занимает и что делают люди. «20 минут, приём заявок переводится на почту». Без этой строки откат откладывают до вечера: непонятно, как эти минуты работать.
У самой возможности отката есть срок годности, и истекает он не по календарю, а по накоплению данных: как только появились документы по новым правилам, возврат к прошлой версии их испортит. Практическая граница — конец рабочего дня или закрытие периода. Та же логика для плановых обновлений учётной системы — в материале про обновление 1С после доработок.
Правка по звонку и журнал изменений
В модельной компании коммерческий директор попросил знакомого разработчика «поменять одно условие в скидке» напрямую — 28-го числа, минуя маршрут. Правка ушла сразу в рабочую систему. Условие сработало шире, чем предполагалось, и скидка стала считаться неверно на части заказов. Никто не связал две вещи, потому что о правке знали два человека, и оба были уверены, что она безобидная.
Пять часов поиска причины — это не сложность задачи, а отсутствие журнала изменений. Инженер начинает разбор любого инцидента с одного вопроса: что менялось за последние две недели. Без ответа он проверяет всё подряд. Журнал из пяти полей сокращает такой поиск до пятнадцати минут — и это единственная часть регламента, нужная даже там, где остальное избыточно.
- Дата и время выкладки — с точностью до минуты: сопоставлять придётся с журналами систем.
- Автор правки — фамилия, а не «подрядчик». Через полгода это единственный способ найти человека, который помнит контекст.
- Суть на языке бизнеса: «изменено условие скидки для оптовых клиентов от 300 000 ₽», а не «поправлен модуль расчёта».
- Ссылка на заявку — чтобы был виден автор, ожидаемый результат и подпись под бюджетом.
- Ссылка на версию или снимок для отката — то, что делает четвёртую строку плана отката исполнимой.
За самим регламентом достаточно следить по четырём числам раз в неделю — пять минут вместе с обычной сводкой. Ведёт администратор системы, читает владелец процесса.
- Изменений выложено за неделю. Норма — 0–2; всплеск до шести почти всегда означает, что что-то чинят наспех цепочкой правок.
- Изменений, выложенных без заявки. Единственное число, где допустим только ноль: одна такая строка — повод разобраться в тот же день.
- Заявок в очереди старше месяца. Растущая очередь означает, что маршрут стал узким местом и через квартал его начнут обходить.
- Откатов за месяц. Норма — не больше одного на десяток изменений. Больше означает, что прогон на тестовом контуре делается формально.
Порог для внепланового разговора с подрядчиком: два отката подряд либо изменение, выложенное без заявки. В первом случае проблема в приёмке, во втором — в договорённостях. Как это ложится на состав работ и включённые часы, разобрано в материале про то, что входит в поддержку системы.
Когда регламент избыточен
Полный маршрут с четырьмя согласованиями и тестовым контуром окупается не везде. Есть три случая, когда достаточно журнала из пяти полей и правила «не в пятницу».
- Систему меняет один человек, и он же ею владеет. В компании до 10–15 сотрудников заявка, оценка и утверждение сходятся в одной голове; остаётся журнал и прогон на копии.
- Изменение не касается денег, документов и клиентов: текст служебного письма, порядок полей, формулировка подсказки. Такие правки идут напрямую с записью в журнал.
- Система в первый месяц после запуска: правок много, и почти все они — устранение дефектов по гарантии. Маршрут вводят с третьего месяца, когда поток спадает до 3–5 в месяц, — что происходит в этот период, разобрано в материале про первый год эксплуатации.
И главное ограничение, о котором обычно молчат: регламент, который дольше самой правки, обходят все. Если путь от заявки до выкладки для двухчасовой мелочи занимает больше десяти рабочих дней, люди начнут звонить напрямую — и это проблема регламента, а не дисциплины. Решение — быстрая дорожка для правок до двух часов: тот же журнал и тот же прогон на копии, но без утверждения бюджета, потому что он утверждён заранее общим месячным лимитом.
И стоит проверить, не стал ли сам поток заявок симптомом. Если изменений больше десяти в месяц и они не мелкие, система расходится с процессом сильнее, чем её догоняют правками. Это уже развилка «дорабатывать или переписывать» со своими критериями и расчётом.
Работающую систему ломают не сложные проекты, а мелкие правки, о которых никто не записал.
