Gastando el presupuesto del año que viene

0

Estamos en fiestas y en estas fechas proliferan por la blogosfera tres tipos de artículos:

  • Los diez nosequés de este año.
  • Las diez previsiones para el año que viene.
  • Los diez regalos que hay que pedirle a los reyes.

De este último grupo me llaman la atención los artículos sobre qué debe incluir en sus presupuestos el departamento de TI. Si sois usuarios habituales de twitter seguro que ya habéis visto pasar más de uno de este tipo. ¿por qué saco el tema? Porque me han hecho pensar en un error que comenten los departamentos de TI, pero que en cambio cualquier manual de buenas prácticas de  servicios TI te dice que tienes que evitar: presupuestar top-down en vez de down-top.

La realidad detrás de “las listas a los reyes”

Cuando lees estos artículos casi todos hablan de “en qué gastar el presupuesto del año que viene”. La conclusión que saco de esta frase es que hay un presupuesto asignado a TI y que hay que elegir en qué nos gastamos la pasta este año. ¿No os parece un error de planteamiento? Lo lógico sería ver en qué es adecuado invertir en TI y luego elaborar el presupuesto. Pero la realidad que yo he vivido, y la que me comentan muchos compañeros, es que tanto en la administración pública como en la empresa privada es muy habitual plantearlo al revés. Se plantea desde la base del coste de TI en el pasado, el presupuesto que se tendrá para el año siguiente, y TI decidirá en qué gastarlo. Es la visión habitual top-down. Y creo que tendría que ser al revés.

Como debería hacerse el presupuesto

Desde mi punto de vista el presupuesto de un departamento de TI lo forman 3 conceptos:

  • Costes fijos de mantenimiento. Independientemente de cuanta demanda tengamos hacia TI, estos costes estarán siempre. Resolución de incidencias, soporte presencial, evolutivos y correctivos, son ejemplos de mantenimiento. Otros pueden ser licencias o contratos comprometidos, o coste de la plataforma de producción base.
  • Costes variables según demanda. Son costes que dependen directamente de la demanda que se nos solicite. Un indicador de demanda que siempre está es el número de empleados a los que hay que dar soporte. Otros pueden ser la cantidad de ventas que esperamos tener (y que nuestros sistemas de TI deben soportar) o el número de peticiones por segundo que esperamos tener en determinada API. Aquí tenemos costes como los puestos de trabajo (mantenimiento + compra de nuevos), licencias o costes de servidores que dependen de la demanda.
  • Proyectos o expectativas de desarrollo. No hablamos de definir con exactitud los productos o nuevas funcionalidades, sino de tener una idea de cuantas personas necesitaremos desarrollando todo esto.

A la hora de explicarlo a Muggles me gusta usar la metáfora del tráfico de un pais:

  • Los costes fijos son el mantenimiento de nuestra red de carreteras. Hay que invertir en eso sí o sí. Si no se invierte, la carretera se degradará, será más caro repararla y te generará accidentes y otros costes superiores al mantenimiento.
  • Los variables según demanda son los costes de la policia, servicios sanitarios y demás personal. Dependen de cuantos vehículos transiten. Si esperamos un incremento de desplazamientos, necesitaremos más agentes.
  • Los proyectos, son la construcción de nuevas carreteras o la mejora de las actuales.

Excepto el primer punto, los otros necesitan de un input desde negocio, y esa es la clave para elaborar correctamente los presupuestos de TI.

No se puede hacer un presupuesto sin conocer la demanda que tendrá TI

Aquí hay dos opciones:

  • O nos indican la demanda que se tendrá,
  • o hacemos un presupuesto variable en base a la demanda.

Personalmente me gusta hacerlo mixto:

  • El coste de TI por empleado me gusta calcularlo y dar dos cifras a negocio: coste mensual por empleado y coste por nuevo empleado. El coste por nuevo empleado incluye la inversión en un nuevo equipo. El coste mensual incluye las reparaciones, el soporte, las licencias y todos los costes que tenemos asociados a los empleados.
  • El coste por volumen de negocio, me gusta que me den una expectativa desde las áreas comerciales, y así desarrollar el presupuesto. En base a esto, indico el coste anual, pero con un corolario: si se supera la demanda, cada X más en ventas supondrá Y más en coste. Así quedo blindado.
  • El coste de desarrollo. Aquí me gusta cerrarlo del todo. Se pacta el tamaño de los equipos y ya veremos que somos capaces de hacer.

Es decir, en parte nos dicen la demanda, en parte nos la estiman y en parte lo hacemos variable.

Por supuesto todo el presupuesto que se entrega a dirección debe estar condicionado a decisiones que se tomarán en niveles más altos. Por ejemplo, Podemos decir que tendremos 300K € anuales en desarrollo para el producto A, que podrían reducirse a 120K € si no se pretendiese cambiar el site eCommerce ese año. O el coste por empleado será de X, y se añadirá Y si se decide colocar doble monitor a todos los empleados. Es decir, las decisiones sobre lo qué hacer no las tomamos desde TI, sino que informamos a negocio de las opciones que hay, los costes y los beneficios que se esperan. Así negocio nos definirá el presupuesto final.

Desde mi experiencia cuando a negocio se le propone cambiar el modelo top-down a uno down-top (que es lo que propongo) es que primero hay un rechazo. Pero cuando se le entrega el presupuesto de la otra manera, lo agradecen.

El último problema

La principal contra de cambio de mentalidad es el tiempo. En la mayoría de sitios que veo los presupuestos empiezan a hacerse cuando ya deberían estar acabados, y se hacen deprisa, corriendo y mal. Hablamos de una de las decisiones más importantes del año, y deberíamos dedicarle el tiempo adecuado. Yo me he encontrado un jueves a medio día con mi jefe mandándome un mail y diciéndome que hay una plantilla en Excel para el presupuesto del año que viene y que la necesita el viernes por la mañana, para revisarla y mandarla antes de que acabe la semana. Por supuesto en esa realidad se hace muy difícil hacer un buen presupuesto.

Presupuesto

Sobre el autor

Jose M. Huerta

Jose es Gestor de TI en Mallorca. Es Ingeniero de Telecomunicaciones y obtuvo el Master of Advanced Studies durante su etapa como investigador. Pero no tardó en abandonar ese mundo y meterse de cabeza en el mundo de las Tecnologías de la Información. Está certificado como ITIL Expert. Tiene amplia experiencia en gestión de servicios, clásica e integrada con desarrollo, gestión de desarrollo de software, usando metodologías clásicas, o desarrollo ágil, gestión de programas y portfolios, gestión de grandes grupos de personas, localizadas y off-shore, sin dejar de perder de vista el lado técnico y freak del sector. Ha trabajado en varias empresas del sector con distintos roles en áreas tanto de gestión de servicios de soporte como de equipos de desarrollo. Actualmente trabaja en WebBeds, como responsable del equipo de operaciones TI.

Sin comentarios