Сценарий бизнес-процессов организации рассмотрения заявок на выполнение работ

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

• 1. Мониторинг;
• 2. Поступление информации о неисправности;
• 3. Обработка информации, передача на исполнение техническим специалистам (системному администратору, инженерам или техникам);
• 4. Устранение неисправности;
• 5. Документирование процесса работы.

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

Рассмотрим укрупненный сценарий бизнес-процессов, связанный с обработкой поступающих заявок (см. рисунок 1.5).

Рисунок 1.5 — Сценарий бизнес-процессов отдела технической поддержки.

В данном сценарии участвуют четыре действующих лица:

• 1. Инициатор, которым является сотрудник или подразделение ООО Трейд;
• 2. Диспетчер;
• 3. Исполнитель — сотрудник из числа технических специалистов;
• 4. Руководитель.

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

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

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

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