Файл: Разработка регламента выполнения процесса «Изучение демографических данных»..pdf

Поскольку готовых системных решений не было, была начата разработка технического задания на создание единой информационно-аналитической системы (ЕИАС) автоматизации выдачи первичных медицинских свидетельств о рождении и смерти. К разработке такого технического задания были привлечены не только IT-специалисты МИАЦ, но и главные врачи больниц и родильных домов, врачи, судебные эксперты и медицинские статистики.

В соответствие с техническим задание, система должна справляться с решением таких задач:

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

Обеспечение оперативности получения данных.

Повышение качества кодировки данных о причинах, повлекших смерть.

ЕИАС «Демография» была разработана в период с июля по сентябрь 2014 года.

Начала эксплуатироваться с ноября 2014 года

ЕИАС «Демография» справляется с поставленными перед ней задачами.

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

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

Хорошо разграничены права пользователей. Есть журнал действий каждого пользователя. Идентификация происходит в домене Active Directory.

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

Глава 2. Информационный процесс. Регламент

2.1. Определения регламента

Для начала давайте дадим определение самому понятию «Регламент информационного процесса». Мы можем смело сказать, что регламент информационного процесса представляет собой определенный порядок выполнения информационного процесса, определяющий состав и действия участников.^[4]

Связи по управлению (отчетность вверх и управленческие решения вниз)

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

Регламентация процессов

Рассмотрим пример регламентации процесса управления на основе информационного бизнес-процесса. Вся информационная система состоит из определенных процессов. Каждый процесс выделяется отдельно, описывается и после этого, начинается его регламентация. Это очень важно и необходимо потому, что управление возможно только тогда, когда есть четко определен­ные объекты, а их взаимосвязи зафиксированы. Все форму­лировки, взаимосвязи и порядок работы и управления должны быть зафиксированы в документах. Наличие бумажных копий документов не обязательно. Документ — это информация, зак­репленная на материальном носителе. Носитель может быть любым: бумажным, электронным, пластиковым и пр. Главная его задача — сохранение информации в удобном для пользова­теля виде.^[5]

2.2. Процедура регламентации

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

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

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

• руководителям «анархического склада» не хочется заниматься «лишней бюрократией» — «мы без этого жили раньше, про­живем и дальше» или «у нас нет времени этим заниматься, мы должны делать деньги»;
• документирование взаимоотношений между процессами приводит к «перетягиванию одеяла (ресурсов)» друг у друга или к «перекладыванию ответственности» друг на друга и, как следствие этого, к конфликтам;

наступает понимание того, что ежедневная «текучка» посте­пенно привела в полную негодность существующие инструк­ции и положения, для того чтобы сделать их работоспособ­ными, требуется очень много сил и времени.

2.3. Методы, используемые для создания информационных процессов, на примере построение бизнес-процессов

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

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

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

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

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

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

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

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

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

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

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

Такие правила называются – нотация. Среди них, наиболее популярными являются IDEF0, BPMN, eEPC.

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

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

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

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

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

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

Получение предложений об изменении условий договора;

Анализ возможности внесения предложенных правок;

Составление дополнительных соглашений к договорам;

Подписание доп. соглашений к договорам;

Пересылка подписанных соглашений заказчику.

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

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

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

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

Их всего три: и, или, исключающие или.

Самыми распространенными ошибками являются использование оператора «ИЛИ» и «исключающего ИЛИ» после события, например:

Характерны ошибки, связанные с пропуском логических операторов, когда событие имеет две исходящих связи, или функция имеет две входящих связи.^[6]

Распространено неправильное использование обратной связи, например:

Основа нотации IDEF0 состоит в том, что сам бизнес-процесс представлен прямоугольником, в который входят и выходят стрелки.^[7]

Преимущества IDEF0 – показывает взаимодействие процессов в общем виде, без лишних подробностей.

Недостатки IDEF0 –  нельзя увидеть алгоритма выполнения бизнес-процессов. Требует определенной подготовки для разработки и чтения нотации.