Роль 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 предоставляет широкий функционал по разграничению прав доступа к данным о клиенте и работе с ними. Все вышеперечисленное является стандартными инструментами и уже неоднократно доказывало свою эффективность на практике.