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