Автоматизация учета и обработки заявок пользователей. Часть 4

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

1. 1. 1. ЖЦ для «Заявка»

Для типа документа «Заявка» настраиваем статусы жизненного цикла.

Табл. Статусы жизненного цикла документа «Заявка»

1. 1. Характеристика результатной информации

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

1. Журнал поступления заявок за период;
2. Список заявок по статусам;
3. Список открытых заявок;
4. Список открытых просроченных заявок;
5. Список заявок  по исполнителям;
6. Просроченные заявки по времени решения;
7. Оценка выполнения заявок в разрезе исполнителей;
8. Среднее время между заявками.

Журнал поступления заявок за период с ХХ.ХХ.ХХХХ

Итого по статусам

Открыта –        ххх

Одобрена –     ххх

Отклонена –    ххх

Уточнение –    ххх

В работе –        ххх

Выполнена –   ххх

Закрыта –         ххх

Описание: Отчёт отражает поступление заявок за период с указанной даты по текущее время.

Критерии выборки: В отчёт выбираются заявки, поступившие с указанной даты по текущий момент. Подсчитывается статистика в разрезе статусов заявок.

Список заявок  по статусам

Статус: ХХХХХХХХХХ

Итого:

Описание: В отчёт выбираются все заявки с указанным статусом, подсчитывается итог по статусу. 

Список открытых заявок  

На дату: ХХ.ХХ.ХХХХ

Итого:

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

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

Открытая заявка — заявка, которая находится в любом статусе кроме «Выполнена» и «Закрыта».

Список открытых просроченных заявок  

На дату: ХХ.ХХ.ХХХХ

Итого:

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

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

Открытая заявка — заявка, которая находится в любом статусе кроме «Выполнена» и «Закрыта».

Просроченная заявка — открытая заявка, у которой время на решение истекло, прежде чем заявка была переведена в статус «Решена».

Список заявок  по исполнителям 

Итого:

Описание: В целях повышения эффективности работы сотрудников команды необходимо оценивать:

• какой сотрудник решает больше заявок;
• у какого сотрудника больше заявок на исполнении.

Критерии выборки: Отчет отражает данные по статусам заявок в ответственности сотрудников команды.

Открытая заявка — заявка, которая находится в любом статусе кроме «Выполнена» и «Закрыта».

Закрытая заявка — заявка, которая была решена в указанный период времени и на текущий момент закрыта.

Просроченные заявки по времени решения  

На дату: ХХ.ХХ.ХХХХ

Итого:

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

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

Закрытая заявка — заявка, которая находится в статусе «Закрыта».

Просроченная заявка — заявка, у которой фактическое время реакции превышает время на реакцию, указанное в Каталоге услуг.

Оценка выполнения заявок в разрезе исполнителей  

На дату: ХХ.ХХ.ХХХХ

Итого:

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

Критерии выборки: Решенная заявка — заявка, которая была решена в указанный период времени и на текущий момент закрыта.

Среднее время между заявками

Период: хх.хх.хххх – хх.хх.хххх

Итого:

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

В отчете отображается информация о двух метриках инцидента:

• Метрика «Среднее время между инцидентами» показывает среднее время между инцидентами, возникшими в указанный период времени по конкретной услуге. По величине данной метрики можно отслеживать качество работы службы технической поддержки. Величина метрики — среднее время ожидания возникновения повторного инцидента (после первого).
• Метрика «Среднее время бесперебойной работы» показывает среднее время бесперебойной работы (т.е. среднее время предоставления услуги без инцидентов). По величине данной метрики можно отслеживать качество предоставляемых услуг. Величина метрики — среднее время, через которое возникает инцидент (показывает как часто возникают инциденты по оказываемой услуге).

Критерии выборки: 

• Метрика «Среднее время между инцидентами» отображает данные по заявкам типа «Инцидент», зарегистрированным в указанный период времени.

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

Формула для подсчета значения:

(время последнего инцидента в периоде – время первого инцидента в периоде)

—————————

(количество инцидентов – 1)

• Метрика «Среднее время бесперебойной работы» отображает данные по заявкам типа «Инцидент», зарегистрированным в указанный временной период.

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

Формула для подсчета значения:

(конец временного интервала – начало временного интервала)

—————————

(количество инцидентов + 1)

Для хранения всех вышеперечисленных документов не используется каких-либо таблиц в базе данных. Формирование результатных документов происходит по запросу, после чего они могут быть выведены на экран, на печать, сохранены в документ Microsoft Excel и отправлены адресату по электронной почте.

Кроме того, для контроля бизнес-процессов используются стандартные экранные формы системы ELMA BPM. Для оперативного контроля хода бизнес-процесса предназначены страницы Мои процессы, Карта процесса и Монитор процессов.

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

 

Рис. Раздел «Процессы»

Используя дерево фильтров раздела «Процессы» можно просматривать различные списки своих процессов. Подраздел Мои процессы предоставляет статистическую информацию (Рис. ):

 

Рис. Подраздел «Мои процессы»

В веб-приложении можно открыть Карту процесса, которая показывает ход выполнения и текущую операцию (выделена зелёным жирным шрифтом) Рис. :

 

Рис. Карта процесса

Экранная форма Монитор процессов необходима для анализа работы по процессам (Рис. ):

 

Рис. Монитор процессов

Выбрав любой процесс, попадаем на Страницу монитора процесса (Рис. ):

 

Рис. Страница монитора процесса

Здесь приведена подробная информация по каждому экземпляру процесса.

1. 1. Моделирование процесса «Заявка в ИТ-службу»

Процесс «Заявка в ИТ-службу» соответствует практики ITIL Управление инцидентами и служит для разрешения инцидентов при использовании компьютерной техники или программного обеспечения в компании.

1. 1. 1. Схема процесса
      2. Краткое описание
      3. Входные и выходные свойства
      4. Зоны ответственности

1. 1. 1. Первоначальная настройка процесса

Доступ

Статусы

Наименование экземпляров

1. 1. 1. Запуск процесса
      2. Шаги  бизнес-процесса
         1. Оформить заявку

 

Тип шага:

Исполнитель: Инициатор процесса – любой пользователь системы.

Задача: Оформить заявку. Заполнить/проверить поля:

• Вид проблемы – выбрать техника/программа;
• Описание проблемы – кратко описать суть проблемы, обязательное поле;
• Прикреплённые файлы – загрузите файлы, скриншоты, поясняющие инцидент;

Переходы:

• Согласовать с руководителем – если по регламенту этот вид инцидента необходимо согласовывать с руководителем;
• Отмена – отменить заявку;
• Отправить заявку – отправить заявку дальше по маршруту.

1. 1. 1. 1. Согласовать заявку

 

Исполнитель: Руководитель инициатора.

Задача: Согласовать заявку. Руководитель просматривает проект заявки и принимает решение по её необходимости. Заполняет поле Комментарий руководителя.

Переходы:

Отказать – руководитель отказывает в инициации заявки;

Согласовано – заявка согласована и направляется инициатору для дальнейшей работы.

1. 1. 1. 1. Классификация заявки

1. 1. 1. 1. Консультация

1. 1. 1. 1. Уточнение информации по заявке

1. 1. 1. 1. Выполнение заявки

1. 1. 1. 1. Анализ инцидента

1. 1. 1. 1. Создать запись в базе знаний

1. 1. Процесс «Управление проблемами»

Процесс «Управление проблемами» — предназначен для выявления, анализа и решения  причин появления инцидентов.

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

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

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

Грамотное и регулярное использование практики управления проблемами даёт бизнесу следующие преимущества:

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

 В компании ООО «ЭлектроПрофи» первым кто замечает проблему и связанные с ней инциденты, является диспетчер ИТ-отдела, который и выступает инициатором запуска процедуры управления проблемой. Кроме него, в процессе также участвуют следующие процессные роли:

• Менеджер проблемы
• Технический руководитель 
• Участники группы по решению проблемы
• Владелец услуги
• Владелец процесса 

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

1. Идентификация проблемы

Цель: Определить и зарегистрировать проблему, которую надо решить

1. Классификация проблемы

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

1. Формирование группы по решению проблемы

Цель: Сформировать группу.

1. Диагностика и поиск решения

Цель: Поиск решения проблемы, инициация изменений.

1. Описание решения и проверка

Цель: Убедиться, что проблема решена, или инициировать дополнительные работы по решению проблемы.

1. Закрытие 

Цель: Убедится, что проблема решена, проинформировать все заинтересованные стороны.

Карта процесса представлена на Рис. :

 

Рис. Карта процесса Управление проблемами

Контекст процесса представлен на Рис. :

 

Рис. Список контекстных переменных процесса Управление проблемами

1. 1. Процесс «Управление базой знаний»

Процесс Управление знаниями необходим для сбора и анализа знаний и информации в компании. Информация сохраняется и накапливается в Базе знаний. 

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

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

База знаний состоит из разделов и подразделов. Рекомендуется структурировать её на основе Каталога услуг. За каждый раздел должен быть назначен ответственный специалист, который контролирует актуальность информации в базе знаний.

Примерный состав Базы знаний:

• Регламенты, инструкции;
• Руководства пользователей;
• Шаблоны документов;
• Видео-уроки;
• Полезные статьи;
• Записи внутренних семинаров, вебинаров, выступлений и т.д.;
• Клиентские FAQ;
• Корпоративная библиотека: книги, видео-тренинги;
• Типовые планы обучения сотрудников;
• И т.д.

База знаний должна быть структурирована в соответствии с Каталогом услуг:

• Аппаратное обеспечение
  • Ноутбук
  • Печатающее оборудование (принтеры, МФУ)
  • Сканирующее оборудование (сканер)
  • Системный блок
  • И т.д.
• Отдел развития инфраструктуры
  • Сервера и системные службы
  • Система хранения данных
  • Сети передачи данных
  • Видеонаблюдение
  • И т.д.
• Программное обеспечение
  • Adobe Reader
  • Flash Player
  • Java
  • MS Office
  • MS Windows
  • Антивирус
  • Интернет
  • И т.д.
• Программное обеспечение 1С
  • 1С: Бухгалтерия 8.3
  • 1С: ЗиУП
  • Изменение и разработка печатных форм
  • Проектная реализация
• Работа с программами
  • Внесение изменений в справочники
  • Внести изменения в документы
  • Электронный документооборот
• Организация переезда
  • Перенос аппаратных средств
  • Перенос учетной записи

Преимущества ведения базы знаний:

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

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

• Администратор БЗ;
• Редактор;
• Менеджер процесса;
• Куратор услуги;
• Владелец процесса.

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

1. Получить информацию об инциденте;

Цель: Изучить инцидент и связанные с ним проблемы.

1. Проверить наличие в базе знаний;

Цель: Убедиться в отсутствии информации в БЗ по инциденту.

1. Уточнить информацию у инициатора инцидента; 

Цель: Запросить у инициатора дополнительную информацию для оценки вариантов рассмотрения.

1. Собрать информацию;

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

1. Анализ информации;

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

1. Документирование;

Цель: Оформить информацию в привычном виде для восприятия пользователем.

1. Проверить полноту и непротиворечивость;

Цель: Проверить информацию на ключевых сотрудниках.

1. Передать информацию Администратору БЗ;
2. Добавить информацию в БЗ;
3. Оповещение пользователей БЗ.

Карта процесса представлена на Рис.

 

Рис. Карта Процесса Управление базой знаний

Контекст процесса представлен на Рис. :

 

Рис. Список контекстных переменных процесса Управление базой знаний

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