Cómo una empresa industrial eliminó el papel de sus aprobaciones de compras en SAP
Una compañía industrial gestionaba en SAP MM la aprobación de contratos, solicitudes y pedidos de compra a través de procesos manuales.
Con nuestra solución, los documentos se envían automáticamente a firma en el momento en que se generan, SAP se actualiza en tiempo real tras cada aprobación y los responsables disponen de un monitor nativo para consultar el estado de cualquier flujo sin salir del ERP
Índice del boletín
🔍 Dato Curioso
En 2011, tres investigadores de Harvard, Yale y Duke (Norton, Mochon y Ariely) documentaron algo que llamaron "El Efecto IKEA". El experimento era simple: pedían a personas que montaran muebles de IKEA, construyeran figuras de origami o ensamblaran piezas de LEGO. Luego les preguntaban cuánto valían esas creaciones.
Los participantes pujaron de media un 62% más por sus propias creaciones que por objetos idénticos construidos por otros, aunque los objetos de otros fueran objetivamente de mejor calidad.
Pero lo más interesante fue el experimento con el origami. Los participantes valoraron sus figuras de origami amateur aproximadamente cinco veces más que los observadores externos. Y lo más revelador: valoraron sus torpes grullas de papel casi igual que el origami de nivel experto.
El esfuerzo en sí mismo había alterado fundamentalmente la percepción.
La conclusión del estudio fue que "el esfuerzo por sí solo puede ser suficiente para generar un mayor gusto por los frutos del propio trabajo", independientemente de la calidad objetiva del resultado.
Ahora sustituye el mueble de IKEA por una solución SAP que llevas tres semanas diseñando. Por un desarrollo ABAP que te ha costado sangre, sudor y tres cafés. Por un flujo de proceso que te parece elegante, lógico y perfecto.
¿Crees que serías inmune a este sesgo?
Spoiler: nadie lo es.
📰 Ultimas noticias
SAP Discovery Center: La Puerta de Entrada a la IA que Quizás No Sabías que Existía
Si llevas tiempo escuchando hablar de SAP Business AI, de Joule, de agentes inteligentes y de todo el ecosistema de IA que SAP está construyendo a marchas forzadas, pero no sabes muy bien por dónde empezar ni qué aplicar en tu empresa o en la de tu cliente, SAP tiene una respuesta. Se llama SAP Discovery Center y, sorprendentemente, es gratuito.
SAP Discovery Center es un portal de autoservicio donde clientes potenciales y actuales pueden explorar soluciones SAP Business AI, acceder a aplicaciones y contenido prediseñado, y descubrir casos de uso, servicios, arquitecturas de referencia y buenas prácticas, todo sin coste.
Hasta aquí, suena a la típica página de marketing con mucho color y poco contenido. Pero lo interesante es que va un poco más allá de eso.
El portal incluye herramientas de estimación de coste y ROI donde el usuario introduce información propia de su organización, como personalizaciones, hiperscalers o número de usuarios, y obtiene casos de uso tangibles y personalizados. También incluye evaluaciones de madurez que, basándose en la estrategia de plataforma y el panorama de arquitectura actual de la organización, orientan sobre los próximos pasos hacia lo que SAP llama la "Empresa Autónoma".
Dos empresas compartieron su experiencia con esto en el SAP Sapphire de Orlando este año.
La primera es Agilent, empresa global de ciencias de la vida. Su problema era evitar la detección tardía de cambios arancelarios y de cumplimiento normativo. Usando una misión del sector petróleo y gas, el equipo de Agilent exploró cómo un agente de IA podía interpretar señales regulatorias no estructuradas, extraer el contexto arancelario, determinar su relevancia y convertir esa información fragmentada en alertas accionables. Lo relevante aquí no es solo la solución sino el enfoque: cogieron un caso de uso de un sector completamente diferente al suyo y lo adaptaron. Eso dice bastante de cómo están construidas estas misiones.
La segunda es Sutherland, empresa de transformación de negocio basada en IA. Su valoración es quizás la más práctica para los que trabajamos en consultoría: "En lugar de empezar un MVP desde cero para ver cuál es el problema, tenemos una solución lista de la que podemos partir. Nos da un arranque de entre el 20% y el 30% dependiendo del escenario."
Ese 20-30% de ventaja inicial en un proyecto no es poca cosa.
¿Qué tiene esto de interesante para el consultor SAP de a pie?
Que muchas veces el principal freno para adoptar IA en un cliente no es el presupuesto ni la tecnología. Es no saber por dónde empezar. No saber cómo justificarlo internamente. No tener un caso de uso concreto que presentar en un comité directivo sin que parezca ciencia ficción.
SAP Discovery Center intenta resolver exactamente eso. Con casi 400 funciones y agentes disponibles en el Catálogo de SAP Business AI para explorar, el portal funciona como un punto de partida para convertir la ambición de IA en resultados de negocio accionables.
Si no lo has explorado aún, merece al menos una visita:
💹 Información en Bolsa
Si has seguido la acción de SAP en bolsa en las últimas semanas, la historia tiene dos capítulos muy distintos y ninguno de los dos aburre.
El subidón de principios de junio
SAP empujó desde el rango de los 160-175 dólares hasta superar los 190, con un precio de cierre cercano a los 191 dólares el 4 de junio de 2026, tras una subida de más del 6% en esa jornada. El catalizador fue el SAP Sapphire de Orlando, donde la compañía presentó su visión de "Empresa Autónoma" junto con toda la artillería de SAP Business AI Platform, Joule Studio y Joule Work. Los mercados lo recibieron con entusiasmo. BlackRock cruzó el umbral del 3% de derechos de voto en SAP SE el 29 de mayo de 2026, señal de creciente confianza institucional en la compañía.
El bajón de esta semana
Lo que sube con fuerza también corrige. El 11 de junio de 2026, las acciones de SAP cayeron un 3,9% hasta los 163,64 dólares, en lo que representa un año difícil para el valor, con una caída del 31,5% en lo que va de año y del 44,4% en el último año.
Para contextualizarlo: el precio de cierre de SAP SE a 10 de junio de 2026 era de 170,30 dólares, muy lejos de su máximo histórico de 306,60 dólares registrado el 9 de julio de 2025.
Esta semana, la acción ha caído un 8,42% respecto a la semana anterior, aunque en el mes acumula una subida del 3,23%.
La explicación no tiene un único culpable. Es una combinación de factores. Por un lado, el mercado tecnológico en general ha sufrido presión por tensiones geopolíticas y expectativas de tipos de interés. Por otro, SAP arrastra desde meses atrás cierta preocupación por la velocidad real de adopción de su IA y el ritmo de conversión del backlog cloud en ingresos recurrentes.
La acción cotiza actualmente un 34% por debajo de su valor estimado según el modelo GF Value, que lo sitúa en 248 dólares, aunque su solidez financiera está calificada con un 8 sobre 10.
De hecho, según 16 analistas, la valoración media del consenso es de "compra", con un precio objetivo a 12 meses de 256 dólares, lo que implica un potencial de subida del 55% desde los niveles actuales.
🚀 Mi Opinión
Hay un momento en todo proyecto SAP que es casi universal. No aparece en ningún manual de gestión. Nadie te lo cuenta en la formación. Pero ocurre. Y cuando ocurre, lo reconoces al instante.
Es el momento en que alguien del equipo mira su propia solución con los mismos ojos con los que una madre mira a su hijo recién nacido. Con amor incondicional. Con la certeza absoluta de que lo que tiene delante es perfecto. Con una generosa incapacidad para ver los defectos que el resto del mundo ve con meridiana claridad.
Puede ser el técnico que lleva dos semanas diseñando un desarrollo ABAP que "lo hace todo". Puede ser el funcional que ha construido un flujo de proceso en SPRO con la precisión de un relojero suizo. Puede ser el consultor que ha planificado una solución en un blueprint y que cada vez que alguien la cuestiona, siente que están atacando algo muy personal. Porque en cierta forma, lo están. Porque esa solución ya no es solo una solución. Es su solución. Y eso lo cambia todo.
El problema no es el amor. El problema es la ceguera que viene con él.
Cuando te enamoras de tu propia solución, dejas de escuchar. No intencionalmente. No porque seas mal profesional. Sino porque el cerebro humano tiene un mecanismo de defensa fascinante y traicionero: cuanto más esfuerzo has invertido en algo, más tiendes a sobrevalorarlo. Lo dice la ciencia, no yo. Aunque puede que a mí también me haya pasado alguna vez. Puede que más de una.
Y lo que viene después es predecible. El cliente dice "esto no encaja con cómo trabajamos nosotros" y la respuesta instintiva no es "cuéntame más, quiero entender." La respuesta instintiva es defender. Explicar. Convencer. Porque aceptar que la solución no funciona duele exactamente igual que aceptar que algo en lo que has puesto alma, tiempo y orgullo profesional no era tan bueno como creías.
Lo más irónico de todo es que el proyecto SAP más exitoso que he visto de cerca no fue el más elegante técnicamente. Fue el más honesto. El equipo tomaba decisiones, las construía, las defendía con argumentos... y cuando alguien llegaba con una perspectiva mejor, las tiraban sin drama. Sin duelo. Sin funerales por el código.
Eso no es fácil. Requiere algo que en los proyectos SAP escasea más que los presupuestos bien estimados: ego bajo control y la capacidad de separar "yo" de "mi solución".
La tragedia griega del consultor enamorado no es que diseñe algo malo. Es que diseña algo que podría haber sido bueno... si hubiera dejado que otros lo mejoraran a tiempo.
🧩 SAP Técnico
Si llevas tiempo en ABAP clásico, los user-exits y los BADIs son tus mejores amigos. Esa lógica de "cuando pase X en el documento, ejecuta Y automáticamente" es pan de cada día en cualquier implementación. En ABAP Cloud y RAP (RESTful Application Programming Model), esa misma necesidad existe. Pero el mecanismo cambia. Y si no lo entiendes bien desde el principio, acabas buscando workarounds que no deberían existir.
El concepto que necesitas conocer se llama Determination.
Una Determination en RAP es exactamente eso: lógica que se ejecuta automáticamente cuando ocurre algo en tu Business Object. Sin que el usuario lo pida. Sin que haya un botón. Solo ocurre. Igual que pasaba con tus user-exits de toda la vida, pero con una estructura mucho más limpia y declarativa.
¿Cómo funciona?
Primero lo declaras en el Behavior Definition de tu Business Object:
define behavior for ZI_MI_ENTIDAD alias MiEntidad
persistent table zmi_tabla
lock master
{
create;
update;
delete;
determination SetEstadoPorDefecto on modify { create; }
}Con esa línea estás diciendo: "Cada vez que se cree una instancia nueva de este Business Object, ejecuta automáticamente la determination SetEstadoPorDefecto."
Luego la implementas en tu Behavior Implementation Class:
METHOD setestadopordefecto.
READ ENTITIES OF zi_mi_entidad IN LOCAL MODE
ENTITY MiEntidad
FIELDS ( estado )
WITH CORRESPONDING #( keys )
RESULT DATA(lt_entidades).
DATA lt_update TYPE TABLE FOR UPDATE zi_mi_entidad\\mientidad.
LOOP AT lt_entidades INTO DATA(ls_entidad).
IF ls_entidad-estado IS INITIAL.
APPEND VALUE #(
%tky = ls_entidad-%tky
estado = 'ABIERTO'
%control-estado = if_abap_behv=>mk-on
) TO lt_update.
ENDIF.
ENDLOOP.
MODIFY ENTITIES OF zi_mi_entidad IN LOCAL MODE
ENTITY MiEntidad UPDATE FIELDS ( estado )
WITH lt_update
REPORTED DATA(lt_reported).
ENDMETHOD.Lo que hace este código es simple: cuando se crea una entidad nueva, si el campo "estado" está vacío, lo rellena automáticamente con "ABIERTO". Sin que el usuario haga nada.
Pero hay algo importante que mucha gente no entiende al principio.
Las Determinations tienen dos momentos de ejecución que debes elegir conscientemente:
on modify: se ejecuta cada vez que el Business Object es modificado (creación, actualización). Es el más común.
on save: se ejecuta justo antes de que los datos se persistan en base de datos. Útil para validaciones o cálculos finales que necesitas que ocurran en el último momento.
La diferencia importa. Si pones tu lógica en on save cuando debería estar en on modify, el usuario verá datos incorrectos en pantalla hasta que guarde. Si la pones en on modify cuando debería estar en on save, puede que se ejecute más veces de las necesarias y consumas recursos innecesariamente.
¿Cuándo usarla?
Las Determinations son perfectas para:
Rellenar valores por defecto al crear un documento
Calcular campos derivados automáticamente cuando cambia otro campo
Actualizar campos de cabecera cuando cambia una posición
Cualquier lógica que en ABAP clásico habrías metido en un user-exit de SAVE o MODIFY
Lo que NO debes hacer con una Determination:
No las uses para validaciones. Para eso existe otro concepto específico en RAP llamado Validation. Mezclar responsabilidades es la receta perfecta para tener un código que nadie entiende seis meses después. Determination = calcular y rellenar. Validation = validar y rechazar. Cada cosa en su sitio.
Si vienes de ABAP clásico y aún no has metido mano a RAP, las Determinations son un buen punto de entrada. Son conceptualmente familiares, están bien documentadas en el SAP Developer Center, y te dan una idea clara de cómo RAP separa responsabilidades de una forma que el ABAP clásico nunca terminó de resolver del todo.
🧩 SAP Funcional
Hay una familia de transacciones en SAP SD que vive en un rincón del sistema que mucha gente conoce a medias. Cuando hay que crear entregas masivamente, la mayoría de los usuarios tira de la que le enseñaron el primer día y ya está. Pero SAP tiene seis variantes de esta funcionalidad, cada una pensada para un escenario específico, y conocerlas todas puede ahorrarte tiempo, errores y más de un quebradero de cabeza en días de alto volumen.
La familia completa es esta:
VL10A - Pedidos de venta
Es la más conocida y la más usada. Permite crear entregas de forma masiva a partir de pedidos de venta. Filtras por cliente, fecha de entrega, organización de ventas, punto de expedición, o cualquier combinación que necesites, y SAP te muestra todos los pedidos que tienen posiciones pendientes de entregar que cumplen esos criterios. Seleccionas, procesas, y las entregas se crean en masa.
Lo que mucha gente no aprovecha de VL10A es la posibilidad de guardar variantes de selección. Si cada mañana procesas los pedidos del mismo punto de expedición con fecha de entrega igual a hoy, puedes guardar esa variante, programar un job en SM36 que la ejecute automáticamente a las 06:00, y llegar al trabajo con las entregas ya creadas. Sin tocar nada.
VL10B - Solicitudes de entrega (órdenes de traslado)
Esta es la hermana menos conocida. VL10B trabaja no con pedidos de venta sino con solicitudes de entrega creadas desde órdenes de traslado entre centros. Si tu empresa hace traspasos de stock entre almacenes o plantas y usa el proceso de entrega de traslado (movimiento 641/647), esta es tu transacción. Mismo concepto que VL10A pero para ese flujo específico.
El error más común aquí es intentar procesar órdenes de traslado desde VL10A y no entender por qué no aparecen. Aparecen en VL10B. Son mundos separados en SAP.
VL10C - Pedidos de venta y órdenes de traslado combinados
VL10C es exactamente lo que parece: la unión de VL10A y VL10B en una sola pantalla. Si tu operativa mezcla entregas de ventas y entregas de traslado en el mismo punto de expedición, esta transacción te da una vista unificada de todo lo pendiente sin tener que ir saltando entre las dos anteriores.
Útil en almacenes donde la misma persona gestiona tanto la expedición a clientes como los traspasos entre plantas. Una sola pantalla, todo visible, todo procesable en un solo paso.
VL10D - Posiciones de pedido individuales
Aquí el enfoque cambia ligeramente. Mientras VL10A trabaja a nivel de pedido, VL10D baja al nivel de posición individual. Eso permite un control más granular: puedes seleccionar específicamente qué posiciones de qué pedidos quieres entregar, aunque pertenezcan a pedidos distintos o aunque un pedido tenga algunas posiciones listas y otras no.
Esto es especialmente útil cuando tienes pedidos con muchas posiciones donde algunas tienen stock disponible y otras no. Con VL10A procesarías el pedido entero y obtendrías una entrega incompleta. Con VL10D seleccionas exactamente las posiciones que puedes servir hoy y creas entregas limpias y completas.
VL10G - Entregas para órdenes WM (Warehouse Management)
VL10G está orientada a entornos donde SAP Warehouse Management (WM) está activo. En estos casos, el proceso de entrega tiene pasos adicionales: creación de orden de transferencia, confirmación, etc. VL10G filtra específicamente las entregas pendientes de este procesamiento adicional en el contexto de WM.
Si no tienes WM activo, esta transacción no te va a dar mucho. Pero si lo tienes, es la herramienta correcta para gestionar el pipeline de trabajo del almacén de forma ordenada.
VL10H - Pedidos de compra (entrada de mercancías)
Y aquí viene la que más sorprende a la gente cuando la descubre: VL10H no es para expedición sino para recepciones. Permite crear entregas de entrada a partir de pedidos de compra, en los casos donde el proceso de compras incluye una notificación de entrega del proveedor antes de la recepción física.
Es menos común en implementaciones estándar, pero en entornos donde existe un flujo de aviso de expedición del proveedor (ASN - Advanced Shipping Notification), VL10H es la pieza que gestiona ese proceso masivamente.
¿Cuál usar entonces?
La respuesta rápida es esta:
Vendes a clientes y creas entregas de salida: VL10A
Haces traspasos entre plantas con entrega: VL10B
Mezclas ambos en el mismo punto de expedición: VL10C
Necesitas control a nivel de posición individual: VL10D
Tienes WM activo y gestionas el almacén con órdenes de transferencia: VL10G
Recibes mercancía de proveedores con aviso previo: VL10H
🔎 Función de la Semana
Si eres desarrollador ABAP, en algún momento de tu vida has tenido que hacer un ALV. Probablemente tu primer ALV lo hiciste con REUSE_ALV_GRID_DISPLAY, esa función módulo clásica que funciona, que lleva funcionando desde los tiempos de SAP R/3, y que genera el mismo ALV de siempre con el mismo toolbar de siempre.
Y funciona. Nadie dice que no funcione.
Pero hay una alternativa orientada a objetos que lleva años disponible en SAP estándar y que mucha gente desconoce o conoce pero no usa: CL_SALV_TABLE.
¿Qué es?
CL_SALV_TABLE es una clase ABAP estándar (disponible en SE24) que permite crear ALVs completos con mucho menos código y con mucho más control sobre el resultado. Es parte del framework SALV (SAP List Viewer) orientado a objetos, y es la forma "moderna" de hacer ALVs en ABAP clásico antes de que llegara RAP y Fiori a complicarnos la vida de la mejor manera posible.
¿Por qué mola?
Lo primero que llama la atención es la simplicidad del código mínimo necesario para tener un ALV funcionando:
DATA: lo_alv TYPE REF TO cl_salv_table.
DATA: lt_datos TYPE TABLE OF mara.
SELECT * FROM mara INTO TABLE lt_datos UP TO 100 ROWS.
TRY.
cl_salv_table=>factory(
IMPORTING r_salv_table = lo_alv
CHANGING t_table = lt_datos
).
lo_alv->get_columns( )->set_optimize( abap_true ).
lo_alv->display( ).
CATCH cx_salv_msg INTO DATA(lo_error).
MESSAGE lo_error->get_text( ) TYPE 'E'.
ENDTRY.Cuatro líneas útiles y tienes un ALV perfectamente funcional con columnas auto-optimizadas. Sin definir fieldcat. Sin pasar estructuras de layout. Sin los parámetros interminables de REUSE_ALV_GRID_DISPLAY.
Pero lo realmente interesante viene después.
CL_SALV_TABLE te permite personalizar prácticamente cualquier aspecto del ALV de forma encadenada y limpia. Por ejemplo, si quieres colorear filas según condiciones:
" Obtener la columna que controla color de fila
DATA(lo_columnas) = lo_alv->get_columns( ).
" Activar columna de color
lo_columnas->set_color_column( 'ZCOLOR' ).O si quieres añadir botones propios en el toolbar y capturar eventos:
" Obtener funciones del ALV
DATA(lo_funciones) = lo_alv->get_functions( ).
lo_funciones->set_all( abap_true ).
" Añadir botón custom
lo_funciones->add_function(
name = 'ZEXPORTAR'
icon = '@BA@'
text = 'Exportar'
tooltip = 'Exportar a Excel personalizado'
position = if_salv_c_function_position=>right_of_salv_functions
).Y capturar el click en ese botón con un event handler:
DATA(lo_eventos) = lo_alv->get_event( ).
SET HANDLER lcl_handler=>on_user_command FOR lo_eventos.Una cosa que muy poca gente sabe sobre CL_SALV_TABLE:
Cuando aplicas un filtro o reordenas las columnas en el ALV en tiempo de ejecución, la tabla interna que pasaste al factory method se reorganiza automáticamente para reflejar ese orden. Eso significa que si tienes lógica de doble-click que lee la tabla interna por índice de fila, el índice siempre corresponderá a lo que el usuario ve en pantalla, independientemente de cómo haya filtrado u ordenado. En el ALV clásico con REUSE, eso no siempre era así y generaba bugs sutiles que tardaban tiempo en detectarse.
¿Cuándo usarla y cuándo no?
CL_SALV_TABLE es perfecta para reports internos, herramientas de consulta, monitors de datos y cualquier pantalla de visualización en un sistema On-Premise con ABAP clásico. No es la solución para proyectos nuevos en ABAP Cloud o BTP donde el camino correcto es RAP con Fiori Elements. Pero en el día a día de muchos proyectos S/4HANA On-Premise, donde todavía hay una cantidad enorme de reports y herramientas en ABAP clásico, CL_SALV_TABLE es la forma más limpia y mantenible de hacer ALVs.
Si aún estás usando REUSE_ALV_GRID_DISPLAY en código nuevo, prueba a hacer el siguiente report con CL_SALV_TABLE. Tardarás la mitad. Y el código será el doble de legible.
👑 Liderazgo y gestión
Antes de hablar de cómo gestionarlo, hay que reconocerlo. Y reconocerlo tiene su ciencia porque no viene con cartel. No hay nadie en el equipo que diga abiertamente "me he enamorado de esta solución y ya no soy objetivo." Lo que hay son señales más sutiles. Aquí van las más comunes:
La solución crece sola. Lo que empezó siendo una respuesta concreta a un problema concreto empieza a acumular capas. "Ya que estamos, añadimos esto." "Y si lo hacemos así, nos sirve también para aquello." El scope crece sin que nadie lo haya pedido porque la persona que lo construye quiere que sea más grande, más completa, más perfecta. Es su bebé y quiere que sea el más listo de la clase.
Las críticas se responden con más explicaciones. Cuando alguien señala un problema y la respuesta es una explicación larga de por qué en realidad no es un problema, hay una señal ahí. La defensa excesiva casi siempre indica apego excesivo.
El "yo lo he probado y funciona" se convierte en argumento definitivo. Funcionar en desarrollo con datos de prueba no es lo mismo que funcionar en producción con datos reales y usuarios reales que hacen cosas inesperadas. Pero cuando alguien está enamorado de su solución, esa distinción tiende a difuminarse.
Entonces ¿qué haces como líder o como compañero de proyecto?
Lo primero es no atacar la solución. Atacar la solución es atacar a la persona. Y cuando alguien siente que le atacan, se cierra. Deja de escuchar. Se pone en modo bunker. Exactamente lo contrario de lo que necesitas.
Lo que funciona es hacer preguntas. No preguntas retóricas disfrazadas de crítica. Preguntas reales, curiosas, orientadas a entender. "¿Cómo funciona esto cuando el usuario hace X?" "¿Qué pasa si el volumen es diez veces mayor?" "¿El cliente ha validado este flujo o lo hemos validado nosotros?" Las buenas preguntas hacen que la persona llegue sola a las conclusiones. Y llegar solo a una conclusión duele mucho menos que que alguien te la imponga.
Lo segundo es separar la identidad del resultado lo antes posible. En los equipos donde funciona bien, las soluciones son del equipo desde el primer día. Se revisan juntos. Se critican juntos. Se mejoran juntos. Nadie tiene un "hijo" porque nadie construye en solitario. Eso no siempre es posible, sobre todo en proyectos con poco personal o mucha presión. Pero cuando lo es, marca una diferencia enorme.
Lo tercero, y esto es para antes de que el problema ocurra, es establecer desde el principio que las revisiones externas no son un cuestionamiento sino una garantía de calidad. Que alguien revise tu solución no significa que desconfíen de ti. Significa que el proyecto se toma en serio. Cambiar esa narrativa desde el inicio del proyecto ahorra muchos momentos incómodos después.
Y si ya estás en medio del problema, si alguien ya está claramente enamorado y la solución claramente no funciona, la única salida honesta es hablar de ello. No de la solución. De la situación. "Llevamos tres semanas con esto y el cliente sigue sin verlo claro. Necesitamos dar un paso atrás." Sin dramas. Sin señalar culpables. Con foco en el objetivo común, que es que el proyecto funcione, no que la solución sea perfecta.
Al final, el mejor indicador de un equipo SAP maduro no es que nunca se enamoren de sus soluciones. Es que cuando pasa, lo detectan rápido, lo dicen sin miedo y lo resuelven sin dramas.
Eso, en la mayoría de proyectos, todavía es más ciencia ficción que realidad.
💬 Frase del Día
La solución perfecta que nadie usa es simplemente un fracaso costoso.
Porque en SAP no gana quien diseña mejor. Gana quien entiende que el cliente es la medida de todo. Si tu solución es impecable pero el usuario no la puede mantener solo, no es buena arquitectura. Es solo ego disfrazado de técnica.
🙌 Gracias por leer
Y hasta aquí el boletín de esta semana.
Hoy hemos hablado de algo que muchas veces vemos todos los días… pero que no siempre analizamos con calma: cómo funciona realmente el ecosistema de consultoría alrededor de SAP.
Porque al final, detrás de cada proyecto, cada desarrollo o cada incidencia, también hay modelos de negocio, decisiones, estrategias y formas muy distintas de entender este mundo.
Y cuanto más tiempo pasas en él, más te das cuenta de que SAP no va solo de tecnología.
Va de personas, de procesos, de negocio… y muchas veces de saber adaptarse constantemente a cómo cambia todo.
Gracias por dedicar unos minutos a leerlo y por seguir formando parte de esta pequeña comunidad donde intentamos hablar de SAP de una forma un poco más cercana y real.
La semana que viene volveremos con más historias de proyectos, algún tema interesante y seguramente otra de esas situaciones que todos hemos vivido alguna vez trabajando en este ecosistema.
Nos leemos en el próximo boletín 👋
Envíame un correo sobre un tema que quieras que salga en la newsletter a [email protected] o contesta a este email.