Атака клонов: чем бизнес заменит уходящие из России IT-продукты
Заменить нельзя оставить
Если бы еще в январе меня спросили, как я отношусь к преференциям для отечественного софта, я бы ответил, что отрицательно. Да, в критической инфраструктуре нужна независимость и защищенность, и выбор российского ПО обоснован. В остальном же российские решения должны иметь возможность свободно конкурировать с западными и выигрывать не за счет того, что они сделаны в нашей стране, а потому, что действительно крутые. Не должно быть выкручивания рук бизнесу с аргументом «зато мы местные».
Сейчас ситуация другая: многим компаниям предстоит в короткий срок отказаться от решений зарубежных компаний, которые так или иначе ограничили свою работу в России. Прежде всего речь об Oracle, Microsoft, Atlassian. В попытках срочно найти замену привычным зарубежным сервисам бизнес, скорее всего, обратит внимание на российских разработчиков, создающих аналогичные продукты. Кажется, чего проще — бери известный софт, копируй набор функций и предлагай заказчику. Но прямое копирование западных продуктов не даст российскому рынку того качественного роста, о котором многие мечтают.
Делая «клон» популярного продукта, компания-разработчик не в полной мере понимает, зачем в него добавлены те или иные функции. Например, одна из популярных CRM-систем Siebel CRM создавалась не для российского рынка. В России исходные ограничения этого софта многим мешали. Например, система плохо «разбиралась» в русском языке — это затрудняло и замедляло поиск клиентов, особенно если вдруг сотрудник допускал опечатки. Приходилось прибегать к «костылям» — обходным приемам, с помощью которых можно быстро устранить последствия некорректной работы. Подчеркиваю — только устранить последствия, а не решить проблему. По аналогичным причинам в крупных российских компаниях иногда можно увидеть весьма странные IT-конструкции, явно дополнявшиеся в процессе разнообразными не предусмотренными изначально инструментами и программами.
При копировании западных решений есть высокая вероятность создать продукт, часть функций которого в российских реалиях никогда не пригодится и даже будет мешать. В общем, давайте наконец концентрироваться на качестве продуктов и думать о том, что бизнесу нужно сегодня и завтра, а не просто импортозамещать!
Еще пример: с российского рынка ушли и такие крупные игроки рынка аналитических систем, как SAP и SAS. Могу прогнозировать, что вместо аналитических решений, которые предоставлял SAS, вырастет несколько локальных точечных решений. И это хороший сценарий. Он куда лучше варианта, при котором кто-то в России возьмется создавать аналогичную американской большую и сложную платформу. Даже если через какое-то время она и появится — скажем, в каком-то из крупных банков, то перенести ее в другие организации будет проблематично. Просто потому, что решение будет слишком кастомизированным и созданным с учетом интересов только одного, пусть и крупного, игрока. Такое мы, к слову, уже видели: один из крупных российских финтех-игроков решил тиражировать свои продуктовые разработки и внедрять их в других компаниях. Было ли это успешным, увидели ли мы wow-продукты и многочисленные успешные внедрения? Боюсь, что нет.
Чтобы не повторять слепо западные решения и не тратить время на разработку, которую сложно тиражировать, бизнесу и российским IT-компаниям нужно научиться открыто разговаривать друг с другом. Да, это не звучит как rocket science, но именно это ключ к успеху импортозамещения.
Шпаргалка для IT
От того, как IT-стартапы и системные интеграторы выстроят диалог с клиентами, во многом зависит успешность импортозамещения. За 17 лет на рынке отечественной разработки мы твердо уяснили, что иногда один вовремя заданный бизнесу вопрос «Зачем вам это?» может изменить представление о продукте и его роли в компании. Поэтому задайте потенциальному заказчику вопросы:
- Что вы дорабатывали в зарубежном решении, которое сейчас нужно заменить? Почему это делали? Без чего не сможете жить в этом решении?
- Какие «костыли» есть в действующем решении и зачем?
- Какие функции продукта вы не используете и почему?
- Что создает для вас самые большие сложности в ходе использования продукта?
- Как проходят обновления продукта? А каких обновлений вы ждали?
- Какой была «дорожная карта» развития? Появления каких функций вы ждали?
- Все ли вас устраивает в технической поддержке этого продукта?
Разговаривайте не только с теми, кто принимает решение о внедрении софта, но и с людьми, которые эксплуатируют систему. Например, сейчас лучшее время, чтобы задать вопросы инженеру поддержки и выяснить, с какими проблемами он сталкивается. Заменить IT-продукт, которым пользуется несколько сотен или даже тысяч человек в компании, вопрос не одного дня. Процесс этот сложный не только с точки зрения организации, но и с точки зрения обучения сотрудников и перестройки их работы.
Как не ошибиться при выборе поставщика
Вот несколько существенных моментов, на которые стоит обратить внимание заказчикам при выборе сложной IT-системы:
- Разберитесь с условиями лицензирования. Схем лицензирования много, и важно понять, что будет, если количество записей, запросов, пользователей или ядер превысит оговоренное в лицензии. Как убедиться, что не превышен объем используемых лицензий? Каковы условия их продления и расширения? Какие есть ограничения? У некоторых вендоров политика лицензирования привязана к количеству процессоров, и компания может хитрить, показывая на этапе закупки небольшое их количество для снижения цены. А при запуске в промышленную эксплуатацию может оказаться, что процессоров недостаточно. Четкое же понимание условий поможет избежать непредвиденных трат.
- Спросите, какие мощности нужны для российского решения. Что будет, если их не хватит? Как решение масштабируется?
- Поинтересуйтесь, какие проблемы при внедрении могут возникнуть у самой IT-компании. Правило хорошего тона со стороны поставщика — рассказать о рисках проекта. Спросите, что нужно перед началом проекта и какие ресурсы с вашей стороны потребуются во время и после внедрения.
- Попросите рассказать, как компания видит преимущества своего продукта. Это показательный вопрос, особенно если речь о стартапе.
- Уточните, как происходит процесс доработки продукта. Можно ли это делать собственными силами и какие риски при этом есть? Кто может доработать ядро продукта и как быстро? Правда, ответа про реальную скорость вы не получите, но, возможно, по крайней мере поймете, как это вообще устроено.
- Узнайте, как организовано сопровождение продукта. Что в него входит, а что нет? От чего зависит стоимость поддержки? Каковы условия исправления ошибок? Какие штрафные санкции? Как будете реагировать, если возникнет ошибка в ядре продукта? В случае с иностранными вендорами ждать исправлений в ядре приходилось месяцами, а то и годами, но от отечественных компаний логично ожидать более оперативных изменений.
И, конечно, лучше сделать пилотное внедрение, чтобы убедиться, что решение работает. «Пилот» позволит сравнить его с другими и в целом оценить адекватность поставщика. Перед тем как сделать окончательный выбор, добавьте небольшое задание. Оно позволит понять, может ли подрядчик что-то менять в своем продукте и как он в целом реагирует на такие просьбы.
И в заключение немного позитива. Лично я не теряю надежды, что в кризисных условиях бизнес сфокусируется на действительно важных задачах. Что станет меньше пустой бюрократии и ситуаций, когда 50 человек по полгода что-то обсуждают и не могут принять решение. Что количество проектов, которые реализуются только для галочки, наконец сократится. И не будет больше тех самых «игрушек» для IT, когда продукты вроде бы внедряются, а задачи бизнеса так и остаются нерешенными.
Мнение редакции может не совпадать с точкой зрения автора