Она выполнена с целью моделирования работы отдела технической поддержки, за счет перечня прописанных в уставе функций:
1) подготовка спецификаций для закупки;
2) установка, настройка, техническое сопровождение и обслуживание;
3) организация автоматизированных рабочих мест;
4) диагностика и устранение неисправностей вычислительной и офисной техники;
5) диагностика и устранение неполадок программного обеспечения;
6) координация работ с поставщиками и производителями вычислительной и офисной техники по вопросам гарантийного обслуживания и ремонта;
7) координация работ с подрядчиками и субподрядчиками - производителями программного обеспечения;
8) разработка и внедрение инструкций, регламентов и стандартов использования программного и аппаратного обеспечения;
9) разработка, внедрение и организация контроля исполнения руководящих документов по обеспечению информационной безопасности;
10) разработка плана обеспечения непрерывной работы и восстановления работоспособности подсистем автоматизированной системы.
11) анализ потребностей подразделений ооо цсс в дополнительных средствах вычислительной техники и обработки информации.
12) организация своевременного рассмотрения и исполнения заявок на выполнение работ, связанных с функционированием программного и аппаратного обеспечения.
Рисунок 2 - Диаграмма декомпозиции первого уровня
По декомпозиции выявлены следующие бизнес-процессы.
· Мониторинг состояния КТС и ПО. Ответственные специалисты техподдержки постоянно следят за исправностью комплекса технических средств и программного обеспечения посредством плановых проверок. Сотрудник отдела регистрирует возникающие неисправности и потребности посредством фиксации в журнале заявок.
· Установка и обслуживание КТС и ПО. Технические специалисты в рамках данного бизнес-процесса выполняют в случае поступления нового программного обеспечения или оборудования, которое должно быть установлено, выполняют соответствующие задачи. Если поступившая диспетчеру заявка заключается в неплановом сервисном обслуживании или установке нового ПО, то это также выполняется в рамках данного бизнес-процесса.
· Устранение неисправностей. В рамках данного бизнес-процесса происходит устранение возникающих нарушений в работоспособности оборудования и программного обеспечения на местах использования. Активация данного бизнес-процесса может произойти по инициативе диспетчера, руководствующегося заявкой, либо при выявлении неисправности в процессе сервисного обслуживания.
· Поддержание и модернизация запасов КТС и ПО. В отделе технической поддержки всегда имеется набор резервного оборудования для быстрого восстановления работоспособности в случае неисправностей. Также имеется репозиторий программного обеспечения, устанавливаемого в соответствии с планом или по требованию. Актуализация данных запасов по технологиям и дополнение по объему выполняется в рамках данного бизнес-процесса.
· Документационное обеспечение. Бизнес-процесс содержит в себе функции по поддержке работы и управления отделом. В его рамках создаются всевозможные отчеты, рассчитывается заработная плата технических специалистов исходя из объемов выполненных работ, формируются планы закупки оборудования и т.д.
· Переходя на второй уровень декомпозиции можно определить важные бизнес-процессы, которые требуется модифицировать. Таковым является Мониторинг состояния КТС и ПО. Именно в рамках этого процесса выполняются наиболее рутинные операции, и он также является первопричиной нерационального расхода рабочего времени технических специалистов.
Проведена первая декомпозиция бизнес-процесса «Мониторинг состояния КТС и ПО» (Рисунок 3).
По результатам декомпозиции выявлены следующие бизнес-процессы:
1) проводить плановые проверки. Технический специалист в соответствии с должностной инструкцией в установленные сроки производит диагностику оборудования и программного обеспечения. В случае возникновения неисправности, соответствующая информация подается диспетчеру;
2) регистрировать факт возникновения неисправности. Диспетчер со слов подающего сведения фиксирует в журнале факт возникновения неисправности и его описания. Устанавливается степень сложности заявки, ее класс (по специализации сотрудников) и сроки устранения. Вместе с этими параметрами заявка передается на следующий бизнес-процесс;
3) передать заявку на исполнение. Заявка, дополненная параметрами, оценивается диспетчером. Осуществляется поиск свободных технических специалистов, которые назначаются исполнителями. Заявка передается на исполнение. При этом выделяется два вида исполнения - установка (недостающих компонентов или их обновление) и устранение (неполадок);
4) передать заявку на контроль. Заявка, дополненная параметрами, а также данные об ответственном за ее исполнение лице подается сотруднику, ответственному за контроль качества работы отдела - его начальнику.
На данном уровне декомпозиции, структура бизнес-процесса не обладает явными узкими местами, можно отметить, что только отсутствие средств вычислительной техники как механизмов его осуществления.
Рисунок 3 - Диаграмма декомпозиции бизнес-процесса «Мониторинг состояния КТС и ПО»
В проектной работе также приведены бизнес-процессы «Регистрировать факт возникновения неисправности» (Рисунок 4) и «Передать заявку на исполнение» (Рисунок 5). Раскрытие этих процессов отображены в нотации IDEF3 для того, чтобы увидеть недостатки протекающих процессов и их узкие места.
Рисунок 4 - IDEF3-диаграмма декомпозиции бизнес-процесса «Регистрировать факт возникновения неисправности»
По результатам декомпозиции «Регистрировать факт возникновения неисправности» выявлены следующие элементарные операции:
1) выяснить причину обращения. Диспетчер из поступившего обращения выделяет необходимую информацию, которая составит содержание заявки;
2) сформировать заявку. Диспетчер формулирует заявку на основании поступившего обращения. Происходит оценка сложности заявки и ее классификация;
3) запись в журнале обращений. Диспетчер делает запись в журнал обращений, которая служит основанием для учета операций, совершенных отделом технической поддержки;
4) подсказать решение. Если неисправность, по мнению диспетчера, является элементарной и его опыт позволяет лично подсказать ее решение, то обратившемуся сразу выдается ответ по его проблеме;
5) оформить заявку. Если диспетчер не может сразу дать ответ на обращение, то в зависимости от характера обращения на бланке установленного образца формируется лист заявки на устранение или на установку.
В данном процессе много узких мест. Так, здесь используются устаревшие технологии, и нет автоматизации. Вместо базы знаний или частых вопросов используется личный опыт диспетчера, что в некоторых ситуациях недопустимо. Интерпретацию проблемы вынужден делать диспетчер, может возникнуть неправильная трактовка неисправности при объяснении техническому специалисту.
Следующим декомпозируем бизнес-процесс «Передать заявку на исполнение» (Рисунок 5).
Рисунок 5 - Диаграмма декомпозиции бизнес-процесса «Передать заявку на исполнение»
По результатам декомпозиции выявлены следующие бизнес-процессы:
1) оценить загруженность специалистов. Диспетчер имеет на руках так называемые индивидуальные листки заданий, в которых содержатся записи о выданных специалисту заявках и отметки об их выполнении. Исходя из записей в этих листках, выбираются наиболее свободные сотрудники;
2) выбрать подходящего специалиста. Диспетчер, руководствуясь профессиональным уровнем свободных специалистов и уровнем сложности поступившей заявки, выбирает подходящего специалиста;
3) присвоить заявку. Диспетчер назначает сотрудника, ответственного за устранение возникшей неисправности, записывая в его индивидуальный листок заданий соответствующую информацию. Каждый сотрудник должен как минимум два раза за рабочий день ознакомиться с листком заданий.
Проанализировав все диаграммы бизнес-процессов, можно сделать вывод, что полученные в ходе построения моделей существующих бизнес-процессов являются основанием и исходными данными для оптимизации бизнес-процессов - реинжиниринга.
Реинжиниринг представляет собой переосмысление и радикальную перестройку бизнес-процессов с целью улучшения таких важных показателей, как стоимость, качество, скорость функционирования, финансы и маркетинг для достижения скачкообразного улучшения деятельности фирмы. Модификации решено было подвергнуть бизнес-процессы «Регистрировать факт возникновения неисправности» и «Передать заявку на исполнение».
По результатам реинжиниринга процесс «Регистрировать факт возникновения неисправности» (Рисунок 6) имеем следующие элементарные процессы:
1) авторизоваться в системе. Сотрудник, столкнувшийся с неисправностью, заходит в информационную систему, к которой имеет соответствующие права доступа. После авторизации сотрудник получает возможность сообщить параметры неисправности или сразу решить ее;
2) поиск решения. Авторизованный пользователь получает доступ к базе знаний отдела технической поддержки, в которой содержится информация о наиболее часто встречающихся неисправностях и способах их самостоятельного устранения. Если решение найдено, то сотрудник при желании может лично им воспользоваться;
3) оформить заявку. Если решения в базе знаний нет, или пользователь не воспользовался базой знаний, то составляется заявка. В определенный фиксированный набор полей вносятся параметры проблемы, снимки экрана, описание причин возникновения и т.д. Пользователь может классифицировать свою заявку как требование установки недостающего оборудования или ПО или же непосредственно как требование устранения неисправности;
4) уведомить диспетчера. Система автоматически помещает сформированную заявку в рабочее пространство диспетчера, однако при желании пользователь может дополнительно послать уведомление, обозначив тем самым срочность или важность решения неисправности.
Рисунок 6 - IDEF3-диаграмма реинжиниринга бизнес-процесса «Регистрировать факт возникновения неисправности»
Кардинально изменился бизнес-процесс, за счет того, что назначены центральными действующими лицами информационную систему и сотрудника, столкнувшегося с неисправностью. Это позволит специалисту сосредоточиться на контроле исполнения заявок, их классификации и учету, а также снизит нагрузку по обработке первичной информации от пользователей. Теперь описание заявок будет вносить сам пользователь, и возможность неправильной трактовки проблемы специалистом существенно снижается. Вводится такое понятие, как база знаний - инструмент, способный заменить «подсказки» диспетчера. База знаний контролируется специалистами и содержит только многократно проверенную информацию, не способную нанести вред. Процесс регистрации заявки будет происходить по новой, реинжиниринговой модели, так как диспетчер заменит пользователя в роли, подающего заявку.
Рисунок 7 - Диаграмма реинжиниринга бизнес-процесса
«Передать заявку на исполнение»
По результатам реинжиниринга процесса «Передать заявку на исполнение» получены следующие бизнес-процессы.
1. Инициализация заявки в системе. Диспетчер выбирает заявку, которую следует передать на исполнение, происходит ее инициализация в системе назначений.
2. Выбрать подходящего специалиста. Система, основываясь на параметрах заявки, индивидуальных листах заданий и профессиональных показателях сотрудников автоматических предлагает наиболее подходящую кандидатуру.
3. Присвоить заявку. Диспетчер выбирает специалиста из числа предложенных системой и назначает его ответственным за устранение возникшей неисправности. Система записывает в его индивидуальный листок заданий соответствующую информацию.
4. Отправить уведомление. Через встроенную систему оповещений (мессенджер) информационная система уведомляет специалиста о поступлении нового задания и предлагает ознакомиться с его содержанием.
Таким образом, внеся все необходимые данные в диаграммы реинжиниринга бизнес-процессов, специалист, который будет разрабатывать автоматизированную систему по данному техническому заданию, будет иметь понимание по всем требованиям к данной системе.
По итогам моделирования, а также с учетом критериев, выявленных на этапе анализа систем-аналогов, были окончательно определены требования к информационной системе, которая будет спроектирована для отдела технической поддержки.
1. Управление заявками. Учет заявок, отслеживание и совместная работа. Отражение работ в личном кабинете.
2. Управление задачами. Оперативное управление работой сотрудников, отслеживание, коллективное взаимодействие. Поддержка подзадач, регулярных задач и тегов.
3. Учет времени. Листы учета времени на основании списываемых часов в задачах и заявках.
4. Аналитические отчеты. Динамика деятельности, удовлетворенность клиентов, качество работы службы поддержки и др. в разрезе времени.
5. Мобильный доступ. При нахождении вне офиса работа сотрудников над заявками должна быть доступна в полной мере с поддержкой уведомлений о новых событиях.
Разобрав, все доступные состояния заявки, необходимо детально рассмотреть наиболее существенные варианты использования информационной системы.
Рисунок 7 - Создание заявки в системе
Выше изображено, что весь процесс заполнения заявки выполняется с помощью системы по строго определенным ею правилам, что устраняет двусмысленность трактовки неисправности и позволяет инициатору наиболее полно описать проблему, даже если он не знает с чего начать (Рисунок 7).