Change Management: Transport Management System Planning (Part I)

Below is a snippet from one of hundreds of articles available to ERPtips subscribers.

If you would like a complimentary copy of the full article, please email
Mark.Downs@ERPtips.com
(include the title of the article in your email)

To subscribe to ERPtips, go to
www.ERPtips.com/Subscribe.asp.

ERPtips Journal is published by Klee Associates, Inc.

ERPtips University provides both public and onsite training for SAP clients.
For more about ERPtips University, including the current schedule, click here:
www.ERPtips.com/WorkshopSchedule.asp

Change Management: Transport Management System Planning (Part I)

TMS can cause a heck of a lot of headaches. The reason TMS is so tricky? Because TMS is
assigned the serious task of making sure that any technical changes you make to your SAP
system are “carried downstream” and properly adjusted on all “live” production systems. There`s enough

Click here to read this Snippet

 SAPtipsJournal
Page 3
Oct./Nov. 2004 Volume II Issue 5
Based on the client strategy shown
in Figure 2, Figure 3 illustrates a
change control process.
Figure 3 shows a basic change
control process. This is one process
that needs to be rock solid and com-
municated and understood by every
member of the project/SAP support
team. Since I feel so strongly about
this topic, during a new implementa-
tion I usually give a few presentations
regarding the change control process
prior to entering into the “Realiza-
tion” phase of the implementation.
The “Realization” phase is the third
phase of SAP’s ASAP implementa-
tion methodology. In short, it is when
the configuration and development
starts. I go so far as to make every
new member of the project team
attend a change control presentation
prior to granting the user access to
the SAP systems. In my opinion, it’s
that important.
Technical Implementation
The technical implementation
of the plan focuses on the techni-
cal “how” of the process. This sec-
tion provides a follow through on the
change control process. Let’s keep
building on our previous example.
Figure 4 shows the technical imple-
mentation based on Figure 3, Sample
Change Control Process. The techni-
cal implementation is highlighted in
SAPtipsJournal
RED.
There is great value in explicitly
specifying all the technical detail of
each process in order to prove com-
parability. When I say comparabil-
ity, let me be more specific so read-
ers understand what I am trying to
point out. A transport can be moved
in many different ways. Here are just
a few:
• manually on the command line
• via a custom script
• via the transaction code STMS
The end result is the same if done
1. Team member creates transport in Development Client 100.
2. Transport is approved and released by Team Lead in Development Client 100.
3. Transport moves on the _ hour to Development Client 200.
4. Team member tests in Development Client 200.
5. If correction is necessary, another transport is created in Development Client 100.
6. Transports move to Quality Client 100 at 6 p.m., daily.
7. Team Leads approve their respective transports via transaction code STMS_QA.
8. Basis gives final approval into STMS_QA.
9. Approved transports move to Production Client at 6 p.m.
Figure 3: Sample Change Control Process
1. Team member creates transport in Development Client 100.
a. Users have security access to create transports.
b. Development Client 100 is set in table T000 for:
i. Automatic recording of changes
ii. Permitting client independent and repository changes
2. Transport is approved and released by Team Lead in Development Client 100
a. Only Team Lead have security access to release transport requests
3. Transport moves on the 1/2 hour to Development Client 200
a. An automated shell (environment in UNIX) script, imp_all.sh, scheduled in cron
(scheduling mechanism in UNIX) runs every _ hour to import all released transports
with no unconditional codes (codes which change behavior of importation) into
Development Client 200 based on the transport buffer(a file that gets populated
after the preceding transport processes are fulfilled) of the Quality System.
4. Team member tests in Development Client 200
a. Team members performs transactions in Development Client 200 based on configu-
ration/development.
5. Transports move to Quality Client 100 at 6pm daily
a. STMS is configured with:
i. Queue-controlled transports, mass transports
ii. Quality Assurance approval procedure
b. Import all is scheduled via TMS
6. Team Leads approve their respective transports via transaction code STMS_QA
a. STMS is configured with:
i. Queue-controlled transports, mass transports
ii. Quality Assurance approval procedure
b. Only Team Leads have security access to approve transport requests.
7. Basis give final approval into STMS_QA
a. STMS is configured with:
i. Queue-controlled transports, mass transports
ii. Quality Assurance approval procedure
8. Approved transports move to Production Client at 6pm
a. STMS is configured with:
i. Queue-controlled transports, mass transports
ii. Quality Assurance approval procedure
b. “Import all” is scheduled via TMS
Figure 4: Technical Implementation of TMS
SAPtips.com SAPtips © 2004 Klee Associates, Inc.
 SAPtipsJournal
Page 4
Oct./Nov. 2004 Volume II Issue 5
correctly, with that particular end
state in mind.
However, suppose that when the
Basis administrator was importing
the transport manually, he made a
typo; or if he used the transaction
code, he selected the wrong icon for
importation. Although the intentions
are to have the same end result, a dif-
ferent method may produce a differ-
Top 5 Most Frequently
Asked TMS Questions
1. Q. “I transported this table entry, but
it does not show up in my target
client.”
A. The transport does not specify the
particular record to be moved. Trans-
ports only do what you tell them.
2. Q. “What is TMS?”
A. Back to Change Management 101.
3. Q. “Can I back out of a transport?”
A. Sure, create another transport
to “undo” your change that was
implemented by that transport in
question. This is the only viable
solution, because organically within
standard SAP, “backing out” a change
is not possible. Third-party tools
that claim this functionality merely
take a backup of the objects prior to
importation.
SAPtipsJournal
4. Q. “What is a transport?”
A. SAP calls it a transport or change
request; both are used interchange-
ably. This object functions as the
vehicle for change. Change requests
are hierarchical, where the top level is
the change request and the subordi-
nate level is the task. Change can be
assigned to the change request or the
task.
5. Q. “Can I delete a change request
imported into the target system?”
A. No, the way to fix an erred transport
is to create another one with the cor-
rect settings.
ent outcome. Here is an actual project
example which highlights this point:
When I came to one of my most
recent implementation, coinciden-
tally, to fix a “broken” TMS system,
the Basis administrator in charge of
TMS was always typing like a mad-
man. “Strange?” I thought so. Well,
it turns out that this TMS guy was
importing transports manually via
the command line.
What a nightmare! Not only can
he potentially make errors in his
commands, from time to time, he is
invariably going to type the wrong
transport to move into the wrong
system and/or client. True enough,
the process was flawed, and as I
suspected, he often mistyped the
transport number and target cli-
ent. How easy do you think it is to
type DEVK901002 when you meant
DEVK901003? Enough said. Main-
taining and documenting comparable
processes is tremendously important,
only so that you can review/audit the
technical process.
Here is another example from
the opposite angle. One day, on the
same implementation as the prior
example, a team lead complained
that an object he had transported did
not show up in the target client. He
immediately jumped to the conclu-
sion that the transport mechanism
was broken and that the clients in
the landscape were all inconsistent.
It turned out that the object that he
wanted to transport was not specified
in the transport. Easy answer: he did
not include that object in the trans-
port. But additionally, after identi-
fying and resolving his issue, I was
also able to document the correct
procedure so that the client would
repeat the exact same process for
each transport. By using the method
of comparability, I could also say that
the technical process was the same for
the transport before the one in ques-
tion, as well as all the ones before
and after. This consistency helps the
SAPtips.com
Basis team with troubleshooting, but
more importantly, demonstrates to
the project team that all transports
are handled in the same manner.
Conclusion
In the first part of this article series,
we defined the major components
of a good TMS strategy, review-
ing client strategy, change control
processes, and the technical imple-
mentation itself. Some frequently
asked questions and some lessons
from the school of hard SAP knocks
were thrown in for good measure. In
Part II of this article series, which
will appear in the Dec/Jan edition of
SAPtips, we will describe the techni-
cal “How to’s” of Transport Manage-
ment.
Change Management the SAP way
can prove to be very challenging.
From experience, it always makes
sense to have a solid plan before
jumping into the realization phase.
There are many ways that change
management can succeed, but just as
many factors in the opposite direc-
tion. After solidifying a solid plan
technically and procedurally, the next
major influx of errors and complaints
you’ll have to address are from your
users. Be prepared for their questions,
concerns, and complaints. I have said
this in previous articles, but it bears
repeating: prior planning prevents
poor performance.
Joey Hirao, Jotech LLC. Joey is a
Basis consultant with expertise in
SAP Basis, UNIX, NT, and database
technologies. He designs, imple-
ments and maintains SAP systems
for customers worldwide. Joey has
been working with SAP technol-
ogy for the past six years. He is the
founder of Jotech LLC, and the
author of SAP R/3 Administration
for Dummies. Joey is SAP Basis cer-
tified, Solaris Administrator certified,
and a MCSE. Joey’s email address is
Joey.Hirao@SAPtips.com. ≈
SAPtips © 2004 Klee Associates, Inc.