Caso cerrado, falla en el predio: servicio sin orden de campo

Un cliente pagó la deuda hace dos días y la vivienda sigue sin energía. Otro firmó el contrato de un local nuevo y todavía espera la conexión. Un tercero pidió revisar el medidor de su comercio. En los tres casos el centro de atención hizo su parte: registró la solicitud, la clasificó, la derivó y la cerró. El tablero muestra todo en verde.

En la calle, en cambio, ninguna cuadrilla salió. La reconexión no se ejecutó, el local sigue sin servicio y nadie revisó el medidor. El caso figura cerrado; el trabajo sigue pendiente.

Este artículo abre una serie de seis piezas sobre un problema concreto de las utilities de América Latina: la solicitud que exige una visita de campo y se queda en el escritorio porque el caso de servicio no genera la orden de trabajo. Aquí planteamos el problema; las piezas siguientes lo irán resolviendo por etapas.

Cuando la llamada termina y el trabajo no empieza

En Consultoría Venezuela vemos este patrón una y otra vez en distribuidoras de energía, agua y gas de la región. La atención al cliente y la operación de campo funcionan bien cada una por su lado; el problema es que nadie las conecta. El caso de servicio vive en un sistema, la orden que despacha a un técnico vive en otro, y entre ambos suele haber un correo, una planilla, una llamada al supervisor o un reingreso manual.

Lo engañoso es dónde se nota. No en los indicadores de atención, porque el caso sí se cerró, sino después: cuando la misma solicitud vuelve a entrar una semana más tarde, cuando el cliente llama de nuevo y más molesto, cuando la reconexión tarda más de lo prometido o la inspección nunca se programa. Y para una utility latinoamericana que pelea a la vez por la recaudación, por reducir pérdidas no técnicas y por cumplir exigencias regulatorias de calidad comercial, ese hueco golpea en los tres frentes.

Tres solicitudes que solo se cierran con una cuadrilla

No toda solicitud necesita un técnico, pero estas tres, por definición, solo se resuelven en el terreno. En el corte y la reconexión física, la decisión comercial se toma en el sistema y la ejecución ocurre en una caja de distribución o en una válvula: una reconexión que no llega a la cuadrilla es un cliente que pagó y sigue sin servicio. En una conexión nueva, el contrato firmado y la cuenta creada no alcanzan; el servicio no existe hasta que alguien instala y conecta. Y cuando hay que revisar o reemplazar un medidor, la respuesta está en la visita y no en la pantalla del agente: mientras nadie la ejecute, la empresa factura sobre supuestos.

Las soluciones de servicio de campo para utilities contemplan justamente este repertorio: la aplicación móvil del técnico se usa para informarle sobre instalación, retiro y reemplazo de medidores, corte y reconexión, altas y bajas de ocupantes o lecturas, y para devolver la confirmación correspondiente (Evora IT Solutions, 2023). La misma fuente describe la dificultad típica del sector: tener que usar varias aplicaciones distintas desde la planificación de rutas hasta recibir del técnico la confirmación de materiales, lecturas y esfuerzo (Evora IT Solutions, 2023).

Cuatro puntos donde se pierde la orden

El problema rara vez es la falta de sistemas; es la falta de un disparador confiable entre ellos. Cada etapa del recorrido tiene su propio punto débil. Primero, el agente describe la solicitud en texto libre y alguien en operaciones tiene que reinterpretarla para crear la orden. Después, el caso suele darse por resuelto al derivarse, no al ejecutarse el trabajo. Luego, la orden puede quedar en una bandeja sin técnico ni fecha. Y al final, aunque el técnico ejecute y confirme, esa confirmación puede no volver nunca al caso, de modo que el cliente no se entera. Cualquiera de esos quiebres basta para que una solicitud resoluble se vuelva recurrente.

Lo que la integración estándar sí documenta

La buena noticia es que el ecosistema SAP tiene un camino documentado para cerrar ese recorrido. SAP Field Service Management —que SAP presentó en 2026 como SAP Field Service and Asset Management, una evolución del mismo producto (SAP, 2026; SAPinsider, 2026)— es una solución en la nube para planificar trabajo de servicio y mantenimiento con foco en técnicos, habilidades, tiempos de traslado y clientes (Evora IT Solutions, 2025). Cubre el proceso desde el disparo del servicio, pasando por la planificación y programación de técnicos y la ejecución en campo, hasta la liquidación de los datos hacia el backend (Evora IT Solutions, 2025). Puede operar sola o integrada con los módulos de Plant Maintenance y Customer Service, o con SAP Service Cloud (Evora IT Solutions, 2025).

En el escenario que combina SAP Service Cloud (C4C), SAP S/4HANA Service y SAP Field Service Management, el recorrido es este: si el ticket requiere intervención en sitio, se crea una orden de servicio de seguimiento en SAP S/4HANA; tras su liberación, la orden se replica en SAP Field Service Management y queda visible en el tablero de planificación; el técnico, asignado de forma automática o manual, la recibe como notificación en su aplicación móvil, registra esfuerzo, repuestos y gastos, y el cliente firma el resumen de la orden; una vez liberados repuestos y gastos, SAP S/4HANA genera la confirmación de servicio.

Este recorrido lo describe una consultora que implementa soluciones SAP, a propósito de la integración entre SAP Service Cloud, SAP S/4HANA Service y SAP Field Service Management (IBsolution, 2021). Es una descripción funcional de 2021: los detalles de configuración vigentes deben confirmarse en la documentación actual de SAP antes de diseñar el proyecto.

Aquí aparece la verdad incómoda: la automatización existe, pero depende de un disparador. La orden solo llega al tablero de planificación del despacho después de liberada (IBsolution, 2021). Si la solicitud nunca se convierte en una orden liberada, ningún técnico se entera. La tecnología no compensa un caso que se cerró sin generar trabajo.

---
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([Solicitud que exige visita]) --> B{¿Orden liberada?}
  B -->|Sí| C[Llega al tablero de planificación]
  C --> D([El despacho puede asignar técnico])
  B -->|No| E[Caso cerrado sin generar trabajo]
  E --> F([Ningún técnico se entera])
  class A inicio
  class B decision
  class C,E proceso
  class D bueno
  class F malo
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
classDef malo fill:#462226,stroke:#ef4444,color:#ffffff

Un matiz importante para quien evalúa este camino: SAP Field Service Management es una solución en la nube que se suma al ERP, con su propio alcance de implementación e integración. Conviene dimensionarla como proyecto, no como un ajuste de configuración, y validar con SAP el licenciamiento aplicable a cada paisaje.

Cuatro preguntas para el gerente de operaciones

Antes de discutir herramientas, vale la pena medir la operación actual: qué proporción de las solicitudes que exigen visita termina realmente en una orden de trabajo liberada, cuánto tiempo pasa entre el registro del caso y el despacho de una cuadrilla, cuántos casos se cierran sin una confirmación de campo asociada y cuántas solicitudes de reconexión, conexión nueva o revisión de medidor se reabren por el mismo motivo.

Si la empresa no puede responder esas preguntas con datos de su propio sistema, ahí está el primer hallazgo: el recorrido no solo está roto, además es invisible.

Lo que viene en esta serie

En la próxima pieza bajamos al primer eslabón: de la orden de servicio a la llamada de campo, y cómo se traduce un caso en trabajo asignable.

Fuentes

• Evora IT Solutions (2025). SAP Field Service Management. https://www.evorait.com/sap-solutions/sap-field-service-management/
• Evora IT Solutions (2023). SAP FSM for Utilities. https://www.evorait.com/solutions/scheduling/sap-fsm-for-utilities/
• IBsolution (2021). How to integrate SAP FSM into existing SAP systems. https://www.ibsolution.com/academy/blog_en/integrate-sap-fsm-into-existing-sap-systems
• SAP (2026). SAP Field Service and Asset Management: The Next Evolution of SAP Field Service Management. SAP Community. https://community.sap.com/t5/supply-chain-management-blog-posts-by-sap/sap-field-service-and-asset-management-the-next-evolution-of-sap-field/ba-p/14392023
• SAPinsider (2026). Accrete Consulting Solutions Maps Service Transformation to SAP’s New Field Service and Asset Management. https://sapinsider.org/blogs/accrete-sap-field-service-asset-management/

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