« SAP Influencer Summit #3 - SAP missing the biggest opportunity ever? | Main | BRP - what is it really? »



Well - you're definitely "on message" Sig ...



ouch, me's being caught redhanded in peddling thingamy friendly ideas again eh?

But as they say, "if the shoe fits" and so forth... :D

phil jones

But it's *hard* to innovate new processes.

You might as well complain that a particular novelist once wrote a great novel ... "why doesn't he keep on doing it?"

Answer : if you just got big because your last process innovation was a great success, now you have to change something much larger in order to innovate again.

The real rival to innovating new business processes *inside* your organization is splitting up entirely and replacing yourself with a market. Markets can take things to the BRP extreme with one-off contracts for every bit of co-ordination if it's better that way.

Increasingly it is.

But if that theory is correct, then Thingamy's rival is not a different *internal* company management software but EBay / Craiglist and other online markets. Can you build a market with Thingamy as easily as you can build a process?



excellent points, got my brain going first thing in the morning, my favourite kind of entertainment - beats the morning newspaper :)

Separate posts material this, but let me take the first steps here:

1. "Hard to innovate processes"

Agree completely with your answer there, biggest reason for the ultimate demise for many companies, lack of innovation.

But let me posit the complete opposite: "Innovating processes is the easiest type of innovation" and that "focus on process, your own and the customer's, when you innovate tangible products and it becomes easier to innovate"

- A process always have a purpose, and asking the question of "why do we do this?" is the provocative operations that sometimes/often leads to innovation. Asking a simple question is simple as such, thus a good start, then
- Processes are mostly inherited or embedded in each other - usually processes have a process in front and at the tail. Thus the answer to the above question should get questioned again all the way until no more answers can be given. That could lead to some parts of the whole process to be eliminated, often the best kind of innovation.
- Exactly the same applies to tangible products - they always have a process purpose, and probably some inheritance or relationship with other products and/or processes.

Example: I'm stuck in an annoying traffic jam every morning so I'd like to make that process, transport to office, better.

a) "Why do I want to go to the office at that time?"
b) "Because my boss requires me to be there"
c) A fork emerges: "Why does he require me to be at the office at all/ at an early hour?"
d i) "No reason to be there early"
d ii) "Need to meet face to face every now and then"
e i) Ah, I can leave later and avoid traffic!
e ii) Ah, I can pop by only on Tuesdays for the 2 pm meeting!

And so forth, suddenly the first focus becomes irrelevant, perhaps the transport process becomes moot and you go Bedouin. Now try same method on a physical product, anything on your desk, and you'll see how the method moves you forward pretty quick in unexpected ways.

2. Letting a "market approach" do the BRPs

Not a bad idea, as you say, much of that is happening already - twitter, blogging, developer networks, newsgroups (couldn't have survived without that when I moved to Linux many years ago!) and the slightly more structured cousin; collaboration software. Not to forget all those age old blasted meetings, markets they truly are!

Two things comes to mind as to why you'd like some structured sequence and data capturing structure:

a) Knowledge distribution and assimilation: There was a Twitter exchange going on yesterday between Craig and Nigel re. finding solutions in the SAP Developer Network (SDN), people being too lazy to search to find a previous solution. I suggested my usual "70% of issues have been solved before" so they should be there to which Nigel replied "that should be about right" there too.
In order to find the solutions one need an effective way of adding knowledge to the objects (issue and solution) and nothing beats relationships.
And process delivers relationships directly, and if you could follow the process in which the issue had been solved earlier more could be "learned" - again increasing the "knowledge" of the group.

b) Everything is conditional: Every step in a sequence, it being using Google to seek a solution or discussing in a meeting, for every suggestion, for every question raised you get ideas and the path changes direction.
That is quite different from the mechanics of a market that usually works perfectly for one input (I have a widget for sale, here give me a price!) with multiple results (10$, 12$, 15$ and free delivery please).

BRP examples: A patient arrives at a hospital. First step is done by a receptionist that notes a few facts and make the first educated guess as to what specialist to send to. There the patient is examined and the results might point to some other specialist and so forth.
Don't think the "Hey I got some stomach cramps, could anybody fix this please?" on e-bay or on your local "Sunday morning outdoor health market" would be as efficient :)

Or the student who's depressed - "hey my girlfriend left me, could anybody soothe me?" (OK, I see the local "depressed people in need of soothing market" aka the local bar ;)
Better is again a proper BRP where each step allows for learning and new paths to be chosen - a conditional sequence. Maybe it's not about loss of girlfriend at all?

Boy, think this will have to become a post or two one day... :D

Balaji Sowmyanarayan

I smell Agile and Kaizen/Lean here. Conceptually of course.

Process Innovation or BRP Manifesto a la Agile Manifesto will make the slope less slippery Sig.

Couple of more posts in the queue?

phil jones

But let me posit the complete opposite: "Innovating processes is the easiest type of innovation" and that "focus on process, your own and the customer's, when you innovate tangible products and it becomes easier to innovate"

Have to disagree on this. Processes are *culture*. That's the hardest thing to change. It's what people know how to do.

Take away that and they stop functioning until they learn a new process. Old processes may be filled with cruft, and inefficient, but to co-ordinate, train, cajole people to move from an old to a new process is a major undertaking.

Even just dreaming up a new process without implementing it can be hard. How does it handle the edge-cases and exceptions, have you "debugged" it? Etc. etc.

Software should be easier to make than buildings, after all it's just typing, not carrying bricks and metal girders around. But it isn't. Processes should be even easier to change than software, right? It's just in people's heads ... :-)


Phil, precisely!

Agree completely - for the implementation bit that is, not for the process design as such.

But, duh, I forgot the implementation in my comment! *slapping forehead*
And without implementation the design is rather... eh... theoretical. :-)

So, off to the practical running of (mostly Barely Repeatable) processes:

The more rigid the "framework" for the process is, the harder it is to change the process. And "culture" must be the worst of all frameworks.
In that context I would even venture "impossible" instead of merely "hard".

Culture is a proof that process requires a framework, culture is "this is how we always do it", a self-organised framework when there was no real framework. Not always pretty nor efficient.

Next step on the framework ladder would be the organisational hierarchy where nodes (bosses) sometimes can change snippets of processes.

Then comes rules & policies to handle the smaller process snippets that could not be covered in Monday morning meetings. Printed on paper and distributed, but easier to change than the other two.

I think that anybody who have tried changing culture or organisations knows - more or less hopeless.

So it's back to the former post about BRPs and systems for that - one sorely needs something that in fact can handle and run processes of that type without any need for "culture", policies & rules or even organisational hierarchy.

If process was run by a process based system the individual user would only be affected by a task as it arrives, so changes could be as easy as drag&drop task icons around - no protest would be heard as nobody would really be bothered.

Until then it might remain a rather theoretical exercise to innovate processes for existing companies.

If you give that a second thought, it says something else; that there must be a tremendous upside in (BRP) bettering once it's possible through better frameworks! Huge, unbelievable huge I would suggest.

John Dodds

Changed process leads to changed experience (greater internal usability) leads to changed culture leads to virtuous circle?



yep, but that I think requires that "culture" becomes something soft and fuzzy again and not being a rigid framework as in "THIS is the way we do things around here!" which it would have to be when you run processes with it! ;)

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