Mes: septiembre 2024

Fases de un proyecto (Waterfall)

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.

No se puede usar ChatGPT para tecnología IT

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».

El mayor peligro de la IA

Ejemplo de alucinación sobre algo muy concreto

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.

OData y SAP Gateway – III – Recuperar Subentidades

En la entrada anterior de esta serie de artículos sobre OData ‘OData y SAP Gateway – II – Publicar un servicio OData en SAP‘ creamos un servicio muy básico de consulta de Business Partners. Ahora toca añadir más funcionalidad a ese servicio que creamos en el anterior artículo. Antes de nada, vamos a recapitular.

Serie de Artículos sobre OData

Este artículo pertenece a una serie de artículos que se van complementando poco a poco como itinerario de conocimiento:

Modelo de datos

Recuperamos cómo era el modelo de datos del servicio que queríamos publicar.

Como podemos ver en el diagrama Entidad-Relación tenemos una Entidad padre «Business Partner» que tiene cuatro entidades relacionadas:

  • Roles del Business Partner
  • Direcciones del Business Partner
  • Relaciones del Business Partner
  • Números de Identificación del Business Partner

Además, este ejemplo lo hemos hecho sencillo, con un solo nivel de relación, por tener un escenario controlado y que esto no se convierta en algo inmanejable de explicar pero, como podreis imaginar, las entidades subordinadas pueden tener otras subentidades a su vez.

Proyecto SAP Gateway creado

Además creamos el siguiente proyecto de Gateway con las entidades del modelo de datos y las relaciones/asociaciones.

Associations Creadas

Vimos en la entrada «OData y SAP Gateway – II – Publicar un servicio OData en SAP» como creábamos Associations o relaciones entre entidades, y el resultado es el siguiente:

Donde vemos que al crear las asociaciones se crean tambien Association Sets y Navigation Properties desde la entidad Padre a las hijas.

Clase de Implementación

En la clase de implementación que crea el proyecto de Gateway ZCL_ZODATA_TEST_BP_DPC_EXT redefinimos solo un método, el GET_ENTITYSET de la entidad BUSINESSPARTNERS.

Pero claro, ahora estamos hablando de relaciones entre entidades, y queremos saber cómo implementar consultas de Business Partners que nos traigan las subentidades de cada BP (Roles, Direcciones, Relaciones con otros BPs y Números de Identificación).

Para ello nos va a valer la Query simple que implementamos, pero queremos que, cuando llamemos a la consulta, nos devuelva los BPs y sus entidades relacionadas.

Uso del $expand en la consulta

Para poder consultar las subentidades de cada entidad en una consulta, usaremos en la URL de llamada al servicio la sentencia $expand. Podemos ver la documentación oficial OData al respecto de la sentencia $expand. Por ejemplo si hacemos una búsqueda de Business Partners y, para cada uno de ellos queremos saber sus roles, realizaremos la consulta de este modo. Para ello ponemos en el Gateway Client (/IWFND/GW_CLIENT).

Error Method ROLESSET_GET_ENTITYSET not implemented

Pero nos da ese error, y esto es porque no hemos implementado el método del GET_ENTITYSET (dame la colección de datos) de la entidad ROLES.

Implementar el GET_ENTITYSET

Para implementar el GET_ENTITYSET nos iremos a nuestra clase Z*DPC_EXT y buscaremos el GET_ENTITYSET de nuestra entidad que queremos consultar. Y redefinimos el método.

Pero claro, una vez redefinido, tenemos que implementar la lógica al respecto de esa acción (GET_ENTITYSET) de esa entidad (ROLES). Vemos que en la firma del método tenemos muchos parámetros de entrada y un par de salida. Son los siguientes:

Parámetros de Entrada

  • IV_ENTITY_NAME: Nombre de la entidad que se va a manejar en el método. Normalmente, cuando hablamos de métodos propios de una entidad concreta, como es el caso, será irrelevante. Pero en otras ocasiones se trata de métodos genéricos, donde tenemos que cambiar la lógica de la acción propuesta en base a este método.
  • IV_ENTITY_SET_NAME: Lo mismo que el anterior pero con el EntitySet.
  • IV_SOURCE_NAME: Nos dirá si partimos de una entidad superior o no y cual es.
  • IT_FILTER_SELECT_OPTIONS: Tabla con los campos de selección que se hayan usado para la búsqueda del EntitySet mediante la sentencia $filter. En este caso si hemos añadido algún criterio de selección para los Roles. Puedes ver la documentación oficial OData sobre el FILTER.
  • IS_PAGING: Nos indica el TOP y SKIP para la consulta, esto sirve para acotar el número de resultados y poder paginar. Por ejemplo, si tenemos 1000 registros pero ponemos un TOP de 100 y un SKIP de 500, recuperaremos del 501 al 600. Puedes ver la documentación oficial OData sobre el TOP y SKIP.
  • IT_KEY_TAB: Si hemos accedido a la entidad por una clave, la suya o la de una entidad superior, en el campo KEY TAB vendrán las claves por las que se accede al EntitySet.
  • IT_NAVIGATION_PATH: Tabla que contiene la ruta de navegación entre entidades.
  • IT_ORDER: Tabla con los criterios de ordenación deseados para recuperar los datos de la colección del EntitySet. Puedes ver la documentación oficial OData sobre ORDERBY.
  • IV_FILTER_STRING: El string de búsqueda con los campos y los valores buscados. Es una forma distinta de manejar los criterios de búsqueda de la tabla IT_FILTER_SELECT_OPTIONS.
  • IV_SEARCH_STRING: Permite realizar búsquedas de texto completo en los datos de una entidad. Este parámetro permite indicar una cadena de búsqueda que se aplicará a varios campos de la entidad, haciendo más fácil encontrar registros que contengan el texto indicado en cualquier parte de esos campos.
  • IO_TECH_REQUEST_CONTEXT: Este parámetro proporciona información técnica sobre la solicitud actual. Contiene detalles relevantes del contexto técnico de la llamada al servicio OData, permitiendo acceder a datos importantes para el procesamiento de la solicitud. Desde este parámetro podemos recuperar mucha información:
    • Usuario llamante
    • Cabecera HTTP
    • Parámetros de la URL
    • IP del cliente
    • Parámetros de la Query

Parámetros de Salida

  • ET_ENTITYSET: Tabla de datos de salida de la consulta para devolver el conjunto de entidades (EntitySet) solicitado. Es una tabla interna, con el tipo de datos de la entidada, que contiene los datos que se devuelven al cliente como resultado de la consulta. Por lo tanto, es la tabla resultado que tenemos que rellenar con los datos buscados una vez aplicados los criterios de entrada.
  • ES_RESPONSE_CONTEXT: Es una estructura de salida de la consulta OData, contiene metadatos sobre la respuesta, como el número de registros devueltos, información de paginación, y cualquier mensaje de error o advertencia.

Implementación de ROLESET_GET_ENTITYSET

Bueno, mucha explicación de lo que son todos los parámetros que se manejan en el GET_ENTITYSET pero no mostramos cómo hacerlo en la práctica. Como es imposible abarcarlo todo en un artículo, los ejemplos de implementación serán sencillos, para complicarlo está la definición de los parámetros del GET_ENTITYSET.

Lo primero que vamos a hacer es ver qué nos llega en la entrada cuando usamos un $expand desde la entidad padre. Para ello, lo que queremos es parar la ejecución en ese método, lo que yo hago es poner una sentencia absurda para poder poner un Breakpoint externo.

Si alguna vez se cumple esto sal corriendo

Al ejecutar de nuevo la llamada en el Gateway Client (/IWFND/GW_CLIENT)

/sap/opu/odata/sap/ZODATA_TEST_BP_SRV/BusinessPartnerSet?$expand=RolesSet

Se abre la sesión debug en el breakpoint externo y podemos ver los datos que nos vienen:

Ahora podemos ver la definición de cada campo que hemos hecho arriba para entenderlo. Vemos que la entidad buscada (IV_ENTITY_NAME) es «Roles» que el origen (IV_SOURCE_NAME) es «BusinessPartner», que no tiene criterios de búsqueda añadidos, ni paginación, ni orden,que la tabla IT_NAVIGATION_PATH tiene un registro con la navigation properties RolesSet desde BusinessPartner, y tiene una clave en la tabla IT_KEY_TAB.

Ahí tenemos nuestro Business Partner padre

Ahora, teniendo el campo Partner en la tabla IT_KEY_TAB vamos a implementar la lógica para rellenar el RolesSet.

Este código se ejecutar una vez por cada Partner servido

Si ahora ejecutamos nuestra sentencia ya veremos datos de los roles de cada uno de los registros de Business Partners.

Implementar GET_ENTITYSET del resto de entidades

Una vez tengamos implementado el GET_ENTITYSET de las subentidades nuestra clase Z*DPC_EXT quedará de este modo:

Y para el que le interese los GET_ENTITYSET quedarán de esta forma:

AddressSet
IdentNumbersSet
RelationSet

Seleccionar las entidades a recuperar

Pero claro, tenemos cuatro subentidades subordinadas de BusinessPartner. ¿Cómo tenemos que hacerlo? Para hacerlo pondremos en la sentencia $expand las subentidades que queramos recuperar, separadas por coma. En nuestro ejemplo la sentencia total sería:

/sap/opu/odata/sap/ZODATA_TEST_BP_SRV/BusinessPartnerSet?$expand=RolesSet,IdentNumbersSet,AddressSet,RelationSet

El resultado será que, para cada Business Partner, tendremos su colección de Roles, Números de Identificación, Direcciones y Relaciones. Por supuesto, para cada subentidad, tendremos que implementar su GET_ENTITYSET correspondiente.

Lo importante de esto es que podemos elegir qué subentidades recuperar, haciendo la recuperación de datos selectiva y dependiente del llamante.

Si te interesa, suscríbete al blog por email

El Síndrome del Impostor

Vamos a hablar de algo que me ha sucedido a mí (y me sigue sucediendo) y a mucha otra gente cuando asume ciertas responsabilidades o estatus en sus áreas de conocimiento y trabajo. No, no es que debido a eso atraigas más al sexo opuesto, eso sólo me pasa a mi. Estoy hablando del Síndrome del Impostor.

Y es que llegas a un proyecto, hablas con un amigo o compañero de profesión, hablas con un cliente o asumes una responsabilidad acorde a tu conocimiento y sientes que estás engañando a los demás, que tu no tienes los requisitos ni el conocimiento para asumir ese estatus, o responsabilidad. Sientes que eres un impostor, asumiendo un rol para el que no tienes capacidad o conocimiento.

¿Qué es el Síndrome del Impostor?

El síndrome del impostor se caracteriza por la creencia persistente de no ser lo suficientemente bueno o competente, a pesar de evidencias que demuestran lo contrario. La persona puede sentir que su éxito se debe a la suerte, o que ha engañado a los demás para que piensen que es más competente de lo que realmente es.

Esto puede suceder en muchos ámbitos de la vida pero se expresa con más claridad en el mundo laboral, al estar muy marcadas las responsabilidades y los perfiles.

Características Principales

Hay varias características del síndrome del impostor que se pueden dar

  • Auto-duda: Una desconfianza constante en las propias habilidades y logros.
  • Atribución a factores externos: Tendencia a atribuir el éxito a la suerte o a la ayuda externa.
  • Miedo al fracaso: Miedo constante de no cumplir con las expectativas y ser descubierto como un «fraude».
  • Perfeccionismo: Estándares personales extremadamente altos y miedo a cometer errores.

Resumiendo, crees que no vales para la responsabilidad que tienes, ya sea porque crees que estás engañando al resto o porque tu visión es de llegar a retos imposibles.

No sé decir «No»

Uno de los problemas es meterte en jardines que te van a generar incertidumbre o que están por encima de tus posibilidades y habilidades. No saber decir que «No» a los demás o a ti mismo te puede meter en un hoyo, en el cual creas que cavando más y más lograrás salir, y es justo al contrario.

Alguno sale por Nueva Zelanda

No sé. No puedo. Tengo otras tareas más prioritarias. Es imposible. No es mi responsabilidad.

Decir estas frases no te hace peor trabajador. Ser sincero es un aspecto positivo, ahora bien, en la sinceridad también está la responsabilidad siempre puede ir acompañado de un «haré lo que esté en mi mano» (pero no más de lo posible).

Nadie lo sabe todo y nadie es perfecto

A veces nos comparamos con otras personas que vemos como superiores a nosotros. No son perfectos, tu tampoco y nunca lo vas a ser (menos mal).

Yo nunca llegaré a sazonar así el entrecot

La estupidez es la felicidad

Si tienes este tipo de pensamientos, es porque eres capaz de evaluar las situaciones y fijas unos niveles de conocimiento y destreza inalcanzables, que son los que tú entiendes que son los óptimos para satisfacer una tarea. Pero la gente «normal» les vale con saber atarse los cordones, hacer lo que les mandan sin pensar en mejorarlo, hablar de fútbol y de política. Ellos en su falta de metas y autoexigencia son felices, y tú no. No te digo que hables de fútbol y política, pero tómatelo con calma. «Piano, piano si va lontano».

Métete un lápiz por la nariz para mejorar la experiencia

Celebra tus éxitos, valórate

Identifica y valora tus logros, si no te salen siéntate a escribirlos, si no te salen pregúntaselo a alguien de confianza que tendrá un juicio externo más claro. Ponte metas realistas y celebra su consecución.

Acabo de ir al baño. ¡Si!

En conclusión

No sé qué hago yo hablando de esto cuando no soy experto en nada de esto. Tampoco sé porqué tengo un blog de tecnología, si no soy ningún gurú y me falta mucho por conocer, hay mucha gente con mucho más conocimiento que yo. Voy a dejar el blog, me voy a apuntar a todas las ingenierías que haya y, cuando las tenga, podré ir dando lecciones. ¿Qué me he creído?

Tipos de Implementaciones: Greenfield/Brownfield/Bluefield

Hoy en «palabros en ingles de moda que usar en tecnología» vamos a hablar de los tipos de implementación de proyectos TI Greenfield, Brownfield y Bluefield.

Spoiler: que uno empiece por Green no significa que no pueda ser un marrón.

Los términos Greenfield y Brownfield provienen el mundo de la planificación urbanística y posteriormente se usaron para cualquier tipo de proyecto en cualquier ámbito. En este caso vamos a hablar de proyectos de implantación de TI, pero se va a entender la esencia para cualquier tipo de proyecto.

Greenfield

Greenfield se refiere a la creación de sistemas o proyectos desde cero, sin restricciones previas por trabajos existentes como un campo verde listo para ser construido (del urbanismo). En el ámbito tecnológico, esto implica la libertad de diseñar y construir utilizando las tecnologías más modernas y las mejores prácticas sin tener que considerar la integración o compatibilidad con sistemas antiguos.

Si conoces esta imagen ya eres un poco eXPerimentado

Vamos, un unicornio alado que resuelve todos los problemas sin mirar atrás. La realidad suele ser menos mágica. Esto es que implantes una solución que no se tenga que integrar con nada pasado y que resuelva un problema que o bien el cliente no tenía nada o bien el cambio es tal que es como hacerlo sin tener en cuenta lo existente.

Yo he estado en algunas de estas implementaciones, pero más porque se olvida el pasado y se realiza reingeniería de procesos.

Ventajas de los proyectos Greenfield

Bueno pues están bastante claras. Aunque alguna de ellas puede ser un arma de doble filo y suponer un reto.

  • Innovación: El cliente, y nosotros como implantadores, podemos elegir los productos, tecnologías y soluciones más innovadoras, sin restricciones (más allá del coste y el conocimiento) siempre se sea justificable y aporte el máximo valor. De esto se trata este trabajo, de modernizar empresas aportando las mejores soluciones y más innovadoras para estar en la vanguardia y tener una ventaja competitiva con la competencia.
  • Diseño: Permite tener libertad para diseñar la solución sin nada que nos ate y nos obligue con condicionantes.
  • Facilidad de mantenimiento: Al construir con tecnologías actuales, los sistemas son generalmente más fáciles de mantener y actualizar. Generalmente, que yo ya he visto mounstros de pocos años de vida.

Desventajas de los proyectos Greenfield

A su vez también tiene retos que sortear. Y aquí voy a repetir algunas de las ventajas, porque pueden traer problemas asociados.

  • Innovación: El papel lo soporta todo, y como el comercial de turno le de por vender lo último, de lo que no hay ni especialistas en el mercado, terminas en un Shitfield de campeonato. Además las empresas como SAP, Salesforce, etc a veces sacan productos muy innovadores que fallan más que una escopeta de feria. Y ahí estas tú, arreglandoles sus errores.
  • Diseño: Partir de la hoja en blanco también genera algo de vértigo. Además las reuniones con negocio y los keyusers depende mucho de la gente involucrada. Puede ser algo complicado de manejar.
  • Costo y tiempo: Diseñar y desarrollar un nuevo sistema puede requerir una inversión significativa de tiempo y recursos. Muchas reuniones para extraer requisitos, prototipos, pruebas de concepto, etc.

Brownfield

Brownfield se refiere a la transformación o cambio de sistemas existentes. Se trata de actualizar, extender o integrar nuevos componentes en infraestructuras o sistemas de software ya existentes. Puede ser un cambio de tecnología donde el cliente quiere mantener su funcionalidad pero usar una nueva tecnología como palanca para mejora, o puede ser cambio total de una funcionalidad pero en medio de un ecosistema complejo de integraciones.

No sé porqué quieren cambiar el sistema de gestión actual.
¡Si está perfecto!

Aunque comiencen por Brown, no necesariamente son peores que los Greenfield. Son los proyectos más habituales. Cambiar una pieza obsoleta por otra en un ecosistema complejo.

Ventajas de los proyectos Brownfield

Los proyectos Brownfield también tienen ventajas asociadas, quizás en el mundo del urbanismo sea más complejo, pero en el mundo de TI el que haya ya un camino sirve para fijarse en aciertos y errores.

  • Diseño más guiado: Al tener ya un mapa de procesos, casos de uso, funcionalidades imprescindibles, integraciones a mantener, etc, el diseño está más claro, pudiéndonos centrar en las áreas de mejora.
  • Aprovechamiento de activos existentes: Permite la reutilización de partes del sistema que aún son funcionales o valiosas.
  • Reducción de costos y tiempo: A menudo, es más económico y rápido mejorar un sistema existente que construir uno nuevo desde cero. Podemos decir que los esfuerzos del proyecto se mueven de una a otra etapa. Cuando ya tienes un sistema o aplicación desplegado el cliente sabe identificar su funcionamiento, sus puntos fuertes y sus debilidades.
  • Menor riesgo: Trabajar con tecnologías y sistemas probados reduce la incertidumbre.

Desventajas de los proyectos Brownfield

  • Dependencias con tecnologías obsoletas: Las dependencias con sistemas antiguos pueden limitar la innovación y la eficiencia. Además de no permitir implementar toda la funcionalidad posible en el sistema que estemos proponiendo. ¿Quién iba a decir que las comunicaciones Host-Host no iban a ser para siempre? ¿Qué es eso de REST? ¿OData?.
  • Complejidad y mantenimiento: Integrar lo nuevo con lo viejo puede resultar en sistemas más complejos y difíciles de mantener.
  • Resistencia al cambio: En proyectos Brownfield, puede haber una mayor resistencia al cambio, tanto a nivel técnico como cultural, dentro de la organización. Los usuarios y el personal técnico pueden estar acostumbrados a los sistemas existentes, lo que dificulta la adopción de nuevas soluciones.
  • Riesgos de seguridad: Los sistemas antiguos pueden contener vulnerabilidades de seguridad no detectadas o no corregidas, lo que puede representar un riesgo significativo al integrarlos con nuevas tecnologías o al intentar modernizarlos.
  • Retos en la gestión del proyecto: La gestión de proyectos Brownfield puede ser más compleja debido a la necesidad de equilibrar la operación continua de los sistemas existentes con el desarrollo e implementación de las nuevas soluciones.

Bluefield

El término Bluefield, aunque no es un término ampliamente utilizado en todo TI, en SAP tiene un papel específico, específicamente en la migración a sistemas hacía SAP S/4HANA, se considera una estrategia híbrida que combina elementos de los enfoques Greenfield y Brownfield. Este método permite a las empresas adoptar nuevas funcionalidades mientras conservan elementos valiosos de sus sistemas SAP existentes.

En un proyecto Bluefield, las organizaciones pueden seleccionar y migrar sólo los datos y procesos que son relevantes para su negocio actual, permitiendo mantener personalizaciones sin necesidad de rediseñar todo el sistema. Esto facilita una transformación que es documentada y clara, y que puede ejecutarse según las especificaciones del negocio. La implementación Bluefield también destaca por ofrecer flexibilidad, ya que permite la transición de sistemas y datos de manera selectiva, lo cual es ideal para empresas que buscan minimizar interrupciones y riesgos durante la migración​

Ni Green, ni Brown, póngame un poco de todo

Por ejemplo, una empresa puede decidir utilizar Bluefield cuando necesite consolidar varios sistemas SAP locales en una plataforma SAP S/4 Hana unificada sin perder la continuidad de los datos históricos. Además, esta estrategia es útil para organizaciones que requieren una integración detallada y personalizada que no sería posible simplemente con un enfoque Greenfield o Brownfield.

En resumen, Bluefield ofrece un equilibrio entre la innovación y la utilización de activos existentes, proporcionando una opción viable para las empresas que necesitan tanto mantener como renovar sus sistemas con nuevas tecnologías.

En conclusión

En el afán de ponerle nombre a todo y adaptar las palabras que vienen del inglés vamos a ir asumiendo todo este tipo de términos que, de primeras, no van a sonar nada y luego ya los usarás en tu día a día.

Ya sabéis:

Hay que dejar pasar al menos cinco minutos desde que aprendes algo nuevo hasta que miras con desprecio a quien todavía no lo sabe

Confucio, el inventor de la Confusión año 500 A.C.

En resumen, ya sea que optes por un Greenfield innovador, un Brownfield eficiente o un Bluefield equilibrado, lo importante es encontrar la estrategia que mejor se adapte a las necesidades específicas de tu negocio. Y si te pierdes entre tantos términos, al menos ya tienes un arsenal de palabros nuevos para tu próxima reunión.

Así que me voy a una Meeting vía Call sobre un proyecto Greenfield que vamos a hacer Agile, que tengo luego un Afterwork.

CU Later