Según Drucker “el conocimiento es perecedero” #quote
En diciembre de 1967 Peter Drucker escribió un ensayo para McKinsey llamado The manager and de moron. Resulta impresionante la capacidad prospectiva del autor para entender el impacto de las computadoras en el día a día del trabajo.
Vale la pena leer el artículo entero pero extraigo un par de párrafos que me parecieron particularmente interesantes.
El primer extracto tiene que ver con el conocimiento. Sobre él, Drucker dice que es perecedero pues se vuelve obsoleto. Yo, por ejemplo, sabía programar en Clipper. Ahora ese conocimiento es inútil. Pero adicionalmente, aunque fuera útil, hay otra pregunta a hacer: ¿qué tan bien programaría 20 años después?
“One of the few things we do know is that for any knowledge worker, even for the file clerk, there are two laws. The“first one is that knowledge evaporates unless it’s used and augmented. Skill goes to sleep, it becomes rusty, but it can be restored and refurbished very quickly. That’s not true of knowledge. If knowledge isn’t challenged to grow, it disappears fast. It’s infinitely more perishable than any other resource we have ever had. The second law is that the only motivation for knowledge is achievement. Anybody who has ever had a great success is motivated from then on. It’s a taste one never loses. So we do know a little about how to make knowledge productive.”
El segundo tiene que ver con el rol del manager y la ayuda de las computadoras. Estas últimas deberían servir para automatizar aquellas tareas cuantificables. De este modo el manager puede dedicarse a pensar y entender las cosas que no pueden ser cuantificadas.
“We must realize, however, that we cannot put on the computer what we cannot quantify. And we cannot quantify what we cannot define. Many of the important things, the subjective things, are in this category. To know something, to really understand something important, one must look at it from 16 different angles. People are perceptually slow, and there is no shortcut to understanding; it takes a great deal of time. Managers today cannot take the time to understand, because they don’t have it. They are too busy working on things they can quantify—things they could put on a computer.
This is why the manager should use the computer to control the routines of business, so that he himself can spend ten minutes a day controlling instead of five hours. Then he can use the rest of his time to think about the important things he cannot really know—people and environment. These are things he cannot define; he has to take the time to go and look. The failure to go out and look is what accounts for most of our managerial mistakes today.
Our greatest managerial failure rate comes in the step from middle to top management. Most middle managers are doing essentially the same things they did on their entrance jobs: controlling operations and fighting fires. In contrast, the top manager’s primary function is to think. The criteria for success at the top level bear little resemblance to the criteria for promotion from middle management.”
Es común ver cómo las empresas cometen el error de poner a sus recursos más caros y escasos a hacer tareas mecánicas que podrían ser resueltas por computadoras (sistemas). Esto las hace perder tiempo y energía para atacar esos problemas que no pueden ser modelados.
Toda iniciativa de mejora de procesos debe estar orientada principalmente al ahorro de tiempo de las personas y, mejor aún, si pudiéramos priorizar, deberíamos procurar ahorrar tiempo de aquellas personas que son un bien escaso en la organización.
Seguimos pensando..
Buen tema de análisis y discusión Ernesto, coincido con las definiciones y desde mi perspectiva y experiencia, esta situación se produce porque no hay un convencimiento sobre la importancia de los procesos, con baja inversión de tiempo en la definición o mejora de los mismos o en otros casos se considera que agrega burocracia y atenta contra la innovación, algo que está demostrado que es a la inversa. Por otro lado en mi experiencia en corporaciones donde los procesos están definidos y tienen areas dedicadas, tienen la debilidad de que no se piensan ni ejecutan en un esquema de End to End, quedando frecuentemente en compartimentos estancos e inconsistentes. Espero aportar valor a la discusión del tema.
ResponderBorrarIvan Columbich - icolumbich@gmail.com
Gracias Ivan por tus comentarios. Claro que han aportado valor.
BorrarSeguimos pensando..