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

[clinton_jones2]

Of course all of these are generalizations and every customer is different, has different requirements, rules and controls.

But it is true, there are risks and justifiable anxieties abound in every area of business and IT. Just the decision to get out of bed in the morning might be cause of anxiety. I might step on the dog and it might bite me and I might get tetanus, or in my blurry world of half asleep state I might not see that there is water on the floor in the bathroom and might slip and fall and lie in a helpless state on the bathroom floor waiting to be rescued by someone. So again, every situation has to be evaluated on its own merits.

I am a great advocate of getting all interested parties involved in the evaluation process of a given product from the get go. The notion of skunkworks implementations of solutions invariably results in tears somewhere at some time - maybe only months or years after implementation and use - so getting everyone (including IT) on the same page at the outset really is helpful.

Let's be clear though, products like those offered by Winshuttle exist for a reason. They wouldn't enjoy the success that they do, if they didn't address a very real need. Additionally, if they were as much of a vulnerability as is being intimated, we would be hearing a lot more noise on this topic from customers and their audtors. (Some do send Ninjas!)

Incidentally SUTL isn't required and isn't in fact on the list of recommended authorizations, and I want to emphasize 'recommended' - you can try without SDTX however you may have some difficulties making the RFC calls in which case you are probably limited in what transaction you can automate and how it will work. Generally the suggestion is for users to try to use the products with standard SAP security authorizations that have already been granted to them and then triage issues wi9th use from there.