Пора сказать прямо: большинство провалов с ERP-системами — это не техническое поражение. Это провал диалога. Мы упорно не хотим говорить друг с другом на одном языке, прячась за иллюзией, что «всё и так понятно».
Возьмем простое пожелание: «Хотим видеть всё в реальном времени». Звучит прекрасно. А что это значит на практике? Что данные обновляются каждую секунду? Или раз в пять минут? Кто и какие именно данные должен видеть? Менеджер по продажам — остатки, а бухгалтер — движение денег? Если не расшифровать это сразу, под «всём» каждый участник проекта будет понимать что-то свое. Результат предсказуем: система есть, а ожидаемой ясности нет.
Часто заказчик приносит в проект идеально отлаженный, по его словам, бизнес-процесс. Он описывает, как всё должно работать в теории. Но реальность — это постоянные отклонения от маршрута. Возвраты, срочные замены, нестандартные заявки. Игнорировать их при внедрении — значит построить мост, который рухнет, как только по нему попробуют проехать не по правилам. Система должна уметь работать не только в идеальных условиях, но и в хаосе, который и есть нормальная жизнь компании.
Если вам откликается тема невысказанных ожиданий и «подводных камней» при внедрении ERP, заглядывайте в наш Telegram-канал @techitpm.
Еще один камень преткновения — роли и права. Кто что видит? Кто что меняет? Без четкой матрицы полномочий начинается либо полный хаос, когда любой сотрудник может случайно изменить критически важные данные, либо невыносимая бюрократия, когда для простого действия требуется пять согласований. И то, и другое убивает эффективность. Люди либо начнут искать обходные пути, либо просто перестанут пользоваться системой.
Отдельная история — термины. Внутри компании все знают, что значит «провести лимитку» или «закрыть аванс». Для разработчика это может быть просто набор звуков. Если не составить глоссарий и не показать, как эти термины живут в конкретных документах и отчетах, получится функционал, который технически соответствует заданию, но абсолютно бесполезен для тех, кто должен на нем работать.
Бывает, заказчик не предоставляет ни одного реального документа или формы отчета. В итоге интерфейс рисуется красивым, но абсолютно оторванным от жизни. Кнопки не там, где привыкли, нужные данные размазаны по трем экранам, а главный отчет нельзя выгрузить в привычном Excel. Это не ошибка разработчика. Это прямое следствие того, что никто не потрудился показать, как люди работают сейчас.
Невысказанные ожидания не лечатся одной статьёй — это про навыки: задавать неудобные вопросы, проговаривать риски, договариваться о правилах игры. Этому мы системно учим на наших программах. Подробнее на сайте.
Не менее критичен вопрос интеграций. Как новая система будет общаться со старой 1С и смежными системами? Что, куда и когда передается? Без детального технического задания на стыковку эти системы либо не заговорят вовсе, либо начнут генерировать тонны ошибок, которые придется разгребать месяцами.
Критерии успеха часто остаются неозвученными. «Быстро», «удобно», «наглядно» — что стоит за этими словами? Пока вы не сформулируете эти ожидания в цифрах и конкретных примерах, приемка проекта превратится в бесконечный спор о вкусах.
Производительность — еще один невидимый враг. Если не обсудить, сколько пользователей будут работать одновременно, какие объемы данных система должна обрабатывать ежедневно, можно получить идеальное с точки зрения логики решение, которое будет «падать» в самый ответственный момент, не выдержав нагрузки.
И, наконец, самая глубокая проблема. Заказчик часто описывает не реальные процессы, а их идеальную, регламентированную версию. А на деле половина операций ведется в Excel, часть в блокнотах, а согласования проходят в чате. Если не учесть эти неформальные, но жизненно важные маршруты, ERP станет красивым, но параллельным миром. Миром, в котором никто не живет.
Что делать?
Перестать бояться вопросов. Задавать их много. Спрашивать о деталях, даже самых неудобных. Проводить совместные сессии, где разбираются не только счастливые, но и все аварийные сценарии. Фиксировать всё: роли, определения, форматы документов, протоколы интеграции.
И главное: договориться, что техническое задание — это не застывший документ, а живой процесс. Его нужно постоянно уточнять, проверять на прототипах, тестировать на практике. Если бизнес-процессы неясны, размыты или живут своей жизнью, никакая технология не поможет. Никакой код не заменит простой человеческой ясности и готовности к долгому, сложному, но необходимому разговору.
Понравилась статья?
Ставьте «палец вверх» и подписывайтесь на канал, если статья оказалась полезной.
Больше интересных тем — на нашем ✈️ Telegram-канале.
Подробнее о наших курсах — на сайте