Turning an Organization’s Practical Intelligence into Explicit Knowledge
There are three ways to create a system to automate and streamline an exisiting process in an organization. Two are the common methods used by most organizations today – the first is by using a standard, packaged application that implement the process, and the second is through BPM modelling and implementation tools.
The first (which is easiest technically, but hardest organizationally) is to replace the existing process with a packaged application that implements the process (e.g. a CRM system) and use that as the basis for replacement process. The best way to do this is to be willing to adopt to a version of the standard process that is supported by the application and keep customizations to a minimum – otherwise the cost in both time and resources can be overwhelming (and the possibility of failure is a distinct possibility). Of course, this method only works for well defined standard process, and for organizations willing to change their processes to suit the system.
A second way is to try and capture the practical intelligence and tacit knowledge of the people participating in a process and create an explicit model of the process – and then to optimize that model. The model becomes the basis for building a speciality application to manage that process. A BPM system is the preferable way to do this since it makes the implementation of the process easier and more standard from an IT perspective. A BPM systems also tends to make the distance between the model and the implementation less then if the application was created not using a BPM platform.This method only works for processes where it is justified (and possible) to create an exhaustive model of the process, allowing the IT department the detailed requirements it needs to implement the process. In this method the discovery and modeling phase is of crticial importance – get that wrong and no one will use the application. The goal of the discovery and modelling process is to leverage people with strong analytical intelligence skills to take an organization’s tacit knowledge of the process and turn it into explicit knowledge that can be articulated and programmed. This is a relatively long and difficult requirements process – and if it isn’t done right no one will use the resulting application. This works only for processes that are common enough to justify the expense (of discovery, modelling and implementation), and that can be rigorously defined using analytical techniques.
ActionBase’s HPM provides a third possibility – appropriate for both processes that can’t justify the expense of a full blown BPM implementation (or just can’t wait), and as a way to gain insight into the practical intelligence and tacit knowledge of an organization – without embarking on wide spread, never ending process discovery and modelling. By using ActionDocs and ActionMail as simple proxies for an existing email and document based process – a system for managing any human process can easily be set up. It doesn’t need to be complete, the process can easily evolve through usage. If someone was left out of the process they can easily be added by sending them an ActionMail, and if a document was overlooked it can easily be added as an attachment. So almost immediately the organization gets all the benefits of a managed process that evolves as the process is used.
Over time, a standard core of the process may evolve and it’s model can be seen using ActionBase’s server. The organization can then decide to implement the process using method 2 (with the expensive discovery and process steps already complete), or leave the ActionBase process.
I’ll discuss more about this “third way” methodology in following posts.
Leave a Comment
You must be logged in to post a comment.
