Техподдержка на новый лад

Или пошаговое руководство для выстраивания процессов ITIL в команде сопровождения приложений

Поддерживаем бизнес-приложения по старинке

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

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

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

Идеальный сервис

https://youtu.be/9A5AGbUwig4

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

Что же в нем написано и как должна быть организована работа идеальной команды сопровождения бизнес-приложений?

Линии поддержки

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

Первая линия, колл-центр, Service Desk
Специалисты этой линии действуют как "Единая точка контакта" для всех пользователей. Им не нужно выбирать, куда нужно позвонить, если у них перестал печатать принтер или появилась ошибка в программе. Человек всегда звонит на один и тот же номер или пишет на один и тот же электронный адрес. При этом пользователь уверен, что трубку всегда поднимут, а на письмо – ответят. Это и есть один из основных показателей SLA – гарантированное время реакции на обращение пользователя.

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

Третья линия
Вот мы и добрались до тех специалистов, про которых шла речь в начале статьи. Именно они - аналитики, разработчики и специалисты по качеству - формируют третью линию, и до них так просто "не достучаться". Они отвечают за работоспособность бизнес-приложения, решают сложные задачи или занимаются развитием программного обеспечения. Чаще всего они делятся по специализации в каком-то конкретном программном обеспечении – Bitrix, 1C, Dynsmics AX, SAP, Cognos, BI.

Типы обращений

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

Управление инцидентами (Incident Management)
Инцидент – это любое событие, которое выходит за рамки стандартной работы. Инцидент вызывает или может вызвать незапланированное прерывание работы приложения или понижение качества его работы. Основной целью процесса управления инцидентами является восстановление стандартной работы в минимально возможные сроки и с наименьшими возможными последствиями как для бизнеса, так и для пользователя.

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

Управление запросами на обслуживание (Request Fulfillment Management)
Обращение — это запрос от пользователя, который заинтересован в подключении дополнительной услуги либо консультации. Обращениями считаются запросы, которые не требуют внесения изменений в программный код поддерживаемого приложения.

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

Управление запросами на изменение
Запрос на изменение – предложение от сотрудников на добавление, модификацию и удаление функционала поддерживаемого приложения.

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

Распределение обязанностей

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

Следующая таблица показывает распределение ответственности между линиями сопровождения

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

Критерии оценки качества услуг

Соглашение об уровне сервиса (Service Level Agreement, SLA) — это стандарты обслуживания пользователей, принятые в компании. Это касается времени реагирования и разрешения запросов от пользователей. SLA применяются ко всем типам обращений пользователей: к инцидентам, запросам на обслуживание и запросам на изменение, которые поступили от пользователей.

SLA - основной документ для планирования и оценки качества предоставляемого компанией сервиса.

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

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

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

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

• Время реакции — это время, в течение которого 1-я линия поддержки подтверждает, что поступивший запрос был взять в работу.
• Время восстановления – это время, в течение которого работа приложения будет восстановлена, и пользователь сможет подтвердить, что приложение функционирует удовлетворительно.
• Время полного восстановления— это время между регистрацией инцидента и полным восстановлением работы приложения. Если инцидент был связан с проблемой, то это время устранения проблемы.

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

Например, обращений с уровнем "критический" не должно быть больше 5% от общего объема заявок. В случае достижения этого показателя приоритеты всех следующих обращений автоматически понижаются на 1 уровень. Такая дополнительная мера позволяет управлять желаниями пользователей завышать приоритет своей задачи, и не дает группе сопровождения "захлебнуться" от срочных задач.

Покрытие
Покрытие является важной составляющей SLA и определяет сервисное время доступности линий техподдержки для пользователей.

Для решения сложных инцидентов специалисты третьей линии иногда могут предоставлять услугу "Дежурный инженер" (Technician on call, ToC). Она заключается в том, что из 3-ей линии техподдержки выделяется специалист, который готов по звонку 2-ой линии провести анализ проблемы и решить ее в установленное в SLA время.

Трансформация сервиса

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

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

Чтобы гарантировать своевременное выполнение работ, соответствие затрат и качества с вашими ожиданиями, снижение потенциальных и предполагаемых рисков компания ICL Services использует проверенную методологию перехода и трансформации. В этой методологии собраны признанные в отрасли стандарты, такие как ITIL V3, Prince2 и программы управления успехом (MSP), а также передовой опыт, разработанный ключевым партнером ГК ICL - компанией Fujitsu.

Суть этой методологии заключается в том, что переход оформляется как отдельный проект и выполняется в следующей последовательности:

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

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

Планирование инициирования и перехода

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

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

На этом этапе формируется реестр рисков, проблем и зависимостей.

Передача знаний

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

Задачи процесса передачи знаний – получить специфические знания, навыки и соответствующую документацию, относящиеся к ИТ-инфраструктуре, а также поддерживающие процессы и обучить этому будущую команду сопровождения.

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

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

Обычно фаза передачи знаний состоит из двух основных последовательных этапов:

• Встречи по передаче знаний,
• Внутренние встречи передачи знаний в команде.

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

Предоставление услуг при поддержке предыдущей командой

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

На данном этапе также формируется и заполняется чек-лист по приему сервиса.

Предоставление услуг с льготным периодом

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

Кроме этого, создается и адаптируется стандартный набор документации по проекту.

Полная готовность предоставления услуг

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

Заключение

Описанный выше подход, который применяется в компании ICL Services, позволяет выстроить оптимальный сервис по технической поддержке пользователей. Технология передачи сервиса или фреймворк, разработанный Fujitsu и адаптированный под российский рынок, позволяет планировать все до мелочей, а значит ничего не упустить при выстраивании грамотной и оперативной работы команды сопровождения.