Учетные записи дилеров и клиентов. Как структурировать работу?

Wialon – универсальная система. Берите любые элементы, инструменты и настройки, комбинируйте и адаптируйте систему под любой проект. Но чтобы не потеряться в бесконечных геозонах, заданиях, пользователях, объектах и маршрутах, нужен порядок. 

Иерархия учетных записей и правильная структура содержимого – основа порядка, как фундамент в доме. Если фундамент заложен неправильно, под нагрузкой он проседает, и дом становится непригодным для жилья. 

Поэтому структура учетных записей – первое, на что мы обращаем внимание партнеров. В этой статье мы расскажем, как навести порядок в учетных записях, не важно, работаете вы с 10 или 10 000 объектов.

Выстраиваем иерархию: базовые элементы и правила

Прежде чем говорить о рекомендуемой структуре, вспомним, с чем и по каким правилам нам предстоит работать.

Вот список ключевых элементов в системе мониторинга:

• Объект – что-то, отслеживаемое системой, на чем установлен трекер.
• Пользователь – человек (или группа людей) с логином, паролем и настраиваемым доступом к различным элементам системы.
• Ресурс – контейнер, который можно воспринимать как набор с инструментами. В него входят геозоны, задания, уведомления, водители, прицепы, пассажиры, шаблоны отчетов и заявки.
• Учетная запись (УЗ) – глобальный контейнер, который включает в себя все вышеперечисленные элементы.

Создание УЗ и ресурсов доступно только в CMS (системе управления). Вы не найдете этого функционала в интерфейсе мониторинга. 

А вот по каким правилам эти элементы взаимодействуют: 

• Подчиненный элемент не может иметь больше прав или возможностей, чем вышестоящий элемент. Это относится и к учетным записям, и к правам доступа, и к иным настройкам. Например, пользователь не может иметь доступа к объекту, если у самого создателя пользователя его нет, либо в учетной записи не может быть доступа к Google картам, если такой доступ отсутствует в родительской учетной записи.
• У всех элементов системы имеется создатель. Это пользователь системы, от имени которого данный элемент создан и к чьей учетной записи он прикреплен. У создателя элемента нельзя забрать все права доступа на этот элемент (как минимум у него будет право «‎Просмотр элемента и его основных свойств»).
• В любой учетной записи изначально всегда есть один пользователь, который является ее создателем, и один ресурс. Далее в УЗ могут быть добавлены объекты, а также другие пользователи и ресурсы.
• Все действия в системе происходят от имени пользователя. Его возможности определяются не только списком прав в отношении других элементов, но и набором услуг учетной записи, в которую пользователь входит. Процесс предоставления доступа можно ускорить с помощью шаблона прав, а процесс назначения списка услуг – тарифным планом.

Главный секрет эффективной структуры сервиса

Ключевая ошибка при выстраивании структуры УЗ в Wialon –  использовать единую учетную запись для всех пользователей, а затем в рамках этой УЗ предоставлять каждому пользователю нужный объем прав на объекты и ресурсы. Когда бизнес расширяется и пользователей становится слишком много, такой подход перестает работать.

Мы настоятельно рекомендуем другой подход, где в четко выстроенной иерархии для каждого клиента создается отдельная УЗ независимо от размера автопарка. В ней же хранятся все нужные элементы: объекты, ресурсы и пользователи. 

В этой структуре для работников компании интегратора имеется промежуточная УЗ, которую будем называть «Менеджерская».

Расскажем подробнее, как создать такую структуру и в чем ее преимущества. 

Создаем правильную структуру сервиса

При активации сервиса каждому новому партнеру Wialon предоставляется главная учетная запись. Она также называется учетной записью верхнего уровня. Главная учетная запись имеет уникальное название, которое служит глобальным идентификатором сервиса в системе Wialon.

В главной УЗ нельзя создавать объекты или восстанавливать содержимое ресурса. Но именно она дает пользователю-создателю уникальные возможности:

• создавать дополнительные тарифные планы;
• добавлять и менять приложения;
• активировать модули;
• восстанавливать удалённые объекты из корзины.

Вдобавок к учетной записи верхнего уровня, партнеру по умолчанию предоставляется основной тарифный план со всем приобретенным функционалом. 

Учетная запись верхнего уровня и основной тарифный план являются системными, а поэтому владелец сервиса не может их редактировать самостоятельно (то есть без участия представителей Gurtam).

Что делаем дальше

• Создаем нужные тарифные планы

Помимо основного тарифного плана, интегратор может создать дополнительные. Это удобный способ ограничить действия пользователя и определить стоимость услуг.

Дополнительный тарифный план может создать только пользователь учетной записи верхнего уровня. В нем он определяет набор доступных сервисов, их стоимость, а также некоторые базовые свойства (например, минимальный баланс, при котором блокируется учетная запись, минимальный баланс, при котором ограничивается доступ к услугам, формат вывода баланса и т.д.).

• Создаем менеджерскую учетную запись

Поскольку учетная запись верхнего уровня имеет особый статус и особые возможности, мы не рекомендуем предоставлять к ней доступ для всех сотрудников интегратора. Для выполнения повседневных работ лучше использовать менеджерскую учетную запись. Она создается под учетной записью верхнего уровня, то есть располагается на втором уровне иерархии.

• Передаем права дилера

Чтобы дальше создавать учетные записи с менеджерской УЗ в качестве родительской, ей необходимо предоставить права дилера, а также выбрать из списка те тарифные планы, которые УЗ с правами дилера будет передавать пользователям на более низком уровне. Так как менеджерская учетная запись относится к компании интегратора, то ей необходимо назначить все тарифные планы сервиса.

Мы не рекомендуем создавать объекты в учетной записи с правами дилера и советуем воспользоваться для этого клиентской УЗ (см. ниже). 

• Создаем клиентскую учетную запись

В рекомендованной структуре такие учетные записи находятся на третьем уровне. Как писали ранее, мы советуем интегратору для каждого нового клиента заводить новую учетную запись вне зависимости от количества объектов у клиента: и для базового мониторинга одного единственного объекта, и для контроля автопарка на 200 объектов. 

Именно пользователь из клиентской УЗ должен иметь право создавать новые объекты. Также в этой УЗ мы рекомендуем хранить все объекты, пользователей, ресурсы с отчетами, геозоны и т.д., которыми будут пользоваться клиенты. 

Почему использовать отдельные учетные записи полезно

• При создании элементов в учетных записях второго и третьего уровня права на них автоматически предоставляются по иерархии вверх. А значит, пользователь УЗ верхнего уровня получает полный контроль над всеми элементами.
• Нельзя предоставить право на отчет, геозону или уведомление – только на ресурс. А значит, вам потребуются отдельные ресурсы для каждого клиента. Когда вы создаете для клиента УЗ, она изначально содержит в себе ресурс, что экономит время на настройку. Тем более, здесь же можно добавить дополнительные ресурсы.
• В настройках УЗ вы можете предоставить клиенту доступ к определенному функционалу, отключив часть услуг и скрыв ненужные вкладки в интерфейсе и в свойствах объекта.

• На вкладке «Услуги» в «Свойствах учетной записи» вы можете не только отключить инструменты, но и ограничить их количество: не более 40 геозон, 30 SMS в неделю, 15 объектов. А на вкладке «Ограничения» – задать автоматическую блокировку клиентов по дням или балансу. Подобные настройки можно собрать в шаблон и представить клиенту в виде отдельного тарифного плана.
• Данные по отдельной учетной записи удобно анализировать в CMS и отчетах. Сразу видна важная информация: какими услугами пользуется конкретный клиент (т.е. какой у него тарифный план), сколько объектов и прочих элементов он использует.
• Клиентские УЗ позволяют восстановить данные. Для главной учетной записи невозможно восстановить содержимое ресурса после удаления (например, задания или геозоны). Для дочерних УЗ восстановление всегда доступно, так что ваши клиенты не потеряют данные безвозвратно, а вам не придется настраивать учетные записи заново в случае проблем. 
• Рекомендуемая структура ускоряет скорость загрузки «тяжелых» учетных записей. Это важно при росте количества объектов. 
• Только создавая отдельные учетные записи для клиентов, вы сможете задать для них разный срок хранения данных. 

А если нужна более сложная структура сервиса?

Никаких проблем: любую структуру можно углубить и дополнить, главное – сохранять логику, описанную выше.

Пример 1

Вы работаете с дилером и хотите разграничить свои и его учетные записи. Создайте дилерскую УЗ под менеджерской УЗ. По функционалу они схожи с менеджерской, но относятся уже не к компании интегратора, а к компании его дилера. Не забудьте предоставить этой учетной записи права дилера и передать только те тарифные планы, которые посчитаете нужными.

Пример 2

Вы работаете с несколькими офисами, территориями или платным функционалом и хотите разграничить УЗ по этому признаку. В таком случае добавьте промежуточные УЗ, которые группируют учетные записи интегратора или дилера по определенному принципу (по офисам, обслуживаемой территории, платному функционалу и т.д.).

Например, часть ваших объектов пользуется сервисом Google Maps, доступ к которому платный. Если вы создаете объекты для всех клиентов под одной учетной записью (а Google Maps нужен не всем), Google может протарифицировать каждый объект и выставить неоправданно высокий счет. Однако вы можете расположить объекты, реально пользующиеся платным сервисом, в отдельной ветви иерархии и серьезно сократить расходы.  

Пример 3

У вас разветвленная система дилеров, отделений и групп клиентов. В таком случае создайте клиентскую, дилерскую и промежуточную УЗ на одном уровне. Это не нарушит порядок построения иерархии и позволит рассматривать уровни в рамках только одной ветки иерархии.

Будьте осторожны с усложнением структуры. Любое разветвление и увеличение количества уровней УЗ должно решать конкретную задачу, как в наших примерах. Иначе это только замедлит работу системы.

Как изменить текущую структуру сервиса

Просмотреть нынешнюю иерархию сервиса в виде древовидного раскрывающегося списка можно с помощью пункта «Иерархия сервиса» в меню пользователя в CMS. Этот функционал доступен для пользователей верхнего уровня, а также для дилеров.

Корректировка нынешней структуры возможна с помощью:

• переноса объектов;
• копирования содержимого ресурсов и настроек пользователя через импорт/экспорт;
• создания учетной записи на основе существующего пользователя.

Более глобальные изменения (например, внедрение менеджерской УЗ или перенос учетных записей со всем содержимым) поможет сделать отдел технического консалтинга Gurtam. Пишите на consulting@gurtam.com, если вам нужна помощь в этом вопросе.

Сравните иерархию своих учетных записей с тем, что описано в статье. Все ли сделано правильно? Создание рекомендуемой иерархии учетных записей – это крепкий фундамент для роста бизнеса. И он стоит того, чтобы уделить ему время. 

Больше советов о том, как структурировать учетные записи, вы найдете в наших видео:

• «‎Иерархия сервиса в системе Wialon» на конференции TelematiX;
• «‎Наводим порядок в сервисе. Перенос объектов».

Если у вас до сих пор остались вопросы о том, как сделать правильную структуру учетных записей, присылайте их на consulting@gurtam.com.