Идеальная архитектура 1С:ERP при отказе от SAP и Oracle

Дмитрий Лившин, генеральный директор «Сайбер Бизнес Консалтинг»

Переход с SAP, Oracle, Axapta или старой «1С:УПП» на «1С:ERP» или «1С:ERP.УХ» обходится крупному предприятию в сотни миллионов, а иногда и в миллиарды рублей и занимает от одного до трех лет. На старте такого проекта команда заказчика выбирает подрядчика, спорит о функциональных требованиях, согласовывает бюджет и обсуждает сроки каждого из этапов. При этом одно из самых дорогих решений в проекте, а именно – какую модель финансового контура закладывать в архитектуру, сквозную или распределенную – нередко принимается по умолчанию: сделаем «как было раньше», «как у соседей по отрасли» или как предложил интегратор. Цена инерции такого подхода выясняется только примерно через год после начала эксплуатации, и тогда менять что-то уже поздно, а жить с неосмотрительно принятым решением придется все последующие десять-пятнадцать лет жизненного цикла системы.

Что нужно финансовому блоку – и почему это вопрос архитектуры

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

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

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

Сквозная или распределенная: где проходит граница

Сквозная модель устроена относительно просто: единая точка ввода данных для всех видов учета, единое управление НСИ и единый поток данных между блоками, а также прямая связь производственных показателей с учетом затрат. Чтобы такая архитектура работала, нужны зрелые и стандартизированные процессы, высокий уровень дисциплины пользователей в подразделениях и готовность CFO принять, что часть его НСИ ведут сотрудники, которые ему прямо не подчиняются. Часто недооценивают и то, что целевая модель процессов (To-Be) должна быть «отрисована» до начала работ. Без нее сквозная архитектура становится способом перенести в новую систему все противоречия старой, только с еще большими издержками.

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

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

Кастомизация и обновления

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

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

Основываясь на нашей практике, я рекомендую использовать следующее правило. Блоки с высокой частотой регуляторных изменений лучше вынести в отдельную базу даже в случае использования условно сквозной парадигмы. Самый очевидный кандидат на это – ЗУП. Прогрессивная шкала НДФЛ, изменения, касающиеся страховых взносов, ежегодные новации в кадровом и пенсионном законодательстве требуют постоянного обновления конфигурации. Держать ЗУП в едином ядре с производственным контуром – значит каждый раз обновлять всю систему ради одного блока, рискуя при этом остановкой производственных процессов. Вынесенная отдельно база для ЗУП может сэкономить десятки человеко-часов при каждом обновлении и снять большую часть связанных с ними риска.

Что чаще всего упускают компании: методологическая готовность

Главная ошибка крупных проектов по внедрению «1С:ERP» обычно заключается в отношении к ним как к «чистым» ИТ-проектам. Внедрение такой ERP-системы меняет операционную модель компании, так что решения, принимаемые по ее архитектуре, примерно на шестьдесят процентов являются методологическими и лишь на сорок – техническими. ИТ-директор, который пытается совершить этот выбор силами только своей команды без участия CFO и операционного директора, получает архитектуру, которая соответствует его представлениям о деятельности компании, а не реальным бизнес-процессам.

Чек-лист для ЛПР до старта проекта: два важных инструмента

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

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

Сравнение моделей по ключевым критериям

Семь вопросов, на которые необходимо ответить до старта проекта

1. Какова целевая операционная модель компании на горизонте трех–пяти лет – стандартизация процессов или сохранение распределенности с автономией подразделений?
2. Готовы ли пользователи в функциональных подразделениях отвечать за свои блоки в системе и принимать последствия своих действий?
3. Есть ли у CFO жесткое требование к автономии финансового блока в части ведения и контроля НСИ?
4. Сколько внешних систем потребуют интеграции с ERP и какой объем постоянной нагрузки на сопровождение интеграций это создаст в штатных единицах (FTE)?
5. Какая часть текущих процессов кастомизирована в действующих системах и насколько критична эта кастомизация для бизнеса?
6. Есть ли в компании внутренние компетенции для самостоятельной поддержки и развития системы или весь жизненный цикл будет отдан подрядчику?
7. Планирует ли компания переходить в режим налогового мониторинга сейчас или на горизонте двух–трех ближайших лет?

Как выбрать архитектуру «1С:ERP», чтобы не пришлось потом переделывать

Универсального ответа на вопрос, какая архитектура лучше, в природе не существует, и поиск его на чужом опыте обычно приводит к тому, что вы копируете чужую архитектуру для своей компании. Архитектура финансового контура – это всегда компромисс между скоростью получения данных, автономией функциональных подразделений и совокупной стоимостью владения (TCO) системой. При этом набор приемлемых компромиссов у каждой компании сугубо индивидуален, и решение о них должно приниматься до старта проекта, когда стоимость изменений минимальна, а спор или торг между ИТ и финансовым блоком измеряется часами согласований, а не месяцами переделок после сдачи и кратного удорожания всего проекта. Я убежден, что те «долгие часы», которые CFO и ИТ-директор потратят на обсуждение на этапе подготовки технического задания, окажутся самой рентабельной инвестицией за весь срок внедрения новой ERP-системы.