ISO 9000, Best Practices, Benchmarking, Six Sigma, Accounting, Social Software and ERP

Your organisation could be split into two activity areas - the well structured business process (think assembly line) like production, HR and supply chain where ERP excels, and...

the iffy stuff you spend most of your day on that has many names:

• Loose ends
• Process orphans
• Practices
• Roughly repeatable processes (hat tip to Keith Patterson via David Terrar)

Facing such loosely defined processes the organisational hierarchies - the main suppliers of process structure through Monday morning meetings, work orders and reports - struggles.

Thus methodology has been developed:

• ISO 9000 (a set of procedures that cover all key processes in the business, also applied to structured processes)
• Six Sigma (set of practices to systematically improve processes by eliminating defects, also applied to the structured processes)
• Best Practices (well, kind-of-chosen standard technique or method to be applied to process)
• Benchmarking (measure the Best Practices)
• Rules on a-sheet-of-paper (you've probably seen those on the wall above you phone)
• Accounting GAAPs (set of rules or benchmarks so iffy activities as a whole can be compared from place to place and time to time then to be adjusted accordingly)

Then out of nowhere social software emerged, delivering structured communication, transparency and documentation to the loose ends processes. And whatever you say, humans as social beings organise themselves quite naturally when the ongoing is transparent thus self generated structure to some processes.

But where does ERP come in?

As software "models real life as we see it" the ERP train picked up the well structured processes and left the loose ends to fight for themselves. But yesterday Hugh argued "that the line that separates social media and ERP is going to start getting VERY blurry, and really soon... I can see a not-to-distant future where even the larger ERP solutions are built around social software, not the other way around". And I agree simply for the reason that they should be one, there are no reasons why the world puts a line in the sand between structured and loose ends processes.

Actually it boils down to the definition of what "social software" is.

Social software "enables people to rendezvous, connect or collaborate".

But a short circuit happens in our brains when we "see" what social software is using those three terms: It invokes the image of an open marketplace or gathering where the efficiency requires freedom and little structure and thus quite the opposite of what ERP entails.

Now, if you study a shopper in a Sunday morning market, or a conference participant mingling you will discern a "flow", one-to-one discussions, then to the next but always transparent so others may join in. Still a structured flow, albeit a barely repeatable one.

I.e. I would argue for an enhanced kind of social software that can offer structure to the flows while it delivers accountability and transparency - as long as it's built with the flexibility to alter direction and allows for new participants as need be. Then Hugh will be right - all processes, both highly structured and the barely repeatable - could be run by the new kind of social process software.

And that would also be the end to makeshift structuring methodologies - ISO 9000, Six Sigma, Best Practices and one day; accounting GAAPs.

There, now I described thingamy again.

Comments

[John Dodds]

I guess you answered my question!

[John Dodds]

Are you essentially saying that where there are human nodes in social software, an ERP version would have both objects and people and perhaps other entities as nodes?

It's all about flow-mapping.

[sig]

John, close and not so close... people are resources as is tangible and intangible things with one difference, people can be assignees but still objects/resources leaving flexibility in the flow.

People being nodes... not as much: Nodes evokes fixed points. Here comes the "object driven" approach vs. the "event/transaction driven" approach of most if not all existing flow systems - which sticks to the fixed-point-nodes thinking.
With an "object driven" thinking it's the object of interest, the object you wish to increase value to, that spurs the events when it arrives thus leaving complete freedom for the path to be altered during the flow.
A football player would not be a node, he/she is merely a assignee-resource-object, it's the football that is the object of interest and when the football comes my way it triggers an ball-kicking-event. And given the need to keep the game flexible, next event is not set until I kick...

[John Dodds]

I was thinking of people as floating/flexible nodes but I see that's wrong because as I have said elsewhere the value in social software resides in the connections not the mechanism by which it's achieved (hence people's promiscuity with regard to various social networking software).

[sig]

And balance has to be found between "push" and "pull"... and that's where Social Software is better than classic ERP or BPM stuff:

You want to join, and you sometimes want others to join but you also want push like a message if somebody pokes you or RSS to have stuff you chose pushed your way.

The Social Software ERP thingie would have to have "push" as work processes requires a sequence, but flexibility to choose a new path and a mechanism for "outsiders" to join in if they can offer value.

[John Dodds]

With regard to the last point, I can see parallels with the groups/clubs/channels that exist in social software. Closed groupings that can determine the rules for internal flows and allow new members as they see fit. But maybe I'm oversimplifying something which to me seems like quite a challenge to bring to fruition.

[sig]

Good point, actually a pretty easy "feature" that can be added to thingamy!