2025-08-14
Статистика показывает, что большинство компаний фокусируются на этапе внедрения ERP-систем, но недооценивают важность пост-внедренческой поддержки. В результате — низкая adoption rate среди пользователей, накопление технического долга и возврат к старым процессам.
Представьте — ваш проект внедрения 1С завершен. Долгие месяцы сбора требований, защита бюджета, согласования, бесконечные тестирования — всё позади. Система внедрена, требования по ТЗ выполнены. Казалось бы, можно выдохнуть и отпускать команду внедрения.
Однако, начинается сопровождение системы. И вместо упрощения процессов — новые проблемы: заявки множатся, критичные вопросы зависают, пользователи оставляют жалобы и продолжают работать по-старинке.
Почему так происходит?
Часто причина кроется не в плохом внедрении и не в «плохих пользователях» или «плохой команде сопровождения». Всё немного сложнее: проект не был грамотно передан на сопровождение. А это — отдельная и весьма важная часть жизненного цикла любой информационной системы.
Как её грамотно выстроить – рассказываю сотрудники ICL Soft: руководитель группы сопровождения 1С Мария Ефремова и ведущий Системный архитектор 1С Евгений Константинов.
Где теряется управление: классические проблемы на этапе перехода
1. Конфликт коммуникаций
Команда внедрения работала в компании месяцами, знала всех заказчиков и бизнес-процессы в деталях. А команда сопровождения? Для них пользователи — это набор заявок и почтовых адресов. Для пользователей — поддержка это такие же безликие почтовые адреса, задающие «странные вопросы» и не понимающие сути критичных бизнес-процессов.
Этот конфликт выливается в большой бэклог задач в ожидании информации, ответов и поиска ответственных. В итоге критичные вопросы могут зависать надолго, и формально в этом никто не виноват. Заявки копятся, проблемы не решаются, сроки срываются. А пользователи не понимают, зачем им нужно сопровождение, и мечтают вернуть «того самого архитектора из команды внедрения», который понимал всё с полуслова (а иногда и без слов).
2. Потеря контекста доработок
Если у вас не просто «коробочная» 1С (а так бывает почти всегда, если мы говорим о внедрениях в корпоративном секторе), значит в ходе реализации проекта вы адаптировали и кастомизировали её под потребности своих пользователей.
Оговоримся, что под адаптацией мы понимаем корректировки типового функционала, а кастомизация – это существенная переработка. Зачастую на этапе внедрения отдельные блоки, элементы и метаданные полностью перерабатываются относительно типовых механизмов – то есть система кастомизируется под потребности бизнеса.
Каждая такая доработка требует правки в коде, а для этого программисту нужна постановка — изложенное на языке метаданных системы техническое задание. Все эти постановки должны передаваться в ходе передачи проекта на сопровождение. Но часто на этапе передачи проекта из внедрения в сопровождение у специалистов не остаётся времени на систематизацию, и все постановки передаются «разрозненным списком» или вообще остаются где-то в архивах внедренцев.
Проблема ли это? Безусловно. Потому что в таком случае теряется историчность изменений объекта.
В итоге заявки решаются не оптимально и некорректно (то есть «в лоб», как это должно быть в типовом функционале). Можно обнаружить, что некий кастомный функционал не работает, отсутствует, сломался после обновлений от вендора или даже простой загрузки изменённых задач на продуктив.
3. «Хвосты» незавершённых задач
Часто бывает, что часть задач и доработок не завершается во время внедрения по различным объективным причинам. Например, не закончили тестирование и приёмку вовремя, в компании поменялись процессы или отдельные блоки системы были введены в эксплуатацию позже.
На этапе сопровождения все эти вопросы становятся актуальными, у заказчика появляется время довести их до ума, но в команде сопровождения не остаётся никаких данных об изначальных договорённостях, что приводит к ряду конфликтов.
Как итог команда сопровождения реализует доработки, но тратит слишком много времени на разбор задачи «с нуля» и неминуемо теряет на входе часть вводных, поэтому конечный продукт часто не соответствует изначальным ожиданиям ключевых пользователей.
Решение: грамотный транзишн
Транзишн — это не красивое слово из корпоративного лексикона, а практическая необходимость. Транзишн переводится как «переход» и в целом является практикой подконтрольного перехода от одного этапа жизненного цикла проекта/продукта к другому или подконтрольного изменения ключевых данных проекта.
Транзишн внедряют там, где есть некие функциональные стыки полномочий и ответственности.
5 ключевых этапов качественного транзишна
1. Планирование передачи
2. Формальная передача знаний
3. Фаза «тени»
4. Фаза «обратной тени»
5. Фиксация завершения
Зачастую транзишн ограничивают одним этапом – передачей знаний.
«Вот вам документация и инструкции, считаем, что транзишн проведён».
На самом деле начать нужно раньше, сформировав план передачи и назначив по каждому блоку или этапу ответственного и сроки. Затем нужно провести конференц-звонки с передачей документации и инструкций под запись, а также сессии вопросов и ответов. На этом заканчивается теоретическая подготовка, которой никогда не бывает достаточно.
Основные действия происходят на этапах 3 и 4 – это работа по реальным заявкам заказчика в режиме тени и обратной тени.
- Режим тени – это когда заявки решает внедрение, а сопровождение изучает подходы к решению.
- Режим обратной тени – это когда к решению приступает сопровождение, и оно может задавать вопросы, получать консультации и опыт внедрения.
Затем мы останавливаем эту работу и подводим итог, после чего внедрение выходит из проекта.
План выглядит достаточно логично и просто, но, несмотря на это, в процессе транзишна могут появляться проблемы. Мы подготовили практические лайфхаки по организации эффективного транзишна из опыта нашей команды.
1. Единое пространство документации
Документы должны быть актуальными и доступными. Мы, например, используем Confluence, но подойдут и другие решения: SharePoint, Wiki, сетевые диски — главное, чтобы всё велось системно.
2. Передача знаний — не формальность
Проводить передачу знаний нужно под запись. Так накапливаются артефакты, которые потом команда сопровождения может использовать в любой непонятной ситуации годами.
3. Обратная связь и разбор сложных кейсов
Важно при передаче знаний определить ведущего аналитика по каждому из блоков и описывать их в разрезе четырёх историй:
- «Историю системы»
- «Историю интеграции»
- «Историю заказчика»
- «Историю проекта»
Так появляется понимание, как устроена именно ваша система, а не абстрактный продукт 1С.
А что с «хвостами»?
Здесь одной передачи знаний не хватит. Необходимо обеспечить выполнение следующих действий:
1. Составить полный список незавершённых задач до начала транзишна к сопровождению.
2. Честно оценить, что закрывает внедрение, что — сопровождение. Согласовать с командой внедрения сроки, объём и меру участия в закрытии долгов.
3. Описать каждый «хвост» со стороны ответственных, а также процессов и проблем заказчика, которые он решает.
4. Передать каждый «хвост» сопровождению как отдельные мини-проекты.
Так заказчик поймет сроки по каждой задаче, а сопровождение не будет тратить время на разгадывание чужих черновиков.
Почему транзишн — это не просто «хорошая практика»
Грамотный транзишн помогает избежать:
1. Зависших критичных заявок.
2. Потери знаний о системе.
3. Срывов при обновлениях и подключении новых специалистов.
4. Конфликтов между заказчиком, внедрением и сопровождением.
Если транзишн – такой важный этап, почему же его часто не проводят в полном объёме?
Существует ряд проблем в организации качественной передачи сервиса:
1. Это сложно организовать — нужно знание методологии и готовность (желание) довести передачу до финала качественно.
2. Процесс требует времени и ресурсов — он может занимать до 7-10% от стоимости внедрения.
3. Есть соблазн «переложить» ответственность между командами.
Какие мы предлагаем пути для преодоления этих проблем:
- Заручиться поддержкой заказчика до начала сопровождения.
- Планировать транзишн на старте проекта внедрения.
- Выделить транзишн самостоятельным этапом как внедрения, так и сопровождения.
- Так как для сопровождения транзишн закладывает базу для всей дальнейшей работы, можно договариваться о дополнительных выгодах для заказчика при проведении транзишна.
Передача проекта на сопровождение — это не техническая формальность, а полноценный процесс, от которого зависит работоспособность вашей 1С в реальной эксплуатации. И чем раньше вы о нём задумаетесь, тем меньше шансов столкнуться с «хаосом на выходе».
Если вашему бизнесу предстоит передача 1С на сопровождение — оставьте заявку на консультацию. Наши эксперты помогут организовать плавный переход без потери данных и снижения производительности.
