Комментарии 17
Обычно вендоры всё-таки стараются не лезть во внедрение. Понятно что не всякому Газпрому получается отказать, если он захочет видеть в проекте именно вендоров, но всё же описанные боли - это больше к интеграторам.
К особенностям добавлю гигантские сроки запуска проектов. От формулирования потребности до запуска тендера в некоторых ГБУ и даже ПАО легко может пройти год и больше, даже если все участники процесса в этом реально заинтересованы.
И, не знаю как на западе, но у нас собирает потребности и пишет ТЗ обычно не заказчик а будущий подрядчик.
Учитывая, что некоторые системы работают пять лет и больше – представьте, сколько всего ненужного там скопилось.
"Системы" обычно работают гораздо дольше. Некоторые системы за 5 лет едва успеваешь нормально написать, вообще не понимаю что это за предприятия, которым нужен кастомный софт, и для которых 5 лет это уже старье и ненужное...
Сбербанк, ВТБ, Яндекс, Почта России, РСХБ и т.п. Т.е. это крупные корпорации с большими бюджетами, которые имеют возможность развивать собственную разработку и пытаться конкурировать с вендорами и интеграторами. Но проблема в том, что как правило, получившийся продукт или не доходит до продажи, или не находит пользователя, т.к. компании на этом не специализируются
Вы привели пример компаний, которые ничего не собираются продавать. Все, что они делают - делают исключительно для себя, для автоматизации собственных бизнес-процессов.
У нас (Альфа-Банк) все ровно точно также. Мы не продаем программный продукт. Мы банк. Но у нас огромное количество бизнес-процессов, которые требуют автоматизации.
Если говорить о той конкретной области, где работаю я. Это "Управление разработки центральных банковских систем". То, что работает на центральных серверах. Автоматизированная Банковская Система (АБС).
Сразу скажу, что центральные сервера у нас работают на специфической платформе IBM i. АБС (точнее, ее ядро) было когда-то выкуплено вместе с исходниками (и это не российская разработка).
С тех пор в АБС было внесено огромное количество изменений и дополнений - где-то что-то изменяется в бизнес-процессах, где появляются новые. Меняются (или появляются новые) требования законодательства или регулятора... Где-то проводится оптимизация существующего. Доработки ведутся постоянно.
Естественно, что вести доработки силами своей команды для банка выгоднее (это было установлено еще лет 6-7 назад, если не больше).
Любая доработка делается и внедряется быстрее своими силами чем каждый раз договариваться с вендором
Любая доработка обходится дешевле своими силами чем каждый раз заключать договор с вендором.
Платформа в РФ распространена мало - вендоров с достаточном уровнем экспертизы по этому стеку (а это и платформа и специализированный язык на ней) практически нет (есть пара-тройка, мы с ними сотрудничаем, но достаточно ограниченно). У нас же за последние годы собрана сильная в этой области команда разработчиков.
Так что ваш пример неудачен. Это не тот случай, когда компания один раз купила продукт (пусть даже кастом) и потом им пользуется без внесения изменений. В крупных корпорациях выгоднее держать свои отделы разработки которые будут заниматься оперативной доработкой и поддержкой системы, автоматизирующей все бизнес-процессы.
Вы привели пример компаний, которые ничего не собираются продавать. Все, что они делают - делают исключительно для себя, для автоматизации собственных бизнес-процессов.
Ну да, давайте прям переберем.
Сбербанк отлично выпускает на рынок продукты - «СберАналитика», «СберМобайл» (собственная сотовая сеть), «Окко», «Ситимобил», «Delivery Club», который сейчас Яндексу принадлежит, даже собственная криптовалюта СберCoin. Они делают сервисы и для бизнеса, и для физлиц.
ВТБ выводит опять же через Т1, через свою дочернюю компанию, которая ей же принадлежит, внедряемые у них же проекты, например, «Сфера».
Яндекс – по аналогии со Сбером, у них глобальная сеть, от DataLens (аналитика) до такси, доставки еды и аренды самокатов. Они зачастую покупают продукты, которые могут в дальнейшем не только использовать для себя, сколько в дальнейшем продавать их на рынок. Опять же, берем замену Google Suite в виде Яндекс 360, который включает и телемост, и почту, и календарь, и т.д., и т.п. Все это строится на различных движках, в том числе опенсорсных.
С остальными перечисленными компаниями идентичная ситуация. Только вот почему-то команды внутри, например, Яндекса, пользуются не Телемостом, а Zoom. ВК пользуются не ВК Teams, а тем же Zoom.
Естественно, что вести доработки силами своей команды для банка выгоднее (это было установлено еще лет 6-7 назад, если не больше).
И да, и нет. В целом, позиция «Альфа-банка» понятна и известна, «все должно быть внутри». Но это радикальная позиция. Мы придерживаемся того, что всегда должен соблюдаться баланс между собственной разработкой и использованием вендорских продуктов.
Когда вы затачиваетесь на то, чтобы все делать исключительно своими силами, вы, с одной стороны, в моменте получаете быструю скорость реакции, а с другой - начинаете очень сильно зависеть от вашей команды, которая не чувствует конкуренции с рынка и может манипулировать уже сроками, ограничивать вас в тех возможностях, которые вам нужны здесь и сейчас, и вы в конечном счете все равно вынуждены будете пойти на рынок и искать продукты, которые ваша команда в данный момент разработать, доработать, внедрить не может.
При этом вторая сторона этого маятника это полная зависимость от внешней разработки, что тоже плохо, и не дает той необходимой гибкости, поэтому необходимо соблюдать всегда баланс.
Кроме того, не забываем, что продукты разные, и содержать команды под каждый продукт может себе позволить только глобальный холдинг.
Пункт 1, про перенос "хлама" можно свести к "пишите функционал, который надо писать и не пишите, который не надо". Отличить одно от другого, это задача на порядки более сложная, нежели просто написать код. И конечно, исполнителю очень хотелось бы, чтобы заказчик её каким то волшебным образом решил. Но это так не работает.
Допустим, берем пример Confluence, у которого тысячи плагинов. Допустим, некая компания хочет заменить его на что-то другое. При этом некоторые плагины работают исключительно в экосистеме Confluence, и воспроизвести их в другой экосистеме просто невозможно. И они используются для определенного типа контента, который нечасто нужен.
Второй пример. Есть специфичный контент, который, если провести анализ, вообще не используется. Зачем тратить деньги на то, чтобы переносить что-то, что не нужно? Вы с одной стороны повышаете трудоемкость и бюджет, который тратите на функционал, который фактически и не нужен.
У нас был опыт с одним крупным холдингом в сфере жд. Там мы проводили такой анализ - более 30% никому не нужного функционала, его не надо переносить.
Сбербанк, ВТБ, Яндекс, Почта России, РСХБ и т.п. Т.е. это крупные корпорации с большими бюджетами, которые имеют возможность развивать собственную разработку и пытаться конкурировать с вендорами и интеграторами. Но проблема в том, что как правило, получившийся продукт или не доходит до продажи, или не находит пользователя, т.к. компании на этом не специализируются
Чья проблема-то? Эти корпорации не собираются ни с кем конкурировать, они разрабатывают продукт под себя. Зачем им его продавать? А свой отдел разработки гораздо более оперативен и гибок, чем сторонние вендоры и интеграторы.
В целом недовольство понять можно - хочется присосаться к жирному клиенту.
Но тут есть еще один момент - внутренние разработчики ближе к внутренним же бизнес-процессам и более погружены в конкретную предметную область. Что дет еще одно преимущество внутренней разработке перед внешней.
Кроме того, у нас еще есть принципиальное условие - все исходники контролируем мы. Ради этого были выкуплены исходник нашей АБС. Ради этого, даже при работе с вендорами, приемка идет на уровне исходных кодов (код-ревью делаем мы, поставки собираем и тестируем мы, аналитика тоже наша). Тут все просто - банк не хочет ставить себя в зависимость от вендора в плане mission critical инфраструктуры.
Вообще вендоры у нас привлекаются в тех случаях, когда не хватает своих, внутренних, ресурсов. И это всегда получается и дольше и дороже (как-то проскакивала стоимость, заявленная вендором за неделю разработки - наш разработчик в месяц получает кратно меньше). А иногда еще и с качеством бывают проблемы (у нас бывали ситуации, единичные случаи, но бывали, когда приходилось в категорической форме отказываться от конкретного разработчика на стороне вендора т.к. его уровень не удовлетворял нашим запросам).
Да, внутренняя команда есть, и это хорошо. Но, повторюсь, не стоит ограничиваться только ей.
Компания не может бесконечно набирать команду. Используются десятки систем, это огромное количество людей, которые будут заниматься этой системой настолько же детально, подробно, как это делает вендор, который фокусируется только на этом.
Фактически, используя только подход внутренней команды, компания ограничивает сама себя.
Зато отсутсвует вендор лок. И компания получает то, что хочет, а не то, что может предложить вендор.
Само собой, жить на одном только внутреннем софте сложно. Потому задача - поиск удачного компромисса. Не изобретать велосипед, когда его проще купить, но и не пытаться участвовать в гонках формулы на серийной легковушке.
Когда основная работа базируется - на внутренней команде, это как строить коммунизм в отдельно взятой .. нет, не стране с 200 млн. населения, а скорее в области с 2 млн населения. Шанс построить, как бы есть, вот только запаса прочности нет, и тогда при малейшем внешнем или внутреннем возмущении вся конструкция рухнет.
Про конкуренцию и "зачем продавать" я выше ответил. Ради прибыли, конечно)
Чьей прибыли?
Работа на внутренние нужды и на внешнего клиента сильно различается. И если абстрактный сбер захочет продавать свою внутренню разработку, то ему придётся нанять ещё больше народу и начать размазывать персонал по разным задачам. В итоге пострадают и внутренние, и внешние. И вместо прибыли будут только убытки.
Статья конечно будет в минусах, так технический портал и тут больше взгляд с колокольни коллег с области их работы внутри компании.
У нас есть пример, когда заказчик 4 года собирает требования с разных вендоров. На этот рыночный ресерч они потратили очень много денег, но, судя по еще одной анкете, до сих пор не пришли к какому-то решению. Напомню – 4 года.
да, такое присутствует не в компаниях где бюрократизированный процесс и зачастую пока они выбирают вектор автоматизации и решения тут либо уже этот проект не нужен, либо продукт уже совсем не тот за тот период пока выбирали.
5. Максимально - собственная разработка, минимум внешних решений.
Тут направление отнюдь не бюджетов(не только) даже и не желания вести прям принципиально свою разработку, данные компании изначально идут с вектором построения экосистем и агрегируя в себе максимально возможное количество сервисом для их предоставления собой - что будет если они наберут кучу коробок которые покрывают от части какой-то функционал. а потом пойдут в интеграцию этих коробок между собой это большие расходы как финансовые так и временные для обсуждения с каждым вендором, а можно ли это делать и так далее, естественно и вендора такие разработки будут считать "кастомными" и так как это компания поставщик она нацелена давайте не будем забывать на получение прибыли.
когда приходилось в категорической форме отказываться от конкретного разработчика на стороне вендора т.к. его уровень не удовлетворял нашим запросам).
Так же коллега выше правильно говорит, вендор просто решит задачу костылем так как это кастомная для него разработка, а заказчик имея такой костыль не сможет далее оперировать где-то этим костылем...
Я думаю обсуждение отдельной (собственной разработки это совсем другое направление.
Но в целом да, не желание приобретать коробку связанно с тем, что зачастую не компетентный персонал, сам не знает чего хочет и не знает что будет нужно в будущем для формирования четкого требования к коробки и ее возможной кастомизации или ее интеграции.
..Так же нужно не забывать, что своя разработка тоже выходит не дешевая, когда вы разрабатываете что-то большое вам нужна большая экспертиза, а это взращивание собственного персонала, поддержание но тут да несомненный плюс возможности быстрой гибкости, кастомизации и самостоятельности.
«Вредные привычки» российских IT-заказчиков