Файл: Разработка регламента выполнения процесса «Управление документооборотом» (Модернизация бизнес-процессов).pdf
Добавлен: 24.04.2023
Просмотров: 176
Скачиваний: 1
Рисунок 3. Процесс «Заключение договора».
В данном процессе определяется компания, которая будет проводить необходимые работы и ответственное лицо организации, выраженное определенным отделом или подразделением, которое будет отслеживать выполнение пунктов договора в течение всех процессов, вплоть до его закрытия (выходной поток «Держатель договора»). Выходными данными этого процесса являются: «Сведения о месте и виде ремонтных работ» и «Сведения об организации», которые отправляются на вход данных следующим процессам, и «Держатель договора», который отправляется на управление всеми последующих процессами, кроме процесса «Закрытие договора», где является механизмом.
В процессе «Подготовка документов» входными данными являются «Сведения об организации» и «Сведения о месте и виде ремонтных работ» (Рисунок 4).
Рисунок 4. Процессы «Подготовка документов» и «Подготовка места к проведению работ».
В процессе «Подготовка документов» осуществляется подготовка подрядчиков к выполнению работ: проверяется наличие документов, подтверждающих квалификацию работников, проводятся инструктажи, и т.д. Механизмами выполнения являются: как сотрудники предприятия, так и подрядной организации. Выходными данными является «Наряд-допуск» – разрешение на проведение работ, которое устанавливает место, время, вид работы, список работников, осуществляющих работы, разработка мероприятий по подготовке и выполнению работ, используемый инструмент и т.д. Поэтому, эти данные являются управляющими в процессе «Проведение работ». Параллельно с этим процессом проводится процесс «Подготовка места к проведению работ». Входные данные – «Сведения о месте и виде ремонтных работ». В данном процессе происходит подготовка объекта к выполнению ремонтных работ. Выполняют работы по подготовке к ремонту в подразделениях предприятия – «Отделы и подразделения предприятия». Результатами процесса являются «Подготовленное место» проведения ремонтных работ и «Акт передачи территории». Результаты этого процесса являются входными данными для процесса «Проведение работ» (Рисунок 5).
Рисунок 5. Процесс «Проведение работ».
В процессе «Проведение работ» непосредственно выполняются ремонтные работы. Работы производятся работниками подрядной организации (механизм «Организация»), определяются нарядом-допуском, выполняется в соответствии с нормативными документами, действующие в РФ и положениями, действующими на территории предприятия, и контролируются держателями договоров (управление «Наряд-допуск», «Законодательство РФ, национальные и межгосударственные стандарты», «Держатель договора»). Выходными данными процесса является «Результат выполненных работ» (фактическое состояние объекта после выполнения ремонта), который отправляется на вход данных процесса «Принятие работ» (Рисунок 6).
Рисунок 6. Процессы «Принятие работ» и «Закрытие договора».
Процесс «Принятие работ» осуществляют сотрудники предприятия (механизм «Отделы и подразделения предприятия»). В этом процессе входные данные анализируются на соответствие фактического состояния объекта заявленным требованиям. Если объект не соответствует, то работа не принимается (выходной поток «Отказ») и происходит возвращение к процессу «Проведение работ». В противном случае, работа считается выполненной, и подтверждающие документы направляются в процесс «Закрытие договора» (выходные потоки «Выполненные работы» и «Акт выполненных работ»). Процесс закрытия договора осуществляют «Организация», «Держатель договора» (отделы производственной области) и «Отделы и подразделения предприятия» (экономические и юридические службы, службы безопасности и т.д.).
После рассмотрения общей схемы проведения ремонтных работ можно рассмотреть схему документального контроля подрядчиков. Для декомпозиции процесса «Подготовка документов» была выбрана нотация IDEF3, так как она способна отобразить логику выполнения процесса и отобразить последовательно выполнения команд (Рисунок 7).
Рисунок 7. Декомпозиция процесса «Подготовка документов» по нотации IDEF3.
В данной схеме рассмотрены процессы работы с каждым работником подрядной организации, который будет осуществлять ремонтные работы (подрядчик). Сначала осуществляется сбор основных сведений от подрядчика (Рисунок 8).
Рисунок 8. Процессы сбора данных.
С внешней ссылки «Данные о подрядчиках» (от подрядчика) поступают данные в процессы «Сбор сведений о прохождении медосмотра», «Сведения о пройденных мероприятиях» и «Сбор сведений о наличии удостоверений». С внешней ссылки «Данные о проводимых работах» (сведения договора) поступают данные в процесс «Сбор сведений о необходимый мероприятиях». Затем выполняется проверка на соответствие полученных данных установленным требованиям. Проверка осуществляется процессами «Определение актуальности срока прохождения медосмотра», «Определение актуальности срока прохождения мероприятия и соответствия вида мероприятия», «Определение соответствия удостоверения виду выполняемой работы (должности)» и «Определение срока действия» (Рисунок 9).
Рисунок 9. Процессы анализа данных.
Перекрестки J2 и J10 имеют тип «Синхронное И», так как после завершения процесса сбора данных об удостоверениях одновременно начинается их проверка на соответствие виду работ и срок действия.
После завершения процессов может быть передано два вида команд (результата) – отрицательная, которая означает несоответствие данных установленным требованиям, и положительная – означающая обратное. После выполнения этих процессов начинается анализ результатов их выполнения.
В перекресток J5 попадают данные о завершении всех процессов с положительным результатом. Вид перекрестка «Асинхронное И», так как требуется завершение всех предшествующих процессов, после которых начинается процесс «Прохождение вводного инструктажа». Данные подрядчиков, прошедших проверку и вводный инструктаж направляются на оформления наряда-допуска. (Рисунок 10).
Рисунок 10. Завершающие процессы.
В перекресток J6 поступают завершенные процессы с отрицательными результатами. Перекресток имеет вид «Асинхронное ИЛИ», так как достаточно завершения хотя бы одного процесса отрицательным результатом, чтобы не допустить подрядчика к проведению работ.
Таким образом, можно видеть, что в процессе «Подготовка документов» данные, необходимые для допуска к работам поступают от подрядчика. Эти данные анализируются, и выводится два возможных результата – или подрядчик не допущен к работам (внешняя ссылка «Отказ в допуске к проведению работ») и происходит проверка следующего, или подрядчик допускается к работам и информация заносится в наряд-допуск (внешняя ссылка «Наряд-допуск»).
Разработанная модель «как есть» бизнес-процесса «Проведение ремонтных работ на предприятии», выполненная в BPwin, приведена в Приложении 1.
Разработанная модель бизнес-процесса позволяет рассмотреть его структуру, выделить и установить связи между этапами его выполнения. Также модель позволят увидеть уязвимости и определить возможности для его улучшения.
2 Модернизация бизнес-процессов
-
-
2.1. Предлагаемые мероприятия по улучшению бизнес-процессов.
-
В рассмотренной модели есть недостатки при осуществлении документальной части контроля подрядчиков. При оформлении наряда-допуска, сотрудникам контролирующих отделов приходится анализировать большое количество данных. Для улучшения модели бизнес-процесса предлагается разработать и внедрить в процесс оформления наряда-допуска реляционную базу данных.
Внедрение базы данных позволит сократить время на анализ актуальности данных, и на формирование данных для их внесения в наряд-допуск. С помощью базы данных, будут формироваться списки работников, относящихся к определенной организации и имеющие все необходимые документы, что ускорит быстродействие и сократит трудовые ресурсы при работе с большим количеством данных. Так же, с помощью базы данных можно будет осуществлять непосредственное обращение к копиям документов, хранимых в электронном виде.
Перед построением улучшенной модели бизнес процесса («как должно быть») необходимо определить, какие данные будут содержаться в базе и как будут реализованы процессы взаимодействия с ней. Для этих целей, с помощью средства Erwin Data Modeler была смоделирована логическая схема базы данных «Управление подрядчиками».
В процессе анализа были выделены три основных области – «Область договора», «Подрядчики» и «Работы». Для каждой из этой области были спроектированы сущности и определены их атрибуты. На схеме ER-модели сущности разделены на две части. В нижней части сущности содержатся простые атрибуты, а в верхней части – первичные и вторичные ключевые поля. Сущности, имеющие только два аргумента – первичный ключ и простой атрибут – называют справочниками, так как чаще всего их используют для получения заранее известных, определенных значений. Для удобства восприятия области на общей схемы обозначены разными цветами (Рисунок 11).
Рисунок 11. Логическая схемы базы данных «Управление подрядчиками».
Первая рассматриваемая область – «Договор». Область является связующий между областями «Работы» и «Подрядчики», так как через нее определяется, какие организации, какие работы будут осуществлять. Область состоит из пяти сущностей: «Держатели договоров», «Организации», «Подразделения» «Договор» и «Ремонтные работы» (Рисунок 12).
Рисунок 12. Схема области «Область договора».
Сущность «Договор» имеет три ключевых атрибута. Первичный ключ «id_Договора» представлен номером договора, так как номер уникален. Два вторичных ключа передают сведения об организации и отделе.
Сущность «Держатели_договоров» связана с сущностью «Договор» и имеет связь вида «один-ко-многим», так как один отдел может держать несколько договоров
Сущность «Организации» связана с сущностью «Договор» и имеет связь вида «один-ко-многим», так как одна организация может заключить несколько договоров.
Сущность «Договор» связана с сущностью «Ремонтные_работы» и имеет связь вида «один-ко-многим», так как по одному договору может осуществляться несколько работ.
Сущность «Ремонтные_работы» выполняет связывающую роль между сущностями «Договор» и сущностью «Подразделение». Кроме того, сущности «Подразделения» и «Ремонтные работы» относятся как к области «Область договора», так и к области «Работы» и являются связывающими звеньями.
В среде ERwin вторичные ключи можно разделить на: прямые и косвенные. Так в сущности «Договор» внешний ключ «Держатель договора id_Отдела (FK)» является прямым, так как имеется атрибут «Держатель договора», содержащий первичный ключ «id_Отдела», принадлежащий сущности «Держатели_договоров», а в сущности «Ремонтные_работы» внешний ключ «id_Отдела» является косвенным, так как в сущности нет атрибута, содержащего данных этого ключа. Однако сущности «Ремонтные_работы» и «Держатели договоров» связаны между сбой посредством сущности «Договор». Именно эту связь и отображает косвенный внешний ключ в сущности «Ремонтные_работы».
Сущности «Подразделения» и «Ремонтные_работы» имеют связь «один-ко-многим» - в одном подразделении могут проводиться несколько работ.
Атрибуты сущностей-списков имеют числовой тип данных для уникального идентификатора, и текстовый тип данных для описания (атрибут «Наименование»).
Атрибуты сущностей «Держатели_договора» и «Ремонтные_работы» имеют числовой тип данных, так как состоят из первичного и вторичных ключей.
Следующая рассматриваемая область «Работы». В этой области определяется вид работ и место их проведения. Также виды работ подразумевают наличие определенной квалификации от исполнителей. Область состоит из сущностей: «Подразделения», «Ремонтные_работы», «Виды_работ» и «Мероприятия» (Рисунок 13).
Рисунок 13. Схема области «Работы».
Область содержит те же сущности «Ремонтные_работ» и «Подразделения», но здесь они имеют другой смысл. Если «Область договора» использовала их для определения зависимости между держателями договоров, организациями и местом проведения работ, то в данной области определяется место проведения и характер выполняемых работ.