Ocho cifras ahorradas, cada año

El Automation Experience Team convierte procesos de negocio manuales en flujos de trabajo automatizados sobre Flow Engine, la plataforma interna de Comcast. Mi equipo es dueño de Paths, la parte de Flow Engine donde estas automatizaciones se diseñan y se entregan. Las solicitudes llegan desde equipos de negocio de toda la empresa, y cada una compite por la misma capacidad de ingeniería, diseño y plataforma.

Las solicitudes de automatización llegaban con niveles de claridad muy distintos, y el proceso de entrega tenía fricciones incorporadas:

• La priorización se enfocaba sobre todo en el impacto, sin una visión consistente del esfuerzo o los bloqueos.
• El diseño tenía que estar completamente terminado antes de empezar el desarrollo, así que el trabajo ocurría en secuencia.
• Paths no tenía un sistema de diseño, así que cada nueva automatización reinventaba sus propios patrones de interfaz.
• Comcast tiene un panorama de APIs federado, así que los desarrolladores muchas veces tenían que buscar la documentación por su cuenta en medio del desarrollo.

Senior Product Manager. Soy responsable de cada automatización desde su asignación hasta el lanzamiento: descubrimiento, análisis de procesos, diseño de la solución, alineación entre equipos y entrega. También mejoré el propio proceso de entrega.

1. 1.

   Recepción y priorización

   Reviso las solicitudes entrantes del negocio y sus requisitos, y califico cada una por impacto, esfuerzo y bloqueos. Sopesar los tres ayuda al equipo a comprometerse con trabajo que realmente genere valor y llegue a producción. Las automatizaciones aprobadas se asignan luego para su entrega.

2. 2.

   Descubrimiento y mapeo de interesados

   Una vez que me asignan una automatización, identifico a todos los involucrados, me reúno con el equipo de negocio y revisamos juntos los requisitos para acordar el problema que vamos a resolver.

3. 3.

   Factibilidad técnica temprana

   Antes de profundizar en el análisis del proceso, extraigo los requisitos técnicos y los reviso primero con ingeniería. Descartar lo inviable desde el inicio nos evita diseñar algo que no se pueda construir.

4. 4.

   Mapeo del estado actual del proceso

   Entrevisto a expertos del tema, dueños de proceso e interesados, reúno toda la documentación existente y mapeo cómo funciona realmente el trabajo hoy. En el camino encuentro vacíos y versiones contradictorias y las resuelvo, luego confirmo el mapa con los dueños del proceso e invito a más retroalimentación del negocio.

5. 5.

   Simplificar antes de automatizar

   Antes de automatizar nada, busco pasos que se puedan simplificar o eliminar. Luego identifico dónde la automatización aporta más valor, eligiendo la herramienta correcta para cada paso junto con ingeniería: flujos de Paths, APIs donde existan, y RPA donde no.

6. 6.

   Diseño del estado futuro y alineación

   Hago una maqueta del estado futuro propuesto y lidero un kickoff con todos los equipos involucrados para llegar a un consenso sobre exactamente qué vamos a construir.

7. 7.

   Diseño y desarrollo escalonados

   Cuando una automatización necesita trabajo de interfaz, incorporo a diseño y divido el trabajo en sprints escalonados: primero el contenido, luego el mapeo del recorrido, luego la interfaz. Cada etapa empieza en cuanto la anterior le da suficiente con qué trabajar. Los diseños aprobados pasan a desarrollo sprint por sprint, de modo que diseño y desarrollo avanzan en paralelo en lugar de uno después del otro. Muchas automatizaciones necesitan poca o ninguna interfaz, y esas van directo a desarrollo.

8. 8.

   Documentación de APIs lista

   Antes de la entrega, reúno la documentación de API que los desarrolladores van a necesitar, para que empiecen con todo en mano en lugar de buscarla en medio del desarrollo.

9. 9.

   Lanzamiento y ciclo de vida

   Desarrollo lleva la automatización hasta el lanzamiento, y el equipo de negocio lidera la capacitación y documentación para sus usuarios. Después del lanzamiento, administro el producto hacia adelante: corrección de errores, mejoras y nuevas solicitudes de funcionalidad.

• El impacto por sí solo no es una prioridad. Las mejores apuestas sopesan el impacto contra el esfuerzo y los bloqueos.
• Pregúntale a ingeniería primero. Revisar la factibilidad antes del análisis de proceso mantiene el descubrimiento con los pies en la tierra.
• Simplifica antes de automatizar. Automatizar un proceso roto solo hace que se rompa más rápido.
• Las mayores demoras están entre equipos, no dentro de ellos. Las ganancias más grandes vinieron de arreglar las transferencias: de diseño a desarrollo, y de documentación a desarrolladores.