Когда ITIL не спасает

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

То ли я стал это больше замечать, то ли действительно повлиял коронакризис, но есть ощущение, что коллеги стали больше говорить об аутсорсинге различных ИТ сервисов. Вот и здесь, в “мыслях” ИТ-сообщества сразу несколько статей касающихся этого.

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

Ну и просто напомню, что как правило компетенции внешнего поставщика выше именно за счет того, что он специализируется на том сервисе, который предоставляет и аккумулирует опыт нескольких заказчиков. У нас недавно был случай, когда пенсионный фонд изменил способ начисления зарплаты для сотрудников с алиментами и потребовалось изменить шаблон экспорта в банк-клиент. Сотрудники банка прислали шаблон, и мы (наши подрядчики изменили выгрузку согласно новому шаблону). Но … новый файл не загрузился, поддержка банка сказала, что все выглядит правильно, и взяла 2 недели!!! на разбор проблемы. Мы не можем задерживать зарплату на две недели, а зеленому банку нет дела до наших проблем. Повезло что подрядчик делал подобные изменения не только для нас, но и для других своих клиентов. Они сравнили файлы между собой и нашли различия (в точке с запятой, которую раньше можно было ставить или не ставить, а в новом шаблоне она выдавала ошибку (без объяснения, конечно). Нашли бы мы её сами - не уверен, всегда ли сработает такой трюк — тоже не всегда конечно. Но случаи бывают, когда это помогает.

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

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

Все знают про ITIL. Из сборника лучших практик британской Axelos он превратился в стандарт де-факто по всему миру. В крупных компаниях изучение ITIL хотя бы в виде Foundation является обязательным для всех сотрудников IT департамента. Но поскольку ITIL впитал в себя все лучшее ото всех, то он все это благополучно “усреднил”, потому что одинаково у всех быть просто не может. Он содержит как базовые истины вроде “мойте руки перед едой”, “делайте бэкапы” и “записывайте обращения пользователей”, так и какие-то сильно абстрактные управление governance, ценностями и ожиданиями.

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

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

Для того чтобы правильно управлять сервисами в системе, где множество поставщиков предоставляют множество услуг, из которых эти сервисы состоят придумали методологию SIAM - Service Integration And Management. По-русски аббревиатуры нету, но перевод примерно понятен - управление и интеграция сервисов. Продвигает эту методологию, между прочим, тот самый Axelos, которому принадлежит ITIL. А торговая марка SIAM принадлежит компании EXIN, которая также развивает ITIL многие годы. То есть это не конкурирующие практики, а дополняющие друг друга. 

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

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

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

Я не являюсь евангелистом этой методологии и не считаю себя гуру ИT-менеджмента, но я вижу, что подходы SIAM работают в европейских компаниях, поэтому точно оно должно прийти и в Россию в ближайшие годы. Кстати, в марте 2020 вышла уже вторая версия методологии SIAM (первая вышла около 6 лет назад) значит он будет развиваться и дальше, так что пора начинать им интересоваться и строить взаимоотношения на принципах партнерства, сотрудничества и долговременной взаимовыгоды, и перенимать опыт тех, кто уже прошел этот путь.

 

Опубликовано 14.07.2020

Другие публикации эксперта