Купить или строить?

И это охренительно частый вопрос не только при выборе собственного жилья, но и при инхаус-разработке. Точнее, это тот вопрос, который необходимо задать до того, как разработка станет инхаус

Давайте определимся: стороннее решение должно существовать. Сложно выбирать в ситуации, когда выбирать не из чего. Мало ли, Вы собрались автоматизировать то, куда никто до Вас не заглядывал

Но раз уж считаем, что нашли готовое ПО, давайте выделим ключевые моменты, которые необходимо проанализировать перед выбором

1️⃣Посмотрите на команду. Если Вас два калеки - Вы и сисадмин - покупайте

2️⃣Оцените область и компетенции. Сейчас речь даже не о компетенциях команды разработки, я и про компетенции людей, обеспечивающих процессы. Если область жёстко регламентируемая, а компания не обладает достаточными ресурсами или экспертизой для отслеживания изменений, их оценки, составления задания на доработку и реализацию (вот это уже про ИТ-департамент) - покупайте

3️⃣Определите отличия существующих процессов (и какими их хотят видеть!!!!) от того, как они заданы в стороннем решении. Если доступное ПО лежит очень далеко от того, как надо, однозначный ответ - пилите Шура, там нихрена страшного. Потому что доработка существующего решения до соответствия требованиям может оказаться неприемлемой по затраченным ресурсам. Если процессы (почти)идентичны, то по этому пункту отдаём предпочтение уже существующему решению ⚠️Кажущаяся незначительной разница может привести к очень большим изменениям - не забудьте ознакомится не только с красивой презентацией от поставщика, но и с архитектурой решения⚠️

4️⃣Взвесьте стратегическую важность. В определённых ситуациях, компании хотят иметь полный контроль над продуктом

5️⃣Обсудите бюджет и сроки. При прочих равных, отдайте предпочтение тому, что лучше впишется, с учётом
▪️возможных требований доработки ПО под принятые бизнес-процессы
▪️стоимостью дальнейшего владения

Это базовые моменты, но какие практические следствия из одного или другого варианта автоматизации?

Инхаус-разработка
➕Увеличивается скорость реакции на требуемые изменения за счёт
▪️меньшей кодовой базы и общей сложности кода - готовые решения (если мы говорим про бизнес-приложения) содержат значительный объем функциональности, зачастую реализованный таким образом, что внедрится в него сложно
▪️обладания полными знаниями о проекте командой разработки
➕Более точная настройка ПО под существующие бизнес-процессы, а не наоборот
➕Сохранение чувствительных данных внутри компании
➕Проще расширять и масштабировать
❌Необходимость чётко документировать все процессы, связанные с разработкой: в случае потери информации - будет не у кого узнать «а почему так?»
❌Долгое погружения в проект: новым сотрудникам потребуется больше времени, чтобы выйти на уровень своей привычной эффективности

Приобретение
➕Вместе с покупкой ПО покупается и экспертиза: опыт, методология, актуальность, а эти знания зачастую будут полезнее, чем кажется
➕Поддержка поставщика может значительно сократить затрачиваемые на обеспечение работоспособности продукта ресурсы в течении всего срока его эксплуатации
❌Зависимость от поставщика и его стабильного существования в том числе
❌Стоимость дальнейших модификаций: Вам придется оплачивать труд не только команды разработки, а ещё и всех остальных сотрудников поставщика, от директора до уборщицы, что-то положить в карман владельцу

Если попытаться как-то подытожить эту на самом деле непростую тему, то есть две лёгких точки принятия решения
1️⃣Денег - много. Процессы - стабильны и не новы для рынка. Область - зарегулирована и/или критична. Выбираем покупку с полной поддержкой. Проблемы с конфиденциальностью можно решить NDA и помещением софта в собственный контур безопасности
2️⃣Автоматизируемый процесс является вспомогательным для компании и на рынке не существует 100% устраивающего решения - можно дать команде разработки поиграться,

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

#медведьразмышляет