Дашборди Power BI для торгових компаній

Торговій компанії достатньо кількох дашбордів, побудованих на узгоджених визначеннях KPI та чистих даних з ERP: продажі й маржа, запаси, дебіторська заборгованість і відвантаження. Power BI, Tableau і Looker Studio впораються з кожним із них, тож вибір інструмента диктують ваші джерела даних, ваші користувачі та ваша модель управління, а не перелік функцій.

Які дашборди потрібні торговій компанії?

Торгові компанії мають невеликий набір управлінських питань, які повторюються щотижня, і кожне з них — це дашборд, а не звіт:

• Продажі та маржа. Що продано, кому й з якою маржею — за товаром, клієнтом, ринком і місяцем. Саме маржинальний зріз змінює поведінку: торговельна компанія може одночасно зростити виручку і зменшити прибуток за один квартал, і лише розріз за маржею це показує.


• Запаси. Що є на складі, де саме, як довго там лежить і що перестало рухатися. Для дистриб'юторів це дашборд грошового потоку: дні запасів і товар, що повільно обертається, заморожують обіговий капітал, потрібний для наступного замовлення.


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


• Відвантаження. Що вийшло вчасно, що запізнюється і що застрягло на етапі документів чи митниці. Для експортерів це ще й дашборд якості сервісу, бо затримку, яку відчуває клієнт, спричиняє подія у відвантаженні, а не в інвойсі.


• Відкриті замовлення. Що вже зафіксовано, що в очікуванні і що заблоковано — операційна картина, яка визначає плани на цей тиждень з виробництва, закупівель і контейнерів.

Визначення KPI та джерела даних

Таблиця — робоче ядро проєкту: кожен KPI потребує одного визначення, одного власника й одного джерела, а колонка з типовими проблемами — це місце, де народжується більшість суперечок про дашборди:

Таблиця A: KPI | визначення | джерело даних | типова проблема

Дві дисципліни тримають цю таблицю живою. Визначення пишуть простою діловою мовою, а не формулами — формула належить моделі даних, речення — словнику, і саме з цим реченням сперечається комерційна команда. І кожне визначення має дату й власника: визначення дрейфують разом зі змінами в бізнесі, а дашборд на торішньому визначенні не застарілий чесно, а тихо неправильний. Ширше питання про те, чи належить цей шар новій системі, чи наявному ERP, розглядається на сторінці про власне проти готового ERP, а сторінка про BI та аналітику даних охоплює ширшу дисципліну.

Джерела даних та інтеграція

Правда торгової компанії розкидана по п'яти системах, і завдання BI-шару — зібрати їх докупи, нічого не вигадуючи:

• ERP. Інвойси, замовлення, запаси, платежі, майстерні дані. Основне джерело й зазвичай єдине з транзакційною цілісністю.


• Електронні таблиці. Плани, бюджети, ручні коригування та тіньові числа, що живуть у файлі однієї людини. Ставтеся до них серйозно — бюджет, який існує лише в таблиці, усе одно залишається справжнім бюджетом, — але заводьте їх як дані з власником, а не як вкладення з листа.


• Електронна комерція та маркетплейси. Замовлення й трафік для компаній, що продають онлайн; дані каналів рідко збігаються з ERP один в один, тож правила зіставлення (що вважати продажем і коли) стають частиною словника.


• Логістика. Відправлення, номери відстеження, статус перевізника — джерело для KPI «вчасно» та дашборда відвантажень, яке найчастіше потребує ручних ключів або фідів від партнерів.


• Банк. Надходження й платежі, зіставлені з відкритими позиціями — міст між дашбордом дебіторської заборгованості та реальністю грошового потоку.

Основи моделі даних

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

• Факти й виміри. Факти — це події: рядки інвойсів, відправлення, платежі — з кількостями й вартостями. Виміри — це контекст: товар, клієнт, ринок, дата, склад — з атрибутами, за якими фільтрують і групують. Кожен KPI з таблиці вище — це агрегація фактів, нарізана вимірами, тому одна модель обслуговує п'ять дашбордів.


• Зіркова схема — свідомо. Тримати факти в центрі, а виміри навколо них, без хитрих скорочень «багато-до-багатьох», — це те, що зберігає адитивність мір: продажі, підсумовані за регіоном, дорівнюють продажам, підсумованим за місяцем, і дорівнюють загальним продажам. Моделі, що оминають цю структуру, працюють у демо й ламаються в третьому звіті.


• Одна версія правди. Однаковий код товару, код клієнта й валюта в кожній таблиці фактів, узяті з одних майстерних даних. Дубльовані виміри, що розходяться, — це те, з чого два дашборди починають показувати два різні підсумки за один місяць, і суперечка, що за цим іде, коштує дорожче, ніж будь-коли економила модель.

Порівняння Power BI, Tableau та Looker Studio

Усі три дають змогу побудувати згадані дашборди; різниця — у відповідності. Порівняння свідомо якісне — умови ліцензування й набір функцій на цьому ринку змінюються часто, тож перевіряйте актуальну інформацію від постачальника перед рішенням і ставтеся до будь-якої цифри, старшої за поточний цикл випуску, як до підказки, а не факту:

Таблиця B: критерій | Power BI | Tableau | Looker Studio

Чесний спосіб вирішити — це ваші власні обмеження в першій колонці, а не продукти в рядках: де живуть дані (середовище, зосереджене на Microsoft, схиляє до Power BI просто за підключенням та ідентичністю), хто щоденні користувачі й хто керуватиме моделлю за два роки. Процедура закупівлі, яка оцінює ці рядки проти ваших письмових вимог — метод описано на сторінці з контрольним списком для тендеру з постачальниками, — дає обґрунтовану відповідь; демо з порівнянням трьох головних сторінок — ні.

Контроль доступу та управління

Дашборди торгової компанії показують маржу, імена клієнтів і платіжну поведінку, тож доступ — це комерційне питання, а вже потім технічне:

• Безпека на рівні рядків. Регіональний менеджер бачить свій регіон, торговий представник — своїх клієнтів, рада директорів — усе; це реалізовано в моделі даних, а не в окремих копіях дашборда. Окремі копії — це шлях, яким повертається «два числа за один місяць».


• Ролі, а не окремі звіти. Доступ іде за посадовими ролями, надається один раз і переглядається періодично; припинення доступу працівника, що звільняється, разом із закінченням його зайнятості — це управлінська рутина, а не проєкт.


• Чутливі поля. Колонки з маржею й собівартістю заслуговують на явні рішення — хто їх узагалі бачить і чи існує дашборд без них для ширшого розповсюдження.


• Захист даних. Персональні дані клієнтів у дашборді підпадають під ті самі обов'язки, які компанія вже несе: KVKK для турецьких операцій і GDPR для даних європейських клієнтів, з охопленням правової підстави, строків зберігання вибірок і журналів доступу. Обов'язки ті самі, що й для систем, з яких надходять дані; дашборд не є звільненням лише тому, що він тільки читає. Ширший контрактний контекст, зокрема розміщення та доступ постачальника, розглянуто на сторінці про IT-аутсорсинг.


• Оновлення та контроль змін. Дашборд, чиє визначення змінюється, має змінюватися помітно — примітка про версію, дата, власник, — бо тихе перевизначення KPI — це те, через що два відділи перестають довіряти числам одне одного.

Кроки впровадження

Послідовність, яка працює, у такому порядку:

1. Спершу визначення метрик. Словник KPI, підписаний керівниками комерційного, фінансового та логістичного напрямів. Одна-дві сторінки; увесь ризик провалу проєкту сидить у тому, чи був цей крок зроблений як слід.


2. Одне джерело даних, один пілотний дашборд. Зазвичай це інвойси ERP і дашборд продажів та маржі — питання, яке менеджмент ставить найчастіше, і дані, які зазвичай найчистіші. Пілот одночасно доводить конвеєр, модель і визначення.


3. Тест користувачами на реальних питаннях. Дайте пілот трьом реальним користувачам на два тижні з їхніми фактичними щотижневими питаннями й дивіться, на що вони не можуть відповісти. Перелік прогалин із цих двох тижнів — це беклог, який має значення; запити на функції, які він породжує, зазвичай менші за страх перед ними.


4. Спершу виправити, потім розширювати. Проблеми якості даних, знайдені в пілоті, виправляються у джерелі, а не в дашборді — розрахункове виправлення у звіті ховає брудний ERP, який отруїть кожен наступний дашборд.


5. Розгортати за дашбордами, а не за кількістю користувачів. Випускайте п'ять узгоджених дашбордів послідовно, кожен зі своїм власником і датою визначення, а не відкривайте інструмент усім одразу — друга половина проблеми впровадження полягає в тому, на що люди дивляться, і п'ять дашбордів із власниками кращі за порожнє полотно.


6. Експлуатувати його. Моніторинг оновлень, призначений власник на кожен дашборд і щоквартальний перегляд визначень. BI-проєкт, що завершується на впровадженні, за рік стає звітним хобі; саме операційна рутина робить його управлінською інфраструктурою.

Часті запитання

Чи потрібне нам сховище даних?

Спочатку — ні. Пряме підключення до ERP плюс кілька таблиць вимірів покриває перші п'ять дашбордів для більшості торгових компаній; сховище виправдовує себе, коли джерельні системи множаться, історію треба зберігати довше за строк зберігання в ERP або продуктивність страждає. Чесний тригер — повторюваність: коли ті самі обхідні шляхи для вибірок відбудовують знову й знову, це і є розмова про сховище, а питання «писати чи налаштовувати», яке вона породжує, розглянуто на сторінці про власне проти готового ERP.

Як часто мають оновлюватися дані?

Узгоджуйте частоту оновлення з циклом ухвалення рішень, для кожного джерела окремо: продажі й відкриті замовлення виправдовують щоденне або майже щоденне оновлення; запаси й дебіторська заборгованість зазвичай щоденне; маркетплейси й банківські фіди — так часто, як вони надійно оновлюються. Частіше, ніж дані насправді змінюються, купує витрати без інформації, а збої оновлення мають бути видимі користувачам, а не тихі — дашборд, що показує вчорашні дані як сьогоднішні, гірший за той, який чесно каже, що запізнюється.

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

Так, як законне джерело — багато перших дашбордів працюють на рутині вивантаження за розкладом, а бюджети часто живуть лише в таблицях. Дисципліна в тому, щоб ставитися до вивантажень як до фідів даних із власником, розкладом і форматом, який перевіряють; режим відмови — файл, який надходить нерегулярно й тихо зникає, забираючи з собою KPI.

Хто визначає KPI?

Бізнес-власники цих чисел: комерційні керівники — для продажів і маржі, операційний напрям — для запасів і відвантажень, фінанси — для дебіторської заборгованості. BI-команда перекладає узгоджені речення в міри; коли BI-команда визначає KPI сама, дашборди вимірюють те, про що ніхто не просив — технічно правильно, організаційно не використано.

Чи безкоштовний Power BI?

Умови ліцензування на цьому ринку змінюються часто, тож перед бюджетуванням перевіряйте актуальну інформацію Microsoft, а не покладайтеся на цифри, які можуть бути старші за поточний цикл випуску. Незмінною лишається форма рішення: підписки на користувача з ролями, шар моделювання, який потребує управління, і витрати, зазвичай скромні поряд із рішеннями, які покращують дашборди — але вирішуйте на основі поточних умов, і письмово.

Як убезпечити дані клієнтів?

Безпека на рівні рядків у моделі, щоб люди бачили те, що дозволяє їхня роль; явні рішення щодо полів маржі й собівартості; доступ, наданий за роллю й періодично переглянутий; а також обов'язки KVKK/GDPR, застосовані до шару дашбордів — правова підстава, строки зберігання вибірок, журнали доступу — точно так, як для джерельних систем. Питання розміщення й доступу постачальника — ті самі, що розглянуто на сторінці про IT-аутсорсинг, і вони мають бути в контракті до запуску.

Джерела та стандарти

• Набір KPI, зіставлення джерел даних, концепції моделювання (факти, виміри, зіркова схема, одна версія правди), теми управління (безпека на рівні рядків, видимість оновлень, контроль змін) і послідовність розгортання відповідають загальній практиці бізнес-аналітики для торгових і логістичних компаній; жодної статистики використання, даних про впровадження чи виміряних результатів на цій сторінці немає.
• Порівняння трьох інструментів свідомо якісне й вільне від цін на ліцензії, обмежень і заяв про функції, що змінюються між циклами випуску; кожен рядок про ліцензування закликає читача перевірити актуальну інформацію від постачальника, і жодного партнерства з Microsoft, Tableau чи Google не заявлено.
• Твердження про процеси відповідають сторінкам цього сайту: BI та аналітика даних, власне проти готового ERP (де місце шару даних) і IT-аутсорсинг із Туреччини (обов'язки KVKK і GDPR, доступ постачальника, контрактні питання).
• Обов'язки щодо захисту даних названо, а не витлумачено: KVKK для турецьких операцій і GDPR для даних європейських клієнтів застосовуються відповідно до ситуації компанії; підтвердьте застосовний режим у кваліфікованого радника.

Пов'язані сторінки

BI та аналітика даних · Власне проти готового ERP · Розробка програмного забезпечення · Контрольний список для тендеру з постачальниками · ШІ-автоматизація · Запросити пропозицію