Организация процесса управления проблемами для интернет-магазина цифровой техники»
Студент
Воронцова Мария Леонидовна
Руководитель Казаков В.А.
Содержание
Введение
1. Описание предметной области
1.1 Общая характеристика организации
1.2 Описание информационной системы и ИТ-инфраструктуры организации
1.3 Необходимость совершенствования системы управления ИТ
2. Теории и практики построения системы управления ИТ
2.1 Общая характеристика процессного подхода
2.2 Теория и практика управления ИТ
2.3 Место процесса «управление проблемами» в управлении ИТ
3. Совершенствование процессов управления ИТ организации
3.1 Организация процессов управления ИТ
3.2 Совершенствование процесса «управление проблемами»
3.3 Организация управления ресурсами
3.4 Организация системы документации
Заключение
Список использованной литературы
Приложения
Введение
управление проблема информационная интернет
В нашей стране наиболее распространенный пример применения передового опыта ITIL – это создание в компаниях служб Help Desk и процессов управления инцидентами. Под этим подразумевается техническая поддержка пользователей и существующей ИТ-инфраструктуры.
Но этот процесс осуществляется уже тогда, когда инциденты произошли и нужно поскорее восстановить работоспособность и нейтрализовать последствия от возникших сбоев. Многие компании на этом и останавливаются, считая достаточным для нормального ведения своей деятельности. Но ведь не всегда последствия от уже случившихся инцидентов можно устранить безболезненно или с малыми потерями для бизнеса, поэтому намного перспективнее предвидеть и предотвращать проявление таких инцидентов. Потому что, если возник инцидент, значит, ему предшествовала какая-то причина и нужно эту причину найти и ликвидировать.
Конечно, инциденты разрешаются, но множество из них продолжают происходить изо дня в день. Совокупность упорядоченных действий по предвидению или обнаружению, идентификации, анализу и ликвидации корневых причин возникновения инцидентов и является областью деятельности процесса управления проблемами. Т.е. такая деятельность направлена не на быстрое устранение неполадок, а на обеспечение большего времени бесперебойной работы. В этом и заключается актуальность такого понятия, как управление проблемами.
Цель данной работы – выявить преимущества, которые можно получить после внедрения в небольшой организации процесса управления проблемами. А также разработать организацию этого процесса применительно к выбранной предметной области.
1. Описание предметной области
1.1 Общая характеристика организации
ООО «Рентген» - интернет-магазин, специализирующийся на продажах цифровой техники и сопутствующих товаров по доступным ценам, а также предоставляющий услуги по консультированию покупателей, сборке, настройке и обслуживанию оборудования.
У компании есть собственные склад и служба доставки, осуществляющая свою работу по Москве и МО. Доставка в другие регионы осуществляется Почтой России и транспортными компаниями-партнерами.
Таблица 1. Характеристика бизнеса интернет-магазина
| Характеристика бизнеса: | |
| Размер | средний |
| Количество сотрудников | ≈ 50 |
| Объем продаж | $ 2 млн. в год |
Компания имеет организационную структуру, представленную на рисунке ниже.
Рис.1. Организационная структура компании
Клиентами компании являются частные лица, имеющие доступ в интернет и находящихся в пределах зоны доставки.
Поставщиками являются компании, занимающиеся поставками и производством электроники.
Основные партнерами компании являются транспортные компании, Почта России, EMS, сервис-компании.
Основные конкуренты компании – это крупные интернет магазины электроники, такие как ОЗОН, плеер.ру, а также крупные гипермаркеты электроники: МедиаМаркт, М.Видео, Техносила, Эльдорадо.
Миссия компании: предоставить нашим клиентам качественную цифровую технику, чтобы удовлетворить даже самые требовательные запросы.
Стратегия компании: закрепить свои позиции на рынке интернет-продаж цифровой техники, потеснить основных конкурентов. Стратегические цели компании представлены на рис.1 в Приложении.
1.2 Описание информационной системы и ИТ-инфраструктуры организации
ИТ-подразделение интернет-магазина «Рентген» небольшое, его главная функция в обеспечении работоспособности и нормального функционирования остальных бизнес-процессов компании. ИТ-подразделение представлено следующими сотрудниками: ИТ-директор, системный администратор и контент-менеджер.
ИТ-инфраструктура интернет-магазина «Рентген» представлена на рис.2. Согласно схеме имеется 2 сервера: на одном установлены информационные системы от 1С, другой сервер занимается организацией сети и доступом к интернету, на нем находится сервер домена, firewall, почтовый сервер, стоит CMS-система 1С-Битрикс. Пользовательские компьютеры используются трех типов: стационарные компьютеры, ноутбуки, КПК. Курьеры имеют WEB-доступ к 1С с КПК.
Рис.2. Схема ИТ-инфраструктуры
Каждое подразделение компании участвует в выполнении определенного перечня бизнес-процессов. Для автоматизации этих бизнес-процессов в компании используются следующие информационные системы:
· «1С:Предприятие 8.1. Бухгалтерия»,
· «1С:Предприятие 8.1. Торговля и склад»,
· «1С:Предприятие 8.1. Зарплата и кадры».
Сайт компании реализован на базе CMS-системы «1С-Битрикс» и поддерживается собственным контент-менеджером.
Служба технической поддержки пользователей Help Desk ведется с помощью программы Hardware Inspector Service Desk v1.1.0.
На рабочих местах пользователей стоит ОС MS Windows 7, на сервере MS Windows Server 2008 R2. Антивирусное ПО – Eset NOD32. В качестве пакета офисных приложений используется MS Office 2007. Информационно-правовое обеспечение представлено системой Консультант Плюс. Схема информационной системы интернет-магазина «Рентген» представлена на рис.3.
Рис.3. Информационные системы интернет-магазина «Рентген»
1.3 Необходимость совершенствования системы управления ИТ
В компании «Рентген» процессы управления ИТ следующие:
· Техническая поддержка пользователей,
· Управление информационной безопасностью,
· Управление контентом,
· Модернизация и развитие.
Управлением контентом занимаются контент-менеджеры. Они следят за базой товаров сайта, добавляют новые товары и их описание, обновляют данные о наличии и поступлении товаров.
Информационной безопасностью занимаются ИТ-директор и системный администратор, они разрабатывает политику безопасности, следят за обстановкой в ИТ-среде компании.
Также ИТ-директор вместе с системным администратором занимаются разработкой и внедрением планов модернизаций оборудования и ПО.
Техническая поддержка пользователей представляет собой следующее: системный администратор принимает заявки от пользователей, регистрирует их в базе SD и пытается как можно быстрее устранить последствия таких непредвиденных ситуаций, затем он заносит в базу SD результаты своих действий. Также системный администратор выполняет периодический мониторинг ИТ-инфраструктуры с целью выявления причин возможных инцидентов, при их обнаружении формирует и регистрирует заявки в базе SD. По своей сути, данный процесс представляет собой упрощенный «Процесс управления инцидентами». Его схема в нотации EPC представлена на рис.2 в Приложении.
Как видно из схемы этот процесс несовершенен. В основном, происходят инциденты, а затем выполняются действия по устранению последствий инцидентов с целью минимизировать их влияние на бизнес. Естественно, не всегда получается выполнять такие действия в кратчайшие сроки, а некоторые инциденты имеют тенденцию достаточно часто повторяться, поэтому необходима выработка комплекса мероприятий по предотвращению и прогнозированию таких ситуаций. Для проведения таких мероприятий, по крайней мере, нужен еще сотрудник.
2. Теории и практики построения системы управления ИТ
2.1 Общая характеристика процессного подхода
Процессный подход является важнейшим признаком совершенного управления. Процессом называют совокупность взаимосвязанных и взаимодействующих видов деятельности, которая преобразует входы в выходы (ИСО 9000:2000). Выход процесса (продукт) обладает ценностью для потребителя. Когда говорят о процессном подходе, имеют в виду, прежде всего то, что управление процессом и каждой из входящих в него работ (деятельностью, подпроцессом, процессом второго или последующих уровней или функцией) происходит с применением особых методических приемов, достаточно хорошо разработанных и позволяющих исключить многие ошибки.
Как правило, руководство ожидает от применения процессного подхода к управлению решение следующих основных проблем:
· Снижение издержек;
· Повышение рентабельности;
· Повышение управляемости (улучшение системы отчетности компании, создание прозрачной системы управления, ускорение процедур принятия управленческих решений);
· Снижение влияния человеческого фактора при управлении компанией.
В основе процессного подхода к управлению организацией лежит выделение в организации бизнес-процессов и управление этими бизнес-процессами.
Для всех типов организаций самой актуальной задачей является построение эффективной системы менеджмента, которая будет обеспечивать выполнение задач организации и достижение успеха во внешней среде.
Построить любую систему управления можно только на основе однозначно определенных объектов, из которых она будет состоять. Самыми главными объектами в любой системе управления являются «Объект управления» - то, чем управляют, и «Субъект управления» - тот, кто управляет. Соответственно, для системы процессного управления эти объекты определяются терминами «Процесс» и «Владелец процесса».
Выделяют три основных группы процессов:
· сквозные (межфункциональные) процессы, проходящие через несколько подразделений организации или через всю организацию, пересекающие границы функциональных подразделений;
· процессы (внутрифункциональные) и подпроцессы подразделений, деятельность которых ограничена рамками одного функционального подразделения организации;
· операции (функции) самого нижнего уровня декомпозиции деятельности организации, как правило, выполняются одним человеком.
Термин «подпроцесс» используется в тех случаях, когда требуется рассмотреть процесс более, подробно как совокупность составляющих его подпроцессов.
Поскольку процессы или подпроцессы по своей сути являются действиями, то для обозначения этих действий необходимо, чтобы названия процессов, подпроцессов (или функций) были выражены глаголом или отглагольным существительным, например, «Процесс производства», «Процесс продаж».
Для управления процессом необходимо назначить должностное лицо, ответственное за выполнение процесса и его результат. Чтобы должностное лицо могло управлять процессом, в его распоряжение должны быть выделены ресурсы, необходимые для проведения процесса, делегированы права и полномочия. Каждый процесс существует не сам по себе, а выполняет какие либо функции в организации и является подконтрольным высшему руководству организации. Поскольку в ряде случаев процессом может управлять не один сотрудник, а коллегиальный орган управления, то определение владельца процесса будет следующим:
Владелец процесса - это должностное лицо или коллегиальный орган управления, имеющий в своем распоряжении ресурсы, необходимые для выполнения процесса, и несущий ответственность за результат процесса. Владелец процесса ведет управление процессом и является неотъемлемой составной частью процесса.
Вход процесса - продукт, который в ходе выполнения процесса преобразуется в выход. Вход всегда должен иметь своего поставщика. К входам процесса могут относиться: сырье, материалы, полуфабрикаты, документация, информация, персонал (для процесса «Обеспечение кадрами»), услуги и т.д.
Входы процесса:
- поступают в процесс извне;
- их объем планируется на один или несколько циклов работы процесса, или выпуск определенного объема продукта.
Выход процесса (продукт) - материальный или информационный объект или услуга, являющийся результатом выполнения процесса, потребляемый внешними по отношению к процессу клиентами. Выход процесса всегда имеет потребителя. В случае если потребителем является другой процесс, то для него этот выход является входом. Выход (продукт) процесса также может использоваться в качестве ресурса при выполнении другого процесса. К выходам процесса могут относиться: готовая продукция, документация, информация, в т. ч. отчетная, персонал, услуги и т.д.
Ресурс процесса - материальный или информационный объект, постоянно используемый для выполнения процесса, но не являющийся входом процесса.
Помимо лиц, ответственных за результаты процесса, его входов и выходов, важны также параметры процесса. Различают качественные и количественные параметры бизнес-процесса. Качественные параметры – это результативность (т.е. соотношение полученного результата с ожидаемым), эффективность (показывает насколько хорошо выполняются процессы) и адаптируемость (говорит о том, насколько хорошо процесс способен реагировать на изменения внешней среды). Количественные же параметры процесса – это его производительность (отношение количества единиц на выходе к количеству единиц на входе), продолжительность (время от начала процесса до его завершения), стоимость для бизнеса (другими словами, совокупность затрат для однократного выполнения процесса), а также количество его входов и выходов.
Однако, этого недостаточно, т.к. без измерения основных (ключевых) показателей эффективности невозможно управлять работающим процессом. Для каждого внедряемого процесса следует выработать набор метрик, определяющих состояние процесса, успехи и неудачи, узкие места. Метрики должны количественно демонстрировать степень продвижения к цели процесса и быть более конкретными и нацеленными на краткосрочную перспективу, а не только на долгосрочную.
Но в современных реалиях до сих пор, фактически, господствует функциональный подход. Считается, что фирма - это некий механизм, который обладает набором функций. Эти функции распределяются среди подразделений, где их исполняют сотрудники предприятия. Выполняя свои узкоспециальные задачи, сотрудники перестают видеть конечные результаты труда всего предприятия и осознавать свое место в общей цепочке. Такая система заставляет персонал хорошо исполнять функции, но не ориентирует на достижение результата. А ведь именно результативность – главная мера успеха бизнеса. Разные отделы взаимодействуют, передают работу друг другу по этапам, и зачастую на взаимодействие между подразделениями уходит больше времени, чем на выполнение собственно работы, так как представители одного подразделения не заинтересованы в эффективном сотрудничестве с представителями соседнего. Поэтому применение процессного подхода к управлению – очень перспективная задача.
В дополнение к вышесказанному суть процессного подхода заключается в том, что деятельность любой организации представляет собой цепочку процессов от маркетинга, планирования, до продажи и послепродажного обслуживания. Однако, обычное графическое (например, в виде схемы) или текстовое (например, в виде инструкции) описание последовательности выполняемых работ не является процессным подходом. Потому что для любого процесса, помимо технологии выполнения, должны быть определены требования к входам и выходам, требования к используемым ресурсам (персонал, оборудование, инструменты, производственная среда, информация и т.д.), критерии оценки результативности процесса и удовлетворенности его клиентов. Для каждого из процессов должен быть определен "владелец", который будет отвечать за результативность процесса.
А самое главное - прежде чем представить какую-либо деятельность как процесс, необходимо убедиться, что эта деятельность приносит компании добавленную ценность (то есть, во-первых, результат деятельности представляет ценность для клиента, и во-вторых, эта деятельность целесообразна с точки зрения затрат на ее осуществление).
2.2 Теория и практика управления ИТ
В настоящее время развиваются и появляются новые подходы и методы к управлению ИТ. Центральными темами обсуждений новых подходов стали - контроль, процессы и сервисы, выполнение нормативных требований. Поэтому новые методы управления ИТ идут рука об руку со сферой управления ИТ сервисами.
Управление ИТ сервисами относится к обеспечению качества услуг, воспринимаемого пользователями, выполнению требований договоров и созданию для бизнеса конкурентных преимуществ, основанных на качестве.
Новые же методы управления в области ИТ больше концентрируются на обеспечении внешних условий функционирования (информационная безопасность, нормативные акты), а также проектного и финансового управления. И если ещё вчера ИТ директор просто получал заказы на внедрение тех или иных ИТ систем, то сегодня он уже совместно с руководителями бизнес-подразделений выбирает стратегию дальнейшего развития и принимает общие решения по поводу выхода из той или иной ситуации.
Сейчас уже появилась новая тенденция управления ИТ как бизнесом для достижения баланса между целями бизнеса и сделанными капиталовложениями в новые технологии. Для этого не обойтись без внедрения лучшего опыта в области ИТ (библиотека передового опыта ITIL), а также поиска правильного сочетания технологий, обеспечивающих управление проектами и сервисами, рисками, финансами (применительно к ИТ), информационную безопасность и соблюдение нормативных требований.
Естественно, ИТ-руководство тоже не должно стоять на месте – оно должно знать количественное управление на основе метрик, расширенное моделирование процессов и рисков во всех областях деятельности ИТ, а также необходимых процедур и инструментов. В этой ситуации может помочь:
· проведение обучения персонала с целью повышения квалификации, сертификация специалистов и топ-менеджеров для подтверждения профессионализма и компетенции в области управления сервисами;
· применение ИТ-консалтинга и аутсорсинга - для улучшения качества руководства ИТ или для решения конкретной задачи в области информационных технологий.
Чтобы избежать вполне закономерных ошибок при управлении ИТ и автоматизации процессов управления, лучшим вариантом является изучение мирового опыта и использование стандартов и рекомендаций по управлению ИТ.
Далее рассмотрим ITIL и Cobit.
Cobit представляет собой методологию управления ИТ, нацеленную на бизнес, помогающую произвести оценку уровня зрелости процессов управления ИТ и их эффективности для бизнеса. Методология предназначена для внедрения в организациях и повседневного использования менеджерами, специалистами в сфере ИТ и аудиторами.
Cobit представляет действия по управлению ИТ в виде управляемой и логичной структуры. Лучшие практики, описанные в Cobit, основаны на консенсусе экспертов и в большей степени ориентированы на контроль, нежели на исполнение. Эти нормы помогут оптимизировать инвестиции в ИТ, обеспечить уверенность в уровне предоставляемых сервисов и выработать показатели, на которые можно ориентироваться.
В Cobit делается акцент на том, что требуется для достижения адекватного управления и контроля в сфере ИТ на высоком уровне. Cobit соотносится и гармонизируется с другими, более детальными стандартами в сфере ИТ и лучшими практиками. Методология Cobit действует в качестве интегратора этих руководящих материалов, суммируя ключевые цели в рамках единой методологии, которая, в свою очередь, увязана с управлением и требованиями бизнеса.
Все компоненты Cobit взаимосвязаны, оказывают поддержку для управления, контроля и аудита, как показано на рисунке 4.
Рис.4. Взаимосвязь компонентов Cobit.
Методология Cobit основана на следующем принципе: для того, чтобы организация обеспечила себя информацией, которая необходима для достижения ее целей, организация должна инвестировать и управлять ресурсами ИТ посредством структурированного комплекса процессов, которые обеспечивают сервисы для предоставления информации. Основной принцип методологии Cobit представлен на рисунке 5.
Организация ИТ стремится к достижению поставленных целей посредством четко определенных процессов, в которых задействуются навыки персонала и технологическая инфраструктура, обеспечивающая выполнение бизнес приложений.
Рис.5. Принцип методологии Cobit.
Чтобы соответствовать бизнес требованиям в сфере ИТ, организации нужно инвестировать в ресурсы, необходимые для создания адекватных технических возможностей. ИТ ресурсы определяются в Cobit следующим образом:
· Приложения – прикладные системы и ручные процедуры для обработки информации.
· Информация – данные в любой форме, введенные, обработанные и выведенные информационными системами в любой используемой бизнесом форме.
· Инфраструктура – это технология и устройства (например, аппаратное обеспечение, операционные системы, системы управления базами данных, сетевое оборудование, мультимедиа, а также та среда, в которой все это находится и поддерживается), которые обеспечивают работу приложений.
· Персонал – люди, необходимые для планирования, организации, приобретения, внедрения, работы, обслуживания, мониторинга и оценки информационных систем и услуг.
На рисунке 6 показано, как бизнес цели для ИТ воздействуют на ИТ ресурсы, которые должны управляться в рамках ИТ процессов для достижения целей ИТ.
Рис.6. Управление ресурсами ИТ для достижения целей ИТ
Cobit ориентирован на процессы и представляет виды деятельности в сфере ИТ в виде типовой модели процессов, состоящей из четырех разделов. Эти разделы называются «Планирование и Организация», «Приобретение и внедрение», «Эксплуатация и Сопровождение», «Мониторинг и оценка». Разделы отражают традиционные зоны ответственности в сфере ИТ, связанные с планированием, созданием, сопровождением и мониторингом. На рисунке 7 показаны четыре взаимосвязанных раздела Cobit.
Рис.7. Разделы Cobit
Cobit является методологией и инструментарием, который позволяет руководителям устранить недостатки с учетом требований контроля, технических вопросов и бизнес рисков и донести достигнутый уровень контроля до сведения заинтересованных сторон. Cobit дает возможность разрабатывать четкие политики и лучшие практики по контролю ИТ в организациях. Сфокусированная на процессах структура Cobit и высокоуровневый, бизнес ориентированный подход обеспечивают комплексное видение ИТ и решений, связанных с этой сферой.
ITIL представляет собой методологию, созданную на основе лучших практик управления ИТ сервисами, это библиотека передового опыта, содержащая описания процессов управления ИТ.
Всю деятельность, связанную с информационными системами, можно условно разбить на два типа: создание чего-либо уникального за ограниченное время (проектная), и продолжительную во времени и повторяющуюся (сервисная). Следуя модели жизненного цикла систем, можно условно выделить две группы процессов: проектные (до передачи системы в эксплуатацию) и сервисные (от начала эксплуатации до ее завершения). Статистка показывает, что 80% затрат за весь жизненный цикл системы приходится на ее эксплуатацию и только 20% - на закупку и создание системы. Методология ITIL ориентирована, прежде всего, на процессы управления сервисными услугами.
ITIL основывается на процессном подходе (в соответствии с требованиями к качеству процессов ISO 9000), предоставляет эталонную модель организации управления ИТ сервисом. Ядром библиотеки считаются книги, описывающие такие области как Поддержка (Service Support) и Предоставление услуг (Service Delivery).
Поддержка Сервисов состоит из следующих процессов:
· Управление инцидентами
· Управление проблемами
· Управление конфигурациями
· Управление изменениями
· Управление релизами
Предоставление Сервисов состоит из следующих процессов:
· Управление уровнем сервиса
· Управление ИТ финансами
· Управление мощностью
· Управление непрерывностью ИТ сервиса
· Управление доступностью.
Полный состав ITIL показан на рисунке 8.
Рис.8. Состав ITIL.
В томах библиотеки описан весь набор процессов, необходимых для того, чтобы обеспечить постоянное высокое качество ИТ-сервисов и повысить степень удовлетворенности пользователей. Следует отметить, что все эти процессы нацелены не просто на обеспечение бесперебойной работы компонент ИТ-инфраструктуры. В гораздо большей степени они нацелены на выполнение требований пользователя и заказчика. В конечном счёте, все процессы ITIL работают на повышение конкурентоспособности, а в наше время даже внутренние ИТ-подразделения компаний не могут чувствовать себя в абсолютной безопасности, так как вынуждены конкурировать с аутсорсинговыми компаниями.
Процессный подход ITIL акцентирует внимание предприятия на достижении поставленных целей, а также на ресурсах, затраченных на достижение этих целей.
Задачи, решаемые при помощи принципов, изложенных в ITIL:
· Снижение затрат на ИТ
· Повышение параметра доступности услуг
· Регулирование нагрузки и мощностей услуг
· Увеличение производительности ИТ
· Оптимальное использование ресурсов ИТ
Стандарт CobiT и библиотека ITIL не являются противоречащими друг другу подходами, они дополняют друг друга, охватывая разные сферы деятельности и разные уровни управления. Посредством использования CobiT руководители IT-подразделений преобразуют задачи бизнеса в четкие и понятные планы развития IT. Методология ITIL применяется для оптимизации процесса обслуживания ИТ инфраструктуры с точки зрения управления.
Методология ITIL больше ориентирована на исполнение, а CobiT – на контроль. ITIL - более гибкая методология, которая позволяет поэтапно реализовать внедрение процессов управления ИТ, так как не содержит жестких требований по взаимосвязанным методологическим блокам. Cobit ближе к стандартам, потому что требует комплексный подход, то есть внедрение всех процессов методологии носит обязательный характер, иначе нельзя получить комплексной оценки ИТ. Cobit используется для оценки зрелости ИТ и проведения аудита управления ИТ. ITIL может использоваться на начальном уровне зрелости для управления ИТ, и могут быть внедрены только отдельные основные блоки, если внедрять остальные пока нет необходимости.
2.3 Место процесса «управление проблемами» в управлении ИТ
Проблема - это неизвестная корневая причина возникновения одного или нескольких инцидентов.
Инцидент - Любое событие, которое не является частью стандартного функционирования услуги и которое приводит или может привести к остановке в предоставлении этой услуги или к снижению её качества [1].
Известная ошибка - это инцидент или проблема, причина которых известна, и для которых найдено временное обходное или альтернативное решение [7].
Цель процесса управления проблемами — минимизировать неблагоприятное воздействие на бизнес, вызванное инцидентами и проблемами, связанными с ошибками в инфраструктуре. Соответственно, управление проблемами – деятельность, направленная на поиск и выяснение причин инцидентов, и осуществляются действия, направленные на улучшение ситуации или устранение выявленных причин.
Процесс управления проблемами носит как реактивный, так и проактивный характер. Первый вариант касается разрешения проблем, связанных с возникшими инцидентами, второй направлен на выявление и устранение проблем, способных привести, но пока не приведших к возникновению инцидентов.
Существенное отличие Управления инцидентами от Управления проблемами заключается в том, что первое направлено на сокращение времени решения инцидентов, а второе - на увеличение времени бесперебойной работы.
Главные преимущества эффективного управления проблемами:
1. Уменьшение количества инцидентов, проблем и известных ошибок и снижение их воздействия на бизнес, так как управление проблемами устраняет первопричины инцидентов и использует эффективные обходные п
2. Улучшение качества ИТ сервиса, так как клиенты имеют дело с меньшим числом повторяющихся инцидентов.
3. Повышение экономической эффективности ресурсов поддержки, так как предпринимаются шаги для сокращения времени, потраченного персоналом службы поддержки на повторяющиеся, трудоемкие, и дорогостоящие задачи.
4. Качество служб. Управление проблемами помогает поддерживать непрерывный цикл постоянного повышения качества ИТ-служб.
5. Непрерывное решение. В результате работы процесса сокращается число и влияние на бизнес уже решенных проблем и известных ошибок.
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.
Рис.10. Процессы управления услугами
Цели процессов представлены в таблице 4.
Таблица 4 Цели процессов управления услугами
| № | Название процесса | Цели процесса |
| 1 | Управление бесперебойностью предоставления и доступностью услуг | Гарантировать, что согласованные обязательства перед потребителями услуг о бесперебойности предоставления и доступности услуг будут выполнены при любых обстоятельствах |
| 2 | Управление обеспечением информационной безопасности | Эффективно управлять обеспечением информационной безопасности в рамках любой деятельности по поддержке и предоставлению услуг |
| 3 | Управление инцидентами | Как можно быстрее восстановить предоставление потребителям согласованной услуги, и минимизировать отрицательное влияние инцидентов на бизнес потребителей услуг, а так же выполнять запросы на обслуживание, поступающие от пользователей |
| 4 | Управление проблемами | Минимизировать отрицательное влияние проблем на бизнес потребителей услуг посредством определения корневых причин инцидентов, превентивного анализа и управления проблемами вплоть до их закрытия |
| 5 | Управление отношениями с потребителями | Устанавливать и поддерживать взаимовыгодные отношения между поставщиком услуг и их потребителями, основанные на понимании потребностей потребителей и мотивов их бизнеса |
3.2 Совершенствование процесса «управление проблемами»
Для организации процесса управления проблемами, во-первых, необходимо усовершенствование Технической поддержки до процесса «Управление инцидентами» (схема этого процесса представлена на рис.6 в Приложении). Как видно из схемы после регистрации заявки в базе SD, она классифицируется, ей задается приоритета, в соответствии с которым она выполняется, все действия по ее решению заносятся в базу SD, если инцидент не решен, то руководство информируется о невозможности выполнения и все данные также заносятся в базу. Таким образом, будет пополняться база сбоев, что будет являться источником информации для дальнейшей организации проактивного управления проблемами.
Во-вторых, нужна разработка метрик – показателей KPI для оценки результативности процесса. В соответствии с главной целью процесса – минимизации неблагоприятного воздействия на бизнес проблемами и инцидентами, вызванными ошибками в инфраструктуре, казалось, можно было бы выбрать следующие показатели:
· снижение количества инцидентов по сравнению с предыдущим отчетным периодом;
· снижение суммарного ущерба от инцидентов, также по сравнению с предыдущим отчетным периодом.
Но как показывает практика, такие критерии слишком глобальны - снижение числа инцидентов, так же, как и снижение совокупного ущерба от них, произойдет только в долгосрочной перспективе. К тому же данные критерии весьма сложно нормировать и оценить по сравнению с предыдущими периодами, если учесть постоянный рост компании. Количество инцидентов растет с изменениями в инфраструктуре: при вводе новых рабочих мест в открываемых филиалах корпорации, при запуске новых информационных систем и т.д. В таких условиях трудно понять, насколько могло бы увеличиться число инцидентов или совокупный ущерб от них при отсутствии процесса управления проблемами, вряд ли возможно без статистических данных за достаточно большой период времени. Поэтому логичнее будет использовать следующие показатели:
· количество зарегистрированных проблем,
· количество закрытых проблем,
· среднее и максимальное время, расходуемое на закрытие проблемы или согласование известной ошибки, рассчитываемое с момента регистрации проблемы, сгруппированное по кодам влияния и группам поддержки;
· ожидаемое время устранения открытых проблем;
· общее затраченное время на все закрытые проблемы.
В соответствии с разделом ITSM [6,7] и ГОСТ ИСО/МЭК 20000:2005 [2] описываемый процесс управления проблемами должен включать в себя следующие деятельности:
· Контроль проблем (заключается в идентификации и записи проблем; их классификации; расследовании и диагностики);
· Контроль ошибок (оценка известных ошибок; запись о ходе разрешения ошибок; закрытие ошибок; мониторинг проблем и прогресса разрешения ошибок);
· Предотвращение проблем (анализ тенденций; анализ инфраструктуры; направление действий по предотвращению; обеспечение организации информацией)
· Отчетность (подготовка аналитических отчетов по выполненным работам)
Применительно к выбранной предметной области – интернет-магазину цифровой техники, данный процесс будет состоять из следующих подпроцессов: контроль проблем, контроль ошибок и предотвращение проблем (рис.11).
Рис.11. Диаграмма цепочки добавленного качества для Процесса управления проблемами.
3.3 Организация управления ресурсами
Имеющиеся процессы управления ИТ выполняют сотрудники ИТ-отдела: ИТ-директор, системный администратор и контент-менеджер. Для внедрения процесса «Управления проблемами» потребуется найм, как минимум, еще одного сотрудника, который будет выполнять функции менеджера по проблемам. Как уже упоминалось, в ITIL этот процесс один из самых дорогостоящих, потому что требует найма квалифицированных специалистов (серьезных аналитиков, имеющих высокую квалификацию сразу в нескольких областях ИТ).
Соответственно, затраты на внедрение процесса будут состоять из ежемесячного заработка менеджера по проблемам, затрат на оснащение его рабочего места оборудованием и необходимым ПО. Помогать ему будут ИТ-директор и системный администратор.
Затраты на ежемесячное обслуживание процесса «Управление проблемами» будут складываться из зарплаты менеджера по проблемам и затрат на изменения в ИТ-инфраструктуре, которые требуются для предотражения и решения проблем (например, покупка более мощного сервера, обновление ПО, модернизация оборудования). Но такие затраты сложно просчитать, поэтому в таблице 3 представлены затраты на внедрение этого процесса.
Таблица 5 Затраты на внедрение процесса управления проблемами
| Затраты | Сумма |
| Зарплата менеджера по проблемам | 40 000р. |
Рабочее место, в том числе Оборудование ПО |
30 000р. 20 000р. 10 000р. |
| ИТОГО | 70000 |
При успешном внедрении этого процесса затраты (и временные, и материальные) на разрешение инцидентов должны существенно снизиться. Основной упор будет сделан именно на предотвращение проблем, не допуская возникновения инцидентов. Естественно, экономический эффект от внедрения этого процесса можно будет увидеть только спустя время (от 5-6 месяцев), только после того как будет налажена работа по управлению инцидентами и проблемами. Будет значительно сокращено время простоев пользователей, соответственно, экономия от стоимости простоев пользователей будет значительной.
Примерный расчет (по средним значениям) затрат на каждый подпроцесс представлен далее.
Таблица 6 Стоимостной анализ подпроцесса «Предотвращение проблем»
Таблица 7 Стоимостной анализ подпроцесса «Контроль ошибок»
Таблица 8 Стоимостной анализ подпроцесса «Контроль проблем»
Все данные можно свести в итоговую таблицу.
Таблица 9 Итоговая таблица затрат на процесс «Управление проблемами»
| № | Название подпроцесса | Стоимость 1 дня | Стоимость 1 раза | Стоимость за год |
| 1 | Предотвращение проблем | 660 | 5500 | 165000 |
| 2 | Контроль проблем | 1064 | 2300 | 266000 |
| 3 | Контроль ошибок | 1064 | 2300 | 266000 |
| Итого по процессу | 2788 | 10100 | 697000 | |
Таким образом стоимость ведения процесса «Управление проблемами» вместе с внедрением составит 70000+697000=767000 руб.
3.4 Организация системы документации
Как было отмечено в пункте 3.2. разрабатываемы процесс управления проблемами состоит из 3 подпроцессов: контроль проблем, контроль ошибок и предотвращение проблем (рис.11).
На рисунке 12 представлена схема системы документации между подпроцессами процесса управления проблемами (предотвращение проблем, контроль проблем и контроль ошибок) и процессом управлении инцидентами
Рис.12. Схема системы документации.
Подпроцессы «Предотвращение проблем», «Контроль проблем» и «Контроль ошибок» и представлены на рис.7,8 и 9 в Приложении 1.
Подпроцесс «Предотвращение проблем»
Проблемы выявляются в ходе подпроцесса «Предотвращение проблем» либо после появления инцидента или нескольких инцидентов, выявления тенденции в появлении инцидентов или анализа ИТ-инфраструктуры на ошибки, причем могут быть выявлены уже произошедшие проблемы и проблемы, которые могут возникнуть в будущем.
Входы подпроцесса:
· Сведения о решенных инцидентах,
· Сведения о нерешенных инцидентах,
· Сведения об ИТ-инфраструктуре.
Выходы подпроцесса:
· Сведения об ошибках в ИТ-инфраструктуре,
· Сведения о тенденциях появления инцидентов.
Все данные собранные в рамках подпроцесса «Предотвращение проблем» поступают в подпроцесс «Контроль проблем».
Подпроцесс «Контроль проблем»
Входы подпроцесса:
· Сведения об ошибках в ИТ-инфраструктуре,
· Сведения о тенденциях появления инцидентов,
· Сведения о нерешенных проблемах,
· Сведения о временно решенных проблемах,
· Данные о работах по устранению известных ошибок.
Выходы подпроцесса:
· Данные об известных ошибках,
· Отчет о решении проблемы.
Суть этого подпроцесса состоит в контроле и мониторинге проблем. После выявления проблемы, происходит ее классификация, присвоение приоритета и начинается поиск корневых причин проблемы. Причем мониторинг для выявления причин проблемы выполняется и для новых проблем, и для ранее незакрытых проблем. Данные о проблеме заносятся в базу SD в соответствии с карточкой проблемы, представленной в Приложении 2.
Затем происходит поиск метода решения проблемы. Если для проблемы найдены корневые причины и метод решения, то она классифицируется как известная ошибка, создается ее описание. Действия по решению ошибки выполняются в рамках подпроцесса «Контроль ошибок».
После выполнения работ по решению известной ошибки в рамках подпроцесса «Контроль ошибок» данные снова поступают в «Контроль проблем», это документ «Данные о работах по устранению известных ошибок». Все действия документируются в базе SD. Проблема закрывается. Создается «Отчет о решении проблемы».
Подпроцесс «Контроль ошибок»
В рамках этого подпроцесса выполняются работы по решению и контролю проблем, классифицированных как известные ошибки.
· Входы подпроцесса:
· Данные об известных ошибках,
· Данные о работах по устранению известных ошибок,
· Дополнительная информация.
Выходы процесса:
· Сведения о временно решенных проблемах,
· Сведения о нерешенных проблемах.
После поступления данных об известной проблеме начинается поиск мер по ее решению. Если меры найдены, то инициируется заявка на облуживание, которая выполняется в рамках процесса «Управление инцидентами». После выполнения работ по устранению ошибки, поступают «Данные по устранению известных ошибок», все действия описываются в базе SD и закрытие ошибки и проблемы выполняется в рамках процесса «Контроль проблем».
Если меры не найдены, то ведется поиск временных мер (обходных решений). Если временные меры найдены, то создается описание в базе SD всех сведений о временных мерах и создается заявка на облуживание, которая выполняется в рамках процесса «Управление инцидентами». Статус ошибки в базе меняется на «В решении».
Если же обходные меры не удалось найти, то составляются «Сведения о нерешенных проблемах» и руководство информируется о такой ситуации. Дальнейший контроль за нерешенной проблемой осуществляется в рамках подпроцесса «Контроль проблем».
Формы всех документов представлены в Приложении 2.
Заключение
В результате данной работы был разработан процесс «Управление проблемами» для интернет-магазина «Рентген», соответствующий стандарту ГОСТ ИСО/МЭК 20000.
Основная цель этого процесса осталась неизменной - минимизировать неблагоприятное воздействие на бизнес, вызванное инцидентами и проблемами, связанными с ошибками в инфраструктуре. Цели работы достигнуты, процесс полностью соответствует стандартам, данный процесс можно рассматривать как базовую систему Service desk, в которой также присутствуют функции системы управления проблемами.
Данный процесс готов к внедрению в подобную организацию, но также может быть рассмотрен как базовый процесс для разработки своей системы Service Desk. В результате выполненной работы был разработан процесс «Управление проблемами», который не так затратен, как часто выходит на практике (благодаря тому, что он хоть и сделан по стандарту ГОСТ ИСО/МЭК 20000, но представляет собой более упрощенную версию, более приближенную к предметной области), представляет собой следующий за «Управлением инцидентами» виток развития процессов управления ИТ.
А если говорить в целом, то дальнейшее развитие Service Desk – еще один шаг на пути к успешному и эффективному ведению бизнеса.
Список использованной литературы
1. ГОСТ Р ИСО/МЭК 20000-2007 Управление услугами. Часть 1 – Общиеположенияисловарь (ISO/IEС 20000-1:2005 «Information technology – Service management – Part 1: Specification»)
2. ГОСТ Р ИСО/МЭК 20000-2007 Управление услугами. Часть 2 – Практическоеруководство (ISO/IEС 20000-2:2005 «Information technology – Service management – Part 2: Code of practice»)
3. СовiТ 4.1. Москва, Аудит и контроль информационных систем 2008
4. М.Б. Букреев, А.Е. Заславский, «Управление ИТ-сервисами информационно-телекоммуникационных систем (ИТС)», Москва, РУСЭЛПРОМ, 2007г.
Интернет-ресурсы:
5. http://www.osp.ru/cio/2005/01/173763/ Статья «Как организовать управление проблемами» 27 января 2005 г.
6. http://masu-inform.ru:8888/index.php/Управление_проблемами
7. www.allITIL.ru
8. http://ru.wikipedia.org/wiki/ITSM
9. http://www.itexpert.ru/rus/biblio/itmanagement/
10. http://www.pcweek.ru/themes/detail.php?ID=81984 Статья «Управление инцидентами и проблемами: как распределить ресурсы» PCWeeK № 562 13 февраля 2007 г.
Приложение
Рис.1. Стратегические цели
Рис.2. Процесс технической поддержки пользователей
Рис.3. Процесс управления инцидентами
Рис.4. Взаимосвязь основных и обеспечивающих процессов
Рис.5. Процесс управление контентом
Рис.6. Подпроцесс «Предотвращение проблем»
Рис.7. Пропроцесс «Контроль проблем»
Карточка проблемы
| Дата обнаружения |
| Дата возникновения |
| Описание проблемы |
| Выполненные действия |
| Статус |
| Приоритет |
| Категория |
| Инциденты |
Рис.1. Карточка проблемы
| ООО "Рентген" | |||||||||
| Управление ИТ | |||||||||
| Сведения о решенных инцидентах | Дата | ||||||||
| № | Дата Регистрации инцидента | Дата Закрытия инцидента |
Описание инцидента | Местонахождение | Описание выполненных работ |
Приоритет | Состояние на текущий момент |
||
| Системный администратор | / / | ||||||||
Рис.2. Сведения о решенных инцидентах
| ООО "Рентген" | |||||||||
| Управление ИТ | |||||||||
| Сведения о нерешенных инцидентах | Дата | ||||||||
| № | Дата Регистрации инцидента |
Описание инцидента | Местонахождение | Описание выполненных работ |
Приоритет | Состояние на текущий момент |
Описание причин невозможности решения инцидента | ||
| Системный администратор | / / | ||||||||
Рис.3. Сведения о нерешенных инцидентах