Организация процесса выбора среды общих данных для проектов объектов капитального строительства

В.И. Пронин, Коммерческий директор - ООО «Ингипро»

Для цитирования в научных исследованиях

Пронин В.И. Организация процесса выбора среды общих данных для проектов объектов капитального строительства // Экономика: вчера, сегодня, завтра. 2023. Том 13. № 5А. С. 239-249. DOI: 10.34670/AR.2023.54.86.078

Введение

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

Основное содержание

Руководителям следует заранее планировать цифровую трансформацию. [3] Рассмотрим ситуацию, когда организация стоит перед необходимостью выбора прикладного программного обеспечения для цифровизации своих процессов. Также примем за исходные условия то, что компания приняла решение приобретать готовое программного обеспечение из доступных на рынке, как наиболее доступный и экономически оправданный способ решения конкретных задач. Это значит, что необходимо организовать работу по изучению, сравнению и выбору программного обеспечения. Будем рассматривать системы класса среда общих данных (СОД). Среда общих данных — это неотъемлемый элемент ТИМ. [4]

В первую очередь рассмотрим некоторые подходы и практики, эффективность которых недостаточна.

«Неправильные люди»

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

Для внедрения технологий информационного моделирования некоторые компании нанимают на работу специалиста со специальностью BIM-менеджер или, как он называется в профессиональном стандарте 16.151 «специалист в сфере информационного моделирования в строительстве» [5], ТИМ-менеджер. Требования данного стандарта распространяются на государственные компании. Это значит, что коммерческие компании могут нанимать себе в штат сотрудников с такой должностью без учета требований профстандарта. Но даже для работы в государственных компаниях сложно найти людей с подходящей по профстандарту квалификацией. Подобная ситуация приводит к тому, что к должностным обязанностям приступают люди с неподходящей квалификацией. Если компании удалось найти и привлечь к себе в штат необходимого специалиста, это не означает, что работа по выбору системы должна лечь исключительно на его плечи. В данном случае у сотрудника будет недостаточно знаний о внутренних процессах в компании, а также отсутствует авторитет для внедрения изменений в организацию. Получается, что каким бы правильным ни казался наём ТИМ-менеджера в качестве лидера команды по выбору системы СОД, делать это нужно осторожно.

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

Иногда встречается ситуация, когда выбором прикладного программного обеспечения занимаются непрофильные специалисты, которые не будут заниматься эксплуатацией системы или ее обслуживанием. На практике автор встречал случаи, когда выбором СОД занимаются специалисты финансового отдела. Хоть эти случаи встречаются реже вышеописанных ситуаций, но требуется указать на то, что подобный выбор лиц, принимающих решение, наиболее неудачен. Данные специалисты могут быть весьма профессиональными в своей области, но знаний в предметной области, для которой выбирается система, им будет недоставать. В результате выбор может быть основан на субъективных предпочтениях конкретного человека. Специалисты в сфере финансов должны знать, как использовать возможности современного ПО. [6] Выбор таких специалистов в качестве экспертов по отбору прикладного ПО оправдан в том случае, когда речь идет о системах по их профилю работы.

«Неправильные подходы»

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

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

Следующий малоэффективный подход представляет собой сбор пожеланий к будущей системе от сотрудников отделов, которые будут вовлечены в работу с этой системой. На первый взгляд, это является верным действием, но в нем есть ошибка. Заключается она в том, что специалисты описывают свои пожелания к системе относительно той ситуации, в которой они находятся, без использования этой системы. Иначе говоря, это будут пожелания улучшения собственной работы без изменения методологии выполнения этой работы. Это уже «методологическая коллизия», так как новая система принесет с собой и новые способы выполнения работы. Внедрение новых технологий неизбежно приведет к изменениям. [7] Второй недостаток, который встречается в этом подходе, в том, что сами по себе пожелания от разных специалистов не согласованы между собой. Они не могут быть согласованы, т.к. специалисты формулируют свои пожелания, не имея ограничений конкретной системы. На один вопрос могут быть получены противоречащие друг другу ответы. [8] Эти же пожелания не складываются в какую-либо методологию работы и не увязаны на общие цели организации.

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

• написание технического задания требует опыта работы в этом направлении и серьезных компетенций;

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

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

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

Сложность выбора заключается в необходимости формирования критериального пространства выбора. [9]

«Инновация»

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

«Команда»

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

На роль лидера команды по выбору среды общих данных следует рассматривать опытных сотрудников из числа руководителей проектов, которые имеют авторитет в коллективе. Внедрение инноваций зависит от умения руководителей оказать влияние на сотрудников, выступая для них примером. [10]

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

Команду выбора системы можно организовать, используя модель RACI [11] – рисунок 1.

Роли в данной модели:

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

• эксперты смогут дать независимую оценку предлагаемым решениям;

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

Ответственный – это лидер группы выбора, о котором упоминалось выше. Этот сотрудник принимает решение о выборе.

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

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

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

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

Первый этап работ – описать задачи

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

Второй этап – отсекающие критерии

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

Примеры таких критериев:

• соответствие требованиям российских нормативных актов, наличие системы в реестре отечественно ПО;

- требования по безопасности, независимость от иностранных вендоров;

• возможность размещения на серверах клиента;

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

• и др.

На этом этапе работ уместно сравнить и выбрать для себя лучшую техническую структуру среды общих данных. В данный момент можно выделить два распространенных на рынке способа построения СОД:

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

Второй способ построения СОД – использование «облачных» сервисов. Этот способ является следующим шагом в развитии информационных технологий. Его применению активно способствует наше государство. Облачный сервис представляет собой систему, которая разворачивается на выделенных серверах, расположенных в профессиональных ЦОДах или на серверах клиента. Пользователи получают доступ к системе посредством браузера на своих устройствах. Установка дополнительного ПО в этом случае не требуется. Плюсами данного способа являются быстрое разворачивание в проекте, возможность подключения к работе неограниченного числа лиц, работа из любого места и низкие издержки на эксплуатацию. Минусами – меньший, по сравнению с клиент-серверными системами, функционал.

Третий этап – сравнение альтернатив

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

К списку задач следует применить принцип Парето. Практика применения различных информационных систем показывает, что пользователи, по большей части, пользуются минимальным количеством функций, которые обеспечивают выполнение требуемой работы. Мы можем выбрать 20% основных задач, для которых нужна система. Эти задачи составляют порядка 80% работы, которую нужно произвести пользователям системы. Сравнение систем следует проводить именно по этим 20% задач. Если этого будет недостаточно для выявления лучших альтернатив, то можно будет провести сравнение по дополнительным критериям. Обычно этого не требуется.

После применения принципа Парето к списку задач у нас должно остаться 5-7 основных задач. В этот список следует добавить критерии оценки стоимости приобретении и стоимости эксплуатации системы.

Для сравнения отобранных систем можно воспользоваться одним из способов:

• если в списке к сравнению 2-3 системы, то следует использовать метод парного сравнения. Одна из систем берется в качестве базовой и с ней сравнивается альтернативная система по существующему списку критериев и задач. Если по совокупности результатов альтернативная система оказывается лучше, то ее принимают за базовую и сравнивают со следующей альтернативой.

• если к сравнению у нас три и более системы, то следует использовать метод бальной или взвешенной оценки. В этом случае составляется таблица, где в строках указываются отобранные задачи и критерии, присваивается «вес» этому критерию (сумма «весов» составляет 100%), а в столбцах указываются альтернативные системы. Эксперты проводят работу по оценке представленных способов решения задач и дают оценку. В результате мы можем получить или одну таблицу, где уже указаны усредненные оценки экспертов, или несколько таблиц от каждого эксперта, которые нужно будет привести к средним значениям. Подробней данный метод оценки описан в статье Щеглова [12]

На основе этого отбора принимается решение о выборе системы или систем. Выбор не обязательно должен включать только одну систему.

Четвертый этап – тестирование

Когда работа по выбору возможных информационных систем проведена, следует провести реальное тестирование системы. Обычно вендоры дают возможность протестировать свои системы в течение 2-4 недель бесплатно. Практика показывает, что подобное тестирование дает мало информации. Будущие пользователи не проводят тестирование реальных бизнес-процессов в системе, а количество тестирующих — это обычно один человек, что совершенно не подходит для тестирования систем класса СОД. Среда общих данных — это такая система, которая затрагивает работу большинства сотрудников организации участника проекта объекта капитального строительства. Лучшей практикой является тестирование системы на реальном проекте. Таким образом покупатель получит реальный опыт применения системы относительно своей организации. Хорошо, если система СОД имеет возможность приобретения лицензий по проектам. В этом случае для тестирования на одном проекте будет достаточно приобрести одну лицензию и подключить всех необходимых пользователей своей организации и подрядчиков. Не стоит боятся купить ограниченное количество лицензий, от которых в будущем откажитесь. Гораздо хуже купить систему целиком на организацию и в процессе эксплуатации понять, что она вас не устраивает.

Заключение

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

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

Библиография

1. Васильева, Н. В. Проблемные аспекты цифровизации строительной отрасли / Н. В. Васильева, И. А. Бачуринская // Вестник Алтайской академии экономики и права. – 2018. – № 7. – С. 39-46. – EDN YUDSQP.

2. Провоторов, И. А. Актуальные направления цифровизации строительной отрасли / И. А. Провоторов, А. В. Вторников // Цифровая и отраслевая экономика. – 2020. – № 2(19). – С. 126-129. – EDN FTIMNX.

3. Соболевская, Т. Г. Влияние цифровизации экономики на систему менеджмента современного предприятия / Т. Г. Соболевская // Экономика: вчера, сегодня, завтра. – 2019. – Т. 9, № 10-1. – С. 165-171. – DOI 10.34670/AR.2020.92.10.019. – EDN WUYWCV.

4. Савенко, А. И. Среда общих данных при реализации строительных объектов с применением BIM / А. И. Савенко, П. В. Черенков // CAD & GIS for roads. – 2019. – № 2(13). – С. 4-11. – DOI 10.17273/CADGIS.2019.2.1. – EDN YCCEZG.

5. Профессиональный стандарт "Специалист в сфере информационного моделирования в строительстве" URL: https://classinform.ru/profstandarty/16.151-cpetcialist-v-sfere-informatcionnogo-modelirovaniia-v-stroitelstve.html (Дата обращения 11.05.2023г).

6. Цифровая экономика: проблема образования в России / Ю. В. Забайкин, Е. В. Красавина, В. А. Сологуб, И. А. Хашева // Управление образованием: теория и практика. – 2022. – № 7(54). – С. 15-21. – DOI 10.25726/z7715-2443-9897-h. – EDN PXXWYD.

7. Провоторов, И. А. Актуальные направления цифровизации строительной отрасли / И. А. Провоторов, А. В. Вторников // Цифровая и отраслевая экономика. – 2020. – № 2(19). – С. 126-129. – EDN FTIMNX.

8. Проблема выбора методов сбора требований и обоснование их использования на этапах разработки автоматизированных информационных систем / О. С. Шевцова, Л. А. Юнина, А. С. Шевцов, Л. З. Давлеткиреева // МОЛОДЕЖНАЯ НАУКА КАК ФАКТОР и РЕСУРС ИННОВАЦИОННОГО РАЗВИТИЯ : сборник статей Международной научно-практической конференции, Петрозаводск, 10 мая 2020 года. – Петрозаводск: Международный центр научного партнерства «Новая Наука», 2020. – С. 19-23. – EDN UDKBLF.

9. Грабовый, П. Г. Методические основы выбора информационной системы корпоративного управления проектами / П. Г. Грабовый, А. В. Иванов // Недвижимость: экономика, управление. – 2019. – № 3. – С. 17-21. – EDN FTHJEZ.

10. Кузнецов, Д. А. Влияние лидерства на внедрение инноваций в организации / Д. А. Кузнецов // Конкурентоспособность территорий : Материалы XX Всероссийского экономического форума молодых ученых и студентов. В 8-ми частях, Екатеринбург, 27–28 апреля 2017 года / Ответственные за выпуск Я.П. Силин, Е.Б. Дворядкина. Том Часть 2. – Екатеринбург: Уральский государственный экономический университет, 2017. – С. 122-125. – EDN UPJYNC.

11. Шалев, Е. Г. Расширенная RACI матрица как инструмент управления персоналом в организации / Е. Г. Шалев // Интернаука. – 2023. – № 6-2(276). – С. 59-62. – EDN VCVGUP.

12. Щеглов, Д. К. Методология выбора корпоративных информационных систем в условиях цифровой трансформации организации оборонно-промышленного комплекса / Д. К. Щеглов // Вестник Концерна ВКО "Алмаз – Антей". – 2021. – № 4(39). – С. 7-24. – DOI 10.38013/2542-0542-2021-4-7-24. – EDN DGUVYS.

13. Иванченко, А. В. Роль экспертных систем при выборе и внедрении автоматизированных информационных систем на предприятии / А. В. Иванченко, А. В. Мельников // Приоритетные научные направления: от теории к практике. – 2013. – № 4. – С. 59-63. – EDN RDYFFZ.