Соответствие параметров ola по качеству зарегистрированных документов

«Обратный» SLA: как зафиксировать обязательства бизнеса перед ОЦО

Обязательства ОЦО перед бизнесом традиционно прописываются в Соглашении об уровне обслуживания (Service Level Agreement — SLA), которое содержит ключевые параметры предоставляемых услуг и заключается заказчиком услуги (бизнесом) с сервисным центром. Однако все чаще представители Общих центров обслуживания стремятся зафиксировать обязательства бизнеса перед ОЦО, которые напрямую влияют на качество выполнения сервиса. В материале Клуба ОЦО рассматривается, как это можно сделать.

Корректировка параметров SLA в зависимости от обязательств и требований бизнеса

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

Так, Александр Блудов, руководитель «СИБУР-ЦОБ», отмечает: «Мы отчетливо понимаем, что трудоемкость операций центра обслуживания формируется не только в самом ОЦО, но прежде всего зависит от качества процессов клиента, от качества входящих в ОЦО данных. И мы начали показывать заказчикам, насколько наша трудоемкость зависит от уровня зрелости их процессов. Например, электронный документ обрабатывать легче, чем бумажный. Мы готовы объяснять заказчикам, что стоимость услуг для них будет ниже, если они максимально оптимизируют свои процессы: это и внедрение ЭДО, и применение стандартных форм договоров, и качество данных на входе, и ритмичность поступления к нам заявок. Мы выработали для себя набор показателей, по которым обсуждаем качество процесса с бизнесом и в зависимости от этого даем либо скидку на услуги, либо, наоборот, устанавливаем наценку. Это так называемый обратный SLA — очень важная для нас тема, поскольку мы понимаем, что есть некий предел оптимизации процессов внутри ОЦО».

Руководитель другого ОЦО в диалоге с финансовым директором холдинга обозначает ключевые задачи бизнеса, выполнение которых позволит снизить стоимость услуг. Например, перед бизнесом ставится задача – увеличить объем ЭДО первичных документов до 90% за два года, что приведет к снижению стоимости услуг ОЦО на 30% за два года. На регулярных совместных совещаниях руководителей ОЦО и бизнеса обе стороны отчитываются, чего им удалось достичь, то есть идет совместная комплексная работа.

Другой пример — план-график предоставления документов бизнес-подразделениями влияет на сроки закрытия отчетности. При выполнении графика отчетность закрывается своевременно. Если у бизнеса возникает срочная потребность в более раннем закрытии отчетности (при этом их график подачи документов не меняется), то ОЦО может сообщить бизнесу, какова будет цена вопроса, то есть клиенту придется оплатить дополнительную загрузку сотрудников ОЦО в выходные дни.

Соответственно, изменение бизнес-процессов (автоматизация, ЭДО, упрощение процесса, корректировка сроков и т.д.) требует пересмотра SLA.

Так, в МФЦО «Ростелекома» с момента запуска ОЦО SLA пересматривался многократно. В SLA вносятся изменения при расширении функционала, пересмотре бизнес-процессов, порядке взаимодействия подразделений. Менеджер проектного офиса фиксирует все необходимые изменения в процессе, после чего вносятся коррективы в SLA.

У некоторых ОЦО в SLA прописан дисклеймер — в каком случае не может применяться ответственность к ОЦО, например в случае несвоевременного предоставлении либо непредоставления в полном объеме необходимых данных.

Обязательства бизнеса могут фиксироваться не в общем SLA и не во внутреннем документе (так называемый внутренний SLA), однако иногда ОЦО заключают с бизнесом отдельный договор, о чем речь пойдет ниже.

OLA: обязательства бизнеса перед ОЦО

Некоторые ОЦО прописывают обязательства бизнеса перед ОЦО в специальном документе — Соглашении об операционном уровне обслуживания (Operational Level Agreement — OLA). Именно OLA показывает работу клиента — как он предоставляет сервисному центру первичные документы, данные для отчетности и т.п. ОЦО считают показатели работы клиента не для того, чтобы указать на его ошибки, а чтобы увидеть «узкие места» в работе бизнеса, которые влияют и на работу сервисного центра.

OLA внедрен во многих сервисных центрах: в «Северсталь-ЦЕС», «Интер РАО — Управление сервисами», «Норникель-ОЦО», «Русагро — Центр учета», МФЦ «Полюс» и других. Основная цель этого документа — добиться того, чтобы бизнес понимал: отдав процесс в сервисный центр, он не перестает на него влиять.

Обычно данные SLA и OLA формируются параллельно, если в ОЦО внедрена модель сквозных процессов, то считается ключевой показатель эффективности процесса в привязке к SLA и OLA, что позволяет увидеть, как работа и ОЦО, и бизнес-подразделений повлияла на качество процесса.

Людмила Сорокина, директор по качеству и операционной эффективности МФЦ «Полюс», отмечает: «Мы пока не формализуем параметры OLA, с 2020 года мы обсуждаем их на наших ежемесячных комиссиях. К примеру, кто из бизнеса нарушает сроки предоставления первичных документов по графику закрытия и как это влияет на GPI (General Performance Indicator) процесса. Мы договорились, что в 2021 году углубим аналитику, формализуем показатели OLA и бизнес будет их контролировать».

Партнерская позиция ОЦО по отношению к бизнесу

Когда речь идет о том, что развитые ОЦО становятся полноправными партнерами бизнеса, то подразумевается, что они не только ищут направления, по которым могли бы быть полезны бизнесу, но и помогают бизнес-подразделениям улучшать свою внутреннюю работу. Александр Блудов, «СИБУР-ЦОБ», подчеркивает: «…Мы готовы помогать клиентам в совершенствовании их процессов, это дорога с двусторонним движением. И очень важно иметь систему инструментов, позволяющих измерить качество процессов».

Есть и другой взгляд на партнерство — когда ОЦО готов выполнять свои процессы на требуемом уровне, независимо от качества работы бизнес-подразделений.

Алексей Романов, руководитель ОЦО Tele2, отмечает: «Для нас SLA — это не мотивационный KPI, а прежде всего источник данных для улучшения сервиса. Данные по кейсам оценки сервисов мы постоянно используем в рамках цикла PDCA (Plan-Do-Check-Act.). Мы приняли решение, что в качестве представителей владельца учетного процесса компании отвечаем за учетные процессы Tele2 целиком. Мы принимаем ответственность за улучшение процессов даже в случае недоработок со стороны исполнителей от бизнеса. В этом также состоит наша партнерская позиция».

Источник

Разница между SLA и OLA

Содержание:

Что такое SLA?

Ниже приведены различные типы соглашений об уровне обслуживания.

SLA на основе клиента

Это соглашение об уровне обслуживания, которое охватывает все группы клиентов вместе с услугами, которые они используют. Например, соглашение об уровне обслуживания между поставщиком услуг и финансовым отделом крупной организации в отношении таких услуг, как финансовая система, система расчета заработной платы.

Многоуровневый SLA

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

SLA на основе сервисов

Это соглашение для всех клиентов, пользующихся услугами, предоставляемыми поставщиком услуг; например, внедрение службы электронной почты для организации.

Технические определения, такие как «среднее время наработки на отказ» (MTBF), «среднее время до ответа» (MTTR) или «среднее время восстановления» (MTTR), используются в SLA вместе со сторонами, ответственными за уплату сборов и сообщение о неисправностях.

Что такое OLA?

В чем разница между SLA и OLA?

SLA против OLA

Источник

Портал №1 по управлению цифровыми
и информационными технологиями

В последние годы я довольно много сталкиваюсь с практическими вопросами организации SLM и построения каталога ИТ-услуг. Одним из актуальных вопросов в этой области является назначение и содержание такого документа как Operational Level Agreement (OLA).

Есть бородатый анекдот про хозяйку, которую соседка обвинила в том, что когда та брала у неё горшок, она вернула его треснувшим. Ответ был таков: «Во-первых, это неправда — я вернула его целым. Во-вторых, когда я брала горшок, он уже был треснувшим. И в-третьих, я вообще его не брала». Так вот, про OLA я могу сказать буквально следующее: во-первых, такого документа не существует, а во-вторых применение OLA на практике требует серьёзного анализа целесообразности.

Тезис первый: OLA не существует

В самом деле, OLA — это документ, который определяет обязательства внутреннего подрядчика по отношению к поставщику услуг, который тот предоставляет своим заказчикам (при этом между поставщиком и заказчиком заключены SLA). Однако, если внимательно посмотреть, то с точки зрения подрядчика OLA на самом деле является SLA. Более того, заказчик может рассматривать SLA со внутренним поставщиком как OLA, ведь предоставляемые услуги поддерживают выполнение его операций и в свою очередь могут обеспечивать предоставление услуг внешним клиентам. Поэтому двигаясь по цепочке создания ценности, мы быстро придём к выводу: то, что для меня OLA, для моего подрядчика будет SLA.

Поэтому OLA как самостоятельный документ не существует — это то же SLA, только с точки зрения другого субъекта сервисных отношений. И наличие термина OLA в тех же книжках ITIL вызывает вопрос о целесообразности. Более того, если посмотреть на предлагаемые в книжке ITIL Service Design примеры SLA и OLA (приложение F), мы увидим, что они очень и очень похожи.

Тезис второй: применение OLA требует анализа целесообразности

Если Вы осуществляете реализацию сервисного подхода к взаимодействию с ИТ-подразделением и планируете SLA с подразделениями своей компании, это вовсе не означает, что Вам обязательно понадобятся OLA, и они будут полезны. Особенно если речь идёт об OLA в пределах ИТ-подразделения.

Дело здесь в том, что OLA является соглашением о предоставлении услуг. То есть введение OLA означает, что Вы «включаете» сервисные отношения внутри ИТ-подразделения. Это имеет довольно серьёзные последствия:

Принимать или не принимать эти последствия решать Вам (это отдельный вопрос в каждом конкретном случае, здесь не может быть универсальной рекомендации). Но осознавать их при принятии решения о применении каталога технических услуг и OLA крайне важно.

Практика

На практике есть компании, которые пытались делать OLA, но они не оправдали надежд. Есть компании, которые обожглись на применении OLA (то есть они не просто не помогли, а помешали). Наконец многие компании называют словом OLA внутренние регламенты взаимодействий, не связанных с сервисными отношениями. То есть, не будучи ясно определён и аргументированно обоснован в первоисточниках, термин OLA вызывает путаницу в реализации.

Лично мне термин OLA представляется просто лишним — SLA и UC абсолютно достаточно. Поэтому берём бритву Оккама и аккуратно отрезаем по шву.

Источник

Как заставить OLA работать

По информации многочисленных источников, доля доходов ИТ-компаний от предоставления услуг технического сопровождения составляет 25-45%. Это существенная часть бизнеса, и она требует внимательного отношения, основанного на взаимовыгодных для клиента и продавца условиях. Ключевым фактором является «прозрачность» во взаимоотношениях, которая, в частности, подразумевает, что клиенту предлагаются услуги по техническому сопровождению, в которых однозначно определены условия устранения возможных проблем. Имея подобный прозрачный сервис, клиент может прогнозировать собственный бизнес и управлять рисками от возникновения инцидентов. Как правило, при предоставлении услуг технического сопровождения заключаются соглашения, в которых прописывается какие инциденты и в какие сроки должна устранить ИТ-компания, причем нарушение сроков ведет к финансовым потерям (выплате штрафов).

Идея заключения подобных соглашений не нова, о ней много написано, разработана методология ITIL (Information Technology Infrastructure Library – библиотеки инфраструктуры информационных технологий), но практически отсутствует информация о том, какие условия на предприятии нужно создать, чтобы обеспечить соблюдение этих соглашений. ITIL констатирует, что SLA (Service Level Agreement – соглашение об уровне предоставления услуг) может выполняться только в том случае, если опирается на OLA (Operation Level Agreement – соглашение о предоставлении услуг на операционном уровне). Действительно, в одиночку техническое сопровождение вряд ли может решить все проблемы, возникающие у клиентов, иногда ему требуется помощь от других подразделений компании, в частности подразделений производства.

Формирование перечня инцидентов

Разработку OLA нужно начинать с определения перечня инцидентов, которые должны быть включены в OLA и затем, соответственно, в SLA. Хотя в SLA число инцидентов может быть большим, чем в OLA, но все инциденты, указанные в OLA, должны войти в SLA. Инцидент в данном случае – это специфическое поведение программного продукта, приводящее к отклонению от нормального функционирования бизнеса. Подходы к устранению однотипного инцидента могут быть различными. Возьмем для примера программное обеспечение, используемое для регистрации договоров. В силу каких-либо причин время отклика системы увеличилось и вместо 30 сек. составляет 3 мин. Для одного человека, заключающего договор, такие временные потери терпимы, а для многих, стоящих в очереди, увеличение времени отклика системы становится проблемой. В связи с этим у компании-клиента может возникнуть упущенная выгода, поскольку кто-то из посетителей не дождется своей очереди и уйдет к конкуренту. Такой инцидент должен быть устранен как можно быстрее. А теперь представим, что подобное «зависание» при регистрации договоров происходит, но достаточно редко – скажем, с периодичностью раз в неделю. Это такой же инцидент, причина его возникновения, возможно, та же самая, но его влияние на бизнес клиента меньше, поэтому устранить инцидент нужно, но с этим можно повременить.

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

Ранжирование инцидентов и сроки устранения

Ранжировать инциденты нужно в зависимости от следующих факторов: степени воздействия и критичности. Степень воздействия определяется объемом бизнеса компании, проблемно функционирующего из-за возникшего инцидента. Критичность является характеристикой качества исполнения бизнес-процессов. Например, CBOSS использует 4 уровня критичности инцидентов: максимально критично, критично, условно критично и не критично.

Уровни критичности инцидентов

Источник: CBOSS, 2009

Стоит отметить, что под устранением инцидента понимается предоставление «временного решения», которое позволит восстановить нормальное функционирование бизнеса. Окончательное же решение по устранению возникших проблем может быть предоставлено и позже, но обязательно должно быть реализовано.

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

Большое значение имеет то, как часто специалисты технического сопровождения будут привлекать к устранению инцидентов сотрудников производства. Список инцидентов в OLA и SLA один и тот же, но не всякий инцидент возникает из-за ошибки или сбоя программы, поэтому не в каждом случае необходимо привлекать к его устранению сотрудников производства. Создать какие-либо простые правила, которые являлись бы сигналом для привлечения / не привлечения производства к решению инцидента, невозможно. Попытка ввести ограничения по мощности (например, десяток инцидентов производство гарантированно устраняет в срок, а остальные – как получится) является, по сути, неким самоуспокаивающим средством, поскольку вроде бы соглашение OLA соблюдается, но клиент все равно в итоге отказывается от сопровождения, ибо возникший у него инцидент не устранили в срок. Однако показатель мощности все же желательно ввести, но он должен стать индикатором для сотрудников технического сопровождения. Значение показателя мощности должно сигнализировать техподдержке, что не стоит сваливать на производство решение всех инцидентов, передавать нужно только те, с которыми самостоятельно точно не справиться. Кроме того, нужно оказывать моральное воздействие на сотрудников, время от времени доводя информацию о том, что не стоит производство «перегружать» работами по обеспечению технического сопровождения, поскольку это может привести к снижению возможностей в других работах, в частности, развитии продукта, что является ключевым бизнес-процессом.

Источник

В чем разница между SLA и OLA?

В традиционных ИТ-средах услуги клиентам предоставляются и поддерживаются организацией. Соглашение об уровне обслуживания (SLA) заключается в деталях, например о том, какой будет доступность услуги, насколько надежной будет услуга, какие штрафы могут взиматься в случае простоя и т. Д. Внутренние группы, такие как группа сетевого администрирования, разработка команда IT служба поддержкии т. д. затем составят соглашения об уровне эксплуатации (OLA) для поддержки SLA.

Раньше этим легко управлять.

Но по мере того, как ИТ-среды стали сложными, для удовлетворения ожиданий клиентов услуги теперь требуют участия нескольких внутренних и внешних групп. Итак, теперь есть не только SLA, о котором вы договорились со своим клиентом, и поддерживающие его внутренние OLA, но и SLA, которые вы как клиент согласовали со своими собственными поставщиками. Эти SLA технически также являются OLA, которые поддерживают SLA, составленное с вашим собственным клиентом.

Мы вас не виним! Достаточно сильно усложнить процесс согласования SLA с вашими клиентами. Следовательно, понимание разницы между двумя типами соглашений чрезвычайно важно. Но сначала давайте посмотрим, что означает каждый тип соглашения, а затем углубимся в то, что отличает их.

Что такое SLA?

SLA предназначены для удовлетворения требований бизнес-уровня и управления бизнес-ожиданиями, например, как долго бизнес может ожидать, что услуга будет отключена, если произойдет сбой.

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

Соглашения об уровне обслуживания технологических компаний могут включать в себя обязательство по обеспечению бесперебойной работы сети на уровне 99.99%. Если этого не добиться, заказчик имеет право сократить свой платеж на определенный процент в зависимости от масштаба отключения. Если вы хотите узнать больше о том, как устанавливать, измерять и составлять отчеты об уровне обслуживания, посетите наш блог на 5 Практические советы по настройке, измерению и составлению отчетов об SLA.

Что такое OLA?

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

OLA четко определяют, какая группа в ИТ-отделе будет оказывать поддержку в рамках определенных границ SLA. OLA описывают такие вещи, как то, как служба поддержки должна реагировать на инциденты и запросы, какие протоколы должны использовать сервисные группы для запуска и запуска критически важных сервисов, какие Администраторы баз данных должны сделать для оптимизации баз данных, что команда настольных компьютеров должна сделать для исправления настольных систем и т. д.

В чем разница между SLA и OLA?

Ключевые различия между SLA и OLA заключаются в следующем:

2. SLA сосредоточены на сервисном аспекте соглашения, таком как время безотказной работы и производительность услуг. OLA, напротив, представляют собой обязательства по поддержанию службы.

3. SLA применимы к общему процессу разрешения заявок, в то время как OLA определены для отдельных групп поддержки, которым назначены заявки.

4. Соглашения об уровне эксплуатации носят более технический характер, чем соглашения об уровне обслуживания.

5. SLA связывает поставщиков услуг с клиентами, в отличие от OLA, поэтому SLA имеют большую целевую группу, чем OLA.

Давайте попробуем понять эти два термина в другом контексте.

Если вы хотите построить дом, соглашение между вами и генеральным подрядчиком будет представлять собой Соглашение об уровне обслуживания о том, что и когда нужно делать. Контракт, который генеральный подрядчик составляет со всеми своими рабочими и рабочими, будет соглашением об уровне эксплуатации.

Заключение

Соглашения об уровне обслуживания и соглашения об уровне эксплуатации важны для поставщиков услуг для управления предоставлением услуг и обеспечения удовлетворенности клиентов. Таким образом, организациям необходимо убедиться, что все имеющиеся соглашения согласованы и хорошо поддерживаются их внутренними командами.

SLA и OLA могут содержать похожие типы информации, но понимание разницы между ними обеспечит бесперебойное предоставление услуг.

Источник