Внедрение российского ПО потребует от компаний перестройки бизнес-процессов

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

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

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

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

— А на что на самом деле заказчик должен обращать внимание при выборе российского софта? Понятно, что любой инженер, который 10-15 лет проработал в одной зарубежной программе и в одном интерфейсе, попробовав другое непривычное ему ПО, придет к начальнику и скажет, что оно никуда не годится…

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

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

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

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

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

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

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

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

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

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

— Вы как производитель софта, на основании которого будет формироваться информационная модель объекта, наверняка знаете о новом постановлении Правительства № 614, которое прописывает требования к информационной модели объекта капитального строительства. По вашему мнению, насколько оно отвечает требованиям рынка?

— По сути, это рамочный документ, в котором большими блоками все довольно понятно прописано, и на его основе можно разрабатывать более предметные документы. Поэтому, на мой взгляд, документ вполне отвечает требованиям рынка, и в нем все есть. Да и в российском ПО для его выполнения тоже, по сути, все есть. На сайте Минстроя России есть набор очень хороших документов, в том числе московских, которые необходимы для формирования и ведения информационной модели. Мы видим там уже требования к самой информационной модели, требования к поверке на коллизии — то есть это ключевые документы, которые можно взять за основу и начать работать. Понятно, что этот пакет документов разработан для гражданских объектов, а не промышленного строительства, но его уже можно использовать. Хотя могу точно сказать, что в большинстве компаний стройной системы внутренних документом для работы с информационной моделью, как правило, нет.

— Вопрос в том, что с 1 июля этого года все застройщики, которые работают по 214-ФЗ, должны были перейти на использование информационной модели при проектировании, строительстве и эксплуатации объектов капитального строительства. И это требование обязательно для всех — и продвинутых столичных гигантов, таких как Группа «Эталон» или «ПИК», и для застройщика в дальнем регионе России, который строит один дом в год. И эти небольшие региональные застройщики, не до конца понимая, что от них требуют по этой ИМ, начнут метаться в поисках ПО, специалистов и так далее. Какие первые шаги должны быть у этого массового застройщика? С чего они должны начать, чтобы выполнять требования ПП-614 и закона?

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

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

— Конечно, могут. Достаточно большой список того, где и какое программное обеспечение может применяться, есть на сайте Минстроя России. Но еще раз подчеркну, что выбор ПО должен быть в рамках уже готовой «дорожной карты», где будут пункты, в каком программном обеспечении будет решаться та или иная задача. И только после этого можно идти и подбирать под эти пункты нужное ПО. Другого пути нет.

— «Сисофт Девелопмент» как лидер рынка отечественного ПО может ли предложить застройщикам всю линейку необходимых им продуктов?

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

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

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

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

— Прошло два года с момента начала импортозамещения иностранного софта — можно ли сказать, что российские вендоры за эти два года встали на ноги, оперились, полетели?

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

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

Елена Шинкоренко

Этот материал опубликован в июльско-августовском номере Отраслевого журнала «Строительство». Весь журнал вы можете прочитать или скачать по ссылке: https://ancb.ru/files/pdf/pc/Otraslevoy_zhurnal_Stroitelstvo_-_2024_god_08_2024_pc.pdf