Восстановление ERP-проекта в FMCG: единая отчётность в SAP Analytics Cloud

Этот кейс для CFO и ИТ-руководителей, у которых больше одной ERP и которые не могут получить единый набор цифр. Коротко: застопорившийся трансграничный проект отчётности между Oracle в Сингапуре и SAP в Великобритании удалось вернуть в строй за шесть месяцев. Это сделали пять вещей. Меньший управляющий комитет с реальными полномочиями. Объём, урезанный до отчётов, которые влияют на решения. Согласованные определения в обеих системах. SAP Analytics Cloud как единый слой отчётности. И локальные чемпионы вместо обучения в классе. Если вы в похожем положении, начинайте с управления и определений, а не со споров об инструменте.

История начинается с застопорившегося проекта ERP-аналитики в известной FMCG-группе со штаб-квартирой в Сингапуре. Группа владела 26 % британского бизнеса энергетических напитков. Несмотря на миноритарную долю, управленческий контроль находился в Сингапуре, поэтому стратегия, которую задавали в Азии на уровне совета директоров, определяла ежедневную отчётность и планирование в Европе.

Технологии всё усложняли. Сингапур работал на Oracle ERP. Великобритания на SAP ERP. Каждая система работала сама по себе, а вместе они создавали проблему отчётности, которая уже съела месяцы усилий.

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

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

До восстановленияПри перезапуске

УправлениеДо восстановленияБольшой управляющий комитет, решения откладываютсяПри перезапускеТолько настоящие лица, принимающие решения, решают прямо на встрече

ОбъёмДо восстановленияДоска, исписанная запросамиПри перезапускеОтчёты, которые влияют на решения

ОпределенияДо восстановленияОдно название, разный смысл в каждой ERPПри перезапускеСогласованные выручка, затраты и маржа

ОтчётностьДо восстановленияСверка в Excel, занимавшая дниПри перезапускеДанные Oracle и SAP в одной модели SAP Analytics Cloud

ВнедрениеДо восстановленияОбучение в классе, затем возврат к ExcelПри перезапускеЛокальные чемпионы, команда за командой

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

Проблема	Последствия	Решение с SAP Analytics Cloud
Две ERP: Oracle в Сингапуре, SAP в Великобритании	Цифры не сходились; сверка занимала дни	Обе подавали данные в одну модель отчётности
Неясное владение отчётностью между странами	Стратегия из Азии сталкивалась с операционными данными в Европе	Единые KPI означали, что оба юридических лица отчитывались по одним и тем же метрикам
Медленная отчётность по выручке	Цифры различались по системе-источнику, что задерживало решения	Единое планирование и отчётность сократили цикл
Рассогласованность планирования	Сингапур задавал стратегию; Великобритания исполняла её на других допущениях	Общие модели планирования выровняли оба бизнеса

Отчётность через две ERP

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

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

Консолидация на конец месяца

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

Операционная отчётность

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

Спор об инструменте

Выбор инструмента отчётности превратился в отдельный проект. Одним менеджерам нравилась стоимость Power BI; другие настаивали на SAP из-за более долгой дорожной карты. Я просидел воркшоп, где половина времени ушла на вопрос «почему SAC, а не Power BI» вместо разговора о потребностях в отчётности. Спор длился месяцы и высасывал темп.

Сопротивление пользователей

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

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

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

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

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

В таблице кратко описано, что изменилось и почему это сработало.

Направление	Что изменилось	Эффект
Перезапуск управления	Управляющий комитет сокращён до реальных лиц, принимающих решения; заседания короче и жёстче	Решения принимались на встрече; эскалации шли быстро
Контроль объёма	Требования урезаны до отчётности, влияющей на решения	Меньше споров, яснее модели данных, меньше движущихся мишеней
Адресная коммуникация	Отдельные сообщения для финансов, операционного блока и ИТ	Каждая команда понимала, что важно именно ей; доверие вернулось
Локальные чемпионы	Коучинг от коллег в малых группах вместо формальных классов	Внедрение улучшалось команда за командой; зависимость от Excel снижалась

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

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

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

Один технический момент, если вы планируете повторить эту схему. Live-подключения к данным в SAC ограничены источниками SAP, такими как SAP HANA, BW, S/4HANA, BPC embedded, универсумы BusinessObjects и SAP Datasphere. Данные не из SAP, например из Oracle ERP, обычно поступают через импортное подключение, универсум или промежуточный слой данных. Определите эту архитектуру рано, потому что от неё зависит, насколько свежими могут быть цифры каждой стороны.

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

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

Перезапуск завершился в течение шести месяцев. Впервые данные Oracle и SAP оказались в одной модели внутри SAC. Споры о сверке пошли на убыль, а руководители просматривали цифры, не дожидаясь, пока разойдутся файлы Excel.

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

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

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

Ошибка	К чему привела	Урок
Нечёткое управление	Бесконечные встречи, отсутствие решений, нарастающие задержки	Рано пересмотрите роли и права принятия решений
Расползание объёма	Цели отчётности постоянно смещались	Держите объём узким и привязанным к решениям
Игнорирование пользователей	Пользователи теряли уверенность, внедрение замедлялось	Рано вовлекайте пользователей и давайте им контекст
Чрезмерная кастомизация	Время тратилось на пересборку отчётов	Начинайте с шаблонов и стандартных коннекторов; кастомизируйте позже
Слабое управление изменениями	Обучение не попало в цель; старые привычки остались	Рано подключайте локальных чемпионов и коучинг от коллег

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

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

Между SAC и источниками встал бы слой данных. SAP Datasphere, теперь часть SAP Business Data Cloud, даёт федеративный доступ к источникам SAP и не-SAP с семантической моделью сверху. В случае двух ERP, как здесь, гармонизировать данные Oracle и SAP в этом слое чище, чем внутри каждой истории SAC. Кроме того, SAC получает live-подключение к гармонизированной модели.

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

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

Перезапуск управления, дисциплина объёма, локальные чемпионы и адресная коммуникация остались бы прежними. Эти закономерности работают при любой технологии. Человеческая работа по тому, чтобы две ERP отчитывались одними и теми же цифрами, не автоматизируется. Подробнее о самом SAC см. в моём руководстве по SAP Analytics Cloud.

Почему застопорился проект ERP-отчётности этой FMCG-группы?

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

Что изменило курс восстановления?

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

Как SAP Analytics Cloud справился и с Oracle, и с SAP?

SAC свёл данные Oracle и SAP в одну модель отчётности, поэтому обе системы появились рядом на одном дашборде без ручных файлов сверки. Момент, когда обе системы оказались в одном представлении, закончил спор об инструменте. Учтите, что live-подключения SAC поддерживают только источники SAP; данные Oracle обычно поступают через импортное подключение, универсум BusinessObjects или слой данных вроде SAP Datasphere.

Почему пользователи сначала сопротивлялись дашбордам?

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

Как выглядит успешное восстановление ERP-отчётности?

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