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]

Cookoid

You comment regarding 'changing the nature of authorisations' is an interesting one because as you have already pointed out and is consistent with the way the product(s) work; you cannot change any more than your SAP credentials allow you to change.

All that said, quite rightly; the idea of being able to perform mass changes on ANYTHING in your SAP system of record should not be taken lightly and due diligence should be applied in determining who should have such tools and under what circumstances they should be used. Design and testing in QA or pre-production environments is an absolute must and this discipline should be applied with the same level of enthusiasm and commitment as you would any objects that you develop for productive use even if they are LSMW or regular BDC's.

The product supports a controlled release approach if implemented in a particular way, using centralised license management and workflow controls around the scripts and data templates and workbooks. Scripts can be restricted to particular SAP instances, particular volumes of data, particular transactions, particular times of day/week/month for execution.

Additionally you have two types of licenses, author/developer licenses and runner-only licenses. This avoids you landing up in a situation where inexperienced users can create their own automation objects, in such circumstances these users would typically only be given a runner license.

Some customers don't choose to use this governance and compliance approach though and choose to buy only the authoring tools, accordingly they essentially leave the door open to the creation of potentially harmful objects.

Again exhaustive testing is always recommended. WIth over 1,000 customers globally there are plenty of ASUG member references and you should actually be able to get referrals to existing customers who can tell you how they have introduced and manage controls around the use of the products.