Разработка регламента выполнения процесса «Управление документооборотом» (Модернизация бизнес-процессов)

Содержание:

ВВЕДЕНИЕ

В современном мире роль информации огромна. Каждый день обрабатывается большое количество документов, даже в самых маленьких компаниях, не говоря уже о больших предприятиях. Работа с данными проводится в самых разных областях деятельности организаций. При этой работе возникает множество проблем, с такими процессами как: хранение, доступ, поиск, обновление и т.д. В свое время появление компьютеров и их доступность позволили совершить переход к электронной форме документов и сократили затрачиваемые ресурсы на обработку информации. Однако простое хранение данных в электронной форме и доступ к ним не решает всех проблем. Зачастую даже в одной сфере деятельности информации так много и она столь разнообразна, что необходимо использовать более совершенное средство организации данных. Таким средством являются реляционные базы данных, обеспечивающие структурное хранение и связывание различных данных. Благодаря такой форме, базы данных обеспечивают удобство, скорость и точность получения нужной информации из массива хранимых данных и организованный документооборот. Однако для разработки удобной и функциональной базы необходимо иметь хорошее представление о сфере деятельности, в которой происходит работа с информацией. Для этих целей производится анализ предметной области, в процессе которого определяются основные моменты работы. Лучшим средством анализа предметной области является моделирование бизнес-процессов.

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

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

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

Цель: Рассмотреть процессы документооборота при проведении ремонтных работ подрядными организациями на химическом предприятии.

Задачи:

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

- построить модель действующей системы;

- определить возможности улучшения процесса документооборота;

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

1 Исследование предметной области

• 1. 1.1. Описание предметной области. Постановка задачи.

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

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

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

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

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

- ремонтные работы разделяются на виды, в зависимости от характера выполняемой работы;

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

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

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

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

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

Следуя из приведенных выше зависимостей можно выделить следующие основные объекты:

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

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

- Организации – подрядные организации осуществляющие работы, определенные договором;

- Рабочие – люди, непосредственно выполняющие работы, и входящие в состав работников подрядной организации;

- Ремонтные работы – работы, выполняемые работниками определенной подрядной организации.

В рамках курсовой работы рассматривается документальная часть при проведении ремонтных работ.

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

Исходные данные:

- данные договора – место и вид проведения работ, организация, проводящая работы, держатели договоров;

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

Результаты:

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

- проанализированные данные на возможность проведения работ определенным работником организации (подрядчиком), формата «допущен/не допущен»;

- оформленный наряд-допуск.

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

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

1.2 Выбор средства для моделирования бизнес-процессов

Для моделирования бизнес-процессов используются CASE-средства – инструменты для упрощения и ускорения процессов разработки программного обеспечения. Некоторые CASE-средства позволяют не только построить модель бизнес-процесса и схему базы данных, но и сгенерировать программный код на некоторых языках программирования и спроектировать базу данных в определенных СУБД.

В России наиболее распространены CASE-средства: Rational Rose, Oracle Designer, AllFusion Process Modeler (BPWin) и AllFusion ERwin Data Modeler (ERWin), ARIS, Power Designer.

Rational Rose (компания IBM) – средство моделирования объектно-ориентированных информационных систем. Позволяет решать практически любые задачи в проектировании информационных систем: от анализа бизнес-процессов до кодогенерации на определенном языке программирования. Позволяет разрабатывать как высокоуровневые, так и низкоуровневые модели, осуществляя тем самым либо абстрактное проектирование, либо логическое.

Oracle Designer (компания Oracle) – входит в комплекс инструментальных средств Oracle Developer Suite по проектированию программных систем и баз данных, реализующих технологию CASE и собственную методологию разработки ИС компании Oracle - "CDM". Средство имеет смысл использовать при ориентации на всю линейку продуктов Oracle, применяемую для проектирования, разработки и реализации сложной программной системы.

AllFusion Process Modeler (BPWin) (компания Соmputer Associates) –основан на методологии IDEF и предназначен для функционального моделирования и анализа деятельности предприятия. Функциональная модель IDEF отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями.

AllFusion ERwin Data Modeler (ERWin) (компания Соmputer Associates) – средство концептуального моделирования БД. Используется при моделировании и создании баз данных произвольной сложности на основе диаграмм "сущность - связь".

ARIS (компания IDS Scheer AG) – интегрированное средство моделирования бизнес-процессов, объединяющее разнообразные методы моделирования и анализа систем. В первую очередь, это средство описания, анализа, оптимизации и документирования бизнес-процессов.

Power Designer (компания Sybase) – средство моделирования бизнес-процессов, проектирования баз данных и объектного моделирования. Power Designer позволяет устранить следующие препятствия, мешающие эффективной разработке проектов: различия в профессиональной подготовке участников проекта, разнородные платформы и изобилие языков разработки, - то, что характерно для большинства современных компаний. Имеет средства моделирования бизнес-процессов, моделирования данных (генерация схем БД), объектного моделирования (стандарт UML) и имеет репозиторий масштаба предприятия.

Для моделирования бизнес-процессов выбраны BPwin Process Modeler и Erwin Data Modeler, из пакета AllFusion Modeling Suite компании CA. Эти инструментальные средства наиболее распространены и имеют хороший баланс между удобством интерфейса и возможностями.

BPwin поддерживает три стандартные нотации: IDEF0 (функциональное моделирование), DFD (моделирование потоков данных) и IDEF3 (моделирование потоков работ), которые будут задействованы в процессе работы.

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

1.3 Моделирование бизнес-процессов «как есть».

Для построения модели бизнес-процесса контроля документов подрядчиков необходимо рассмотреть общую схему проведения ремонтных работ. Для построения общей схемы бизнес-процесса использовалась нотация IDEF0, так как она лучше всего описывает структуру процесса и позволяет определить процессы и схему их взаимодействие. По этой нотации была построена контекстная диаграмма и определены входные/выходные данные, управление и механизмы (Рисунок 1).

Рисунок 1. Контекстная диаграмма «Проведение ремонтных работ на предприятии»

Входными данными определены:

- «Необходимость в проведении работ» – общее наименование причин, по которым необходимо провести работы (выход из строя оборудование, не соответствие состояния оборудования определенным нормам, изменение требований законодательства, разрушение зданий и сооружений и др.);

- «Место проведения работы» – территориальное и юридически расположенное, определение объекта проведения ремонта, выраженное подразделением, отделением, позицией оборудования, корпусом и т.д.;

- «Список подрядных организаций» – список, формируемый из организаций способных провести ремонт данного вида;

Выходными данными являются «Выполненные работы» – результат процесса ремонта (исправленное оборудование, сооружения и др.).

Управление реализует «Законодательство РФ, национальные и межгосударственные стандарты», т.к. любая производственная деятельность регулируется законами и стандартами, действующими в Российской Федерации.

Механизмы, осуществляющие выполнение процесса:

- «Отделы и подразделения предприятия» – отделы и подразделения предприятия, отвечающие за подготовку места к ремонтным работам и контроль работы подрядчиков;

- «Организация» – подрядная организация, осуществляющая ремонтные работы.

Для детального рассмотрения общей схемы была произведена ее декомпозиция, и выделены процессы: «Заключение договора», «Подготовка документов», «Подготовка места к ремонтным работам», «Проведение ремонта», «Принятие работ», «Закрытие договора». Для удобства пересекающиеся стрелки потоков отмечены разными цветами (Рисунок 2).

Рисунок 2. Декомпозиция контекстной диаграммы.

Входными данными, управлением и механизмами в процессе «Заключение договора» являются соответствующие потоки контекстной диаграммы (Рисунок 3).

Рисунок 3. Процесс «Заключение договора».

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

В процессе «Подготовка документов» входными данными являются «Сведения об организации» и «Сведения о месте и виде ремонтных работ» (Рисунок 4).

Рисунок 4. Процессы «Подготовка документов» и «Подготовка места к проведению работ».

В процессе «Подготовка документов» осуществляется подготовка подрядчиков к выполнению работ: проверяется наличие документов, подтверждающих квалификацию работников, проводятся инструктажи, и т.д. Механизмами выполнения являются: как сотрудники предприятия, так и подрядной организации. Выходными данными является «Наряд-допуск» – разрешение на проведение работ, которое устанавливает место, время, вид работы, список работников, осуществляющих работы, разработка мероприятий по подготовке и выполнению работ, используемый инструмент и т.д. Поэтому, эти данные являются управляющими в процессе «Проведение работ». Параллельно с этим процессом проводится процесс «Подготовка места к проведению работ». Входные данные – «Сведения о месте и виде ремонтных работ». В данном процессе происходит подготовка объекта к выполнению ремонтных работ. Выполняют работы по подготовке к ремонту в подразделениях предприятия – «Отделы и подразделения предприятия». Результатами процесса являются «Подготовленное место» проведения ремонтных работ и «Акт передачи территории». Результаты этого процесса являются входными данными для процесса «Проведение работ» (Рисунок 5).

Рисунок 5. Процесс «Проведение работ».

В процессе «Проведение работ» непосредственно выполняются ремонтные работы. Работы производятся работниками подрядной организации (механизм «Организация»), определяются нарядом-допуском, выполняется в соответствии с нормативными документами, действующие в РФ и положениями, действующими на территории предприятия, и контролируются держателями договоров (управление «Наряд-допуск», «Законодательство РФ, национальные и межгосударственные стандарты», «Держатель договора»). Выходными данными процесса является «Результат выполненных работ» (фактическое состояние объекта после выполнения ремонта), который отправляется на вход данных процесса «Принятие работ» (Рисунок 6).

Рисунок 6. Процессы «Принятие работ» и «Закрытие договора».

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

После рассмотрения общей схемы проведения ремонтных работ можно рассмотреть схему документального контроля подрядчиков. Для декомпозиции процесса «Подготовка документов» была выбрана нотация IDEF3, так как она способна отобразить логику выполнения процесса и отобразить последовательно выполнения команд (Рисунок 7).

Рисунок 7. Декомпозиция процесса «Подготовка документов» по нотации IDEF3.

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

Рисунок 8. Процессы сбора данных.

С внешней ссылки «Данные о подрядчиках» (от подрядчика) поступают данные в процессы «Сбор сведений о прохождении медосмотра», «Сведения о пройденных мероприятиях» и «Сбор сведений о наличии удостоверений». С внешней ссылки «Данные о проводимых работах» (сведения договора) поступают данные в процесс «Сбор сведений о необходимый мероприятиях». Затем выполняется проверка на соответствие полученных данных установленным требованиям. Проверка осуществляется процессами «Определение актуальности срока прохождения медосмотра», «Определение актуальности срока прохождения мероприятия и соответствия вида мероприятия», «Определение соответствия удостоверения виду выполняемой работы (должности)» и «Определение срока действия» (Рисунок 9).

Рисунок 9. Процессы анализа данных.

Перекрестки J2 и J10 имеют тип «Синхронное И», так как после завершения процесса сбора данных об удостоверениях одновременно начинается их проверка на соответствие виду работ и срок действия.

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

В перекресток J5 попадают данные о завершении всех процессов с положительным результатом. Вид перекрестка «Асинхронное И», так как требуется завершение всех предшествующих процессов, после которых начинается процесс «Прохождение вводного инструктажа». Данные подрядчиков, прошедших проверку и вводный инструктаж направляются на оформления наряда-допуска. (Рисунок 10).

Рисунок 10. Завершающие процессы.

В перекресток J6 поступают завершенные процессы с отрицательными результатами. Перекресток имеет вид «Асинхронное ИЛИ», так как достаточно завершения хотя бы одного процесса отрицательным результатом, чтобы не допустить подрядчика к проведению работ.

Таким образом, можно видеть, что в процессе «Подготовка документов» данные, необходимые для допуска к работам поступают от подрядчика. Эти данные анализируются, и выводится два возможных результата – или подрядчик не допущен к работам (внешняя ссылка «Отказ в допуске к проведению работ») и происходит проверка следующего, или подрядчик допускается к работам и информация заносится в наряд-допуск (внешняя ссылка «Наряд-допуск»).

Разработанная модель «как есть» бизнес-процесса «Проведение ремонтных работ на предприятии», выполненная в BPwin, приведена в Приложении 1.

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

2 Модернизация бизнес-процессов

• 1. 2.1. Предлагаемые мероприятия по улучшению бизнес-процессов.

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

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

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

В процессе анализа были выделены три основных области – «Область договора», «Подрядчики» и «Работы». Для каждой из этой области были спроектированы сущности и определены их атрибуты. На схеме ER-модели сущности разделены на две части. В нижней части сущности содержатся простые атрибуты, а в верхней части – первичные и вторичные ключевые поля. Сущности, имеющие только два аргумента – первичный ключ и простой атрибут – называют справочниками, так как чаще всего их используют для получения заранее известных, определенных значений. Для удобства восприятия области на общей схемы обозначены разными цветами (Рисунок 11).

Рисунок 11. Логическая схемы базы данных «Управление подрядчиками».

Первая рассматриваемая область – «Договор». Область является связующий между областями «Работы» и «Подрядчики», так как через нее определяется, какие организации, какие работы будут осуществлять. Область состоит из пяти сущностей: «Держатели договоров», «Организации», «Подразделения» «Договор» и «Ремонтные работы» (Рисунок 12).

Рисунок 12. Схема области «Область договора».

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

Сущность «Держатели_договоров» связана с сущностью «Договор» и имеет связь вида «один-ко-многим», так как один отдел может держать несколько договоров

Сущность «Организации» связана с сущностью «Договор» и имеет связь вида «один-ко-многим», так как одна организация может заключить несколько договоров.

Сущность «Договор» связана с сущностью «Ремонтные_работы» и имеет связь вида «один-ко-многим», так как по одному договору может осуществляться несколько работ.

Сущность «Ремонтные_работы» выполняет связывающую роль между сущностями «Договор» и сущностью «Подразделение». Кроме того, сущности «Подразделения» и «Ремонтные работы» относятся как к области «Область договора», так и к области «Работы» и являются связывающими звеньями.

В среде ERwin вторичные ключи можно разделить на: прямые и косвенные. Так в сущности «Договор» внешний ключ «Держатель договора id_Отдела (FK)» является прямым, так как имеется атрибут «Держатель договора», содержащий первичный ключ «id_Отдела», принадлежащий сущности «Держатели_договоров», а в сущности «Ремонтные_работы» внешний ключ «id_Отдела» является косвенным, так как в сущности нет атрибута, содержащего данных этого ключа. Однако сущности «Ремонтные_работы» и «Держатели договоров» связаны между сбой посредством сущности «Договор». Именно эту связь и отображает косвенный внешний ключ в сущности «Ремонтные_работы».

Сущности «Подразделения» и «Ремонтные_работы» имеют связь «один-ко-многим» - в одном подразделении могут проводиться несколько работ.

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

Атрибуты сущностей «Держатели_договора» и «Ремонтные_работы» имеют числовой тип данных, так как состоят из первичного и вторичных ключей.

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

Рисунок 13. Схема области «Работы».

Область содержит те же сущности «Ремонтные_работ» и «Подразделения», но здесь они имеют другой смысл. Если «Область договора» использовала их для определения зависимости между держателями договоров, организациями и местом проведения работ, то в данной области определяется место проведения и характер выполняемых работ.

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

Сущность «Ремонтные_работы» связана с сущностью «Вид_работы» связью «многие-к-одному», так как несколько проводимых работ могут иметь один и тот же вид.

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

Сущность «Ремонтные_работы» является связующей между областями «Работы» и «Область договора», а сущность «Мероприятия» осуществляет связь между областями «Работы» и «Подрядчики». Типы данных атрибутов сущности «Мероприятия» приведены в Таблице 1.

Таблица 1

Атрибуты сущности «Мероприятия»

Атрибут	Тип данных	Свойство
id_Мероприятия	Числовой, Счетчик	Первичный ключ (PK)
Вид_работы	Числовой	Внешний ключ (FK)
Мероприятие	Текстовый	Ограничен до 50 символов (String)
Срок действия	Числовой	Целое число (Integer)

Следующая рассматриваемая область «Подрядчики». Область имеет четыре сущности: «Личная карта», «Аттестация», «Должности» и «Профессиональные удостоверения» (Рисунок 14).

Рисунок 14. Схема области «Подрядчики».

Через сущности «Личная карта» и «Аттестация» область связана с областями «Область договора» и «Работы» соответственно.

Сущность «Личная карта» содержит основную информацию о сотруднике, а так же даты прохождения обязательных мероприятий. Вторичным ключом «Организация id_организация» она осуществляет связь с сущностью «Организация» области «Область_договора».

Сущность «Личная карта» связана с сущностью «Должности» связью «многие-к-одному», так как разные сотрудники могут иметь одну должность.

Сущность «Личная карта» связана с сущностью «Аттестация» связью «один-ко-многим», так как один сотрудник имеет несколько удостоверений.

Атрибуты сущности «Личная карта» приведены в Таблице 2.

Таблица 2

Атрибуты сущности «Личная карта»

Атрибут	Тип данных	Свойства
id_Сотрудника	Числовой, счетчик	Первичный ключ (PK)
Должность id_Должности	Числовой	Внешний ключ (FK)
Организации id_Организации	Числовой	Внешний ключ (FK)
ФИО	Текстовый	Ограничен до 60 символов (String)
Дата_рождения	Дата/время	Короткий формат даты
Дата_прохождения_инструктажа	Дата/время	Короткий формат даты
Дата_прохождения_МО	Дата/время	Короткий формат даты

Сущность «Должности» связана с сущностью «Профессиональные удостоверения» не идентифицирующей связью «один-ко-многим», так как одна должность может иметь несколько удостоверений, а может быть не одного.

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

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

Атрибуты сущности «Профессиональные удостоверения» представлены в Таблице 3.

Таблица 3

Атрибуты сущности «Профессиональные удостоверения»

Атрибут	Тип данных	Свойства
id_Удостоверения	Числовой, счетчик	Первичный ключ (PK)
Должность id_Должности	Числовой	Внешний ключ (FK)
Удостоверение	Текстовый	Ограничен до 60 символов (String)
Срок_действия	Числовой	Целое число (Integer)

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

Основные атрибуты сущности представлены в Таблице 4.

Таблица 4

Атрибуты сущности «Аттестация»

Атрибут	Тип данных	Свойства
id_Аттестации	Числовой, счетчик	Первичный ключ (PK)
Сотрудник id_Сотрудника	Числовой	Внешний ключ (FK)
Должность id_Должности	Числовой	Внешний ключ (FK)
Удостоверение id_Удостоверения	Числовой	Внешний ключ (FK)
Дата_получения	Дата/время	Короткий формат даты
Пройденные мероприятия id_Мероприятия	Числовой	Внешний ключ (FK)
Дата_прохождения	Дата/время	Короткий формат даты

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

Основная задача проектируемой базы данных – определение подрядчиков, которые могут осуществлять определенные виды работ. Формирование списка допущенных подрядчиков для оформления наряда-допуска также будет осуществляется через запрос. Логическая схема базы данных в полном объеме представлена в приложении 2.

• 1. 2.2. Моделирование процессов «как должно быть».

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

Бизнес-процесс построен с учетом включения в работу базы данных «Управление подрядчиками». Изменения касаются процесса «Подготовка документов». Так как база данных реализует собой информационную систему, модель была построена по нотации DFD (Рисунок 15).

Рисунок 15. Модель «как должно быть» процесса «Подготовка документов».

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

Рисунок 16. Внешняя сущность «Ответственный отдел по договору».

Процесс «Предоставление данных» веделен отдельно (не формой потока данных), так как объеденяет в себе данные от внешней сущности «Отдел ответсвенный по договору», который передает данные о ремонтных работах, и от внешней сущности «Подрядчик», который передает персональную информацию (ФИО, наличае удостоверений и т.д) (Рисунок 17).

Рисунок 17. Процессы внесения данных.

Внешняя сущность «Назначенный отдел» принимает данные от процесса «Предоставление данных» и отправляет их в процесс «Внесение данных в базу данных». В процессе «Внесения данных в базу данных» данные приобретают структурированный вид и отправляются на хранение в базу данных (носитель «Данные о подрядчиках»).

Дальнейшие действия происходят в базе данных «Управление подрядчиками». Данные из базы используются в процессе «Анализирование данных пользователя для его допуска/не допуска к проведению работ» (Рисунок 18).

Рисунок 18. Процесс анализа данных.

В процесс «Анализирование данных подрядчика для его допуска/не допуска к проведению работ» поступают запросы-выборки и запросы на обновление данных. Так же из базы данных (носитель «Данные о подрядчиках») поступают необходимые для анализа данные. После выполнения процесса анализа, данные разделяются на два потока – «Данные о работниках прошедших проверку» и «Данные о работниках не прошедших проверку». Эти данные фиксируются в базе данных (носители «Список допущенных подрядчиков» и «Список не допущенный подрядчиков»). Из носителя «Данные о работниках прошедших проверку» данные передаются в процесс «Прохождения вводного инструктажа» в виде «Журнала прохождения вводного инструктажа» (Рисунок 19).

Рисунок 19. Завершение процедуры проверки.

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

Модель бизнес-процесса «Проведения ремонтных работ на предприятии» формата «как должно быть» в полном объеме представлена в приложении 3.

ЗАКЛЮЧЕНИЕ

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

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

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

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

СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ

1. Федеральные нормы и правила в области промышленной безопасности «Правила безопасного ведения газоопасных, огневых и ремонтных работ» [Текст]: ФНП №485 утв.приказом Федеральной службы по экологическому, технологическому и атомному надзору от 20 ноября 2017 г. N 485 // [Электронный ресурс] СПС «КонсультантПлюс». Дата обращения 20.01.2020.
2. Положение о порядке безопасного проведения ремонтных работ на химических, нефтехимических и нефтеперерабатывающих опасных производственных объектах [Текст]: РД 09-250-98 утв. Постановлением Госгортехнадзора РФ от 10.12.1998 N 74: введен в действие с момента утверждения // [Электронный ресурс] СПС «КонсультнтПлюс». Дата обращения 20.01.2020.
3. ГОСТ 7.32-2001 СИБИД. Отчет о научно-исследовательской работе. Структура и правила оформления (с Изменением N 1, с Поправкой) [Текст]: Дата введения 2002-07-01 // [Электронный ресурс] СПС «ТехЭксперт»: URL http://docs.cntd.ru/document/1200026224. Дата обращения 30.01.2020
4. ГОСТ 7.1-2003. Межгосударственный стандарт. Система стандартов по информации, библиотечному и издательскому делу. Библиографическая запись. Библиографическое описание. Общие требования и правила составления [Текст]: Дата введения 2004-07-01 // [Электронный ресурс] СПС «ТехЭксперт»: URL http://docs.cntd.ru/document/1200034383. Дата обращения 30.01.2020.
5. ГОСТ Р 7.0.5-2008 СИБИД. Национальный стандарт Российской Федерации. Система стандартов по информации, библиотечному и издательскому делу. Библиографическая ссылка. Общие требования и правила составления [Текст]: утв. и введен в действие Приказом Ростехрегулирования от 28.04.2008 N 95-ст // [Электронный ресурс] СПС «ТехЭксперт»: URL http://docs.cntd.ru/document/1200063713. Дата обращения 30.01.2020.
6. Файзрахманов Р. А. Структурно функциональный подход к проектированию информационных технологий и автоматизированных систем с использованием CASE-средств. [Текст] / Р. А. Файзрахманов, К. А. Селезнев: Учебное пособие к практическим занятиям // [Электронный ресурс] Перм. гос. техн. ун-т – Пермь, 2005. – 245 с
7. Анализ современных средств моделирования бизнес-процессов [Текст] // [Электронный ресурс] Реинжиниринг бизнес-процессов. URL: http://www.reengine.ru/index.asp?Menu=2&Sub=2. Дата обращения 28.01.2020

ПРИЛОЖЕНИЕ 1. Модель бизнес-процесса «как есть»

ПРИЛОЖЕНИЕ 2. Логическая схема базы данных

ПРИЛОЖЕНИЕ 3. Модель бизнес-процесса «как должно быть»