Noooooo. El fin del mantenimiento de SAP Business Suite que, para algunos, puede ser un poco el fin del mundo.
¿Qué es eso del mantenimiento de SAP?
Antes de entrar en fechas y cuáles son las consecuencias de esto vamos a saber qué es eso del mantenimiento de SAP ECC, o de cualquier solución SAP que contiene la SAP Business Suite 7 (SAP ECC, CRM, SRM, HCM, SCM, etc.).
Como sabemos, SAP es una suite de soluciones empresariales estándar, Out-of-the-box, es decir, las empresas pagan una licencia por tener las funcionalidades SAP y tener sus sistemas SAP actualizados de correcciones y nuevas funcionalidades.
Esto, como puedes imaginar, es fundamental para una empresa que quiera tener unos sistemas robustos, seguros y actuales. Estamos en un mundo empresarial en el que tener unos sistemas de información potentes te proporciona una ventaja competitiva sobre tus competidores.
Fin del mantenimiento de SAP Business Suite 7
Pues si, el fin del mantenimiento extendido de SAP Business Suite 7 se acerca (luego veremos fechas) y esto es un problema para muchas empresas. ¿Por qué? ¿Va a dejar de funcionar mi SAP? No, eso no va a pasar, tus sistemas van a seguir funcionando pero, ahora bien, como tengas un problema no vayas a SAP a pedirle cuentas, ayuda o soporte, que no habrá nadie. Tampoco habrá nuevas notas o support packages. Y eso en sistemas con condiciones legales como Recursos Humanos (HCM) o contabilidad no tendrán estas actualizaciones legales disponibles. A partir del fin del mantenimiento extendido tu sistema SAP será como el WinRAR.
31 de diciembre de 2025: Fin del mantenimiento estándar de SAP ECC EhP-5. Todavía quedaría pasar a SAP ECC EhP6 pero ¿para qué?.
31 de diciembre de 2027: Este es el fin del mantenimiento estándar para SAP Business Suite 7. A partir de esta fecha, SAP ya no ofrecerá soporte completo (correcciones, actualizaciones y mejoras) para estas soluciones.
31 de diciembre de 2030: SAP ha extendido el mantenimiento extendido hasta finales de 2030 para aquellos clientes que aún no hayan migrado a SAP S/4HANA. Durante este periodo, los clientes pueden recibir actualizaciones limitadas, pero ya no habrá nuevas funcionalidades. Además, este tipo de soporte conlleva un coste adicional, habrá que ver si compensa pagar más por menos y además con la previsión de que se acabe el mantenimiento.
¿2027? ¿2030? Queda mucho tiempo
¿Seguro? ¿Cuánto tardas en implantar todo lo que tienes en tu ECC, CRM, SRM, etc. en un S/4 HANA y soluciones anexas? Entre analizar tus sistemas, publicación de RFP, selección de proveedor, análisis y diseño, implementación (hay cosas que no se migran tan fácil), faseado, arranque y corrección de incidencias hasta estabilización… ¿Cuánto tardas?
Madre mía! Y ahora ¿Qué hago?
Calma, todo va a ir bien
SAP lleva tiempo, mucho tiempo, avisando que esto va a pasar.
Ya allá por 2020 amplió la fecha de fin de mantenimiento que originalmente estaba en 2025 a 2027.
Además está el soporte extendido hasta 2030 y luego se guarda la posibilidad de negociar, con quien lo necesite, una ventana de soporte especial por cliente. Eso sí, desde ya mismo, las empresas que no están en S/4HANA se están perdiendo las innovaciones de SAP, y las que sí lo tienen contarán con esa ventaja contra la competencia.
Pero todavía hay tiempo, para eso estamos nosotros, los consultores, para guiar, ayudar y acompañar a este paso a S/4HANA y las nuevas soluciones. Y para dar el salto cualitativo que aportan las nuevas soluciones SAP (SAP Sales Cloud V2 por ejemplo)
En Conclusión
En tecnología hay varios momentos en los que hay ciertos saltos tecnológicos que te ves obligado a realizar. En el caso de SAP, el paso a S/4HANA es uno de ellos y, obviamente SAP quiere convertir sus clientes On-Premise SAP ECC en la nueva tecnología para evolucionar.
Hay que estar con los tiempos y evolucionar con la tecnología para no quedarse atrás. Hay tiempo para responder y empezar a andar.
Llevo desde los 18 años programando, y empecé por curiosidad y en casa. Es algo que se me da bien, me gusta y me genera satisfacción «crear» algo donde no lo había. Mi perfil profesional actual es bastante amplio, pero nunca quiero dejar ese aspecto de mi día día. Es algo que me llena, que me alegra…. hasta que veo algunas masacres de código que hay por el mundo, que me entran ganas de matar.
if dino_aux2-tipo = ‘velociraptor’ and dino_aux2-enfadado = ‘true’ or dino_tocho = ‘suelto’. Write:/ ‘Me voy’. endif. Viendo tu código te tenían que haber despedido hace tiempo, pero no habría película
Hoy voy a hablar de la calidad del código, no solo en su efectividad, también en su eficiencia, su facilidad de lectura y mantenimiento. A muchos les parecerá una tontería, algo sin importancia, pero un buen código simplifica mucho el mantenimiento, la reutilización, la lectura y documentación.
CleanABAP
Existe un proyecto en GitHub llamado Clean ABAP donde la comunidad de desarrolladores ABAP han sacado una guía de estilo de desarrollo ABAP con las mejores prácticas. Además está en varios idiomas, incluido el Español lo puedes ver aquí.
Y claro, yo iba a escribir mi libro de buenas prácticas desde mi punto de vista. Cosa que he hecho en algún proyecto al ver los desastres que la gente generaba en el sistema. Pero, al ver que ya había un consenso entre desarrolladores ABAP, y que no estaba solo en esto, pues mejor. Lo que voy a hacer es extraer de la guía de estilo CleanABAP aquellas recomendaciones que vea más necesarias. En la guía de estilo (lectura recomendadísima), se dividen las recomendaciones por áreas, vamos a respetarlas por si quieres ir a ver la fuente.
NOTA: Si estás viendo esto desde un móvil o tablet mejor en horizontal, las líneas de código se te van a cortar y hay cosas que no entenderás. No obstante, es preferible que lo leas desde el PC.
Formato
Optimiza para lectura, no para escritura
Siempre escribe pensando en la legibilidad del código, no en lo rápido que puedas escribirlo.
Bueno, yo con esta ya si que me corto las venas. Es un &#+%€ botón, pulsar un botón y te hace gran parte del trabajo.
Usa el Pretty Printer.
Usa el Pretty Printer
En serio. Usa el Pretty Printer.
Usa la configuración de Pretty Printer de tu equipo
Enlazado con lo anterior, tampoco estamos hablando de ingeniería. Es configurar tu Pretty Printer para que actúe de la forma que se consensue en tu equipo de trabajo. Yo, personalmente me gusta así:
Y esto es por lo siguiente:
Sangrar: Obvio, que el texto tenga sus correspondientes sangrías que te indiquen el nivel en el que estás es fundamental.
Conversión mayúsc./minúsc.: A mi me parece muy interesante que las palabras clave sean mayúsculas para ver claramente la acción que se está realizando e identificar las sentencias ABAP de variables, parámetros y literales.
" Ejemplo sin palabras clave mayúsculas select partner into lv_partner from but000 where bu_group = lv_clientes and xdele = abap_false and type = 1.
" Ejemplo con palabras clave mayúsculas SELECT partner INTO lv_partner FROM but000 WHERE bu_group = lv_clientes AND xdele = abap_false AND type = 1.
Por favor, usa el Pretty Printer.
No más de una sentencia por línea de código
Cada línea de código debe contener solo una sentencia, evitando mezclar varias operaciones en una sola línea.
Para mi esto es especial para los IFs con múltiples condiciones. Todo de seguido no se ve claramente.
" Ejemplo Incorrecto IF lv_total > 100 And lv_is_customer = 'X' AND lv_country = 'ES'. lv_discount = lv_total * 0.1. ELSE. lv_discount = 0. ENDIF.
" Ejemplo Correcto IF lv_total > 100 AND lv_is_customer = 'X' AND lv_country = 'ES'. lv_discount = lv_total * 0.1. ELSE. lv_discount = 0. ENDIF.
Aquí la posición de los AND y OR ya es manía personal, hay quien los pone al principio, a mi me gusta ponerlo al final y alinear las variables, los operadores y los AND/OR.
Mantén una longitud de línea razonable
Si la línea de código es demasiado larga, divídela en varias líneas para que sea más fácil de leer y seguir.
" Ejemplo Incorrecto SELECT carrid connid fldate FROM sflight INTO TABLE lt_sflight WHERE carrid = 'LH' AND connid = '0400' AND fldate = '20231010'.
" Ejemplo Correcto SELECT carrid connid fldate INTO TABLE lt_sflight FROM sflight WHERE carrid = 'LH' AND connid = '0400' AND fldate = '20231010'.
Vamos, no hay color. Mi manía personal es ponerlo en ese orden (SELECT, INTO, FROM, WHERE), y alineando desde el INTO. Además con las sentencias ABAP alineadas el código tiene más aire y se lee mejor. Se identifica claramente qué se selecciona, a donde se guarda, de qué tablas y con qué condiciones.
Usa una línea en blanco para separar cosas, pero no más
Utiliza una línea en blanco para separar lógicamente secciones del código, como declaraciones de variables y bloques de código, pero evita poner líneas en blanco innecesarias.
Los bloques de sentencias han de estar separados para su entendimiento. Todo junto no se lee bien.
" Ejemplo Incorrecto DATA: ls_order TYPE zorder, lv_total TYPE p DECIMALS 2, lv_discount TYPE p DECIMALS 2. ls_order-order_id = 'ORD001'. ls_order-customer_id = 'CUST001'. ls_order-status = 'OPEN'. lv_total = 500. lv_discount = lv_total * 0.1. ls_order-total_amount = lv_total. ls_order-discount_amount = lv_discount. INSERT zorder FROM ls_order.
" Ejemplo Correcto DATA: ls_order TYPE zorder, lv_total TYPE p DECIMALS 2, lv_discount TYPE p DECIMALS 2.
Alinea asignaciones al mismo objeto, pero no a objetos diferentes
Cuando asignas valores a varios atributos de un mismo objeto, puedes alinearlos para mejorar la legibilidad, pero evita alinear asignaciones entre diferentes objetos.
" Cómo lo hago yo lo_instance->set_data( EXPORTING iv_name = lv_name iv_age = lv_age iv_address = lv_address iv_order_id = lv_order_id ).
Fíjate en el alineamiento de los =, hace que sepas claramente identificar parámetros de variables. Esto también lo suelo hacer los IFs con los comparadores, pero eso ya es manía personal.
" Ejemplo Incorrecto IF lv_status EQ 'A' AND lv_subtype NE 'X' AND lv_amount GT 100. lv_result = 'Valid'. ELSE. lv_result = 'Invalid'. ENDIF.
" Cómo lo hago yo IF lv_status EQ 'A' AND lv_subtype NE 'X' AND lv_amount GT 100. lv_result = 'Valid'. ELSE. lv_result = 'Invalid'. ENDIF.
Nomenclatura
Usa nombres descriptivos
Los nombres de variables, clases y métodos deben ser lo suficientemente claros para que cualquier desarrollador entienda su propósito sin necesidad de contexto adicional. Por ejemplo
" Declaraciones no descriptivas DATA: lv_amt TYPE i, lt_cust TYPE TABLE OF but000, lt_items_aux TYPE TABLE OF crmd_orderadm_i.
" Declaraciones con nombres descriptivos DATA: lv_total_amount TYPE i, lt_customers TYPE TABLE OF but000, lt_items_completed TYPE TABLE OF items.
No cuesta nada y se lee todo mejor, eso sí, se consecuente con usar cada uno para lo que es, no vayas a meter en lt_items_completed cualquier tipo de posiciones de pedido porque te venga bien.
Usa sustantivos para las clases y verbos para los métodos
Las Clases deberían representar conceptos o entidades y, por lo tanto, se nombran como sustantivos.
" Ejemplos order_calculator order_utils
Los Métodos representan acciones o comportamientos, por lo que deben nombrarse con verbos.
Para mejorar la legibilidad en ABAP, se prefiere el uso de snake_case en lugar de camelCase o PascalCase en variables y métodos. El uso de snake_case es una convención ampliamente utilizada en el código ABAP debido a su compatibilidad con otras herramientas del ecosistema SAP y porque ayuda a mejorar la claridad del código, haciéndolo más legible y fácil de seguir para los desarrolladores.
" Ejemplos Incorrectos DATA: TotalAmountDue type p decimals 2. DATA: itemstoadd type table of items.
" Ejemplos Correctos DATA: lv_total_amount_due TYPE p DECIMALS 2, lt_items_to_add TYPE TABLE OF items.
Constantes
Usa constantes en lugar de números mágicos
Evita usar números sin contexto directamente en el código. En su lugar, define constantes para mejorar la legibilidad.
" Ejemplo Incorrecto IF lv_value > 42.
" Ejemplo Correcto IF lv_value > gc_max_allowed.
Sabemos que el 42 es «El sentido de la vida, el universo y todo lo demás» pero a lo mejor en tu proceso no es el sentido de ese número. Usa constantes, puedes declararlas en un INCLUDE TOP o bien en una clase estática que aglutine varias constantes.
Prefiere clases de enumeración a interfaces de constantes
Esto lo he añadido por el punto anterior. Lo que yo suelo hacer es crear una serie de clases UTIL con métodos estáticos, con un sentido funcional cada una, y sus constantes correspondientes. Voy a poner un ejemplo:
CLASS zcl_crm_ofertas_util DEFINITION. PUBLIC SECTION.
" Constantes para los estados de la oferta CONSTANTS: c_estado_abierto TYPE char10 VALUE 'E0001', c_estado_cerrado TYPE char10 VALUE 'E0002'.
" Métodos estáticos CLASS-METHODS: get_datos_oferta IMPORTING iv_oferta_id TYPE char10 RETURNING VALUE(rt_oferta_datos) TYPE TABLE OF zcrm_oferta.
CLASS-METHODS: get_interlocutores IMPORTING iv_oferta_id TYPE char10 RETURNING VALUE(rt_interlocutores) TYPE ztt_interlocutores. ENDCLASS.
Y las constantes c_estado_abierto y c_estado_cerrado podemos usarlo en cualquier código para comprobar si un pedido tiene ese estado.
IF lv_estado_pedido EQ zcl_order_util=>c_estado_abierto. " Hacer cosas ENDIF.
Variables
Prefiere declaraciones in-line que al inicio
Este apartado no estoy al 100% de acuerdo, porque soy de vieja escuela, antes de que las declaraciones In-line estuviesen disponibles y suelo hacer bastantes declaraciones al inicio. No obstante, creo que tiene bastante razón.
" Ejemplo Incorrecto METHOD calculate_discount. DATA: lv_discount TYPE p DECIMALS 2, lv_total_amount TYPE p DECIMALS 2, lt_clientes TYPE TABLE OF but000.
SELECT * INTO TABLE @DATA(lt_clientes) FROM but000 WHERE bu_group EQ zcl_bp_util=>c_agrupación_cliente. ENDMETHOD.
Lo importante es conocer las declaraciones In-line que son muy útiles y aportan claridad y limpieza al código.
No encadenes declaraciones
Cada declaración debe ocupar una línea por sí misma. Esto facilita el seguimiento de las variables.
" Ejemplo Incorrecto DATA: lv_value TYPE i, lv_discount TYPE p, lv_total TYPE p.
" Ejemplo Correcto DATA: lv_value TYPE i, lv_discount TYPE p, lv_total TYPE p.
A lo que yo añado lo siguiente
Usa «DATA:» y evita usar múltiples DATA
Entras en un código y te encuentras con esto
DATA lv_es_cliente TYPE bu_partner. DATA lt_pedidos_abiertos TYPE TABLE OF zpedidos. DATA ls_pedidos_abiertos TYPE zpedidos. DATA lv_fecha_creacion TYPE datum. DATA lv_sociedad TYPE werks. DATA lt_pedidos_cerrados TYPE zpedidos.
Pero ¿Para qué ponemos tantos DATA. Si ponemos solo un DATA: el Pretty Printer se va a encargar de darle mucho aire y alinear los TYPE.
DATA: lv_es_cliente TYPE bu_partner. lt_pedidos_abiertos TYPE TABLE OF zpedidos. ls_pedidos_abiertos TYPE zpedidos. lv_fecha_creacion TYPE datum. lv_sociedad TYPE werks. lt_pedidos_cerrados TYPE zpedidos.
Vamos. no hay color, y eso que he puesto un ejemplo con seis líneas, he llegado a ver decenas de DATA juntos. Ya sabes, usa el Pretty Printer.
Tablas
Prefiere INSERT INTO TABLE a APPEND TO
Usar INSERT INTO TABLE es más versátil y claro para la inserción de datos en tablas internas. Además el uso del APPEND da errores en las tablas de tipo SORTED y en INSERT INTO TABLE lo gestiona bien.
" Ejemplo Incorrecto APPEND ls_cliente TO lt_clientes.
" Ejemplo Correcto INSERT ls_cliente INTO TABLE lt_clientes.
Ocupa lo mismo y no da problemas.
Prefiere LINE_EXISTS a READ TABLE o LOOP AT
En lugar de leer tablas para verificar si una línea existe, usa la función LINE_EXISTS, que es más clara y eficiente. Esto no lo suelo usar mucho, porque soy vieja escuela, pero me parece muy interesante.
" Ejemplo Incorrecto READ TABLE lt_table WITH KEY id = lv_id TRANSPORTING NO FIELDS. IF sy-subrc = 0. WRITE: 'La línea existe'. ELSE. WRITE: 'La línea no existe'. ENDIF.
" Ejemplo Correcto IF line_exists( lt_table[ id = lv_id ] ). WRITE: 'La línea existe'. ELSE. WRITE: 'La línea no existe'. ENDIF.
Strings
Usa | para construir textos
En ABAP, puedes usar | para concatenar y construir cadenas de forma más limpia que con las antiguas funciones CONCATENATE.
" Ejemplo menos eficiente CONCATENATE lv_name lv_surname INTO lv_fullname.
Este es uno de los principios básicos de CleanABAP. Es mejor hacer un método que haga una cosa cada vez para que el código se pueda leer de forma sencilla y coherente. Para que el método haga una cosa nos tenemos que asegurar que:
Tiene pocos parámetros: Un método que hace una sola cosa debería tener pocos parámetros de entrada. Tener muchos parámetros indica que el método podría estar haciendo más de una tarea
No tiene parámetros booleanos de entrada: Los parámetros booleanos en un método pueden ser una señal de que el método realiza dos cosas: una cuando el valor es verdadero y otra cuando es falso.
Tiene exactamente un parámetro de salida: Un método que hace una sola cosa debería tener solo un resultado. Si devuelve más de un valor, probablemente esté realizando múltiples tareas
Es corto: Un método debe ser corto y directo. Si un método es demasiado largo, es una señal de que está realizando múltiples tareas.
Desciende un nivel de abstracción: Un buen método debe enfocarse en un solo nivel de abstracción. No debe mezclar operaciones de bajo nivel (como acceso a base de datos) con operaciones de alto nivel (como lógica de negocio)
Lanza un solo tipo de excepción: Si un método lanza múltiples tipos de excepciones, es probable que esté haciendo más de una cosa
No puedes extraer más métodos de él con un significado claro: Si no puedes dividir un método en varios métodos más pequeños que tengan un propósito claro y diferenciado, entonces probablemente el método está bien estructurado.
No puedes agrupar sus sentencias en secciones lógicas: Si las sentencias de un método se pueden agrupar en diferentes secciones, es probable que el método esté realizando múltiples tareas.
Mensajes
Haz que los mensajes sean fáciles de encontrar
Para hacer los mensajes fáciles de encontrar en una búsqueda desde la transacción SE91. Realmente yo usaba la sentencia incorrecta, pero la recomendación es no usar eso.
" Ejemplo Incorrecto IF 1 = 2. MESSAGE e001(ad). ENDIF.
" Ejemplo Correcto MESSAGE e001(ad) INTO DATA(message).
Comentarios
Exprésate en código, no en comentarios
El código bien escrito debe ser lo suficientemente claro para no requerir comentarios excesivos.
" Ejemplo Incorrecto " Calcula el total con el descuento lv_total = lv_total - lv_discount.
Usa nombres descriptivos en lugar de comentarios, ya que esto hace el código más autoexplicativo.
Los comentarios no son excusa para nombrar mal objetos
Los nombres de variables y objetos deben ser claros y descriptivos por sí mismos, sin depender de comentarios para su explicación.
" Ejemplo Incorrecto " Cantidad Total DATA: lv_tot_amnt TYPE i.
" Ejemplo Correcto DATA: lv_total_amount TYPE i.
El nombre de la variable debe ser suficientemente descriptivo para evitar depender de comentarios innecesarios.
Usa métodos en lugar de comentarios para segmentar tu código
Es más eficiente y claro usar métodos con nombres descriptivos para organizar las diferentes tareas dentro del código. Esto mejora la legibilidad y el mantenimiento del código, además de seguir el principio de hacer una sola cosa en cada método.
Los comentarios pueden volverse obsoletos o estar mal escritos, lo que puede generar confusión. Sin embargo, los métodos con nombres claros y bien definidos hacen que el propósito de cada sección sea evidente, eliminando la necesidad de comentarios explicativos.
" Ejemplo Incorrecto METHOD process_order. " Validación del cliente IF lv_customer_id IS INITIAL. RETURN. ENDIF.
" Calcular el total lv_total = calculate_total( lt_items ).
" Aplicar el descuento IF lv_discount > 0. lv_total = lv_total - lv_discount. ENDIF.
" Guardar el pedido en la base de datos save_order( lv_order_id ). ENDMETHOD.
METHOD save_order. INSERT INTO zorders VALUES iv_order_id. ENDMETHOD.
El diseño va en los documentos de diseño, no en el código
Evita incluir detalles de diseño en el código, ya que esto pertenece a la documentación externa. El diseño debe documentarse fuera del código para evitar que el código se vuelva innecesariamente complicado de leer.
" Ejemplo Incorrecto " Este método sirve para crear pedidos de venta con los datos de " entrada de cliente, datos organizativos, productos y precios. " Los tipos de posición se calcularán en base al tipo de cliente y el " tipo de pedido que se quiere crear. " Para eso se llamará a la tabla ZTB_TIPO_POS y se recuperarán los " tipos de posición. " El estado del pedido será siempre "Abierto" METHOD crear_pedido_ventas.
Nadie se lee esto, además puede quedar fácilmente obsoleto al cambiar el contenido del método. Si el código se entiende, no hace falta hacer explicaciones de más.
Usa » para comentar, no *
Es preferible usar » para líneas de comentario porque se identan automáticamente al nivel donde aplican al usar Pretty Printer.
" Ejemplo Incorrecto CASE lv_estado. WHEN c_abierto. * Comentario en abierto
WHEN c_en_proceso. * Comentario en proceso
WHEN c_cerrado. * Comentario en cerrado
ENDCASE.
" Ejemplo Correcto CASE lv_estado. WHEN c_abierto. " Comentario en abierto
WHEN c_en_proceso. " Comentario en proceso
WHEN c_cerrado. " Comentario en cerrado
ENDCASE.
Borra el código en lugar de comentarlo
El código obsoleto debe ser eliminado en lugar de ser comentado para evitar confusión. Para algo está la gestión de versiones, el código que pasa por muchas manos y correcciones se vuelve imposible de leer.
No agregues prototipos ni comentarios de fin de métodos (INTERESANTE)
Los comentarios estándar de la firma de métodos o performs no aportan valor y generan ruido en el código. Estos comentarios pueden haber tenido sentido décadas atrás, cuando los entornos de desarrollo eran limitados, pero en los entornos modernos de ABAP (SE24, SE80, ABAP Development Tools en Eclipse), ya no son necesarios, porque la firma del método está fácilmente accesible con herramientas integradas.
" Ejemplo Incorrecto *&---------------------------------------------------------------------* *& Form CHECK_ORDER *&---------------------------------------------------------------------* * text *----------------------------------------------------------------------* * -->P_LV_ABAP_BOOL text * -->P_LV_COUNTRY text * -->P_LV_CUSTOMER_ACTIVE text * -->P_LV_HAS_DISCOUNT text * <--P_LV_TOTAL text * <--P_LV_SPECIAL_CUSTOMER text *---------------------------------------------------------------------- FORM check_order USING p_lv_abap_bool p_lv_country p_lv_customer_active p_lv_has_discount CHANGING p_lv_total p_lv_special_customer.
" Ejemplo Correcto FORM check_order USING p_lv_abap_bool p_lv_country p_lv_customer_active p_lv_has_discount CHANGING p_lv_total p_lv_special_customer.
En Conclusión
Me ha quedado algo largo, y eso que he hecho una selección de las recomendaciones que me parecen más interesantes. A pesar de eso, además yo tengo alguna manía más que realizo en mi día a día (no voy a añadir más leña). En entradas posteriores seguiremos hablando de esto pero desde un punto de vista de comprobar la calidad del código existente.
Por último, si solo me tuviese que quedar un un básico, diría:
Hoy traigo Mitología Griega que me encanta, todo muy coherente con el sentido del blog (no). Bueno, veréis como sí tiene que ver con nuestra profesión (o cualquiera) y las motivaciones, debilidades y fortalezas humanas.
(Todas las imágenes han sido generadas con ChatGPT y Dall-E 3)
El Mito de Ícaro
Cuenta la leyenda de la mitología griega que Ícaro era el hijo de Dédalo, un talentoso inventor y arquitecto ateniense. Dédalo era famoso por haber construido el Laberinto en Creta, donde el rey Minos encarceló al Minotauro (esa es otra historia), una criatura mitad hombre y mitad toro.
Sin embargo, tras ayudar a Teseo a matar al Minotauro y escapar del Laberinto, Dédalo cayó en desgracia con el rey Minos. Como castigo, el rey Minos encerró a Dédalo y a su hijo Ícaro en una torre alta en Creta para evitar que escaparan y difundieran los secretos del Laberinto. Sin embargo, Dédalo, con su ingenio, ideó un plan para huir: construir alas hechas de plumas de aves y cera para Ícaro para poder volar sobre el mar y escapar de la isla.
Antes de iniciar el vuelo, Dédalo advirtió a Ícaro que no volara demasiado alto ni demasiado bajo. Si volaba demasiado bajo, el agua del mar empaparía las alas y lo haría caer. Si volaba demasiado alto, el calor del sol derretiría la cera que mantenía las plumas unidas.
Lleno de emoción por la experiencia de volar, Ícaro olvidó las advertencias de su padre y, embriagado por la sensación de libertad, comenzó a ascender cada vez más alto en el cielo. Al acercarse demasiado al sol, la cera de sus alas comenzó a derretirse, haciendo que las plumas se desprendieran. Sin posibilidad de mantener el vuelo, Ícaro cayó desde el cielo y se hundió en el mar, donde se ahogó. El lugar donde Ícaro cayó fue nombrado en su honor: el Mar Icario.
Reflexión sobre el Mito de Ícaro
La leyenda de Ícaro se puede interpretar como una advertencia sobre los peligros de la desmesura, el exceso de confianza y la desobediencia. La ambición de Ícaro lo llevó a ignorar los límites y las precauciones, lo que resultó en su caída.
Para mi, o sobre lo que yo quiero reflexionar en este artículo, es que hay que tener cuidado con la ambición, saber medir los riesgos, controlarse y controlarlos. Nada es gratis y, si intentas volar muy cerca del sol, es muy posible que te quemes.
Así que la próxima vez que sientas el deseo de volar más alto que nunca, recuerda que incluso el cielo tiene sus límites. Pero, claro, eso no significa que no debamos intentar volar.
El Mito del Ave Fénix
En un rincón lejano del mundo, mucho antes de que la humanidad pudiera siquiera imaginar criaturas fantásticas, existía un ser único, majestuoso y envuelto en misterio: el Ave Fénix. Era un ave radiante como ninguna otra, con plumas doradas y rojas que parecían llamas vivientes. Pero lo que hacía especial al Fénix no era solo su belleza, sino su increíble capacidad para renacer de sus propias cenizas.
Cuenta la leyenda que el Fénix vivía en un paraíso escondido, donde el tiempo pasaba de manera diferente. Su vida no era corta como la de otras aves, sino que duraba siglos. Sin embargo, el Fénix sabía que, al igual que todo en el universo, su tiempo también llegaría a su fin. Cuando empezaba a sentir el peso de los años y la fatiga en sus alas, el Fénix se preparaba para el gran momento: su renacimiento.
Cuando el tiempo llegaba, volaba hasta lo más alto del cielo y, desde allí, descendía en un vuelo majestuoso hacia su nido hecho de ramas de especias y plantas aromáticas. Una vez en su nido, el Fénix dejaba que las llamas lo envolvieran, ardiendo con un fuego brillante y purificador. Todo su cuerpo se consumía en ese fuego, hasta que no quedaba más que un montón de cenizas.
Pero aquí es donde ocurría el milagro: de esas mismas cenizas, entre el humo y el calor residual, nacía un nuevo Fénix, joven y lleno de vida. Con un poderoso aleteo, este nuevo ser emergía, más hermoso, con más energía y más resplandeciente que antes. Y así, una y otra vez, el Fénix vivía y moría, solo para resurgir con más fuerza.
Reflexión sobre el Mito del Ave Fénix
Resumen rápido: Cuando te caes, te levantas, aprendes y mejoras.
El mito del Ave Fénix es un poderoso mensaje sobre resiliencia, renacimiento y esperanza. El Fénix simboliza la capacidad de resurgir de las cenizas, incluso después de haber pasado por momentos de destrucción o pérdida.
Este mito nos recuerda que, aunque atravesemos dificultades, fracasos o situaciones dolorosas, siempre existe la posibilidad de volver a levantarse y comenzar de nuevo, renovados y fortalecidos.
¿Por qué cuento esto? ¿Qué relación tiene?
Bueno, digamos que es una reflexión personal que estoy contando en público. Es muy fácil convertirse en Ícaro, querer volar demasiado cerca del sol pero que tus capacidades, tu entorno, las alas que tienes o el destino donde quieres volar te hagancaer, y la caída esdura.
Pero es más difícil, una vez habiéndote convertido en cenizas, como el Ave Fénix, al volar tan cerca del Sol, resurgir de tus cenizas, aprender de los errores y hacer que ese tropiezo sea una lección aprendida que te haga resurgir con más fuerza, siendo más consciente de lo bueno que tienes y queriendo mejorar.
Volvemos a sentar las bases, en este caso, de lo que es un proyecto de implantación. Es posible que nunca hayas vivido un proyecto de implantación porque siempre has estado en mantenimiento, o que hayas entrado en uno que, o bien ya estaba empezado, o bien no se siguen las buenas prácticas a la hora de pasar por las distintas fases, generando la documentación necesaria en cada fase. Estas fases tan marcadas y secuenciales pertenecen a la metodología Waterfall de desarrollo de software que es la más común y la que hemos usado siempre. Otras metodologías como las Agile cambian estos paradigmas y la forma de realizar entregas, documentación y puesta en producción. Peto de Agile ya hablaré más adelante.
Un proyecto es como una carretera sinuosa, en muchos casos con tintes surrealistas.
No es necesario indicar que esta lista de fases, análisis, documentación y entregables es a máximos, no todo es imprescindible y, en muchas ocasiones, es imposible pasar por todo. Pero es lo deseable.
Fase 0: Etapa de Selección del Proveedor
Esta es la previa al proyecto pero, como veremos, es crucial. Si somos consultores participaremos en este proceso, o bien para sacar una oferta de funcionalidades que satisfagan los requerimientos, o incluso ayudando al cliente a crear la RFP.
🏢 Evaluación de Proveedores
Se analizan diferentes proveedores de SAP para evaluar su experiencia, capacidad, y compatibilidad con los requerimientos del proyecto. Esto se hace para acotar aquellos proveedores a los que se les quiere hacer la RFP.
📑 RFI (Request for Information)
Dentro del paso anterior se puede emitir un RFI (Request For Information) para recopilar información general sobre los proveedores. Se trata de un documento que las organizaciones utilizan para recopilar información básica de posibles proveedores de servicios SAP. Su propósito es obtener un entendimiento general de las capacidades y servicios que ofrecen distintos proveedores, ayudando a la organización a filtrar y seleccionar los que mejor se ajusten a sus necesidades específicas antes de solicitar propuestas más detalladas (RFP) o cotizaciones (RFQ). La RFI es un paso inicial importante para identificar los proveedores más adecuados para el proyecto.
📝 Assessment
Un proceso que puede solicitar un cliente, antes de la RFP, es que uno de los proveedores les ayude a estudiar sus procesos y elevar las necesidades de negocio. Como resultado de este proceso se generan documentos del AS IS (Cómo están los sistemas actualmente) y el TO BE (Qué es lo que se quiere).
Hay varios objetivos que puede tener esta fase:
Estimar a alto nivel costes futuros: Si tenemos que realizar un cambio tecnológico y necesitamos tener una magnitud de costes y tiempos de cara a preparar el presupuesto y a nuestro CEO del golpe que viene.
Identificar las posibilidades y poder comparar soluciones: El TO BE puede ser una comparativa de las soluciones que pueden ayudar a la empresa a realizar la evolución tecnológica. Por ejemplo, para satisfacer el AS IS y poder evolucionar a medio largo plazo en X negocio puedes usa SAP Sales Cloud V2 con estos PROS y estos CONTRA o Salesforce con estos PROs y estos CONTRAS.
Conocer el estado del sistema actual: Puede que tengamos un sistema infrautilizado, o con demasiados desarrollos propios y un mapa de integraciones loco.
📑 RFP – Request for Proposal
Este es el paso importante de la búsqueda de un proveedor desde el punto de vista del cliente. Se solicitan propuestas detalladas a los proveedores preseleccionados. Aquí se incluyen requisitos específicos del proyecto, plazos, y expectativas.
Desde el punto de vista del Proveedor la RFP es el documento de requerimientos (a muy alto nivel) sobre el que trabajar para presentar una oferta con la solución, plazos, perfiles, precio, etc.
¿Cuantas RFPs pasan por las manos de managers? Huelga decir que la persona o grupo de personas que realice la oferta necesita tener mucho conocimiento, de negocio, de las posibilidades de la herramienta, de esfuerzos necesarios (perfiles y costes), identificación de gaps o riesgos, etc.
📑 RFQ – Request for Quote
Cuando un cliente tiene muy claro lo que quiere, el alcance y cuando la funcionalidad a implementar es algo que no tiene discusión (Por ejemplo compra de Hardware), se genera un documento en el que la organización solicita cotizaciones específicas de proveedores potenciales. A diferencia de un RFP, que es más detallado y abarca cómo se abordarán los requisitos del proyecto, un RFQ se centra principalmente en el precio y los costos asociados.
Yo nunca me he encontrado con esta petición, puesto que no estoy en el departamento comercial y, lo que me llega a mi son RFPs para su análisis y preparación de la Oferta correspondiente.
🎯Respuesta al RFP
La oferta como tal. Pero no solo en términos económicos, sino como documento de análisis de los procesos y necesidades expresado en la RFP y propuesta de soluciones en la herramienta o herramientas seleccionadas. Incluye también, a alto nivel, estimación de tiempo, perfiles y esfuerzo. Y bueno, todo lo que se considere necesario para que el cliente lo lea y diga:
¡Está muy bien!
Fase 1: Preparación del Proyecto
En la Fase 1 de un proyecto de implementación de SAP, cada documento e hito tiene un propósito específico:
⚽ Kick Off
Como en los partidos de fútbol, el kick off es el evento que da comienzo el partido. Una vez contratado con un proveedor el proyecto, acordado el alcance y planificado las fases, tiempos y esfuerzos, comienza el partido.
Alguno empieza así el proyecto
✈️ Plan de Trabajo de Alto Nivel
Define la dirección general del proyecto, estableciendo los objetivos, el alcance y la estructura del equipo. Este documento es crucial para asegurar que todos los involucrados entiendan la visión y los objetivos del proyecto.
🛤️ Estudio de Viabilidad
Evalúa si el proyecto es técnicamente y financieramente viable. Incluye análisis de costos, recursos disponibles, y beneficios esperados, ayudando a tomar decisiones informadas sobre la viabilidad del proyecto.
🚑 Análisis de Riesgos
Identifica posibles riesgos asociados con el proyecto, evaluando su impacto potencial y proponiendo estrategias para mitigarlos. Este análisis ayuda a prevenir problemas futuros y planificar respuestas adecuadas.
⏳Especificación de Necesidades y Límites
Detalla lo que se incluirá en el proyecto. Esto implica definir los procesos y funciones que se necesitan mejorar o implementar con SAP, estableciendo así los límites del proyecto
👨💼👩💼Identificación de Actores
Se determinan todas las partes interesadas en el proyecto, asignando roles y responsabilidades. Esto incluye identificar a los miembros del equipo, los patrocinadores, los usuarios finales y otras partes relevantes.
Iñigo Montoya Consultor Senior SAP CRM
Fase 2: Business Blueprint
En la Fase 2, el enfoque principal está en mapear los procesos de negocio actuales, identificar las necesidades de adaptación y planificar cómo se configurará el sistema SAP para alinearse con estos procesos.
📋 Actas de Reunión
Durante la fase de Business Blueprint, se llevan a cabo múltiples reuniones con stakeholders y expertos en procesos empresariales. Las Actas de Reunión son esenciales para documentar las discusiones, decisiones y acuerdos realizados durante estas reuniones. Ayudan a asegurar que todos los detalles de los procesos de negocio y los requisitos del sistema estén claramente comunicados y acordados.
🏭 Business Blueprint (BBP) – Documentación de Procesos del Negocio
Esta es la piedra angular de la fase. Se documentan los procesos empresariales existentes y cómo se espera que funcionen con el nuevo sistema SAP. Este documento sirve como un mapa detallado que guía la configuración y personalización del sistema.
Me ha quedado bonita la caseta del perro. Quizás se ha pedido funcionalidad innecesaria para una caseta de perro.
📅Cronograma de Actividades
Desarrolla un plan de tiempo para el proyecto, estableciendo hitos y fechas límite. Este cronograma sirve como una hoja de ruta para la ejecución del proyecto y ayuda a garantizar que se mantenga en el camino correcto. Hay gente que usa el Project, otros con un Excel es suficiente. Su utilidad es para ver desviaciones, avances, cuellos de botella, esfuerzos, asignación de recursos, etc.
Tiene miga hacer la caseta
🌩️ Gap Analysis (Análisis de Brechas)
Identifica las diferencias entre los procesos de negocio existentes y las capacidades del sistema SAP. Este documento es crucial para determinar las necesidades de personalización o desarrollo adicional.
Sacamos los posibles problemas y damos soluciones alternativas
Fase 3: Realización/Diseño
La Fase 3 es donde se configura y personaliza el sistema SAP según lo definido en el Business Blueprint. Esta fase es crítica para asegurar que SAP funcione de acuerdo con las necesidades y expectativas del negocio. En esta fase:
🧩 Parametrización del sistema
Se realiza la configuración específica de los módulos de SAP para alinear el sistema con los procesos de negocio documentados.
Somos unos máquinas parametrizando
⛏️ Desarrollo ABAP
Involucra cualquier desarrollo de software personalizado necesario para cumplir con los requisitos que SAP no cubre de forma estándar.
En Deloitte ha cambiado mucho el tema de ir en traje
🖇️ Diseño de integraciones
Se detallan las integraciones entre SAP y otros sistemas, asegurando un flujo de datos sin interrupciones.
💼 Documentación técnica
Al finalizar o incluso durante la Parametrización y desarrollo de las funcionalidades para satisfacer los procesos de negocio, se realiza un documento maestro de las funcionalidades SAP implementadas. Puede dividirse en dos, uno de Parametrización y otro de desarrollos. Sea como fuere es un entregable imprescindible. Bajo mi punto de vista se le da poca importancia (nadie lo revisa) a este documento. Cuando es crucial para conocer como esta configurado el sistema.
Yo haciendo la documentación y los manuales
🧙 Documentos de Roles y Perfiles de Usuario
Se definen los roles y perfiles de usuario en SAP, asegurando el acceso adecuado a las funciones y datos del sistema.
Fase 4: Preparación Final
🤸 Pruebas Unitarias
Evalúan las funciones individuales del sistema para garantizar que cada componente funcione según lo previsto.
🤼 Pruebas de Integración
Verifican cómo los diferentes módulos y sistemas integrados funcionan juntos. Ya sea entre SAP y sistemas externos o todo el proceso de inicio a fin en los distintos módulos de SAP.
👥 Pruebas de usuario (UAT)
Las oruebas de Aceptación del Usuario (UAT) se realizan con usuarios finales para asegurar que el sistema cumpla con sus necesidades y expectativas.
🩺 Pruebas de Regresión
Comprueban que las nuevas configuraciones o desarrollos no hayan afectado negativamente las funcionalidades existentes.
📚 Manuales de Usuario
Se elaboran manuales detallados que proporcionan instrucciones sobre cómo utilizar el sistema SAP. Estos son esenciales para la capacitación de los usuarios finales.
👨🏫 Capacitación de Usuarios
Se lleva a cabo la formación de los usuarios finales para asegurar que puedan operar el sistema eficientemente una vez que esté en funcionamiento.
🪂 Plan de Cutover
Se prepara el plan para el traspaso final del sistema antiguo al nuevo sistema SAP, incluyendo la migración de datos y la transición operativa.
Esta fase culmina con la preparación completa del sistema para su implementación y uso en vivo, asegurando que todos los aspectos funcionales y técnicos estén afinados y listos para la operación.
Fase 5: Puesta en Producción y Soporte
La Fase 5 en un proyecto de implementación de SAP es la etapa de «Puesta en Producción y Soporte». En esta fase, es crucial mantener una comunicación efectiva y proporcionar el soporte necesario para garantizar una transición fluida y exitosa al nuevo sistema SAP. Esta fase incluye:
🌅Puesta en Producción (Go-Live)
El sistema SAP se pone en funcionamiento y se utiliza en el entorno real. Esta transición debe ser cuidadosamente planificada y ejecutada.
🚑Soporte Post-Implementación
Proporciona asistencia continua a los usuarios para resolver problemas y adaptarse al nuevo sistema.
⏱️Optimización del Sistema
Incluye el ajuste fino del sistema para mejorar el rendimiento y la eficiencia operativa.
🌋Disaster Recovery Plan (DRP)
Prepara planes de contingencia en caso de problemas graves o desastres para garantizar la continuidad del negocio.
En conclusión
Pero ¡voy a necesitar un par de personas para orquestar todo esto!.
Pues claro, se llaman jefes de proyecto y/o managers y no están (o no deberían) todo el día tomando cafés con otros de su especie. Ahora bien, como con otros perfiles, tienes que ser bueno en esto, metódico, ordenado, analítico, asertivo y, en ocasiones, cortante y estricto..
No obstante, todo el equipo debería tener claras todas las fases, hitos y entregables a realizar. Que luego nos enfadamos cuando nos piden que documentemos.
Tengo un blog de tecnología, SAP, Consultoría IT e Inteligencia Artificial, publico un artículo nuevo aproximadamente cada semana, trabajo, tengo hijos, hago ejercicio (intento), leo y tengo vida social.
¿Cómo es posible? Tus artículos los está escribiendo la inteligencia artificial.
Pues, ¡oh sorpresa!, eso no es así.
Por supuesto que uso ChatGPT para investigar y aprender sobre varios de los artículos que escribo. Pero esto tiene matices que vamos a ver.
Información de SAP
Esto es mi área de conocimiento, llevo más de 16 años trabajando en esto, empecé cuando mi única fuente de información era mundosap.com (hasta que me di cuenta que en español no iba a encontrar nada). Luego vinieron los foros de SAP, las paginas de help.sap.com, los cursos gratuitos de SAP, impartir cursos, luchar en proyectos, etc. Sé muchas cosas, pero desconozco muchísimas más, el mundo SAP es muy vasto y, como cualquier tecnología, está en continua evolución. Podemos decir que me suena todo un poco, sé por donde pueden ir las cosas.
Bueno, el tema es que cuando quiero investigar algo de SAP y uso ChatGPT, por ejemplo cuando tengo un problema en el trabajo, o estoy escribiendo de algo en el blog, ChatGPT se tira unos triples que ni Kobe Bryant. Y yo los identifico, porque sé lo que podría ser y me suena a mentira, porque busco fuentes alternativas o porque tengo sistema para corroborar.
En SAP la transacción para hacer un pedido de churros es la CHURRI
Las alucinaciones de ChatGPT (y cualquier otra IA)
No lo voy a explicar yo.
Está clarísimo. Lo importante es que «genera información incorrecta» que «suena plausible«. Y, como no sepas del tema del que habla, puedes creer que es correcta. Esto está relacionado con el artículo que escribí sobre la dependencia excesiva o «Overrelaince».
Esto me pasó el otro día, quería recalcular los precios de una Sales Quotation de un SAP CRM 7 por medio de un programa, algo que no es novedoso. SAP CRM 7 lleva años en usándose (desde el 2009). Podría buscar en mi repositorio histórico de código pasado donde he hecho esto, pero pensé que sería más rápido usar a mi amigo ChatGPT, pero enseguida vi que me estaba engañando.
Todo parece muy plausible, pero inútil, una pérdida de tiempo y frustrante
¿Cómo usar ChatGPT para temas tecnológicos?
Al final, lo que a mi me ha valido es pedirle que busque en internet y me de una lista de webs con un resumen del contenido. Esto sirve para enfocar el tema, ver qué trata cada web y acceder a investigar en aquellas que sí que sean relevantes para lo solicitado.
Esto ya es otra cosa
No queda otra que seguir leyendo internet para ver si alguien ha tenido la misma duda o aporta información que sea relevante para lo que quieras obtener, como siempre, pero guiado. Este método tampoco es perfecto, porque va a darte referencias que no encajan con lo que buscas, pero al tener el resumen de cada enlace, puedes descartarlo directamente.
En conclusión
No te creas ciegamente lo que dice la Inteligencia Artificial, tampoco te creas ciegamente lo que dice tu compañero de trabajo Paco. Ten espíritu crítico, contrasta la información, busca otras referencias. La Inteligencia Artificial es una herramienta, pero no va a solucionar todos tus problemas (por ahora). En ocasiones será frustrante porque ves que lo que te da no funciona, no existe o es incorrecto. Pero siempre, siempre, siempre te dará pistas que, si tienes olfato para saber rastrear, te pueden llevar a la solución.
Jorge Ocampos 