Es que es un placer conducir por las Autobahn alemanas… siempre y cuando, el tráfico sea expedito. En caso contrario, lo recomendable es armarse de paciencia y rogar para salir del atasco dentro de pocas las horas. Sí, no es extrano que el tráfico en una autobahn pueda significar horas detenido.
A mediados del 2016, el departamento de IT del principal grupo químico Alemán reportó un fallo de su sistema logístico. Este fallo en el sistema bloqueó el ingreso de camiones a sus instalaciones durante varias horas. Este bloqueo no sólo afecto a las instalaciones de las compañía, sino que generó el caos en la ciudad completa, así como en las autopistas nacionales de las inmediaciones. Es decir, un fallo en un sistema productivo, no sólo produjo un retardo de una día de las operaciones locales de uno de los principales grupos químicos mundial, sino que produjo el bloqueo de una ciudad completa y múltiples retardos en autopistas alemanas.
La idea central de toda solución de PANAYA es la de ofrecer, de la forma más eficiente posible, un plan de acción estratégico del cambio, que garantice la continuidad de los procesos de negocio en los sistemas. Este es el verdadero valor por el que una solución como PANAYA debe ser evaluada. Y sin embargo curiosamente, cuando se considera una posible adquisión de PANAYA se suele dejar de lado esta idea central: la interrupción del proceso de negocio, que, como se acaba de ver, puede representar pérdidas de órdenes de magnitud superiores.
Pero entonces, ¿cómo se evalúa el valor de una solución como PANAYA?
Este el el primero de una seria de blog en las que describiremos cómo cuantificar valores ocultos dentro de los patrones de diseño de PANAYA.
Normalmente, analizando aspectos meramente operativos y metodológicos, es decir, se suele considerar el “cómo” y no el “qué” hace PANAYA. Pero incluso en esta acotada evaluación, quizás por cuestiones de tiempo y de complejidad, suelen considerarse sencillamente un par de indicadores, un conjunto mínimo de KPI de alcance directo, valores indiscutibles, y que a menudo, son suficientes para enseñar al cliente el valor producto.
Un ejemplo típico: ante un upgrade o conversión a S/4HANA suele requerirse modificaciones de código del cliente. Pues bien, PANAYA puede realizar parte de estas correcciones de forma automática. El número de correcciones automatizables es un indicador simple y fácil de obtener. Otro indicador que se suele tener en cuenta son aquellas correcciones de bajo riesgo, es decir, aquellas que PANAYA clasifica como opcionales y pueden ser ignoradas sin riesgo de fallo.
Si bien este tipo de KPIs están al alcance y son fáciles de explicar, estos suelen representar sólo una fracción menor del valor total del beneficio. PANAYA es una plataforma colaborativa diseñada para responder a decenas de casos de uso para diferentes perfiles de usuario. Veamos tres ejemplos:
Evidence Viewer y reproducción del fallo
La excepción confirma la regla: se realizan pruebas, porque se generan fallos. Los fallos pueden reportarse a través de distintas herramientas. La gran mayoría de estas ofrecen un campo de texto así como pantallazos de la ejecución. En ocasiones el programador puede identificar directamente el fallo y proveer la corrección para repertir el test. Pero en un número importante de casos el programador debe asumir la a veces dificil tarea de reproducir el fallo. Lo que pasa con un usuario, no pasa con el otro. La secuencia exacta de pasos es simplemente irreproducible o simplemente el tester no logra comunicar el fallo. En ocasiones el mismo tester no es capaz de reproducir por segunda vez un fallo específico. Se suceden entonces una serie de intercambio correos y probablemente de reuniones antes de poder identificar el fallo, si lo hay. En este tipo de interacción el tiempo efectivo de resolución del ticket suele ser menor del 10% del tiempo computado de resolución de ticket, el restante 90% es usado para comunicación.
Pues bien, en un escenario ideal lo que el programador necesita es reproducir en tiempo real exactamente la ejecución donde el usuario tester encontró el fallo, las variables del entorno, condiciones, secuencias de click, mensajes, etc.
PANAYA no entrega una reproducción en tiempo real, pero lo más parecido a una. El reporte de evidencia de prueba es un documento autogenerado que incluye la información antes descrita, incluyendo scripts de interacción así como pantallazos de cada secuencia del tester. Este documento es enviado al corrector desde el primer segundo y esta es la razón principal por qué trabajando con PANAYA los desarrolladores solucionan errores de corrección significativamente más rápido.
Pero cuantifiquemos valores. En un sistema ECC no muy complejo, fácilmente se encontrarán un par de miles de correcciones de código a realizar, antes de una conversión a S/4HANA. De éstas, suponiendo cierto grado de eficiencia de desarrollo y que nuestros procesos de negocios no se han desviado tanto de la nueva versión, se podría estimar que sólo un 10% reportarían al menos un fallo de corrección. Asumiendo también que no se disponde de una herramienta de pruebas colaborativa inteligente, consideremos que cada fallo puede tardar en promedio 1 día en ser corregido, es decir 200 días de trabajo para corregir fallos en correcciones. Pues bien, esta carga de trabajo podría fácilmente reducirse a 50 días de trabajo por el mero uso de PANAYA TDx.
- Número de adaptaciones de código requeridas para migración: 2000
- Número de fallos esperados en pruebas de adaptaciones (10%): 200
- Tiempo de corrección de fallo promedio: 1 día
- Tiempo total corrección de adaptaciones: 200 días
- Tiempo total de corrección de adaptaciones usando PANAYA: 50
- Ahorro de 150 días de Desarrollo/Consultoría
Es así como un pequeño detalle de diseño, como es el PANAYA Evidence Viewer puede tener un impacto inmediato en la estimación de su proyecto de conversión. Y si bien el valor principal de PANAYA es siempre el de garantizar la continuidad de los procesos de negocios, este tipo de evaluación de KPI, puede ser relevante al momento de visualizar otras aristas del producto y acercarnos más a una evaluación real sobre su uso.