Cinco decisiones que conviene dejar por escrito para que su equipo cambie el rumbo sin consultores

Su Director de Finanzas pide una nueva línea de servicio para el próximo trimestre. La respuesta honesta del administrador depende de decisiones tomadas años atrás: qué sistema es dueño del cliente, cómo se comunica el campo con finanzas, quién puede ver qué. Si esas decisiones solo existen en la cabeza de un consultor, la respuesta es llamar al socio externo y esperar.

Esta guía es para el Director de Tecnología (CIO) que heredará el sistema, y para los Directores de Operaciones y de Finanzas que le pedirán cambios. Para cada decisión, indica qué dejar por escrito y por qué importa cuando el negocio se mueve.

Success by Design↗, el marco de trabajo de Microsoft que usa FastTrack↗, revisa el mismo terreno.

Sus revisiones de implementación cubren el modelo de datos, la seguridad, las integraciones, la gestión del ciclo de vida de las aplicaciones y las pruebas. La revisión valida cada decisión. Mantener el registro le corresponde a su equipo.

1. Cada tipo de registro necesita un solo dueño, por escrito

Decida qué aplicación es dueña de cada tipo de registro y consígnelo en una sola tabla. Cliente, activo, artículo, precio, orden de trabajo y factura: cada uno con un dueño, la lista de aplicaciones que lo consultan y el rol autorizado para modificarlo.

La guía de integración de Microsoft lo explica. Una sincronización en un solo sentido define con claridad quién guarda el registro y simplifica los conflictos. Una sincronización en ambos sentidos complica la resolución de conflictos y copia los datos en cada sistema.

Algunas de estas decisiones vienen con el producto, y su equipo debe saber cuáles. Cuando se activa la integración de Field Service con las aplicaciones de finanzas y operaciones, Supply Chain Management pasa a ser el sistema de registro del inventario. Field Service oculta entonces sus propias pantallas de inventario.

Para el Director de Finanzas, esta es la decisión detrás de un cierre limpio. Finanzas y el campo coinciden en las cifras porque ambos leen el mismo registro.

2. Defina qué tan rápida debe ser cada conexión, y cómo falla

Para cada flujo entre sistemas, deje por escrito el disparador, la dirección, qué tan actualizados deben estar los datos, el patrón y quién recibe la alerta cuando algo se rompe.

La actualidad de los datos es la decisión que los equipos omiten. La guía de Microsoft advierte que los patrones en tiempo real y casi en tiempo real se confunden con frecuencia.

Una consulta de existencias en tiempo real espera una respuesta y se detiene cuando el otro sistema está caído. Una actualización cada pocos minutos permite seguir trabajando durante una interrupción. Microsoft señala que la mayoría de los patrones que recomienda son asíncronos.

Después, deje por escrito qué pasa cuando falla. La integración de Microsoft entre Field Service y finanzas reintenta varias veces una transacción fallida y luego conserva el error para que alguien lo corrija y lo reenvíe. Alguien de su equipo es responsable de esa cola. Póngale nombre.

Las conexiones también tienen fecha de término. Esa integración dejará de estar disponible después del 28 de febrero de 2027; Microsoft traslada la capacidad a la integración entre Field Service y Project Operations↗. Con un mapa de integraciones por escrito, su equipo puede ver en una tarde qué procesos toca el cambio.

3. Los accesos son fáciles de ampliar y difíciles de retirar

Deje por escrito cómo su modelo de seguridad refleja el negocio: las unidades de negocio, el rol de cada puesto y quién aprueba un rol nuevo.

En Dataverse↗, la plataforma de datos de las aplicaciones de Dynamics 365 para clientes, los privilegios se suman y prevalece el acceso más amplio. El ejemplo de Microsoft: si concede a toda la organización permiso para leer los contactos, después no puede ocultar ni un solo contacto. El tipo de propiedad de una tabla también se define al crearla y no puede cambiarse más adelante.

Por eso conviene registrar el razonamiento.

Anote por qué los despachadores ven todos los territorios o solo el suyo, y por qué los técnicos no ven los precios. Liste las columnas que guardan datos personales y quién puede leerlas.

Cuando usted abre una región o compra una empresa, su administrador amplía un patrón en lugar de adivinar.

Los agentes van en el mismo registro. Success by Design pide revisar los datos a los que llega cada agente y conceder el mínimo acceso que funcione. Además, asignamos a cada agente un responsable con nombre del lado del cliente.

4. Sepa dónde se construyen, se prueban y se publican los cambios

Deje por escrito qué entornos existen, para qué sirve cada uno, quién puede cambiar qué y dónde, y cómo llega un cambio a producción.

Microsoft recomienda definir la estrategia de entornos antes de empezar la construcción, porque cambiarla después puede ser difícil y costoso. Su guía del ciclo de vida es concreta. Se construye en un entorno de desarrollo con soluciones no administradas, que se guardan en control de código fuente, y se publican soluciones administradas en prueba y producción.

Una prueba rápida: pida a su administrador que explique cómo un campo nuevo en la orden de trabajo pasa de la idea a producción, y quién lo aprueba. Si la respuesta es «eso lo hace el consultor», la ruta de publicación todavía es del consultor.

Incluya aquí también el calendario de actualizaciones. Microsoft ahora publica cambios en Dynamics 365 de forma continua, y alguien de su lado decide cuándo llegan a su gente.

5. Cada desarrollo a la medida necesita una razón y una salida

Para cada extensión, deje por escrito el requisito, por qué la función estándar no bastó, qué toca la extensión y qué volver a probar después de cada actualización.

La guía de Microsoft es clara sobre el costo. Advierte contra reconstruir el sistema anterior dentro del nuevo, porque alejarse mucho de las funciones estándar aumenta la deuda técnica y el costo de mantenimiento.

También advierte que depender de otro proveedor para mantener sus extensiones puede impedirle adoptar funciones nuevas. Success by Design recomienda registrar cada requisito y su solución en un documento de diseño funcional.

Agregue una línea más: la salida. Si Microsoft incorpora después la función como estándar, la extensión debe retirarse. Una razón por escrito facilita esa decisión.

Los equipos pequeños necesitan un registro breve; los regulados, uno más completo

Una sola aplicación, unas decenas de usuarios y ningún desarrollo a la medida necesitan un registro breve. Las cinco decisiones aplican igual; las respuestas son cortas.

Los fabricantes regulados necesitan más. Con Microsoft publicando cambios de forma continua, requieren un ciclo permanente de pruebas de regresión y validación, presupuestado como costo de operación.

Los distribuidores de equipo suelen mantener un sistema de gestión para distribuidores como dueño de algunos registros, y esos sistemas por lo general se conectan por lotes. Para los distribuidores, la decisión 2 es la que más pesa.

Un registro de decisiones funciona cuando el administrador que lo usará ayudó a escribirlo. Uno que nadie leyó no sirve de nada.

El registro nace de hacer el trabajo juntos

Dejamos por escrito cada decisión de diseño, con su razón, mientras avanza el proyecto, y los administradores del cliente construyen junto a nuestros consultores. Un contratista de instalaciones mecánicas, eléctricas y sanitarias de 2,000 personas en el sur de Estados Unidos terminó su proyecto con un plano que registra cada decisión de diseño. La hoja de ruta por fases es del contratista, para ejecutarla con su propio equipo, con nosotros o con otro socio.

Lo que deben hacer los líderes antes de que se vayan los consultores

Haga de las cinco decisiones un entregable. Inclúyalas en el contrato, cada una con su razón.

Haga que su administrador las escriba con el arquitecto. La persona que cambiará el sistema debe ser dueña del registro.

Ponga a prueba el registro con un cambio real. Antes del arranque, pida a su equipo que agregue una sucursal o un rol usando solo el registro. Cada pregunta que tengan que hacer es una brecha por cerrar.

Actualícelo cuando cambie el negocio. Una región nueva, una adquisición o un aviso de retiro de Microsoft deben activar una revisión del registro.

Cómo lo sabemos

Esta guía proviene de los proyectos de Dynamics 365 de Ludia. Fuentes de Microsoft, todas en Microsoft Learn (en inglés): Introduction to the Success by Design framework (agosto de 2026); Choose the right pattern for your integration strategy; Field Service integration with finance and operations applications (septiembre de 2026), sobre el sistema de registro del inventario, los reintentos y la fecha de término del 28 de febrero de 2027; Security concepts in Microsoft Dataverse (septiembre de 2026); Plan your environment strategy for Dynamics 365; Solution concepts with Power Platform; Extend Dynamics 365 apps without compromising performance; Stay current with Dynamics 365 service updates (julio de 2026). Publicación continua y fabricantes regulados: ERP Today (26 de agosto de 2026). El ejemplo del contratista es un resultado de cliente publicado por Ludia; el cliente no se nombra.