В упрощенной интерпретации рестарт проекта – это фиксирование несоответствия реализованного функционала потребностям бизнеса при котором работа и использование системы наносит бо’льший финансовый вред чем ее не использование или продолжение работы в «старых» системах.

Рестарту в большей степени подвержена транзакционная ERP система, нежели информационное хранилище SAP BW, по сути рестарт SAP BW – это нонсенс. Существенной причиной возникновения такой необходимости видится только глобальный пересмотр реализуемой архитектуры влекущий за собой глубокий реинжиниринг проектных решений. Но даже в случае, когда наступает понимание что «все сделано не так» и работает «не туда», задачи по реинжинирингу архитектуры  и проектных решений SAP BW хорошо укладываются, например, в активность по переход на новую версию ПО, или в текущую доработку систему. При этом одновременно в системе SAP BW могут сосуществовать как старая реализация, так и новая (о потере производительности при таком подходе я умышленно умолчу…).

На практике не всегда причиной рестарта является некорректная реализация функционала, причина может скрываться в пресловутом человеческом факторе. Невозможность подготовить данные и закрыть период в ERP в обозначенный срок вынуждает начать процедуру подготовки данных нового периода с удалением из системы старых данных. Такой тип рестарта чаще встречается в период запуска системы, когда пользователям, по сути, приходится работать сразу в двух системах: старой учетной и новой ERP. Ошибка или задержка одного подразделения в этом случае ставят под удар всех. При этом одной из частых  практик опытно-промышленной эксплуатации является практика сохранения введенных данных для использования в промышленной эксплуатации - экономия ресурсов компании на выполнении одних и те же операции дважды, т.е. ОПЭ может организовываться на продуктивных данных.

Чтобы завершить ввод данных ОПЭ и выполнить тестирование закрытия периода и одновременно начать подготовку продуктивных данных следующего периода, в ERP могут поступить достаточно просто: сделать копию текущего манданта в той же системе. В откопированном манданте пользователи продолжают добивать данные, разработчики отлаживают механизмы закрытия периода, основной мандант очищается и в нем выполняется ввод данных только нового периода.

Казалось бы, очень простая операция для ERP – копирование манданта, но она сопровождается далеко идущими последствиями для SAP BW. Причина кроется в организации таблиц системы: таблицы ERP манданто-зависимы и при копировании манданта происходит копирование и данных в таблицах; копирование манданта BW не имеет смысла т.к. таблицы с данными в BW манданто-независимые. Для SAP BW размножение и деление ERP на манданты является фактором который  требует перестройки информационного хранилища и