Itil

Первое о чем стоит подумать при определении ключевых показателей (KPIs) - это для кого они предназначены.

Кто те заинтересованные лица, кому вы будете предоставлять отчеты? В описываемом случае мы хотели измерять последствия процесса улучшения, который планировался. Отчеты использовались менеджером процесса Управления изменениями (change manager), операционным менеджером (IT operations manager), офисом управления проектами и менеджерами процесса Управления уровнем обслуживанием (service level managers).

Мы поговорили с заинтересованными лицами, чтобы понять, что для них важно, и определили четыре критичных фактора успешности (critical success factors, CSFs) для процесса Управления изменениями (change management):

1. Защита бизнеса от негативного влияния последствий изменений

2. Поддержание скорости изменений, необходимой бизнесу

3. Предоставление знаний и информации о новых и изменяемых услугах, требуемых ИТ сотрудникам и бизнес персоналу

4. Рациональное использование ИТ ресурсов

Ваши факторы успешности (CSFs) могут значительно отличаться от озвученных, но вы должны быть готовы покащать их список вашим заинтересованным лицам. Еще один неплохой вариант, способный помочь найти ваши факторы успешности (CSFs), - примеры из книги ITIL Service Transition (но их тоже не стоит бездумно копировать).

Факторы успешности (CSFs) не могут быть точно измерены, но то, что более важно, они представляют собой фразы, с которыми согласны ваши стейкхолдеры, иони описывают результаты, ожидаемые от процесса Управления ИТ изменениями (change IT management).

Следующий шаг - определить не более 3 ключевых показателей результативности (KPIs), которые могут помочь понять достигнуты ли все критические факторы успешности (CSFs). Ключевые показатели (KPIs) однозначно не доказывают, что фактор успешности (CSF) достигнут, но помогают продемонстрировать, как хорошо выполнеятся то, что направлено на достижение фактора успешности (CSF). Вполне допустимо иметь один и тот же ключевой показатель (KPIs) в нескольких факторах успешности (CSFs), но важно, чтобы показателей не было много.

Пока мы обсуждали ключевые показатели (KPIs) для процесса Управления изменениями (change management) осознали, что необходимо улучшить качество данных об изменениях. Ранее каждое изменение помечалось, как успешное, и сотавалось таким до тех пор, пока его не возвращали на доработку, но это не давало нам информации достаточной для внедрения факторов успешности (CSFs). Мы решили оценивать каждое изменение на основе признаков:

• Было ли изменение полностью реализовано без необходимости возврата на доработку?

• Было ли изменение реализовано в заявленные при планировании время и ресурсы?

• Вызвало ли изменение инциденты?

• Обеспечило ли изменение результаты, на которые рассчитывал заказчик?

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

И теперь мы смогли определить ключевые показатели (KPIs), поддерживающие наши факторы успешности (CSFs)

CSF1 - Защита бизнеса от негативного влияния последствий изменений

• Уменьшать количество и долю изменений, которые вызывают инциденты

• Уменьшать общее влияние на бизнес от инцидентов, вызванных изменениями

CSF2 - Поддержание скорости изменений, необходимой бизнесу

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

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

• увеличение уровня удовлетворенности от процесса Управления изменениями (change management) у проектного офиса и конечных заказчиков

CSF3 - Предоставление знаний и информации о новых и изменяемых услугах, требуемых ИТ и бизнес персоналу

• увеличение доли изменений, по которым были предоставлены материалы в базе знаний для техподдержки (service desk)

• увеличение уровня удовлетворенности от процесса Управления изменениями (change management) у ИТ персонала и конечных заказчиков (я бы сюда поставил пользователей, но автору виднее)

CSF4 - Рациональное использование ИТ ресурсов

• увеличение числа и доли изменений, которые были реализованы за плановое время и с привлечением планового объема ресурсов

• уменьшение числа и доли срочных и аварийных изменений

В результате получили довольно небольшое количество ключевых показателей для измерения и отчетности, которые были сфокусированы на интересах и заботах заинтересованных лиц (stakeholders), а также способствовало пониманию нами результативности процесса улучшений, который мы планировали.

А когда вы последний раз пересматривали ключевые показатели (KPIs), используемые в процессе управления изменениями (change management)?
Почему бы не пересмотреть показатели и отчеты по ним, чтобы сделать их более полезными для вас и ваших стейкхолдеров?

У меня есть серия заметок о метриках (metrics) и ключевых показателях результативности (Key Performance Indicators, KPIs), для оценки нескольких областей Управления ИТ-услугами (IT service management). И они были очень популярны, т.к. посвящены теме, в которой многие людей ищут подсказки. Вот эти заметки:

• Как определить метрики для процесса Управления изменениями (перевод, оригинал)

• Как определить метрики для процесса Управления проблемами (перевод, оригинал)

• Как определить метрики для процесса Управления инцидентами (перевод, оригинал)

• Сбалансированная система показателей для ключевых показателей IT (перевод, оригинал)

На одну из них я получил запрос: А как насчет техподдержки?. Ниже мои мысли о том как можно посчитать техподдержку.

Рекомендуемая картина мира при определении метрик и ключевых показателей

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

Также стоит помнить о пересмотре ключевых показателей, это позволит со временем менять показатели, которые хорошо работали, а потом потеряли релевантность. Не забывайте, что K в KPI означает ключевой, так что вам стоит сконцентрироваться на наиболее важных для вас моментах. Вам не стоит измерять и отчитываться обо всем, что вы сможете измерить.

Также нужно прояснять понимание целей и критичных факторов успешности (Critical Success Factors, CSFs), которые необходимо выполнить, чтобы обеспечить достижение целей. Каждый ключевой показатель должен поддерживать одну или более целей или критичных факторов. Отчеты и обсуждения с заказчиками стоит вести о целях и критичных факторах, их поддерживающих, а не о ключевых показателях. I в KPI означает индикатор. Показатели - это не доказательство достижения цели, а всего лишь индикатор, помогающий понимать тренды и проблемы.

Цели и критичные факторы для техподдержки

Та что можно сделать для техподдержки? О чем в стоит думать? Я предлагаю несколько идей, которые могут быть включены, как цели или критичные факторы их достижения для техподдержки.

• Мы делаем для пользователей простым и удобных взаимодействие с нами, когда они обращаются для помощи, когда задают вопросы или когда мы предоставляем им информации о ходе работ

• Мы хорошо общаемся с нашими пользователями, поддерживаем их достаточным объемом информации и соответствуем их ожиданиям

• Мы решаем пользовательские инциденты быстро и эффективно

• Мы выполняем запросы на обслуживание быстро и эффективно

• Мы достигаем высокого уровня удовлетворенности заказчика

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

Я использовал термины цели или критичные факторы (objectives or CSFs) для обозначения высокоуровневых понятий. Мы провели бесконечное число обсуждений о разнице между двумя этими понятиями, но это не так уж и важно. Просто будьте уверены в том, что нашли то, о чем стоит заботиться. В идеале стоит остановиться на 3-6 целях или критичных факторах. Если будет больше, то отчеты будут слишком длинными и слишком размытыми.

• Мы делаем для пользователей простым и удобных взаимодействие с нами, когда они обращаются для помощи, когда задают вопросы или когда мы предоставляем им информации о ходе работ

  • все взаимодействия пользователи могут инициировать по телефону или через портал самообслуживания (Да/Нет)

  • процент телефонных звонков принятых в течение 30 секунд

  • процент непринятых телефонных звонков

  • результаты ответа на вопрос: Как проще всего связаться с IT, когда они нужны? в ежегодном опросе удовлетворенности заказчиков

• Мы хорошо общаемся с нашими пользователями, поддерживаем их достаточным объемом информации и соответствуем их ожиданиям

  • процент инцидентов, по которым пользователи запрашивали текущее состояние решения

  • процент инцидентов, возвращенных пользователем в работу после того, как техподдержка их закрыла

• Мы решаем пользовательские инциденты быстро и эффективно

  • процент инцидентов, решенных не хуже утвержденного уровня обслуживания (SLA)

  • процент инцидентов, решенных пользователями самостоятельно используя портал самообслуживания

  • процент инцидентов, решенных в течение первого контакта с пользователем.

• Мы выполняем запросы на обслуживание быстро и эффективно

  • процент запросов на обслуживание, выполненных не хуже утвержденного уровня обслуживания (SLA)

  • процент запросов на обслуживание, выполненных без ручных операций со стороны ИТ сотрудников

• Мы достигаем высокого уровня удовлетворенности заказчика

  • процент пользователей поставивших оценки 4 или 5 в опросе удовлетворенности результатом решения инцидента

  • увеличение удовлетворенности заказчиков работой техподдержки в ежегодном опросе удовлетворенности

Эти примеры ключевых показателей основаны на целях и критичных факторах для техподдержки. Их не стоит путать с более детальными ключевыми показателями, которые могут использоваться для измерения процесса Управления инцидентами (incident management process).Вам может также потребоваться несколько дополнительных внутренних ключевых показателей для измерения на сколько рационально техподдержка использует свои ресурсы, но это вряд ли будет интересно заказчикам (внутренним заказчикам это будет очень даже интересно).

Заключение

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

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

На российском рынке представлен большой выбор help desk систем, которые позволяют автоматизировать процессы постпродажного обслуживания. С одной стороны, это хорошо, так как у каждой компании есть возможность подобрать решение для своего бизнеса и под свои задачи. С другой стороны, возникает путаница в том, для чего предназначен тот или иной helpdesk. Какой выбрать? В попытке протестировать все системы, который выдал поисковик, уходит много времени и сил, а на выходе результат не всегда получается даже удовлетворительным.

Чтобы облегчить этот выбор, я сгруппировал типы поддержки и help desk системы, предназначенные для автоматизации каждого вида обслуживания.Надеюсь, это поможет каждому из вас, как минимум, не потратить время "впустую".

Зачем вообще нужны Help Desk системы? Есть ли результат?

Прежде чем обсуждать типы поддержки и автоматизацию задач внутри "каждого" из них, стоит задуматься, а стоит ли вообще заниматься саппортом и как-то его автоматизировать?

По данным Teleperformance Customer Experience Lab, клиенты на 13% будут лояльнее к компании, если у них будет позитивный опыт взаимодействия с ее техподдержкой. Если негативный опыт, есть вероятность, что лояльность клиентов снизится на 27%.

Согласно всероссийскому отраслевому исследованию, проведенного Okdesk в этом году, почти 60% компаний утверждают, что их клиенты отказываются от продолжения сотрудничества из-за некачественного сервиса. При этом у 69,7% компаний доля выручки от сервисного обслуживания составляет от 10% до 25%.

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

Типы поддержки и разница в задачах, подходах и автоматизации

В чем различие между типами поддержки? Какие задачи возникают при их автоматизации? Какие для этого есть системы на рынке? Давайте разбираться.

На верхнем уровне можно выделить два вида поддержки:

1. Внутренняя.

2. Внешняя.

При этом внешнюю поддержку можно условно разделить на:

• работу в сегменте B2С (с "анонимусами");

• взаимодействие с B2B-клиентами.

Специфика "внутренних" пользователей или ИТ-поддержка

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

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

Внутренняя поддержка зародилась в ИТ-департаментах. Именно по этой причине в организации процессов сервисного управления во всем мире используют подход ITSM(Information Technology Service Management). Он основан на базе передового опыта сервисного обслуживания внутри предприятия (Information Technology Infrastructure Library, ITIL).

Системы автоматизации внутренней техподдержки соответствуют процессам и практикам, которые описаны в ITIL. По крайней мере, так заявляют их разработчики. Существуют даже сертификации систем на соответствие ITIL.

Однако автоматизация внутренней поддержки по канонам (с CMDB, ресурсно-сервисной моделью и т.д.) актуальна и, главное, даёт результат на больших масштабах, то есть, только для крупных компаний (более 1000 сотрудников). Системы, которые соответствуют процессам ITIL, для среднего и малого бизнеса не подойдут: излишне функциональны, дорогие и требуют серьезных организационных изменений.При этом ничего не мешает использовать Help Desk системы для внутренней автоматизации более гуманные по ценнику и решающие бОльший пласт задач небольших организаций.

Если вы представляете крупную компанию, тогда советую вам ограничить выбор среди таких решений, как Omnitracker, HP Service Manager, BMC Remedy ITSM, Naumen Service Desk. Более дешевые варианты: OTRS, ITSM 365 и 1С:ITIL.

Внешняя B2С поддержка или Customer Service

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

Основные задачи поддержки B2С-клиентов можно сформулировать так:

• фиксировать заявки по всем возможным каналам, включая соцсети и мессенджеры;

• иметь инструменты, которые позволят автоматизировать решение типовых и простых вопросов;

• отслеживать клиентскую лояльность.

Именно по этой причине Help Desk системы автоматизации Customer Service созданы для регистрации заявок из всех возможных каналов обращений (соцсети, мессенджеры и т. д.) и быстрой выдачи шаблонных ответов. Для последнего используют чат-ботов с типовыми сценариями вопросов-ответов и/или базу знаний.

Предлагаю обратить внимание на лидеров этого сегмента: Zendesk, Freshdesk, Kayako, Help Scout и Omnidesk.

Внешняя B2B поддержка и обслуживание клиентской инфраструктуры

В поддержке B2B-клиентов всё сложнее: нужно вести базу заказчиков, привязывать к ним все их заявки. Также необходимо учитывать договоры с клиентами, обслуживаемые объекты (в зависимости от бизнеса это может быть точка продаж, сайт, офис или даже транспортное средство), оборудование и ПО.

Почти каждая клиентская заявка не типовая и потому её выполнение имеет более сложный цикл. Бывает, что для решения проблемы компания привлекает подрядчика по сервисному обслуживанию. Тот в свою очередь может привлечь субподрядчика или самого производителя или разработчика. К тому же возникают ситуации, когда какие-то работы нужно оказывать за рамками договора и это биллингуется отдельно. А еще нужно планировать загрузку специалистов. При этом в случае выездного обслуживания (field service management) распределять заявки на ближайшего.

Именно поэтому в системах автоматизации B2B-поддержки критическое значение имеют:

• встроенные и готовые отчеты по множеству метрик работы бизнеса;

• блок учета платных работ, выходящих за рамки абонентского или договорного обслуживания;

• более проработанный блок отслеживания обязательств и договоренностей по контрактам (SLA) в привязке к клиенту, объекту или с более сложной логикой;

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

• настраиваемые чек-листы по сложным, но повторяющимся заявкам;

• развитое API для реализации специализированных интеграций.

Поддержку B2B-клиентов можно разделить на удаленную и выездную. Удаленную поддержку оказывают вендоры своим клиентам и партнерам, сервисные компании, которые обслуживают ПО (например, франчайзи 1С).

Выездное обслуживание преимущественно связано с поддержкой и обеспечением работоспособности самой разной инфраструктуры: от светофоров, датчиков уровня топлива и телематического оборудования до кассовых аппаратов, охранно-пожарных систем.

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

Для удаленной и выездной B2B-поддержки обратите внимание на Jobber, Mhelpdesk и Service Fusion. Из отечественных на лидирующее решение Okdesk.

Вместо заключения

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