I think business processes should be a reflection on the way the business has chosen to operate, rather than the technology used to implement it. Some processes will be linear, chronological and cumulative and some non-linear, asynchronous and collaborative - for good business reasons. Using the wrong modelling approach because there aren't a choice of tools to automate the process as it is performed in the real world is going to end in tears - for the user and the developer alike.
Both SAP Business Workflow and NetWeaver Business Process Management use the sequential workflow modelling approach. Processes are depicted as separate chunks of work with information and choices flowing from one step to the next. The problem arises when the solution to the business requirement is not linear, chronological and cumulative, or at least not satisfactorily described by such an approach. Such examples are unstructured human-centric activities, which feature parallel processes with collaboration. These types of workflow are known as state machine workflows, because they transition from state to state rather than from activity to activity. Think of a state as a status within a business process. States are useful because they indicate how much of a workflow has completed and how much must still occur. This lends itself very well to workflows that are long running. In addition, within SAP Netweaver the publish and subscribe paradigm of status event management is possible, meaning that very complex interactions can be automated.
The technology for state machine workflows exist with CRM Orders, and examples of their use have been implemented within Solution Manager in the Incident Management, Service Management and Change Request management scenarios. Here is a walk-through of the ITSM/ChaRM scenarios:
Figure 1. Transaction types used in ITSM and ChaRM scenarios.
In the figure above, different types of documents (solution manager term: transaction types) represent different phases of the "incident to resolution" business process. Incidents are created by saving details in a document of transaction type SMIN. If several incidents are raised all pointing to an underlying problem, the SMIN can be copied into an SMPR (problem transaction type) and from the SMPR the underlying incident locked.
Contents from either the SMIN (or if created the SMPR) can be used to create a change request (SMCR). Human input is vital at this point, because there is not enough system information to determine the next step. This is a major collaborate phase, where approvals and can be sought, and discussions conducted, for example in a change acceptance board. This phase (as are other transaction types) is fully enriched with status and categorisation to allow reporting and tracking in a format readily extractable for management and optimisation reporting of the underlying issue - not just a record that something has happened, but the what, where and who. In addition, with time recording functionality, the when question will be answered and then integration knowledge articles provides a reference to how and why - the full company of Kipling's six honest serving men no less!
As necessary, a change can be carried forward. In Figure 1 I've used the motif of the highway. A normal change (SMMJ) would fall within the project lifecycle, and have to observe the stop/go traffic lights of the maintenance cycle. Urgent changes (SMHF) put on their sirens and ignore these phases. Even with these phases, there might still be the need for sequential processing, and tasks lists that recognize the different phases are available. If the change runs into trouble, it's not necessary to go back to the change manager and a change request, but an SMTM can be dispatched to coordinate recovery.
Some changes don't use the CTS vehicle (such as profile changes managed with SMAD) but still has to observe the traffic lights. Still other changes are free of project coordination constraints (SMCG).
So, while the technology exists for state transition workflows, and Solution Manager is a ubiquitous platform, licensing will of course be an issue. ITSM and Charm are specific licensed scenarios of CRM order scenarios. Extended solution manager licenses are required to make use of other CRM order scenarios that are visible within the IMG, such as Case Management for example. Nevertheless, the potential is there for an additional workflow solution alongside SAP Business Workflow and NetWeaver BPM.
edit: I thought I'd link to an explnaition of the difference between sequential v state machine workflows. It's a simple example to illustrate the following point: In state machine workflows, actions that model messy real world behaviours can be easily achieved because they don't change the object's state. In an activity based (sequential) workflow on the other hand, defining these steps would increase flow complexity - unless they were to be considered undocumented, hidden steps (i.e ignored). Both outcomes are limitations on the type of processes able to be modelled successfuly.
- SAP Managed Tags:
4 Comments
