Reflexiones de un curso de Balanced Scorecard...

"Lo que no se mide, no se mejora".
Principio de Calidad.

He llevado varios cursos de indicadores, recuerdo hace varios años una serie de cursos de la Secretaria de Planeación en la UTEZ en los que descrubrí los indicadores macros o  superindicadores como el Indice de Desarrollo Humano. Ahora, al tomar el curso de Gustavo, que está muy bien presentado para comprender los sistemas de indicadores me surgió la pregunta: ¿Si yo diera un curso de indicadores hoy, para implementarlo, algo así como Gestión práctica de indicadores que haría?

Punto 1: Understaand deeply simple things.

Si yo tuviera que dar un curso practico para medir lo que importa o poner un sistema de indicadores como lo haría?

1. Pondría el video de Kaplan vs Goldratt donde Goldratt defiende que no se necesitan más de tres métricas. 
2. Aquí ver la película de Moneyball y del libro sacar algunos datos importantes sobre que es lo más importante.
3. Buscar sobre radiadores de información y tableros físicos.
4. Buscaría implementar un tablero de información.
5. Tal vez algo de gamificación para gestión interna.
6. Seguir el libro del principio del progreso: progreso, catalizacion y la construcción de un ambiente sano de trabajo.

Punto 2: Make mistakes.

Aqui va la implementación del tablero. Debemos de implementar un tablero en el taller de indicadores que s e vaya retroalimentando iterativamente.

Punto 3: Raise questions.

• ¿Porque no me gusta tanto el Balaced Scorecard ahora, si si me gustaba cuando lo implementé en la Oficialía Mayor? Tal vez es porque en donde estoy ahora es mejor aplicar técnicas más sencillas. 
• ¿Lo usarías o no en este momento? No.
• ¿Qué usarías en su lugar? Me inclino más por los tableros físicos y por limitar el número de indicadores. Debemos de gestionar pocas cosas, es imposible gestionar 100 indicadores...
• Debo de implantar un sistema de gestión de indicadores? Sí.
• Si Toyota, que es un monstruo maneja tableros físicos. Nosotros no deberíamos seguir esta práctica? Sería una buena idea comenzar por aquí.
• ¿Cómo sería un sistema de medición automático? Mas bien creo que debo de evaluar automáticamente el progreso como dice The Progress Principle.

Punto 4: Follow the flow of ideas.

• Sistemas de gestión de calidad. Que fue antes?
• Balanced ScoreCard. Que se está usando?
• Tableros físicos. Qué sigue?
• Buscar algunas curvas S en Sistemas de medición de indicadores.

Punto 5: Change.

El estado natural de las cosas es el cambio. Under construction.

Cualquier implementación de sistemas de indicadores va a cambiar. Es un hecho de la vida.

¿Qué he aprendido en el curso?:

Que es importante conocer los detalles de cada uno de los indicadores. Understand deeply simple things.

Alejandro, me dio los siguientes tips en función de la perspectiva de Goldratt:

1) Identificar la meta.

2) Ver que te impide lograr mas de la meta.

3) Definir indicadores negativos, es decir, descendentes, que es lo que debemos reducir para lograr más de la meta.

4) No medir más allá del nivel de ruido. Es decir, no dedicar esfuerzos adicionales a la medicion. Si la toma de decisiones se realiza en dias, no buscar medir horas o minutos. (Buscar referencia de ello).

Por leer:

• Tesis de alumnos de Gustavo para alternativas de sw para indicadores para Balanced Scorecard. Más de 100 herramientas y casi 20 de software libre.

Tips para administración utilizando Teoría de Restricciones (TOC)

En el CIMAT se realiza un coloquio o plática entre estudiantes, profesores y gente relacionada con el CIMAT. En esta ocasión toco el turno a Alejandro García. De manera previa ya habíamos realizas una sesión introductoria de Teoría de Restricciones. De la cual luego les comentaré. La sesión tuvo la siugiente agenda:

1) Primero realizamos el ejercicio para demostrar que se es más productivo cuando se realizan tareas secuenciales a tareas con multitasking.

2) Caso de matnenimiento de aviones de la fuerza aérea israelí. 6 ingenieros, 6 aviones por ingeniero, tiemp promedio 17 meses. 6 ingenieros, 3 avios por ingeniero, tiempo promedio de mantenimiento 5 meses. Qué pasó? Redujeron el mutlitasking

3) Minimizar el multitasking

3.1) Gráfico de cuantos proyectos permiten elevar la productividad de un Ingeniero de Sw.

4)  Primera observación respecto al tiempo

4.1) El cuadruple del tiempo promedio para dar una buena estimación

4.2) Todos los IS queremos ser considerado personas confiables y eso implica cumplir compromisos. Cuando a un IS experto no promete más del 80%.  Ello implica no exagerar.

4.3) La variabilidad hace que los ingenieros se esfuersen para cumplir las metas. 

4.4) Hay otro ejemplo de startups. Cuando una compañía empiza y tiene pocos desarrolladores produce más que cuando se integra más gente a la compañía en el transcurso del tiempo.

La regla equivocada de la administración es "La manera de asegurar que un proyecto termine en tiempo es tratar que cada actividad termine en tiempo".

Las nuevas reglas:

1. No convertir los estimados en compromisos
2. Mover la protección del nivel de tarea a nivel proyecto
3. Usar un buffer de administración para establecer prioridades

Ejemplo:

1) Diagrama de PERT de un proyecto normal con buffers al final de cada terea.

2) La primera ocasión se reduce la estimación al 50% y se deja un buffer de 33%. El proyecto queda en 66% de la estimación original.

3) Cuando las estimaciones son optimistas solo agregas el 33% de buffer.

4) Se administran los buffers. Si el buffer va bien ni me meto a ver como van las tareas. Pero si tengo problemas de que mi buffer se está consumiendo y se me va a pasar debo de tomar acciones.

4.1) De aquí se deriva que si el buffer esta libre, tal vez conforme avance el proyecto se pueden realizar más tareas.

4.2) Empresas que utilizan está técnica, realizan reuniones de avance de una manera más rápida.

4.3) Con el método de buffer puedes aceptar adiciones si está contemplado dentro del tiempo.

Las premisas son que:

1. Buscamos tieempos optimistas.
2. El buffer sirve para problemas inesperados.
3. Si alguna tarea se retraza no hay problema, siempre y cuando sea razonable el tiempo del buffer.

Ejemplo de los pueblos japoneses a la orilla de las montañas. Lo invitaron porque con TOC resolvieron el problema. Una casa es un proyecto, necesitas un buffer. Un constructora de una fraccionamiento. Hay otras técnicas que se utilizan para contabilidad y otro tipo de cosas...

Conclusiones del equipo:

• Vale la pena dar el beneficio de la duda a la Teoría de Restricciones.
• Es contra intutivo la aplicación de Teoría de Restricciones en empresas de desarrollor de software.
• Vale la pena buscar y obtener más ejemplos al respecto.