Ринат Гимранов, начальник управления ИТ в ПАО «Сургутнефтегаз» — как российские решения становятся основой для суверенной, масштабируемой и гибкой ИТ-инфраструктуры

— Ринат, добрый день. Начнем нашу беседу. Какие тренды и события вы считаете ключевыми вызовами для современного российского ИТ и для себя лично?

— Сегодня я вижу два главных вызова. То, что еще недавно называли импортозамещением, я бы сформулировал как обретение технологического суверенитета. Мы заметно продвинулись, но пока недостаточно. Мы по‑прежнему живем в западных парадигмах, пользуемся западными продуктами, хотя, как говорил один русский философ, нам пора «переумнить Запад»: перестать копировать и начать создавать собственное. Это серьезная, но решаемая задача.

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

— В сфере кибербезопасности вы отметили, что работы еще много. Что мешает? Это вопрос технологий, ментальности или чего‑то еще?

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

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

— Вы упомянули импортозамещение. В дискуссиях звучит мнение, что мы уже опережаем, и противоположное — что все еще догоняем. На каком этапе, по‑вашему, находится рынок? Возможно, по разным классам ПО ситуация различается?

— Сегодня компании находятся на разных дистанциях. Некоторые, включая наш холдинг, просто берут и делают. Другие до сих пор тормозят. Мы фазу выбора прошли в 2022‑м, в 2023‑м делали прототипы, а в 2024‑м приступили к внедрению. Сейчас ландшафт в основном сформирован: мы обсуждаем уже не то, какой модуль лучше, а как быстрее реализовать проекты.

При этом объективную картину составить сложно: в ИТ‑сфере легко «навести тень на плетень». Долгое время под импортозамещение выдавали обновление «1С» с седьмой на восьмую версию. В бизнес‑планах появлялась строка «Внедряем 1С 8», и отчетность перед регуляторами выполнялась. Особенно это было заметно в компаниях с госучастием. К счастью, это не стало массовой практикой. Большинство коллег‑айтишников действительно стараются.

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

— Учредители часто требуют экономического обоснования, а аудиторы смотрят на соблюдение нормативов. Как ИТ‑директорам проходить эти процедуры, если на кону — технологический суверенитет?

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

Мы организовали работу импортозамещения в виде дорожных карт для каждого бизнес‑направления. Таких карт больше десяти, и они взаимосвязаны. Если задержать, например, развитие учета материалов, не заработает бухгалтерия или торговый модуль. Синхронизация дорожных карт — первый пункт в нашем реестре рисков. Мы постоянно отслеживаем, чтобы сдвиги в одной области не разрушили все остальное.

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

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

— Какие качества и навыки вы считаете сегодня наиболее важными для лидеров в ИТ?

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

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

Важно также выстраивать взаимодействие с внешними разработчиками. Если раньше вместе с продуктом SAP мы получали готовую методологию и организационные схемы, то сегодня на российском рынке это приходится делать самим. Мы уделяем этому больше внимания. Например, когда начинали проект с VK Tech, провели отдельную сессию командообразования: не типичный тимбилдинг, а серьезный мозговой штурм. Нам было важно, чтобы наша совместная команда думала о результате, а не воспринимала друг друга только в формате «подрядчик — заказчик». С тех пор мы следим за качеством взаимодействия и стараемся сохранять это партнерство: просто контрактной схемы для успеха недостаточно.

— Расскажите о ключевых проектах, которые вы реализуете вместе с VK Tech.

— Проектов много, но условно это один большой проект: внедрение частного облака. Мы тщательно исследовали рынок, и в финале осталось два лидера, которые закрывали весь спектр потребностей. Мы оценивали функциональность, дорожные карты, обязательства. В честной конкуренции победил VK Tech, и мы приняли решение разворачивать платформу у себя.

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

Выше — уровень управления разработкой. Мы называем его ПУР — процессы управления разработкой (или подсистема управления разработкой). Здесь есть две ипостаси: во‑первых, поддержка процедур и процессов, которые требует вендор, — например, интеграция с его средой разработки. Во‑вторых, обеспечение всех наших внутренних процессов: когда мы создаем свои приложения, нам нужна полноценная среда, чтобы управлять требованиями, версиями и тестированием.

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

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

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

— Корневую бизнес‑функциональность мы, конечно, покупаем. Но практика показывает, что крупные предприятия серьезно адаптируют типовые системы под свои нужды. Мы когда‑то провели исследование и выяснили: в среднем около 60% объектов в SAP подвергается изменению. Это не значит, что переписывается 60% кода; речь о том, что по специфическим процессам компоненты подстраиваются. SAP‑стандарт, как выяснилось, — миф.

Сейчас, когда ландшафты становятся композитными и ни один вендор не может покрыть всю функциональность, некоторые компоненты выгоднее написать самим. Мы не создаем собственную ERP‑систему, но у нас есть MES, АСУПП, АСУТП, которые развиваются десятилетиями. Мы разработали собственный digital master data management (DMDM), потому что стандартное предложение нас не устраивало. Сейчас на рынке появились альтернативы, но наш продукт работает, мы его импортозаместили и продолжаем развивать. Таким образом, внутренняя разработка остается там, где она оправданна и экономически эффективна.

— Каких успехов вы уже добились в программе импортозамещения?

— У нас принята трехлетняя программа перехода на отечественные ERP‑решения. К 2027 году планируем полностью выключить SAP. Тогда можно будет подробно рапортовать об успехах. Сейчас мы в процессе. Есть локальные достижения: запущены отдельные блоки, но масштабный результат впереди. У нас более 30 продуктивных систем, включая SAP BW, HR и две ERP‑системы, которые нужно заменить. Когда завершим основную массу, можно будет говорить о полноценном успехе. Пока мы делимся опытом с коллегами, но официально объявлять о завершении рано.

— С какими сложностями вы столкнулись? Бывали ли случаи, когда планировали один сценарий, а получили другой?

— Одно серьезное опасение не оправдалось. Мы думали, что придется потратить огромные усилия на переобучение: коллектив у нас стабильный, многие работают по 10–20 лет. Я сам пришел в «Сургутнефтегаз» в 1989‑м и больше нигде не работал. Казалось, что новые языки, среды, иначе реализованные бизнес‑процессы потребуют колоссальных ресурсов. Но оказалось, что специалисты с глубокими знаниями SAP довольно быстро осваивают новые платформы, если правильно организовать обучение.

Из реальных рисков выделю два. Первый — сложность синхронизации дорожных карт. У нас их больше десяти, и они взаимозависимы: задержка в одном направлении может притормозить другие. Поэтому мы постоянно анализируем взаимовлияние и корректируем планы. Второй риск — ресурсная емкость вендоров. Российские разработчики пока меньше по численности, чем глобальные корпорации. Если несколько крупных компаний одновременно обратятся со своими требованиями, у вендора может не хватить ресурсов, чтобы быстро их реализовать. Это мы тоже учитываем.

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

— Как вы оцениваете потенциал российских разработчиков и ИТ‑рынка?

— У российского ИТ‑рынка отличный потенциал. У нас сильные специалисты и высокая мотивация. Сейчас ситуация непростая: некоторые крупные компании сократили ИТ‑бюджеты, и для разработчиков это удар, но это не значит, что деньги тратятся бездумно. Мы тоже бережно относимся к бюджетам и стараемся их экономить, но активность сохраняем. Когда к активной фазе перейдут хотя бы 50–70% крупных компаний, рынок заживет иначе.

Наш рынок далеко не маленький. Когда‑то он был привлекательным для SAP, Microsoft, Oracle, IBM и других крупных игроков. Почему же для российских вендоров он вдруг стал маленьким? Конечно, развитие экспортных направлений важно — открытый рынок стимулирует рост. Но потенциал внутри страны еще не исчерпан: множество предприятий только собираются приступить к проектам. Когда они начнут, рынок станет полноценным. Нужно найти баланс между инженерным и коммерческим подходами: кто‑то считает, что сначала нужно довести продукт до совершенства, а потом продавать, а кто‑то — что можно продавать и дорабатывать по ходу. Истина, как всегда, посередине.

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

— Есть хорошая формулировка: желающие сделать ищут средства, нежелающие — причину. Жалобы на отсутствие функций у отечественных продуктов зачастую служат оправданием бездействия. Мы, например, в свое время допилили около 60% SAP, и это общемировая практика. То же самое можно сделать и с российскими решениями: они дорабатываются. Мы проводили нагрузочные тесты, проверяли функциональность — задачи решаемы. Те, кто хотят работать, уже берут продукт и доводят его до нужного уровня. Те, кто не хочет, говорят о «перламутровых пуговицах», которых нет.

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

— Какую роль, по вашему мнению, российские национальные вендоры должны сыграть в ближайшие пять лет? Некоторые ждут возвращения иностранных производителей; кто‑то — нет. Как вы видите их место на рынке?

— Разговоры о возможном возвращении иностранных компаний часто используются как повод ничего не делать: а вдруг вернутся. Даже если вернутся, кто поверит и захочет вновь работать с ними? Перед российскими разработчиками стоит сложная, но понятная задача — стать полноценными вендорами. Мы сравниваем их с SAP, Microsoft, IBM, Hewlett Packard — это высокая планка. Им нужно выстроить зрелые бизнес‑модели, развить экосистемы, создать поддержку для партнеров, предлагать разные бизнес‑направления, инвестировать в обучение, работать с крупными клиентами и внимательно относиться к функциональным запросам.

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

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

— Ни одно серьезное интервью сейчас не обходится без вопросов про искусственный интеллект и большие данные. Как у вас обстоят дела с последними?

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

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

— Каким вы видите российский ИТ‑рынок через пять лет?

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

Главное — сохранить драйв, чтобы не угас «огонек в глазах». Недавно мы встречались с крупнейшим производителем российской СУБД. Они показали дорожную карту: развивают in‑memory‑решение уровня SAP HANA. Это не копирование, а самобытная разработка, но по возможностям — серьезное движение вперед. В горизонте полутора‑двух лет это даст заметный результат. В этом же направлении двигаются и другие поставщики корпоративных хранилищ. Будет конкуренция — и будет качественный результат.

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

— Проведем блиц. SAP или СУП?

— Мне не нравится термин «СУП» — система управления предприятием. Думаю, что в привычном виде не будет ни SAP, ни СУП. Модели будут другими.

— On‑premise или облако?

— On‑premise. Все данные — в собственном дата‑центре.

— Десктоп или смартфон?

— Хочется сказать «планшет». На деле — и десктоп, и смартфон: оба нужны.

— Внутренняя разработка или готовые решения?

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