Sistemas de información de clientes: caso de defensa en Oriente Medio

Este es un caso práctico de cómo un fabricante de defensa mediano de Oriente Medio arregló sus sistemas de información de clientes. Los datos de clientes vivían en tres sitios, las cotizaciones salían con precios incoherentes y las aprobaciones se perdían en el correo. La solución fue un registro único de cliente en Microsoft Dynamics, cotización basada en reglas en Experlogix CPQ y un traspaso automático de las cotizaciones aprobadas a SAP Sales and Distribution (SD) a través de SAP Cloud Integration. El plazo de las cotizaciones bajó un 35 % de media. Está escrito para responsables de operaciones comerciales, de TI y de finanzas de fabricantes con ciclos de venta largos, configurables y con mucha carga de cumplimiento normativo. La secuencia del despliegue y las lecciones del final son lo que conviene reutilizar.

Cuando los equipos de defensa piden sistemas de información de clientes, suelen querer algo más que un CRM. Quieren estructura: un lugar donde las decisiones complejas se vean juntas y en contexto, a lo largo de ciclos de venta largos, flujos con mucha carga de cumplimiento y grupos cambiantes de responsables de la decisión.

En mi puesto de Director de Transformación Digital en una empresa de defensa, me pidieron resolver exactamente esto. El problema no era la falta de esfuerzo. La gente hacía el trabajo. La cuestión era que ese esfuerzo no tenía hogar. Ni una plataforma compartida, ni visibilidad, ni alineación entre lo que se vendía y lo que se planificaba.

Un fabricante de defensa mediano de Oriente Medio. Operaba entre bastidores: no era una marca pública, y la visibilidad no era el objetivo. Sus componentes se usaban en aviación militar y en comunicaciones seguras.

Cada venta seguía un camino detallado: revisiones de ingeniería, controles de cumplimiento, aprobaciones internas, cotizaciones con control de versiones. No era caótico, pero sí pesado.

Los sistemas de información de clientes se desmoronaban. Ventas usaba una plataforma. Soporte, otra. Operaciones trabajaba con hojas de cálculo, carpetas sin conexión y documentos que estaban desactualizados antes de que alguien los abriera.

Esto es lo que estaba roto y lo que costaba:

Qué estaba roto	Impacto
Ningún CRM para el flujo de oportunidades ni para ver a los responsables de la decisión	Ninguna imagen compartida de en qué punto estaba cada operación
Precios gestionados a mano y sin un registro coherente	Las cotizaciones salían con cifras desactualizadas o contradictorias
Aprobaciones por correo, a menudo perdidas o retrasadas	Los rastros de auditoría de cumplimiento estaban incompletos
Registros de clientes duplicados entre sistemas, con datos ligeramente distintos	Nadie podía decir qué versión era la correcta

En el papel parecía estructurado. Si se seguía una cotización desde su creación hasta la entrega, se venía abajo. Las aprobaciones se atascaban sin un responsable claro. Los precios dependían de quién enviaba la cotización. Las cotizaciones quedaban enterradas en hilos de correo. Los equipos se hacían las mismas preguntas una y otra vez. Ninguno de esos fallos era dramático, pero con los meses los pequeños retrasos se acumulaban, y para un negocio con ciclos de venta largos el impulso perdido importaba más de lo que la mayoría imaginaba.

El objetivo no era sustituirlo todo. Era reducir la fricción sin dificultar el uso de nada: ayudar a que los sistemas reflejaran cómo ya trabajaban los equipos, no obligar a las personas a seguir procesos rígidos.

Pasé tiempo con los equipos antes de tocar ninguna configuración. Observé cómo avanzaba el trabajo desde la captura hasta la entrega, dónde estorbaban las herramientas y dónde la gente había dejado de confiar en los datos.

De esas sesiones salieron tres prioridades:

1. Un registro compartido de cliente, visible para ventas, soporte y operaciones en el mismo formato. Se acabaron las versiones paralelas.
2. Cotización estructurada, con reglas coherentes de configuración y precios en lugar de hábitos individuales y plantillas antiguas.
3. Ejecución de pedidos conectada, con un traspaso limpio de la cotización aprobada a SAP SD y sin reintroducir datos a mano.

Sistema	Qué resolvió
Microsoft Dynamics CRM	Un registro único de cliente, vinculado a la actividad comercial y a las oportunidades
Experlogix Configure Price Quote (CPQ)	Reglas de configuración de productos, lógica de precios, versiones de cotización
SAP Sales and Distribution (SD)	Ejecución y entrega de pedidos
SAP Cloud Integration (CPI)	Capa de integración que conecta CPQ y CRM con SAP SD

Microsoft Dynamics como base. Necesitábamos un único lugar donde la información de clientes fuera precisa y visible en su contexto completo. Dynamics nos dio un punto de partida para desenredar los datos. Ayudó la familiaridad con la plataforma, y también su encaje con Outlook y Teams. No obligó a nadie a empezar de cero; solo requirió ajustes para adaptarse a cómo funcionaba el negocio. Cuando los equipos vieron los mismos datos en el mismo formato en todas las funciones, empezó a crecer la confianza.

Experlogix CPQ para configuración y precios. Antes, las cotizaciones se hacían de demasiadas maneras distintas. La gente se fiaba de la memoria y de ediciones manuales. Configuramos Experlogix con reglas definidas para las combinaciones de productos, precios ligados a las configuraciones y un enrutamiento de aprobaciones según el tipo y el valor de la operación. Al principio parecía limitante, y algunos no tuvieron reparos en decirlo, pero eliminó la ambigüedad. Ingeniería recibía cotizaciones más limpias, y ventas dejó de ajustar los precios de memoria a partir de operaciones anteriores.

SAP SD a través de SAP CPI. SAP SD ya se usaba para los pedidos. La carencia estaba en el traspaso: una cotización aprobada todavía había que volver a teclearla en SAP. Integramos ambos mediante SAP CPI, de modo que las cotizaciones aprobadas pasaban directamente a SAP como pedidos y los datos de clientes y de pedidos se mantenían sincronizados entre Dynamics y SAP. Donde nos topamos con limitaciones, añadimos lógica a medida. No fue elegante en todos los casos, pero funcionó.

1. 01Registro de clienteMicrosoft Dynamics, una sola versión para todos los equipos
2. 02Configurar y fijar precioReglas de Experlogix CPQ para combinaciones y precios
3. 03AprobarEnrutada según el tipo y el valor de la operación
4. 04Crear el pedidoSAP CPI pasa la cotización aprobada a SAP SD
5. 05EntregarSAP SD, con los datos de cliente sincronizados

Sin reintroducir datos y con un rastro de auditoría desde la aprobación hasta el pedido

El despliegue se escalonó a lo largo de unos seis a ocho meses. Nada dramático: cambios por capas, validados en cada paso.

1. Piloto. Un grupo pequeño de usuarios y escenarios concretos centrados en CRM y CPQ. Probamos casos límite, sacamos a la luz carencias e hicimos cambios antes de escalar.
2. Limpiar los datos. Los registros de clientes se consolidaron y se depuraron de duplicados antes de entrar en Dynamics, con los documentos de cumplimiento vinculados a las oportunidades correctas. Esto llevó más tiempo que la configuración.
3. Extender a los departamentos. Una vez perfeccionados los flujos del piloto, la solución pasó a ventas, soporte y operaciones.
4. Integrar SAP SD a mitad de camino. La integración de CPQ con SAP entró en producción cuando los sistemas previos ya eran estables, para que los primeros problemas no se propagaran a los pedidos.

La seguridad y el cumplimiento normativo se diseñaron desde el primer día. Para un cliente de defensa, la integridad del rastro de auditoría y el acceso basado en roles no son opcionales. Definimos con claridad los roles de acceso y registramos los rastros de aprobación. La residencia de los datos se resolvió pronto: todos los datos permanecieron dentro de los Emiratos Árabes Unidos, conforme a las normas del sector de defensa. Eso nos frenó un poco al principio y evitó problemas más graves después.

La formación fue práctica: sesiones cortas, materiales específicos, demostraciones en directo y vídeos de instrucciones, que continuaron durante semanas y meses en lugar de limitarse a una sola sesión. La adopción no fue perfecta al principio. El apoyo constante y los beneficios visibles superaron la reticencia inicial. El punto de inflexión llegó cuando los equipos usaron las herramientas en situaciones reales y comprobaron que los datos que recibían eran correctos.

Resultado	Qué cambió
Plazo de las cotizaciones	Un 35 % menos de media; horas ahorradas en muchas operaciones y varios días en las complejas
Precisión de la configuración	Las reglas de validación evitaron errores antes de que llegaran a ingeniería
Preparación para auditorías	Los controles de cumplimiento ya no exigían una carrera de última hora
Alineación entre equipos	Ventas, soporte y operaciones trabajaban con el mismo registro de cliente

La reducción del 35 % no llegó en la primera semana. Los primeros ciclos todavía incluían aclaraciones y correcciones. Cuando las reglas de producto y la lógica de precios fueron coherentes, la cotización se aceleró. Los comerciales dejaron de perseguir aprobaciones o de arreglar plantillas reutilizadas. El sistema se encargaba de esos pasos.

La alineación importa más que la tecnología. La parte técnica del proyecto fue la más fácil. Lo difícil fue lograr que los equipos confiaran en una única fuente de verdad y dejaran de mantener sus propios registros. Significó demostrar a las personas que los datos eran fiables antes de pedirles que dependieran de ellos.

Los detalles de la integración importan más que las funcionalidades. La integración de CPQ con SAP SD es lo que dio valor a todo el sistema. Un CRM aislado y una cotización aislada con introducción manual de pedidos habrían ayudado cada uno un poco. La conexión entre ellos es donde desapareció la fricción.

El apoyo y la formación hacen que se mantenga. Desplegar y abandonar no es entregar. La formación continuó durante semanas y meses después del go-live, y ese periodo es donde la adopción se consolida o se deshace.

La arquitectura sigue siendo válida: CRM para el registro de cliente, CPQ para la cotización estructurada, integración con el ERP para la ejecución de pedidos. Tres cosas cambiarían si el mismo proyecto empezara ahora.

La plataforma de integración. SAP CPI es ahora la capacidad Cloud Integration dentro de SAP Integration Suite, junto con la gestión de API, la integración basada en eventos y el contenido de integración prediseñado. Un flujo de Dynamics a CPQ y a SAP SD requeriría hoy menos tiempo de diseño. Mi guía de SAP Cloud Integration cubre la plataforma.

El CRM propio de SAP estaría en la lista corta. Con un back-end SAP SD, un proyecto nuevo debería comparar SAP Sales Cloud, que ahora incluye Joule, con Microsoft Dynamics. Dynamics fue la elección correcta aquí por la familiaridad existente. La respuesta sigue dependiendo de la capacidad y de las preferencias de integración, pero la opción nativa de SAP es hoy una candidata más creíble que antes. Mi comparativa de sistemas CRM para SAP repasa las opciones.

El alcance federal de EE. UU. necesita otro modelo de alojamiento. Este cliente no lo necesitaba, pero una empresa de defensa con operaciones federales en EE. UU. miraría SAP National Security Services (SAP NS2). En 2025 recibió una autorización provisional para operar S/4HANA Cloud Private Edition y SAP BTP en FedRAMP+ Impact Level 5, con operaciones solo en EE. UU.

Los requisitos específicos de defensa (rastros de auditoría, acceso basado en roles, control de versiones de las cotizaciones, residencia de datos) se aplican sea cual sea la generación de la plataforma. Para el panorama general del cumplimiento normativo, vea mi guía sobre el cumplimiento normativo de SAP en el sector público.

¿Por qué se eligió Microsoft Dynamics frente a otras plataformas CRM?

Podía gestionar todo el ciclo de vida del cliente, desde el cliente potencial hasta la oportunidad y el compromiso posventa, y soportar los ciclos de operación largos y complejos de las ventas de defensa. Su encaje con Outlook y Teams ayudó a la adopción, y la familiaridad del equipo con la plataforma redujo aún más la barrera.

El control de acceso, el registro de auditoría, la flexibilidad y el margen para crecer fueron los otros factores decisivos para un cliente con tanta carga de cumplimiento normativo.

¿Qué papel desempeñó Experlogix CPQ y por qué un CPQ?

Los productos de defensa tienen reglas de configuración complejas. Una lista de precios no puede reflejar la interacción entre variantes de producto, requisitos de cumplimiento y condiciones específicas de cada cliente. Sin CPQ, cada cotización dependía de que quien la elaboraba conociera las reglas.

Experlogix llevó esas reglas a la herramienta de cotización. Un comercial recibía avisos de validación mientras elaboraba la cotización, no una corrección de ingeniería días después. Los errores se movieron aguas arriba, donde es barato corregirlos.

¿Cómo se integró SAP SD con el CRM y el CPQ?

SAP CPI actuó como middleware. Una cotización aprobada en Experlogix disparaba un flujo que creaba el pedido en SAP SD con las posiciones, los precios y los datos de cliente correctos. CPI también mantenía sincronizados los datos de clientes y de pedidos entre Dynamics y SAP, con reglas de validación para evitar datos que no coincidieran.

Antes, alguien copiaba a mano cada cotización aprobada en SAP. Automatizarlo eliminó los errores de reintroducción y creó un rastro de auditoría limpio desde la aprobación hasta el pedido.

¿Cuáles fueron los mayores retos durante la implementación?

Primero, la calidad de los datos. Los datos de clientes eran incoherentes entre departamentos, con duplicados y campos vacíos, y hubo que limpiarlos antes de que Dynamics pudiera ser la fuente de verdad.

En segundo lugar, el mapeo de la integración, sobre todo de configuraciones de producto y precios entre tres sistemas. En tercer lugar, alinear a ventas, ingeniería, TI y finanzas, en particular cuando cambió quién era responsable de partes del proceso.

¿Cómo se gestionaron la seguridad y el cumplimiento normativo?

Se incorporaron desde el primer día. Cada componente tenía que cumplir las políticas de seguridad internas y la normativa nacional. El acceso basado en roles limitaba quién podía ver y cambiar qué registros. Rastros de auditoría completos cubrían la cotización, las aprobaciones y los cambios de datos. Todos los datos permanecieron en los Emiratos Árabes Unidos, conforme a las normas del sector de defensa.

Como el diseño partió de esos requisitos, los datos ya tenían la forma adecuada cuando llegaron las revisiones de cumplimiento.

¿Cuánto duró el despliegue?

Unos seis a ocho meses, por fases. Empezó con un piloto centrado en CRM y CPQ, se extendió a los departamentos tras recoger comentarios y añadió la integración con SAP SD a mitad de camino, cuando los sistemas previos ya eran estables. La formación, el soporte y los ajustes continuaron durante todo el proceso.

¿Se puede aplicar este modelo a otras empresas de defensa o de fabricación?

Sí, allí donde los ciclos de venta sean largos, los productos configurables y se exija documentación de cumplimiento: aeroespacial, equipos industriales y cualquier negocio en el que una cotización necesite validación de ingeniería antes de salir.

Las herramientas concretas importan menos que la lógica de integración. La cotización aprobada debe fluir hacia el ERP sin reintroducir datos, y el registro de cliente debe ser una única fuente de verdad.