This website is not affiliated with, sponsored by, or approved by SAP AG.

ST22 - Organizational Question

Basis (Basis Technology Modules: Basis Component/System Administration, GUIs)

Moderators: Snowy, thx4allthefish

ST22 - Organizational Question

Postby Martin_US » Wed Apr 03, 2013 5:36 am

Hi Guys,

I used to work for a company that collected on a daily basis about 140 entries in ST22.
Needles to say, that was a mess. Problem is you have to have someone responsible for that stuff in the organization. Now the issue on hand is that ST22 can have entries from any functional or technical area. Even if you go by transaction, the business may still divide that into different areas of responsibility. Even the transaction code may have nothing to do with the underlying problem.

So, how would you go about it and get ST22 cleaned up?

I mean you can't just send a mail around to everyone asking them to have a look.
That's kind of silly.
Martin_US
 
Posts: 663
Joined: Thu Nov 07, 2002 9:40 am
Location: Walking amidst the Stars

Re: ST22 - Organizational Question

Postby Zavaros » Thu Apr 04, 2013 6:57 am

Hello,

Each company should have some kind of a ticketing tool with implemented incident and problem management.
... and of course there should be some nice KPIs and a team that tracks the tickets and escalates if they do not move as should.

So the solution is to open incident about each dump (and demand RCA).
If the ABAP dump is systematic but the cause is not trivial then you should open a problem ticket about it.

Regards,
Zav

PS: often the Customer is not interested in reducing the amount of dumps ... or does not have resources to bother with it.
Zavaros
 
Posts: 756
Joined: Thu Oct 24, 2002 10:50 pm
Location: Hungary

Re: ST22 - Organizational Question

Postby blueteeth » Thu Apr 04, 2013 9:21 am

I'd say, ABAP dumps can be broadly classified into three:

System Errors
Program Errors
Time Outs

System Errors & Program Errors have to be addressed by SAP Technical Team. There is little point in assigning the responsibility to business user.

Time outs can be discussed with user and strategy be developed (like running background jobs, specific application servers etc.). This is in addition to tuning SAP system.

Of course, there are background jobs which cleans up ST22 dumps.

Regards,
BT
blueteeth
 
Posts: 499
Joined: Sat Apr 05, 2008 12:22 pm

Re: ST22 - Organizational Question

Postby Martin_US » Thu Apr 04, 2013 10:05 am

Well,

what I have experienced with that company were very different problems.
i.e. programs that run fine when executed interactively and fail when running in batch. That's an ABAP problem.

Other issues were due to SAP errors and fixed with patches. I would assume those to be under functional investigation.

Then you have custom functionality and that's a grey area.

Finally you may have shared functionality. i.e. Billing is sued in service as well as in regular sales and spare parts. Thus you may have three different departments, but the same transaction code.

Understanding dumps and their cause is very difficult and when you have transaction that fail and postings aren't done, you can't just wipe out ST22. In my case we had € 8 Million of sales not posted into finance.
Martin_US
 
Posts: 663
Joined: Thu Nov 07, 2002 9:40 am
Location: Walking amidst the Stars

Re: ST22 - Organizational Question

Postby waltersen » Fri Apr 05, 2013 7:04 am

Hello,

I (as tester and last level support) am on the same line as Zavaros. If a end user is annoyed by the dump, he shall open an incident. That goes back to IT and can not be ignored. We get emails for every dump, which I collect in a special folder. I have a view on that folder every day. Normaly I do not care about them (see above, if it is really important, you get a ticket and have to react, change etc.)

What is important, if there is the same dump mabe 20 or 30 times. This can not be normal and should be researched. Well the company should have something like a running the system concept (user help desk, tickets with incident and problem management, changes, are chages put together in releases, monitoring...) I would contact the person who is responsible for that.

When I have a dump as a tester in qas i try to reproduce it. If that works I contact the architect (your problem now) and write a deviation. When testing the change, which solves the deviation, the dump should have gone.

Nice weekend to you
waltersen
 
Posts: 251
Joined: Wed Oct 13, 2004 7:03 am
Location: Hamburg, Germany

Re: ST22 - Organizational Question

Postby Martin_US » Fri Apr 05, 2013 10:05 am

Well Walter,

in an ideal world, I would happen to agree. Unfortunately the world isn't perfect.
BTW, it was a German company were I had this experience and not even a small one.

The IT director assumed their service partner would take care of dumps, they surely don't.
When I showed him the mess, he was baffled.

They did have a ticketing system, but frequently the users either didn't bother or would never even see the dump.
The staff was fairly old and often created BDC sessions out of programs that failed.

I will drop the subject as I know the ideal world very well, but unfortunately that's what we never see in real life.
Martin_US
 
Posts: 663
Joined: Thu Nov 07, 2002 9:40 am
Location: Walking amidst the Stars

Re: ST22 - Organizational Question

Postby Zavaros » Sun Apr 07, 2013 2:19 am

Hello,
Martin_US wrote:They did have a ticketing system, but frequently the users either didn't bother or would never even see the dump.
The staff was fairly old and often created BDC sessions out of programs that failed.


Without positive attitude of involved parties the dumps can not be eliminated.
There are no doubts that BC experts can find solution for most of the ABAP dumps.
Nevertheless without permission you can not do any change in the that affect the users (or has financial impact).

in case of the failed BDCs ... you should find the responsible for that business process and ask him to change the session (in ideal world). In real world it could be that that BDC session was forgotten by users and gods and nobody care about its output ... in this case you are in trouble: nobody will dare allowing you to repair/kill that bugged session.

Regards,
Zav
Zavaros
 
Posts: 756
Joined: Thu Oct 24, 2002 10:50 pm
Location: Hungary

Re: ST22 - Organizational Question

Postby Martin_US » Sun Apr 07, 2013 11:28 am

Well Zav,

you face the problem of any consultant. People hate change. They are so used to their ways and can not imagine anything else.

And yes, part of the problem is very bad IT management. I kid you not, the ABAP guys didn't now what BAPI's are. I gave them training on SE37. When I saw the amount of BDC sessions created each day and the failed ones and when I brought it up, I got answers like "yes, we know", but no one wanted to fix that.

All that in turn made me close my Laptop and walk out of the building.

Sadly, there are quite a few companies like that.
Martin_US
 
Posts: 663
Joined: Thu Nov 07, 2002 9:40 am
Location: Walking amidst the Stars

Re: ST22 - Organizational Question

Postby waltersen » Mon Apr 08, 2013 3:24 am

Hello,

if the people do not want a change, why are they calling a consultant? Maybe my IT Organisation is not brilliant, but it is verry solid. We have an User Help Desk, Incident and Problem Management. Also first (non IT) and last level support (IT).

We put together our changes (coming from requests/projects, incidents, deviations) to releases. There are architects and tester and they communicate with the programming people and the basis guys.

I can speak only for my organisation, as a consult you have the advantage to see many.

Waltersen
waltersen
 
Posts: 251
Joined: Wed Oct 13, 2004 7:03 am
Location: Hamburg, Germany

Re: ST22 - Organizational Question

Postby Martin_US » Mon Apr 08, 2013 6:31 am

Good question as to why they hire consultants.

Possible answer is that there is apparently "some work" to be done and hope is there the problem will go away.
Your company seems to be quite well organized.

I have seriously seen all kinds of crap.

There was a Germany company with a subsidary in France. Germany was using SAP since R/2 times and France was trying to implement Oracle. Mind you, same line of business. After France has burned a few million Euros and didn't get up and running, they wanted to port SAP for the French company. First thing being done is setting a project deadline without doing a system readiness acessment.

Now, SAP had about 24.000 Z* objects. Impossible to know which are still used or how frequently.
Worst, texts and messages were hardcoded in German, thus forget about SAP translation tools.
Absolute everything was hardcoded by plant or sales organization.

According to a consulting firm, they estimated the translation alone to take about a year. Any and all documentation was in German as well.

IT didn't even had a concept on how to setup the landscape in order to support the live stream and development stream during the transition. Which is actually quite simple to do with SAP, if one has experience.

I guess the point I am driving is unrealistic time lines right from the start. There is nothing wrong with setting up an agressive schedule, but please, if consultants come in and role their eyes within 10 min of joining a project, you should exchange the IT management.

I once worked at a very large food company. The project manager showed me the project plan. Goal was to bring a number of legacy systems from various subsidaries onto SAP in an overlapping wave approach. Meaning when one company goes live you would have half done programs and configuration of the next project in production. That cannot work. 6 month later they realized that and pulled the plug on that idea.

I guess IT management is frequently ignoring consultants or as you would say in German are "beratungsresistent".
Only to find out later that the sh*t hits the fan full force.

They keep taling about SDLC, Scrum vs. Waterfall, Best Practise and all those fancy catch phrases without even knowing what that implies. Everything that goes beyond "Green, Yellow, Red" on the Powerpoint to the Steering Comittee is to complicated.
Martin_US
 
Posts: 663
Joined: Thu Nov 07, 2002 9:40 am
Location: Walking amidst the Stars


Return to Basis

Who is online

Users browsing this forum: No registered users and 7 guests





loading...


This website is not affiliated with, sponsored by, or approved by SAP AG.