Flujo de trabajo operativo - AWS Guía prescriptiva

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Flujo de trabajo operativo

El flujo de trabajo operativo respalda la base técnica y los flujos de trabajo del recorrido del usuario. La mayoría de las actividades no técnicas que son cruciales para el éxito general de la migración forman parte de este flujo de trabajo.

Este flujo de trabajo incluye decisiones que se pueden cambiar o revertir con poco esfuerzo o impacto. Las especificaciones de los productos, que se basan en la forma en que las personas trabajan y se relacionan, rara vez son correctas la primera vez; hay muchas partes interesadas y voces a tener en cuenta. Es importante participar desde el principio y realizar consultas amplias y frecuentes, por lo que un enfoque ágil e iterativo tiene sentido para este flujo de trabajo. Se empieza con un primer borrador de un modelo operativo o materiales de capacitación y se va repitiendo con frecuencia y rapidez hasta llegar al producto final.

El flujo de trabajo operativo consta de cinco fases: la gobernanza del proyecto, la alineación, la definición del modelo operativo, la introducción del servicio y la capacitación.

Flujo de trabajo operativo en las migraciones de centros de contacto

Gobernanza del programa

Las actividades de gobernanza del programa se extienden a lo largo de todo el cronograma de un proyecto de migración. Independientemente de la fase en la que se encuentre el proyecto, las actividades deben ser periódicas (reuniones periódicas programadas), transparentes (se da al equipo del proyecto la oportunidad de plantear los riesgos y los problemas con franqueza) y contar con una gobernanza comprometida (los líderes están facultados y dispuestos a tomar decisiones o a tomar las medidas necesarias). Estas son fundamentales para detectar y resolver los problemas de forma rápida y eficaz.

Alineación

Esta es la primera actividad formal del proyecto y se centra en alinear el alcance del proyecto con los resultados empresariales. La alineación brinda la oportunidad de validar y ajustar los planes y estimaciones anteriores en función de las conversaciones con las partes interesadas.

Las acciones clave durante esta actividad incluyen las siguientes:

  • Descubrir casos prácticos de clientes de alto nivel, problemas técnicos y empresariales actuales y oportunidades de mejora.

  • Analizar y acordar los resultados empresariales deseados, determinar sus prioridades relativas e identificar los criterios de éxito.

  • Desarrollar un diseño de solución general, que se utilice para definir el alcance y las opciones tecnológicas en esta fase inicial. Este diseño general brinda instrucciones para acelerar las actividades de diseño de bajo nivel en fases posteriores.

  • Validar los plazos y los costos de implementación.

Definición del modelo operativo

Las actividades de esta fase definen quién utilizará la solución de centro de contacto y cómo se gestionará la solución. El modelo operativo no es un documento, un manual de procedimientos ni un archivo de configuración. Por ejemplo, no se debería explicar cómo extraer los registros y adjuntarlos a un tique de soporte, ni cargar capturas de pantalla de este procedimiento. En su lugar, se debe identificar quién debe extraer los registros y a qué lista o proveedor deben enviarse.

La definición del modelo operativo debe incluir lo siguiente:

  • Una matriz responsable, confiable, compatible, consultada e informada (RASCI), para que cada equipo comprenda sus funciones y responsabilidades y cómo interactuará con otros equipos. A continuación, se muestra un fragmento de una matriz RASCI.

    Ejemplo de matriz RASCI para migraciones de centros de contacto
  • Flujos de procesos que definen las end-to-end actividades y quién es responsable de cada actividad. Por ejemplo, debe haber un flujo de proceso para conseguir el out-of-hours soporte, de forma que quede claro a quién se llama, qué pasa si no se puede contactar con él, quién registra el ticket de soporte y cómo se evalúa la importancia de la empresa. Otro ejemplo es el mensaje de la cola de emergencia. El flujo del proceso debe mostrar quién decide si debe iniciarse y qué datos debe utilizar para tomar esa decisión.

Por lo general, el modelo operativo se define en la segunda mitad del proyecto, ya que hay que finalizar el diseño de la solución y la experiencia de los usuarios antes de poder definir los procesos para gestionarlos con precisión. Sin embargo, le recomendamos que reúna a las partes interesadas al principio del proceso y reserve su tiempo para las fases posteriores del proyecto. 

Reúna ejemplos de documentos similares de su organización que pueda utilizar como plantillas. Esto facilitará la revisión y la aprobación por parte de las partes interesadas, ya que la estructura del documento les resultará familiar.

Asegúrese de que las partes interesadas aprueben el modelo operativo antes de que su nuevo centro de contacto pase a la fase de producción y haga de este un requisito para tomar la decisión de ponerlo en marcha. Cada miembro del equipo debe comprender su función y el proceso para operar el centro de contacto en el entorno de producción.

Introducción al servicio (SI)

En las actividades de SI, se implementan los cambios definidos en el modelo operativo. Piense en la definición del modelo operativo como las fases de diseño y creación del nuevo modelo, y en la SI como la fase de implementación del modelo operativo.

El equipo de SI suele ser un equipo dedicado en su organización y trabaja de forma independiente del equipo del proyecto. El proyecto debe cumplir los criterios y las listas de verificación del equipo de SI antes de recibir la aprobación para su puesta en marcha. Por ejemplo, las listas de verificación incluyen los resultados de las pruebas de aceptación por parte de los usuarios (UAT) y la confirmación de que un evento conflictivo (como una congelación de cambios u otro evento de puesta en marcha programado) no tendrá lugar el mismo día de la puesta en marcha del proyecto, que los usuarios cuentan con la capacitación necesaria y que los equipos de operaciones están preparados para proceder.

No deje las actividades de SI para el final del proyecto. Involucre al equipo de SI al principio del proyecto e inclúyalo en su lista de distribución para enviarles la documentación del diseño. La participación temprana garantiza que el equipo de SI pueda ayudar a prepararse para la puesta en marcha, por ejemplo, ayudando a seleccionar el plan de AWS apoyo más adecuado, proporcionando declaraciones de impacto para las solicitudes de cambio (CRs) y apoyando los debates de la junta de aprobación de cambios (CAB).

Formación

La creación de materiales de capacitación y la organización de sesiones con una buena asistencia son fundamentales para el éxito de las migraciones. La tecnología puede funcionar perfectamente, pero si los usuarios no saben cómo responder a las llamadas y realizar sus tareas diarias, la migración se considerará un fracaso. 

Las actividades de capacitación pueden incluir la capacitación directa de los usuarios, la capacitación de los formadores, de los supervisores, del personal de apoyo y de los administradores de sistemas o los propietarios de los productos. Cada organización es única, por lo que algunas opciones pueden ser más adecuadas desde el punto de vista cultural que otras.

Le recomendamos un enfoque de formar al formador que involucre al personal de capacitación interno de su organización. Su personal conoce la cultura de la organización y el formato y las técnicas de capacitación que mejor se adaptan a sus usuarios. Los miembros del equipo del proyecto pueden asumir funciones de expertos en la materia (SME) para brindar materiales técnicos (como manuales de usuario, manuales de la consola de gestión y guías de pantalla) que se pueden utilizar como material de referencia para las sesiones de capacitación de formadores. Si su organización no cuenta con un equipo de capacitación, el proyecto SMEs debería capacitar a los supervisores y al personal de apoyo principal, quienes luego podrán capacitar a los usuarios del centro de contacto.

También recomendamos que los administradores de sistemas y los propietarios de los productos realicen cursos formales de capacitación sobre productos impartidos por un instructor para obtener una comprensión más profunda del entorno de AWS y de la consola de Amazon Connect, a fin de utilizar las funciones del producto y solucionar problemas de forma eficaz.