Як відповідати очікуванням замовника

imageПредставляю Вашій увазі ще одну статтю Стюарта Рейнса. Цього разу він ділиться своїм досвідом, як успішно укладати Угоди про Рівень Обслуговування (Service Level Agreement, SLA).

Оригінал див. «How to Meet Customer Expectations» опубліковано 13.12.2016 в блозі blog.sysaid.com

Складність матеріалу — початковий рівень.

Матеріал може бути цікавий для усвідомлення підходу, його сповідають ITSM до роботи з Замовниками та Користувачами, а також може завдати не поправимую користь тим, хто тільки ознайомився з теорією процесу Управління Рівнем Обслуговування і бажає її застосувати на практиці, або тим хто безуспішно намагався це зробити і зараз шукає щось нове в цьому.

Але знову закликаю Вас бути обережними у своїх висновках. Описане в статті це ідеальна ситуація, коли і Постачальник, і Замовник Послуг щиро зацікавлені у співпраці заради цінності Послуги. На практиці таке зустрічається, скажемо так, не завжди, при чому з обох сторін.

Тут і далі курсивом позначені примітки перекладача


Очікування від Service Desk

Одна з найбільших проблем, які ми зустрічаємо в Управлінні ІТ — Послугами, — це невиконання очікувань наших замовників та користувачів. Не важливо наскільки хороша сама Послуга і не важливо, як добре ми її підтримуємо, важливо, що коли ми не виправдовує очікування людей, вони відчувають себе нещасним.

Я працював з багатьма ІТ організаціями, які регулярно не відповідали очікуванням, і які не брали свою відповідальність за це. І в них завжди було виправдання цього, наприклад:
  • "Їх очікування не розумні"
  • «Ми змушені так робити, тому що Бізнес не дає нам ресурси»
  • «Ми надали те, на що користувач має право на підставі Угоди про Рівень Обслуговування (Service Level Agreement, SLA)»
  • «Ми не підняли пріоритет, тому що користувач не сказав, що це важливо»
  • «Ми не можемо впровадити новий функціонал так швидко, як Ви хочете, так як ми вже сильно завантажені аналогічними завданнями»
  • “Ми не можемо зробити це зміна, адже воно так ризиковано. Вони зможуть почекати"
Можливо, Ви чули такі речі в своїй організації або навіть самі вимовляли щось з перерахованого. В такому випадку, може бути, зараз саме час для деяких серйозних змін. Якщо Ви хочете надавати відмінні Послуги своїм користувачам та замовникам, поясніть, чому Ви не можете це робити досить добре. Ось, навіщо найбільш ефективні ІТ організації беруть на себе відповідальність за управління очікуваннями замовника. І, звичайно ж, це легко сказати, але не легко зробити. У цій статті зібрані мої пропозиції, як це зробити.

Якщо Ви хочете прокачати спроможність вашої організації надійно досягати очікування, тоді Вам необхідно виконувати чотири пункти:
  1. Розуміти, що замовники і користувачі очікують
  2. Об'єднувати «Що може бути зроблено» з «Спробувати впливати на очікування»
  3. Керувати Послугами для надання того, що чекають замовники і користувачі
  4. Звітувати про ваші досягнення, щоб бути впевненим, що замовники і користувачі знають, що Ви їм надали
Всі чотири пункти однаково важливі і Ви можете задовольнити очікування Ваших замовників тільки якщо приділіть увагу їм усім.

В іншій частині статті, я буду розглядати ці моменти в подробицях. Але спочатку я почну з донесення думки про одному важливому відмінності (див. Користувач і Замовники — Хто ховається за цими словами?). 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)

Дякую за увагу.
Залишайте, будь ласка, свої враження у коментарях, особливо якщо ви знизили рейтинг цієї публікації.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.