Ir al contenido principal
SAP

Despacho en SAP FSM: asignar al técnico no basta, hay que liberar

Cómo el dispatcher de SAP Field Service Management asigna y libera la actividad de campo, y qué datos vuelven a SAP S/4HANA en reclamos de utilities.

Edward Camacho Guerra
Edward Camacho Guerra

CEO / Arquitecto de Soluciones SAP

· 14 min de lectura

Despachador de una empresa de servicios públicos reorganiza turnos de técnicos en un tablero magnético de taller mientras consulta una tableta

En el tablero del planificador, la actividad ya muestra el nombre de un técnico en su franja horaria. En el teléfono de ese técnico, en cambio, no aparece nada. Para el centro de atención de una utility latinoamericana, ese desfase explica más de una visita prometida que nunca ocurrió: un medidor por revisar, una reconexión pendiente, una acometida nueva que espera. En SAP Field Service Management, poner un nombre en el calendario y entregar el trabajo son dos gestos distintos: la llamada llega a la aplicación móvil del técnico recién cuando ha sido asignada y, además, liberada desde la aplicación de planificación y despacho (SAP Community, 2019).

Esta entrega se queda en el tablero del dispatcher: qué decide, qué cambia con cada clic y qué ve después el centro de atención.

Tres objetos en el tablero del planificador

SAP Field Service Management distingue con precisión tres objetos que en la operación diaria suelen confundirse. La llamada de servicio es el ticket que inicia la solicitud del cliente; la actividad es el trabajo concreto que debe ejecutar el técnico; y cuando esa actividad se asigna a un técnico, pasa a ser una asignación de servicio (SAP Learning, s. f.).

Para el planificador de una utility, la consecuencia es práctica. Un mismo reclamo puede abrir varias tareas —verificar el medidor, reemplazarlo, normalizar la acometida— y cada una se agenda, se asigna y se libera por separado. El tablero no ordena reclamos: ordena tareas con dueño y horario.

Esta pieza arranca cuando esas tareas ya están en la lista del planificador; cómo llegaron hasta ahí lo cubrió la entrega anterior de la serie.

Asignar no es despachar: el paso de liberación

El dispatcher trabaja sobre el tablero de planificación, un calendario dinámico con las agendas de los técnicos donde se arrastran asignaciones, se ajustan horarios y se liberan las llamadas de servicio (SAP Learning, s. f.). Antes de elegir a quién enviar, puede revisar y confirmar los detalles de la llamada, y sumar recordatorios y adjuntos útiles para el técnico (SAP Learning, s. f.).

La elección del técnico admite distintos grados de automatización: manual, automática o asistida, en cuyo caso el sistema sugiere al técnico que mejor se ajusta a la actividad (SAP Learning, s. f.). El mapa de servicio, además, permite ubicar al técnico más cercano para asignarle una llamada (SAP Learning, s. f.).

Lo decisivo viene después. En el flujo de integración que describe SAP, el dispatcher asigna la llamada considerando la naturaleza del caso y, una vez completada la asignación, la libera para que los técnicos puedan trabajarla (SAP Community, 2020). En términos de turno: un nombre sin liberar es un borrador de agenda; liberado, es una orden de salir. Para cerrar la planificación de una jornada completa, el tablero permite seleccionar varias actividades pendientes y liberarlas en bloque (SAP Learning, s. f.).

Cuando el botón de liberar no libera

Hacer clic no garantiza que la liberación ocurra. Un artículo de conocimiento de SAP documenta un caso concreto: con usuarios del tipo PARTNER_TECHNICIAN, el tablero no logra liberar las asignaciones. El botón reacciona y muestra un mensaje de éxito, pero la actividad sigue sin liberar, y la causa está en la configuración de crowd (SAP KBA 3708694, s. f.). Si la utility despacha a técnicos de empresas contratistas modelados de esa forma, la regla operativa es clara: lo que confirma que el trabajo salió es el estado real de la actividad, no el mensaje en pantalla.

Qué cambia en el origen cuando el dispatcher libera

La liberación también se nota del otro lado. En el escenario documentado, cuando la asignación se libera, fluye hacia SAP S/4HANA Cloud Public Edition una actualización con el técnico y las fechas planificadas de inicio y fin; los cambios sobre una actividad todavía sin liberar solo se replican en el momento en que se libera (SAP Learning, 49X, s. f.). El ítem de servicio, además, refleja el avance con un estado de ejecución propio: mientras la actividad espera, figura en planificación; al liberarse, pasa a ejecución (SAP Learning, 49X, s. f.).

Para el agente que atiende la segunda llamada del cliente, eso cambia la conversación. Ya no tiene que suponer: ve en el sistema de origen si la visita salió del borrador, cuándo está programada y quién la hará, sin abrir otra herramienta.

El alcance conviene precisarlo: el escenario descrito corresponde a SAP S/4HANA Cloud Public Edition (proceso de solución 49X). Si la operación corre sobre otra edición de S/4HANA o sobre un landscape IS-U heredado, el camino de retorno debe validarse en el diseño de integración de cada proyecto, no asumirse.

Reasignar, desasignar, modificar: donde se pierde la trazabilidad

Excepciones del flujo feliz
Qué pasa cuando cambia una actividad ya asignada
---
config:
  theme: base
  fontFamily: 'Inter Variable, system-ui, sans-serif'
  themeVariables:
    darkMode: true
    fontFamily: 'Inter Variable, system-ui, sans-serif'
    fontSize: '15px'
    background: '#111113'
    primaryColor: '#1A1A1D'
    primaryTextColor: '#F4F5F8'
    primaryBorderColor: '#8B5CF6'
    secondaryColor: '#242428'
    tertiaryColor: '#1A1A1D'
    mainBkg: '#1A1A1D'
    secondBkg: '#242428'
    tertiaryBkg: '#2E2E33'
    lineColor: '#8B5CF6'
    textColor: '#F4F5F8'
    titleColor: '#F4F5F8'
    nodeBorder: '#8B5CF6'
    clusterBkg: '#1A1A1D'
    clusterBorder: '#2E2E33'
    edgeLabelBackground: '#242428'
    pie1: '#8B5CF6'
    pie2: '#f59e0b'
    pie3: '#22c55e'
    pie4: '#b495f9'
    pie5: '#f97316'
    pie6: '#ef4444'
    pieTitleTextColor: '#F4F5F8'
    pieSectionTextColor: '#F4F5F8'
    pieLegendTextColor: '#F4F5F8'
    pieStrokeColor: '#111113'
    pieOuterStrokeColor: '#111113'
---
flowchart TD
  A([Cambio sobre una actividad asignada]) --> B{Tipo de cambio}
  B -->|Desasignar| C{Comportamiento documentado}
  C -->|General| D([Nueva actividad e ítem sin técnico])
  C -->|Con ajuste| E([Se elimina el empleado ejecutor del ítem])
  B -->|Reasignar| F{¿Ajuste sin copias?}
  F -->|No| G[La actividad liberada pasa a modificado]
  G --> H[Se libera la nueva asignación]
  H --> I([Nueva actividad, anterior cancelada, nuevo ítem con técnico])
  F -->|Sí| J([Se actualiza el ítem existente])
  B -->|Modificar| K{¿Técnico o cuadrilla?}
  K -->|Técnico| L([La asignación pasa a modificado])
  K -->|Cuadrilla| M([La asignación se mantiene liberada])
  class A inicio
  class B,C,F,K decision
  class G,H proceso
  class D,E,I,J,L,M neutro
classDef inicio fill:#30274d,stroke:#8B5CF6,color:#ffffff
classDef decision fill:#473519,stroke:#f59e0b,color:#ffffff
classDef proceso fill:#33363c,stroke:#9aa0aa,color:#ffffff
classDef neutro fill:#33363c,stroke:#9aa0aa,color:#ffffff
El ajuste es «Allow reassigning or unassigning activities without copies». En cuadrillas de corte y reconexión, la señal de cambio en el tablero puede no aparecer.SAP Community, 2020; SAP Learning, 49X, s. f.; SAP KBA 3621833, s. f.

Un turno ordenado exige poco al tablero; las correcciones a mitad de jornada son las que ponen a prueba si el sistema de origen sigue diciendo la verdad. El diagrama resume los tres casos; la tabla muestra qué deja cada uno en Field Service Management y en la orden de S/4HANA Cloud.

Cambio Caso A Caso B Fuente
Desasignar Comportamiento general
Crea una nueva actividad en FSM y el ítem de servicio correspondiente en la orden de S/4HANA Cloud, sin técnico asignado.
Con ajuste «sin copias»
Se elimina el empleado ejecutor del ítem de servicio.
SAP Community, 2020; SAP Learning, 49X, s. f.
Reasignar Sin ajustes adicionales
La actividad ya liberada pasa a estado modificado; al liberar la nueva asignación se crea una actividad nueva, se cancela la anterior y se agrega un ítem de servicio con el técnico.
Con ajuste «sin copias»
Se actualiza el ítem existente en lugar de duplicarlo.
SAP Community, 2020; SAP Learning, 49X, s. f.
Modificar una actividad ya liberada Técnico individual
La asignación pasa a estado modificado.
Cuadrilla
La asignación se mantiene como liberada.
SAP KBA 3621833, s. f.

El ajuste «sin copias» corresponde a la opción «Allow reassigning or unassigning activities without copies» de SAP Field Service Management.

Ese último punto pesa en corte y reconexión, donde es habitual despachar cuadrillas y no técnicos individuales. Si el equipo de planificación usa el color o el estado del tablero como señal de cambio, en asignaciones a cuadrillas esa señal puede no aparecer. Por eso conviene un control explícito sobre cualquier cambio en trabajo ya liberado.

Diseñar el despacho para reclamos de campo en utilities

En los tres casos de esta serie —reclamos de medidor, corte y reconexión física, y nuevas conexiones— el dispatcher decide mejor cuando la tarea llega con el requisito a la vista. Field Service Management permite que las habilidades requeridas se hereden desde el socio comercial, el equipo y el ítem (SAP Learning, s. f.). Si el tipo de medidor o de acometida trae asociada una habilidad, la tarea aparece en el tablero con ese requisito cargado, y los filtros pueden dejar a la vista solo a los técnicos aptos.

A partir de ahí, tres definiciones de proceso suelen marcar la diferencia:

Diseño del despacho en utilities
Tres definiciones de proceso que cierran el loop
🔓
Política de liberación explícita
Definir quién libera, en qué momento y si se hace en bloque al cierre de la planificación diaria o actividad por actividad.
🧭
Trazabilidad de punta a punta
Un identificador que siga el mismo trabajo desde el caso de servicio hasta la asignación y su retorno, para conciliar estados cuando hay reasignaciones.
📡
Monitoreo del retorno
Comprobar que las fechas y el técnico asignado llegaron al sistema de origen; con una integración silenciosa se prometen visitas sin fecha real.

Ninguna de las tres exige funcionalidad adicional. Son acuerdos que se toman en la fase de diseño y que deciden si el loop entre el reclamo y el campo queda cerrado o abierto.

Lo que sigue en la serie

Con la actividad asignada, liberada y visible en el sistema de origen, el siguiente tramo ocurre en el predio. La próxima pieza recorre qué sucede automáticamente cuando el técnico cierra la actividad en campo y cómo ese cierre regresa al caso que la originó.

Vocabulario de SAP FSM
Tres objetos que el tablero no trata igual
📋
Llamada de servicio
El ticket con el que arranca la solicitud del cliente.
Origen
🔧
Actividad
El trabajo concreto que ejecuta el técnico. Un mismo reclamo puede abrir varias: verificar el medidor, reemplazarlo, normalizar la acometida.
Unidad de planificación
👷
Asignación de servicio
La actividad una vez que se asigna a un técnico. El tablero de despacho trabaja sobre actividades, no sobre reclamos.
Técnico asignado
Asignar no es despachar
La misma asignación, antes y después de liberarla
Asignación sin liberar
Qué es Un borrador de agenda
En campo Tiene nombre de técnico, pero en su teléfono no aparece nada
Hacia S/4HANA Sus cambios todavía no se replican
Asignación liberada
Qué es Una orden de salir
En campo Se envía a la aplicación móvil del técnico
Hacia S/4HANA Fluyen el técnico y las fechas planificadas de inicio y fin
SIN LIBERARLIBERADA
Retorno al sistema de origen
Cuándo llega la información a S/4HANA
---
config:
  theme: base
  fontFamily: 'Inter Variable, system-ui, sans-serif'
  themeVariables:
    darkMode: true
    fontFamily: 'Inter Variable, system-ui, sans-serif'
    fontSize: '15px'
    background: '#111113'
    primaryColor: '#1A1A1D'
    primaryTextColor: '#F4F5F8'
    primaryBorderColor: '#8B5CF6'
    secondaryColor: '#242428'
    tertiaryColor: '#1A1A1D'
    mainBkg: '#1A1A1D'
    secondBkg: '#242428'
    tertiaryBkg: '#2E2E33'
    lineColor: '#8B5CF6'
    textColor: '#F4F5F8'
    titleColor: '#F4F5F8'
    nodeBorder: '#8B5CF6'
    clusterBkg: '#1A1A1D'
    clusterBorder: '#2E2E33'
    edgeLabelBackground: '#242428'
    pie1: '#8B5CF6'
    pie2: '#f59e0b'
    pie3: '#22c55e'
    pie4: '#b495f9'
    pie5: '#f97316'
    pie6: '#ef4444'
    pieTitleTextColor: '#F4F5F8'
    pieSectionTextColor: '#F4F5F8'
    pieLegendTextColor: '#F4F5F8'
    pieStrokeColor: '#111113'
    pieOuterStrokeColor: '#111113'
---
flowchart TD
  A([Asignación o cambio en FSM]) --> B{¿Asignación liberada?}
  B -->|Sí| C[Fluye la actualización a S/4HANA Cloud Public Edition]
  C --> D([Técnico y fechas visibles en el origen])
  B -->|No| E[El cambio aún no se replica]
  E --> F[Se libera la asignación]
  F --> C
  class A inicio
  class B decision
  class C,E,F proceso
  class D bueno
classDef inicio fill:#30274d,stroke:#8B5CF6,color:#ffffff
classDef decision fill:#473519,stroke:#f59e0b,color:#ffffff
classDef proceso fill:#33363c,stroke:#9aa0aa,color:#ffffff
classDef bueno fill:#193e2b,stroke:#22c55e,color:#ffffff
Escenario documentado para SAP S/4HANA Cloud Public Edition (proceso de solución 49X); en otras ediciones o en IS-U heredado, el retorno debe validarse en el diseño de integración.SAP Learning, 49X, s. f.

Lecturas relacionadas

Estas piezas ya publicadas complementan el tramo del despacho, desde el reclamo que no llega a campo hasta la gestión del caso en el front office.

Artículo Publicado Qué aporta
Serie · cap. 1
Caso cerrado, falla en el predio: servicio sin orden de campo
17 oct 2026 Por qué un reclamo de medidor o reconexión que no se vuelve orden de campo solo se cierra en papel.
Serie · cap. 2
Orden de servicio a llamada de campo: cómo replica S/4HANA a FSM
26 oct 2026 Cómo la orden liberada en S/4HANA se convierte en llamada y actividad en SAP FSM: el paso previo al despacho.
Cuadrilla de lectura: cómo redistribuirla tras la telemedición 29 oct 2026 La cuadrilla pasa de la ruta de lectura a la excepción —pérdidas, medidores sin reporte, reclamos—: el trabajo que luego hay que despachar.
Cuando el medidor también habla: estatus técnico en el caso 3 oct 2026 Cómo el objeto técnico de IS-U entra al caso de servicio para orientar el reclamo de medidor desde la llamada.
Gobernar el SLA transversal: un caso, un reloj por reclamo 4 sep 2026 El caso único con SLA compartido que evita reaperturas cuando el mismo reclamo entra por varios canales.
Enrutar por habilidad: el caso correcto al agente correcto 29 ago 2026 La asignación por habilidades en el front office, contraparte del filtro de técnicos aptos en el tablero de despacho.

Fuentes

Artículo de Edward Camacho Guerra, elaborado con apoyo de herramientas de inteligencia artificial y revisado y aprobado por el autor.

Conversemos 30 minutos

¿Este análisis describe un mercado donde ya opera o que está evaluando?

Revisamos su caso, mapeamos los riesgos que aplican y le decimos con franqueza si es una oportunidad para usted —sin presentación comercial, solo una conversación técnica y estratégica.

Al enviar aceptas ser contactado por AGT Consultoría para el assessment solicitado. Tus datos no serán compartidos con terceros ni usados para publicidad.

Edward Camacho Guerra · CEO / Arquitecto de Soluciones SAP
#sap field service management #s/4hana #dispatching #servicio de campo #is-u #utilities latam