Nando's Weblog
delirios e ilusionesMore posts? (Follow me on LinkedIn)
Find more Posts from me in LinkedIn:
→ https://www.linkedin.com/in/fguigou/
El trabajo en modo “Stand-by”
En su libro “This is Lean” los autores suecos Niklas Modig y Pär Åhlström nos guían en un encantador viaje que incluye encuentros con directivos de Toyota. Muuuy recomendable.
El libro comienza con un ejemplo donde una paciente necesita hacerse varios análisis sobre cáncer. En un caso tiene que ir a través de diferentes laboratorios y en el otro, cuenta con un centro que reúne todo lo necesario. Si hacemos en ambos casos el cociente entre el tiempo efectivamente utilizado y el tiempo total que demora la persona en saber los resultados, las diferencias son evidentes.
El ejemplo demuestra las consecuencias de maximizar el uso de los recursos vs. optimizar el flujo del proceso.
En el modelo de producción en masa, maximizar el uso de los recursos (utilization) era una premisa fundamental. Sin embargo, con el tiempo se observó que una sobrecarga excesiva (en particular a partir del 80% de utilización) puede generar un aumento de los tiempos y costos en forma exponencial.
Obviamente una baja utilización implica que el costo de mantenimiento de los recursos no se amortiza, así que existe un punto de equilibrio:
Pero resolver este equilibrio no es solamente un tema de fórmulas, gráficas o ecuaciones matemáticas. Esas son herramientas. El problema es más profundo. Allá vamos …
Taiichi Ohno decía que para ver la importancia de optimizar el flujo de trabajo, se debe partir de la premisa de que las cosas (al igual que las personas) no quieren esperar. Luego, debería ir personalmente a acompañar un elemento a través de la cadena del proceso que se estuviera estudiando, quedándose en cada etapa el mismo tiempo que demora ese elemento en pasar a la siguiente y así sucesivamente.
¿Alguien se imagina seguir una determinada solicitud de un trámite, como si la solicitud estuviera pegada a nuestra mano y nosotros tuviéramos que acompañarla durante todo el proceso hasta su resolución final? Seguramente encontraríamos muchos tiempos muertos, etapas inútiles, etc. que no dudaríamos en eliminar. Lo que estaríamos haciendo, es eliminar el desperdicio de las cosas que no aportan valor (waste).
¿Pero que sucede cuando durante el proceso de optimización nos encontramos que hay partes del mismo que dependen de otras organizaciones? Supongamos que hay una cierta validación que debe ser hecha por otro organismo público o un proveedor externo. ¿Como resolver entonces esa interrupción?
Y acá es donde llegamos a la definición de una forma de trabajo muy uruguaya: el trabajo en modo “Stand-by”.
Influenciados todavía por la vieja época, seguimos pensando que “mientras estemos ocupados …” estamos haciendo nuestro trabajo. O al menos, haciendo “algo“.
Si queremos entender mejor el problema del que estamos hablando, deberíamos clasificar nuestro trabajo en dos categorías:
- aquellas cosas que hacemos para que todo siga funcionando (mantenimiento)
- aquellas cosas que hacemos para mejorar (desarrollo)
Esto se aplica al software y a cualquier otro tipo de actividad. Por ejemplo, un banco en Suiza le llamaba a estas diferentes actividades “Run the Bank” (RtB) y “Change the Bank” (CtB). Está claro que lo primero es necesario. Pero lo segundo es lo que nos permite crecer y avanzar.
Ahora bien, a veces surgen imprevistos.
Esos “incendios” que requieren una atención inmediata son también parte del mantenimiento, pero su impacto es de tal magnitud y alteran la planificación de tal forma, que merecen una mención aparte. En especial en Uruguay o cualquier otro lugar donde uno sienta que vive “apagando incendios” o “corriendo las cosas desde atrás”.
¿Suena familiar?
No hay dudas de que las mejoras son mejoras de los productos (bienes o servicios) pero también del proceso que los genera. Sin embargo, cuesta mucho implementarlas en un escenario donde existen dependencias con terceras partes y no hay un SLA (Service Level Agreement) que estipula los tiempos máximos de demora.
Esto nos lleva a veces a comenzar ciertas actividades, pero sin tener la certeza de cuándo van a ser terminadas.
Es un gran error. Pensar que “no hay otra forma”, es un error aún mayor. Las consecuencias son nefastas, porque cada interrupción nos llevará a (re)iniciar otras actividades, aumentando el work-in-progress, la sobrecarga del sistema y los costos totales.
Por si todo eso fuera poco, cada vez que llegamos a una interrupción de ese tipo es común sentir que ya no es nuestra responsabilidad (sí lo es!!!) y bueno … mientras encontremos otra cosa para hacer, al menos no estamos “perdiendo el tiempo”. Error!! En Lean, cada vez que trabajamos en algo que NO es lo más importante, estamos perdiendo el tiempo.
A eso le llamamos “el trabajo en modo stand-by”.
Es ese trabajo que uno hace, sabiendo que NO es lo más importante.
Cuando eso sucede, al igual que un electrodoméstico que está a la espera de ser usado, hacemos “algo”, pero como no es lo más importante, es como si estuviéramos en “stand-by”. Un funcionamiento mínimo pero no “apagado” (como cuando estamos de vacaciones o simplemente no estamos trabajando).
Las posibles soluciones a este tema en principio, parecen ser dos:
- o bien partir el proceso en etapas independientes, con sub-productos definidos que puedan quedar aguardando a que la otra parte termine su trabajo
- o bien establecer tiempos de entrega normales y máximos, que sean realistas.
De este modo la otra parte puede cumplir sin necesidad de un esfuerzo extra (que será utilizado cuando el tiempo normal haya expirado, para que en ningún caso supere el máximo) y de esa forma se puede planificar la actividad en forma continua
Si damos una segunda mirada a estas dos opciones, veremos que solamente la segunda nos garantiza la continuidad del flujo. La primera, simplemente nos evita quedarnos esperando y nuevamente, optimizamos nuestro tiempo en lugar del flujo del trabajo.
La segunda opción, implica una coordinación a través de diferentes actores, de modo tal que exista una visibilidad mayor sobre el trabajo por venir, el grado de avance de cada pedido y las fechas de entrega (normal y máxima) esperadas.
El objetivo es llegar a no comenzar nada, hasta saber que va a fluir sin interrupciones.
Dicho de otra forma: asegurarnos antes de empezar, de tener todo lo necesario.
La siguiente imagen es bastante elocuente …
(Management Lesson: nunca comiences un proyecto a menos que tengas todo lo que vas a necesitar)
Lo contrario, nos lleva a una letanía interrumpida por incendios que salimos a apagar de apuro. A eso le llamamos trabajar en modo “Stand-by”.
Es necesario mejorar. Pero es imposible mejorar si cada mejora está plagada de interrupciones.
Nos despedimos con Mafalda …
Burocracia & Lean
Lean & Traffic
Hoy vi este aviso en la televisión española:
Jé … cualquier similitud con Montevideo … no es casualidad.
Que tiene que ver Lean con todo esto? Tranquilos, no los voy a aburrir con la producción en masa, los horarios, todos los días lo mismo, etc.
De hecho, la bicicleta es una buena solución. Más aún, en aquellas ciudades donde la municipalidad las ubica disponibles en forma gratuita, con una tarjeta que simplemente identifica a quien la retira y registra que la misma fue devuelta. La publicidad asegura el mantenimiento del sistema y hasta se pueden alquilar cascos y candados.
Pero esta “solución” en realidad soluciona un problema que no debería existir.
Sería más fácil si no hubiera tanto tránsito. No al menos, a la misma hora.
¿Por qué tenemos todos el mismo horario?
Si las personas tuvieran horarios flexibles y pudieran ir a trabajar más temprano, más tarde o incluso quedarse a trabajar desde su casa, el problema de tránsito sería mucho menor. Sumado a lo anterior, tal vez ni siquiera existiría, haríamos más ejercicio …
Pero si la gente va a trabajar a cualquier hora, o se queda a hacerlo desde su casa, como controlamos que realmente trabajen? – algunas personas podrían preguntar.
Pues … muy mal le debería estar yendo a cualquier organización, si la única manera de saber si todos hicieron su trabajo, es fijándose en el tiempo que han estado presentes.
Spring benefits
Why Spring ?
For the re-engineering of DieTiX, it has been necessary to make a choice, regarding a Java Framework.
Two major solutions have been proposed for that. They are not the only ones, but they are the two ones with major acceptance: EJBs and Spring.
The selected option was Spring.
Why ?
The long answer can be found in Rod Johnson’s book, “J2EE Design and Development”
The short one is that Spring provides just what we need.
Because … what is an integration framework about ?
In the same way that WS orchestration just coordinates different webservices without forcing them to be “orchestration-aware”, a good integration framework should not force the components to handle additional complexity to solve other problems.
Divide and conquer is easier to say than to implement. It is clear that a subdivision of a system helps to tackle the issues separately, in a much smaller scale. But this is useless if encapsulation is not strong enough and if it is, the relation among these components is the remaining problem.
Your abstraction and conceptualization capabilities during the analysis are the key factors to partitionate a system. A framework can afterwards help you to integrate them seamlessly. Here is precisely where a good framework should show its strength, and connections among beans have one special moment: instantiation.
After instantiation, the reference to this object can be handled in many ways (ideally, among certain limits to keep layers independent) but this part of the story means a different challenge. The point is that instantiation is the first step that builds a link among the different components in any application.
Some GRASP patterns try to address exactly this problem, very well solved by Spring.
Information Expert and Creator are principles about who should instantiate an object and this is done with Spring in a way that is transparent for the beans involved. Furthermore, instantiation is actually done by the container itself and beans are then available to the others, which need to use them. This is obviously right and an Application Server does it also. Where the EJB approach fails, is when forcing the beans to use lookup code (JNDI) to find the beans they need.
Even after having defined (really) large XML descriptors in the early versions, nobody took this responsibility away from the bean.
Whilst in EJB you should write something like this (i.e. with JBoss):
InitialContext ctx = new InitialContext();
MyBean myBean = (MyBean) ctx.lookup("MyBeanImplementation/remote");
With Spring you just define the property and a standard way to set its value, even by a setter or through a value received in the constructor.
But the best of all, is that none of the participating beans have to be aware that one is injected into the other.
In EJB 3.0 there are big improvements into the right direction. These improvements are clearly influenced by the main alternatives to the previous EJB specifications which are Spring and Hibernate. The open question is then which one to choose and also which configuration option (annotations or xml).
In this case, we answered this two points starting with the configuration issue. The decision was that annotations are ok for persistence, since it makes perfect sense that a persisted bean is aware of its nature. But for DI, we prefer to keep the bean as much unaware as possible and therefore, xml is the prefered option.
From this point of view, Spring is then not only future-proof but also a simpler solution that can run just within a servlet container like Tomcat, without the need of an Application Server. Even though JBoss has now an embeddable container, it is still considered as an additional level of configuration that if possible, is prefered to be avoided.
Some Spring benefits:
- no lookup code
- simple descriptors
- autowiring
Underestimating concurrency issues
More often than you can imagine, I have seen systems where the problems of concurrency were severely underestimated. Even people that I considered quite intelligent, when I was commenting about the lack of a concurrency control, argued: But chances are quite low.
Or even worst: a kind of optimistic locking was implemented, but the check of the time-stamp was done through a SELECT statement previous to the update without locking the row. Again, the argument was it is really improbable to get an update in between.
The problem is simple, low probability does not mean impossible and when this happens, it is specially tricky to find the reason for an error in a system that was running without any problem for a long time.
Fixing a bug has two parts: detection and correction. From these two steps, the first one is the most difficult and concurrency problems are (precisely, because of their low probability) very hard to reproduce.
Thinking that it doesn’t worth the effort to solve them, due to the low-probability, is like playing Russian roulette with a single bullet.
Hibernate now makes everything easier. Be aware however, that EntityManager is not thread-safe.
High performant (but useless) systems
Many times, I heard people talking about the problems of performance, when defining some constraints at DB level. Anyone can understand that no matter how fast a response is generated, it is totally useless if it is wrong. However, some people sometimes think that actually it depends and it is just about finding the right balance between performance and data integrity.
For those who are still not sure about this point, this example might be helpful.
The company was an electricity company.
Just few years before, it had paid several millions for a huge consulting project that implied a broad reengineering of the processes and information systems.
Whilst relational databases were already an industry standard, the implementation option on which the solution was based was a non-relational database (Adabas). In order to improve performance, one-to-many relationships were implemented as arrays, with no FK constraint. The result was a much performant system and everyone was proud of it.
But after having seen many inconsistencies, I made a small program in Natural. The input was a screen where the user declared the FK constraints and the source of a Cobol program was automatically generated, compiled and run, in order to make the checks and produce a report of the inconsistencies.
We all know how bad inconsistencies are and how they tend to reproduce themselves. What we might not always be aware of, is about the business and economical consequences they may have.
As said before, many processes were improved not only internally, but also the communication among them. An electricity company has many offices distributed across the service area. Each of these offices does maintenance and other kind of tasks. So the Operations and CRM systems were feeding the service orders each office needed to do on a given day.
One of this types of orders, was to read the meters in order to generate the invoices.
The problem, is that some meters were assigned to invalid offices.
This means, that this meters were never included into any service order to read them.
Yes, you are right. No reading means that no invoice was being generated. They were getting electricity for free. There were many of them. Happy customers, of course.
I hope inconsistencies will no further be seen as a technical problem. They might mean huge amounts of money.
Nando's Weblog 