Портал №1 по управлению цифровыми
и информационными технологиями

Дом для услуги

CityЕсли мы будем говорить о предоставлении услуг в целом, то никто не будет спорить с тем, что услуга – это непрерывно изменяющийся объект управления. С течением времени функциональные и эксплуатационные требования к услуге претерпевают изменения. Это естественно: мир вокруг нас непрерывно движется и бурлит своим многообразием. Потребители услуг предъявляют к услугам требования, которые позволяют им извлечь наибольшую для себя выгоду или ценность в настоящий момент. Они же отказываются от услуги, когда она уже не может эту ценность предоставить.

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

Льюис Кэррол:

" – У нас, – сказала Алиса, с трудом переводя дух, – когда долго бежишь со всех ног, непременно попадешь в другое место.

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

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

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

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

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

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

 

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

Cheshire2

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

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

 

IT Service Management
Учебные курсы от соавторов ITIL 4

Комментариев: 7

  • Внутренний поставщик ИТ-услуг, пользуясь своим монопольным положением, изолированностью от рыночных отношений, обычно не спешит "бежать со всех ног". Куда тут до "счастливых потребителей". Партнёрскими отношениями с заказчиками (видимо, всё-таки с заказчиками, а не пользователями) здесь не пахнет, тем более пониманием "нужд пользователей". "Мы работу работаем, нам глупостями заниматься некогда" – таков обычно девиз.

    А вот для успешного внешнего поставщика, даже так – лидера – да, согласен, такое поведение характерно.

    • Андрей Яковлев

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

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

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

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

    • Андрей Яковлев

      Андрей, Вы много реальному бизнесу, не имеющему не контролируемых средств это сумели объяснить? Хоть у него ОКВЭД 72?

      • Именно “объяснить” – нет. Говорить об этом – да. Для того, чтобы это было, нужно чтобы руководство огранизации могло и хотело ставить своему ИТ такие задачи. Род деятельности организации может быть совсем не влиять, у нас сейчас сильно зависимы от ИТ: финансы, конкурентный ритейл, сфера услуг. Это кроме самого ИТ рынка, разумеется.

        • Андрей Яковлев

          Добавлю сразу к обеим комментариям. OLA как и SLA предполагает наличие согласованного уровня сервиса, одни платят, другие делают. Внешний SLA довольно четко прописывает вычеты и премии исполнителю. SQI=100% без вопросов +/- по договоренности. Такая же система должна быть и OLA в этом месте они не отличаются. То есть система премирования должна зависеть от показателей.  Вот тут и начинается. Менеджмент должен четко понимать, за что будет платить, а свой сотрудник другое дело, может и лицо у него не такое. Потом это не безликий в общем исполнитель.

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

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


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
;