Proof of concept показывает, что идея может работать в благоприятных условиях. Промышленная система должна работать каждый день, для реальных пользователей, на реальных данных и рядом с системами, которые никогда не проектировались с расчётом на неё. Многие организации понимают эту разницу только тогда, когда после успешной демонстрации наступают месяцы тишины. В этой статье объясняется, почему так происходит и как выстроить проект по этапам, чтобы у демо был реалистичный путь в промышленную эксплуатацию.

Почему проекты proof of concept останавливаются

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

  • Нет владельца со стороны бизнеса. Работу спонсирует команда инноваций или ИТ, а в профильном подразделении никто не согласился менять процесс ради результата.
  • Доступ к данным принят как данность. Демо использовало выгрузку, подготовленную вручную, тогда как реальные данные находятся в системах со своими владельцами, правами доступа и проблемами качества.
  • Нет интеграции с существующими системами. Прототип работает сам по себе, поэтому стоимость подключения к ERP, CRM или заводским системам никто не оценивал.
  • Не определены критерии приёмки. Без заранее заданной цели успех становится вопросом мнения, а проект, который нельзя признать успешным, редко получает дальнейшее финансирование.

Что нужно промышленной системе помимо демо

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

  • Аутентификация и авторизация, подключённые к корпоративному провайдеру идентификации, с ролями, которые соответствуют реальным должностным функциям.
  • Журналирование и мониторинг, позволяющие оператору увидеть ошибки, медленные запросы и сбойные задания раньше, чем о них сообщат пользователи.
  • Контракты на данные, которые определяют поля, форматы, частоту обновления и поведение системы, если вышестоящая система присылает неожиданные данные.
  • Процедуры развёртывания и отката, которые автоматизированы и отработаны заранее, так что неудачный релиз можно отменить за минуты.
  • Документация по архитектуре, интерфейсам, конфигурации и эксплуатационным процедурам.
  • Назначенный ответственный на дежурстве, у которого есть доступы и знания для устранения инцидентов.

Как строится поэтапный проект

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

Затем идёт proof of concept с одним измеримым критерием приёмки, согласованным заранее. Для системы классификации документов это может быть минимальная точность на отложенной выборке. Для модели прогнозирования это может быть порог ошибки по сравнению с текущим ручным методом. Цель состоит в том, чтобы получить чёткий ответ «да» или «нет».

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

Вопросы поставщику перед подписанием договора

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

Разумно также спросить, какие части работы зависят от заказчика, например доступ к данным, тестовые среды и профильные эксперты, и к каким срокам они нужны. Задержки на стороне заказчика часто становятся причиной срыва графика, и если назвать их заранее, ими проще управлять.

Заключение

Переход от proof of concept к промышленной эксплуатации определяется прежде всего владением результатом, данными, интеграцией и эксплуатацией, и лишь отчасти зависит от продемонстрированной технологии. Организации, которые решают эти вопросы заранее и ведут работу по этапам с понятными критериями, меньше времени проводят в бесконечных пилотах и больше времени уделяют системам, на которые опираются люди.