 |
|
|
|
Практическая реализация проактивности при организации службы HelpDesk
Практическая реализация Статья посвящена вопросу повышения эффективности службы HelpDesk за счет более проактивной работы ее сотрудников. Предлагается использовать регламентные задачи, в рамках которых выполняются углубленный анализ проблем и выработка новых проактивных решений по улучшению ИТ-инфраструктуры. Передача до 30% объемов всех работ ИТ-службы на проактивные регламентные задачи в итоге приводит к суммарной экономии ресурсов и повышению качества обслуживания ИТ Введение Рекомендации ITSM по управлению информационными технологиями обращают внимание на вопрос достижения баланса между оптимизацией затрат и качеством работы службы технической поддержки. Объем предоставляемых ресурсов на техподдержку должен быть достаточным, чтобы обеспечивать требуемый уровень сервиса. Значительное увеличение финансирования может несущественно повысить качество работы, необходим поиск оптимального значения или баланса между затратами и качеством. Другой взгляд на данный вопрос, прописанный в рекомендациях, – это баланс между реактивностью и проактивностью. Проактивность понимается как постоянный поиск возможности улучшить текущую ситуацию, развить информационные технологии (ИТ) организации, оптимизировать затраты, повысить качество услуг. В противоположность проактивности ставится реактивность, ситуация, когда техподдержка начинает работать, только если происходит поломка или другой сбой. Рекомендации в общем случае не дают конкретных указаний по реализации проактивности и достижению баланса, ответ на этот вопрос ищет каждая служба информационных технологий самостоятельно. В данной статье на основе практического опыта предложены варианты организации работы службы техподдержки, в которой с помощью регламентных задач реализуется принцип проактивности. На примерах показано, как регулировать проактивность. Что рекомендует ITIL В соответствии с рекомендациями ITIL должен быть достигнут баланс при организации ИТ-службы между реактивностью и проактивностью [1, 2, 7] (рис. 1). Реактивная организация не действует, пока нет внешнего толчка – нового бизнес-требования. Суровая реальность, во многих организациях провальная ориентация на реактивное управление, заключается в обеспечении услуг, которые последовательны и стабильны, активно препятствуют проактивным действиям операционного персонала, направленного на улучшение.
Рисунок 1. Достижение баланса между реактивностью и проактивностью Проактивная организация ИТ-службы всегда ищет возможность улучшить текущую ситуацию. Последовательно проверяя ИТ-инфраструктуру, служба пытается обнаружить сигналы потенциально влияющих изменений. Проактивный подход обычно воспринимается как положительный, позволяет сохранять конкурентные преимущества. Тем не менее, являясь слишком проактивным, он может сделать ИТ-службу излишне дорогой. Необходимость правильного баланса между реактивным и проактивным подходом часто помогает достигнуть правильного результата. Рекомендации ITIL прямо не указывают на способы достижения проактивности, но теоретически предлагают два механизма. На рис. 2 показана последовательность сцепления процессов управления событиями, инцидентами, проблемами. Видно, что события, инциденты могут привести к формированию запроса на изменение, что, по сути, является проявлением проактивности. События, происходящие в ИТ-инфраструктуре, инициированные системами мониторинга или пользователями, анализируются и в случае выявления систематического понижения качества услуги (управления проблемами) перерастают в конкретные изменения через RFC (запрос на изменение).
Рисунок 2. Возникновение проактивности в процессах эксплуатации услуг Понятие проактивности в ITIL связано с разделом эксплуатации услуг, но также проактивность заложена в рекомендации в виде глобального цикла постоянного улучшения услуг, вкотором участвуют все разделы рекомендаций: стратегия, проектирование, предоставление, эксплуатация услуг. Однажды созданная услуга постоянно подвергается переосмыслению, изменяется, возможно, ликвидируется. Данный вид проактивности правильнее именовать стратегическим, так как он обеспечивает глобальные изменения ИТ ворганизации. Первый вид проактивности проявляется ежедневно, является операционной проактивностью. Операционная проактивность является источником информации и точкой инициации стратегической проактивности. Причины недостатка проактивности на практике Основная причина реактивного управления в большинстве ИТ-служб – это неполная реализация процессов эксплуатации услуг. Во-первых, не во всех ИТ-службах реализован процесс управления проблемами. Как правило, программное обеспечение HelpDesk не имеет реализации этого процесса или он урезан, неудобен. Для небольших организаций практикуется единая очередь заявок на инциденты, изменения, события, в лучшем случае производится категоризация [8]. Обычно используется функционал объединения похожих заявок, но это делается не для инициации проблемы, а для группового закрытия инцидентов. Процесс управления проблемами как основной источник проактивности чаще всего на практике все же выполняется, но его алгоритм существенно упрощен по сравнению стребованиями ITIL. Нет выделенных сотрудников, проблемы устраняют инженеры первой или второй линий, в целом данную деятельность правильнее отнести к реактивной, направленной на решение текущих проблем, а не предотвращение их возникновения в будущем. Главный вопрос: почему сотрудники должны быть инициативны и проактивны, чтоэто им дает в личном плане? Аргументация, что в будущем станет меньше проблем и заявок, на практике работает плохо. Рядовой сотрудник HelpDesk не заинтересован в улучшении ИТ-инфраструктуры, показатели процессов обычно не делают его проактивным. Ситуация с глобальной проактивностью выглядит хуже. Конечно, реализуются проекты по улучшению ИТ-инфраструктуры, но в редких случаях существует стратегия развития ИТ как главный систематизирующий инструмент. Положительно, что Project management – главный инструмент реализации стратегической проактивности – известен большинству специалистов. Рекомендации ITIL в общем случае дают определения, принципы разделов проектирования, преобразования услуг, постоянного улучшения, но в большинстве организаций стратегическая проактивность в ИТ носит не системный характер. Основной вывод в том, что вопросам реализации и управления проактивностью уделено недостаточное внимание. Вопрос в большей части остался на декларативном уровне, конкретная реализация – на совести каждой ИТ-службы. Когда возникает проактивность Понятие проактивности в ITIL тесно переплетается с инициативностью, профессиональным качеством каждого отдельного сотрудника. Важно понять, при каких условиях инициатива возникает. Если брать в расчет, что все сотрудники мотивированы выполнять меньше работы за большее вознаграждение, то инициатива или проактивность – это, посути, инциированная самостоятельно сотрудником деятельность по уменьшению его работы в будущем. Побочным эффектом является то, что ИТ начинает работать лучше. Если следовать такой логике, становится очевидно, что проактивность лучшим образом возникает в случае полного владения сотрудником объектом ИТ (рис. 3). Это может быть служба, сеть, сервис, сервер и т.д. Например, системный администратор контролирует сервер, следит за его работоспособностью, осуществляет превентивные меры (устанавливает обновления, проверяет бэкапы и т.д.). Сотрудник заинтересован в отсутствии проблем с таким сервером, он обслуживает большее количество серверов и, соответственно, получает высокое вознаграждение.
Рисунок 3. В подразделениях ИТ-службы, построенных по функциональному принципу, проактивности больше, чем в HelpDesk Далее, следуя логике для проактивности, всю ИТ-инфраструктуру нужно разбить на отдельные элементы и закрепить их за сотрудниками. Здесь возникают следующие затруднения:
В результате если следовать внутренней мотивации и инициативности сотрудников ради проактивности, то можно потерять бизнес-ориентированность – основную ценность большинства рекомендаций ITSM [3, 4, 6, 7] не только ITIL. То есть идея получения бонусов от работы конкретного элемента ИТ сотрудником выглядит провальной, но втрадиционном для ITIL стиле скажем, что должен быть найден баланс между различными подходами. Что на практике это значит? В грамотно организованной ИТ-службе мотивация сотрудников завязана на показатели процессов. В большинстве случаев это мотивирует к выполнению большего объема работы, что, например, в ситуации с разработкой ПО является положительным, а в ситуации эксплуатации услуг – отрицательным моментом. Если включить в мотивацию показатели отхорошей работы элементов ИТ, то автоматически включается проактивность, и не важно, много работает специалист или нет. Необходим баланс в мотивации сотрудников между показателями объемов работ и хорошей работы ИТ-элемента, не ухудшающих бизнес-ориентированность ИТ в целом. Другие способы повышения проактивности Для повышения проактивности можно двигаться по ранее обозначенному пути процессов эксплуатации услуг. Запуск этих процессов происходит в связи с событиями в ИТ-инфраструктуре. Можно циклически генерировать события или заявки, в которых будут прописаны задания, требующие проактивности. В принципе это давно известная идея регламентных задач, однако ее можно расширить до нового уровня. Технически реализация регламентных работ может быть построена на том же «движке» HelpDesk. По расписанию в систему вносятся заявки, которые автоматически или вручную назначаются сотрудникам второй линии (рис. 4). Содержание заявок формируется по шаблону, инициатором и принимающим выполнение заявки назначается ответственное за ИТ-инфраструктуру лицо, например ИТ-директор [5].
Рисунок 4. Повышение роли регламентных задач до отдельного направления работы ИТ-службы Большинство проактивных регламентных задач выполняется сотрудниками второй линии. Таким образом, удается приблизиться к концепции «владения» объектом ИТ, сотрудники второй линии в основном отвечают за конкретную подсистему. Периодическая генерация регламентной задачи заставляет сотрудника снова и снова возвращаться к вопросу оптимизации вверенного ему сервиса и службы, обратная связь возникает на этапе приемки задачи. Часть регламентных работ формулируется в традиционной манере «проверить», «очистить». Примеры проактивных заявок:
Данные примеры на первый взгляд не требуют большой инициативы, их добросовестная реализация вносит большую проактивность. Выполнение этих заданий можно свести кформальным процедурам (особенно второго), но, с другой стороны, их качественная проработка требует общения с пользователями. Формируя таким образом периодические регламентные задания и перенося часть работы с процессов управления проблемами, постоянного улучшения услуг, можно существенно систематизировать управление проактивностью. С позиции исполнителя такая заявка ничем не отличается от инцидента или проблемы, работает система показателей HelpDesk. То есть может быть применена та же система мотивации, что используется для обработки инцидентов и запросов. Важно, что появляется новая точка инициации работы – это периодическая генерация регламентной работы, приэтом можно регулировать объем регламентных работ, создавая, отменяя регламентные работы или меняя их расписание. Создается единая инфицированная среда HelpDesk дляреактивной и проактивной деятельности, появляется возможность регулировать баланс в ту или иную сторону. Ресурсное планирование ИТ-службы Более активное использование регламентных задач забирает существенную часть работы со службы HelpDesk [9] (рис. 4). Сотрудники в повседневной работе будут сбрасывать задачи анализа и улучшения на очередное регламентное задание, тем самым уменьшая операционную проактивность. С другой стороны, сотрудники профильных подразделений ИТ-службы будут теперь постоянно задействованы в регламентах, что на первый взгляд добавляет им работы. Уменьшится объем работы в рамках глобального процесса постоянного улучшения услуг. Сколько же работы в итоге станет: больше или меньше? Сразу стоит отметить, что такая постановка вопроса неверна в корне. Первоначально ставилась задача повысить проактивность и, как следствие, качество услуг, предоставляемых ИТ-службой, без резкого повышения объема ресурсов. Следующие практические наблюдения на ряде предприятий подтверждают этот факт, работы не стало меньше, но она перераспределилась между сотрудниками:
В итоге на регламентные работы может быть перенесено до 30% объемов работ всей ИТ-службы. Важно, что этот объем работ легко просчитывается, имеет предопределенный результат и в целом уменьшает степень хаоса в ИТ. Заключение На сегодняшний день мало информации и статистики по применению регламентных задач для управления проактивностью. Рекомендации ITSM часто носят размытый характер, конкретная реализация организационной структуры, процессов в каждой службе ИТ индивидуальные, это же касается вопроса проактивности. Реализованная на практике идея циклической генерации задач показала свою состоятельность, но важным здесь является правильная формулировка заданий и внимательная приемка результатов их выполнений. Почти всю работу ИТ-служба может сместить в сторону регламентных работ, однако это приведет только к росту штата. Должна быть найдена золотая середина или баланс по использованию этого механизма. Важно, что периодическая генерация однотипных заданий заставляет специалиста постоянно возвращаться к вопросу, что в конце концов сдвигает ранее не разрешимые задачи. Рассматривая результаты решения одной и той же задачи во времени, удобно отслеживать динамику изменений ИТ, анализ заявок и событий в HelpDesk не дает такой информативности.
Ключевые слова: информационные технологии, ИТ-менеджмент, ITSM, ITIL. Practical implementation of proactive service HelpDesk Lyubimov E.V., Ph.D., VSUES, Vladivostok, an assistant professor of mathematics and modeling Summary: Proactive work employees improves efficiency of HelpDesk service. Proposed to use a scheduled task, for advanced analysis of of problems and proactive development of new solutions to improve the IT infrastructure. Transfer up to 30% of the volume of work of IT department to proactive scheduled tasks eventually leads to saving of resources and improve the quality of IT services. Keywords: Information Technology, IT Management, ITSM, ITIL. |
ЛЮБИМОВ Е.В., к.т.н., ВГУЭС, Владивосток, доцент кафедры математики и моделирования
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
