Между вендором и open source: выбор в эпоху оптимизации

Будь то промышленное оборудование, электроника или программные решения большая доля в закупках компаний и предприятий исторически приходилась на международных мейджоров: IBM, Oracle, HP, DELL, Fujitsu, SWIFT, Huawei, Microsoft, Komatsu, Caterpillar и т.д. 

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

Зависимость от глобальных вендоров – один из ключевых рисков в России. Например, компания IBM с отдельными решениями вышла на отечественный рынок еще в 1976 году. Когда же после развала СССР открыли границы, она стала полноценно предлагать оборудование и решения, которые уже работали у крупных компаний по всему миру. Таким образом в России постепенно сложилась ситуация, схожая с той, что наблюдается во всем мире: два-три крупных вендора в своей отрасли занимают до 70–80% рынка, а оставшиеся 20–30% – стартапы или компании с узкой специализацией. Насколько такая система устойчива в нынешних условиях? 

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

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

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

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

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

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

Но в использовании разработок на открытом коде есть нюансы. Первый связан-таки с сервисной поддержкой. Даже если речь идет о действительно широко используемой платформе или распространенном решении с большим сообществом разработчиков, могут возникнуть проблемы со скоростью и качеством ответов на вопросы: комьюнити обычно не предлагает SLA. А если решение нишевое и у него нет большого комьюнити, то вся поддержка ложится на плечи внутренней ИТ-службы или возникает потребность в привлечении третьей компании, которая может такую поддержку предоставить. 

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

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

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

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

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

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

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

Заметили неточность или опечатку в тексте? Выделите её мышкой и нажмите: Ctrl + Enter. Спасибо!