Закрыть
Логин:
Пароль:
Забыли свой пароль?
Регистрация
Войти как пользователь
Вы можете войти на сайт, если вы зарегистрированы на одном из этих сервисов:

DOCFLOW - теория и практика электронного документооборота. Все о ECM и СЭД (системы электронного документооборота), ЭП

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

По информации сайта www.crmru.info
Компания "БМикро", Ростислав Дублин

 

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

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

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

Так, искажение данных о размещении VIP-персон в гостиницах, времени и месте их транспортного обслуживания могут не просто свести к нулю все усилия и ресурсы, потраченные на внедрение CRM-системы, но и сильно ударить по имиджу и финансовому состоянию компании.

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

Многие CRM-системы обладают простейшими средствами, позволяющими зафиксировать, кто из пользователей создал и кто последним изменил тот или иной Объект.

Однако, подобного средства недостаточно для полного мониторинга действий пользователей по следующим причинам:

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

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

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

  • Позволяет выбрать, скажем, все Действия, произведенные одним пользователем за определенный промежуток времени;
  • Сгруппировать записи журнала, например, по Типам объектов;
  • Отфильтровать, допустим, только действия, связанные с редактированием данных,
  • и получить выборку из Журнала операций редактирования, произведенных данным пользователем за указанный период.

Основной список «Журнала изменений» содержит лаконичный, универсальный набор сведений о каждом действии вне зависимости от Типа измененного Объекта:

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

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

Еще раз обратим внимание на нижнюю часть интерфейса просмотра Журнала.

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

Если аудитора заинтересовала какая либо запись в Журнале, он имеет возможность быстро перейти к Объекту, к которому она относится (конечно, если сам Объект к этому моменту еще не удален):

Следует открыть карточку выбранного Действия двойным кликом в списке. Карточка отобразит в более удобном виде те же сведения, что видны в списке Действий.

В верхней строке карточки располагается ссылка на Объект.


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

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

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

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

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

  1. Включить (Выключить) журнализацию для каждого конкретного Типа объектов.
  2. Включить (Выключить) журнализацию для любого атрибута объекта.

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

Технические управление настройками осуществляется администратором системы и не требует от него специальных знаний и навыков программного кодирования:

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

Эти действия можно производить в любой момент, на функционирующей системе, в том числе во время активной работы пользователей. Настройки вступают в действие немедленно.

Поделиться:


Тэги: Web 2.0


КАЛЕНДАРЬ
ПОСЛЕДНИЕ НОВОСТИ
21.06.2019
TESSA 3.3 – новые горизонты СЭД
Компания Syntellect объявила о выпуске официального релиза СЭД TESSA версии 3.3.
В новой версии платформы расширены возможности легкого клиента, обеспечена поддержка разных часовых зон и внесено более сотни других улучшений.

28.03.2019
Финансы уйдут в электронный документооборот
На рассмотрение государственной думы РФ вынесен законопроект о введении электронного документооборота в российских организациях. При создании электронных копии бумажных документов, оригиналы нужно будет хранить всего год.

28.03.2019
В ожидании цифрового прорыва
Как выбраться из «колеи», в которой, согласно институциональной теории, движется, увязнув всеми колесами, Россия? Ответ на этот вопрос эксперты ищут не первый год. Вряд ли есть одно решение, но, возможно, в этом стране помогут технологии: отечественная математическая школа всегда высоко ценилась во всем мире, да и IT-отрасль в России развита сильнее прочих. Во всяком случае, именно на их развитие делают ставку власти: от направления «Цифровые технологии» нацпроекта «Цифровая экономика» они ждут настоящего прорыва. Впрочем, его успех, по мнению экспертов, будет зависеть от синхронизации процесса цифровой трансформации во всех российских регионах.