«Остановка запрещена», или Не бойтесь развивать ITSM-систему

Для процессной автоматизации будущего ITSM-проекта важным фактором выбора является функциональность платформы. Выбирая из продуктовой линейки вроде Naumen Service Desk, HPSM, BMC Remedy, ServiceNow и т.п. продвинутое решение для автоматизации процессов, заказчик предполагает, что функциональность продукта позволит автоматизировать не только процессы управления ИТ в рамках планируемого ITSM-проекта, но и, как правило, деятельность смежных сервисных подразделений.

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

В зрелой организации ITSM не заканчивается проектом по внедрению платформы процессной автоматизации. Напротив, это лишь отправная точка для длительного «путешествия» с постоянными трансформациями и преобразованиями: меняются услуги, технологии и способы обслуживания потребителей или задачи бизнеса. И естественно, что эти изменения должны находить отражение и в функциональности ITSM-системы. Ведь даже те заказчики, которые на старте проекта думают обойтись решением-«коробкой», в ходе эксплуатации существенно модифицируют коробочную функциональность.

За несколько лет опыта внедрения автоматизированных систем мною был сформирован примерный перечень возможных рисков при развитии ИТ-систем, которые чаще всего носят организационно-технический характер. В этой статье я поделюсь накопленным опытом и расскажу, как при постоянной модификации ITSM-системы нивелировать или даже постараться обойти эти возможные «острые углы».

Точки автоматизации и нивелирование рисков

В качестве основных ключевых точек автоматизации и связанных с ними рисков выделяются следующие аспекты:

1. Встраивание новых модулей. Вызывает опасение, что процессы бизнеса не «лягут» в программную логику системы, например, в ситуации, когда ИТ-инструмент не обладает необходимым модулем, поэтому новый модуль будет сложнее интегрировать с уже существующими.
2. Информационная нагрузка интерфейсов. Увеличение функциональности системы влияет на то, что пользовательские интерфейсы становятся всё более контекстно нагруженными, в результате может расти неудовлетворенность пользователей при работе в чрезмерно усложненной или громоздкой веб-среде.
3. Визуализация и детализация связей между объектами. Велика вероятность, что разнородные сущности в разных процессах системы не смогут быть интуитивно понятны и достаточно связаны между собой, из-за чего под вопросом будет качество данных для дальнейшего анализа. Возникнет риск отсутствия или нехватки связей, неверно заполненных полей и т.д.
4. Расширение количества автоматизаций. Автоматизация новых и новых процессов ведет к расширению количества скриптов, что напрямую влияет на производительность системы. Важно управлять этим процессом, чтобы не допустить зависаний или недоступности системы, а также ситуаций, когда из-за разрастания автоматизаций администраторы не могут оперативно разобраться в ее «внутренностях».
5. Персонализация схем представления информации. Недостаточная проработка форм визуализации и сценариев обработки данных порождает риск ограниченных способов представления информации и может вызывать ситуации саботирования работы с системой со стороны участников процесса.
6. Инструменты аналитики. Всё больше и больше в практике работы мы нуждаемся в интерактивных и гибких инструментах аналитики в ИТ-системах для интерпретации информации по различным метрикам, срезам и аспектам. Отсутствие расширяемого набора инструментов увеличивает затраты на «ручной» мониторинг и снижает эффективность труда в целом.

Далее остановимся подробнее на способах «устранения» каждого из потенциальных рисков.

Встраивание новых модулей

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

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

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

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

Информационная нагрузка интерфейсов

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

Пользователю не может быть комфортно, если он видит в «едином окне» все, если каждый объект содержит более 10 вкладок с 4-5 уровнями вложенности и вдобавок вертикальный скроллинг в рамках страницы. Поэтому нельзя идти только по пути набрасывания контентов на одну вкладку или укрупнения объектов до состояния многоэтапной вложенности.

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

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

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

При использовании нескольких систем на одном инстансе целесообразно выдавать пользователям права на просмотр только тех подсистем, в которых они будут работать, а остальные скрыть. Это реализуется за счет введения профилей пользователей, соответствующих используемым системам: пользователь Service Desk, пользователь системы управления ИТ-активами, пользователь системы управления знаниями.

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

Данные рекомендации позволят сохранить объем отображаемой информации на приемлемом уровне, не перегружая интерфейсы. Кроме того, получение от пользователей обратной связи, проведение аудита интерфейсов на предмет оптимизации — всё это последовательные и необходимые шаги по конструированию удобных интерфейсных форм. Оптимизировать уже готовые интерфейсы всегда можно за счет скрытия неиспользуемых кнопок, слияния схожих объектов в списках, скрытия тех частей системы, с которыми пользователь не работает, периодического просмотра обновлений платформы. Бывают ситуации, когда то, для чего в старой версии платформы автоматизации была выделена отдельная вкладка, в новой версии решается всего лишь одной кнопкой.

Визуализация и детализация связей между объектами

Недостаточно удобно представленные связи между объектами обычно проявляют себя на стыках процессов: обращение — изменение, обращение — база знаний, обращение — учет ИТ-активов. Пользователи забывают проставлять связи или намеренно игнорируют представленную функциональность, считая ее необязательной для заполнения. Административные меры здесь работают не всегда, приходится периодически проводить аудит силами менеджеров соответствующих процессов.

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

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

Расширение количества автоматизаций

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

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

Персонализация схем представления информации

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




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




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




По требованиям безопасности методы интеграции с базой данных напрямую или промежуточные файлы используются всё реже, поэтому целесообразно использовать интеграцию по REST, SOAP или по шине данных. При отсутствии готового модуля дляnbsp;работы с шиной данных несложно написать отдельный функциональный модуль, содержащий правила отправки и получения пакетов данных.

Инструменты аналитики

Участники процессов в ITSM-проекте постоянно нуждаются в удобных инструментах аналитики с широкими возможностями в аспекте интерактивности. Пользователи ожидают от отчетности получить drill-down технологии, позволяющие проходить «вглубь» аналитики показателей, чтобы разбираться в причине появления итоговых цифр. Все базовые метрики должны концентрироваться в одном отчете, предоставляя пользователю дашборды для расширенной аналитики. Существующие свободно распространяемые системы отчетности (Pentaho, Birt, Jaspersoft) удовлетворяют этой задаче не в полной мере, поэтому следующим проактивным шагом является интеграция с BI-системами. Такие системы незначительно влияют на производительность приложения, при этом позволяя выстроить аналитику согласно потребностям заказчика (иерархия данных выстраивается, начиная с первичного запроса и конвертируется в кубы данных или иные структуры, удобные для исследования).




Организация единого центра компетенции

Наш опыт ведения ITSM-проектов подсказывает, что постоянное развитие и совершенствование ИТ-систем невозможно без организации некоего центра компетенций, где главной фигурой должен стать ИТ-архитектор, который сможет на ранних стадиях заниматься нивелированием потенциальных рисков.




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

Ищете надежную ITSM-систему для организации работы ИТ и других внутренних подразделений? Расскажите о вашей задаче, а мы проконсультируем и проведем демо Naumen Service Desk.