SLA-ите са обещания към клиентите - OLA-ите гарантират, че вътрешните ви екипи могат да ги изпълнят. С Trupeer можете да спестите часове при писане на OLA, като започнете с безплатен шаблон за оперативно ниво на споразумение, персонализирате го с вашите brand guidelines и превърнете OLA в видео разходка, която обединява всеки вътрешен екип зад общи стандарти за обслужване.

Какво е шаблон за оперативно ниво на споразумение?

Оперативното ниво на споразумение, или OLA, е вътрешно споразумение между екипи в рамките на една и съща организация, което подкрепя ангажимент, направен към някого извън нея. Сервизният диспечер обещава на бизнеса разрешаване в рамките на четири часа при големи инциденти. Това обещание важи само ако мрежовият екип, екипът за приложения и всеки друг по веригата изпълняват своята част в рамките на известен срок.

OLA-ът е мястото, където тези вътрешни части са записани. Това не е договор, никой не плаща на никого и прилагането е изцяло управленско — и това е едновременно неговата слабост и причината да може да бъде честен по начини, които договорът не може.

Шаблонът за оперативно ниво на споразумение е повторяемата структура: страните, услугите, които се покриват, ангажиментите, мерките и условията за преглед. Шаблоните за това се намират лесно. Повечето от тях ще ви позволят да напишете OLA, което е напълно изпълнявано, но пак да се проваля — и точно за това е останалата част от тази страница.

OLA vs SLA: към какво реално се ангажира всяко от тях

Три документа попадат в това семейство и смесването им създава реални проблеми.

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

Оперативното ниво на споразумение е вътрешно — между екипи, които и двата докладват в рамките на една и съща организация. То съществува единствено, за да направи SLA-ът постижим и никога не трябва да съдържа ангажимент, който SLA-ът не изисква.

Подкрепящият договор е търговското споразумение с трета страна, доставчик или аутсорснат провайдър, което подкрепя същата верига. То има правна сила, която OLA-ът няма, и обикновено има най-малка гъвкавост от трите, така че трябва да бъде договорено преди SLA, а не след него.

Практическото следствие е правило за последователност. Първо договорете подкрепящите договори, после SLA спрямо това, което тези договори позволяват, и накрая OLA-ите, които запълват останалото. Организации, които го правят в обратния ред, рутинно обещават на бизнеса нещо, което нито един доставчик не е съгласувал да достави.

Как да персонализирате този шаблон в Trupeer

Стъпка 1: Отворете секцията с шаблони

Отидете до секцията Templates от главната навигация.

Стъпка 2: Изберете и отворете шаблон

Кликнете върху който и да е шаблон, с който искате да работите, за да го отворите.

Стъпка 3: Разгънете изгледа на шаблона

Ако е нужно, разгънете изгледа на шаблона, за да видите пълното оформление и детайлите ясно.

Стъпка 4: Редактирайте шаблона

Кликнете върху Edit, за да започнете да променяте избрания шаблон.

В редактора можете да:

• Добавяте нови секции

• Дефинирате или актуализирате правила за форматиране

• Добавяте лого и настройвате позицията му и свързаните настройки

Стъпка 5: Запазете персонализирания си шаблон

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

Стъпка 6: Преглед и фина настройка на шаблона

Когато искате да видите как изглежда вашият персонализиран шаблон, отворете Preview.

От екрана за преглед можете да продължите да правите корекции директно, ако е нужно, като гарантирате, че шаблонът се показва точно както искате.

С шаблон за оперативно ниво на споразумение можете да:

• Спестите часове при писане: Пропуснете празната страница със структура, създадена за OLA-ите.

• Обедините вътрешните екипи: Вградените полета гарантират, че всеки екип знае своята отговорност.

• Останете в бранд стила: Приложете логото, шрифтовете и цветовете си с brand kit-а на Trupeer.

• Защитите SLA-ите към клиентите: Силните OLA-и предотвратяват вътрешните прехвърляния да разрушат външните обещания.

• Стандартизирайте между услугите: Използвайте един и същ шаблон за OLA за всяко вътрешно споразумение.

• Достигнете глобални екипи: Превеждайте OLA-и на 65+ езика с едно кликване.

Защо всеки екип постига своята OLA, а SLA пак се нарушава

Това е най-често срещаният модел в управлението на услугите и изглежда като противоречие.

Всеки екип отчита зелено. Мрежата реагира в рамките на своя час. Екипът за приложения разрешава в рамките на своите два. Сервизният диспечер триажира в рамките на тридесет минути. Месечният отчет за съответствие с OLA е лесен за четене. И все пак SLA-ът към клиента се нарушава при една трета от големите инциденти.

Обяснението е, че OLA-ите измерват времето вътре в екипите, а SLA-ът измерва времето от край до край. Разликата между тези две числа е транзитът: тикетът, който стои в опашка след преназначаване, чака да бъде поет, или се връща обратно за повече информация.

Това време не принадлежи на никого. То не е в никоя OLA, не се отчита никъде и често е по-голямо от цялото комбинирано работно време.

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

OLA управлява предаването, а не работата

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

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

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

Щом предаването стане предмет, двете липсващи полета стават очевидни. Критерии за вход — какво трябва да е вярно, преди часовникът на приемащия екип да започне. И изрично разпределение на самото транзитно време, така че разликата между екипите да е нечие число, а не „на никого“.

Всичко останало в шаблона за OLA е администрация. Тези две са документът.

Критерии за вход: какво трябва да е вярно преди да започне часовникът

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

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

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

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

Приемащият екип запазва правото да отхвърля и то трябва да е ограничено: отхвърлянето е валидно само когато конкретен критерий за вход наистина липсва и всяко отхвърляне се записва с причината. Записването превръща връщането от невидим навик в число, което някой трябва да обясни.

Безплатен шаблон за оперативно ниво на споразумение: структурата, която да копирате

Копирайте от тук. Полетата, отбелязани с asterisk, са тези, които стандартните шаблони пропускат.

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

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

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

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

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

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

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

Изключения. Договорени обстоятелства, при които ангажиментите не се прилагат, като например по време на обявен голям инцидент или при замразяване на промени.

Преглед. Дати и какво задейства преглед извън цикъла.

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

Как да проверите дали OLA-ите реално се събират до SLA

Преди да подпишете каквото и да е, направете аритметиката. Отнема петнадесет минути и почти винаги се пропуска, защото OLA-ите се договарят поотделно с различни екипи в различни дни.

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

Ако сборът надвишава SLA, имате три честни опции: да преговаряте SLA, да намалите времето на екип с нещо, което прави това възможно, или да премахнете предаване. Това, което не можете да направите, е да подпишете OLA-и, които гарантират нарушение, и после да управлявате изпълнението спрямо тях — позицията, в която се намира изненадващо голям брой сервизни диспечерски екипи.

Търговецът, чийто транзитен период беше по-дълъг от работата

Rendlesham Group управлява няколко търговски бранда с около шест хиляди служители и вътрешен IT сервизен диспечер, който поддържа магазини и централния офис.

Неговият P2 инцидентен SLA към бизнеса беше четири часа до разрешаване. Процентът на нарушения при P2 беше около тридесет и осем процента в продължение на две години. Съответствието с OLA на всеки екип се отчита ежемесечно и всеки екип беше зелен.

Най-накрая някой добави времеви печат към всяка промяна на състоянието при сто и двадесет нарушени P2 инцидента.

Медианното общо изминало време беше шест часа и петдесет и една минути. От него три часа и дванадесет минути бяха време вътре в екип, който активно работи по тикета. Три часа и тридесет и девет минути бяха транзит: престой в опашка след преназначаване, чакане да бъде поет или връщане обратно.

Повече от половината от изминалото време при нарушен инцидент беше собственост на никого и се отчита никъде.

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

Промените бяха ограничени. Критериите за вход бяха записани във всеки OLA-ред. Ангажиментът на сервизния диспечер беше пренаписан от „триаж в рамките на тридесет минути“ към „предаване на тикет, който отговаря на критериите за вход, в рамките на тридесет минути“. Петнадесет минути транзит бяха разпределени за всяко предаване и се отчитаха към приемащия екип, след като критериите за вход бяха изпълнени. И всяко връщане беше записано с причина.

През следващите два тримесечия процентът на връщане падна от тридесет и четири процента от P2 до девет. Медианното транзитно време падна от три часа и тридесет и девет минути до един час и шест. Процентът на нарушения при P2 падна от тридесет и осем процента до единадесет.

Времето за вътрешно разрешаване на нито един екип не се промени съществено. Никой не работеше по-бързо. Времето, което преди е принадлежало на никого, просто беше дадено на някого.

Как да съставите оперативно ниво на споразумение стъпка по стъпка

Започнете от SLA, а не от шаблон. Запишете какво е обещано на клиента, от край до край, с дефиницията на часовника.

Картографирайте веригата. Всеки екип, който докосва заявка от този тип, по ред, включително всяка трета страна. Начертайте предаванията като отделни стъпки, а не като стрелки.

За всяко предаване задайте на приемащия екип един въпрос: от какво се нуждаете в тикета, за да започнете работа, без да се връщате при нас. Отговорът, записан, са вашите критерии за вход. Екипите отговарят лесно и точно и повечето никога не са били питани.

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

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

Договорете измерването, включително процента на връщане, и откъде идва. Ако инструментите ви не могат да го генерират, това си струва да се знае преди да подпишете, а не при първия преглед.

После го тествайте за едно тримесечие, преди да го формализирате. Първите версии обикновено са грешни на едно или две места и е по-лесно да се коригират, преди да има подписи.

Чести грешки при OLA и как всяка една се отразява

Измерване на екипите, а не на веригата. Всички са зелени и SLA се нарушава. Най-честият провал и темата на тази страница.

Без критерии за вход. Връщането се превръща в рационалната защита на приемащия екип и изминалото време надува невидимо.

Времена, които не се събират. Настройката на OLA гарантира нарушение и никой никога не го е смятал.

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

Копиране на езика от SLA в OLA. Наложените санкции, кредитите и правните формулировки не са тук и внасянето им кара екипите да преговарят отбранително вместо честно.

Писане на OLA с трета страна. Ако парите сменят собственика си, това е подкрепящ договор и изисква участие на procurement и правен отдел, а не шаблон. Нашият IT procurement policy template покрива одобрителния път.

Подписване и архивиране. OLA, който никой не преглежда, описва сервизна верига, която вече не съществува след около година.

Как да управлявате и преглеждате OLA-ите, след като вече съществуват

Отчитате веригата, а не компонентите. Има значение едно число — представянето от край до край спрямо SLA — и метриките на OLA съществуват, за да го обяснят, а не да стоят самостоятелно.

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

Наблюдавайте три неща. Процент на връщане по предаване — това ви казва къде критериите за вход се нуждаят от работа. Време за транзит по предаване — това ви казва къде се образуват опашки. И делът на инцидентите, които са минали по път, който OLA не описва — това показва, че документът се е отдалечил от реалността.

Задействайте преглед извън цикъла, когато даден екип се реорганизира, когато система преминава между екипи, когато в веригата влиза нова трета страна или когато SLA се променя. И четирите се случват по-често, отколкото годишният цикъл на преглед предполага.

OLA, SLA или подкрепящ договор: от какво имате нужда?

Ако ангажиментът е към някого извън вашата организация по доставката — било то външен клиент или вътрешно бизнес звено, което обслужвате — това е SLA.

Ако е между два екипа във вашата организация, без да се разменят пари, това е OLA.

Ако е със доставчик при търговско споразумение, това е подкрепящ договор и изисква правен и procurement подход, а не този шаблон.

Неловкият случай е центърът за споделени услуги или вътрешен екип с модел за chargeback, който се намира между OLA и SLA. Практичният отговор е да го напишете като OLA и да отпаднете всякакъв език за санкции, защото вътрешните режими за санкции надеждно произвеждат отбранително поведение и по-лошо обслужване.

За дефинициите и формулировките за отговор, насочени към клиента, които стоят върху всичко това, нашите help desk response template и ticket and resolution template покриват слоя, който крайният потребител реално вижда.

Мога ли да получа OLA шаблон в Word или Excel?

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

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

PDF за подписаната версия, експортирана от източника. Дръжте работната версия като editable, защото критериите за вход ще трябва да се коригират след първото тримесечие на реални връщания.

Как да поддържате OLA и реалността в синхрон

OLA описва верига от работа, която се променя постоянно. Екипите се реорганизират, системите се преместват, инструментите се сменят и документът е последното нещо, което някой актуализира.

Частта, която остарява най-бързо, са критериите за вход, защото те описват какво трябва да съдържа тикетът и какво трябва да съдържа тикетът зависи от това как реално работят текущите инструменти и текущият процес.

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

Запишете го. Брандирайте го. Преведете го. Trupeer-нете го.

SOP creator покрива процедурите, от които зависи OLA-ът, а нашият IT SOP template покрива как да решите кои от тях си струва да се поддържат. Documentation държи споразуменията и процедурите заедно, а инструкциите за настройка са в document template setup guide.

Често задавани въпроси

Има ли безплатен шаблон за оперативно ниво на споразумение в Word?

Структурата по-горе се поставя директно в Word или Google Docs, включително полетата за критерии за вход и разпределение на транзита, които стандартните шаблони пропускат. Няма заключено изтегляне и няма формуляр. Дръжте таблицата с ангажиментите в spreadsheet и я използвайте като справка, защото тази част трябва да се сортира и събира.

Има ли безплатен шаблон за оперативно ниво на споразумение в PDF?

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

Има ли безплатен шаблон за оперативно ниво на споразумение в Excel?

Excel е правилното място за таблицата с ангажиментите и за проверката на аритметиката. Един лист с по една редица за всяко предаване и текущ сбор спрямо SLA, който маркира всяка верига с по-малко от десет процента запас. Изграждането на този лист преди преговорите обикновено променя това, което се договаря.

Къде мога да намеря примерен PDF за оперативно ниво на споразумение?

Няколко доставчици на ITSM и държавни институции публикуват OLA и SLA шаблони като документи и те са разумни по отношение на структурата. Прочетете ги за секциите, а не за съдържанието, тъй като ангажиментите във всеки публикуван пример са нечия чужда верига, а времената са безсмислени извън SLA, за който са създадени да го поддържат.

Кой подписва оперативно ниво на споразумение?

Посоченият собственик от всяка страна, който трябва да е мениджърът, отговорен за доставката на този екип, а не функция по управление на услугите. OLA, подписан само от service management, е по-скоро желание, защото човекът, който трябва да осигури ресурсите, не е бил в стаята.

Колко OLA-ове трябва да има сервизният диспечер?

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

Трябва ли оперативното ниво на споразумение да има санкции?

Не. Няма правна връзка за прилагане и вътрешните режими за санкции надеждно произвеждат отбранително поведение: екипите отхвърлят работа, спорят кога започва часовникът и оптимизират за собственото си число, вместо за резултата. Отчитате веригата от край до край вместо това — така споделеното следствие става видимо, без никой да бъде глобяван.

Колко често трябва да се преглеждат OLA-ите?

Тримесечно, с всички страни на място, плюс преглед извън цикъла винаги когато даден екип се реорганизира, когато система се премества между екипи, когато трета страна влиза във веригата или когато основният SLA се променя. Тримесечният ритъм улавя разминаванията, а тригерите улавят промените, които правят документа грешен още през нощта.