eFuncionario

Interesantísimo el artículo de Daniel Gómez Hidalgo, “La Meta”, analizando algunas de las actividades y formas de operar de las unidades TIC de las Administraciones desde el punto de vista del libro de Eliyahu Godratt del mismo título.

Este artículo empezó por ser un comentario en el blog de Dani, pero viendo que la cosa iba para largo, decidí convertirlo en un post propio para mayor claridad.

En efecto, el libro “La Meta” describe de forma novelada las dificultades con las que se encuentra el gerente de una fábrica, al que le dan tres meses de plazo para conseguir que la fabrica consiga sacar adelante la producción requerida por el negocio, a pesar de una reciente tanda de despidos acompañada de la reducción de jornada. La alternativa, en caso de no conseguirlo, es el cierre de la fábrica.

El paralelismo, en muchos aspectos, entre la situación descrita en “La Meta” y la situación actual en las unidades TIC de la Administración, es evidente. En una reunión de Dirección,  Peach, el Vicepresidente de la División, está diciendo:

 «… es imperativo que minimicemos el riesgo relativo… aceptable en nuestra presente situación de mercado…, sin reducir los gastos estratégicos… requieren sacrificios… aumentos de productividad en cada puesto de trabajo…»

«… y la respuesta es evidente —continúa Peach—, el futuro de este negocio depende de nuestra habilidad para aumentar la productividad.»

A los que aún no hayan leído el libro y lo quieran hacer, les sugiero dejar la lectura de esta artículo ahora, pues voy a desvelar el meollo de algunas cuestiones nucleares del mismo. Para el resto, vamos a ello.

El libro trata en realidad de dos asuntos:

• Cuál es verdaderamente “la meta”
• Cómo llegar a ella

En realidad, ambas cuestiones están relacionadas. Ya que el primer problema surge porque suele creerse que la meta es otra distinta de la que realmente és. Y los intentos para alcanzarla van pues en la dirección equivocada. Por ello, el resultado de los esfuerzos, siempre bien intencionados, es el fracaso.

En el ejemplo del libro, una fábrica que elabora algún tipo de material o equipos, parece sobreentenderse que el objetivo es “aumentar la productividad”, a pesar de los recientes recortes, sobre todo en personal y mano de obra. Para compensar estos recortes, se han adquirido robots, los cuales, nominalmente, suponen un aumento importante de la productividad, con unas cifras que rondan entre el 30% y el 40%. Sin embargo, y analizando más la situación, resulta que esos aumentos de productividad “locales” en las secciones donde se han instalado los robots, no han supuesto un aumento de productividad “global” en la fábrica. En realidad, la fábrica funciona igual o peor que antes de la instalación de los robots.

La respuesta a esta aparente contradicción reside en que el objetivo de la fábrica no es maximizar la productividad (normalmente definida como el número de unidades de salida dividido por los recursos empleados para conseguirlas), sino maximizar los resultados, los cuales se consiguen maximizando la siguiente ecuación:

Resultados (beneficio neto) = Ingresos netos (ingresos brutos-coste de las materias primas) / inventario * costes operativos

Es decir, que los resultados serán mejores cuanto mayores sean los ingresos netos, cuanto menores sean los costes operativos, y cuanto menor sea el inventario.

De ahí se deduce que un supuesto objetivo “bueno” que es aumentar la producción, lo cual genera un aumento de la productividad (mas unidades fabricadas con el mismo coste) es en realidad malo, si esa producción no se “vende”, pues se convierte en inventario, el cual en lugar de beneficios, genera costes. Lo que es más, si algunas de las unidades productivas se convierten en “óptimos locales”, es decir, fabrican muchas piezas, pero que la siguiente etapa no es capaz de absorber, también generan inventario y por lo tanto la productividad local es opuesta y contraproducente para lograr la productividad global.

Todo esto, si no me equivoco, es la teoría del “lean manufacturing” que tiene, como no podría ser menos, orígenes orientales (Caso Toyota) ya que está basada en el equilibrio (Ying-Yang) a lo largo de todo el proceso productivo.

Una vez que entendemos que el verdadero objetivo es global y no local, que es globalmente donde debemos maximizar el rendimiento y resultados, el siguiente paso es la optimización: ¿cómo logramos maximizar los resultados globales?.

Para ello, el sistema propuesto es localizar los cuellos de botella, es decir, los puntos donde se acumula el inventario en su entrada, que normalmente son la salida de las unidades con mayor rendimiento o productividad. Para equilibrar el sistema y optimizarlo, no basta con reducir la producción de estos puntos de máximo rendimiento, sino que además hay que trasladar recursos de estos puntos “sobrantes” a los cuellos de botella. De este modo al aumentar el rendimiento de los cuellos de botella, se obtiene como efecto directo la reducción de inventario, y como efecto indirecto la optimización de todo el proceso, lo cual, además de la reducción de costes, lleva a la reducción de los plazos de fabricación y entrega de los productos.

Como podemos ver, los aspectos esenciales de todo ello son:

• Entender correctamente el objetivo como global y no local. El esfuerzo local puede empeorar los resultados globales.
• Las soluciones no son aumentar los recortes o pedir más esfuerzos a la gente. Las soluciones son organizativas.

El lean manufacturing aplicado a las unidades TIC de la Administración. Definiendo la meta.

A partir de aquí, Daniel Gómez-Hidalgo hace el notable esfuerzo de aplicar estos principios a una unidad de Desarrollo de Aplicaciones de la Administración. Yo haré el mío propio, no sin antes advertir que es simplemente otro punto de vista, a partir del iniciado por Dani, sin ánimo de polemizar sino de enriquecer.

La aplicación del Lean Manufacturing a las unidades TIC no es descabellado ni nuevo, y hasta tiene su propio nombre: Lean IT. El enfoque Lean es visto hoy día no como una opción sino como uno de los principales enfoques a aplicar para sacar adelante cualquier unidad o negocio TIC hoy en día. El paralelismo nos permite hacer una sencilla asociación, como dice Wikipedia (traducido por mí del inglés):

…mientras que la función de producción fabrica bienes de valor para los clientes, la unidad de TI “fabrica” servicios de negocio de valor para la organización a la que pertenece y sus clientes. Al igual que en la fabricación, el desarrollo de servicios de negocio implica la gestión de recursos, gestión de la demanda, control de calidad, control de la seguridad, etc.

Aquí es importante entender que el “valor” del producto o servicio no lo define el fabricante o proveedor, lo define el cliente. A la hora de definir el verdadero valor de nuestro producto o servicio, por lo tanto, será el cliente el que diga cuánto está dispuesto a pagar por ello. Este es un factor común entre las metodologías y catálogos de buenas prácticas al uso como Six Sigma, ITIL, etc.

Así pues, el cliente es el que “paga”. Hay una importante distinción entre cliente y usuario, ya que usuario es el que usa el producto o servicio, pero en ocasiones, sobre todo cuando hablamos no de personas sino de organizaciones, el que paga y el que usa pueden no ser el mismo.

En el caso de la Administración, estas definiciones pueden no estar tan claras como en el caso de una empresa comercial. Argumenta Dani, que:

Obviamente a diferencia del libro, donde es una empresa la que se analiza, la meta de la Administración Pública no es el dinero o al menos no debería serlo, sino que es prestar cada vez mejores servicios al ciudadano y a las empresas, a la vez que optimizar el uso de los recursos públicos, creados y mantenidos con los impuestos de aquellos.

Sin embargo, el concepto de “entrega de valor” sí es igualmente aplicable a las organizaciones públicas y privadas. La diferencia es cómo lo medimos. En una empresa, a través de las ventas, las cuales son reflejo de cuántas personas están dispuestas a pagar una cierta cantidad de dinero por nuestros bienes y servicios. Pero, ¿y en una Administración?.

Pues depende. Evidentemente, la definición concreta va a depender del tipo de organismo y de su función o funciones hacia la sociedad. Pero en muchos casos se pueden hacer aproximaciones plausibles. En el caso de organismos que reciben algún tipo de ingresos, via impuestos o tasas, los resultados pueden incluir en su formulación el factor económico, no asociado al concepto de ventas, pero sí de ingresos, los cuales pueden ser función de la forma y calidad de los servicios existentes para conseguirlos, y cuando hablamos de TIC, de los ingresos obtenidos a través de trámites realizados por vía electrónica. Esto es aplicable al conjunto de unidades u organismos dedicados por ejemplo a la gestión de impuestos (AEAT), gestión de sanciones (DGT), y también a las unidades que reciben ingresos por la prestación de servicios en forma de tasas (SETSI, OEPM, etc.).

¿Y para el resto?. Pues igualmente podemos asignar un valor unitario al trámite en función del valor para el cliente (ciudadano o empresa) que lo utiliza, y multiplicarlo por el número de veces que ese trámite es usado, lo cual nos da un valor económico “virtual” de nuestro producto o servicio. Ya sé que es dificil y aventurado asignar ese valor “unitario” al trámite en una situación que no es de libre mercado. Sin embargo, se han hecho intentos, como por ejemplo la atribución de un ahorro de alrededor de 80 euros (para el ciudadano o empresa) por cada trámite electrónico en lugar del trámite presencial, lo cual podemos usar como punto de partida.

En el caso de los servicios internos, es decir, aquellos que proporcionan las unidades TIC hacia el interior de su organización, o el de los servicios de intermediación hacia otras administraciones, quizás es aún más complicado calcular el valor de estos servicios. Sin embargo, es un ejercicio que debemos hacer. Según los casos, podemos adoptar unas técnicas u otras, pero una sencilla que se me ocurre es hacer una estimación del daño (convertido a euros) que supondría para la organización la detención del servicio, para una unidad de tiempo dada, dividido por el número de utilizaciones de ese servicio que se realiza en esa misma unidad de tiempo.

Así por ejemplo, podemos estimar el daño que se produciría para un Ministerio la paralización derivada del sistema de correo electrónico durante una semana, dividido por el número de usuarios de ese Ministerio que tienen buzón de correo electrónico, y por el número medio de veces que acceden al correo, cada uno de ellos, en el plazo de una semana. Eso nos daría una estimación económica del valor unitario del servicio de correo electrónico para la organización.

Puede parecer que las cifras sean muy ficticias o descabelladas, pero no olvidemos que el objetivo no es tener un valor operativo real, sino un valor de referencia que nos permita la optimización de resultados, y por lo tanto, del proceso realizado para conseguirlos.

En mi opinión, no son buenas métricas de resultados parámetros como las encuestas de satisfacción de los usuarios, ya que por un lado los usuarios no son el cliente (por ejemplo, los usuarios de una aplicación de contabilidad pueden estar en varios departamentos. El cliente sería, en primera instancia, el jefe de la unidad de contabilidad) y por otro lado los resultados dependen también del número de usuarios y del número de veces que se utiliza la aplicación o servicio, los cuales no quedan adecuadamente reflejados en las encuestas de opinión.

Ello no quiere decir que no sea importante contar con los usuarios a la hora de diseñar aplicaciones o servicios. Al contrario, es esencial, pero con la vista puesta en conseguir el máximo valor para el negocio. Para ello, en primer lugar se debe contar con los usuarios y el cliente desde las fases iniciales de definición del proyecto, asegurando que cumple sus expectativas y necesidades para la realización de sus funciones. En segundo lugar, debe hacerse un análisis de necesidades y de la capacidad necesaria para definir el servicio. En tercer lugar hay que analizar los marcos temporales y económicos existentes. No hay nada peor que incumplir los plazos o gastar el doble del presupuesto previsto, pues ello repercute directamente en el valor entregado. En cuarto lugar, debe haber un control de calidad de los productos en todas las fases del proyecto, pero especialmente en los momentos de la entrega del producto o servicio y su entrada en explotación. Y ya por último, todo lo anterior será mucho más fácil y eficaz gracias a la aplicación de alguna de las metodologías de gestión de proyectos o servicios TI existentes.

Optimizando las unidades TIC

Hemos visto por lo tanto que uno de los primeros objetivos a la hora de gestionar las unidades TI de la Administración es definir lo mejor posible los resultados esperados en términos de valor para el negocio y los clientes del mismo. Esto es obviamente difícil y en cada caso particular requerirá un esfuerzo dirigido a las características de la organización a la que pertenecemos, los servicios que ofrece, y los recursos de los que disponemos, así como de la estructura organizativa existente.

A continuación, y siguiendo las recomendaciones del Lean Manufacturing, procederemos a optimizar nuestro funcionamiento, buscando para ello dos elementos esenciales: los cuellos de botella, y los excesos de inventario.

Los cuellos de botella son identificables por dos síntomas, uno es que es donde se producen los mayores retrasos en la entrega de los servicios, y por lo tanto los que están sometidos a mayor presión, y otro porque es donde se acumulan los excesos de inventario a su entrada.

Así por ejemplo, en una subdivisión clásica de una unidad TIC entre Sistemas y Desarrollo, los cuellos de botella pueden encontrarse, en el punto donde los productos preparados por Desarrollo pasan al servicio de Explotación. Esto puede suceder porque los responsables de una y otra unidades son diferentes, y como tal, el responsable de los Desarrollos tiene como objetivo (óptimo local) la entrega de su programa a explotación, y por lo tanto maximiza su trabajo para realizar las entregas lo antes posible. Pero cuando hay varios proyectos en marcha y coinciden las entregas de todos ellos a la vez en los servicios de Sistemas, puede suceder que no sea posible atenderlos a todos, y por lo tanto se forma una cola de pasos a explotación y se genera un exceso de inventarios en forma de versiones de aplicaciones esperando ser pasadas a explotación.

En esta situación es muy fácil al responsable de Desarrollo (que está normalmente más cerca de los usuarios de negocio) echar la culpa de los retrasos al responsable de Sistemas, lo cual no sólo no mejora la situación sino que la empeora, al crear una presión añadida sobre el departamento de Sistemas, el cual no tiene forma por si mismo de mejorar la situación.

La situación puede llegar a ser aún peor, si como consecuencia de las “urgencias” o la presión de los usuarios de negocio, las entregas de versiones se aceleran, para lo cual se eliminan los controles de calidad y las pruebas necesarias antes de cada entrega. De ese modo, se generan aún más entregas (más trabajo para el colapsado servicio de Sistemas) y los productos de baja calidad entregados, además de funcionar mal y dar un mal servicio al usuario, generan trabajo adicional como consecuencia de las inevitables versiones nuevas para corregir los errores de las anteriores versiones.

¿Qué podemos hacer para optimizar la unidad TIC?

Una primera acción es equilibrar los departamentos, desviando recursos desde el lugar donde “sobran”, es decir, donde se genera el exceso de producción, al lugar donde “faltan”, y de este modo agilizando el cuello de botella. Esto no siempre es fácil, en primer lugar por la especialización requerida, que puede que no sea igual en Desarrollo y en Sistemas, y en segundo lugar como consecuencia de la “mala fama” que ha adquirido el cuello de botella: un lugar donde se trabaja mucho y donde se reciben todos los “palos”. ¿Quién iba a querer ir a un sitio así?.

Por lo tanto es necesario adoptar otras medidas. Como hemos visto, una de las causas del embotellamiento es la mala calidad de las entregas, por lo que es buena idea el establecimiento de un Servicio de Calidad, dotado de su propio entorno (“preproducción”) donde pruebe las entregas, y con la potestad de validar, o rechazar, éstas, en funcion de determinados parámetros de funcionamiento. Esto es válido, no lo olvidemos, tanto para los equipos de desarrollo “propios” como para aquellos contratados externamente ad-hoc para un proyecto determinado.

La coordinación entre proyectos también es un factor clave. Para evitar el efecto “todos a la vez” lo ideal es que las entregas se planifiquen coordinadamente con suficiente antelación, y sobre todo que se coordinen con el departamento de Sistemas ANTES de comprometer las fechas de las entregas con el usuario.

Todo ello, como lo anterior, son funciones que idealmente debe desarrollar una unidad especializada, que además de las funciones de control de calidad desempeñe funciones de control de proyectos y gestión de la arquitectura. Una oficina de proyectos es el mejor medio conocido para implantar todas o una parte de estas funciones. Asociado a la Oficina de Proyectos, es necesaria la adopción de estándares y metodologías de valor probado que no sólo mejoren el funcionamiento sino que otorguen indicadores de negocio y cuadro de mandos (Balanced Scorecard)

¿Una unidad TIC idílica?

Soy perfectamente consciente de que todo lo anterior se puede llevar a cabo en condiciones idílicas, pero la situación real en las unidades TIC de la Administración puede ser muy diferente, desigual en algunos casos, bastante difícil en otros.

Una dificultad evidente puede ser la diferencia entre las visiones de “valor” para el negocio arriba expresadas y las del mismo concepto en manos de los diversos directivos o jefes de unidades no TIC, y por lo tanto, la dificultad de llegar a un acuerdo que permita trabajar a todos en pos de un objetivo común.

Un segundo problema es la situación de recortes y ajuste sostenido en la que llevamos ya varios años, lo que dificulta aún más la adopción de medidas transformadoras. Sin embargo, la alternativa a transformar es sencillamente aceptar la degradación progresiva de los servicios. Esto debe estar muy claro como palanca para obtener el apoyo de la Dirección en pos de realizar los análisis y adoptar las medidas necesarias.

Para rematar este larguísimo artículo, que seguramente daría casi para escribir un libro, algunas ideas resumen y de concepto:

Esto es lo que entiendo yo por una unidad TIC de la Administración:

El objetivo de una unidad TIC de la Administración debe ser la entrega de servicios TI a la organización a la que pertenece, y a la sociedad (ciudadanos y empresas) y a otras Administraciones, definidos según las necesidades, funciones e instrucciones directas de la dirección del organismo al que pertenece, así como de la legislación aplicable, con el objetivo de maximizar el valor de los servicios entregados a su propia organización, y aquellas de las que ésta depende, al resto de Administraciones, y a toda la sociedad, optimizando para ello los recursos disponibles, tanto materiales como organizativos.

Así pues, hasta donde se me alcanza, el objetivo es la entrega de servicios TI, y para ello contará con recursos propios, como unidades de producción en el ámbito de Sistemas o Desarrollo, unidades de coordinación y gestión de proyectos, arquitectura, calidad y seguridad, y recursos externos o contratados, para lo cual son necesarias también unidades de contratación y gestión económica y presupuestaria y unidades o servicios de gestión de los servicios externos contratados.

Como ejemplo de lo que podría ser una buena organización de una unidad TIC, veamos este ejemplo tomado de una reciente oferta de empleo de la OAMI:

The mission of the Business Information Technologies Area is to supply all necessary information technologies services to the Office in order to support and allow the business reach its goals. Under the authority of the Deputy Director, the Area comprises five services, each managed by a Head of Service:

• Operations and Infrastructure, responsible for operating and managing the IT infrastructure, performing quality control and deploying applications and managing IT security.
• Architecture, responsible for defining and maintaining business, application and technical architecture as well as corresponding standards.
• Governance, responsible for governance structure, processes, the Project Management Office and for the monitoring and follow-up of the implementation of the Strategic Plan.
• Applications Development and Maintenance, responsible for project management, development and maintenance of the business information systems.
• Vendor Management and Support, responsible for managing IT performance and, in cooperation with other concerned services, IT vendors, budget and contract management.

Para estar en condiciones de cumplir sus objetivos y de optimizar su funcionamiento, es esencial que se cumplan al menos tres condiciones:

• La unidad TIC debe ocupar el lugar adecuado en la organización, en contacto directo con la Dirección del mismo, ya que es necesario para que las funciones y servicios TIC estén alineados con los objetivos de negocio y sean definidos conjuntamente con las funciones operativas del resto de las unidades.
• La unidad TIC debe estar compuesta por profesionales TIC adecuadamente capacitados y motivados, conocedores de su ámbito profesional tanto por formación como por experiencia.
• Es necesaria la aplicación de metodologías de gestión de los servicios (como por ejemplo ITIL) y de la producción (ej. Six Sigma), la gestión de los proyectos (ej PRINCE2) y de gestión de calidad del software y de la contratación (ej. CMMI, ISO 9000, etc.)

En fin, con esto me despido de todos por este puente, para los que tengan tiempo, y recomiendo la lectura del libro de Antonio Muñoz Molina “Todo lo que era sólido”, un poco para remover conciencias y para animarse a que, a pesar de las dificultades, es preciso seguir trabajando profesionalmente por una mejor Administración.