Почему и какие компании решают заказывать индивидуальную разработку для внутренних систем?
Сам лично участвовал в нескольких таких проектах, когда некая компания с IT бюджетом решает строить свой продукт и берёт не существующие решения, а заказывает всё с нуля на Java/.NET в Web версии.
Вопрос для тех кто принимает участие в таких проектах, хочется как то понять картину кто эти компании, и как выходит что они принимают решение — заниматься индивидуальной разработкой. Их требования настолько специфичны или это просто случайность?
10 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарівУспешные компании, в своем секторе — при этом как правило недооценившие стоимость сопровождения и поддержи собственной системы со временем, а также рисков, которые будут только расти.
Вдобавок к очевидным соображениям (время реакции на изменение требований, отсутствие оплаты чужой прибыли, как правило большие стартовые вложения при покупки лицензий на сотни рабочих мест и т. п.) некоторые компании рассматривают вариант выхода на рынок с продуктом. Ну и необъективность или некомпетентность экспертов, дающих информацию для решения нельзя отбрасывать. Внутренние не заинтересованы в смене привычных процессов — нужно будет искать новую работу в пределе- , да и зачастую не владеют ситуацией на рынке, внешние зачастую заинтересованы в смене и не могут это скрыть — мало чисто консалтинговых компаний, которые не являются реселлерами или интеграторами тех или иных вендоров.
Нормально в любой продуктовой компании. Cерьёзный продукт на десятки микросервисов — это API. И чем более долговечный по развитию продукт, и чем более он ориентирован на интеграцию — тем больше в нём «своих» деталей лего.
Взять тот же HTML — ведь фреймворки тоже не энтузиастами были сделаны, и не от хорошей жизни. А были когда-то внутренностями компаний. Не факт что и компания выжила, но если хороший фреймворк пошёл в жизнь — потом считают стандартом фе-факто.
Даже Руби — и тот сначала без рельсов :)
Разрабатываю такой проект. Да, зачастую требуются очень специфические возможности системы как в плане функциональности, так и в плане UX. Реализованные нами решения по улучшению эргономики экономят множество человеко-часов. В готовых продуктах этого нет. Множество функционала сделано по просьбам активных пользователей. Отклик на запросы очень быстрый. В общем, все меняется и делается очень быстро и максимально удобно для конкретной компании-пользователя. Релизы выпускаются раз в неделю. Естественно, это — продукты для очень больших компаний (500+ сотрудников) с большими бюджетами.
интересно, какие это специфические возможность/процессы даже в части ui нельзя быстро автоматизировать, за счет внутреннего штата аналитиков хорошо знающих предметную область и bpm платформы, к тому же если они еще и владеют bpmn, биплом и т.д.?
Кроме того, это будут намного более стабильные решение чем то, что вы накодите и даже хорошо протестите. и опять же моделирование процесса, сборка ui в конструкторе или даже возможность докодить какие-то экстра фичи самому, это намного более быстро и дешево чем расширять специфическую безупречную систему под заказ.
Подскажите пож-ста какие платформы вы имеете ввиду? Если 1С, Sharepoint, NetSuite, Salesforce, MS CRM, SAP и т.п. — они, как и множество решений о которых я пока не слышал, довольно популярны. Мне было бы интересно узнать о конструкторе для бизнес процесов широкого профиля. В идеале который не имеет заоблачных лицензионных отчислений и легок в освоении :)
А вобще причины написания своего кода, на мой взгляд:
1)стоимость — для узких решений может быть дешевле начать внедрение с разработки пилотных версий, а не покупать лицензии для сотен или тысячей юзеров от крупной платформы. И дальше эти проэкты уже жалко бросать) .
2)знание — если и есть какито хорошие глобальные платформы — мало в наличии эвангелистов и специалистов аналитиков разбирающихся в этой области. я так предполагаю должно быть чтото от IBM в этой области но много ли людей об этом знают .
3) контроль — затраты на внедрение и допилку все равно будут большими, и хочеться иметь собсвенный продукт а не зависимость от поставщика который может прекратить поддержку продукта, перейти на новую версию и тп.
4) инвестиции и амбиции — опять же при схожих порядках затрат хочется инвестировать деньги и время в чтото, что потенциально можно перевести в продукт. Так вобщемто и стартовало множество Б2Б проэктов.
По вашим пунктам 1,2,3,4... может рассуждать ай-ти менеджер, а не топ менеджер в корпорации, которая задумываеться уже идти за разботкой к пордрядчику. Последнему нужно меньше мороки больше стабильности, больше капитализации от бизнесса от инвестиций. Все это он получит пойдя в Pega, Oracle, IBM, а не в какой-то ноунейм бодишоп из Украины, о который ему даже стыдно обьявить как о партнере, что практически и находит отражение в NDA.
имхо, разработки энтерпрайз систем под заказ с нуля становиться пережитком прошлого и чем дальше тем больше будет сводиться на нет. Для специфических стандартизированных процессов, продукт всегда предпочтительней(как АБС система например). Для специфических процессов, на рынке с гибкими ценами предлагаються совершенно различные решения от малого до много вплоть до облачных технологий.
Айти менеджеры в бизнесе уже научены сполна, во-первых самописными неспровождаемыми решениями, во-вторых привязкой к каким-то языкам платформам и т.д, также грамотный it-менеджер в бизнессе себе трезво отдает отчет что то, что ему сейчас напишет бодишоп, через 5 лет уже будет нахер никому не надо, так как в тренде будут другие подходы языки технологии с новыми планками производительности и гибкости.
Задача любого здравомыслящего бизнесса — как можно более абстрагироваться от всего этого говна, с которым сотферная индустрия(особенно бодишопы/аутсорсеры) пытаеться справиться уже не один год и как показывает рост спроса на программистов и зарплаты, справляется очень слабо.
кстати вот еще версия — существующие решения от крупных консалтеров типа IBM настолько не успевают за развитием технологий и нововведений в бизнесе что топ менеджеры предпочитают более молодые и динамичные команды и продукты.
Ок, предполагаю, что на рынке bpm систем сейчас и такаких хватает, так же очень верно сказано, что это продуктовые компании, а не бодишопы и разработка с нуля под чью-то хотелку
Думают что это будет дешевле, больше контроля над направлением разработки.