Now back in my quiet office, rechecking the keynote videos and in general trying to shake my head free of slide delivered bubbles, rounded-corner boxes and interconnecting lines in subdued primary colours.
Luckily I also enjoyed hours of hugely entertaining and interesting discussions with SAP executives, developers and members of their SDN and BPX communities. My kind of conference that, and thanks goes out again to the extremely able and friendly folks at or around SAP! (Not to forget my appreciation for picking up my travel expenses to Munich!)
As mentioned earlier I at least had three questions, as a starting point quite useful as it led to much more probing, and learning on my side. More on that later.
The three questions and what I gleaned:
1. Semantic Web methods - any of that happening within SAP?
Not presuming that this area is, or should be, important for SAP, but it is an interesting methodology even for enterprise software methinks, and after all their competitors are all dabbling in that area...
First person asked - thinking pause - "I'm not the right person but try ......". Which I then did. Repeat process. Many times.
Ah, then I met somebody that nodded knowingly: Gunther Stuhec, who actually used the W3C standards as a part of his "semantic translation engine" for mapping schemas from different systems to/from the SAP services interfaces. Excellent, an important small step and quite natural use of the W3C standards, but still a technical solution to a technical issue. Where were the bigger, more philosophical, grand scale efforts?
Kept on digging, but alas, same thinking pauses and further person pointing ensued.
Then another lead appeared: An EU project named DIP (Data, Information and Process integration - BTW, what's the difference between Data and Information I wonder...).
SAP was one of many contributors to this project which did produce tangible conclusions and documents. But there the lead ended. I found no trace of DIP at SAP today.
2. Enabling easy Business Process changes - at the customer of course. What's SAP's attitude here?
On my flight to Munich I read a special report on innovation in the last number of the Economist. That just strengthened my pet peeve that global productivity growth has changed, and is increasingly coming from process innovation (holistically) and not from the capital or labour parameters.
SAP delivering the stuff that runs business should thus have a real and big interest in this area; how to help their customers gain more profit and success by making changes to processes easier. Or even allow changes to the whole process map.
The answer I gleaned from three days of discussions and freestyle probing in the corridors were two fold:
a) There was a lot of talk about "co-innovation", a term that popped up in all keynotes and lightened up many crowded slides over the days. When pressing for some explanation the answers could be summed up like one of their customers (a developer) did: "They invite us to work with them to create solutions that enters their products and that'll gain us".
On the surface well and fine, but being cynical it does sound like "help as self help" - making SAP's products better first, thus helping the customer of course, but still lacking that nice "here's a tool built for idea generation and implementation, now go and become smarter with it! Go create and earn more profit!".
b) That said, they do something tangible that will help their customers to get better, enabling the end user make his processes better directly:
The name of that would be project Galaxy, now renamed Business Process Management: Business Process Composer (might be wrong on the exact name there, I'm easily confused) - a nifty and quite powerful interface for process changes and tweaks inside Eclipse, a system development tool.
I heard from another party, close to overall corporate strategy, that this "product" (or rather tool) would make a big splash at Sapphire next year. Plan is to pilot it end of first quarter next year, then normal ramp-up mid next year.
And that would be a natural, Galaxy/BPM would be most welcome I'm sure (two years ago, prior to having the chance to see SAP's products close by I would have taken it for granted that this feature was already a part of their offering).
Add some "marketing twists" to the importance of this feature and I suspect it will be played up nicely next time SAP have one of their bashes!
3. Barely repeatable processes - the process orphans.
The stuff that most spend most of their days on, the stuff that often start with a call or a mail and that falls outside of the usual rather linear processes covered by SAP's current products. Actually, often originating from the nicely repeatable process when they have the inevitable hiccups.
Well. Closer to anything in that direction than the Galaxy/BPM thinghie I could not find - if processes are user buildable, well, half way there. So perhaps something useful could come from that? But any signs of an official declaration on the importance of this I could not find - although the more marketing oriented strategy chap I spent some time with at end of the show did "claim" that Galaxy "will be" their 42 (the answer to all and everything). :)
Obviously, more observations and thoughts were duly noted down in my trusted Moleskine - deciphering now for more posts!
Is a non-repeatable process an appropriate inclusion in a transaction-oriented application? The attraction of an apps package is that it (hopefully) takes away most of the stress around the bread-and-butter aspects of the business - would asking it to cater for ad-hoc implicit-knowledge-based processes be just a bit too square peg:round hole to be effective?
My point of view is that that makes a business too app-centric (and heavily locked-in) - if you want an all-inclusive process model do it outside the app with service-based touchpoints into the app where required for transactions. That way you could change the app (eg SAP to Oracle), or take advantage of advances in the app space itself (R/3 to Netweaver to BBD for instance).
Posted by: Ric | October 25, 2007 at 06:38
Ric,
agree that the hard part is to find the limit between what needs to be structured and what's better off not being structured - last part has social software, water cooler chit-chat etc.
In fact that question can be split in three: 1. Why focus on transactions, should it not be changes to states of objects? 2. What are objects and thus prone to transactions / events or other object changes? 3. What are events?
1. As you know I'm saying that transaction or event focus limits the architecture of an enterprise system - if you think simple and say that it's all about changing states for objects - in truth adding value to objects - then you're closer to a business strategy. Actually that is precisely what business is all about - add value to objects, tangible or not!
2. If "object driven" then there are no limits to what objects are, all important for your business - widgets, bikes, frames, screws but also issues and solutions if you're in a service industry. Ah, if you have objects like issues and problems then of course anything can be covered, even those pesky ad-hoc things that happens in production.
And in reality, most ad-hoc processes, barely repeatable on the surface, are core process derails and are thus quite important to capture and run.
3. If you stick to "transactions", an event is very precise and limited - typically run and captured by the legacy systems. But who says it shall be like that? There is no reason to limit an event if it's about changing the state of an object. "Go forth around the world and find out as much as possible about xxxx" - an event that could take months, involve many activities but that still could be a single event in a system: The system delivers the object in present state, you go forth and do what's necessary to enhance that object - no always a need to capture all that happens, merely the important stuff and the change to the object.
That would leave room for any method or system to be used within one event delivered by a main system. And with a flexible system; a chance to build all within that event (or part of it) into the main system if in any way repeatable as experience increases.
See, now you got me started on almost a post within a post :D
Posted by: sig | October 25, 2007 at 09:37
Sig - you're either saying that you think SAP is capable of changing their philosophy and can do all that you suggest in your "mini-post", or that they are not, and the world needs thingamy.
My point wasn't that I thought transactions were the best way forward, or even the best description for business events - I am saying that SAP and its ilk DO "transactions" ... and that's all at the moment. Now they do it well, but as you so eloquently point out, that's a long way short of complete from the perspective of the whole business. Increasingly I think (and certainly in innovative businesses) the ad-hoc, non-repeatable processes need to be the CORE, not derailments of the "core" - they should be the norm, not the exception. thingamy can probably handle that level of ambiguity and "randomness" - I doubt that SAP and Oracle in their current forms can
Posted by: Ric | October 25, 2007 at 16:11
Ric - I think (actually I know..hehe) that SAP is aware at least of the issue, but as you say - they cannot and thus will not.
This due to the architecture of the whole shebang, hailing back about 25 years. Just looking at their business objects is enough to convince me about that.
But as they are aware they do try as well as they can, and I think they may get half there through easier ways to alter the processes (Galaxy seems to enable just that) - but in my humble view it is a hard and complicated issue due to the underlying code and architecture. Where the wall will be nobody knows, but a wall is somewhere there between current and future perfection.
Sometimes one just have to start over, cannibalise one's products. Don't see any signs of that though.
And I think you're right - the not-so-linear processes should be core - suspect that's where the major value adding happens for all firms, while the linear processes could be seen as mere execution of what comes from the not-so-linear processes. Good point indeed!
Thing is that most are so focused on the negatives - "aaargh, my daily problems" - that the not-so-linear processes focused on are the derailment, the daily problems, the noise - stuff that all would like to simplify. Hence perhaps my choice of terms, market-adjusted as they are :D
On an aside, I think SAP are better poised to perfect their product than Oracle as they in my mind have a more holistic view on their product - one underlying platform with all built in and around and not a whole portfolio of loosely connected bits.
Posted by: sig | October 25, 2007 at 16:29