SAP

La buena idea que muere en el backlog: el costo de esperar a TI

En utilities y oil & gas de LATAM, las mejoras pequeñas de alto valor mueren en la fila de TI. Por qué ocurre y qué le cuesta a la operación.

EvoTech
EvoTech Consulting Company

· 11 min de lectura

Supervisor de campo de una empresa de servicios públicos espera turno en un pasillo, con una planilla en la mano y un reloj de pared al fondo

Un supervisor de cuadrillas nota que sus técnicos anotan a mano el estado del medidor retirado y lo digitan en el sistema al final del turno. Propone algo simple: un formulario en el celular que capture el dato en sitio. Nadie rechaza la idea y nadie duda de cómo hacerla. Meses después sigue sin construirse, porque en la empresa solo un equipo puede construir y su agenda está tomada.

Con este artículo, EvoTech Consulting abre una serie de seis piezas sobre ese problema en las utilities y las empresas de oil & gas de América Latina: TI convertida en el único constructor de cada mejora, sin importar su tamaño. No hablamos de agregar un campo o ajustar una pantalla dentro de SAP S/4HANA. Hablamos de aplicaciones, formularios y flujos de aprobación pequeños que viven alrededor del sistema y que hoy esperan turno junto a los proyectos mayores. Aquí planteamos el dolor de negocio; las piezas siguientes lo irán resolviendo por etapas.

Un solo constructor para toda la demanda

En la mayoría de las organizaciones que operan sobre SAP, todo lo que hay que construir termina en el mismo equipo de desarrollo profesional. La regla tiene sentido para lo que toca la facturación, el recaudo o la continuidad operativa. El problema aparece cuando se aplica también a un formulario de inspección, que pasa a competir por las mismas personas que la adecuación a un cambio regulatorio, la integración con la medición inteligente o la migración a SAP S/4HANA.

Un solo constructor
La misma regla, dos resultados distintos
Donde aparece el problema
Qué se construye Un formulario de inspección
Con qué compite La adecuación a un cambio regulatorio, la integración con la medición inteligente o la migración a SAP S/4HANA
Donde la regla tiene sentido
Qué se construye Lo que toca la facturación, el recaudo o la continuidad operativa
Quién lo construye El equipo de desarrollo profesional, el mismo donde termina todo lo demás
EL PROBLEMALA REGLA TIENE SENTIDO

Y esas personas escasean en la región. En Colombia, por ejemplo, el mercado demanda cerca de 85.000 talentos digitales adicionales, según Fedesoft en la presentación oficial del Estudio de Empleabilidad y Talento Digital que elaboró con el Ministerio TIC (MinTIC, 2025). La firma de talento tecnológico Avos Tech describe la misma magnitud: una demanda insatisfecha cercana a 85.000 profesionales de TI (Portafolio, 2026). El desarrollo de software figura entre las especialidades más difíciles de cubrir, y la misma nota registra una demanda creciente de profesionales en soluciones SAP (Portafolio, 2026). La consecuencia la describe la propia firma: una vacante abierta puede retrasar proyectos y frenar iniciativas de automatización (Portafolio, 2026).

Por qué la idea pequeña queda siempre al final

No hay mala voluntad detrás: es aritmética de capacidad. En nuestros proyectos vemos que la fila de TI suele ordenarse en cinco turnos:

La fila de TI
Cinco turnos, del primero al último
1
Obligaciones con fecha
Cambios regulatorios y tarifarios que no admiten retraso
2
Incidentes de producción
Lo que detiene la facturación o el recaudo
3
Integraciones
Medición inteligente y sistemas que deben conversar con SAP
4
Migración y proyectos mayores
Presupuesto aprobado y patrocinio de la gerencia
5
Mejoras pequeñas de la operación
Sin fecha, sin patrocinador y con beneficio disperso

Tres razones mantienen a la mejora pequeña en el último turno:

  • Un solo tipo de constructor. Mientras todo deba pasar por desarrollo profesional, cada hora dedicada a un formulario se le quita a una iniciativa mayor. Postergarlo es la decisión racional.
  • Una comparación desigual. Frente a una fecha regulatoria o a un incidente, la mejora pequeña nunca es urgente.
  • Un valor que nadie defiende. El beneficio es real, pero se reparte en minutos por orden de trabajo entre muchas cuadrillas, y no llega al comité con un patrocinador.

Cada decisión, tomada por separado, es razonable. Sumadas, hacen que la organización filtre sus mejoras por tamaño y no por valor.

Lo que cuesta la espera en campo, reclamos y activos

Tres frentes operativos
Por dónde viaja hoy cada dato
📋
Trabajo de campo
Qué viaja
Datos de inspecciones, retiros y normalizaciones
↓
Por dónde
En papel; se digitan después, con retrasos y errores
↓
Qué está en juego
Las órdenes de trabajo y la gestión de pérdidas no técnicas
✉️
Atención de reclamos
Qué viaja
Aprobaciones de ajustes y derivaciones entre áreas
↓
Por dónde
Por correo; el caso avanza al ritmo de quien revisa su bandeja
↓
Qué está en juego
Los plazos que el regulador vigila
🔧
Seguimiento de activos
Qué viaja
Novedades de equipos
↓
Por dónde
Por mensajería; nunca llegan al registro maestro
↓
Qué está en juego
El plan de mantenimiento, que se decide con información incompleta

El costo de este filtro no aparece en ningún presupuesto, porque es el costo de lo que no se hizo. Nuestra práctica SAP lo encuentra, sobre todo, en los tres frentes operativos del cuadro: el trabajo de campo, la atención de reclamos y el seguimiento de activos. En los tres se repite el patrón: el dato viaja por papel, correo o mensajería, y llega al sistema tarde, con errores o no llega.

Ninguna de estas mejoras justifica un proyecto. Sumadas y sostenidas en el tiempo, marcan la distancia entre la operación que se diseñó y la que ocurre todos los días. Para una empresa de servicios públicos con presupuesto acotado, esa distancia se paga en recaudo, en calidad del dato y en horas del personal más experimentado.

El cuello de botella no es solo suyo

La presión es general en la comunidad SAP. La investigación de SAPinsider sobre SAP Business Technology Platform, de alcance global y no regional, muestra hacia dónde se están moviendo las organizaciones:

Comunidad SAP
Hacia dónde se mueven las organizaciones
57%
de los encuestados usa herramientas de desarrollo low-code
(SAPinsider, 2025)
37%
de los encuestados usa o evalúa SAP Build
(SAPinsider, 2025)
47%
de los encuestados cita capacidades de desarrollo low-code/no-code y pro-code como requisito en sus planes de plataforma empresarial
(SAPinsider, 2025)
Encuesta de alcance global, no regional.

La lectura para un ejecutivo de la región no es que una herramienta esté de moda. Es que muchas organizaciones llegaron al mismo diagnóstico: la capacidad de desarrollo profesional no alcanza para todo, y conviene reservarla para lo que solo ella puede resolver.

SAP Build es la suite de desarrollo de SAP sobre SAP Business Technology Platform, y sus herramientas de bajo código son tres: SAP Build Apps, SAP Build Process Automation y SAP Build Work Zone (SAPinsider — Understanding SAP Build, 2025; SAP Licensing Experts, 2026). Hoy SAP presenta el portafolio como herramientas low-code, pro-code y de IA generativa, e incluye también SAP Build Code para desarrollo profesional (SAP — SAP Build innovations, consultado en octubre de 2026). Su premisa es que los equipos puedan prototipar y desplegar aplicaciones sencillas sin depender por completo de TI (SAPinsider — Understanding SAP Build, 2025).

Conviene una advertencia de costo desde ahora: SAP Build no es gratuito. Según la asesoría independiente SAP Licensing Experts, se licencia sobre SAP BTP, por suscripción o por consumo, y los derechos de uso que acompañan a RISE with SAP y GROW with SAP corresponden a una capacidad inicial que varía según el paquete contratado (SAP Licensing Experts, 2026). Liberar presupuesto de TI exige contar ese consumo dentro del caso de negocio y validarlo contra el contrato propio.

Sin vía formal, el control también se pierde

De la fila al riesgo
Cómo una idea sin turno se vuelve un problema de control
⏳
Sin turno
La idea no encuentra lugar en la fila, pero rara vez desaparece.
›
🛠️
Se construye por fuera
Con las herramientas que la operación tenga a mano.
›
🔀
Cambia el problema
Deja de ser de productividad y pasa a ser de control.
›
🔓
Información sensible en circulación
Datos comerciales del cliente sin auditoría, sin control de versiones y sin mínimo privilegio.
Democratización controlada: TI define qué puede construir el negocio, con qué datos y bajo qué reglas.

La secuencia es conocida: lo que no encuentra turno se construye por fuera, con las herramientas que la operación tenga a mano, y el problema pasa de la productividad al control. Por esas herramientas circula información comercial sensible del cliente sin auditoría, sin control de versiones y sin el principio de mínimo privilegio que TI sí aplica dentro de SAP.

Los usuarios de negocio quieren agilidad y los equipos de TI necesitan control (SAPinsider — Understanding SAP Build, 2025); cuando el único constructor autorizado no da abasto, la agilidad se busca por fuera y el control se pierde.

Por eso en EvoTech Consulting hablamos de democratización controlada: no se trata de quitarle la llave a TI, sino de que TI defina qué puede construir el negocio, con qué datos y bajo qué reglas.

Cinco mediciones sobre su propia fila

Diagnóstico del backlog
Cinco mediciones antes de hablar de herramientas
📅
Solicitudes sin fecha
Las pequeñas que llevan más de un ciclo de priorización sin fecha asignada.
Cuántas
🧭
Origen y destino
La parte del backlog que nació en campo, reclamos o mantenimiento, y cuánta llegó a producción.
Qué parte
⏱️
Horas de desarrollo
Las horas de desarrollo profesional dedicadas a formularios y flujos de aprobación.
Cuántas horas
🔍
Herramientas no autorizadas
Si TI sabe cuáles usa la operación para cubrir esos vacíos.
¿Lo sabe TI?
🔑
Quién puede construir
Quién está autorizado además del equipo de desarrollo. Si la respuesta es «nadie», el backlog ya decide qué mejoras existen y cuáles no.
Quién

Antes de hablar de herramientas, vale la pena mirar el backlog con otros ojos y responder cinco preguntas: cuántas solicitudes pequeñas llevan más de un ciclo de priorización sin fecha asignada; qué parte del backlog nació en campo, reclamos o mantenimiento, y cuánta de ella llegó a producción; cuántas horas de desarrollo profesional se dedican a formularios y flujos de aprobación; si TI sabe qué herramientas no autorizadas usa la operación para cubrir esos vacíos; y quién, además del equipo de desarrollo, está autorizado para construir algo.

Si la respuesta a la última pregunta es «nadie», el backlog ya está decidiendo qué mejoras existen y cuáles no.

Lo que sigue en esta serie

Depender solo de TI para cada mejora no protege al sistema: traslada el riesgo a la operación y consume en cambios menores la capacidad que deberían recibir las iniciativas complejas. Reconocer el problema es el primer paso. La siguiente pieza de esta serie aborda el segundo: «Construir sin escribir código ABAP: qué puede hacer el negocio por sí mismo con las herramientas de bajo código».

Fuentes

Conversemos 30 minutos

¿Este análisis mapea un mercado donde ya operas o estás evaluando entrar?

Revisamos tu caso específico, mapeamos los riesgos que aplican, y te decimos honestamente si es oportunidad para ti —sin pitch comercial, solo discusió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.

EvoTech Consulting Company · AGT Consultoría
#sap build #low-code #backlog de ti #utilities #oil and gas #sap btp #innovación operativa