Аналітичний CRM з чого починати Програмні продукти
Впровадження CRM-систем для великих компаній - давно пройдений етап на шляху налагодження ефективних взаємин із клієнтами та підвищення прибутковості. Найбільш успішні гравці ринку вже зрозуміли, що тільки взаємодії з клієнтом мало. Потрібно не лише підвищувати лояльність, вчасно вітаючи людину із сімейними святами, а й аналізувати інформацію про неї для подальшого ефективного розвитку бізнесу. І тут у гру вступає аналітичний CRM.
CRM-системи (Customer Relationship Management) – були створені для управління взаємовідносинами із клієнтами. Метою застосування цих систем зрештою є підвищення лояльності і, як наслідок, підвищення ефективності та прибутковості компанії. Однак якщо раніше, два-три роки тому, CRM розглядався в основному як класична операційна частина, то тепер це поняття набуло дедалі чіткішого поділу на дві складові: операційну та аналітичну. Багато компаній вже дійшли розуміння необхідності впровадження аналітичного CRM, але багато хто ще перебуває в процесі прийняття цього рішення.
Що таке CRM аналітичний?
Обидві системи – операційний CRM (OCRM) та аналітичний CRM (ACRM) – ставлять перед собою однакові цілі та відрізняються лише способами їх досягнення. Якщо OCRM вирішує завдання підвищення лояльності клієнта в процесі безпосереднього контакту з ним, то ACRM навпаки аналізує накопичену про нього інформацію і допомагає розробити стратегію подальшої взаємодії. Образно кажучи, якщо OCRM – це передова лінія фронту, то ACRM – це штаб, і успіх залежить від їх спільних злагоджених дій.
Але чим ACRM відрізняється від стандартних систем аналітичної звітності та Data Mining? Відповідь проста: він не відрізняється про них, він включає їх, але використовує відмінні від інших систем принципи подання та аналізу інформації. У ACRM ключовою є інформація про клієнта, у той час як в інших аналітичних системах це може бути зведена інформація по цілим групам клієнтів або бізнес-напрямків.
Бізнес-вимоги
Отже, рішення про впровадження ACRM ухвалено. Першим етапом, безумовно, є бізнес-вимоги. Важливо, щоб на момент початку впровадження бізнес-вимоги було сформульовано остаточно та в повному обсязі. Для того, щоб технічні можливості системи максимально перетнулися з очікуваннями, які замовник пред'являє до ACRM, важливо, щоб процес створення цих вимог проводився спільною командою замовника (представника бізнесу) та виконавця (бізнес-консультанта та експерта з системи). Багато менеджерів проектів схильні вважати, що процес їхнього вироблення - це виключно завдання замовника. Такий підхід може призвести одразу до двох негативних моментів. По-перше, недостатньо повного використання доступних можливостей системи. Перед впровадженням замовник часто не знайомий із системою, тому при створенні ТЗ деякі важливі та оптимальні для вирішення бізнес-завдань можливості можуть бути просто не враховані. По-друге, до нереалізованості очікувань замовника. При створенні бізнес-вимог замовник може керуватися уявленнями, отриманими від демонстрації інших систем. Якщо ці уявлення увійдуть у технічне завдання, але не будуть реалізовані, то вони можуть легко перетворитися на ложку дьогтю.
Окресливши коло завдань, можна приступати до їх детального опрацювання. Тепер у гру включається бізнес-консультант,завдання якого спільно із замовником виділити список необхідних ключових показників (KPI's - Key Performance Indicators) та вимірювань (Dimensions), у розрізі яких ці показники будуть вимірюватися. Кожна бізнес-завдання має бути декомпозірована у відповідний набір показників та вимірювань, на базі яких створюватимуться таблиці фактів (Facts). Це справді складний та важливий процес, оскільки від нього фактично залежить успіх усього проекту. Замовник має уявлення про те, що він хоче отримати, але часто він не знає, як це виміряти та подати у вигляді кінцевих показників. Тому важливо, щоб бізнес-консультант уже мав досвід впровадження ACRM у цій галузі та міг запропонувати попередній варіант реалізації бізнес-вимог, відштовхуючись від якого замовник зможе виділити набір необхідних для нього KPI та вимірювань.
Інтеграція із зовнішніми системами
АCRM може оперувати інформацією, взятою з різних зовнішніх джерел, кількість яких обмежена лише бізнес-вимогами: це можуть бути, наприклад, бухгалтерські, складські, білінгові, CRM та інші системи та бази даних, в яких міститься інформація про клієнтів, історія їхньої поведінки та спілкування із нею. З цих систем у Сховищі ACRM повинна надходити інформація, необхідна для розрахунку показників і побудови вимірювань, а з ACRM в OCRM - рекомендації щодо подальшого спілкування у вигляді отриманих сегментів з описами клієнтів, що ввійшли до них. На цьому етапі необхідно узгодити інтерфейси взаємодії ACRM із зовнішніми джерелами: перевірити наявність та доступність необхідної інформації та підготувати специфікації інтерфейсів з усіма інтегрованими системами та базами даних.
На практиці нерідко виникають ситуації, коли бізнес-вимоги не можуть бути реалізовані через проблеми інтеграції з джерелами вихідної інформації через відсутність самих даних, або відсутність технічної можливості збору цих даних. Тому важливо проаналізувати рівень інтеграції із зовнішніми системами, бажано з одночасним узгодженням бізнес-вимог. Це дозволить з одного боку зафіксувати в бізнесових вимогах лише джерела інформації, інтеграція з якими можлива, а з іншого боку - уникнути можливих проблем, пов'язаних з реалізацією бізнесових вимог через відсутність вихідних даних.
Модель сховища ACRM
Тепер настав час визначитися із моделлю, яка буде взята за основу сховища ACRM. Модель містить структуру пов'язаних між собою та згрупованих за предметними областями таблиць фактів та вимірювань. Вона має бути добре продуманою, адже від неї фактично залежить те, наскільки система буде масштабованою та гнучкою у використанні. Можна або спробувати розробити власну модель сховища, що пов'язано з додатковими витратами часу та ризиками, або взяти за основу одну з існуючих "референсних" pre-build моделей, тобто. спроектованих для конкретних предметних областей. Сьогодні pre-build моделі сховищ даних є у Oracle, SAP, IBM, Amdocs та інших компаній. Вони добре підходять для швидкого запуску шаблонного проекту, але нерідко потребують додаткового доопрацювання для вирішення конкретних бізнес-завдань. При виборі на користь тієї або іншої моделі сховища необхідно проаналізувати її архітектуру і оцінити обсяг необхідних додаткових доробок. До моделі ACRM пред'являються дві базові вимоги - вона повинна зберігатиінформацію про клієнтів та побудовані сегменти, а сама інформація має бути агрегована на рівні клієнта - ключового елемента сховища. Іншими словами, модель має бути клієнто-орієнтованою. Це дозволяє створити профілі клієнтів – горизонтальні таблиці фактів, у яких унікальним ключем є клієнт, а поля містять розраховані значення показників цього клієнта та посилання на вимірювання, за якими ці показники виміряні. Також має зберігатись історія зміни профілів клієнтів.
Модель має підтримувати 2 типи показників: планові (значення показників, спрогнозовані на майбутнє) та фактичні (отримані в результаті значення цих показників). Для завантаження інформації про клієнтів та розвантаження побудованих сегментів у зовнішні операційні системи може використовуватись будь-який інтерфейс. Важливою вимогою до моделі є масштабованість та варіативність. Тобто вона повинна дозволяти досить легко додавати додаткові атрибути клієнтів як як показники, так і як вимірювання.
Модель має покривати бізнес-потреби. Повнота моделі залежить від набору реалізованих вимірів та показників.
Додаткові вимоги до моделі у кожному конкретному випадку можуть відрізнятися одна від одної.
Засоби інтелектуального аналізу
Після вибору моделі необхідно визначити, які засоби інтелектуального аналізу, прогнозування та Data Mining потрібні для вирішення сформульованих бізнес-завдань. У деяких випадках завдання можна вирішити використанням аналітичної системи, що дозволяє кінцевим користувачам самостійно створювати необхідні звіти шляхом вибору показників і вимірювань із заздалегідь розроблених бізнес-шарів. Такі можливості доступні, наприклад, Business Objects, SAS, Oracle BI(Siebel Analytics), Cognos та інших систем.
Але в деяких випадках виникає необхідність використання засобів Data Mining для інтелектуального аналізу та видобутку прихованої інформації. Як правило, Data Mining використовується для вирішення завдань, пов'язаних з виявленням прихованих залежностей між параметрами, що досліджуються. До них відносяться завдання, вирішення яких не може бути універсальним: для них не можна однозначно визначити список KPI, що впливають на результат. Data Mining дозволяє в кожному конкретному випадку знаходити унікальний набір параметрів, що впливають на досліджувану групу. Подібні рішення також представлені цілим рядом компаній: SPSS, SAS, Angoss та інші.
Крім аналізу поточної інформації про клієнтів важливо мати можливість прогнозувати їхню подальшу поведінку. Відмінною особливістю ACRM є те, що значення KPI прогнозуються для кожного збудованого сегмента окремо. Причому обраний аналітичний інструмент має дозволяти будувати прогнози як на фактичних значеннях, а й у передбачуваних значеннях. Наприклад, аналітик, зробивши припущення про те, що продажі певного продукту знизяться на 20%, може ввести це значення як апріорний показник, на підставі якого побудувати прогноз зміни доходів.
При виборі на користь того чи іншого постачальника важливо оцінити: - вимоги до апаратно-програмної платформи; використовуваний математичний апарат; інтерфейс підключення додаткових джерел даних та передачі результату; повнота інструментарію з аналізу та прогнозування, досвід впровадження в інших компаніях цієї галузі.
Платформа сховища ACRM
Отже, сформовано чіткі бізнес-вимоги, розроблено модель сховища ACRM і, можливо, навіть є уявлення про те, якіінструменти аналізу знадобляться реалізації проекту. Тепер потрібно вибрати апаратно-програмну платформу.
Як правило, після вибору сховища, моделі ACRM та прикладного ПЗ вже можуть бути сформовані уявлення про те, на якій платформі вони мають працювати. Платформа повинна складатися з апаратної частини, СУБД, а також ETL-інструменту (Extract Transformation Load), який виконуватиме завдання транспортування та перетворення даних між інтегрованими системами та базами даних. Сьогодні досить багато компаній пропонують апаратне забезпечення: від недорогих поширених Windows-серверів, до багатопроцесорних серверних Unix-систем. Як СУБД найбільшого поширення набули: Oracle, MS SQL, DB2. ETL-інструменти також представлені на ринку рядом компаній: Oracle, Informatica, Microsoft, хоча в деяких випадках роль ETL можуть виконувати самостійно написані процедурною мовою модулі.
Крім вартості апаратно-програмної частини, при виборі платформи рекомендується керуватися такими факторами, як масштабованість, умови її супроводу, сумісність з нею прикладного ПЗ, надійність та продуктивність спільної роботи компонентів, що інтегруються, досвід впровадження аналогічних систем на цій платформі іншими компаніями та наявність кваліфікованих фахівців.