Si siempre has querido ir al SAP Sapphire a comer canapés y beber champagne estás de suerte, este año se hace en Orlando y en Madrid.
¿Cómo? ¿Orlando te pilla muy lejos de tu casa? No te preocupes, si eres español el de Madrid si que te pilla cerca.
¿Cómo? ¿Al de Madrid no puedes ir porque no hay forma de que nadie te invite y es un evento para comerciales?
Vaya, pues nada, ya lo siento. Bueno, espera, hay otra opción.
Cómo lo que a ti te interesa es el conocimiento, no los canapés, SAP proporciona el acceso a un SAP Sapphire Virtual donde poder ver las sesiones que te interesen. Para registrarte entra en
Una vez registrado podrás inscribirte a las sesiones que te interesen. Están catalogadas por Topics para que puedas marcartelas como favoritas e inscribirte, hay los siguientes Topics:
Artificial Intelligence
Cloud ERP
Customer Experience
Data and Analytics
Financial and Spend Management
Human Capital Management
Supply Chain Management
Technology Platform
A mi me interesan especialmente las de
Artificial Intelligence
Customer Experience – Por ser mi área de especialización
Data and Analytics – Por Business Data Cloud que va a ser una revolución
Technology Platform – Por el ecosistema BTP que es otra revolución.
Por ello me he inscrito en las siguientes sesiones:
CX – Customer Experience
CX innovation: Transforming experiences with AI – CXP2270v
Unlocking the value of SAP CX and SAP Business Suite – CXP2269v
BTP – Technology Platform
Explore the road map for SAP Business Technology Platform – BTP2122v
Discover SAP Business Technology Platform and its value for your business – BTP1579v
SAP Build
Extending SAP S/4HANA Cloud with SAP Build at OGE: A customer perspective – BTP5056v
Extend SAP S/4HANA Cloud: SAP Build application development and automation – BTP5022v
Vamos a explicar otro de los temas básicos pero no por ello dominados totalmente y, seguro, todos aprenderemos algo, tanto el nuevo en el mundo SAP, como el senior. En esta serie de artículos hablaremos de los transportes en SAP.
Y el primero de esta serie será acerca de qué son las órdenes de transporte. En primera instancia hablaremos de los transportes clásicos, no hablaremos de transportes de las nuevas herramientas SAP como Build Apps, Sales Cloud, BTP, Fiori, Ariba, Success Factors, etc…
¿Qué es una orden de transporte en SAP?
Una orden de transporte es un contenedor que almacena todos los cambios transportables realizados en un sistema SAP. Estos cambios pueden incluir configuraciones, desarrollos de ABAP, personalizaciones y cualquier otra modificación en el sistema. Las órdenes de transporte garantizan que los cambios realizados en un entorno de desarrollo se puedan mover de manera controlada y segura a los entornos de pruebas y producción.
Mete tus objetos en el camión, que va a salir ya
¿Cómo se crean las Órdenes de transporte?
Pues hay dos formas de crear órdenes de transportes en el sistema.
Creación automática
Cuando se realiza una modificación en el sistema, dicha modificación pide guardarse una orden de transporte.
Pudiendo, en este popup, crear una nueva orden de transporte o seleccionar una ya existente. Al pulsar a crear una nueva nos saldrá un nuevo popup donde indicar la descripción. Y el sistema creará la orden automáticamente.
Esta es la forma más básica de crear una orden de transporte, la más básica pero también la más controlada, puesto que el sistema se encarga de meter la modificación realizada en la orden que has seleccionado. Obviamente puedes seleccionar una orden que ya exista, lo cual es lo habitual.
Pongamos un Ejemplo de creación de orden de transporte
Imagínate que estás realizando un proyecto para implantar una funcionalidad concreta, por ejemplo un proceso nuevo de Ventas Online. Cuando realices la primera configuración al respecto te pedirá una orden de transporte, pero no la habrás creado inicialmente, y podrás crearla en el momento, para lo cual lo único que tendrás que hacer es ponerle un nombre. Pero para las siguientes configuraciones, te volverá a pedir la orden de transporte, pero ya no tendrás que crearla, solo seleccionar la que creaste anteriormente, que será la que aglutine todas las configuraciones de tu funcionalidad.
Creación manual
Sin embargo, aunque sea menos habitual, también podemos crearla directamente en la transacción SE10 que veremos posteriormente. Esto es especialmente útil cuando necesitamos trabajar con los objetos de una funcionalidad concreta para agruparlos, realizar transportes de copias, depurar errores, etc. Todo esto lo veremos a continuación.
Id de las Órdenes de Transporte
Los Ids de órdenes y tareas son consecutivos y se forman de la siguiente forma <SID>K9<Número> Donde:
<SID> es el Id del sistema
K9<Número> – Es un número consecutivo del rango, que se construye del K900000 al K999999 (esto se puede ver en la tabla E070L).
Por lo tanto, si tu id de sistema de desarrollo es JOD una orden de transporte podría tener por id JODK9001627.
Tipos de Órdenes de Transporte
Y es que existen varios tipos de órdenes de transporte que, cada una tiene su razón de ser y su funcionalidad. Los tipos pueden agruparse en dos grupos, dependiendo de su funcionalidad.
Órdenes de Transporte sobre cambios en el sistema
Estas son las órdenes de transporte habituales, las que se crean automáticamente cuando realizamos un cambio en la configuración o los objetos técnicos del sistema. Pero precisamente esa distinción es la que hace SAP de cara a organizar los dos tipos de órdenes de transporte:
W – Customizing: Las órdenes de Customizing son las que contienen las modificaciones sobre el Customizing del sistema, es decir, sobre la modificación de los parámetros del menú de configuración (SPRO – IMG).
K – Workbench: Las órdenes de Workbench son las que contienen las modificaciones sobre los objetos del repositorio técnico. Código, modificaciones sobre objetos del diccionario de datos (Tablas, Vistas, Elementos de datos, Dominios, Estructuras, Tipos Tabla, etc.). Por resumir a algo que entendamos todos, guarda todas modificaciones o creaciones de objetos técnicos dentro de Paquetes.
Órdenes de Transporte para realizar gestiones
Existen otros tipos de órdenes de transporte además de las básicas de Customizing y Workbench. Obviamente, como órdenes de transporte que son. contienen también los objetos que han sufrido cambios en el sistema, pero quería separarlo para que se entendiese que su propósito es ligeramente diferente.
T – Transporte de Copias: Las ordenes de transporte de copias sirven para transportar modificaciones de objetos (Customizing o Workbench) de un sistema a otro sin necesidad de transportar la orden de transporte original que contiene esa modificación. Tiene las siguientes características:
No se catalogan como Customizing o Workbench, pudiendo contener objetos de ambos tipos.
Su ciclo de vida de transporte solo sirve para hacer un transporte de un sistema al siguiente, pero no se quedan pendientes en la cola del siguiente sistema.
Se deben crear siempre de forna manual. Teniendo que incluir los objetos en ellas o manualmente o incluyendo los objetos desde otras órdenes.
Se utilizan principalmente para transportar objetos de un sistema al siguiente pero manteniendo los objetos bloqueados en las órdenes originales. Esto ayuda a pasar funcionalidades al entorno de Test, manteniendo las órdenes originales en desarrollo, poder probar la funcionalidad y, cuando se quiera pasar a Producción, pasar las órdenes originales sabiendo que esa funcionalidad está probada. Esto evita tener que pasar a Producción muchas versiones de órdenes con correcciones y solo pasar las órdenes definitivas.
Traslados (Relocations): Se trata de un tipo de orden de transporte que yo en 17 años no he tenido que usar nunca. He estado investigando, pero no puedo aportar valor añadido aquí, por lo que prefiero no ahondar en este punto. Si necesitais algo de información en esta entrada del la help de SAP hay algo de información. Transports of Copies and Relocations
Estructura de una orden de transporte
Por lo general una orden de transporte comprende de un nivel superior que es la orden de transporte propiamente dicha, y de 0 a n Tareas.
Id Orden de Transporte – Usuario – Descripción
Id Tarea 1 – Usuario
Objetos bloqueados en la tarea
Id Tarea 2 – Usuario
Objetos bloqueados en la tarea
En este caso solo hay una tarea porque solo hay un usuario tocando los objetos
Y digo, por lo general, porque también puedes encontrar órdenes sin Tareas, pero esto sería dado por alguna manualidad.
¿Todos los cambios se guardan en una orden de transporte?
No, y cuidado con esto, hay configuraciones (Customizing) que no se guardan en órdenes de transporte. Se tratan de las configuraciones independientes de mandante. ¿No sabes lo que es un mandante? Revisa esta entrada.
El caso es que puede haber Customizing que no se graba en orden de transporte (el sistema te avisará) y actualizaciones de tablas que no requieran transporte (el sistema no te avisará).
¿Para qué sirven las órdenes de transporte?
Pues para transportar objetos y configuración de un sistema a otro ¿no?. Por supuesto, pero no solo para eso. Vamos a ver la utilidad de las órdenes de transporte.
Transportar objetos y configuración de un sistema a otro
Es la función principal, lo que les da nombre, y que desgranamos en futuros artículos.
Gestión de versiones
Permiten llevar un control de las versiones de los objetos, asegurando que se pueden gestionar y revertir cambios si es necesario.
Cada vez que se transporta una orden de transporte de desarrollo al sistema destino se guarda la versión transportada, de esa forma, se pueden ver todas las versiones pasadas e incluso recuperar una versión que se requiera.
Bloqueo de objetos y control de modificaciones
Aseguran que los objetos que se están modificando no puedan ser alterados por otros desarrolladores simultáneamente, evitando conflictos y asegurando la coherencia de los cambios.
Cuando un desarrollador modifica un objeto se guarda en una orden de transporte y se «bloquea». Cuando otro. Desarrollador modifica posteriormente el mismo objeto, al guardar la modificación le dirá que el objeto ya está bloqueado en una orden de transporte y que está no es suya, que se creará una tarea dentro de la orden del compañero. Esto asegura:
Que el segundo desarrollador sabe que el objeto modificado ya fué modificado por un compañero
Que el primer desarrollador sabe que el segundo ha tocado un objeto bloqueado, en una primera instancia por él, viendo que en su orden de transporte hay una tarea del segundo desarrollador.
Es importante indicar que esto sólo sucede con los objetos Workbench ya que el customizing son registros en tablas.
Auditoría
Las órdenes de transporte proporcionan un registro detallado de quién hizo qué cambios, cuándo y cómo, lo que es esencial para auditorías y revisiones de seguridad.
Transacciones para gestionar órdenes de transporte
Para gestionar las órdenes de transporte tenemos varias transacciones disponibles.
SE10 – Transport Organizer
Es que yo más uso, es mi punto de entrada para revisar y gestionas la órdenes de transporte. Siempre se ejecuta por un usuario, pudiendo ver todo poniendo un asterisco *. Además puede seleccionar ver unos tipos de órdenes u otros y según su estado (Modificable/Liberadas).
Una vez dentro veremos, por cada entorno, tipo, sistema destino y estado, las órdenes de transporte con sus tareas y objetos.
Esta transacción es la principal de gestión de las ordenes de transporte y la veremos con detenimiento en un artículo concreto, porque da para mucho contar.
SE01 – Transport Organizer (Ampliado)
Se trata de una transacción de varias herramientas, puedes buscar directamente por un Id de Orden de transporte o realizar distintos tipos de búsqueda. Yo suelo usar la SE10 para todo.
Logo retro
SE03 – Herramientas del Transport Organizer
Esta transacción es muy importante, contiene herramientas para poder gestionar casos especiales al respecto de órdenes de transporte. No podemos detenernos ahora en todo ello así que intentaré desgranarlo en una entrada aparte.
STMS – Transport Management System
Se trata de la transacción para la gestión de los transportes de la ordenes de un sistema a otro.
Logo retro con colorinchis
Obviamente, la gestión del transporte de las órdenes es uno de los puntos clave, y requiere estudiarlo pormenorizadamente. Lo haremos en esta serie.
Conclusión
Esta primera entrada hemos abortado qué es una orden de transporte, los tipos, como se crean, su estructura básica y su utilidad. Seguiremos viendo en esta serie cómo trabajar con las órdenes de transporte y, en definitiva, cómo transportar objetos y customizing de un sistema a otro.
Hoy en, anglicismos para parecer más cool (otro), vamos a explicar qué es eso de Proof of Concept. En castellano «Prueba de Concepto» o, más comúnmente llamado, «piloto».
Ya no hay pilotos como antes (si reconoces esta imagen estás en mi equipo)
¿Qué es Proof of Concept?
Hay veces que, ante una necesidad de un cliente, para satisfacerla a nivel tecnológico, sucede alguna de estas situaciones:
Incertidumbre tecnológica: No está clara la tecnología a aplicar
Evaluación de soluciones: No está clara la mejor de las soluciones de entre las propuestas
Costes elevados: El coste de implementar la solución es muy elevado
Resistencias internas: Hay resistencias por parte de los key users, dirección u otras áreas.
Si sucede alguna de estas situaciones una solución habitual es hacer una prueba de concepto (Proof of Concept) o piloto.
Un Proof of Concept o Prueba de Concepto es el implementar una solución acotada de la solución final. La forma de acotar puede variar dependiendo del contexto y los objetivos, pero generalmente implica reducir la escala del proyecto, simplificar funcionalidades y/o limitar el tiempo y recursos asignados. Y, en el caso de herramientas estándar, como SAP, minimizar al máximo, o incluso evitar cualquier desarrollo o ampliación, intentando enseñar como la herramienta estándar se adapta a las necesidades del negocio.
Resumiendo, lo más normal en una PoC es tomar un escenario aislado, dentro de todas las necesidades del cliente, y montarlo en la tecnología seleccionada como prueba del potencial a obtener si se implementa la solución completa para toda la necesidad.
Objetivos de un Proof of Concept
Una vez sabemos el qué es y el porqué, vamos a ahondar en cuales son los objetivos de realizar una PoC.
Validar la viabilidad técnica: Verificar si la tecnología propuesta es capaz de cumplir con los requisitos y expectativas del proyecto.
Identificar problemas y riesgos: Detectar posibles inconvenientes técnicos, organizativos o de otro tipo que puedan surgir durante la implementación.
Demostrar el valor de la solución: Proporcionar evidencia tangible de que la solución propuesta puede resolver el problema del cliente y ofrecer beneficios concretos.
Obtener retroalimentación: Recoger opiniones y comentarios de los usuarios clave y otras partes interesadas para ajustar y mejorar la solución antes de su implementación completa.
Pasos para desarrollar un Proof of Concept
Ya sabemos el qué, el porqué y el para qué, ahora vamos a ver el cómo. Para ello, como ejemplo, podemos proponer los siguientes pasos:
Definir los objetivos y el alcance: Establecer claramente qué se pretende lograr con la prueba y cuáles son los límites del proyecto piloto.
Seleccionar las herramientas y tecnologías: Elegir las tecnologías y herramientas que se utilizarán en la prueba de concepto.
Desarrollar un prototipo: Crear una versión simplificada de la solución final que permita realizar las pruebas necesarias.
Realizar pruebas y recopilar datos: Ejecutar la prueba de concepto y recopilar información relevante sobre su desempeño.
Analizar los resultados: Evaluar los datos recopilados para determinar si la prueba de concepto ha cumplido con los objetivos planteados.
Tomar decisiones informadas: Basándose en los resultados, decidir si se procede con la implementación completa, si se requieren ajustes, o si se debe reconsiderar la solución propuesta.
Riesgos de hacer una Prueba de Concepto (PoC)
Al hacer una PoC todas las partes implicadas tienen que estar alineadas con los requisitos, el alcance, la funcionalidad a implementar y las espectativas del resultado.
Entre los riesgos que hay que controlar cuando queremos hacer una PoC están:
Alcance mal definido: Como he comentado anteriormente, es crucial acordar. entre todas las partes, un alcance claro de cara, no solo a su implementación, sino también de las expectativas y demostración de funcionalidad potencial.
Alcance no relevante para el negocio: Una PoC sin sustancia suficiente no vale para que el negocio vea el potencial de la solución final
Alcance no claro: Habrá problemas con las expectativas de las partes. Desde el famoso «yo tenía un excel que hacía más cosas» hasta el «¿y esto no lanza la nómina de este mes?»
Alcance justo: No un alcance sin sustancia ni un alcance que sea ya la solución definitiva. Se trata de hacer un piloto, muchas cosas no funcionarán, porque no tendrán que funcionar.
Recursos insuficientes: Vamos, que te dejan a ti solo a hacer una PoC de un alcance que supone mucho trabajo. Tampoco está bien poner un equipo de 20 personas.
Dependencia de prototipos: Cuidado con ir montando la solución en base a prototipos o PoCs. La prueba de concepto ha de ser la llave de entrada al análisis, diseño e implementación de una solución final, robusta y funcional.
Falta de aceptación del usuario: Puedes ponerlo de colores, con música o con Gifs animados de gatitos. Puedes hacer una PoC perfecta, que satisfaga ese área del negocio acotado. Pero si no tienes a los usuarios/negocio apostando por ello, le buscarán los problemas. Ahora bien, mejor identificar estos problemas en una PoC que en un arranque a producción.
Problemas de integración: El eterno problema, es una PoC, hay que minimizar al máximo cualquier desarrollo. ¿Nos integramos con otros sistemas? Pues hay ocasiones en las que no hay más remedio si quieres que el negocio se sienta identificado. Hay que definir muy bien qué integraciones son necesarias e incluso posibles, puesto que en ocasiones las PoC se desarrollan fuera del ámbito tecnológico del cliente.
Conclusión
Las Proof of Concept, PoC o Prueba de Concepto son nuestros aliados, y cuando digo nuestros hablo de todos, Consultores, TI del cliente y negocio. Debe ser una palanca de cambio que nos ayude a ponernos en situación y poder evolucionar el negocio a nuevas metas tecnológicas.
Desde el punto de vista de la consultoría nos sirve como palanca para abrir negocio, poder mostrar nuestras capacidades y las de la solución, y la posibilidad de adaptación que tanto la solución como nosotros podemos aportar para conseguir satisfacer las necesidades del negocio.
Como ya hemos visto en algunas del Blog, en este mundo laboral de consultoría TI es fácil identificar problemas relacionados con el estrés el agotamiento o la adicción al trabajo. Como hemos hablado en entradas sobre el estrés como El Síndrome de Burnout o en adicción al trabajo como en Workaholic o La jaula de oro.
Pero, sin embargo, existe otro fenómeno igualmente dañino, aunque menos discutido, llamado «Síndrome del Boreout». Este término, relativamente nuevo en el campo de la psicología laboral, describe una condición en la que los empleados experimentan un profundo aburrimiento y falta de satisfacción debido a la infrautilización de sus habilidades, o falta de estímulos, lo que puede llevar a consecuencias graves tanto para la salud mental como para la productividad.
Y otro día en la oficina
¿Qué es el Síndrome del Boreout?
El Síndrome del Boreout fue introducido por Philippe Rothlin y Peter R. Werder en su libro «El nuevo síndrome laboral Boreout: Recupera la motivación» en 2007. Este concepto hace referencia a la experiencia de estar constantemente desocupado o aburrido en el trabajo. Contrariamente al Burnout, que resulta del estrés y la sobrecarga de trabajo, el Boreout surge de la falta de desafíos y la monotonía. ¿No sabes lo que es el Síndrome del Burnout?
Los empleados que sufren de boreout pueden parecer ocupados, pero en realidad, su trabajo es tan poco estimulante o tan mal asignado que se sienten vacíos y subutilizados.
Motivos de que aparezca el Síndrome del Boreout
Vaya! Qué aburrimiento ¿Tengo que hacer otra lista de motivos de que algo suceda? bah, estoy por dejarlo, luego nadie me da reconocimiento. Bueno, lo haré por inercia. Los motivos de que aparezca este síndrome los podemos englobar en:
Tareas Monótonas y Repetitivas: Trabajos que no requieren creatividad o pensamiento crítico suelen llevar a una sensación de inutilidad.
Falta de Desafíos: Cuando no te sientes desafiado o no te asignan responsabilidades que correspondan a tu nivel de competencia, puedes comenzar a desconectarte emocionalmente.
Mala Asignación de Tareas: A menudo, los empleados tienen habilidades que no se están utilizando en su puesto actual, lo que genera frustración y una sensación de desperdicio.
Falta de Reconocimiento: La ausencia de retroalimentación positiva o el reconocimiento de logros también puede contribuir a un estado de insatisfacción y apatía. ¿Para qué voy a escribir esto si nadie le interesa?.
¿Estoy describiendo a un funcionario? Yo me he encontrado con muchos funcionarios en empresa privada, gente que lleva muchos años en la empresa y ya se dejan llevar, sin más desafío que la jubilación.
Consecuencias del Boreout
Bueno, muchas son de sentido común, pero el boreout no solo afecta a los empleados, sino también a las organizaciones. Algunos de los efectos negativos más comunes incluyen:.
Desmotivación: Esto es obvio. Los empleados que no se sienten desafiados tienden a perder el interés en su trabajo, lo que afecta su desempeño y su actitud general.
Bajo Rendimiento: La falta de motivación se traduce en una disminución de la productividad, lo que afecta directamente a la organización. Si estás poco motivado,, poco puedes ofrecer.
Problemas de Salud Mental: El aburrimiento crónico puede llevar a la depresión, ansiedad y otros trastornos psicológicos. El boreout, al igual que el burnout, es un riesgo significativo para la salud mental. Parece una tontería de síndrome, pero la sensación de «vacío» y el estado depresivo, cansado y apáticos afecta,.
Alta Rotación de Personal: Los empleados insatisfechos son más propensos a buscar nuevas oportunidades laborales, lo que incrementa la tasa de rotación en las empresas. La búsqueda de retos profesionales, en ocasiones, hacer que nos pasemos de frenada.
Cómo Combatir el Boreout
No es fácil combatir el Boreout, porque cada uno tiene unas motivaciones distintas y lo que a uno de puede valer a otro no. Por ejemplo, a mi eso de las dinámicas de grupo y hacer chorradas en grupo con el equipo, no me va. A otros les engancha.
Redefinición de Roles: Revisar y redefinir las responsabilidades para asegurar que los empleados se sientan desafiados y valorados.
Desarrollo Profesional: Ofrecer oportunidades de formación y desarrollo para que los empleados puedan expandir sus habilidades y asumir nuevos retos. Yo siempre he dicho que lo mejor es fomentar que tus empleados mejoren su CV y, paradójicamente, no se irán (siendo más atractivos al mundo laboral).
Comunicación Abierta: Fomentar una cultura de comunicación abierta donde los empleados se sientan cómodos expresando sus preocupaciones sobre la falta de trabajo o la falta de desafíos. Así mismo hacer partícipes a los empleados de lo que sucede en la empresa, los proyectos en los que se está trabajando, los éxitos y los fracasos y pedir abiertamente si alguien tiene participar en algo, aunque no sea su competencia directa.
Asignación de Proyectos Variados: Introducir una variedad de proyectos que requieran diferentes habilidades para mantener a los empleados involucrados y estimulados.
Reconocimiento y Feedback: Proporcionar reconocimiento regular y retroalimentación constructiva para asegurar que los empleados sientan que su trabajo es apreciado.
En Conclusión
El Síndrome del Boreout no es solo un problema de aburrimiento en el trabajo; es una amenaza silenciosa que erosiona la salud mental, desintegra la motivación y puede destruir el tejido mismo de una organización. Mientras que el burnout grita con agotamiento, el boreout susurra con apatía, infiltrándose lentamente hasta que la productividad se desploma y la rotación de personal se dispara. Ignorar el boreout es permitir que una enfermedad sutil pero devastadora se propague sin control.
A nivel personal puede ser desalentador, desmotivador y deprimente. Es fácil entrar en ese estado sin que te enteres que estás entrando, porque sobre el papel todo es bueno, pero en tu interior no estás contento.
A nivel organización el boreout nos recuerda que no se trata solo de evitar el estrés; se trata de alimentar constantemente el propósito y la creatividad en cada empleado. Solo así, las organizaciones pueden prosperar en un mundo donde el aburrimiento es tan letal como el estrés.
Ahora vamos a ver una metodología de gestión de proyecto propia de SAP para el paso ágil a SAP S/4HANA. Vamos a ver SAP Activate.
¿Qué es SAP Activate?
SAP Activate es una metodología que ha sido desarrollada por SAP allá por el 2015 (Sí, 9 años he tardado en escribir esto) para proporcionar un enfoque estandarizado y ágil para implementar soluciones SAP. Este enfoque incluye las mejores prácticas, metodologías ágiles y herramientas de última generación para ayudar a las organizaciones a implementar soluciones SAP de manera más rápida y eficiente, minimizando los riesgos y maximizando el retorno de la inversión.
Si te quieres ahorrar leer este artículo hay varias referencias oficiales y/o útiles para conocer esto del SAP Activate.
SAP Activate es una metodología compuesta por tres elementos principales:
Best Practices (Mejores Prácticas)
SAP ha compilado una serie demejores prácticas que son específicas para diferentes industrias y procesos. Estas mejores prácticas son plantillas de configuración que permiten a las empresas implementar sus soluciones más rápidamente y con menos riesgos.
Se refiere a las herramientas y recursos que SAP proporciona para facilitar la configuración de las soluciones. Esta configuración guiada permite que las organizaciones configuren sus sistemas de manera ágil, asegurando que se adhieran a las mejores prácticas y a los estándares de la industria.
Agile Methodology (Metodología Ágil)
SAP Activate adopta un enfoque ágil para la implementación de soluciones, lo que permite a las organizaciones adaptar y ajustar sus procesos durante el proyecto, en lugar de seguir un enfoque rígido y secuencial.
Fases de SAP Activate
La metodología SAP Activate, como se ha comentado anteriormente, es una metodología Ágil y está organizada en seis fases clave:
Discover (Descubrimiento)
En esta fase, se analiza la viabilidad del proyecto. Las organizaciones evalúan las soluciones disponibles, identifican sus necesidades y definen el valor que pueden obtener de la implementación de SAP.
Prepare (Preparación)
En esta fase se establecen los fundamentos del proyecto, incluyendo la formación del equipo, la planificación inicial y la preparación de los recursos necesarios.
Explore (Exploración)
En esta fase, se realiza un análisis detallado de las necesidades del negocio y se exploran las diferentes soluciones de SAP que pueden satisfacer esas necesidades. Las configuraciones iniciales también se establecen durante esta fase.
Realize (Realización)
Esta es la fase de ejecución, donde las soluciones se configuran, prueban y ajustan según los requisitos del negocio. Los datos se migran y se realizan pruebas exhaustivas para asegurar que todo funcione según lo planeado.
Deploy (Despliegue)
En esta fase, la solución se pone en marcha en el entorno de producción. Se realizan pruebas finales, capacitaciones para los usuarios finales y se asegura que todo esté listo para la operación en vivo.
Run (Operación)
Una vez que la solución está en producción, comienza la fase de operación y soporte. SAP proporciona herramientas y recursos para monitorear el sistema, solucionar problemas y optimizar el rendimiento.
Herramientas ejecutar un proyecto SAP Activate
Para implementar un proyecto y seguir la metodología SAP Activate, SAP proporciona una serie de herramientas recomendadas para cada fase del proyecto.
SAP Solution Manager
¿Qué voy a decir de Solution Manager? Es una plataforma integral que proporciona soporte durante todo el ciclo de vida de las aplicaciones SAP, desde la implementación hasta el uso en producción. Facilita la gestión de cambios, pruebas, documentación de procesos, y el monitoreo de sistemas.
Todo esto sobre el papel está genial, lo que yo he solido usar no suele estar bien pensado o bien implementado.
SAP Cloud ALM (Application Lifecycle Management)
A grandes rasgos y como un resumen rápido podemos decir que es una heerramienta en la nube que soporta la gestión de proyectos y el ciclo de vida de las aplicaciones SAP, ideal para implementaciones en entornos Cloud.
SAP Best Practices Explorer
Se trata de un portal que permite explorar y acceder a las mejores prácticas de SAP específicas para diferentes industrias y procesos de negocio. Es esencial para la configuración inicial de soluciones SAP. Lo hemos visto en la parte de Elementos Principales de SAP Activate y podemos acceder a este portal en el SAP Best Practices Explorer.
SAP Central Business Configuration
Es una herramienta diseñada para configurar de manera centralizada los procesos de negocio en SAP S/4HANA Cloud, facilitando la adopción de SAP Best Practices.
Tricentis for SAP
Conjunto de herramientas para la automatización de pruebas dentro de proyectos SAP, que complementa la metodología SAP Activate asegurando calidad y estabilidad en las implementaciones.
SAP Roadmap Viewer
Una herramienta que proporciona una visión estructurada y personalizada de las hojas de ruta de implementación dentro de SAP Activate. Ayuda a los equipos de proyecto a seguir un plan claro y adaptado a las necesidades de su solución SAP. Podemos acceder a los Roadmaps disponibles en la web:
Se trata de un conjunto de herramientas que facilita el modelado, gestión y optimización de procesos de negocio. Es particularmente útil en las fases de Explore y Realize de SAP Activate, donde se necesita entender y mejorar los procesos empresariales. Esto, en sí mismo, ya tiene miga como para explicarlo pormenorizadamente.
En conclusión
Lo que antes era la metodología de gestión de proyectos ASAP (Acelerated SAP) pasó a evolucionar a SAP Activate, siendo ambas opciones válidas, pero siendo Activate la idónea para entornos S/4Hana y tecnologías SAP modernas.
Yo, y supongo que casi todos, estoy mucho más acostumbrado a metodologías Waterfall como ASAP. Pero hay que estar atento las formas de gestión de proyecto que tenemos encima de la mesa para saber aprovecharnos de sus ventajas.
Jorge Ocampos 