Выбор ERP: Готовый пакет или индивидуальная система? 12 вопросов перед принятием решения

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

Сначала процессы, потом программное обеспечение

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

• Карта процессов: Сквозные потоки от запроса до счета-фактуры, от найма до расчета заработной платы и полномочия на утверждение на каждом этапе.
• Инвентаризация данных: Какие данные хранятся и где (бухгалтерская программа, Excel, электронная почта), какие из них должны быть «единственным источником достоверной информации».
• Список интеграций: Банки, провайдеры электронных счетов, бухгалтерское ПО, каналы электронной коммерции и сервисы SMS/email.

Сильные и слабые стороны готового пакета

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

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

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

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

12 вопросов перед принятием решения

1. Какая доля наших процессов является отраслевым стандартом, а какая уникальна для нас?
2. Работаем ли мы с несколькими компаниями, филиалами или валютами?
3. Являются ли наши цепочки утверждения ролевыми или основанными на конкретных лицах?
4. Кто будет владельцем данных; можем ли мы получить базу данных по окончании контракта?
5. Кто будет обновлять законодательную отчетность (электронные счета-фактуры, электронные бухгалтерские книги, законодательство по зарплате)?
6. Обязательна ли интеграция с существующей бухгалтерской программой или она заменит ее?
7. Будут ли полевые команды (строительная площадка, склад, сервис) получать доступ к системе с мобильных устройств?
8. Применяется ли авторизация на уровне базы данных или только на уровне пользовательского интерфейса?
9. Ведется ли журнал аудита (кто, когда и что изменил)?
10. Кто несет ответственность за резервное копирование и восстановление?
11. Каковы будут затраты на лицензирование и обслуживание через три года?
12. Документирована ли система на случай смены команды разработчиков?

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

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

Гибридный подход: объединение лучших сторон обоих вариантов

На практике наиболее распространенным сценарием является гибридная структура. Например: официальный бухучет остается в существующей программе учета, операционные процессы (запросы на закупку, ТМЦ, табели учета рабочего времени, акты выполненных работ, наряды) управляются в индивидуально разработанной системе, а между двумя системами настраивается плановый перенос данных. Такой подход позволяет переложить нагрузку по регламентированной отчетности на специализированное ПО, не ограничивая моделирование уникальных процессов компании.

Подход Cy Logic

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

Три частые ошибки

1. Принятие решения по демоверсии

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

2. Оставление интеграции напоследок

Подход «давайте сначала установим ERP, а банк и электронные счета подключим позже» приводит к многомесячному периоду двойного ввода данных после запуска. Список интеграций и технические требования для каждой интеграции (доступ к API, тестовая среда, контракт) должны быть уточнены на этапе выбора.

3. Оставление пользователя напоследок

Теми, кто будет ежедневно пользоваться ERP, являются кладовщик, специалист по закупкам и прораб, а не руководство. Неучастие этих людей в процессе выбора приводит к результату: «система есть, но мы продолжаем работать в Excel».

Пример оценочной рамки

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

КритерийВопросГотовый пакетИндивидуальная система Соответствие процессамМоделируются ли наши процессы без изменений?ЧастичноДа Законодательная отчетностьКто выполняет обновления законодательства?ПроизводительИнтегрированная программа учета Владение даннымиМожем ли мы получить базу данных?Зависит от контрактаДа Скорость стартаКогда используется первый модуль?БыстроПоэтапно Долгосрочные затратыЧто мы платим через три года?Лицензия + адаптацияОбслуживание + разработка

План перехода: в какой последовательности?

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

Примечания в контексте Кипра и Турции

Обязательства по электронной счет-фактуре, электронному архиву и электронным книгам в Турции делают практически обязательным сохранение бухгалтерской стороны в программном обеспечении, совместимом с Налоговым управлением (GİB); это выдвигает на первый план гибридную модель. Для предприятий, работающих на Северном Кипре, часто возникает потребность в работе с разными валютами и консолидации с группой компаний в Турции; многокомпанийная и многовалютная структура индивидуальной системы здесь может быть решающей. В обоих случаях подтвердите юридические и финансовые требования со своим финансовым консультантом; решение по программному обеспечению строится поверх этих требований.

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