Ninguna propuesta redactada en marzo se mantiene vigente tras una revisión de precios de SAP S/4 HANA en mayo, por lo que la oportunidad de SugarCRM presenta las cifras actuales en lugar de las que alguien citó inicialmente.
Las ofertas a largo plazo se presupuestan dos veces: una al redactar la propuesta y otra cuando el cliente la firma. Entre medias, SAP S/4HANA ha modificado costes, renovado acuerdos con proveedores y posiblemente cambiado alguna condición de la cuenta, y nada de esto afecta a la oportunidad de SugarCRM que alguien ha estado gestionando durante cuatro meses. Así pues, se emite el presupuesto con las cifras de marzo, se acepta el pedido y, posteriormente, se habla del margen sin que nadie tenga a quién culpar. La conexión entre SAP S/4HANA y SugarCRM mantiene actualizada la cifra de la oportunidad, de modo que se vuelve a presupuestar la oferta mientras aún se puede renegociar.

Cuando SAP S/4 HANA modifica el precio de algo de lo que depende una oportunidad abierta de SugarCRM, el cambio es visible en el registro en lugar de descubrirse en el momento de la aceptación.
Las cotizaciones se almacenan en SAP S/4 HANA y se reflejan en SugarCRM, por lo que el documento que recibe el cliente y el documento que utilizará el departamento de finanzas para facturar son el mismo.
La solvencia crediticia de SAP S/4 HANA reside en la misma cuenta de SugarCRM, por lo que no se invierten meses de esfuerzo en licitaciones para un cliente que nadie en finanzas aprobaría jamás.
Cuando una oportunidad de SugarCRM se marca como ganada, se crea el pedido correspondiente en SAP S/4 HANA, por lo que no es necesario volver a introducir ningún dato entre la aceptación y la programación de la mercancía.
Cuando SAP S/4 HANA modifica una condición de precio en una oferta abierta, Alumio actualiza la oportunidad de SugarCRM, de modo que el vendedor se entera mientras el cliente aún está en conversación, en lugar de en el momento de la firma.
Una cotización generada en SAP S/4 HANA se refleja en la oportunidad de SugarCRM con su versión, por lo que una situación en la que un cliente discute la tercera revisión y un vendedor consulta la segunda deja de ocurrir.
Cuando se cierra la oportunidad de SugarCRM, Alumio crea el pedido de venta en SAP S/4 HANA contra el cliente y la cotización aceptada, por lo que el pedido cumplido es el acordado y no una aproximación del mismo que se haya vuelto a escribir.
Alumio se sitúa entre los canales de venta y los sistemas de cumplimiento como una columna vertebral de integración gobernada. Los pedidos se enrutan, transforman y validan, mientras que las actualizaciones de estado regresan a cada canal.
Autentique sus sistemas utilizando los conectores preconfigurados de Alumio. Elija entre más de 200 paquetes de conectores en el marketplace, además de integraciones personalizadas ilimitadas.
Defina cómo se asignan los campos de datos entre sistemas en una interfaz visual. Ajuste formatos, enriquezca registros y aplique lógica de negocio, sin necesidad de código personalizado.
Configure los flujos para que se ejecuten en tiempo real según eventos, según un horario o ambos. Reduzca la entrada manual de datos y deje que Alumio gestione el movimiento y la transformación entre sistemas.
Una vez que su primera integración esté activa, añadir su ERP, PIM, WMS o CRM se conecta al mismo centro. Los flujos existentes siguen funcionando. Sin necesidad de reconstruir desde cero.
Comience por donde se elaboran las propuestas, ya que ni SAP S/4HANA ni SugarCRM almacenan el documento que lee el cliente. Una biblioteca de ofertas contiene las secciones, las referencias y los términos que se reutilizan, y actualmente se trata de una carpeta. Alumio mantiene esa conexión junto con la actual, de modo que la propuesta, el precio y la oportunidad describen la misma oferta en lugar de tres versiones distintas.
Sí, es posible, y la decisión sobre qué sistema gestiona la cotización es la primera que debe tomarse. Alumio puede reflejar las cotizaciones de SAP S/4HANA y sus versiones en la oportunidad de SugarCRM con la frecuencia que usted configure, y enviar una aceptación en sentido contrario. Al permitir que ambos sistemas contengan una cotización editable, el cliente termina con un documento y las facturas financieras de otro. La función de reflejar una cotización depende de las funcionalidades que SugarCRM ofrece a través de su propia interfaz.
No, y nada de esto se realiza dentro de SAP S/4HANA. La propuesta, generada a partir de dos pantallas, es la que se envía, y el vendedor conserva una copia privada de las cifras. Las condiciones de SAP S/4HANA que afectan a los campos de SugarCRM, y lo que genera una oportunidad ganada, se registran en Alumio. Cuando se debe derivar un precio de oferta a partir de varias condiciones, el Code Transformer se encarga de ello.
Desde SAP S/4HANA, siempre, y lo útil es que SugarCRM indica cuándo se realizó el último cambio. Una oferta que estuvo vigente durante cuatro meses se basó en cifras que ya no existen, y un vendedor que no lo vea defenderá la cifra anterior ante el cliente. Actualizar la oportunidad a medida que cambian las condiciones convierte la revisión de precios en una conversación en lugar de una sorpresa al momento de la firma.
Una cifra que llega a SugarCRM después de que el cliente ya haya visto la anterior es el fallo que perjudica la relación, ya que la corrección se traduce en un aumento de precio. Alumio monitoriza cada actualización en tiempo real y registra el estado de SAP S/4HANA con la hora de lectura, de modo que un cambio tardío genera una alerta que indica la oportunidad y el motivo. Se ejecutan reintentos donde esté configurado, por lo que nada pasa desapercibido.
Habla con un especialista en integración de Alumio. Diseñaremos la arquitectura adecuada para tus sistemas, a la escala correcta, para que tus operaciones sigan siendo fiables ante cualquier cambio.