Scott Thurm discussed the latest management meme, the data-driven enterprise in today’s Wall Street Journal. The article was in part a review of "Hard Facts, Dangerous Half-Truths & Total Nonsense,” by Jeffrey Pfeffer and Robert I. Sutton. The article talks a lot about what it takes to base decisions on facts rather than assumptions. Recent and not-so-recent corporate failures on assumptions rather than hard data. To me, it emphasizes the pitfalls of selected the wrong data to watch.
Jeffrey Pfeffer describes managers so focused on perfecting today's business that they lose sight of tomorrow's. Quality-focused approaches may reduce defects, but hamper innovation. Enterprises must find long term success by gaining advantage by analyzing today's problems while looking creatively for tomorrow's opportunities. The problem, of course, is how to do this.
I think segmentation is a way to do this. Each small area of performance must focus on optimizing its processes. That cannot be the whole focus of management. As David
Girouard of Google observes, "A lot of analytical stuff will give you incremental improvement, but it won't give you a big leap…You can't time or plan for innovation. It can't come from customer data. It has to come from the heart of somebody with an idea."
The challenge is to find the balance between optimization and innovation. You may be wondering about another challenge, how I am going to tie this to building automation.
I think the answer lies in understanding that the span of optimization is small. Optimization is process oriented. Optimization looks at a small value chain, and finds incremental improvements. If you stretch the process too long, you lose site of the overall goals, and attain the optimizations afforded by government re-organization. No one would strive for that.
Innovation works in a different way, or rather two different ways. Innovation replaces a process with a whole new process, or it finds new value in arranging the existing processes in new ways. Preparing for innovation requires two things. (1) Processes must be defined in terms of outcomes so they can be replaced with entirely different processes. (2) Processes must have short enough spans of concern that the services they provide support new higher order processes as they are discovered.
In building systems this means:
- Keep the span of a process, and of the control system that runs the process, small. Do not over-integrate. One should e able to replace a process with a new one without re-doing the whole larger system.
- Define the outputs of each system in terms of service provided.
- Choose what you measure wisely, as measuring the wrong things will paint you into a box.
Interoperability enables innovation. Large processes can stifle innovation. True interoperability requires abstraction.
How do you think these ideas apply to building systems?