/* PERSONALIZACION DE LUIS

23/9/08

A precio cero demanda infinita...


... es lo que pasa en muchas situaciones y diversos entornos pero Ángel Medinilla, hablando del síndrome de la barra libre en las peticiones que hacen los usuarios al departamento de IT, me lo ha recordado relacionado con una experiencia interesante que viví (sufrí) cuando estaba al otro lado de la barrera como director de IT (o similar).

Cuando llegué al susodicho puesto me encontré una situación donde la parte "hard" de mis responsabilidades, esto es, la pura tecnología, estaba muy bien resuelta. Comunicaciones e infraestructuras de primera (algunas venían directamente de los EEUU, eran el "estado del arte" y ni siquiera se podían comprar razonablemente en España) y personal técnico al cargo (también de EEUU) supercompetente del que aprendimos mucho yo y mi equipo de "europeos" que éramos los que dábamos el servicio en la región (EMEA).

Pero ¡ay!, la parte "soft", la organización y gestión del servicio y equipo humano, era un poco desastre.

No me extenderé en todas las batallas que tuve que sostener, algunas las perdí, sólo en una de ella y que está relacionada con lo que Ángel, en su entrada, denomina, ya lo he dicho antes, el síndrome de la barra libre y que yo resumo en la frase que da título a ésta entrada: A precio cero demanda infinita.

Sigo con la batallita: Me encontré un equipo de soporte desbordado por las peticiones de los usuarios: sin método, filtros, niveles, ... barra libre en su máxima expresión. Una especie de chicos para todo en cualquier momento que habían logrado sobrevivir en ese entorno y que, sin más remedio, lo asumían como parte inevitable de su trabajo.

Inicialmente ataqué a la parte interna: organización, niveles, ticketing, registro y reporting de actividad, ... sota, caballo y rey, nada que valga la pena comentar.

Algo después me atreví con la parte externa, los clientes/usuarios y aquí vino lo bueno:

Primero me centré en la Evangelización, en propagar que IT Matters. Hacerle ver a un CxO, sobre todo a los comerciales, que eso por lo que no paga nada, tiene valor es una tarea, creedme, difícil.

Conclusión: antes había que hacer visible el coste de las IT para los países y departamentos - algo arriesgado me diréis, ya que era poner a esos CxO's en el punto de mira de mi CxO favorito, el CFO o director financiero. Mi estrategia fue aliarme con él - le convencí de que una de mis prioridades era el control del gasto (que él ya sabía que era desbocado) y que quería participar más activamente en la elaboración y control de los presupuestos de los países y departamentos.

Dicho y hecho, ese verano pasé la mayor parte de mi tiempo en crear un modelo de presupuestación para las partidas de IT que partiese de conceptos cercanos a IT (hasta ese momento se presupuestaba directamente sobre cuentas contables) y basado filosóficamente en el pago por uso, lo que hizo que el presupuesto de IT fuese a ser más ajustado a la realidad y sobre todo gestionable de una forma más proactiva y no reactiva cuando te llegaba el report mensual.

El modelo era muy ambicioso y se basaba en una adopción gradual de los siguientes principios:
  • Imputar los costes directos de material de IT a cada país/departamento. Este principio era relativamente fácil de aplicar aunque requirió un esfuerzo relevante para inventariar en detalle todos los elementos de hardware de uso directo en cada país/departamento. Si el hardware era comprado se aplicaba el coste de amortización y si era por leasing/renting pues el importe de la cuota. Las compras directas tipo consumibles iban directas.
  • Imputar los costes indirectos de material de IT a cada país/departamento. Este ya era más complicado de aplicar ya que se trataba de repartir costes de recursos compartidos y no siempre era fácil disponer de la información necesaria para ello. Por ejemplo, para repartir los costes de la plataforma de correo teníamos que medir de alguna forma el uso que se le daba en cada país/departamento. ¿Cómo se medía el uso?,... ¿por número de correos enviados, por ocupación del disco?, ... luego, ¿qué importe repartes?,... licencias, coste mensualizado del hardware (amortización), salario del personal dedicado, ...? Se puede calcular todo en principio, sólo hay que disponer de la información y consensuar los criterios de reparto.
  • El siguiente paso era ya un salto cualitativo y consistía en imputar los costes directos de personal consumidos por cada país/departamento. Se dice pronto pero este principio es una bomba: tienes que empezar consiguiendo que tu equipo registre su actividad y se la asigne a un centro de coste (país/departamento). Para personas que nunca lo han hecho es un concepto extraño y si encima están desbordadas por el día a día, es muy difícil - me dejé algunos espolones en ello. Después, tienes que poner una tarifa a los servicios que das - es decir, los has de cuantificar primero y lo que es más duro, los haces comparables con proveedores externos. Así puedes demostrar que eres más eficiente (si lo eres claro), aparte de meterte en las guerras de tener que discutir los partes de actividad al final de cada periodo con los países/departamentos. Luego estaba con el tiempo que no podías asignar a nadie (siempre podría salir el que preguntase qué hacen los de IT en ese tiempo no asignado - mucha presión). Si tenéis la ocasión y voluntad, antes de meteros en una guerra como ésta, pensadlo bien porque abrís muchas cajas de Pandora.
  • Un siguiente paso, que ya no me atreví a plantear, es convertir al departamento de IT en una especie de centro de beneficio, donde se disponía de un portafolio de servicios TIC que los departamentos cliente consumían y eran facturados por ello. El tema tenía sentido porque al ser una región multipaís se podía pensar en un centro de servicios TIC compartidos, incluso con entidad jurídica propia - es un modelo que existe y funciona (al menos tres de mis clientes actuales lo tienen). Es convertir al departamento en una empresa de servicios, interna o externa, con todas las consecuencias.


Como veis este modelo se basaba en traspasar el presupuesto de IT de cada país a cada país/departamento cliente. En algunos entornos esto puede parecer un suicidio - tanto presupuesto manejas tan importante eres, ¿no?. Para mí era una manera de incentivar la reducción de costes (en el momento en que traspasas ese presupuesto traspasas también el control de su cumplimiento). Este era el motivo aparente, pero en realidad lo que buscaba era hacer visibles esos costes y por encima de todo hacer patente el valor de IT a los CxO's. Y creo que eso lo logré, al menos de forma teórica en los comités de dirección, donde conseguí explicarlo y que me aprobaran el plan a tres años.


Finalmente no me dio tiempo a implantar el modelo (el plan era hacerlo a tres años), el primer paso sí y el segundo a medias. Me fui - volví al lado oscuro - antes de acabar, donde lo he intentado vender en alguna ocasión pero con fracaso absoluto.



Entradas relacionadas:

5 comentarios:

Antonio Valle dijo...

Jo.der, tio! Vaya peaso de post.
Si señor... has dado en el clavo de las cajas de pandora y de la inexistencia de modelos claros para la contabilidad de costes del area TIC de las empresas *con significado*.

Yo tambien lo he intentado.. y he fracasado en el intento!

Pero tengo fe en ello y creo que algun dia lo conseguiré.

Antonio

Anónimo dijo...

Apasionante tema. Pero muy complicado de gestionar, especialmente sus consecuencias. Salvo que tengas un apoyo clarísimo del CFO o incluso más arriba. ¿Por qué? Por varias razones que intento resumir.

- Siempre hay un caso en que el CxO de ese área puede estar tentado de elegir otra opción más barata. A él no le importara que no sea compatible con el resto de la compañía o posibles complicaciones posteriores. Cree que un precio que puede conseguir "por fuera" es mejor (ejemplo: comprar PCs en MediaMarkt en vez de en DELL/HP).
- Unido a eso, tentación de buscar atajos para saltarse el dpto de TI (Office pirata, tamatgochis en Access que luego no mantiene nadie..).
- Peligro de obsolescencia del dpto. Una aplicación en un nuevo lenguaje me costará 125 respecto a la base de 100 de usar lo que ya conozco. Pero ese 25 "extra" me permite que el equipo de desarrollo actualice conocimientos, se prepare para el futuro y, además, genera cierta motivación extra. Será difícil que el COO pague ese 25% más y preferirá que sigas con el COBOL.
- Reparto de "ahorros". En ocasiones, un desarrollo/proyecto tiene unos costes de aprendizaje/instalación que se repercuten al proyecto A pero luego mejoran los resultados de los proyectos B, C y sucesivos. ¿Cómo le devuelves ese ahorro al que "pagó" A?. Ejemplo, instalas un BusinessObjects para comercial sobre el que luego montar un datamart para financiero.


Este es un ejercicio para llevar la contraria, la idea me parece excelente y, de hecho, estamos en algo parecido, aunque el no tener atados todos estos extremos me ha hecho, hasta ahora, evitar la publicación de los datos.

luis.[tic616] dijo...

Gracias Antonio, sólo soy un aprendiz autodidacta. A ver si los "maestros" de verdad os animáis a contar más

Buena disección del tema Rafa, no es fácil no

Anónimo dijo...

Mis experiencias en los departamentos de sistemas de Cruzcampo y Exel me llevaron a implantar esos métodos de gestión de servicios de puertas para adentro, pero no hacia fuera, por lo que explica Rafa.

Lo de la "barra libre" lo manejaba en los comités de dirección (mediante informes y planes con datos), o directamente con el director general de turno (con los que tenía muy buena relación).

Ello no evitaba que los CxO se quejaran y culparan "a los de sistemas" de que estaban muy condicionados porque no les prestábamos el servicio que demandaban y decían necesitar. El CEO les escuchaba, les consolaba, les pedía que hicieran lo que pudieran y les decía que hablaría conmigo.

Cuando lo hacía, a mí me pedía que siguiera igual. Debo decir que ambos directivos conocían el trabajo de sistemas de información casi tanto como yo.

Anónimo dijo...

Rafa da en un clavo sensible. Da para un post... Nos vemos en "mi sitio" O:-)