Митът за най-добрите практики, Главен информационен директор, Издателство на отворени системи
Оценката на съдържанието на оперативните процеси в третата версия на ITIL показва, че някои от тях са прехвърлени от втората версия към третата чрез просто копиране
Разработчиците на третата версия на ITIL обърнаха много внимание на актуализирането на структурата на тактическите процеси - това става очевидно след прочитане на книгите Стратегия на услугата и Дизайн на услугата. Иновациите обаче не са засегнали основните оперативни процеси. Разработчиците са повлияни от минал опит и не забелязват, че има нужда от промяна на отдавна остарели концепции. „Защо да докосвате нещо, което работи толкова добре?“ те се оправдават.
Помислете например за основния оперативен процес на управление - управление на инциденти. ITIL 2 предоставя вариант на консервативна схема за приоритизиране, базирана на спешността на разрешаването на инциденти и тяхното въздействие върху бизнеса. С други думи, стойността на приоритета се изчислява чрез комбиниране на стойностите на параметрите за спешност на разрешаването и силата на удара (или степента на въздействие) на инцидента.
Схемата се поддържа от много решения на Service Desk. Изискването за предоставяне на атрибутите „приоритет“, „спешност“ и „въздействие“ е включено в списъка на критериите Pink Verify, най-известният методологичен инструмент в света за проверка на съответствието на ITSM софтуерно решение с препоръките на ITIL.
Слушателите на лекции и участниците в семинари по дизайн винаги са помолени да обяснят значението на тази схема. На практика никой не се задоволява със стандартни обяснения. Внимателните слушатели, които вече имат уменията да прилагат ITSM, или опитните мениджъри на процеси, никога не се задоволяват с теоретични обяснения. Участниците в семинара винаги се опитват да допълнят и усъвършенстват схемата за приоритизиране. Всяка такава дискусия все повече и повече убеждава,че е необходимо да се актуализира схемата или поне да се допълни с други опции.
Разпространение на инциденти
Сега да преминем към стойността на приоритета, изразена в часове, която определя крайния срок за изпълнение. Нека разгледаме ситуация, при която веднага след започване на работа по инцидент с висок приоритет (червено), неочаквано от работника в работната група се получава неусложнен инцидент с по-нисък приоритет (жълто), но с по-близък краен срок. Логично би било "жълтият" инцидент да бъде разрешен, като не се допуска изпускане на сроковете за него. И едва след това завърши инцидента "червено".
Неравностойни условия могат да възникнат в случаите, когато няма последователно получаване на инциденти на входа на процедурата за тяхното разрешаване и преразпределение на задачите между работни групи, изпълнители (например, ако е необходимо, концентрация на ресурси, тяхното преразпределение).
Разбира се, в идеалния свят на процеси с най-високо ниво на зрялост делът на такива ситуации клони към нула, но ние живеем в реалния свят. Добра практика е да се ръководите при определяне на реда на работа за оставащото време до крайния срок за изпълнение (подобна директна препоръка не беше намерена в ITIL). Правилата за разпространение, изградени върху тази практика, ще бъдат подходящи както за случая, когато инцидентите пристигат последователно, така и за случаите, когато инцидентите пристигат "безразборно" по някаква причина.
Присвояване на приоритет на инцидента
Не е достатъчно да има таблица, схема за приоритизиране на инциденти и разпределяне на инцидентите по приоритет. Трябва също така да можете да присвоите конкретен приоритет на конкретен входящ инцидент. Присвояването и промяната на приоритетите на контрола от изпълнителя води до срив, тъй като получаваме „контрол на изпълнителя“ и стандартния проблем на класическия модел на доставкауслуги, пропуск в разбирането на качеството на услугата от доставчика на услугата и потребителя на услугата. Приоритетът на изпълнителя не винаги съвпада с приоритета на потребителя, освен това приоритетите на ИТ специалистите и потребителя на услугата най-често не съвпадат!
По правило първата линия на поддръжка играе ключова роля при приоритизирането. Това отчасти решава проблема с липсата на услуги. Първата линия осигурява единна точка за контакт с потребителя и често се застъпва за неговите интереси.
Дали обаче първата линия на поддръжка е квалифицирана да използва обективни критерии за управление на потока от инциденти?
Като инструмент за обективно приоритизиране, ITIL предлага два сребърни куршума: спешност и въздействие.
Оценяването на въздействието е малко по-лесно - лесно е да се идентифицират инциденти, които засягат цялата организация. Но има ли много значими инциденти за една година и струва ли си да се добави към ежедневно използваната класификация за това? Какво ще кажете за незначителни инциденти, засягащи един потребител на услугата или няколко потребители, отдел, отдел, един или повече клонове, накрая? По време на първия инцидент малко се знае за истинската степен на въздействието преди диагнозата. В този случай специалистите по поддръжка от първа линия трябва да имат поне експертни технически познания и за предпочитане да разбират бизнес спецификата на услугите. Въпреки че, разбира се, можете да опитате да се справите с обикновен дар на предвидливост.
Така отново се връщаме към необходимостта от използване на висококвалифицирани експерти за класифициране на инциденти, което е неефективно.
Има сребърен куршум!
Има обаче решение на този проблем. Нека се обърнем към източника и да разгледаме по-отблизо целитепроцес на управление на инциденти.
Първоизточникът ни дава абсолютно ясен и недвусмислен намек за прилагането на една от процедурите за управление на инциденти. Трябва да се даде по-висок приоритет на тези инциденти, чието въздействие върху услугата е по-критично за бизнеса и следователно трябва да бъдат коригирани първи.
Трябва незабавно да се обърнете към официално или неофициално одобрения документ, който съдържа изискванията за нивото на услугата, тоест споразумението за ниво на услугата (Service Level Agreement, SLA). Необходимо е бързо да се възстановят тези услуги, чието отсъствие или лошо качество причинява по-големи загуби за бизнеса, което трябва да бъде отразено в SLA. Нормалното предоставяне на услуга също трябва да бъде определено в SLA. В края на краищата, един от значимите за клиента резултати е навременното възстановяване на определено ниво на обслужване в рамките на договореното време.
Силно желателен елемент за работа на тази схема би бил внедрен каталог на услуги. В добре проектирания каталог на услугите диспечерът лесно може да идентифицира услуга, която не работи или работи под договореното ниво, което потребителят има предвид, когато се свързва. Във всеки случай потребителят ще бъде идентифициран от първата линия за поддръжка, което веднага ще ви позволи да определите набора от SLA с потребителите на това устройство.
Тук не разглеждаме голяма част от инциденти, които не са свързани с повреди - консултации, нулиране на парола, инсталиране на ново работно място, известяване от системата за наблюдение - тоест заявки за услуги и събития. Просто е невъзможно да се дадат недвусмислени препоръки как да се класифицират всички многобройни видове събития и заявки заедно с неуспехите.
Приоритетизиране въз основа на услуги
Възможни са и комбинации от първите два подхода с привличането на допълнителни анализатори.
И двете предложени схеми са обективни по отношение на класифицирането на инциденти от помощния служител на първа линия и на практика като правило дават по-добър резултат от стандартната схема „спешност-въздействие“.
Вторият подход предполага, без да се променя основната идея, да се прехвърли анализът на следващите нива на самия каталог на услугите. При присвояване на услуга от второ или трето ниво на каталога към инцидент, операторът автоматично поставя вече зададения приоритет на услугата. Пример за такова приоритизиране би била справочната услуга "ERPERP отстраняване на проблеми с логистиката".
При първия подход най-често се приема, че видовете инциденти са еднакви за всички услуги. Втората схема е много по-гъвкава, но каталогът е по-сложен, времеемък и скъп. В допълнение, втората схема ограничава или значително усложнява възможността за сравняване на анализите на инциденти на различни услуги една с друга и усложнява вземането на управленски решения. Има и други ефективни схеми за приоритизиране, базирани на услугата.
Едно е сигурно: концепцията за приоритизиране в процеса на управление на инциденти, пренесена непроменена в ITIL 3, отдавна е остаряла. Трябва да доведе до механизъм за приоритизиране, базиран на услуга и SLA.
Александър Жилински — ИТ консултант, отдел за консултиране и интеграция, Inline Group, [email protected]
Споделяйте материал с колеги и приятели