Ir al contenido principal

Racionalización tecnológica y casos de negocio

Cada solución tecnológica está soportada en componentes que tienen un costo de licenciamiento, de operación, de soporte, etc. Tener la posibilidad de determinar si una u otra ofrece una máxima capacidad operacional, mejores costos y flexibilidad para la organización se conoce comúnmente como racionalización de la tecnología. 

 

La racionalización implica, por tanto, entender el impacto económico que tiene en la organización la implementación de soluciones tecnológicas. Es común que se comparen alternativas a través de un proceso de selección y escoger la que cumpla la mayor cantidad de requerimientos y sea la más económica.  Sin embargo, no siempre es claro si la solución a implementar es realmente beneficiosa para el negocio o simplemente se quiere satisfacer una moda o tendencia. 

 

Existen varias referencias de empresas que deciden hacer cambios en IT por distintas razones (ver artículos anexos). Se espera, por tanto,  que estos cambios traigan consigo beneficios, como la reducción de costos operativos o el incremento de los ingresos. La suma de estos beneficios, a un plazo determinado debería superar el gasto, tal que permita a la organización recuperar lo invertido. 



 

Análisis de casos de negocio

 

El análisis de caso de negocio no solo se hace para entender el costo que una solución genera en un plazo determinado, sino que debe permitir entender cuantitativamente si esta es más óptima que aquella que se usa actualmente para satisfacer una capacidad o función de negocio. Cuando la capacidad o segmento no existe, los casos de negocio se centran en determinar si el retorno de la inversión amerita el riesgo..

 

Partiendo entonces de la premisa que el caso de negocio se usará para remplazar una tecnología o mejorar una solución que satisface una capacidad de negocio existente, es relevante identificar los siguientes 3 aspectos:


  1. Inversión.
  2. Costos operativos.
  3. Beneficios perceptibles

Identificar todos los parámetros de cada uno puede ser una tarea compleja pero necesaria, generalmente basada en hipótesis que se puedan sustentar. Esta labor es parte de las tareas que un Arquitecto de soluciones debe saber recopilar, con el apoyo de los arquitectos de dominio, dueños de producto, especialistas en mercado, financieros, entre otros. 

 

Para poner en contexto un ejercicio de caso de negocio, imaginemos que se busca migrar una solución de tienda en línea de un datacenter local (onpremise) a una nube, lo que en términos prácticos permitirá reducir los tiempos de indisponibilidad y escalar rápidamente para atender nueva demanda.


Inversión

 

Se define como una actividad de esfuerzo/costo que se realiza una sola vez y se denomina comúnmente como CAPEX.

La alternativa de migrar a la nube implica una inversión de esfuerzo para dejar la solución operativa. Como ejemplo, sería posible identificar los siguientes parámetros:

  • Costo de horas/Hombre dedicas a la migración de datos
  • Costo de horas/Hombre dedicas a la migración de software
  • Adquisición de nuevas licencias para nube
  • Consultoría para la estructura de proyectos de servicio en la nube
  • Capacitaciones 

Costo Operativo


Los costos operativos son recurrentes, se generan año tras año; estos son conocidos como OPEX. Para el caso de ejemplo se pueden identificar:

  • Uso de servicios en la nube
  • Costo de mantenimiento y servicio al cliente
  • Renovación de licencias
  • Costo en cultura organizacional

Beneficios

 

Se identifican como los ahorros o los ingresos generados por implementar la iniciativa que se estudia. Por ejemplo: si al automatizar una tarea se reduce el tiempo dedicado de un grupo de personas, multiplicar ese total de horas por el costo promedio se identifica un variable cuantitativa del beneficio. Para el ejemplo en cuestión, se podrían identificar los siguientes parámetros:

  • Reducción en tiempos de indisponibilidad. 2 horas más al mes en el que, por ejemplo, se finalizan 20 ventas adicionales.
  • Incremento de la demanda. Nuevos clientes pueden ser atendidos en concurrencia. Por ejemplo, permitiendo escalar hasta 500 nuevos clientes.
  • Reducción de 10 horas semanales  en los tiempos asignados a monitoreo y estabilización de los servicios.

Es importante entender que los beneficios no necesariamente se alcanzan inmediatamente se libera la solución. Durante el ejercicio de caso de negocio es común asignar una probabilidad de esta tendencia, por año. Por ejemplo, si se espera incrementar en 10 mil nuevos clientes, un escenario podría sugerir que el primer año proyecta llegar al 20%, el siguiente al 50%, y así gradualmente hasta llegar al 100% de lo esperado.

 

Ejercicio

 

El movimiento de los costos operativos, año tras año, en conjunto con los beneficios obtenidos se denomina flujo de caja, y sobre este cálculo es posible inferir, entre otros:  el retorno de la inversión (ROI), el momento en el que los beneficios y los costos se equilibran o payback, y la rentabilidad o TIR. 

Sin embargo, aunque he dejado por fuera varios aspectos que son netamente financieros es  necesario familiarizarse con conceptos como Valor presente neto, valor futuro, WACC, Curva de costos, intereses, impuestos, etc. 

 

Por último, desde la academia he venido usando un modelo en excel que me parece útil para este tipo de análisis. Lo modifiqué mientras fui independiente y aún lo uso no solo para mi labor como Arquitecto sino incluso para entender si una inversión (Por ejemplo adquirir una vivienda para arriendo) vale la pena o no. Lo adjunto esperando que pueda ser de utilidad y para recibir feedback de sus apreciaciones.


Clic para visualizar en Google Drive y descargar 


 

Referencias 

Comentarios

Entradas populares de este blog

Proceso para la creación de la Arquitectura

Hoy quiero contarles acerca de un modelo que he adoptado para la construcción y entrega de la Arquitectura de Software, el cual lo he relacionado con éxito al interior de la compañía para la cual trabajo y que considero, bien puede adaptarse a cualquier tipo de especialidad de la Arquitectura Empresarial. Cuando era desarrollador escuchaba hablar constantemente acerca de varias metodologías de desarrollo. Durante mucho tiempo apliqué RUP, XP y metodologías AGILES, usé PSP y TSP como procesos de desarrollo. Pero durante todo ese tiempo nunca oí hablar de metodologías orientadas a la generación de la Arquitectura de Software, aún luego de comenzar a estudiar y al día de hoy he tenido muy pocas referencias. Quiero aclarar que existen varios modelos y  frameworks bastante conocidos para la Arquitectura Empresarial que son confrontados a profundidad en unas entregas muy completas de Microsoft, estas pueden estudiarse en este link . Pues bien, el método al que me refiero es ACDM, ...

Expandir espacio en disco duro en Virtual Box y con Partition Logic

Cuando nos quedamos sin espacio en nuestra máquina virtual, tenemos problemas para seguir usándola adecuadamente. Los siguientes son  los pasos que seguí para aumentar el espacio en disco duro, para la unidad principal de una máquina virtual de Windows XP instalada en mi Mac Book.  Probé una herramienta llamada Partition Logic   y, debido a que no la conocía, decidí documentarlo. Tenía asignadas 5GB a la unidad donde está instalado el sistema operativo, y se veía así: Mi máquina, con 5GB de tamaño en disco duro. 1. Redimensionar la unidad vdi. el siguiente es el comando que realiza toda la magia en VirtualBox: VBoxManage modifyhd "ruta/unidad.vdi" --resize [tamaño] En mi caso aumenté el tamaño a 20GB. VBoxManage modifyhd "/Users/oscar/VirtualBox VMs/WindowsXP/WindowsXPClone.vdi" --resize 20000 Como anotación,  debí clonar la unidad, pues había creado el disco de tamaño fijo en Virtual Box y no me permitía aumentarlo (generaba error...

Atributos de Calidad

¿Qué son los Atributos de Calidad? Los Arquitectos debemos participar en el entendimiento de las necesidades de los usuarios. Sí, esa es nuestra principal responsabilidad.  En mi experiencia he debido iniciar con leer términos de referencia para aplicar a licitaciones públicas y privadas y luego acompañar al equipo de análisis en el levantamiento de requerimientos. Los usuarios finales, a excepción de algunos muy técnicos, hablarán en el lenguaje del negocio, de otros sistemas que conocen, de lo que hace la competencia, de lo que otro proveedor les contó, de lo que alguno de sus más influyentes operarios conoce o del patrón de trabajo que ejecutan a diario. Muy pocas veces nos dirán exactamente lo que quieren y por eso debemos estar presentes; debemos ayudar a traducir esos relatos prosaicos de necesidades a requerimientos técnicos.  Los requerimientos técnicos se dividen principalmente en 2: los funcionales (functional requirements) y los no funcionales (Non-functi...