Модель деятельности отдела технической поддержки: «как есть»

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

На рисунке 2.1 изображена контекстная диаграмма, с которой согласно нотации начинается моделирование.

Рисунок 2.1 — Контекстная диаграмма Диаграмма дает нам следующее представление о бизнес-процессе:

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

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

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

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

Рисунок 2.2 — Диаграмма декомпозиции первого уровня По результатам декомпозиции выявлены следующие бизнес-процессы:

Мониторинг состояния КТС и ПО. Ответственные технические специалисты постоянно следят за исправностью комплекса технических средств и программного обеспечения посредством плановых проверок. Диспетчер отдела регистрирует возникающие неисправности и потребности посредством фиксации в журнале заявок;

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

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

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

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

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

Проведем первую декомпозицию бизнес-процесса «Мониторинг состояния КТС и ПО» (рисунок 2.3).

Рисунок 2.3 — Диаграмма декомпозиции бизнес-процесса.

" Мониторинг состояния КТС и ПО" .

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

• 1. Проводить плановые проверки. Технический специалист в соответствии с должностной инструкцией в установленные сроки производит диагностику оборудования и программного обеспечения. В случае возникновения неисправности, соответствующая информация подается диспетчеру;
• 2. Регистрировать факт возникновения неисправности. Диспетчер со слов подающего сведения фиксирует в журнале факт возникновения неисправности и его описания. Устанавливается степень сложности заявки, ее класс (по специализации сотрудников) и сроки устранения. Вместе с этими параметрами заявка передается на следующий бизнес-процесс;
• 3. Передать заявку на исполнение. Заявка, дополненная параметрами, оценивается диспетчером. Осуществляется поиск свободных технических специалистов, которые назначаются исполнителями. Заявка передается на исполнение. При этом выделяется два вида исполнения — установка (недостающих компонентов или их обновление) и устранение (неполадок);
• 4. Передать заявку на контроль. Заявка, дополненная параметрами, а также данные об ответственном за ее исполнение лице подается сотруднику, ответственному за контроль качества работы отдела — его начальнику;

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

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

Рисунок 2.4 — IDEF3-диаграмма декомпозиции бизнес-процесса «Регистрировать факт возникновения неисправности» .

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

• 1. Выяснить причину обращения. Диспетчер из поступившего обращения выделяет необходимую информацию, которая составит содержание заявки;
• 2. Сформировать заявку. Диспетчер формулирует заявку на основании поступившего обращения. Происходит оценка сложности заявки и ее классификация;
• 3. Запись в журнале обращений. Диспетчер делает запись в журнал обращений, которая служит основанием для учета операций, совершенных отделом технической поддержки;
• 4. Подсказать решение. Если неисправность, по мнению диспетчера, является элементарной и его опыт позволяет лично подсказать ее решение, то обратившемуся сразу выдается ответ по его проблеме;
• 5. Оформить заявку. Если диспетчер не может сразу дать ответ на обращение, то в зависимости от характера обращения на бланке установленного образца формируется лист заявки на устранение или на установку.

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

Следующим декомпозируем бизнес-процесс «Передать заявку на исполнение» (рисунок 2.5).

Рисунок 2.5 — Диаграмма декомпозиции бизнес-процесса «Передать заявку на исполнение» .

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

• 1. Оценить загруженность специалистов. Диспетчер имеет на руках так называемые индивидуальные листки заданий, в которых содержатся записи о выданных специалисту заявках и отметки об их выполнении. Исходя из записей в этих листках, выбираются наиболее свободные сотрудники;
• 2. Выбрать подходящего специалиста. Диспетчер, руководствуясь профессиональным уровнем свободных специалистов и уровнем сложности поступившей заявки, выбирает подходящего специалиста;
• 3. Присвоить заявку. Диспетчер назначает сотрудника, ответственного за устранение возникшей неисправности, записывая в его индивидуальный листок заданий соответствующую информацию. Каждый сотрудник должен как минимум два раза за рабочий день ознакомиться с листком заданий.

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

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