Бізнес-аналітика

Що це таке

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

Термін старший за програмне забезпечення. У жовтні 1958 року IBM Journal of Research and Development надрукував статтю Ганса Петера Луна «A Business Intelligence System». Лун описав машинну систему, яка мала брати документи, що надходять до організації або створюються в ній самій, автоматично реферувати кожен, описувати його набором характерних слів і надсилати тим місцям в організації — Лун називав їх action points, — чий профіль інтересів підходить. Таким місцем могла бути одна людина, група, відділ чи цілий підрозділ. Слово business він навмисно тлумачив широко, як будь-яку організовану діяльність — від науки й торгівлі до права, державного управління й оборони, а intelligence розумів як здатність побачити, як пов’язані між собою наявні факти, настільки добре, щоб спрямувати дії до мети. Описавши всі методи, він назвав ціле: «We call this a Business Intelligence System.»

Матеріалом Луна був текст. Сучасна бізнес-аналітика здебільшого працює з числами в таблицях, і опис системи сховища даних та BI від Kimball Group показує звичну будову. У задній частині (back room) дані витягують із систем-джерел, очищують, узгоджують і завантажують. У передній частині (front room) їх подають упорядкованими за бізнес-процесами й збереженими на найдетальнішому рівні, а для швидкості додають агреговані підсумки. Згори розташовані BI-застосунки: довільні запити, стандартні звіти, дашборди й таблиці показників (scorecards), а також важчі застосунки для аналізу й видобування даних (data mining).

Обидва значення поєднує питання Луна: кому потрібно це знати і як воно дійде до них у формі, яку вони справді прочитають?

Чому це важливо

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

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

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

Як це виглядає на практиці

Типове питання для BI: виручка за третій квартал 2026 року в розрізі регіонів і товарів, з проміжним підсумком для кожного регіону й загальним підсумком. Якщо є таблиця sales з одним рядком на кожен продаж і стовпцями sold_on, region, product та amount, стандартний SQL відповідає на це одним запитом:

SELECT region,
       product,
       sum(amount)               AS revenue,
       GROUPING(region, product) AS level
FROM   sales
WHERE  sold_on >= DATE '2026-07-01'
AND    sold_on <  DATE '2026-10-01'
GROUP  BY ROLLUP (region, product)
ORDER  BY GROUPING(region), region, GROUPING(product), product;

На кількох рядках прикладу він повертає:

 region | product | revenue | level
--------+---------+---------+-------
 North  | Boots   |    1200 |     0
 North  | Jackets |     800 |     0
 North  |         |    2000 |     1
 South  | Boots   |     500 |     0
 South  | Jackets |    1500 |     0
 South  |         |    2000 |     1
        |         |    4000 |     3

ROLLUP (region, product) — це скорочення для GROUPING SETS ((region, product), (region), ()): увесь список, кожен коротший його префікс і, нарешті, порожній набір, який підсумовує всі рядки. Документація PostgreSQL називає цю конструкцію звичним засобом для ієрархічних даних, як-от зарплати за відділами, за підрозділами й по всій компанії. CUBE (region, product) натомість групував би за всіма підмножинами й тому додав би підсумок для кожного товару по всіх регіонах.

Стовпець, що не входить до набору групування рядка, повертається як NULL, тому в рядках проміжних підсумків є порожні клітинки. GROUPING(region, product) показує, які саме це стовпці. Функція повертає бітову маску з одним бітом на кожен аргумент, причому останній аргумент займає наймолодший біт, а біт дорівнює 1, коли стовпець для цього рядка не групувався. Отже, 0 позначає детальний рядок, 1 — підсумок регіону (товар не згруповано), а 3 — загальний підсумок (обидва стовпці не згруповано). Звіт читає level, щоб вирішити, які рядки виділити жирним.

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

Де виникають проблеми

Дві цифри під однією назвою. Виручка, активний клієнт і відтік клієнтів мають по кілька розумних визначень, і кожен звіт, що рахує сам, обирає одне з них. Запишіть кожен показник один раз — що він рахує, з якого джерела й станом на яку дату — і обчислюйте його в базі даних, наприклад як подання (view), а не у формулах кожного звіту. Kimball Group називає описову частину бізнес-метаданими: які дані є, звідки вони походять і що означають.

Усе для всіх. Дашборд із десятками діаграм і розсилка на весь відділ відтворюють ту саму повінь, яку хотів зупинити Лун. Почніть із конкретної людини й рішення, яке вона ухвалює, показуйте цифри, потрібні для цього рішення, і приберіть звіти, яких ніхто не відкривав цілий квартал.

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

Підсумки з підсумків. Середнє із середніх чеків кожного регіону не дорівнює середньому чеку компанії, якщо в регіонах різна кількість замовлень. Кількість унікальних клієнтів за місяць не можна скласти в квартальну, бо клієнта, який купував і в липні, і в серпні, буде враховано двічі. Зберігайте детальні рядки й агрегуйте кожен рівень із них. Набори групування роблять саме це: кожен рівень у запиті вище обчислюється з рядків продажів, а не з рівня під ним.

Порожня клітинка з двома значеннями. Додайте один продаж із невідомим регіоном, і запит вище поверне детальний рядок із порожнім регіоном, підсумок для нього з двома порожніми клітинками і загальний підсумок — теж із двома порожніми клітинками. З CUBE ще гірше: два рядки показують порожній регіон і Boots — один для Boots, проданих у невідомому регіоні, другий для Boots по всіх регіонах разом. Документація PostgreSQL попереджає, що NULL у даних неможливо відрізнити від NULL, який з’являється, коли стовпець згорнуто в підсумок. Шукайте рядки підсумків через GROUPING(), а не через IS NULL, і давайте відсутнім значенням видиму позначку на кшталт «невідомо» ще під час завантаження.

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

Що почитати далі

• A Business Intelligence System — стаття Ганса Петера Луна в IBM Journal of Research and Development за жовтень 1958 року, звідки походить термін.
• Kimball Technical DW/BI System Architecture — огляд Kimball Group: задня частина, презентаційна область, BI-застосунки й метадані.
• Table Expressions — довідка PostgreSQL про GROUPING SETS, ROLLUP і CUBE та про те, як NULL заміняє незгрупований стовпець.
• Aggregate Functions — функція GROUPING і її бітова маска з розібраним прикладом.