business process and practice

On one hand we have:

A procurement process, the HR department's hiring process, order taking, or any project - all well structured Business Processes, the typical domain of the big legacy systems or focused project management systems.

That's what we call Business Processes. The important stuff. IT stuff for grown ups.

On the other hand we have:

A desperate call from a chap in the field when a supplier does not show up, a router that goes whirr-kaplunk, or the back and forth of mails prior to getting that big project up on rails.
All run and supported by Monday morning meetings, boss meddling, e-mail, faxes, phone calls and to-do lists.

The business processes that's not even called Business Process. The process orphans. The nuisance. The stuff that actually take most of our time.
What I'd call Business Practices.

I wonder what the gain would be if the Practices could be as efficiently handled as the proper Processes?

A lot? A whooping gigantic leap?

Did I mention the lack of learning from the unstructured Practices? The e-mails spread on hundreds of HDDs or Monday morning meeting reports that nobody reads or even write?

And what gain would we have if the learning was automatic, the increase in intellectual capital like a snowball instead of instant snow melting?

A friggin lot? Unbelievably huge gain to company efficiency and value?

Just to rub in what a business day consists of:

1) Business Process.
Examples: Procurement, HR processes, sales and marketing processes and any project.
Supported by: ERP systems, CRM, HR management systems, project management systems and BPxx systems.
Intellectual Capital: Big data repositories, data mining systems on top.

2) Business Practice.
Examples: Getting a process up to start and any issue that threatens to derail or mess up with the "proper" processes.
Supported by: To-do lists, fax-mail-phone, meetings and management involvement.
Intellectual Capital: Data (if any) spread in unreadable form all over the place, no IC growth at all.

Enter thingamy; it is designed to build the needed flexibility into workflows to even support and run the Practices. Then capturing the ongoings and data as well as define any report template for efficient use of the data so that next time, you can learn from prior issues and solutions.

Then when the inevitable questions comes - "where's the border between the proper "Process" and the "Practices", we would go "there is none!".
And then proceed to nibble on the proper Processes to give those room for the occasional derailing.

Always nice to be able to enter the corporation by replacing to-do lists, e-mails and Monday morning meetings - less risky for the end-user, more of a no-brainer.
Extending or replacing the big legacy systems would be entirely up to the user, please feel free when the time is ripe :)

[Thankful nod to Tony (link when he gets his blog up! Now up!) for reminding me and to Dominic for even more input on the issue.]

Comments

[Ian Prince]

Interesting post Sig, as always.

I'm wondering whether you can equate:

Business Process = Top-Down Process
Business Practice = Bottom-Up Process.

My small business is nearly all Business Practice/Bottom-Up Process. By definition Top-Down is easy to define and model, but Bottom-Up is *hard* to define as it "Just Happens".

Which leads me to wonder if Bottom-Up "learning" or "automatic modelling" could be a killer feature for Thingamy, getting it in-the-door for little up-front investment.

'Cus hand-modelling the Business Practices – whilst nice in theory – is just too hard in practice (no pun intended).

Cheers,

Ian.

[sig]

Ian, not a bad idea, top-down vs. bottom-up... although I sort of lean towards more linear vs all-over-the-place...

The best part is that any of those "linear" and proper processes have unplanned for hiccups so the Practices have to be set in gear. Guess it becomes a "practice" after it has happened a few times as such usually do. And "best practices" (hear now Thomas!) when it has happened so often that one have managed to get some idea of how to do it halfway properly.
But "best practice" is not even half way - still cracks to be seen (Oops, forgot!) and no furthre building of knowledge and Intellectual Capital to speak of.

And definitely, this seems to be the area of interest for first use of thingamy - not my plan - but I love it! Nothing real to compete with, really easy to model as a working start for later tweaks and bettering... thus extremely low risk for the early adopter. And of course, the perfect gate to squeeze in the Trojan Horsy ;)

[Ian Prince]

I agree that getting thingamy through the door aimed at the Practice/Bottom-up/All-Over-the-Place processes is low risk.

However, low risk does not equal low cost because modelling these process is *hard by definition*.

Which is where I thought some kind of "modelling-through-doing" functionality in thingamy might provide some form of "instant gratification" without having to spend hours (days?) on modelling first.

[sig]

Ian, but of course! Modeling? Bah, humbug!

1) Do not analyse current processes or practices.
2) Think "why are we doing this?" about the practice.
3) Build accordingly a ridiculously simple first flow.
4) Tweak and expand at will :)

[Ian Prince]

For "3) Build accordingly a ridiculously simple first flow", would it be possible for thingamy to build the flow *for me* by watching me actually *doing* the flow, along the lines of applescript "record"?

Ideally thingamy would record *all* the ad-hoc flows and based on aggregation propose generic flows for user validation (and tweaking).

It's written in lisp right ;-)

[sig]

Ian, sure, sitting next to you that is :)

Actually a "user story" is much more useful, that allows for some cheeky questions like "Why do you do that? What's the purpose?" with the inevitable follow-up creative sounds of "hmmm... ah!".

Never a bad idea to revisit, remember that the "way you do things today" is a method created using pen, paper, post, faxes, meetings, phones... you know, the pre-it methodologies! No need to keep that at all, in fact, better to scrap as principle and reintroduce if really good after all!

Start with a simple no-nonsense flow that does what it should do in it's simplest form, the start asking "what if" questions to generate the ad-hoc parts of the flow.

Hehe, yep, CL yes, you/we find a need that is not covered (and is generic) we add in a snippet ;)

[myspace design]

Interesting article. Great to have stumbled upon your blog.