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

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

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

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

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

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

Проблемы, также как и инциденты можно классифицировать:

· проблемы с сетью,

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

· проблемы с ПО,

· проблемы с оборудованием и т.д.

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

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

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

В соответствии с разделом 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.