Този сайт използва бисквитки (cookies). Ако желаете можете да научите повече тук. Разбрах

Новини ИТ мениджмънт
бр. 6, 2013

Кратък наръчник за каталога на услугите

Организациите полагат неистови усилия да измислят каталога на услугите си – най-практичното решение е да започнем от смисъла

от , 18 юни 2013 1 8834 прочитания,

Нина Проданова-Йоцева, Управляващ партньор, ITCE

В консултантската си практика срещнах много случаи, в които организациите полагат неистови усилия да измислят каталога на услугите си и прекарват много време в отегчителни дискусии. Каталозите, които успяват да създадат често остават без практическо приложение да отлежават в някоя папка. Усилието започва отново следващия път, когато решат, че им трябва каталог на услугите. Тази нужда изниква все по-често и по най-различни причини, като желанието да подпишем договор с вътрешните отдели или клиентите (SLA–Service Level Agreement), заради мениджърите по информационна сигурност, които настояват да правят анализ на риска на информацията, във връзка инициативите за продължаване на бизнеса при бедствени ситуации и много други стимули.

Докато се главоблъскат над каталога на услугите мениджърите се чудят „Принтерът услуга ли е или си е просто принтер?“, „Поддръжката на система услуга ли е? А даването на права на потребителите?“, „Мрежата бизнес услуга ли е или е техническа?“ “Архитектурата на системите има ли връзка с каталога или си е съвсем отделно?“, „Собственикът на услугата от бизнеса ли е или от технологичния отдел?“. „Ако няколко системи правят известяване по мейл, то да направя ли услуга „Известяване“ за всички системи?“. За съжаление дори много старателното изчитане на темата в ITIL книгата “Стратегия“ само добавя объркване.

В същото време въпросът за каталога има далеч по-просто и практично решение. Да започнем от смисъла:

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

Клиентите и доставчика се договарят на базата на каталога, по него наблюдават статус и планират подобрения. Доставчикът предоставя на клиентите чрез различни ИТ системи множество функционалности, които те използват в оперирането на бизнеса си, например в управлението на продажбите, в управлението на склада, на приходите и т.н. В каталога това множество от функционалности трябва да се композира под формата на услуги. В композирането трябва да ни води нуждата от взаимно разбиране и комуникация между доставчика и клиента. Искаме клиентите да четат с лекота справките за статуса, да разбират съвършено връзката между финансирането на технологиите и ползата им в бизнес процесите. В същото време доставчикът трябва да може да направи удобен, лесно управляем модел на разходите.

Например, ако в момента имаме 2 отделни системи за продажби на крайни и бизнес клиенти, то по-удобно ще е да имаме 2 услуги в каталога на услугите вместо една „Управление на продажбите“, за да съпоставим лесно 2-те архитектури и различните екипи към различни услуги. Ако показателите, които договаряме с бизнеса са еднакви, може просто да имаме един договор за двете услуги или пък два, но базирани на общ образец. Ако търговският и маркетинговият отдел използват различни модули на единна CRM система вероятно е по-добре да композираме 2 отделни услуги базирани на модули на тази система.

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

Какво все пак е услуга?

Дефиницията, според ITIL е горе долу такава: „Услугите са начин за доставяне на стойност на клиентите чрез улесняване на резултата, който искат да получат без да е нужно клиентите да управляват специфичната цена и рискове, свързани с всички отделни компоненти и с предоставянето на услугата “. С други думи, резултатът е набор от функционалности. В бизнес анализа по създаване или промяна на софтуер, тези функционалности се наричат сценарии на използване (use cases). Клиентите плащат цена за тях и имат гаранция за стабилната им работа и тяхната поддръжка. Тези 3 перспективи на една услуга могат да се представят в триъгълника във фигура 1.

Класификация на услугите

Услугите често се класифицират като бизнес и технически.

Бизнес услугите са видими за клиентите и или съответстват директно на продуктите, които компанията предоставя или са елемент от оперирането на бизнеса. Различаваме външни и вътрешни бизнес услуги. За телеком пример, външна бизнес услуга е „Мобилен интернет“ – продукт за пазара, а за вътрешна - „Управление на заплатите“ - технологичната част на процеса по изчисляване и изплащане на заплати на служителите в компанията и „Печат“, включващ сканиране, копиране и принтиране.

Клиентите не взаимодействат директно с техническите услуги и компоненти и те остават невидими за тях, но пък са ключови в осигуряването на бизнес услугите.

Корпоративната мрежа е пример за техническа услуга. Тя е представена в архитектурата на всички бизнес услуги. Провизирането на телефонията и мобилния интернет в Телеком е техническа услуга, от която зависят бизнес услуги като Интернет портала и Кол центъра, защото през тях клиентите или служителите активират телефония и Мобилен интернет.

Каква е връзката между бизнес и технически услуги и компоненти?

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

Напълно възможно е да моделираме бизнес услугите само с отделни технически компоненти като сървъри и бази от данни, но ако имаме споделено използване на логически групи от компоненти или пък отделни отговорни за поддръжката звена или доставчици, е по-удобно да оформим технически услуги като например „Опорна мрежа“ или „Провизиране“, „Таксуване“.



Плосък или йерархичен каталог?

Много полезно е да гледаме на каталога като на дървовидна структура, в която виждаме различни нива на детайлност. Започваме от типа на услугите, след това определяме категория на услугата като област от бизнес активности от картата на бизнес процесите на компанията или група продукти за пазара, след това идва нивото на услугите, за които сключваме SLA с клиентите. Съставните сценарии на използване или функционалности са едно ниво надолу. Фигура 2 е пример за подобна структура.

Има ли връзка със SOA?

Много често услугата „Интернет портал“ достъпва услугата „Провизиране“ с обръщения към софтуерни компоненти, които са услуги в смисъла на SOA (Service Oriented Architecture) и могат също да се дефинират с функционалностите, които дават, точно както услугите от каталога, но на по-ниско ниво на детайлност. SOA е архитектурна концепция, при която има отлично съпоставяне на бизнес функционалност към технологичен компонент и тя също включва каталог-регистър. На практика това е същия каталог, но на много детайлно ниво.


Услугите в смисъла на SOA могат да бъдат базови или процесни. Ако са процесни ще ги видите на нивото на сценариите в горната структура. Ако са базови, то това вече е едно следващо ниво, което може да определим като стъпки. Много важно е това да бъде осъзнато, за да може компанията да получи хармонично представяне на технологичната архитектура и екипите които правят каталога за управление на услугите и каталога за SOA да разбират, че правят различни части на една обща структура.

Кои са всички роли, използващи и развиващи каталога?

Много често каталог на услугите се прави в контекста на система за Service Desk или най-много в контекста на оперирането на услугите. Разбира се, каталогът дава класификацията на инцидентите и структурата на справките за анализът им по SLA. Но това е твърде ограничено. В създаването му трябва да се включат:

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

  • бизнес анализаторите по проектите за промени в бизнес системите,

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

  • специалистите по информационна сигурност, които класифицират информацията.

  • продуктовите мениджъри от маркетинг, които правят продуктите за пазара,

  • проектните офиси, които структурират портфолиа от проекти,

Всички те трябва да работят в един и същ контекст – контекста на каталога, който е фундаментално знание за всяка една компания. За съжаление, тази универсална същност не е залегнала в софтуера за управление на каталога – софтуерните производители правят CMDB (configuration management database) системи, които не поддържат регистър за SOA и обратното.

Ако вече сме измислили услугите, какво правим след това, как представяме всяка услуга?

1. Ролите – собственик на услугата от страна на доставчика и заинтересованите от бизнеса, групите по поддръжка

2. Технически средства за управление на услугата – например за мониториране и справки

3. SLA на услугата като работно време, достъпност, производителност, показатели за измерване. Много удобно е да се използва Excel за представяне на характеристиките на услугите, представени в точки 1-3.

4. Статичен модел на услугата – това е карта от компоненти, които взаимодействат, за да осигурят работата на услугата като включват софтуерни, информационни, хардуерни, мрежови, лицензи и др. Самите зависимости или връзки между услугите също се типизират, например „Компонент на“, „Използва“, „Управлява“ и др. Отделните компоненти и връзки имат атрибути. Статичният модел е на практика дизайна и съдържанието на CMDB. Често се използват 2 вида Visio диаграми за статичния модел – концептуално и физическо представяне и Excel за атрибутите на компонентите, но само докато се моделира и инвентаризира. След това те влизат в CMDB система.

5. Динамичен модел – това е динамиката на услугата или как тя реално работи и се използва. В ITIL книгата има една леко смешна примерна диаграма за представяне на динамиката. Странно е защо авторите на ITIL са се опитали да измислят представяне, а не са се обърнали към едно вече толкова зряло знание – моделирането на бизнес процеси, което се прилага в бизнес анализа. Много удобно е да представим динамиката с UML(unified modeling language) Use case диаграми и сценариите от отделните случаи да се представят с поточна диаграма като например с BPMN (Business process modeling notation).



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

Как тестваме каталога?

Един каталог е качествен, само ако е полезен. За да го тестваме проверяваме дали е полезен за:

  1. Класификация на събитията, като инциденти и заявки по услугите

  2. За приоритизация на работата по инцидентите

  3. За договаряне с бизнеса за нивото на обслужване

  4. За създаване на модел на разходите

  5. За анализ от тип “Ползи към разходи“

  6. За анализ на нуждите от капацитет

  7. За бюджетиране

  8. За анализ на капацитета и знанията на екипите, които поддържат услугите

  9. За обучение на екипите по поддръжка, за да ме сигурни, че те разбират пълния бизнес и технически контекст на компонентите, за които отговарят

  10. За планиране на договорите с доставчици по поддръжката

  11. За брилянтна видимост за технологичната архитектурата и ресурсите под една услуга

  12. За анализ на идеите за нови услуги – дали те могат да използват съществуващ капацитет и функционалност

  13. За анализ на риска от промени

  14. За идентифициране на критичните компоненти и анализ дали те са проектирани спрямо нуждите

  15. За планиране на подобрения в цялостната архитектура за постигане на ефективност на разходите, намаляване на риска и улесняване на иновациите

В заключение

Каталогът на услугите е централно знание за организацията и трябва да се проектира с широко участие на различни роли. В същото време трябва да бягаме от академичен продукт, а да се стремим той да е лесно разбираем, широко използваем и в никакъв случай перфектен.

Нина Проданова-Йоцева е управляващ партньор на ITCE. Тя има е 19-годишен опит в ИТ индустрията. През 15-те си години в ITCE е работила по много и разнообразни ангажименти в областта на управление на услугите и в подготовка за одити по ISO 20000 и Cobit. През 2000 г. е сред топ 15 инструктори за MS SQL в Европа, а през 2005 г. е сред първите с ITIL сертификат. В конкурса за най-добра статия за 2012 на CIO статията на Нина за Agile и Lean спечели първо място.



ЕТИКЕТИ:
мениджмънтITIL

КОМЕНТАРИ ОТ  

КОМЕНТАРИ

 
  
10:27, 07 юли 2015 # 1
NO AVATAR
Са rel="nofollow" мо мътите водата да изглежда по-дълбока(консултантска му работа).
Един пост пример на каталог с една услуга щеше да е много по-полезен.
Трябва да сте регистриран потребител, за да коментирате статията
"Кратък наръчник за каталога на услугите"



    

Полезни страници
    За нас | Аудитория | Реклама | Контакти | Общи условия |
    Действителни собственици на настоящото издание са Иво Георгиев Прокопиев и Теодор Иванов Захов