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

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

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

Пронин В.И. Организация процесса выбора среды общих данных для проектов объектов капитального строительства // Экономика: вчера, сегодня, завтра. 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.

Рисунок 1 - Модель RACI

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Больше интересной информации в Telegram-канале «ИНГИПРО»