Аналітичний CRM: як побудувати оптимальну модель?

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


У минулій статті "Аналітичний CRM: з чого починати?" говорилося про те, що модель ACRM повинна зберігати інформацію про клієнтів і побудованих сегментах, а сама інформація повинна бути агрегована на рівні клієнта – ключового елемента сховища. Тобто модель повинна бути клієнто-орієнтованої. Але що ж насправді представляє з себе клієнто-орієнтована модель ACRM, і які умови можуть забезпечити її оптимальність? Постараємося відповісти на ці питання в цій статті.


Рівні представлення даних


Оскільки ACRM є прикладним прикладом BI-систем, то в ній є всі 3 рівня представлення даних: фізичний рівень, рівень бізнес-логіки та презентаційний рівень.


Фізичний рівень відповідає за збір інформації з використовуваних джерел, її очищення, агрегацію і завантаження в сховище даних (Data Warehouse – DWH). Цей процес, як правило, виконується ETL-інструментами (Extract Transformation Load). Правильно побудована модель сховища даних дозволяє уникнути проблем зі швидкістю доступу до інформації, а також забезпечує можливість подальшого масштабування DWH, його кастомізації і підключення додаткових джерел даних.

Рівень бізнес-логіки будується безпосередньо в репозиторії BI-системи та перетворює дані з структур фізичного рівня в структури, призначені для вирішення конкретних бізнес-завдань. Тут відбувається обчислення вузькоспеціалізованих KPI's (Key Performance Indicator), будуються ієрархії, і для кожної бізнес-області зв'язуються в схеми (mappings) використовувані в ній таблиці фактів (facts) і вимірювань (dimensions).


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


Презентаційний рівень містить показники, переведені в поняття конкретної бізнес-області. На цьому рівні підготовлені і розраховані на рівні бізнес-логіки об'єкти проектуються у відповідні звіти та dashboards (панелі звітів, згрупованих за бізнес-завдань) кінцевих користувачів.

Схема рівнів представлення даних



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


Отже, в ACRM необхідно приділити увагу оптимальності, як мінімум, двох моделей: моделі сховища даних (МХД) і моделі бізнес-логіки (МБЛ). Розглянемо їх більш докладно.


Модель сховища даних


Як вже було зазначено, МХД впливає на швидкість вибірки інформації. Для того щоб визначити критерії оптимальності моделі сховища достатньо відповісти на запитання: "Яка інформація в ACRM найбільш часто цікавить бізнес-користувачів? ".


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


Інформація, зазначена в першому випадку, використовується для швидкого сегментування клієнтської бази з актуальних критеріями (наприклад, за статусом клієнта на поточний момент, за сумарним доходу за місяць, за поточної заборгованості і т.д.). Другий випадок дозволяє виявляти типові профілі поведінки клієнтів (наприклад, отримати типовий профіль боржника, профіль абонента, схильного до відходу і т.д.) Виходячи з цього, можна визначити рекомендації до моделі сховища ACRM.


Виходячи з цього, можна визначити рекомендації до моделі сховища ACRM:


1. Модель сховища повинна містити таблиці з показниками клієнтів і посиланнями на виміри, розрахованими на поточний момент часу (Поточні Профілі).


2. Модель сховища повинна містити таблиці, що зберігають історію зміни цих показників і посилань на вимірювання (Історичні Профілі).


3. На рівні сховища даних рекомендується проводити розрахунок тільки тих показників, алгоритм обчислення яких не зміниться надалі, або процес їх обчислення занадто ресурсоемок, щоб виконувати його на рівні бізнес-логіки.


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



Модель може зробити систему швидкої, гнучкою та функціональної, ..
 

 
а може, навпаки, перетворити її в неповороткий шматок програмного коду.

Багато розробники пропонують оптимізувати сховище ACRM шляхом використання стандартного секціонування за часом. Цей підхід може мати позитивний успіх у BI-системах, призначених для управлінської звітності, але навряд чи підійде для ACRM. Оскільки критеріїв сегментації дуже багато, то краще створити кілька таблиць-профілів, розділивши клієнтську базу на непересічні діапазони клієнтів, наприклад, по регіону або за методом взаєморозрахунків. Кожну таку таблицю-профіль можна додатково секціонованими за новими критеріями. Для поточних профілів краще використовувати секціонування по швидко змінюється критерієм: категорія надійності клієнта, рівень лояльності і т.д. А для історичних профілів, навпаки, по постійному критерієм: стать, регіон, дата укладення договору і т.д. Такий спосіб оптимізації дозволяє не тільки прискорити процес доступу до даних, а також забезпечує гнучкий спосіб настройки різних способів секціонування для окремих груп клієнтів та розмежування доступу до них на рівні БД. Створені на рівні сховища таблиці-профілі тепер необхідно об'єднати в моделі бізнес-логіки.


Модель бізнес-логіки


Вона створюється в репозиторії і є, мабуть, найскладнішим і найбільш "живим" об'єктом всієї системи. Бізнес не стоїть на місці: цілі, завдання і способи їх досягнення змінюються щодня. А значить, і сама МБЛ повинна швидко адаптуватися під вимоги бізнесу, підвищуючи в кінцевому підсумку його успішність. Іншими словами, модель повинна дозволяти оперативно створювати і змінювати показники, вимірювання та рівні ієрархії.


Щоб визначити рекомендації до МБЛ, необхідно відповісти на питання: "На що більше витрачає часу аналітик у процесі пошуку сегмента?". Майже завжди чути один і той же відповідь на це питання: "На все!", але на практиці виходить трохи інакше.


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


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


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


На рівні МБЛ рекомендується проводити розрахунок показників, алгоритм обчислення може змінитися. Такий підхід дозволяє уникнути проблем з показниками, які в різних випадках повинні розраховуватися по-різному, а також підвищити швидкість і зручність роботи кінцевого користувача, надаючи йому дійсно необхідний для вирішення набір елементів.


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

Ще одну важливу роль в оптимізації МБЛ грають рівні ієрархії вимірів, оскільки саме вони дозволяють кінцевому користувачеві виходити в звітах на більш детальний рівень (drill down) або, навпаки, "підніматися" до більш загального (drill up). Від того, скільки рівнів ієрархії містить вимір і наскільки грамотно вони були створені, буде в кінцевому підсумку залежатиме зручність і швидкість роботи з цим виміром. Тому ще одна важлива рекомендація для створення оптимальної моделі бізнес-логіки: будувати рівні ієрархії треба виходячи з угрупування даних по бізнес-глузду.


Ці рекомендації допоможуть зрозуміти, від чого слід відштовхуватися для того, щоб з самого початку закласти оптимальну модель даних, а значить, запобігти ще один важливий ризик проекту впровадження ACRM.

 

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*