Разработка автоматизированной информационной системы ателье индивидуального пошива

· Запросы на обслуживание (стандартные запросы на поддержку функционирования системы);

· Запрос на обработку инцидентов (инцидент определяется как отклонение, выходящее за рамки допустимого, например серьёзные неполадки в системе или необработанный в срок, и создающее серьёзные препятствия для функционирования организации);

· Запросы на изменение состояния системы - например установку нового оборудования и программного обеспечения.

Service desk состоит из следующих логических компонентов:

· Модуль регистрации заявок об инцидентах

· База данных заявок

· Система отслеживания статуса заявки и оповещения

· База знаний

· Панель администрирования

· Модуль отчетности

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

2. Постановка задачи. Используемые методологии и технологии

2.1 Постановка задачи

Задачей данной работы является анализ автоматизации производственного процесса ателье на основе практики библиотеки практик и методов автоматизации ITIL и реализация бизнес-процесса, системы на основе данной методологии.

2.2 Описание бизнес процессов

Бизнес-процесс - последовательность действий, направленная на получение заданного результата, ценного для организации. На рисунке 2.1 представлена система процессного подхода. Например, Прием заказа клиента, Планирование закупок, Производство товара, и т.п.

Рисунок 2.1 - Система бизнес-процессов

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

На рисунке 2.2 представлена схема бизнес процесса ателье индивидуального пошива.

Рисунок 2.2 - Схема бизнес процесса

Плюсы процессной схемы управления:

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

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

· Разгрузка руководителей. Они вмешиваются в оперативное управление только в случае значительных отклонений.

· Руководители занимаются своими прямыми обязанностями - организацией эффективного управления и стратегией развития.

· На порядок большая операционная эффективность по сравнению с другими схемами управления.

· Не критичность для компании смены работников, поскольку есть механизм передачи знаний новым сотрудникам (регламенты бизнес-процессов).

· Минусы:

· В случае формирования кроссфункциональных подразделений требуются отдельные процедуры для обеспечения профессионального роста сотрудников (обучение).

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

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

2.3 ITSM

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

Методология ITSM сосредоточена в двух книгах ITIL (два тома):

· «Поддержка сервисов» («Service Support»)

· «Предоставление сервисов» («Service Delivery»)

Рисунок 2.3 - Основные группы процессов ITIL/ITSM

Процессы Поддержка сервисов (Service Support):

· Управления инцидентами (Incident Management)

· Управления проблемами (Problem Management)

· Управления конфигурациями (Configuration Management)

· Управления изменениями (Change Management)

· Управления релизами (Release Management)

Процессы Предоставление сервисов (Service Delivery):

· Управленияуровнемуслуг (Service Level Management)

· Управленияфинансами (Financial Management for IT Services)

· Управления мощностью (Capacity Management)

· Управлениянепрерывностью (IT Service Continuity Management)

· Управления доступностью(Availability Management)

Услуги и качество

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

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

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

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

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

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

Качество - это совокупность характеристик продукта или услуг, которые формируют способность продукта удовлетворять сформулированные и подразумеваемые потребности (ISO-8402).

Понятие «разумная цена» можно рассматривать как производное понятие. После того, как достигнуто Соглашение об Ожиданиях Заказчика, можно обсудить цену. На данном этапе поставщик должен знать, каковы его затраты на сервисы и какие существуют текущие рыночные расценки на аналогичные услуги.

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

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

Цикл качества Деминга

Цикл качества Деминга (Deming) (рис. 2.4) представляет собой простую и наглядную модель Управления Качеством. Согласно данной модели, для предоставления соответствующего Уровня Качества нужно непрерывно повторять следующие этапы:

· Планирование (Plan): что нужно сделать, когда это нужно сделать, кто должен это сделать, как это следует сделать и с помощью чего

· Выполнение (Do): выполнение запланированных работ.

· Проверка (Check): определяется, дало ли выполнение работ ожидаемый результат.

· Действие (Act): производится корректировка планов с учетом информации, полученной на этапе проверки.

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

Рис. 2.4 - Цикл качества Деминга

Принцип действия TQM можно сравнить с удержанием мяча на наклонной плоскости. Для того чтобы мяч не скатывался, его нужно либо подпирать снизу, либо тянуть сверху. TQM включает два механизма: Quality Assurance (QA) -- контроль качества и Quality Improvements (QI) -- повышение качества. Первый -- контроль качества -- поддерживает необходимый уровень качества и заключается в предоставлении компанией определенных гарантий, дающих клиенту уверенность в качестве данного товара или услуги. Второй -- повышение качества -- предполагает, что уровень качества необходимо не только поддерживать, но и повышать, соответственно поднимая и уровень гарантий. Два механизма: контроль качества и повышение качества -- позволяют "удерживать мяч в игре", то есть постоянно совершенствовать, развивать бизнес.

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

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

Система обеспечения качества -- это организационная структура, определяющая распределение обязанностей, используемые процедуры и ресурсы, необходимые для реализации Управления Качеством. Для разработки, оценки и усовершенствования системы обеспечения качества часто используются стандарты серии ISO-9000.

Стандарт качества ISO-9000:

· поставщик предпринимает меры пo обеспечению качества, согласованного с заказчиками;

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

· процедуры работы поставщика задокументированы и переданы тем лицам, кто зависит от них;

· претензии заказчика регистрируются, рассматриваются в течении разумного срока и, по мере возможности, принимаются во внимание при усовершенствовании услуг;

· поставщик контролирует производственные процессы и может их совершенствовать.

Цикл качества Деминга входит составной частью в модель EFQM.

EFQM -- (European Foundation for Quality Management) Европейский фонд Управления Качеством разработал модель, которую можно использовать для определения зрелости организации, показана на рисунке 2.5). С помощью данной модели определяются основные сферы деятельности, которые следует принимать во внимание при Управлении Организацией.

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

Рис. 2.5 - Модель EFQM

Голландская организация по вопросам качества (INK) дополнительно поделила модель EFQM на этапы, давая тем самым возможность определить, в какой степени компании удалось реализовать общее Управление Качеством в отдельной области и в организации в целом. Определено пять этапов:

· Нацеленность на продукт -- этап, известный как ориентированный на результат; все в организации работают напряженно (но в этих усилиях отсутствует направленность); деятельность организуется специальным образом для каждого конкретного случая.

· Нацеленность на процесс -- этап также известен под названием «мы знаем, что делаем»; деятельность организации имеет плановый и повторяющийся характер.

· Нацеленность на систему -- или «сотрудничество подразделений».

· Нацеленность на цепочку -- этап также известен под названием «внешнее партнерство»; организация концентрирует усилия на том качестве, которое она добавляет как составляющий элемент к цепочке поставщик-заказчик.

· Нацеленность на всеобщее качество -- этап, называемый «рай на земле»; организация достигла такого уровня, когда постоянное и сбалансированное стремление к совершенствованию стало нормой.

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

В ИТ индустрии процесс развития Уровня Зрелости наиболее известен через Модель зрелости (Capability Maturity Model-- СММ). Эта модель была создана в институте разработки программного обеспечения (ПО)(Software Engineering Institute -- SEI) в университете Карнеги-Меллона (Carnegie Mellon). Она предназначается для совершенствования процессов разработки ПО и повышения степени зрелости этих процессов. Модель СММ включает в себя следующие уровни:

· Начальный уровень -- процессы выполняются индивидуально для каждого конкретного

· случая.

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

· Уровень Документированных Процессов -- процессы в организации документированы, стандартизованы и интегрированы.

· Уровень Управляемых Процессов -- организация оценивает полученные результаты и использует их для повышения качества предоставляемых услуг.

· Уровень Оптимизирующихся Процессов -- организация постоянно оптимизирует свои процессы с целью повышения качества услуг или разработки новой технологии или сервисов.

На основе выше перечисленных Уровней Зрелости процессов были разработаны модели ИТ Сервис-менеджмента. Разрабатывая и сопровождая системы качества, отвечающие требованиям стандарта серии ISO-9000 (ISO-9000-2000), организация может достичь Уровня «Нацеленности на систему» (или Уровня «Управляемых процессов» по терминологии модели СММ). Эти стандарты ISO уделяют основное внимание определению, описанию и проектированию процессов.

При оценке зрелости организации нельзя ограничиться только поставщиком услуг. Здесь также важен Уровень Зрелости Заказчика (рис.2.5).

2.4 Библиотека ITIL

ITIL и CobiT

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

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

ITIL, в отличие от CobiT, не является стандартом. Это библиотека, в которой собраны лучшие практики по организации процессов ИТ-службы. ITIL говорит о том, как правильно построить ИТ-процессы, как их связать между собой и каким образом ими управлять. Фокус ITIL смещен на управление услугами, которые предоставляет ИТ, а многие сферы, к примеру, информационная безопасность, покрыты поверхностно. Использование библиотеки ITIL важно для того, чтобы не "изобретать велосипед", а использовать проверенные индустрией подходы и идеи по организации эффективной ИТ-службы.

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

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

Преимущества ITIL

Основой данной разработки выбрана библиотека методов ITIL. Выбор сделан основываясь на следующих достоинствах:

· Гибкость проектирования

Технология стремится к возможности описания и видоизменения себя самой.

· Полнота

Проектирование способно обеспечить максимальное покрытие реального интеллектуального бизнес процесса ИТ-процессом.

· Интегрируемость

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

2.4.1 Управление Инцидентами

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

В приложении Б приведена выдержка основополагающих определений из глоссария библиотеки ITIL.

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

Примеры Запросов на Обслуживание:

· вопрос о функционировании ИТ-систем или запрос о предоставлении какой-либо информации;

· запрос о состоянии (статусе) чего-либо в ИТ-инфраструктуре;

· запрос о замене пароля;

· запросы на выполнение пакетных заданий, восстановление или авторизацию пароля;

· получение информации из базы данных.

Для того чтобы можно было отличить «настоящие инциденты» от «инцидентов-Запросов на Обслуживание», рекомендуется присваивать Запросам на Обслуживание специальную категорию. Важно также отметить, что Запрос на Обслуживание это не то же самое, что Запрос на Изменение;

Запрос на Изменение (RFC) -- это экранная или бумажная форма, используемая для записи детальной информации о предлагаемом Запросе на Изменение какой-либо Конфигурационной Единицы (CI) в ИТ-инфраструктуре или процедуры или какого-либо иного объекта ИТ-инфраструктуры.

Запрос на Изменение RFC считается завершенным после проведения изменения в инфраструктуре, например, замены зарегистрированных компонентов, инсталляции ПК и т.д. Это не инциденты, а изменения.

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

На рисунке 2.6 показан схематичный пример Управления Инцидентами как горизонтальный процесс, охватывающий разные ИТ-отделы.



Рис. 2.6. Позиционирование Процесса Управления Инцидентами относительно других функций (подразделений) ИТ-организации

Целью Процесса Управления Инцидентами является скорейшее восстановление нормального Уровня Услуг, определенного в Соглашении об Уровне Услуг(Service Level Agreement -- SLA), с минимальными возможными потерями для бизнес-деятельности организации и пользователей. Кроме того, Процесс Управления Инцидентами должен вести точную регистрацию инцидентов для оценки и совершенствования процесса и предоставления необходимой информации для других процессов.

Преимущества использования процесса

· Для бизнеса в целом:

· своевременное разрешение инцидентов, ведущее к уменьшению потерь для бизнеса;

· повышение производительности работы пользователей;

· независимый, ориентированный на потребности заказчика мониторинг инцидентов;

· доступность объективной информации о соответствии предоставляемых услуг согласованным договоренностям (SLA).

· Для огранизации:

· улучшенный мониторинг, позволяющий проводить точное сопоставление уровня производительности ИТ-систем соглашениями (SLA);

· эффективное руководство и мониторинг выполнения соглашений (SLA) на основе достоверной информации;

· эффективное использование персонала;

· предотвращение потери инцидентов и Запросов на Обслуживание или их неправильной регистрации;

· повышение точности информации в Конфигурационной Базе Данных (Confi ati Management Database -- CMDB) за чет е проверки при регистрации инцидентов в привязке к Конфигурационным Единицам (Configuration Item -- CI);

· повышение удовлетворенности пользователей и заказчиков.

Отказ от использования Процесса Управления Инцидентами может привести к следующим отрицательным последствиям:

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

· пользователи могут перенаправляться к одним и тем же специалистам «по кругу» безуспешного разрешения инцидента;

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

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

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

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

2.4.2 Процесс

На рисунке 2.7 представлены вх0оды и выходы процесса, также виды деятельности, которые охватывает этот процесс.

Рисунок 2.7 - Положение Процесса Управления Инцидентами

Входы процесса

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

Управление Конфигурациями

Конфигурационная База Данных (Configuration Management Database -- CMDB) играет важную роль в Управлении Инцидентами, так как она определяет связь между ресурсами, услугами, пользователями и Уровнями Услуг(сервисов). Например, Управление Конфигурациями показывает, кто является ответственным за компонент инфраструктуры, что делает возможным более эффективное распределение инцидентов по группам специалистов. Кроме того, эта база данных помогает решать оперативные вопросы, например, перенаправление очереди печати или переключение пользователя на другой сервер. При регистрации инцидента в регистрационные данные добавляется связь (link) с соответствующей Конфигурационной Единицей, позволяющая предоставить более подробную информацию об источнике ошибки. В случае необходимости может быть обновлен статус соответствующей компоненты в CMDB.

Управление Проблемами

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

Управление Изменениями

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

Управление Уровнем Услуг

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

Управление Доступностью

Для определения показателей доступности услуг Процесс Управления Доступностью использует регистрационные данные об инцидентах и данные мониторинга статуса, предоставляемые Процессом Управления Конфигурациями. Аналогично Конфигурационной Единице(CI)в Конфигурационной Базе Данных (CMDB), сервису (услуге) может быть также назначен статус «не работает». Это может быть использовано для проверки действительных показателей доступности услуги и времени реагирования поставщика. При осуществлении такой проверки необходима фиксация времени действий, произошедших в процессе обработки инцидента, от момента обнаружения и до закрытия.

Управление Мощностями

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

· Прием и регистрация инцидента (Acceptance and Recording) -- принимается сообщение и создается запись об инциденте.

· Классификация и начальная поддержка (Classification and Initial support) -- присваиваются тип, статус, степень воздействия, срочность, приоритет инцидента, SLA и т.п. Пользователю может быть предложено возможное решение, даже если оно только временное.

· Если вызов касается Запроса на Обслуживание (Service Request), то инициируется соответствующая процедура.

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

· Расследование и диагностика (Investigation and Diagnosis) -- при отсутствии известного решения производится исследование инцидента с целью как можно быстрее восстановить нормальную работу.

· Решение и восстановление (Resolution and Recovery) -- если решение найдено, то работа может быть восстановлена.

· Закрытие (Closure) -- с пользователем связываются, чтобы он подтвердил согласие с предложенным решением, после чего инцидент может быть закрыт.

· Мониторинг хода работ и отслеживание (Progress monitoring and Tracking) -- весь цикл обработки инцидента контролируется, и если инцидент не может быть разрешен вовремя, производится эскалация.

Рисунок 2.8 - Процесс Управления Инцидентами

2.4.3 Виды деятельности

· Прием и регистрация

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

· трудно произвести точную регистрацию информации об инциденте, если это не сделано сразу;

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

· зарегистрированные инциденты помогают при диагностике новых инцидентов;

· Управление Проблемами может использовать зарегистрированные инциденты при работе над поиском корневых причин;

· Легко определить степень воздействия, если все сообщения (звонки) зарегистрированы;

· Без регистрации инцидентов невозможно контролировать исполнение договоренностей (SLA);

· Немедленная регистрация инцидентов предотвращает ситуации, когда или несколько человек работают над одним звонком, или никто ничего не делает для разрешения инцидента.

Место обнаружения инцидента определяется по признаку, откуда пришло сообщение о нем. Инциденты могут быть обнаружены с дующим образом:

· Обнаружен пользователем: он докладывает об инциденте в Службу Service Desk

· Обнаружен системой: при обнаружении события в приложении или технической инфраструктуре, например, при превышении критического порога, событие регистрируется как инцидент в системе регистрации инцидентов и, при необходимости, направляется в группу поддержки.

· Обнаружен сотрудником Службы Service Desk: сотрудник производит регистрацию инцидента.

· Обнаружен кем-либо в другом подразделении-ИТ: этот специалист регистрирует инцидент в системе регистрации инцидентов или докладывает о нем в Службу Service Desk

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

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

· Если нет (отличается от открытого инцидента), производится регистрация нового инцидента.

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

При регистрации инцидента производятся следующие действия:

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

· Запись базовой диагностической информации: время, признаки (симптомы), пользователь, сотрудник, принявший вопрос в обработку, место произошедшего инцидента и информация о затронутой услуге и/или технических средствах.

· Запись дополнительной информации об инциденте: добавляется информация, например, из скрипта (scri) или процедуры опроса или из Конфигурационной Баз Данных -- CMDB (обычно на основе взаимоотношений Конфигурационных Единиц, определенных в CMDB).

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

· Классификация

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

Категория

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

· Центральная процессинговая система -- подсистема доступа, центральный сервер, приложение.

· Сеть -- маршрутизаторы, сегменты, концентратор (hub), IP-адреса.

· Рабочая станция -- монитор, сетевая карта, дисковод, клавиатура.

· Использование и функциональность -- услуга (сервис), возможности системы, доступность, резервное копирование (back-up), документация.

· Организация и процедуры -- заказ, запрос, поддержка, оповещение (коммуникации). Запрос на Обслуживание -- запрос пользователя в Службу Service Desk на поддержку, предоставление информации, документации или оказание консультации. Это может быть выделено в отдельную процедуру или обработано таким же образом, как реальный инцидент.

Приоритет

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

Приоритет = Срочность x Степень воздействия

Услуги (сервисы)

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

Группа поддержки

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

Сроки решения

С учетом приоритета и соглашения SLA пользователь информируется о максимальном расчетном времени разрешения инцидента. Эти сроки также фиксируются в системе.

Идентификационный номер инцидента

Абонент информируется о номере инцидента для его точной идентификации при последующих обращениях.

Статус

Статус инцидента указывает на его положение в процессе обработки инцидента. Примерами статусов могут быть:

· новый;

· принят;

· запланирован;

· назначен;

· активный;

· отложен;

· разрешен;

· закрыт.

· Привязка (сопоставление)

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

· Расследование и диагностика

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

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

· Решение и восстановление

После успешного завершения анализа и разрешения инцидента сотрудник записывает решение в систему. В некоторых случаях необходимо направить Запрос на Изменение (RFC) в Процесс Управления Изменениями. В наихудшем случае, если не найдено никакого решения, инцидент остается открыть

· Закрытие

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

· Мониторинг хода решения и отслеживание

В большинстве случаев ответственной за мониторинг хода решения является Служба Service Desk, как «владелец» всех инцидентов. Эта служба должна также информировать пользователя о состоянии инцидента. Обратная связь с пользователем может быть уместной после изменения статуса, например, направление инцидента на следующую линию поддержки, изменение расчетного времени решения, эскалации и т.д. Во время мониторинга возможна функциональная эскалация к другим группам поддержки или иерархическая эскалация для принятия руководящих решений.

· Контроль процесса

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

· Руководителю Процесса Управления Инцидентами отчет необходим для:

o идентификации недостающих звеньев процесса;

o идентификации нарушений исполнения соглашений об Уровне Услуг(SLA);

o отслеживания хода выполнения процесса;

o определения тенденций развития.

· Руководство Линейными ИТ-подразделениями -- отчет для руководства группы поддержки; он также может быть полезен в Управлении ИТ-подразделениями. Отчет должен содержать следующую информацию:

o прогресс в решении инцидентов;

o время разрешения инцидентов в различных группах поддержки.

· Управления Уровнем Сервисов (Услуг)-- отчет должен, прежде всего, содержать информацию о качестве предоставляемых услуг. Руководитель Процесса Управления Уровнем Услуг должен получать всю информацию, необходимую для составления Отчетов об Уровне Услуг перед заказчиками. Отчеты для заказчиков должны предоставлять информацию о том, выполняются ли соглашения в отношении Уровня Сервисов (услуг) рамках Процесса Управления Инцидентами.

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

o число обнаруженных и зарегистрированных инцидентов;

o число разрешенных инцидентов, с разделением по времени разрешения;

o статус и число неразрешенных инцидентов;

o инциденты с разбивкой по периодам возникновения, группам заказчика, группам поддержки и временем разрешения в соответствии соглашением (SLA);

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

· Критические факторы успеха

Для успешного Управления Инцидентами необходимо с дующее:

· Актуальная Конфигурационная База Данных (CMDB), помогающая оценить степень

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

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

· Соответствующую автоматизированную с тему регистрации, отслеживания и мониторинга инцидентов.

Дополнительно необходимо тесное взаимодействие с Процессом Управления Уровнем Сервисов (Услуг) для определения требуемых приоритетов и времени разрешения инцидентов.

· Показатели эффективности

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

· общее количество инцидентов;

· среднее время разрешения инцидентов;

· среднее время разрешения инцидентов по приоритетам;

· среднее число инцидентов, разрешенных в рамках соглашений (SLA);

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

· средняя стоимость поддержки на инцидент;

· число решенных инцидентов на одно рабочее место или на одного сотрудника службы Service Desk;

· инциденты, решенные без посещения пользователя (удаленно);

· число (или процент) инцидентов с первоначально некорректной классификацией;

· число (или процент) инцидентов, неправильно распределенных в группы поддержки.

· Функции и роли

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

Руководитель Процесса Управления Инцидентами

Во многих организациях роль Руководителя Управления Инцидентами играет менеджер Службы Service Desk. В сферу ответственности Руководителя Процесса Управления Инцидентами включается следующее:

· мониторинг эффективности и рациональности работы³процесса;

· контроль работы групп поддержки;

· составление рекомендаций по совершенствованию работы процесса;

· развитие и сопровождение системы Управления Инцидентами.

Персонал групп поддержки

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

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

2.5 Service Desk

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

· Прием, регистрация обращений пользователей по вопросам ИТ

· Идентификация и обработка Инцидентов и запросов на обслуживание

· Накопление базы знаний по решенным инцидентам

· Управление жизненным циклом Инцидента

· Информирование пользователей о текущем статусе обращений

· Контроль сроков решения инцидентов

· Диспетчеризация инцидентов специалистам более высокой квалификации

· Информирование пользователей о проведении плановых работ, изменений и т.д.

Service Desk обеспечивает:

· Единую точку контакта к службе поддержки. Удобный и понятный для клиентов механизм позволит более быстро решать их проблемы.

· Стандартный способ регистрации и выдачи заданий специалистам.

· Контроль над последовательностью выполненных работ, потраченного времени и ресурсов.

· Назначение приоритетов запросам в зависимости от типа запроса, конкретногоклиента или других обстоятельств.

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

Схема и структура работы Service Desk

В общем случае работа Service Desk может быть представлена из пяти основных этапов:

1 Пользователь обращается в Службу с заявкой о Проблеме (Инциденте).

2 Оператор выполняет анализ заявки, и присваивает ей Категорию, при возможности помогает пользователю решить проблему с помощью Базы Знаний.

3 Координатор назначает Инженера для решения заявки и фиксирует ее закрытие.

4 Инженер решает проблему либо возвращает ее координатору.

5 Выполняются работы по извещению пользователя.

Структура Service Desk напоминает луковицу. Ее сердцевина -- программно-аппаратный комплекс, называемый центром обработки вызовов, который обеспечивает грамотное распределение заявок. Например, для этих целей может применяться решение IP Contact Center компании Cisco Systems. Вокруг него строится Help Desk, который отличается от Service Desk тем, что участвует только в одном процессе -- в управлении инцидентами. Соответственно, задачи Help Desk -- зарегистрировать инцидент и как можно быстрее восстановить нормальную работу сервиса самостоятельно либо привлечь группу специалистов более высокого уровня для полного устранения причины инцидента. Но мы должны не только «тушить пожары», но и предупреждать их. Мы должны оказывать бизнесу дополнительные услуги и именно этим и занимается Service Desk, как структурное подразделение.

3. Реализация

3.1 Средства разработки

3.1.1 Сервер Service Manager

Используемый продукт HP Service Manager (SM) представляет собой программное обеспечение по управлению базой данных (БД) средствами графического и текстового интерфейса.

Технически сервис SM состоит из следующих узлов и представлен на рисунке 3.1:

· СУБД

· Кластер SM

· Веб-сервер

· Веб-клиент

· ОС-клиент (ПО для работы с SM)

Узел СУБД служит для хранения всех данных, таблиц, настроек, функционала, кода участвующего в работе системы.

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

Веб-сервер играет роль интерфейса к системе для подключения через веб-клиент. Веб-сервер представлен двумя версиями: в защищенной DMZ зоне сети для внешних пользователей и внутри сети для внутренних пользователей.

У системы имеется ОС-интерфейс (специальный клиент для подключения к SM) и веб-интерфейс для пользователей, не обладающих возможностью использовать ОС-клиент.



Рисунок 3.1 - Общая схема сервера SM

3.1.2 Сервис S M

Интерфейс пользователя состоит из (рис. 3.2):

· Меню (слева)

· Командная строка (слева сверху)

· Информативной формы (справа)

· Окно сообщений (снизу)

· Контекстное меню (над формой, бокс для хранения кнопок)

Примечание: при необходимости можно варьировать местоположение элементов. Администратор в системе также имеет все описанные виды интерфейса и подразумевает наличие отдельной роли в системе и ИТ-процессах.



Рисунок 3.2 - Пользовательский интерфейс

Управление БД представляет собой графический интерфейс создания таблиц и полей. Относительно самой системы, понятие Таблица заменяется понятием Объект, это способствует упрощенному проектированию системы в виду того, что разработанные ИТ-процессы почти идентичны соответствующим объектам системы (выделенные таблицы SM).

Функционал системы состоит из:

· Данных объекта

· Данных интерфейса

· Программного кода

Система SM представляет собой ядро, содержащее предустановленный функционал (создание/управление формами, создание/управление процессов управления данными Объекта на форме). Данные объекта - это пользовательские данные о рабочих инцидентах, проблемах, взаимодействиях, настройках учетных записей, пользовательских контактов.

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

Кнопки

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

Объекты

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

На рисунке 3.3 представлено определение объекта и его изменение.

Рисунок 3.3 - Модификация объекта



Рисунок 3.4 - Графическая форма

Оповещения

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

Рисунок 3.5 - Оповещение по инциденту

SLA

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

...