Как крупные компании выбирают ERP: мой опыт на стороне заказчика и участника тендеров

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

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

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

1. Сначала появляется проект и обоснование инвестиций

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

Внедрение ERP проходит через эту же систему принятия решений.

Когда компания приходит к мысли, что ей нужна новая ERP, внутри появляется проект. У него должны быть обоснование, документы и ответственные люди.

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

В моей практике одним из основных документов был project charter — устав проекта. Это знакомый инструмент формального проектного управления, в том числе подходов, связанных с PMBOK — сводом знаний по управлению проектами.

В уставе фиксируется примерно следующая мысль:

«Мы как компания рассматриваем возможность внедрить новую ERP для поддержки следующих бизнес-процессов. Мы ожидаем такие результаты, рассматриваем такие временные и бюджетные рамки и предъявляем к информационной системе такие принципиальные требования».

Здесь важно правильно понимать роль документа. Это не формальность, которую подготовили и положили в папку. В нём зафиксировано реальное намерение бизнеса:

• почему компания хочет заменить существующую систему;
• какие процессы должна охватить новая ERP;
• каким принципиальным функционалом она должна обладать;
• кто будет ею пользоваться;
• какие результаты ожидаются;
• какие бюджетные средства и сроки компания готова рассматривать.

При этом конкретный ERP-продукт на данном этапе может вообще не называться. Сначала компания разрешает провести выбор решения. Решение о том, какой продукт приобретать и с кем его внедрять, будет принято позже.

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

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

2. Требования бизнеса превращаются в матрицу выбора

Следующий этап — подготовка торгов.

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

Результатом становится матрица критериев выбора. В ней компания описывает, что должна уметь ERP, чтобы её вообще можно было рассматривать.

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

• поддержка нескольких юридических лиц;
• возможность получения консолидированной отчётности по группе;
• штатные процессы бюджетирования;
• согласование заявок на оплату;
• мобильное приложение для торговых представителей;
• API для интеграции с другими системами;
• управление продажами и выставление счетов клиентам;
• закупки;
• складской учёт;
• учёт товарных запасов и анализ их оборачиваемости;
• бухгалтерский и финансовый учёт.

Поясню несколько моментов для тех, кто раньше не участвовал в таком выборе.

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

API — это программный интерфейс, через который системы могут обмениваться данными. Само наличие API ещё не означает, что нужная интеграция уже готова. Но для компании это может быть принципиальным условием: ERP должна иметь возможность взаимодействовать с другими решениями.

Оборачиваемость запасов помогает понять, как быстро товар продаётся и сколько средств остаётся связано в складских остатках.

Список требований получается большим. Я не вижу в этом проблемы. Чем подробнее компания сформулирует свои критерии на этом этапе, тем понятнее будет последующее сравнение. Главное, чтобы за каждым критерием стояла реальная потребность бизнеса.

Например, фраза «система поддерживает несколько компаний» оставляет множество вопросов. Можно ли вести отдельный учёт по каждому юридическому лицу? Видеть группу целиком? Отражать операции между связанными компаниями? Работать с разными валютами?

С согласованиями та же история. Наличие кнопки «Согласовать» ещё мало о чём говорит. Нужно понимать, кто согласует документ, в какой компании, при каких условиях и что происходит, если основной согласующий отсутствует.

Как может выглядеть фрагмент матрицы

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

Такая таблица помогает отделить ответ поставщика от подтверждённой возможности.

За словами «да, мы это поддерживаем» могут стоять совершенно разные варианты: функция работает штатно, её нужно настроить, требуется дополнительный модуль или поставщик считает, что сможет её разработать.

Для проекта это разные стоимость, сроки и риски. Я хочу, чтобы матрица делала эти различия видимыми.

Итак, у нас уже есть устав проекта и критерии выбора. Теперь можно переходить к поиску потенциальных исполнителей.

3. В моей практике поиск начинался с вендоров

В крупных проектах, о которых я рассказываю, заказчик обычно начинал поиск через самих вендоров — разработчиков и поставщиков ERP-продуктов.

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

«Мы рассматриваем внедрение ERP. Вот наши критерии выбора, условия отбора и предполагаемые сроки. Просим порекомендовать партнёров, которые способны реализовать такой проект».

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

У такого подхода есть практические причины.

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

Кроме того, участие вендора помогает в коммерческом обсуждении. Если предложение партнёра становится неконкурентным из-за цены, вендор может повлиять на переговоры или предложить другой вариант реализации.

В этой схеме вендор — заинтересованная сторона, которая знает свою партнёрскую сеть и хочет, чтобы её продукт был выбран.

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

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

4. Сбор предложений — отдельная большая работа

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

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

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

Оставшиеся кандидаты переходят к обсуждению решения и способа его внедрения.

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

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

На этом этапе мы одновременно рассматриваем две составляющие будущего проекта: саму ERP и людей, которые предлагают её внедрять.

5. Функциональность нужно демонстрировать на конкретных задачах

Первый вопрос достаточно прямой: соответствует ли система набору критериев, который сформулировала компания?

Покажите, как у вас работают продажи. Как устроены закупки? Как ведётся склад? Как представлены остальные модули, без которых наш бизнес не готов рассматривать решение?

Особенно внимательно я отношусь к демонстрации отчётности. Для меня это одна из самых показательных и чувствительных частей оценки.

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

Если в системе есть стандартные отчёты — покажите их. Затем покажите детализацию.

Можно ли перейти от итоговой суммы к документам, которые её сформировали? Посмотреть выручку и затраты по подразделениям? Сравнить результаты разных компаний группы? Изменить период и аналитический разрез?

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

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

Чем больше полезных возможностей анализа ERP действительно показывает, тем интереснее она становится для бизнеса.

Отдельно обсуждается расширение системы. Можно ли устанавливать дополнительные модули? Сколько они стоят? Как долго будет разрабатываться специфическая функция, необходимая компании?

Например, нужно подключить внутреннюю бухгалтерскую систему — ту же 1С. Что для этого потребуется? Какие данные будут передаваться? Какая часть интеграции уже существует, а какую придётся разрабатывать?

Чем конкретнее ответы, тем точнее мы можем определить, подходит ли нам предлагаемое решение.

Я бы обязательно фиксировал, что уже продемонстрировано, а что пока остаётся обещанием. И то и другое может присутствовать в предложении, но проектный комитет должен видеть разницу.

6. Мы выбираем ERP вместе с командой внедрения

Команда — один из ключевых факторов принятия решения.

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

Но на практике реализация проекта очень сильно зависит от людей.

Поэтому я хочу знать: какая у вас команда? Кто персонально будет работать с нами? Какая экспертиза есть у этих специалистов?

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

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

Хорошая коммерческая презентация полезна. Но проект будут выполнять конкретные специалисты: анализировать процессы, принимать архитектурные решения, настраивать систему и разбираться с проблемами.

Например, мы обсуждаем оценку запасов или операции между юридическими лицами группы. Понимают ли консультанты бизнес-логику? Какие вопросы задают? Могут ли объяснить последствия предлагаемого подхода?

Такие разговоры многое показывают ещё до начала работ.

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

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

7. Цена рассматривается вместе с качеством и риском

В крупных проектах, в которых я участвовал, цена редко была единственным определяющим фактором.

Бизнес понимал, что стоимость нужно рассматривать вместе с качеством решения, профессионализмом команды и риском внедрения.

Более дорогое предложение не становится автоматически лучшим. Но и меньшая сумма в коммерческом предложении сама по себе не делает инвестицию выгоднее.

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

Крупный бизнес способен оценивать эту разницу. Он смотрит на последствия неудачного внедрения и на то, что получает за свои деньги.

Поэтому я бы сравнивал цену одновременно с обязательствами поставщика. Какие требования включены? Что считается допущением? Какие работы будут оцениваться позже? Какой объём дополнительных задач уже виден?

Предложения проще сопоставлять, когда стоимость и содержание проекта рассматриваются вместе.

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

8. Руководитель проекта защищает короткий список вариантов

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

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

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

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

Но масштаб вариантов уже становится понятен.

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

Компания выбирает ещё и модель реализации:

Для сложных компаний, о которых я говорю, последний вариант встречается реже. Обычно определённые настройки, интеграции или доработки всё-таки необходимы.

Мне важно, чтобы сравнение объясняло последствия выбора. Что компания сможет использовать первым? Что останется за границами первоначального запуска? Сколько работы нужно выполнить до перехода сотрудников в новую систему?

Тогда руководство принимает решение с пониманием того, какой проект ему предстоит поддерживать.

9. После предварительного отбора начинаются внутренние переговоры

Наличие короткого списка ещё не означает, что выбор завершён.

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

Выбор ERP бывает достаточно конфликтным. У подразделений разные интересы, а новая система может менять привычный порядок работы.

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

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

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

Запрос теперь звучит конкретнее:

«Покажите, как вы видите наш процесс в вашей системе. Как именно он будет работать?»

Здесь уже нужен сквозной сценарий — последовательность действий через несколько подразделений и функциональных областей.

10. Сквозное демо показывает, как ERP работает в структуре бизнеса

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

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

Мы хотим увидеть всю цепочку, а затем разобраться, как она отражается в учёте и отчётности.

Во время такого демо неизбежно появляются вопросы. Чего не хватает? Что требует настройки? Где нужна разработка? На каких этапах действуют согласования?

Затем тот же процесс нужно посмотреть с другой стороны.

Допустим, я работаю в юридическом лице А, связанном с юридическим лицом Б. Что вижу я? Что видят сотрудники другой компании? Как операции отражаются у каждой стороны? Как затем формируется общая картина по группе?

Это позволяет понять, как ERP будет вести себя в реальной организационной структуре.

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

Сравнение должно отражать актуальное знание о кандидатах. Иначе компания рискует принять решение по таблице, которая уже не соответствует результатам обсуждений.

11. Почему решение может занимать год

Подробные демонстрации требуют времени.

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

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

Сами торги, рассмотрение предложений и консультации могут занять несколько месяцев. Затем к ним добавляется цикл бюджетирования.

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

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

Особенно хочу обратить на это внимание консультантов со стороны IT. Для участия в крупных проектах полезно понимать, как заказчик принимает инвестиционные решения.

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

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

12. Как в такой выбор вписывается Odoo

Всё, о чём я рассказал, определяет и мой подход к оценке Odoo.

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

Я считаю, что заслуживает.

Odoo — полноценная ERP со своими особенностями, сильными сторонами и ограничениями. Рассматривать её нужно применительно к конкретному бизнесу, как и другие системы.

В зависимости от объёма проекта и модели реализации она может предложить более доступную стоимость по сравнению с некоторыми вариантами SAP или Oracle.

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

Для этого и пригодится подготовленная матрица.

13. Где я вижу сильные стороны Odoo

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

Если стандартная логика соответствует работе компании, объём доработок может быть относительно небольшим.

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

Для группы юридических лиц также важны финансовая отчётность и консолидация. Эти возможности я бы внимательно проверял применительно к структуре заказчика.

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

Так общий разговор о поддержке группы компаний превращается в оценку конкретного решения.

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

14. Где Odoo нужно оценивать особенно внимательно

Больше всего вопросов у меня вызывают сложное управление последовательностью бизнес-процессов, маршруты согласования и совместная работа над документами.

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

Рассмотрим договор.

Юрист вносит изменения. Другим участникам нужно увидеть и проверить правки. Затем документ проходит несколько этапов согласования — например, через финансы, операционное подразделение и руководство. После этого его нужно подписать, сохранить и дальше контролировать его состояние.

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

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

То же относится к маршрутизации документов между подразделениями и юридическими лицами. Одной компании достаточно простого согласования, другой нужна существенно более сложная логика.

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

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

Тогда компания понимает реальный состав проекта и может обоснованно решить, подходит ли ей такой вариант.

15. Практический подход: запустить основные процессы и развивать систему

Для компаний, которые в 2026 году ищут более доступную альтернативу дорогостоящим ERP-решениям, Odoo, на мой взгляд, представляет серьёзный интерес.

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

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

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

Как партнёры по внедрению мы можем помочь с такой проработкой.

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

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

В этих областях понимание бизнеса так же важно, как знание возможностей программы.

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

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

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

Для компании, которая хочет получить полноценную ERP и внимательно относится к стоимости проекта, Odoo определённо стоит рассмотреть.

Давайте обсудим выбор ERP для вашей компании

Если вы готовитесь выбирать ERP, приглашаю вас на бесплатную консультацию.

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

Я буду рад помочь вам разобраться в вариантах и подобрать подходящее сочетание ERP и команды внедрения.