Бизнес процессы управления обслуживанием лекция

1. Частное профессиональное образовательное учреждение «Анапский индустриальный техникум»

Курсовая работа
Тема:
Бизнес процессы управления
обслуживанием
Студента группы 23701 «Прикладная
информатика
4ПИ
Николаева Д.С.
Руководитель: Шевелёва В.Ю.

2.

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

3.

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

4.

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

5.

Для успешного внедрения ERP-системы нужно
придерживаться следующих правил:
Точно знать цели проекта, т. к. 70% проектов
терпит неудачу именно по этой причине.
Должны быть документально определены цели,
бюджет и сроки проекта, назначен руководитель и
сформирована проектная команда.
Проектная команда должна быть обеспечена всем
необходимым для выполнения проекта
Проект должен быть разбит на логически
выверенные этапы и фазы работ, которые должны
быть проверены на отсутствие «конфликтов» в
последовательности и продолжительности работ.

6.

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

7. Основные недостатки ERP-систем:

Высокая сложность внедрения. Нужно предъявлять
самые высокие требования к проектной команде,
как со стороны Исполнителя, так и со стороны
Заказчика.
При перестройке бизнес-процессов предприятия и
внедрении ERP-решения в большинстве случаев
возникают большие риски и затраты, которые
могут привести к значительному снижению
производительности
и,
как
следствие,
уменьшению рентабельности бизнеса.

8.

Высокая и стоимость внедрения, т. к. значительная
доля затрат на внедрение ERP приходится не на
стоимость системы, а на работы по ее внедрению;
Высокая
стоимость владения ERP-системой
(ежегодные затраты);
Долгая окупаемость системы — 2-3 года после ее
внедрения.

9. Бизнес-процесс и его структура

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

10.

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

11. Характеристики бизнес-процесса:

1.Стоимость. Должна стремиться к минимальному
значению.
2.Длительность.
Желательно
стремиться
к
максимальной скорости реализации.
3.Степень качества продукта (удовлетворенность
клиента).

12.

В результате проведенного исследования по теме:
«Оптимизация бизнес — процесса с помощью ERPрешений», цель работы была достигнута путем
реализации поставленных задач.
В ходе проведенного исследования было выявлено,
что использование ERP- системы для оптимизации
бизнес — процесса повышает эффективность ее
деятельности (между затратами и доходами),
позволено
сократить
затраты
ресурсов
предприятия.

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

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

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

Стратегии ремонта

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

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

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

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

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

Необходимые параметры и документы

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

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

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

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

На основании графиков ППР выполняется планирование обеспечивающих ресурсов. Это, в первую очередь, материально-техническое обеспечение (МТО), которое включает в себя обеспечение запасными частями, материалами и средствами ТО и ремонта (инструментами), используемыми при выполнении технологической операции, и обеспечение трудовыми ресурсами, необходимыми для выполнения технологической операции.

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

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

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

Выполнение ремонта или ТО регистрируется актом выполненных работ — документом, отражающим выполнение работ по ремонту или ТО и позволяющим формировать документы по списанию затрат МТО в производство и по выплате денежных средств исполнителям.

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

Совокупность процессов

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

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

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

Типовая модель процессов ремонта и технического обслуживания оборудования основана на методологии EAM (Enterprise Asset Management) — систематической и скоординированной деятельность предприятия, нацеленной на оптимальное управление физическими активами и режимами их работы, рисками и расходами на протяжении всего жизненного цикла для достижения и выполнения стратегических планов. Она включает в себя следующие бизнес-процессы управления деятельностью по техническому обслуживанию и ремонтам оборудования предприятия (рис.1.):

1. Учет оборудования и нормативов — ведение списка оборудования, классификация оборудования, ведение списка нормативных ремонтов и ТО и их технологических карт.
2. Учет показателей эксплуатации — учет осмотров оборудования, контролируемых показателей и контроль их значений, ведение журнала дефектов, учет наработки и простоев оборудования, учет перемещений оборудования, хранение исторических данных о ремонтах оборудования.
3. Планирование ремонтов — формирование графика ППР, формирование заявок на проведение ремонтов, планирование потребности в запасных частях и материалах, трудовых ресурсах, формирование бюджета на ремонты.
4. Управление материально-техническим обеспечением ремонтов — ведение первичного учета МТО, контроль неснижаемого остатка, формирование внутренних заказов, учет затрат.
5. Управление персоналом — определение необходимых компетенций, формирование персонального списка работников, аттестации и допуски, контроль трудозатрат.
6. Управление нарядами и работами — подготовка наряд-допусков, нарядов на выполнение ремонтных работ, учет выполненных работ.
7. Управление документацией — ведение архива документов, хранение графической документации.
8. Анализ эффективности и формирование отчетности — формирование отчета по показателям эффективности, план-фактный анализ выполнения работ, план-фактный анализ трудозатрат, план-фактный анализ затрат МТО, текущий анализ данных по состоянию оборудования и др.

Рис. 1. Схема взаимосвязей бизнес-процессов (процесс «Анализ эффективности и формирование отчетности» не показан)

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

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

После определения начальных событий необходимо понять: «Где закончится процесс?». Конечное событие также может быть не единственным.

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

После определения выходов процесса следует установить: «Кто использует полученные продукты/услуги или информацию (выходы процесса)?», т.е. определить клиентов процесса.

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

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

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

Рис. 2. Схема описания бизнес-процесса

В виду важности на современном предприятии системы ТОиР и сложности в управлении ими широкое распространение получили специализированные автоматизированные информационные системы. Такие системы в рамках концепции EAM, в частности «1С:Предприятие 8. ТОИР Управление ремонтами и обслуживанием оборудования»  значительно облегчают согласованное управление процессами технического обслуживания и ремонтом оборудования, материально-технического снабжения и трудовыми ресурсами. Их применение позволяет существенно сократить расходы на техническое обслуживание и ремонты, снизить продолжительность простоев оборудования, увеличить его загрузку. По данным агентства A.T.Kearney, использование таких систем позволяет сократить затраты на обслуживание оборудования в среднем на 25-30%, повысить готовность оборудования к работе на 15-17% и на 30% сократить количество аварийных и сверхурочных работ.

Электронные лекции Балажигитова р.А. Управление бизнес — процессами

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

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

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

Дисциплина «Управление бизнес-процессами»
относится к Математическому циклу
дисциплин и входит в вариативную часть
этого цикла.

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

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

Тема 1. Основы процессного подхода к управлению предприятием Лекция 1 вопросы:

Введение.

1. Виды деятельности в организации.
Понятие бизнес-процесса.

2. Система и классификация бизнес-процессов
предприятия.

3. Принципы построения системы управления
бизнес-процессами.

☆ Переход от функционального к
процессному подходу в управлении
предприятием;

☆ Методы УБП: реинжиниринг и
совершенствование;

☆ Инжиниринговые средства УБП.

Введение

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

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

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

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

— Всегда ли мы реагируем на проблемы
до того, как проявятся их последствия?

— Сколько времени проходит между
констатацией явлений и реакцией на них?

— Кто быстрее использует новые возможности
— мы или наши конкуренты?

— До какой степени можно сокращать
операционные ресурсы без ущерба для
эффективности?

— Как у нас обстоит дело с профессиональным
ростом, склонны ли наши сотрудники
делиться своим опытом с коллегами?

— Насколько лояльны наши клиенты?

— Охватывает ли наша система управления
наших партнеров?

— Можно ли считать, что каждое принимаемое
нами решение приносит компании пользу?

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

Профессор Массачусетского университета,
эксперт по искусству лидерства. Гуру
процессного управления М. Хаммер и Д.
Чампи заметили, что «не продукты, а
эффективные процессы их создания и
развития приносят компаниям долгосрочный
и устойчивый успех».

Большинство производственных компаний
уделяют пристальное внимание своим
процессам и повышению их эффективности.

13.1. Управление запросами на обслуживание

Управление запросами на обслуживание (Request Fulfillment) — процесс, ответственный за управление жизненным циклом всех запросов на обслуживание [1].

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

Основные цели процесса Управления запросами на обслуживание:

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

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

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

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

Ответственность за формальное закрытие запроса на обслуживание чаще всего лежит на сервис-деске.

Метриками эффективности процесса Управления запросами на обслуживание могут быть:

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

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

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

Проблема (Problem) — причина одного или нескольких инцидентов[1].

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

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

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

Управление проблемами состоит из двух подпроцессов:

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

Реактивный процесс управления проблемами изображен на рис. 13.1

Рассмотрим основные этапы Реактивного управления проблемами.

Первый этап — обнаружение проблемы. Существует множество путей обнаружения проблем, в частности:

• обнаружение или «подозрение» причины возникновения одного или более инцидентов от сервис-деска. Сервис-деск может разрешить инцидент, но не выявить его первопричину, что увеличивает вероятность возникновения аналогичных инцидентов в дальнейшем. В этом случае формируется запись о проблеме для поиска основной причины инцидента;
• анализ инцидента технической группой поддержки, в результате которого будет выявлено существование проблемы или вероятность ее существования;
• автоматическое обнаружение сбоев приложений или компонентов инфраструктуры, которое выявит необходимость создания записи о проблеме;
• уведомление о существовании проблемы от поставщика или подрядчика;
• анализ инцидентов как часть проактивного управления инцидентами[17].

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

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

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

Для определения приоритета проблемы необходимо также оценить ее «тяжесть» или то, насколько она серьезна для инфраструктуры:

• систему можно восстановить или она должна быть заменена?
• сколько это будет стоить?
• сколько людей и какой квалификации необходимо для решения проблемы?
• сколько времени займет решение проблемы?
• насколько велик охват проблемы? ( например, сколько конфигурационных единиц она затрагивает)

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

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

• хронологический анализ. Когда возникает сложная проблема, могут появиться противоречивые отчеты и сообщения относительно того, что действительно случилось. Для восстановления картины документально фиксируют хронологию всех событий, связанных с проблемой. Это помогает также выяснить зависимости и устранить из цепочки события, которые не относятся к рассматриваемой проблеме.
• Анализ потерь (Pain Value Analysis) — методика, используемая для идентификации влияния на бизнес одной или нескольких проблем. Формула расчета потерь основана на количестве затронутых пользователей, продолжительности простоя, влияния на каждого пользователя, и стоимости для бизнеса (если известно).
• Анализ Кепнера и Трего — системный подход к разрешению проблем. Проблема анализируется в терминах Что, Где, Когда и Сколько. Определяются возможные причины. Наиболее вероятная причина подвергается проверке. Таким образом определяется истинная причина.
• «Мозговой штурм» — методика, которая помогает команде генерировать идеи. При этом идеи не должны критиковаться и анализироваться во время проведения самого Мозгового штурма, это происходит после.
• Диаграмма Ишикавы — методика, помогающая команде определить все возможные причины проблемы. Первоначально была разработана Каору Ишикавой (Kaoru Ishikawa), результатом работы этой методики является диаграмма[1]. Основная проблема изображается в виде ствола диаграммы, главные факторы — как ветки, вторичные факторы — как соплодие и т.д. Создание диаграммы стимулирует обсуждение проблемы и более глубокое понимание ее сложности.
• анализ Парето — методика отделения значимых причин возникновения проблемы от незначимых. Должны быть предприняты следующие действия:
  1. сформировать таблицу, содержащую причины проблемы и их частоту в процентном соотношении от общего количества случаев возникновения проблемы;
  2. упорядочить строки таблицы в порядке увеличения важности причин;
  3. добавить столбец совокупного процента.

     Более понятным анализ Парето будет на примере из публикации ITIL. В табл. 13.1 приведены 10 причин отказа сетевых взаимодействий, то есть «падения сети».

     Таблица
     13.1.

     	«Падение сети»
     Причины	Процент от общего количества (%)	Расчет	Совокупный процент (%)
     Сетевой контроллер	35	0+35	35
     Порча файлов	26	35+26	61
     Конфликт адресации	19	61+19	80
     ОС Сервера	6	80+6	86
     Ошибки скриптов	5	86+5	91
     Непротестированное изменение	3	91+3	94
     Ошибки оператора	2	94+2	96
     Сбой резервного копирования	2	96+2	98
     Попытки вторжения	1	98+1	99
     Сбой дисков	1	99+1	100

     Далее необходимо сделать следующие шаги:

  4. создать столбиковую диаграмму причин, расположенных в соответствии с их Процентом от общего количества ( 2 столбец);
  5. наложить линию суммарного процента (4 столбец).
  6. нарисовать линию от 80 % совокупного процента к оси y, параллельно оси x. В точке пересечения с линией суммарного процента «уронить» ее на ось x. Точка оси x, на которую «упадет» линия отделит значимые причины от незначимых.

Диаграмма рассматриваемого примера изображена на рис. 13.2.

Следующий этап — поиск обходного решения. Обходное решение (Workaround) — уменьшение или устранение влияния инцидента или проблемы, для которых в текущий момент недоступно полное разрешение[1]. Например, перезапуск отказавшей конфигурационной единицы или ручное добавление поврежденного файла из резервной копии. Обходные решения являются временными решениями для поддержания работоспособности системы на время поиска решения проблемы. Обходные решения документируются в Базе известных ошибок. База известных ошибок (Known Error Database или KEDB) — база данных, содержащая все записи об известных ошибках. Эта база данных создается в процессе Управления проблемами и используется процессами Управления инцидентами и проблемами. База известных ошибок это часть Системы управления знаний по услугам (SKMS) [1].

Как только найдено решение проблемы, его необходимо как можно быстрее реализовать. Тем не менее, важно помнить, что внесение изменений может затронуть другие услуги или конфигурационные единицы. Если необходимо какое-то функциональное изменение, прежде чем его осуществить, надо сформировать Запрос на изменение, который будет обработан в рамках процесса Управления изменениями. После того, как все необходимые действия предприняты, проблема устранена, происходит закрытие записи о проблеме, а также всех связанных с ней записей об инцидентах. Перед закрытием необходимо провести проверку (пересмотр) полноты записи о проблеме — она должна содержать детальное описание всех осуществленных процедур и действий. Для значительных проблем, которые считаются таковыми в соответствии с системой приоритетов конкретной организации, проверка должна быть более детальной, в частности рассматривать такие вопросы как:

• что сделано правильно в отношении проблемы;
• что сделано неправильно в отношении проблемы;
• что может быть сделано лучше в будущем;
• как предотвратить повторение проблемы;
• были ли задействованы третьи стороны.

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

Для оценки эффективности процесса Управления проблемами можно использовать следующие метрики:

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