Внедрение идёт тяжело: что проверить в первую очередь

Как отличить рабочие трудности проекта от признаков, что дело не выправится само, что можно поправить без смены подрядчика и когда помогает независимый разбор со стороны

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

Короткий ответ: смотрим на управляемость, а не на настроение

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

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

Как отличить рабочие трудности от признаков, что дело не выправится

| Что происходит | Обычная трудность проекта | Признак, что нужен разбор |

|---|---|---|

| Сроки этапов сдвигаются | Сдвиг объясняют: называют причину, пересчитывают план, предлагают, что убрать из объёма | Даты переносят без объяснения, план не обновляется, объём не пересматривается |

| Приёмка этапов | Этап закрывают документом: отчёт о разрывах, прототипы, протокол сверки | Этапы «закрываются» на словах, следующий уже начат, а результата предыдущего нет |

| Требования растут | Новое пожелание попадает в реестр изменений с оценкой и приоритетом | Границы проекта не пересматриваются, а «доделаем потом» звучит на каждой встрече |

| Участие ваших людей | Финансы, производство, закупки и ИТ приходят на интервью и тестирование | Встречи переносятся, решения «согласуем позже», проект идёт без вашей команды |

| План и прогресс | Видны этапы, статус и список открытых вопросов с ответственными | Плана нет или он не обновлялся месяцами, о статусе вы узнаёте сами |

| Расхождения в данных | Расхождения разбирают по списку, у каждого есть решение | Список растёт, дату его закрытия никто назвать не может |

Если больше половины строк попали в правый столбец, дело не в характере людей, а в отсутствии управления проектом. Хорошая новость: управление наводится быстрее, чем меняется система.

Проект выправляется не тогда, когда найден виноватый, а когда появляются план этапов, письменные критерии приёмки и человек, который принимает решения в срок.

Что можно поправить без смены подрядчика

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

• Вернуться к плану этапов. Соберите план заново: что уже сделано, что осталось, какой результат у каждого этапа и когда он ожидается. План должен быть один и общий, а не две версии — у вас и у подрядчика.
• Договориться о критериях приёмки. Для каждого этапа письменно: какой документ вы получаете, кто его принимает, в какой срок и что считается замечанием. Без этого этапы закрываются на словах, а работа копится в конце.
• Ввести регламент изменений требований. Новое пожелание попадает в реестр, получает оценку влияния на срок и объём и одно из решений: берём в первую очередь, во вторую или отказываемся. Решение фиксирует заказчик, а не обсуждает заново на каждой встрече.
• Назначить одного ответственного со стороны заказчика. Не «ИТ-директор вообще», а человек с временем в календаре и правом решать спорные места между подразделениями. Там, где такого человека нет, решения ждут неделями, и проект стоит.

К этому стоит добавить короткий еженедельный статус: что сделано, что мешает, какие решения нужны от вас и к какому сроку. Полчаса раз в неделю обычно экономят месяцы.

Когда нужен независимый разбор

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

Для этого есть цифровой аудит: [Цифровой аудит за 5 дней](/quiz/uslugi/cifrovoy-audit). Пять рабочих дней: интервью с финансами, производством, ИТ и закупками, проверка системы и данных, разбор того, как закрывается период и считаются затраты. На выходе — отчёт, карта рисков и план работ по этапам с оценкой трудоёмкости.

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

Как разговаривать с подрядчиком и что фиксировать письмом

Разговор, который помогает проекту, отличается от разговора о претензиях. Смысл не в том, чтобы найти виноватого, а в том, чтобы вернуть проекту управляемость.

Что стоит спросить на встрече:

• какой этап идёт сейчас и что считается его результатом;
• какие решения ждут от нас и к какому сроку они нужны;
• что мешает работе и что подрядчик предлагает сделать в ближайшие недели;
• какой план на следующий месяц и какие в нём риски.

Что стоит фиксировать письмом, даже если отношения хорошие:

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

Переписка здесь не для суда, а для памяти: через месяц никто не будет вспоминать, кто что обещал на созвоне, а письмо с решением снимает половину споров.

Часть причин всегда на стороне заказчика, и это нормально

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

• У ключевых сотрудников нет времени. Они заняты текущей работой, а интервью и тестирование откладывают. Лечится календарём: часы на проект выделяют заранее и защищают как обычные встречи.
• Решения принимаются неделями. Спорное место ждёт согласования между подразделениями, команда простаивает. Лечится ответственным с правом решать и сроком на решение.
• Требования меняются по ходу. Так бывает почти всегда. Лечится реестром изменений и прямым пересмотром границ: что уходит во вторую очередь, если появляется новое.
• «Сделайте пока без нас». Тогда систему осваивают уже после запуска, и часть работы возвращается в привычные таблицы. Лечится участием ключевых пользователей в тестировании на своих сценариях.
• Данные не готовы. Справочники, остатки и правила их ведения — работа заказчика, её нельзя передать подрядчику. Лечится владельцем данных, назначенным до старта настройки.

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

Что делать дальше

Если проект буксует, есть два спокойных способа продолжить.

Первый — [расчёт ориентира в квизе](/quiz): несколько вопросов о масштабе, отрасли, текущей системе и задаче. Помогает понять, какой объём работ стоит за вашей ситуацией, и подготовиться к разговору с подрядчиком или к пересмотру плана.

Второй — [оставить заявку на аудит](/quiz/audit): обследование занимает 5 рабочих дней и заканчивается отчётом с картой рисков и планом работ. Если сначала нужно обсудить задачу, на странице аудита есть кнопка «нужна консультация эксперта» — заявка придёт менеджеру, и он согласует время разговора.

«Аксионт» работает на рынке 1С 15 лет, в компании 70+ специалистов, 77 кейсов внедрений и 38 отраслевых решений. К нам приходят и с проектами, которые уже идут: сначала разбираем состояние, потом предлагаем порядок действий.

<!-- Проверить перед публикацией: (1) подтвердить формулировку про цифровой аудит (пять рабочих дней, интервью с финансами, производством, ИТ и закупками, проверка системы и данных, отчёт с картой рисков и планом) и то, кто из команды его проводит; (2) согласовать, что статья описывает ситуации, а не конкретных подрядчиков, и что формулировки не читаются как упрёк заказчику или исполнителю; (3) подтвердить, что перечень того, что можно поправить без смены подрядчика (план этапов, критерии приёмки, регламент изменений, ответственный заказчика, еженедельный статус), совпадает с методикой компании и её шаблонами документов; (4) подтвердить, что перечень причин на стороне заказчика (время ключевых людей, сроки решений, изменения требований, участие в тестировании, готовность данных) можно публиковать в таком виде; (5) подтвердить актуальность утверждённого набора цифр компании на дату публикации (15 лет, 70+ специалистов, 77 кейсов внедрений, 38 отраслевых решений); (6) проверить, что в тексте нет цен, сумм, сроков окупаемости и обещаний результата; (7) подтвердить ссылки: страница услуги «Цифровой аудит за 5 дней», /quiz и /quiz/audit, и решить, где публикуем материал. -->