Why Workflow in MDM?

The ability to develop workflows around master data in MDM is a highly valued feature of the product. Traditional business workflow in R/3 has long been a crucial part of any implementation, and SAP provides many workflows for standard processes. If there isn’t a delivered workflow for a certain process you can develop your own. It’s long been one of the most powerful features of SAP. However, SAP never addressed the issue of workflows for master data until MDM.

Before I get too deep into this topic I should at least explain what a workflow is to anyone who may be reading this and is unfamiliar with the term. A workflow is simply the way a task is distributed and passed among different people in an organization. For example, if you would like to request vacation there is a workflow process. You submit your request, therefore creating a task for your manager who must either approve the vacation request, or reject it. If he rejects it, he can either reject it altogether, or he could pass it back to you to modify, therefore creating a task for you to complete. Each task would represent a work item in a workflow. The way that tasks are transferred from you to your manager would represent the flow.

So why do companies want to develop workflow around master data? Many businesses see a major value in developing a process for approving a master data record before it gets established in the R/3 system. A typical example of this would incorporate an accounts receivable department. For example, let’s say you want to create a record in your system for a customer that you want to do business with, however someone in another department (maybe AR) discovers that the credit rating for that customer is bad, so they don’t want to do business with them; therefore you don’t want to establish a record in your system. This is a bad example, but it illustrates the point. Another reason for developing workflow around master data is to maintain data integrity by having different processors and stewards review and edit the records after the initial entry. As we know, one of the great strengths of using MDM as part of an EDM project is to cleanse existing data. Of course, this doesn’t do too much good if you let your master data get dirty again, so developing a workflow can help prevent this from happening. Automated data integrity through system validation checks is one way to maintain data integrity, but nothing beats good old fashioned human review, especially if the two are combined.

Unfortunately, SAP never developed a workflow procedure for the creation of new master data in the traditional applications. Many customers have chosen to adopt a paper workflow process. In other words, they use a form that is filled out and passed from person to person with a final sign off, and then someone goes into SAP and manually creates the approved record. A major drawback to this is the fact that you can’t get the native system validations in most paper workflows, such as check tables and data validations. If you want to add a new vendor for a particular purchasing organization, how do you know what reconciliation accounts are available for that purchasing org without the help of the MM configurations? Another drawback is the fact that paper workflows typically take a long time complete, therefore affecting efficiency.

The customers that have chosen to develop workflows in R/3 (or ECC) have run into many common problems. The first issue is that once a record is established in your business system, it’s very difficult to get rid of. In fact, the only way to get rid of it is to “flag” the record for deletion; you can’t simply delete the record. Additionally, if a record is established in your system you need to prevent it from being used until the record has completed its workflow procedure. One way to do this would be to block the record at all levels, then of course you need to remember to unblock the record when it has finished the workflow. Some companies have opted for more complex methods, such as developing a z-table (SAP terminology for a custom table in the database) to store the record data while it is part of a workflow. An ABAP program can then enter the data into the correct system tables once the record is approved. Again, you run into system validation issues in the sense that a z-table won’t contain the traditional logic configured in MM, so you would need a workaround for this.

SAP’s answer to this common issue is MDM. With MDM you can easily (I mean, really easily) develop workflows around your master data maintenance process and change them on the fly. The MDM can be integrated into Microsoft Visio with a plug-in that is downloadable on the service marketplace. This allows you to build workflows in Microsoft Visio, and they represent an actual process in MDM. It’s very cool considering most functional analysts use Microsoft Visio to draw the flow for the spec anyway, so it just makes sense that the Visio flow is the actual technical workflow.

Building the workflow in MDM can satisfy the majority of issues that companies face with a paper process for master data. For one thing, the data integrity can be upheld by the use of validations. Validations are expressions which are built into MDM that can check if a certain criteria are met for a certain attribute, or set of attributes. An example of this would be to make sure a number that is entered falls within a certain range. The expression builder is impressive, and lets us build rather sophisticated logic very easily. This solves the issue of upholding data integrity validated at the time of entry, therefore less work has to be done in the long run. Another major benefit to using MDM as the workflow engine is the ability to delete the record entirely if it is rejected. In MDM you can actually delete records and there is no trace of them in your business system. That of course leads me to another benefit; you don’t have to worry about blocking the record because it’s not in your business system at all. Additionally, once the record is approved it can be sent out to all the partner systems at the same time.

There are still issues to be sorted out with the MDM workflow engine, but in general it’s a major improvement to what was currently delivered as a recommended process for master data, that of course being nothing. The most notable drawback to using MDM as the workflow engine is that you can’t get some of the very complex data validations that are inherent in MM and SD configuration. For example, you can configure the sales offices that are available for each particular sales area. Because a sales area is a combination of three values from three different tables, you have a complex relationship between the sales area and the sales office in the database. Performing this sort of data validation in MDM is extremely difficult, and generally not recommended. It can be counter argued that your sales office is most likely not an enterprise level attribute, and consequently doesn’t belong in your MDM data model to begin with, especially since it will probably not have any bearing on weather or not the record is approved.

I’ve done some rather extensive work with MDM workflows, so I’ll be posting some technical pointers in the near future, but I first wanted to explain the benefits of MDM workflow and why it’s useful.