В строительной отрасли Российской федерации происходят масштабные процессы цифровизации и внедрения технологий информационного моделирования. [1] Эти технологии затронут работу каждого участника строительной отрасли. В ближайшие годы большинство строительных организации встанут на путь цифровизации. Это позволит организациям оставаться конкурентоспособными на рынке. [2] Внедрению технологий информационного моделирования способствуют требования Постановлений Правительства, регулирующих органов и возможности современных информационных технологий. При этом большое количество разнообразных информационных систем на рынке осложняет выбор для компаний, что приводят к затягиванию внедрения новых технологий.
Основное содержание
Руководителям следует заранее планировать цифровую трансформацию. [3] Рассмотрим ситуацию, когда организация стоит перед необходимостью выбора прикладного программного обеспечения для цифровизации своих процессов. Также примем за исходные условия то, что компания приняла решение приобретать готовое программного обеспечение из доступных на рынке, как наиболее доступный и экономически оправданный способ решения конкретных задач. Это значит, что необходимо организовать работу по изучению, сравнению и выбору программного обеспечения. Будем рассматривать системы класса среда общих данных (СОД). Среда общих данных — это неотъемлемый элемент ТИМ. [4]
В первую очередь рассмотрим некоторые подходы и практики, эффективность которых недостаточна.
«Неправильные люди»
Для выбора прикладного программного обеспечения, в том числе для выбора систем для организации среды общих данных проекта объекта капитального строительства, нередко назначают людей с неподходящими компетенциями или должностными обязанностями. Рассмотрим некоторые наиболее часто встречающиеся примеры.
Для внедрения технологий информационного моделирования некоторые компании нанимают на работу специалиста со специальностью BIM-менеджер или, как он называется в профессиональном стандарте 16.151 «специалист в сфере информационного моделирования в строительстве» [5], ТИМ-менеджер. Требования данного стандарта распространяются на государственные компании. Это значит, что коммерческие компании могут нанимать себе в штат сотрудников с такой должностью без учета требований профстандарта. Но даже для работы в государственных компаниях сложно найти людей с подходящей по профстандарту квалификацией. Подобная ситуация приводит к тому, что к должностным обязанностям приступают люди с неподходящей квалификацией. Если компании удалось найти и привлечь к себе в штат необходимого специалиста, это не означает, что работа по выбору системы должна лечь исключительно на его плечи. В данном случае у сотрудника будет недостаточно знаний о внутренних процессах в компании, а также отсутствует авторитет для внедрения изменений в организацию. Получается, что каким бы правильным ни казался наём ТИМ-менеджера в качестве лидера команды по выбору системы СОД, делать это нужно осторожно.
Следующей часто встречающейся ситуацией является назначение специалиста отдела информационных технологий или руководителя этого отдела в качестве лица, принимающего решение о выборе прикладного ПО. Кажется, что это правильный выбор. Компании предстоит выбрать некоторое программное обеспечение, и кто же должен этим заниматься, если не отдел информационных технологий. Но в этом решении есть изъян. Заключается он в том, что специалисты ИТ-отдела рассматривают программное обеспечение со стороны вопроса о его обслуживании. Это значит, что приоритет критериев выбора системы будет смещен с выполнения задач бизнеса в сторону комфортного обслуживания информационной системы.
Иногда встречается ситуация, когда выбором прикладного программного обеспечения занимаются непрофильные специалисты, которые не будут заниматься эксплуатацией системы или ее обслуживанием. На практике автор встречал случаи, когда выбором СОД занимаются специалисты финансового отдела. Хоть эти случаи встречаются реже вышеописанных ситуаций, но требуется указать на то, что подобный выбор лиц, принимающих решение, наиболее неудачен. Данные специалисты могут быть весьма профессиональными в своей области, но знаний в предметной области, для которой выбирается система, им будет недоставать. В результате выбор может быть основан на субъективных предпочтениях конкретного человека. Специалисты в сфере финансов должны знать, как использовать возможности современного ПО. [6] Выбор таких специалистов в качестве экспертов по отбору прикладного ПО оправдан в том случае, когда речь идет о системах по их профилю работы.
«Неправильные подходы»
Первым подходом, который нельзя считать эффективным, можно назвать создание таблицы сравнения. Таким способом представитель покупателя пытается собрать информацию о существующих на рынке решениях. Производится это приблизительно таким образом: создается таблица, где в названия строк указывается какой-либо функционал системы и далее эта таблица рассылается по вендорам программного обеспечения с просьбой указать наличие или отсутствие указанного функционала. Что в этом подходе не так?
Первое - формулировки (наименования функций) весьма часто могут трактоваться по-разному. Вендоры могут трактовать это в свою пользу. В итоге в таблице будет указано, что какой-то функционал присутствует в указанном ПО, но на деле заказчик получит не то, что ожидает. И даже если функция, о которой мы говорим, вполне понятна, как, например, «добавление пользователя в систему», то ответ о ее наличии не дает полной картины. Например, добавление пользователя в одну систему занимает 3 минуты, а в другую - 30 минут. В обеих системах функция есть, но сложно представить пользователей, которых устроит тратить столько времени для выполнения типовой операции. Это значит, что индикация о наличии функции в системе не дает и не может давать понимания о возможности ее использования в определенной компании. Подобные таблицы могут быть использованы для оценки отсекающих критериев. Например, если компания выбирает решение, которое должно быть построено только на отечественных технологиях, то вопрос о наличии иностранных компонентов будет уместен. Таких критериев может быть несколько, но они редко касаются конкретного функционала.
Следующий малоэффективный подход представляет собой сбор пожеланий к будущей системе от сотрудников отделов, которые будут вовлечены в работу с этой системой. На первый взгляд, это является верным действием, но в нем есть ошибка. Заключается она в том, что специалисты описывают свои пожелания к системе относительно той ситуации, в которой они находятся, без использования этой системы. Иначе говоря, это будут пожелания улучшения собственной работы без изменения методологии выполнения этой работы. Это уже «методологическая коллизия», так как новая система принесет с собой и новые способы выполнения работы. Внедрение новых технологий неизбежно приведет к изменениям. [7] Второй недостаток, который встречается в этом подходе, в том, что сами по себе пожелания от разных специалистов не согласованы между собой. Они не могут быть согласованы, т.к. специалисты формулируют свои пожелания, не имея ограничений конкретной системы. На один вопрос могут быть получены противоречащие друг другу ответы. [8] Эти же пожелания не складываются в какую-либо методологию работы и не увязаны на общие цели организации.
Некоторые организации развивают предыдущий подход и на основании собранных пожеланий составляют документ, которому дают название «Техническое задание на информационную систему». Это действие неэффективно по нескольким причинам:
- написание технического задания требует опыта работы в этом направлении и серьезных компетенций;
- для того, чтобы компании-изготовители могли оценить объем работ по заказной разработке, писать техническое задание должны специалисты.
Как мы видим, написание технического задания (ТЗ) в процедуре организации выбора существующей на рынке системы является излишним. Рассылать подобное ТЗ по вендорам нет никакого смысла. Существующие решения написаны исходя из другой логики, можно сказать они написаны по «другому ТЗ». Получить систему, которая соответствует собственному ТЗ, можно лишь в случае, когда заказчик обращается за заказной разработкой. В данной статье мы не рассматриваем этот способ решения задачи по цифровизации.
Рассмотрим некоторые рекомендованные подходы и действия, которые могут повысить эффективность работы по выбору информационной системы.
Сложность выбора заключается в необходимости формирования критериального пространства выбора. [9]
«Инновация»
Внедрение новой информационный системы в организацию — это всегда инновация. Данная деятельность требует соответствующего подхода. Прежде всего организация должна быть готова изменяться. Изменяться будут бизнес-процессы и люди. Попытки внедрения информационных систем без изменения старых способов работы не будут иметь успеха, это невозможно сделать. Это значит, что выбор, а потом и внедрение информационной системы, должен возглавлять сотрудник, наделенный достаточными полномочиями для внедрения инноваций. Помимо официальных полномочий у этого человека должен быть некий «кредит доверия» со стороны сотрудников организации. Ему предстоит не только выбрать новую систему, но и «протащить» ее в коллектив. Люди не склонны меняться, а значит потребуется лидер, который эти изменения проведет.
«Команда»
К деятельности по выбору новой информационной системы требуется относиться со всей серьезностью. Это значит, что группа сотрудников, которая занимается этой работой, должна быть назначена приказом по организации. Сама работа не должна производится по «остаточному признаку», т.е. время на ее выполнение должно быть явно выделено в рабочем распорядке. Сроки, задачи, цели и ограничения должны быть четко обозначены.
На роль лидера команды по выбору среды общих данных следует рассматривать опытных сотрудников из числа руководителей проектов, которые имеют авторитет в коллективе. Внедрение инноваций зависит от умения руководителей оказать влияние на сотрудников, выступая для них примером. [10]
Для организации работы по выбору будущей информационной системы требуется назначать лиц с соответствующими компетенциями по предметной области. При этом в группе по выбору информационной системы могут находиться специалисты смежных отделов и отдела информационных технологий, но роль у них будет консультационная.
Команду выбора системы можно организовать, используя модель RACI [11] – рисунок 1.
В первую очередь рассмотрим некоторые подходы и практики, эффективность которых недостаточна.
«Неправильные люди»
Для выбора прикладного программного обеспечения, в том числе для выбора систем для организации среды общих данных проекта объекта капитального строительства, нередко назначают людей с неподходящими компетенциями или должностными обязанностями. Рассмотрим некоторые наиболее часто встречающиеся примеры.
Для внедрения технологий информационного моделирования некоторые компании нанимают на работу специалиста со специальностью BIM-менеджер или, как он называется в профессиональном стандарте 16.151 «специалист в сфере информационного моделирования в строительстве» [5], ТИМ-менеджер. Требования данного стандарта распространяются на государственные компании. Это значит, что коммерческие компании могут нанимать себе в штат сотрудников с такой должностью без учета требований профстандарта. Но даже для работы в государственных компаниях сложно найти людей с подходящей по профстандарту квалификацией. Подобная ситуация приводит к тому, что к должностным обязанностям приступают люди с неподходящей квалификацией. Если компании удалось найти и привлечь к себе в штат необходимого специалиста, это не означает, что работа по выбору системы должна лечь исключительно на его плечи. В данном случае у сотрудника будет недостаточно знаний о внутренних процессах в компании, а также отсутствует авторитет для внедрения изменений в организацию. Получается, что каким бы правильным ни казался наём ТИМ-менеджера в качестве лидера команды по выбору системы СОД, делать это нужно осторожно.
Следующей часто встречающейся ситуацией является назначение специалиста отдела информационных технологий или руководителя этого отдела в качестве лица, принимающего решение о выборе прикладного ПО. Кажется, что это правильный выбор. Компании предстоит выбрать некоторое программное обеспечение, и кто же должен этим заниматься, если не отдел информационных технологий. Но в этом решении есть изъян. Заключается он в том, что специалисты ИТ-отдела рассматривают программное обеспечение со стороны вопроса о его обслуживании. Это значит, что приоритет критериев выбора системы будет смещен с выполнения задач бизнеса в сторону комфортного обслуживания информационной системы.
Иногда встречается ситуация, когда выбором прикладного программного обеспечения занимаются непрофильные специалисты, которые не будут заниматься эксплуатацией системы или ее обслуживанием. На практике автор встречал случаи, когда выбором СОД занимаются специалисты финансового отдела. Хоть эти случаи встречаются реже вышеописанных ситуаций, но требуется указать на то, что подобный выбор лиц, принимающих решение, наиболее неудачен. Данные специалисты могут быть весьма профессиональными в своей области, но знаний в предметной области, для которой выбирается система, им будет недоставать. В результате выбор может быть основан на субъективных предпочтениях конкретного человека. Специалисты в сфере финансов должны знать, как использовать возможности современного ПО. [6] Выбор таких специалистов в качестве экспертов по отбору прикладного ПО оправдан в том случае, когда речь идет о системах по их профилю работы.
«Неправильные подходы»
Первым подходом, который нельзя считать эффективным, можно назвать создание таблицы сравнения. Таким способом представитель покупателя пытается собрать информацию о существующих на рынке решениях. Производится это приблизительно таким образом: создается таблица, где в названия строк указывается какой-либо функционал системы и далее эта таблица рассылается по вендорам программного обеспечения с просьбой указать наличие или отсутствие указанного функционала. Что в этом подходе не так?
Первое - формулировки (наименования функций) весьма часто могут трактоваться по-разному. Вендоры могут трактовать это в свою пользу. В итоге в таблице будет указано, что какой-то функционал присутствует в указанном ПО, но на деле заказчик получит не то, что ожидает. И даже если функция, о которой мы говорим, вполне понятна, как, например, «добавление пользователя в систему», то ответ о ее наличии не дает полной картины. Например, добавление пользователя в одну систему занимает 3 минуты, а в другую - 30 минут. В обеих системах функция есть, но сложно представить пользователей, которых устроит тратить столько времени для выполнения типовой операции. Это значит, что индикация о наличии функции в системе не дает и не может давать понимания о возможности ее использования в определенной компании. Подобные таблицы могут быть использованы для оценки отсекающих критериев. Например, если компания выбирает решение, которое должно быть построено только на отечественных технологиях, то вопрос о наличии иностранных компонентов будет уместен. Таких критериев может быть несколько, но они редко касаются конкретного функционала.
Следующий малоэффективный подход представляет собой сбор пожеланий к будущей системе от сотрудников отделов, которые будут вовлечены в работу с этой системой. На первый взгляд, это является верным действием, но в нем есть ошибка. Заключается она в том, что специалисты описывают свои пожелания к системе относительно той ситуации, в которой они находятся, без использования этой системы. Иначе говоря, это будут пожелания улучшения собственной работы без изменения методологии выполнения этой работы. Это уже «методологическая коллизия», так как новая система принесет с собой и новые способы выполнения работы. Внедрение новых технологий неизбежно приведет к изменениям. [7] Второй недостаток, который встречается в этом подходе, в том, что сами по себе пожелания от разных специалистов не согласованы между собой. Они не могут быть согласованы, т.к. специалисты формулируют свои пожелания, не имея ограничений конкретной системы. На один вопрос могут быть получены противоречащие друг другу ответы. [8] Эти же пожелания не складываются в какую-либо методологию работы и не увязаны на общие цели организации.
Некоторые организации развивают предыдущий подход и на основании собранных пожеланий составляют документ, которому дают название «Техническое задание на информационную систему». Это действие неэффективно по нескольким причинам:
- написание технического задания требует опыта работы в этом направлении и серьезных компетенций;
- для того, чтобы компании-изготовители могли оценить объем работ по заказной разработке, писать техническое задание должны специалисты.
Как мы видим, написание технического задания (ТЗ) в процедуре организации выбора существующей на рынке системы является излишним. Рассылать подобное ТЗ по вендорам нет никакого смысла. Существующие решения написаны исходя из другой логики, можно сказать они написаны по «другому ТЗ». Получить систему, которая соответствует собственному ТЗ, можно лишь в случае, когда заказчик обращается за заказной разработкой. В данной статье мы не рассматриваем этот способ решения задачи по цифровизации.
Рассмотрим некоторые рекомендованные подходы и действия, которые могут повысить эффективность работы по выбору информационной системы.
Сложность выбора заключается в необходимости формирования критериального пространства выбора. [9]
«Инновация»
Внедрение новой информационный системы в организацию — это всегда инновация. Данная деятельность требует соответствующего подхода. Прежде всего организация должна быть готова изменяться. Изменяться будут бизнес-процессы и люди. Попытки внедрения информационных систем без изменения старых способов работы не будут иметь успеха, это невозможно сделать. Это значит, что выбор, а потом и внедрение информационной системы, должен возглавлять сотрудник, наделенный достаточными полномочиями для внедрения инноваций. Помимо официальных полномочий у этого человека должен быть некий «кредит доверия» со стороны сотрудников организации. Ему предстоит не только выбрать новую систему, но и «протащить» ее в коллектив. Люди не склонны меняться, а значит потребуется лидер, который эти изменения проведет.
«Команда»
К деятельности по выбору новой информационной системы требуется относиться со всей серьезностью. Это значит, что группа сотрудников, которая занимается этой работой, должна быть назначена приказом по организации. Сама работа не должна производится по «остаточному признаку», т.е. время на ее выполнение должно быть явно выделено в рабочем распорядке. Сроки, задачи, цели и ограничения должны быть четко обозначены.
На роль лидера команды по выбору среды общих данных следует рассматривать опытных сотрудников из числа руководителей проектов, которые имеют авторитет в коллективе. Внедрение инноваций зависит от умения руководителей оказать влияние на сотрудников, выступая для них примером. [10]
Для организации работы по выбору будущей информационной системы требуется назначать лиц с соответствующими компетенциями по предметной области. При этом в группе по выбору информационной системы могут находиться специалисты смежных отделов и отдела информационных технологий, но роль у них будет консультационная.
Команду выбора системы можно организовать, используя модель RACI [11] – рисунок 1.
Рисунок 1 - Модель RACI
Роли в данной модели:
Исполнители – эксперты из числа опытных сотрудников организации, представляющие разные отделы, которые будут непосредственно задействованы в работе в системе. Количество экспертов зависит от количества отделов и размеров организации. Привлечение таких экспертов имеет два положительных значения:
- эксперты смогут дать независимую оценку предлагаемым решениям;
- эксперты, как представители коллектива, будут служить лучшему принятию инноваций внутри коллектива при внедрении. Фактически, через экспертов коллектив сам выбирает эту инновацию.
Ответственный – это лидер группы выбора, о котором упоминалось выше. Этот сотрудник принимает решение о выборе.
Консультанты – сотрудники смежных отделов, которые должны отследить в процессе выбора интересы организации. Тут должны быть привлечены сотрудники финансового и информационного отделов, юристы и т.д.
Информируемый – сотрудники из числа высшего руководства организации, до которых должна быть доведена информация о проведенной работе по выбору системы в виде отчета, а также принятое решение.
Сформировав команду выбора системы таким способом, возможно организовать объективный и непредвзятый выбор системы.
В качестве методологии работы стоит рассмотреть системный подход в принятии управленческих решений. Итогом работы по выбору информационной системы должен служить отчет с анализом доступных альтернатив.
- эксперты смогут дать независимую оценку предлагаемым решениям;
- эксперты, как представители коллектива, будут служить лучшему принятию инноваций внутри коллектива при внедрении. Фактически, через экспертов коллектив сам выбирает эту инновацию.
Ответственный – это лидер группы выбора, о котором упоминалось выше. Этот сотрудник принимает решение о выборе.
Консультанты – сотрудники смежных отделов, которые должны отследить в процессе выбора интересы организации. Тут должны быть привлечены сотрудники финансового и информационного отделов, юристы и т.д.
Информируемый – сотрудники из числа высшего руководства организации, до которых должна быть доведена информация о проведенной работе по выбору системы в виде отчета, а также принятое решение.
Сформировав команду выбора системы таким способом, возможно организовать объективный и непредвзятый выбор системы.
В качестве методологии работы стоит рассмотреть системный подход в принятии управленческих решений. Итогом работы по выбору информационной системы должен служить отчет с анализом доступных альтернатив.
