ОПД в CRM системе. Как должны быть построены ограничения прав доступа
Invite pending
В данной статье, без привязки и указания конкретных систем, проводится попытка обсудить организацию механизма прав доступа в современной CRM/XRM системе.
Как только количество сотрудников в компании переваливает за небольшое число в 5 – 7 – 10 человек, возникает потребность в ограничении к доступу к данным для пользователей системы. Причины ограничений могут быть: «лишнего не надо знать», «не знать, чтобы избежать конфликтов», «сохранить свои данные от порчи, выноса», другие причины.
Разработчики небольших систем ограничиваются доступом к модулям. «Кто-то» не видит модуль сделок, «кто-то» модуль проектов и пр. В развитых системах это решается управлением меню. Как показано на рисунке ниже.
В целом, все просто. Есть группы пользователей (произвольно создаваемые), у каждой из них есть меню, навигационные панели, риббон-панели и пр. Мышкой можно брать доступные интерфейсы и создавать навигационную структуру. Для красоты присваивать подгружаемые пользовательские иконки или коллекции иконок. Можно копировать настройки, чтобы было проще.
Это, так сказать, первичный, самый простой уровень функционального разграничения. «Туда ходим, сюда не ходим», «секретарь имеет 1 – 2 интерфейса, ей больше не надо» и пр.
Другое дело, если Вы захотите разграничивать доступ к объектам данных. Здесь могут быть ограничения абсолютного значения: «Группа не видит клиентов в Москве» или относительного: «Текущий пользователь не видит клиентов, где он не является куратором», или еще пример: «Логистам не видны суммы договоров, если они больше ххх ххх ххх евро».
Стоит отметить, что в ряде систем существует возможность добавлять свои справочники, поля и т.п. Когда мы анализировали конкурентов и «конкурентов», было замечено, что далеко не все поставщики CRM делают доступными «свои» пользовательские поля в системе разграничения доступа. Часто бывает, что «здесь поля можно добавить, но ни в ОПД, ни в интеграции с 1С они не будут доступны» Тем более, что в небольших системах разграничение доступа по полям таблиц в принципе невозможно. Но зачастую и в больших системах разграничение доступа по условиям если и возможно, то крайне неудобно, скриптами, еще как-то.
Предлагаем рассмотреть, как по-нашему мнению должна быть организована система разграничения доступа в CRM/XRM системе, чтобы это было легко настраиваемым, изменяемым, в т.ч. на пользователях в количестве 1000+.
В центральной части формы настройки ОПД, (см. выше) имеется доступ ко всем таблицам и их атрибутам. В левой части располагается список групп пользователей.
И самое интересное — в правой части условия доступа:
• Отображение
• Добавление
• Изменение
• Удаление
• Использование
• Экспорт
Для каждой группы можно создавать 1 или несколько комбинаций: «Разрешить отображать, но запретить удалять и редактировать». При этом доступно ключевое (!) По условию: «Разрешить отображать, но запретить редактировать, если прошло 3 дня с даты последней редакции» и т.п.
Настройка условий может быть абсолютной и производиться в специальной форме фильтра – с указанием конкретных значений:
Условий фильтрации может быть любое количество, включая группы условий и логику связи групп.
Также разграничение может быть относительным по:
• Текущему пользователю,
• Текущему подразделению,
• Текущей компании пользователя (в соотв. с орг. структурой и логином)
• Текущий временной период или соседние периоды
o Текущая неделя, день, месяц и т.п.
o Предыдущая или иная неделя, день и т.п. (устанавливается, как «текущая неделя – 1»)
o И др. гибкие настройки
• Др. относительные параметры и внешние переменные.
Здесь следует отметить, что под внешними параметрами могут выступать и вычисления, например, когда:
• Можно привязать ОПД к сумме или сроку;
• Можно привязать ОПД к сложному вычислению условия по функции в SQL.
Настройка ОПД ко всем атрибутам осуществляется аналогично.
С той лишь разницей, что атрибут нельзя использовать по ссылке и для него вводится понятие «Ввод нового значения» (для справочных атрибутов, как показано на рисунке) и нет экспорта.
Указание «по условию» ОПД и работы с атрибутом для каждой группы задается аналогично – через гибкую форму фильтра, по сути перекрывающую любую логическую комбинацию.
Дополнительно следует обратить внимание, что для администраторов системы предусмотрены все возможные комбинации копирования групп условий между группами пользователей – для удобства управления большими коллективами.
Закрывание возможности осуществлять экспорт данных из той или иной таблицы – мы не видим смысла описывать – там все просто.
Основной смысл: гибкое и логически выверенное ОПД как на уровне таблиц, так и на уровне атрибутов. При этом, реализация ролевого доступа «кто владелец записи» не вызывает проблем в данном контексте, разве что может потребоваться (по опыту) небольшое программирование на SQL. Опыт есть – обращайтесь.
Как только количество сотрудников в компании переваливает за небольшое число в 5 – 7 – 10 человек, возникает потребность в ограничении к доступу к данным для пользователей системы. Причины ограничений могут быть: «лишнего не надо знать», «не знать, чтобы избежать конфликтов», «сохранить свои данные от порчи, выноса», другие причины.
Разработчики небольших систем ограничиваются доступом к модулям. «Кто-то» не видит модуль сделок, «кто-то» модуль проектов и пр. В развитых системах это решается управлением меню. Как показано на рисунке ниже.
В целом, все просто. Есть группы пользователей (произвольно создаваемые), у каждой из них есть меню, навигационные панели, риббон-панели и пр. Мышкой можно брать доступные интерфейсы и создавать навигационную структуру. Для красоты присваивать подгружаемые пользовательские иконки или коллекции иконок. Можно копировать настройки, чтобы было проще.
Это, так сказать, первичный, самый простой уровень функционального разграничения. «Туда ходим, сюда не ходим», «секретарь имеет 1 – 2 интерфейса, ей больше не надо» и пр.
Другое дело, если Вы захотите разграничивать доступ к объектам данных. Здесь могут быть ограничения абсолютного значения: «Группа не видит клиентов в Москве» или относительного: «Текущий пользователь не видит клиентов, где он не является куратором», или еще пример: «Логистам не видны суммы договоров, если они больше ххх ххх ххх евро».
Стоит отметить, что в ряде систем существует возможность добавлять свои справочники, поля и т.п. Когда мы анализировали конкурентов и «конкурентов», было замечено, что далеко не все поставщики CRM делают доступными «свои» пользовательские поля в системе разграничения доступа. Часто бывает, что «здесь поля можно добавить, но ни в ОПД, ни в интеграции с 1С они не будут доступны» Тем более, что в небольших системах разграничение доступа по полям таблиц в принципе невозможно. Но зачастую и в больших системах разграничение доступа по условиям если и возможно, то крайне неудобно, скриптами, еще как-то.
Предлагаем рассмотреть, как по-нашему мнению должна быть организована система разграничения доступа в CRM/XRM системе, чтобы это было легко настраиваемым, изменяемым, в т.ч. на пользователях в количестве 1000+.
В центральной части формы настройки ОПД, (см. выше) имеется доступ ко всем таблицам и их атрибутам. В левой части располагается список групп пользователей.
И самое интересное — в правой части условия доступа:
• Отображение
• Добавление
• Изменение
• Удаление
• Использование
• Экспорт
Для каждой группы можно создавать 1 или несколько комбинаций: «Разрешить отображать, но запретить удалять и редактировать». При этом доступно ключевое (!) По условию: «Разрешить отображать, но запретить редактировать, если прошло 3 дня с даты последней редакции» и т.п.
Настройка условий может быть абсолютной и производиться в специальной форме фильтра – с указанием конкретных значений:
Условий фильтрации может быть любое количество, включая группы условий и логику связи групп.
Также разграничение может быть относительным по:
• Текущему пользователю,
• Текущему подразделению,
• Текущей компании пользователя (в соотв. с орг. структурой и логином)
• Текущий временной период или соседние периоды
o Текущая неделя, день, месяц и т.п.
o Предыдущая или иная неделя, день и т.п. (устанавливается, как «текущая неделя – 1»)
o И др. гибкие настройки
• Др. относительные параметры и внешние переменные.
Здесь следует отметить, что под внешними параметрами могут выступать и вычисления, например, когда:
• Можно привязать ОПД к сумме или сроку;
• Можно привязать ОПД к сложному вычислению условия по функции в SQL.
Настройка ОПД ко всем атрибутам осуществляется аналогично.
С той лишь разницей, что атрибут нельзя использовать по ссылке и для него вводится понятие «Ввод нового значения» (для справочных атрибутов, как показано на рисунке) и нет экспорта.
Указание «по условию» ОПД и работы с атрибутом для каждой группы задается аналогично – через гибкую форму фильтра, по сути перекрывающую любую логическую комбинацию.
Дополнительно следует обратить внимание, что для администраторов системы предусмотрены все возможные комбинации копирования групп условий между группами пользователей – для удобства управления большими коллективами.
Закрывание возможности осуществлять экспорт данных из той или иной таблицы – мы не видим смысла описывать – там все просто.
Основной смысл: гибкое и логически выверенное ОПД как на уровне таблиц, так и на уровне атрибутов. При этом, реализация ролевого доступа «кто владелец записи» не вызывает проблем в данном контексте, разве что может потребоваться (по опыту) небольшое программирование на SQL. Опыт есть – обращайтесь.