Si supieras dónde vas a caer, no solo pondrías paja en el suelo, sino que también extenderías una alfombra. Sin embargo, la vida y la práctica nos presentan sorpresas tales, que incluso los especialistas experimentados a veces cometen errores. Y esto puede sabotear la implementación de un nuevo sistema de hardware y software o el lanzamiento de un call-center. Aquí una historia basada en eventos reales. Gracias a una serie de circunstancias, terminó bien. La implementación fue un éxito, pero todo podría haber terminado mal. Si es que, no fuimos nosotros quienes implementamos, pero no repitan los errores ajenos.
El artículo pertenece a herramientas para el líder
Introducción
La empresa “Romashka” tenía su propio centro de contacto con capacidad para 200 posiciones, compuesto por dos partes. Condicionalmente, los llamaremos departamento de ventas y servicio al cliente. El departamento de ventas se ocupaba de atraer nuevos clientes, atendiendo llamadas entrantes y solicitudes a través de chats con ayuda de un sistema CRM.
El servicio al cliente brindaba asistencia a los clientes existentes, manejando llamadas con Asterisk, y llevaba su registro en unos CRM de desarrollo propio (que, por cierto, utilizaba simultáneamente cuatro DBMS: MS SQL Server, Oracle, PostgreSQL y MySQL para que no fuera aburrido).
El departamento de IT era una unidad organizativa separada y no desarrollaba ni mantenía su propio CRM, los técnicos de servicio periódicamente la mejoraban – así fue «históricamente». La empresa se dedicaba a la fabricación y suministro de equipos.
La dirección decidió implementar la plataforma CC (lanzar un call-center en la nube), para ayudar a los líderes de servicios a lidiar con el «zoológico» de sistemas de información, cuyos datos, naturalmente, se sincronizaban, pero «de alguna manera no del todo bien». Se suponía que el CC asumiría la gestión unificada de las llamadas, y los sistemas CRM – la gestión de contactos, mientras que el CC recibiría el contacto para su procesamiento y lo devolvería a la «correcta» CRM, es decir, se pretendía implementar un mecanismo de sincronización dentro de las «entrañas» del centro de contacto. En principio, tal esquema es posible en ciertas condiciones, porque no se podía acceder directamente al «cloud» del departamento de ventas, sino por API.
Dificultades en el lanzamiento del call-center, y sus soluciones
Las dificultades en el lanzamiento del call-center surgieron de inmediato. Por razones ideológicas se eligió la plataforma, y luego surgió la pregunta sobre el integrador. Se escribieron los requisitos técnicos, se solicitaron propuestas a cuatro compañías con experiencia similar, y se recibieron cuatro ofertas con una variación de precios de tres veces. ¿Cómo saber a quién confiar el trabajo? Escogieron al proveedor SIP más barato y, sorprendentemente, acertaron; los chicos resultaron ser los menos audaces, pero aun así tenían la calificación adecuada. Pero fue suerte, no se realizó una evaluación del potencial de los integradores. Y lo peor en los negocios es confiar en la suerte.
Firmaron el contrato, y comenzaron. Y entonces resultó que, por parte del cliente, el departamento asignado como responsable fue IT (que estaba aislado en su propio mundo y no sabía nada sobre el CRM interna, y no lo sabría, porque simplemente no existía documentación al respecto). Se dirigieron al servicio al cliente, la líder explicó que simplemente no tenían suficientes horas-programador para ayudar con la integración con la plataforma CC. Simplemente no. Pero tenían un plan de trabajo aprobado por la gerencia, que, por supuesto, todo era de categoría «importante-urgente».
Luego fueron al líder del departamento de ventas. Respondió que estaba completamente a favor, pero no podía liderar la implementación, porque no era técnico, sino de ventas y tenía… su propio plan. De alguna manera, con mucha dificultad, los representantes del integrador, contactando al propietario del negocio, obtuvieron horas de programador de IT y del departamento de servicio. El líder de la implementación por parte del cliente fue nombrado… correcto… ¡ el principal de ventas!
Se sentaron a escribir y aprobar los requisitos. En este punto, algunos se dieron cuenta de que las estaciones de trabajo de los agentes podrían no ser compatibles con la plataforma CC debido a los requisitos del sistema operativo. Se salvaron… pero podrían no haberlo hecho. Esto debe verificarse en la discusión previa al proyecto, antes de firmar el contrato principal. El error fue cometido por el gerente por parte del integrador, quien dijo que en las estaciones que vio, el SO era el correcto. Pero pasó por alto que podría haber estaciones que no había visto.
Lo primero que intentaron fue conectar el CC con la CRM en la nube. Con cierta dificultad se conectaron mediante API y la combinación funcionó… hasta que no se probó bajo carga real. Ahí fue cuando – el número de solicitudes a la base de datos en la nube por unidad de tiempo, resulta estar limitado, y esto no estaba indicado en ninguna parte, simplemente es así. En resumen, el problema se redujo a que la nube específica no podía manejar el CC específico. Calcularon el presupuesto para una solución en sitio – se estremecieron y casi la compraron. Casi – porque esta vez el integrador hizo la pregunta correcta sobre la migración de datos de la nube a la caja. Resultó que la migración de recursos definitivamente no era una opción. De alguna manera, lograron reducir el número de solicitudes a la nube. No compraron la caja.
Llegó la hora de conectar el CC con el departamento de servicio. Por supuesto, el único programador de allí que podía ayudar, se fue de vacaciones tres días antes de comenzar el trabajo. El proyecto se detuvo durante dos semanas (verifique los horarios de vacaciones de los especialistas clave, definitivamente). Pero cuando la persona regresó, se hizo el trabajo.
Surgió la pregunta de qué hacer con los datos que ya existían en ambas nubes, para reconciliarlos entre sí. Por cierto, había un esquema complejo de enrutamiento de contactos, dependiendo de en cuál CRM y con qué estado se encontraba el contacto, por lo que la contradicción de datos creó para los clientes una experiencia asombrosa como ciclos eternos en IVR. Los clientes pagaban a «Romashka» mucho dinero y no estaban muy contentos, porque cuando había problemas con el equipo, se interrumpía la continuidad de su negocio. Decidieron «dejar los datos existentes como estaban y limpiarlos después», y los datos de los nuevos clientes ya se manejaban correctamente. Esto funcionó, pero obviamente, el problema no se resolvió.
Casi dentro de los plazos y (con dificultad) dentro del marco de los requisitos técnicos, pero no de los requisitos, el integrador fue a entregar el trabajo. Y aquí resultó que los informes del CC, aunque cumplían 100% con los requisitos, eran… poco atractivos… no gustaban. Por qué eran poco atractivos y cómo modificarlos, nadie pudo explicar, hay sospechas de que simplemente no quedaba dinero para hacerlo. En general, el cliente discutió con el integrador durante un par de semanas más sobre la estética de los informes.
Hubo muchos más problemas, por ejemplo, surgieron conflictos internos entre los líderes de los departamentos del cliente. Pero – se hizo. Y funciona hasta hoy.
Conclusiones
La moraleja de esta fábula es muy simple: supongan que las cosas pueden ser incompatibles entre sí. Ya sea por sus características (como el sistema operativo de los puestos de operadores y el software del CC), o bajo ciertas condiciones (con carga y sin ella), o por el factor humano. Y en papel, todo suele estar bien, pero… It’s always easier said than done.
