Build or buy? Продолжу писать на холиварные темы, на этот раз вечная дилемма: Build or Buy (или выбор между тем, чтобы написать софт самим и страдать от того, что он глючный, или сразу купить глючный софт на рынке и потом уже ругаться с вендором). Существует разные стратегии к решению этой проблемы, и мне самым разумным кажется следующий подход: все, что отличает компанию от конкурентов, следует писать самим; все типовые же процессы и решения, которые не являются уникальными, лучше покупать. Пример — Dodo пишет свою Dodo IS, так как посчитали автоматизацию и стандартизацию своей главной фишкой, а вовсе не секретный рецепт пиццы (в этом случае хватило бы обычно iiko или r-keeper). Или вот Amazon — несмотря на большое количество WMS/TMS систем, упорно пишет свое, что порождает даже новые бизнесы типа AWS и даже считается одной из ведущих ИТ компаний в мире, несмотря на то, что разработчиков там работает 4% от всего персонала (70k из 1.5M). Правда, есть у такой логики один фатальный недостаток, а именно: принцип NIH (Not Invented Here), при котором умные разработчики обязательно будут убеждать, что и вот текущий бизнес-процесс для компании уникален и лучше его обязательно переписать самостоятельно, так как подходящих коробок на рынке нет и все их придется дорабатывать, а лучше сразу переписать с нуля (хотя мы это уже обсуждали). Поэтому в случае нетехнологичных компаний (т.е. там, где ИТ пока отличает себя от бизнеса) и их внутренних ИТ департаментов может быть вполне выигрышная стратегия и все покупать — например, когда я работал в Volvo, мой тогдашний CEO ссылался на какую-то умную шведскую книжку, в которой автор утверждал, что если услугу можно купить на рынке, то нужно ее покупать (надо отметить, что это было в начале 2000-х и тогда очень популярна была идея внутреннего аутсорсинга и тогда же была популярна поговорка No CIO ever got fired for buying IBM).