Большая система на несколько месяцев нужна не всегда. Когда у компании есть понятная проблема, полезнее начать с небольшого рабочего контура: он даёт команде опыт, показывает реальные ограничения и не заставляет заранее строить всё будущее бизнеса.
Например, не «автоматизировать продажи», а собрать заявки из двух каналов, передать менеджеру контекст и настроить контроль следующего шага. Не «сделать ИИ-поддержку», а помочь с одним типом частых вопросов на основе проверенной базы знаний.
Из чего состоит рабочий спринт
Граница задачи
Один процесс, один пользовательский сценарий и конкретный критерий: что должно стать быстрее, понятнее или контролируемее.
Карта данных и интеграций
Какие источники уже есть, кому нужны доступы и где контекст должен появиться после действия пользователя.
Настройка контекста и правил
Какие знания разрешено использовать, как звучат ответы и в каких случаях система передаёт задачу человеку.
Тестирование на реальных сценариях
Команда проходит типовые и сложные случаи до запуска, фиксирует ошибки и корректирует правила.
Документация и обучение
У команды остаётся понятный сценарий работы, владелец процесса и способ сообщать об изменениях.
Что значит «законченный»
У контура есть начало и конец. Пользователь делает действие, система фиксирует нужный контекст, ответственный видит следующую задачу, а результат можно проверить. Если в спринте получился только прототип интерфейса без реального процесса, это ещё не рабочая система.
Чего не стоит включать в первый спринт
- несколько отделов и все каналы сразу;
- сложную миграцию данных без ясной цели;
- автономные решения там, где цена ошибки высока;
- функции «на будущее», которыми никто пока не пользуется.
До старта нужно договориться, что наблюдаем после запуска: время первого ответа, доля заявок со следующим шагом, скорость поиска информации, количество передач человеку или качество ответов по выборке. Это не обещание ROI — это способ увидеть, работает ли контур.
Что происходит после
Если контур прижился, следующий этап строится вокруг фактического опыта: какие данные оказались неполными, где команда продолжает работать вручную, какие сценарии действительно повторяются. Так Business OS развивается слоями, а не превращается в долгий проект с непроверенными предположениями.
Материал помогает сориентироваться в подходе. Конкретный состав решения зависит от процессов, данных и задач компании.