miércoles, julio 25, 2012
Honda implica a sus clientes en una iniciativa social
Honda Automóviles España ha puesto en marcha una acción de
responsabilidad social empresarial que dotará hasta con 25.000 euros a la
propuesta ganadora de entre las acciones presentadas por los clientes de Honda.
Comunica alternativas mk ha sido la agencia encargada de llevar a cabo el
proyecto.
Bajo el nombre “Tu Proyecto, nuestro proyecto”, la marca
japonesa invita a todos los clientes propietarios de un automóvil Honda a enviar
sus propuestas para mejorar su entorno a través de acciones en diversos
ámbitos como pueden ser la comunidad (actividades sociales), el medio ambiente,
la movilidad sostenible y la tecnología e investigación.
Hasta el próximo 30 de septiembre los clientes podrán entrar en
un site privado y dejar sus propuestas. Una vez presentadas, los propios
usuarios son los encargados de su difusión para lograr el mayor número de votos
posible a través de las redes sociales. Todos los proyectos estarán visibles en
www.hondatuproyectonuestroproyecto.com, espacio de acceso para
visualizar y votar las iniciativas.
Una vez cerrado el plazo, se seleccionarán 10 propuestas
finalistas a partir de los votos recibidos por el público general.
Posteriormente, un jurado formado por personalidades de distintos ámbitos como
el académico, medioambiental, social y cultural y de Honda Automóviles España
será el encargado de elegir al proyecto ganador dotado de 25.000 euros,
que se conocerá en otoño de este 2012.
Esta iniciativa forma parte del marco Honda
Advantage, el proyecto de fidelización de la marca para sus clientes
también creado y gestionado por Comunica alternativas mk.
Transgresora
campaña de Scottex para relanzar sus toallitas húmedas
Con el nombre de “Culitos Besables”, la marca Scottex, propiedad de
Kimberly-Clark, ha estrenado una original y transgresora campaña para relanzar
el papel higiénico húmedo Scottex Fresh, que rompe con los cánones tradicionales
de la marca y del sector.
viernes, julio 06, 2012
Cómo tener éxito en su implementación de call center
Introducción
Un call center es una unidad de negocios cuyo epicentro es la gente y donde el punto focal radica en una comunicación exitosa. Vivimos en una era en la que la tecnología está revolucionando esas comunicaciones, y los call centers de mayor éxito utilizan una amplia gama de aplicaciones: PBXs y Sistemas de Distribución Automática Llamadas (ACD) que enrutan las llamadas; Sistemas de Audiorespuesta (IVR) y sistemas de buzón de voz que proporcionan una capacidad de respuesta automatizada y de autoservicio; sistemas de Administración de las Relaciones con los Clientes (CRM) que los agentes utilizan para tener acceso a y trabajar con los registros de los clientes; y toda una batería de sistemas de reporteo, supervisión y monitoreo de la calidad que los gerentes utilizan para manejar la operación del call center y medir su desempeño. Hay quienes podrían afirmar que casi todo sistema de negocios en una organización debería, de alguna manera, tener contacto con el call center. Para integrar todo esto en una solución única y coherente que satisfaga las necesidades de los usuarios finales, se necesitan no sólo un buen mapa de ruta, sino también un conocimiento exhaustivo y un entendimiento cabal de cómo se arma el rompecabezas, cuáles son las limitantes y restricciones, y qué es exactamente lo que se puede lograr con los sistemas y el presupuesto que tiene a su disposición. Se necesita algún tipo de guía.
Este artículo tiene el propósito de iniciar un diálogo sobre los pasos que hay que dar para garantizar una integración exitosa de su call center. Por desgracia, debido a la dificultad de combinar tan amplia variedad de sistemas con la impredecible comunicación en tiempo real con el cliente, son muchas las implementaciones que acaban por quedarse cortas respecto a las expectativas. Se puede fracasar de diversas maneras: el proyecto se prolonga y por lo tanto rebasa el presupuesto; los componentes tecnológicos no funcionan armónicamente como los proveedores prometieron; los usuarios finales rehúsan adoptar la tecnología. El fracaso puede ir desde que el sistema se considere como una molestia continua hasta el abandono total. Nosotros definimos el éxito como una entrega a tiempo y conforme al presupuesto, con la tecnología haciendo lo que usted espera que haga, y con la gente que trabaja en su call center entusiasmada con los resultados.
Cómo elegir a sus proveedores
Antes de comenzar un proyecto, es necesario seleccionar a sus proveedores. Todos hemos pasado por ahí: los socios prospectivos presentan sus credenciales y plantean sus propuestas – y usted debe elegir al que se perfile como el socio más compatible.
Al seleccionar un proveedor para una tecnología, usted está, hablando en términos generales, seleccionando dos cosas: la tecnología que vende y quién es. Este no es un tratado de las tecnologías en sí, por lo que damos por sentado que usted ha llevado a cabo la debida diligencia en lo que a elección de tecnología se refiere – ha comparado las soluciones con lo que ofrece la competencia y ha determinado que la tecnología de este proveedor tiene toda la funcionalidad que usted desea, es compatible con su ambiente tecnológico y es congruente con la visión de su organización a futuro. Ahora necesita evaluar si el proveedor es adecuado como prestador de servicios y socio/proveedor para su empresa.
Las estadísticas en la industria de call centers son bastante claras: si no se es cuidadoso, hay una probabilidad significativa de que el proyecto no tenga éxito, y una probabilidad aún mayor de que los costos resultan ser hasta dos veces lo que usted esperaba. Al elegir proveedores, usted está dando el primer paso para determinar si va a mantener su proyecto dentro del presupuesto o si va a pasar a ocupar un lugar en el lado deficitario de la ecuación. Usted necesita elegir a alguien que esté motivado para hacer que usted tenga éxito porque de ese modo también ellos tendrán éxito. Necesita crear una situación ganar/ganar, y la mejor manera de hacerlo es mantener todas las cartas sobre la mesa. Haga un esfuerzo por asegurarse que todos entiendan perfectamente el alcance de trabajo involucrado, y que sus proveedores estén dispuestos a entrarle por un precio justo. A cambio de la energía que usted dedique al “estira y afloja” con el proveedor de su elección con el fin de bajarle el precio hasta el mínimo absoluto posible, el proveedor se limitará a entregar exactamente lo usted adquirió... y nada más. Los márgenes perdidos los va a recuperar de otras maneras – cargos no especificados, funciones adicionales provenientes de modificaciones al alcance, y cargos extra hasta por el más mínimo detalle. A la hora de negociar, asegúrese de delinear con toda claridad qué quiere del proveedor y cómo espera que le sea entregado. La solución es compleja, así que hay que ser cautos.
Si usted crea una situación ganar/ganar con su proveedor – una en la que se entreguen bienes justos a precio justo, no debería haber motivos para que se presenten problemas continuamente en torno al precio. Por supuesto, toda negociación involucra a dos partes. Muchos proveedores rebajan el precio inicial con tal de ganar el negocio y después tratan de reponer lo perdido. Tenga cuidado con esta táctica. Como se mencionó anteriormente, uno de los dogmas de la industria dice que usted acabará pagando el doble de lo que pensó que iba a pagar. Si un precio le parece sospechosamente más bajo que los demás, escrutínelo bajo una lupa de escepticismo y exija que la definición del trabajo sea doblemente clara para garantizar que su proveedor se esté comprometiendo a entregarle éxito.
Específicamente, hay que prestar atención a lo siguiente:
La idea no es asegurarse de que su proveedor esté haciendo todo lo que aparece en la lista, sino más bien cerciorarse de que, de entrada, todo mundo entienda quien va a hacer qué, a fin de que todos puedan trabajar juntos de manera exitosa en un acuerdo mutuamente satisfactorio.
Administración del proyecto
Para tener un proyecto bien administrado, se necesita tener un buen administrador de proyectos.
¿Qué características hay que procurar en un administrador de proyectos? Antes que nada, experiencia en administración de proyectos técnicos en el campo de call centers. Alguien que ya haya guiado una implementación de soluciones exitosa en un call center es mucho más capaz de rendir buenos resultados que alguien que sólo tenga conocimientos generales de administración de proyectos. Un call center es una bestia muy particular, y se necesita alguien experimentado que la conozca bien.
Así que, ¿donde se puede encontrar a esa persona? ¿Va a recurrir a alguien interno, pedir al proveedor que la suministre, o a traer a alguien de fuera?
Administrador de proyectos interno
Las ventajas de utilizar a alguien interno son que la persona conoce su negocio y sabe cómo lograr que se muevan las cosas dentro de la organización. Si dispone de alguien así, que además entienda muy bien las cuestiones técnicas, probablemente es su mejor opción para encabezar el proyecto. Necesita poder interpretar la visión de conjunto y también (con asistencia técnica adecuada) llegar hasta un nivel considerable de detalle cuando se trate de puntos importantes. Esta persona, idealmente, debería ser uno de los principales decisores en la elección del proveedor. Si no está seguro de su capacidad técnica, tal vez valga la pena reconsiderar el nombramiento más detenidamente e incluso analizar la posibilidad de contratar a alguien externo.
Administrador de proyectos suministrado por el proveedor
Pedir al proveedor que proporcione el administrador del proyecto funciona bien si el proveedor va a realizar la mayor parte del trabajo o si está administrando la mayoría de los aspectos de la solución. En ese caso, casi podía uno considerar que el proveedor está obligado a administrar el proyecto. Pero tenga cuidado con sus expectativas. Ciertamente, el proveedor debe ser capaz de administrar la parte que le toca del trabajo, así como de administrar todas las áreas de trabajo en común para las cuales tenga el expertise necesario. Pero una cosa que un proveedor no puede hacer muy bien es movilizar recursos dentro de su empresa ni con otros proveedores involucrados en el proyecto. Aun si se conviene en que el proveedor administre el proyecto, de cualquier manera usted tendrá que proporcionar a alguien propio que tenga la autoridad para hacer cumplir su parte del trato y que pueda hacer suyo el proyecto. El área de mayor preocupación con un administrador de proyectos suministrado por el proveedor es que no son necesariamente objetivos en sus puntos de vista, y esto puede afectar el resultado del proyecto.
Administrador de proyectos consultor
Para un proyecto grande, a menudo es conveniente incorporar un administrador de proyectos contratado externamente si la persona tiene experiencia similar en proyectos similares. Esto le da a usted la ventaja de trabajar con alguien que es neutral desde el punto de vista técnico y profesional respecto a usted y los proveedores, y que puede fungir como árbitro imparcial en caso de discrepancias. La lealtad de su administrador externo debe ser para con el proyecto. Sin embargo, en este caso, necesita asegurarse de dar a esa persona suficiente autoridad para llevar a cabo su labor. No tiene caso traer a alguien de fuera si no se le faculta para hacer que se hagan las cosas.
Se ha hecho mucho énfasis en los aspectos técnicos del rol del administrador de proyectos. ¿Significa que un administrador de proyectos tiene que estar perfectamente familiarizado con todas las tecnologías involucradas en un proyecto? La respuesta rápida es “no”. Se trata de encontrar a alguien que tenga una visión muy completa de la tecnología del proyecto en general, y que tenga la capacidad para entender los detalles técnicos a medida que le sean presentados y explicados. Para ilustrar este punto, veamos un caso de estudio hipotético.
Vamos a crear en nuestra imaginación un proyecto de integración de un call center. Nuestra empresa imaginaria se llama GrowthCorp y cuenta con tres call centers en tres husos horarios distintos. Dos de ellos son idénticos en cuanto a tecnología, pues utilizan el mismo sistema de IVR y el mismo PBX, pero sin automatización CTI en las terminales de los agentes. El tercer centro es producto de una adquisición reciente. Utiliza un PBX y una plataforma de IVR distintos, pero tiene una integración CTI SmartCall de primera clase con un sistema de CRM GreatService. Actualmente no hay una red que enlace los tres centros. GrowthCorp ha decidido que quiere tener un solo call center virtual. A nivel corporativo también ha decidido adoptar GreatService como solución de CRM.
Luego de examinar muchas soluciones distintas, GrowthCorp decide (dejando de lado los diferentes drivers de negocios) lo siguiente: Va a establecer una red para enlazar los tres centros usando la misma plataforma de PBX para tener un único call center virtual con buena redundancia geográfica entre las tres regiones geográficas. Para la plataforma de PBX, ha optado por conservar el sistema A que utilizan dos de sus centros, pues ofrece buena capacidad de interconexión en red y una excelente plataforma para una migración futura hacia VoIP. Sin embargo, quiere utilizar el combo de IVR y CTI del centro C, ambos compatibles con el PBX A. En pocas palabras, el proyecto en general sería más o menos así:
En el proyecto tomarán parte representantes de los siguientes grupos:
Las probabilidades de que encuentre un administrador de proyectos con amplia experiencia en todas estas áreas son muy remotas. Pero lo que usted está buscando es alguien que haya administrado integraciones parecidas. El trabajo de su administrador de proyectos no consiste en entender todas las minucias técnicas de un proyecto tan vasto. Su labor es coordinar las actividades y asegurarse de que todo se haga. De modo que, aunque su administrador de proyectos no tiene que entender los detalles de configuración de cada uno de los componentes, si debería entender las dependencias entre todas las partes del sistema. Su administrador de proyectos debe poder entender cómo embonan las piezas y cómo sortear las múltiples “excusas” que sin duda le presentarán, a fin de determinar qué es real y qué no lo es.
Por encima de todo, su administrador de proyectos debe ser capaz de crear un ambiente de equipo en el que las dependencias se discutan, se evalúen y se incorporen al plan del proyecto. En lo que se refiere a los detalles técnicos, ese es el rol más importante de su administrador de proyectos: debe fungir como un agilizador, cerciorándose de que todos los detalles se ventilen y se incorporen a un plan integral.
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:
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.
Aquí estamos hablando de un nivel muy general. Para el proyecto del ejemplo que presentamos anteriormente, se requieren un gran número de requerimientos y sesiones de diseño.
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.
Implementación
El tema del desarrollo de prototipos nos conduce a la implementación en sí. Considerando todos los demás factores como constantes, el éxito de una implementación por lo general se reduce a contar con los recursos adecuados en un entorno adecuado. Eso significa que los desarrolladores y los integradores tengan acceso a los sistemas con los cuales necesitan trabajar, que cuenten con las autorizaciones y permisos es necesario para instalar y configurar los sistemas, y que dispongan del tipo de datos que necesitan para simular condiciones reales operación, entre otros requerimientos. Lo que rotundamente no significa es que alguien se presente en las instalaciones del cliente para dedicarle dos días de trabajo y deba esperar un día y medio para que “lo den de alta”, o hacer que alguien tenga que esperar un mes para la entrega de algún dato sólo para descubrir que el sistema no maneja el tipo de comportamiento necesario para el trabajo de desarrollo.
Una buena práctica de implementación consiste en hacer que la gente adecuada comience a comunicarse desde muy temprano en el proyecto y en asegurarse que tengan la autoridad necesaria para lograr que las cosas se hagan. En papel, la implementación viene después del diseño. Usted no va a poder construir nada mientras no tenga el diseño perfectamente definido y aprobado. Sin embargo, especialmente cuando uno ya tiene una muy buena idea de hacia dónde va, una de las primeras cosas por hacer es comenzar a preparar sus sistemas de desarrollo. Esta es una actividad en la que es posible hacer avances concretos mientras se afina el diseño, especialmente en los casos en que hay preguntas que necesitan ser resueltas antes de concluir el diseño -- ¿cómo se va a comunicar mi IVR con este sistema en el backend? ¿Puedo integrar estos controles a la aplicación de CRM o tengo que irme por otra ruta? Y, por supuesto, siguiendo la línea de pensamiento previamente expuesta, entre más pronto se tenga un ambiente de trabajo, más pronto se podrá comenzar a trabajar en un prototipo.
La obra terminada
Un área que siempre se pasa por alto a la hora de seleccionar al integrador del sistema es su capacidad para diagnosticar problemas del sistema durante el proyecto. Así como algunos médicos son mejores que otros para diagnosticar un problema en un paciente, algunos integradores son mejores que otros para diagnosticar cuál es el problema con una implementación. Entre mejor sea su capacidad de diagnóstico, más terso resultará el proceso de implantación.
Contar con las herramientas adecuadas para ayudar a suministrar información sobre los síntomas resultará sumamente útil a lo largo de todo el proceso. Una de las calamidades de todo proyecto de implementación es que de pronto se presenta algún problema que nadie entiende. Pueden pasar días o semanas hasta que se resuelve y, mientras tanto, los proveedores se echan la culpa unos a otros y lo dejan a usted, el propietario del proyecto, a que averigüe qué está sucediendo en un ambiente técnico y sumamente complejo, y a que consiga a alguien que pueda solucionarlo.
Al momento de hacer su evaluación inicial de los proveedores, averigüe cómo es que pretenden aislar y resolver los problemas que lleguen a presentarse durante el proceso de implementación. Estar seguro que sus proveedores pueden resolver cualquier problema rápidamente puede acortar hasta en semanas el tiempo del proyecto, liberar a su personal más pronto, y garantizar que podrá mantener a raya los costos de sus proveedores.
Contar con buenas herramientas de diagnóstico también le permitirá resolver los problemas que se presenten en su ambiente de producción cuando sea necesario hacer cambios, y también acortarán considerablemente el tiempo de resolución. Sus costos totales serán menores y su negocio funcionará mejor si usted puede determinar la fuente específica de un problema en cuestión de horas en vez de días. Preste mucha atención a esto desde el principio de su implementación para cerciorarse que las cosas marchen sobre ruedas en un futuro.
Pruebas de aceptación
Ya hemos planteado la mayor parte de los puntos clave que necesitamos presentar. Hablando de pruebas de aceptación, uno de los principales problemas es el del sentido de “propiedad”. Hay que dejar bien claro que su proveedor es el responsable de garantizar que la solución que ha sido implementada esté funcionando correctamente. Esto se definiría como una prueba de sistema: asegurarse que el sistema en su conjunto funcione bien, de cabo a rabo. La propiedad de cualquier prueba de sistema le corresponde al proveedor. Las pruebas de aceptación, en cambio, son un proceso de aceptación que a menudo se sigue para que el propietario del proyecto pueda determinar que la solución satisface sus necesidades. Por lo tanto, la propiedad de las pruebas de aceptación le corresponde definitivamente a los propietarios y patrocinadores del proyecto, quienquiera que sea que va a “aceptar” el sistema.
Es mejor si la propiedad de los diferentes tipos de pruebas queda entendida de manera explícita desde un principio. Por lo general el proveedor se va a asegurar que el sistema funcione correctamente, pero usted tiene que cerciorarse que satisfaga sus criterios de aceptación. Es importante señalar que estas pruebas pueden ser una misma, y más aún, que incluso cuando se habla de pruebas de aceptación, el proveedor debe poder ayudarle a implementar las pruebas, pues ellos saben cómo hacer que funcione el sistema. Pero, en última instancia, usted necesita recordar que se trata de su sistema y, por consiguiente, tendrá que hacer suya la responsabilidad de asegurarse que las cosas se organicen. Si comenzó bien su proyecto con una descripción adecuada de cómo se debe comportar el sistema, entonces fincó buenos cimientos para las pruebas de aceptación. Cada proveedor necesita presentar casos de prueba para la parte del sistema que les corresponde conforme a las especificaciones definidas por usted. Todos los proveedores, juntos, deben contribuir con aquellos casos que pongan a prueba el funcionamiento del sistema en su conjunto. Una persona debe ser responsable de organizar todo para conformar un paquete coherente de casos de prueba.
Le aconsejamos no poner a prueba únicamente casos positivos; esto es, hay que asegurarse que las pruebas de su sistema no se limiten a confirmar que el sistema funciona como debe ser cuando se usa de la manera en que usted espera que sea utilizado. Hablando de desarrollo de software en general, el 80% del código está dedicado a manejar situaciones de error. Si usted prueba todos los casos positivos, habrá cubierto, por consiguiente, tan sólo el 20% de su funcionalidad. Cerciórese de poner a prueba los puntos de falla y trate de determinar cómo se comporta el sistema cuando no se le utiliza debidamente. Es importante tomar en cuenta que no hay manera de anticipar todas las distintas maneras en que se abusará del sistema en la práctica.
Transición
Es importante planear el proceso de transición con la debida anticipación. Divídalo en etapas siempre que sea posible cuando se trate de un rollout complejo, y apréndase de memoria el procedimiento para revertirlo en caso necesario.
A partir del momento que comience su proyecto usted deberá estar contemplando el momento en que llegue a su término. Al principio, la transición no es más que un momento de la verdad aparentemente distante. Pero muy pronto llegará el momento en que se encuentre previendo contingencias y determinando las listas de actividades para pasar del Viejo al Nuevo Mundo. Y la verdad es que lo deseable es que no se trate de un momento de la verdad, sino más bien de una secuencia ordenada de pasos. Para ello necesita identificar todo lo que pueda implantarse de antemano e implantarlo. Cualquier software en su sistema de IVR o CRM, o en las terminales de sus agentes que pueda instalar de antemano será una cosa menos de qué preocuparse cuando llegue el momento. Entre menos cosas tenga que hacer al mismo tiempo, mejor.
Un aspecto importante de la transición consiste en garantizar que todos los sistemas prescritos estén funcionando, lo que significa que una de las últimas cosas que va usted a hacer es incorporar la configuración del sistema completo. A menudo este es el último paso antes de comenzar la transición, pero con mucha frecuencia ocurre que el equipo de proyecto no se da cuenta de que la información de configuración que necesita no se encuentra disponible en una sola fuente, y además resulta que la que está disponible muchas veces está obsoleta. Es muy importante entender qué información se necesita y recabarla con tiempo. Si además la verifica dos veces para cerciorarse que es la información más exacta y actualizada, habrá dado un paso crucial para una implementación sin sobresaltos.
La capacitación es a menudo un aspecto complicado. Es indispensable capacitar a los agentes y a los supervisores con anticipación. Hay que explicar con lujo de detalles cualquier modificación que vaya a sufrir el comportamiento de los teléfonos o las aplicaciones. Muchas veces la capacitación se aborda en forma precipitada, con lo cual los agentes sienten que son los últimos en enterarse de lo que está sucediendo y los primeros en padecer los efectos secundarios. Aproveche sus sesiones de capacitación para ganarse el entusiasmo de los agentes. Explíqueles la “imagen de conjunto”, cómo es que estos cambios son mejoras que les ayudarán a alcanzar sus objetivos (lo cual, idealmente, ¡debería ser cierto!). Recuerde que los buenos agentes utilizan sus herramientas de manera habitual y como verdaderos expertos. Si van a tener que modificar sus hábitos, hágaselos saber con antelación y explíqueles por qué.
Durante la transición en si, cualquier cosa que pueda hacerse por etapas deberá hacerse así. Por ejemplo, si puede hacer la transición de las aplicaciones número por número en su sistema de respuesta interactiva de voz, hágalo. Si puede hacer la transición de los agentes a la nueva aplicación por grupos, hágalo.
Si quita cualquier elemento del sistema, cerciórese de que sabe cómo volverlo a incorporar en caso necesario. Tenga cuidado en aquellas situaciones en las que esté reutilizando algún equipo de hardware. ¿Está instalando su nuevo servidor de CTI en la misma computadora del sistema viejo? Más le vale que sepa cómo revertir el procedimiento, por si acaso.
Y por supuesto no hay que olvidar todas las formalidades de rigor a la hora de la transición para asegurarse que todos los interesados en el negocio estén al tanto de lo que está sucediendo – qué se está cambiando y cómo puede afectar el desempeño de sus labores, tanto en el mejor como en el peor de los casos. No basta con cerciorarse de tener personal a la mano en caso de una posible falla, sino también que los supervisores estén al tanto de cualquier problema crítico al que necesiten estar atentos y que sepan a quién y cómo deben reportarlo.
La mañana siguiente
Entonces, ¿qué pasa una vez que se acaba la música? La respuesta: nunca se acaba. El ritmo cambia, pero puede estar seguro que siempre seguirá habiendo cambios. Algunas organizaciones prefieren un proceso formal de cierre de proyecto en el que todos los pendientes de proyecto se “empacan”, se palomean oficialmente las listas de comprobación, y se libera a los integrantes del proyecto. Eso suena muy bien y, si usted sabe cómo hacer que funcione (o si es congruente con la manera en que se hacen las cosas en su organización), adelante. Nosotros hemos visto, por experiencia, que algunas transiciones se dan de manera limpia y rápida, pero otras pueden llevarse algún tiempo hasta que las cosas se estabilizan. Cuando llega a haber ruido, generalmente se debe a errores de configuración de hardware (muchas veces en el PBX) que habrían resultado muy difíciles de prever y a veces resulta difícil aislar. En este caso va a necesitar que sus equipos de soporte dediquen tiempo adicional a ir depurando todas las fallas. Eso nos lleva al punto de la transición al área de soporte.
A lo largo del proyecto se trabaja en estrecha colaboración con los equipos de implementación del proveedor, los expertos en integrar la solución. En muchos sentidos, la prueba de fuego para determinar el calibre de un proveedor viene después de la implantación. Si de pronto se encuentra con que no puede comunicarse con su equipo de expertos después de la transición, está usted en aprietos. Es una exageración, pero sin duda sería muy bueno que no hubiese un cambio de guardia radical en cuanto se da la transición. Sería injusto que usted esperase que el ingeniero que implementó su solución le resolviese problemas de configuración de rutina, pero no es poco razonable esperar que esta persona esté disponible para resolver problemas que afecten el desempeño de su call center y no hayan sido debidamente atacados durante el proyecto.
Conclusión
Los proyectos de integración de call centers son complejos por naturaleza, y tradicionalmente son más difíciles que los proyectos básicos de integración de datos que por lo general enfrentan los departamentos de TI. El call center abarca una gran variedad de tecnologías que interactúan no sólo con sus principales sistemas de negocios, sino también con el activo más valioso de su empresa: sus clientes. Muchas implementaciones en este terreno no son consideradas como éxitos, pero hemos descubierto que, siguiendo algunos de los lineamientos aquí presentados, es posible lograr que las cosas funcionen, es posible integrar y optimizar el call center, y usted puede tener éxito en mejorar la atención que brinda a sus clientes sin exceder su presupuesto. Al igual que con otros proyectos en el call center, todo se reduce a contar con gente capaz de hacer el trabajo, seguir aquellos procesos que favorezcan un resultado positivo, y usar una tecnología que satisfaga sus necesidades hoy y en el futuro.
Fuente: ContactCenterWorld
Un call center es una unidad de negocios cuyo epicentro es la gente y donde el punto focal radica en una comunicación exitosa. Vivimos en una era en la que la tecnología está revolucionando esas comunicaciones, y los call centers de mayor éxito utilizan una amplia gama de aplicaciones: PBXs y Sistemas de Distribución Automática Llamadas (ACD) que enrutan las llamadas; Sistemas de Audiorespuesta (IVR) y sistemas de buzón de voz que proporcionan una capacidad de respuesta automatizada y de autoservicio; sistemas de Administración de las Relaciones con los Clientes (CRM) que los agentes utilizan para tener acceso a y trabajar con los registros de los clientes; y toda una batería de sistemas de reporteo, supervisión y monitoreo de la calidad que los gerentes utilizan para manejar la operación del call center y medir su desempeño. Hay quienes podrían afirmar que casi todo sistema de negocios en una organización debería, de alguna manera, tener contacto con el call center. Para integrar todo esto en una solución única y coherente que satisfaga las necesidades de los usuarios finales, se necesitan no sólo un buen mapa de ruta, sino también un conocimiento exhaustivo y un entendimiento cabal de cómo se arma el rompecabezas, cuáles son las limitantes y restricciones, y qué es exactamente lo que se puede lograr con los sistemas y el presupuesto que tiene a su disposición. Se necesita algún tipo de guía.
Este artículo tiene el propósito de iniciar un diálogo sobre los pasos que hay que dar para garantizar una integración exitosa de su call center. Por desgracia, debido a la dificultad de combinar tan amplia variedad de sistemas con la impredecible comunicación en tiempo real con el cliente, son muchas las implementaciones que acaban por quedarse cortas respecto a las expectativas. Se puede fracasar de diversas maneras: el proyecto se prolonga y por lo tanto rebasa el presupuesto; los componentes tecnológicos no funcionan armónicamente como los proveedores prometieron; los usuarios finales rehúsan adoptar la tecnología. El fracaso puede ir desde que el sistema se considere como una molestia continua hasta el abandono total. Nosotros definimos el éxito como una entrega a tiempo y conforme al presupuesto, con la tecnología haciendo lo que usted espera que haga, y con la gente que trabaja en su call center entusiasmada con los resultados.
Cómo elegir a sus proveedores
Antes de comenzar un proyecto, es necesario seleccionar a sus proveedores. Todos hemos pasado por ahí: los socios prospectivos presentan sus credenciales y plantean sus propuestas – y usted debe elegir al que se perfile como el socio más compatible.
Al seleccionar un proveedor para una tecnología, usted está, hablando en términos generales, seleccionando dos cosas: la tecnología que vende y quién es. Este no es un tratado de las tecnologías en sí, por lo que damos por sentado que usted ha llevado a cabo la debida diligencia en lo que a elección de tecnología se refiere – ha comparado las soluciones con lo que ofrece la competencia y ha determinado que la tecnología de este proveedor tiene toda la funcionalidad que usted desea, es compatible con su ambiente tecnológico y es congruente con la visión de su organización a futuro. Ahora necesita evaluar si el proveedor es adecuado como prestador de servicios y socio/proveedor para su empresa.
Las estadísticas en la industria de call centers son bastante claras: si no se es cuidadoso, hay una probabilidad significativa de que el proyecto no tenga éxito, y una probabilidad aún mayor de que los costos resultan ser hasta dos veces lo que usted esperaba. Al elegir proveedores, usted está dando el primer paso para determinar si va a mantener su proyecto dentro del presupuesto o si va a pasar a ocupar un lugar en el lado deficitario de la ecuación. Usted necesita elegir a alguien que esté motivado para hacer que usted tenga éxito porque de ese modo también ellos tendrán éxito. Necesita crear una situación ganar/ganar, y la mejor manera de hacerlo es mantener todas las cartas sobre la mesa. Haga un esfuerzo por asegurarse que todos entiendan perfectamente el alcance de trabajo involucrado, y que sus proveedores estén dispuestos a entrarle por un precio justo. A cambio de la energía que usted dedique al “estira y afloja” con el proveedor de su elección con el fin de bajarle el precio hasta el mínimo absoluto posible, el proveedor se limitará a entregar exactamente lo usted adquirió... y nada más. Los márgenes perdidos los va a recuperar de otras maneras – cargos no especificados, funciones adicionales provenientes de modificaciones al alcance, y cargos extra hasta por el más mínimo detalle. A la hora de negociar, asegúrese de delinear con toda claridad qué quiere del proveedor y cómo espera que le sea entregado. La solución es compleja, así que hay que ser cautos.
Si usted crea una situación ganar/ganar con su proveedor – una en la que se entreguen bienes justos a precio justo, no debería haber motivos para que se presenten problemas continuamente en torno al precio. Por supuesto, toda negociación involucra a dos partes. Muchos proveedores rebajan el precio inicial con tal de ganar el negocio y después tratan de reponer lo perdido. Tenga cuidado con esta táctica. Como se mencionó anteriormente, uno de los dogmas de la industria dice que usted acabará pagando el doble de lo que pensó que iba a pagar. Si un precio le parece sospechosamente más bajo que los demás, escrutínelo bajo una lupa de escepticismo y exija que la definición del trabajo sea doblemente clara para garantizar que su proveedor se esté comprometiendo a entregarle éxito.
Específicamente, hay que prestar atención a lo siguiente:
- ¿Puede el proveedor hablar de manera coherente y significativa sobre cómo piensa implementar la solución?
- ¿Puede abordar con inteligencia las ramificaciones de funciones específicas que está ofreciendo suministrarle?
- ¿Busca un entendimiento concreto de su negocio y su entorno?
- Cuando alguien le dice que este componente se va a comunicar con aquel, ¿le dicen quién se va a encargar de que así sea?
- ¿Existe algún software o middleware adicional que se va a requerir pero que no ha sido identificado o desglosado en el costo?
- ¿Quién va a administrar qué partes del proyecto? Si espera que su proveedor administre todo el proyecto, ¿se lo ha hecho saber con todas sus letras?
- Si es necesario llevar a cabo trabajo de desarrollo en su front o back-end actual, ¿cómo se van a repartir las responsabilidades?
- ¿Quién es responsable de las pruebas del sistema, y por establecer ambientes de pruebas?
- ¿Cómo se va a capacitar a los usuarios finales? Si los agentes del call center van a utilizar nuevas interfaces, ¿quién va a proporcionar a los instructores?
- ¿Están contempladas todas las interfaces?
- ¿Qué tipo de documentación le van a entregar?
La idea no es asegurarse de que su proveedor esté haciendo todo lo que aparece en la lista, sino más bien cerciorarse de que, de entrada, todo mundo entienda quien va a hacer qué, a fin de que todos puedan trabajar juntos de manera exitosa en un acuerdo mutuamente satisfactorio.
Administración del proyecto
Para tener un proyecto bien administrado, se necesita tener un buen administrador de proyectos.
¿Qué características hay que procurar en un administrador de proyectos? Antes que nada, experiencia en administración de proyectos técnicos en el campo de call centers. Alguien que ya haya guiado una implementación de soluciones exitosa en un call center es mucho más capaz de rendir buenos resultados que alguien que sólo tenga conocimientos generales de administración de proyectos. Un call center es una bestia muy particular, y se necesita alguien experimentado que la conozca bien.
Así que, ¿donde se puede encontrar a esa persona? ¿Va a recurrir a alguien interno, pedir al proveedor que la suministre, o a traer a alguien de fuera?
Administrador de proyectos interno
Las ventajas de utilizar a alguien interno son que la persona conoce su negocio y sabe cómo lograr que se muevan las cosas dentro de la organización. Si dispone de alguien así, que además entienda muy bien las cuestiones técnicas, probablemente es su mejor opción para encabezar el proyecto. Necesita poder interpretar la visión de conjunto y también (con asistencia técnica adecuada) llegar hasta un nivel considerable de detalle cuando se trate de puntos importantes. Esta persona, idealmente, debería ser uno de los principales decisores en la elección del proveedor. Si no está seguro de su capacidad técnica, tal vez valga la pena reconsiderar el nombramiento más detenidamente e incluso analizar la posibilidad de contratar a alguien externo.
Administrador de proyectos suministrado por el proveedor
Pedir al proveedor que proporcione el administrador del proyecto funciona bien si el proveedor va a realizar la mayor parte del trabajo o si está administrando la mayoría de los aspectos de la solución. En ese caso, casi podía uno considerar que el proveedor está obligado a administrar el proyecto. Pero tenga cuidado con sus expectativas. Ciertamente, el proveedor debe ser capaz de administrar la parte que le toca del trabajo, así como de administrar todas las áreas de trabajo en común para las cuales tenga el expertise necesario. Pero una cosa que un proveedor no puede hacer muy bien es movilizar recursos dentro de su empresa ni con otros proveedores involucrados en el proyecto. Aun si se conviene en que el proveedor administre el proyecto, de cualquier manera usted tendrá que proporcionar a alguien propio que tenga la autoridad para hacer cumplir su parte del trato y que pueda hacer suyo el proyecto. El área de mayor preocupación con un administrador de proyectos suministrado por el proveedor es que no son necesariamente objetivos en sus puntos de vista, y esto puede afectar el resultado del proyecto.
Administrador de proyectos consultor
Para un proyecto grande, a menudo es conveniente incorporar un administrador de proyectos contratado externamente si la persona tiene experiencia similar en proyectos similares. Esto le da a usted la ventaja de trabajar con alguien que es neutral desde el punto de vista técnico y profesional respecto a usted y los proveedores, y que puede fungir como árbitro imparcial en caso de discrepancias. La lealtad de su administrador externo debe ser para con el proyecto. Sin embargo, en este caso, necesita asegurarse de dar a esa persona suficiente autoridad para llevar a cabo su labor. No tiene caso traer a alguien de fuera si no se le faculta para hacer que se hagan las cosas.
Se ha hecho mucho énfasis en los aspectos técnicos del rol del administrador de proyectos. ¿Significa que un administrador de proyectos tiene que estar perfectamente familiarizado con todas las tecnologías involucradas en un proyecto? La respuesta rápida es “no”. Se trata de encontrar a alguien que tenga una visión muy completa de la tecnología del proyecto en general, y que tenga la capacidad para entender los detalles técnicos a medida que le sean presentados y explicados. Para ilustrar este punto, veamos un caso de estudio hipotético.
Vamos a crear en nuestra imaginación un proyecto de integración de un call center. Nuestra empresa imaginaria se llama GrowthCorp y cuenta con tres call centers en tres husos horarios distintos. Dos de ellos son idénticos en cuanto a tecnología, pues utilizan el mismo sistema de IVR y el mismo PBX, pero sin automatización CTI en las terminales de los agentes. El tercer centro es producto de una adquisición reciente. Utiliza un PBX y una plataforma de IVR distintos, pero tiene una integración CTI SmartCall de primera clase con un sistema de CRM GreatService. Actualmente no hay una red que enlace los tres centros. GrowthCorp ha decidido que quiere tener un solo call center virtual. A nivel corporativo también ha decidido adoptar GreatService como solución de CRM.
Luego de examinar muchas soluciones distintas, GrowthCorp decide (dejando de lado los diferentes drivers de negocios) lo siguiente: Va a establecer una red para enlazar los tres centros usando la misma plataforma de PBX para tener un único call center virtual con buena redundancia geográfica entre las tres regiones geográficas. Para la plataforma de PBX, ha optado por conservar el sistema A que utilizan dos de sus centros, pues ofrece buena capacidad de interconexión en red y una excelente plataforma para una migración futura hacia VoIP. Sin embargo, quiere utilizar el combo de IVR y CTI del centro C, ambos compatibles con el PBX A. En pocas palabras, el proyecto en general sería más o menos así:
- Instalar el PBX A en el call center C y luego enlazar los tres centros en red.
- Dotar a todo el sistema de la solución IVR del centro C.
- Implementar el sistema de CRM GreatService en los tres centros, junto con CTI SmartCall.
En el proyecto tomarán parte representantes de los siguientes grupos:
- El proveedor de servicios de telecomunicaciones, a fin de determinar cómo enrutar las llamadas hacia y entre los tres centros
- El proveedor del PBX, para instalar el nuevo conmutador y configurar el enrutamiento de la red en función de habilidades
- El proveedor del sistema IVR, para configurar los nuevos programas de IVR para el centro virtual.
- El proveedor de CTI, para configurar la integración de CTI para el centro virtual
- El proveedor de CRM, para dar respaldo durante la implementación a nivel empresa.
Las probabilidades de que encuentre un administrador de proyectos con amplia experiencia en todas estas áreas son muy remotas. Pero lo que usted está buscando es alguien que haya administrado integraciones parecidas. El trabajo de su administrador de proyectos no consiste en entender todas las minucias técnicas de un proyecto tan vasto. Su labor es coordinar las actividades y asegurarse de que todo se haga. De modo que, aunque su administrador de proyectos no tiene que entender los detalles de configuración de cada uno de los componentes, si debería entender las dependencias entre todas las partes del sistema. Su administrador de proyectos debe poder entender cómo embonan las piezas y cómo sortear las múltiples “excusas” que sin duda le presentarán, a fin de determinar qué es real y qué no lo es.
Por encima de todo, su administrador de proyectos debe ser capaz de crear un ambiente de equipo en el que las dependencias se discutan, se evalúen y se incorporen al plan del proyecto. En lo que se refiere a los detalles técnicos, ese es el rol más importante de su administrador de proyectos: debe fungir como un agilizador, cerciorándose de que todos los detalles se ventilen y se incorporen a un plan integral.
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.
Aquí estamos hablando de un nivel muy general. Para el proyecto del ejemplo que presentamos anteriormente, se requieren un gran número de requerimientos y sesiones de diseño.
- 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.
Implementación
El tema del desarrollo de prototipos nos conduce a la implementación en sí. Considerando todos los demás factores como constantes, el éxito de una implementación por lo general se reduce a contar con los recursos adecuados en un entorno adecuado. Eso significa que los desarrolladores y los integradores tengan acceso a los sistemas con los cuales necesitan trabajar, que cuenten con las autorizaciones y permisos es necesario para instalar y configurar los sistemas, y que dispongan del tipo de datos que necesitan para simular condiciones reales operación, entre otros requerimientos. Lo que rotundamente no significa es que alguien se presente en las instalaciones del cliente para dedicarle dos días de trabajo y deba esperar un día y medio para que “lo den de alta”, o hacer que alguien tenga que esperar un mes para la entrega de algún dato sólo para descubrir que el sistema no maneja el tipo de comportamiento necesario para el trabajo de desarrollo.
Una buena práctica de implementación consiste en hacer que la gente adecuada comience a comunicarse desde muy temprano en el proyecto y en asegurarse que tengan la autoridad necesaria para lograr que las cosas se hagan. En papel, la implementación viene después del diseño. Usted no va a poder construir nada mientras no tenga el diseño perfectamente definido y aprobado. Sin embargo, especialmente cuando uno ya tiene una muy buena idea de hacia dónde va, una de las primeras cosas por hacer es comenzar a preparar sus sistemas de desarrollo. Esta es una actividad en la que es posible hacer avances concretos mientras se afina el diseño, especialmente en los casos en que hay preguntas que necesitan ser resueltas antes de concluir el diseño -- ¿cómo se va a comunicar mi IVR con este sistema en el backend? ¿Puedo integrar estos controles a la aplicación de CRM o tengo que irme por otra ruta? Y, por supuesto, siguiendo la línea de pensamiento previamente expuesta, entre más pronto se tenga un ambiente de trabajo, más pronto se podrá comenzar a trabajar en un prototipo.
La obra terminada
Un área que siempre se pasa por alto a la hora de seleccionar al integrador del sistema es su capacidad para diagnosticar problemas del sistema durante el proyecto. Así como algunos médicos son mejores que otros para diagnosticar un problema en un paciente, algunos integradores son mejores que otros para diagnosticar cuál es el problema con una implementación. Entre mejor sea su capacidad de diagnóstico, más terso resultará el proceso de implantación.
Contar con las herramientas adecuadas para ayudar a suministrar información sobre los síntomas resultará sumamente útil a lo largo de todo el proceso. Una de las calamidades de todo proyecto de implementación es que de pronto se presenta algún problema que nadie entiende. Pueden pasar días o semanas hasta que se resuelve y, mientras tanto, los proveedores se echan la culpa unos a otros y lo dejan a usted, el propietario del proyecto, a que averigüe qué está sucediendo en un ambiente técnico y sumamente complejo, y a que consiga a alguien que pueda solucionarlo.
Al momento de hacer su evaluación inicial de los proveedores, averigüe cómo es que pretenden aislar y resolver los problemas que lleguen a presentarse durante el proceso de implementación. Estar seguro que sus proveedores pueden resolver cualquier problema rápidamente puede acortar hasta en semanas el tiempo del proyecto, liberar a su personal más pronto, y garantizar que podrá mantener a raya los costos de sus proveedores.
Contar con buenas herramientas de diagnóstico también le permitirá resolver los problemas que se presenten en su ambiente de producción cuando sea necesario hacer cambios, y también acortarán considerablemente el tiempo de resolución. Sus costos totales serán menores y su negocio funcionará mejor si usted puede determinar la fuente específica de un problema en cuestión de horas en vez de días. Preste mucha atención a esto desde el principio de su implementación para cerciorarse que las cosas marchen sobre ruedas en un futuro.
Pruebas de aceptación
Ya hemos planteado la mayor parte de los puntos clave que necesitamos presentar. Hablando de pruebas de aceptación, uno de los principales problemas es el del sentido de “propiedad”. Hay que dejar bien claro que su proveedor es el responsable de garantizar que la solución que ha sido implementada esté funcionando correctamente. Esto se definiría como una prueba de sistema: asegurarse que el sistema en su conjunto funcione bien, de cabo a rabo. La propiedad de cualquier prueba de sistema le corresponde al proveedor. Las pruebas de aceptación, en cambio, son un proceso de aceptación que a menudo se sigue para que el propietario del proyecto pueda determinar que la solución satisface sus necesidades. Por lo tanto, la propiedad de las pruebas de aceptación le corresponde definitivamente a los propietarios y patrocinadores del proyecto, quienquiera que sea que va a “aceptar” el sistema.
Es mejor si la propiedad de los diferentes tipos de pruebas queda entendida de manera explícita desde un principio. Por lo general el proveedor se va a asegurar que el sistema funcione correctamente, pero usted tiene que cerciorarse que satisfaga sus criterios de aceptación. Es importante señalar que estas pruebas pueden ser una misma, y más aún, que incluso cuando se habla de pruebas de aceptación, el proveedor debe poder ayudarle a implementar las pruebas, pues ellos saben cómo hacer que funcione el sistema. Pero, en última instancia, usted necesita recordar que se trata de su sistema y, por consiguiente, tendrá que hacer suya la responsabilidad de asegurarse que las cosas se organicen. Si comenzó bien su proyecto con una descripción adecuada de cómo se debe comportar el sistema, entonces fincó buenos cimientos para las pruebas de aceptación. Cada proveedor necesita presentar casos de prueba para la parte del sistema que les corresponde conforme a las especificaciones definidas por usted. Todos los proveedores, juntos, deben contribuir con aquellos casos que pongan a prueba el funcionamiento del sistema en su conjunto. Una persona debe ser responsable de organizar todo para conformar un paquete coherente de casos de prueba.
Le aconsejamos no poner a prueba únicamente casos positivos; esto es, hay que asegurarse que las pruebas de su sistema no se limiten a confirmar que el sistema funciona como debe ser cuando se usa de la manera en que usted espera que sea utilizado. Hablando de desarrollo de software en general, el 80% del código está dedicado a manejar situaciones de error. Si usted prueba todos los casos positivos, habrá cubierto, por consiguiente, tan sólo el 20% de su funcionalidad. Cerciórese de poner a prueba los puntos de falla y trate de determinar cómo se comporta el sistema cuando no se le utiliza debidamente. Es importante tomar en cuenta que no hay manera de anticipar todas las distintas maneras en que se abusará del sistema en la práctica.
Transición
Es importante planear el proceso de transición con la debida anticipación. Divídalo en etapas siempre que sea posible cuando se trate de un rollout complejo, y apréndase de memoria el procedimiento para revertirlo en caso necesario.
A partir del momento que comience su proyecto usted deberá estar contemplando el momento en que llegue a su término. Al principio, la transición no es más que un momento de la verdad aparentemente distante. Pero muy pronto llegará el momento en que se encuentre previendo contingencias y determinando las listas de actividades para pasar del Viejo al Nuevo Mundo. Y la verdad es que lo deseable es que no se trate de un momento de la verdad, sino más bien de una secuencia ordenada de pasos. Para ello necesita identificar todo lo que pueda implantarse de antemano e implantarlo. Cualquier software en su sistema de IVR o CRM, o en las terminales de sus agentes que pueda instalar de antemano será una cosa menos de qué preocuparse cuando llegue el momento. Entre menos cosas tenga que hacer al mismo tiempo, mejor.
Un aspecto importante de la transición consiste en garantizar que todos los sistemas prescritos estén funcionando, lo que significa que una de las últimas cosas que va usted a hacer es incorporar la configuración del sistema completo. A menudo este es el último paso antes de comenzar la transición, pero con mucha frecuencia ocurre que el equipo de proyecto no se da cuenta de que la información de configuración que necesita no se encuentra disponible en una sola fuente, y además resulta que la que está disponible muchas veces está obsoleta. Es muy importante entender qué información se necesita y recabarla con tiempo. Si además la verifica dos veces para cerciorarse que es la información más exacta y actualizada, habrá dado un paso crucial para una implementación sin sobresaltos.
La capacitación es a menudo un aspecto complicado. Es indispensable capacitar a los agentes y a los supervisores con anticipación. Hay que explicar con lujo de detalles cualquier modificación que vaya a sufrir el comportamiento de los teléfonos o las aplicaciones. Muchas veces la capacitación se aborda en forma precipitada, con lo cual los agentes sienten que son los últimos en enterarse de lo que está sucediendo y los primeros en padecer los efectos secundarios. Aproveche sus sesiones de capacitación para ganarse el entusiasmo de los agentes. Explíqueles la “imagen de conjunto”, cómo es que estos cambios son mejoras que les ayudarán a alcanzar sus objetivos (lo cual, idealmente, ¡debería ser cierto!). Recuerde que los buenos agentes utilizan sus herramientas de manera habitual y como verdaderos expertos. Si van a tener que modificar sus hábitos, hágaselos saber con antelación y explíqueles por qué.
Durante la transición en si, cualquier cosa que pueda hacerse por etapas deberá hacerse así. Por ejemplo, si puede hacer la transición de las aplicaciones número por número en su sistema de respuesta interactiva de voz, hágalo. Si puede hacer la transición de los agentes a la nueva aplicación por grupos, hágalo.
Si quita cualquier elemento del sistema, cerciórese de que sabe cómo volverlo a incorporar en caso necesario. Tenga cuidado en aquellas situaciones en las que esté reutilizando algún equipo de hardware. ¿Está instalando su nuevo servidor de CTI en la misma computadora del sistema viejo? Más le vale que sepa cómo revertir el procedimiento, por si acaso.
Y por supuesto no hay que olvidar todas las formalidades de rigor a la hora de la transición para asegurarse que todos los interesados en el negocio estén al tanto de lo que está sucediendo – qué se está cambiando y cómo puede afectar el desempeño de sus labores, tanto en el mejor como en el peor de los casos. No basta con cerciorarse de tener personal a la mano en caso de una posible falla, sino también que los supervisores estén al tanto de cualquier problema crítico al que necesiten estar atentos y que sepan a quién y cómo deben reportarlo.
La mañana siguiente
Entonces, ¿qué pasa una vez que se acaba la música? La respuesta: nunca se acaba. El ritmo cambia, pero puede estar seguro que siempre seguirá habiendo cambios. Algunas organizaciones prefieren un proceso formal de cierre de proyecto en el que todos los pendientes de proyecto se “empacan”, se palomean oficialmente las listas de comprobación, y se libera a los integrantes del proyecto. Eso suena muy bien y, si usted sabe cómo hacer que funcione (o si es congruente con la manera en que se hacen las cosas en su organización), adelante. Nosotros hemos visto, por experiencia, que algunas transiciones se dan de manera limpia y rápida, pero otras pueden llevarse algún tiempo hasta que las cosas se estabilizan. Cuando llega a haber ruido, generalmente se debe a errores de configuración de hardware (muchas veces en el PBX) que habrían resultado muy difíciles de prever y a veces resulta difícil aislar. En este caso va a necesitar que sus equipos de soporte dediquen tiempo adicional a ir depurando todas las fallas. Eso nos lleva al punto de la transición al área de soporte.
A lo largo del proyecto se trabaja en estrecha colaboración con los equipos de implementación del proveedor, los expertos en integrar la solución. En muchos sentidos, la prueba de fuego para determinar el calibre de un proveedor viene después de la implantación. Si de pronto se encuentra con que no puede comunicarse con su equipo de expertos después de la transición, está usted en aprietos. Es una exageración, pero sin duda sería muy bueno que no hubiese un cambio de guardia radical en cuanto se da la transición. Sería injusto que usted esperase que el ingeniero que implementó su solución le resolviese problemas de configuración de rutina, pero no es poco razonable esperar que esta persona esté disponible para resolver problemas que afecten el desempeño de su call center y no hayan sido debidamente atacados durante el proyecto.
Conclusión
Los proyectos de integración de call centers son complejos por naturaleza, y tradicionalmente son más difíciles que los proyectos básicos de integración de datos que por lo general enfrentan los departamentos de TI. El call center abarca una gran variedad de tecnologías que interactúan no sólo con sus principales sistemas de negocios, sino también con el activo más valioso de su empresa: sus clientes. Muchas implementaciones en este terreno no son consideradas como éxitos, pero hemos descubierto que, siguiendo algunos de los lineamientos aquí presentados, es posible lograr que las cosas funcionen, es posible integrar y optimizar el call center, y usted puede tener éxito en mejorar la atención que brinda a sus clientes sin exceder su presupuesto. Al igual que con otros proyectos en el call center, todo se reduce a contar con gente capaz de hacer el trabajo, seguir aquellos procesos que favorezcan un resultado positivo, y usar una tecnología que satisfaga sus necesidades hoy y en el futuro.
Fuente: ContactCenterWorld
lunes, junio 25, 2012
La Diferenciación: Una Estrategia de Éxito
Hace unos días leía la noticia de que el “El Corte Inglés rebaja un 20% el precio de 5.000 productos de alimentación”. La verdad es que me hizo reflexionar sobre muchas cosas; sobre los costes unitarios, el umbral de rentabilidad, margen de contribución, que un 20% es una bajada muy considerable y como repercutiría esto en la cuenta de resultados, y otras cuestiones de diversa índole. Pero sobre todo, se me vino a la cabeza: “otro más con estrategias cortoplacistas y muchas prisa por derribar la imagen forjada durante años”. Sobre todo, después de leer en el artículo, “…pero no vamos a ser una cadena low cost ni vamos a recortar nuestra oferta de marcas, sino que queremos tener la misma referencia de precios que los grandes de la distribución en alimentación como Mercadona y Carrefour". Es decir, vamos a entrar en la guerra de precios, no se nos ocurre nada más.
Imaginaros, se pueden encontrar productos con los mismos precios en ambos supermercados. Entonces, ¿Qué diferencia hay entre comprar en uno o en otro? ¿Cuál es el motivo que me llevará a elegir un supermercado concreto?
Bajar los precios es siempre una señal inequívoca de que no se ofrece nada diferente al consumidor, de que no existe diferenciación o que no se ofrecen atributos diferentes que justifiquen un mayor precio. Si hacer la compra en el súper, comprar los libros de texto, la música, y un largo etc., supone tedio, aburrimiento y una molestia, ¿por qué además tengo que pagar más por todo ello? Obviamente buscaré precio y compraré allí donde el único valor que me ofrezcan sea un ahorro considerable.
Michel Porter, autoridad global reconocida en temas de estrategia de empresa, expone que solo hay dos fuentes de ventaja competitiva; liderazgo en costes (ofrecer un producto similar a menor precio) o diferenciación (ofrecer un producto diferente, algo único valorado por los consumidores más allá del precio o a un precio superior.). Aunque ambas estrategias pueden ser exitosas, las basadas en bajos costes suelen ser menos sostenibles en el tiempo.
La cuestión siguiente es ¿todos los productos se pueden diferenciar? Según Theodore Levitt, no existe producto indiferenciable.
Las fuentes de diferenciación son múltiples. Puede ser un elemento relacionado con el producto (características, funcionalidad, diseño, etc.), con el servicio (entrega, instalación, rapidez, etc.) o con los valores emocionales de la marca (estatus, prestigio, etc.).
De todas las características que debe tener un atributo de diferenciación (comunicables, creíbles, implementables, rentables, exclusivos, nuevos y sostenibles en el tiempo) hay dos que son esenciales: que sean relevantes para el consumidor, y diferentes a los de la competencia.
Y para determinar cuáles son estos, hay que empezar por analizar la demanda, es decir, escuchar al consumidor, Conocer el motivo por el cual elige los productos que componen la cesta de su compra o porque le gusta determinada marca.
Plantearse que los consumidores solo quieren comprar al precio más bajo, no solo es erróneo (pensar por ejemplo en el Iphone, Polo, BMW, Carrier o Ben & Jerry´s, seguro que conoces mil ejemplos más), sino que es indicativo de haber perdido el contacto con el cliente. La ausencia de diferenciación es la que hace que los consumidores no estén dispuestos a pagar más por los productos. A igualdad de atributos en un producto, buscamos el precio más bajo, obviamente.
Además, la diferenciación es la base del posicionamiento de la marca ('lugar' que en la percepción mental de un cliente o consumidor tiene una marca, lo que constituye la principal diferencia que existe entre ésta y su competencia).
Seguramente en más de una ocasión te habrás encontrado con atributos que lejos de ser diferenciadores, provocaban rechazo, o cuando menos, no eran el motivo por el que los adquirías, por mucho que la marca se empeñara en resaltar determinados valores del mismo.
Y como comentábamos en el post sobre marketing experiencial, es necesaria mucha coherencia. Coherencia interna, que la empresa apueste decididamente por los atributos elegidos. Y coherencia externa, de tal manera que comuniquemos a los consumidores cuales son nuestros atributos diferenciadores para que sean percibidos por estos últimos.
La diferenciación puede hacer que una empresa domine el mercado, si es ésta la que lo crea. La gran ventaja es que el precio de estos productos, siempre que así sea transmitido a los clientes, puede ser mucho más alto, pues la cadena de valor así lo justifica. Además, se reduce la competencia, pues las otras empresas no pueden generar exactamente el mismo producto. Los clientes están dispuestos a pagar más siempre que puedan identificar el elemento diferenciador que lo justifique y este sea relevante o importante para ellos.
¿Tu porque apuestas, por bajar los precios o diferenciarte?
Hace unos días leía la noticia de que el “El Corte Inglés rebaja un 20% el precio de 5.000 productos de alimentación”. La verdad es que me hizo reflexionar sobre muchas cosas; sobre los costes unitarios, el umbral de rentabilidad, margen de contribución, que un 20% es una bajada muy considerable y como repercutiría esto en la cuenta de resultados, y otras cuestiones de diversa índole. Pero sobre todo, se me vino a la cabeza: “otro más con estrategias cortoplacistas y muchas prisa por derribar la imagen forjada durante años”. Sobre todo, después de leer en el artículo, “…pero no vamos a ser una cadena low cost ni vamos a recortar nuestra oferta de marcas, sino que queremos tener la misma referencia de precios que los grandes de la distribución en alimentación como Mercadona y Carrefour". Es decir, vamos a entrar en la guerra de precios, no se nos ocurre nada más.
Imaginaros, se pueden encontrar productos con los mismos precios en ambos supermercados. Entonces, ¿Qué diferencia hay entre comprar en uno o en otro? ¿Cuál es el motivo que me llevará a elegir un supermercado concreto?
Bajar los precios es siempre una señal inequívoca de que no se ofrece nada diferente al consumidor, de que no existe diferenciación o que no se ofrecen atributos diferentes que justifiquen un mayor precio. Si hacer la compra en el súper, comprar los libros de texto, la música, y un largo etc., supone tedio, aburrimiento y una molestia, ¿por qué además tengo que pagar más por todo ello? Obviamente buscaré precio y compraré allí donde el único valor que me ofrezcan sea un ahorro considerable.
Michel Porter, autoridad global reconocida en temas de estrategia de empresa, expone que solo hay dos fuentes de ventaja competitiva; liderazgo en costes (ofrecer un producto similar a menor precio) o diferenciación (ofrecer un producto diferente, algo único valorado por los consumidores más allá del precio o a un precio superior.). Aunque ambas estrategias pueden ser exitosas, las basadas en bajos costes suelen ser menos sostenibles en el tiempo.
La cuestión siguiente es ¿todos los productos se pueden diferenciar? Según Theodore Levitt, no existe producto indiferenciable.
Las fuentes de diferenciación son múltiples. Puede ser un elemento relacionado con el producto (características, funcionalidad, diseño, etc.), con el servicio (entrega, instalación, rapidez, etc.) o con los valores emocionales de la marca (estatus, prestigio, etc.).
De todas las características que debe tener un atributo de diferenciación (comunicables, creíbles, implementables, rentables, exclusivos, nuevos y sostenibles en el tiempo) hay dos que son esenciales: que sean relevantes para el consumidor, y diferentes a los de la competencia.
Y para determinar cuáles son estos, hay que empezar por analizar la demanda, es decir, escuchar al consumidor, Conocer el motivo por el cual elige los productos que componen la cesta de su compra o porque le gusta determinada marca.
Plantearse que los consumidores solo quieren comprar al precio más bajo, no solo es erróneo (pensar por ejemplo en el Iphone, Polo, BMW, Carrier o Ben & Jerry´s, seguro que conoces mil ejemplos más), sino que es indicativo de haber perdido el contacto con el cliente. La ausencia de diferenciación es la que hace que los consumidores no estén dispuestos a pagar más por los productos. A igualdad de atributos en un producto, buscamos el precio más bajo, obviamente.
Además, la diferenciación es la base del posicionamiento de la marca ('lugar' que en la percepción mental de un cliente o consumidor tiene una marca, lo que constituye la principal diferencia que existe entre ésta y su competencia).
Seguramente en más de una ocasión te habrás encontrado con atributos que lejos de ser diferenciadores, provocaban rechazo, o cuando menos, no eran el motivo por el que los adquirías, por mucho que la marca se empeñara en resaltar determinados valores del mismo.
Y como comentábamos en el post sobre marketing experiencial, es necesaria mucha coherencia. Coherencia interna, que la empresa apueste decididamente por los atributos elegidos. Y coherencia externa, de tal manera que comuniquemos a los consumidores cuales son nuestros atributos diferenciadores para que sean percibidos por estos últimos.
La diferenciación puede hacer que una empresa domine el mercado, si es ésta la que lo crea. La gran ventaja es que el precio de estos productos, siempre que así sea transmitido a los clientes, puede ser mucho más alto, pues la cadena de valor así lo justifica. Además, se reduce la competencia, pues las otras empresas no pueden generar exactamente el mismo producto. Los clientes están dispuestos a pagar más siempre que puedan identificar el elemento diferenciador que lo justifique y este sea relevante o importante para ellos.
¿Tu porque apuestas, por bajar los precios o diferenciarte?
viernes, junio 22, 2012
“XI Congreso Regional de CRM y Contact Centers”
Bajo el lema “Hacia la Interacción Efectiva con los Clientes”, se llevará a cabo en Buenos Aires, entre los días 27 y 28 de junio, la onceava edición del Congreso Regional de Contact Centers y CRM, auspiciada por la Agrupación de Centros de Atención al Cliente.
Contará con la presencia de destacados disertantes de orden local e internacional, que abordarán las nuevas tendencias y metodologías de trabajo, el update en procesos y estrategia, la innovación tecnológica y los desafíos por venir. También se tratará la incidencia de las redes sociales, la función del Community Manager y las interacciones entre telefonía, e-mail, chat, Twitter y Facebook; en este contexto, se ahondará en la integración de una estrategia de Crowdsourcing (recolección de ideas a través de redes, portales y comunidades).
La Agrupación de Centros de Contacto de la Cámara Argentina de Comercio integra el Comité Académico de este Congreso y, además, será auspiciante institucional del evento.
La organización prevé sesiones y foros simultáneos para permitir al auditorio no sólo actualizarse sino también debatir sobre los nuevos paradigmas en la gestión del negocio, al tiempo que se expondrán los casos regionales de éxito. Durante el desarrollo de este congreso internacional, habrá conferencias plenarias con calificados speakers como Clint Oran (EEUU), María Eugenia García (México), Vilmor Grube (Brasil), Juan Manuel Llano Uribe y Ana Quessep (Colombia), y Juan González e Ignacio González Ferro (Argentina).
“Esta es una excelente oportunidad de actualización tecnológica y de know how pues se compartirán los casos de éxito más resonantes de la región”, afirmó Juan Pablo Tricarico, Presidente del Comité Académico. “Es el ámbito ideal para que clientes, empresarios y sponsors tecnológicos debatan y reflexionen desde el punto de vista técnico e industrial sobre el desarrollo sustentable de la actividad”, agregó.
Bajo el lema “Hacia la Interacción Efectiva con los Clientes”, se llevará a cabo en Buenos Aires, entre los días 27 y 28 de junio, la onceava edición del Congreso Regional de Contact Centers y CRM, auspiciada por la Agrupación de Centros de Atención al Cliente.
Contará con la presencia de destacados disertantes de orden local e internacional, que abordarán las nuevas tendencias y metodologías de trabajo, el update en procesos y estrategia, la innovación tecnológica y los desafíos por venir. También se tratará la incidencia de las redes sociales, la función del Community Manager y las interacciones entre telefonía, e-mail, chat, Twitter y Facebook; en este contexto, se ahondará en la integración de una estrategia de Crowdsourcing (recolección de ideas a través de redes, portales y comunidades).
La Agrupación de Centros de Contacto de la Cámara Argentina de Comercio integra el Comité Académico de este Congreso y, además, será auspiciante institucional del evento.
La organización prevé sesiones y foros simultáneos para permitir al auditorio no sólo actualizarse sino también debatir sobre los nuevos paradigmas en la gestión del negocio, al tiempo que se expondrán los casos regionales de éxito. Durante el desarrollo de este congreso internacional, habrá conferencias plenarias con calificados speakers como Clint Oran (EEUU), María Eugenia García (México), Vilmor Grube (Brasil), Juan Manuel Llano Uribe y Ana Quessep (Colombia), y Juan González e Ignacio González Ferro (Argentina).
“Esta es una excelente oportunidad de actualización tecnológica y de know how pues se compartirán los casos de éxito más resonantes de la región”, afirmó Juan Pablo Tricarico, Presidente del Comité Académico. “Es el ámbito ideal para que clientes, empresarios y sponsors tecnológicos debatan y reflexionen desde el punto de vista técnico e industrial sobre el desarrollo sustentable de la actividad”, agregó.
domingo, junio 17, 2012
LaMezcla de Mercadotecnia
La mezcla de mercadotecnia (en inglés: Marketing Mix) forma parte de un nivel táctico de la mercadotecnia, en el cual, las estrategias se transforman en programas concretos para que una empresa pueda llegar al mercado 1) con un producto satisfactor de necesidades y/o deseos, 2) a un precio conveniente, 3) con un mensaje apropiado que se transmite mediante canales de comunicación adecuados y 4) un sistema de distribución que coloque el producto en el lugar correcto y en el momento mas oportuno.
Por todo ello, es indispensable que los mercadólogos conozcan qué es la mezcla de mercadotecnia y cuáles son las herramientas o variables (más conocidas como las 4 P`s) que la conforman.
¿Qué es la Mezcla de Mercadotecnia o Marketing Mix?:
Kotler y Armstrong, definen la mezcla de mercadotecnia como "el conjunto de herramientas tácticas controlables de mercadotecnia que la empresa combina para producir una respuesta deseada en el mercado meta. La mezcla de mercadotecnia incluye todo lo que la empresa puede hacer para influir en la demanda de su producto" [1].
Por su parte, el "Diccionario de Términos de Marketing" de la American Marketing Asociation, define a la mezcla de mercadotecnia como aquellas "variables controlables que una empresa utiliza para alcanzar el nivel deseado de ventas en el mercado meta" [2].
En síntesis, la mezcla de mercadotecnia es un conjunto de variables o herramientas controlables que se combinan para lograr un determinado resultado en el mercado meta, como influir positivamente en la demanda, generar ventas, entre otros.
¿Cuáles son las Herramientas o Variables de la Mezcla de Mercadotecnia?:
A mediados de la década de los '60, el Dr. Jerome McCarthy (premio Trailblazer de la American Marketing Asociation) introdujo el concepto de las 4 P's, que hoy por hoy, se constituye en la clasificación más utilizada para estructurar las herramientas o variables de la mezcla de mercadotecnia.
Las 4 P's consisten en: Producto, Precio, Plaza (distribución) y Promoción
Producto: Es el conjunto de atributos tangibles o intangibles que la empresa ofrece al mercado meta.
Un producto puede ser un bien tangible (p. ej.: un auto), intangible (p. ej.: un servicio de limpieza a domicilio), una idea (p. ej.: la propuesta de un partido político), una persona (p. ej.: un candidato a presidente) o un lugar (p. ej.: una reserva forestal).
El "producto", tiene a su vez, su propia mezcla o mix de variables [1]:
- Variedad - Calidad - Diseño - Características - Marca - Envase - Servicios - Garantías
Precio: Se entiende como la cantidad de dinero que los clientes tienen que pagar por un determinado producto o servicio.
El precio representa la única variable de la mezcla de mercadotecnia que genera ingresos para la empresa, el resto de las variables generan egresos.
Sus variables son las siguientes [1]:
- Precio de lista - Descuentos - Complementos - Periodo de pago - Condiciones de crédito
Plaza: También conocida como Posición o Distribución, incluye todas aquellas actividades de la empresa que ponen el producto a disposición del mercado meta. Sus variables son las siguientes [1]:
- Canales - Cobertura - Surtido - Ubicaciones - Inventario - Transporte - Logística
Promoción: Abarca una serie de actividades cuyo objetivo es: informar, persuadir y recordar las características, ventajas y beneficios del producto. Sus variables son las siguientes [1]:
- Publicidad - Venta Personal - Promoción de Ventas - Relaciones Públicas - Telemercadeo - Propaganda
martes, junio 12, 2012
La nueva era del brand marketing empieza por entender las relaciones familiares
El futuro del comercio, la cultura, las creencias y el carácter y la economía depende del poder de las relaciones de parentesco, y el auge de las redes sociales no ha hecho más que evidenciar esta tendencia y hacer que las marcas estén alerta. Y, aunque resulte llamativo que una de las tendencias más revolucionarias de la actualidad se asiente sobre uno de los instintos humanos más profundos, la importancia de las conexiones personales y las relaciones están marcando los pasos básicos que las marcas van a tener que emular.
Pero para las marcas hay un aspecto clave que tienen que entender y radica en que las personas quieren conexiones con otras personas, pero no con marcas. Y si las marcas quieren acercarse a sus posibles consumidores, tendrán que facilitar relaciones personales y no profundizar en relaciones de marca.
La gente seguirá adoptando marcas como siempre. Pero para hacerlo las marcas tendrán que ser reivindicadas como parte de la familia y sólo los consumidores tienen el poder de hacer esto. Si no es así, las marcas seguirán siendo unos extraños irrelevantes en la intimidad implícita que se establece en las relaciones, haciendo que la retención, la fidelidad y las recomendaciones sean menos propensas y costosas.
El reto ante este escenario parte de que los consumidores están mucho más centrados en relacionarse con otras personas y no interesados en relacionarse con marcas, por lo que hacer que los consumidores dejen entrar a las marcas no puede hacerse de forma directa, sino a través de estrategias indirectas. Y es en este punto donde muchas marcas han tenido problemas con las redes sociales. Ya no sirve hacer un concierto en solitario, sino que las marcas tienen que convertirse en la música de fondo que acompañe a la gente mientras se relacionan entre sí. Si lo hace bien, la gente querrá tener a la marca cerca cuando se conecten, pero si la marca interrumpe, sólo querrán deshacerse de ella.
Por otro lado, las relaciones familiares implican intimidad. Los miembros de una familia comparten los momentos más privados y si una marca quiere formar parte de ello, tendrá que estar dispuesta a abrirse igual que quiere que lo hagan los consumidores. Es decir, ser totalmente transparentes en cuanto a intenciones, operaciones y responsabilidades.
Por último, las marcas no deben olvidar que una buena relación familiar también implica altruismo, sacrificarse y esforzarse los unos por los otros. Las marcas tienen que interiorizar esta actitud, poniendo el estilo de vida y los intereses personales de sus consumidores por delante de sus intereses transaccionales y comerciales. Los consumidores esperan de una marca algo más que pagar por sus productos, quieren relaciones, no comerciar, y eso implica una nueva dinámica que convierta las relaciones en el centro de todas las estrategias.
Una campaña reivindica el valor de los medios impresos como herramienta de marketing
09 Febrero 2012
.
Print Power es una iniciativa paneuropea que tiene como objetivo aumentar el porcentaje de los presupuestos de marketing que los anunciantes dedican al medio impreso.
Para difundir su mensaje han creado una campaña de banners y anuncios impresos en los que defienden que las ventas en publicidad se mantengan en revistas y periódicos, que se utilice el correo directo, que se sigan imprimiendo catálogos… es decir, una defensa del medio impreso como una herramienta eficaz y de gran utilidad para la comunicación comercial.
Entre sus mensajes destacan “Lo único que estás mirando ahora soy yo”, “Yo soy un aliado muy persuasivo” y “Yo soy una llamada a la acción realmente eficaz!”. Además las gráficas incluyen códigos BIDI que invitan al lector a unirse a la iniciativa.
Los socios fundadores de esta iniciativa son los fabricantes de papel (representados tanto por Cepifine como por Cepiprint), los comerciantes de papel (representados por Eugropa) y los impresores (representados por Intergraf).
Suscribirse a:
Entradas (Atom)