Добрый день!
Возможно, заголовок не совсем соответствует сути данной темы, но есть весьма актуальная проблема и хотелось бы ознакомиться с вашим опытом организации процесса управления изменениями в SAP-системе.
Если тема поднималась ранее, то прошу кинуть в меня ссылкой.
Итак, классика. 3 системы: DEV->QAS->PRD с настроенным транспортом.
В системе разработки (DEV) производятся настройки, разработка программного кода и предварительное тестирование. В системе контроля качества (QAS) производится эталонное тестирование и обучение. В продуктивной системе (PRD) производится промышленная эксплуатация ПО.

В идеальной бизнес среде существует циклы в последовательности: разработка - тестирование - эксплуатация - разработка и т.д. (не рассматриваю возвращение на доработку из тестирования). На практике задачи по доработке поступают одна за другой, при этом они имеют разный приоритет. От приоритета зависит очередность разработки и тестирования. Трудоемкость и срок как правило не учитывается. Поэтому зачастую цикл нарушается и возникает следующие ситуации (утрировано):
I. Объект А в PRD.
1. Объект А изменен в DEV по задаче 1, становится A’, далее транспортный запрос деблокируется и переносится в QAS.
2. Объект А’ изменен в DEV с высшим приоритетом по задаче 2. Становится А’’. Транспортный запрос деблокируется и переносится в QAS. В соответствии с приоритетом, тестирование функциональности объекта A’ останавливается и производится тестирование функциональности объект A’’. Тестирование успешно – подлежит переносу в PRD. Однако функциональность объекта A’ не прошла эталонного тестирования и не должна быть перенесена в PRD. Что делать с A’, а точнее с его запросом?
II. Объект B в PRD.
1. Объект B изменен в DEV по задаче 1, становится B’.
2. Объект B изменен в DEV с высшим приоритетом по задаче 2, становится B’’ в том же транспортном запросе. В соответствии с приоритетом, производится тестирование функциональности объекта B’’. Тестирование успешно – подлежит переносу в QAS. Что делать с изменениями объекта B’?
Ответ на вопрос у меня есть - в нашем случае, это "пляска с бубном", манипуляции с транспортными запросами, зачастую нарушение принципов разработки в одной системе, т.к. приходится исправлять объекты в системе QAS, для того, чтобы не переносить в PRD не протестированную функциональность, что, разумеется, не может положительно сказаться как на производительности процесса изменений (приходится вручную перебрасывать объекты транспортных запросов, комментировать не уместный программный код и т.д.), так и на стабильности программного кода.
Проблема, очевидно, в дисциплине процесса имплементации разработок. Но бизнес не желает дисциплинироваться и, по-правде говоря, имеет на это право, т.к. обеспечивает фин. ресурсом и заказывает музыку.
---------------------------------------------------------------------------------------------------
Могли бы вы описать как в вашем случае реализуется многопоточная разработка?
Спасибо!

Добрый день. А может 1 разработка = 1 запрос ?

Как представитель разработчика я всеми руками "за"! Я называю это дисциплиной имплементации разработок, или другими словами соблюдением последовательности.
Но бизнес такое положение дел не удовлетворяет. В условиях конкуренции бизнес должен быть гибким, поэтому хотелки поступают каждый день. При этом копится очередь хотелок, которые мы пытаемся ранжировать по приоритету и согласовываем этот приоритет с заказчиком. Но наступает момент, когда поступает хотелка с высшим приоритетом или одна из очереди внезапно становится более важнее, чем та хотелка, которая в настоящее время реализуется. В итоге, имеем то, что имеем.

Change Request Management может в эту сторону нужно посмотреть?
запишитесь на EGI-сессию и задайте вопросы о наболевшем эксперту...

когда очередь "хотелок" напоминает о бренности бытия..

скорее о неизбежности бития...

Добрый день.

Мне кажется в вашем случае надо сделать релизную схему переноса разработок, т.е. расширить ландшафт систем (попробую нарисовать с помощью текста):
DEV -> QAS -> PRD
DEH -> QAH -> PRD

Таким образом системы DEV и QAS используются для основной разработки, а системы DEH и QAH для срочных исправлений. Но встает проблема их выравнивания между собой, эту процедуру можно выполнять или в ручном режиме или в автоматическом.

Это реальная схема из жизни.

Спасибо, что откликнулись!
Буду бесконечно признателен, если подробнее опишите процедуру выравнивания. То, как это происходит в схеме из жизни.