Содержание:
1. Как оценить внутренние услуги и процессы. ITIL
2. ITIL: управление и оценка эффективности организации работы
Данная статья не предназначена для технических специалистов. Использованы неспецифические слова при описании. Статья рассчитана на более широкий круг читателей, а также руководителей среднего и высшего звена. На простых примерах показаны методологии оценки эффективности сервисных подразделений и описание качественных параметров для оценки эффективности.
1. Как оценить внутренние услуги и процессы. ITIL
Высокая зависимость бизнеса от сервисных подразделений заставляет менеджмент компаний искать методологии для оценки качества внутренних услуг, предоставляемых подразделениями. Де-факто все сервисные подразделения считаются убыточными, а качество предоставляемых услуг подвергается критике.
Для оценки услуг менеджмент выделяет как минимум три показателя:
1. Стоимость общего количества потребляемых внутренних услуг или оценка по методу «стоимость владения одним рабочим местом»
2. Качество предоставляемых услуг.
3. Планирование затрат на внутренние услуги (это не только текущие затраты, но и затраты направленные на улучшение качества услуг)
При оценки мы не берем для рассмотрения компании, где малый объем внутренних услуг. К примеру, стоит ли держать ИТ-специалиста при наличии 5 автоматизированных рабочих мест (АРМ), здесь ответ очевиден – аутсорсинг будет дешевле. А если АРМ более 100 или 300 или у вас есть цех, - какое количество электриков надо.
Для моделирования систем оценки нам требуется более четкие параметры. Практика показывает, что содержание и качество услуг подразделения информационных технологий вызывает вопросы в силу большого количества параметров и сложности понимания процессов ИТ. Здесь мы можем наблюдать высокие риски, связанные с информационными технологиями.
Рассмотрим существующие модели и их недостатки, исходя из накопленного практического опыта.
Первая модель использует показатели удовлетворенности внутренних клиентов и стоимость активов. Если взять среднюю оценку сервисных подразделений и стоимость активов. Ниже приведены две диаграммы. На первой - средняя оценка, на второй - стоимость активов. При увеличении стоимости активов в связи с расширением количества или изменении качественных показателей, можно наблюдать с небольшим временным разрывом в случае расширения сервиса или с большим временным разрывом при замене сервиса на сервис с более качественными показателями, пик удовлетворенности совпадает с увеличением стоимости активов. Данный метод имеет множество недостатков, так как оценка удовлетворенности — это эмоциональное измерение, и не имеет четких параметров. Здесь заложен риск неверной оценки при потере коммуникаций. Также этот метод не дает оценку экономической эффективности и планирования затрат.
Следующая модель основана на показателях доходности, затрат на сервисные подразделения и риск менеджмента. В данной модели рассчитывается процент затрат от общей доходности. При таком подходе мы стараемся снизить уровень затрат на сервисы с учетом экспертного мнения по рискам вследствие снижения уровня сервиса. По факту данная модель наследует недостатки предыдущей модели, а риск — это экспертная оценка, и возможны моменты возникновения оппортунизма.
2. ITIL: управление и оценка эффективности организации работы
Рассмотрим модель, использующую ITIL service (библиотека инфраструктуры информационных технологий) — библиотека, описывающая лучшие из применяемых на практике способов организации работы подразделений или компаний, занимающихся предоставлением услуг в области информационных технологий. Данная методология использует необходимые для оценки качества услуг показатели. Данная методология позволяет проследить за услугой на протяжении всего «жизненного цикла». Но кроме ИТ данная методология может использоваться для всех сервисных подразделений, чтобы определить эффективность внутренних работ.
Изучим, какими показателями качества оперирует данная методология.
К примеру, мы предполагаем, что при 90% доступности услуги в день наш бизнес не несет экономических потерь. В примере график работы 8 часов в день, 160 часов в месяц. 8 часов это 100%. Простой расчет дает нам, что 10% времени - это 48 минут в день, а 90% это 432 минуты в день. Для упрощения расчета: «всего рабочих дней» - 20 дней в месяц.
Для наглядности используем таблицу расчетов. Исходя из графика выше, нам доступно 8 часов или 480 минут времени, а 10% это 48 минут, до момента наступления риска экономических потерь.
Таким образом, мы имеем начальное значение в каждый рабочий день 48 минут или 0,5% недоступности услуги. При этом значении мы не имеем экономических потерь.
Первый показатель который рассмотрим это – «Допустимое время простоя». Допустимое время простоя - сумма времени простоя за период, за исключением простоев, вызванных следующими причинами:
1. Запланированным техническим обслуживанием по согласованию с заказчиком.
2. Неработоспособностью каналов связи и оборудования, находящихся вне зоны ответственности или контроля заказчика.
3. Приложения или компоненты заказчика неподконтрольные или неуправляемые Компанией, которые привели к невозможности оказать Услугу.
4. Деятельностью заказчика, его работниками, что привело к негативному воздействию на компоненты Услуги (нарушение правил использования Услуги и т. п.).
5. События, классифицируемые как форс-мажорные обстоятельства.
Таким образом наше суммарное время в день, когда услуга будет не оказана по нашей вине - 48 минут или 0,5% от общего времени за день, при котором мы не несем экономические потери.
Для данного показателя требуется определение недоступности услуги в день, при других параметрах недоступности услуги можно столкнуться с коллизией, когда услуга отсутствует 16 часов за один день, и показатель доступности услуги в допустимых пределах (10% от общего времени, но за месяц).
Для определения надежности (Reliability) - меры того, как долго услуга, компонент или конфигурационная единица может выполнять согласованную функцию без прерывания. Надежность услуги можно повысить двумя способами. Первый заключается в повышении устойчивости услуги к отказу отдельных компонентов, второй – в увеличении надежности отдельных компонентов. Обычно надежность измеряется с помощью двух показателей:
Показатель «Среднее время между системными инцидентами (MTBSI)».
Среднее время между системными инцидентами – Среднее время между инцидентами (от сбоя до следующего сбоя с одним типом конфигурационной единицы). Данный показатель регулирует время между инцидентами. Возвращаясь к времени в примере, для соблюдения предыдущего показателя нам требуется, чтобы события по недоступности проходили не чаще чем раз в один рабочий день. Переводя на время событие, которое длится 48 минут в день, должно повториться на следующий рабочий день и значит среднее время между инцидентами должно быть выше, чем 8 часов при этом мы не несем экономических потерь.
MTBSI в часах=Время доступности в часах/Количество сбоев
Показатель «Среднее время между сбоями (MTBF)»
Средняя продолжительность работы устройства между отказами. То есть показывает, какая наработка в среднем приходится на один отказ. Измеряется от начала работы до момента следующего сбоя. Выражается в часах.
где ti — наработка до наступления отказа i; m — число отказов.
Вычисляется методами теории надежности.
Показатель «Среднее время разрешения инцидента (MTTR)»
Среднее время, затраченное на ремонт конфигурационной единицы или услуги после сбоя. MTTR измеряется от момента выхода из строя конфигурационной единицы или услуги, до устранения причины отказа.
Показатель «Время реакции» - Мера времени, необходимого для выполнения операции или транзакции. Этот термин используется в управлении инцидентами как мера времени, необходимого для ответа по телефону или начала диагностики.
Показатель «Процент доступности услуги»
Для вычисления достигнутого уровня доступности необходимо знать время простоя (П) и время обещанной доступности (Д), в случае высокой доступности в это время не включается суммарное время запланированных простоев. Тогда уровень доступности можно получить по формуле:
доступность = (Д — П) / Д × 100 %
Как видим, данные показатели сильно зависят от времени работы и графика предоставления услуги.
Нельзя также упускать момент воздействия рисков и то, насколько проработаны документы по восстановлению работоспособности услуг.
Для уменьшения трансакционных издержек требуется проработка маршрутов движения заявок и их распределения по степени важности.
Несоблюдение параметров одного или нескольких показателей ведет к финансовым потерям.
Данная методология может быть применена не только для подразделений ИТ, но и для других подразделений, используя не все показатели. К примеру, автотранспортное подразделение может использовать практически весь набор показателей.
Накопленная статистика позволяет планировать затраты на поддержание услуг в будущем и находить ресурсы, которые используются не оптимально.
К недостаткам данной модели можно отнести то, что требуется специализированное программное обеспечение, поддерживающее методологию ITIL 1С, и высокая зависимость от персонала ИТ. Исходя из практических наработок, мы сталкиваемся с сопротивлением персонала при внедрении новых технологий, а в данном случае возникает проблема, когда подразделение должно внедрить программное обеспечение для контроля своей деятельности.
Все перечисленные модели обладают своими недостатками и достоинствами. Но высокая зависимость от информационных технологий заставляет все чаще задумываться над определением качества информационных услуг, а экономическая нестабильность подталкивает к подсчету стоимости этих услуг.
Консультант компании «Кодерлайн»
Александр Васецкий.
