Risks of automating transactions in master data management (Winshuttle)

[Former Member]

This product is being introduced at a client.

Some of the users are not technical and I understand it can be used for master data maintenance.

There seems to be acceptance of the package on the basis that it follows SAP authorisations, but it strikes me that by enabling automation, particulary of master data changes, it changes the nature of the authorisations.

i.e. It is one thing to be able to change material masterdata. If you make a mistake, it will not be a problem, but if you can now change ALL the material master data in one go, this has a significant risk. Therefore this should be signed off as tested in Q before it can happen on the production system.

Has anyone else encountered this product and am I right to be concerned about it being used without controls?

Edited by: Thomas Zloch on Apr 18, 2011 7:10 PM

[Former Member]

Hmm, I dont think I am likely to get a reply with my thread moved to this forum.

Perhaps if I re worded the title as "Risks of automating transactions in master data management" ? Its a real operational issue which people may meet, rather than a musing off topic type of thing.

[clinton_jones2]

Some time back I posted a blog on this at /people/clinton.jones2/blog/2011/02/14/the-problems-with-mass-actions-with-sap-data

[ThomasZloch]

I've changed the title. I don't know where your thread originated, which SCN forum would you seem fit? Maybe a moderator of that area can then decide about moving it there.

Thomas

[Former Member]

Thanks Clinton, Thomas.

Not sure where it would be best, but now I have some info to read I can see this has indeed been considered before, which is helpful.

Looks like conventional wisdom from the manufacturers is that master data changes undergo testing and sign-off, which is my feeling too.

[Former Member]

If the auditors send a ninja then you could be in for some troublesom times with such enduser computing tools which run on the client side and connect to the backend systems via technical interfaces which are not APIs. Some of them are also explicitly mentioned by SAP as not released and uncertifiable!

When they force you into granting access to the enduser which enables them to bypass the intended application from any client of their own choosing, then you should react with outrage at such tools.

The most famous of these are function groups SUTL and SDTX. The auditors know these and will look for them.

Take care,

Julius

[ThomasZloch]

Isn't SUTL the one that contains function module PLZ_INJECT_YOUR_CODE_HERE ?

Thomas

[Former Member]

Another one to be carefull of is ZAW1. That is because SAP built S_DEVELOP and SCC4 checks into SUTL which meant that it does not run in production systems... because it is not not intended to.

ZAW1 has 28 function modules in the group, each one worse than the next.

Basically the user can build the query on the client server as text using any client tool of their choosing, which then runs on the backend system as ABAP.

From a security perspective, it is a huge design error IMO as the clients are as mighty as the application server is and you dont have an application security to use - the user can run their own code and directly access the database / operating system at runtime of it.

They also tend to start saving their passwords in places where programs can pick them up at runtime as well...

Toasted

Julius