I have been involved in numerous conversations recently regarding problems a specific SAP customer is having with daily operations and during these conversations it struck me that something awful was happening and either being hidden under the proverbial ‘bushel’ or being contemplated internally without sharing the problem with outsiders. The issue primarily revolved around mass change and creation of materials using Winshuttle products, however as was revealed by a team of technically skilled resources, the issue was not the tool as much as the sheer volumes of data that were being shoved through the system. Needless to say, the business model probably required all these changes but running them multithreaded during the peak of an operations day indiscriminately and without due testing and in particular load testing was probably not the best way to use and abuse the system. Scripts written with any other tool like an LSMW script or BDC session or even custom ABAP would likely have led to the same outcome. Part of the ultimate solution is applying SAP notes, other applicable activities include planning the runs and applying some governance around who can run what when. These are all solid technology and process improvements.
There’s that old saying, a problem shared is a problem halved. It isn’t really true but it can lead to a faster solution or resolution of your problem simply through the power of more people with more experience and more perspectives, simply offering a potentially different perspective to the problem. In our personal relationships we likely engage in the same philosophy. Unless your spouse works in the same role and industry as you, it is likely that they can only relate to your occupational challenges on an analogous basis; those analogues can be useful nonetheless and the way the other person deals with the problem in the analog may provide clues to how you should solve your own problem.
failure to escalate a problem is a disservice to yourself and the company you work for
In the realm of technical issues, the more people with technical knowledge who get involved in trying to resolve the problem, usually, the better the outcome. This sharing the problem concept is not just important for the person or organization with the problem, it also important for the company that sells the technical solution or provides the technical skills. Product improvement only arises out of information sharing and gathering. A company that uses a given product and complains incessantly about it, publicly, but never shares the minutiae of the problem with the given product does itself and the supplier of the product a disservice. Naturally, the provider of the product or service needs to do their own research, their own exhaustive testing, their own scenario building and their own investigations but the feedback loop is critical.
A great support organization becomes one as a result of process, knowledge and application of both. I was amazed that this company had labored under sufferance for at least three months before the issue was escalated to the attention of support and product management only because sales saw an opportunity to make peace with the customer and concurrently up sell. Getting information out of this customer in the preceding weeks had been incredibly difficult, people had changed roles, the target seemed to be a moving one and more particularly no one seemed to have any precise information. There were a lot of rumors of course, a lot of hearsay and a lot of cooler talk but not solid information on which to base either an escalation or to pinpoint some opportunities to remediate the apparent problem. Most important of all, there was no support incident.
when machismo prevails over common sense
I’ve seen this type of issue before, not just with technology, not just in North America, it seems to be prevalent in the IT sector and it does seem to be characteristic of male dominated environments where perhaps machismo overwhelms common sense. In some cultural settings, despite technology and despite gender it definitely is not characteristic, in fact so much so, that it becomes characteristic of what is universally referred to as CYA or blame avoidance. These environments are however characterized by some degree of emasculation through either classism or the relegation of IT to a menial necessary evil service that is constantly under scrutiny from the higher ups.
the sting of criticism
Whatever the reason for the reticence in raising the red flag about a problem, as professionals in our field, we should try our level best to make others aware of the challenges we are having, even when we think we might be criticized for not doing appropriate housekeeping (like keeping application versions current, or cleaning out system logs) or for having malformed business practices (like running mass change or create jobs during peak productive hours).
These criticisms that get leveled at us by vendors, partners and our peers may reveal more useful information that just a sting from chastisement and may ultimately lead us to running our IT development and IT operations better. Certainly through sharing and appropriate escalation even if the problem isn’t halved, others will be more empathic and you move a little closer to finding a solution to the problem. At the very least, by providing information to support organizations, you provide a frame of reference for those who can support you in your operations and development quest, a frame that positions them to help others with possible solutions to problems that may have parallels to your own.
