Миграция с HP OpenView Service Desk

Краткое практическое руководство

За последние семь лет наиболее популярным инструментом автоматизации процессов управления ИТ-услугами в России стала система HP OpenView Service Desk. Для большинства компаний внедрение этого продукта было связано с построением первого в их жизни процесса - управления инцидентами, организацией службы Service Desk. С тех пор многие организации развивали свою систему управления ИТ, появлялись новые процессы, а с ними - новые требования к их автоматизации. Зачастую развитие процессов тормозилось ограничениями системы автоматизации.

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

Предпосылки к миграции

Одной из основных причин, по которым ИТ-руководители начинают думать о переходе на другую систему автоматизации, является риск снятия компанией Hewlett Packard продукта HP OpenView Service Desk 4.5 с поддержки. Компания-производитель об этом уже не раз заявляла, при этом дата прекращения поддержки несколько раз переносилась, но рано или поздно поддержка будет прекращена. При этом, скорее всего, команды разработчиков, обеспечивавших развитие системы, будут перенаправлены на новые продукты, такие как HP Service Manager, что может сказаться на качестве поддержки. Полное прекращение поддержки означает не только прекращение решения проблем, возникающих в ходе эксплуатации продукта, но и прекращение выпуска обновлений, реализующих новый функционал, запрашиваемый потребителями этого продукта.

Кроме того, компании, развивающие действующие процессы управления ИТ-услугами и строящие новые процессы, сталкиваются с ограниченностью возможностей продукта, расширение которых требует больших вложений (трудозатрат, денег). Так, например, для процесса управления конфигурациями может не хватать визуализации CMDB, для процесса управления изменениями может потребоваться более гибкий механизм согласования, и так далее. При этом автоматизация процессов, изначально не предусмотренных в системе производителем (например, процесса управления мощностями), практически невозможна. По мере эксплуатации продукта он обрастает различными внешними доработками (скрипты, внешняя бизнес-логика с применением "data update from external system", внешние приложения на базе WebAPI), реализующими недостающую логику, что не добавляет продукту стабильности и повышает затраты на его поддержку.

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

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

Многие современные продукты более гибки, что позволяет в большей степени подстраивать продукт под процессы, а не наоборот. Кроме того, предлагаемые «коробочные» конфигурации современных продуктов более развиты, чем HP OpenView Service Desk 4.5. и позволяют автоматизировать больший набор процессов и получить больше возможностей в существующих процессах (например, базу знаний, которая в HP OpenView Service Desk практически не реализована).

Что такое миграция?

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

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

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

1. определение подхода к миграции
2. выбор программного продукта и стратегии миграции
3. выбор исполнителя
4. корректировка процессов и документации
5. разработка конфигурации продукта
6. планирование перехода на новую систему
7. обучение специалистов скорректированным процессам и работе с новой системой
8. перенос системы в продуктивную среду
9. разработка плана дальнейших мероприятий по освоению новых возможностей продукта (например, внедрению процессов, для которых раньше не было средства автоматизации)

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

1. Определение подхода к миграции

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

Переход на новый продукт не всегда заключается в простом повторении возможностей автоматизации старого продукта. В большинстве случаев, в компании накопился список «претензий» к старому продукту (что-то неудобно, что-то хотелось бы добавить; например, в HP OpenView Service Desk 4.5 невозможно организовать цепочки Workorder в привязке к Service Call, а для автоматизации обработки стандартных запросов на обслуживание это было бы очень удобно), поэтому миграция может включать в себя устранение ряда существенных недостатков, которые мешают нормальной работе. Кроме того, определяя требования, следует учитывать и дальнейшие планы развития системы, таких как автоматизация смежных видов деятельности (например, контроль выполнения регламентных работ с оборудованием), автоматизация новых процессов (например, управление релизами, знаниями), перенос функционала с разрозненных систем в единую (например, автоматизация в той же системе процесса учета активов).

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

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

2. Выбор программного продукта

Подход к миграции определяет подход к формированию требований к продукту. На практике требования к продукту строятся с учётом информации:

• о существующих на рынке системах, их классах; на что можно смотреть и что точно смотреть не нужно (см. статью «Выбираем продукт для автоматизации ITSM-процессов»)
• о текущем уровне автоматизации (новая система должна быть не хуже). При этом следует учитывать не только базовые возможности продукта, с которого вы переходите (например, HP OpenView Service Desk), но и весь объём настроек и доработок, интеграций, которые выполнены до текущего момента. Иногда бывает немаловажно оценить и практику применения продукта в организации, так как часто объекты, заложенные вендором в систему в одном качестве, используются в организации совершенно иначе. Например, в моей практике объект Project в HP OpenView Service Desk использовался несколькими способами: для группировки запросов на изменения и для группировки заданий на формирование документации в ходе создания ИТ-сервиса в рамках процесса SLM
• о текущих сложностях в автоматизации (новая система, по возможности, не должна содержать тех проблем, которые присущи существующей системе автоматизации). Лучше всего о сложностях расскажут сами участники процессов, так как исполнители разных ролей процессов по-разному используют продукт. Например, специалисты 1-й линии поддержки скажут, что их не устраивает невозможность применения шаблонов к уже сохраненным объектам, специалисты 2-й линии скажут, что не хватает механизма применения типовых решений и так далее. В зависимости от процессов таких сложностей может набраться довольно много, и важно выделить основные и учесть их при формировании требований к продукту, понимая, каковы последствия невнимательного к ним отношения
• о планируемом развитии автоматизации процессов и смежных видов деятельности. Новая система не должна препятствовать выполнению планов. Если в ваших планах фигурируют процессы, то желательно, чтобы продукт мог их автоматизировать «из коробки», либо мог быть настроен для их автоматизации. При этом следует учитывать, что практически любой вендор про свой продукт скажет, что любой процесс можно автоматизировать с его помощью - если не из коробки, так «простым конфигурированием». Важно только не забывать о трудозатратах на «простое конфигурирование» и стоимости/качестве поддержки такого решения
• об архитектуре существующей системы автоматизации. Новый продукт может предъявлять иные требования к серверам, каналам связи, СУБД и так далее. Необходимо оценить текущие и будущие требования и готовность менять инфраструктуру под требования продукта
• об уровне нагрузки на существующую систему автоматизации (количество одновременных подключений, количество объектов, регистрируемых в системе в день, объём CMDB, ...), сейчас и в планах. Подобная статистика позволит оценить возможность работы продукта с требуемыми объемами информации и необходимость модернизации ресурсов. В ряде случаев может быть полезно нагрузочное тестирование
• о доступных ресурсах на поддержку и сопровождение системы автоматизации. Без качественной поддержки и сопровождения продукта работа процессов подвергается серьёзному риску, особенно в первое время, пока специалисты компании только знакомятся с продуктом, и неизбежно возникающие вопросы и ошибки приводят к замедлению или остановке работы процессов
• о технологии обновления продукта. Некоторые вендоры регулярно выпускают пакеты обновлений для своих продуктов, либо новые версии продуктов. Однако не все продукты одинаково легко переносят обновление. В ряде случаев обновление может привести к необходимости повторной миграции со старой версии на новую
• о наличии инсталляций. Многие вендоры с удовольствием отведут вас к своим клиентам и покажут, как работает их система в реальной жизни. Подготовленные заранее вопросы по интересующим областям позволят более результативно провести встречу, иначе есть риск увидеть продукт только с той стороны, про которую выгодно рассказывать вендорам, так и не затронув узкие места продукта.

3. Выбор исполнителя

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

• сроки выполнения проекта
• соответствие того, что вы получите в итоге, требованиям
• рациональность внедряемого решения

Наличие в штате компании-исполнителя специалистов, не только сертифицированных вендором, но и выполнивших ряд проектов схожей тематики, снижает риски того, что на вашем проекте будут учиться, и значит будут закладывать бОльшие сроки и деньги на реализацию проекта, либо того, что сроки проекта будут нарушены. При этом следует учитывать, что при выполнении миграции необходимо как знание HP OpenView Service Desk, так и того продукта, на который осуществляется миграция. Хороший способ познакомиться с исполнителями - попросить их продемонстрировать продукт, возможно, выполнить небольшое задание по автоматизации процесса.

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

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

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

Вариант 1. Приоритет - сохранению и постепенному развитию текущих процессов и практик управления

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

Преимущества:

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

Недостатки:

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

Вариант 2. Приоритет - минимизации доработок продукта при переходе на новый продукт

В этом случае выбираются продукты, обладающие как можно более мощным функционалом «из коробки» (например, BMC Remedy ITSM Suite). Существующие процессы перестраиваются под логику продукта, продукт настраивается там, где это необходимо.

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

Преимущества:

• возможность использования готового решения, работающего у многих клиентов, проверенного временем
• некоторые производители предлагают вместе со своим решением готовые процессы, автоматизируемые их программным продуктом

Недостатки:

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

Примечание. Прекращая продажу и поддержку HP OpenView Service Desk, компания HP активно продвигает на рынке свое новое решение, HP Service Manager. Казалось бы, именно оно должно рассматриваться как основное направление миграции «первого типа» - с максимальным сохранением имеющейся практики. Однако, как ни удивительно, именно Service Manager - один из тех продуктов, выбор которого практически не оставляет для заказчика такой возможности. HP настойчиво рекомендует миграцию «второго типа» - подстройку ваших процессов под типовую модель организации и автоматизации деятельности, заложенную в продукт. См. статью «Выбираем продукт для автоматизации ITSM-процессов»

4. Корректировка процессов и документации

Если выбранный продукт не позволяет в точности повторить возможности и вашу текущую конфигурацию HP OpenView Service Desk, или если вы наконец-то получите долгожданные возможности, отсутствовавшие в HP OpenView Service Desk, то придется подстраивать процессы под особенности нового продукта. Корректировка процессов может быть незначительной, а может и привести к необходимости перепроектирования процессов, обучения участников процессов новым правилам работы, корректировке процессной документации. Например, некоторые продукты очень болезненно относятся к изменению набора статусов объектов, заложенных производителем, так как на них завязана существенная часть бизнес-логики системы. При переходе на такой продукт придется менять свои процессы таким образом, чтобы процедуры выполнялись в соответствии с заложенной производителем логикой.

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

5. Разработка конфигурации продукта

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

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

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

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

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

6. Планирование перехода на новую систему

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

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

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

7. Обучение специалистов

Обучение делится две части: обучение администраторов системы автоматизации и обучение участников процессов. Объём обучения зависит от выбранного подхода и средства автоматизации. Если выбран путь максимального сохранения существующих процессов, и продукт настроен максимально близко к HP OpenView Service Desk, то обучение участников процессов сведется к изучению небольшого количества отличий и нововведений, в основном - изменений интерфейса. В том случае, если процессы серьёзно перерабатывались, придется затратить много времени на обучение специалистов и работе в новых процессах, и использованию нового средства автоматизации.

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

8. Перенос системы в продуктивную среду

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

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

Кроме того, переключение на новую систему означает перенастройку интеграции с внешними системами, например - перенаправление потоков электронной почты.

Дорогу осилит идущий

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

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