О пользе Due Diligence для ИТ-аутсорсинга

Прилично удивился, столкнувшись с этапом Due Diligence в конкурсной документации на аутсорсинг ИТ-сервисов. Неожиданности в конкурсных процедурах всегда вызывают определённый напряг, так как они могут означать, что придётся быстро пересобрать привычную сервисно-процессную конструкцию, а это сродни тому, как ребёнку сложить гигантский пазл из мелких и трудноразличимых деталей. Раньше мне всегда казалось, что процедура Due Diligence применяется при оценке стоимости компании перед её покупкой или в рамках «айпиошного» проекта. По сути – это оценка надёжности и коммерческой привлекательности будущей сделки. Ну и выглядеть это должно было так: приходят в компанию умные консультанты-аналитики, ворошат годовую отчётность, проверяют прогнозы, оценивают риски и выносят свой вердикт. Мы, как аутсорсинговый партнёр, прошли-таки эту процедуру, правда, не при оценке компании, а в рамках конкурсной процедуры ИТ-тендера. Это был скорее технический Due Diligence.

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

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

Как аудитор оценивает уровень зрелости сервисных процессов:

1. Смотрит в расчетные таблицы и делает предварительный вывод, по какой из моделей – ресурсной или ресурсно-сервисной – выстраивает процессы обслуживания подрядчик.
2. Просит продемонстрировать шаблоныTASK в системе Trouble Tickets: какие в них используются теги.
3. Выясняет, как осуществляется маршрутизация запросов между различными направлениями и исполнителями; какие консоли использует для операционной деятельности служба поддержки; как квотируется время реакции и время разрешения запросов.
4. Спрашивает, как выглядит план восстановления после аварий.
5. Просит показать отчетность по KPI для 1-й и 2-й линий поддержки и т.д.

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

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

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

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

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

Стало ясно, что нужно создавать единое понятийное поле для обеих сторон. В сложных случаях стопроцентного маппирования услуги на требования добиться не всегда возможно, и тогда встает вопрос о Сервисном каталоге, когда стороны на этапах переговорного процесса могут скомпоновать сбалансированную по затратам матрицу оказания услуг. В частности, мы столкнулись с тем, что нам надо было разнести и сгруппировать ресурсы-затраты в виде блоков: Infrastructure Management, Service Delivery Management, Service Support Management и Asset Management.

Еще лингвистический нюанс: используемая нами система регистрации обращений и внутреннего квотирования времени реакции/выполнения настроена на работу с тремя уровнями срочности входящих обращений – «Очень срочно», «Срочно» и «Некритично». А клиент хотел бы расширить правила обработки за счёт еще одного, четвертого класса срочности, а также учитывать 4-х уровневую матрицу с показателями степени влияния инцидентов на системы.

Мы заявляем: «настраиваем «модель здоровья» для конфигурационных элементов и сервисов. Используемая Relationships model, построенная на основании данных CMDB, позволяет отслеживать влияние на бизнес-сервисы планируемых изменений или возникающих инцидентов».Looks great. Но что может получиться? Пытаемся формулировать одно из условий выполнения SLA:«Максимальная скорость поступления web-запросов не менее….». На практике, оказывается, нужно было договориться о проценте запросов со временем обработки менее 1сек. и отдельно оговорить условие с включением/выключением в момент замеров этого показателя процессинга. Вроде все слова знакомые, но общий лексикон выстраивается постепенно.

Идем дальше. Будущий заказчик спрашивает документ уровня Operational Objectives, который пояснит определения базовых сервисных понятий (Service BaseLine) и затем станет частью Service Level Agreement. В частности, это удобный момент определить, что есть базовый мониторинг (представить «модели здоровья»), и, как вариант, описать, какие действия предпринимаются 1-ой или 2-ой линиями поддержки в случае тех или иных событий со стороны системы мониторинга, как проходит процесс эскалации. Здесь же вопросы: каким опытом обладает Сервис-менеджер, какого уровня детализации готовится Service Improvement Plan.

Собственно, возвращаясь к заглавию: а в чём всё-таки была польза для нас? Прежде всего, можно с помощью внешнего беспристрастного взгляда заметить на своих привычных сервисных «пейзажах» размытые контуры и аврально кинуться их поправлять. Я бы отнёс вышеописанный подход к Outsource best practice, так как мы получили срез оценки своей готовности к несколько иной модели оказания услуг, а планка заданных требований явно указывала на профессиональную продвинутость людей, которые их готовили. В качестве ещё одного довода могу добавить, что пришлось задуматься о внедрении настраиваемого инструментария моделирования и управления собственными затратами, потому что «толкаться» в ценовом конкурсе без такой модели проблематично.

P.S. В конце концов, Due Diligence был взаимный, и «дырки» в процессах были видны не только у нас, но и у второй стороны….

Автор: jetinfosystems

Источник ^[1]