Размещено на http://www.allbest.ru/

Введение

связь информационный управление

Автоматизация отделов, служб и секторов, занимающихся технической поддержкой и сопровождением процесса использования оборудования - задача на сегодняшний день известная и распространенная. Можно говорить об огромном количестве удачно внедренных проектов в различных отраслях, в различных по масштабу компаниях, с применением различных средств автоматизации. Когда мы говорим об автоматизации технической поддержки, мы всегда подразумеваем внедрение автоматизированного средства из группы программного обеспечения Help Desk. Фактически понятие HelpDesk стало аналогом понятия сектор сопровождения, что говорит о том, что в настоящее время большинство ИТ-служб в той или иной степени пересмотрели свой подход к структуре и процессам управления ИТ. Это во многом связано с распространением процессного подхода для управления ИТ и применением передовых методологий eTOM, ITSM\ITIL, COBIT. Если проанализировать структуру большинства крупных и средних ИТ подразделений, то независимо от того используют они эти методологии или нет, выстроена модель управления процессами ИТ или нет - мы обязательно найдем аналог понятию Help Desk, которое определено в библиотеке передового опыта в области информационных технологий ITIL.

В связи с тем, что в МБУЗ ГБ г. Армавира имеется множество территориально отдаленных пунктов, качество и скорость работы отдела АСУ встает на первый план в группе задач обеспечения эффективной работы предприятия.

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

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

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

1. Объект исследования и проектирования

В разделе приведены характеристики исследуемой мною отдела АСУ, показана организационная структура предприятия, в которую входит отдел, приведены сценарии работы. В конце раздела приведены требования к проектируемой информационной системе и выполнена полная постановка задачи выпускной квалификационной работы.

1.1 Краткая характеристика области исследования

МБУЗ ГБ г. Армавира - одно из старейших лечебных учреждений города. Сегодня это многопрофильная клиническая больница, обеспечивающая все виды амбулаторно-поликлинической и стационарно-терапевтической помощи. На базе больницы размещены: городское психосамотическое отделение для инвалидов и ветеранов войны, центр апитерапии, центр прогрессивных медицинских технологий, открыты районные аллергологический и пульманологический кабинеты. В больнице работает 1800 сотрудников из которых половина имеют высшую и первую квалификационные категории (рис.1). В МБУЗ ГБ г. Армавира развернуто около 1000 коек. В составе больницы имеется поликлиника на 1500 посещений в смену, консультативно-диагностическая поликлиника.

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

В 2007 году МБУЗ ГБ г. Армавира подтвердила 1 категорию лечебно-профилактического учреждения по уровню организации оказания медицинской помощи населению.

В своей деятельностью больница руководствуется Конституцией Российской Федерации, Федеральными законами, нормативными документами Министерства здравоохранения и социального развития Российской Федерации, Министерства здравоохранения Краснодарского края.

Виды медицинской помощи, предоставляемой бесплатно в МБУЗ ГБ г. Армавира: первичная медико-санитарная, в том числе неотложная, медицинская помощь; скорая, в том числе специализированная (санитарно-авиационная), медицинская помощь; специализированная, в том числе высокотехнологичная, медицинская помощь.

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

Специализированная, в том числе высокотехнологичная, медицинская помощь предоставляется гражданам в медицинских организациях при заболеваниях, требующих специальных методов диагностики, лечения и использования сложных, уникальных или ресурсоемких медицинских технологий. Медицинская помощь гражданам предоставляется: учреждениями и структурными подразделениями скорой медицинской помощи (скорая медицинская помощь); амбулаторно-поликлиническими учреждениями и другими медицинскими организациями или их соответствующими структурными подразделениями и дневными стационарами всех типов (амбулаторная медицинская помощь); больничными учреждениями и другими медицинскими организациями или их соответствующими структурными подразделениями (стационарная медицинская помощь). Амбулаторная медицинская помощь предоставляется гражданам при заболеваниях, травмах, отравлениях и других патологических состояниях, не требующих круглосуточного медицинского наблюдения, изоляции и использования интенсивных методов лечения, а также при беременности и искусственном прерывании беременности на ранних сроках (абортах). Стационарная медицинская помощь предоставляется гражданам в больничных учреждениях и других медицинских организациях или их соответствующих структурных подразделениях в следующих случаях, требующих круглосуточного медицинского наблюдения, применения интенсивных методов лечения и (или) изоляции, в том числе по эпидемическим показаниям: заболевание, в том числе острое; обострение хронической болезни; отравление; травма; патология беременности, роды, аборт; период новорожденности. Мероприятия по восстановительному лечению и реабилитации больных осуществляются в амбулаторных и больничных учреждениях, иных медицинских организациях или их соответствующих структурных подразделениях, включая центры восстановительной медицины и реабилитации, в том числе детские, а также санатории, в том числе детские и для детей с родителями. При оказании медицинской помощи осуществляется обеспечение граждан в соответствии с законодательством Российской Федерации необходимыми лекарственными средствами, изделиями медицинского назначения, а также обеспечение детей-инвалидов специализированными продуктами питания. Для получения медицинской помощи граждане имеют право на выбор врача, в том числе врача общей практики (семейного врача) и лечащего врача, с учетом согласия этого врача, а также на выбор медицинской организации в соответствии с договорами обязательного медицинского страхования.

1.2 Структура отдела автоматизированных систем управления

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

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

Отдел АСУ- формальная, централизованная структура с плоской системой управления. Он состоит из руководства и секторов (рисунок 1).



Рисунок 1 - Структура отдела АСУ

В отделе автоматизированных систем управления есть следующие должности:

1. Администратор сети - 3 ставки;

2. Инженер - 4 ставки;

3. Техник - 2 ставки;

4. Документовед - 1 ставка;

5. Диспетчер - 1 ставка.

Таким образом, отдел насчитывает 11 человек.

1.3 Сценарий бизнес-процессов организации работ по обслуживанию оборудования и компьютерной техники

В целом работу отдела АСУ можно охарактеризовать следующими состояниями:

1. Мониторинг;

2. Поступление информации о неисправности;

3. Обработка информации, передача на исполнение техническим специалистам (администратору, инженерам или техникам);

4. Устранение неисправности;

5. Документирование процесса работы.

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

Рассмотрим укрупненный сценарий бизнес-процессов, связанный с обработкой поступающих заявок (см. рисунок 2).

По сценарию в случае возникновения неполадок инициатор подает заявку, заявка получает статус «открыта». С этого момента до момента получения данной информации диспетчером может пройти от нескольких секунд (в случае обращения по телефону) до нескольких часов или даже рабочих дней (в случае использования почтовых сервисов). Такой разброс обусловлен неоднозначностью средств размещения заявки в группе клиентских подключений отдела управления сетями связи. Удаленные отделы, размещая информацию о не критичной по части работоспособности неисправности пользуются в основном электронной почтой, к которой диспетчер в зависимости от загруженности может обращаться всего один раз в день (приоритетными являются телефонные звонки). Поэтому на данном этапе возникает первая проблема, связанная с длительностью ожидания реакции на заявку.

Рисунок 2 - Сценарий бизнес-процессов отдела АСУ

В данном сценарии участвуют четыре действующих лица:

1. Инициатор, которым является сотрудник или подразделение;

2. Диспетчер;

3. Исполнитель - сотрудник из числа технических специалистов;

4. Документовед.

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

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

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

1.4 Математическая модель оценки процесса организации работ по обслуживанию оборудования и компьютерной техники

Для решения задачи моделирования бизнес-процесса регистрации заявок больше всего подходит дискретно-событийное моделирование.

Чтобы отмоделировать деятельность технического специалиста с помощью дискретно-событийных моделей, определим время T, которое он тратит на устранение одной неисправности. Оно складывается из времени реагирования t_реаг-я на возникновение неисправности и времени устранения неисправности t_устр-я. Первое состоит из времени пути в офис t_пути1 для получения задания, времени получения задания t_зад. и времени пути в отдел для устранения задания t_пути2. Описанное выше представим формулой (1):

(1)

Время пути в офис составляет от 5 минут (если сотрудник находится в отделе) до 0,5 часа (если сотрудник находится на самой удаленной точке). Таким образом, t_пути1= (5+30)/2=17,5 мин.

Время получения задания составляет от 5 до 10 минут в зависимости от объема переданных инициатором заявки сведений. Таким образом, t_зад.= (5+10)/2=7,5 мин.

Время пути в отдел составляет от 10 минут (если неисправность возникла в административном здании) до 0,5 часа (если неисправность возникла на удаленном объекте). Таким образом, t_пути2= (10+30)/2=20 мин.

На устранения неисправности сотруднику в среднем требуется 1 час (данные получены в результате наблюдения). Таким образом, t_устр-я= 60 мин.

Исходя из этого общее время на устранение одной неисправности техническим специалистом составляет 1 час 45 минут.

T= 17,5+7,5+20+60=105 мин.

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

В группе клиентских подключений отдела управления сетями связи МБУЗ ГБ г. Армавира работает 4 инженера, поток заявок никак не ограничен по времени и количеству. Поэтому воспользуемся четырехканальной моделью с неограниченной длиной очереди.

Рассмотрим модель текущего состояния процессов. По данным наблюдений, проводимых в течение месяца, средняя частота поступления обращений л=0,033 заявок/мин, время обслуживания одного обращения одним специалистом - 120 минут, а интенсивность обслуживания обращений - м=0,0095 заявок/час. Инженера трудится 4, так что число каналов m=4.

Найдем нагрузку на сектор сопровождения: с=л/(mм) = 0,87.

Найдем вероятность простоя сотрудников по формуле P₀ = 1-с: P₀=0,13.

Найдем среднюю длину очереди из необработанных обращений по формуле:

.

Получим: q=2,9 заявки.

Сектор сопровождения принимает на обслуживание все поступающие заявки (отказов в обслуживании нет). Поэтому P_отк=0, P_обсл=1.

Найдем остальные характеристики математической модели по формулам из справочной литературы: Коэффициент загрузки

,U=0,87;

Среднее число обращений, обслуживаемых сектором сопровождения в текущий момент времени

, S=3,48 заявок;

Среднее число обращений, включая ожидающие обслуживания

, k=6,4 заявки;

Количество обращений, которые сектор способен обслужить в единицу времени

,г=0,033 заявки/мин;

Среднее время пребывания обращения в ожидании обслуживания

, w=88 мин.;

Среднее время от момента подачи обращения до его выполнения

,t=193 мин.

Проанализируем полученные характеристики дисктретно-событийной модели. Технические специалисты загружены на 87%, т.е. заняты обслуживанием сотрудников, обратившихся с неисправностями в течение 87% всего времени своей работы, это на 2% выше рекомендуемой нормы нагрузки [3]. В течение 13% времени технические специалисты простаивает из-за отсутствия заявок. Таким образом, загрузка технических специалистов достаточно высока. Дальнейшее увеличение загрузки крайне нежелательно.

Следует провести оптимизацию временных показателей работы технических специалистов, чтобы улучшить работу рассмотренной модели.

1.5 Проблемы в деятельности отдела АСУ МБУЗ ГБ г. Армавира

В ходе выполнения работы и моделирования сценариев были выявлены следующие проблемы:

· Необходимость вернуться в офис для получение задания на устранение другой поломки.

· Потеря времени ремонтной бригадой, что существенно отражается на работе.

· Увеличение затрат.

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

1.6 Постановка цели и задачи дипломной работы

Цель моей дипломной работы - провести оптимизацию деятельности отдела АСУ МБУЗ ГБ г. Армавира с целью повышения качества его работы и оптимизации расхода рабочего времени сотрудников, в особенности технических специалистов.

Задача моей дипломной работы - спроектировать и описать и информационную систему выставления заявок на обслуживание оборудования и компьютерной техники МБУЗ ГБ г. Армавира. Проект, который будет создан мною, должен отвечать проведенному реинжинирингу бизнес-процессов.

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

2.1 Оптимизация математической модели оценки процесса организации работ по обслуживанию оборудования и компьютерной техники

Оптимизация математической модели процесса сводится к сокращению временных показателей модели путем внесения изменений в бизнес-процессы.

Определим временные показатели из формулы (1), на которые можно повлиять (см. таблицу 1).

Таблица 1 - Показатели оптимизируемой дискретно-событийной модели

Показатель	Обозначение	Возможности влияния
время устранения неисправности	tустр-я.	Не может быть сокращено или увеличено, так как является случайным и зависит от характера поломки.
время пути в офис для получения задания	tпути1	Может быть полностью исключено из модели путем создания средств моментальной доставки задания
время получения задания	tзад.	Может быть полностью исключено из модели путем создания средств моментальной доставки задания
время пути в отдел для устранения неисправности	tпути2	Не может быть сокращено, так как техническому специалисту в любом случае требуется время на прибытие в отдел для устранения неисправности.

Введем функцию выставления заявки напрямую техническим специалистам, минуя диспетчера. Тогда время, требующееся сотруднику для устранения неисправности составит:

T= 0+0+20+60=80 мин.

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

В обновленной модели время обслуживания одной заявки одним каналом - 80 минут, а интенсивность обслуживания заявки в одном канале - м=0,0125 заявок/час. Инженера трудится 4, так что число каналов m=4.

Найдем нагрузку на сектор сопровождения: с=л/(mм) = 0,66.

Найдем вероятность простоя по формуле P₀ = 1-с: P₀=0,44.

Найдем среднюю длину очереди по формуле:

.

Получим: q=0,49 заявки.

Найдем остальные характеристики модели по формулам из справочной литературы: Коэффициент загрузки

,U=0,66;

Среднее число обрабатываемых обращений

, S=2,64 заявок;

Среднее число обращений включая ожидающие обработки

, k=3,13 заявки;

Количество заявок, которые сектор способен провести через себя в единицу времени

,г=0,033 заявки/мин;

Среднее время пребывания обращения в очереди

, w=15 мин.;

Среднее время пребывания обращения с момента подачи до момента обработки

,t=95 мин.

Проанализируем полученные характеристики.

Технические специалисты загружены на 66%, т.е. заняты обслуживанием сотрудников, обратившихся с неисправностями в течение 66% всего времени своей работы, это на 9% ниже минимальной рекомендуемой нормы нагрузки [6]. В течение 44% времени технические специалисты простаивает из-за отсутствия заявок. Таким образом, загрузка технических специалистов при использовании мобильной информационной системы существенно уменьшится.

Время ожидания в очереди на обслуживание сократится для отделов почти в 6 раз (с 88 до 15 минут), время нахождения заявки в сократится в 2 раза. Полученные показатели являются приемлемыми, так как достигнуто снижение временных затрат и разгружены сотрудники отдела АСУ.

2.2 Определение способа реализации оптимизированной математической модели

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

Рисунок 5 - Алгоритм доставки сведений о неисправности

Алгоритм состоит в получении сведений о возникновении неисправности, установки связи с техническим специалистом, передачи ему сведений о заявке и фиксации сведений и принятии их к исполнению.

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

Из рисунка 5 составим таблицу 3, в которой покажем различия во времени при выполнении данного алгоритма различными способами.

Таблица 3 - Сравнение временных затрат

Способ выполнения/ операция	Передача сведений по телефону	Передача через информационную систему
Получение заявки	0 минут	0 минут
Установка связи	1 минута	1-2 сек.
Передача сведений	2 минуты	1 сек.
Фиксация сведений и принятие к исполнению	2 минуты	1 мс.

Из таблицы видно, что при работе человека процесс доставки займет 5 минут, то есть невозможно удовлетворить условиям математической модели. В то же время на доставку сведений информационной системе потребуется порядка 3 секунд, что вполне приемлемо и никак не повлияет на показатели СМО.

Очевидно, что следует использовать информационные технологии и разработать подсистему мобильного доступа к функциям информационной системы отдела АСУ. Это позволит добиться желаемых временных затрат.

2.3 CASE-средства моделирования, используемые в работе

Существует множество средств моделирования автоматизированных систем. За последние десятилетия сформировалось новое направление в программотехнике - CASE (Computer-Aided Software/System Engineering) на основе методологии структурного системного анализа и проектирования. CASE-технология представляет собой совокупность методологий анализа, проектирования, разработки программного обеспечения (ПО) и сопровождения информационных систем, поддержанную комплексом, взаимосвязанных средств автоматизации [3]. CASE - это инструментарий для системных аналитиков, разработчиков и программистов, позволяющий автоматизировать процесс проектирования и разработки ПО.

Итак, основным критерием при выборе CASE-средств является поддержка методологий SADT, так как с помощью данного семейства моделей (IDEF1, IDEF3, DFD) может быть создано полное и непротиворечивое описание бизнес-процессов. Помимо этого необходимо учитывать доступность и простоту работы с данными средствами.

Остановимся подробно на выборе CASE-средства, для построения моделей бизнес-процессов отдела АСУ МБУЗ ГБ г. Армавира. На российском рынке представлен большой набор программных продуктов для моделирования, мною было решено выбрать три наиболее популярных инструмента, о которых имеется подробная документация на русском языке. После поиска по специализированным форумам и сайтам, посвященным моделированию бизнес-процессов, был определен следующий набор средств:

1. Microsoft Visio 2007.

2. AllFusion Modeling Suite;

3. Aris Toolset.

1. Microsoft Visio 2007. Это наиболее простое и доступное средство моделирования. Данный продукт имеет стандартные, привычные всем панели управлении в стиле MS Office и легко интегрируется с любыми приложениями этого пакета, что упрощает работу с ним для неопытных пользователей.

CASE-средство Microsoft Visio 2007 поставляется в комплекте с базовым пакетом Microsoft Office и не требует дополнительных затрат на приобретение. Помимо этого данный продукт поддерживает все виды диаграмм языка UML.

2. AllFusion Modeling Suite - пакет инструментальных средств разработанный компанией Computer Associates International, Inc. (CA), пакет поддерживает все этапы разработки информационных систем, в этот пакет входит пять продуктов:

· AllFusion Process Modeler - «BPwin» (позволяет облегчить проведение обследования предприятия и построить функциональные модели).

· AllFusion ERwin Data Modeler - «ERwin» (позволяет создавать модели данных и генерировать схему баз данных).

· AllFusion Data Model Variator - «ERwin Examiner» (позволяет производить поис и исправление ошибок модели данных).

· AllFusion Model Manager - «ModelMart» (система организации коллективной работы и хранилище моделей BPwin и ERwin).

· AllFusion Component Modeler - «Paradigm Plus» (инструмент создания обьектных моделей).

3. ARIS: компании IDS Scheer AG. Система ARIS представляет собой комплекс средств анализа и моделирования деятельности предприятия. Ее методическую основу составляет совокупность различных методов моделирования, отражающих разные взгляды на исследуемую систему. Одна и та же модель может разрабатываться с использованием нескольких методов, что позволяет использовать ARIS специалистам с различными теоретическими знаниями и настраивать его на работу с системами, имеющими свою специфику. ARIS поддерживает четыре типа моделей, отражающих различные аспекты исследуемой системы:

· Организационные модели, представляющие структуру системы - иерархию организационных подразделений, должностей и конкретных лиц, связи между ними, а также территориальную привязку структурных подразделений.

· Функциональные модели, содержащие иерархию целей, стоящих перед аппаратом управления, с совокупностью деревьев функций, необходимых для достижения поставленных целей.

· Информационные модели, отражающие структуру информации, необходимой для реализации всей совокупности функций системы.

· Модели управления, представляющие комплексный взгляд на реализацию бизнес-процессов в рамках системы.

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

Выделим критерии наиболее важные конкретно для моей работы:

1. Поддержка стандартов выбранной методологии;

2. Удобство использования (наличие автосохранения, возможностей отмены и повтора действий);

3. Простота освоения;

4. Экспорт моделей в графические форматы;

5. Возможность декомпозиции объекта;

6. Стоимость.

На основании шести выбранных критериев проведем оценку эффективности CASE-средств методом экспертных оценок. Предлагается следующая шкала оценок.

Таблица 4 - Шкала оценок.

Параметр	Баллы	Оценка
	4	Отлично
	3	Хорошо
	2	Удовлетворительно
	1	Предельно допустимо
	0	Неприемлемо

Таблица 5 - Экспертная оценка.

Параметр, оценка	Весовой к-т	VISIO 2007	All Fusion	ARIS
Поддержка стандартов	0,15	3	0,45	4	0,6	3	0,45
Удобство использования	0,15	1	0,15	3	0,45	3	0,45
Простота освоения	0,10	5	0,5	4	0,4	3	0,3
Экспорт моделей	0,25	4	1	5	1,25	4	1
Возможность декомпозиции	0,25	1	0,25	4	1	3	0,75
Стоимость	0,10	5	0,5	3	0,3	2	0,2
Общая оценка, Q		Qа = 2,85	Qр = 4	Qр = 3,15

Вывод: Проведенный сравнительный анализ методом экспертных оценок показал, что наиболее подходящим программным средством для моделирования бизнес-процессов является AllFusion Modeling Suite фирмы Computer Associates.

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

Чтобы выполнить переход на новые модели работы отдела АСУ, необходимо построить структуру происходящих внутри бизнес-процессов с учетом предложений по оптимизации. Для этих целей строится модель «как должно быть». Применим структурный подход и нотацию 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. Отправить уведомление. Через встроенную систему оповещений (мессенджер) информационная система уведомляет сотрудника о поступлении нового задания и предлагает ознакомиться с его содержанием.

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

2.5 Требования к проектируемой информационной системе отдела АСУ

По итогам моделирования можно окончательно определить требования к информационной системе, которая будет спроектирована для отдела АСУ.

Требования к структуре системы. Информационная система должна иметь в своем составе следующие модули:

· Управление заявками.Учет заявок, отслеживание и совместная работа. Отражение работ в личном кабинете.

· Управление задачами. Оперативное управление работой сотрудников, отслеживание, коллективное взаимодействие. Поддержка подзадач, регулярных задач и тегов.

· Учет времени. Листы учета времени на основании списываемых часов в задачах и заявках.

· Аналитические отчеты. Динамика деятельности, удовлетворенность клиентов, качество работы службы поддержки и др. в разрезе времени.

· Мобильный доступ. При нахождении вне офиса работа сотрудников над заявками должна быть доступна в полной мере с поддержкой уведомлений о новых событиях.

Требование к функциям, выполняемым системой. Информационная система отдела АСУ должна выполнять следующие функции:

· Регистрация заявок на выполнение работ;

· Классификация и диспетчеризация приходящих заявок, в том числе для назначения исполнителей, категорий и приоритетов;

· Отслеживание текущего статуса заявки;

· Протоколирование работ, выполняемых по заявке, а также всех вносимых в нее изменений;

· Регистрация трудозатрат исполнителей;

· Построение отчетов по выбранным параметрам.

3. Проектирование информационной системы выставления заявок на обслуживание оборудования и компьютерной техники отдела АСУ МБУЗ ГБ г. Армавира

3.1 Обзор и анализ информационных систем для автоматизации деятельности секторов и служб сопровождения

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

1. Aquaria SD;

2. Sevrice DesKit;

3. ISDesk.

Рассмотрим каждую систему подробно.

Aquaria SD

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

Aquaria SD представляет собой готовый программный продукт, в котором заложены практики IT Infrastructure Library (ITIL), включая шаблоны процессов и каталога услуг, структуру базы конфигураций (CMDB) и метрики для измерения эффективности. Это позволяет в короткий срок приступить к эксплуатации системы, сохранив при этом возможность ее дальнейшего развития и адаптации под ваши потребности благодаря гибким инструментам настройки, имеющимся у Aquaria SD.

Aquaria SD позволяет автоматизировать процессы управления инцидентами, проблемами, уровнем сервиса, конфигурациями, изменениями, релизами, доступностью и финансами.

Програмный продукт Aquaria SD предлагает широкие возможности для управления ИТ-обслуживанием:

Ведение единой клиентской базы:

· Настраиваемые карточки клиентов/контактных лиц;

· Хранение всей истории взаимоотношений с клиентом;

· Анализ клиентской базы по всем параметрам (настраиваемый генератор отчетов)

Управление инцидентами

Учет и классификация инцидентов:

· Внесение в систему информации о всех возникающих инцидентах;

· Автоматическая регистрация и первичная классификация инцидентов;

· Наличие таких индикаторов, как приоритет, степень влияния, срочность для назначения инцидентам и учета их при классификации и определении порядка обработки инцидентов;

· Категоризация инцидентов в терминах затронутых сервисов и конфигурационных единиц;

· Привязка поступившего обращения к уже зарегистрированному инциденту;

· Хранение истории событий по каждому инциденту;

· Поиск инцидента в базе данных (по идентификатору, описанию и т.д);

· Использование базы данных об известных ошибках и опросных листов для диагностики инцидента и его разрешения

Организация процесса разрешения инцидентов:

· Автоматическая передача ответственности за инцидент при изменении состояния инцидента;

· Изменение технологического цикла обслуживания инцидента в зависимости от типа инцидента;

· Разграничение прав доступа к информации и операциям в системе (открытие, редактирование, закрытие инцидентов);

· Контроль ответственности за разрешение инцидента;

· Механизм передачи ответственности за инцидент между отделами и сотрудникам, в том числе возможность автоматического распределения инцидентов на конкретного сотрудника или группу сотрудников;

· Уведомление сотрудников и клиентов о событиях, связанных с инцидентами, настраиваемые правила оповещения;

· Закрытие инцидента с указанием причины его возникновения.

Учет временных характеристик инцидента:

· Учет времени начала и завершения работ;

· Учет общего времени обработки инцидента в службе поддержки;

· Контроль превышения нормативного времени, выделенного на разрешение инцидента;

· Механизм уведомления руководства о трудностях, возникших в ходе разрешения инцидента (эскалация инцидента);

· Настройка пороговых значений времени разрешения инцидента для проведения автоматической эскалации;

· Обеспечение доступа в систему для клиентов с целью контроля над ходом разрешения своих инцидентов.

Управление проблемами

Учет и классификация проблем:

· Объединение инцидентов в проблему;

· Автоматическая регистрация и первичная классификация проблемы;

· Учет связей между инцидентами, проблемами и известными ошибками;

· Автоматическое назначение ответственного за решение проблемы;

· Наличие таких индикаторов, как приоритет, степень влияния, срочность для назначения проблемам и учета их при классификации и определении порядка обработки проблемы;

· Категоризация проблем в терминах затронутых сервисов и конфигурационных единиц;

· Привязка поступившего инцидента к уже зарегистрированной проблеме;

· Хранение истории событий по каждой проблеме;

· Поиск проблемы в базе данных (по идентификатору, описанию и т.д).

Организация процесса разрешения проблем:

· Изменение технологического цикла обслуживания проблемы в зависимости от типа проблемы;

· Разграничение прав доступа к информации и операциям в системе (открытие, редактирование, закрытие проблемы);

· Контроль ответственности за разрешение проблемы, выделение менеджера процесса, делегирование полномочий;

· Уведомление сотрудников и клиентов о событиях, связанных с проблемами, настраиваемые правила оповещения;

· Закрытие проблемы с указанием причины ее разрешения.

Учет временных характеристик проблемы:

· Учет времени начала и завершения работ;

· Учет общего времени обработки проблемы;

· Механизм уведомления руководства о трудностях, возникших в ходе разрешения проблемы (эскалация проблемы при делегировании полномочий менеджером процесса).

Управление сервисами и соглашениями

Управление сервисами:

· Ведение иерархического справочника сервисов (услуг) компании (каталог сервисов);

· Возможность учета бизнес-сервисов, операционных и внешних сервисов;

· Разделение сервисов (типизация) по функциональным особенностям;

· Гибко настраиваемые карточки сервисов - возможность задать разный набор полей для разных типов сервисов;

· Возможность настройки для каждого типа сервиса своего жизненного цикла;

· Возможность задать индивидуальный вид формы для каждого типа сервисов;

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

· Связь сервисов с конфигурационными единицами (поддерживающие и зависимые КЕ);

· Полноценное построение ресурсно-сервисной модели;

· Возможность назначить ответственного за сервис (куратор сервиса), что позволяет автоматически маршрутизировать запросы, связанные с данным сервисом;

· Контроль за соблюдением требуемого качества предоставления сервиса;

· Поддержка цикла Деминга в процессе повышения качества сервиса.

Управление соглашениями:

· Ведение справочников бизнес-соглашений (SLA), операционных оглашений (OLA), поддерживающих соглашений (UC);

· Гибко настраиваемые карточки соглашений - возможность задать разный набор полей для разных типов соглашений;

· Определение в каждом соглашении параметров оказания и поддержки сервисов, сроков действия соглашения;

· Связь соглашений с получателями и поставщиками сервисов, конфигурационными единицами;

· Уведомления о нарушении соглашений об уровне сервиса, настраиваемая эскалация

Управление конфигурациями:

· Учет и классификация конфигурационных единиц, ведение CMDB;

· Неограниченная типизация КЕ (аппаратное обеспечение, программное обеспечение, серверное оборудования и т.д.);

· Возможность указания для каждого КЕ своего набора полей и своего жизненного цикла;

· Настройка связей между конфигурационными единицами;

· Наличие настраиваемого справочника текущих статусов конфигурационной единицы;

· Хранение полной истории изменения каждой конфигурационной единицы;

· Возможность автоматической проверки соответствия статуса конфигурационной единицы информации в CMDB при интеграции с системами мониторинга;

· Возможность привязки КЕ к пользователю, которому КЕ передана в эксплуатацию;

· Возможность указания в карточке КЕ сотрудника ИТ, который отвечает за обслуживания данной КЕ;

· Возможность индивидуальной настройки формы КЕ для каждой категории КЕ;

· Хранение всей истории событий с КЕ;

· Модуль универсального импорта для синхронизации базы данных КЕ системы с внешними системами, включая функцию аудита (проверка изменений в базе данных КЕ с результатами инвентаризации);

· Интеграция с системами MS SCCM, LANDesk, Nagios, MS SCOM и т.д.

...