« SAP Influencer Summit #2 - the message | Main | Big Company Innovation »


Mikhail Elashkin

Sig, I agree - “automation” isn’t correct word. I translated your text to Russian and published in my blog.

One opinion is quite interesting and may explain why you can’t say “automation”. BRP has no sensors. You have no feedback from real world. Outlook doesn’t know that you really have had meeting and this document in Word is the result of it. But automation since Norbert Wiener means system with positive or negative feedback.

Anyway, to be efficient BPM should have feedback capability.


Mikhail, precisely!

For me a good BRP system would be like freshly fallen snow in the woods, you'll leave tracks that you can retread later if you found a good path, then show it to others so they can follow the good path :)

Think I have a summary post brewing!

vinnie mirchandani

Sig, could not agree more...you are getting to the heart of what I have been telling CIOs - there is vendor version of "innovation" aimed at scalable, but generally lowest common denominator of customer base and what they need to do - on the edge, with alpha technology, intense etc - see my MAGIC framework below...


but the Street would clobber someone like SAP if it moved away from productized, scalable offerings



"Street would clobber someone like SAP if it moved away from productized, scalable offerings" - I agree, to a certain point, the question is more - how to move the market to see what's good for the future?
(Yeah I know, Xmas and all that, believe in Santa Clause one must..;)

My main point is actually not to move away from what they're doing now, they're damned good at that, it's more to move into a new untouched market - the BRP space which is now populated application-wise by office suites and your SNOWs!
None of those have much of "process" built in, and SAP should know process and could do it, although from a different tech angle.

If that could be done without a huge investment (some new tech but they have the channels etc) and without cannibalising anything of what they do - well, even the most Reuter-screen-affixed-traderoid would not bother much or what? :-)

Jon Husband

As I think you know, Sig, I am not very technically 'adept" .. so I think I use "mashup" in a perhaps less stringent sense that you may.

I like your notions of footfalls in freshly fallen snow .. what I meant by mashup is that from what i understand you are talking about creating applications that allow for, accommodate, enable BRP's without incurring any or much cost in terms of making a rigid, highly defined "product" ?



precisely, more "clay" than "mashup" :)
And not "burned clay", have to keep the clay moist and raw and malleable.

Funny with these metaphors, Thomas (vendorprisey) was confused by my "snow" metaphor, still have not established if it's his southern hemisphere roots that never had him trudging in knee-deep snow to school every morning!

I think the most important distinction between the actual ERP or BRP types is that BRP events are almost all conditional with a large number of choices at each point - the results of a blood test would decide what next step in the BRP would be, more blood tests? X-ray?
While ERP's conditional events often are limited to "above 10 k$ then divert to boss for OK" kind of forks.
That would make the architecture of ERP hit the wall pretty quickly when trying to do BRP.

"Best practices" would not be a strict way of doing things, it would be the palette of choices offered at each step. "Go buy an ice cream" would not be a natural choice to include after a Feeedback From X-ray event ;)

So the BRP architecture has to allow much, still be a framework so no cracks appears and all is captured.

And, it must allow creation of and changes to the flows rather easy and cost efficient as one have to "learn" while doing - the moment one have found a good route it shall become a path so I can retread it and others can use it!

Graham ( PC enclosure Man) Gallagher

Excellent post, I wish some of the other posts and threads I saw was as interesting as yours. yes the costs are high but applied correctly you get a good return on investment.Thanks for sharing.

Jacob Ukelson

Great post. At ActionBase (www.actionbase.com) we actually have what you call a BRP. For lack of a better term we call it a human process management system. We have had informal on and off contact with SAP and maybe I can give some insight why SAP isn't going after the BRP market full force:
1. Their management find it difficult to believe that BRPs actually exist and are important to the business (though this is changing in the rank-and-file). The notion of unstructured, ad-hoc process doesn't fit well with their view of the world.
2. The work that they do in this area is via Research - an interesting paper and demo of a tool for "weakly-structured processes", the Gravity demo. So there are folks that understand the issues at SAP - but they are the minority.
3. Building a BRP requires a very diferent mindset then ERP - which is why BPM vendors are also having a hard time with BRPs



interesting, although there are SAP'ers very high up who do understand the importance and size of the BRP opportunity - but with their organisational history and solidity it's hard to free the mind completely I suspect :)

I think you guys are taking a sensible track by letting people use their existing tools adding your "human process management system". Less ruffling of feathers that.

But we're taking the much harder tack, actually being as radical as saying the term "management" is what we'd like to get rid of - so our's is more of a "human process framework" or even "running". That's of course much harder to accept, but heck, if doing it we'll have to do it properly and devil-may-care etc. :-D

The comments to this entry are closed.

My Photo


  • Phone: +33 6 8887 9944
    Skype: sigurd.rinde
    iChat/AIM: sigrind52

Tweet this

Thingamy sites

  • Main site
  • Concept site

Tittin's blog


Enterprise Irregulars


Twitter Updates

    follow me on Twitter


    • Alltop, all the cool kids (and me)


    Blog powered by Typepad
    Member since 01/2005