business - the three frameworks

This one reminded me about the structures we have to live with, or not:

Doing business is all about process, in which value is created (or rather added).

For the processes to work you need a framework, some structure that leads the flows and handles exceptions.

As I see it there are three:

1. Organisational Hierarchies.

The classic decision and reporting structures created ages ago, supporting a whole industry of academia, authors and consultants. It's the core framework, and it's what we have. Kind of.

2. Business Rules & Practices.

Extending the hierarchy mechanism into the daily life of the organisation. The structure for when the boss or the meetings have no time, or is not available. Usually found on piece of paper in drawer or pinned on wall behind computer screen. If this then do that.

3. Enterprise Software Systems.

Now this is interesting. Enterprise systems in many cases offers the structure previous delivered by the hierarchy or the rules.

But when you study the legacy enterprise software systems you'll find built-in features where rules, practices, decision and reporting mechanisms can be set.

That I think is quite funny, and rather something superfluous - frameworking a framework.

But of course, the decision and reporting structures as well as the written and unwritten rules are so ingrained that nobody really knows why they're there anymore. Just questioning them is met with blank stares, and to suggest that a software framework could replace them is seen as utterly bollocks.

Well, I'll go with bollocks. Rethink and rewrite 3, then let 1 and 2 slowly disintegrate, or whatever. Heck, social software is already hacking away at the hierarchies, why not go all the way in a slightly more conscious way?

Comments

[phil jones]

Totally agree that increasingly enterprise software is used to police the process rules. And equally that there's a huge demand from customers (ie. NOT users) of enterprise software to make sure that the software gets these rules "just right".

That's the challenge. I'm convinced that companies that take advantage of new software to throw away their old processes will have a huge advantage.

The problem is convincing them ... and I'm thinking that that's largely a matter of the existing internal divisions between who buys software, who specifies it, who uses it.

As long as "procuring software" is a little insular process within an organization which is given a mandate : "go and buy software" and this is completely independent of "let's think about our internal processes" companies are in trouble. But so are *new* enterprise software vendors.

Perhaps one thing vendors can do is to provide some little "what-if" process modelling tools (widgets) on the web-site of the company selling the software, so potential buyers can play around with process remodelling and understand the potential.

[sig]

Phil, you're absolutely spot on that not enough questions are asked as to "why?" (BTW, goes for most any purchase I suspect...)

Suspect this is a leftover from the days software were mere support tools to other frameworks. OK, most still is... but if (business model) framework then suddenly Enterprise Software would be impossible to split from strategy.

Agree to your last point as well, some way the actual user can play around and perhaps even use.

But as mentioned above, what if the system becomes a framework then as you say, the people close to the strategy would be the users... and that certainly injects some very new requirements into the design and ease of entry :)

What we're talking about here would be close to the (unintended?) sell-in mechanism of web/office 2.0 products. Let users use, apply creativity, find value then move to convince buying powers to buy with proof in hand. Now how to design so the powers close to strategy wants to spend time on playing... hmm...

[Ed Matthews]

Here is a set of categories, if not a framework, for analyzing the business question, "Why isn't this repetitive action automated?" or alternately, "Why are my costs so high?"

Gathering
Categorizing
Assigning ownership
Acting
Sharing

ERP manual work and associated costs revolve around these categories, which need often to be repetitive, to run in parallel with each other, and to have outputs for different audiences.

For example, while a transactional customer service person is managing an order, the system should be journaling what is being done and outputting that to the HR / Mgr / Business Analyst, etc.

Every ERP should have a base "ticket" module (Request Tracker (RT), Jira, etc) that can handle the unstructured human-based work, and the binary files.

These modules typically handle the ideas of owner, workflow status, journaling, attachments, etc. and often better than ERP does, because they were designed for Gathering and Sharing, and let humans do the Categorizing and Assigning, tasks which ERP automates when it can but also rigidly and often incorrectly enforces.

Along side of Tickets, but never entirely replacing it, one builds the structured data and the business rules incrementally as he figures out what's really going on with the manual work.

So, first work manually with a tool that records what people are doing. Analyze the records. Add structure. Add automation. Repeat.

In the web world, the ticket systems need to talk to each other; there should be no more application silos. Interestingly, Google, Yahoo, etc. have not put up ticket systems to date. We shall see what the gPhone / Android stack brings in 2008. Some vendors are Zoho, RT and Hiveminder, Atlassian/Jira, QuickBase. Security remains an issue for hosted systems.

Take the ending for what you will, the early chapters of this short story describe how humans are directed by and become gathering agents for an ERP:
http://marshallbrain.com/manna1.htm

[sig]

Ed,

agree to your suggestion - although it raises (or rather should raise!) the question:

Gathering of process information for the purpose of automating/structuring entails an acceptance of the current processes.

That, as can be seen from most of my posts herein, is where I respectfully differ - in the name of process innovation (the highest, increasingly so, contributor to productivity growth) one needs to revisit the processes, question them and if need be change them altogether. Current processes are after all a result of former technologies (pen, paper, feet, ear-to-ear) and that alone should give a hint that there is much room for innovation.

And the best way to innovate is often to discard former ways for a moment, revisit the underlying principles and objectives for the organisation - rebuild from there, test, rebuild, rinse and repeat.

Of course one might end up with the age old process, but rethinking/revisiting is a must anyway to establish if current process design is really the best.

And then do the same next week, now with some experience ;)