Цифровую зрелость оценивают до покупки разработки: автоматизировать хаос дорого даже с агентами

CRM, аналитика и подписки на ИИ могут уже стоять в бюджете, а сотрудники всё ещё вручную сверяют разные списки клиентов. Покупки показывают наличие инструментов. Зрелость включает то, как люди используют их в согласованной работе и замечают ошибки. На вопрос о выборе собственной CRM отдельно отвечает соседняя статья. Здесь проверяем, готов ли процесс к такой покупке.

В методологии ЦПУР и РАНХиГС цифровая зрелость рассматривается через культуру, кадры, процессы, продукты, модели, данные, инфраструктуру. В европейском инструменте EDIH тоже есть стратегия, люди и данные. Общий смысл: техническая оснащённость составляет лишь часть картины. Методологии открыты 7 октября 2026; мы не переносим их баллы в свою проверку готовности к заказу.

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

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

Владелец процесса определяет правило работы. Принимающий результат проверяет конкретную поставку; это может быть тот же человек, если он действительно участвует в проверке. Их роли нельзя молча переложить на агента. Разделение решений бизнеса и инженерной работы подробно разобрано в соседней статье. Подписка на разработку сама по себе эту договорённость не создаёт.

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

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

Для пилота подготовьте примеры обычного прохода и исключений. Ниже не клиентский кейс, а иллюстрация проверки заявки: выполненная, отменённая и полученная повторно. Ожидаемое поведение определяет владелец процесса. Исполнитель должен иметь возможность сверить его с конкретными входными данными, а принимающий результат воспроизвести случай после изменения.

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

На публичной карте нашей машины видно, что документация и журнал решений занимают самостоятельные зоны. На той же странице показаны 387 тысяч строк описаний системы и 391 тысяча строк кода. Это снимок страницы на 7 октября 2026; период накопления этих строк не указан. Из их объёма нельзя вывести зрелость компании или экономию на разработке.

Описание объясняет, что система должна делать и почему правило принято. Журнал связывает правило с причиной его появления. Это позволяет следующему исполнителю продолжить работу без догадок. Но наличие папки с документами ещё не означает, что конкретная задача приведёт агента к нужному правилу. На этом различии наша машина уже ошибалась.

17 июля агент подготовил схему по старым соседним образцам и пропустил действующее правило. Оно было записано в документации темы, но отсутствовало во входе, который использовал исполнитель. После разбора поправили именно вход. Урок для покупателя: попросите показать путь от заказа к правилу, а не только список существующих документов.

Объём описаний не защитил нас от этого пропуска. Похожий риск есть у любого заказа, который отправляют исполнителю без ссылки на актуальное правило. Если договорённость остаётся в переписке, а задача ссылается на старую версию, агенту придётся выбирать. Как оформлять правила для ИИ-агентов, разобрано отдельно; перед покупкой убедитесь, что они попадают в рабочий вход.

30 июля другой разбор закончился автоматической сверкой: описание экрана и его адрес не должны расходиться после переезда. 31 июля перенос поля новости свели в одно место и закрепили проверкой. В этих случаях правило получило способ обнаружить повтор ошибки. Это следующий шаг после записи договорённости, а не доказательство того, что все ошибки можно убрать заранее.

Наши эпизоды относятся к машине vibecoding.ru. Клиентского аудита цифровой зрелости у нас нет. Мы не выдаём эти истории за исследование компаний и не считаем по ним стоимость их хаоса. Они показывают более узкую вещь: правило должно доходить до исполнителя, а ошибку желательно уметь заметить при проверке результата.

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

Согласованные случаи проверяет принимающий результат. Исполнитель показывает изменение и результаты проверок, а владелец сопоставляет их с нужной работой. Если проверка нашла пропущенное исключение, уточняют правило и повторяют этот случай. Так приёмка становится источником следующей задачи. Наличие демонстрации и работающий обычный проход ещё не означают, что пилот принят.

В выводе DORA 2025 ИИ усиливает существующие сильные и слабые стороны организации. Это согласуется с нашим опытом правил, но не даёт гарантии ускорения конкретного бизнеса. Почему экономия на написании кода может не сократить всю разработку, разобрано отдельно. Перед масштабированием полезнее увидеть принятую задачу и причины переделок, чем считать объём сгенерированного кода.

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

Необязательно сначала описать всю компанию. Достаточно выбрать ограниченный процесс, который можно показать и проверить. Но если после каждого вопроса меняется цель, покупка постоянной разработки преждевременна. Сначала добейтесь устойчивой договорённости по этому процессу. Планировать очередь и календарь разработки помогает соседняя статья; оценка зрелости здесь определяет, что уже можно отдавать в работу.

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

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

2. Проверьте источник данных на обычном случае и исключениях; запишите ожидаемый результат.

3. Дайте исполнителю актуальное правило на входе, а принимающему результат способ повторить проверку.

4. После пилота вернитесь к ошибкам и исходному замеру. Следующую разработку покупайте под уточнённую очередь.