Летом прошлого года в ряде изданий мелькали новости о том, что «Северсталь» создала единую систему управления проектами капитального строительства на базе 1С-продуктов. В первую очередь они были адресованы бизнес-сообществу строительной отрасли и описывали поставленные цели и достигнутые результаты именно в бизнесе. В этой статье мы хотим рассказать о том, зачем понадобилась система, из чего она состоит и с какими вызовами столкнулись при её внедрении. Возможно, материал будет интересен или даже полезен ИТ-специалистам, которые внедряют готовые приложения на платформе «1С:Предприятие» с глубокой адаптацией штатной функциональности под определённые задачи. В эфире старший менеджер нашего 1С-центра Павел Архиереев, он участвовал во внедрении многих сложных систем в инфраструктуру «Северстали». 

А при чём здесь строительство, да еще и капитальное?

Дело в том, что «Северсталь» состоит из множества так называемых бизнес-единиц, которые занимают огромные площади в разных городах своего присутствия. На территории этих промышленных площадок есть здания и сооружения производственного и административного-бытового назначения — всё это объекты капитального строительства. Они существуют в физическом мире, имеют материальную природу и состоят из реального камня, металла и стекла. А значит использование этих объектов приводит их к естественному износу, компенсация которого возможна либо модернизацией, либо ремонтом.

Кроме того, даже в такой консервативной отрасли как металлургия (человек проводил первые опыты с плавлением металлов ещё в третьем тысячелетии до нашей эры) технологии продолжают совершенствоваться, стремясь к повышению эффективности и экологичности. И вот это совершенствование металлургических технологий требует строительства новых объектов: производственных зданий, сооружений, агрегатов. Так вот всё это в «Северстали» образует сферу корпоративного капитального строительства.

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

Схема работы дирекции по инвестициям «Северстали» и зачем ей понадобилась автоматизация

Наша дирекция по инвестициям — это не какое-то уютное подразделение, которое только и делает, что распределяет большие деньги налево и направо. Это целый центр методологии, управления и реализации инвестиционных проектов капстроительства (и не только их). Например, в 2021 году инвестиционная программа включала более 1000 инвестиционных капстрой-проектов с проектно-изыскательскими и строительно-монтажными работами. Сотрудники дирекции по инвестициям условно распределены по трём направлениям: в проектировании трудятся ≈800 человек; строительство обеспечивают ≈1000 человек; в управлении заняты ≈350 человек. Немало, согласитесь.

Проектно-изыскательские работы для сферы капитального строительства по заказам дирекции по инвестициям выполняют корпоративные проектные институты:

1. ООО «Северсталь-проект», г. Череповец.

2. ООО «СпБ-Гипрошахт», г. Санкт-Петербург.

3. АО «КО ВНИИМЕТМАШ», г. Санкт-Петербург.

Для выполнения строительно-монтажных работ дирекция по инвестициям применяет смешанную схему «инсорсинга» / «аутсорсинга». Так внутренним производителем работ выступает «Центрдомнаремонт» ПАО «Северсталь», а в качестве внешних подрядчиков привлекаются специализированные строительные компании, количество которых на конец 2021 года составило около сотни.

 Прибавьте сюда высокий уровень регламентации, свойственный строительной сфере, и вы получите ещё и объёмный и, порой, трудноуправляемый бумажный документооборот. Конечно, многие задачи у нас решались с помощью различного ПО — от унифицированных приложений типа Microsoft Office до узкоспециализированного «ГРАНД-Смета». Но в том-то и дело, что это различное ПО состояло из огромного количества очень разных, часто несовместимых программ, работа с которыми сопровождалась высокими затратами на выполнение ежедневных операций. Кроме того, такая и без того неудобная информационно-технологическая среда не принимала внешних пользователей в лице сотрудников подрядных организаций, с которыми шёл тот самый обременительный, но необходимый документооборот.

В общем, стало очевидно, что наша дирекция по инвестициям, как огромное проектное подразделение, нуждается в едином для всех участников капстроительства автоматизированном цифровом информационном пространстве. Было решено разработать целую программу проектов автоматизации дирекции по инвестициям. В рамках этой программы и появилась идея создания информационной системы управления проектами со строительно-монтажными работами, первоначально получившей малоговорящее название: «Расчёт смет и ПК», а впоследствии переименованной в ИСУП — информационную систему управления проектами.

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

Ну а цель проекта — создание единой  автоматизированной информационной среды для всех участников капитального строительства для сокращения времени выполнения типовых операций и минимизации влияния человеческого фактора. Простая, в общем, цель. Однако достичь её «с наскока» не получилось. Но давайте о трудностях мы расскажем позже, а сейчас — о том, из чего мы строили ИСУП.

Из чего состоит ИСУП

Посмотрим на устройство ИСУП с разных сторон: со стороны технологической платформы, со стороны функциональной и технической архитектуры.

Технологическая платформа

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

1. Зрелость и используемость в промышленных средах.

2. Модифицируемость, расширяемость и интегрируемость.

3. Техническая поддержка производителем.

4. Максимально возможная локализация или отечественное происхождение.

5. Возможность сопровождения собственными силами.

   На момент выбора в корпоративной информационно-технологической среде уже были технологические платформы, которые отвечали этим требованиям и которые претендовали на то, чтобы стать основой ИСУП. Это, в частности, SAP, 1С и Oracle. Мы даже совершали так называемые демонстрационные визиты к коллегам по сфере, чтобы изучить опыт использования этих платформ в деле строительного управления. После всестороннего анализа отдали предпочтение SAP и 1С, на базе которых было решено создать комплексный интегрированный тандем, в котором обе платформы взаимно дополняли бы и расширяли возможности друг друга.

 На платформе SAP на базе модулей PPM («Управление портфелями проектов») и PS («Управление проектами») был реализован инструмент централизованного управления всей корпоративной инвестиционной программой в целом — не только в области капитального строительства и ремонтов но и в других, например, в области информационных технологий.

 На платформе 1С:Предприятие на базе конфигураций «1С:PM Управление проектами» и «1С:Смета» мы хотели реализовать расширение функциональности SAP, которое бы учитывало национальную специфику проектов с проектно-изыскательскими и строительно-монтажными работами.

 Причины выбора 1С для управления строительными проектами:

1. Наличие специализированной конфигурации для управления проектами капстроительства со строительно-монтажными работами и объёмными календарно- сетевыми графиками.

2. Многолетний опыт корпоративного использования продуктов 1С: конфигурация «1С:Управление проектной организацией» в ООО «СпБ-Гипрошахт» с 2011 года; конфигурация «1С:ERP+РМ» в ООО «Северсталь-Проект» с 2019 года.

3. Наличие в компании центра корпоративной экспертизы по внедрению и эксплуатации 1С-решений, состоящего из 60+ специалистов, обеспечивающих эксплуатацию ≈260 продуктивных экземпляров системы и оказывающих поддержку ≈20 000 пользователям этих систем.

4. Национальное происхождение технологической платформы «1С:Предприятие», разработчик которой выпустил на рынок и поддерживает более 1000 тиражируемых решений (бизнес-приложений) от унифицированных вроде «1С:ERP Управление предприятием» до узкоспециализированных «1С:Деньги». Плюс обширная партнёрская сеть из 7000 организаций в 600 городах, насчитывающих 300 000 специалистов, 2000 учебных центров и 5 000 000 пользователей.

Функциональная архитектура

В таблице ниже перечислены те функциональные области, которым требовалась автоматизация:

Часть требуемой функциональности уже присутствовала в отраслевых решениях «1С». Так, функциональность управленческого, производственного, бухгалтерского и налогового учёта, которая требовалась для корпоративных проектных институтов, присутствовала в конфигурации «1С:ERP Управление предприятием», функциональность управления проектами — в конфигурации «1С:PM Управление проектами», функциональность расчёта строительных смет — в конфигурации «1С:Смета». Мы решили не мелочиться и собрать конгломерат из перечисленных конфигураций, встроить в него специализированные строительно-нормативные сборники (справочники) и кастомизировать всё это дело под специфические потребности дирекции по инвестициям с учётом ограничений инфраструктуры и требований корпоративной информационной безопасности. 

Однако столкнулись с некоторыми вызовами.

Вызов 1: с обновлениями от разных вендоров 1С-решений

Через некоторое время стало очевидным, что присутствие подсистемы «1С:ERP» в составе общей конфигурации ИСУП (собранного конгломерата) категорически препятствует её своевременному обновлению на релизы вендора, которые оперативно выпускаются под перманентно меняющиеся требования национального законодательства в области РСБУ (российские стандарты бухгалтерского учёта) и НУ (налоговый учёт).

Так, обновления конфигурации «1С:ERP» фирма «1С» выпускает почти одновременно с изменениями законодательства. А вот обновления тандема «1C:ERP+PM» компания ООО «АйТиЛенд-Софт» выпускает порой спустя несколько месяцев после выхода обновления «1C:ERP», что является критически недопустимым, особенно, если речь идёт о глубокой кастомизации тандема «1C:ERP+PM». Ситуация усугубляется тем, что «1C:ERP+PM» используется корпоративными бизнес-единицами, чья регламентированная бухгалтерская и налоговая отчётность консолидируется с корпоративной финансовой отчётностью.

Решили выделить подсистему «1С:ERP» в отдельный экземпляр (базу данных), а между двумя получившимися в результате разделения базами данных построить двухстороннюю интеграцию на основе веб-сервисов.  

Вызов  2: с механизмом RLS

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

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

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

Поскольку ИСУП по внутренней классификации относится к системам, содержащим коммерческую тайну (КТ), было решено реализовать ограничение доступа к данным на более надёжном системном уровне, используя механизм RLS технологической платформы «1С:Предприятие».

RLS (row-level security), как и любой программный алгоритм, срабатывая, потребляет вычислительные ресурсы. Срабатывает же он при выполнении каждой операции, в которой реализовано ограничение доступа к данным — то есть постоянно. Понимая это, разработчики 1С предусмотрели два режима работы механизма RLS: производительный и стандартный. При производительном правила доступа (ключи доступа) рассчитываются заранее и хранятся для их последующего использования при выполнении операций. При стандартном ключи доступа рассчитываются «на лету» перед непосредственным выполнением операции. Использование производительного режима сразу же показалось нам привлекательным. Ещё бы, тратим процессорное время один раз при предварительном расчёте ограничений, а потом, пережив «цифровой шторм» с падением производительности системы, используем полученные результаты во время выполнения пользовательских операций. Но дьявол кроется в деталях, как известно.

Во-первых, оказалось, что в производительном режиме расчёт ограничений выполняется после каждого обновления конфигурации системы. И чем чаще такие обновления, тем чаще «цифровой шторм» и снижение производительности. А мы стремились к частым обновлениям во имя короткого time to market. Во-вторых, оказалось, что количество ограничений (ключей доступа) является декартовым произведением количества персональных групп доступа пользователей на количество элементов аналитики RLS. То есть в нашем случае мы получили ≈ 50 миллионов ключей доступа, которые при каждом обновлении конфигурации системы пересчитывались заново. Весь пар — в свисток.

Для конечного пользователя это проявилось в виде крайне низкой производительности и отсутствии доступа к нужному проекту порой в течении 3±5 суток после очередного обновления конфигурации системы. На момент написания статьи все многочисленные попытки оптимизации производительного режима RLS были исчерпаны и после дополнительных исследований мы решили перейти на стандартный режим.

Вызов  3: со встроенным HelpDesk

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

В таких двойственных случаях пользователей делят на два класса: ключевые и конечные. Техническую поддержку же строят по иерархическому принципу, используя трудовые ресурсы проектной команды. Разработчики поддерживают ключевых пользователей, а те в свою очередь поддерживают конечных. Вопрос, кто кого поддерживает, решён. Осталось поддерживающих и поддерживаемых оснастить соответствующим инструментом. Использование корпоративного HelpDesk было невозможно, так как он был предназначен для поддержки пользователей регулярных сервисов, официально внедрённых и переданных на сопровождение в корпоративную ИТ-функцию. Нужна была альтернатива.

В то время в «Северстали» широкое распространение получил облачный сервис Microsoft Teams. По примеру соседних проектных команд мы стали его использовать. Создали соответствующую команду, сформировали внутри неё тематические каналы поддержки, подключили пользователей. Чаты каналов позволяли поддерживаемым размещать свои обращения, а поддерживающим формировать на основе этих обращений задачи, отражать их на доске Kanban, назначать исполнителей и отслеживать прогресс. Такая стройная система поддержки вполне себе жила вплоть до введения в отношении ПАО «Северсталь» зарубежных санкций и недружественного отключения Microsoft Teams.

Коллеги из команды сопровождения SAP в качестве инструмента технической поддержки использовали встроенный штатный модуль SAP Solution Manager. Подсмотрев у них это, мы решили реализовать аналог такого модуля в ИСУП. Купили на сайте Infostart.ru готовую конфигурацию HelpDesk для 1С с доской Kanban, адаптировали её и встроили в конфигурацию ИСУП.

Так у нас получилось удобное «единое окно» технической поддержки: пользователь размещает заявку на поддержку непосредственно в ИСУП, диспетчер классифицирует заявку и назначает её на соответствующего исполнителя. Модуль HelpDesk позволяет отслеживать статус выполнения, поддерживать коммуникацию между заявителем и исполнителем, собирать статистику, оценивать загрузку и прогресс.

Техническая архитектура: тут всё четко

Из предлагаемого фирмой 1С разнообразия технических архитектур мы, исходя из корпоративных стандартов и существующих практик, выбрали трёхуровневую модель для нашей ИСУП: «клиент» — «сервер приложений» — «сервер базы данных».

Кластеры. Для повышения надёжности (отказоустойчивости и доступности), а также балансировки нагрузки, мы усилили эту архитектуру кластерной схемой, которая охватывает как сервер приложений 1С, так и сервер базы данных MS SQL. Предыдущий опыт эксплуатации подобных архитектур показал, что один сервер приложений 1С (то есть один узел кластера) с приемлемой производительностью обслуживает ≈300 одновременно работающих пользователей. В нашем случае ожидаемое число одновременно работающих пользователей равняется 500, то есть 1/3 от целевого количества подключенных пользователей. Таким образом каждый кластер состоит из двух узлов, которые функционируют в среде виртуализации.

 Контроль лицензирования 1С-конфигураций. Как вы помните, функциональная архитектура нашей системы состоит из трёх конфигураций и лицензируется каждая из них отдельно. Специалисты знают о том, что система лицензирования программных продуктов 1С такая же сложная, как и у многих других производителей ПО, например Microsoft. При этом часть лицензий, так называемые основные поставки, приобретается в виде документов, которые фиксируют юридическое право использования ПО как такового, в то время как другие лицензии (например, клиентские лицензии рабочих мест) поставляются в виде цифрового артефакта, который имплементируется в инфраструктуру. Для контроля количества используемых лицензий и обеспечения лицензионной чистоты в инфраструктуре ИСУП развёрнуты отдельные серверы защиты системы лицензирования конфигураций 1С (СЛК).

 Аутентификация. Для работы конечных пользователей используется desktop-приложение «1С:Предприятие». Оно установлено на компьютеры пользователей и работает в режиме «тонкого» клиента через отдельные веб-серверы. Это позволяет с одной стороны перенести вычислительную нагрузку на серверную часть инфраструктуры системы, а с другой — использовать каналы связи с негарантированной пропускной способностью. При подключении к системе внутренних (корпоративных) пользователей из корпоративной сети передачи данных применяется доменная аутентификация Active Directory. При подключении к системе внешних (некорпоративных) пользователей строительных подрядчиков из интернета применяется двухфакторная аутентификация Web SSO.

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

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