SAP Maintenance transport requests work flow

An example of a basic principle and flow is:-

1. A request for a change is submitted to support team

2. Change is done in DEV (if approved) and tested by support team (limited testing only due to lack of productive data)

3. Change is transported to TST

4. User testing takes place

5. User approves or rejects (giving reasons)

6. System manager approves the change to go into PRD

7. Change is transported to PRD

All transports are done by the support team.

If a change is urgent it is transported straight away, if not they are batched up and done once a week.

The Workflow can be controlled by a software like a Lotus Notes database so you can have a record of approval at every step.

Note :-

The system manager is the manager of the support team. The system "belongs" to him i.e. it is his responsibility and he has the final say on what goes into the PRD system. 99.999% of the time he will approves the change, this is mainly a way of keeping him informed of what changes are happening in the system.

Many companies uses the core modules MM, PP, FI, CO. The problem with transporting single transports is that if it is a program, the complete program buffer is reloaded therefore giving a performance hit. Therefore you tend to leave them and just have one performance hit per week (although most weeks there are no program changes). When you are in production the number of transports will settle down to a reasonable figure. Maybe about 10 transports a week, and most of those are material groups (which, although they are user data, they are classed as customising). This rises if you are doing any modifications or changing business processes etc, but 10 is about quite normal for most.