This is a great challenge to have on several levels. The diverse nature of work means that there are needs within each organization that push system requirements in all directions simultaneously. This pushing of requirements leads to innovation which lends itself to better ways of doing business. That’s right where I want to be, and I would image most of us, too.
Argument meets reality
Reality is what we see in business not what we argue and rail against. What I see on the ground, in my customers, is a need to have prescribed processes for things that are regulated: UPS needs to ship controlled medications, Northrop Grumman needs to deliver F-18’s within precise contract terms and Nestle must get FDA approval of their baby food testing process. At the same time, these same customers need to do things that are outside the box: UPS moving into logistics from small package shipping, Northrop Grumman doing rapid prototyping to be able to respond to a threat in Afghanistan and Nestle creating new markets in new regions of the World. Are these multiple systems for differing purposes or are they different ways to implement structure, both loose and tightly managed? The latter, I would say. The proliferation of software systems to manage what seems to be distinct issues is a way of the past (think client-server purchasing apps being replaced by ERP).
The unspoken issue of allowing too much creativity is that it lends itself to disorganization and diversion from the mission. Sure, it allows new ways of doing things to flow freely, but it also allows people to go their own way regardless of what’s been proven to be prudent and efficient. What matters, then, is allowing creativity while also having an appropriate amount of structure. A happy medium, all things in moderation, and all of those things your parents told you.
Governance makes this possible. Good governance means that the creativity has reasonable boundaries based on shared knowledge and hard-and-fast requirements, an established method for granting exceptions to those boundaries, and possibly a peer review that allows learning to happen (think ‘social’).
Centralization matters, too
Strong governance that allows what I’m describing isn’t found in SharePoint privileges, data in Visio diagrams and certainly not in documents stored on laptops. It is found in systems that store process data in a central repository that allows for a hierarchy of ownership and a means to communicate.
All sounds fine in theory, right? It works in reality, too:
- Structure: Any activity that meets a regulatory (think: FDA) or compliance (think: ISO) requirement can’t be negated without a change request to the owner of that requirement…after all, what is a hard requirement that can be ignored?
- Some structure: Any activity that has been published as a best-practice way of doing business can’t be negated without review and approval of the owner. It isn’t necessarily a change request because it may be just situational or experimental/creative.
- Minimal structure: Activities that are undefined or open to innovation but should involve collaboration between stakeholders and perhaps peers.
My approach won’t end the arguments on the topic. To get a feel for how passionate this argument is (and enjoy true creativity), read Adam Deane’s ACM: Radical, Man!
A new blogger on the scene, Craig Willis, expressed similar thoughts in his first post, “Is Social BPM over already?”
I also wrote about this in May of this year in my post, “The four corners of Social BPM“:
- Process that MUST be done repeatedly the same way (i.e. regulatory, compliance, higher-volume transactions)
- Process that SHOULD be done repeatedly the same way (i.e. customer service) but has room for creativity
- Processes that SEEM fluid or unstructured (i.e. consulting, non-admin parts of sales) but have structure behind them that must be followed (and talked about)
- Conversations that are tangential to business and process but still important ways people establish communication capability (i.e. the truly social–like weekend planning)
Additionally, Sandy Kemsley provided the following on her Column 2 post, “It’s Not About BPM vs. ACM, It’s About a Spectrum of Process Functionality“:
“I think that the whole ‘BPM versus ACM’ debate has completely blown out of all sensible proportion, when we’re really talking about a spectrum of functionality that ranges from structured process management (or what some people think of as BPM) to completely dynamic process management.
The key, to me, is that it’s not an either-or situation: almost every business process that I’ve ever seen lies somewhere in the middle, with both structured and dynamic aspects: in some cases, different workers may perform either highly structured or highly dynamic functions, depending on their role. We need both end of the spectrum – and everything in between – to manage our processes, and we need them to work together in a cohesive environment.”
I welcome your comments.