Роль CRM-системи в розмежуванні прав доступу до даних про клієнта
Тематика: CRM-системи
Галузь: Універсальні рішення
Автор: Розмежування прав доступу до даних і функціональних можливостей додатку – важливий елемент будь-якої ІТ-системи. Причому вимоги, що пред’являються до такого інструментарію, для різних додатків можуть відрізнятися досить сильно, хоча, на перший погляд, це може бути і не очевидним.
Сьогодні я хотів би описати, як реалізовано розмежування прав доступу в Oracle Siebel CRM. Тим більше, що рішення, які використовуються в даній CRM-системі, дійсно «елегантні» та заслуговують вашої уваги.
В Siebel CRM управління правами доступу розділене на дві основні частини:
– Розмежування прав доступу до функціонала CRM-системи
– Розмежування прав доступу до даних, що зберігаються в CRM-системі
При розгляді розмежування прав доступу до функціонала CRM-системи можна виділити основний об’єкт – Responsibility (в перекладі – посадові обов’язки, хоча частіше використовується поняття «бізнес-ролі»).
Що це і як це працює?
Наприклад, оператор контакт-центру повинен мати можливість переглядати основну інформацію про клієнта і створювати Service Request (сервісне звернення). При цьому він не повинен мати можливість створювати угоди або виправляти важливу інформацію про клієнта: ІПН, номер паспорта і т.п. У той же час, менеджер з продажу, закріплений за зазначеним клієнтом, має право створювати угоди або на підставі пред’явлених документів – вносити зміни в базу даних.
Як реалізувати такі обмеження на практиці?
У Oracle Siebel CRM це досягається шляхом подання для різних категорій користувачів різних екранних форм (в термінології Siebel CRM – View) з певним набором функціоналу (перелік інформації, що зображується, кнопки, пункти меню, доступ до редагування даних).
Таким чином, оператор контакт-центру і менеджер з продажу будуть мати доступ до екранних форм з різним набором функціоналу, який визначається в залежності від виконуваної ділової ролі.
Однак, управління доступом до функціонала CRM-системи – це тільки частина завдання. Для коректної роботи потрібен інструмент для розмежування доступу до даних.
Для прикладу наведу ряд типових ситуацій, в яких найбільш логічно використовувати подібний інструментарій:
- Клієнти закріплюються за територіальними одиницями компанії (філіями, відділеннями, регіональними представництвами тощо). Доступ до повної інформації про клієнта (адреси, контактні дані, продані товари і послуги, потенційні угоди, сервісні звернення і т.п.) повинні мати тільки співробітники цієї «філії», співробітники «сусідньої філії» бачити ці дані не повинні.
- Усередині «філії» клієнти можуть закріплюватися за певними співробітниками.
- Досить часто виникають завдання, за яких окремі співробітники отримують доступ до даних по клієнтах. При цьому, список клієнтів чітко визначений, а співробітники не мають прямого відношення до «філії», до якої «прикріплені» зазначені клієнти.
- Звичайно ж, в будь-який великий компанії існує ієрархія підрозділів і посад. Логічно, що «вищі» підрозділи і посадові особи повинні мати доступ до інформації про клієнтів «підлеглих».
Давайте відповімо на питання: які цілі ми переслідуємо, коли хочемо обмежити доступ до даних?
Найбільш популярна відповідь: в цілях безпеки бізнесу…
Більш того, нерідко цією відповіддю все й обмежується, залишаючи без уваги не менш важливі речі. Так, наприклад, чим менше доступної інформації, тим легше знайти «те, що шукав». Звичайно ж, за умови, що потрібна для роботи інформація доступна 🙂
Отже, як же вирішується завдання щодо розмежування доступу до даних в Oracle Siebel CRM?
По-перше, в Siebel CRM є всі необхідні об’єкти, що описують ієрархію організаційної структури компанії, ієрархію штатного розкладу і список співробітників.
Варто відзначити, що в Oracle Siebel CRM ієрархія штатного розкладу може істотно відрізнятися від ієрархії організаційної структури компанії.
По-друге, всі записи в БД Siebel CRM прив’язуються до підрозділів, штатних одиниць і співробітників.
В результаті, CRM-система може забезпечувати гнучку фільтрацію даних. Наприклад, для будь-якого користувача можна зобразити:
- Всіх клієнтів, які прив’язані до його «філії».
- Всіх клієнтів, до яких «прив’язаний» співробітник, як штатна одиниця (в термінах Siebel CRM – команда клієнта). Причому, в даному випадку абсолютно не важливо, в якій «філії» працює співробітник.
- Всіх клієнтів підлеглих (мається на увазі посадова ієрархія, а не орг. структура).
- Всіх клієнтів підпорядкованих підрозділів.
У Oracle Siebel CRM доступ до різних бізнес-об’єктів може надаватися як конкретним співробітникам, так і певним позиціям штатного розкладу. В першу чергу, це пов’язано з тим, що співробітники можуть змінювати посади всередині компанії, звільнятися, а штатна одиниця при цьому частіше залишається незмінною. Таким чином, при звільненні відповідального співробітника достатньо на цю ж посаду в Siebel CRM призначити нову людину і він одразу отримає доступ до всіх необхідних даних.
У той же час, «Завдання співробітникам» або «Контакти» (фіз. особи) «прив’язуються» до співробітників, а не до посад. Це пов’язано з тим, що завдання зазвичай даються персонально, а спілкування з конкретними людьми найчастіше будується на особистих контактах. Але Oracle Siebel CRM має гнучкі налаштування по управлінню правами доступу, тому розмежування може бути організовано виходячи з внутрішньої політики компанії.
Але і це ще не все. У Oracle Siebel CRM є можливість управляти доступом на підставі продуктового каталогу.
Наприклад, в банку добре організований роздрібний бізнес (кредити, депозити тощо). Філіальна мережа відмінно продає стандартний набір роздрібних продуктів, але банк вирішує запропонувати своїм заможним клієнтам додаткові послуги з формування і обслуговування «інвестиційного портфеля». Цей продукт сильно відрізняється від «звичайних» роздрібних продуктів, тому його не варто «довіряти» всім продавцям філіальної мережі. Одна з найбільш правильних стратегій в такому випадку — створення команди професійних інвестиційних брокерів в центральному офісі.
Для реалізації такого підходу в продуктовому каталозі Siebel CRM створюються відповідні продукти з потрібними атрибутами. Доступ до нових банківських продуктів надається тільки для учасників команди «Інвестиційні брокери». При цьому продавці філій не побачать в продуктовому каталозі ці специфічні продукти, хоча можуть знати про їх існування. Це дозволить уникнути прояву непотрібної ініціативи з продажу того, в чому вони «нічого не розуміють». Далі в тій же CRM-системі запускаються маркетингові кампанії та команда професіоналів продає і супроводжує нові продукти по всій країні.
Для розмежування прав доступу до продуктів в Oracle Siebel CRM передбачені додаткові об’єкти: «Каталоги» і «Групи доступу», що нагадують елементи LDAP або AD.
Я описав основні принципи управління правами доступу в Siebel CRM, тепер давайте дуже коротко зупинимося на процесах адміністрування всього перерахованого.
Налаштування переліку екранних форм відповідно до бізнес-ролей (Responsibility) і каталогів в більшості випадків відбувається один раз. Нових користувачів потрібно лише додати до відповідних груп доступу і вибрати бізнес-ролі. З клієнтськими даними справа дещо складніша. Даних багато, вони постійно змінюються, доповнюються. Їх необхідно прив’язувати до орг. структури, посад і співробітників. Частина інформації CRM-система «прив’язує» автоматично, але доведеться попрацювати і «руками».
Oracle Siebel CRM надає широкий функціонал щодо розмежування прав доступу до даних про клієнта і роботі з ними. Все перераховане вище є стандартними інструментами і вже неодноразово доводило свою ефективність на практиці.
