Развитие системы электронного документооборота на базе Lotsia PDM Plus в ООО «ТюменНИИгипрогаз»

Андрей Эльзессер
Начальник отдела АСУ, ООО «ТюменНИИгипрогаз»

В результате работы любой крупной компании генерируется огромное количество документов, в особенности если продукция носит интеллектуальный характер — например проектная документация, отчеты о научно­исследовательских работах, и ООО «ТюменНИИгипрогаз» здесь не является исключением. К собственно проектной и научной продукции добавляются организационно­распорядительные документы, конкурсная и договорная документация, документы ряда вспомогательных бизнес­процессов. Для организации упорядоченного хранения документов и упрощения работы с документацией в 2002 году в компании была внедрена Автоматизированная система управления проектными данными (далее — АСУ ПД), которая затем, по мере масштабирования на новые направления и бизнес­процессы, трансформировалась в АСУ производственной деятельностью. Об основных задачах АСУ ПД, истории ее построения и внедрения было рассказано в нашей публикации в журнале «САПР и графика» № 12'2012.

Сейчас АСУ ПД, построенная на платформе Lotsia PDM Plus 5.10 (разработка российской компании «Лоция Софт»), является центральным элементом информационной системы предприятия, выступая связующим звеном между рядом других информационных систем. В АСУ ПД реализованы основные процессы всего жизненного цикла проектов обустройства месторождений и научных исследований: участие в конкурсных процедурах на право выполнения работ, проведение тендеров для привлечения субподрядных организаций, оформление и заключение договоров, согласование планов­графиков выполнения работ, ведение электронного архива проектной документации, контроль работ по обмену заданиями и согласованию готовой документации, переписка по проектам и т.д. Реализация этих блоков в рамках единой системы позволяет легко организовывать связи между ними и упрощает работу пользователей, которым не нужно переключаться между разными системами. Например, в дереве проекта обустройства можно просмотреть корреспонденцию, относящуюся к этому проекту, а от договора на обустройство перейти к конкурсу, по итогам которого этот договор был заключен. Система содержит множество данных, которые могут быть представлены в отчетах различных форм, процессы согласования документов описаны и стандартизованы, за счет средств разработки шаблонов работ обеспечивается повторяемость процессов. Но жизнь не стоит на месте — меняется внешняя среда, изменяется сама организация, добавляются новые задачи и процессы, пересматриваются и оптимизируются уже существующие. Эти изменения необходимо отражать в настройках системы, чтобы она поддерживала новые реалии и оставалась рабочим инструментом. Описанию некоторых таких нововведений и посвящена данная статья.

Одной из подсистем АСУ ПД является АСУ документационного обеспечения управления (далее — АСУ ДОУ). В рамках АСУ ДОУ реализована регистрация основных типов документов (входящих и исходящих писем, приказов, распоряжений, служебных записок), ведение архива документов с возможностью поиска и привязки входящих и исходящих писем к конкретному проекту, пересылка документов с резолюциями и на ознакомление. Процессы пересылки документов были автоматизированы несколько лет назад, и тогда же в систему был заложен принцип единоначалия — сотрудник мог передать письмо с резолюцией только своему непосредственному подчиненному. Сделано это было сознательно, чтобы не нарушать вертикаль управления. Генеральный директор мог передать письмо одному из своих заместителей, заместители генерального директора — другому заместителю или одному из подчиненных начальников отдела и т.д.

Однако практика довольно быстро показала несостоятельность подобного подхода — заместители генерального директора передавали письмо начальнику отдела, подчиняющегося другому заместителю, или главному специалисту одного из своих отделов, в обход начальника этого отдела. В системе повторить такое было невозможно из­за искусственных ограничений, но заместители директора, конечно, от этого не изменили своих привычек — вся нагрузка легла на их секретарей, которые вводили резолюции в АСУ ДОУ. Им приходилось выбирать заместителя директора, которому подчинялся адресат, и в резолюции указывать комментарий «для Иванова И.И.». Для наиболее часто встречающихся случаев были предусмотрены списки­исключения, из которых пользователи могли выбрать сотрудников, напрямую им не подчиняющихся. Эти списки наполнялись группой внедрения АСУ ПД по просьбам пользователей, что не добавляло оперативности всему процессу. Более того, для разных уровней сотрудников (заместители директора, ГИПы, начальники отделов) были предусмотрены свои списки возможных адресатов (опять же — для выполнения принципа единоначалия), что только усложняло сопровождение.

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

Рис. 1. Интерфейс ввода резолюций и выбора адресатов

Шаблон документооборота, используемый для обработки входящих писем, был расширен для работы с новыми типами документов — приказами и служебными записками. Ранее для этих документов были разработаны свои типы и формы объектов, так как у каждого из них есть своя специфика при регистрации, а для пересылки приказов был разработан свой шаблон документооборота, в рамках которого можно было отправить приказ на ознакомление выбранным сотрудникам. Однако в некоторых случаях простого ознакомления было недостаточно — нужно было фиксировать поручения по приказу и контролировать их выполнение. Вместо добавления блоков формирования и контроля поручений в отдельный шаблон было решено использовать уже отлаженный функционал обработки входящих писем. Впоследствии на этот шаблон были переведены и служебные записки. Единообразие в процедурах выдачи поручений по документам разного типа позволило привести к одному виду и процедуру контроля этих поручений — разработан отчет «Документы на контроле», состоящий из двух блоков: «документы ДЛЯ меня» и «документы ОТ меня», в каждом из которых возможна группировка по типам документов. Этот отчет формируется при запуске АСУ ПД (но не более раза в сутки) и информирует пользователя, поручения по каким документам он не выполнил и какие поручения требуют его контроля.

Применение одного шаблона для обработки трех различных типов документов стало возможным благодаря тому, что шаблон представляет собой лишь часть процесса обработки документа и описывает взаимодействие только между двумя пользователями: руководителем и исполнителем. Шаблон включает получение документа исполнителем (или его секретарем, если таковой имеется), обработку документа, отчет о выполнении поручения и согласование этого отчета (рис. 2). Полный процесс обработки документа складывается из нескольких таких частей, их количество заранее неизвестно и неограниченно. Если исполнителю (которым может оказаться начальник отдела, если в роли руководителя был заместитель генерального директора по направлению или ГИП) требуется передать документ своим подчиненным, он формирует массив резолюций и исполнителей (например, главных специалистов), после чего для каждого исполнителя посредством внешней работы запускается новая копия этого же шаблона. В новой копии начальник отдела становится руководителем, а главный специалист — исполнителем, и процесс может повториться на новом уровне. История пересылки в системе сохраняется, что, в сочетании с фиксацией собственно поручений и отчетов об их выполнении, позволяет восстановить общую картину обработки конкретного письма даже спустя продолжительное время.

Рис. 2. Шаблон документооборота для обработки входящих писем, приказов и служебных записок

Другой подсистемой АСУ ПД, гораздо более обширной по сравнению с АСУ ДОУ, является АСУ проектно­изыскательскими работами (далее — АСУ ПИР). В ней реализованы специфические для проектного направления процессы и процедуры (согласование плана­графика, выдача заданий смежным подразделениям, сдача готовой документации и ряд других), функционирует электронный архив исходных данных по проектам, заданий смежным подразделениям, комплектов готовой документации в формате САПР­приложений, а с недавнего времени — и в формате скан­копий подлинников. Однако для планирования проектных работ применяется специализированное средство — Корпоративная система управления проектами (далее — КСУП), построенная на основе MS Project Server. В КСУП разрабатываются планы­графики производства проектных работ, в которых планируются сроки обмена заданиями и сдачи готовой документации, в ней же реализован мониторинг загрузки производственных подразделений. Очевидно, что от качества составления планов­графиков зависит как успешное выполнение проектных работ, так и адекватный мониторинг загрузки. Чтобы формирование планов­графиков не занимало у ГИПов слишком много времени, в компании разрабатываются шаблоны планов­графиков для различных объектов проектирования — цехов, емкостей различного назначения, зданий и сооружений. В каждом шаблоне определяется перечень и последовательность задач, выполнение которых необходимо для проектирования объекта конкретного типа, указываются их взаимосвязи и базовая продолжительность.

Структура плана­графика в КСУП должна повторять структуру комплекса проектирования, которую ГИП определяет в АСУ ПИР. Для соблюдения принципа единовременного ввода информации и сокращения времени на создание плана­графика разработан механизм, позволяющий нажатием буквально пары кнопок загрузить структуру дерева проектов из АСУ ПИР в КСУП. Отчет в Lotsia PDM формирует Excel­файл со структурой проекта, затем при запуске MS Project срабатывает макрос, который на основе Excel­файла формирует структуру проекта. С помощью другого макроса на основе существующих шаблонов происходит наполнение объектов проектирования конкретными задачами, с сохранением последовательности задач и их взаимосвязей. Таким образом, формирование первой версии плана­графика занимает минимум времени, а сам план­график учитывает «лучшие практики» планирования, описанные в шаблонах.

В 2013 году был завершен перевод КСУП на новую версию MS Project Server 2013. Это позволило построить на базе КСУП удобную систему учета трудозатрат — предыдущая, 2007­я версия, обладала не самым удобным интерфейсом для ввода трудозатрат по задачам. Была сохранена интеграция АСУ ПИР и КСУП — плановые даты из КСУП в полуавтоматическом режиме передаются в АСУ ПИР, а фактические сроки выполнения задач, генерируемые в АСУ ПИР в ходе выполнения процессов выдачи заданий и сдачи документации, передаются в КСУП без привлечения пользователей, с помощью функционала сервера автоматических этапов. Таким образом, планы­графики в КСУП всегда актуализированы с учетом фактических данных.

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

Для решения этой задачи в Visual Studio был разработан программный модуль, использующий встроенный в MS Project Server механизм делегирования задач. В удобном интерфейсе можно выбрать задачи из плана­графика (свои или одного из подчиненных сотрудников) и переназначить их другому подчиненному сотруднику (или сразу нескольким). С добавлением необходимости делегирования задач изменился процесс ознакомления с утвержденным планом­графиком, реализованный в виде шаблона документооборота в АСУ ПД. Если раньше пользователи, получив план­график на ознакомление, могли только перейти на страницу с графиком и переслать его своим подчиненным, то сейчас они должны делегировать свои задачи. Из формы задачи (имеется в виду уже не задача из Project Server, а задача документооборота в терминологии АСУ ПД) вызывается модуль Делегирование, в котором пользователь переопределяет исполнителей на полученные задачи плана­графика (рис. 3). После завершения работы с модулем список выбранных исполнителей автоматически возвращается в АСУ ПД и производится пересылка плана­графика выбранным адресатам. Они, в свою очередь, получают аналогичную задачу документооборота и обрабатывают ее — делегируют задачи плана­графика своим подчиненным сотрудникам либо оставляют их у себя, если являются конечными исполнителями. Как следствие — процесс делегирования стал более прозрачным, а значит, можно проследить, кому из пользователей были делегированы задачи и на ком остановился процесс.

Рис. 3. Интерфейс задачи процесса делегирования и выбора исполнителей

Функционал экспорта данных из АСУ ПД в формат Excel, описанный выше, серьезно расширяет возможности Lotsia PDM Plus. С его помощью можно преобразовать разнообразные данные системы в обычный файл Excel, оформленный по требованиям пользователей. Затем этот файл можно использовать в своей работе, передать в контролирующие подразделения или организации. Пользователи, активно работающие с Excel, одним из первых пожеланий упоминают как раз выгрузку отчетов в привычный для них формат. Эта возможность упрощает и сопровождение системы документооборота. Имея excel­файл с необходимыми данными, пользователи могут преобразовать его под свои потребности, изменить оформление, добавить формулы, убрать лишние колонки, и все это — самостоятельно, без привлечения ИТ­специалистов. Однако практика показала, что у этой медали есть оборотная сторона. Определенные риски возникают тогда, когда сгенерированный из Lotsia PDM файл начинает использоваться несколькими пользователями для коллективной работы.

Одним из примеров неоправданного применения функции экспорта в Excel является процедура сбора данных от нескольких пользователей, сформировавшаяся при обработке заданий и комплектов в АСУ ПИР. У каждого из этих объектов есть плановая дата выдачи, полученная из КСУП. Естественно, проектировщики прилагают все усилия, чтобы выполнить задачу в установленный срок, но, в силу разных причин, это не всегда удается. Для мониторинга срывов плановых дат в АСУ ПД был разработан отчет «Справка о реализации плана­графика», в который попадают все сорванные задания и комплекты. Это позволяет руководству видеть, где возникают проблемы, и оперативно принимать корректирующие меры. В процессе работы с этой справкой возникла процедура указания проектировщиками причин невыполнения той или иной задачи, которые доводились до руководства направления перед каждой планеркой. Причины указывались в привычном и удобном для пользователей виде — в Excel­файле, сгенерированном из справки. Само по себе это не вызывало никаких проблем. Проблема была в том, что в заполнении справки участвует несколько уровней пользователей (начальник отдела — главный специалист — руководитель группы), при передаче на каждый уровень файл копировался, а затем, уже заполненный, возвращался обратно ответственным сотрудникам, которым из 15­20 файлов необходимо было сформировать один, для рассмотрения на планерке. Ситуация усугублялась тем, что строки с причинами срывов от одного отдела нельзя было просто добавить в конец общего файла — задания и комплекты в справке сгруппированы по ГИПам, шифрам и объектам проектирования. Эти операции нужно было повторить для каждого отдела. Неудивительно, что формирование итогового файла порой занимало по нескольку часов и ответственным сотрудникам приходилось даже задерживаться на работе. Помимо чрезмерной траты времени сам по себе результат этой работы после завершения планерки оказывался практически ненужным. К следующей планерке, уже через неделю, готовилась новая справка, и все повторялось. Проследить историю конкретного задания или комплекта в течение нескольких планерок было практически нереально — нужно было просмотреть несколько файлов, а они были достаточно объемными.

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

Еще одним потенциальным источником проблем может оказаться экспорт в Excel и дальнейшее добавление недостающих данных в файл. К примеру, у сотрудников Бюро ГИПов была необходимость работать со списком договоров и этапов, оформленным в виде плана работ направления на год. Этот отчет содержит основные данные о договорах и этапах (названия, стоимости, сроки выполнения) — все эти данные вносят сотрудники Сметно­договорного отдела (СДО). Однако этих данных было недостаточно для решения стоящих перед Бюро ГИПов задач. Существовал еще ряд параметров договоров и этапов, которые необходимо было учитывать, но эти параметры были совершенно неважны для СДО. В итоге отчет с основными параметрами выгружался в Excel, где для существующих этапов добавлялись необходимые данные. Но список договоров и этапов меняется в процессе работы, и эти изменения необходимо учитывать в Бюро ГИПов. Было найдено два варианта: первый — периодически выгружать в Excel новую версию оригинального отчета и дописывать в нее собственные данные, а второй — брать за основу свой файл с собственными данными и дописывать в него общие данные о договорах, появившихся с момента последней актуализации. Естественно, по прошествии некоторого времени оба варианта стали приводить к серьезным затратам времени и сил — всё больший объем данных приходилось синхронизировать вручную.            Решение этой проблемы было уже очевидным. В договоры и этапы были добавлены атрибуты для собственных данных Бюро ГИПов, настроена видимость атрибутов на формах. На основе первоначального отчета был разработан другой, который отображает как основные атрибуты, внесенные СДО, так и уникальные атрибуты Бюро ГИПов. При добавлении нового договора или этапа он автоматически появляется в новом отчете и сотрудники Бюро ГИПов дополняют его своими атрибутами. Таким образом, обеспечивается принцип единовременного ввода данных.

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

САПР и графика 4`2014