Выбирая тему для второй статьи, мы хотели представить арсенал современной TDMS с разных сторон. В рамках одного материала рассказать об улучшениях в «толстом» клиенте, о новых возможностях сервера приложений и веб-клиента и, конечно, о программных интерфейсах. И тема нашлась, да еще какая.
Напомним, что, начиная с пятой версии TDMS, у нас появился сервер приложений, который в недавно вышедшей седьмой версии системы получил новое развитие. Благодаря серверу приложений наши заказчики располагают не только современным инструментом бесшовной интеграции системы управления проектным производством в корпоративную информационную среду, но и совершенно новыми возможностями взаимодействия с внешним миром.
В зависимости от информационного контура, в котором располагается сервер приложений системы, он может использоваться как в целях организации внутреннего стека сервисов и межпрограммных интерфейсов, так и для применения модулей, управляющих подключением к системе внешних пользователей и сервисов.
Одной из подсистем, размещаемых во внешнем контуре системы, может быть модуль управления техническим документооборотом с субподрядными организациями. Модуль предназначен для автоматизации взаимодействия генпроектировщика и субподрядных организаций в рамках выполнения работ по совместным проектам.
Проблема повышения эффективности взаимодействия с подрядчиками стоит не только перед крупными организациями, у которых их количество по каждому из проектов может исчисляться десятками, а иногда доходить и до нескольких сотен постоянных партнеров. Даже средние проектные организации, ведущие несколько проектов одновременно, вынуждены прибегать к услугам других компаний как в целях оптимизации собственных затрат на выполнение некоторых видов работ, так и в случае отсутствия возможности выполнения определенных видов проектной деятельности, например, при отсутствии соответствующей лицензии или необходимого уровня квалификации у собственных специалистов.
Для организаций, которые сами часто выступают субподрядчиками, этот модуль может быть интересен как с точки зрения начала общего перехода на электронный технический документооборот, так и для решения частных задач — уменьшения количества ошибок и сокращения трудозатрат при оформлении документов и передаче данных заказчику, автоматизации процедур согласования и внесения изменений, реализации других положительных сторон применения единой с заказчиком информационной системы.
Со стороны пользователя основной системы взаимодействие выглядит так, как будто субподрядчик работает непосредственно в вашей системе. Вы видите его в списке пользователей, можете средствами TDMS отправить ему письмо или быстрое сообщение, видите результаты его работ — загруженные им документы, ответы на ваши замечания, внесенные по результатам обработки замечаний изменения
Но в целях обеспечения информационной безопасности все субподрядчики работают не просто в другой системе, они физически отделены от системы генерального проектировщика. Как это сделано?
Напомним, что рабочее место пользователя на платформе TDMS чаще всего реализуется в виде полнофункционального приложения, работающего в среде Windows. Большинству пользователей системы привычнее работать в TDMS в «толстом» клиенте, особенно с учетом того, что все приложения для редактирования файлов — например, подавляющее число систем автоматизированного проектирования (САПР) — также являются полнофункциональными приложениями вышеуказанной операционной системы. Для обеспечения взаимодействия с внешними и внутренними модулями и приложениями нам потребуется сервер приложений, размещенный в информационном контуре предприятия. Назовем его просто «сервер TDMS».
Однако систему, в которой будет работать субподрядчик, гораздо логичнее сделать платформонезависимой, что лучше всего реализуется с применением стека таких программных продуктов, как ОС Linux и СУБД Postgres, и подключением пользователей через веб-доступ. Для обеспечения работы такой системы нам потребуется еще один сервер приложений TDMS и специальная область информационного пространства предприятия, в которую разрешен внешний доступ по протоколам HTTP/HTTPS. Эта область называется «демилитаризованной зоной» (ДМЗ). Сервер субподрядной организации, размещенный в ДМЗ, назовем «сервер СПО».
Синхронизация данных между серверами приложений работает только в одностороннем порядке — от сервера TDMS к серверу СПО. К серверу СПО также имеется доступ через интернет, как это показано на рис. 2.
Синхронизация данных между серверами приложений предполагает передачу данных в объеме, необходимом исключительно для выполнения функциональных задач в рамках обмена данными между различными участниками проекта. Например, субподрядная организация получает только тот объем документов и структурных элементов системы, которые особым образом помечены как исходные данные для разработки субподрядной документации по проекту. В рамках одного сервера приложений/сервера БД различные организации видят только те данные, которые относятся непосредственно к их работе.
Как и при обычной работе, связанной с разработкой проектной продукции, в деятельности субподрядчика существует несколько отображенных на рис. 3 взаимоувязанных процессов, реализующих обеспечение специалистов исходными данными, постановку задачи, согласованной с другими проектными специальностями, организацию контроля хода выполнения работ и проверки загруженной документации.
Театр начинается с вешалки, а проектирование — со сбора исходных данных и составления плана работ. Еще до выдачи первого задания на проектирование должна быть сформирована структура проекта и определены объемы проектно-изыскательских работ (ПИР). На основе понимания общей картины руководитель проекта может принять решение о привлечении соисполнителей.
Создание томов или комплектов, передаваемых на субподряд, осуществляется руководителем проекта (как правило, главным инженером проектов — ГИПом) в рамках основного процесса создания сводной ведомости основных комплектов (СВОК) на рабочей стадии проектирования или формирования структуры разделов проекта на проектной стадии. По сути этот процесс ничем не отличается от создания структуры документации, разрабатываемой силами своей организации.
Для привлечения субподрядчика средствами TDMS ГИПу достаточно заполнить соответствующие атрибуты в карточке документа (или, например, целого раздела, и тогда эти свойства унаследуются всеми входящими в него документами). Такими атрибутами являются наименование контрагента и ссылка на заключенный с ним договор.
Сразу оговоримся, что наш модуль пока не обладает возможностями управления договорами и проведением конкурентных закупок, что в принципе от него и не требуется, так как обычно на предприятии эти вопросы возложены на другие информационные системы. Но определение перечня работ, передаваемых на субподряд, и предварительный расчет их трудоемкости, конечно, выполняются в TDMS.
Вся документация, создаваемая в TDMS, имеет атрибуты плановых и фактических дат начала и завершения работ, а также плановой и фактической трудоемкости. Эти же атрибуты заполняются при планировании субподрядных работ. Фактическую трудоемкость субподрядного проекта мы вряд ли сможем узнать, но плановая трудоемкость является отправной точкой для расчета себестоимости. Она может быть получена эмпирическим путем — например, на основе аналогичных работ, выполненных ранее без привлечения субподряда, или путем сравнения данных конкурентных закупок.
Благодаря обмену данными с системой управления ресурсами предприятия обновление свойств субподрядных организаций и заключенных с ними договоров может быть полностью автоматизировано. Если интеграция отсутствует, функцию ведения данных подрядчиков, как правило, передают в группу управления проектами (бюро ГИП).
На основе уже известного перечня работ ГИП формирует задание на проектирование для субподрядной организации. В составе задания могут быть размещены различные документы, включая части проекта, выполняемые силами генпроектировщика, если это требуется для полноты исходных данных.
После загрузки исходных данных и определения списка томов/комплектов, передаваемых на субподряд, ГИП публикует задание. Карточка задания для субподрядной организации представлена на рис. 4.
После публикации задания сервер TDMS готовит и передает пакет данных, содержащий сведения по передаваемому заданию, исходные данные в виде файлов и ссылки на тома и комплекты с любого уровня иерархии проектных (объектных) папок документации. Сервер СПО принимает и загружает эти данные в субподрядную систему.
Этот вид взаимодействия подразумевает обмен информацией в электронном виде между двумя и более организациями. Поскольку в данном случае мы напрямую затрагиваем правовые вопросы, процессы обмена данными можно дополнить созданием сопроводительных документов и цифровой подписью. По соглашению организаций может использоваться как простая подпись TDMS, так и усиленная квалифицированная электронная подпись (УКЭП).
Информационное взаимодействие с пользователями ДМЗ производится посредством почтовых сообщений TDMS. Почтовые сообщения в обеих системах синхронизируются и обеспечивают возможность обмена информацией. При необходимости и предварительной договоренности почтовые сообщения TDMS могут дублироваться на внешний почтовый ящик субподрядчика.
Кроме этого «классического» метода обмена информацией в TDMS стороны могут использовать обмен быстрыми сообщениями в границах информационных потоков одного из серверов приложений. Поскольку сервер TDMS недоступен субподрядчику, таким сервером будет выступать сервер СПО.
Получив задание, субподрядчик приступает к изучению полученных исходных данных и разработке документации. Свою работу специалист субподрядчика выполняет в браузере, но логика работы системы, команды и все основные формы повторяют основное клиентское приложение TDMS, что видно на рис. 5.
Так как субподрядчик работает в системе, основанной на системе генерального проектировщика, все требования к обозначению документации, именованию файлов, заполнению атрибутов (свойств) документов, правилам их размещения в структуре проекта и прочие условия будут распространяться и на субподрядную документацию.
Так, при создании проектного документа в составе комплекта система субподрядчика автоматически заполняет нередактируемое поле Обозначение, формируя его по тем же правилам, что и базовая система. И, как и в основной системе, разработчик документа может ввести дополнительный шифр, который может быть обозначением документа во внутренней информационной системе субподрядчика, или опустить его, как показано на рис. 6, если используется единая система кодировки обозначений.
В процессе работы над проектом субподрядчик добавляет всю разработанную им документацию в форматах файлов, предусмотренных договором. Процесс проектирования и загрузки документов может сопровождаться обсуждением с заказчиком в неформальной форме с обменом данными через почту TDMS или Менеджер быстрых сообщений.
Закончив загрузку ПП, субподрядчик командой переводит ее в специальный статус; иными словами, «публикует» ее. Из опубликованных документов сервер приложений СПО формирует пакет данных, содержащий загруженную субподрядчиком документацию, для ее передачи на основной сервер TDMS. Согласно расписанию синхронизации, сервер TDMS забирает этот пакет и загружает его в базу данных. Лицу, отвечающему за взаимодействие с субподрядчиком, отправляется письмо TDMS c вложением.
Получив информацию о публикации документов субподрядчиком, ГИП приступает к их первичной оценке. При обнаружении ошибок общего характера (ошибки оформления, некомплектность
В случае отсутствия замечаний ГИП должен запустить процесс технической проверки документации профильными подразделениями. По умолчанию в список проверяющих отделов добавляется подразделение, указанное в комплекте. ГИП может добавить в этот список любое другое подразделение.
При маршрутизации TDMS обычно использует групповые контакты. После запуска процесса проверки тома/комплекта (рис. 7) задачу на его проверку получит группа руководителей профильного отдела и такие же группы руководителей отделов, добавленных ГИПом. Это позволяет, например, в случае отсутствия или высокой загрузки начальника отдела выполнять его функции силами других специалистов.
Специалист из группы руководителей отдела может произвести проверку документации самостоятельно или передать задачу любому сотруднику своего отдела.
При отсутствии замечаний к документации задача завершается (карточка задачи по проверке документа представлена на рис. 8). Если замечания есть, они оформляются в виде заключения эксперта (рис. 9). Один пользователь может оформить несколько заключений. Процесс модерируется руководителем, назначившим пользователя на эту задачу. Так, руководитель может закрыть или аннулировать заключения любого сотрудника своего отдела.
После завершения всех задач по проверке документа процесс переходит в стадию подготовки сводного заключения (рис. 10). Ответственный за сводное заключение изучает все подготовленные заключения экспертов, может закрыть или аннулировать любое из них или добавить собственное. По завершении задачи ответственный принимает решение выдать положительное или отрицательное заключение.
Далее система письмом информирует ГИПа о завершении процесса проверки. Основываясь на результатах проверки, ГИП принимает решение о сдаче документации в архив или о ее возврате на доработку субподрядчику.
В случае возврата документации на доработку сервер TDMS готовит для передачи на сервер СПО пакет данных, содержащий сводное техническое заключение со списком незакрытых заключений экспертов. Сервер СПО загружает эти данные для доступа субподрядчика.
Получив письмо о необходимости доработки документации, субподрядчик открывает в браузере заключение (рис. 11) и приступает к анализу полученных замечаний.
На все замечания экспертов субподрядчик должен добавить ответ (рис. 12).
Если вносить изменения в документацию не требуется, субподрядчик может опубликовать том/комплект без изменений, выполнив специальную команду, как показано на рис. 13.
Если же в документации необходимы изменения, субподрядчик возвращает том/комплект в работу. При этом создается новая версия тома/комплекта. Внесенные изменения публикуются субподрядчиком. Важно отметить следующее. Несмотря на то что при взаимодействии с субподрядчиком может появиться произвольное количество версий документа, заказчику проекта будет передан документ с «нулевым измом». Система сохраняет все внутренние версии документа, но при этом не меняет обозначение документа, загружаемого на сервер TDMS.
Получив информацию о готовности комплекта, ГИП принимает решение о дальнейшем направлении тома/комплекта. Процесс проверки и внесения изменений продолжается до тех пор, пока все замечания не будут устранены и комплект не будет готов к передаче заказчику проекта.
Внимательный читатель наверняка заметил, что мы описали процесс ручной загрузки документов со стороны субподрядной организации. Но что если у субподрядчика уже есть своя система хранения ПП, и ему, по сути, придется заниматься двойной работой, сначала загружая документы в свою систему, а затем в систему заказчика.
Такой замечательной компании мы можем предложить два варианта автоматизации.
Первый вариант немного архаичный, что, безусловно, скажется на сложности разработки и поддержки такого модуля. Пакеты данных, в которых TDMS обменивается информацией между серверами, формируются на основе XML. Точно такой же формат имеют обычные пакеты импорта и экспорта данных. При наличии собственных программных средств субподрядчик может формировать XML-пакет на основе данных своей системы и загружать его в TDMS одной командой импорта. Недостатки у такого подхода есть, назовем два главных:
Чтобы избежать описанных выше проблем, субподрядчик может использовать более современный способ загрузки документов. Этот метод основан на TDMS REST API — программном интерфейсе, специально разработанном нами для доступа внешних приложений, расположенных как внутри контура предприятия, так и вне его.
REST — это современный архитектурный стиль, созданный для управления данными через веб. Он позволяет разрабатывать унифицированные программные интерфейсы, независимые от применяемых компонентов, в целях создания многоуровневой распределенной системы для обеспечения безопасности и инкапсуляции разнородных систем.
Использование REST API значительно упрощает загрузку данных: сервер СПО сам формирует обозначения, проверяет непротиворечивость и полноту данных. При этом нарушать границы контура безопасности не потребуется: для доступа к службе интерфейса REST API будет достаточно авторизовать учетную запись лица, от имени которого осуществляется программный доступ.
С внедрением нового модуля процессы работы с субподрядом становятся значительно более прозрачными и современными. Более того, в этой статье мы сознательно пропустили момент планирования и контроля субподрядных работ. Оперативное планирование — это задача производственной системы, которой и является TDMS. Однако в рамках статьи рассказать еще и об этом модуле уже невозможно. Мы обязательно вернемся к этой теме в рамках следующего материала (возможно, даже не одного), посвященного управлению проектами в нашей системе.
От лица всего коллектива разработчиков TDMS выражаем надежду, что статья вам понравилась, была не очень сложной для понимания и не слишком занудной. До новых встреч в ближайшее время!
