Судя по опыту и исследованиям - в РФ существует определенная специфика внедрения.
Одной из важнейших ценностей для многих является гибкость ИТ-системы. Потому что бизнес-процессы считаются незыблемыми, и ПО должно максимально под них подстроиться.
На Западе при внедрении несколько чаще не только адаптируют ПО под процессы, но и процессы под ПО, исходя из того, что в ПО, как правило, уже заложены лучшие практики. И такое изменение процессов - один из важных бонусов внедрения. В России почти каждая компания считает себя уникальной. Выстраивает не всегда эффективные процессы (с множеством workarounds), а затем стремится полностью подогнать ИТ-системы под эти процессы. При этом зачастую, если процессы не описаны, а исходные создатели успели уволиться - никто даже вспомнить не может, почему процесс выстроен именно так. И если такие процессы подвергнуть критическому анализу - вполне может выясниться, что исходные причины давно изменились, и процесс можно сделать более простым и эффективным.
Будьте уникальными (особенно в вашем core-продукте). Адаптируйте или разрабатывайте свой софт под ваши уникальные процессы (особенно если они эффективны). Но старайтесь по максимуму использовать лучшие практики (особенно в области поддерживающих и вспомогательных процессов). Уже очень много есть классного софта и просто прикиньте, как в этом софте можно выстроить процессы, как если бы вы настраивали эти процессы с нуля.
Корни этого, возможно, растут в том, что в РФ люди на местах мало ощущают свою ценность и признание, что и может приводить к стремлению сделать "уникальные" процессы. Поэтому если вы внедряете ПО, которое будет стандартизировать деятельность людей, - подумайте о том, как сможете вовлечь их, где сможете предоставить свободу творчества. И, конечно, доверяйте. Если вы за них продумываете все шаги, оставляя им роль только исполнителей.. Ставьте цели и давайте общий фреймворк. И только если этого будет мало - подключайтесь и помогайте.
На другой чаше весов лежит не вендоро-независимость, а зависимость от штатных разработчиков. Если они уходят, много времени и ресурсов тратится на то, чтобы разобраться в коде. Это и прямые финансовые потери, и репутационные риски.
Самописные системы имеют много плюсов, но для их полной реализации необходимы хорошо поставленные процессы разработки, когда в проект погружено как минимум несколько разработчиков, код подробно и понятно задокументирован и т.д.