El coste de no definir los requisitos de la nube

En un proyecto de nube de cualquier tamaño, conocer los resqisitos es el punto crucial del riesgo del proyecto. Aunque las fases de descubrimiento y arquitectura de un proyecto pueden representar sólo el 15% del esfuerzo total, un error u omisión desde el principio puede causar alargar el proyecto más del 150%.

Desafortunadamente, ésta es también la fase de luna de miel del proyecto, donde el exceso de optimismo y un falso sentido de seguridad pueden enmascarar el riesgo inherente. Este es el momento en que el liderazgo del proyecto del vendedor debe ser más asertivo, guiando al cliente a través de decisiones difíciles y obligando al cliente a reconocer desagradables compensaciones.

Recorrido mágico y misterioso

Incluso si el cliente ha preparado una gran cantidad de requisitos de recopilación y creado un documento de requisitos grandes antes del proyecto, hay 4 problemas críticos:

Los documentos están demasiado influenciados por la propaganda del vendedor y las listas de comprobación del analista de la industria, y no son bastante influenciados por las necesidades reales del proceso del negocio.

Los requisitos no son lo suficientemente priorizados, proporcionando una orientación débil sobre los compromisos que serán necesarios para cumplir con el presupuesto y el calendario del proyecto.

Los requisitos son incompletos, faltando transiciones importantes en el proceso de negocio de extremo a extremo. Con demasiada frecuencia, las brechas se descubren sólo a medida que avanza el proyecto, con los requisitos "invisibles" descubiertos mucho después del final de la fase de descubrimiento. Esto es más dramático cuando aparece un requisito importante durante las pruebas de aceptación del sistema.

El negocio evoluciona a lo largo de la vida del proyecto, y cada cambio de política puede invalidar o incluso contradecir el documento original.

Debido a que los documentos de requisitos preescritos tienden a ser hojas de ruta poco fiables para un gran proyecto, los consultores prefieren partir el proyecto en varias fases, cada una de las cuales debe comenzar con su propio descubrimiento y ciclo de aprobación de requisitos.

Un día en la vida

Incluso el método ágil puede encontrar problemas si el consultor no ha llevado al cliente a través de un "día en la vida" para explorar el proceso de negocio de extremo a extremo desde la perspectiva de los usuarios reales y el cliente. A menudo, los ejecutivos no saben los detalles de cómo funciona realmente el negocio, y las personas de nivel inferior realmente conocen sólo su parte del rompecabezas. Con aplicaciones orientadas al cliente, a veces sólo el cliente sabe lo frustrante que son sus sistemas, y nadie interno ha dedicado tiempo para conectar todos los puntos y ver el proceso de extremo a extremo.

El punto de partida del descubrimiento profundo es mostrar el sistema como una serie de procesos de negocio tales como:

Objetivo de la comercialización

Gestión de ventas

Cotización

Entrega, instalación y atención al cliente

Facturación y recaudación

Garantía y derechos de servicio

Gestión de casos y programación de servicios

Resolución de problemas y llamadas de servicio

Seguimiento y encuesta a clientes

Las empresas más grandes que se someten a este análisis descubrirán rápidamente que no tienen (y tal vez nunca pueden tener) un flujo de proceso único para el negocio en su conjunto. Las operaciones multinacionales probablemente tienen variaciones significativas incluyendo:

Las prácticas empresariales regionales o incluso nacionales (por ejemplo, Estados Unidos vs. Europa vs. Asia)

Normas verticales de la industria y regímenes regulatorios (para la privacidad del cliente, normas contractuales o contabilidad)

Canales de distribución y ‘joint ventures’

Los sistemas heredados que no forman parte del proyecto (por ejemplo, ERP o eCommerce)

Las políticas de dentro y fuera de la compañía

Cada una de estas variaciones necesita ser mapeada como un proceso paralelo con sus propios requisitos.

Las empresas quieren creer que un proyecto de nube puede simplificar radicalmente el desorden de sistemas que han acumulado a lo largo de los años. Y pueden hacerlo, pero sólo si alguien hace una tarea seria para simplificar el desorden de procesos que han acumulado a lo largo de los años. La simplificación significa entender el propósito y las interacciones entre todas las partes móviles que hay... y llegar a una estrategia inteligente de unificación y reemplazo.

El largo y ventoso camino

Esto suena costoso y consumir tiempo porque, realmente, lo es. Tanto el consultor como el cliente verán que es un profundo proceso de descubrimiento que lleva más que el "15% estándar" del esfuerzo general del proyecto. Esto es particularmente cierto cuando un sistema de nube está reemplazando uno o más sistemas heredados que han evolucionado (de maneras saludables e insalubres) a través de los años. El deseo de la gerencia superior de un proyecto apresurado debe ser firmemente contrarrestado con el conocimiento de que la precipitación producirá un nuevo sistema que automatiza viejos hábitos y refuerza las reglas comerciales obsoletas. Para realmente transformar el negocio significa hacer suficiente trabajo en los procesos de negocio para convertirlos en una ventaja.