I recently caught up with an SAP support team manager at a customer who has been using Rev-Trac change control automation software for about 4 years. At the time of implementing Rev-Trac, the customer was a “Green Field” SAP installation. This meant Rev-Trac was installed with the initial SAP systems and every transport from the very first development transport created has been tracked and change controlled using Rev-Trac. I asked what some of the most valuable benefits were Rev-Trac had brought to the support team.
It is quite common for customers to outsource their SAP system support to external partners or a System Integrator (SI). Last week I visited Mumbai, India to train a new System Integrator team (new SI) to support Rev-Trac on behalf of one of our larger customers. When we looked under the covers to identify how Rev-Trac change control automation was being used, we found some disturbing results.
I’m not sure about you but I think I heard this phrase, or similar variations, hundreds of times from my parents. I believe the entire quote is “If something is worth doing, do it right the first time.” Eventually, I saw the wisdom in this simple saying. After all, who wants to have to do things over again – and the larger the project, the larger the effort to do it a second or third time.
A few of our customers have asked us about the ability to put a change control process around Rev-Trac configuration modifications. It often a tricky subject to discuss, as there is an irony in the need to put Change Control around the Change Control tool. As Rev-Trac is written in ABAP and runs as a transaction in SAP, it is possible for organizations to benefit from the use of multiple Rev-Trac instances; at least a Development and a Production environment.
“It’s not the strongest of the species to survive, nor the most intelligent, but the ones more responsive to change.” – Charles Darwin. Rev-Trac change control automation functionality can help your processes evolve naturally. Here are some ways cited by RSC customers…
A customer emailed an interesting account of a recent RSC consulting engagement and allowed me to share it anonymously for benefit of other Rev-Trac users. What follows is lightly edited for readability.
Our newest Melbourne based customer has been implementing Rev-Trac for an environment which has a fixed 2 tier BAU (support) track and project track. In this particular case, there are different outsourced partners managing each environment and I am training the Basis staff from each environment on how to administer Rev-Trac.
Over the past month I’ve spent some time with a few of our Melbourne based customers. One customer ran me through the methods they were using to perform reapplications of BAU changes to a project track. The customer was benefiting from the Rev-Trac’s OOPS Overwrite Foreign reports, which identifies any changes in the project track, about to be overwritten by BAU support changes.
Early this month I joined the RSC team at our headquarters in Melbourne to help work on Rev-Trac 7. One of my last engagements in Europe involved some issues with a customer who was experiencing volatile connectivity across one of their key landscapes, which was in a project building phase.
The issue was that the customer would approve development transports for release and migration to the QA or Pre-Production environment and TMS would return a code indicating that the system was unavailable, and in some cases would hang.
Since last month’s post about the various roles of different types of Rev-Trac Administrators, I have had several inquiries about the training and consulting that is available from RSC.