Главный компромисс ITSM

Трудна дорога от правды к истине.
Сергей Довлатов. Компромисс.

 

Любой проект – компромисс. Между желаниями и возможностями, планами и реальностью, сроками и охватом проекта. Иногда приходится идти и на более принципиальные компромиссы, чтобы достичь значимого результата за конечное время. Для ITSM такой принципиальный компромисс – исключение из области охвата управления уровнем ИТ-услуг вопросов разработки новой функциональности информационных систем.

С точки зрения классического ITSM это, конечно, тот еще трюк. Он не понятен заказчикам: «Как это вы опять не можете гарантировать мне время разработки? Зачем тогда мне SLA, ведь существующая функциональность и так работает, а гарантировать, что она будет работать лучше вы все равно не можете?». Он не очень понятен и самому поставщику ИТ-услуг, поскольку предполагает заключение SLA без соответствующей фазы проектирования (всех этих замечательных штук – SLR, SAC, …). Тем не менее, такой подход применяется на практике, и довольно широко.

Основная причина – объем и сложность организационных изменений, которые необходимо провести для реализации полноценного сервисного управления. В большинстве известных мне компаний ИТ-подразделение включает в себя две относительно автономные функции – разработку (Change the business) и сопровождение / эксплуатацию (Run the business). Они управляются разными людьми, по разным правилам, имеют разные точки входа для потребителей ИТ-услуг, взаимодействуют посредством управления изменениями и релизами (изменениями – со стороны «эксплуататоров», релизами – со стороны разработчиков), а также при устранении инцидентов и проблем. Разработчикам заказывают изменения в ПО, «эксплуататоры» обеспечивают целостность систем при развертывании разработок и максимальную доступность в ходе эксплуатации.

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

Буду честен – работая с крупным бизнесом, я знаю единицы компаний, которые идут по этому пути. Большинство идет на компромисс: Application lifecycle management (ALM) – для разработки, IT service management (ITSM) – для эксплуатации / сопровождения. Однако чем дальше, тем больше я думаю, что такой компромисс оправдан только если он используется в качестве временной меры, если ИТ-руководители стратегически нацелены на расширение сервисного подхода на разработку. Иначе управление уровнем ИТ-услуг заведомо принесет меньше пользы (чем написано в книжках) обеим сторонам – и ИТ-подразделению, и потребителям ИТ-услуг. И почему бы вообще в этом случае не отказаться от SLM, ограничившись реализацией оперативных процессов управления? Это соответствует уровню зрелости «Controlled» согласно модели «KPMG maturity phases model of the IT organisation», и может быть в данном случае это наиболее адекватная оценка? И может быть этого достаточно?

ITIL ITIL Intermediate: Service Offerings and Agreements

Учебный курс: проектирование и предоставление ИТ-услуг, SLA и SLM, экономика и финансы ИТ, управление поставщиками и подрядчиками — в ITIL и на практике.
 

Узнайте больше!

Комментарии и мнения

  1. Alexander Peshkov

    К сожалению, это прямо вот списано с реальности ИТ-организаци. Разработчики яростно упираются в ИТСМ-инициативу и всеми имеющимися силами ее соботируют (- мы не работаем по вашим процессам! — так их пока нет, мы и зовем вас их проектировать. — нет, у нас свои процессы!). Одна из причин — ИТСМ-драмма — видна невооруженным взглядом. Этакая "самодостаточность" шэфа разработчиков. Ну как же он будет потом шэфом, если позволит кому-то там диктовать ему правила работы его подразделения.

    К вопросу, Дмитрий. Мне кажется, что нет, не достаточно. Потому что, на практике, выход этого ALM — софт. Наваяли софт, вывалили (мягко говоря) его в эксплуатацию, а там оказывается, спроектирован ТОЛЬКО софт. Кто будет давать доступ — не подумали, куда будут звонить пользователи — не подумали, как будет поддерживаться — не подумали, каковы условия среды — не подумали. Прямо вот как "a must", из раза в раз одно и то же.

    1. Дмитрий Исайченко Автор

      Наваяли софт, вывалили (мягко говоря) его в эксплуатацию, а там оказывается, спроектирован ТОЛЬКО софт.

      Да, проблема понятна. Но ее можно решать другими средствами — стандартными требованиями к разработкам со стороны эксплуатации, включением эксплуатационных требований в BRD, ранним вовлечением эксплуатации в согласование требований и архитектуры, стандартизацией практики управления проектами по разработке ПО, определением порядка ввода в экслпуатацию с чеклистом готовности к эксплуатации (operation readiness). Сам по себе SLM конфликт с разработчиками не решит, увы.

  2. Andrey Kapustin

    С сожалением, полностью согласен с Александром.

    Работая на аутсорсе в IT Operations крупного мирового инвестиционного банка, констатирую картину описанную выше. При этом приятность ситуации в том, что помимо деления на CTB и RTB, каждый из стримов раздроблен княжества отдельных вендоров, которые имеют билет мнополистов, каждый в своей экспертизе, и не стремятся улучшать "сквозные услуги-процессы" ради Заказчика и его ценностей. Скорее склонны к выгодным действиям, классифицируемых как CSI, когда видят возможность откусить кусочек бюджета у конкурируещего вендора. Это конечно рынок, и сам Заказчик декларирует (почти формально), что именно так подстегивается конкуренция и появляются дополнительные выгоды для Бизнеса, но... Но... Как много же сил уходит на Vendor management в данном случае 🙂

    Возвращаясь к вопросу, моя позиция: в орг. среде, в котороживет мой проект и команда, искали 2-3 года, кто будет реальным IT Service Owner'ом. Пытались закрепить на этой роли аналитиков, но не прижилось. В виду высокой ответственности за результат, данная роль была де факто закреплена за функцией SL3, которая не является формально частью команды разработки, а выполняет только задачи связанные с IT RTB. Со временем данная функция получили де факто достаточные полномочия, чтобы привлекать "в любой момент любые IT ресурсы", чтобы качество сервиса сохранялось на согласованном уровне и в том числе улучшалось. В CAB представительства таки не получили, но влияние на CAB достигли приемлемого. С Бизнес RTB взаимодействие простроили... Такой вот пример частного, на моц взгляд позитивного опыта, который правда не был легким, потому что "поддержку сверху" пришлось зарабатывать, ее априори не было.

    Вообще же, склонен не согласиться с iTIL 2011, считаю что Service Owner'ом должен быть кто-то из Business RTB.

    1. Анатолий Павлюченко

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

      1. Alexander Peshkov

        Видимо, все же SLM, а не Change. Или, как он победоносно именован в ISO, New or changed Services. Потому как Change — технологичка, конвеер. На вход баран, на выходе — палка колбасы. Все проектирование прячется в New or changed Services.

    2. Дмитрий Исайченко Автор

      Вообще же, склонен не согласиться с iTIL 2011, считаю что Service Owner'ом должен быть кто-то из Business RTB.

      Я не думаю, что это альтернатива. Во внутрикорпоративном сценарии за ИТ-услугу важно зафиксировать ответственность с обеих сторон — и от заказчика, и от поставщика. На мой взгляд ответственный со стороны заказчика от Business RTB — ОК. Закрепление ответственного со стороны поставщика от IT RTB возможно, но опасно — блок RTB не заинтересован в изменениях, они отвечают за стабильность. Поэтому в компаниях в период трансформации, в поиске способов захвата рынка, в среде с выской конкуренцией такой подход может стать реальным тормозом в развитии бизнеса. А бизнес-аналитики просто потому, что они ближе всех к бизнес-прооцессу, лучше других его понимают и априори должны регулярно встречаться и разговаривать с заказчиком на одном языке. Бесспорно, у такого варианта есть и свои минусы.

      Пытались закрепить на этой роли аналитиков, но не прижилось

      Системных или бизнес-аналитиков? Почему не прижилось?

      1. Дмитрий Исайченко Автор

         

        Закрепление ответственного со стороны поставщика от IT RTB возможно, но опасно

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

         

      2. Andrey Kapustin

        Роль пытались закрепить за FA (Functional Analyst), которые находятся на стороне подрядчика 😉 FA хорошо были вовлечены в процесс изменений, но не обладали полнотой картины в RTB. Вообще же в процессе изменений им хватало столько рабоиы-рисков,  что думать о "стабильности Бизнеса в RTB" просто не оставалось возможности. Не последнее значение играло и то, что FA в рамках своей изначальной роли не имели ни веса ни полномочий, чтобы давать "свой ответ Чемберлену" на призывы( и жалобные крики ) Business RTB. (SL3 же призывам внял и построил под себя FA 😉 )

        Спасибо и за вопрос "почему не CTB BA?". Конструкция имеет следующую замысловатость: СТВ BA, не смотря на на то, что все они  работают в штате Заказчика, ответсвенность за Сервисы брать отказались. Дистанцировались на уровне формулировок: мы отвечаем только за формирование изменений, а как там работают в Бизнес RTB, нас интересует постольку-поскольку. У данной ситуации есть простое объяснение: крупный иностранный инвестиционный банк по уровне политизированности и количеству "разборок между группировками" ничем не отличается от Российских гос. Учреждений/монополий. Цели/задачи/лучшие начинания сверху успешно вязнут в инертном среднем звене и до исполнителей и подрядчиков доходят в донеузнаваемости искаженном виде ( страшно? 😉 ). У CTB BA такой руководитель, которому лишняя головная боль в виде ответственности за Сервис напрочь не нужна: ему за 50, 2 года назад родилась единственная дочь, надо выплачивать ипотеку за домик в Шотландии, и вообще он в Банке всего 3 года — тут уж не до иделистических подходов, надо двигать наверх не обременяясь лишними провалами. Гораздо проще держаться обще-лояльно-лениво-осваивающего-бюджеты мейнстрима. И ничего неприличного в этом нет, все так делают.

        Но я что-то сильно в строну ушел? Или Вам, Дмитрий, эта картина кажется нетипичной? ( ритоически )

         

        1. Дмитрий Исайченко Автор

          страшно? 

          О да 🙂

          Роль пытались закрепить за FA (Functional Analyst), которые находятся на стороне подрядчика

          Это вариант только если каталог сформирован от систем. Но в "крупном иностранном инвестиционном банке" я бы этой дорогой  не ходил — строил бы каталог от бизнес-процессов. С другой стороны, раз роль ответственных за сервис в итоге закрепилась на SL3, предполагаю, что каталог построен именно от систем?

          Или Вам, Дмитрий, эта картина кажется нетипичной?

          Едва ли 🙂 Но если вернуться к моим вопросам (и к пока не очень понятному мне Вашему согласию с Александром), скажите, пжл, зачем в данном случае вообще был нужен SLM? Какие задачи им решали? Кто был инициатором и где он был, когда "СТВ BA ... ответсвенность за Сервисы брать отказались"?

          1. Andrey Kapustin

            Это вариант только если каталог сформирован от систем. Но в "крупном иностранном инвестиционном банке" я бы этой дорогой  не ходил — строил бы каталог от бизнес-процессов. С другой стороны, раз роль ответственных за сервис в итоге закрепилась на SL3, предполагаю, что каталог построен именно от систем?

            "Каталог" (список сервисов) построен от Бизнес-процессов, хотя бы потому, что система одна, и список "от систем" состоял бы из одной строяки. В КИИБ ( крупном иностранном инвестиционном банке) организация проектной деятельности все-таки кореллирует с бизнес-процессами: одни и те же системы/компоненты (в разных группировках) формируют ИТ сервисы, которые встроены в разные Бизнес-процессы ( все как в той картинке из ITIL). Просто Управление портфелем сервисов в явном виде не выполняется со стороны Заказчика: во время разработки новых сервисов, успешно забывается, что есть сервисы разработанные 2-3 года назад, на качество работы которых новые изменения могут повлиять со всеми вытекающими... Да и Бизнес молодец: когда срочно надо отчитываться перед регулятором по новым методикам расчета рисков, то нарушение (в связи с новыми изменениями) в работе подразделений в Африке, или Австралии... и даже иногда Wall Street, перестают волновать начальство. Бизнес прибегает в мыле: меняйте ваши штуки ( они только в спокойном состоянии могут вспомнить, что это Сервисом зовется) , так чтоб мы сдали отчеты в срок!! ... А вот когда новая отчетность со скрипом таки собирается, то тут появляются ребята из Африки-Австралии-и т. д. со словами : у нас все поломалось.

            В описанной ситуации я не считаю процесс внесения изменений - ключевой с точки зрения генерации проблем. Change в данном случае является прямой прекцией Strategy, а точнее говоря - отсутствие внятного Strategy ( и органичного мапирования IT Strategy на Business Strategy ) приводит к орг. бардачку в Change и далее по цепочке.

            Что касается SL3: взятие на себя ответсвенности, было результатом осознанного интереса руководителя команды в ITSM подходе и просто ответвенного клиенто-ориентированного взгляда на ситуацию.

            зачем в данном случае вообще был нужен SLM? Какие задачи им решали? Кто был инициатором и где он был, когда "СТВ BA ... ответсвенность за Сервисы брать отказались"?

            SLM был нужен для систематизации деятельности подразделения. ITIL использовался как универсальный источник объяснения "мы так делаем, потому что так правильно и по стандарту", чтобы:

            — снизить хаотичные и противоречащие друг-другу запросы бизнеса как в RTB, так в последствии и в CTB

            — стабилизировать работу Operations, создать у сотрудников уверенность, что они выполняют "полезную работу" согласно разумному и управляемому регламенту

            — выйти во взаимоотношении с Заказчиком на новый уровень: аутсорсер продает не FTE, а Сервис; и собственно управляет Сервисами в Бизнес-Процессах Заказчика

            — можно еще навспоминать, если интересно — задавайте наводящие вопросы 😉

            1. Дмитрий Исайченко Автор

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

              Мне показалось, что роли SLM (ответственный за сервис от ИТ) распределены скорее не по функциональному принципу, а по персональному — в зависимости от наличия видения, личной заинтересованности и обязательности конкретного руководителя. Подтвержу — такое случается и нередко. Основной момент здесь, который, как мне кажется, требует внимания и контроля, — хорошее понимание SL3 структуры бизнес-процессов, знание текущих потребностей бизнеса и заинтересованность во внесении важных ему изменений. Иначе может возникнуть существенный перекос в сторону операционной стабильности, что в наше время в инвестиционных компаниях вряд ли на пользу. По крайней мере в РФ, не знаю про Африку и Австралию 🙂

              Уточните, пжл, а SL3 на стороне заказчика или подрядчика?

              1. Andrey Kapustin

                Мне очень симпатичен Ваш кейс 

                Спасибо! Живу в этом кейсе уже 4 года, 2 из них — управляю со стороны Подрядчика. Профессиональное признание — всегда приятная штука 🙂

                ...Иначе может возникнуть существенный перекос в сторону операционной стабильности...

                Перекос имеет место быть, и он сделан сознательно. В КИИБе приходится постоянно наблюдать вендоров ( "команды-однодневки") , которые промышляют сознательным перекосом в сторону Бизнеса, а по сути: обещают (ради бюджета) "несметные функциональные возможности для Бизнеса в очень короткие сроки". На мой взгляд с КИИБом маловероятно поступить так, как поступил Билл Гейтс с пользователями, выпустив на рынок сыроватую Windows 95: в КИИБе много чего видели и "система" пережила многих таких новаторов. Проверенный вендоры, дающие гарантированный результат по качеству-срокам таки пользуются заслуженным вниманием. ( компания, в которой работаю, входит в Top3 стратегических IT вендоров для данного КИИБ; и это при том что вендоров сотни по миру ).

                Данный вопрос баланса CTB-RTB в управлении Сервисами я не против обсудить, сам же как практик я больше на стороне RTB.

                Уточните, пжл, а SL3 на стороне заказчика или подрядчика?

                На стороне Подрядчика-аутсорсера.

                ... Конечно КИИБ никогда не признается, что за достаточно небольшие деньги позволил IT вендору из Восточной Европы понимать чуть больше чем положено в том, как зарабатываются деньги ( на самом деле мы это доподлинно и не знаем), однако... Против (арте)фактов не поспоришь: SL3 ведет Каталог услуг, формирует SLA, выступает с предлжениями CSI 🙂

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

                1. Дмитрий Исайченко Автор

                  Дмитрий, я уверен, что в ходе аудита моего проекта кем-либо из Вашей компании, будет найдена масса поводов пообсуждать, так ли хорош налаженный ITSM

                  Андрей, задавая вопросы, я ни в коем случае не собирался выискивать недостатки вашей реализации. Как я и писал выше, мне интересен Ваш кейс, и мною двигает именно профессиональный интерес. Более того, я по себе знаю, что добиться, чтобы организация стала работать по-другому, очень не просто. Тем более крупная, территориально-распределенная организация. Знаний для этого недостаточно, требуются дар убеждения, умение слушать и анализировать, синтезировать новые решения, перерабатывая прошлые знания и опыт с учетом локальной специфики, а также очень много энергии. Это как забивать гвоздь — надо сильно, точно и последовательно бить в одно и то же место, только тогда дело двигается. Так что Ваша профессиональная гордость мне очень понятна и "провинциальность" здесь не причем (тем более учитывая, о каком банке идет речь).

                  SL3 ведет Каталог услуг, формирует SLA, выступает с предлжениями CSI

                  Вот это действительно любопытно и специфично. Получается, что каталог ИТ-услуг сформирован от бизнес-процессов, при этом сервис-менеджеры — внешние люди из блока эксплуатации. Видимо такое возможно благодаря трем факторам: а) наличие заинтересованности руководства SL3, возможно в том числе коммерческой, б) хорошие горизонтальные связи SL3 с FA / разработчиками, которые также являются частью той же внешней компании и в) весьма плотное включение данной компании в обеспечение бизнес-процессов банка. Все верно?

                  1. Andrey Kapustin

                     Видимо такое возможно благодаря трем факторам: а) наличие заинтересованности руководства SL3, возможно в том числе коммерческой, б) хорошие горизонтальные связи SL3 с FA / разработчиками, которые также являются частью той же внешней компании и в) весьма плотное включение данной компании в обеспечение бизнес-процессов банка. Все верно?

                    а) верно

                    б) верно: FA сервис предоставляется тем же вендором что и SL3, территориально обе команды сидят рядом

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

                2. Дмитрий Исайченко Автор

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

                  1. Andrey Kapustin

                    Всеми ИТ-услугами банка не управляем. ... Ох как же мой директорат был бы счастлив получить такое предложение от КИИБа 🙂

                    Про управление ИТ-услугами в данном кейсе-контексте готов рассказать только про свой проект. С одной стороны не владею детальной информацией про КИИБ целиком (ну большой он очень), а с другой стороны не хочу выступать в роли "популяризатора-спамщика" (о компании в которой работаю можно почитать на www.luxoft.com ("Первыми в Европе среди IT-вендоров сертифицировались на CMMI-5" блин 🙂 )).

                    Сам КИИБ декларирует Сервисный подход в ИТ довольно давно, думаю лет 10 точно. Другое дело, как упоминал выше, что в каждом отдельном проекте/подразделении/вендоре Сервисность имеет разные оттенки зрелости. Не в последнюю очередь, существенное влияние в продвижение такой зрелости оказывает масштабность-стратегичность проекта и, конечно же, харизма находящихся у руля данных проектов людей. Про проект в котором участвую могу сказать: а) проект для КИИБа большой, ввиду значимости результата для взаимоотношений с регуляторами, проект имеет соотвествующий статус б) проектная команда со всех участвующих сторон достаточно сильная, понимание значимость ITSM подхода наличествует (потому на мой взгляд и случились имеющиеся результаты).

                    В целом, как упоминал выше, Vendor Management КИИБа работает с сотнями ИТ-вендоров (даже не с десятками) по миру, понятно правда что размеры их сильно разнятся. Формально владение Бизнес-процессами и ИТ-услугами в целом по КИИБу закреплено за Банком, вендоры (формально) допускаются максимум к роли управления. (С данным подходом полностью согласен, поскольку Ownership это по сути часть Governance в моем понимании. ) Однако, как это нередко бывает, в конкретных проектах, в силу конкретных обстоятельств, случаются "перекосы", когда вендоры успешно перенимают (иногда даже существенную) часть обязанностей Owner`а (как IT-сервисов так и IT-процессов). КИИБ за такими случаями присматривает, но как правило палок в колеса не ставит, поскольку на аутсорс никогда не отдает что-нибудь существенно связанное с коммерческой тайной, рыночным преимуществом и т.д. (например, доподлинно знаю, что КИИБ никогда(!) не отдаст на аутсорс модули расчета рисков по сделкам и содержащиеся в них оригинальные мат. модели; данный функционал всегда будет разрабатываться внутренним подразделением, аутсорсеры будут осведомлены только об интерфейсах доступа и не более). И еще сам КИИБ отчасти заинтересован в подобных "проактивных инициативах" вендоров: формально декларируется последние 3-4 года самим КИИБа, что от вендоров ожидается не просто выполнение контрактов, но и активное участие в ревью и улучшении (инновациях) Сервисов&Процессов, в которые вендор оказывается включен. На мой взгляд политически КИИБ прав: он поощеряет вендоров, демонстрирующих клиентоориентированность ("Находите и предлагайте как улучшить Нашу работу, и Мы дадим Вам новую работу-контракты").

                    Как-то так.

        1. Дмитрий Исайченко Автор

          IDDQD — это не аббревиатура 🙂 А вот с МБПВВ реальная история была в институте. Один гражданин записывал за быстро читающим лекции преподавателем и довольно часто в конспектах использовал эту аббревиатуру. Потом на сессии ломал голову (несколько дней), пока не вспомнил, что это значит "Может быть представлена в виде" 🙂

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

ИЮН
26