Почему процесс чинят до внедрения системы, а не вместе с ней

Мы внедряли CRM трижды: в агентстве, в сезонном производстве корпоративных подарков и в платформе онлайн-записи. Три компании, три отрасли, три команды. Общее было одно: везде первой версией конфигурации становился существующий порядок работы, перенесённый в поля и статусы как есть.

Именно это и есть точка, где решается судьба проекта. Если процесс до внедрения содержал необязательные поля, ручные исключения и «здесь мы обычно звоним и договариваемся», всё это переезжает в систему и получает статус нормы. Дальше исправлять становится дороже: теперь у беспорядка есть конфигурация, интеграции и обученные пользователи.

Что именно закрепляет система

Формулировка «система закрепляет беспорядок» звучит как метафора, пока не разложить её на конкретные механизмы. Их четыре, и каждый наблюдаем в первые же недели после запуска.

Необязательное поле становится вечно пустым. На этапе настройки почти всегда побеждает аргумент «сделаем необязательным, а то не будут заполнять». Через квартал выясняется, что поле не заполнено у 80% записей и построить по нему отчёт нельзя. Решение о том, какие данные обязательны, — процессное, а не техническое, и принимать его после запуска поздно: теперь придётся заполнять задним числом.

Исключение превращается в статус. «У этого клиента мы делаем иначе» на этапе внедрения выглядит мелочью, и под неё заводится отдельный статус или отдельный тип сделки. Через год таких статусов двенадцать, и ни один сотрудник не может объяснить разницу между четырьмя из них. Каждый статус — это ветка в отчётности, в правах доступа и в обучении новичка.

Ручная договорённость становится невидимой. Там, где раньше двое коллег решали вопрос голосом, система показывает пустоту: заявка висит в статусе, а работа идёт. Формально процесс исполняется, фактически он проходит мимо системы, и данные в ней перестают отражать реальность. Дальше руководитель принимает решения по отчёту, который описывает не то, что происходит.

Расчёт по памяти переезжает в свободное поле. Если правила расчёта не формализованы до внедрения, в системе появляется поле «сумма», куда менеджер вписывает число. Система при этом выглядит внедрённой, а арифметика остаётся ручной — со всеми ошибками, которые она давала раньше.

Общее у всех пяти строк — момент обнаружения. Ни одна проблема не проявляется во время проекта; все они всплывают после его формального закрытия, когда команда внедрения уже распущена, а бюджет израсходован.

Насколько это массовая история

Внедрения корпоративных систем измеряются регулярно, и картина устойчива: проблема не в технологии и не в вендоре.

Оговорка обязательна и делаю её сам: это отчёт консалтинговой компании, которая продаёт сопровождение внедрений ERP. Выборка не случайна — респонденты откликнулись на приглашение, вероятен перекос в сторону клиентов и подписчиков самой компании. Цифра годится как порядок величины, а не как измерение рынка.

Это пресс-релиз, а не полный отчёт: инструмент опроса, период сбора и точные формулировки вопросов публично не раскрыты. Ценна здесь не сама доля, а разрыв в 23 процентных пункта между лидерами и остальными — он показывает, что результат определяется не наличием системы, а тем, как устроена работа вокруг неё.

Что мы стали делать до старта внедрения CRM

После третьего внедрения набор предварительных решений стал фиксированным. Он короткий и не требует ни аналитика, ни бюджета — только времени владельца процесса.

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

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

Третье решение — про переходы между ролями. Каждый переход должен быть событием в системе, а не устной договорённостью. Если работа между двумя людьми передаётся голосом, система будет показывать одно, а происходить будет другое.

Отдельно про то, чего в этом списке нет. В нём нет описания процесса «как есть» в виде схемы на двадцать листов. Такое описание почти всегда делается, почти никогда не читается и не помогает принять ни одно из трёх решений выше: оно фиксирует наблюдаемое поведение, а решения касаются нормы. В третьем нашем внедрении мы отказались от полного описания и потратили освободившееся время на два дня разбора обязательных полей — это оказалось единственным этапом подготовки, который повлиял на результат.

Второе, чего в списке нет, — выбор платформы. Он не бессмысленный, но вторичный: все три решения формулируются одинаково для любой из распространённых систем, и ни одно из них не зависит от вендора. Порядок, при котором сначала выбирается система, а потом обсуждается процесс, гарантирует, что разговор о норме будет вестись в терминах ограничений конкретного продукта, а не в терминах бизнеса.

Почему исправление после запуска стоит дороже

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

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

Четыре вопроса перед стартом проекта внедрения

Вопросы, которые задают чаще всего