На эту тему можно долго рассуждать, но общие правила:
1. Консультант сам должен знать стандартную функциональность. Многие переделки имеют в основе то, что архитектор или консультант просто не до конца понимают, как настроить стандартный функционал под требования клиентов. Настроить, как правило, можно. Но надо знать, чем, например, freight terms отличается от FOB.
2. Консультант должен научить ключевых пользователей основам стандартной функциональности системы. Они должны весьма ясно представлять свои процессы "from ... to ...". А настраивая типы документов или параметры финансов, надо разъяснить суть каждого из настраиваемых параметров. Любая ошибка на этом этапе может оказаться критичной - впоследствии переделки потребуются как раз для исправления неправильных первоначальных настроек (конечно, многие из них можно менять по ходу эксплуатации, но не все, да и еще ведь не догадаются поменять, начнут вместо этого код писать).
3. Собрать полные требования. Бизнес может не выдвинуть некоторых требований, которые очень желательно реализовать уже при первоначальной настройке. Например, люди от бизнеса могут просто не знать про электронное утверждение документов, потому что раньше они этого не делали. Это не значит, что настраивать workflow не нужно.
4. Никогда не трогать переделками самых основ! Например, если вы хотите чтобы у вас сначала создавался инвойс по ЗП, а уже потом ЗП, то вы хотите чего-то противоестественного.
5. Соображать. Уметь "подниматься над проблемой" и предлагать оптимальные решения. Например, если вас просят совместить два плана счетов в одной ГК, то может быть, на самом деле клиенту нужны две ГК?

Конечно, в системе есть много мест, которые не только можно переделывать, но и нужно. Но такие переделки не подходят под определение "масштабные изменения".