Un CRM, un ERP y una plataforma de operaciones de compradores resuelven partes distintas de un modelo operativo de preventa. Un CRM normalmente es dueño del contexto de relación y ventas, un ERP o sistema financiero aprobado es dueño de los registros financieros, y una capa de operaciones de compradores coordina flujos entre sistemas, políticas, tareas, comunicaciones y excepciones sin convertirse en la fuente de verdad de cada registro.
Compara responsabilidades, no etiquetas de producto
Los nombres de las categorías de software son atajos útiles, pero no definen lo que una implementación específica puede o debe poseer. Dos productos descritos como CRM pueden exponer registros, flujos, permisos y opciones de integración diferentes. Lo mismo ocurre con los ERP, los sistemas de documentos, los portales y las plataformas de flujo.
Comienza con las responsabilidades operativas:
- ¿Qué sistema es autoritativo para cada registro?
- ¿Qué equipo puede aprobar un cambio?
- ¿Qué trabajo entre sistemas necesita coordinación?
- ¿Qué acciones pueden automatizarse bajo una política aprobada?
- ¿Qué condiciones requieren revisión humana?
- ¿Qué evidencia debe permanecer rastreable?
Las capacidades varían según el producto, la edición, la configuración y la versión. Verifícalas en la documentación actual del proveedor y en el entorno configurado del desarrollador antes de tomar una decisión de arquitectura. Este artículo compara roles operativos, no proveedores ni productos con nombre.
De qué debe ser dueño el CRM
Un CRM comúnmente es dueño del contexto de relación y ventas. Según la configuración del desarrollador, eso puede incluir:
- registros de prospectos y compradores;
- historial de relación;
- propiedad de ventas;
- preferencias de contacto aprobadas;
- contexto de oportunidad o reserva;
- actividad de la etapa de ventas; y
- historial de comunicación creado dentro del CRM.
El CRM también puede ofrecer capacidades de automatización, documentos, pagos o portal. Esas funciones deben evaluarse frente al mapa real de responsabilidades del desarrollador, en lugar de asumirse a partir de la etiqueta del producto.
Tras la reserva, el CRM puede seguir siendo autoritativo para el contexto del comprador y la relación mientras otros sistemas son dueños de los contratos, los registros financieros, los documentos o el inventario. Un flujo de operaciones de compradores puede leer el contexto permitido del CRM y coordinar acciones sin copiar cada registro del CRM a una base de datos en competencia.
De qué debe ser dueño el ERP o sistema financiero
El ERP o sistema financiero aprobado debe seguir siendo autoritativo para los registros financieros que se le asignan. Según el modelo operativo, esos pueden incluir:
- calendarios de pago aprobados;
- registros de cuentas por cobrar o de libro mayor;
- transacciones contabilizadas;
- estados de cotejo y asignación;
- reversos, disputas, correcciones o reembolsos;
- estado liquidado; y
- referencias y resultados aprobados por finanzas.
La distinción entre calendario y transacción es importante. Un calendario describe una expectativa aprobada; un registro de transacción describe lo que finanzas ha registrado. Un mensaje del comprador, una carga de documento, una fecha esperada o una notificación externa no deben sobrescribir el estado financiero autoritativo.
El flujo de operaciones de pago coordina el contexto del calendario aprobado, el estado de finanzas, la comunicación y las excepciones, manteniendo la autoridad financiera con el sistema y el equipo designados.
Qué coordina una capa de operaciones de compradores
Una capa de operaciones de compradores conecta el trabajo operativo que cruza sistemas autoritativos. Puede coordinar:
- el contexto de comprador, unidad, proyecto y ciclo de vida requerido para una tarea;
- los requisitos de documentos aprobados y los estados de revisión;
- la comunicación con el comprador controlada por política;
- el seguimiento de pagos basado en fuentes aprobadas;
- las tareas y traspasos entre ventas, operaciones, finanzas y cierre;
- la detección, asignación y evidencia de resolución de excepciones;
- la evidencia de preparación antes de una revisión autorizada; y
- un registro de actividad que muestre qué fuente y política sustentaron una acción.
La capa no debe absorber la autoridad de los sistemas que conecta. Puede crear un estado operativo como "listo para revisión de finanzas", pero no debe declarar que una transacción se liquidó a menos que la fuente financiera aprobada sustente ese estado. Puede registrar que un documento se recibió, pero no debe declarar que el documento era suficiente a menos que un revisor autorizado haya registrado esa decisión.
Este modelo de coordinación se refleja en los flujos de preparación de documentos, atención al comprador y preparación para el cierre de Asterisko.
Asigna cada tema operativo a una sola fuente autoritativa
La fuente probable a continuación es un punto de partida, no una asignación universal. Un desarrollador debe reemplazarla con los sistemas, políticas y responsables usados en su propio entorno.
| Tema operativo | Sistema autoritativo probable | Uso del flujo entre sistemas |
|---|---|---|
| Identidad del comprador | CRM aprobado o sistema de identidad del comprador | Conectar al comprador correcto con la unidad, las tareas y las comunicaciones permitidas |
| Relación | CRM | Aportar propiedad de ventas, contexto del ciclo de vida y preferencias aprobadas |
| Unidad | Sistema de inventario o proyecto aprobado | Anclar documentos, pagos, comunicación y preparación a la unidad correcta |
| Contrato | Repositorio de contratos o sistema de contratos aprobado | Exponer el estado del contrato autorizado sin permitir que el flujo infiera efecto legal |
| Calendario | Contrato aprobado, ERP o sistema financiero | Coordinar hitos y tiempos de política sin cambiar los términos aprobados |
| Transacción | ERP o sistema financiero aprobado | Impulsar acciones permitidas desde el estatus registrado y enrutar conflictos a finanzas |
| Documentos | Repositorio de documentos o sistema de contratos aprobado | Dar seguimiento a recepción, revisión, aprobación, procedencia y excepciones como hechos separados |
| Comunicación | CRM, portal o registro de comunicación aprobado | Aplicar plantillas, permisos, tiempos y política de escalamiento aprobados |
| Tarea | Flujo o sistema de tareas aprobado | Asignar trabajo rutinario y excepciones con responsables, estados y evidencia |
| Preparación | Registro de preparación aprobado | Reunir evidencia y solicitar una decisión autorizada sin autoaprobarse |
Un sistema puede ser dueño de varios temas, y una implementación puede exponer funciones superpuestas. El control es que cada tema tenga una autoridad designada en un punto dado del modelo operativo.
Decide si mejorar, integrar o agregar una capa de flujo
Usa estas preguntas ordenadas como un árbol de decisión:
-
¿Es el registro subyacente correcto, gobernado y accesible en su sistema actual?
Si no, primero mejora el sistema de origen, la propiedad de los datos, los permisos o la política operativa. La integración no puede hacer autoritativa una fuente poco confiable. -
¿Puede el sistema actual soportar el flujo requerido sin duplicar la autoridad?
Si sí, configura y gobierna esa capacidad antes de agregar otra capa. -
¿Depende el trabajo de contexto de otro sistema autoritativo?
Si sí, evalúa una integración que exponga el mínimo contexto permitido y preserve la procedencia. -
¿Cruza la ruta operativa varios sistemas, equipos y políticas?
Si sí, una capa de flujo puede ayudar a coordinar acciones, traspasos y excepciones sin reemplazar las fuentes. -
¿Están definidos los responsables de excepciones y los límites de decisión humana?
Si no, defínelos antes de automatizar. Una nueva plataforma no resolverá una autoridad ambigua. -
¿Puede el diseño propuesto mostrar por qué ocurrió cada acción?
Si no, agrega evidencia de fuente, política, actor, marca de tiempo y excepción antes del despliegue.
El resultado puede ser una combinación: mejorar una fuente, integrar un conjunto limitado de registros aprobados, y agregar coordinación de flujo solo en torno al recorrido entre sistemas.
Revisión humana, permisos y propiedad de excepciones
Los límites entre sistemas no eliminan la necesidad de límites de decisión. Define qué acciones puede tomar una persona o un flujo, sobre qué registros, bajo qué política y con qué evidencia.
La revisión humana es apropiada cuando:
- los registros de comprador, unidad, contrato, calendario, transacción o documento entran en conflicto;
- una acción solicitada cambia un término, obligación o registro autoritativo aprobado;
- un documento requiere revisión de suficiencia, validez o legal;
- una transacción está sin cotejar, cotejada parcialmente, revertida, disputada o poco clara;
- una comunicación está fuera del contenido o los permisos aprobados;
- un comprador solicita una interpretación legal, contable, de financiamiento, de título o específica de la jurisdicción; o
- una decisión de preparación, liberación, aprobación o cierre requiere autoridad.
Cada excepción debe tener un responsable con nombre, un estado visible, evidencia de origen, una ruta de resolución permitida y un resultado autorizado. Los permisos deben seguir principios de mínimo acceso y las políticas de seguridad, privacidad y retención del desarrollador.
Preguntas a hacer durante la evaluación de productos
Haz a cada sistema o configuración candidata las mismas preguntas basadas en responsabilidades:
- ¿Qué temas operativos puede poseer como fuente autoritativa?
- ¿Qué temas puede leer sin copiarlos ni redefinirlos?
- ¿Cómo preserva la procedencia de la fuente y la vigencia del registro?
- ¿Qué acciones pueden limitarse por rol, proyecto, estado y política?
- ¿Cómo se registran los estados del flujo y las versiones de política?
- ¿Cómo se manejan los duplicados, los reintentos y las actualizaciones de fuente retrasadas?
- ¿Puede detenerse el trabajo rutinario cuando los registros entran en conflicto o falta contexto?
- ¿Cómo se representan la revisión humana, la propiedad de excepciones y la evidencia de resolución?
- ¿Pueden los campos sensibles permanecer en el sistema autoritativo?
- ¿Qué documentación actual sustenta las APIs, eventos, permisos y límites requeridos?
- ¿Cómo se pueden exportar los registros y la evidencia si el modelo operativo cambia?
Evalúa estas respuestas frente a un recorrido del comprador mapeado y excepciones representativas. Una lista de funciones por sí sola no muestra cómo dividirán la responsabilidad los sistemas configurados.
Dónde encaja Asterisko
Asterisko está diseñado como una capa de operaciones de compradores para desarrolladores de preventa. Coordina flujos sobre los sistemas existentes, incluidos los registros aprobados de CRM, ERP o finanzas, documentos, comunicación y proyecto.
No se posiciona como un reemplazo universal de cada CRM, ERP, portal del comprador, repositorio de documentos o proceso de revisión profesional. El modelo operativo mantiene esos sistemas como autoritativos para los temas que se les asignan, mientras Asterisko coordina el contexto, la política, las tareas, las comunicaciones, los traspasos y las excepciones.
Empieza por mapear un recorrido del comprador y asignar cada tema operativo a una fuente autoritativa. Luego identifica los pasos entre sistemas que siguen desconectados. Explora la atención al comprador como un patrón de coordinación, y verifica todas las capacidades requeridas frente a la documentación actual del proveedor y la configuración real del desarrollador antes de decidir si mejorar, integrar o agregar una capa de flujo.
