Introducción

La compra de tecnología y la contratación de servicios tecnológicos representan una inversión, tanto para las empresas como para el uso personal. Este es un principio que hoy cobra todavía más importancia. Sé que algunos administradores señalarán que un servicio contratado representa un gasto y no la adquisición de un activo tangible, pero este artículo no busca debatir su tratamiento contable. Cuando hablo de inversión, me refiero al propósito de lo que compramos o contratamos: debe ayudarnos a resolver una necesidad, potenciar una capacidad o convertir una debilidad en una fortaleza del negocio. Lo importante es el valor que aportará la tecnología seleccionada y cómo contribuirá a los resultados que necesitamos. Ese es el fundamento que desarrollaremos a continuación.

Lo primero es identificar la necesidad. Puede tratarse de una debilidad del negocio que todavía no está cubierta, un nuevo requerimiento o un sistema que se ha vuelto lento por hardware obsoleto, falta de capacidad o limitaciones del propio software o de una base de datos. Ahí, la mayor parte de las veces, surge como idea o solución comprar una plataforma o tecnología nueva. A veces es la respuesta correcta. Pero antes conviene entender qué está ocurriendo y qué se quiere lograr.

¿Qué proceso se necesita mejorar y dónde está la causa?

Para responder correctamente esta pregunta, recomiendo lo siguiente:

  • Verifique si existe actualmente una tecnología que apoye este proceso.
  • Describa el proceso de principio a fin.
  • Identifique quién o quiénes intervienen.
  • Determine dónde se espera información y qué pasos se repiten.
  • Comparta una descripción del resultado esperado para evitar que cada área espere algo distinto de la solución.

¿Qué evidencia tenemos?

Reúna tiempos de respuesta, volumen de trabajo, incidencias y comentarios de los usuarios. No hace falta comenzar con una medición compleja: unos datos consistentes permiten establecer una referencia y evaluar los avances. Si el problema es la lentitud, identifique cuándo ocurre, a quién afecta y en qué parte del proceso se presenta. Si hay trabajo repetido, observe qué lo provoca y cuánto tiempo consume. Esta información ayuda a comprobar la causa antes de elegir una solución y evita que una percepción aislada se convierta en el único criterio para invertir.

¿Qué resultado sería valioso?

Traduzca la necesidad a un resultado observable. Entre los resultados que puede buscar están:

  • Reducir retrabajos.
  • Mejorar la disponibilidad.
  • Responder más rápido o facilitar una decisión.

Defina también los límites de presupuesto, tiempo y capacidad interna. Estos límites ayudan a establecer qué solución es viable y con qué recursos se podrá implementar y mantener.

¿Puede resolverse con lo que ya existe?

Revise configuraciones, integraciones y funciones que el equipo no utiliza. En ocasiones, mejorar un flujo o capacitar a las personas resuelve parte del problema. Cuando se requiere una nueva solución, esa revisión deja requisitos más claros, y esto es imprescindible para los siguientes pasos encaminados a resolver la necesidad. Desde este momento, se requiere establecer el alcance y el objetivo del proyecto: qué se espera lograr, qué incluye la solución y qué queda fuera.

Si la necesidad se atiende internamente, se debe seguir el proceso de identificación, diseño, construcción o configuración, pruebas y puesta en operación que corresponda. Marcos como COBIT e ITIL pueden orientar este trabajo, aunque sus conceptos no son equivalentes ni se limitan al desarrollo interno. En COBIT 2019, el objetivo BAI03 aborda la identificación y construcción de soluciones; en ITIL 4, la práctica de desarrollo y gestión de software orienta el trabajo con aplicaciones y se complementa con las prácticas de habilitación del cambio, validación y pruebas, y despliegue. Lo importante es aplicar las prácticas que correspondan al tipo de solución y a las necesidades de la organización.

Cuando se necesita acudir a un proveedor externo y comparar propuestas, una RFP puede ayudar a organizar la selección. RFP significa Request for Proposal, o solicitud de propuestas. Es el documento donde se describen la necesidad, los resultados esperados, el alcance, los requisitos y las condiciones que deben cumplir los proveedores para participar. También conviene incluir los criterios de evaluación, los entregables, los niveles de soporte y la forma de comprobar que la solución cumple lo solicitado. La claridad de este documento permite comparar propuestas con una misma base y reduce los malentendidos durante la contratación.

¿Quién sostendrá el cambio?

Considere seguridad, soporte, responsables, capacitación y mantenimiento. La elección técnica debe funcionar en la operación diaria, no solo durante una demostración. Definir el problema primero permite comparar opciones con un criterio común y hacer una inversión mejor fundamentada.

Luego de responder estas cinco preguntas, el trabajo debe continuar con las metodologías y los procesos adecuados para desarrollar soluciones internas, adquirir soluciones externas y gestionar el proyecto. Las respuestas permiten comenzar con un fundamento claro, identificar las decisiones pendientes y reducir lo que se deja a la interpretación. No eliminan todas las incertidumbres, pero sí ayudan a saber qué se necesita, para qué se necesita y cómo se evaluará el resultado.