Lean IT, una declaración de objetivos

Jorge Ordovás    10 diciembre, 2012

Lean IT es uno de los conceptos de moda en estos tiempos de crisis que vivimos, que persigue tratar de alinear definitivamente la TI con las necesidades del negocio, maximizando el retorno de la inversión en tecnología.

No se trata de una metodología, ni un compendio de buenas prácticas (como ITIL), es algo más. Una filosofía, una forma de pensar y actuar basada en escuchar “la voz del cliente”, en la aportación de todas las personas de la organización para ver al cliente como centro y razón de ser de todas las actividades que se desarrollan.

¿Recuerdan la película Jerry Maguire? Todo empieza por una declaración de objetivos que escribe el protagonista, Tom Cruise, a raíz del choque emocional que le provoca una conversación en el hospital con el hijo pequeño de uno de los deportistas a los que representa, tras la cuarta conmoción cerebral de su padre.

Esta declaración de objetivos (“no un memorándum”), titulada “Las cosas que pensamos, y no decimos”,  defendía una vuelta al origen, recordar para qué estamos aquí, qué es lo importante: cuidar a los clientes,  escuchar sus necesidades, darles la atención que se merecen.

Pues en el fondo eso es lo que propone Lean IT.

¿Significa eso que estamos haciendo mal las cosas? No en muchos casos, pero seguro que es siempre mejorable, y ese “back to basis”, la orientación al cliente, es imprescindible en los tiempos que corren.

Y conste que digo esto con conocimiento de causa, avalado por mis conocimientos como certificado ITIL v3 Expert y mi experiencia profesional de años desarrollando servicios de TI para empresas, en la primera compañía española certificada en ISO 20.000 por AENOR.

Hagamos un poco de historia. La filosofía “Lean” nació en Toyota, en los años 50 del siglo pasado, como una revisión profunda de la forma de trabajo en la industria automovilística para poder competir con Estados Unidos, que en aquellos tiempos fabricaba vehículos en masa en las cadenas de montaje de fabricantes como Ford.

Estaba, por tanto, muy relacionada con la cultura japonesa, y propugnaba la necesidad de entregar al cliente lo que necesita (ni más ni menos), en tiempo, maximizando la calidad y eliminando todas aquellas actividades que no aportan valor, lo que Lean denomina como “residuos” o “desperdicios” (muda en japonés): sobreproducción, tiempos de espera entre distintos procesos, repetición de actividades, etc.

Este cambio en la forma de entender el proceso de fabricación de automóviles permitió a Toyota competir con éxito en el mercado, y supuso un auténtico revulsivo que fue imitado posteriormente por otros grandes del sector, como General Electric o Porsche.

A finales del siglo 20, la filosofía Lean se aplicó también al desarrollo de servicios TI, aportando un enfoque complementario a estándares como ITIL, especialmente en aspectos como la gestión del Ciclo de Mejora Contínua y la Gestión de Problemas que ya contemplaban, pero que en muchas ocasiones quedaban vagamente implementados en la práctica.

Los principios de Lean IT se resumen en las “5 S”, que se corresponden con los siguientes términos japoneses:

  • seiri (clasificar)
  • seiton (ordenar)
  • seiso (limpiar)
  • seiketsu (simplificar, estandarizar)
  • shitsuke (disciplinar)

Lean IT se apoya también en una serie de conceptos y herramientas para ayudar en este proceso (algunos utilizados también en la metodología Six Sigma de mejora de procesos):

• Tableros kanban que tienen como objetivo fijar las metas a corto y medio plazo, poner en común el trabajo que se realiza y analizar cómo evoluciona, permitiendo compartir la experiencia y los problemas entre todo el equipo, e identificar mejoras.

• Árbol Crítico de Calidad (CTQ, Critical to Quality Tree) para identificar claramente los requisitos del cliente, distinguiendo entre necesidades y deseos.

• Diagrama SIPOC (Supplier, Input, Process, Output, Customer) para eliminación de residuos.

• Mapa de Cadena de Valor (VSM, Value Stream Mapping), para conocer los procesos y sus desperdicios, facilitar la comunicación y establecer flujos de información entre los equipos de trabajo.

En este proceso es clave la participación e involucración de las personas que forman la organización, lo que es quizá uno de los aspectos olvidados en enfoques como ITIL. Porque son las personas quienes conocen la situación real, el día a día, y son por tanto quienes pueden identificar los “residuos”, proponer ajustes y cambios para maximizar el rendimiento.

Y no olvidemos que un jefe con “mentalidad Lean” tiene que involucrarse activamente, conocer de primera mano cómo se trabaja en la compañía, qué problemáticas existen, entendiéndolo como oportunidades de mejora para alcanzar la perfección y dar el mayor valor posible al cliente.

Porque, como en Matrix, para una empresa llegar a ser Neo gracias a Lean IT es una cuestión de fe. Creer en ello es la clave. Que se lo pregunten a Toyota.

Imagen: Flickr deflam

Comentarios

  1. Magnífico post Jorge.

    Lean management es no sólo un método de producción sino una filosofía de ver el negocio, una forma de pensar que está a la orden del día en industrias como la automovilística o electrónica, pero que cuesta todavía en empresas de servicios. El problema es que es necesario que todo el entorno a la empresa que busca ser “Lean” se adapte a su forma y normas, de lo contrario nada.

    Sólo un detalle que se te olvidó destacar: la filosofía Lean se basa, primordialmente, en un término japonés que supone todo una delcaración de intenciones: “kaizen”, que viene a significar una mezcla de “continous improvement” y “change for better”.

  2. Siempre queremos una formula rápida para conseguir el éxito aunque sepamos que no existe. Debemos comprender como avanzar y mejorar gracias al comportamiento.
    El comportamiento de las personas, ayuda al éxito de las empresas, comunidades, países…

    Una filosofia que nos muestra como camino para el avance, la mejora continua y la búsqueda de la perfección, tienen los ingredientes básicos para el éxito.

    Gran post, Jorge !

  3. Hola,

    Muy interesante el post.

    Por añadir alguna nota a esta interesante información: curiosamente el término “Lean” no fue creado por los Japoneses, fue popularizado por los estadounidenses, concretamente por el “best-seller” del MIT “La máquina que cambió el mundo” (1990), y fue en ese libro donde se le puso nombre (lean) a esta manera japonesa de trabajar.

    Dejo tambien este enlace http://www.javiergarzas.com/2012/10/lean-software-development-2.html con cómo, además de a sistemas, el Lean llega al desarrollo software.

    Saludos

  4. Estimado Jorge,

    Buena aportación en tu entrada. Sí quieres ver de donde viene Lean, os aconsejo que os leáis “Las claves del éxito de Toyota” en el que explica los 14 principios del modelo Toyoya (TPS). De aquí parte todo así como bien a indicado Javier el término de Lean viene de Womack y Jones, y sus respectivos libros.

    Creo que es un magnífico complemento como promulgas de ITIL, aplicando la filosofía de Lean.
    Un saludo

  5. Jorge
    Te envio este caso que es un poco complejo ya que me gustaria tener una guia tuya por tu experiencia:
    Descripción General del Negocio y el Software:
    Somos una compañia dedicada la comercialización de productos con venta al cliente final (almacen por departamentos) y este negocia comenzo como un pequeño negocio de ferreterias y ahora somos 6 almacenes en Bogotá.
    El software que tenemos es un sofware que se desarrolllo In house pero en sus Inicios no se estructuraron las aplicaciones de una forma (arquitectonica), los programadores que arrancaron con los desarrollos lo fueron costruyendo como ellos creian eran lo más conveniente.
    El desarrollo esta echo MR Cobol y corre en aix de IBM.
    El software tiene unos 18 años de desarrollo y realmente se han rediseñado programas y nuevos programas con estructua mas eficientes hace unos 4 años con nuevos programadores.

    Po lo cual se esta evaluando lo siguiente:
    1. Como RM Cobol fue comprado por Microfocus el soporte de esta herramienta RM cobol ya es más costoso, esta la opción de pasarce al nuevo Cobol que se llama Visual Cobol que es el que maneja Microfocus. esta decisión implica pagar manteniemientos anaules por Licenciamiento al doble de lo que veniamos pagando y comprar de nuevo toda las licencias para usuarios.
    2. la segunda opción es dejar el RM Cobol que se tiene porque a pesar de que haya un spagueti en el desarrollo de los aplicativos se pueden conrtatar coboleros para que lo organicen y los nuevos aplicativos desarrollarlo en java, se puede obviamente contratar programadores ya expertos en Java para que lo Coboleros aprendan más rapido.
    Para el anterio punto que tan funcional es Java en cuanto a su información y en cuanto a la transaccionalidad de datos (este es el punto más critico creo yo).?????
    Los programadores que son de Cobol que tan facil les quedara aprender y manjar la programación en Java.????, yo considero que hay que dejar el cobol como transaccional y todo la parte visual hacia los usuarios en Java (colsultas, informes, formularios, capturas etc) y que el que procese sea el RM cobol y soportarnos con una capa de base de dato para que el procesamiento no lo haga todo cobol cada vez que se require infomación ya que Cobol procesa a traves de archivo indecsados.
    3. Una tercera opción es cambiar todo a java pero eso me parece algo demasiado complejo y demorado y Java no es un Lenguaje muy comercial (trasaccional), lo veo más para paginas web, video juegos, comunicaciones etc (que opinan de Java.????)
    4.Por último esta en comprar un ERP el cual ya hemos cotizado (sap, y unos 6 más) pero sus aplicativos son muy estandares y los desarrollos son costosos y este negocio de Retail tiene muchas particularidades y requiere de Flexibilidad. Un ERP de estos realmente comprado su implementación es de 3 a 4 años y no como se lo venden que es en 6 meses.
    5. UNa última opción que es la que más fuerza creo que tiene es dejar el COBOL en lo transaccional y migrar, las consultas, informes a Java y paralos informes que requiere porcesamiento parasrlo a una Base de Datos para traerlos a Java. Esto seri 3 capas; cobol, base de datos y el java para los usuarios finales.

  6. Mi personal conclusión después de leerlos es que debo plantearme como posible negocio montar una tienda donde se vendan artículos de papelería. Con franqueza he de decir que pertenezco a los cortos de miras

  7. Muchas Gracias por el Aporte. Es de esperarse que las cosas no queden en ITIL, sino que empiecen a mutar… debemos estar alerta los que implantamos ITIL para mejorar los procesos y el resultado final.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *