Управление процессом экспертизы промбезопасности

Процесс экспертизы

ООО «Аттестационный научно-технический центр Зевс»

Мишин А.Ю. mishin@an-tc.ru

 

Управление процессом экспертизы.

Часть I. Создание информационной системы – база данных для процесса экспертизы.

 

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

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

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

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

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

Каждый отдел отвечает за  свой этап. Всю работу обобщает  и контролирует ведущий отдел. Он определяет  темп, собирает данные и осуществляет общий контроль,  непосредственно формирует заключения ЭПБ – основной продукт деятельности экспертной организации.

Чтобы весь процесс протекал эффективно у высшего руководства стоит непростая задача: следить за работой всей цепочки, выявлять слабые места, подгонять отстающих, в общем, делать все, чтобы выпуск конечного продукта (заключение ЭПБ) шел в  нужном темпе. Необходимо следить, чтобы в самом процессе не было сбоев, вовремя выявлять и решать возникшие проблемы.

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

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

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

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

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

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

Как правило, такие базы содержат несколько информационных блоков:

– Идентификация объекта экспертизы (название объекта; зав. №; рег. №; предприятие Заказчик и т.д.)

– Процесс экспертизы (зачистка объекта для ЭПБ; проведение технического  диагностирования, проведение ГИ, оформление протоколов НК, проведение прочностных расчетов, проверка и подпись экспертом, сдача заключения ЭПБ в переплет, внесение в реестр и т.д.)

– Финансовый блок (номер договора, стоимость экспертизы за конкретную единицу тех.устройства, подпись актов выполненных работ, поступление денег на счет и т.д.).

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

 

Таблица № 1

Объект

Экспертизы

Рег. № Заказчик Зачистка под ЭПБ Техническое диагностирование Расчет

На прочность

ГИ Эксперт Внесено в реестр Подписаны акты

выполненных работ

Сосуд Е-1 зав. № 24 14256 ООО

«Титан»

20.04.16 28.04.16 28.05 29.05 Иванов 28.06 30.07
Котел ДКВР

Зав. № 123

1134 ООО

«Энерго»

15.04.16 25.04.16 06.06 Петров
Резервуар

РВС-1000

Зав. №-

35 Склад ГСМ№ 38 10.04. 16 Сидоров

 

Примерно такую информационную систему по процессу экспертизы в 2012-2013 году вела одна крупная экспертная организация, в которой я работал на тот момент.

Чтобы понять насколько рассматриваемая нами  «типичная база данных» эффективна и работоспособна, проведем небольшой анализ.

Примерно понятно, что на один листок формата А4 может поместиться 30-40 объектов экспертизы (строчек).

В конце 2012 года в работе  у экспертной организации  находилось около 4500 объектов экспертизы. Соответственно, база данных состояла более чем из 100 страниц формата А4. Это привело к тому, что все оборудование образовало единую, трудноразделимую  массу.

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

Для того, чтобы эффективно справиться с большим объемом работы необходимо понимать  насколько качественно работают отделы, какие отделы отстают.

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

Самое большое количество оборудования, более половины, это «сосуды, работающие под давлением». По этому  виду оборудования  работало 4 отдела. По трубопроводам – 3 отдела.

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

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

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

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

Еще один  фильтр  – разделение работ по Заказчикам. Этот фильтр позволяет работать  только с маленьким объемом  информации, т.к. 90 % общего объема приходилось на одного крупного Заказчика.

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

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

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

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

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

Опять же,  программно в базу не был заложен финансовый блок (номер договора, стоимость единицы оборудования).

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

Итог получился парадоксальный. «Типичная база данных» оказалась нерабочей. Значит, есть какой-то секрет. Видимо, не были созданы какие-то механизмы, которые должны привести к нужному результату.

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

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

Для этого рассмотрим спектр пользователей. База данных процесса экспертизы создается для управления. Значит, ею пользуются только руководители.

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

Руководители 3-го уровня.

По должности это бригадиры или руководители секторов (эксперты). Они в подчинении имеют бригаду из нескольких человек и   непосредственно отвечают за сам процесс обследования (технического диагностирования) и формирование заключений ЭПБ.

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

Попробуем сформулировать задачи и особенности руководителей 3-го уровня.

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

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

Руководители 2-г уровня.

Руководители 2-го уровня  – это начальники отделов. Начальники отделов имеют в подчинении достаточное количество людей, которые делятся в свою очередь на бригады (сектора). Руководители это уровня   распределяют работу между секторами (бригадами) и отслеживают деятельность каждого сектора.

Начальнику отдела нет необходимости знать состояние дел по каждой единице оборудования. Его интересует суммарная деятельность всего отдела (всех секторов отдела). Для этого начальнику отдела необходимо иметь аналитические данные (сумма оборудования за единицу времени прошедшее обследование, количество подготовленных за единицу времени заключений ЭПБ). Кроме того,  руководители среднего уровня, как правило, отвечают за выполнение финансовых задач, поставленных перед отделом. Поэтому аналитические данные по деятельности отдела  необходимо перевести в денежные показатели. Кроме того, необходимо проводить планирование на ближайшую и дальнейшую перспективу.

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

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

Руководители 1-го уровня.

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

Для руководителей 1-го уровня необходимо иметь данные по результативности деятельности всех вместе взятых отделов (и каждого конкретно), конечные результаты деятельности (подготовленные заключения ЭПБ, а как следствие, полученные деньги).

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

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

Руководители 1-го уровня должны иметь перед глазами реальную картину по деятельности всех отделов. Это обобщенный  взгляд на весь процесс экспертизы.

Подведем итог.

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

Для этого необходимо создавать многоуровневую систему.

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

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

схема базы данных, таблицы данных, схема
Нет комментариев

Оставить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

*

СВЯЖИТЕСЬ С НАМИ

Оставьте Ваше сообщение...

Отправка

©2020 Аттестационный научно-технический центр ЗЕВС. Экспертиза промышленной безопасности.Иркутск.

Войдите со своими учетными данными

Забыли свои данные?