Разбор типовых причин провала: неверная задача, отсутствие владельца, грязные данные, сопротивление людей, зомби-системы и подрядчик, который исчез после сдачи.
Провалившийся проект автоматизации редко выглядит как катастрофа. Чаще это работающая система, которой никто не пользуется: сотрудники ведут параллельный учёт в таблице, а руководитель не может объяснить, куда ушли деньги.
Здесь собраны причины, по которым это происходит, ранние признаки каждой и то, что можно сделать, пока проект ещё можно спасти.
Самое дорогое решение в буксующем проекте — не остановить его вовремя. Шесть наблюдаемых признаков, разговор про невозвратные затраты без экономических терминов, расчёт развилки на 620 000 ₽ вложенных и 900 000 ₽ предстоящих и список того, что остаётся у компании после остановки.
ПрактикаОбучение — самая дешёвая строка сметы и первая, которую вычёркивают. Разбираем минимальный комплект на 72 000 ₽, расчёт потерь на 112 050 ₽ за первые три недели, проверку усвоения через одну реальную заявку и правило, по которому обучение не ставят на последнюю неделю проекта.
ПрактикаПять метрик, по которым система признаётся мёртвой, аудит за один рабочий день, расчёт стоимости зомби на два года и три сценария выхода — включая честное списание.
ПрактикаПровал внедрения редко выглядит как авария. Чаще это работающая система, через которую проходит 61 % заявок, и девять человек, которые продолжают вести свою таблицу. Разбираем три причины, замер использования из трёх чисел и три рычага, которые меняют арифметику для сотрудника.
МетодикаРоль владельца процесса в часах и полномочиях, а не в общих словах: сколько времени она отнимает, какие пять признаков говорят, что владельца нет, что делать, если единственный владелец — собственник, и почему ИТ-специалист на этой роли не работает.
ПрактикаСовет «сначала наведите порядок» верен ровно наполовину: полное описание as is на восемьдесят страниц убивает проект не хуже беспорядка. Разбираем, какого минимума достаточно, как получить его за один рабочий день и в каких процессах порядок наводит как раз система.
МетодикаКаждая причина привязана к неделе проекта, на которой её уже видно, к наблюдаемому признаку и к действию, которое ещё можно совершить. Со светофором из 12 вопросов для еженедельной встречи и расчётом, что остаётся у компании, если проект на 900 000 ₽ останавливают на четвёртом месяце.
Разбор типичных провалов — от автоматизации хаоса до системы, брошенной без поддержки. По каждой причине: как выглядит изнутри компании, как распознать до подписания договора и что делать.
Раздел выходит частями. Ниже — темы, которые уже расписаны и ждут очереди. Если нужен ответ по одной из них прямо сейчас — напишите нам, разберём вашу ситуацию отдельно и без ожидания.
Не про важность качества данных вообще, а про шесть конкретных проверок, которые можно сделать выгрузкой в таблицу за полдня, и про то, какой сценарий ломается при каждом типе грязи.
Разбор не эмоциональный, а процедурный: что должно быть на руках до последнего платежа, по каким признакам исчезновение видно заранее и во сколько реально обходится подхват чужого решения.
Практическая процедура на три недели: пять дней аудита, сужение до одного сценария, разговор с текущим подрядчиком и новая точка приёмки с измеримым критерием. И отдельный раздел о том, когда перезапуск не поможет.
Показывает арифметику раздувания на одном примере: три сценария за 250 000 ₽ и четыре недели против восемнадцати за 1 200 000 ₽ и пять месяцев — при том, что первые три закрывают основную долю потока.
Сравнивает на числах цену обследования и цену переделки, и объясняет, чем платное обследование с артефактами на руках отличается от «бесплатного ТЗ за час», которое на деле является презентацией продажи.
Практическая инструкция на две недели: какие шесть показателей снять до старта и как это сделать, если в компании никогда ничего не считали. Без этих цифр любой расчёт окупаемости после запуска становится предметом веры.
Честная статья про случай, когда правильный ответ — не автоматизировать. Даёт четыре вопроса-фильтра о сроке жизни процесса и перечисляет дешёвые заменители капитального внедрения.
Разбор механики покупки: демонстрация показывает чужой отлаженный процесс, а у покупателя такого процесса нет и в помине. Три проверки перед оплатой лицензий и что делать с уже купленными.
Интеграция, написанная «в один проход», незаметно теряет данные при первом же таймауте. Статья перечисляет пять типов сбоев, показывает проверку существующего обмена за 30 минут и оценивает, во сколько обходится надёжность.
Разбирает самую скучную и самую дорогую причину расхождений: одну и ту же сущность две системы называют по-разному. Даёт правило одной мастер-системы и порядок сопоставления по коду, а не по названию.
Объясняет разрыв между демонстрацией на пятидесяти примерах и работой на шести тысячах обращений в месяц: другая цена запроса, другие требования к отказам и другой уровень ответственности за ошибку.
Разбирает срыв сроков по источникам, а не по виноватым: ожидание доступов, согласование сценариев, отсутствие тестовых данных и поток новых пожеланий съедают больше, чем сама разработка.
Одновременный перевод всех отделов лишает возможности откатиться и превращает любую ошибку сценария в остановку работы. Статья описывает выбор пилотной группы, критерий её успеха и план отката.
Опишите процесс словами, голосом или файлами — вернёмся с картой процесса, вариантом решения и предварительной вилкой бюджета. Бесплатно и без обязательств.
