Software CRM: respuestas ágiles cuando el desarrollo de sistemas está externalizado

Imagen metodologías ágiles 300x82 Software CRM: respuestas ágiles cuando el desarrollo de sistemas está externalizado

Metodologías ágiles a favor del proyecto común

Desde hace años las metodologías ágiles han permitido a muchas empresas reaccionar a los cambios, modificando sus sistemas de información a un ritmo adecuado a sus necesidades ( http://es.wikipedia.org/wiki/Desarrollo_%C3%A1gil_de_software ).  A modo de resumen, el concepto de “Metodologías Ágiles” supone el desarrollo de iteraciones cortas e independientes, con objetivos alcanzables, que constituyan funcionalidades básicas dentro de una lista de funcionalidades del proyecto. Este modelo se basa en los principios del “Manifiesto Ágil” (ver manifiesto en: http://agilemanifesto.org/iso/es/).

En la actualidad, disponemos de herramientas que permiten cambiar los sistemas de forma flexible.  Google, entre muchas otras cosas, es capaz de hacer una carga a “google docs” mientras el usuario utiliza el programa.

El avance es mucho más moderado cuando hablamos de los cambios organizacionales. Uno de los casos más complejos y frecuentes es el de la subcontratación de servicios de tecnología que implican desarrollos de software ( CRM, ERP, BI…). Los desarrolladores externos, en su esfuerzo por maximizar el resultado del proyecto y el bien del negocio, se ponen al servicio del cliente aceptando los cambios en cualquier etapa del proyecto.

El primer reto que se presenta es lo que en economía se ha llamado problema de la relación de agencia: las dos partes tienen que tomar medidas especiales para asegurar que no se deterioran las condiciones para ninguna de ellas.

La subcontratación típica requerirá como mínimo un contrato y un documento de requisitos.  De acuerdo a las experiencias pasadas del cliente y de la empresa contratada, es posible que se alteren los niveles de aprobación y se incluyan en los mismos a: arquitectos de sistemas,  departamento legal, contabilidad, auditores y responsables financieros.  Si añadimos a éstos, los respectivos departamentos de compras y ventas tendremos muchas reuniones de trabajo costosas.

Ese “sobrecoste” (en tiempo y dinero) introduce retrasos que impiden a las empresas reaccionar a tiempo a los cambios que pide el mercado. Una buena forma de medir este desgaste es preguntarse:

  • ¿Cuánto tiempo y cuánto dinero me costaría cambiar una regla de negocio mínima de mis sistemas informáticos externalizados?
  • ¿Cómo se desglosa ese coste?
  • ¿Cuánto tiempo tardo desde que detecto una necesidad hasta que se firma el proyecto y tengo la funcionalidad requerida en marcha?
  • ¿Los requisitos del proyecto salen estables de ese proceso o suelen sufrir cambios?
  • ¿Cuánto tardaría el proveedor en conseguir respuesta a una inquietud simple? Ejemplo: si un programador necesita saber las especificaciones de diseño de un texto, en cuánto tiempo obtiene su respuesta?
  • ¿Todos los niveles del procedimiento aportan valor? ¿cuál es?

Otro reto importante cuando hablamos de la externalización de servicios, es que a veces el propio cliente dificulta que las empresas a las que contrata puedan seguir los principios y buenas prácticas de las metodologías ágiles.

Algunos aspectos que dependen del cliente son:

  • Definir espacios físicos en los cuales los responsables de negocio y los consultores trabajen en conjunto.
  • Disponer de mecanismos que faciliten la comunicación “cara a cara” entre consultores y responsables de negocio.
  • Establecer mecanismos de retroalimentación periódica sobre las funcionalidades terminadas que se reciben, y la facilidad de adaptación al trabajo diario.

Éstas son prácticas que contribuyen al éxito de los proyectos, y a la maximización del uso de los recursos propios y subcontratados. El reconocimiento de las diferencias culturales y la definición de puntos de integración y comunicación también facilitarán el logro de los objetivos planteados.

Ante estas dos situaciones, el responsable de la contratación debe plantearse las ventajas e inconvenientes según sus propias necesidades. En un mercado cambiante o en proyectos con requisitos ambiguos el tiempo de reacción es crítico. El principio por el que una empresa de nueva constitución puede vencer a una empresa que cotiza en bolsa no es muy diferente. Incluso en sectores tradicionalmente más estables como la banca y los seguros: surgen competidores, cambia el marco jurídico y el entorno.

¿Cuánto tardaremos en actuar cuando lo necesitemos?

¿Soluciones?

Mi lado consultor no puede evitar intentar solucionar un problema. Aún a falta de estudios con los que probar todas las afirmaciones, creo poder dar algunas pinceladas que nuestros lectores sabrán enriquecer o matizar:

  • Crear varias vías para subcontratar proyectos:  no podemos tratar igual un proyecto de 1000 que de 100.000 horas. Tampoco cambian igual los requisitos de un proyecto de I+D que la repetición de uno anterior en otro sistema.
  • Construir relaciones de confianza con los proveedores: esto  permite contratar sin tener los requisitos cerrados al 100%. En realidad, si el cliente tiene que iniciar un procedimiento legal no será porque el proyecto sea un éxito.
  • Documentar y comunicar: si el proceso de contratación y/o cambio de requisitos es complejo ayudará que esté bien documentado y que se informe a los interesados de los cambios, apenas estos se visualicen.
  • Construir equipos de trabajos experimentados y calificados de acuerdo a su función: en caso de duda forme el equipo de trabajo con menos trabajadores pero con experiencia verificable. Se reducen los posibles caminos de comunicación y la información fluye de forma efectiva desde el principio. Como beneficio adicional, un consultor experimentado para las labores que así lo requieren, puede tener un gran impacto en la productividad y en el éxito del proyecto.
  • Utilizar las bondades de la tecnología para facilitar el flujo de la información y la comunicación entre los participantes:  usar un software de gestión de requisitos de forma compartida entre el cliente y el proveedor podría ayudar a generar rápidamente documentos y rastrear las implicaciones para las partes y los sistemas (considerar la modalidad Saas).
  • Construir sistemas flexibles, diseñados para cambiar: centrarse en hacer flexibles los sistemas de cara al exterior. La web, intranet, centralitas telefónicas,  comunicaciones por carta, e-mail o sms son buenos candidatos. Por supuesto un buen CRM  puede permitir adelantarse a los cambios sin olvidar el efecto que tiene sobre los proveedores.

Finalmente, si clientes y consultores unieran sus fuerzas crearían más valor, finalizarían los proyectos antes y las soluciones terminadas estarían más ajustadas a las necesidades presentes y futuras.

Obtener logros y reconocimientos para todo el equipo interno y externo es posible y también necesario.

Software CRM: usabilidad vs funcionalidad

Foto Charles 150x150 Software CRM: usabilidad vs funcionalidad

Charles Leonard /Director Consuloria & Finanzas

Centrarnos en la funcionalidad de un software es insuficiente. Debemos también medir su usabilidad.

Cuando decidimos sobre cuál es el mejor sistema para nuestra organización, otorgamos mucho valor a la funcionalidad: lo que hace el producto. Establecemos, por un lado una lista de funciones de negocio y por otro, listas de capacidades para cada producto evaluado. Dentro de los límites presupuestarios que nos hemos establecido, seleccionamos el producto con las capacidades que mejor solapen las funciones de negocio.

Esto pudo haber sido suficiente en el pasado, cuando la mayoría de los sistemas atendían procesos internos de la organización, cuando el tiempo se medía en meses y cuando los usuarios usaban la tecnología principalmente en sus horas laborables. Actualmente este enfoque es insuficiente y pone en riesgo los proyectos tecnológicos, especialmente los que implican soluciones CRM.

La evolución del mercado ha forzado a las organizaciones a gestionar el entorno que les rodea: clientes, colaboradores y competidores. El tiempo se mide en segundos y los usuarios son expertos en tecnologías para acceder a múltiples fuentes de información.

Entre las principales características que debe tener un sistema para que sea capaz de ofrecer una solución real: “fácil de usar”, “intuitivo”, “para usuarios internos y externos a la organización”, “con el menor número de clicks” por función”. Todo esto es usabilidad. La usabilidad es lo que describe la experiencia del usuario al manejar el sistema. Si la funcionalidad describe el “qué”, la usabilidad describe el “cómo”.

El meteórico éxito del iPhone es un buen ejemplo de la importancia de la usabilidad. En sus inicios, a pesar de tener menos funcionalidad que otras plataformas comparables, era superior a sus competidores en usabilidad: era más fácil hacer lo que se quería hacer. Fue descalificado como un “juguete” pero muchos encontraron que aún en el ámbito de negocios era una herramienta más efectiva que otras teóricamente más completas.

La usabilidad no es tan fácil de describir como la funcionalidad. Tampoco es fácil de medir. Incluirla en un proceso de evaluación requiere “desprenderse del papel”. Será necesario simular las actividades más comunes de los usuarios y encontrar el producto que nos ofrezca el camino más eficiente para realizar dichas actividades.

Modificar nuestro proceso de evaluación para valorar correctamente la usabilidad tiene un coste, pero se nos retornará con creces en beneficios, eficiencia y productividad