ITSM живет с нами уже 30 лет. За это время многое изменилось: технологии, версии ITIL, бюджеты на реализацию. Что осталось неизменным — так это завышенные ожидания, которые часто идут вразрез с реальностью.

Напомню, что ITSM (Information Technology Service Management, Управление ИТ-услугами) — это подход к управлению ИТ-деятельностью, который рассматривает ИТ-ресурсы как услуги, предоставляемые бизнесу для достижения его целей.

Сегодня я хотел обсудить самые распространенные «мифы», которые громогласно и красиво рассказывают со сцен отраслевых мероприятий и на вебинарах признанные специалисты, консультанты, продавцы, эксперты в области ITSM, и то, как потом эти «мифы» разбиваются о скалы суровой реальности.

Disclaimer: мнение автора основывается исключительно на личных наблюдениях и может отличаться от мнения читателей.

Миф № 1: Я легко пройду сквозь бюрократию и быстро внедрю сервисный подход! Ведь это же прогресс и инновации, за этим будущее!

Реальность: нет, это будет долго и больно.

Бюрократия (ну а как же без неё?) может ставить палки в колёса абсолютно на всех уровнях и этапах внедрения ITSM-проектов. Ну, допустим, мы это и так знали, но тут важно понимать разницу между бюрократией обыкновенной и сопротивлением изменениям в организации со стороны её работников.

Чем старше и больше компания, тем больше кругов ада вам придётся пройти: от стандартных согласований до слёзных убеждений (а иногда и шантажа).

Можно даже вывести какой-нибудь простенький индекс адаптируемости и внедряемости инноваций в организациях. Что-то вроде:

Где:

• ИСИ – Индекс сопротивления инновациям;

• Вк – Возраст компании;

• СВс – Средний возраст сотрудника;

• УИН – Уровень инновационности нововведения, индикативно оцененного от 1 до 10, где 1 – вообще не инновационно, а 10 – супермегаинновационно.

Чем выше индекс сопротивления, тем сложнее будет «продать» компании идею нового сервисного подхода (да и любого другого).

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

• Она монетизирована;

• Она служит для размытия ответственности (и подстилания соломы);

• Она обоснована законом или социально значимыми причинами.

Существуют целые региональные единицы, целью которых служит создание отчетности, выполнение штатных операций. Цель этих документов и операций может стремиться к нулю, но ее нужно делать для соблюдения законодательства, выполнения регуляторных требований, или иных причин. Все они сводятся к тому, что «так надо». И сложность в том, что нельзя просто в одночасье взять и отказаться от выполнения этих операций. Да, можно отменить или внести корректировки в законы, но что делать с высвободившейся в одночасье рабочей силой в тысячи, а то и десятки тысяч людей, которым нужно получать зарплату, содержать семьи, выплачивать ипотеки, обеспечивать экономику регионов притоком свежих денег? Такая ситуация, кстати, актуальна для всего мира.

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

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

Миф №2: Внедрим все процессы ITIL — получим полную понятную картину стоимости и ценности ИТ-услуг.

Реальность: 9 из 10 проектов внедрения ITSM ограничатся 4-5 процессами, и на этом все.

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

Или еще более абсурдный сценарий: объединить процессы управления инцидентами, запросами на обслуживание, благодарностями, жалобами, еще чем-нибудь в один макропроцесс, скажем, управление «обращениями», после чего гордо заявлять, что внедрено 5-6-7 процессов, описанных в ITIL.

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

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

Миф № 3: Сервисный подход — уникальная методология, которая может быть адаптирована для организаций любого масштаба.

Реальность: вы можете сломать то, что до вас уже прекрасно работало.

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

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

Иногда к спорам и разногласиям подключается еще и консультант/вендор, который в лучшем случае просто со всем соглашается, а в худшем — начинает проповедовать что-то своё. Однажды я общался лично со Стюартом Рэнсом (Stuart Rance), тогда еще он работал в HP. Я задал вопрос: «дескать, а как же противостоять методологическим разногласиям, на которые натыкаются ITSM-проекты в крупных организациях». Стюарт ответил: «Никак! Просто нужно заставить делать всех так, как говорит консультант. Он тут для этого и присутствует».

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

Так что сервисный подход — это не про универсальное решение или уникальную единую стандартную методологию. Сервисный подход — это про набор рекомендаций и лучших практик, которые в ряде случаев можно изменить до неузнаваемости. Возможно, их даже и нужно менять под потребности одной отдельно взятой крупной компании. Но другое дело, когда внутри организации таких попыток может быть 2,3, 10 и более одновременно. И каждый адаптирует методологию по-своему и под себя.

Миф № 4: Сервисному подходу можно легко обучиться на курсах, мастер-классах или в ВУЗе.

Реальность: на курсах учат не ITSM-у, а сдавать экзамен по ITSM.

Можно провести хорошую аналогию с автошколами: там учат ПДД, ездить на машине по площадке, парковаться задом, ездить по простеньким маршрутам в городе с минимальным количеством знаков и рассказывают, как будет происходить экзамен в ГИБДД. Показателем успешности автошколы будет количество успешных сдач на права.

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

То же самое и со специалистами в ITSM! Человек, даже с опытом работы в ИТ, впервые сдав экзамен и познакомившись с полным циклом процессов ITIL, далеко не сразу станет высококвалифицированным специалистом. Нужен опыт. Нужно участие в проектах (лучше в разных) в разных компаниях. Только тогда сформируется тот «водительский» опыт, знание негласных правил и подводных камней.

Даже в тех ВУЗах, где сервисный подход преподается серьезно, студентам он непонятен — нет опыта и практики.

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

Не всегда достаточно обучить сотрудника/студента ITIL, важно — просветить и побудить «встать на путь истинный».

У нас нет ВУЗов, которые готовят студентов именно по специальности ITSM. ITSM, как правило, отдельный, или вообще специальный (то есть не всегда обязательный) курс в рамках других специальностей. Так, будущие ИТ-аналитики, разработчики, менеджеры и другие специалисты лишь поверхностно и без погружения затрагивают ITSM в программах обучения.

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

И что же теперь, не внедрять ITSM?

Здесь важно решить для себя самостоятельно. Могу лишь посоветовать ответить на два ключевых вопроса:

1. Надо ли оно вам вообще в целом? (я про внедрение ITSM-проектов)

2. Готовы ли вы к тому, что каждая из мифических «плюшек» сервисного подхода может рассыпаться в труху?

Пишите комментарии и задавайте вопросы. Возможно, у вас есть свои мифы и реальность.