Представляю Вашему вниманию еще одну статью Стюарта Рейнса. В этот раз он делится своим опытом, как успешно заключать Соглашения об Уровне Обслуживания (Service Level Agreement, SLA). Оригинал см. «How to Meet Customer Expectations» опубликован 13.12.2016 в блоге blog.sysaid.com
Сложность материала — начальный уровень.
Материал может быть интересен для осознания подхода, проповедуемого ITSM к работе с Заказчиками и Пользователями, а также может нанести не поправимую пользу тем, кто только ознакомился с теорией процесса Управления Уровнем Обслуживания и желает ее применить на практике, либо тем кто безуспешно пытался это сделать и сейчас ищет что-то новый в этом.
Но опять призываю Вас быть аккуратными в своих выводах. Описанное в статье это идеальная ситуация, когда и Поставщик, и Заказчик Услуг искренне заинтересованы в сотрудничестве ради ценности Услуги. На практике такое встречается, скажем так, не всегда, при чем с обеих сторон.
Здесь и далее курсивом обозначены примечания переводчика
Ожидания от Service Desk
Одна из самых больших проблем, которые мы встречаем в Управлении ИТ Услугами, — это невыполнение ожиданий наших заказчиков и пользователей. Не важно насколько хороша сама Услуга и не важно, как хорошо мы ее поддерживаем, важно, что когда мы не оправдывает ожидания людей, они чувствуют себя несчастным.
Я работал с многими ИТ организациями, которые регулярно не соответствовали ожиданиям, и которые не принимали свою ответственность за это. И у них всегда было оправдание этого, например:
- “Их ожидания не разумные”
- “Мы вынуждены так делать, потому что Бизнес не дает нам ресурсы”
- “Мы предоставили то, на что пользователь имеет право на основании Соглашения об Уровне Обслуживания (Service Level Agreement, SLA)”
- “Мы не подняли приоритет, потому что пользователь не сказал, что этот важно”
- “Мы не можем внедрить новый функционал так быстро, как Вы хотите, так как мы уже сильно загружены аналогичными задачами”
- “Мы не можем сделать это изменение, ведь оно так рискованно. Они смогут подождать”
Возможно, Вы слышали такие вещи в своей организации или даже сами произносили что-то из перечисленного. В таком случае, может быть, сейчас самое время для некоторых серьезных изменений. Если Вы хотите предоставлять отличные Услуги своим пользователям и заказчикам, объясните почему Вы не можете это делать достаточно хорошо. Вот, зачем наиболее эффективные ИТ организации берут на себя ответственность за управление ожиданиями заказчика. И, конечно же, это легко сказать, но не легко сделать. В этой статье собраны мои предложения, как это сделать.
Если Вы хотите прокачать способность вашей организации надежно достигать ожидания, тогда Вам необходимо выполнять четыре пункта:
- Понимать, что заказчики и пользователи ожидают
- Объединять “Что может быть сделано” с “Попытаться влиять на ожидания”
- Управлять Услугами для предоставления того, что ждут заказчики и пользователи
- Отчитываться о ваших достижениях, чтобы быть уверенным, что заказчики и пользователи знают, что Вы им предоставили
Все четыре пункта одинаково важны и Вы можете удовлетворить ожидания Ваших заказчиков только если уделите внимание им всем.
В оставшейся части статьи, я буду рассматривать эти моменты в подробностях. Но сначала я начну с донесения мысли о одном важном отличии (см. Пользователь и Заказчики — Кто скрывается за этими словами?). ITIL различает заказчика (кто ведет переговоры, согласовывает условия и платит за услугу) и пользователя (кто фактически пользуется услугой). Если Вы не слишком хорошо знакомы с этим различием, представьте магазин игрушек. Родители платят за игрушки, но используют их дети. Когда я говорю об ожиданиях заказчика я имею в виду ожидания обеих этих групп. Ошибочно рассматривать только нужды и ожидания пользователей, так как они не совпадают с ожиданиями заказчика, а это именно он платит за Услугу.
Понимать, что заказчики и пользователи ожидают
Если вы хотите понять ожидания Ваших заказчиков и пользователей, то вам необходимо разговаривать с ними. И Вы должны делать это на регулярной основе, потому что потребности со временем меняются и ожидания вместе с ними.
Многие ИТ организации полагаются на Соглашения об Уровне Обслуживания (SLA), говорящие им о нуждах заказчиков и пользователей. К сожалению, эти соглашения могут быть согласованы месяцы и даже годы назад, а в некоторых случаях даже написаны самой ИТ организацией в большей части, чем заказчиками. Вы можете знать и понимать SLA, но при чем тут заказчики?
Если Вы используете SLA для планирования и предоставления услуг, тогда Вам необходимо регулярно обсуждать его с заказчиками И ПОЛЬЗОВАТЕЛЯМИ.
- Они понимают цели (зачем Услуга)?
- Цели сформулированы в явных бизнес терминах или это технические ИТ цели мало связанные с чем-то еще?
- Эти цели все еще соответствуют их потребностям?
Если Вы еще не выработали привычку разговаривать с заказчиками, пожалуйста, не ждите следующего планового годового пересмотра. Сделайте это сейчас, пока вам не случилось оказаться в эпицентре управления значительным инцидентом, побеседуйте с заказчиками об их ожиданиях от Вас.
Объединить “Что может быть сделано” с “Попытаться влиять на ожидания”
Иногда заказчики действительно имеют нереалистичные ожидания, и мы не можем предоставить им то что они ожидают, просто потому что это слишком дорого. Например, они могут верить, что Вы можете предоставлять услугу, способную на реакцию менее 1 секунды при тысячах транзакциях минуту и с временем решения инцидентов не более 2 минут. И что делать с этим удивительным заявлением?!
Если Вы знаете, что ожидают от Услуги и Вы это действительно не сможете обеспечить, скажите об этом сразу. Не ждите пока это произойдет. Будьте честны, объясните почему не можете сделать ожидаемое, покажите потенциальную цену обеспечения текущих нереалистичных ожиданий, сравнивая с размером потециальной выгоды. Иногда это окажется достаточным, чтобы помочь заказчикам понять, что им нужно поменять свои ожидания. В других случаях Вы можете быть удивлены выяснив, что заказчик действительно имеет потребность в таком уровне обслуживания и подтвердит, что готов платить за требуемый уровень. Один заказчик, с которым я работал, рассказывал ИТ департаменту, что он хочет Услугу, которая будет восстанавливаться мгновенно. ИТ департамент же полагал, что восстановления работоспособности RAID массива за 20 секунд, ему будет вполне достаточно. После уточнения, оказалось, что заказчик готов оплатить возможность восстановления Услуги за четверть секунды, так как при большем времени восстановления потери для его бизнеса становились неприемлемыми.
В любом случае, Вы нуждаетесь в согласовании того, что можете действительно достичь. Когда Вы получили согласие, запишите это, предпочтительно используя слова самого заказчика. Не прячьтесь за неясными техническими целями. Например, многие IT организации указывают целевое значение доступности Услуги в процентах. Это может быть 99,5% или 99,9%, только это имеет смысл для персонала IT, а заказчики вряд ли понимают, что это для них означает. Гораздо лучше задать, как часто Услуга может быть неработоспособна и как долго она будет восстанавливаться. Например: “Услуга может быть полностью неработоспособна не более 4 раз в год и должна восстанавливаться в течение 4 часов”, это будет более полезно, чем “99,82%”.
Управлять Услугами для предоставления того, что ждут заказчики и пользователи
Не нужно согласовывать с Заказчиками целевые значения показателей, которые не сможете им обеспечить. Вам необходимо быть уверенными, что Вы приняли все необходимые (и достаточные) меры, чтобы сказать, что Вы это сделаете. Давайте вернемся к примеру, который только что рассматривали. Если Вы уверены в возможности “Услуга может быть полностью неработоспособна не более 4 раз в год и должна восстанавливаться в течение 4 часов”, Вам нужно подумать, как Вы будете Управлять обоими этими значениями:
- Что может причиной полной потери работоспособности Услуги и как, скорее всего, это может случиться?
- Как это можно сделать менее вероятным?
- Как вы будете восстанавливать Услугу после такого завала?
- Сколько это займет времени?
- Что вы можете сделать сейчас для уменьшения этого времени?
Все это абсолютно стандартная деятельность в рамках Управления Рисками, но если вы не сможете реестр рисков, вы не Управляете рисками, а просто ждете возникновения проблем.
Отчитываться о ваших достижениях, чтобы быть уверенным, что заказчики и пользователи знают, что Вы им предоставили
Наконец Вам нужно рассказать Вашим Заказчиками, что Вы в действительности сделали. И снова должно это делаться в терминах, которые Заказчики будут считать полезными для себя. Не стоит ежемесячно предоставлять 200-страничный отчет, если Заказчики просто хотят знать, что их ожидания выполнены, но, если что-то прошло не так, просто сказать об этом не достаточно. Самое важное — это регулярный отчет, рассказывающий о том, что вы делаете для усовершенствования. Объясняйте, что Вы сделаете, чтобы улучшить их впечатление от Услуги на следующей неделе, месяце, году. Обсуждайте эти улучшения с ними. Вы сконцентрированы на правильных вещах? Предложенные улучшения действительно сделают их восприятие Услуги лучше? Они хотят внести свои предложения?
В заключение
Что заказчики думают об Услуге, предоставляемой Вами? Имеете ли вы хороший механизм получения обратной связи, чтобы действительно понимать, что они чувствуют? Интерактивные опросы заказчиков могут использоваться, но они никогда не заменят результатов, получаемых при живом разговоре с заказчиками И пользователями. Если вы хотите быть уверенным, что знаете, что они хотят и что они понимают, что вы им поставляете и что вы работаете совместно обеспечивая наилучшую ценность от ИТ Услуг, которыми вы управляете от их имени, тогда вы не должны иметь никаких проблем с управлением ожиданий заказчиков.
Узнать больше про работу с ожиданиями заказчиков Вы можете прочитав мою работу “Назад к основам ITSM” Может быть вы не знаете, что они ожидают (”Back to ITSM Basics” Might Not Be What You Expect)
Спасибо за внимание. Оставляйте, пожалуйста, свои впечатления в комментариях, особенно если вы понизили рейтинг этой публикации.
