SAPPHIRE is only a half day today, and there’s really only one session that I wanted to attend: Cheryl Mascaro, Enterprise Architect at Intel, and Thomas Volmering, BPM product manager at SAP, talking about BPM in Action.
Volmering started with the now-familiar SAP positioning of BPM that I’ve seen earlier in the week: BPM evolving from human-facing workflow and EAI into today’s process composition environments that allow for the orchestration of both human and system tasks. They’re seeing that business is now driving integration projects, even if they’re mostly system-to-system: it still comes down to filling a business need.
Mascaro is on SAP’s design partner council, who work with SAP (including have access to early versions of the software) during early product development in order to validate the goals, concepts and technology, and influence the product roadmap by identifying their own scenarios and expected patterns of usage. This also helped SAP to set priorities on what features to implement in what order, driving product releases.
She told us a bit about Intel first: with 86,500 employees in 146 locations, they have had to look at standardization and improvement of processes in order to maintain operational excellence. Their BPM efforts are owned by IT, but there’s a business process leadership team across the organization, and many business architects/analysts. They have a strategic enterprise plan — effectively a fully-developed enterprise architecture — in order to align business and IT, and have a BPM model based on Rummler-Brache that they use for driving the BPM enterprise-level strategy down into specific process improvement projects.
She sees NetWeaver BPM as filling in the gaps that aren’t serviced by core SAP applications, and orchestrating heterogeneous systems including SAP. She showed a screen snapshot of the Process Composer with a version of their development service request process (that is, someone requesting that a specific service be developed for use in another project, which includes attempting to locate an existing service, and approving and logging the development request if not), and walked us through the process design. We then saw the form used to kick off the process — where we did see some calendar and drop-down widgets but still no information on how this form is created — then the UI that a process participant would see at a task in the process. There are some human-facing steps in here, but also steps that interface directly with the development request database.
Volmering rejoined the conversation, and they discussed creating the user interface based on the process data and context. Mascaro wasn’t really clear on how that was done, just that the developer who worked on it found it “not hard”; I hope to see more on this in a more in-depth demo at another time.