ITSM-платформы: гибкость бизнес-процессов

2 апреля 2020

Для того, чтобы выбрать для вашего предприятия ITSM-платформу, необходимо иметь ввиду один фактор: это решение должно быть максимально гибким. Если оно таковым является, надо привести в порядок собственные бизнес-процессы и кастомизировать систему.

Cегодня на рынке предоставлено немалое количество платформ, скажем так, для автоматизации по стандартам Cobit/ITIL/ITSM. Это как проприетарное программное обеспечение, например, HP Service Manager, ServiceNow, так и ПО с открытым исходным кодом, например, OTRS. Вопросы построения и автоматизации служб технической поддержки стали настолько актуальны, что простые системы для отслеживания тикетов, применявшиеся когда-то в процессах разработки ПО, попытались занять свободные места на этом практически бескрайнем поле. Тому пример Atlassian с продуктом JIRA и надстройкой Service Desk. Причина легкости их входа на рынок проста: если у тебя есть описания процессов и инструментарий бэкэнда для их реализации в автоматизированной системе, то поставить клиенту решение становится работой бизнес-аналитика и инженера — зачастую даже без глубоких знаний внутреннего устройства системы.

Казалось бы, при чем тут анализ процессов? Развитие внутренних процессов во многих крупных международных компаниях шло параллельно с развитием всем известных библиотек документов, напрмер, с Cobit, ITIL/ITSM и пр. Процессы, описанные в них, достаточно сложны для полноценной реализации, какие-то элементы не требуются в силу специфики бизнеса, отказ от других этапов и компонентов принят риск-менеджментом. В то же время добавлены новые специфичные, сложившиеся годами, процессы. За кулисами конференций опытные специалисты-консультанты говорят: «Если построить все процессы в строгом соответствии с этими стандартами техподдержки, вся компания будет работать только лишь на ИТ».

Подобные реалии жизни ставят производителей ITSM-платформ перед необходимостью делать свои решения максимально гибкими, чтобы в результате заказчику была поставлена автоматизированная система управления бизнес-процессами с более или менее базовым функционалом управления технической поддержкой: «Мы вам тут джип продали с сабвуфером и 16 динамиками, но если что, задний ряд снимается и влезает паллета с полтонной груза, а вот там шноркель — можно купить и рыбок рассматривать в соседнем пруду». Подобную адаптацию JIRA для процессов найма сотрудников я наблюдал в российском ИТ-офисе международной компании, где HR-департаменту потребовалось лишь описать процесс, рассказать, как они и что делают.

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

Неплохой пример был в 2013 году в OTRS с CMDB: в базе своей она шла с минимальным набором классов а ля «сервер», «сетевое устройство» и инструкцией «вот примеры, вот словарь, на их базе можете описать, как вы учитываете свое оборудование, софт, IP адреса»…

В общем, вопрос выбора ITSM-системы для управления теми или иными процессами на предприятии сводится к примерно следующим этапам:

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

Небольшим бонусом в выборе станет возможность вендора/поставщика реализовать решение “As a Service”, в облаке, иногда даже предоставив закрытый канал доступа (VPN) к уже готовому решению, разгрузив таким образом центральный бизнес-дата-центр межрегиональной компании.

Читать еще:

4021