Во вселенной SAP сложились жёсткие границы между специалистами из разных областей. Каждый выполняет свои задачи, не выходя за пределы той области, в которой он специализируется. Функциональный консультант делает настройки в SPRO и пишет ТЗ для разработчика, разработчик пишет программы, создаёт объекты словаря, реализуя ТЗ, а администратор после всех этих действий обеспечивает работоспособность системы.

Обучение и подготовка специалистов также осуществляется в рамках этих чётко определённых границ, однако это приводит к тому, что порой даже опытные консультанты не имеют представления об общих и элементарных процессах, происходящих в SAP. Как результат, зачастую они не понимают, как производимые ими настройки и разработки могут повлиять на работоспособность системы в целом. Например, в треке подготовки ABAP-разработчика первый рекомендуемый курс - SAPTEC, описывающий базовые процессы и основные принципы работы SAP, но я не знаю ни одного разработчика, который бы его прослушал. При этом, я встречал таких, кто отвечал на предложение оптимизировать часть кода следующим образом: «Я написал программу, а как она там работает, меня не интересует».

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

Знакомство с архитектурой SAP обычно начинается с рисунка архитектуры самой системы (рисунок 1), и далее, в зависимости от требуемой глубины знаний, описываются функции представленных на рисунке блоков. Рассказ получается достаточно скучный, и аудитории без предварительной подготовки