Revista Mundo-Contact
| Cómo tener éxito en su implementación de call center. 2ª. de 3 partes
En la primera parte de este artículo se habló de cómo elegir el proveedor adecuado es crítico para garantizar una integración exitosa del call center, pues ello abarca muchas facetas de las operaciones del centro de contacto. También se hizo énfasis en que es necesario contar con un gerente del proyecto capaz de crear un espíritu de equipo en el cual toda la información se discuta, evalúe e incorpore al plan del proyecto. Metas de negocios Su gerente de proyecto tiene otro rol primario, en cierto sentido aún más importante. El gerente de proyecto necesita entender los motivadores de negocios del plan y cerciorarse de que estén siendo tomados en cuenta. Antes de comenzar cualquier tipo de labor de implantación, lo primordial es asegurarse de que se esté implementando una solución orientada a satisfacer las necesidades originales del negocio. En alguna parte hay alguien que ha formulado un caso de negocios para este proyecto. Lo más probable es que ese caso de negocios esté expresado en pesos y centavos, pero puede haber otros factores menos tangibles. El gerente de proyecto debe saber cuáles son y nunca perder de vista el objetivo original. El gerente de proyecto también necesita incluir en el proceso a los usuarios finales del sistema. En todo proyecto de gran envergadura, usted va a estar afectando sistemas que han evolucionado hasta su estado actual debido a un conjunto perfectamente definido de razones. Ahora, es posible que los sistemas no funcionen, que las razones hayan sido las equivocadas y que el proyecto pretenda solucionar las cosas. Si es así, usted necesita saberlo. Pero hay otros casos en los que un sistema se comporta como se comporta debido a otros motivos. El arquitecto de la solución Anteriormente presentamos una lista de las diferentes áreas involucradas en el proyecto y señalamos que no es probable que vaya usted a encontrar un gerente de proyecto que tenga experiencia en todas las distintas tecnologías que abarca el proyecto. Pero eso no quiere decir que no haya alguien involucrado en el proyecto que sí entienda a fondo la tecnología. Esa persona es el arquitecto del sistema. El arquitecto es la persona que arma la solución. Esta persona puede ser un recurso interno de su empresa, un integrador de sistemas externo o bien uno de los proveedores que estén tomando parte en el proyecto. En cualquier caso, es la persona que ha llevado a cabo el diseño general y debe ser responsable de comunicarlo al resto del equipo. Más que eso, esta persona tiene que hacer suya la solución. Usted tiene que hacer que el arquitecto de la solución asuma esa responsabilidad, especialmente al principio, en las etapas de planeación. Hay que asegurarse que el panorama general del proyecto no esté guardado en las cabezas de los integrantes del equipo del proveedor responsable de contestar a su solicitud de propuesta. La solución propuesta, ya sea que estemos hablando de un recurso interno o externo, nos exige que nos aseguremos que esa persona esté presupuestada y asignada. Un último comentario a este respecto: en un proyecto lo bastante pequeño, el arquitecto del sistema y el gerente del proyecto bien pueden ser una misma persona. En un proyecto grande, por lo general eso no sucede. Armando las piezas OK. Se ha dado la luz verde al equipo. Se ha dado la orden, se han generado las órdenes de compra, y ha llegado la hora de celebrar la junta de kickoff. ¿Qué debería usted esperar lograr en sus primeras juntas y a quién debe invitar? Por encima de todo, sea ambicioso. Se trata de echar a volar (no a gatear) el proyecto. Sostenga una junta de arranque e introducción en toda forma. Invite a todos los involucrados dentro de su organización, incluyendo a los patrocinadores de negocios, a los responsables de la implementación y a los usuarios finales. Los proveedores le vendieron la solución y son quienes estarán llevando a cabo la implementación, así que deben mandar tanto al ejecutivo de cuenta que hizo la venta como al gerente responsable de implementarla. La junta de kickoff debe tener tres metas principales: Comunicar el propósito del proyecto – Explique al grupo de qué se trata el proyecto. Desde una perspectiva de 20,000 pies de altura, explique en qué consiste y por qué se está llevando a cabo. La explicación debe estar enfocada al negocio y es mejor que la introducción la haga uno de los patrocinadores de alto nivel ejecutivo. Esta junta sirve para que la gente se conozca y se finquen relaciones. Pero también es crítico que usted establezca con claridad desde ese momento por qué se está llevando a cabo el proyecto, determine qué problemática es la que se está atacando y cuáles son las metas últimas de la iniciativa. Definir los criterios de éxito – Esto debe incluir el propósito del proyecto y qué significa que el proyecto tenga éxito. También es necesario abordar la importantísima cuestión de la fecha de entrada en producción. Poner la bola en juego – Es a esto a lo que nos referimos cuando le decimos que sea ambicioso. Es bueno poner la pelota en juego con una discusión técnica. Para ello, en el caso de proyectos grandes, es probable que se requiera llevar a cabo una sesión de continuación/seguimiento, con menos ejecutivos de cuenta y más personal técnico. Con esto se debe dibujar el panorama de conjunto a fin de echar a volar las ideas para las sesiones de diseño y planeación que vendrán a continuación. Tenga a la mano a una persona para que dibuje un diagrama de todas las piezas y haga que el grupo participe en un recorrido guiado por el flujo y la manera en que se supone que las llamadas y los contactos deberán viajar por el sistema. Este es el momento en donde se empieza a ganar tracción. Todos en su equipo van a tener una visión ligeramente distinta de la llamada, pues cada quien la ve desde la perspectiva de su propia tecnología o necesidad de negocios. Cada proveedor tendrá un entendimiento inicial del proyecto con base en lo que tiene que entregar y seguramente ya tendrá una serie de preguntas e inquietudes fundamentadas en ese entendimiento. Ese recorrido guiado es en donde empiezan a visualizar la imagen de conjunto y donde los jugadores empiezan a aglutinarse como equipo. Permita que la gente se desvíe hacia los detalles si eso les ayuda a involucrarse y participar. Tire de las riendas si el foco comienza a difuminarse. Tecnología de juntas y colaboración La realidad de negocios determina que no siempre es posible congregar en una misma sala de juntas a todas las personas que usted necesita el mismo día. Si es necesario, aproveche la tecnología para permitir que algunas personas participen de manera remota, ya sea por teléfono o mediante aplicaciones tipo Webex™. Aproveche toda la tecnología que tenga a su alcance para salvar esas distancias, sin descuidar la importancia de las primeras dos o tres juntas en donde usted va a impartir propósito y rumbo al proyecto. Las primeras impresiones siempre son importantes y un proyecto tendrá más éxito si usted gestiona cuando menos una junta presencial de los principales involucrados. Haga que su proveedor vuele hasta la oficina remota para conocer a los miembros de su equipo, o traiga a los principales involucrados de la oficina remota al corporativo para una de las juntas iniciales del proyecto. Una vez que la gente se conoce, las juntas subsiguientes pueden llevarse a cabo fácilmente utilizando cualquier tecnología que se desee. Requerimientos de diseño En muchos sentidos, la etapa de requerimientos y diseño del proyecto es la más importante de todas. Esta es su mejor oportunidad para lograr que las cosas se hagan bien a la primera. Es en esta fase que hay que ponerse de acuerdo sobre qué se va a hacer y cómo se va a hacer. Cualquier cosa importante que se omita en esta etapa regresará más adelante para cobrar venganza — si corre usted con suerte, unas semanas antes de la entrada en producción, cuando todavía se puede hacer algo al respecto, a cambio, simplemente, de una demora en la fecha prometida. En nuestra experiencia, la mayoría de los proyectos no son tan afortunados. En pocas palabras: en la medida de lo posible, resuelva sus problemas desde el principio, en la fase de diseño. Asegúrese de poner sobre la mesa absolutamente todos los requerimientos. Cuando un agente transfiera la llamada a un supervisor, tiene que ir seguida automáticamente de un mensaje en pantalla (“screen pop”) 60% de las llamadas deben terminar en el sistema IVR Si el IVR y el sistema CTI no están funcionando, las llamadas de todos modos tienen que ser canalizadas a un agente Las oportunidades de ventas identificadas en el sistema de audiorespuesta deben disparar un “screenpop” en la terminal del agente Los agentes deben tener la capacidad para poner a grabar una llamada No debe hacerse necesario modificar elementos de las pantallas de CRM Si el sistema CRM no funciona o está demasiado lento, los agentes de todos modos deben tener acceso a la información que ingresó el cliente Una sola tabla de reporte debe poder mostrar la siguiente información: actividad del sistema IVR para una llamada, asignación por habilidades, tiempo que pasó el agente en esa llamada, agente asignado a la llamada, trabajo posterior a la llamada Todas las ventas deben tener una impresión de voz Todas las llamadas deben terminar con un código de motivo ingresado por el agente Una cosa que usted observará en relación con esta lista de requerimientos es que son sumamente diversos. Provienen de diferentes partes del call center que representan las necesidades de diferentes grupos. Usted no va a obtener todos sus requerimientos en un solo lugar. Asegúrese de consultar a todas las personas que pudieran tener requerimientos o a aquellas que pudieran estar al tanto de restricciones o limitantes que incidan sobre su capacidad para satisfacer los requerimientos. Es probable que se tope con requerimientos que se contraponen unos a otros. En la lista anterior vemos que los agentes siempre deben seleccionar un código de motivo de la llamada antes de poder tomar otro contacto. Antes de eso tenemos un segundo requerimiento que dice que no debe se debe hacer necesario modificar las pantallas del sistema CRM. Al parecer el grupo de sistemas ha trabajado mucho para lograr que el sistema de CRM funcione exactamente cómo quieren y consideran que la aplicación debe mantenerse congelada durante los próximos meses. Entonces llega un requerimiento que les obliga a abrir el código fuente y quizá hasta incluir por ahí algún botón nuevo. En este caso se trata de un requerimiento proveniente de las operaciones del call center que se contrapone a una restricción por parte del área de TI. La única manera de resolver este tipo de conflictos sin tener que acudir a instancias superiores es congregar bajo el mismo techo a todos los interesados desde el principio. Ponga los requerimientos sobre la mesa, ventílelos. Utilice un poco de psicología — si alguien empieza a plantar obstáculos, déjelo hablar e involúcrelo en la solución. Mantenga a la gente concentrada en la meta en común. Recuérdeles lo valioso que es lo que se está haciendo. Documentos y especificaciones Durante esta fase, usted va a generar dos tipos de documentación: documentos de requerimientos y especificaciones funcionales. La especificación funcional es el documento de diseño resultante de recopilar sus requerimientos y elaborar su diseño (y, una vez más, estamos hablando de un documento compuesto por muchos elementos, muchas especificaciones diferentes juntas en una misma carpeta). Ahora, como todo veterano del mundo corporativo sabe, un documento puede cobrar vida y convertirse en un fin en sí mismo. En ningún otro caso se manifiesta este fenómeno con mayor claridad que aquí. Hemos tomado parte en más de un proyecto en el que la elaboración y aprobación de una especificación se convirtió, en sí misma, en un proyecto existente casi en un universo paralelo. Luego, una vez que la especificación quedó concluida y aprobada, nunca más se volvió a hacer referencia a ella, casi como si desapareciese de la faz de la Tierra una vez que se termina de elaborar. La declaración de requerimientos y la especificación funcional constituyen un contrato entre el usuario final y la gente que va a realizar el trabajo: juntos, están afirmando “esto es lo que pretendemos lograr y así es como lo vamos a lograr.” Para ello, estos documentos deben ser exhaustivos y exactos. Pero no deben ser un fin en sí mismos. Su especificación funcional debe ser el resultado de su diseño, y no la razón por la que se hizo. En el peor de los casos, la especificación se convierte en una especie de campo de batalla El proveedor redacta su visión de cómo será el producto final y cómo va a funcionar. Usted, como cliente, lee ese documento y desarrolla su propio punto de vista. Luego lo modifica para alinearlo mejor con su propia visión y se lo devuelve al proveedor. Todo mundo afirma que está de acuerdo, todo mundo firma, y luego el proveedor va e implementa su propia visión de lo plasmado en ese documento definitivo, con toda una serie de supuestos y sesgos. Pero usted sabe que eso va a ocurrir, y por lo tanto se muestra renuente a firmarlo; “mejor vamos a afinarlo otro poquito, y otro poquito”. Como usted lo sabe, lo firma, y se convierte en ley. Cuando usted quiere que el sistema haga algo que pensó que estaba cubierto, el proveedor va a señalar la especificación y a decir: “¿Ya ve? Eso no está”, o “¿Ya ve? Eso fue lo que hicimos; lo que pasa es que no es exactamente como usted pensaba que iba a ser”. Así que ¡nadie quiere firmar el documento! Lograrlo puede llevarse meses — meses de tiempo del proyecto desperdiciados para que todo mundo pueda cubrirse debidamente el trasero, pero mientras tanto no está ocurriendo nada productivo en aras del proyecto. Créame: el proveedor no gana dinero si se la pasa haciendo revisiones a las especificaciones, y usted tampoco logra que se ejecute el proyecto. La solución a todos estos problemas es también una práctica muy recomendable de ingeniería. Simplifique la especificación y el proceso de aprobación y luego trabaje rápidamente para elaborar una aplicación prototipo que pueda ser susceptible de revisión, crítica constructiva y mejora. Déle retroalimentación al proveedor. “Mueve este botón para acá; cambia esta lógica”. Por lo general hacer estos cambios no requiere grandes cantidades de trabajo si el proveedor entiende bien sus requerimientos de negocios e hizo su tarea antes de empezar. Este le permite a su equipo hacer aportaciones válidas sobre algo concreto. A la mayoría de nosotros no se nos da muy bien crear cosas a partir de la nada, pero sí tendemos a ser bastante buenos para señalar cómo mejorar aquello que podemos ver y con lo que podemos interactuar. Un prototipo le permite a su equipo ver lo que el sistema está haciendo y cómo va a funcionar, y aportar ideas válidas sobre cómo su negocio puede interactuar con él. Fuente: ContactCenterWorld Continuará… |
|
