How not to do it - 12sprints and Chatter

More and more Enterprise Software vendors (and users) have their "aha!" moments, getting the reality that "unstructured", Barely Repeatable Processes are immensely important.

Not only happens about 60% of all work in such processes, but no proper process based IT exists, leading to about 65% of all time spent at such work being spent on running the processes and not on value creation.

So what are the vendors doing?

Grasping at the term "collaboration", then stitching collaboration tools together hoping for some process structure to ensue. Some early examples, before the serious stitching and slapping-on has commenced, are Salesforce and their Chatter, SAP with 12sprints and misc. creative plug-in uses involving Google Wave. 

 

The process result is equal to sending mail from Word. And back again.

Instead of approaching the issue from the bottom up, creating one core that orchestrates all tasks and activities with a single data model for everything that happens, they slap something on the top like bandaid applied to broken legs.

Sucking data from one application, via APIs, applying local logic, then sending off to the next application with another data model and logic looks fine on the surface - some illusion of process ensues.

But process illusion is not process reality!

Where's the full real time overview? Where's the historical data? Where are the easy changes to process? And, most importantly, where is the process-data (not the process-result-data)?

Nowhere. Or everywhere in different formats. 

Illusions works for awhile but will always fail.

Comments

[Jacob Ukelson]

Here at ActionBase we had our "aha" moment quite a few years back, and we exclusively focus on supporting unstructured, ad-hoc, human processes (I know - it is quite a mouthful:)

Another epiphany we had is that email and documents are the way most people execute those processes - so we focused on extending those paradigms (currently for Microsoft Outlook and Office) to allow for real time overview, full audit trail of the process, reporting, historical process data stored in a DB - and put the users in charge of how the process unfolds. You can find out more about us at www.actionbase.com and our blog at blog.actionbase.com

[sig]

Hi Jacob,

yep, like your stuff, sensible and practical approach that.

Myself think we need to go some steps further to avoid becoming "middleware 2.0" and being stuck in the current complexity. This by building upon core process engine and not vice versa.

The datamodel is crucial - sticking with documents, forms and double-entry book keeping based transactions complicates any model tremendously over reality. And that is not possible unless the core is the process engine and data architecture.