Как сэкономить бюджет на внедрении 1С ERP в 2025 году?

В нашем блоге вопрос оценки стоимости проекта такого рода детально описан в статье Сколько стоит внедрить 1С:ERP.

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

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

Но в связи с возрастающими бюджетными ограничениями, а также с необходимостью все-таки переходить на 1С ERP (просто в силу того, что предшественник, 1С УПП, снимается с поддержки), мы постараемся дать рекомендации – как оптимизировать (а местами – и сэкономить) бюджет на внедрение.

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

Итак. Бюджет на проект такого рода может отличаться в разы (дисклеймер: в нашей практике «среднего размера» проект обходится от 10 до 60 миллионов рублей). Общая продолжительность такого проекта составляет порядка 20-24 месяцев.

Какие рекомендации мы можем дать потенциальным заказчикам

  1. Выбирайте подрядчиков до того, как начнете собирать ценовые предложения.

Оптимальный подход: приглашать в конкурс только тех, кто имеет опыт аналогичных проектов, имеет собственную команду (и может подтвердить квалификацию специалистов)

  • Не спрашивайте ставки в самом начале – сравнивайте вначале из по существу.
  • Попросите прислать портфолио (список завершенных проектов).
  • Расскажите о себе и предложите поделиться опытом работы с аналогичными компаниями.
  • Предложите в ходе разговоров несколько кейсов, и послушайте, какие варианты решения предлагают разные подрядчики.
  • На квалификационный отбор лучше ходить командой из нескольких человек с разным опытом – в этом случае оценка будет всесторонней.

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

  1. При проведении конкурса никогда не принимайте самое дешевое предложение.

Доказанный факт: оптимальная цена – как минимум, вторая после «лучшей», доказано лауреатами Нобелевской премии по экономике за 2020 год Полом Милгром и Робертом Уилсоном

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

Компания, которая предлагает наиболее выгодный вариант (в случае с проектом – минимальную стоимость) имеет самую оптимистическую оценку, и с высокой вероятностью получит «проклятье победителя», т.е. ситуацию, когда победитель завершает проект с убытком, или уходит из проекта или существенно начитает экономить по его ходу. В конечном итоге минимальная цена в начале оборачивается компромиссным завершением проекта, увеличением бюджета и иногда сменой подрядчика.

Подсказка: даже если вы ставите ценовой фактор на первое место, не давайте ему 100% вес в тендерной документации.

  1. Подготовьтесь к конкурсу. Чем лучше ваша подготовка, тем качественнее будут коммерческие предложения от поставщиков.

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

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

  • Протоколы предварительных интервью с ключевыми пользователями (эти протоколы потом войдут в состав функционального дизайна и сократят время на интервью в основном проекте, т.е. эти затраты точно не в пустую)
  • Обоснование по рамкам проекта и предварительная оценка трудозатрат на проект в часах* (обычно это параметрическая оценка «от-до» с указанием допущений и ограничений)
  • Конкурсное техническое задание, по которому можно начинать конкурс.
  • При необходимости – настроенные демонстрационные процессы на стандартном функционале системы

Подсказка: Средняя стоимость такой услуги — от 1-2 млн. рублей, что составляет несколько процентов от общей стоимости проекта. Предварительное обследование занимает 4-8 недель.

  1. В ходе конкурса проводите процедуру защиты коммерческих предложений.

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

Любая цифра является обоснованной, и понимая не только сумму, но и перечень работ, вы будете лучше понимать выходной результат. Необходимо разбираться с отличиями как в большую, так и в меньшую сторону. Например, разница в несколько миллионов рублей на этапе построения может означать, что один подрядчик запланировал нагрузочное тестирование системы, а другой – нет. Когда вы понимаете эту разницу, вы можете для себя принять (или не принять) риск/бюджет и четко понимать – для вас важнее гарантированная скорость работы системы в определенных операциях или экономия этих нескольких миллионов руб. Но – это будет ваше решение, и оно будет обоснованным.

  1. По максимуму используйте стандартные возможности ПО. Чем меньше уникальность, тем меньше бюджет.

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

  • 1С ERP уже вобрала в себя опыт сотен проектов практически во всех секторах экономики. Проект, аналогичный вашему, кем-то уже был реализован с определенными допущениями на стандартном функционале.
  • За любую модификацию вы платите дважды: сначала в момент реализации – подрядчику, потом – при каждом обновлении – поддержке.
  • Существующий механизм расширений позволяет реализовать очень многие функции, при этом вы не получите проблем с обновлением

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

  1. Минимизируйте количество разрабатываемых отчетов (как дополнительная рекомендация в продолжение предшествующего пункта).

Старайтесь использовать стандартный функционал, научитесь пользоваться СКД (системой компоновки данных), установите 1С Аналитика и настройте дашборды, но не делайте заказную разработку десятков отчетов для каждого отдела (просто на основании того, что они привыкли пользоваться аналогичными в старой системе). Если пользователи настаивают – лучше сначала собрать требования и список отчетов, а потом просеивать через сито целесообразности. Иначе команда разработчиков будет несколько недель делать потратят на то, что не дает ощутимого финансового результата. А вы потратите дополнительно несколько миллионов рублей.

  1. Не обязательно всё и сразу перетаскивать в 1С ERP.

Проект можно делать и по частям. Более того, проблема «отключения от поддержки» 1С УПП в большей мере влияет на вопросы подготовки регламентированной/налоговой отчетности и в меньшей мере – на внутренние процессы, такие, как движение материалов и производственные операции.

Это означает, что, в условиях ограниченного бюджета не обязательно переносить сразу все процессы в новую систему. Рассмотрите интеграцию старой УПП (где материальный учет и производство могут существовать в привычной оболочке много лет) и новой ERP, куда вы первым этапом будете переносить данные по операциям и формировать проводки и финансовые транзакции. Да, у вас будет две системы и интерфейс между ними. Но – вы закрываете две проблемы – и экономите бюджет в ситуации нехватки средств и закрываете риски, связанные с отчетностью.

  1. Тщательно подбирайте собственную команду, не перекладывайте все проектные задачи на подрядчика.

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

Хорошая практика, когда со старта работ со стороны заказчика в выделенной команде есть:

  • Ключевые пользователи – наиболее подготовленные специалисты (и еще те, кто не собирается от вас увольняться), которые в ходе проекта будут изучать функциональность по своему бизнес-направлению. И после завершения проекта станут основными хранителями компетенции.
  • Эксперты – носители методологии. Те, кто будет выступать постановщиком задач и приемщиком результата
  • Координаторы процессов, руководитель проекта от заказчика, административный персонал, обеспечивающий согласование и коммуникации проектной команды

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

  1. Привлекайте своих специалистов на отдельные виды работ.

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

Какого типа задачи вы можете забирать себе:

  • Частично – тестирование. Кроме непосредственной экономии это позволяет повысить квалификацию ваших ключевых пользователей и быстрее разобраться с функционалом. Частично, т.к. некоторые виды тестирования (авто тесты, нагрузочные) требуют специальных технических познаний. А вот протестировать расширения, настройки или модификации системы – вполне по силам «продвинутым» пользователям, участвующим в проекте.
  • Обучение «простых» пользователей. Эту функцию вполне могут забрать себе ключевые пользователи. Тем более, им потом работать вместе – мотивация должна быть высокой.
  • MDM – мастер-данные – подготовка справочников. Трудоемкая работа, требующая усидчивости и внимания, но окупается сторицей – вы не перенесете в систему «мусорные» записи.
  • Перенос остатков пред стартом, проверка настроек.
  • Методологические вопросы.
  • И многое другое, на что хватит ресурса и квалификации.
  1. Принимайте работы по частям и регулярно.

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

Хорошей практикой является поэтапное принятие от исполнителя результатов проекта, с четким пониманием – какой материальный результат вы должны получить на каждом этапе (для этого опытные руководители проекта пишут устав и в нем прописывают – что именно должно передаваться заказчику по мере продвижения в оказании услуг).

Подсказка: вот такие материальные результаты могут быть на каждом этапе проекта (и содержать в себе еще и промежуточные вехи).

ЭТАП МАТЕРИАЛЬНЫЙ РЕЗУЛЬТАТ
Анализ и дизайн Описанные функциональные требования (вехи – по отдельным блокам учета)

Архитектура системы и интерфейсов обмена со смежными системами

Перечень настроек, расширений и модификаций

Построение Настроенная и готовая к старту конфигурация (вехи- отдельные демо по отдельным блокам)

Протестированные и принятые модификации и интерфейсы обмена (соответственно, вехи по отдельным модификациям)

Готовая и проверенная инфраструктура

Внедрение Обученные пользователи

Перенесенные остатки и справочники

Готовая инфраструктура (сети, ПК, сервера…)

  1. Требуйте качественную документацию и храните ее бережно.

Хорошо сделанная документация сэкономит вам в будущем массу сил и средств:

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

  1. Придерживайтесь планов и графиков. И требуйте того же от подрядчика.

Если какая-то встреча сорвалась, не состоялась, перенеслась – это упущенное время и дополнительные затраты (вы оплачиваете простои команды, прямо или косвенно). Кроме того, масса мелких срывов имеет способность накапливаться и существенно влиять на сроки запуска проекта.

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

Кроме сроков, придерживайтесь согласованных рамок проекта, не давайте ему увеличиваться в объёмах без крайней необходимости. Если вы правильно запланировали бюджет (в том числе – не выбрали самое дешевое предложение), этого риска можно избежать.

 

Оригинал статьи размещен на портале РБК Компании.

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