This post is both long, and long overdue. It’s based on several online sessions with Donka Dimitrova and Jie Deng of the SAP NetWeaver BPM product management team, then an update with Wolfgang Hilpert and Thomas Volmering at SAPPHIRE in May when the product entered unrestricted release. In the past few weeks, there’s been a series of “Introduction to SAP NetWeaver BPM” posts by Arafat Farooqui of Wipro on the SAP SDN site (part 1, part 2, part 3 and part 4, which are really about how to hook up a Web Dynpro UI to a human task in BPM, then invoke a process instance using web services from a portal), and I’m inspired to finally gather up all my notes and impressions.
The driver for BPM with SAP is pretty obvious: Business Workflow within the SAP ERP suite just isn’t agile or functional enough to compete with what’s been happening in BPM now, and SAP customers have been bringing in other BPM suites for years to complement their SAP systems. I had to laugh at one of Dimitrova’s comments on the justification for BPM during our discussion – "process changes in an ERP are difficult and require many hours from developers" – oh, the irony of this coming from an SAP employee!
The Eclipse-based Process Composer is part of the NetWeaver Developers’ Studio, and is used to create processes in the context of other development tools, such as the Yasu rules engine (which they bought) and user interfaces. Like most modern BPMS’, what you draw in the Process Composer (in BPMN) is directly executed, although user interfaces must be created in other development tools such as Web Dynpro or Adobe Interactive forms, then linked to the process steps. There are future plans to generate a UI from the process context data or provide some sort of graphics forms designer in place, but that’s not there yet.
As with most Eclipse-based process modelers that I’ve seen, Process Composer has multiple perspectives for different types of process design participants, with a shared process model. Initially, there is only a process architect (technical) perspective in the modeler, and the business analyst view will be released this year. Future releases will include a line-of-business manager view to see task sequences and parallelism, but no details of gateways; and an executive view of major phases with analytics and KPI dashboards.
There is no link between ARIS-based modeling (SAP Enterprise Modeling Applications by IDS Scheer) and the NetWeaver BPM in this version; integration is planned for later version, although it will be interesting to see how that plays out now that IDS Scheer has been purchased by Software AG, which competes with SAP in (at least) the BPM arena.
Although all you can do now is create your BPM processes in this environment, in the future, there’s plans to have a common modeler and composition environment provide visibility into ERP processes, too, which will be a huge selling point for existing SAP customers who need more agility in their ERP processes. This common process layer will provide not just a unified design experience, but common runtime services, such as monitoring and performance management.
One huge issue from an orchestration standpoint is the lack of support for asynchronous web services calls, meaning that you have to use the existing NetWeaver Process Integrator (PI) environment to create system-centric processes, then invoke those (as synchronous web services) from NetWeaver BPM as required. I didn’t get a clear answer on future plans to merge the two process management platforms; keeping them separate will definitely cause some customer pushback, since most organizations don’t want to buy two different products to manage system-centric and human-centric processes, as they are encouraged to do by stack vendors such as IBM and Oracle.
Taking a look at the Process Composer environment, this is a fairly standard Eclipse-based BPMN process modeling environment: you create a process, add pools, add steps and link them together. For human-facing tasks, you use the properties of the step to connect it to a UI for that step, which must already be built by a developer using something like Web Dynpro. As I mentioned previously, the first version only has the “process architect” perspective, and is targeted at creating human-centric processes without full orchestration capabilities, since that’s what SAP’s customers who were involved in the product development cycle said that they most wanted. The environment is fairly technical, and I wouldn’t put it in front of any but the most technical of business analysts.
Roles can be set by lanes and overridden by task role assignment, which allows using the lanes for a department (for example) and overriding manager-specific tasks without moving them to another lane. Also, expressions can be used to assign roles, such as manager of the user that started the process. User IDs, roles and groups are pulled from the NetWeaver user management engine (UME).
Each step can have other properties, including deadlines (and the events that occur when they are exceeded) and user texts that appear for this step in the user worklist, which can include parameters from the process instance. These are all maintained (I think) in a task object, which is then associated with a step on the process map; that allows the same task to be easily reused within the same process or across processes.
There are a number of things that I like about Process Composer:
- Some nice UI pop-ups on the process map to make specifying the next step easier.
- An explicit process data model, called the process context, driven by master data management concepts; this is used for expressions and conditions in gateways, and to map to the inputs and outputs of the UI of human steps or the service interface of automated steps. It can be imported as an XSD file if you already have the schema elsewhere.
- The visuals used to map and transform from the process context to a human or web service step make it obvious what’s getting mapped where, while allowing for sophisticated transformations as part of the mapping. Furthermore, a mapping – including transformation functions – can be saved and reused in other processes that have the same process context parameters.
- Lots of fairly obvious drag-and-drop functionality: drag a task to create a step on a process map, drag a role to assign to a pool, or drag a WSDL service definition to create a system task.
- Nice integration of the Yasu rules engine, which can be purely within the context of the process with rules appearing as functions available when selecting gateway conditions, or as a more loosely-coupled full rules engine.
Process Composer is just one tab within the whole NetWeaver Project Explorer environment: you can open other tabs for UI design, rules and other types of components. This allows the process to be visible while rules are being modeled, for example: handy for those of us with a short attention span. Rules are created using decision tables, or by writing in a Java-based rules language; Dimitrova referred to the latter as being “a bit complicated for business people”, which is a bit of an understatement, although decision tables are readily usable by business analysts. Future releases will have a business perspective in the rules modeler.
The Rules Composer is a full rules modeling environment, including debugging for incomplete or over-constrained rules in a decision table, and rules versioning. Parameters from a process context can be passed in to rules. Rules can be exposed as web services and called just like any other web service; in fact, although there is tight integration between the rules and process environment allowing for easy creation of a rule directly from within the Process Composer perspective, the rules management system is a separate entity and can be used independent of BPM: really the best of both worlds.
Having spent about 3 sessions going through the design environments, we moved on to process execution. Processes can be initiated using a web services call, from an Adobe form, or manually by an administrator. Since process models are versioned, all of the versions available on the server can be seen and instantiated.
Human tasks can be seen in the SAP Universal Worklist (UWL) through a connector that I heard about at SAPPHIRE, appearing along with any other tasks that are surfaced there including SAP ERP tasks or other systems that have developed a connector into the UWL. I like the unified inbox approach that they’re presenting: other BPM systems could, in fact, add their own human tasks in here, and it provides a common inbox that is focused on human workflow. Although an email inbox could be used for the same purpose, it doesn’t provide adequate management of tasks from a BPMS. The UWL is fairly independent from NetWeaver BPM; this is just one way to provide a worklist of BPM tasks that is provided by SAP in a portal environment, but it doesn’t have to be done that way.
Once a task is selected and opened, there is a frame across the top with standard task information that will be common across all tasks: information such as start date, deadline and status; common task functions of Close, Delegate and Revoke; and notes and attachments to the task. Below that is the Web Dynpro UI form that was connected to that task in the Process Composer, which contains the instance data that is specific to the process context for this process. The user can interact with that form in whatever manner specified by the Web Dynpro developer, which might involve accessing data from databases or ERP systems; that part is completely independent of NetWeaver BPM.
The user can also click through to a process view showing where they are in the context of the entire process map, plus runtime task parameters such as priority and start date.
Considering the all-important areas of monitoring and management of work in progress, that’s a bit weak in the first version. In the next version, there will be a dashboard showing process status and cycle time, with drill-down to process instances, combining exported BI data and realtime work in progress statistics. There is no way to update the process design of work in progress; there are actually only a few BPMS that do this very well, and most either don’t do it at all or require manual modification of each instance. Wherever possible, things that might change should be put into business rules, so that the correct rule is invoked at the point in time that it is required, not when the process instance was created.
At the end of all the demos, I was impressed with what SAP has released for a version 1.0, especially some of the nice handling of data and rules, yet aware of the many things that are still missing:
- task UI generation
- simulation
- KPI measurement
- asynchronous web services calls
- links to/from ARIS
- common process composition environment across BPM and ERP processes
- BPEL translation
- business analyst perspective in process and rules modelers
- BPMN 2.0 support
- strategy for merging or coexisting with NetWeaver process orchestration platform
In the briefing at SAPPHIRE, I did see a bit of the roadmap for what’s coming in the next year or two. In 2009, the focus will be on releasing the common process layer to allow for discovery, design and management of processes that include core (ERP) processes, human tasks in BPM, and service orchestration. This, in my opinion, is the make-or-break feature for NetWeaver BPM: if they can’t show much deeper integration with their ERP suite than any other BPMS vendor can offer, then they’re just another behind-the-curve BPMS struggling for market share. If they do this right, they will be positioned to win deals against other BPMS vendors that target SAP customers, as well as having a pre-existing relationship with SAP customers who may not yet have considered BPM.
Also in 2009, expect to see convergence of their BPM and BI, which is badly needed in order to provide dashboard/monitoring capabilities for BPM.
Further out, they’re planning to introduce a UI generator that will create a simple forms-based UI for tasks based on the process context (data model), as well as reports generated from the process definition and point-and-click integration of analytics at process steps. There will be more robust event provisioning tied to the existing event structure in the ERP layer, allowing events to be propagated to external applications such as BPM, and intermediate message events integrated with Business Suite. As mentioned previously, there will be new perspectives in the Process Composer, initially a business analyst perspective with a different focus than the existing technical perspective, not just a dumbed-down version as I’ve seen in other tools, and eventually they’ll use the Eclipse rich client platform (RCP) for an even lighter weight (and less geeky) Eclipse interface. There are plans for allowing ad hoc collaboration at a process step – necessary for case management functionality – as well as allowing operation managers to have control over interactive rule thresholds, providing greater business control over processes once they are in operation.
There’s a lot still missing in this first version; : simulation, KPIs, asynchronous web services calls just to name a few. That doesn’t mean, however, that it’s not usable – I know many customers using BPMS’ that do support those functions, but the customers never use them: great demo and sales tools, but not always used in reality.
NetWeaver BPM is not the best BPMS on the market. However, they don’t need to be the best BPMS on the market: they need to be the best BPMS for SAP customers. They’re not quite there yet, but it’s an achievable goal.