Рулевой на стороне заказчика: кому доверить штурвал внедрения 1С
Введение
Представьте ситуацию: вы решили построить дом. Нашли отличного прораба, архитектора и бригаду строителей. Вы заплатили им аванс и уехали в длительный отпуск, оставив лишь расплывчатое пожелание: «Постройте мне красиво и функционально, вы же профессионалы». Как думаете, какой дом вы увидите по возвращении? Скорее всего, там будут золотые унитазы, но не будет канализации, или стены окажутся там, где вы планировали панорамные окна.
Внедрение 1С — это та же стройка, только из кода и бизнес-логики. Почему-то многие собственники бизнеса, доверяя ключи от офиса охраннику, без колебаний отдают «ключи» от своего бизнеса команде внедренцев, самоустраняясь от процесса. Результат такой «слепой» автоматизации почти всегда один и тот же: сорванные сроки, раздутый в два-три раза бюджет, неработающий функционал и испорченные нервы, переходящие в судебные споры о приемке работ.
Разберем без прикрас, почему роль руководителя проекта (РП) со стороны заказчика критически важна и как отсутствие «своего» человека на этой позиции превращает проектное внедрение в «русскую рулетку».
1. Точка сборки: почему аналитик не должен играть в испорченный телефон
Одна из главных болей любого подрядчика, о которой редко говорят на старте, — это бесконечные итерации согласований. Команда исполнителя — это целый десант: руководитель проекта со стороны франчайзи, бизнес-аналитик, системный архитектор, группа разработки, менеджер по качеству. Все они работают в связке, но их продуктивность напрямую зависит от качества входящей информации.
Когда со стороны заказчика нет выделенного РП, аналитик исполнителя вынужден проводить интервью со всем отделом продаж, бухгалтерией и складом одновременно. Результат: Мария Петровна из бухгалтерии хочет одну форму отчета, а Иван Иваныч из продаж — прямо противоположную. Аналитик фиксирует «среднее арифметическое», тратит недели команды на написание ТЗ и проработку архитектуры, а на финальной демке выясняется, что «мы так не договаривались, мы это не подписываем».
Показательный случай из практики внедрений:
Одно крупное производственное предприятие затеяло переход на новую ERP-систему. Контракт был подписан с серьезным интегратором, но заказчик не выделил отдельного руководителя проекта, решив сэкономить ресурс. Ключевые пользователи срывали встречи по тестированию, ссылаясь на операционную загрузку. Аналитикам и архитекторам подрядчика приходилось по десять раз объяснять логистику складских процессов разным заместителям, каждый раз получая новую вводную. Итог: проект, рассчитанный на 8 месяцев, шел полтора года. На этапе опытной эксплуатации выяснилось, что блок планирования производства полностью расходится с реальными потребностями цеха. При подписании закрывающих документов заказчик заявил, что система «нерабочая», хотя команда внедрения строго следовала тем противоречивым вводным, которые давали разные сотрудники завода. Конфликт дошел до разбирательства в центральном офисе вендора, а бюджет проекта превысил плановый на 60%.
Вывод: Один голос — одно действие. РП со стороны заказчика фильтрует «хотелки» и превращает хаос требований в четкие задачи, экономя сотни человеко-часов всей проектной команде.
2. Тестирование: как «замыленный глаз» саботирует запуск
Выполненные работы нужно принимать не на словах, а руками. Но кто заставит бухгалтера, у которого и так аврал, сесть и гонять тестовые сценарии в незнакомой базе? Команда внедрения со стороны исполнителя? Нет, у них нет административного ресурса внутри вашей компании. Их менеджер может вежливо попросить, написать письмо, эскалировать проблему своему куратору, но заставить вашего сотрудника выполнить рутинную, но критически важную работу они не в силах.
Только руководитель проекта со стороны заказчика, обладающий полномочиями (желательно подкрепленными приказом гендиректора), может обязать коллег вовремя провести тестирование.
Без этого контроля наступает «эффект отложенного фиаско». Подрядчик сдает этап, пишет акт. Заказчик машет рукой: «Некогда проверять, потом посмотрим, вы же гарантию даете». Проходит месяц, два, запускается следующий этап, наслаиваются доработки. И когда наконец доходят руки до полноценного тестирования, оказывается, что фундаментальная логика была неверна, но она уже обросла таким количеством нового кода и документации, что переделывать всё придется заново и за отдельные деньги.
Пример из жизни другой компании:
В одной торговой сети внедряли блок управления запасами. Сотрудники отдела закупок саботировали участие в тестировании, считая, что «раньше в Excel считали, и дальше будем, а это ваша ИТ-шная блажь». РП со стороны заказчика был назначен формально — эти функции попытались повесить на и без того перегруженного финансового директора, у которого не было времени следить за дисциплиной тестирования и работой ассистентов. Команда интегратора закрывала спринты по формальным признакам, так как обратной связи от пользователей не поступало. При попытке запустить автозаказ в промышленную среду система выдала такой объем неликвидного товара, что могла парализовать оборотные средства компании на месяцы. Потребовалось экстренное отключение модуля и новое трехмесячное расследование причин ошибки, в ходе которого исполнитель доказывал, что алгоритм был согласован в ТЗ и протестирован ровно на тех данных, которые предоставил заказчик.
Вывод: Без жесткой руки РП тестирование превращается в фикцию. А не найденный вовремя баг в 1С — это реальная финансовая дыра, а не просто иконка на рабочем столе.
3. Финансовый финиш: как не стать заложником приемки
Самый болезненный момент любого внедрения — закрытие актов и оплата. Когда со стороны заказчика нет ответственного лица, уполномоченного принимать решения, команда подрядчика попадает в бюрократический лабиринт. Сначала акт неделями лежит у юриста, потом у финансиста, потом его пытается завизировать собственник, который «в процессе не участвовал, но хочет видеть результат».
Знакомая картина? Менеджер проекта со стороны исполнителя вынужден пробиваться на прием к ЛПР (лицу, принимающему решения), чтобы доказать очевидное: работы выполнены по ТЗ, система работает, команда отработала этап, дайте денег. Если же на проекте есть РП со стороны заказчика, эти вопросы решаются в рабочем порядке. РП — это адвокат проекта внутри компании заказчика. Он защищает бюджет и сроки от необоснованных претензий своих же коллег и при этом следит, чтобы команда внедрения не схалтурила и не навязала лишних трудозатрат. Это паритет, без которого проект скатывается в воронку взаимных обвинений.
4. Каким набором качеств должен обладать идеальный РП со стороны заказчика (независимо от должности)
Многие компании, осознав необходимость РП, пытаются назначить на эту роль человека по остаточному принципу: «Пусть Ваня из ИТ-отдела посматривает, он в компьютерах разбирается» или «Главбух все равно все процессы знает, пусть она и руководит». Это фатальная ошибка. Важно понимать: системный администратор, обслуживающий ваши серверы, и команда внедрения 1С — это принципиально разные вселенные. Сисадмин отвечает за «железо», сеть и установку обновлений платформы, но он не управляет бизнес-процессами и уж точно не обладает весом, чтобы заставить коммерческого директора перестроить работу отдела.
Неважно, кто этот человек по должности — начальник производства, ведущий аналитик, руководитель отдела продаж или специально нанятый проектный менеджер. Важен набор компетенций, а не строчка в трудовой книжке. Без этих качеств проект обречен на турбулентность:
- Административный вес и доступ к «телу». У этого сотрудника должен быть мандат доверия от первого лица компании. Без этого он не сможет заставить коммерческого директора изменить привычный маршрут согласования заявки или обязать кладовщика вовремя провести инвентаризацию в тестовой базе.
- Временной ресурс. Проект внедрения — это не довесок к основной работе в режиме «между обедом и планеркой». Это вторая полноценная работа на ближайшие полгода-год. Если руководство не готово разгрузить сотрудника от операционки на 30-50%, лучше сразу закладывать в бюджет внешнего РП на аутсорсе.
- Умение говорить «нет». Это ключевой навык. «Нет» подрядчику — когда тот ради собственного удобства предлагает излишне сложное и дорогое решение, которое не окупится. «Нет» своим сотрудникам — когда они под видом «критически важной доработки» пытаются оставить всё как в старом Excel, убивая саму идею автоматизации.
- Системное мышление. РП должен видеть картину целиком. Сотрудник, зацикленный только на технической части кода, или бухгалтер, видящий только ОСВ, одинаково опасны. Нужен человек, понимающий, как связаны склад, производство, продажи и финансы.
Заключение
Внедрение 1С — это история не про написание кода, а про управление изменениями. Провалы случаются не потому, что платформа «1С:Предприятие» плохая или команда интегратора недостаточно компетентна. Провалы случаются там, где заказчик не сформировал проектную власть на своей территории.
Не будьте тем самым домовладельцем, который удивляется кривым стенам, вернувшись из отпуска. Назначьте прораба на своей стороне. И неважно, какую должность он занимает сейчас — будь то аналитик, начальник цеха или руководитель отдела развития. Важно, чтобы у него были полномочия наводить порядок, время на это занятие и смелость принимать решения. Только в такой связке дорогостоящая команда аналитиков, архитекторов и разработчиков исполнителя сможет выдать тот результат, за который вы платите деньги, а не бесконечный протокол разногласий.
Партнерство рождается не тогда, когда один платит, а другой делает. Партнерство — это когда обе стороны несут равную ответственность за результат. И начинается оно с выбора сильного игрока в вашей команде.
