Информационная система Help Desk отдела технической поддержки ОО. Информационная система Help Desk отдела технической поддержки ооо трейд
 Скачать 3.58 Mb.
|
Модель деятельности отдела технической поддержки: «как есть»Чтобы выполнить системное исследование отдела технической поддержки, необходимо изучить структуру происходящих внутри бизнес-процессов. Для этих целей строится модель «как есть». Применим структурный подход и нотацию 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 индивидуальный листок заданий, мы решим проблему своевременного оповещения специалистов и оптимального расхода времени. Таким образом, оптимизации должны быть подвергнуты два последних бизнес-процесса, структура остальных соответствует целям функционирования отдела и не оказывает отрицательного влияния на качество его работы. |