Power BI отчети за ръководството на преработвател на плодове с ERP по поръчка

Клиентът е сред водещите преработватели на плодове в Европа. Проектът засягаше дейността му в България, която е сезонна и е насочена основно към износ. Там компанията работи с ERP система, разработена по поръчка от местен екип. Оперативните данни бяха налице, но системата даваше малко отчети и никакви графики, така че ръководството нямаше на какво да стъпи при управлението.

Готови отчети от доставчик нямаше. Липсваше и документация за базата данни на ERP системата, от която да тръгне изграждането на отчети.

Къде болеше

• Наличности без видимост. В сезонен бизнес количествата сурови и преработени плодове на склад решават всеки ход в продажбите и производството.
• Продажбите и производството оставаха скрити. Ръководството не виждаше резултатите достатъчно добре, за да направлява сезона.
• Финанси, сглобявани парче по парче. Финансовите числа се подготвяха ръчно, вместо да идват от основната система.
• Недокументирана база данни. Трудно е да правиш отчети, когато никой никога не е описал базата под тях.
• Борд без картина на пазара. Директорите нямаха ясна представа къде стои компанията на пазара.

Изпълнителният директор, ръководството и бордът вече работят с един модел. Той стъпва на живи данни от ERP системата и всеки вижда онова, което ролята му разрешава.

• Основни отчети, на които стъпват решенията на изпълнителния директор, използвани вътрешно в цялата организация.
• Ясна представа за пазарната позиция на компанията за ръководството и борда.
• Финанси, производство, продажби и наличности в общ модел, върху живи данни от ERP.
• Отчетност върху ERP без документация и без вградени отчети, от които да се тръгне.

По този проект не е измервано спестено време, нито използване. Посочените числа описват обхвата.

Къде се проваля отчетността върху ERP по поръчка

Отчетите върху недокументирана ERP по поръчка се чупят по-лесно от тези върху стандартна система. Имената на колоните може да значат друго, а не написаното. Анулираните записи може изобщо да не се трият. Схемата може да се промени със следващото обновление от разработчика на ERP. Отчет, който изглежда наред, но брои анулирани наличности или брои прехвърлянията двойно, бързо губи доверието на борда. Истинската работа е да проверим модела спрямо числа, на които бизнесът вече вярва, да опишем какво научихме за базата и да държим модела за отчетност отделно, така че обновление на ERP да развали едно съпоставяне, а не всички отчети.