Как выходить из «зомби-проектов» автоматизации без скандалов и потери нервов
Как выходить из «зомби-проектов» автоматизации без скандалов и потери нервов
Источник и контекст: адаптация и аналитический рерайт материала из корпоративного блога Totum Online (Habr), с расширением терминологии и библиографией.
ABAqH61PQjJy8gYh44MBoWJdAxS2I5PYL8Bq8r4xPjqunNpaEL1dkwEHYWNldG9uZZMGFU4ACsOFkgbDUqO8w4UEA6/Fxw==
В разработке систем автоматизации есть особый подвид проектов — зомби-проекты. Они формально живы, бюджет освоен наполовину, интерфейсы уже существуют, но бизнес-результата нет и не предвидится. Такие системы годами ходят между отделами, не решая ни одной исходной задачи.
Мой базовый продукт — low-code платформа для конструирования веб-приложений: данные, действия, триггеры, интерфейсы. Параллельно я много лет делал кастомные решения под конкретные процессы. Итог повторялся почти всегда: проект замирал в середине, а вытаскивать его приходилось ценой личного времени и нервов.
Со временем стало ясно: проблема не в коде и не в платформе. Проблема в экономике, организационной структуре и ложных ожиданиях.
Почему автоматизация часто не работает
1. Автоматизируют то, что нельзя автоматизировать
Классический паттерн:
Системой хотят «снять зависимость» от ключевого сотрудника, но ввод данных поручают ему же.
Отдел должен внедрить систему, которая заменяет этот же отдел.
Для планирования нужны нормативы, которые не пересчитывались десять лет — и их опять должен дать тот же отдел.
Это не автоматизация. Это попытка переложить управленческую проблему на софт.
Термин: организационный тупик автоматизации.
2. Нужны действия в физическом мире — но их никто не делает
Система предполагает, что сотрудники начнут:
пересматривать контракты,
менять процессы закупок,
корректировать производственные цепочки.
На практике система превращается в «витрину данных». Используют её не для решения задачи, а «для отчёта о внедрении».
Аналогия: абонемент в спортзал без походов в зал.
3. Автоматизируют процесс, который и так работает
Excel-учёт без последствий ошибок, ручные замеры без критичности точности, контроль, где 80 % времени уходит на установку образца.
Даже нейросеть не спасёт, если бутылочное горлышко находится вне зоны ИТ.
Термин: локальная оптимизация без системного эффекта.
4. Делают «фетиш-автоматизацию»
Табло, лампочки, панели мониторинга «чтобы было как у японцев».
При этом:
нормативы не пересматриваются,
мотивация не меняется,
управленческие решения не ускоряются.
Визуализация без управленческого контура — это декоративная электроника.
5. Конкурирующие подрядчики и скрытые конфликты
Бухгалтерия, ИТ-отдел, внешний интегратор — каждый тянет систему в сторону своего продукта. Работоспособность итоговой архитектуры зависит от тех, кто заинтересован в её провале.
Термин: конфликт интересов в цифровой трансформации.
6. Реальную проблему решил первый модуль
Контракт на 10 модулей, бизнес-эффект получен на первом.
Дальше мотивация исчезает, но юридические обязательства остаются.
7. Магическая вера в «систему, которая изменит людей»
Руководство заказывает «таблетку»:
«Поставим систему — и сотрудники станут дисциплинированными, точными и ответственными».
На выходе получается ИБД-система (имитация бурной деятельности), существующая параллельно реальной жизни.
Как рождается зомби-система
Типовой сценарий:
старт без полноценного скрининга,
ранний функциональный оптимизм,
первый управленческий конфликт,
уход в бесконечные правки,
срыв платежей,
требования возврата денег,
попытки переложить ответственность на платформу.
Это не психология. Это экономика плохих контрактов.
Практическая схема выхода без войны
Модель, выработанная на проектах со средним чеком 800 000 – 1 500 000 ₽, для команд без армии менеджеров и юристов.
1. Предварительный скоринг (бесплатно)
1–2 встречи по 2 часа.
Цель — найти точку будущего фейла раньше, чем подписан договор.
Не ТЗ, а диагностика реализуемости.
2. Технический прототип риска
Если есть критичный элемент (парсер, интеграция, CAD, нестандартный протокол):
до 10 часов работы,
без предоплаты,
с зачётом в договор при старте.
3. Модульная схема проекта
Не ТЗ, а:
карта модулей,
зависимости,
последовательность разработки,
указание, какие модули не заработают без действий заказчика.
Ключевая идея — дойти до точки фейла как можно раньше.
4. Контракт не на результат, а на часы
Предмет договора:
«Часы разработки описанного проекта в обмен на оплату».
Без фиксированных дат, без общей суммы, без потолка.
Любая дата становится инструментом давления.
Любая общая сумма — поводом для шантажа.
5. Итерационная модель
итерации по 150–200 тыс. ₽,
обязательные акты,
неделя на возражения,
два неподписанных акта — проект останавливается навсегда.
Жёстко. Зато честно.
6. Разработка на сервере заказчика
прозрачность,
отсутствие проблем передачи,
контроль в реальном времени.
7. Обязательства заказчика
до 4 часов в неделю на коммуникации,
параллельная подготовка данных,
подтверждающие акты по критическим этапам.
Итоговая логика
Эта схема решает не задачу «довести любой проект до конца», а задачу:
быстро завершить проекты с реальной мотивацией,
максимально рано расстаться с проектами-фантазиями,
не превращать подрядчика в бесплатного терапевта для организации.
Автоматизация не лечит управленческие болезни.
Она лишь делает их видимыми быстрее.
Библиография и источники
Totum Online, блог на Habr — цикл статей о внедрении автоматизации
https://habr.com/ru/companies/totum_online/Brooks F. The Mythical Man-Month — классика о рисках сложных проектов
Goldratt E. Theory of Constraints — системные ограничения и бутылочные горлышки
Davenport T., Prusak L. Working Knowledge — роль данных и организационных процессов
Standish Group CHAOS Reports — статистика провалов ИТ-проектов
Хэштеги
#Автоматизация #ЗомбиПроекты #ИТКонтракты #DigitalTransformation #LowCode #BPM #УправлениеПроектами #ТехническийДолг #СистемныйАнализ #Интеграция #КорпоративныеСистемы
Comments
Post a Comment