Según The Standish Group en EE. UU. Y Europa para 2015:
- El 31,1% de todos los proyectos de TI se detienen y no se completan;
- El 52.7% de todos los proyectos de TI se completaron con una fecha límite, un aumento significativo en el presupuesto planificado originalmente o un cambio radical en las metas originalmente planificadas;
- solo el 16.2% de todos los proyectos de TI cumplieron con las expectativas.
Total:
83.8% (en realidad 8 de 10) fallas versus 16.2% de éxito.
En los últimos 10 años, estos números no han cambiado: al implementar sistemas de TI, una empresa enfrenta problemas típicos que se pueden agrupar de la siguiente manera:
- Dificultades y problemas organizacionales.
- Errores en la planificación y administración del proyecto de implementación (presupuesto, plazos y otros errores asociados con el enfoque del proyecto).
- Problemas relacionados con la infraestructura y las herramientas de trabajo (incluidas las prácticas y los sistemas que deberían ayudar a la implementación).
¿Y qué conduce a fallas en la implementación de Service Desk y otros sistemas en Rusia?
Estamos desarrollando un
sistema de mesa de ayuda para automatizar todos los procesos de servicio postventa en empresas de servicios . Después de hablar con más de 5,000 representantes de una amplia variedad de sectores de servicios (empresas medianas y pequeñas), decidimos compartir las razones de las implementaciones fallidas de Service Desk en Rusia / CIS y los métodos para superar la mayoría de las dificultades. De hecho, los problemas resultaron ser "universales" para la implementación de cualquier sistema de TI y proyectos de TI.
Estamos seguros de que esto le permitirá prepararse y evitar al menos algunos de ellos.
Implementación de Service Desk. Realidades rusas
La comunicación con más de 5000 empresas de servicios que operan en el segmento b2b en Rusia y los países de la CEI no proporciona estadísticas precisas sobre los proyectos, pero nos permite identificar grupos similares de problemas (no sin detalles locales). A continuación, consideramos cada elemento con más detalle, centrándonos en los "representantes" más populares de fallas. Cabe señalar que la clasificación de los problemas utilizados es condicional y se selecciona solo por conveniencia de presentación. Los grupos seleccionados se cruzan entre sí. Por ejemplo, el miedo al cambio está inextricablemente vinculado a problemas de organización, etc.
Bala de plata
"El sistema de Service Desk en sí resolverá todos los problemas"
Muchos realmente creen que un sistema de automatización resolverá todos los problemas. En los procesos actuales de la mayoría de las empresas de servicios, reina el caos, y parece que la introducción de
Service Desk o CRM le permitirá tener un control total sobre la situación de las ventas o el soporte al cliente.
Este es un gran error. Hay un dicho bien conocido:
"Si su empresa tiene caos, entonces el resultado de la introducción de un sistema de automatización será un caos automatizado" .
Ninguna herramienta puede resolver problemas internos apremiantes. El efecto de introducir Service Desk en empresas con baja madurez tendrá indudablemente un efecto grave (por ejemplo, eliminará la pérdida de aplicaciones,
reducirá el retraso de SLA , etc.). Pero la finalización exitosa del proyecto con resultados comprensibles y medibles, que pueden desarrollarse aún más, es casi imposible en el caso general sin cambiar el componente organizacional.
"Tire" de nuestros requisitos
Este problema es característico de un negocio más grande y más burocrático.
Como regla general, los procesos en tales compañías se han desarrollado durante mucho tiempo; se está formando algún tipo de esquema de gestión. Encima de este sistema hay una automatización de "patchwork": Service Desk en algunas áreas específicas, diferentes CRM en diferentes departamentos, etc. Pero la empresa quiere obtener un único sistema centralizado y automatizado, que vincule todos los procesos entre sí. El error es que, al mismo tiempo, no quiere adaptarse a los sistemas existentes y las mejores prácticas de acuerdo con las cuales se desarrollan, tratando de "atraer" el producto seleccionado a sus necesidades. Y hacer esto es extremadamente difícil.
Para lograr el resultado, junto con el proyecto de implementación, tendrá que cambiar los enfoques de trabajo, llevar a cabo cambios organizativos e incluso deshacerse de algunas personas o, por el contrario, introducir nuevos roles en el estado. Y todo esto debe hacerse razonablemente, entendiendo qué indicadores se requieren para lograrlo.
Implementar la mesa de servicio. Miedo al cambio
"Nuestros clientes no están tan acostumbrados".
Las compañías de servicios realmente consideran algo como esto:
"No funcionará porque nuestros clientes no están acostumbrados".
Ni siquiera están listos para tratar de cambiar el esquema de trabajo existente, por ejemplo, proponiendo mecanismos de prueba nuevos, más simples y más convenientes para varios de sus clientes. Desde el principio, tienen la confianza de que los clientes rechazarán todo lo nuevo. Esto significa que no tiene sentido lanzar un proyecto, o, por el contrario, un proyecto lanzado no finaliza.
"Reorganización requerida"
Este problema está asociado en gran medida con la introducción de sistemas de mesa de servicio debido a la complejidad comparativa de los procesos de soporte. El rechazo de proyectos está asociado con el temor a la reorganización. Pero a menudo, tales cambios benefician al negocio. Pueden basarse en las "mejores prácticas y bibliotecas" en las que se agregan:
ITIL, o el enfoque para organizar la gestión de servicios de ITSM , pero las pequeñas y medianas empresas, por supuesto, se niegan a usar estas "mejores" prácticas.
Un gran ejemplo es una empresa de servicios, donde el servicio ya no lo realizan 2-3, sino 10 o más personas. En tal escala, en primer lugar, ya hay un gran flujo de aplicaciones y, en segundo lugar, hay una gradación clara de personas en términos de competencias y pagos. La reorganización del servicio de soporte implica la asignación de la primera, segunda, tercera línea, un cambio en la interacción con los contratistas y mucho más.
Sin tener en cuenta la reorganización, las empresas tienen miedo de lanzar proyectos para introducir sistemas de mesa de servicio o los están introduciendo, pero no obtienen el resultado deseado (automatizar el caos).
"Los costos en tiempo real aumentarán"
Las empresas posponen la implementación de herramientas cuando se dan cuenta de que los costos en tiempo real de los empleados cuando trabajan con el nuevo sistema de mesa de servicio están creciendo. Y esto es cierto!
Al principio, realmente tienes que pasar más tiempo. Por ejemplo, tendrá que registrar el 100% de las solicitudes, marcar las acciones realizadas durante su procesamiento, cancelar los costos laborales, etc. Pero los puntos de ineficiencia no se pueden identificar sin fijar actividades y seguir métricas sobre ellos. Y por lo tanto, antes de comenzar el proyecto, solo tiene que responder a su pregunta "¿Qué queremos como resultado de la implementación de la mesa de servicio?"
Familiaridad: "Los colegas serán infelices"
En los negocios rusos, las relaciones de "familiaridad" son muy comunes. Y cuanto más "hogareña" es una empresa, más compleja es. Esto es especialmente pronunciado en empresas en la periferia, en el negocio de 10 a 20 personas que han estado trabajando juntas durante mucho tiempo.
El cronismo plantea preguntas morales difíciles cuando se requieren cambios o despidos de quienes trabajan mal. A menudo, en tales situaciones, el proyecto se suspende y la nueva herramienta no se utiliza, porque dentro de la empresa hay descontento o una pregunta sin respuesta: "¿Cómo es eso?"
En tal situación, tendrá que priorizar. Si el amiguismo es más importante, entonces no tiene sentido pensar en el desempeño comercial y las actividades en las que su empresa se dedica a llamar a los negocios en principio. Y aún más, introduce herramientas que revelen cuellos de botella. Pero si necesita resultados, tiene que ser duro. La implementación de la Mesa de Servicio solo permitirá tomar decisiones objetivas e informadas en materia de soporte de servicio y servicio al cliente postventa.
Errores organizativos y dificultades en la implementación de Service Desk
Resistencia interna
A los empleados de las empresas no les gustan los cambios en la forma de vida existente. Por ejemplo, el despachador se sentó y, en una revista en un bolígrafo, a la antigua usanza, escribió todas las apelaciones de los residentes de la casa sobre la inoperancia del ascensor, bebió té con calma. Y aquí se ve obligado a arreglar algo en un sistema incomprensible. Naturalmente, se resiste.
El problema también está relacionado con la edad. Cuanto más viejo es el equipo, más difícil es adoptar un formato de trabajo nuevo y cambiante.
No existe un interés real en la gerencia / tomadores de decisiones (tomadores de decisiones)
En gran medida, esto es cierto para las medianas y pequeñas empresas. Los líderes de tales compañías se ven obligados a ser "multi-trabajadores". Venden, brindan atención al cliente y resuelven problemas burocráticos. Y cuando no tienen ningún interés real en el proyecto, no termina con nada bueno.
Cualquier proyecto necesita un "controlador". Él puede "venir" de la alta gerencia, la mejor opción. De lo contrario, el gerente intermedio o la persona responsable de la unidad de proceso dentro de la empresa tendrá que "venderla" dentro y ser responsable del resultado.
Falta o problemas con el enfoque de diseño
No hay equipo dedicado y gerente de proyecto
Cuando las empresas no asignan a las personas responsables del resultado de la introducción del sistema de mesa de servicio, no sucede nada.
Si el proyecto es pequeño y hay pocas personas en la empresa, no se necesita un equipo dedicado. Pero debe haber un gerente de proyecto con autoridad. Está obligado a dirigir el proyecto hasta su punto final, siendo responsable de los presupuestos y las personas, teniendo la oportunidad de aplicar influencias organizacionales o esquemas motivacionales.
Por cierto, es necesario no solo distinguir a las personas con poderes y responsabilidades claras, sino al menos parcialmente eliminar de ellas simultáneamente actividades en otras áreas.
No hay tiempo disponible para los afectados.
A menudo, la compañía tiene un equipo de proyecto dedicado e incluso su líder, pero no hay tiempo para aquellos que se verán afectados por la implementación del sistema de mesa de servicio. Por ejemplo, ingenieros, ejecutando aplicaciones o programadores (si los incluimos en el proceso de soporte en forma de una tercera línea). Cuando no se asigna su tiempo y, lo más importante, las personas no tienen motivación y no entienden por qué esto es necesario, el proyecto se basa en la resistencia interna y el "sabotaje".
No hay requisitos reales y casos de uso (alcance del proyecto)
Tales problemas a menudo se encuentran en Occidente: al principio no hay requisitos claros ni para el sistema de mesa de servicio ni para los resultados del proyecto. Esto lleva, entre otras cosas, a un proceso interminable de toma de decisiones. Dichos clientes desean automatizar absolutamente todo: ajustar el sistema a sus requisitos (más sobre esto más arriba), o los requisitos del sistema cambian constantemente.
Finalmente, los proyectos abandonan sin comenzar: prueban 20 sistemas varias veces y se dan cuenta de que ninguno es adecuado. Peor aún, si se lanzó el proyecto, se determinaron algunos plazos y plazos presupuestarios, y luego los requisitos se "extendieron", lo que conduce a una interrupción significativa en el plazo y a costos internos "inflados". En cierta etapa, se hace más fácil abandonarlo.
Sin "impacto" (Verificar - Actuar)
Muchas empresas, habiendo obtenido resultados primarios (a veces muy buenos, especialmente si nada se había automatizado antes), dejan de mejorar el sistema y los procesos para los que se pretende automatizar. Dejan de controlar los indicadores y, lo más importante, de dar seguimiento a los resultados de este control.
Cualquier proyecto se asemeja a una "espiral". Hay un llamado ciclo de Deming - Plan -> Hacer -> Verificar -> Actuar. Si hablamos de Service Desk, una de las tareas típicas de implementar dicho sistema es reducir el retraso en el SLA. Pero después del comienzo del trabajo, muchas empresas, en principio, no usan informes. Y algunos de los que todavía lo usan no planean cambios posteriores en sus procesos, lo que les permite lograr indicadores de alguna manera mejores. Sin esto, la satisfacción final no se puede obtener del proyecto.
La historia de "calidad / rápido / gratis"
Hasta ahora, muchas, especialmente las pequeñas empresas, creen que puedes encontrar un sistema o personas que puedan hacer todo de forma rápida, eficiente y prácticamente gratis. En presencia de esta esperanza, el proyecto termina en nada: resulta durante mucho tiempo, no muy caro y de mala calidad.
El deseo del cliente de desarrollar su propio sistema de Service Desk también está relacionado con esta categoría de problemas (por qué no necesitábamos hacerlo, escribimos en detalle en nuestro artículo). Si la empresa tiene la oportunidad de asignar 2-3 programadores, por ejemplo, durante seis meses, un año, entonces su negocio es muy malo, el negocio no está enfocado en lo que debería hacer. En aquellas áreas que no son clave para los negocios, es mejor atraer personas o usar sistemas "desde afuera", en lugar de reinventar su bicicleta.
Implementación de Service Desk. ¿Cómo evitar errores?
Aquí hay algunas recomendaciones universales que le permitirán ahorrar tiempo en la etapa de lanzamiento de un proyecto e implementación de un sistema de Service Desk:
- La empresa debe tener un "controlador" para el proyecto de implementación del sistema . Al mismo tiempo , debe tener la autoridad para tomar decisiones , incluidas las impopulares, y todos los participantes del proyecto y aquellos que se verán afectados por el sistema después del lanzamiento deben conocer estos poderes.
- Es necesario definir objetivos y requisitos de registro (para el sistema, proyecto, resultados). Antes de comenzar a buscar un sistema de mesa de servicio, debe definir objetivos, ya que, en su ausencia, esta epopeya puede no terminar en nada.
- Presupuesto / tiempo / equipo debe destacarse . Todos estos recursos obviamente dependen de los requisitos. No debe haber ilusiones: el deseo de ajustar el sistema a los requisitos individuales dará lugar a altos costos (una demanda por encargo siempre es más costosa). El alcance del proyecto también determina el tiempo que deben asignar los conductores y los participantes del proyecto, así como todas las personas que se verán afectadas por el uso del sistema.
- No hay que tener miedo a los cambios y lo "nuevo" . Los cambios se pueden probar en partes de clientes o usuarios, por ejemplo, en varios clientes. Sí, tendrá que pasar más tiempo reorganizando la estructura, especialmente después de identificar los focos de ineficiencia. Es difícil y a veces doloroso, especialmente considerando el amiguismo. Pero esto es necesario si nos centramos en la efectividad de la organización y el negocio en sí.
- Superar persistentemente la resistencia: el derecho a "vender" . Los sistemas de mesa de servicio están diseñados no solo para controlar el trabajo, sino también para construir relaciones transparentes con los clientes. Los empleados, incluso los mayores, entienden este y otros argumentos razonables.
- Concéntrese en su negocio principal . Cuando las empresas deciden inventar su propia bicicleta en medio año o un año, desarrollan CRM, Helpdesk, etc. - Casi siempre termina en fracaso. Pero lo principal es un indicador de cuán ineficaz es su negocio actualmente.
- Deja de creer en los cuentos de hadas sobre "gratis, barato y de alta calidad" . Sí mismo no "vuela". El principal problema de implementar todos los sistemas es precisamente las dificultades organizativas y los cambios que deberán llevarse a cabo, de lo contrario el sistema, aunque traerá resultados, pero no será exactamente el que podría obtenerse.
Nota publicada en base al material del
blog de Okdesk