На рынке рядом существуют два ориентира: 14-21 день в коммерческих предложениях и в среднем 5,5 месяца в обзорах завершенных ИИ-проектов. Обе цифры могут быть честными.
14-21 день обычно относятся к простому внедрению "под ключ": брифу, настройке, тестовому режиму и запуску. Подготовка базы знаний, доступы и обучение сотрудников в такой срок часто не входят.
5,5 месяца - ориентир для полного пути от выбора процесса и подготовки данных до интеграции, приемки и запуска. Это наблюдение по завершенным проектам, а не обещание для конкретного предприятия.
Разница появляется потому, что подрядчик обычно считает свои работы. Компания живет по полному календарю: выбирает процесс, готовит данные, согласует доступы, подключает людей, принимает результат и затем поддерживает его в работе.
Ниже - пять этапов такого календаря. Для каждого указано, что вы покупаете, какой срок можно обсуждать до старта и что придется сделать внутри компании.
Этап 1. Как выбрать процесс и поставить задачу?
Плохая постановка звучит так: "нужен агент для отдела снабжения". В нее помещаются поиск поставщиков, разбор предложений, проверка договоров, контроль сроков и переговоры. У этих задач разные данные, цена ошибки и правила приемки. Оценить такой проект до обследования нельзя.
Для первого внедрения нужен один переход от известного входа к проверяемому результату. Например: получить коммерческие предложения, привести позиции к общей форме, отметить расхождения и подготовить таблицу для решения снабженца.
Срок: для простого сценария бриф и проектирование обычно занимают 2-4 дня. Если у процесса нет владельца, а участники по-разному описывают результат, календарный срок определяется не разработкой, а скоростью внутренних решений.
Что на этом этапе делает заказчик: назначает владельца процесса, показывает несколько реальных операций, выбирает один результат для автоматизации и утверждает критерии приемки.
На выходе должна появиться не презентация про возможности ИИ, а короткая карточка процесса:
- что запускает работу;
- что приходит на вход;
- какой результат должен подготовить агент;
- что остается решением человека;
- какие случаи считаются исключениями;
- по какой текущей величине будет виден эффект;
- кто принимает результат со стороны бизнеса.
Метрика нужна до пилота. Иначе подрядчик покажет, что система умеет разбирать документы, а компания не сможет ответить, сократилось ли время операции и стала ли проверка результата дешевле самой ручной работы.
Что спросить подрядчика
- Какой один участок процесса входит в первый запуск?
- Как выглядит результат агента: документ, заполненная карточка, запись в системе или новый статус?
- Какие решения агент не принимает?
- По каким данным сравнят новый процесс со старым?
- Кто и по каким правилам принимает этап?
Первый этап закончен, когда обе стороны одинаково понимают границы работы. Подписанный договор сам по себе эту проблему не решает.
Этап 2. Что потребуется для доступа к данным и системам?
После постановки задачи обычно выясняется, что нужные сведения живут в нескольких местах. Часть хранится в 1С, часть в CRM, часть в общей папке, а исключения знает только опытный сотрудник. Подрядчик может подключить систему, но не может вместо компании решить, какой прайс действующий и кому верить при расхождении остатков.
На этом этапе определяют:
- откуда агент берет документы и справочники;
- какая версия данных считается основной;
- что можно только читать, а что разрешено создавать или менять;
- как удаляются персональные и конфиденциальные сведения из тестовых наборов;
- кто согласует доступ со стороны ИТ и информационной безопасности;
- кто связывается с обслуживающей компанией, если нужна доработка 1С, CRM или другой системы.
Срок: этот этап считается после инвентаризации источников и пробной выгрузки. Если данные разрознены, противоречат друг другу или требуют очистки, подготовка может стать самой длинной частью проекта. Если они уже собраны и непротиворечивы, срок можно назвать после их проверки, а не до нее.
Что на этом этапе делает заказчик: предоставляет тестовый набор реальных материалов, назначает владельцев источников, определяет правильные версии документов и организует согласование доступов.
Доступ к системе не равен готовности данных. Агент может успешно подключиться к папке и при этом брать устаревший регламент. Поэтому результатом этапа должны быть карта источников, согласованные права и проверочный набор примеров с эталонным результатом.
На старте безопаснее выдавать минимальные права. Если для пилота достаточно чтения и создания черновика, агенту не нужен доступ к проведению документа или отправке сообщения от имени сотрудника. Расширить права можно после проверки. Исправлять последствия лишнего действия обычно дороже.
Что спросить подрядчика
- Какие данные нужны для первой версии и в каком формате?
- Кто решает, какой источник главный при расхождении?
- Какие права нужны на пилоте: чтение, создание черновика или запись?
- Где будут храниться документы и журналы работы?
- Что произойдет, если источник недоступен или данные неполны?
- Какие действия потребуют отдельного согласования с ИБ и поставщиками наших систем?
Если подрядчик называет дату пилота до просмотра данных и списка систем, это пока дата в плане продаж, а не проверенный график проекта.
Этап 3. Что должен доказать пилот на узком участке?
Пилот нужен не для эффектной демонстрации. Он должен проверить весь короткий рабочий цикл на ваших материалах: получить вход, обратиться к разрешенным источникам, подготовить результат, передать исключение человеку и сохранить журнал действий.
У пилота должны быть границы. Один процесс, ограниченная группа пользователей, заранее собранные примеры и понятный способ вернуться к ручной работе. Если в пилот одновременно включить весь отдел и несколько систем, по итогам будет трудно понять, где именно возник эффект или ошибка.
Срок: узкий пилот обычно занимает 2-6 недель. Для крупного проекта с несколькими системами и расширенной проверкой срок может составить 8-12 недель. До старта нужно определить, к какому классу относится пилот и что именно входит в названный срок.
Что на этом этапе делает заказчик: дает реальные примеры, выделяет эксперта процесса для регулярной проверки, фиксирует ошибки и исключения, сравнивает результат с исходным процессом и принимает решение о переходе к интеграции.
Хороший пилот отвечает на четыре вопроса:
- Справляется ли система с типовыми случаями на реальном потоке?
- Какие ситуации она обязана передавать человеку?
- Сколько времени занимает проверка результата?
- Сохраняется ли ожидаемый эффект с учетом этой проверки и стоимости использования?
Последний вопрос защищает от ложной автоматизации. Если сотрудник после агента заново читает весь документ или полностью повторяет расчет, система добавила еще один слой работы. Проверка должна быть короче исходной операции: посмотреть отмеченные расхождения, подтвердить заполненные поля или разобрать только исключения.
До начала пилота договоритесь и о механизме остановки. Кто выключает агента, что происходит с незавершенными задачами и как сотрудники возвращаются к ручному процессу? Это часть приемки, а не сценарий на случай катастрофы.
Что спросить подрядчика
- На каком реальном потоке будет идти пилот?
- Какие типовые и сложные случаи войдут в проверочный набор?
- Как фиксируются ошибки, действия агента и использованные источники?
- Какая доля работы остается человеку и сколько занимает проверка?
- Как считается стоимость месяца работы при полной нагрузке, а не на тестовой группе?
- Как остановить пилот и вернуться к ручному процессу?
- Какой документ получит заказчик по итогам: отчет, протокол приемки, список ограничений и расчет эффекта?
Пилот закончен не тогда, когда агент впервые выдал правильный ответ. Он закончен, когда компания понимает его рабочие границы и может решить, стоит ли встраивать его в процесс.
Этап 4. Как проходят интеграция и обучение сотрудников?
После пилота агент должен перестать быть отдельным окном. Заявка приходит из привычного канала, результат появляется там, где сотрудник продолжает работу, а исключение уходит конкретному человеку. Для этого нужны интеграции, роли, уведомления, журнал действий и правила эксплуатации.
На этой стадии меняются программа и сам порядок работы. Раньше специалист собирал документ с нуля. Теперь он получает черновик и проверяет исключения. Нужно определить, что он обязан проверить, что может подтвердить и куда сообщать об ошибке. Без этого люди либо не используют систему, либо перепроверяют все целиком.
Срок: настройка агента и интеграций обычно занимает 7-10 дней, еще 3-5 дней нужен тестовый режим. Это не полный срок этапа для любой компании: подготовка базы, доступы, согласования с ИТ и ИБ, обучение сотрудников могут увеличить календарь. Точный диапазон определяется после проверки систем и состава работ.
Что на этом этапе делает заказчик: координирует ИТ, ИБ и поставщиков внутренних систем, утверждает новый регламент, выделяет сотрудников на обучение и проверяет работу интеграции в привычном рабочем контуре.
Обучение здесь не означает лекцию про нейросети. Сотруднику нужно уметь сделать несколько конкретных вещей:
- понять, что агент уже сделал;
- проверить обязательные поля и отмеченные исключения;
- исправить результат без обходных схем;
- передать обратную связь владельцу системы;
- остановить действие, если ситуация вышла за разрешенные границы.
Лучше проверять это на тех же операциях, которые сотрудники выполняют каждый день. Если после обучения человек не понимает, где появился результат и кто отвечает за ошибку, проект еще не готов к запуску.
Что спросить подрядчика
- Какие системы входят в интеграцию, а какие остаются за рамками?
- Кто отвечает за доработку каждой системы и согласование с ее поставщиком?
- Где сотрудник увидит результат и исключения?
- Какие действия требуют подтверждения человека?
- Какой регламент и инструкции останутся у компании?
- Как проверят, что сотрудники умеют работать по новому порядку?
- Что считается завершением интеграции: техническое подключение или полный проход рабочей операции?
Этап 5. Когда агента можно вывести в работу и как его поддерживать?
Промышленный запуск отличается от пилота нагрузкой и последствиями. На тесте агент видит ограниченный поток. В работе он получает новые форматы документов, сбои источников и случаи, которых не было в проверочном наборе.
Поэтому запуск лучше принимать по рабочему процессу, а не по факту включения системы. Нужно проверить, что типовые случаи проходят, исключения доходят до назначенных людей, действия восстанавливаются по журналу, а расходы соответствуют расчету на полной нагрузке.
Срок: вывод в работу имеет дату приемки, а поддержка продолжается весь срок использования системы. Длительность стабилизации зависит от нагрузки, числа интеграций и готовности сотрудников, поэтому ее фиксируют после пилота вместе с критериями завершения. Слова "поддержка включена" недостаточны: должны быть названы зона ответственности, порядок разбора ошибок и правила обновления данных.
Что на этом этапе делает заказчик: принимает решение о запуске, назначает владельца системы, контролирует бизнес-метрику, обновляет исходные документы и решает, какие новые сценарии можно допустить к автоматической работе.
После запуска меняются три вещи.
Первая - данные. Появляются новые прайсы, формы документов, продукты и правила. Если базу не обновлять, агент продолжит уверенно работать по старой версии.
Вторая - поток. Стоимость теста нельзя механически переносить на всю компанию. Число запросов растет, а вместе с базой может увеличиваться и объем данных в каждом обращении. До запуска запросите расчет при полной нагрузке и способ контролировать расходы.
Третья - границы автоматизации. Стабильные типовые случаи можно постепенно проводить дальше без ручного подтверждения. Новые и дорогие ошибки должны по-прежнему останавливаться у человека. Права расширяют по статистике собственной системы, а не потому, что закончился пилот.
Что спросить подрядчика
- По каким критериям подписывается промышленная приемка?
- Кто получает уведомление об ошибке и кто отвечает за ее разбор?
- Какие показатели и журналы видит заказчик?
- Кто обновляет инструкции, справочники и базу знаний?
- Как считается и ограничивается стоимость эксплуатации при полной нагрузке?
- Что входит в поддержку, а что оформляется как новая доработка?
- Как выгрузить данные и продолжить работу, если подрядчик меняется?
- Когда и на основании каких данных агенту можно расширить права?
Чек-лист перед подписанием договора
Сведите ответы по пяти этапам в один лист. До старта у вас должны быть:
- один процесс с понятным входом и результатом;
- владелец проекта со стороны бизнеса;
- метрика исходного процесса и критерии приемки;
- список источников данных и ответственные за них;
- схема прав агента и согласование с ИТ и ИБ;
- границы пилота, проверочный набор и механизм остановки;
- план интеграции в рабочие системы;
- порядок обучения и новый регламент для сотрудников;
- расчет эксплуатации на полной нагрузке;
- правила поддержки, обновления данных и выхода из решения.
Если подрядчик не может связать срок с этими пунктами, он оценивает разработку в своем контуре, а не внедрение в вашей компании.
Перед первой встречей необязательно писать техническое задание. Достаточно принести один повторяемый процесс, реальные примеры входящих материалов и человека, который знает, как работа идет на самом деле. Решение по технологии имеет смысл принимать после того, как видны границы работы, роли компании и способ посчитать эффект.
Если пока непонятно, какой участок брать первым и готовы ли данные, запишитесь на бесплатную диагностику процессов Neuroprem, 35-45 минут. Разберем одну реальную операцию, определим границы автоматизации и данные для расчета эффекта. Чтобы записаться, оставьте заявку в форме ниже.