Service Requests – постигане на максимална добавена стойност

Случвало ли ви се е да сте в ситуация, в която двете страни бързо достигат до разбирателство относно параметрите на доставка на дадена услуга, подписват споразумение (SLA), усмихват се едни на други и си пожелават всичко най-хубаво, но само седмици след това започват да изпращат едни на други гневни имейли? Какво се случи, защо сте стигна до тези мейли, нали уж всичко по доставката на услугата беше ясно?

Една от основните причини доставчик на услуга и негов клиент да развалят своите взаимоотношения е, че и двете страни приемат, че на другата страна всичко относно самата доставка на услугата е ясно и задълбават в по-оперативни параметри. Ако използваме езика на ITIL®, можем да кажем, че фокусът е върху това услугата да предоставя своята добавена стойност (Warranty), и не толкова върху самата доставка на добавената стойност (Utility).

ITIL® разделя добавената стойност (Value), която услугата доставя на клиента, на два основни компонента:

• Utility (fit for purpose) – добавената стойност е предоставена, както е очаквана
• Warranty (fit for use) – добавената стойност е достъпна за клиента

Само ако и двата компонента са налични, можем да сме сигурни, че клиентът ще получи добавена стойност от предоставянето на услугата.

Фокусът върху Warranty води до следните проблеми:

• Прекален фокус върху технологиите, не върху доставката на добавена стойност
• Прекален фокус върху процедури, не върху крайни резултати , които могат да помогнат на клиента
• Прекален фокус върху самия доставчик, а не върху нуждите на неговите клиенти

Как тогава можем да подобрим нашата оферта (value proposition) и едновременно с това да подсигурим, че клиентът и доставчикът имат еднакво разбиране за нея? Моят опит ми е показал, че един лесен начин за това е да обсъдим т.н. потребителски заявки (service requests) възможно най-рано, а именно още докато сме в процес на договаряне на документа за поддръжка на услугата (Service Level Agreement).

Нека дам пример с една много популярна услуга – Поддръжка на имейл. Клиентът иска да поръча въпросната услуга от своя Доставчик. Организира се среща между тях и се започва дискусия за параметрите на доставка: Exchange, Web Mail, Blackberry, Number of mailboxes, Size of mailboxes, и т.н.

Сценарий А: Без дискусия относно потребителските заявки (Service Requests)

След  подписването на SLA документа, Клиентът започва да изпраща към Доставчика голямо количество заявки за увеличаване на пощенските кутии. Предвид факта, че тази тема не е била засегната, докато се е обсъждал документът за поддръжка, Доставчикът се опитва да достави тези заявки, но срокът на реализацията зависи силно от моментното му натоварване, което води до недоволство както от страна на Клиента, така и от страна на собствените му служители. Клиентът също така очаква от Доставчика всички негови мениджъри на високо ниво да имат втора пощенска кутия, която да бъде създавана скоро след тяхното постъпване и премахвана веднага след тяхното напускане. За нещастие на Доставчика, мениджърите на въпросните нива се сменят доста често, което води до голям брой подобни заявки.

Доставчикът приготвя и изпраща репорти, в които ясно се вижда, че услугата е достъпна и всички параметри, описани в договора за доставка, са покрити. Най-вероятно тези репорти ще бъдат приети от Клиента, но той ще коментира, че да, услугата се поддържа на нужното ниво, но добавената стойност, която той е очаквал, не е там. Това, както сами може да предположите, ще доведе до конфликт и възможна смяна на Доставчика в даден бъдещ момент.

Сценарий Б: С дискусия относно потребителските заявки (Service Requests)

След като всички технически и оперативни подробности са изяснени, се започва дефиницията на потребителските заявки:

• Разширяване на пощенска кутия (Extend Mailbox) – Видимост: всички служители, Цена: 10 USD, Срок: 1 работен ден
• Втора пощенска кутия (Second Mailbox) – Видимост: Високо ниво мениджъри, Цена: 100 USD, Срок: 5 работни дни

Всички заявки се публикуват онлайн и са достъпни според договорената видимост. Цената е видима за всички заявители, което води до лесно менажиране на обема на заявките. Също така целевият срок на доставка е ясно посочен, така че не са необходими допълнително време и усилия от двете страни относно менажирането на крайните срокове.

При положение, че на клиента е доставено обещаното, можем да очакваме само положителна обратна връзка от негова страна.

На практика повечето дискусии завършват някъде между Сценарий А и Б. Моят съвет е да не пестите усилия, да развиете темата до края и да не приключвате дискусията по SLA документа, докато всички потребителски заявки не бъдат дефинирани, а ключовите им параметри за изпълнение – изяснени.

Как този подход може да пасне в настоящата рамка на ITIL®? Моето предложение е да „надградите“ процеса за изпълнение на заявки (Request Fulfillment) до процес за Управление на потребителски заявки (Service Request Management) и да включите този процес във фазата Дизайн на услугата (Service Design). По този начин при започване на процеса ви за създаване на SLA документа, паралелно ще се инициира дизайнът на заявките, което ще гарантира, че клиентът ще получи максимална част от обещаната добавена стойност на услугата.

Защо ни е да „надграждаме“ процеса за изпълнение на заявки (Request Fulfillment)? Според мен този процес, както показва и името му, е по-скоро фокусиран върху изпълнението на заявките, отколкото върху добавената стойност, която те носят на клиента. Както споменах по-горе, потребителските заявки са силен инструмент за увеличаване на добавената стойност на вашето предложение и по тази причина трябва да бъдат вземани предвид още в първата фаза на създаване на услугите, а именно Стратегия (Service Strategy).

Колко свобода ще дадете на клиентите си зависи изцяло от вас! Дали ще им позволите да променят всеки аспект на услугата или по-скоро не. Тези въпроси са ключови, когато става въпрос за дефиниране на добавената стойност  на услугата. Затова смятам, че този ключов процес трябва да има по-подходящо название и освен това трябва да бъде преместен поне във фазата на Дизайн на услугата, така че да получим един цялостен или холистичен дизайн, както ни учи ITIL®.

* * *
ITIL® е регистрирана търговска марка на AXELOS Limited. Swirl logo™ е търговска марка на AXELOS Limited.
Акредитираните ITIL® курсове се доставят от Ню Харайзънс България, ITIL® & PRINCE2® тренинг организация, акредитирана от PEOPLECERT, и New Horizons CLC- 5Point Enterprises, ITIL® & PRINCE2® тренинг организация, акредитирана от PEOPLECERT, което означава, че доставяме най-новите официални курсове, за да получите най-добри резултати от инвестицията си в обучение.