И как же связаны "параллельность" и тр. SCI?

Практически в любом языке есть возможность организовать параллельные вычисления. Ну породите задачу в новом диалоговом процессе. Или фоновом. И ждите себе результатов в основном диалоге. И так до исчерпания доступных процессов.
Только не забудьте запастись каской, предохраняющей от удара молотком со стороны базиса.

Причём здесь всё это?
Речь идёт о том что есть, например,

А диалоговый процесс, сам посебе, без изменений в коде, одновременно на процессоре 1 выполняет код form A ..., а на процессоре 2 выполняет код form B ...

А толку? Выполнение подпрограмм последовательное, а не параллельное.

Ну так про это речь с самого старта темы - что хочется секретную опцию что-бы было параллельное.

А нафига , простите за пафос.
У Вас появились вычислительные задачи в рамках SAP, которые требуют неслабых процессорных мощностей? Причем, хотелось бы заметить, еще и не использующие базу данных, во всяком случае не проводящие там изменения в рамках стандартных транзакций.
Если да, и Вы научитесь таки в рамках одного диалога/фона грузить все доступные процессоры, тогда молоток у базисника будет ещё больше

Тяжело представить такую возможность перехода из последовательного выполнения в параллельное без переделки логики программы. Параллельность возможна на уровне сессий, а в рамках одной программы (сессии), разве что автоматическую балансировку при выборе менее загруженного процессора при выполнении модуля в рамках одной программы.

Вопрос параллельности вычислений намного сложнее, чем кажется на первый взгляд. И сложность даже не в логике программ, а в особенности связки ядра операционной системы и вычислительной архитектуры. Насколько мне известно, наиболее популярные архитектуры (Intel-win, RISC - Unix) готовы распараллеливать вычислительные процессы на уровне т.н. вычислительных нитей.

Например, если сидят 500 пользователей и колотят документы, то этот процесс создает множество коротких тразакций к БД происходящих в одно и то же время, которые преобразуется в великое множество этих самых нитей. Распараллеливание ведется путем разделения нитей на несколько пучков, в зависимости от количества процессоров.

Другой вариант, когда один пользователь запустил обычный отчет. В ходе работы этого отчета возможно создание нескольких параллельных селектов(а в некоторых отчетах это не возможно в принципе). Несколько селектов, происходящих одновременно могут создавать так же несколько пучков вычислительных нитей. Вот этот вариант можно рассмотреть при реализации на ABAP.

И наконец, третий вариант. Запускается отчет с применением длинной выборки (к приметру пресловутая пузырьковая сортировка). Так вот, такой процесс в названной архитектуре не распараллеливается. Его конечно можно заставить ветвиться если применить какой нибудь сопроцессор (вспомните старенький математический сопроцессор или современные графические карты) и какой нибудь драйвер к нему, можно реализовать путем дополнительного программного модуля на уровне операционной системы, но тогда расходы на обслуживание этого модуля возрастут на столько , что его применение станет не нужным. Кстати, работа некоторых внутренних процессов BW как раз таки этот случай. Поэтому не удивляйтесь, если вы перенесете производство BW-ных отчетов на многопроцессорную системы, а повышения производтельности не получите. Это точно, проверено уже.