Fundamento técnico: flujo de trabajo

Este flujo de trabajo implica decisiones que requieren una revisión significativa si se modifican, por lo que el flujo de trabajo hace hincapié en un diseño cuidadoso, una consulta amplia y una inversión inicial en los procesos y las pruebas de DevOps.

El flujo de trabajo básico técnico consta de cinco fases: descubrimiento y hoja de ruta, diseño, creación, prueba, implementación y soporte posterior a la puesta en marcha.

Descubrimiento y hoja de ruta

En esta fase, recopilará información y programará talleres para lo siguiente:

• Asignación “tal cual”: examine los sistemas y las capacidades, recopile datos y reúnase con los SME para comprender el estado actual del centro de contacto.

• Diseño futuro y evaluación de las brechas: determine la experiencia ideal para todos los agentes y clientes del centro de contacto a fin de determinar el alcance del proyecto.

• Plan de cierre de brechas: describa una hoja de ruta para crear e implementar el estado futuro del centro de contacto.

Asistentes al taller:

• Administradores de proyectos

• Arquitectos empresariales, de soluciones, técnicos y de seguridad

• Propietarios de plataformas de infraestructura

Diseño

En esta fase, se producen documentos de diseño. Es posible que tenga sus propias convenciones o procesos para crear artefactos de diseño. Recomendamos incluir al menos tres secciones en el documento de diseño: configuración, redes y seguridad de Amazon Connect. Es probable que cada sección cuente con diferentes grupos de partes interesadas especializados para garantizar la eficacia de las revisiones y aprobaciones, por lo que podría resultar más práctico crear documentos separados para estas tres áreas. Entre las partes interesadas deberían figurar los arquitectos, el equipo de seguridad y conformidad y los propietarios de las plataformas.

Compilación

En esta fase, se siguen los principios de la infraestructura como código (IaC) mediante el uso de herramientas de DevOps para estandarizar y gestionar las versiones estables. Evite adoptar un proceso de compilación manual, aunque lo ayude a empezar más rápidamente, ya que esto puede aumentar los riesgos para la estabilidad y la cantidad de errores a medida que la compilación se vuelve más compleja y pasa a los entornos de prueba y producción. Si no tiene sus propias herramientas de DevOps, le recomendamos que utilice herramientas de AWS, como AWS CodePipeline y AWS CodeBuild, que se pueden activar rápidamente. Tenga en cuenta el esfuerzo de configurar estas herramientas en el ámbito del proyecto; serán beneficiosas a largo plazo y le permitirán seguir los principios de DevOps. Le recomendamos que incorpore al menos tres cuentas de AWS independientes para el desarrollo, las pruebas y la producción. Las herramientas de DevOps y la automatización pueden ayudarlo a mover el código a través de estos entornos.

Pruebas

La fase de prueba consta de tres subfases secuenciales:

1. Pruebas unitarias: se prueban los componentes individuales de la infraestructura para garantizar que sean correctos y que se cumple con las especificaciones de diseño. Realizadas por: desarrolladores

2. Pruebas de integración: pruebas de elementos que forman los límites de la integración, como los servicios de gestión de identidad de Microsoft Active Directory (AD). Realizadas por: desarrolladores

3. Pruebas de productos: pruebas integrales de los recorridos funcionales en toda la infraestructura; por ejemplo, probar que cada evento del agente se registre en la herramienta de monitoreo de seguridad, que la llamada se atienda y que la grabación de la llamada esté en el bucket correcto de Amazon Simple Storage Service (Amazon S3). Realizadas por: equipo de pruebas funcionales

Implementación

La infraestructura debe estar preparada para gestionar el tráfico en directo cuando los recorridos de los usuarios estén programados para ponerse en marcha. El objetivo de la fase de implementación es garantizar que las cuotas de servicio de AWS cumplan con la cantidad de agentes simultáneos y los volúmenes de llamadas esperados, que se haya completado la transferencia de números o el redireccionamiento del servicio de números gratuitos (TFNS) y que se monitoree el estado de los sistemas de backend a medida que aumenten los volúmenes de tráfico en tiempo real. Desde su perspectiva, el equipo de seguridad y conformidad también debe confirmar que la plataforma está preparada para el tráfico en directo.

Soporte posterior a la puesta en marcha (PGLS)

El equipo del proyecto sigue colaborando con los equipos de soporte y los usuarios finales de las prácticas comerciales habituales (BAU) durante las primeras semanas después de la puesta en marcha del nuevo centro de contacto. El equipo del proyecto puede ayudar a los usuarios a empezar a usar el nuevo sistema, participar en la solución de problemas junto con el equipo de soporte de las BAU y mejorar la documentación de soporte basándose en los comentarios.