Учредитель журнала

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

УДК 004.9, 658.5

DOI 10.52815/0204-3653_2022_56189190_40
EDN: CIWMTI

Сунцов Валерий
Магистрант кафедры микропроцессорных средств автоматизации,
Пермский национальный исследовательский политехнический университет.
e-mail: SuntsovVP@rambler.ru

Мыльников Леонид
Доцент кафедры Микропроцессорных средств автоматизации, к. т. н.,
Пермский национальный исследовательский политехнический университет.
e-mail: Leonid.Mylnikov@pstu.ru

Разработка документации для строительства является сложным процессом, подразумевающим совместную работу множества сотрудников, относящихся к разным подразделениям, а также разным организациям (исполнители и заказчики). Информационные процессы, в этом случае, связаны с передачей данных между участниками проекта (технические параметры, справочная информация, информация о согласованных решениях и т. д.). Необходимость держать в голове или обновлять данные о ходе проекта при одновременной реализации множества проектов существенно увеличивает время, необходимое для внесения изменений и дополнений. Это особенно сложно, когда согласование с заказчиком осуществляется только в конце реализации проекта (после прохождения многочисленных внутренних этапов).
Проектные организации функционируют в условиях динамики внешней и внутренних сред. Параметры внешней среды и характеристики проектов являются сложно измеримыми и содержат ошибку. С. Сэвидж считает, что такие системы стоит рассматривать как стохастические [1]. Повышение эффективности организационной системы в таких условиях возможно при переходе от классических методологий управления к гибким [2], что дает возможность перехода к согласованию промежуточных результатов с заказчиком и пошаговой сдаче работ. Такие изменения с одной стороны сокращают время, необходимое для ознакомления с реализованными и требующими изменения частями проекта, а с другой стороны, влекут за собой перестроение информационных процессов, протекающих в организационной системе [3]. Кроме этого, использование гибкой методологии хорошо согласуется с теорией рационального поведения Г. Саймона, которая объяснила разницу между принимаемыми крупными корпорациями решениями и рекомендациями, вырабатываемыми на основе теорий рационального поведения [4].
Для внесения изменений в организацию информационных процессов широкое распространение получила методология BPR, которая заключается в переосмыслении и переделке бизнес-­процессов для достижения значительного улучшения показателей эффективности, таких как стоимость, качество, обслуживание и скорость [5]. Её использование представляет собой итерационный процесс: проведение AS-IS и TO-BE анализа процесса компании (шаг 1), генерация нового решения (шаг 2), тестирование в пилотной среде перед окончательным внедрением (шаг 3). При этом большее число более коротких этапов и их согласований приведет к появлению большего числа «следов», что открывает возможности для последующей реконструкции процессов и исследования их на соответствие заданному образцу [6]. Существуют и неудачные примеры использования управления информационными процессами, связанные с ошибками или отсутствием стратегического видения [7].
Рассмотрим бизнес-­процесс разработки строительной документации на примере небольшой проектной организации в сфере электроснабжения и автоматизации производственных объектов (см. рис. 1).

Рис. 1. BPMN-модель рассматриваемого процесса до внесения изменений

В приведенном процессе можно выделить несколько этапов – принятие проекта в работу, сбор исходных данных, принятие инженерных решений согласно техническому заданию, оформление итоговой документации и выдача её заказчику. Результаты, полученные на этапе принятия инженерных решений, проектировщику необходимо согласовывать с руководителем проекта, отвечающим за его реализацию в организации-­исполнителе, а итоговую документацию – как с руководителем проекта внутри организации, так и с заказчиком. Рассматриваемый этап проектирования соответствует модели управления «водопад», которая подразумевает последовательный переход от этапа к этапу и не предполагает возвратов и доработок при выявлении недостатков. Таким образом в рамках этапа нарушается основные принципы управления заложенные Г. Файолем и У. Г. Шухартом (функции менеджмента, циклы PDSA (Plan-­Do-­Study-­Act) и PDCA (Plan-­Do-­Сheck-­Act) [2]. Учитывая этапы и работы, которые выполняются при разработке проектной документации (см. таблицу 1) становиться очевидным, что многие работы требуют согласования с заказчиком, а ошибки на этапах проекта могут приводить к повторению полного цикла проектирования.

Таблица 1. Этапы реализации проектов и сопоставляемые им работы и применяемые методы

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

Рис. 2. BPMN-модель предлагаемых изменений в рассматриваемый процесс

Предложенный подход согласуется с методологией AGILE/SCURUM, оказывающей преимущества при неоднозначных требованиях к итоговому результату [8].
Преобразование BPML-моделей в сеть Петри [9] показывает, что процесс подготовки документации распадается на три последовательных контура (см. выделенные цветом взаимосвязанные состояния и переходы на рис. 3 и 4).

Рис. 3. Сеть Петри, соответствующая процессу организации работ по подготовке документации до внесения изменений
Рис. 4. Сеть Петри, соответствующая процессу организации работ по подготовке документации после внесения изменений

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

Таблица 2. Анализ потребностей во временном ресурсе в минутах на 40‑часовую рабочую неделю (программа WoPeD)

При этом время ожидания обслуживания при необходимом количестве персонала сокращается с ~223 единиц до временных 197 единиц по данным моделирования в системе WoPeD.
Внесение изменений в организацию информационных процессов влияет на их взаимодействие с другими процессами, протекающими в организации, механизмы использования информационных систем и других ресурсов.
Работа процесса характеризуется последовательностью состояний и переходов, которые были достигнуты или использованы. Чем короче пройденный путь, тем эффективнее была проделана работа. Зная параметры, которые характеризуют проект (количество затрагиваемых разделов (ПЗ, АК, ИОС, ЭЭ и т. д.), количество материалов в текстовой и графической формах и (или) в форме информационной модели, количество закладываемого проектом оборудования, необходимость демонтажа существующего оборудования и систем, а также наличие или отсутствие документов, описывающих объект: графическое представление существующих электрических схем, планов расположения оборудования, затрагиваемых проектом узлов) можно установить взаимосвязь между ними и эффективностью реализации проекта. Таким образом могут быть определены специализация проектов, с которыми организационная система справляется наилучшим образом, и проекты реализация которых требует особого внимания или изменений в системе.
Реализация проекта невозможна без использования информационной поддержки и оценки качества работы. Тогда порядок взаимодействия рассматриваемого процесса с окружением может быть представлен схемой приведенной на рис. 5.

Рис. 5. Схема взаимодействия процесса с его окружением в нотации ArchiMate [10]

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

Исследование выполнено при финансовой поддержке правительства Пермского края в рамках научного проекта № С‑26/692.