The process of refining the process

By Mervyn George on May 24, 2011

It’s not easy to change the way we do things. We become accustomed to a process and before long the process becomes policy, and then we don’t realize that we are able to change it. Human nature leads us to make emotional decisions, to sway from logic and reason and choose the less practical approach. Sometimes these emotional decisions are the best decisions, but most of the time they’re not.

I have worked on several SAP implementations and the project environment varies significantly. There are a multitude of factors that influence the decisions we make on projects, as well as in the daily operation of ERP systems. A clash of cultures, a language barrier, the intentions of key players, the project and team location or even corporate baggage can all contribute to a well-executed, but completely inappropriate solution.

SAP customers aim to reduce costs and increase return on investment, while consulting companies want to maximize billable time and increase the number of seats on a project. Objectives of project leads differ and consultants’ working methods differ to that of in-house team members. The customer has a time constraint, while consultants have a methodology that requires time. All of this contributes to a clash of working cultures. Add a mix of nationalities, various office locations for global rollouts and a range of languages and the policy become more crucial. The pressure of keeping an engine running can often blind us from seeing ways to refine that policy and improve the process.

A common example would be what I call the ABAP addiction syndrome. It starts with a couple of very talented ABAP developers who convince the project team that they can develop anything. They put together a working, undocumented solution to perform a key function and then they leave the company. They charge a fortune to maintain the solution until the company hires a team of developers to figure out exactly what the solution does. The next few years are plagued with regression tests and compatibility discussions to see if any new functionality they introduce will work with this development. It all gets really messy after this point. I have seen a client so concerned about upgrading their SAP systems because their solution was heavily customized with code that they couldn’t guarantee it’s stability after the upgrade.

There are times when we need developers. They are also plenty of situations where we don’t. For many Winshuttle users this difference is already apparent. The policy has been refined and the process has been changed and improved. Easy-to-record upload scripts using Winshuttle Transaction replace unnecessary development time. Easy-to-design extraction scripts using Winshuttle Query cut down the waiting period to build ad-hoc reports and empower the business user to get the data they really need. Web services to extract and upload data via InfoPath forms or PDF documents are designed by the person who knows the business process and can identify where and how to optimize that process.

We often make emotional choices and we hope that the emotions lead us to the best choice. What we need to be looking for is the correct choice that allows us to optimize the way we spend our time.

Questions or comments about this article?

Tweet @mervynonline to continue the conversation!