El panorama de Steve Trucking

🌐 También en 28 idiomas

English · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Imagen generada con IA

Traducido con IA. Aún no revisado por la comunidad. Leer en inglés

Módulo 6 de 6 del capítulo Entender los datos de la empresa, capítulo 4 del curso Data Architect. Cada módulo se sostiene por sí solo. Anterior: La estrategia de organizaciones es una decisión del panorama · Siguiente: el próximo capítulo, Calidad y gobierno de datos

La pregunta que responde este módulo: ¿Qué nos dice un panorama real antes de diseñar nada?

Este capítulo ha ido alejando la cámara: Salesforce como un sistema entre muchos, los tipos de datos, los sistemas alrededor de Salesforce, cómo dibujar el panorama y la estrategia de organizaciones. Ahora juntémoslo en Steve Trucking. Pero todavía no vamos a arreglar nada. Esa es la disciplina: dibuja lo que existe, recorre cada flecha y mira lo que te dice el panorama.

Empieza por lo que sabemos

Steve Trucking tiene una organización de Salesforce, en EE. UU. Service Cloud gestiona los casos de los destinatarios y de los socios minoristas; Field Service lleva las citas, los equipos y la aplicación móvil; Experience Cloud da a los socios minoristas un portal, que hoy se usa solo para reclamos e informes; Sales Cloud lleva el seguimiento de los contratos con los socios y de las ofertas para nuevos centros de distribución. Así que Salesforce va en el centro.

A la izquierda, las personas: 45 coordinadores de despacho que trabajan dentro de los centros de distribución de los socios minoristas, unos 700 miembros de equipo en 330 camiones, 60 agentes de atención al cliente, 40 personas de operaciones, finanzas y ventas, y unos 300 usuarios de los socios minoristas. Eso ya nos dice algo: no es un CRM departamental. Es una plataforma operativa para la mayor parte del negocio. Pero sigue siendo una caja. Ahora veamos qué la rodea.

Click to enlarge

Steve Trucking hoy, antes de una implementación como corresponde. Cada manifiesto cae en RouteDesk; los coordinadores vuelven a teclear las rutas en Salesforce y las paradas completadas de vuelta, a mano; a FleetLink le falta su conexión.

Marca lo que está mal

Este es un estado actual, antes de una implementación como corresponde, y lo digo en el dibujo. Luego abro la paleta. En el panorama de un sistema terminado no uso el rojo; en un estado actual, sí. El rojo marca un proceso malo o inadecuado, la línea discontinua marca algo que se hace a mano, y los puntos rojos marcan una conexión que falta. Dejar fuera una flecha también dice algo. Nada de esto es decoración: cada línea roja es un requisito esperando a que lo escriban.

Tres socios, tres integraciones

Los tres socios minoristas envían los manifiestos de tres formas distintas, así que dibuja cada uno por separado.

Keystone deja cada tarde un manifiesto CSV en un servidor SFTP, para entregar dos días después, y quiere un archivo de estado de vuelta cada noche. Dos flechas: el manifiesto entra por archivo, abierta por Keystone, y el estado sale por archivo, abierta por RouteDesk. Asíncrono, con una ventana de tiempo amplia.

Redrock envía los manifiestos mediante una API REST y espera actualizaciones de estado por webhook a medida que ocurren. Dos flechas, dos mecanismos: Redrock llama para enviar los manifiestos a través de la API, y RouteDesk llama para enviar el estado a través del webhook. Casi en tiempo real.

Brightwave envía archivos EDI a través de una red de terceros y espera mensajes de estado EDI de vuelta. Otro formato, otro mecanismo.

Los mismos conceptos de negocio (manifiesto, entrega, estado), tres integraciones completamente distintas. No simplifiques el dibujo porque te gustaría que fueran consistentes. No lo son. Ese es el estado actual.

Luego recórrelas. Keystone: ¿cómo se autentica la conexión SFTP, dónde cae el archivo, qué lo recoge, cómo sabemos que se procesó el archivo completo, qué pasa con una fila mala y cómo se entera Keystone de un cambio antes del archivo de esta noche? Redrock: ¿cómo se autentica la API, qué pasa cuando cualquiera de los dos lados está caído, qué cuenta como un webhook exitoso, y si el mismo estado llega dos veces? Brightwave: ¿quién opera la red EDI, dónde está la traducción, qué acuses de recibo vuelven? No estamos rediseñando nada. Estamos descubriendo las preguntas. Ese es el trabajo del panorama.

RouteDesk sigue ahí

RouteDesk es la herramienta de escritorio heredada de despacho y planificación de rutas que los coordinadores usan en cada centro de distribución para convertir los manifiestos en rutas. Guarda ocho años de historial de entregas, y está previsto retirarla. Dibújala igual. Un error común es dejar fuera el sistema “del que nos vamos a deshacer”. ¿Cuándo? Supongamos que la respuesta es dieciocho meses. Entonces forma parte de la arquitectura al menos durante dieciocho meses, y sus ocho años de historial, unos cinco millones de entregas, no desaparecen cuando desaparece la aplicación. Y mira lo que deja al descubierto el panorama: RouteDesk y Salesforce no están conectados. Los equipos trabajan sus paradas en la aplicación de Field Service de Salesforce, pero las rutas se arman en RouteDesk, así que los coordinadores las vuelven a teclear en Salesforce cada tarde y luego vuelven a teclear las paradas completadas en RouteDesk para que pueda enviar el estado a los socios. Unas 3.300 paradas al día, dos veces, a mano. Eso va discontinuo y en rojo en el dibujo. También te dice que el webhook “a medida que ocurren” de Redrock no es realmente a medida que ocurren. ¿De qué es dueña RouteDesk hoy? ¿Qué depende de ella? ¿Qué historial tiene que sobrevivirla, y dónde: Salesforce, el almacén de datos, un archivo? Todavía no estamos respondiendo. El panorama solo dejó al descubierto las preguntas.

FleetLink es una isla

FleetLink, la plataforma de telemática, recibe el GPS de cada camión: unas 200.000 lecturas al día, cada camión, cada minuto que está en marcha. Y no está conectada a nada. Los coordinadores la miran en una pantalla aparte. Así que dibuja FleetLink sin flechas. Ninguna línea de integración mágica porque creemos que debería haberla.

Luego cuenta los ceros: 200.000 al día son más de 70 millones al año. Eso no es “tenemos datos de GPS”. Es una fuente de streaming con muchos ceros, fuera de la experiencia de Salesforce. ¿Necesita Salesforce 70 millones de lecturas al año? Probablemente no todas. Es una pregunta de diseño para más adelante.

Finanzas tiene su propia verdad

El ERP de finanzas factura a cada socio minorista por entrega, instalación y retiro, y paga los incentivos de los equipos. Y los recuentos de entregas le llegan a través de una hoja de cálculo mensual. Dibuja la hoja de cálculo. No la reemplaces por una ordenada flecha de API porque somos arquitectos y sabemos más; es parte de la arquitectura actual. Y una vez dibujada, llegan las preguntas: ¿quién la hace, a partir de qué sistema, quién la revisa, qué pasa si una entrega cambia después de enviarla, y qué número gana? Hay dinero atado a las respuestas.

Snowflake recibe una exportación semanal

Snowflake guarda la analítica de operaciones y finanzas, alimentada por una exportación semanal. Snowflake no puede hacerlo por sí mismo; algo en el medio lo hace: un trabajo de exportación programado, que corre fuera de Salesforce, saca los datos a través de la Bulk API y los carga en Snowflake. Dónde vive la analítica depende de dónde viven los datos, y Snowflake ya es el hogar analítico. Pero el ritmo también nos dice algo. “¿Qué pasó el mes pasado?”. Una alimentación semanal está bien. “¿Dónde está esta entrega ahora mismo?”. Snowflake no es por donde yo empezaría. La misma empresa, otra carga de trabajo, otra actualidad de los datos, otra respuesta.

La identidad no llega a todos de la misma manera

El proveedor de identidad corporativo va encima de Salesforce. El personal de oficina usa el inicio de sesión único. Pero los coordinadores y los equipos inician sesión con credenciales de Salesforce. Así que una sola línea de confianza del IdP a Salesforce escondería la mitad de la historia. La pregunta real es qué usuarios inician sesión por qué camino, y eso pertenece al panorama.

La experiencia del destinatario tiene un hueco

El proveedor de SMS y correo electrónico envía a los destinatarios un mensaje genérico de “tu entrega es mañana” desde RouteDesk. No hay enlace de seguimiento. Mientras tanto hay unos 180.000 casos al año, y alrededor del 60 % son “¿dónde está mi entrega?”: unos 108.000 casos al año haciendo la misma pregunta. Ahora pon eso junto a FleetLink. La empresa sabe dónde están sus camiones. Sus destinatarios siguen llamando para preguntar. Y el sistema que lo sabe no está conectado con el que responde. Todavía no necesito diseñar la solución. El panorama ya está contando la historia.

Pon los ceros en el inventario

Ahora cuenta lo que se mueve. Como en el módulo 4, los ceros no van en las flechas; van en el inventario detrás del dibujo, donde determinarán los mecanismos cuando diseñemos. Alrededor de un millón de entregas al año, unas 3.300 al día, creciendo un 30 % anual; unas 1,6 partidas cada una; unas ocho actualizaciones de estado cada una, así que hoy ocho millones de actualizaciones de estado al año; de cuatro a cinco millones de fotos al año, hoy en los teléfonos personales de los equipos; unas 200.000 lecturas de GPS al día; unos 180.000 casos al año. Una flecha con la etiqueta “estado de la entrega” no es un mensaje ocasional. Las cajas te dicen qué existe. Las flechas te dicen qué se mueve. Los ceros te dicen si tus supuestos sobreviven a la realidad.

Click to enlarge

El inventario detrás del panorama de Steve Trucking: el volumen junto al mecanismo que determinará.

Todavía no hay arquitectura objetivo, y ya puedo ver dónde viven los datos importantes, de qué tipo son, qué tan rápido se mueven y cómo los intercambian los sistemas.

Más allá del examen: lo que cambia la IA. Supón que Steve Trucking construye un agente para responder el “¿dónde está mi entrega?” de un destinatario. ¿A qué sistema debería preguntar? Salesforce conoce la cita, FleetLink sabe dónde está el camión, el manifiesto del socio definió la entrega. El panorama actual es el mapa del agente, y antes de que el agente pueda responder con seguridad, el arquitecto tiene que saber qué sistema es la referencia para cada dato y qué tan actual es. Apunta un agente a la fuente equivocada y los datos desactualizados se convierten en una respuesta segura de sí misma.

Lee el dolor, todavía no lo arregles

Da un paso atrás. Tres socios, tres estilos de integración. Una herramienta de despacho heredada con ocho años de historial, y coordinadores que vuelven a teclear 3.300 paradas al día en Salesforce y de vuelta. Una plataforma de telemática con 200.000 lecturas al día, desconectada. Finanzas contando entregas a partir de una hoja de cálculo mensual. La analítica con una semana de retraso. Inicio de sesión único para algunos usuarios, no para otros. Ningún enlace de seguimiento, y 108.000 casos al año preguntando dónde está una entrega. Todo creciendo un 30 % anual.

Es mucha arquitectura sacada de un solo dibujo. La tentación es empezar a arreglarlo. No lo hagas. Todavía no. Quiero que te sientas cómodo dejando feo un diagrama del estado actual, porque a veces el estado actual es feo. La idea no es impresionar a nadie con un dibujo limpio; es tener una comprensión compartida de la realidad. Rediseña mientras documentas y pierdes la línea de base. Más adelante quiero poder decir: esto es lo que existía, este es el problema que resolvimos, esto es lo que cambiamos y por qué. El capítulo 6 empieza a tomar decisiones sobre la propiedad y la identidad, y el Punto de control 1 junta la Parte 1. El curso Integration Architect diseña a fondo los flujos con los socios.

Lo que decide aquí un arquitecto

En esta etapa el arquitecto no está decidiendo la arquitectura objetivo. La decisión es si el estado actual se entiende lo bastante bien como para diseñar una:

• Qué sistemas, poblaciones de usuarios, almacenes de datos y socios externos existen realmente hoy.
• Qué datos cruzan cada frontera importante, en qué dirección, con qué frecuencia y por qué mecanismo.
• Dónde viven ahora los datos operativos, analíticos, de streaming, históricos y no estructurados.
• Qué flujos llevan más volumen y merecen atención temprana.
• Qué huecos, pasos manuales, sistemas desconectados, autoridades poco claras y patrones inconsistentes se convierten en preguntas de diseño explícitas.

Este capítulo empezó con una idea: dibuja el panorama antes de diseñar la organización. Si hubiera empezado por el modelo de datos de Steve Trucking, podría haber pasado horas con objetos y relaciones mientras FleetLink seguía afuera con 200.000 lecturas al día, RouteDesk guardaba ocho años de historial, tres socios hablaban tres idiomas, finanzas usaba una hoja de cálculo y cien mil casos al año preguntaban dónde estaba una entrega. No son preguntas de modelo de objetos. Son preguntas de datos de la empresa. Dibuja las integraciones feas, la hoja de cálculo, el sistema que supuestamente vas a retirar. Anota los ceros. Recorre cada flecha. Entonces estarás listo para cambiarlo.

Explora

• El planteamiento de Steve Trucking, secciones 2 a 4, y su diagrama del panorama.