Звоните: +7 (495) 517-57-25

Рассмотрим разработку модели данных приложения, созданного на базе OMNITRACKER. Для того, чтобы в полной мере оценить возможности OMNITRACKER, давайте продолжим сравнивать его с хорошо известной системой HP OpenView Service Desk 4.5.

Вот несколько задач, с которыми вы наверняка сталкивались в ходе работы с HP OV SD 4.5 в части расширения модели данных:

  • Создать новое поле
  • Создать новый объект (ведь правда, вам в голову хоть раз приходила такая идея, но от неё пришлось отказаться)
  • Связать объекты между собой

Рассмотрим, как решаются эти задачи в OMNITRACKER.

Создание нового поля

Например, вы решили учитывать в справочнике персонала не только номера телефона сотрудников, но и их табельные номера. Задача одинаково легко решается и в HP OpenView Service Desk 4.5 и в OMNITRACKER. Однако обратите внимание на то, какое количество опций доступно вам при настройке поля:

OMNITRACKER
(нажмите на изображении для увеличения)

Оставим подробности настройки полей в руководстве администратора, а здесь лишь обратим внимание на самые интересные возможности:

  1. Включение поля в полнотекстовый индекс для последующего использования при полнотекстовом поиске
  2. Установка условий обязательности поля. При этом условия обязательности включают не только статус, как это было в HP OV SD 4.5, но и все остальные поля, тип клиента, текущий пользователь, значения других полей и так далее.
  3. Установка условий доступности поля. При этом условия доступности включают не только категорию объекта, как это было в HP OV SD 4.5, но и все остальные поля, тип клиента, текущий пользователь, значения других полей и так далее.
  4. Можем задать значения по-умолчанию
  5. Для текстовых полей можем задать маску, по которой будет вводиться информация в поле, что пригодится, например, если табельный номер имеет вид 0000-0000–00.

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

OMNITRACKER
(нажмите на изображении для увеличения)

Ниже приведен перечень доступных типов полей:

OMNITRACKER
(нажмите на изображении для увеличения)

Помимо общеизвестных типов в этом списке вы увидите не встречавшиеся ранее:

  • Memo — Time Stamped
  • Workflow
  • Reference to list of objects
  • Reference to object
  • Reference to user

Давайте коротко рассмотрим некоторые из них.

Memo — Time Stamped

Представьте, что в рамках процесса управления инцидентами, построенного по рекомендациям ITIL, решается инцидент, и каждый специалист, который с ним работает, оставляет комментарии о ходе его обработки. Разобраться в том, кто, о чём и когда писал в HP OpenView Service Desk 4.5 невозможно, так как все комментарии сваливаются в один большой блок текста. Только если специалисты дисциплинированы, или если вы любите читать длинный журнал истории изменений, можно частично понять, что и когда происходило.

OMNITRACKER предлагает более удобный механизм. Поле типа «Memo — Time Stamped» позволяет отображать информацию блоками с указанием автора и времени изменения. При этом механизм разграничения полномочий позволяет указывать, кто имеет права на добавление, удаление, изменение комментариев.

OMNITRACKER

Workflow

Большинство объектов в процессах ITSM имеют свой жизненный цикл. Перемещение по жизненному циклу обычно отражается в поле системы автоматизации, например, поле «Статус». Для объекта «Инцидент» значения поля, например, могут быть такими: «Зарегистрирован», «В работе», «Решен», «Закрыт» Перемещение по статусам означает выполнение определенных процедур процесса, вовлечение участников процесса и так далее. При этом:

  • в процессе обычно существует определённая последовательность перемещения между статусами, и некоторые перемещения могут быть запрещены. Например, выйти из статуса «Зарегистрирован» можно, но вернуться в него уже нельзя, так как объект уже находится в работе
  • перед переходом из одного статуса в другой необходимо обеспечить заполнение определённых полей, проконтролировать выполнение определённых условий. Например, прежде чем закрыть инцидент, необходимо убедиться, что заполнено поле «Решение» и проверить, что к инциденту не привязано открытых обращений
  • или, наоборот, при переходе из статуса в статус необходимо выполнить заполнение полей. Например, при переходе из статуса «Зарегистрирован» в статус «В работе» необходимо заполнить поле «Время реагирования».

Как подобные задачи решались в HP OpenView Service Desk 4.5? Несколькими механизмами: правила бизнес-логики, условия обязательности полей, механизм определения взаимосвязей между значениями полей (Generic relationships). В итоге настройка контроля перемещения объекта по жизненному циклу была затруднена, а иногда и невозможна, так как не все ограничения можно описать с помощью правил бизнес-логики.

OMNITRACKER для решения этой задачи предлагает поле типа Workflow, которое позволяет определить:

  • правила перехода между статусами
  • условия контроля при выходе со статуса и при входе на статус
  • необходимые действия при переходе между статусами
  • права на выполнение перехода между статусами

При этом настройка выполняется в одном месте в удобном графическом представлении.

OMNITRACKER
(нажмите на изображении для увеличения)

Поля типа «Reference to»

Вот ещё пара задач, часто встречающихся на практике:

  • Вам необходимо в существующем объекте хранить ссылку на другой объект. Например, в описании рабочей группы в поле «Старший группы» хранить ссылку на справочник персонала.
  • Вам необходимо в существующем объекте хранить список ссылок на другие объекты. Например, в описании ИТ-сервиса хранить перечень представителей заказчика, которым необходимо отправить уведомление в случае остановки этого сервиса.

HP OpenView Service Desk 4.5 в большинстве случаев справляется с первой задачей (в большинстве, так как есть несколько ограничений). Вторая задача в HP OV SD 4.5 не решается вообще никак, можно использовать только заложенные производителем ссылки.

В OMNITRACKER поле типа «Reference to object» позволяет ссылаться на другой объект, даже ссылаться на объект того же типа. Например, для того, чтобы выстраивать иерархию объектов (родительский/дочерний). Поле типа «Reference to list of objects» позволяет хранить список ссылок на объекты другого типа. Таким образом, у вас появляется возможность гибко управлять связями между объектами, причем связи могут быть двунаправленными, то есть привязав сотрудника к группе в качестве старшего, мы не только увидим это при просмотре группы, но также увидим в карточке сотрудника перечень всех групп, где он является старшим.

OMNITRACKER
(нажмите на изображении для увеличения)

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

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

Последний тип поля группы «Reference to…», «Refence to User», позволяет ссылаться на учетные записи OMNITRACKER, что бывает полезно при идентификации сотрудника, работающего с объектом.

Создание нового объекта

Теперь представьте, что перед вами стоит задача включения в ваш процесс нового объекта, которого ещё нет в системе. Например, вы решили в рамках процесса управления инцидентами сформировать базу знаний с описанием стандартных решений. Вам понадобится объект «стандартное решение», объект «статья базы знаний». В HP OV SD 4.5 вы не можете расширить модель данных и создать новые типы объектов. То есть придётся выкручиваться, используя существующие объекты, например, как-то отделяя базу знаний от инцидентов признаками, фильтрами и так далее.

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

Выводы

Модель данных OMNITRACKER позволяет снять множество ограничений, стоявших ранее. При этом продукт может использоваться не только для автоматизации стандартных процессов, но и для автоматизации других видов деятельности, которые уже существуют в организации или только планируются. Открытость всех настроек позволяет придать конфигурации продукта такой вид, который необходим именно вашим процессам, а не подстраивать процессы под возможности продукта, как это было при использовании HP OV SD 4.5.

В следующей статье мы рассмотрим возможности OMNITRACKER по разграничению полномочий на доступ к данным.

Автор: Евгений Шилов.

Евгений Шилов