Главная Коллекция "Revolution" Программирование, компьютеры и кибернетика Информационная система эксплуатационной поддержки для ГБУЗ ККБ №2

Информационная система эксплуатационной поддержки для ГБУЗ ККБ №2

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

Рубрика Программирование, компьютеры и кибернетика
Вид дипломная работа
Язык русский
Дата добавления 18.05.2017
Размер файла 2,3 M
рефераты на заказ со скидкой

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Страница:

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

Найдем значение среднее число заявок в системе (показатель k), при котором можно добиться значения показателя убытков на уровне 1000 рублей в час.

Решим уравнение

Таким образом, при достижении значения показателя k (среднее количество заявок в системе) в 1,57 заявки, мы сможем обеспечить убытки от нахождения заявок в системе на уровне 1000 рублей.

В качестве оптимизации предполагается нахождение таких параметров обслуживания заявок, при которых среднее число заявок в системе будет равно 1,57. Формула для расчета показателя k:

Где

Определим значение загрузки СМО (c точностью до двух знаков после запятой), при котором можно достичь требуемых 1,57 заявки в системе. Известно, что начальное значение составляет 0,72. Начнем уменьшение данного показателя (поскольку он находится в прямо пропорциональной зависимости) с шага 0,1, который будем сокращать по мере приближения к требуемому значению.

Данные по расчетам показаны в таблице 2.1

Таблица 2.1 - Поиск оптимального значения загрузки модели

Загрузка

Среднее число заявок в системе

Шаг уменьшения

0,72

4,05

0

0,62

2,99

0,1

0,52

2,29

0,1

0,42

1,76

0,1

0,41

1,71

0,01

0,40

1,66

0,01

0,39

1,61

0,01

0,38

1,57

0,01

Таким образом, при достижении показателя загрузки СМО на уровне 0,38 (38%) можно достичь требуемого значения количества заявок в системе.

Зная, что

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

Таблица 2.2 - Определение параметров обслуживания оптимизированной модели

Показатель

Обозначение в модели

Старое значение

Новое значение

Количество каналов

m

4

7,57

Интенсивность обслуживания

м

0,017

0.033

Таким образом, чтобы достичь требуемого значения загрузки, мы можем либо увеличить вдвое количество каналов (количество системных администраторов) до восьми человек, либо вдвое увеличить интенсивность обслуживания. Первый вариант неприемлем, так как 100% несет удвоение расходов на заработную плату и содержание рабочего персонала. Второй же вариант связан с оптимизацией и улучшением процедуры работы сотрудников Отдела программного обеспечения, сетевых технологий и защиты информации ГБУЗ МИАЦ и по моему мнению является подходящим.

Поскольку интенсивность обслуживания - величина, обратная среднему времени обслуживания, то из этого следует, что на одну заявку Системный администратор должен тратить 1/0,033=30,3 минуты. Задача дальнейшей оптимизации сводится к нахождению способа достижения такого показателя.

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

Необходимо найти способ достижения сокращения времени на поиск неисправности и способов устранения. Известно, что на данный момент сотрудники Отдела программного обеспечения, сетевых технологий и защиты информации ГБУЗ МИАЦ работают на основе своего опыта и имеющихся знаний, а также прибегают к помощи коллег. В то же время общепризнанным способом повышения продуктивности работы сотрудников является база знаний по часто возникающим проблемам [4]. Применение данного инструмента позволяет в корне изменить процесс выявления неисправности и способов ее устранения, и что самое главное - сократить временные затраты. Алгоритм работы с базой знаний показан на рисунке 2.1.

Рисунок 2.1 - Алгоритм работы с базой знаний

Согласно рисунку, алгоритм работы с базой знаний сводится к:

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

2. получению параметров проблемы (что не работает, как давно, при каких обстоятельствах это произошло);

3. поиску фактов по полученным параметрам (случалось ли такое ранее, при таких же или схожих обстоятельствах, на таком же или схожем оборудовании)

4. формулировке решения (выборе перечня возможных неисправностей с распределением по оборудованию, а также списка мероприятий по их устранению)

5. применении решения (использовании полученных подсказок и решений при устранении проблемы)

Вариантов реализации базы знаний может быть несколько:

- общий журнал истории неисправностей, который ведется в отделе;

- база знаний как программный продукт, устанавливаемый на специализированном ПК в Отделе программного обеспечения, сетевых технологий и защиты информации;

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

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

Используем метод анализа иерархий [5] для выбора способа реализации.

Критерии, по которым будем сравнивать варианты: Время, требуемое на выполнение алгоритма; Сложность реализации варианта; Затраты на использование варианта; Усложнение в процессе использования.

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

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

1 - равная важность

3 - умеренное превосходство одного над другим

5 - существенное превосходство одного над другим

7 - значительное превосходство одного над другим

9 - очень сильное превосходство одного над другим

2, 4, 6, 8 - соответствующие промежуточные значения

Таблица 2.4 - Сравнение критериев

Критерии

Время

на выполнение

алгоритма;

Сложность реализации;

Затраты на

использование;

Усложнение со

временем.

Оценка компонент собственного вектора

Нормализованные оценки вектора приоритета

Время на выполнение алгоритма;

1

2

4

6

2,632148026

0,512750827

Сложность реализации;

1/2

1

2

4

1,414213562

0,275493311

Затраты на использование;

1/4

1/2

1

2

0,707106781

0,137746655

Усложнение со временем.

1/6

1/4

1/2

1

0,379917843

0,074009207

Далее попарно сравним альтернативы по каждому из критериев.

Таблица 2.5 - Временные оценки по критерию «Время на выполнение алгоритма».

Способ реализации

Среднее время выполнения,

минут

Доступ к базе

Получение параметров

Поиск фактов по параметрам

Формулировка решения

Применение решения

Общее время на выполнение

Журнал

7 мин.

0 мин.

15 мин.

5 мин.

1 мин.

28 мин.

ИС на стационарном ПК

5 мин.

1 мин.

3 мин.

1 мин.

1 мин.

11 мин.

Клиент-серверная ИС

1 мин.

1 мин.

3 мин.

1 мин.

1 мин.

7 мин.

Таблица 2.6 Сравнение альтернатив по критерию «Время на выполнение алгоритма».

Критерии

Журнал

ИС на стационарном ПК;

ИС ОСАС;

Оценка компонент собственного вектора

Нормализованные оценки вектора приоритета

Журнал

1

1/4

1/7

0,33299510

0,0799767

ИС на стационарном ПК

4

1

1/3

1,09958747

0,2640922

Клиент-серверная ИС

7

3

1

2,73106708

0,6559310

Таблица 2.7 - Данные по критерию «Сложность реализации»

Журнал

Просто

ИС на стационарном ПК

Сложно

ИС на переносном устройстве

Сложно

Таблица 2.8 - Сравнение альтернатив по критерию «Сложность реализации»

Критерии

Журнал

ИС на стационарном ПК;

ИС ОСАС;

Оценка компонент собственного вектора

Нормализованные оценки вектора приоритета

Журнал

1

4

4

2,49666109

0,66357892

ИС на стационарном ПК

1/4

1

1

0,63287829

0,16821053

Клиент-серверная ИС

1/4

1

1

0,63287829

0,16821053

Таблица 2.9 - Данные по критерию «Затраты на использование»

Журнал

Средние (систематическая закупка канцтоваров, аренда за содержание архивного помещения)

ИС на стационарном ПК

Средние (единовременные затраты на закупку оборудования и разработку ПО, систематические затраты на администрирование и машинное время)

Клиент-серверная ИС

Средние (единовременные затраты на закупку оборудования и разработку ПО, систематические затраты на администрирование)

Таблица 2.10 - Сравнение альтернатив по критерию «Затраты на использование»

Критерии

Журнал

ИС на стационарном ПК;

ИС ОСАС;

Оценка компонент собственного вектора

Нормализованные оценки вектора приоритета

Журнал

1

2

1/2

1

0,2976263

ИС на стационарном ПК

1/2

1

1/3

0,55361785

0,1647712

Клиент-серверная ИС

2

3

1

1,80630012

0,5376024

Таблица 2.11 - Данные по критерию «Усложнение со временем»

Журнал

Со временем растет количество журналов, что негативно сказывается на времени доступа и времени поиска

ИС на стационарном ПК

Со временем растет объем базы данных, однако скорость поиска и время доступа меняется незначительно (в масштабах нескольких миллисекунд)

Клиент-серверная ИС

Со временем растет объем базы данных, однако скорость поиска и время доступа меняется незначительно (в масштабах нескольких миллисекунд)

Таблица 2.12 - Сравнение альтернатив по критерию «Усложнение со временем»

Критерии

Журнал

ИС на стационарном ПК;

ИС ОСАС;

Оценка компонент собственного вектора

Нормализованные оценки вектора приоритета

Журнал

1

1/4

1/4

0,400535

0,112488

ИС на стационарном ПК

4

1

1

1,580083

0,443756

Клиент-серверная ИС

4

1

1

1,580083

0,443756

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

Таблица 2.13 - Сравнение и окончательный выбор альтернатив

Альтернатива

Критерии

Глобальные
приоритеты

Время на выполнение алгоритма;

Сложность реализации;

Затраты на использование;

Усложнение со временем.

Численное значение вектора приоритета

0,51275082

0,27549331

0,13774665

0,07400920

Журнал

0,0799767

0,66357892

0,2976263

0,112488

0,27314184

ИС на стационарном ПК

0,2640922

0,16821053

0,1647712

0,443756

0,23729308

Клиент-серверная ИС

0,655931

0,16821053

0,5376024

0,443756

0,48956500

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

2.3 Выбор и обоснование средств моделирования

2.3.1 Характеристика используемых нотаций

Среди всего многообразия средств решения данных задач в методологиях структурного анализа наиболее часто и эффективно применяемыми являются следующие нотации [6]:

- IDEF0;

- DFD (Data Flow Diagrams) ;

- IDEF3.

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

Нотация IDEF0. Начало моделирования в SADT означает создание диаграмм АО и А-0, которые затем могут быть отрецензированы. Эти две диаграммы полностью рассказывают все об изучаемой системе с минимальной степенью детализации. Создавая их, аналитик предпринимает начальную попытку декомпозировать систему и затем обобщить полученную декомпозицию. Декомпозиция (диаграмма АО) освещает наиболее важные функции и объекты системы. Объединение (диаграмма А-0) трактует систему как "черный ящик", дает ей название и определяет наиболее важные входы, управления, выходы и, возможно, механизмы.

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

Под моделью в IDEF0 понимают описание системы (текстовое и графическое), которое должно дать ответ на некоторые заранее определенные вопросы.

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

Наиболее важным принципом данной методологии IDEF0 является принцип "функциональной декомпозиции" блоков. Данный принцип представляет собой модельную интерпретацию той практической ситуации, что любое действие (тем более такое сложное, как бизнес-процесс) может быть разбито (декомпозировано) на более простые операции (действия, бизнес-функции). Или, другими словами, функция может быть представлена как совокупность элементарных функций.

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

В основе данной методологии (методологии Gane/Sarson) лежит построение модели анализируемой ИС - проектируемой или реально существующей. В соответствии с методологией модель системы определяется как иерархия диаграмм потоков данных (ДПД или DFD), описывающих асинхронный процесс преобразования информации от ее ввода в систему до выдачи пользователю. Диаграммы верхних уровней иерархии (контекстные диаграммы) определяют основные процессы или подсистемы ИС с внешними входами и выходами. Они детализируются при помощи диаграмм нижнего уровня. Такая декомпозиция продолжается, создавая многоуровневую иерархию диаграмм, до тех пор, пока не будет достигнут такой уровень декомпозиции, на котором процесс становятся элементарными и детализировать их далее невозможно.

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

Нотация IDEF3. Наличие в диаграммах DFD элементов для описания источников, приемников и хранилищ данных позволяет более эффективно и наглядно описать процесс документооборота. Однако для описания логики взаимодействия информационных потоков более подходит IDEF3, называемая также workflow diagramming - методологией моделирования, использующая графическое описание информационных потоков, взаимоотношений между процессами обработки информации и объектов, являющихся частью этих процессов.

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

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

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

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

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

2.3.2 Выбор и обоснование CASE-средства

CASE-средство моделирования должно отвечать следующим требованиям:

1. Поддержка методологии структурного анализа и проектирования;

2. Возможность русификации интерфейса;

3. Поддержка процедуры декомпозиции;

4. Наличие бесплатной или ознакомительной версии.

Под указанные критерии попадают следующие CASE-средства:

? All Fusion ERWin Process modeler (бывший BPWin);

? Design/IDEF;

? График-студио Лайт.

Дадим характеристику каждому CASE-средству.

All Fusion Process Modeler (BPwin). [7] Данный программный продукт относится к малым интегрированным средствам моделирования, которые поддерживают несколько типов моделей и методов.

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

Из существующих CASE-средств, ориентированных на построение моделей по методологии IDEF0, BPwin является наиболее известным и распространенным, а удобный интерфейс пользователя облегчает работу с программой

Design/IDEF [8] - CASE-пакет Design/IDEF автоматизирует все этапы проектирования сложных систем различного назначения: формулировку требований и целей проектирования, разработку спецификаций, определение компонентов и взаимодействий между ними, документирование проекта, проверку его полноты и непротиворечивости. Наиболее успешно пакет применяется для описания и анализа деятельности предприятия; он позволяет оценить такую структуру, как единый организм, сочетающий управленческие, производственные и информационные процессы. В основе пакета лежит методология структурного проектирования и анализа сложных систем IDEF0/SADT. Design/IDEF строит иерархические модели сложных систем посредством декомпозиции ее компонентов, поддерживает коллективную разработку IDEF-модели, позволяя в любой момент объединять различные подмодели в единую модель системы, создает словарь данных для хранения всей информации о функциях и структурах данных проекта. Кроме IDEF0, пакетом поддерживаются методологии моделирования данных IDEF1, IDEF1X (основанные на диаграммах "сущность-связь"), а также методология моделирования динамики систем IDEF/CPN, основанная на "цветных" или "раскрашенных" сетях Петри..

График-студио Лайт. [9] Программный продукт График-студио Лайт является упрощенной версией модуля График-студио программного продукта Бизнес-инженер и предназначен для разработки локальных графических диаграмм (График-студио диаграмм), сохраняемых в виде локальных файлов и их дальнейшего импорта в Бизнес-инженер.

"Лайт" также может использоваться независимо от программного продукта Бизнес-инженер и распространяется бесплатно. Основными пользователями продукта являются неспециалисты по бизнес-моделированию.

В типовую конфигурацию программного продукта График-студио Лайт включены 15 График-студио диаграмм, соответствующих наиболее часто применяемым на практике методологиям и нотациям процессного описания:

? БИТЕК Диаграмма бизнес-процесса

? IDEF0

? Data flow diagram в нотации Гейна-Сарсона

? Data flow diagram в нотации Йордона-Де Марко

? IDEF3

? ORACLE diagram

? BAAN diagram

? Swimmer lanes

? Process variant matrix diagram

? ARIS Function tree

? ARIS Process selection diagram

? ARIS eEPC

? ARIS Information flow diagram

? ARIS Material flow diagram

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

Используем метод анализа иерархий для выбора CASE-cредства по указанным в начале пункта критериям:

- Поддержка SADT;

- Русскоязычный интерфейс;

- Удобная декомпозиция;

- Бесплатная версия.

Сравним критерии, используя шкалу, представленную в таблице 2.3 (см. таблицу 2.14).

Таблица 2.14 - Сравнение критериев

Критерии

Поддержка SADT

Русскоязычный интерфейс

Удобная декомпозиция

Бесплатная версия

Оценка компонент собственного вектора

Нормализованные оценки вектора приоритета

Поддержка SADT

1

6

4

3

2,91295063

0,557183179

Русскоязычный интерфейс

1/6

1

1/4

1/3

0,343294524

0,065664667

Удобная декомпозиция

1/4

3

1

1/2

0,78254229

0,149683073

Бесплатная версия

1/3

3

2

1

1,189207115

0,22746908

Далее попарно сравним альтернативы по каждому из критериев.

Таблица 2.15 - Оценки по критерию «Поддержка SADT».

BPwin

Полная (IDEF0, IDEF3, DFD)

Design/IDEF

Частичная (только IDEF0)

График-студио Лайт

Полная (IDEF0, IDEF3, DFD)

Таблица 2.16 Сравнение альтернатив по критерию «Поддержка SADT».

Критерии

BPwin

Design/IDEF

График-студио Лайт

Оценка компонент собственного вектора

Нормализованные оценки вектора приоритета

BPwin

1

4

1

1,58008262

0,4437561

Design/IDEF

1/4

1

1/4

0,40053493

0,1124876

График-студио Лайт

1

4

1

1,58008262

0,4437561

Таблица 2.17 - Данные по критерию «Русскоязычный интерфейс»

BPwin

Через сторонний русификатор

Design/IDEF

Нет

График-студио Лайт

Полностью русифицирована

Таблица 2.18 - Сравнение по критерию «Русскоязычный интерфейс»

Критерии

BPwin

Design/IDEF

График-студио Лайт

Оценка компонент собственного вектора

Нормализованные оценки вектора приоритета

BPwin

1

2

1/2

1

0,286561

Design/IDEF

1/2

1

1/4

0,503478

0,144277

График-студио Лайт

2

4

1

1,986185

0,569162

Таблица 2.19 - Данные по критерию «Удобная декомпозиция»

BPwin

Встроенный инспектор, декомпозиция в рамках проекта

Design/IDEF

В рамках одного проекта, нет инспектора объектов

График-студио Лайт

Декомпозированные объекты - это разные файлы. Нельзя создать один проект с несколькими диаграммами

Таблица 2.20 - Сравнение альтернатив по критерию «Удобная декомпозиция»

Критерии

BPwin

Design/IDEF

График-студио Лайт

Оценка компонент собственного вектора

Нормализованные оценки вектора приоритета

BPwin

1

2

8

2,49666109

0,6130815

Design/IDEF

1/2

1

4

1,25701337

0,3086729

График-студио Лайт

1/8

1/4

1

0,31864015

0,0782454

Таблица 2.21 - Данные по критерию «Бесплатная версия»

BPwin

30-дневная бесплатная версия

Design/IDEF

Бесплатная программа

График-студио Лайт

Бесплатно-распространяемое средство с ограничением по возможностям

программный математический модель отдел

Таблица 2.22 - Сравнение альтернатив по критерию «Бесплатная версия»

Критерии

BPwin

Design/IDEF

График-студио Лайт

Оценка компонент собственного вектора

Нормализованные оценки вектора приоритета

BPwin

1

1/4

1/2

0,50347777

0,1442769

Design/IDEF

4

1

2

1,98618499

0,5691624

График-студио Лайт

2

1/2

1

1

0,2865606

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

Таблица 2.23 - Сравнение и окончательный выбор альтернатив

Альтернатива

Критерии

Глобальные приоритеты

Поддержка SADT

Русскоязычный интерфейс

Удобная декомпозиция

Бесплатная версия

Численное значение вектора приоритета

0,51275082

0,27549331

0,13774665

0,07400920

BPwin

0,4437561

0,286561

0,6130815

0,1442769

0,39065682

Design/IDEF

0,1124876

0,144277

0,3086729

0,5691624

0,24782005

График-студио Лайт

0,4437561

0,569162

0,0782454

0,2865606

0,36152295

Таким образом, применив метод анализа иерархий, мы выяснили, что по совокупности критериев следует выбрать и использовать CASE-средство BP-Win, так как оно обладает максимальным значением глобального приоритета.

2.4 Функциональное моделирование бизнес-процессов

Рассмотрев математическую модель и проведя ее оптимизацию, мы получили готовые предложения по реинжинирингу, которые опишем с помощью методологии IDEF0, IDEF3 и DFD. На рисунке 2.2 показана контекстная диаграмма функциональной модели.

Рисунок 2.2 - Контекстная диаграмма функциональной модели

Рассмотрим составляющие диаграммы.

«Управление»

1. Должностная инструкция;

2. Инструкция по работе с информационной системой.

«Входные данные и объекты»

1. Сбой в работе автоматизированной системы;

2. Необходимое программное обеспечение и оборудование;

«Исходящие данные и объекты»

1. Восстановление работы АС;

«Механизмы»

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

2. Информационная система.

Черный ящик «Оптимизированный процесс восстановления работоспособности автоматизированных систем» содержит основные бизнес-процессы, которые выполняются в ходе поддержки работоспособности ИТ-инфраструктуры ГБУЗ МИАЦ. Проведем его декомпозицию (см. рисунок 2.3)

Рисунок 2.3 - Декомпозиция черного ящика

«Оптимизированный процесс поиска и устранения неисправностей»

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

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

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

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

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

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

Рисунок 2.4 - Декомпозиция черного ящика

«Поиск неисправностей и способов устранения»

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

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

Ввод данных о проблеме в ИС - в рамках данного черного ящика сотрудник ОСАС в диалоговом режиме вводит сведения о неисправности, спускаясь как-бы по иерархии от глобальных свойств неполадки к специфическим деталям. В дальнейшем рассмотрим этот процесс подробнее с помощью диаграмм DFD (см. рисунок 2.5).

Поиск решения по устранению - в рамках данного черного ящика сотрудник отдела при помощи ИС выбирает наиболее характерный вариант проблемы, для которой имеется решение. Рассмотрим этот процесс подробнее при помощи диаграммы IDEF3 (см. рисунок 2.6).

Рисунок 2.7 - Декомпозиция черного ящика

«Ввод данных о проблеме в ИС»

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

Ввод текста по шаблону - в рамках данного действия через интерфейс ИС производит заполнение параметров неисправности, по которой в дальнейшем будет вестись поиск.

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

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

Также при декомпозиции выявлены следующие объекты:

1. Сотрудник ОСАС - внешняя сущность;

2. Информационная система - внешняя сущность;

3. База данных - хранилище данных.

Рисунок 2.8 - Декомпозиция черного ящика

«Поиск решения по устранению»

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

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

Если подходящего варианта не найдено:

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

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

Если подходящий вариант найден:

Выбор наиболее подходящего решения - как правило, способов устранения может быть несколько и Сотрудник ОСАС должен на основе своего опыта выбрать оптимальное.

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

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

3. Проектирование информационной системы эксплуатационной поддержки для ГБУЗ МИАЦ

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

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

1. База знаний или аналогичная функция;

2. Поиск фактов через мобильное устройство;

3. Наполнение базы знаний через мобильное устройство;

4. Хранение сведений об имеющемся оборудовании;

5. Автономная работа с базой знаний с мобильного устройства;

6. Кроссплатформенность;

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

Для сравнения по данным критериям были отобраны следующие четыре информационные системы

- Управление отделом сопровождения

- ManageEngine ServiceDesk Plus;

- LANDesk Service Desk;

- Naumen ServiceDesk.

3.1.1 Обзор рынка информационных систем

Готовое решение для автоматизации Отдела программного обеспечения, сетевых технологий и защиты информации на базе программной платформы 1С:Предприятие 8.2.12.96. Позволяет в едином информационном пространстве вести много векторный учет в рамках Отдела программного обеспечения, сетевых технологий и защиты информации предприятия.

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

Основные возможности

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

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

- Заказы поставщикам.

- Заявки пользователей, контроль их исполнения.

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

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

- Работа с вспомогательным оборудованием (работа со сканером штрих-кодов).

- Импорт данных о составе оборудования из Everest, AIDA64.

- Поддержка схем сетей, кабинетов, зданий.

- Учет серийных и инвентарных номеров, а так же характеристик номенклатуры.

- Автоматическая загрузка организаций, подразделений и сотрудников из "1С:Зарплата и Управление Персоналом".

- Учет расходных материалов и контроль количества заправок картриджей.

- Печать этикеток оборудования и паспортов рабочих мест.

- Возможность вести учет сразу по нескольким организациям.

- Инвентаризации мест хранения.

- Загрузка изображений номенклатуры с сервиса Google Image.

- Список рабочих мест/компьютеров Active Directory с возможностю создания мест хранения.

Дополнительные механизмы

- прикрепление файлов к любому документу (это позволяет, например, в документе "Заказ поставщику" прикрепить счет), в том числе добавить можно прямо со сканера

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

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

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

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

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

ServiceDesk Plus -- это веб-приложение для обеспечения работы Отдела программного обеспечения, сетевых технологий и защиты информации и управления активами. Система состоит из нескольких объединенных в единое целое блоков: обработки заявок, отслеживания активов, закупок, управления контрактами, портала самообслуживания и базы знаний. Рассмотрим краткую характеристику данной ИС.

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

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

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

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

Распределенная функциональность. Управление запросами, основными средствами и специалистами отдельно для различных участков в организации и для обеспечения 24/7 поддержки сотрудникам.

Оперативные Отчёты. Позволяет получить сводное изображение запросов в службе помощи на одинарном режиме просмотра отчётов.

Управление активами и инвентарем IT-отдела. Позволяет контролировать IT-активы всей организации и получать точную информацию об оборудовании и программном обеспечении рабочих станций под управлением ОС Windows и Linux.

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

Отслеживание заказов. Позволяет управлять заказами IT-отдела при помощи функции отслеживания и автоматического создания активов из заказов.

Каталог продуктов. Предназначен для создания полного списка всех активов и типов продуктов, которыми располагает организация, и поддержания статистики по каждому типу.

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

LANDesk Service Desk реализован на базе технологии Microsoft .NET Framework и построен по архитектуре клиент/сервер. Серверные модули функционируют под управлением операционной системы Windows 2008 Server, Windows 2003 Server или Windows 2000 Server. В качестве СУБД поддерживаются Microsoft SQL Server или Oracle. LANDesk Service Desk поддерживает четыре типа консолей пользователя. Полнофункциональная консоль работает под управлением операционной системы Windows 2000, Windows XP или Windows Vista или Windows 7. Данная консоль предназначена для выполнения всех операций по настройке и администрированию системы и для работы сотрудников службы технической поддержки. Web-консоль функционирует под управлением Microsoft Internet Explorer, Mozilla Firefox, Netscape Navigator и Safari. Данный тип консоли предназначен как для работы сотрудников службы технической поддержки, так и для работы конечных пользователей по медленным каналам связи. Мобильная Web-консоль функционирует на карманных персональных компьютерах под управлением браузеров, поддерживающих HTML 4. Консоль WebDesk предназначена для работы сотрудников технической поддержки и реализована на базе Ruby.

Перечень функциональных возможностей:

LANDesk Service Desk представляет собой графическое приложение, позволяющее автоматизировать бизнес-процессы (от описания объектов процесса, до разработки/модернизации пользовательских интерфейсов и электронных моделей процессов, сбора аналитической информации и построения отчетности). Система включает в себя набор электронных моделей процессов и функциональных модулей позволяющий автоматизировать работу службы технической поддержки:

- управление инцидентами (Incident Management),

- управление проблемами (Problem Management),

- управление изменениями (Change Management),

- управление каталогом услуг (Service Catalog Management), управление уровнем услуг (Service Level Management),

- управление конфигурациями и активами (Service Asset & Configuration Management),

- управление знаниями (Knowledge Management),

- управление запросами на обслуживание (Request Fulfillment Management),

- управление событиями (Event management),

- управление релизами и развертыванием (Release & Deployment Management),

- управление финансами (Financial Management),

- управление доступностью (Availability Management),

- управление мощностями (Capacity Management),

- управление портфелем услуг (Service Portfolio Management) .

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

Решение предлагает следующие возможности:

1. Создание единого информационного пространства, в котором будут учитываться:

- Сервисные центры, региональные (партнерские) сервисные центры, договоры, заключенные с сервисными центрами

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

- Единая база запросов (операционных процессов):

§ по взаимоотношению с производителями;

§ гарантийный/постгарантийный ремонт оборудования;

§ замену оборудования;

§ логистика оборудования между сервисными центрами и складами;

- Формирование отчетности по работе сервисных центров (отчет о количестве выполненных ремонтов, выставленных счетах на оплату) и документов необходимых при работе с оборудованием (формирование накладных, актов и т.д.);

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

3. Сохранение в истории запроса на проведение ремонта оборудования всех событий, происходящих во время ремонта (ответственные, временные интервалы, информация по замененному оборудованию);

4. Своевременное оповещение ответственных и ключевых участников процесса облуживания техники о различных событиях, происходящих с запросами;

5. Отслеживание регламентных (договорных) сроков при обслуживании оборудования и работе с региональными сервисными центрами;

6. Накопление актуальной информации обо всей истории предоставления техподдержки и взаимодействия с региональными сервисными центрами;

7. Предоставление прозрачной статистики по временным затратам и по загрузке различных исполнителей процесса;

8. Накопление актуальной статистики и формирование отчетных документов для возможности принятия управленческих решений.

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

1. Рабочее место оператора call-центра:

- Консультирование покупателя о возможностях сервисного ремонта;

- Консультирования покупателя о ходе его ремонта (получение информации из системы по № заказ-наряда или серийному номеру);

- Помощь в выборе наиболее близкого сервисного центра розничной сети;

2. Рабочее место приемщика товара в ремонт:

- Просмотр истории обслуживания оборудования;

- Прием/выдача оборудования;

- Выдача покупателю ПФ заказ-наряда с указанием всей необходимой информации;

- Оказание консультаций;

3. Рабочее место руководителя группы:

- Распределение заданий на инженеров группы/отдела;

- Оперативный контроль регламентных сроков выполнения ремонта;

- Отслеживание пула задач рабочей группы;

- Формирование необходимой отчетности;

4. Рабочее место сотрудника ответственного за ремонт оборудования:

- Детальная информация о неисправности оборудования;

- Информация о контактных данных покупателя;

- Информация и сроках устранения неисправности;

- Возможность просмотра всей истории оборудования;

5. Рабочее место сотрудника склада:

- Прием/выдача товара;

- Проведение инвентаризации склада;

6. Рабочее место сотрудника отдела логистики:

- Формирование партий оборудования перед отправкой в региональные сервисные центры или представителям производителя;

- Формирование документов, необходимых для логистики оборудования;

7. Рабочее место сотрудника регионального сервисного центра:

- Детальная информация о неисправности оборудования;

- Информация о контактных данных покупателя;

- Информация и сроках устранения неисправности;

- Возможность просмотра всей истории оборудования.

3.1.2 Сравнительный анализ отобранных систем

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

Выполним попарное сравнение критериев и определим наиболее важные (см. таблицу 3.1)

Таблица 3.1 - Сравнение критериев

Критерии

База знаний

Поиск фактов

Наполнение базы знаний

Хранение сведений об оборудовании

Автономная работа

Кроссплатформенность

Стоимость

Оценка компонент собственного вектора

Нормализованные оценки вектора приоритета

База знаний

1

1/2

1/2

2

4

6

1/4

1,169930

0,1198637

Поиск фактов

2

1

1

3

5

7

1/2

1,944200

0,1991905

Наполнение базы знани...

Страница:


Подобные документы

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.

© 2000 — 2023, ООО «Олбест» Все права защищены