Что может пойти не так при внедрении 1С:Документооборот: 7 рисков и как их снизить

Сроки сдвинулись, бюджет вырос, ожидания не совпали с результатом — обычно именно это называют рисками проекта. Но если срок уже сорван, это не риск, а свершившийся факт. Управлять нужно тем, что привело к нему раньше: расплывающимися требованиями, отсутствием ответственного со стороны заказчика, потерянным контекстом или бесконечным согласованием.

Мы собрали семь ситуаций, которые встречались на реальных проектах внедрения 1С:Документооборот. Не каждая из них обязательно превращается в проблему. Но каждая способна однажды выстрелить — обычно в самый неудобный момент.

Главная мысль: рост стоимости, срыв сроков и заморозка проекта — это последствия. Настоящий риск всегда конкретнее, а значит, с ним можно работать.

Риск 1. Требования начинают расти уже после старта
Риск 2. В типовом решении обнаруживается ошибка
Риск 3. У заказчика нет руководителя проекта, куратора или времени
Риск 4. Заказчик и исполнитель говорят на разных языках
Риск 5. Руководитель проекта или куратор меняется во время внедрения
Риск 6. Пользователи сопротивляются новой системе
Риск 7. Проектная документация согласовывается бесконечно
Короткий чек-лист перед стартом проекта
Какие риски встречаются чаще и какие опаснее

Проект может начинаться с понятной фразы: «Хотим автоматизировать документооборот». Через несколько встреч выясняется, что за ней скрываются договоры, закупки, бюджетирование, склад, кадровые процессы — и желательно всё сразу. На одном из проектов руководитель вернулся с конференции на волне энтузиазма и предложил добавить в проект по транспортной логистике криптовалюту — просто потому, что это модно.

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

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

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

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

Из практики: доработки любят гораздо меньше, чем принято думать. Они приносят не только дополнительную работу, но и новые сроки, стоимость, тестирование и ответственность.

Ошибки встречаются в любом программном продукте. Большая система развивается, в неё вносят изменения разные команды, выпускаются новые версии — предусмотреть абсолютно всё невозможно. Сам факт ошибки ещё не катастрофа. Катастрофой она становится, если обновление без проверки сразу попадает в рабочую базу.

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

Правило простое и не новое: сначала тестовая база, затем рабочая. Тем удивительнее, как часто проект вспоминает о нём уже после фразы «что-то пошло не так».

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

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

Ещё один тревожный сигнал — фраза: «Делайте сами, вы же специалисты». Через месяц она легко превращается в: «Почему вы сделали не так?» Специалист по внедрению знает продукт, но не может вместо заказчика определить, как именно компания должна принимать решения, согласовывать документы и распределять ответственность.

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

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

У каждой отрасли свой словарь. Одно и то же сокращение в двух компаниях может означать разные вещи, а привычное слово — иметь неожиданно узкий смысл. Например, на одном из проектов выяснилось, что «маршрут» в логистике означает совсем не то, что консультант представлял по обычному значению слова.

У внедренцев есть собственная терминология 1С:Документооборот, у заказчика — профессиональный язык отрасли. В начале разговора обе стороны уверены, что понимают друг друга. Расхождение обнаруживается позже, когда уже настроены справочники, процессы или роли.

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

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

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

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

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

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

Саботаж редко начинается с решения «буду мешать проекту». Чаще человек боится потерять привычный порядок, влияние или работу. Новая система выглядит как дополнительная нагрузка, контроль и источник ошибок — особенно если о ней впервые рассказали за день до запуска.

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

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

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

Исполнитель завершил обследование или подготовил модель, но согласование со стороны заказчика занимает недели. Документ ходит по кругу, появляются новые замечания, затем возвращаются уже закрытые вопросы. В плане проекта стоял срок выполнения работ, но никто не заложил два месяца ожидания ответа.

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

Срок согласования нужно заранее включить в график и контролировать с обеих сторон. Полезно ограничить число итераций: например, первая версия собирает замечания, вторая подтверждает исправления и становится финальной. Когда участники знают, что кругов будет два, замечания формулируются внимательнее.

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

• Цель, границы и ожидаемый результат проекта зафиксированы и одинаково понятны сторонам.

• Назначены куратор и руководитель проекта со стороны заказчика, определены их полномочия.

• Есть заместитель, который участвует в проекте с самого начала, а не знакомится с ним в экстренной ситуации.

• У ключевых сотрудников выделено время на обследование, встречи, проверку и обучение.

• Изменения требований оцениваются по влиянию на сроки, стоимость и результат.

• Обновления и новые версии сначала проверяются на тестовой базе.

• Термины и сокращения собраны в глоссарий, а важные решения — в протоколы.

• Сроки и число итераций согласования включены в график проекта.

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