Как разделить доступ в системе на тех, кому не мы не доверяем, и тех, кому верим как себе. Какие бывают варианты спрятать от ненужных глаз и нечистых рук самое сокровенное, читаем в этой статье.
Доступ на базу клиентов
Например, самое сокровенное из самого распространенного — клиентская база. Каждый уважающий себя руководитель беспокоится за то, чтобы конкурент не получил эту базу, еще и не дай бог со всей историй сношений, они же пожелания и предпочтения клиентов. Риск того, что уходящий менеджер прихватит с собой базу, это даже не как то ружье на стене, что стрельнет — это 100% гарантия.
Для того, чтобы усложнить эту задачу придумано множество способов, которые обязательно надо применять. Даже простейшие CRM-системы имеют некое подобие ролей доступа, которыми настраиваются так, что Иван Иванов может видеть только своих клиентов, и никак не может выгрузить их себе во внешний файл. Он, конечно, может сфотографировать на телефон карточки всех своих клиентов, но от этого уже точно, кроме угрозы перелома ног, никак не защититься. Хранение данных клиентов просто в файле Excel на сетевом диске равносильно предложению “забирайте, кто хочет”.
В индивидуальных системах существуют более хитрые способы разграничения доступа к данным. Какие существуют варианты доступа?
Без вариантов
А точнее, без ограничения доступа. Каждый может скопировать и увидеть всё содержимое. Это относится, например, ко хранению данных в файлах. Если не вырвать из системного блока все порты и дисководы, отключив предварительно Интернет, то данные уплывут.
Такой вариант используется при отсутствии каких-либо систем автоматизации на уровне развития компании сразу после перехода от печатных машинок к компьютерам.
Такой вариант допустим, когда компьютер отключен от сети, для надежности помещен в клетку Фарадея и, конечно, в нем отсутствуют дисководы. А вход в клетку делается по записи в соответствующий категорийный журнал. Наверное, все видели такое в кино про шпионов.
А если серьезно, то есть такое, в реальной жизни. Когда файл Excel лежит на сетевом диске и с ним работает много человек. Excel замечательный инструмент для бизнеса, но во-первых, не для задач работы с клиентами, во-вторых, не для обеспечения безопасного хранения. Бывает вариант, когда вместо Excel используются Google-таблицы. Более продвинутый вариант, с защитой путем определения доступа нескольких пользователей, но это уже второй вариант — “Единый доступ”.
Единый доступ
Это когда доступ ко всем данным защищен логином и паролем, или просто паролем. Это либо один логин пароль на всех, либо несколько логинов и паролей, как с Google-таблицами, но доступ одного уровня. Вариант с несколькими логинами лучше потому, что в данном случае можно отслеживать, кто именно накосячил. То есть, кто именно какие нехорошие изменения внес или что именно удалил. И если это именные доступы, то наказать виновника. К сожалению, данный вариант доступа, вне зависимости один это логин или несколько, не распределяет доступ по данным (например, менеджер работает только со своими клиентами).
Такой уровень разделения доступа часто встречается в локальных старых программах или старых самописных сайтах. Когда логин и пароль зашиты на уровне программы или системы управления сайта и изменяются путем изменения программного кода.
Разделение по данным
Это базовый, довольно распространенный способ доступа к данным. Он применяется в большинстве систем, позволяя сотрудникам получать доступ только к тем данным, которые они сами внесли в систему. Или видеть только те задачи, которые поставлены конкретно им. При этом все действия выполняются в рамках одного интерфейса, разделен только доступ на редактирование данных или открытие определенных карточек.
Этот уровень разделения доступа используется и в распространенных SaaS решениях для автоматизации, и даже в CMS (системах управления содержимым сайтов). При этом, как правило, подразумевается, что пользователь имеет доступ на всю систему, но не всё может менять.
Роли, интерфейсы и функции
Самый продвинутый вариант. Учитывая, что мы делаем индивидуальные системы, и можем делать их так, как хотим, а точнее как надо заказчику, с точки зрения доступа к данным тоже можно сделать как угодно.
Частым способом разделения доступа является подготовка отдельных интерфейсов для разных участников процесса. В некоторых случаях рационально сделать один интерфейс, как описано в разделе выше, и не переплачивать за отдельный. Но бывает так, что намного удобней и логичней сделать отдельный раздел для работы с теми же данными, но с другими ролями сотрудников. Например, система CRM для производителя оконных конструкций. При этом менеджеру надо видеть все данные по заказу. А вот замерщики имеют свой интерфейс и доступ на него, в который попадают заказы только в стадии замера. При этом они видят только адрес, имя и телефон, ну или другие необходимые только ему данные для того, чтобы выполнить свою роль. Тоже самое по доставке, достаточно видеть что везем и на какой адрес, но знать сколько это стоит и внутреннюю математику заказа специалисту по доставке видеть незачем. Сотрудники на производстве видят заказ как результаты замера и вносят только те данные, которые должны внести в систему. Им тоже незачем знать, сколько и каких заказов на стадии замера.
Такая реализация исключает множество рисков. Например, когда поступил звонок менеджеру и клиент пока думает, а ему звонят конкуренты чтобы предложить дешевле потому что один из участников процесса на производстве, имеющий доступ в систему, имеет друга в конкурентной компании, это плохо.
Функциональный подход
Это когда в системе задаются не роли-должности, а функции, выполняемые в рамках бизнес-процессов. Такая модель организации доступа еще лучше ролевой, потому что, как правило, на практике сотрудники выполняют по несколько функций, замещают друг друга на время отпусков и болезней. В случае функционального подхода выдается доступ на функцию добавления заказов, создания клиентов, обработки входящих звонков, утверждения заказа на производство и других действий в системе. А сотруднику настраивается доступ на набор функций. Это работает в сочетании с едиными интерфейсами с разными элементами. Например, карточка заказа. Если у пользователя включена функция на утверждение заказа на производство, то у него есть соответствующая кнопка. В некоторых системах мы делали с помощью такого подхода процессы согласования заказов у всех руководителей, “руководитель производства”, “коммерческий директор”, “финансовый директор” и так далее. При этом у генерального директора есть разрешение на выполнение всех функций и за любого из заместителей он может поставить утверждение. Конечно, в систему заносится кто и когда нажал одобрение, не только роль, но и данные пользователя. При данном подходе каждый пользователь в системе — отдельный человек, а не просто роль, то есть это конкретное ответственное лицо со своим ФИО.
Функции в ролях
Также существует еще более сложная организация процесса. Это когда кроме функций создается еще и справочник ролей. Создается роль Менеджер, в него включаются функции создания клиентов, создания сделок. Создается роль Старший менеджер, в него включаются также функции удаление клиентов, просмотр всех клиентов компании. А на пользователя назначается уже конкретная роль. Если делать назначение нескольких ролей, то доступ определяется наличием функций в этих ролях. Такой подход является более запутанным, более требовательным к администрированию. Например, один из пользователей ушел в отпуск, и надо дать другому только одну функцию, или вообще распределить функции сотрудника между другими сотрудниками, по одной функции на каждого. Тогда прошлый подход, где назначаются только функции, является более удобным и гибким.
Доступ на практике
На практике используется такой подход, который диктует система. Ну конечно, кроме индивидуальной разработки. Используется тот механизм защиты данных, который можно использовать или задать. К сожалению, вопросы о необходимости защиты данных другого уровня возникают когда уже и поздно.