Reflexiones y apuntes sobre arquitectura, consultoría y gestión proyectos CRM

¿Qúe incluye la auditoría de un sistema CRM?

¿Qué debo revisar en mi sistema CRM para asegurar un buen estado de ‘salud’? ¿Contra qué métricas debo contrastarlo para asegurar que no se va degradando con el uso?

¿Cómo debo auditor mi sistema CRM?

Audit

Audit

Este artículo no habla de la característica de Dynamics CRM que permite auditar quién y cuándo modifica qué datos. Ni tampoco de la consultoría requerida para asesorar la estrategia y la adecuación de las políticas ‘CRM’ de una organización dada.

Este artículo habla de la auditoría técnica y funcional de un sistema Dynamics CRM en producción que permite garantizar que dicho sistema va a perdurar en el tiempo porque está correctamente construido y mantenido.

Arquitectura general y documentación del sistema

El primer análisis a realizar es validar, desde el punto de vista de la arquitectura de sistemas, que el sistema está construido sobre unas bases estables y bien dimensionadas para dar soporte a unos requerimientos dados.

Se trata no solo de contrastar que los bloques que construyen el sistema en su conjunto son los adecuados sino que están correctamente dimensionados para el uso que se le está dando al sistema. Por otra parte, también se trata de garantizar que el sistema está correctamente documentando tanto desde el punto de vista técnico como funcional.

Se trata de responder a estas cuestiones:

  • ¿Están adecuadamente separados los servicios que componen el sistema?
  • ¿Están correctamente dimensionados los servidores que dan soporte al sistema?
  • ¿Existe algún ‘cuello de botella’ que esté afectando el rendimiento general del sistema?
  • ¿Es seguro mi sistema y no expone ninguna vulnerabilidad a ataques externos más allá de las estrictamente necesarias?
  • ¿Está adecuadamente documentado el sistema CRM? ¿Existe un documento de diseño técnico y funcional comprensible que describe los plug-ins instalados? ¿Existe un manual de operaciones? ¿Existe un manual de usuario que documente los casos de uso del sistema? ¿Existe un manual de administración del sistema?

Auditoría técnica de un sistema on-premise

Desde el punto de vista técnico se trata de responder positivamente a una cuestión fundamental ¿Funcionan ahora y van a funcionar correctamente los sistemas y servicios que dan soporte al sistema CRM?

Para ello es necesario obtener indicadores sobre los servicios de soporte al sistema:

  • El propio sistema operativo de los servidores que dan soporte al sistema CRM: la disponibilidad general del mismo, el espacio disponible en disco, el uso de la CPU, la memoria RAM disponible, el tamaño adecuado del archivo de paginación y las actualizaciones instaladas.
  • La base de datos del sistema CRM y del sistema de Reporting: el tamaño del archivo de datos y del archivo de transacciones, los bloqueos por espera o de tablas, el plan de mantenimiento definido, la disponibilidad de los servicios de la BBDD -Reporting Services, Agent, Browser y Server-, el crecimiento y la consistencia de la BBDD y las actualizaciones instaladas.
  • Los servicios específicos del sistema CRM: los servicios IIS -W3SVC, HTTPFilter, IISADMIN-, el servicio de procesamiento asíncrono, el servicio de enrutamiento de email).

Auditoría funcional de un sistema CRM

Desde el punto de vista funcional la cuestión es más delicada pues depende en gran medida de comprender para qué se ha diseñado el sistema y qué se espera del mismo. En cualquier caso una auditoría funcional debe responder a una serie de cuestiones clave:

  • ¿Funcionan adecuadamente las integraciones con terceros sistemas?
  • ¿Responden correctamente los servicios web que el sistema CRM expone a terceros sistemas?
  • ¿Están dicho sistemas permanentemente disponibles para que CRM ‘comunique’ con ellos?
  • La distribución del crecimiento de cada tabla ¿es adecuado y responde coherentemente con el diseño del sistema? ¿indica algún error de diseño en el sistema de seguridad o en la definición de los flujos de trabajo?

Detailed Table Analysis

Detailed Table Analysis

  •  ¿Se detectan errores críticos durante el trazado de los mensajes del sistema?

    CRM Diagnistics Tool

    CRM Diagnistics Tool

  • ¿Hay errores críticos relacionados con los servicios CRM en el visor de eventos de los servidores que dan soporte al sistema?
  • ¿Está correctamente configurado el servicio de enrutamiento de email?

Email Router Test

Email Router Test

  •  ¿Están finalizando correctamente los ‘trabajos’ del sistema? ¿Hay trabajos cancelados o finalizados con error? ¿Qué tipo de errores producen la cancelación o resolución errónea de los trabajos?
  • ¿Existen algún sistema de relanzamiento de trabajos por errores puntuales, por ejemplo ‘time-outs’ temporales en la BBDD?
  • ¿Existen algún sistema de ’limpieza’ de los trabajos finalizados correctamente?
  • ¿El código javascript implementado en formularios está comportándose como se definió?
  • Está el código fuente que implementa la lógica del sistema disponible para su modificación (plug-ins, informes, integraciones y servicios web, …).

Métricas para la auditoría

A nivel de arquitectura del sistema es complicado definir métricas más allá que la misma cumpla con las recomendaciones que recomienda el fabricante en cuanto a composición, versiones y dimensionamiento. Como solución para medir la arquitectura implantada, a modo de caja negra, la propuesta es realizar tests de estrés a diferentes niveles (IIS, BBDD, capa de servicios Web del sistema CRM y cliente web/móvil del sistema CRM) cuyos resultados demuestren que no hay ningún componente que actúe como cuello de botella para el resto y que afecte negativamente al rendimiento general del sistema.

A nivel técnico, las métricas son más objetivas en tanto que lo son los indicadores para su medición, por ejemplo:

  • Que los sistemas operativos que dan soporte al sistema CRM están 100% operativos.
  • Que el espacio disponible en disco duro no sea inferior al 30% de la capacidad del mismo.
  • Que el uso de la CPU y de la RAM no supere de media el 80% de la misma.
  • Que el servidor tenga instaladas las últimas actualizaciones.
  • Que el crecimiento del archivo de datos y del archivo de transacciones no supere un ratio de un 5% mensual.
  • Que el procedimiento de restauración de la BBDD y restauración de la misma esté probado y correctamente documentado para su ejecución inmediata ante una contingencia que requiera una restauración de la BBDD.
  • Que los servicios de la BBDD y los servicios específicos del sistema CRM están 100% disponibles.

A nivel funcional, las métricas tampoco son tan objetivas y dependen, en gran medida, de cómo se haya diseñado el sistema, por ejemplo:

  • Que el sistema no trace ningún error crítico en la plataforma.
  • Que no quede encolado ningún trabajo de sistema en estado incorrecto.
  • Que los sistema con los que interacciona CRM están 100% disponibles.
  • Que los servicios web expuestos por CRM están 100% disponibles.
  • Que ninguna tabla crece más de lo previsto, especialmente las tablas de operaciones asíncronas (AsyncOperationBase) y la de seguridad (Principal Object Access).
  • Que no hay ningún error crítico relacionado con los servicios CRM en el visor de eventos de los servidores que dan soporte al sistema
  • Que todos los mensajes enviados desde CRM llegan a sus destinatarios.
  • Que todos los mensajes enviados a los buzones monitorizados por CRM se crean correctamente en sus respectivas colas de trabajo.

Conclusión: propuesta de proyecto de auditoría

La auditoría de un sistema CRM no es un análisis que se realice una vez y que ya sea válida para siempre. Al contrario, es un proceso de medición continua de los indicadores definidos en el contexto de un proyecto de auditoría que deben ser constantemente monitorizados tanto para proponer posibles mejoras al sistema como para actuar proactivamente ante cualquier indicador fuera de rango.

Dicho proyecto requiere una primera fase de análisis dónde se definen los indicadores a medir y la métrica contra los que contrastarlos, así como las acciones correctivas/evolutivas que cada indicador debe disparar en cuándo alcancen un determinado valor.

Una fase de desarrollo/construcción, dónde se implementan las herramientas de monitorización y se automatiza, en la medida de lo posible, la obtención de los indicadores. Así como se construye el sistema de avisos que se deben disparar ante cualquier indicador fuera de rango.

Una implementación del sistema de auditoría en producción dónde el sistema avisa automáticamente de posibles malfuncionamientos y previene de que determinados indicadores fuera de rango tengan consecuencias negativas para el sistema y sus usuarios.

Finalmente, con la periodicidad establecida en el contexto del proyecto la elaboración de un informe de ‘estado’ del sistema CRM que permite, sobre todo, tener información de base para la propuesta de acciones preventivas y evolutivas del sistema que permitan asegurar que el sistema es estable y está preparado para soportar los requerimientos tanto técnicos como funcionales de sus usuarios, así como decidir sobre qué recomendaciones de mejora es recomendable aplicar al sistema.

En esta página puedes ver la oferta de ENCAMINA para este servicio de auditoría.

 

Sobre Juan Ribes

Director de Servicios CRM en ENCAMINA. Responsable de la implantación los proyectos CRM en ENCAMINA desde 2005, principalmente con Microsoft Dynamics.
Esta entrada ha sido publicada en Arquitectura, Consultoría, Estrategia, Metodología. Enlace permanente.
ENCAMINA, piensa en colores