Apparently Serendipity is one of the hardest words to translate in the English language. Maybe that in itself is a happy accident. But what has this to do with process design, case management or enterprise social ?
While everyone is mostly concerned with designing process and outcomes around the ‘happy path’, no happy path is truly without deviations and exceptions and serendipity is concerned with finding happy coincidence or positive effects from unrelated cases. If we look at Case Management, and specifically the Adaptive/ Dynamic variant, definitions centre around it being “information technology that exposes structured and unstructured business information (business data and content) and allows structured (business) and unstructured (social) organizations to execute work (routine and emergent processes) in a secure but transparent manner.”
The tangled wiring in my head is trying to make a correlation now between what we know as ACM and serendipity in the Enterprise.
In an organisational context, the happy accident has been used in successful japanese business by the “ability to create knowledge not by processing information but rather by “tapping the tacit and often highly subjective insights, intuitions, and hunches of individual employees and making those insights available for testing and use by the company as a whole”.
And so where this Yellow Brick Road leads is not to Oz but the rather bizarre notion that Case Management and Enterprise Social are in fact serendipitously linked to each other. In my hazy mind the two can no longer survive without the other as the world moves forward because while one focuses on the knowledge worker and unstructured work, enterprise social can support the emergent feedback and insight gleaned from those workers and expose it to create adaptive processes.
Yes, yes, there are those who baulk at the use of ‘social’ right now but it’s a convenient moniker to strike a few points home and make some of the notions more transparent.
And perhaps that’s just the power of serendipity at work when I blog randomly like this !
IT :: redux 
ACM is by definition social activity aligned to the context of reaching goals. The social aspect has to be somewhat reduced because there is data security and proper authority to be considered.
I provided two years ago a formula that proved that the happy path for an end-to-end process (delivering a customer outcome) in which each fragment is 80% perfect, will not meet more than 30% of all execution variants. That turns orthodox BPM with flowcharts into an illusion.
Just adding generic social text interactions does reduce some of the external email messaging but the actual process still can’t be changed and still is not goal oriented. Still no one knows what happened in cases when the process did not fit. No one can learn from the failures and the later solution as it is external to the process.
That is the whole point of ACM. Make objectives (customer outcomes), targets and process goals transparent and allow performers to execute freely, just bound by a few boundary rules. Everyone participates according to skill.
I have compared a process to playing a game of Golf and who would dispute the Golf is a social sporting activity. But ‘Social + BPM’ is far from ACM. ACM is a superset of BPM and not a subset for a few special cases. It applies to all processes equally. There are just some processes that really can’t be done with rigid BPM flows, but that is not the space for ACM. In difference it can handle them too.
Thanks Max, nice to see you pop up on here again 🙂
To some extent while I have to disagree that we downplay the “social” aspects, data security is of course a large concern but authority (if I interpret correctly) cannot be based on hierarchy in this context and needs to be based more on a networked model than traditional tiered levels. In my scattered brain something dynamic like this, almost like how neurons are networked, would work better as a business architecture/ operating model for ACM which may help realise adaptability because they support each other.
Or maybe I’m just slightly mad and on the wrong track entirely.
If you work for example in a medical case, data security is a major concern and access to information is purely on a need to know basis. Still at any time any specialist might be called in to participate and only the data of the work task may be accesible to him/her.
Simple Q:
1. Does a case (in ACM or otherwise) ever get repeated?
2. Is a goal measurable? How does it get measured?
3. Do we follow the same goal / objective from different paths – happy or unhappy / known or unknown?
4. Is goal a culmination of multiple smaller goals?
5. Can you change the definition of your goal?
ad 1) Yes, cases and parts (subgoals) thereof are often repeated but not exactly the same way.
ad 2) Goals can be measured by means of rules or can be judged by the performer or customer.
ad 3) The goals mostly remain the same but not the activities that are needed to achieve them.
ad 4) One goal can be the split into subgoals.
ad 5) Goals are simply defined by business users either by description or rule definition. If a particular goal can be changed during execution is a matter of defined user authority.
In addition to goals I propose the use of strategic objectives (customer outcomes) and operational targets that the goals are executed towards.
Pingback: The art of serendipity in BPM, Case Management and Enterprise Social « Campbell Robertson's Blog·