Как сэкономить бюджет на внедрении 1С ERP в 2025 году?
В нашем блоге вопрос оценки стоимости проекта такого рода детально описан в статье Сколько стоит внедрить 1С:ERP.
Единственная корректировка: в условиях инфляции, превышающей базовый прогноз и ставки рефинансирования, превышающей 20% к началу 2025 года, стоимость проекта, указанная в публикации, увеличилась примерно на треть, по каждой из перечисленных статей затрат.
Добавить по вопросу стоимости существенно нечего, так как методология работы, структура затрат остались прежними.
Но в связи с возрастающими бюджетными ограничениями, а также с необходимостью все-таки переходить на 1С ERP (просто в силу того, что предшественник, 1С УПП, снимается с поддержки), мы постараемся дать рекомендации – как оптимизировать (а местами – и сэкономить) бюджет на внедрение.
Ниже приведенные советы – это рекомендации, которые мы выработали в многолетней практике. Приведённый перечень – не является исчерпывающим, и опытный руководитель проекта знает еще десятки приемов. Прежде всего этой публикацией мы преследовали цель показать, что существуют приемы управления бюджетом, позволяющие заниматься автоматизацией в разнообразных финансовых ситуациях. Важно так же понимать – автоматизация это инвестиционные вложения, следовательно, финансовым результатом внедрения возможно управлять так же как и в другом любом инвест.проекте.
Итак. Бюджет на проект такого рода может отличаться в разы (дисклеймер: в нашей практике «среднего размера» проект обходится от 10 до 60 миллионов рублей). Общая продолжительность такого проекта составляет порядка 20-24 месяцев.
Какие рекомендации мы можем дать потенциальным заказчикам
- Выбирайте подрядчиков до того, как начнете собирать ценовые предложения.
Оптимальный подход: приглашать в конкурс только тех, кто имеет опыт аналогичных проектов, имеет собственную команду (и может подтвердить квалификацию специалистов)
- Не спрашивайте ставки в самом начале – сравнивайте вначале из по существу.
- Попросите прислать портфолио (список завершенных проектов).
- Расскажите о себе и предложите поделиться опытом работы с аналогичными компаниями.
- Предложите в ходе разговоров несколько кейсов, и послушайте, какие варианты решения предлагают разные подрядчики.
- На квалификационный отбор лучше ходить командой из нескольких человек с разным опытом – в этом случае оценка будет всесторонней.
Подсказка: самый короткий путь составить список подрядчиков – посмотреть на список ежегодных участников ERP форума. Это крупнейшее мероприятие, на котором собираются ведущие «внедренцы»; как минимум – проработку стоит начать именно с этого списка, т.к. в нем нет «случайных» компаний.
- При проведении конкурса никогда не принимайте самое дешевое предложение.
Доказанный факт: оптимальная цена – как минимум, вторая после «лучшей», доказано лауреатами Нобелевской премии по экономике за 2020 год Полом Милгром и Робертом Уилсоном
В двух словах: они проводили исследования эффективности аукционов в условиях информационной неопределенности (а это как раз ситуация оценки проекта), где крайне частым является недооценка рисков или переоценка будущей прибыли.
Компания, которая предлагает наиболее выгодный вариант (в случае с проектом – минимальную стоимость) имеет самую оптимистическую оценку, и с высокой вероятностью получит «проклятье победителя», т.е. ситуацию, когда победитель завершает проект с убытком, или уходит из проекта или существенно начитает экономить по его ходу. В конечном итоге минимальная цена в начале оборачивается компромиссным завершением проекта, увеличением бюджета и иногда сменой подрядчика.
Подсказка: даже если вы ставите ценовой фактор на первое место, не давайте ему 100% вес в тендерной документации.
- Подготовьтесь к конкурсу. Чем лучше ваша подготовка, тем качественнее будут коммерческие предложения от поставщиков.
Помните, что потенциальным подрядчикам приходится делать оценки в условиях неполной информации. Чем качественнее будет конкурсная документация, тем качественнее будут предложения.
В том случае, когда собственной квалификации, либо ресурсов недостаточно для подготовки конкурса такого рода, мы настоятельно рекомендуем проведение предпроектное обследование. Это услуга, в результате которой подрядчик получает, в качестве материального результата:
- Протоколы предварительных интервью с ключевыми пользователями (эти протоколы потом войдут в состав функционального дизайна и сократят время на интервью в основном проекте, т.е. эти затраты точно не в пустую)
- Обоснование по рамкам проекта и предварительная оценка трудозатрат на проект в часах* (обычно это параметрическая оценка «от-до» с указанием допущений и ограничений)
- Конкурсное техническое задание, по которому можно начинать конкурс.
- При необходимости – настроенные демонстрационные процессы на стандартном функционале системы
Подсказка: Средняя стоимость такой услуги — от 1-2 млн. рублей, что составляет несколько процентов от общей стоимости проекта. Предварительное обследование занимает 4-8 недель.
- В ходе конкурса проводите процедуру защиты коммерческих предложений.
Выделите время и обсудите с каждым кандидатом условия их предложений. Попросите обосновать трудозатраты и суммы, которые существенно отличаются от предложений других участников.
Любая цифра является обоснованной, и понимая не только сумму, но и перечень работ, вы будете лучше понимать выходной результат. Необходимо разбираться с отличиями как в большую, так и в меньшую сторону. Например, разница в несколько миллионов рублей на этапе построения может означать, что один подрядчик запланировал нагрузочное тестирование системы, а другой – нет. Когда вы понимаете эту разницу, вы можете для себя принять (или не принять) риск/бюджет и четко понимать – для вас важнее гарантированная скорость работы системы в определенных операциях или экономия этих нескольких миллионов руб. Но – это будет ваше решение, и оно будет обоснованным.
- По максимуму используйте стандартные возможности ПО. Чем меньше уникальность, тем меньше бюджет.
Смотрите в первую очередь варианты организации процессов на стандартном функционале; оценивайте необходимость каждой модификации. Важно помнить, что
- 1С ERP уже вобрала в себя опыт сотен проектов практически во всех секторах экономики. Проект, аналогичный вашему, кем-то уже был реализован с определенными допущениями на стандартном функционале.
- За любую модификацию вы платите дважды: сначала в момент реализации – подрядчику, потом – при каждом обновлении – поддержке.
- Существующий механизм расширений позволяет реализовать очень многие функции, при этом вы не получите проблем с обновлением
Подсказка: В некоторых случаях дешевле пересмотреть и перенастроить бизнес-процесс, чем создавать модификацию.
- Минимизируйте количество разрабатываемых отчетов (как дополнительная рекомендация в продолжение предшествующего пункта).
Старайтесь использовать стандартный функционал, научитесь пользоваться СКД (системой компоновки данных), установите 1С Аналитика и настройте дашборды, но не делайте заказную разработку десятков отчетов для каждого отдела (просто на основании того, что они привыкли пользоваться аналогичными в старой системе). Если пользователи настаивают – лучше сначала собрать требования и список отчетов, а потом просеивать через сито целесообразности. Иначе команда разработчиков будет несколько недель делать потратят на то, что не дает ощутимого финансового результата. А вы потратите дополнительно несколько миллионов рублей.
- Не обязательно всё и сразу перетаскивать в 1С ERP.
Проект можно делать и по частям. Более того, проблема «отключения от поддержки» 1С УПП в большей мере влияет на вопросы подготовки регламентированной/налоговой отчетности и в меньшей мере – на внутренние процессы, такие, как движение материалов и производственные операции.
Это означает, что, в условиях ограниченного бюджета не обязательно переносить сразу все процессы в новую систему. Рассмотрите интеграцию старой УПП (где материальный учет и производство могут существовать в привычной оболочке много лет) и новой ERP, куда вы первым этапом будете переносить данные по операциям и формировать проводки и финансовые транзакции. Да, у вас будет две системы и интерфейс между ними. Но – вы закрываете две проблемы – и экономите бюджет в ситуации нехватки средств и закрываете риски, связанные с отчетностью.
- Тщательно подбирайте собственную команду, не перекладывайте все проектные задачи на подрядчика.
Даже просто в силу того, что подрядчик уйдет после завершения работ, а вам дальше с этой системой жить.
Хорошая практика, когда со старта работ со стороны заказчика в выделенной команде есть:
- Ключевые пользователи – наиболее подготовленные специалисты (и еще те, кто не собирается от вас увольняться), которые в ходе проекта будут изучать функциональность по своему бизнес-направлению. И после завершения проекта станут основными хранителями компетенции.
- Эксперты – носители методологии. Те, кто будет выступать постановщиком задач и приемщиком результата
- Координаторы процессов, руководитель проекта от заказчика, административный персонал, обеспечивающий согласование и коммуникации проектной команды
Наличие собственной команды позволяет вам удерживать компетенцию внутри себя, выполнять часть работ собственными силами и обеспечить частичную поддержку после завершения проекта. И это все позволяет существенно экономить бюджет.
- Привлекайте своих специалистов на отдельные виды работ.
Вы существенно сократите бюджет, если возьмете на себя часть проектных работ. Здесь, конечно, требуется понимание, что сотрудники будут «вырваны» из операционной деятельности, и им надо будет доплачивать за переработки, но – доплата за совмещение всегда существенно ниже, чем часовая ставка за услуги подрядчика.
Какого типа задачи вы можете забирать себе:
- Частично – тестирование. Кроме непосредственной экономии это позволяет повысить квалификацию ваших ключевых пользователей и быстрее разобраться с функционалом. Частично, т.к. некоторые виды тестирования (авто тесты, нагрузочные) требуют специальных технических познаний. А вот протестировать расширения, настройки или модификации системы – вполне по силам «продвинутым» пользователям, участвующим в проекте.
- Обучение «простых» пользователей. Эту функцию вполне могут забрать себе ключевые пользователи. Тем более, им потом работать вместе – мотивация должна быть высокой.
- MDM – мастер-данные – подготовка справочников. Трудоемкая работа, требующая усидчивости и внимания, но окупается сторицей – вы не перенесете в систему «мусорные» записи.
- Перенос остатков пред стартом, проверка настроек.
- Методологические вопросы.
- И многое другое, на что хватит ресурса и квалификации.
- Принимайте работы по частям и регулярно.
Нет хуже ситуации, когда отсутствует промежуточный контроль и результат проекта принимается целиком в самом конце.
Хорошей практикой является поэтапное принятие от исполнителя результатов проекта, с четким пониманием – какой материальный результат вы должны получить на каждом этапе (для этого опытные руководители проекта пишут устав и в нем прописывают – что именно должно передаваться заказчику по мере продвижения в оказании услуг).
Подсказка: вот такие материальные результаты могут быть на каждом этапе проекта (и содержать в себе еще и промежуточные вехи).
ЭТАП | МАТЕРИАЛЬНЫЙ РЕЗУЛЬТАТ |
Анализ и дизайн | Описанные функциональные требования (вехи – по отдельным блокам учета)
Архитектура системы и интерфейсов обмена со смежными системами Перечень настроек, расширений и модификаций |
Построение | Настроенная и готовая к старту конфигурация (вехи- отдельные демо по отдельным блокам)
Протестированные и принятые модификации и интерфейсы обмена (соответственно, вехи по отдельным модификациям) Готовая и проверенная инфраструктура |
Внедрение | Обученные пользователи
Перенесенные остатки и справочники Готовая инфраструктура (сети, ПК, сервера…) |
- Требуйте качественную документацию и храните ее бережно.
Хорошо сделанная документация сэкономит вам в будущем массу сил и средств:
Как информация для поддержки и доработки. Информационные системы, как и другие технически сложные устройства, пока работают хорошо – не требуют инструкций. Но стоит чему-то поломаться, пользователи и поддержка сразу кинутся читать документацию. Чем лучше и точнее она будет написана, тем меньше времени потребуется для устранения сбоев.
- Придерживайтесь планов и графиков. И требуйте того же от подрядчика.
Если какая-то встреча сорвалась, не состоялась, перенеслась – это упущенное время и дополнительные затраты (вы оплачиваете простои команды, прямо или косвенно). Кроме того, масса мелких срывов имеет способность накапливаться и существенно влиять на сроки запуска проекта.
Требуйте соблюдения сроков как от своих сотрудников, так и от команды подрядчика. Для этого в том числе и существует руководитель проекта.
Кроме сроков, придерживайтесь согласованных рамок проекта, не давайте ему увеличиваться в объёмах без крайней необходимости. Если вы правильно запланировали бюджет (в том числе – не выбрали самое дешевое предложение), этого риска можно избежать.
Оригинал статьи размещен на портале РБК Компании.
Поможем перейти с 1С УПП на 1С ЕРП
Оставьте заявку. Мы свяжемся с вами в ближайшее время.