Оптимизированная модель деятельности отдела АСУ МБУЗ ГБ г. Армавира

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

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

Рисунок 6 — Контекстная диаграмма.

Диаграмма дает нам следующее представление о бизнес-процессе:

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

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

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

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

Рисунок 7 — Диаграмма декомпозиции первого уровня.

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

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

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

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

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

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

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

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

Проведем первую декомпозицию бизнес-процесса «Мониторинг неисправностей» (рисунок 8).

" Мониторинг неисправностей" .

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

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

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

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

Выше было сказано, что модификации следует подвергнуть бизнес процессы «Регистрация неисправностей» и «Определение исполнителей». Проводить реинжиниринг следует с учетом использования проектируемой информационной системы. Начнем построение модели «как должно быть» с процесса регистрации неисправности (рисунок 9).

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

" Регистрация неисправностей" .

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

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

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

Перейдем к реинжинирингу второго проблемного бизнес-процесса — определение исполнителей. Как уже говорилось, структурно процесс построен правильно, и проблема заключается в технологии его реализации. Однако, внедрение информационной системы так или иначе приведет и к изменению структуры бизнес-процесса передачи на исполнение заявки. Изменения показаны на оптимизированной модели (рисунок 10).

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

" Определение исполнителей" .

По результатам реинжиниринга получены следующие бизнес-процессы:

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

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