Организация процесса управления проблемами для интернет-магазина цифровой техники

В соответствии с разделом ITSM [7] входами процесса «Управление проблемами» являются:

·                     Инцидент,

·                     Сведения об инфраструктуре,

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

Выходы процесса «Управление проблемами»

·                     Записи о проблемах и известных ошибках,

·                     Обходные решения,

·                     Решенные проблемы,

·                     Отчеты.

Виды деятельности, осуществляемые в рамках процесса «Управление проблемами»:

·                   Контроль проблем – заключается в идентификация и записи проблем; их классификации; расследовании и диагностики.

·                   Контроль ошибок – оценка известных ошибок; запись о ходе разрешения ошибок; закрытие ошибок; мониторинг проблем и прогресса разрешения ошибок.

·                   Проактивное управление проблемами - анализ тенденций; анализ инфраструктуры; направление действий по предотвращению; обеспечение организации информацией.

·                   Отчетность – подготовка аналитических отчетов по выполненным работам.

Таблица 3 Основные роли для процесса управления проблемами:

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

При отказе от внедрения процесса «Управление проблемами» возможны ситуации как:

·                     служба ServiceDesk работает только по принципу реагирования и устраняет проблемы когда предоставление услуги пользователю прервано,

·                     Пользователи ИТ сталкиваются с повторяющимися инцидентами и теряют доверие к качеству ServiceDesk

·                     ServiceDesk становится неэффективной, так как требуется разрешение повторяющихся инцидентов и структурные решения не внедряются.

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

3. Совершенствование процессов управления ИТ организации

3.1 Организация процессов управления ИТ

Как упоминалось ранее процессы управления ИТ интернет-магазина цифровой техники следующие:

·                   Техническая поддержка пользователей,

·                   Управление информационной безопасностью,

·                   Управление контентом,

·                   Модернизация и развитие.

Т.к. размер бизнеса компании небольшой, то эти процессы выполняются ИТ-подразделением, состоящим из ИТ-директора, системного администратора и контент-менеджера. Очевидно, что существующим процессам необходимо совершенствование, а также внедрение новых процессов. Процесс «Управление проблемами» является новым для компании «Рентген», поэтому он должен разрабатываться в соответствии со стандартом ГОСТ ИСО/МЭК 20000:2005 «Управление услугами» [1,2]. Стандарт состоит из двух частей: 1 часть - описание требований к системе менеджмента ИТ-сервисов; 2 часть - практические рекомендации по процессам, требования к которым сформулированы в первой части. Является руководством для аудиторов и компаний, намеренных пройти сертификацию.

Согласно ГОСТ ИСО/МЭК 20000:2005 определены 13 процессов, которые объединены в пять групп (схема взаимосвязи этих процессов представлена на рисунке 9):

·                   Предоставление сервисов (Service delivery process);

·                   Процессы взаимоотношений (Relationship processes);

·                   Процессы решения (Resolution processes);

·                   Процессы контроля (Control processes);

·                   Процессы релиза (Release process).

Рис.9. Процессы управления услугами по ГОСТ ИСО/МЭК 20000:2005

Разрабатываемый процесс управления проблемами входит в третью группу вместе с процессом управления инцидентами. Конечно, все процессы управления ИТ, прописанные в стандарте здесь внедрить будет сложно и дорогостояще. Поэтому первоначально нужно внедрение процессов «Управления проблемами», «Управления бесперебойностью предоставления и доступностью услуг», «Управления отношениями с потребителями», а также «Управление конфигурациями» и «Управление изменениями». Схема этих процессов представлена на рис.10.

Рис.10. Процессы управления услугами

Цели процессов представлены в таблице 4.

Таблица 4 Цели процессов управления услугами

3.2 Совершенствование процесса «управление проблемами»

Для организации процесса управления проблемами, во-первых, необходимо усовершенствование Технической поддержки до процесса «Управление инцидентами» (схема этого процесса представлена на рис.6 в Приложении). Как видно из схемы после регистрации заявки в базе SD, она классифицируется, ей задается приоритета, в соответствии с которым она выполняется, все действия по ее решению заносятся в базу SD, если инцидент не решен, то руководство информируется о невозможности выполнения и все данные также заносятся в базу. Таким образом, будет пополняться база сбоев, что будет являться источником информации для дальнейшей организации проактивного управления проблемами.

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

·                     снижение количества инцидентов по сравнению с предыдущим отчетным периодом;

·                     снижение суммарного ущерба от инцидентов, также по сравнению с предыдущим отчетным периодом.

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

·                   количество зарегистрированных проблем,

·                   количество закрытых проблем,

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

·                   ожидаемое время устранения открытых проблем;

·                   общее затраченное время на все закрытые проблемы.

В соответствии с разделом ITSM [6,7] и ГОСТ ИСО/МЭК 20000:2005 [2] описываемый процесс управления проблемами должен включать в себя следующие деятельности:

·                   Контроль проблем (заключается в идентификации и записи проблем; их классификации; расследовании и диагностики);

·                   Контроль ошибок (оценка известных ошибок; запись о ходе разрешения ошибок; закрытие ошибок; мониторинг проблем и прогресса разрешения ошибок);

·                   Предотвращение проблем (анализ тенденций; анализ инфраструктуры; направление действий по предотвращению; обеспечение организации информацией)

·                   Отчетность (подготовка аналитических отчетов по выполненным работам)

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

Рис.11. Диаграмма цепочки добавленного качества для Процесса управления проблемами.

3.3 Организация управления ресурсами

Имеющиеся процессы управления ИТ выполняют сотрудники ИТ-отдела: ИТ-директор, системный администратор и контент-менеджер. Для внедрения процесса «Управления проблемами» потребуется найм, как минимум, еще одного сотрудника, который будет выполнять функции менеджера по проблемам. Как уже упоминалось, в ITIL этот процесс один из самых дорогостоящих, потому что требует найма квалифицированных специалистов (серьезных аналитиков, имеющих высокую квалификацию сразу в нескольких областях ИТ).

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

Затраты на ежемесячное обслуживание процесса «Управление проблемами» будут складываться из зарплаты менеджера по проблемам и затрат на изменения в ИТ-инфраструктуре, которые требуются для предотражения и решения проблем (например, покупка более мощного сервера, обновление ПО, модернизация оборудования). Но такие затраты сложно просчитать, поэтому в таблице 3 представлены затраты на внедрение этого процесса.

Таблица 5 Затраты на внедрение процесса управления проблемами

При успешном внедрении этого процесса затраты (и временные, и материальные) на разрешение инцидентов должны существенно снизиться. Основной упор будет сделан именно на предотвращение проблем, не допуская возникновения инцидентов. Естественно, экономический эффект от внедрения этого процесса можно будет увидеть только спустя время (от 5-6 месяцев), только после того как будет налажена работа по управлению инцидентами и проблемами. Будет значительно сокращено время простоев пользователей, соответственно, экономия от стоимости простоев пользователей будет значительной.

Примерный расчет (по средним значениям) затрат на каждый подпроцесс представлен далее.

Таблица 6 Стоимостной анализ подпроцесса «Предотвращение проблем»

Таблица 7 Стоимостной анализ подпроцесса «Контроль ошибок»

Таблица 8 Стоимостной анализ подпроцесса «Контроль проблем»

Все данные можно свести в итоговую таблицу.

Таблица 9 Итоговая таблица затрат на процесс «Управление проблемами»

Таким образом стоимость ведения процесса «Управление проблемами» вместе с внедрением составит 70000+697000=767000 руб.

Страницы: 1, 2, 3, 4