22
либо электронной (когда приходит письмо со сканом заявки от начальника отдела
по почте секретарю на имя директора).
Приём заявки производит, как уже было отмечено, начальник
обслуживающего отдела (если заявка устная или письменная) или же секретарь
директора (если заявка электронная на имя директора). Далее начальник отдела или
директор формулируют отказ (например, если в заявке содержится требование
того, чего в Центре нет) либо организуют исполнение заявки. В любом из случаев
заявка сохраняется у начальника в отдельной папке.
Выполнение заявки осуществляют сотрудники-исполнители. Любая заявка в
Центре должна выполняться в срок и без задержек, т.к. от деятельности данного
учреждения зависит состояние здоровья людей. Заявка выполняется, согласно
должностным инструкциям. После выполнения заявки она закрывается (в
отдельную тетрадь вносится пометка о выполнении заявки).
Сбор и анализ информации о сотрудниках и их работе осуществляется
сотрудниками отдела кадров для дальнейшего начисления или удержания премий,
а также для начисления штрафов.
Прием отчетов от начальников отделов и отдела кадров осуществляется
непосредственно директором для контроля за деятельностью Центра и поощрения
активных сотрудников.
1.2.2. Определение места проектируемой задачи в комплексе задач
и ее описание
Для того, чтобы наглядно представить себе место проектируемой задачи в
комплексе задач, были разработаны диаграммы потоков данных (DFD).
Рассмотрим диаграмму нулевого уровня (см. рисунок 6).
0.1.
Выполнение
заявки / вызова
Отправитель
заявки / вызова
Заявка /
вызов
Услуга
Рисунок 6. Диаграмма потока данных: нулевой уровень
23
Это самое общее представление процессов документооборота внутри Центра
медицины катастроф. На этом уровне смешиваются вызовы (имеются в виду
вызовы скорой помощи) и заявки (заявки сотрудников Центра). Из схемы видно,
внешней сущностью является «Отправитель заявки / вызова», а процессом,
соответственно – «Выполнение заявки / вызова». Входные информационные
потоки – это заявки или вызовы, выходные – предоставляемые Центром услуги:
медицинское обслуживание или обслуживание заявок от сотрудников-заявителей.
Более детально потоки данных отражаются на диаграмме потоков данных
первого уровня (см. рисунок 7).
Принять вызов
Лицо,
обратившееся в
скорую помощь
Вызов
Оказать
услуги скорой
помощи
Выехать
на вызов
Обеспечить
выполнение
вызова
Отправить
заявку на
обслуживание
Принять заявку
на
обслуживание
Сохранить
данные о
вызове
Хранилище
аудиозаписей вызова
Выполнить
заявку
Пациент
скорой
помощи
Хранилище заявок
Запись в
электронной
мед. карте
БД аудиозаписей
Хранилище
электронных карт вызов
БД электронных
карт вызовов
Аудиозапись
вызова
Услуги скорой
помощи
Передача вызова
бригаде
Выполнение
вызова
Передача заявки
в приемную /
отделу
Организация
выполнение
заявки
Информация
Об условиях
работы
Потребность
в какой-либо
услуге
Отчитаться о
выполненной
работе
Согласованная
заявка
Отчет
Рисунок 7. Диаграмма потока данных: первый уровень
На этой диаграмме указаны две внешние сущности – лицо, обратившееся в
скорую, и пациент, обслуживаемый по вызову. Бывает, что эти сущности
совпадают (пациент вызывает скорую себе), а бывает, что разнятся (например, мать
вызывает скорую сыну, дочь – отцу и т.д.). На этой схеме, также как и на
предыдущей, указан один входной информационный поток – этовызов. Остальные
24
потоки – выходные. От процесса «принять вызов» исходит четыре потока. Два из
них – это запись в электронной карте вызова (осуществляется диспетчером, затем
фельдшером в программе «1С») и аудиозапись вызова (осуществляется
автоматически через архиватор речи «Спрут-Агат»). От процесса «Сохранить
данные о вызове» исходит два потока –база данных аудиозаписей – к хранилищу
аудиозаписей вызова (находится на сервере «Спрута») и база данных электронных
карт вызовов (находится на сервере MySQL, сопряженном с сервером «1С»).
Еще один поток исходит от диспетчера к свободной бригаде и диспетчеру
гаража – это передача вызова бригаде. Далее следует процесс «выехать на вызов»,
осуществляемый бригадой и дистанционно сопровождаемый диспетчером Центра
и диспетчером гаража. Следом идет потом выполнение вызова, который
завершается процессом «оказать услуги скорой помощи» (реализуется выездной
бригадой). От данного процесса исходит поток услуги скорой помощи,
направляемый к внешней сущности «Пациент скорой помощи».
Эти процессы и потоки, связанные с внешними сущностями – лица,
сделавшими вызов скорой, и пациентами скорой, характеризуют работу Центра
медицины катастроф в целом. Но нас интересуют иные процессы и потоки –
внутренние, те, что направлены на обслуживание собственных нужд. На диаграмме
эти процессы и потоки выделены красным цветом. Их формирует исходящий поток
информация об условиях работы. Этот поток исходит из диспетчерского отдела, на
работу которого равняются прочие отделы Центра. Затем информационный поток
переходит в процесс «Обеспечить выполнение вызова». В этом процессе участвуют
все отделы, обслуживающие бригады. От упомянутого процесса исходит поток
потребность в какой-либо услуге (формируется руководителем какого-либо
подразделения или его сотрудниками). Этот поток переходит в процесс «Отправить
заявку на обслуживание» (осуществляется руководителем какого-либо отдела или
его сотрудниками). Далее следует поток передача заявки в приемную / отделу. Этот
поток, как и сформировавший его процесс, осуществляется руководителями
отделов или их сотрудниками. Затем идет процесс «Принять заявку на
обслуживание», выполняемый руководителями обслуживающих отделов
непосредственно или директором, а затем – руководителями отделов. После этого
следует два потока – поток согласованная заявка, направляющийся к хранилищу
25
заявок, и организация выполнения заявки, направляющийся к процессу
«Выполнить заявку» (осуществляется сотрудниками-исполнителями). От этого
процесса исходит поток отчет, который переходит в процесс «Отчитаться о
выполненной работе» (осуществляется сотрудниками, выполнившими заявку,
перед своими руководителями, а уже руководителями – перед директором).
Автоматизация обозначенного комплекса процессовдолжна привести к тому,
что процессы выделенной нами области будут прозрачными и легко
контролируемыми, а их результаты можно будет формировать автоматически в
форме электронных отчетов.
Выбранная нами задача тесно связана с задачами контроля и организации
деятельности в Центре медицины катастроф, а также с задачами формирования
отчетности для отправки в вышестоящие инстанции.
Важность автоматизации приема входящей документации в Центре
обусловлена необходимостью усиления контроля за исполнением работы
сотрудниками отделов, а также необходимостью привести, по возможности, весь
документооборот к «единому знаменателю», т.е. к единой информационной
системе документооборота.
Для решения поставленной задачи необходимо привлечь сотрудников –
специалистов в сфере информатики и вычислительной техники.
Назовем теперь основные определения и понятия, свойственные
рассматриваемой области, которые в дальнейшем будут фигурировать в нашем
проекте.
Входящий документ – это письмо, составленное сотрудником Центра и
сохраненное в проектируемой информационной системе. На данном этапе это
заявка на обслуживание. В дальнейшем это может быть любое официальное
обращение в Центр от сотрудника.
Сотрудники – это сотрудники Центра. Условно делятся на пять типов:
«пользователи», «администраторы», «сотрудники отдела кадров», «начальники
отделов» и «директор».
Отделы – это подразделения Центра. Сюда относятся собственно отделы, а
также службы, управления, подстанции и проч.
26
Отчеты – это сообщения руководству о выполнении поставленных задач.
Соответственно к отчетам могут иметь доступ только руководители Центра.
Поскольку отдел кадров оказывает влияние на вынесение сотрудникам премий
бухгалтерий, то ему также разрешено иметь доступ к отчетам.
Теперь обратимся к проектируемой нами программе. Она должна
использовать в качестве входных документов несколько источников. Это
- входящие документы,
- сведения о сотрудниках,
- сведения об отделе.
В качестве выходных документов наша ИС должна «уметь» формировать
- отчеты о входящей документации,
- отчеты о сотрудниках,
- отчеты об отделах.
В рамках решения задачи автоматизации документооборота заявка
сотрудника Центра будет трансформироваться из устной формы в отчеты, которые
должны характеризовать управленческие процессы внутри Центра, происходящие
во время выполнения заявки.
Особенности расчетов показателей, содержащихся в отчетах по
документообороту в Центре, будут содержать общую сумму предоставляемых в
отчете записей.
Теперь попробуем поэтапно описать исполнителей вех процессов и
регламент исполнения.
На первом этапе зарегистрированные пользователи удаленно формируют
заявку в специальном разделе для заявок, указывая своиФИО,содержание заявки и
дату заполнения в соответствующие графы.
На этом же этапе администратор из отдела АСУ просматривает
сформированные заявки и корректирует их при необходимости.
На втором этапе, после того, как заявка сформирована, её просматривает
секретарь, указывающий свои ФИО в графе «ответственный секретарь», а также
заполняет графы «исполняющий отдел» и «номер входящего документа». Затем
заявку просматривает директор или его заместитель, консультируется с
начальником указанного отдела, корректирует при необходимости графу
27
«исполняющий отдел», а также вводит конечную дату в графу «сроки исполнения»
и свои ФИО в графу «согласовано – автор резолюции». Также он ставит при
необходимости помету в графу «на особом контроле». Таким образом заявка
согласовывается с руководством Центра.
На третьем этапе происходит выполнение заявки сотрудниками.
На последнем четвертом этапе директор получает отчет по результатам
работы, редактирует графу «на особом контроле», а секретарь ставит пометку в
графе «снято с учета».
1.2.3. Обоснование необходимости использования вычислительной
техники для решения задачи
Стоит отметить, что Центр медицины катастроф до внедрения программного
продукта уже являлся частично автоматизированным благодаря
функционированию, прежде всего, таких ПО, как «1С» и «Антивирус
Касперского». Несколько лет функционирует сайт Центра. Для ведения
документооборота используется специальное ПО – СЭД «Диалог».
При этом в Центре оставалась не автоматизированной работа с технической
документацией.Это является одной из важных проблем учреждения. Решить её
можно путем внедрения нового разрабатываемого нами программного
обеспечения. И в дальнейшем, при успешной реализации проекта, данное ПО
сможет стать альтернативой навязываемому «сверху» «Диалогу».
В настоящее время работа сотрудников по учету всех документов, в
основном, выполняется вручную, малая часть из них (электронные письма из
вышестоящих организаций) учитывается в системе СЭД «Диалог».
Покажем на примере отдела АСУ, как организован документооборот в
Центре в тех сферах, которые не охватывает СЭД «Диалог».
Входящая техническая документация формируется локально – сотрудниками
на своих рабочих местах или принимается от посетителей, после чего она – в
бумажном виде – продолжает движение по учреждению. Так, например, в отделе
АСУ при оформлении заявки на ремонт старого оборудования сотрудники должны
вручную вписывать данные на бланке «Заявка на обслуживание в отдел АСУ». Это
28
можно было бы делать быстрее, если бы работала программа, помогающая
автоматически заполнять необходимые документы. Кроме того, часть работы
могли бы выполнять сами посетители – удаленно.
Все заявки хранятся в бумажном виде в отдельной папке. Чтобы сотруднику
отдела АСУ найти нужную заявку, бывает нужно перерыть всю папку.
Новую технику в отделе АСУ выдают после того, как посетители –
руководители подразделений – оформят заявку на имя директора Центра и он, в
свою очередь, поставит на ней свою резолюцию. При этом, как правило, свободных
компьютеров в Центре для посетителей нет. Это обстоятельство создаёт немало
трудностей для тех, кто приехал издалека (а подразделения Центра разбросаны по
всему Крыму) и желает оформить заявку на получение новой техники на месте.
Из всего сказанного выше можно сделать следующее заключение: чтобы
обеспечить ускорение движения заявки по Центру, нужно освободить от
выполнения рутинной бумажной работы сотрудника отдела АСУ и
автоматизировать сам процесс документооборота.
1.2.4. Анализ системы обеспечения информационной безопасности
и защиты информации
Следует отдельно оговорить защищенность разрабатываемой программы.
Сеть Центра функционирует за трехуровневой системой аппаратной защиты.
На перовом уровне расположен маршрутизатор Mikrotik CCR1009-7G-1C-
1S+. Он распределяет потоки сети и устанавливает правила и запреты. На него
установлена парольная защита, как и на все сетевые устройства в Центре.
На втором уровне работает программно-аппаратный комплекс VipNet IDS
1000. Это сетевое устройство в нашем случае подключается к каналам связи
контролируемых ИС, используя Т-образную схему при помощи маршрутизатора
Mikrotikсо SPAN-портом. Проходящий через Mikrotikтрафик зеркалируется – и
передается на ПАК. Поэтому VipNet IDS 1000никак не влияет на качество
прохождения трафика через канал.
На третьем уровне работает криптошлюзViPNet Coordinator HW1000
(производства российской компонии Infotecs). Это шлюз безопасности, который
29
позволяет организовать в Центре медицины катастроф защищенный доступ как в
местный ЦОД, так и в корпоративную облачную инфраструктуру. ViPNet
Coordinator помогает организовать защищенный контролируемый доступ
сотрудников к сети Интернет. Он также защищает мультисервисные сети (включая
видеоконференцсвязь и IP-телефонию). Его поддержка защиты скоростных
каналов связи составляет до 1 Гбит/сек. Под ViPNet’ом работает те отделы,
которые собирают индивидуальные данные – отдел кадров, отдел медицинской
статистики, оперативно-диспетчерский отдел и т.д.
На программном уровне компьютеры и планшеты Центра защищены ПО
«Kaspersky Endpoint Security» версии 11. Эта программа позволяет легко
администрировать пользовательские АРМы при помощи ПО «Kaspersky Security
Center», устанавливаемого соответственно на АРМе администратора.
В программах «ПроМед» и «1С» пользователи работают под своими
запароленными учетными записями.
В Центре на все компьютеры установлены по две учетные записи – для
администратора и для пользователя. Также в учреждении функционирует как
локальные учетные записи, так и учетные записи домена.
В Центре функционирует два вида корпоративной почты – на домене
krcmr.ruи защищенном сегменте – «Деловая почта» под ViPNet’ом.Также
руководством Центра совместно с отделом АСУ разработаны «Правила
пользования корпоративной почтой».
На всех компьютерах Центра, работающих в защищенной сети, установлен
СДЗ DallasLock, лицензия на которое бесплатно поставляется Центру от
Крымского медицинского информационно-аналитического центра. Но из
отрицательных моментов можно назвать то, что не на всех компьютерах он
настроен таким образом, чтобы препятствовать незаконному копированию данных.
Также из отрицательных моментов можно выделить то обстоятельство, что в
Центре должность инженера информационной безопасности остается вакантной.
По факту, за информационную безопасности отвечает начальник отдела АСУ.
Однако на бумаге эта ответственность никак не закреплена и не регламентирована.
30
1.3. Анализ существующих разработок и выбор стратегии
автоматизации «КАК ДОЛЖНО БЫТЬ»
1.3.1. Анализ существующих разработок для автоматизации задачи
Рассмотрим основные программные разработки, созданные для
автоматизации документооборота.
Во-первых, обратим внимание на крымский IT-продукт. Это СЭД «Диалог»
– разработка ГУП РК «Крымтехнологии». Являясь облачной автоматизированной
ИС, «Диалог» обеспечивает юридически значимый электронный документооборот
и управление корпоративной информацией.
Разработчики заверяют, что данное ПО легко адаптируется к разным
инструкциям и регламентам по делопроизводству, применяемым в учреждениях.
Недостатками «Диалога» является неудобный интерфейс и невозможность
охватить им все сферы или хотя бы большинство сфер документооборота
организации.
СЭД «Контур.Диадок» – это ПО, разработанное екатеринбургской АО «ПФ
«СКБ Контур» (имеет в Симферополе своё представительство). Вышеуказанная
СЭД даёт возможность быстро обмениваться юридически значимыми
электронными документами и счетами-фактурами.
«Контур.Диадок» имеет простую и удобную в пользовании веб-версию. Эта
веб-версия позволяет легко получать, создавать, отправлять электронные
документы без установки дополнительного ПО.
В «Контур.Диадок» также встроен интеграционный модуль для «1С»версий
7.7, 8.1, 8.2 и 8.3, а также с SAP, Oracle, MS Dynamics и т.д (через API).
Недостатки также присутствуют. Это, по мнению пользователей, отсутствие
некоторых удобных функций и ошибки в коде программы, периодически
приводящие к её сбоям.
ECM-система «ЭЛАР Контекст»– разработка московской корпорации
«ЭЛАР» (имеет в Симферополе своё представительство). «ЭЛАР Контекст»
построен на современной сервис-ориентированной архитектуре. Он, по сути, даёт
возможность реализовать модульное ПО. Благодаря этому пользователиполучают
31
нужный им функционал без избыточных опций, а также возможность легко
масштабировать систему при помощи дозакупки необходимых модулей, в т.ч. на
базе искусственного интеллекта.
Особо выделяется модульинтеллектуальной обработки «Документопоток».
Он занимается распознаванием и классификацией документов. Источники ввода
документации могут быть разными – искусственный интеллектклассифицирует
документы по типам и собирает комплекты. Затем из каждого комплекта берется
информация и заносится в электронный архив.
Модуль интеллектуального поиска, как и предыдущий модуль, уже заложен
в базовом функционале «ЭЛАР Контекст». Он может формировать аннотации к
документам, производить поиск по полным текстам и их атрибутам, понимать
грамматику русского языка и выдавать релевантные результаты для разных групп
пользователей.
ECM-система «1С: Документооборот»– это ПО, созданное компанией
«Фирма ''1С''» (Москва). Основными направлениями работы этой системы
являются следующие:
- делопроизводство (в т.ч. и общий),
- управление договорной деятельностью,
- электронный архив,
- работа с обращениями.
Функционал «1С: Документооборот» можно расширять, используяплагины.
У пользователей также есть возможность прикреплять файлы и в дальнейшем
изменять их– при обработке маршрутов документов. В базовом наборе функций
также присутствует регистрация Проводника Windows.
Интерфейс «1С: Документооборот» настраивается с опорой на типы
пользователей. Организационная структура предприятия и роли исполнителей
могут быть использованы для выбора исполнителей бизнес-процессов. Есть
возможность просмотреть список работающих в данный момент пользователей.
Подсистема «Задачи и процессы сотрудников» содержит средства создания и
управления бизнес-процессами, а также настройки ролевой адресации задач,
настройки матрицы замены/замещения сотрудников.