17
моделированием этой деятельности. В качестве основной методологии построения
функциональных моделей выступает IDEF0.
Методологию IDEF0 создали американские военные для того, чтобы более
успешно тиражировать бизнес-процессы на предприятиях аэрокосмической
промышленности. В свое время венные столкнулись с проблемой следующего типа.
При проектировании деятельности заводов было замечено, что каждый раз
сотрудники выполняют одни и те же действия при проектировании подсистем
управления, на что уходило много дополнительного времени и ресурсов. Поэтому
возникла идея разработать новый язык, или чертеж, при помощи которого
сотрудники могли бы описать типовые подсистемы управления и при создании
нового завода использовать эти наработки. Язык, которые был создан для этих
целей, лег в основу методологии описания бизнес-процессов на предприятиях IDEF0
[16].
Данная методология описания бизнес-процессов предполагает указание не
только входов и выходов, но дополнительных входов. Всего в данном стандарте
выделяют три типа входа: первый так и называется вход, второй – управлением, а
третий – механизмами.
Стандарт IDEF0 регламентирует с помощью входа (первый тип входных
данных) показывать объекты, которые преобразуются в данным бизнес-процессе,
это могут информационные и материальные потоки. С помощью управления (второй
тип) показывают объекты, которые управляют выполнением бизнес-процессам. С
помощью механизмов (третий тип) необходимо показывать объекты, которые
непосредственно осуществляют данные бизнес-процесс: сотрудники, технические
средства, информационный системы. На выходе бизнес процесса показывают
результат выполнения данного бизнес-процесса [15].
На первом этапе построения IDEF0 модели система представляется как
единое целое. Основная цель данного этапа – выявить входные и выходные данные,
а также механизмы и правила для данной системы [17]. Диаграмма данного этапа
называется контекстной.
Контекстная диаграмма деятельности технического отдела, связанная с
заявками на техническую поддержку изображена на рисунке 4 (для построения
диаграмм использовалось CASE- средство AllFusion Process Modeler 7).
18
Рисунок 4 – Контекстная IDEF0-диаграмма
В качестве входных данных для рассматриваемой деятельности
технического отдела (связанной с приемом и обработкой заявок на техническую
поддержку) выступают заявки от сотрудников учреждения. То есть, когда у
сотрудника возникают сложности в работе компьютерной техники, он подает по
телефону заявку в технический отдел. Результатом деятельности отдела являются
выполненные заявки и отчет по заявкам.
Механизмами, выполняющими рассматриваемую деятельность, являются
сотрудники технического отдела: техники и руководитель отдела. Вся деятельность
осуществляется в соответствии с регламентами работы технического отдела.
Следующий этап моделирования бизнес-процессов – декомпозиция
контекстной диаграммы на блоки, составляющие моделируемую деятельность.
Диаграмма декомпозиции изображена на рисунке 5.
USED AT: AUTHOR: DATE:
REV:PROJECT: IDEF0
05.03.2018
05.03.2018
NOTES: 1 2 3 4 5 6 7 8 9 10
WORKING
DRAFT
RECOMMENDED
PUBLICATION
READER DATE CONTEXT:
TOP
NODE: TITLE: NUMBER:
Деятельность Технического отдела
A-0
Техник
Заявки
Выполненные заявки
Регламет работы
технического
отдела
Руководитель отдела
Отчет по заявкам
00 р.
Деятельность Технического отдела
19
Рисунок 5 – Диаграмма декомпозиции
Исследуемую деятельность составляют пять основных бизнес-процессов:
прием заявок;
выявление причины;
выполнение требуемых работ;
формирование отчетов.
При поступлении заявки в технический отдел её принимает техник, затем
выясняет причину, по которой сотрудник обратился. Далее выполняет требуемые
работы по заявке, в соответствии с выявленными причинами.
Завершающий бизнес-процесс – формирование отчетности. По мере
необходимости (обычно – раз в месяц) руководитель технического отдела
формирует отчет по всем поступившим и выполненным заявкам.
1.2.2. Определение места проектируемой задачи в комплексе задач и ее
описание
В рамках данного дипломного проекта рассматривается создание
информационной системы для автоматизации процессов учета и обработки заявок
USED AT: AUTHOR: DATE:
REV:PROJECT: IDEF0
05.03.2018
05.03.2018
NOTES: 1 2 3 4 5 6 7 8 9 10
WORKING
DRAFT
RECOMMENDED
PUBLICATION
READER DATE CONTEXT:
A-0
NODE: TITLE: NUMBER:
Деятельность Технического отдела
A0
Техник
Регламет работы
технического отдела
Выполненные заявки
Заявки
Принятая заявка
Данные для
работ
Руководитель отдела
Отчет по
заявкам
10 р.
Прием заявок
20 р.
Выявление причины
30 р.
Выполнение требуемых
работ
40 р.
Формирование
отчетов
20
на техническую поддержку. Такие заявки отправляются при необходимости
обслуживания техники какого-либо сотрудника (чаще всего при её неисправности).
А так как в организации используется большое число оргтехники для выполнения
всех бизнес-процессов, то и потребности в ремонте или обслуживании возникают
несколько раз в день.
Обработка и учет заявок включают в себя прежде всего прием этих заявок.
Для моделирования бизнес-процесса этого процесса была также построена IDEF0-
диаграмма, приведенная на рисунке 6 (это декомпозиция соответствующего
процесса, представленного на диаграмме на рисунке 5).
Рисунок 6 – IDEF0-Диаграмма бизнес-процесса «Прием заявок»
Прием заявок выполняется в несколько этапов:
сначала техник принимает заявку;
затем выясняет подробности заявки;
вносит все данные по заявке в журнал заявок;
Организация процесса получения заявок с помощью телефонных звонков
или писем на электронную почту признана низко эффективной не только из-за
USED AT: AUTHOR: DATE:
REV:PROJECT: IDEF0
31.07.2018
31.07.2018
NOTES: 1 2 3 4 5 6 7 8 9 10
WORKING
DRAFT
RECOMMENDED
PUBLICATION
READER DATE CONTEXT:
A0
NODE: TITLE: NUMBER:
Прием заявок
A1
Регламет работы
технического отдела
Техник
Заявки
Принятая заявка
Общие данные по
заявке
Подробные данные
по заявке
10 р.
Получение
заявки
20 р.
Выяснение
подробностей
30 р.
Внесение
заявки
в журнал заявок
21
больших временных затрат, необходимых для выявления всех подробностей заявки
по телефону или в электронной переписке, но и из-за отсутствия возможности
четкого контроля выполнения заявки, решения возникших у сотрудника проблем.
Автоматизация данного процесса позволит четко регламентировать его выполнение
сотрудниками технического отдела, а также стандартизировать форму подачи
заявки, что положительно скажется на эффективности работы сотрудников.
Кроме того, техники имеют разную специализацию и уровни квалификации,
что никаким образом не учитывается при обработке заявок. Часто заявки с
небольшими проблемами приходится обрабатывать высококвалифицированному
сотруднику, а сложные проблемы переходят к низкоквалифицированным или
малоопытным сотрудникам. Это значительно снижает качество работы
технического отдела.
В качестве входных данных для автоматизируемого процесса выступают
заявки от сотрудников на устранение неисправностей, обслуживание и ремонт
оргтехники и компьютеров.
В качестве выходных данных выступают обработанные заявки (результаты
выполнения работ), а также отчеты о количестве поступлений тех или иных заявок
и качестве их обработок сотрудниками учреждения.
1.2.3. Обоснование необходимости использования вычислительной
техники для решения задачи
Задача автоматизации учета и обработки заявок, поступающих в
технический отдел, предполагает использование вычислительной техники для
своего решения. Рассмотрим текущую схему документооборота для поступающей
заявки (Рисунок 7).
22
Сотрудник
учреждения
Сотрудник технического
отдела
1. Отправка заявки по
телефону или
электронной почте
2. Уточнение
недостающих данных
3. Внесение заявки в
журнал
4. Добавление
записи в журнал
после устранения
причины заявки
Заявка на
техническую
поддержку
Заявка на
техническую
поддержку
Заявка на
техническую
поддержку
Заявка на
техническую
поддержку
Заявка на
техническую
поддержку
5. Формирование
отчета по заявкам
Отчет по заявкам
Руководитель технического
отдела
Рисунок 7 – Схема документооборота заявки в технический отдел
Сотрудник организации, у которого возникли какие-либо проблемы с
компьютерной техникой, передает заявку в технический отдел учреждения. Стоит
отметить, что заявка может быть передана как по телефону, так и посредством
электронной почты. Если же ни одним из этих способов нет возможности передать
заявку, то возможен личный визит сотрудника в технический отдел (в случае, если
не работает локальная сеть учреждения).
Затем сотрудник технического отдела (техник), принявший заявку, выясняет
требуемые ему подробности заявки, вносит данные заявки в журнал технической
поддержки и устраняет неисправность (или проводит требуемое обслуживание).
После того, как причина, по которой сотрудник отправил заявку, устранена, в
журнал технической поддержки напротив соответствующей заявки делается
пометка об успешном решении заявки. В конце месяца (или по мере необходимости)
на основании всех заявок в журнале руководителем технического отдела
составляется отчет по заявкам, в котором указывается общее количество
поступивших заявок и количество выполненных.
23
Согласно статистике, в среднем в месяц в отдел поступает 315 заявок,
затраты на обработку и учет одной заявки в среднем составляют 15 минут.
Дополнительно необходимо ежемесячно составлять отчет по заявкам, что требует в
среднем 8 часов рабочего времени в месяц. Таким образом, временные затраты на
прием заявок (без учета этапа выполнения работ) составляет 315*15/60+8=86,75
часов.
Внедрение информационной системы автоматизации учета и обработки
заявок позволит сократить количество этапов, которые проходит заявка. Сотруднику
технического отдела не нужно будет вручную вносить запись о поступившей заявке
в журнал технической поддержки, все поступившие заявки будут автоматически
сохранены в базе данных. Также можно будет проследить какой именно сотрудник
сопровождал ту или иную заявку, а использование возможности отправки
комментариев к заявке позволит выяснить все необходимые подробности в режиме
онлайн-чата. Также необходимо будет предусмотреть разделение технических
специалистов по уровню квалификации и специализациям, чтобы заявки
обрабатывались только компетентными в данном вопросе специалистами.
Кроме того, руководителю технического отдела для формирования отчета
больше не нужно будет пересматривать и перепроверять все записи в журнале
технической поддержки, т.к. подсчет необходимых показателей и формирование
шаблонного отчета можно будет целиком переложить на функции ИС.
1.2.4. Анализ системы обеспечения информационной безопасности и
защиты информации
В ГБОУ Школа № 937 особое внимание уделено вопросам информационной
безопасности и защиты информации. Для обеспечения информационной
безопасности имеются нормативно-правовые и организационно-распорядительные
документы, такие как:
1. Регламент информационной безопасности:
доступ сотрудников к служебной информации;
доступ сотрудников к информационным системам в которых имеются
персональные данные сотрудников и обучающихся;
24
доступ к использованию программного обеспечения, которое
настроено и сконфигурировано специально под требования организации.
2. Регламенты использования ресурсов локальной вычислительной сети,
сети Интернет и электронной почты.
Информационная безопасность и защита информации обеспечиваются на
двух уровнях: программном и аппаратном.
Программный уровень включает в себя настройку политики безопасности
Microsoft Windows Server 2016:
а) права доступа;
б) права пользователя системы на чтение, запись и исполнение каких-либо
данных;
в) парольная защита, доступ к базе (установлены пароли на программные
продукты, такие как: Антивирус Касперского, 1С);
г) аудит основных действий пользователей.
Аппаратный уровень включает в себя хранение ключей от серверной и
коммуникационных шкафов в закрытом сейфе, а также периодические резервные
копирования данных, хранимых на сервере организации.
Кроме того, в организации используется ежеквартальная смена паролей на
доступ к ключевым ресурсам (1С, авторизация в операционной системе на
пользовательских ПК, базы данных, файловые серверы и т.д.).
Ответственным за информационную безопасность является руководитель
технического отдела.
Также в обязанности ответственного за информационную безопасность и
защиту информации входит постоянный мониторинг наиболее опасных угроз:
утечка данных;
халатность сотрудников;
вирусы;
хакеры;
кража оборудования;
аппаратные и программные сбои.
Из списка угроз видно, что первое место в иерархии опасностей
информационного обеспечения учреждения занимает утечка данных. А именно
25
нарушается конфиденциальность персональных данных, как обучающихся, так и
сотрудников организации. Поэтому в обязанности руководителя технического
отдела также входят контроль прав доступа к автоматизированным
информационным системам, на файловый сервер, мониторинг электронной почты
сотрудников, контроль интернет-канала путем закрытия доступа к запрещенным
сайтам, внесенным в Федеральный список экстремистских материалов.
Если утечку информации удается предотвратить, сотрудник несет
ответственность за нарушение внутренней информационной безопасности. К
нарушителю применяются одна или несколько санкций:
1) выговор;
2) строгий выговор;
3) штраф;
4) увольнение из учреждения согласно статье и с заведением уголовного
дела.
1.3. Анализ существующих разработок и выбор стратегии
автоматизации «КАК ДОЛЖНО БЫТЬ»
1.3.1. Анализ существующих разработок для автоматизации задачи
Один из наиболее развитых и популярных подходов к организации ИТ-
менеджмента на предприятии является библиотека ITIL.
ITIL представляет собой совокупность правил, рекомендаций, описаний,
схем и подходов из применяемых на практике способов организации работы служб
ИТ внутри предприятий, или деятельности всего предприятия, если оно занимается
информационными технологиями.
Создателем библиотеки является британская правительственная служба
OGC, которая развивает её и по сей день. Данная служба в структуре правительства
отвечает за повышение эффективности работы государственных учреждений
Великобритании.
Тем не менее библиотека развивается не только силами и идеями данной
службы, но также и с большой помощью независимого сообщества itSMF. Данное
сообщества представляет собой добровольное объединение частных лиц и
организаций, которые профессионально занимаются информационными
26
технологиями. В чисто крупнейших корпоративных членов Форума входят такие
гиганты IT-производства, как компании Microsoft, HP и IBM.
ITIL состоит из нескольких практически руководств, каждое из которых
детально расписано рассмотрено. Эти руководства используются для представления
эффективных и рациональных ИТ-услуг (сервисов).
Сама библиотека состоит из нескольких детально проработанных «Собраний
практических руководств», которые используются для предоставления
эффективных и рациональных ИТ-услуг (сервисов).
Десять основных процессов, входящих в ядро ITIL:
управление инцидентами (Incident management);
управление проблемами (Problem management);
управление конфигурациями (Configuration management);
управление изменениями (Change management);
управление релизами (Release management);
управление уровнем сервиса (Service level management);
управление финансами (Financial management for IT services);
управление мощностью (Capacity management);
управление непрерывностью (IT service continuity management);
управление доступностью (Availability management).
Рассмотрим каждый из них немного подробнее. Первый – управление
инцидентами основан на понятии инцидента. Инцидентом называют любое событие,
которое требует ответной реакции (типичными примерами инцидентов в ИТ службе
можно назвать сбои в работе оборудования, запросы на консультации и т.п.).
Основная задача управления инцидентами – устранение их в кратчайшие сроки. В
тесной связи с этим процессом в ядре ITIL идут вопросы создания и управления
структурным подразделением, являющимся точкой контакта с пользователями ИТ
инфраструктуры предприятия, то есть своего рода службы технической поддержки
пользователей.
Задача этого процесса по управлению проблемами – уменьшение количества
возникающих инцидентов. Это достигается путем постоянного выявления и
своевременного устранения причин, из-за которых возникают инциденты.