El retorno de inversión para proyectos de tecnologías de información.

El retorno de inversión para proyectos de tecnologías de información.

Uno de los temas que ha sido motivo de investigación personal, conjuntamente con el tema de la administración del riesgo y alineación táctica gerencial versus la planificación estratégica corporativa, la ha constituido lo referido al retorno de inversión para proyectos de tecnologías de información.

Existen muchas variables cuantificables que los expertos en finanzas usan a la hora de evaluar proyectos de inversión. Los más comunes tenemos el Retorno sobre la Inversión o ROI, que técnicamente es una métrica simple, otra es el VAN o Valor Presente Neto o el TIR o Tasa Interna de Retorno. Estos indicadores efectivamente funcionan y algunos valores interesantes nos van a ofrecer para poder determinar si el proyecto de tecnología que estamos evaluando pareciese financieramente razonable. No descarto nada y todos los alegatos, cifras, indicadores y métricas que nos permitirán sustentar ante la Dirección la aprobación o por lo menos la evaluación del cambio es buena y aceptable.

Sin embargo debemos ser muy cuidadosos y responsables como consultores y asesores empresariales en evaluar y determinar cual métrica usar según el caso, ya que no siempre serán de valor para el proyecto de evaluación que estaremos realizando y sólo serán efectivos como los supuestos que utilizaremos en su cálculo.

Un cambio de un ERP de gestión empresarial, no necesariamente implicará un incremento en las ventas, o una reducción de las notas de crédito por devolución de mercancía o la disminución en el despacho de la mercancía. Unos de los aspectos que más apoya y donde se debe enfatizar un proyecto tecnológico es la minimización de los niveles de exposición de riesgos con impacto económico.

Un proyecto de evaluación tecnológica debe estar sustentado en una simple respuesta a una simple pregunta: Porqué debo cambiar el sistema o la plataforma?. Si la respuesta es que el nuevo sistema es mejor, más eficiente, utiliza X ó Y tecnología, que tecnológicamente nuestro sistema es obsoleto, seguramente no le estaremos dando a la Dirección General la respuesta contundente que sustenta nuestra solicitud del cambio. La respuesta debe ser contundente, precisa y medible. Mejor, más moderno, más seguro, no se mide, es complejo cuantificar y menos determinarlo en el presupuesto de inversión. Los argumentos anteriores son secundarios y circunstanciales, pueden hacer inferir a la dirección que algo no anda bien en el sistema o que el responsable del área no sabe cómo solucionarlo y se escuda en esos argumentos como respuesta a la ineficiencia de los mismos. No lo invento yo, es lo que los CFO y CEO exponen en forma reiterada cuando los apoyo en evaluar estos proyectos. Todo porque la gerencia de IT no habló en el idioma que la dirección de la empresa conoce, habló en bits, bites, megaherz y nanosegundos, pero no en dólares, en rendimiento y en beneficios que es lo que toda dirección espera como retorno de su inversión.

Un proyecto para la evaluación de cambio o sustitución para una plataforma de gestión administrativa o tecnológica contempla varias etapas, que podrán variar de acuerdo a la magnitud de la organización y su complejidad.

Hay gerencias de IT que en principio se presentan a la dirección con una propuesta de cambio, sin previamente preparar a la Dirección de la necesidad del cambio que motiva la solicitud. La Dirección General, debe entender qué está sucediendo en los sistemas y en los procesos y que estas debilidades causan pérdidas materiales significativas monetarias o no, ésta es la primera etapa, entendámosla como de concientización gerencial.

Esta concientización, deberá partir en una evaluación detallada de los procesos de negocios automatizados o no, a fin de identificar debilidades significativas y materiales (entendiendo que estas son aquellas debilidades que se traducen en pérdidas no necesariamente económicas pero de impacto en la organización, como la disminución de la cartera de clientes, de proveedores o de reputación). Por ejemplo tenemos un ERP que no controla el despacho de mercancía según su vencimiento y lote de producción, en pocas palabras un control FIFO, ocasionando serios problemas en la rotación de los productos y su obsolescencia, pero peor aun si el sistema permite que estos ítems obsoletos sean vendidos y despachados a los clientes, ocasionando sus respectivas quejas, notas de devolución por mercancía obsoleta, costos de envió, retiro, almacenamiento y destrucción. Solo una debilidad de un sistema puede ocasionar una importante pérdida económica directa (asociadas el proceso de la venta, cobranza, almacenamiento, despacho y traslado) como indirecta (reputación ante nuestro cliente, descertificación de nuestros productos o de nuestros procesos.) Estos son indicadores medibles y cuantificables que pueden soportar un proceso de cambio. Mientras más debilidades de este nivel podamos detectar más se sustentará el cambio, dejara de ser una solicitud para ser una necesidad. La gerencia de IT tendrá un argumento medible y cuantificable que impacta en los resultados financieros, y eso lo entenderá inmediatamente la organización.

Puedo referir varios casos asistidos personalmente en los cuales la gerencia de IT no lograba que su solicitud llegase ni siquiera a ser discutida ante la Dirección ya que las bases sobre las cuales se sustentaba la misma no estaba adecuadamente soportada con cifras ante la Dirección para que esta hubiese aprobado la necesidad del cambio.

Uno de esos casos estaba referido al nivel de riesgo de uno de los gerentes de alto nivel que requería trasladarse diariamente varios kilómetros para revisar y aprobar las órdenes de pedido y distribuir la venta. Ese ejecutivo perdía una cantidad importante de tiempo en el traslado, adicionalmente al riesgo de una autopista de alto transito donde la posibilidad de un accidente grave siempre existe. Ese riesgo factible, de alta posibilidad de ocurrencia y de alto impacto no estaba medido ni cuantificado, adicionalmente a otros muchos riesgos propios de los procesos. Solo esa debilidad que exponía a este alto ejecutivo ocasionó no solo el cambio del ERP sino el cambio de las oficinas principales que estaban ubicadas en una zona de alta criminalidad.

Otro ejemplo reciente fue con una prestigiosa institución de salud la cual no lograba que la Junta Directiva aprobase el cambio del ERP de gestión médica. Cuando se evaluaron los procesos críticos de la gestión médica constituido por unos 120 procesos, casi el 40% de estos no estaba adecuadamente soportado por el actual ERP y los riesgos reales de pérdidas económicas por tardanza en la facturación de insumos médicos, o de servicios complementarios (nutricionistas, imágenes, banco de sangre, entre otros) determinaron que el plan estratégico corporativo no podría ser alcanzado, ya que estas áreas estaban altamente expuestas a pérdidas materiales. Ese comparativo de debilidades internas versus estrategia que es netamente cualificable sustentó el inmediato proceso de evaluación del cambio no solo del ERP de gestión médica sino el cambio de la plataforma tecnológica.

No quiero y no es mi intensión que no se usen los indicadores del ROI, TIR o VAN o indicar que los mismos no son de valor en la evaluación de TI, sino que debemos ser acuciosos en saber utilizar esas cifras para soportar adecuadamente un proyecto y saber cómo utilizar estos indicadores para apoyar un proceso de cambio y que este no solo es medible y que no solo debemos utilizar la estrategia del ROI, VAn o TIR para justificar o sustentar un cambio tecnológico.

Una vez que se logre la concientización gerencial y lograremos la aprobación de la solicitud de cambio, se tendrá la autorización respectiva para dar inicio a la segunda etapa del proceso, constituida por la conformación del portafolio de proyectos la cual está constituida por las alternativas viables que deberemos considerar como solución al problema presentado. Cada portafolio de proyectos estará constituido por una serie de proyectos que deberá ser llevado a cabo para la culminación exitosa del proyecto principal, ya que nos permitirá medir prioridad, criticidad e inversión de cada uno de ellos.