Раз в пару месяцев ко мне приходят с одинаковым вопросом: пришла смета на внедрение ERP, посмотрите, это нормальная цена. Отвечаю я обычно не про цену. Сначала выясняется, какие именно процессы в компании не сходятся, и примерно в половине разговоров становится понятно, что ERP-система тут закроет процентов двадцать боли, а остальные восемьдесят живут за её границами — у клиентов, на складе, в отраслевых расчётах и в отчётности.
Я Дмитрий Васильев, основатель Code Pilots. Внедрение ERP мы не продаём: мы делаем модули, кабинеты и обмен поверх учётного ядра и приходим туда, где внедрение уже прошло или где вместо него нужно что-то другое. Поэтому разговор ниже — без интереса продать вам лицензии. Разберу развилку, которую обсуждают меньше всего: внедрять систему целиком или достроить то, что уже работает.

Коротко: учётная система отвечает на вопрос «что было», ERP — на вопрос «что будет и хватит ли ресурсов».
Путаница начинается с того, что почти у всех уже стоит что-то из линейки 1С, и слова «внедрение ERP» звучат как «обновим то, что есть». Разница принципиальная. Бухгалтерская конфигурация ведёт регламентированный учёт и не управляет оперативной работой. Управление торговлей закрывает продажи, закупки и склад, но планирования в ней почти нет. ERP добавляет сверху финансы и бюджетирование, производство, потребность в материалах и сквозную консолидацию.
Простой тест, который я предлагаю на первой встрече. Задайте вопрос: где сейчас заказ номер 4172 и хватит ли материалов, чтобы отгрузить его двадцатого числа. Если отвечает система — у вас уже есть то, что называют ERP, как бы это ни называлось в договоре. Если отвечает человек, который сводит три выгрузки в Excel, вопрос открыт.
Дальше начинается интересное. Человек сводит три выгрузки вовсе не потому, что компании не хватает класса системы. Гораздо чаще — потому, что три системы не обмениваются данными или обмениваются раз в сутки.
Я задаю их в таком порядке.
Первый: у вас производство или торговля? Расчёт потребности в материалах, спецификации, маршруты, себестоимость по переделам — это ядро ERP, и заменить его обвязкой не выйдет. Если компания продаёт и возит, набор задач другой, и закрывается он, как правило, оперативным учётом плюс нормальными интеграциями.
Второй: сколько у вас юрлиц и как собирается консолидированная отчётность? Одна компания, один склад, один расчётный счёт — ERP избыточна. Группа компаний с внутренними оборотами и управленческой отчётностью по МСФО — это уже разговор по существу.
Третий: где именно теряются деньги? Обычно ответ звучит так: заказ клиента идёт три дня, потому что его руками переносят между отделами; кладовщик ищет товар по памяти; менеджер готовит коммерческое предложение полдня; клиент звонит узнать статус, потому что больше негде. Ни одна из этих четырёх бед не лечится сменой учётного ядра.

Претензии к вендорам тут нет: так устроен сам класс систем. ERP хорошо закрывает внутренние процессы обученных сотрудников. Всё, что происходит на границе с внешним миром, она закрывает плохо, и эти зоны повторяются почти на каждом проекте.
Внешние пользователи. Клиент, дилер и поставщик хотят видеть свои цены, остатки, статус заказа и отгрузочные документы. Пускать их внутрь учётного контура нельзя: лицензии, права доступа и интерфейс, рассчитанный на человека, которого обучали неделю. Кабинет строится снаружи и синхронизируется с ядром.
Люди в поле и на складе. Водитель, монтажник и кладовщик работают с телефона или терминала сбора данных, часто без устойчивой связи. Нужны офлайн-режим, фотофиксация, синхронизация при появлении сети. Веб-интерфейс учётной системы в этот сценарий не встаёт.
Отраслевые расчёты. Ровно то, чем компания отличается от соседа, в типовой поставке отсутствует по определению. У поставщика корпоративных подарков TooMany Gifts цена зависела от объёма, брендирования, срочности нанесения и статуса клиента, и вся эта политика жила в головах менеджеров и в таблицах. Мы собрали конструктор коммерческих предложений, который применяет правила сам: документ выходит за пять минут вместо трёх часов, операционные затраты на подготовку упали на 60%, а средний чек вырос за счёт автоматических допродаж. Никакая смена учётного ядра этого бы не дала — правила ценообразования там просто негде хранить.
Отчётность под нагрузкой. Тяжёлые аналитические запросы к боевой базе замедляют работу пользователей, а в дни закрытия периода конкурируют с ней за ресурсы. Данные выносят в отдельную витрину и строят дашборды уже по ней.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13755 тендеров
проведено за восемь лет работы нашего сайта.
Здесь принимается самый дорогой выбор проекта, и обсуждают его обычно бегло — в тот момент, когда все заняты описанием процессов.
Требование, которого нет в типовой поставке, закрывают четырьмя способами. Настройкой — права, дополнительные реквизиты, шаблоны, правила ценообразования. Расширением конфигурации — отдельным слоем поверх типовой, со своими формами и логикой. Правкой самой конфигурации, после которой она снимается с поддержки. И отдельной системой рядом, которая общается с ядром через обмен.
Первые два способа стареют нормально. Третий — это технический долг с ежегодным платежом: каждое обновление платформы и каждый релиз с изменениями законодательства проходит через разработчика руками, с разбором конфликтов. Компании с большим объёмом таких правок рано или поздно перестают обновляться вовсе, а регламентированная отчётность меняется каждый год.
Разница между третьим и четвёртым вариантом в смете выглядит скромно. Через два года она превращается в разрыв. Поэтому правило у нас простое: ядро оставляем типовым, новое строим снаружи и связываем обменом. Как этот выбор выглядит со всеми подробностями — способы доработки, механизмы обмена, миграция справочников, — мы расписали в отдельном материале про ERP-системы.
Смета интегратора — это не стоимость владения. К ней добавляется как минимум пять вещей, и они всплывают уже после подписания.
Первое — доработки. Инвентаризация обычно показывает, что реально используется меньше половины купленной функциональности, а часть того, ради чего систему брали, всё равно требует программиста.
Второе — обмен с тем, что остаётся. Сайт, приложение, кабинет клиента, складская система, маркетплейсы никуда не деваются, и каждый обмен нужно написать и сопровождать.
Третье — миграция справочников. Номенклатура с тремя кодами на одну позицию и контрагенты-дубли переезжают в новую систему вместе со всем остальным, только теперь их видят все. Это отдельная дисциплина и отдельные месяцы работы.
Четвёртое — люди. Проект без выделенного владельца со стороны бизнеса стоит дороже и идёт дольше, потому что решения по процессам никто не принимает.
Пятое — год после запуска. Первые месяцы система работает хуже прежней: люди привыкают, отчёты донастраиваются, ошибки вылезают на реальных данных.
Своих сумм я здесь не называю намеренно — они зависят от отрасли и масштаба сильнее, чем от класса системы. Но структуру расходов стоит разложить до того, как сравнивать предложения, иначе сравниваются несравнимые вещи.
Чтобы не выглядело, будто я отговариваю. Есть ситуации, в которых обвязка не спасает и класс системы менять придётся.
Производство с планированием, где нужно считать потребность в материалах, загрузку и себестоимость. Группа компаний с консолидацией и внутренними оборотами. Уход с зарубежной системы, у которой закончилась поддержка. Учётное ядро, которое уже не держит объём данных и падает на закрытии периода.
Общее у этих случаев одно: проблема лежит внутри учёта, а не на его границе. Если же болит граница — клиенты, склад, полевые сотрудники, отчётность, — внедрение стоит дороже и помогает слабее.
Порядок, который мы предлагаем клиентам, выглядит скучно и экономит месяцы.
Сначала — карта процессов и мест, где данные переносят руками. Дальше по каждому месту считаем частоту, стоимость ошибки и число людей в цепочке. Потом смотрим, что из найденного закрывается настройкой существующей системы, что — сервисом рядом, и только оставшееся складываем в аргументы за смену ядра.
У интернет-магазина электронных компонентов «Радиоэлемент» вся боль была в загрузке прайсов от десятков поставщиков: у каждого свой формат, файлы лежат на FTP или приходят почтой, а конкурирующие решения обрабатывали такие объёмы часами. Мы сделали парсеры, которые справляются за 30–120 секунд, и конструктор, в котором клиент подключает нового поставщика сам, без разработчиков. Каталог на полмиллиона позиций работает поверх прежнего учётного контура. Разговор о смене ядра там не возникал ни разу.
Этот разбор мы обычно делаем как проект по автоматизации процессов: смотрим, где именно теряется время, и раскладываем найденное по способам решения. Если выясняется, что дело в обмене между системами, дальше работает интеграционный слой, а ядро остаётся на месте.
Что такое ERP-система простыми словами? Единая база и сквозные процессы предприятия: от заказа клиента до отгрузки, себестоимости и денег на счёте. Ключевое отличие от учётной системы — планирование вперёд: потребность в материалах, закупки, загрузка производства.
Чем ERP отличается от 1С? Сравнение некорректное: 1С — это платформа и линейка продуктов, внутри которой есть и простая бухгалтерия, и полноценная ERP. Сравнивать стоит состав процессов, которые система закрывает; названия продуктов об этом не говорят ничего.
Сколько длится внедрение ERP? От нескольких месяцев до пары лет. Срок задают две вещи: описаны ли процессы до старта и в каком состоянии справочники. Размер компании тут почти ни при чём. Запуск всех контуров одновременно — самый надёжный способ растянуть проект.
Можно ли обойтись без ERP? Многим компаниям — да. Если проблема в том, что данные переносят руками между системами, дешевле настроить обмен и достроить недостающее рядом. Класс системы стоит менять, когда не сходится само ядро: планирование, производство, консолидация.
Что дешевле: внедрить ERP или дописать существующую систему? На горизонте трёх лет считайте стоимость владения целиком: доработки, обмен с остальными системами, миграцию справочников и год привыкания. Смета внедрения — только её часть. Доработка выигрывает, когда болит граница учёта; внедрение — когда не сходится сам учёт.