БИЗНЕС-СЕТЬ KINETICS CRM ERP ITSM
ЧТО ТАКОЕ CRM? НОВОСТИ АНАЛИТИКА ПРАКТИКА CRM СИСТЕМЫ CALL-ЦЕНТРЫ ПОСТАВЩИКИ  
   История Тренды Колонки Рейтинги Статьи     Консультации


РЕЙТИНГИ
СТАТЬИ
ПЕРСПЕКТИВЫ CRM
ИТОГИ И ТРЕНДЫ
ЛОЯЛЬНОСТЬ КЛИЕНТОВ
ОБЗОРЫ И РУКОВОДСТВА
СТОИМОСТЬ РЕШЕНИЙ
МЕТРИКИ ЭФФЕКТИВНОСТИ
ПОЛЕЗНЫЕ СОВЕТЫ


Gartner, ISM, Forrester Research, CRM TOP AWARDS и другие

   
   

СТАТЬЯ

Учет, контроль и анализ действий пользователей информационных систем



Часто бывает, что данные в учетной системе меняются, причем не всегда так, как того хотели ответственные лица. Такого рода изменения могут быть связаны с:
  1. Действиями пользователя-новичка, не имеющего достаточного опыта работы с программой;
  2. Действиями человека безответственного или не правильно понявшего свою задачу;
  3. Действиями, намеренно искажающими данные - порча, удаление, ввод некорректных данных по принципу "лишь бы вбить";
  4. Действиями случайными;

Рост вероятности подобных действий прямопропорционален количеству пользователей и их лояльности, а серьезность их последствий - статусу лиц, данные о которых вводятся в систему.
Так искажение данных о размещении VIP-персон в гостиницах, времени и месте их транспортного обслуживания могут не просто свести к нулю все усилия и ресурсы, потраченные на внедрение CRM-системы, но и сильно ударить по имиджу и финансовому состоянию компании.
В таких ситуациях супервайзинг данных становится задачей номер один, требующей как управленческих решений так и технического обеспечения.
Компания БМикро (www.bmicro.ru) на основе опыта внедрений сложных проектов с количеством пользователей 50+, разработала специальный инструмент для регистрации, контроля и анализа всех действий пользователей в системе.
Многие CRM-системы обладают простейшими средствами, позволяющими зафиксировать, кто из пользователей создал и кто последним изменил тот или иной Объект. Например, вот так:



кликните на картинку для ее увеличения


Однако, подобного средства недостаточно для полного мониторинга действий пользователей по следующим причинам:
  • Во-первых, этот метод не позволяет зафиксировать всей цепочки изменений, которые происходили с Объектом с момента его создания. Ведь при каждом последующем изменении информация о предыдущем Редакторе пропадает;
  • Во-вторых, невозможно понять, какие именно изменения и в каких именно атрибутах Объекта были произведены;
  • В-третьих, при удалении Объекта бесследно исчезает и вся информация: о его Авторе, Редакторах и, главное, Удалившем лице;
  • В-четвертых, трудно получить информацию обо всех действиях, произведенных в системе каким-либо пользователем за определенный промежуток времени;
  • Не фиксируется с какого рабочего места произведены изменения;
  • Не сформировать целостной картины действий пользователя за период именно в виде журнала.

В данной статье описывается более совершенное средство журнализации (протоколирования) данных, реализованное в системе Клиент-Коммуникатор и избавленное от перечисленных недостатков:
В основу встроенной в Клиент-Коммуникатор системы журнализации действий пользователей положен единый информационный регистр «Журнал изменений». Он снабжен удобным визуальным интерфейсом поиска, сортировки, группировки и просмотра:



кликните на картинку для ее увеличения



  1. позволяет выбрать, скажем, все Действия, произведенные одним пользователем за определенный промежуток времени;
  2. сгруппировать записи журнала, например, по Типам объектов;
  3. отфильтровать, допустим, только действия, связанные с редактированием данных;




кликните на картинку для ее увеличения


  1. и получить выборку из Журнала операций редактирования, произведенных данным пользователем за указанный период;




кликните на картинку для ее увеличения


Основной список «Журнала изменений» содержит лаконичный, универсальный набор сведений о каждом действии вне зависимости от Типа измененного Объекта:
  • Номер и Имя класса. Определяют Тип измененного Объекта (принадлежность к определенному списку данных);
  • ID записи. Позволяет Администратору группировать данные по внутреннему идентификатору Объекта, даже после удаления самого Объекта;
  • Дата изменения. Позволяет восстановить хронологию действий;
  • Пользователь. Позволяет отслеживать действия каждого пользователя;
  • Имя компьютера. Позволяет зафиксировать имена компьютеров, с которых производились изменения данных;
  • Действие. (Добавление, Правка, Удаление). Определяет тип каждого Действия;
  • Старое значение главного атрибута. Фиксирует тезис значений ключевых атрибутов Объекта по состоянию «до изменений»;
  • Новое значение главного атрибута. Фиксирует тезис значений ключевых атрибутов Объекта по состоянию «после изменений»;

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



кликните на картинку для ее увеличения


Она отображает список атрибутов объекта, изменившихся в результате действия, выбранного в основном списке. Таким образом, переходя в списке действий от строки к строке, аудитор Журнала будет иметь возможность получать полный объем информации, представляющей ценность для анализа;
Если аудитора заинтересовала какая либо запись в Журнале, он имеет возможность быстро перейти к Объекту, к которому она относится (конечно, если сам Объект к этому моменту еще не удален):
  • Следует открыть карточку выбранного Действия двойным кликом в списке. Карточка отобразит в более удобном виде те же сведения, что видны в списке Действий.
    В верхней строке карточки располагается ссылка на Объект (в данном примере это ссылка на Объект класса «Контактные лица»):




кликните на картинку для ее увеличения


  • Есть возможность «перейти по ссылке» непосредственно к объекту. Для этого предусмотрена кнопка.

    Иногда удобнее рассматривать информацию не со стороны общего журнала, а со стороны конкретного объекта, история которого интересует аудитора. Для этого в карточке объекта имеется вкладка со списком действий, произведенных над ним. Посмотрим на открытую карточку объекта, изображенную на предыдущем рисунке. Как мы видим, она снабжена вкладкой «Журнал изменений». Перейдем на эту вкладку и изучим её содержимое.



    кликните на картинку для ее увеличения


    Как мы видим, это список, отображающий выборку из Журнала, о котором говорилось выше;
    Часто возникает ситуация, когда пользователь в течение короткого промежутка времени несколько раз редактирует один и тот же объект, например, по причине того, что неправильно указал значение одного из атрибутов или забыл внести какие-то данные. Если фиксировать в Журнале все такие действия, то его объем будет избыточно пополняться малоинформативными сведениями. Поэтому, в рамках рассматриваемой реализации задачи разработчиками применен следующий механизм оптимизации:

    • если один и тот же пользователь несколько раз редактирует один и тот же объект в течение 1 (одной) минуты, то в журнале создается только одна запись.
    • при этом в поля Журнала с названиями типа «Старое значение…» подставляются значения, соответствующие состоянию объекта до самого первого изменения этой серии. А в поля с названиями типа «Новое значение…» подставляются значения, соответствующие состоянию объекта, приобретенному в результате самого последнего изменения этой серии;

    Теперь поговорим о настройке Журнала. Разумеется, не имеет смысла протоколировать изменения всех подряд Объектов системы, а следует вести Журнал только по тем Объектам и их атрибутам, которые Администратор системы сознательно выберет для этой цели. В противном случае объем Журнала быстро превысит все разумные пределы, да и превратится в «кладбище» бесполезных данных. Поэтому, существует механизм управления настройками журнализации, обладающий следующими возможностями:
    1. Включить (Выключить) журнализацию для каждого конкретного Типа объектов.
    2. Включить (Выключить) журнализацию для любого атрибута объекта.

    При первом включении журнализации для указанного Типа объекта в его карточке появляется вкладка «Журнал изменений». При выключении журнализации эта вкладка остается, и её список отображает ранее запротоколированные Действия. При повторном включении журнализации пополнение списка продолжается.
    Технические управление настройками осуществляется администратором системы и не требует от него специальных знаний и навыков программного кодирования:
    • Данные в системе упорядочены в виде «Дерева классов», каждый Класс определяет соответствующий Тип объектов:




    кликните на картинку для ее увеличения


    • Чтобы включить журнализацию класса и некоторых его атрибутов, достаточно определить их номера в дереве, а затем выполнить несколько процедур, что занимает не более минуты.

    Эти действия можно производить в любой момент, на функционирующей системе,
    в том числе во время активной работы пользователей. Настройки вступают в действие немедленно.
    Компания БМикро (www.bmicro.ru) предлагает всем пользователям программного комплекса «Клиент-Коммуникатор» версии 5.8. уникальный инструмент журнализации изменений, обеспечивающий наиболее полную и простую техническую поддержку супервайзинга данных. Информацию об условиях приобретения и дополнительные технические консультации всегда можно получить в офисах компании.

_______________________________________________________________________


ПРОЧИТАТЬ ДРУГИЕ СТАТЬИ:

7 причин, почему внедрение CRM приносит одни проблемы

В какой CRM работают крупные компании?

Обзор CRM-системы BPMSoft

Презентация Битрикс24 Орион

Введение в Microsoft Dynamics 365 Copilot

Разбор SBER CRM

Аналоги 1С:Предприятие

Новые механизмы RegionSoft CRM 8.0

Что такое CSAT?

CRM-система 一 что это такое?

Обзор новинок релиза Битрикс24.Полярная звезда

Пишем клиентам из Planfix в Telegram

«Арника» - система управления салоном красоты

Переход с SAP на 1С за 1,5 месяца. Опыт компании Zentiva

CRM-маркетинг в Битрикс24: Сегментация клиентов

Как внедряли новый процессинг для программ лояльности «Пятёрочки» и «Перекрёстка»

Какая в Мегаплане воронка продаж?

Результаты качественного исследования программ лояльности и CRM-маркетинга в России

Презентация новой версии amoCRM 2022

Чем хороша Low-code BPMS платформа от Comindware?


Показаны статьи 1 - 20 из 1517

Дальше  >>>




 
О портале Новости портала RSS Feed Услуги Размещение рекламы Форум Карта сайта Напишите нам! RUS / ENG  
Copyright © 2002 - 2025 CRMONLINE.RU All rights reserved. E-mail: