Skip to Content

Sometimes you just need to ask for help

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.

You must be Logged on to comment or reply to a post.
  • I’m afraid that solving the “ask for help” problem is a bit of a Quixotic adventure.  It feels like the right problem to solve but the forces against it’s resolution…as you point out in your post…are too powerful to overcome.  But there is a solution and it’s firmly entrenched in the psyche of the Agile community…iterative learning. 

    No one should go from concept to full production in one step.  That’s just crazy. Furthermore, when you bring the system to a screeching halt, the last thing you want to do is call attention to yourself by asking for help.  But if you broke the goal down into smaller experimental increments and analyzed the performance data that you were getting, you’d probably realize that you were headed for a disaster.  Asking for help at that stage wouldn’t be so hard.

    If we focus the technical community on incremental and iterative learning, asking for help will come naturally.


    • I couldn’t agree more, I think all of us know when we have been guilty of being too optimistic, too convinced that we ‘must’ be able to solve the problem ourselves but I think that sometimes we are also blinded by the sheer magnitude of the problem and fail to return to fundamental processes like escalation. I have seen many posts on SCN and other forums that were questions for which the SAP CSS had a quick and bulls-eye response. One wonders whether these questions were asked through a support message. Additionally, on numerous projects I have asked whether a message was opened in response to a problem encountered and the initial response was er… um… no… People who have been burnt enough times eventually get it I guess.
  • Not really WinShuttle, as I’ve never used the product.

    There are times when we ask for help from vendors, and are told it’s a consulting issue.  Or that’s the way the software is supposed to work.   Or it can be fixed, but we have to pay for it.  Get enough answers like this, and asking for help seems futile.  (And a waste of time.)


    • Hi Michelle,

      No doubt the scenario you bring up is played out everyday and is quite frustrating.  Another wonderful Agile principle…Transparency…goes a long way to solve that problem.  This SAP Community Network is actually a great example of that.  If a vendor knows that there are no negative consequences to pushing back on your request, than it is in their short term benefit to not take responsibility for your issue.  However, if their goal is to “Delight” you because they know you have access to thousands of their customers with a simple forum or blog post or Tweet, than the balance of power has shifted.  I believe we all ought to learn how to use these new channels of communication and collaboration more effectively.  The upside…especially in markets where customers have options…are more responsive vendors.

      Try it.  See how powerful your voice can be 🙂


      • I agree. It is easy for a consultant to say ‘it’s meant to work that way’ or a change order can be instituted to make it work differently but I think we have a responsibility to make a noise even if it seems that we are shouting at waves like King Canute. No consultant can honestly say he/she knows it all and with the increasing complexity of solutions and the wide variety of business models and configurations, the more noise you make the more likely someone with a similar problem or past experience with that problem, is likely to hear you. Answers sometimes come from the most unlikely of places!
  • I would agree that we need to ask questions – but sometimes perhaps, people are not asking the right questions or perhaps not asking them in the right way.

    I’ve seen several excellent answers to the wrong problem. And it has to be said that sometimes, people will post a response taht assumes the person will understand exactly what they mean – but in many cases, they posted the question because they didn’t know enough in the first place.

    When you are still new to something, it is possible that you know what you mean, but you are unable to explain it to someone else in a way that they will understand. This has been an issue with IT from the early days.

    Worse, sometimes in forums comments made by new people are denigrated by others with more experience. I have seen numerous comments made that belittle the efforts of someone to ask for help – not exactly encouraging them to come back.

    • I think in forums like SDN/SCN unfortunately there is the underlying expectation that you do your due diligence before asking the question. Many newbies in particular spam multiple forums with the same question and are then suprised or disappointed when they get beaten up for this action. Secondly, some newbies really don’t do a modicum of research before asking the question and then it gets very frustrating for the forum participants and the moderators in particular  to answer the same question over and over again.

      We have a similar problem internally with sales people who seem to forget the things you tell them and keep asking the same questions over and over again. We resolved that in part through a searchable FAQ and on SDN Wikis would be analogous i guess.

      As far as answers are concerned, there are two types of answers that seem to prevail. A regurgitation of something published elsewhere, and a pinpoint answer; question asked and therefore answered. The regurgiations seem to be fairly commonplace, incredibly annoying and sometimes almost illegible because they are copy and pasted with malformed formatting.

      My comments were largely around the fact that barring questions posted in forums, people should still leverage the standard support protocols rather than thinking that they have to wander in the wilderness and hope for manna from the heavens to solve their system problems. 

      • Clinton,

        I understand what you mean – numerous posts asking exactly the question must get terribly frustrating particularly when the answer is in the FAQ or posted in response to the same question asked 2 days previously – and yes, I have seen those posts!

        In statistical analysis, there is a particular curve called the “ogive” curve – it looks like a stretched out S. I use this to describe the learning curve of most people when learning about new software. At the beginning, their knowledge level remains quite flat. Then after a while, it starts to increase slowly, but then  increases faster. Eventually, it flattens out again as the level at which they learn new material slows.

        I would suggest for the most part that people can only really communicate effectively within the quartile (25% area) in which they are positioned themselves. So those at the bottom can only really talk to others at the same level, as they have not yet learnt sufficient to be able to communicate effectively with people at a higher level. (They don’t yet understand the technical terms)

        Those at the higher level, forget how hard they found it when they started, and because they have learnt the “technospeak” of the particular product, they use it often without realising that they are no longer speaking the same language as those at the bottom level.

        Those at the highest levels generally speak in a way which makes perfect sense to them, bt is often confusing to those with less experience. They then get frustrated by those at lower levels – after all, it really is so simple isn’t it!

        And I would add that this is NOT unique to SAP – I would suggest that this is exactly the same for almost any software product you could name.