Модель деятельности отдела технической поддержки: «как есть»
Чтобы выполнить системное исследование отдела технической поддержки, необходимо изучить структуру происходящих внутри бизнес-процессов. Для этих целей строится модель «как есть». Применим структурный подход и нотацию IDEF0.
На рисунке 2.1 изображена контекстная диаграмма, с которой согласно нотации начинается моделирование.
Рисунок 2.1 – Контекстная диаграмма
Диаграмма дает нам следующее представление о бизнес-процессе:
Отдел технической поддержки руководствуется указаниями руководства и должностных инструкций. Ведет свою деятельность на основании устава;
Отдел технической поддержки в качестве механизмов исполнения бизнес-процессов использует персонал и вычислительную технику;
Отдел технической поддержки в качестве входящего потока информации имеет заявки от инициаторов (отделов или сотрудников, сообщающих о неисправности); неисправное оборудование, требующее замены или ремонта; новое оборудование и программное обеспечение, поставляемое по заказу отделом закупок;
Отдел технической поддержки в качестве потока исходящей информации имеет различные виды отчетной документации, как регламентированной, так и произвольной формы; обслуженные заявки инициаторов; заказы на закупку оборудования и программного обеспечения; отремонтированное оборудование.
Чтобы перейти к подробному рассмотрению работы отдела, необходимо выполнить декомпозицию – так в нотации IDEF0 называется процесс детализации описания. Декомпозиция будет выполнена для черного ящика «Моделировать работу отдела технической поддержки», при этом следует отталкиваться от перечня прописанных в уставе функций:
Подготовка спецификаций для закупки;
Установка, настройка, техническое сопровождение и обслуживание;
Организация автоматизированных рабочих мест;
Диагностика и устранение неисправностей вычислительной и офисной техники;
Диагностика и устранение неполадок программного обеспечения.
Координация работ с поставщиками и производителями вычислительной и офисной техники по вопросам гарантийного обслуживания и ремонта;
Координация работ с подрядчиками и субподрядчиками – производителями программного обеспечения.
Разработка и внедрение инструкций, регламентов и стандартов использования программного и аппаратного обеспечения.
Разработка, внедрение и организация контроля исполнения руководящих документов по обеспечению информационной безопасности.
Разработка Плана обеспечения непрерывной работы и восстановления работоспособности подсистем автоматизированной системы.
Анализ потребностей подразделений ООО Трейдв дополнительных средствах вычислительной техники и обработки информации.
Организация своевременного рассмотрения и исполнения заявок на выполнение работ связанных с функционированием программного и аппаратного обеспечения.
Это позволит детально изучить протекающие внутри бизнес-процессы, выявить узкие места и провести анализ способов решения существующих проблем. Диаграмма декомпозиции первого уровня представлена на рисунке 2.2.
Рисунок
2.2 – Диаграмма декомпозиции первого
уровня
По результатам декомпозиции выявлены следующие бизнес-процессы:
Мониторинг состояния КТС и ПО. Ответственные технические специалисты постоянно следят за исправностью комплекса технических средств и программного обеспечения посредством плановых проверок. Диспетчер отдела регистрирует возникающие неисправности и потребности посредством фиксации в журнале заявок;
Установка и обслуживание КТС и ПО. Технические специалисты в рамках данного бизнес-процесса выполняют в случае поступления нового программного обеспечения или оборудования, которое должно быть установлено, выполняют соответствующие задачи. Если поступившая диспетчеру заявка заключается в неплановом сервисном обслуживании или установке нового ПО, то это также выполняется в рамках данного бизнес-процесса.
Устранение неисправностей. В рамках данного бизнес-процесса происходит устранение возникающих нарушений в работоспособности оборудования и программного обеспечения на местах использования. Активация данного бизнес-процесса может произойти по инициативе диспетчера, руководствующегося заявкой, либо при выявлении неисправности в процессе сервисного обслуживания;
Поддержание и модернизация запасов КТС и ПО. В отделе технической поддержки всегда имеется набор резервного оборудования для быстрого восстановления работоспособности в случае неисправностей. Также имеется репозиторий программного обеспечения, устанавливаемого в соответствии с планом или по требованию. Актуализация данных запасов по технологиям и дополнение по объему выполняется в рамках данного бизнес-процесса.
Документационное обеспечение. Бизнес-процесс содержит в себе функции по поддержке работы и управления отделом. В его рамках создаются всевозможные отчеты, рассчитывается заработная плата технических специалистов исходя из объемов выполненных работ, формируются планы закупки оборудования и т.д.
Переходя на второй уровень декомпозиции определим интересующие нас бизнес-процессы, которые требуется модифицировать. Таковым является Мониторинг состояния КТС и ПО. Именно в рамках этого процесса выполняются наиболее рутинные операции, и он также является первопричиной нерационального расхода рабочего времени технических специалистов.
Проведем первую декомпозицию бизнес-процесса «Мониторинг состояния КТС и ПО» (рисунок 2.3).
Рисунок 2.3 – Диаграмма декомпозиции бизнес-процесса
«Мониторинг состояния КТС и ПО»
По результатам декомпозиции выявлены следующие бизнес-процессы:
Проводить плановые проверки. Технический специалист в соответствии с должностной инструкцией в установленные сроки производит диагностику оборудования и программного обеспечения. В случае возникновения неисправности, соответствующая информация подается диспетчеру;
Регистрировать факт возникновения неисправности. Диспетчер со слов подающего сведения фиксирует в журнале факт возникновения неисправности и его описания. Устанавливается степень сложности заявки, ее класс (по специализации сотрудников) и сроки устранения. Вместе с этими параметрами заявка передается на следующий бизнес-процесс;
Передать заявку на исполнение. Заявка, дополненная параметрами, оценивается диспетчером. Осуществляется поиск свободных технических специалистов, которые назначаются исполнителями. Заявка передается на исполнение. При этом выделяется два вида исполнения – установка (недостающих компонентов или их обновление) и устранение (неполадок);
Передать заявку на контроль. Заявка, дополненная параметрами, а также данные об ответственном за ее исполнение лице подается сотруднику, ответственному за контроль качества работы отдела – его начальнику;
На этом уровне декомпозиции, структура бизнес-процесса не обладает явными узкими местами, стоит отметить только отсутствие средств вычислительной техники как механизмов его осуществления.
Перейдем на более детальный уровень рассмотрения бизнес-процесса «Мониторинг состояния КТС и ПО», рассмотрим поочередно бизнес-процессы «Регистрировать факт возникновения неисправности» (рисунок 2.4) и «Передать заявку на исполнение» (рисунок 2.5). Раскрытие данных процессов сделаем в нотации IDEF3, чтобы увидеть недостатки протекающих процессов и их узкие места.
Рисунок 2.4 – IDEF3-диаграмма декомпозиции бизнес-процесса
«Регистрировать факт возникновения неисправности»
По результатам декомпозиции выявлены следующие элементарные операции:
Выяснить причину обращения. Диспетчер из поступившего обращения выделяет необходимую информацию, которая составит содержание заявки;
Сформировать заявку. Диспетчер формулирует заявку на основании поступившего обращения. Происходит оценка сложности заявки и ее классификация;
Запись в журнале обращений. Диспетчер делает запись в журнал обращений, которая служит основанием для учета операций, совершенных отделом технической поддержки;
Подсказать решение. Если неисправность, по мнению диспетчера, является элементарной и его опыт позволяет лично подсказать ее решение, то обратившемуся сразу выдается ответ по его проблеме;
Оформить заявку. Если диспетчер не может сразу дать ответ на обращение, то в зависимости от характера обращения на бланке установленного образца формируется лист заявки на устранение или на установку.
В данном процессе много узких мест. Так, здесь используются устаревшие технологии, и нет автоматизации. Вместо базы знаний или частых вопросов используется личный опыт диспетчера, что в некоторых ситуациях недопустимо. Интерпретацию проблемы вынужден делать диспетчер, может возникнуть неправильная трактовка неисправности при объяснении техническому специалисту.
Следующим декомпозируем бизнес-процесс «Передать заявку на исполнение» (рисунок 2.5).
Рисунок 2.5 – Диаграмма декомпозиции бизнес-процесса
«Передать заявку на исполнение»
По результатам декомпозиции выявлены следующие бизнес-процессы:
Оценить загруженность специалистов. Диспетчер имеет на руках так называемые индивидуальные листки заданий, в которых содержатся записи о выданных специалисту заявках и отметки об их выполнении. Исходя из записей в этих листках, выбираются наиболее свободные сотрудники;
Выбрать подходящего специалиста. Диспетчер, руководствуясь профессиональным уровнем свободных специалистов и уровнем сложности поступившей заявки, выбирает подходящего специалиста;
Присвоить заявку. Диспетчер назначает сотрудника, ответственного за устранение возникшей неисправности, записывая в его индивидуальный листок заданий соответствующую информацию. Каждый сотрудник должен как минимум два раза за рабочий день ознакомиться с листком заданий.
Структура бизнес-процесса не требует переработки, однако технологии его реализации следует заменить. Так, сделав доступным через WEB индивидуальный листок заданий, мы решим проблему своевременного оповещения специалистов и оптимального расхода времени.
Таким образом, оптимизации должны быть подвергнуты два последних бизнес-процесса, структура остальных соответствует целям функционирования отдела и не оказывает отрицательного влияния на качество его работы.