CC BY
441
МОДЕЛИРОВАНИЕ ПРОЦЕССА ОБРАБОТКИ ЗАЯВОК В СЛУЖБЕ ТЕХНИЧЕСКОЙ ПОДДЕРЖКИ
СЛОЖНЫХ ТЕХНИЧЕСКИХ СИСТЕМ Р.В. Иванов, А.В. Маятин, А.Е. Михайленко
На примере процесса обработки заявок на ремонт офисной техники рассмотрено место технического обслуживания в жизненном цикле сложных технических систем. Проанализированы возможности и ограничения систем класса Не1рБе8к для поддержки этого процесса. Построена модель процесса, обладающая большей прогностической силой в условиях реального бизнес-процесса.
Введение
Информатизация современного бизнеса приводит к росту плотности и усложнению структуры информационных потоков, циркулирующих в офисе. Для организации службы технической поддержки (СТП) таких потоков уже недостаточно концепции независимо существующих единиц офисной техники, а требуется переход к концепции сложной технической системы (СТС). В литературе (см., например, [1-4]) представлены различные трактовки понятия СТС, но общими являются следующие аспекты:
• понятие СТС связывается не с размером (номенклатурой элементов), а с модельной сложностью;
• управление СТС организуется в условиях неопределенностей различного типа, в том числе параметрической, структурной, модельной;
• в состав СТС должны включаться звенья (например, экспертные системы), способные адекватно задаче компенсировать эту неопределенность;
• в качестве таких звеньев могут выступать люди как элементы принятия решения.
Соответственно, в качестве объекта технической поддержки в работе рассматривается система, включающая в себя офисную технику (аппаратное обеспечение), программное обеспечение и персонал офиса в различных ролевых позициях.
В соответствии с требованиями ГОСТ Р ИСО серии 9000 [5, 6] СТП должна переходить от устранения отдельных дефектов по мере их возникновения к менеджменту качества системы в целом. В систему менеджмента качества производственной системы [5, 6] как обязательные процедуры введены «Корректирующие действия» (КД) и «Предупреждающие действия» (ПД). В частности, процедура КД должна включать [7]:
• рассмотрение сообщений о несоответствиях продукции и рекламаций потребителей;
• изучение причин несоответствий и регистрацию результатов такого изучения;
• проверку выполнения КД и их результативности.
Процедура ПД должна включать:
• использование всех источников информации для выявления, анализа и устранения потенциальных причин несоответствий;
• определение требуемых мер;
• осуществление мер, проверку их выполнения и результативности;
• доведение информации о предпринятых действиях и их результатах до сведения руководства для анализа и принятия решения.
Согласно требованиям стандартов [5, 6], КД и ПД должны быть организованы в виде цикла Шухарта-Деминга (планирование-выполнение-контроль-воздействие, РБСЛ) [8, 9]. Этот цикл универсален и применим почти ко всем процессам в организации, но в силу высокого уровня общности требует конкретизации с учетом специфики производственной системы. В то же время высокая динамичность и вариативность объектов технической поддержки не позволяют рассматривать задачи проектирования конкретной СТП как уникальные, а требуют перехода к созданию САПР СТП.
Анализ факторов неопределенности, характерных для СТП
Как показывает практика, на большинстве предприятий, входящих в сегмент малого и среднего бизнеса (БЫВ), четкий регламент работы СТП отсутствует. На рис. 1 в нотации ГОЕБЗ [10-12] представлена модель, описывающая процесс «как есть».
Рис. 1. Нерегламентированный процесс работы СТП
Выделим особенности такой организации СТП.
• При возникновении проблемы пользователю приходится самостоятельно определять ее причину, чтобы сообщить в СТП.
• Информация о проблеме передается, как правило, устно (по телефону) и должна быть повторена для каждого нового специалиста, подключившегося к ее решению.
• Отсутствуют средства структурирования и детальной фиксации проблемы (шаблоны и пр.).
• Диспетчирование и контроль прохождения заявки на обслуживание выполняются, как правило, на уровне межличностных отношений, соответствующие средства информационной поддержки отсутствуют или не используются.
Очевидно, что в этой модели СТП время и средства, затрачиваемые на устранение проблемы, неоправданно велики, что во многом связано с наличием в СТП факторов неопределенности различной природы.
Организация работы НЫрОеэк
Сформировать заявку
Обработать заявку
Выполнить заявку
Сформировать Базу Знаний
П ро ко нтроли ровать выполнение заявок
О Подать заявку через
вэб-форму О Позвонить О Написать е-таН О Принести в поддержку
бумажную заявку О Формализовать заявку
О Осуществить
начальную поддержку О Установить статус
заявки О Информировать пользователя о результатах работы О Назначить
исполнителей О Отправить заявку в работу
О Ознакомиться с
заявкой О Отработать заявку О Связаться с
пользователем для получения допол н ител ьно й информации
О Определить проблемную область О Создать описание
проблемы О Создать описание
решения проблемы О Создать проблемную область О Определить
категорию О Создать запись в
Базе Знаний О Создать категорию
О Выявить просроченные необработанные заявки О Выявить причины О Принять решение
об оптимизации О Пересмотреть
нагрузки О Оставить заявку
без изменений О Переназначить исполнителя
Рис. 2. Источники неопределенностей в СТП
Проведенный авторами анализ СТП офисной техники как СТС позволил выделить источники неопределенностей, возникающие на различных этапах обработки заявки (см. рис. 2).
Модельная сложность и неопределенности различного типа, присущие СТП офисной техники как СТС, выдвигают на первый план при построении САПР СТП офисной техники проблемы построения моделей процессов обслуживания, которые, с одной стороны, обладают достаточной прогностической силой для поддержки процедур КД и ПД, а с другой стороны - могут быть программно реализованы в рамках САПР как информационной системы.
Анализ возможностей парирования неопределенностей в существующих
системах поддержки СТП
Рассматривая СТП как СТС, ее моделирование можно проводить на различных системных уровнях. Так, широкое распространение получили модели массового обслуживания. Модели типа систем массового обслуживания (СМО) используются обычно для оценки времен ожидания в случайных процессах с очередями. Такое моделирование системы предполагает, что:
• система функционирует в непрерывном времени;
• задача системы - реагировать на поток заявок;
• заявки появляются и завершаются в случайные моменты времени, т. е. система является стохастической.
СМО определяется кортежем 0=^, и, 2, Я, Н, Л>, где W - подмножество входящих потоков (подмножество неуправляемых переменных), И - подмножество потоков обслуживания (подмножество управляемых переменных), Ъ - состояние системы, Я - оператор сопряжения, формирующий направленный граф движения заявок, Н - подмножество собственных параметров схемы, Л - оператор алгоритмов (дисциплин) поведения заявок.
Как правило, получить оценки для СМО в аналитической форме удается только при сильных упрощающих предположениях, а именно для одноканальной схемы с ма-ровским входящим потоком и марковским потоком обслуживания. Для оценки работы реальных СМО требуется имитационное моделирование. Даже в этом случае имеются проблемы, в том числе: параметры прибора обслуживания постоянны, не позволяет моделировать текущую активность звеньев обслуживания и текущую смену модельных представлений.
иВЕОЛТ. литнс«. АЬтеуМЫнук-пко ОАТС. М. 10.2007 ■ хтогаомб яшзся олтп СООТЕХТ
РИибСТ иргликии^ня работы ЫНрСкчк ОНАРТ
едссммемсео
N07 С 5: 123466769 10 РиВиСАТЮМ АО
[1гш«арты. ^плиятч дцщ.
ИНСТИ"'"" ™...........
> ХМвП , ГИфИНИП
огикюотэть зарвку 5478_
1 ГРОРЭ5С1 ^-¥
ЕкНт >ачиг--'-
От-
~*0
АО
Организация работы Не1рОе5к
Рис. 3. Общая схема организации процесса работы систем класса Не!р0евк
Поэтому широкое распространение получил альтернативный подход к моделированию СТП, состоящий в построении интегральной модели бизнес-процесса и последовательном ее уточнении вплоть до уровня отдельных бизнес-переходов, имеющих программно реализуемую информационную поддержку. На этой модели основаны информационные системы для поддержки СТП класса Не1рРеБк.
Системы класса Не1рёеБк - это информационные системы, предназначенные для обработка задач (запросов) любых пользователей, постановки задач между исполнителями, накопления информации о каждой из задач, назначения ответственных и отслеживание сроков реакции и выполнения. Обобщенная схема организации работы систем класса Не1рРеБк представлена на рис. 3.
литио«. Ак)»уМ1М1ау!ег*0 ОЛТЕ. М.10.2007
РНОЛСГ СЗртяннаацйя р.ге-аги Мй^-Пйи». ВДУ Л 1?ЗМГ
Рис. 4. Разделение ролей на этапе обработки заявки.
На рис.3 выделены стандартные роли для такого класса БП:
• пользователь самостоятельно ищет решения возникшей проблемы в Базе Знаний или при помощи оператора-координатора или самостоятельно составляет заявку об инциденте;
• оператор-координатор при возможности помогает пользователю решить проблему с помощью собственных знаний и Базы Знаний или формализует заявку, относя ее к определенной категории, назначает инженера для разрешения заявки и фиксирует ее закрытие, следит за сроками исполнения заявок;
• инженер НР решает проблему и возвращает оператору-координатору отчет о выполнении заявки.
• начальник группы НР следит за сроками и качеством исполнения заявок, контролирует целостность базы знаний.
Системы класса Не1рРеБк поддерживают эффективность работы СТП за счет жесткой формализации ролей пользователей и связанных с этим прав доступа к системе (рис.4).
Выделим особенности такой организации СТП.
• При возникновении проблемы пользователь формулирует ее причину, самостоятельно или с помощью оператора, опираясь на информацию в БЗ.
• Информация о проблеме поступив в БД передается оператору для регистрации, быстрой обработки или передачи специалисту, все этапы обработки заявки фиксируются.
• Диспетчирование и контроль прохождения заявки на обслуживание максимально формализованы, применяются стандартные шаблоны как для заявки, так и для всех этапов ее решения, в том числе для хранения решений заявок в БЗ.
Анализ наиболее распространенных на российском рынке систем класса Не1рБевк [13-16] показал, что:
• большинство систем заявлено разработчиками как масштабируемые, однако масштабируемость имеет смысл расширения функциональностей в рамках жестко определенной структуры бизнес-процесса, в том числе четкого разделения ролей пользователей;
• эффективная работа систем предполагает наличие наполненной БЗ;
Это нивелирует эффективность использования такого класса систем на начальных этапах развития бизнеса, особенно в малом и среднем бизнесе.
Пути модификации систем класса Не1рБе8к для поддержки СТП
с неопределенностями
При взаимодействии СТП с клиентом (рис. 5) можно выделить несколько источников неопределенности.
КЛИЕНТ
|пользовател1^ + ^ Техника
. стс
ЗАЯВКА.
СТП
^ Оператор ^ —*- ^ Инженер""^
I
, Объеденение ролей I
Рис. 5. Взаимодействие клиент-СТП
Во-первых, клиент должен моделироваться как СТС, включающая в себя техническое устройство и пользователя. С точки зрения СТП эти две составляющие неразделимы, поскольку оказывают постоянное воздействие друг на друга, и, следовательно, СТП не может быть полностью формализована. Следовательно, в соответствии с общесистемными принципами [1], не может быть полностью формализована и заявка на обслуживание, поступающая от клиента
Рис. 6. Смешение ролей на этапе обработки заявки
Во-вторых, оператор производит первичную классификацию поступающих заявок для передачи на исполнение инженеру на основании слабо формализованных данных и часто неполных данных. Эффективность такой классификации может быть повышена за счет либо высокой квалификации оператора как системного инженера, либо использования БЗ, позволяющей по ряду признаков уточнить описание заявки.
Таким образом, в случае практического применения внедрения систем класса HelpDesk на начальном этапе или в условиях малого штата СТП происходит смешение ролей пользователей системы (рис. 6), специфичное для конкретного БП.
Для разрешения сформулированного противоречия целесообразно использовать следующий комплекс мер.
1. Введение в систему возможности назначения одному пользователю нескольких ролей. Например, в момент приема заявки от пользователя необходимо формализовать суть неисправностей и постараться выявить возможные причины их появления. Это требует высокой специализации или наличия обширной БЗ. Если таковой нет или она еще в процессе формирования, на приеме заявок необходим специалист, а не просто оператор. С учетом требований системы ему придется постоянно входить в систему под другой ролью, что неудобно. В то же время назначение пользователю одновременно нескольких ролей позволит с развитием системы высвободить специалиста от выполнения невысококвалифицированного труда оператора-диспетчера.
2. Фиксирование текущей роли пользователя в системе, от имени которой совершено действие (присвоение флага роли операции).
Наиболее эффективным видится введение в интерфейсы пользователей системы со стороны СТП дополнительного элемента в виде экранного меню с обозначением текущей роли пользователя на каждом логическом этапе жизненного цикла заявки. Существенно, что такое обозначение должно выполняться максимально эргономично («в один клик»).
3. Возможность текущего добавления ролей как декомпозиции или специализации существующих.
В процессе выполнения заявки специалист выполняет ряд действий, которые эффективнее разделить на несколько этапов. Например, при создании локальной сети клиента необходимо выполнить следующие работы:
- прокладка кабелей;
- установка сервера или другого оборудования и его настройка;
- формирование сетевой политики;
Эти действия эффективнее разделить между несколькими специалистами с более узкими специализациями и зафиксировать переходные требования. Заранее выявить все возможные роли специалистов невозможно, так же как и специализации технических специалистов.
4. Формирование БЗ с максимально полным семантическим описанием типов и групп заявок со структурированным хранилищем готовых решений.
Точность формулировок и широта связей в БЗ позволит не только сократить выезды специалиста к клиенту для подключения сетевого шнура по заявке «Не работает Интернет», но и решит проблему преемственности специалистов, когда при появлении нового работника нет необходимости вспоминать все особенности каждого конкретного клиента и ли его техники. Набор статистики использования ролей и принятых решений в жизненном цикле набора заявок позволит декомпозировать рабочий поток (Workflow) для последующего формирования диаграмм прецедентов в рамках построения БЗ как части структуры HelpDesk.
Литература
1. Перегудов Ф.И., Тарасенко Ф.П. Введение в системный анализ. - М.: Высш. шк., 1989.
2. Ларичев О.И. Теория и методы принятия решений. М.: Логос, 2000.
3. Надежность и эффективность в технике: Справочник: В 10 т. / Ред. совет: B.C. Авдуевский (пред.) и др. М.: Машиностроение, 1988. Т. 3: Эффективность технических систем / Под общ. ред. В.Ф. Уткина, Ю.В. Крючкова.
4. Акофф Р. Искусство решения проблем. М: Мир, 1982.
5. ГОСТ Р ИСО 9004-2001. Системы менеджмента качества. Рекомендации по улучшению деятельности.
6. ГОСТ Р ИСО 9001-2001. Системы менеджмента качества. Требования.
7. Адлер Ю.П., Хунузиди Е.И., Шпер В.Л. Методы постоянного совершенствования сквозь призму цикла Шухарта-Деминга /Методы менеджмента качества. 2005. № 3.
8. Иняц Н. Малая энциклопедия качества. Ч. III. Современная история качества. - М.: РИА "Стандарты и качество", 2003.
9. Управление эффективностью и качеством. Модульная программа. Ч. I. Модуль 9: Повышение эффективности и качества: концепции, процессы и методы / Под ред. И. Прокопенко, К. Норта. - М.: Дело, 2001. — 608 с.
10. Репин В.В., Елиферов В.Г. Процессный подход к управлению. Моделирование бизнес-процессов. - М.: РИА «Стандарты и качество», 2004. - 408 с., ил. - (Серия «Практический менеджмент»).
11. Черемных С.В. Моделирование и анализ систем. IDEF-технологии: практикум / С.В. Черемных, И.О. Семенов, В.С. Ручкин. - М.: Финансы и статистика, 2006. -192 с.: ил. - (Прикладные информационные технологии).
12. Маклаков С. В. Создание информационных систем с AllFusion Modeling Suite. - М.: Диалог-МИФИ, 2005. - 432с.
13. HP OpenView Service Desk http://www.hp.ru/openview/products/servicedesk/
14. Итилиум - Service Desk http://itilium.ru/content/view/8/109/
15. Naumen Service Desk http://www.naumen.ru/go/products/nausd
16. OneOrZero http://www.oneorzero.com/
