Summary : when we try to explain the new way of collaborating that’s expected in the workplace, it often looks like a lot of flows and interactions that has to form around every employee. But that’s overlooking one essential point : context. If interactions flows around employees, employees are organized around a production flow that aims at turning a request into a solution or answer. That’s the difference between collaboration to meet one’s goals and collaborating to create value. That’s essential because it makes us put individual actions into perspective and measure their usefulness and added value not in relation to the person performing them but to their contribution to the production flow, even if intangible and made of information. Conclusion : the value of any collaborative system does not rely on generic approaches but has to target the weakest link of the chain. The latter is not only weak because of the lack of collaboration tools but also because of organizational constraints that are peculiar to him.
Let’s take a few minutes to wonder about the sense, the goal of one’s activity in the workplace. We collaborate, exchange, solve problems (more or less efficiently)…but it’s only the micro part of a wider system. We tend to focus on individuals who “should” and “need to” without paying attention to their context.
At the beginning there’s an input, a request. It cames in the form of a simple question, a request to get a deliverable, a problem to solve. This input needs an output in return, that may be an answer, an operating model, a methodology to apply. If we have a closer look it appears that the whole organization is working this way, the input being either ‘can our product do such thing”, “how to fix this machine”, “what communication plan for our new product”, “designing our new intranet” or “how to hire someone with such or such skills”. It comes from someone who can be called customer, who can be either internal or external.
What does happen when this input is sent ? There are two possible situations : either it exists a methodology/process/procedure to manage the input or not.
In the first case we have a linear intangible flow with defined steps (creation, problem solving, design, validation etc…). Each of these tasks needs specific actions that themselves need information, knowledge, experience, expertise that that the owner of the task seldom have. If he can identify the right information/resource, he’ll use it to create/design/decide as fast and good as possible. If not he’ll do with what he has and push the work to the next person in the chain and so on until the final deliverable is issued, what is the output. Behind something that looks linear we have, in fact, a something that quite different and looks like a network even if, officially, things are supposed to be linear.
In the second case, the person that receives the input has to manage to find the way to process the input before starting to work. So he immediately falls into a network logic that, in the end, looks like the result of the previous case with on difference : there was no predifined role.
Let’s call “flow” the processus that ensures the transformation of the input into output (solution, answer), should it be linear or not. What is the major and most legitimate concern for any business ? (note that even if the matter that is transformed and the role of humain being has evolved, the problem has been the same for ages).
Improve both the output (that impacts created value and revenue) and its pace (productivity). Not more not less. But that’s already a lot.
Now, let’s find what’s needed to meet this goal. [Read more...]
You can find the "original" french version of this blog here
