Сколько стоит внедрить 1С ERP в 2023 году?

«Сколько стоит внедрить 1С:ERP», – неизбежный вопрос любого потенциального заказчика. Любой мой коллега-продажник из компании-интегратора почти наверняка столкнётся с этим вопросом на первой же встрече. Да, признаться, на месте заказчика я бы тоже хотел знать стоимость проекта на первой же встрече. Жаль, что в жизни так не бывает.

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

Итак, чтобы примеры были более показательны, пусть наша выдуманная компания ООО «Ромашка» представляет из себя производственное предприятие из пищевой отрасли, с полным производственным циклом, с количеством сотрудников около 600 человек. В компании используется устаревшая, практически «самописная» система на базе 1С:УПП и в конце 2022 года был утвержден проект миграции на новое решение на базе 1С:ERP, поскольку скоро УПП окончательно будет снята с поддержки. Будем считать, что проект стартует, например, в начале марта (провели переговоры с подрядчиками, тендер, согласовали и подписали договор и т.д.).

Не буду переписывать PMBOK, но всё-таки вспомним, что такое проект. Проект — это комплексное (иначе говоря, многосоставное), не повторяющееся мероприятие, ограниченное по времени, бюджету, ресурсам, а также четкими установленными целями и с заданными приоритетами. Таким образом у проекта есть:
1. Цель. Кроме самой цели есть и критерии её достижения. Цель должна удовлетворять критериям достижимости, измеримости и конкретности.
2. Определенная длительность, с началом и завершением.
3. Ресурсы в виде людей, бюджета и иных ресурсов. Обычно в проекте участвуют несколько подразделений и разнообразные специалисты, формально людские ресурсы закрепляются в структуре проекта.
4. Приоритеты. Должны быть четко установлены приоритеты в рамках «треугольника приоритетов» — содержание/бюджет/сроки.

На примере нашего проекта в ООО «Ромашка» сформулируем описание цели: «Перенести основную функциональность текущей системы на базе 1С:УПП в новую систему на базе 1С:ERP, которая позволит осуществлять все основные текущие бизнес-процессы в новой системе начиная с начала следующего года. Приоритет проекта – срок. Допускается сокращение функционального объема проекта исходя из приоритета «срок» и реализация части вспомогательного функционала после завершения текущего проекта (в т.ч. ряд отчетов, доработки направленные на повышение юзабилити, удобств – точный объем отложенной функциональности будет определен в ходе реализации текущего проекта). Критерий успешности завершения проекта – функционирование основных бизнес-процессов в новой системе и сдача пакета управленческой отчётности за один месяц».

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

Поскольку мы пытаемся ответить на вопрос стоимости проекта, давайте перечислим, из каких компонентов она складывается, а далее проанализируем:

Стоимость консалтинга и трудозатраты собственной команды

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

Методология

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

1. Классическая водопадная методология. Восходит к началу 60-х годов, и по сути первая методология в рамках самой дисциплины «управление проектами». Предполагает последовательные этапы, которые не пересекаются и четко следуют один за одним, с формально проверяемыми результатами на каждом этапе. В наших 1С-проектах обычно выделяются такие этапы как подготовка к проекту (этот этап проходит на самом деле до старта проекта), анализ и моделирование, потом построение (разработка), внедрение (загрузка НСИ и настройка, обучение, старт), активная поддержка и передача в регулярную поддержку.
2. Agile-методология. Это дитя 2000-х, по  мнению agile-методологов классическая модель внедрения ERP-систем довольно неповоротлива, слишком формальная и медленная. В agile-методологии все работы по проекту разбиваются на спринты(итерации) продолжительностью 2-4 недели, перед каждым циклом проводится оценка приоритетов задач и их декомпозиция на более мелкие. Agile-методология позволяет в короткие сроки создать MVP (minimum viable product, минимально жизнеспособный продукт), и путем большого количества итераций и коммуникации – в конце концов достичь цели проекта. Меньше писанины томов документации – больше дела, это основной принцип agile.
3. Гибридная методология. Комбинирует подходы двух первых вариантов, но в практике ФТО мы пока не использовали данную методологию, хотя мне известно об успешном применении гибридной методологии в некоторых проектах наших коллег-интеграторов.

Фирма 1С предлагает для своих продуктов несколько вариантов адаптированных методологий: 

• «1С:Технология быстрого результата» («1С:ТБР») — базовая технология, основанная на agile-подходе, подходит для проектов внедрения типовых и отраслевых решений на платформе «1С:Предприятие 8»;
• «1С:Технология корпоративного внедрения» («1С:ТКВ») — «классическая» проектная технология, ориентированная на проекты разработки и масштабные проекты внедрения решений на платформе «1С:Предприятие 8».
• «1С:Технология стандартного внедрения» («1С:ТСВ») — технология, ориентированная на небольшие объемы проектных работ и содержащая некоторые базовые элементы управления проектом (хорошо подходит для внедрения типовых «коробок»);

Как пишет фирма 1С на сайте «1С:Консалтинг»: Технологии управления проектами внедрения, предлагаемые фирмой «1С», разработаны в соответствии с рекомендациями и требованиями мировых и отечественных стандартов, таких как:

• «Руководство к своду знаний по управлению проектами PMI PMBOK»;
• рекомендации по использованию agile-подходов к организации разработки программного обеспечения, такие как eXtreme Programming (XP) и SCRUM;
• стандарты ISO 9001 и ГОСТ Р ИСО 9001 «Системы менеджмента качества. Требования»;
• других рекомендаций выдающихся практиков в области разработки и внедрения информационных систем.

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

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

Далее перечислим основные этапы и содержание работ в рамках выбранной водопадной методологии на проекте внедрения 1С:ERP:

Этап проекта	Работы, выполняемые интегратором	Работы, выполняемые Заказчиком
Подготовка проекта	Подготовка проекта договора и Устава Подготовка предварительного плана проекта (точный на этап «Анализ и моделирование», предварительный на все остальные этапы)	Согласование договора и Устава, плана проекта Формирование и утверждение проектной команды Утверждение функционального объема проекта Подписание договора и старт проекта
Анализ и моделирование	Подготовка графика интервью, проведение интервью с бизнес-экспертами	Согласование графика интервью, участие в интервью
	Подготовка протоколов интервью, описаний бизнес-процессов	Согласование протоколов интервью, описаний бизнес-процессов
		Подготовка технической инфраструктуры в соответствии с требованиями, закупка оборудования, закупка ПО, настройка инфраструктуры
		Выполнение сайзинга, совместно с интегратором. Подготовка требований к системной архитектуре, совместно с интегратором.
	Подготовка графика моделирования, подготовка к моделированию и проведение моделирования, подготовка протоколов моделирования	Согласование графика моделирования, проведение моделирования процессов с ФТО, согласование протоколов моделирования
	Подготовка реестра выходных форм, формирования перечня модификаций, оценка и приоритизация	Согласование реестра выходных форм, перечня модификаций, приоритетов
Построение	Написание функциональных дизайнов (ФД, технические задания для разработчика) по согласованному списку модификаций	Согласование функциональных дизайнов
	Разработка модификаций по ФД
	Тестирование модификаций, интеграций с внешними системами	Пользовательское юнит-тестирование модификаций (если предусмотрено), согласование протоколов тестирования
	Подготовка к ИТ (интеграционному тестированию) — подготовка и настройка системы, проведение интеграционного тестирования, включая интеграции с внешними системами	Участие в ИТ, приемка системы и согласование протокола ИТ
	Если предусмотрено — Подготовка к нагрузочному тестированию (сценарии и скрипты), проведение нагрузочного тестирования и подготовка отчёта по нагрузочному тестированию	Согласование отчёта по нагрузочному тестированию
	Если предусмотрено – Подготовка к ТОД (тест одного дня) — подготовка системы, подготовка рабочих мест, проведение ТОД (поддержка пользователей, фиксация ошибок), подготовка протокола ТОД	Участие в ТОД, согласование протокола ТОД
	Разработка пользовательских инструкций по всем процессам, входящим в объем проекта, актирование работ по инструкциям	Согласование и приемка пользовательских инструкций, согласование акта по работам по разработке инструкций
Внедрение	Подготовка системы для обучения, подготовка графика обучения, проведение обучения, подготовка ведомостей по обучению, актирование обучения	Согласование графика обучения, участие в обучении, согласование акта по обучению
	Настройка параметров системы и прав пользователей	Настройка параметров (совместно с ФТО)
	Настройка интеграций с внешними системами	Настройка интеграций (совместно с ФТО, на стороне внешних систем)
	Настройка рабочих мест	Настройка рабочих мест (совместно с ФТО)
	Подготовка шаблонов для заполнения начальных данных (справочники и остатки), загрузка заполненных шаблонов в систему – в случае загрузки из шаблонов. В случае автоматической загрузки – подготовка скриптов загрузки и их запуск.	Заполнение шаблонов начальными данными – в случае загрузки из шаблонов.  Проверка корректности заполнения начальных данных в системе.
	Старт системы
Активная поддержка	Перевод пользователей в новую систему и их поддержка	Персонал Заказчика самостоятельно осуществляет работу в системе по всем процессам, включенным в функциональный объем
	Исправление обнаруженных ошибок	Согласование протокола активной поддержки
	Закрытие периода (один или несколько, в соответствии с условиями договора)

Структура проектной команды

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

Краткое описание ролей, кто что делает:

Где	Роль	Типичная плановая загрузка в ходе работ по проекту
Заказчик	Спонсор проекта. Основной заказчик проекта со стороны бизнеса. Отвечает за утверждение итоговых и промежуточных результатов проекта. Контролирует бюджет, входит в управляющий комитет.	Обычно до 10% на всем протяжении проекта
Заказчик	Координатор проекта. Руководитель проекта со стороны Заказчика. Необходимы полномочия на уровне заместителя генерального директора	До 100% на всем протяжении проекта.
Заказчик	Координатор от IT. Отвечает за организацию и построение инфраструктуры (оборудование, программное обеспечение, лицензирование, каналы связи, схемы резервирования, поставки и т.д.), управление командой IT.	До 50% в период построения инфраструктуры
Заказчик	Бизнес-эксперты по функциональным областям (закупки, продажи, логистика, учет, планирование, финансовая отчетность). Участие в интервью, совместная с консультантами выработка решений, согласование описаний БП, функциональных дизайнов, отчетных форм, пользовательское тестирование, интеграционное тестирование, обучение пользователей, активная поддержка.	До 60% на этапе анализ и моделирование, до 50% на этапе построения (тестирование, интеграционное тестирование), до 100% на этапе внедрения и поддержки
Заказчик	Ключевые пользователи. Участие в обучении, тестировании, интеграционном тестировании, поддержка процессов на старте совместно с командой интегратора	До 100% на этапах обучения и поддержки старта
Интегратор	Руководитель проекта. Планирование работ, управление проектной командой, управление рисками, оперативный контроль, контроль параметров (бюджет, сроки, рамки), управление изменениями, отчетность по проекту, финансовые вопросы.	До 100% на всем протяжении проекта
Интегратор	Ведущий консультант, консультант. Анализ и формализация описаний процессов, подготовка вариантов решений, разработка функциональных дизайнов модификаций, тестирование, интеграционное тестирование, разработка пользовательских процедур, обучение пользователей, подготовка начальных данных и настройка системы, активная поддержка на местах.	100 % на всём протяжении проекта
Интегратор	Разработчик. Разработка, первичное тестирование модификаций.	до 100 % на различных этапах
Интегратор	Менеджер по качеству. Руководитель верхнего уровня на стороне интегратора, отвечающий за качество реализации проекта, участвует в принятии ключевых проектных решений, разрешении конфликтных ситуаций на верхнем уровне управления	Обычно до 10% на всем протяжении проекта

Оценка трудоёмкости проекта

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

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

Оценка трудоёмкости проекта – это своего рода искусство. Наиболее разумное обоснование — ранее полученный опыт и конечно же анализ того, что мы узнаём в ходе подготовки к проекту. Обычно подготовка к проекту выполняется до заключения договора внедрения, и часто после подготовки к проекту следует проведение тендера. Я в своей практике видел если не тысячи, то точно сотни оценок проектов и тем не менее, никогда нельзя быть уверенным что конкретная новая оценка будет точной. На практике попадание +/- 25% — это неплохо.

Какие основные факторы влияют на точность оценки:

1. Опыт архитектора и ПМа, которые готовят оценку. Очень важен опыт реализации похожих проектов в такой же или близкой функциональной области.
2. Зрелость, стабильность бизнес-процессов заказчика. Полнота перечня процессов. Очевидно, внедрение новых TOBE-процессов сложнее внедрения существующих ASIS-процессов.
3. Функциональный объем, в т.ч. количество и сложность интеграций с внешними системами, использование шин данных, требования к отчетам, дополнительные формы и т.д.
4. Состояние НСИ. Один из важнейших факторов!
5. Миграция или старт новой системы с нуля.
6. Состояние и степень документированности текущих систем заказчика.
7. Количество пользователей и график работы.
8. Нагрузка на систему и количество критичных бизнес-процессов.
9. Правильная оценка компетенции планируемой команды как со стороны интегратора, так и со стороны заказчика. К сожалению, все люди разные, и реальная производительность конкретных двух аналитиков или разработчиков вполне может достаточно сильно отличаться.
10. Степень приоритетности проекта внутри заказчика, мотивация и вовлечённость ключевых членов команды.
11. Честность и открытость представителей заказчика на этапе подготовки оценки.
12. Допущения и ограничения проекта, которые закладываются в момент подготовки оценки и обязательно доводятся до заказчика.
13. Готовность заказчика соблюдать утверждённый приоритет проекта и утвержденные регламенты взаимодействия.
14. Готовность придерживаться регламента управления изменениями в части функционального объема.

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

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

1. Управление закупками (закупка у поставщика)
2. Управление закупками (импорт)
3. Управление закупками (товары в пути, неотфактурованная поставка)
4. Управление продажами (оптовые)
5. Управление продажами (экспорт)
6. Учет безналичных платежей
7. Учет наличных платежей
8. Кредиты и займы, депозитные счета
9. Казначейство
10. Учет основных средств
11. Учет нематериальных активов
12. Учет лизинговых операций и арендных платежей
13. Учет ТМЦ на складе
14. Учет ТМЦ в эксплуатации
15. Учет ответ. хранения
16. Учет производства (без заказов на производство и планирования)
17. Учет давальческого производства
18. Учет затрат (26, 44)
19. Учет затрат (20, 23, 25, 29 и правила расчета с/с)
20. Расчеты с подотчетными лицами
21. Учет НДС
22. Учет налогов (кроме налогов по ЗП, НДС)
23. Учет взаиморасчетов с контрагентами (поставщики, покупатели, прочие контрагенты)
24. РБП
25. ДБП
26. Ремонты
27. Интеграция с ФГИС Зерно
28. Интеграция с WMS
29. Интеграция с Альта-Софт (ДТ)
30. Интеграция с ОМС (управление заказами покупателей)
31. Обмен данных — отгрузки основному покупателю (файлы xml)
32. Интеграция с ЗУП
33. Перенос НСИ из УПП

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

В ходе подготовки проекта определяется состав проектной команды как со стороны интегратора, так и со стороны заказчика. В нашем примере, исходя из объема, было определено, что достаточно команды в составе: руководитель проекта, 3 аналитика, архитектор (функциональный координатор), и 2-3 разработчика (2 обычных и ведущий на разных этапах). Естественно, загрузка членов команды может меняться на различных этапах (хотя аналитики будут загружены на 100% практически на всём протяжении проекта). Часы менеджера QA не учитываются в бюджете. Определение и стоимость команды заказчика обсудим ниже.

Дальше начинается детальное определение трудозатрат уже в разрезе процессов и этапов, которое выполняется проектным архитектором с соответствующим опытом, с участием ПМа, руководителя проектного департамента и менеджера по продажам. Да, снова скажу, это некая магия и колдовство, но в конечном счёте всё основано на опыте, понимании процессов заказчика, функционала 1C:ERP и текущей системы. Вот что у нас получилось:

Этап проекта	Работы	Длительность работ	Трудозатраты, ч/часов
Анализ и моделирование	Подготовка к интервью и проведение интервью	2 недели	180
	Подготовка протоколов интервью	2 недели	162
	Подготовка к моделированию и проведение моделирования (настройка процессов заказчика на типовой системе)	3 недели	242
	Подготовка и согласование протоколов моделирования	4 недели	415
	Подготовка реестра выходных форм, формирования перечня модификаций, оценка и приоритизация, согласование объема	1 неделя	80
	Управление проектом (ПМ, частично ведущий разработчик на оценках)	10 недель	460
	Итого по этапу (общая длительность меньше суммы, т.к. есть наложение)	10 недель	1 539
Построение	Написание функциональных дизайнов (ФД, технические задания для разработчика) по согласованному списку модификаций	2 недели	160
	Разработка модификаций по ФД, правил миграции, тестирование модификаций, интеграций с внешними системами	7 недель	690
	Подготовка к ИТ (интеграционному тестированию) — подготовка и настройка системы, проведение интеграционного тестирования, включая интеграции с внешними системами	8 недель (в т.ч. непосредственно ИТ – 2 недели)	365
	Управление проектом (ПМ, ведущий разработчик, архитектор)	8 недель	800
	Итого по этапу (общая длительность меньше суммы, т.к. есть наложение)	8 недель	2015
Внедрение	Подготовка системы для обучения, подготовка графика обучения, проведение обучения, подготовка ведомостей по обучению, актирование обучения	3 недели	289
	Настройка системы (настройка параметров системы и прав пользователей, интеграций с внешними системами, рабочих мест)	2 недели	118
	Подготовка НСИ (подготовка шаблонов для заполнения начальных данных, загрузка заполненных шаблонов в систему – в случае загрузки из шаблонов, в случае автоматической загрузки – подготовка скриптов загрузки и их запуск.	2 недели	160
	Управление проектом (ПМ, ведущий разработчик, архитектор)	5 недель	320
	Старт системы	Контрольная точка
	Итого по этапу (общая длительность меньше суммы, т.к. есть наложение)	5 недель	887
Активная поддержка	Поддержка процессов в новой системе, исправление обнаруженных ошибок, закрытие периода (один месяц)	8 недель	1 000
	Управление проектом (ПМ, ведущий разработчик, архитектор)	5 недель	400
	Итого по этапу	5 недель	1 400
	ИТОГО ПО ПРОЕКТУ	28 недель (старт на 24 неделе)	5 841

Важные замечания к приведённой таблице:

1. Я не привожу расшифровку в разрезе процессов, но в оценке, которую мы показываем заказчику, присутствует детальная расшифровка по этапам «Анализ и моделирование», «Построение», «Внедрение» для каждого процесса. Это довольно большая «портянка», которая не даст лучшего понимания в рамках данной статьи, а только загромоздит текст. Очевидно, невозможно оценить этап «Активная поддержка» в разрезе процессов.
2. Второй момент, который крайне сложно оценить до завершения этапа «Анализ и моделирование» — трудоёмкость реализации модификаций. Здесь может быть два подхода – попытаться дать какую-то оценку исходя из требований, озвученных в ходе подготовки к проекту, или ограничить плановый объем модификаций какой-то величиной трудозатрат. Далее, в ходе управления проектом – приоритезировать доработки в соответствии с задачами и приоритетом проекта, всё что не попадает – будет отнесено на последующий после завершения проекта этап жизненного цикла системы (этап «развитие и сопровождения системы»). В рассматриваемом примере мы пошли по первому этапу, проанализировали требования, функциональность текущей системы и постарались сделать оценку.
3. В нашем примере, поскольку проект относительно небольшой, отсутствуют такие задачи как проведение «теста одного дня» (сквозное тестирование всех процессов непосредственно на рабочих местах в течение одного дня), нагрузочного тестирования (т.к. риски по производительности оценены как незначительные).
4. Для сокращения бюджета проекта было принято решение не писать детальные пользовательские инструкции, а записать скринкасты обучения пользователей. Далее собственными силами сотрудников заказчика могут быть написаны детальные пользовательские инструкции. Соответственно написание инструкций здесь отсутствует.
5. Четверть трудоёмкости  занимает этап «активная поддержка», в ходе которого осуществляется «всего лишь» поддержка и закрытие одного периода. В рассматриваемом примере таково было требование заказчика по команде. Из нашего опыта, достаточно сопровождения в течение одного месяца, а также возможно существенное сокращение трудозатрат за счёт привлечения команды заказчика.

Что мы имеем в итоге? Достаточно типичный проект внедрения 1С:ERP (миграция с 1С:УПП), не слишком сложный, но и не слишком простой. От старта работ до запуска системы – около 6 месяцев. Можно ли сделать быстрее или медленнее – в принципе да, указанный график является комфортным для интегратора, при желании, можно было бы сократить сроки на 4-6 недель, слегка увеличив команду (с соответствующим увеличением ресурса заказчика, что мы обсудим далее).

При текущей ставке 4 000 руб./час не включая НДС, стоимость  услуг добавит в копилку бюджета проекта 23,3 млн. руб. Столько и стоит небольшой проект внедрения 1С:ERP сегодня. Указанная ставка — средняя ставка для хороших интеграторов с опытом, со статусом «1С:Центр ERP» на момент публикации этой статьи (к таким я, безусловно, отношу и нашу компанию ФТО).

Может ли эта цифра поменяться? В общем, да. Всё зависит от того, какие договоренности между интегратором и заказчиком были на старте проекта. Если мы должны зафиксировать бюджет проекта в целом, сразу и на весь проект, в любом случае будут закладываться какие-то резервы в бюджете (потому что в таком проекте крайне сложно управлять изменениями объёма, без прямых финансовых потерь со стороны интегратора). Если можно договориться о фиксации функционального объёма и о переоценке бюджета проекта после завершения этапа «Анализ и моделирование» — риски для интегратора снижаются, и в целом это гораздо более честный подход по отношению к друг другу. Наиболее безопасная схема работы для интегратора – работа по схеме t&m, но тут все риски по бюджету ложатся на заказчика, т.е. ответственность за бюджет целиком переносится на заказчика.

В нашей практике мы предпочитаем работать по варианту с переоценкой бюджета проекта после завершения этапа «Анализ и моделирование». После такой переоценки точность планирования бюджета составляет более 90%.

Оценка стоимости команды заказчика

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

Сотрудников заказчика должно быть выделено такое количество (вернее, количество их времени), которое достаточно для выполнения их функций в рамках проекта. Если есть регламент согласования, который был принят при подготовке проекта,  в рамках которого были обязательства по согласованию протоколов в течение суток, то бизнес-эксперт обязан выделять необходимое время. В противном случае «поедет» весь план проекта. Всегда нужно помнить, что проект внедрения – совместная деятельность, и вообще нет команды заказчика, команды интегратора – есть одна совместная команда проекта. Поэтому задача координатора (ПМ со стороны заказчика, называем его так просто ради удобства, чтобы не было двух руководителей проекта), выстроить команду со своей стороны таким образом, чтобы она была в состоянии регулярно выделять необходимое время на проектные задачи. Зачастую для этого требуется мощный административный ресурс уровня ГД или ГД-1 и временное перераспределение обязанностей сотрудников внутри подразделений.

В нашем примере представляется, что команда со стороны заказчика будет состоять как минимум из координатора проекта, бизнес-экспертов (допустим, продажи, закупки, логистика, казначейство, бух.учёт – будет несколько экспертов, интеграции с внешними системами  — кто-то из ИТ), координатора от ИТ, ключевых пользователей по функциональным областям (которые помогают на обучении, тестировании, поддержке). Грубо прикинем плановую загрузку и команду со стороны заказчика в ч/месяцах и зарплату указанных людей:

Позиция	Количество	Зарплата с налогами, руб./мес.	Загрузка, ч/мес.	Премия, мес.	Итого затрат
ПМ	1	182 000	7	1	1 456 000
Бизнес-эксперт	6	156 000	3	2	4 680 000
Ключевой пользователь	6	105 000	1,5	2	2 205 000
Координатор ИТ	1	130 000	1	0,5	195 000
ИТОГО					8 536 000

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

Важный момент, который хотелось бы отметить – мотивация сотрудников заказчика, премия. Редко когда заказчику возможно целиком и полностью освободить сотрудников от текущих обязанностей, а значит, проектная загрузка может приводить к переработкам и выгоранию. Важный и правильный инструмент материальной мотивации сотрудников – премия по успеху проекта. Сумма премии должна быть значимой – хотя бы 1-2 зарплаты, мы всегда рекомендуем заказчикам закладывать это в бюджет проекта. Такая мотивация действительно помогает, в чём я неоднократно убеждался собственными глазами. Всё же часто людям приходится очень нелегко на сложных проектах, когда нагрузка на них особенно высока — в моменты интеграционного тестирования, запуска системы и активной поддержки.

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

Накладные расходы

Самая простая часть для оценки бюджета проекта – план по накладным расходам. Это стоимость командировок команды проекта (если они будут). В случае такого небольшого проекта, как в рассматриваемом примере, с уверенностью могу утверждать, что старт и запуск может быть выполнен полностью удалённо, поскольку у нас в ФТО уже неоднократно был опыт удаленного внедрения в сопоставимых проектах. Таким образом, бюджет накладных расходов в нашем примере будет равен нулю.

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

Стоимость лицензий на ПО 1С

Базовая модель лицензирования 1С довольно проста, в отличие от многих других продуктов. Лицензироваться должны следующие компоненты:

1. конкурентные (одновременно работающие) пользователи
2. сервер приложений
3. сам продукт (в нашем случае 1С:ERP)

В случае необходимости использования какого-то отраслевого решения (вроде «1С:ERP Управление мясоперерабатывающим предприятием» и т.п.) базовая модель конечно несколько усложняется, но мы рассмотрим более простой случай. Так же за скобками оставляем пакеты ИТС в силу незначительного влияния на общий бюджет проекта.

Приведённый вариант – не единственный. Существует возможность использовать 1С в облаке по модели SaaS, как минимум два варианта от самой фирмы 1С:

• 1С:Fresh (правда, 1C:ERP здесь предполагается использовать только типовую, с модификациями стандартной функциональности есть существенные ограничения, доступен только функционал так называемых «расширений»)
• 1С:Готовое рабочее место

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

Есть также аренда лицензий 1С, но это лучше изучить самостоятельно по ссылке. По моей оценке, существенной экономии вы не получите. Подходит вам это или нет – решайте сами.

Как всегда, есть некоторые нюансы, а именно:

1. Наличие удаленных филиалов (про это можно почитать здесь)
2. Необходимость использования лицензий уровня КОРП. Это на самом деле вопрос непростой и связан с планируемой нагрузкой на систему, основное  ограничение, которое снимает уровень КОРП – количество пользователей (500) и ядер, доступных для сервера приложений.
3. Необходимость использования USB-ключей защиты (а не программных лицензий) для некоторых заказчиков (например, из-за каких-то  ограничений, связанных с информационной безопасностью). Многие позиции с USB-ключами стоят дороже, да и сами USB-ключи уже морально устарели.
4. Сокращение стоимости за счёт апгрейда существующих лицензий (если компания к примеру переходит с 1С:УПП).
5. Выбор между электронной и неэлектронной поставкой (стоимость одинаковая, но во втором случае вы получаете ещё прекрасные коробки и книжки про 1С).

Обо всём этом партнёры 1С в курсе, и помогут учесть такие моменты при подготовке спецификации на лицензии 1С. В случае ООО «Ромашка» будем считать, что филиалов у нас нет, КОРП лицензии не нужны, работает одновременно до 100 пользователей, и конечно, будут использоваться программные ключи (что делает сейчас подавляющее большинство заказчиков), а апгрейд мы делать не будем. Тогда первая – минимальная – спецификация будет выглядеть так:

Артикул	Наименование	Количество	Цена, руб. (Лицензии НДС не облагаются)
2900001871365	1С:Предприятие 8. ERP Управление предприятием 2. Электронная поставка *	1	432 000
2900001833585	1С:Предприятие 8.3 ПРОФ. Лицензия на сервер (x86-64). Электронная поставка *	1	95 100
2900001847209	1С:Предприятие 8 ПРОФ. Клиентская лицензия на 100 рабочих мест. Электронная поставка *	1	396 000
			923 100

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

Хороший партнёр, имеющий опыт внедрения 1С:ERP, должен конечно предупредить, что вполне вероятно потребуется ещё и 1С:Документооборот (даже если сама функциональность документооборота не заявлялась, очень часто движок 1С:ДО используется в проектах 1С:ERP, например в цепочках согласования чего-либо). Также хороший партнёр знает, что иногда можно прилично сэкономить за счёт приобретения так называемого «бандла», тогда вторая, уточнённая спецификация для ООО «Ромашка» будет выглядеть так:

Артикул	Наименование	Количество	Цена, руб. (Лицензии НДС не облагаются)
2900001871372	1С:Предприятие 8 ПРОФ. ERP Управление предприятием 2 + Документооборот КОРП. Сервер (x86-64). 50 клиентских лицензий. Электронная поставка *	1	768 000
2900001833554	1С:Предприятие 8 ПРОФ. Клиентская лицензия на 50 рабочих мест. Электронная поставка *	1	206 000
			974 000

Сумма стала больше, но это на самом деле выгоднее, т.к. приобретается ещё и 1С:Документооборот КОРП, который отдельно стоит 220 700 руб. Таким образом лицензии 1С добавили в копилку бюджета проекта для ООО «Ромашка» около 1 млн.руб.

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

Важный момент, который хотелось бы отметить дополнительно: за рамками осталось любое другое ПО, но это уже выходит за рамки статьи. Ведь 1С не умеет работать на голом железе! А потому законопослушная организация ООО «Ромашка» также лицензирует операционные системы (Microsoft Windows Server, который не очень понятно, как ныне приобрести, если конечно не используется Linux), базы данных (Microsoft SQL Server с аналогичной проблемой приобретения, или бесплатная СУБД PostgreSQL), гипервизоры виртуализации (например, Vmware vSphere), лицензии Windows CAL, ПО резервного копирования, терминальные лицензии и т.д. и т.п.

Стоимость инфраструктуры

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

Требования к оборудованию определяются исходя из сайзинга. Сайзинг – это процесс детального планирования аппаратной части информационной системы под конкретные бизнес-процессы и конкретный профиль нагрузки. Это непростая процедура, особенно в случае сложных профилей нагрузок, высокого документооборота, большого количества одновременно работающих пользователей. В сложных случаях для проведения сайзинга требуется выполнение отдельного проекта, с привлечением высококвалифицированных специалистов с сертификатами «1С:Эксперт по технологическим вопросам» и с использованием специальных программных инструментов (ЦУП, входит в 1С:КИП – требуется отдельная лицензия), особенно когда речь идёт о высоконагруженных системах. В простых случаях, как с ООО «Ромашка» со 100 пользователями и относительно небольшим документооборотом – сайзинг выполняется интегратором в рамках проекта, на этапе проектирования системы.

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

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

В случае аренды, стоимость оборудования почти не влияет на бюджет проекта (т.к. проект – инвестиционные затраты компании; хотя и можно отнести в бюджет проекта стоимость аренды на период реализации проекта). Дальнейшие затраты на аренду оборудования будут относиться к операционной деятельности компании в ходе промышленной эксплуатации системы (таким образом стоимость аренды влияет на операционный результат компании). Вариантов на рынке сегодня масса – крупнейшие сервисы российский Яндекс.Облако, Селектел или иные другие – тысячи их. Смело мог бы рекомендовать лидеров – Amazon Web Services, Microsoft Azure, но к сожалению эти компании ушли с российского рынка. Стоимость смотрите сами, разброс достаточно большой, рынок конкурентный и развитый.

В нашем примере, в простом случае с ООО «Ромашка», потребуется 2-3 сервера (сервер приложений, сервер СУБД, возможно терминальный сервер). Считаем, что старое оборудование придется полностью поменять и останавливаемся на варианте собственной инфраструктуры. Я весьма далёк от рынка серверов, но примерная стоимость подходящего сервера составит от $5 тыс., то есть оборудование добавит в копилку бюджета ещё около 1 млн.руб. Эта цифра может поменяться как в меньшую сторону (например, за счёт отсутствия необходимости в терминальном сервере; или использование БУ-оборудования), так и в большую (к примеру, в случае необходимости отдельного дискового хранилища).

Важный момент, который хотелось бы отметить дополнительно: за рамками остались рабочие места конечных пользователей (персональные компьютеры), принтеры, затраты на построение корпоративной сети, организацию каналов связи. Если что-то необходимо для проекта – добавляем в копилку бюджета.