Чек-лист выездного обследования☑️

Как внедрить MVP в боевой режим за неделю? Правильно, никак.

Представьте, что крупная инжиниринговая компания решает внедрить мобильный BI для просмотра аналитики о ходе выполнения работ непосредственно на объекте. На этапе согласования бюджета принято решение начать с MVP — бюджет сильно ограничен, функциональный заказчик сомневается, будет ли удобно работать через смартфон, сотрудники информационной безопасности не готовы быстро согласовывать схемы интеграции с внутренними системами. Но все хотят попробовать вживую и тогда уже окончательно определиться.

Ситуация рабочая — поехали! Команда быстро создаёт функциональный прототип — симпатичный интерфейс, функциональность ограничена, но базовые идеи демонстрируются идеально. Руководители ходят по объекту со смартфонами — всё прекрасно.

Однако... вместо того, чтобы одобрить доработку и переходить на следующий этап, заказчик вдруг решает, что “всё уже работает” и начинает требовать внедрения системы в “боевом режиме”. Как это получилось? При демонстрации результатов работы ЛПРам руководитель проекта со стороны заказчика не совсем чётко проговорил, что это только MVP, а не полноценное решение😊

Как избежать проблем в такой ситуации?

📍Убедитесь, что вы все понимаете одно и то же под MVP. Перед стартом проекта обсудите и запишите цели MVP: он создаётся не для использования “как есть”, а для проверки гипотез и демонстрации возможностей.
📍Юридическое подкрепление. Пропишите в договор, ТЗ, что разрабатывается всего лишь временный прототип, а не финальное ПО.
📍Зафиксируйте слабые стороны MVP. Иногда стоит даже осознанно не брать в MVP все важные функции, проговаривать, что такой прототип никогда не сможет пройти проверку информационной безопасности и т.д.
📍План перехода. Подготовьте пошаговый план доработки MVP и покажите, какие дополнительные затраты, сроки и ресурсы потребуются для создания полноценного решения.

И обязательно нужно не забыть помочь руководителю проекта подготовить презентацию для ЛПРов о том, какой результат на каждом этапе проекта компания получит и когда будет возможно первое “боевого внедрение”.

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

Так, в стремлении улучшить клиентский сервис, один производитель промышленного оборудования запустил на своём сайте простой, но удобный конфигуратор. С его помощью клиенты могли настраивать под себя нужное оборудование: выбирать размер, мощность, дополнительную комплектацию. После оформления заказа конфигуратор сохранял данные на сервер в… Excel-файл.

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

Сначала всё шло замечательно. Клиентам упростили процесс заказа, а менеджерам обработку заказов. К конфигуратору все привыкли, и он стабильно начал генерировать заказы. Но затем, спустя где-то полгода, новые заказы перестали падать в Excel. Первые дни отдел продаж грустил, а через неделю началась паника после звонков недовольных клиентов с вопросами: “Вы будете обрабатывать наш заказ или нет?”. Оказалось, что заказы через конфигуратор оформляли, но они не приходили в отдел продаж.

Оказалось, что Excel-файл, который использовался для хранения заказов, просто достиг своего максимального размера. Формат, в котором велась запись, поддерживал ограниченное количество строк, и когда этот предел был превышен, конфигуратор продолжал работать, но новые заказы просто не записывались. Сколько заказов было потеряно установить не удалось, но по статистике продажи в эти две недели были на 20 млн рублей меньше, чем в другие недели квартала.

Этот случай демонстрирует то, как недостаток внимания к ИТ-инфраструктуре способен помешать работе даже хорошо отлаженного бизнес-процесса. На самом деле основной причиной провала стал не Excel как инструмент, а отсутствие качественного аудита инфраструктуры и недостаточное внимание к масштабируемости используемых решений.

Какие действия тут могли бы помочь:
📍Оценить границы используемых технологий
Excel — великолепный инструмент для небольших задач, но никогда не был предназначен для работы с большими потоками данных или автоматизации цифровых процессов. Если ваш бизнес растет, изучите возможности других решений: баз данных, облачных платформ, специализированных бизнес-систем.


📍Аудиты ИТ-инфраструктуры должны быть регулярными
Изменения в бизнесе неизбежны. Если вы внедрили какую-либо систему 6 месяцев назад, это не значит, что она до сих пор справляется с поставленной задачей. Регулярный аудит помогает выявлять скрытые проблемы, неисправности или ограничения, которые могут поставить бизнес под угрозу. При этом аудит — это не только техническая проверка оборудования или ПО, но и анализ процессов, которые с помощью них реализуются.

📍Не экономьте на специалистах
Все мы любим экономить, особенно там, где это кажется возможным. Кто-то скажет, что привлекать специалиста для проверки одного конфигуратора на сайте — это излишняя трата. Но давайте будем честными: что стоит дороже — такие "излишние" траты или потерянные заказы и клиенты?

Цифровая катастрофа на Уолл-Стрит или как за 45 минут "умный" алгоритм убил компанию с 90-летней историей (и что делать, чтобы не повторить это с вашим ИИ)

Представьте: компания внедряет "революционный" ИИ для автоматизации ключевого бизнес процесса. Все в восторге, топы ждут рекордной прибыли… но алгоритм за первые 45 минут работы сжигает годовой бюджет компании. Фантастика? Увы, это реальность. 1 августа 2012 года (в мой день рождения) автоматизированная система одного из крупнейших финансовых игроков Америки Knight Capital Group совершила миллионы ошибочных сделок. Компания потеряла $440 миллионов. Это не "баг", это провал в управлении внедрения инноваций.

И уроки Knight Capital очень актуальны сейчас, когда ИИ рвётся во все бизнес-процессы.

❓Что случилось?
На 8 из 30 серверов при обновлении забыли удалить старый модуль. При запуске системы он начал генерировать ошибочные ордера на покупку/продажу акций, не учитывая реальную рыночную ситуацию. Это вызвало эффект домино: ордера сбивали цены, другие алгоритмы воспринимали их как реальные изменения и также выставляли ордера. Без защитных механизмов ошибки повторялись, что привело к 4 миллионам сделок и банкротству.
Главная причина случившегося — игнорирование рисков ИТ проекта и промышленных подходов к разработке. А главное – не соблюдение базовых процессов: тестирование, контроль версий, механизмы защиты данных и предотвращения сбоев.

💡Как нам избежать своей "Knight-катастрофы"?

📍Переход на язык денег и рисков
Не “Система может сломаться”, а “Если наш ИИ-модуль даст сбой, то это может привести к перепроизводству/недопоставкам на сумму ХХ миллионов в месяц”

Риски — это конкретные цифры. Управление ими это защита денег компании.

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

📍Не делаем “всё и сразу”, а разбиваем проект на этапы
Сначала за месяц разрабатываем PoC для одного показателя, чтобы на исторических данных вручную проверить и утвердить подход. Цель этого этапа – показать решаемость задачи и сделать прогноз о точности работы.
Затем этап для второго, третьего параметра и т.д. Этот подход снижает риски (риски одного этапа меньше рисков всего проекта), даёт быстрые победы и доказывает ценность.

📍Всегда есть место для MVP
Типовая задача: бизнес хочет “полностью автоматизированную систему без участия человека”. В запросе видно очень много рисков. Что делать?
Найти MVP, который даст пользу для бизнеса, но при этом не остановит весь процесс в случае проблем.

Вместо “полной автономности” согласуйте MVP, где ИИ выдаёт рекомендации, а окончательное решение принимает человек. Или где ИИ обрабатывает только низкорисковые, стандартные кейсы, а сложные передаёт человеку. Это снижает риск катастрофы, но уже дает значительную часть экономии.

Кейс Knight Capital — не древняя история. Современные ИИ-системы сложнее, автономнее и быстрее старых алгоритмов. Мощь ИИ лишь подчёркивает важность человеческого надзора и строгого управления рисками.

Главное не пугать бизнес "багами", а стать его стратегическим партнёром в цифровизации, используя язык денег, поэтапные победы и разумные MVP. Потому что настоящая "магия" ИИ проявляется, когда он работает надежно, предсказуемо и приносит прибыль.