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.
Over the last few weeks, I’ve been asked by customers and prospects what it takes to be a Rev-Trac Administrator. There is often confusion around what an administrator does, compared to a high level release manager or production approver. Often people assume that because they are performing an approval of a more important or critical nature, that they will require special training or administrative privileges. This is not necessarily the case.