Осознанный выбор средства автоматизации ITSM процессов

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

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

Так как тема выбора программных продуктов возникает постоянно, а материалов на эту тему крайне мало, я решил поделиться проектным опытом, часть которого позднее нашла подтверждение в разделе 7.2. Service management tools книги Service Design библиотеки ITIL® v3.

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

Поэтому давайте рассмотрим последовательность шагов по оценке программных продуктов, предлагаемых авторами ITIL v3 с поправками на то, как это бывает на практике.

Формирование требований

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

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

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

Создание длинного списка

На первый взгляд создать длинный список просто, однако необходимо все же тщательно подойти к выбору продуктов попадающих в длинный список. Не лучшим способом составления длинного списка является копирование рейтинга программных продуктов, подготовленного каким-либо аналитическим агентством, так же как и списков сертифицированных продуктов (Pink Verify, OGC ITIL® Software Assessment Scheme), поскольку они могут не содержать продуктов, которые могут быть наиболее интересны для вас. Поэтому обзоры, рейтинги и списки сертифицированного программного обеспечения стоит рассматривать в качестве дополняющих друг друга источников.

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

Ниже приведён пример длинного списка:

• Beetil
• BMC Remedy ITSM Suite
• CA Service Desk Manager
• HP Service Manager
• ManageEngine ServiceDesk Plus
• Microsoft Service Center
• Naumen Service Desk
• Numara Footprints
• OMNINET OMNITRACKER ITSM Center
• OTRS
• ServiceNow Service Desk
• Деснол Софт Итилиум

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

Создание критериев отбора в короткий список

Критерии отбора в короткий список обычно строятся на базе требований, определённых на первом шаге и отнесённых к категории M (Must have) в рамках MoSCoW анализа с добавлением дополнительных условий, например, таких как ценовой диапазон. Критерии подбираются таким образом, чтобы их можно было оценить с минимальными затратами, например, на основании общедоступных сведений от производителя или партнёров.

Примером таких критериев может быть:

• Наличие локализованного интерфейса
• Наличие русскоязычной поддержки
• Наличие внедрений в России
• Наличие автоматизации определённых процессов
• Стоимость не более чем X рублей

Оценка продуктов и формирование короткого списка

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

Отобранные таким образом продукты попадают в короткий список, по которому будет производиться дальнейшая детальная оценка продуктов.

Детальный анализ и подсчёт баллов

Для проведения детального анализа продуктов формируется список критериев, по которым проводится сравнение продуктов.

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

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

• Коробочное решение (Out-of-the box) – требование выполняется.
• Требуется настройка (Configuration) – требование может быть выполнено в результате конфигурирования продукта и результат конфигурирования сохранится в ходе обновления продукта на более новые версии.
• Требуется разработка (Customization) – для выполнения требования программный продукт необходимо выполнять разработку программного кода, и возможно эти работы придётся повторить при каждом обновлении продукта на новую версию.

Естественным образом напрашивается ещё один пункт «Требование невыполнимо».

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

Отдельного внимания заслуживает оценка совокупной стоимости владения продуктом в перспективе N лет (обычно 1-3 года). Так, например, дешёвый продукт, может запросто наверстать своих более дорогих конкурентов за счёт постоянной необходимости привлечения вендора или его партнёров для выполнения доработок или настройки продукта. Обычно при оценке стоимости владения оценивается:

• стоимость приобретения;
• стоимость поддержки и сопровождения производителем (часто производители требуют обязательного приобретения поддержки, вместе с лицензиями на сам продукт);
• стоимость персонала в самой компании, который потребуется для поддержки и сопровождения продукта.

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

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

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

Ранжирование продуктов/выбор продукта

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

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

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

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