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

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

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

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

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

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

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

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

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

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

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

• 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» позволяет отображать информацию блоками с указанием автора и времени изменения. При этом механизм разграничения полномочий позволяет указывать, кто имеет права на добавление, удаление, изменение комментариев.

Workflow

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выводы

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

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

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