Поделиться
Как заставить OLA работать
Разработка соглашений о предоставлении услуг на операционном уровне базируется на формировании списка инцидентов, определении сроков решения проблем, мониторинге устранения инцидентов и мотивации сотрудников на выполнение этих работ. Чтобы получать 100-процентную отдачу от услуг технического сопровождения, необходимо составить 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
Большое значение имеет то, как часто специалисты технического сопровождения будут привлекать к устранению инцидентов сотрудников производства. Список инцидентов в OLA и SLA один и тот же, но не всякий инцидент возникает из-за ошибки или сбоя программы, поэтому не в каждом случае необходимо привлекать к его устранению сотрудников производства. Создать какие-либо простые правила, которые являлись бы сигналом для привлечения / не привлечения производства к решению инцидента, невозможно. Попытка ввести ограничения по мощности (например, десяток инцидентов производство гарантированно устраняет в срок, а остальные – как получится) является, по сути, неким самоуспокаивающим средством, поскольку вроде бы соглашение OLA соблюдается, но клиент все равно в итоге отказывается от сопровождения, ибо возникший у него инцидент не устранили в срок. Однако показатель мощности все же желательно ввести, но он должен стать индикатором для сотрудников технического сопровождения. Значение показателя мощности должно сигнализировать техподдержке, что не стоит сваливать на производство решение всех инцидентов, передавать нужно только те, с которыми самостоятельно точно не справиться. Кроме того, нужно оказывать моральное воздействие на сотрудников, время от времени доводя информацию о том, что не стоит производство "перегружать" работами по обеспечению технического сопровождения, поскольку это может привести к снижению возможностей в других работах, в частности, развитии продукта, что является ключевым бизнес-процессом.
Короткая ссылка
