Sunday, September 30, 2007
Friday, September 28, 2007
Last week I organized a meeting concerning "The Business Case for Digital Working". Quite interesting it was, I might say. The striking thing of the meeting was that the outcome of this session wasn't a shortlist of Business Cases, translated into marketing products. Because we approached the Digital Working Environment from an entirely different angle, being "the business" instead of "IT", the outcome was quite different.
After intensive discussion (which is, fortunately, quite normal within YNNO) we realized that implementing and "running" a Digital Working Environment is never finished. It doesn't end with "working with Documentum, Hummingbird, LiveLink, or any other ECM application".
This, of course, isn't mindboggling, I hear you say. True, IT always has its fair share of bug fixes, add-ons, new releases, et cetera. No, the striking thing was that, because we addressed it from the Business Point of View, we realized that the business never stands still, continuous improvement and adaptation. My colleague Guus appointed that quite nicely from his earlier posts in the realm of BPM. Also, I read a very interesting article on that in MIT Sloan as well.
So what does this mean for the realm of ECM and the related operations within the organization, keeping it aligned with the business? What does it mean for governance? How do these processes have to be managed? Furthermore, if you read posts about Enterprise 2.0, as my other colleague Robbert does, the "golden release" of the IT doesn’t exist anymore (or did it ever?); it's perpetual beta.
More questions than answers, as it should be after an intensive session. It's quite interesting to take these outcomes and put them to good use.... Continuous Improvement isn't a fad, but the way forward; I'm convinced. The result: a digital working environment constantly tailored and suited for the business.
Thursday, September 20, 2007
Monday, September 3, 2007
In our studies for finding the link between BPM and Social Networks, we found a simple, but interesting conclusion in an article of Armistead (Business Process Management, exploring social capital within processes). A process is just a community with a common goal. So a community is a group of people exchanging ideas. If one thinks about this and projects it on BPM, then this opens new doors. So why is it not standard practice in the BPM field to make sure everybody in the process knows each other. May be we sometimes don't need structure, but just time to get to know eachother and refind the common goal, results for the customer.
But this leads to some new questions, do we need to know all the people in the process to be more effective. Probably not. So what is the most effective social structure. I think this depends heavily on two things, 1. the exceptions in the process 2. variety of the output. If we need to solve exceptions quickly, we better know the people in the process. Then we can find the right person fast to solve it. On the other hand, in BPM we don't want too much exceptions, becasu this is ineffective and inefficient. So traditionally we first would get the maturity of the process up, and reduce the exceptions. And then if 99 procents of the work is standardised and stable, then we just have to do our thing and we don't need to know the others. This leads to my second believe, variaty of the output. In more and more processes the variaty of the output is not standard. Why? Because the processes are more knowledge intensive and can be not be standardised fully. For example think about creating policies in a government agency, or a case of lawyer. So in processes where exception (or better collaborating and exchanging knowledge) is more a standard practice, we need to focus more on the people in the processcommunity. And this is of course, where it gets interesting.
Posted by Guus Balkema at 10:00 AM