Un enfoque inteligente hacia S/4HANA: Modernización y eficiencia con PRISM.

Hola, muy buenas tardes para algunos, buenos días. Gracias por acompañarnos en este webinar, un enfoque inteligente SAI SORHANA, modernización y eficiencia con PRISON. Antes de comenzar, queremos informarles que esta sesión está siendo grabada y que, al finalizar el evento, recibirán por correo el enlace a la grabación. Para asegurar una mejor experiencia, los micrófonos permanecerán silenciados durante toda la sesión. Si en cualquier momento tienen preguntas o comentarios, pueden escribirlos en el apartado de preguntas. Al final de la presentación, responderemos algunas de ellas, si el tiempo lo permite, de lo contrario, recibirán las respuestas por mail. Permítanme presentarme, soy Nancy Remolí, del equipo de marketing de EPI SAP para Sudamérica, y hoy estoy acompañada por Omar González, Advanced consultan con más de dieciocho años de trayectoria en el ecosistema SAP. Omar es experto liderando proyectos internacionales complejos de implementaciones y fusiones en sectores claves como manufactura y automotriz. Actualmente dirige equipos de consultoría enfocados en la optimización estratégica de servicios y el desarrollo del talento. Para quienes no nos conocen, les cuento un poquito quiénes somos. EPI-USE Labs es una empresa internacional especializada en soluciones de software y servicios gestionados con más de mil ochocientos clientes en cincuenta y cinco países, y más de veinte años de experiencia en el ecosistema SAP. Formamos parte del group elephant y destinamos el uno por ciento de nuestros ingresos al programa EPI, elefantes, rinocerontes y personas, una iniciativa sin fines de lucro dedicada a proteger especies en peligro y apoyar comunidades. Este mapa refleja lo que mencionábamos recién, estamos presentes, como dije, en cincuenta y cinco países. Esa escala nos permite ofrecerles la solidez de una organización global con capacidad de respuesta y conocimiento local que sus proyectos necesitan en todo momento. Así que, bueno, ya nos hemos presentado, le cedo la palabra a Omar para comenzar con la sesión. Omar. Nancy, muchas gracias, buenos días a todos. Muchas gracias por esta presentación, creo que es muy bueno que todos los amigos que se están sumando a esta a esta sesión puedan conocer un poquito sobre quiénes somos, cuál es nuestra experiencia, cómo trabajamos, y también muchas gracias por la presentación que hiciste de de mi persona. Muy bien, entonces, ahora sí, vamos a empezar con esta charla. La idea principal es de que podamos platicar de las diferentes estrategias que tenemos hoy en día para poder migrar nuestros sistemas actuales, que prácticamente casi todas las empresas aún continúan en SAP SC, cómo migrarnos a S4HANA, que es la nueva plataforma, la nueva tecnología que tiene tiene SAP. Entonces, en esta plática vamos a tratar de abordar esas estrategias que que SAP nos está proporcionando, más aparte algunas otras alternativas que son muy competitivas hoy en día en el mercado. Básicamente, cuando SAP nos propone sus estrategias, es muy drástico y nos da nos da prácticamente dos dos alternativas, el blanco y el negro, solamente que a SAP le gusta ponerle colores y le llama, a la primera le llama el greenfield y al segundo el brownfield. Seguramente muchos de ustedes ya han escuchado hablar de estos dos términos. Son muy son muy buenas las dos, sin embargo, son muy diferentes una con la otra. Cada una de las empresas tendría que hacer una un análisis profundo para determinar cuál de estas dos opciones se acomoda mejor a sus necesidades. Básicamente, el green field es cuando nosotros vamos a mudar nuestro sistema a una caja nueva, vamos a habilitar en un nuevo servidor, vamos a a instalar los servicios de SAP, nuestro subgee, y vamos a tener que reinstalar toda nuestra configuración. Si nosotros teníamos dos módulos, diez módulos, tenemos que hacer otra vez toda esa configuración que teníamos. Vamos a tener que, este, por lo mismo, tener un equipo de consultoría un poquito más robusto, porque vamos a tener que solicitar un experto en cada uno de los módulos. Por lo mismo, también vamos a necesitar que el que el negocio ponga a un equipo de key users un poquito grande para que puedan validar y verificar que todo lo que se está reconstruyendo y reconfigurando realmente funcione y no deje algo olvidado o algo que esté, este, no no no funcionando de la manera en que debería de de hacerse y genere algunos problemas ya una vez en la operación. ¿Cuál es la consecuencia de esto? Al tener equipos un poquito más grandes y al ser una reimplementación en la que vamos a construir otra vez toda la configuración y vamos a tener que hacer todas las pruebas y todas las validaciones de forma exhaustiva, pues los tiempos del proyecto también se van a alargar un poquito más. En los mejores de los casos son implementaciones de ocho meses para este tipo de de de proyecto. ¿Cuáles son las ventajas? Las ventajas es de que es prácticamente un borrón y cuenta nueva, donde dejamos todo el histórico atrás y vamos a empezar con una historia totalmente nueva una vez que lleguemos a nuestro sistema de Greenfield. Vamos a migrar únicamente los saldos iniciales, el opening balance, pero todo lo demás se queda atrás. Y como esto es una configuración nueva, se vuelven a cargar datos maestros, se vuelve a cargar las pólizas que estén, este, abiertas, pues el usuario también va a tener que tener una curva de aprendizaje, porque muchas veces ellos ya conocen de memoria el el número de sus clientes, el número de sus proveedores, de sus materiales, de sus bancos, etcétera. Puede ser una gran cantidad de elementos que, este, que ellos ya tengan muy bien familiarizados, y ahora, al al cargarse en este sistema, pues la numeración va a ser diferente, porque los contadores vuelven a empezar desde cero y, entonces, tendrían que acostumbrarse otra vez a a cuál va ser el nuevo número, volver a crear sus layouts, sus templates, este, sus variantes. No es algo complicado, pero, de momento, al al inicio es una, pues una brecha o es un reto que van a tener usuarios. Y, finalmente, todo el histórico no lo vamos a tener en S4HANA, tendrían que irlo a consultar a sus sistemas actuales, que se quedarían únicamente con la opción de display. Básicamente, así se comportaría una migración en Greenfield. A su vez, tenemos la de Brownfield, que es el otro extremo, es la otra cara de la moneda. Aquí lo que se va a hacer es, vamos a migrar con toda la casa. Es como si nosotros nos estuviéramos mudando y compráramos un terreno nuevo, el cual está vacío, pero nosotros viviéramos en una casa rodante, entonces la metemos en el trailer y la transportamos completita hacia el nuevo terreno. Cuando llegamos allá, tenemos absolutamente todo, vamos a tener todos nuestros programas, estándar o no estándar, vamos a tener todas nuestras tablas, nuestras estructuras, todo lo que tenemos z, nuestros user exits, todo va a estar ahí disponible, y cuando bajemos la información, va a bajar con toda la historia que teníamos. Es decir, si nuestro sistema SC el día de hoy tiene un histórico de quince años, de veinte años, todo eso va a pasar tal y como está y lo vamos a tener en nuestro sistema browser. Significa que va a ser muy simple y muy sencillo para los usuarios adaptarse a este nuevo sistema porque conocen todo lo que tiene. Sin embargo, va a haber algunas mejoras que que para ellos va va a ser muy representativo, aunque no vean dónde están. Las mejoras normalmente son técnicas, tiene mejor performance, mejor lectura de las tablas, todo ya se encuentra en la tabla universal, etcétera. O sea, hay hay algunas, este, ventajas de esta ya en S4HANA, que el usuario va va a identificar y se va a sentir más a gusto una vez estando ahí, pero toda la historia y todos los elementos que que estaban van a pasar tal y como estaban. ¿Cuál podría ser una de las ventajas, desventajas, perdón? Si bien es sabido que siempre que tenemos una implementación tenemos vicios, tenemos procesos que se llevan a cabo no de la mejor manera, y durante la marcha vamos identificando y decimos, híjole, esto hubiera sido mejor si lo hubiéramos configurado de esta manera o este proceso funcionaría mejor si está, si lo operáramos de esa otra forma. Aquí como lo estamos migrando tal y como está, pues esos problemas se van a mantener, ahí vamos a perder la oportunidad de poder hacer una adaptación o una solución a ese tipo de de de temas, y pues bueno, ese es uno de los de los contras. Tampoco vamos a tener transformación de de datos o de procesos porque estamos llevándolo todo tal como lo teníamos. Y, finalmente, pues vamos a mover hacia nuestra nueva casa una cantidad de datos históricos muy, muy grande, este, con todo el histórico que tenemos, lo cual, pues también se transforma en costos al momento de el licenciamiento con SAP. Como saben, S-FORHANA, este, se mide en FUES. FUES, para términos prácticos, es el tamaño de nuestra base de datos, y dependiendo de qué tan grande vaya a ser esta base de datos, es el costo que SAP nos va a proporcionar para nuestras licencias. Si vamos a hacer un brownfield, tenemos que estar conscientes que el tamaño de la base de datos que vamos a requerir en en S4HANA va a ser grande y, por lo tanto, el costo de licenciamiento puede ser un poco mayor, así nos, a que si nos enfocáramos en un esquema tipo greenfield. Básicamente, estas son las dos estrategias que SAP proporciona y, como lo ven, son muy, muy drásticas y muy diferentes una con la otra. Esto ha generado que muchas empresas se sientan que que no tienen una estrategia lo suficientemente robusta y flexible para cubrir con sus necesidades y con sus expectativas, y por lo tanto están evitando a toda costa migrar a S4HANA durante el tiempo que se pueda. Sabemos que SAP está presionando mucho para que estas migraciones se den ya lo más pronto posible, y comentaron que hasta el veinte veintisiete van a dejar de dar soporte a todos los sistemas SCC. Después comentaron que iban a dar una extensión hasta el dos mil treinta, pero no más. Si no llegamos al dos mil treinta ya migrados a S4HANA, pues algo tendrán que hacer las empresas en otro sistema, porque ya no van a tener soporte en ese. Con esto, nosotros, EPI SAPs, hemos creado una alternativa flexible que puede ayudar mucho a las empresas para tener algo intermedio entre el green field y y el el brand field. Nosotros lo llamamos PRISOOM SDT. PRISOOM es nuestro nuestra metodología, nuestro producto, el cual tiene varias herramientas para atacar distinto tipo de de problemáticas y de requerimientos, y SDT es una de ellas. Está llamado así por sus siglas en inglés, que es es selective data transition, es decir, la selección, la transición selectiva de datos. ¿Qué es esto? Es una estrategia que nos va a permitir hacer un híbrido entre el Greenfield y en Brownfield. Prácticamente, nosotros podríamos replicar el repositorio a ABAP en una nueva caja, en un nuevo servidor, de modo tal que no se pierdan los programas, que no se pierdan las estructuras, que no se pierdan nada de lo que ya tenías construido a lo largo de la historia, y aún así tener algo muy similar al gniffle una vez después de la migración. También podemos seleccionar qué vamos a llevar. Podemos hacer cortes por tres tipos de, este, de aristas. Una, ¿cuántas compañías de las que tengo hoy en mi sistema quiero migrar? Al igual tengo diez, pero solamente siete siguen en operación, las otras ya no me interesan. También, estas estas empresas pudieran tener, como lo mencionábamos, quince o veinte años de historia. Son muchos datos que, prácticamente, no hace sentido que los migremos. Sabemos bien que, por regulaciones, este, legales, dependiendo del país, estamos obligados a mantener ciertos años de historia. Por ejemplo, en México son diez años, en otros países nos piden cinco, entonces, todo lo que exceda ese tiempo lo dejamos por fuera y solo migramos lo que estamos obligados a mantener. Y, aun así, todavía podemos ser más selectivos y llevar a S4HANA el último año completo, cerrado, que sería, en este caso, veinte veinticinco, más los meses que van en curso de dos mil veintiséis, cuatro meses, y lo los cuatro años restantes, o los nueve años restantes que nos pida el gobierno, los podemos almacenar en otra herramienta que se llama Kaife Central, parte de Privacy. Es mucho más barata en costo, mucho más barato en licenciamiento que si lo tuviéramos en un servidor de de SAP. Archive Central también cuenta con uso de roles y perfiles para que las personas que tengan acceso solamente puedan ver los datos que corresponde a su posición y que corresponde a sus necesidades. Esa información va a estar disponible las veinticuatro horas, los siete días de la semana, y como prácticamente es una extracción de SAP a archive central, tiene todo, o sea, todas las tablas se extraen y se poblan ahí en archive central, así que si nosotros queremos ver los reportes, podemos tener el mismo juego donde quitas columnas, metes columnas, haces un ordenamiento, sacas subtotales, exportas Excel, creas variantes. Todo es muy, muy similar a a SAP. Cambia un poquito la la estética de las pantallas, pero, prácticamente la funcionalidad se mantiene. Incluso el drill down, donde si tú estás en una factura y le das doble clic, puedes ver qué orden de compra la detonó, y si le das doble clic, te puedes ir un poco más atrás a la requisición de compra, etcétera, todo eso está disponible. Con eso disminuimos en gran tamaño lo los datos que vamos a llevar a un S4HANA, por lo tanto, también los UFs se van a hacer mucho más pequeños y nuestro costo de licenciamiento va a ser más barato. Ese, a grandes rasgos, es la definición de SDT. También nos va a dar la posibilidad de que nuestro proyecto de implementación lo podamos hacer de una manera planificada, es decir, no es un big band. Si nosotros tenemos diez empresas, no es necesario que migremos a las diez empresas en un solo golpe, elegimos la empresa más pequeña, la que su operación sea más sencilla, la que sea menos riesgosa, y esa es la primera que tomamos y la migramos. Obviamente, van a salir algunos temas a resolver, algunas lecciones aprendidas, algunos problemas que se tengan que atender, y todo esto se documenta para que en la siguiente ola, donde migremos otras compañías un poquito más complejas, todo esto que ya aprendimos en la primer migración no nos suceda, no estamos exentos a que aparezcan nuevos retos. De la misma manera, se van a documentar, se van a resolver, y entonces nos vamos a la siguiente ola y a la siguiente ola hasta poder migrar a las compañías más complicadas, a las más robustas, de una forma mucho más sencilla, más transparente, digamos, tipo como cuchillo en mantequilla, donde no va a ser doloroso, va a ser más más sencillo para toda la operación, para todos los usuarios, para todo el mundo, es mejor tener una migración planificada que tener un big bang. Nos va a permitir reducir la huella de datos. Como les mencionaba, nosotros podemos viajar a nuestro exforjana con un año de historia, y el y los demás años que el gobierno nos obligue a mantener, lo podemos salvaguardar en de modo tal que nuestros sistemas SAP sean muy pequeños, mucho más eficientes y más baratos. Después, también nos va a permitir adaptar y transformar los objetivos o los procesos. Presum tiene también una herramienta que permite la transformación de datos. Si nosotros tenemos hoy en día una estructura donde mi empresa tiene cinco plantas, pero nos hemos dado cuenta que con cinco plantas, al igual, no es como lo deberíamos tener, lo podemos reducir a tres. Entonces, cuando migramos a a Esforjana, convertimos toda esa data histórica que estaba repartida en cinco plantas, lo podemos reducir a que solo estuvieron en tres. Y entonces, toda la historia que tú tengas en S-ForHANA va a estar representada solo en tres plantas. Podemos convertir datos maestros si queremos cambiar nuestros centros de costos, ya vimos que teníamos demasiados, y podemos fusionar algunos, podemos hacer también que toda esa historia sea representada únicamente en los centros de costos que queremos mantener y quitamos todo lo demás que no nos no nos funciona, lo cual nos da una oportunidad bastante, bastante atractiva para que no solamente migremos a nuestro SJORJANA, sino poder hacer transformación, reestructuración, reorganización de nuestros datos y de nuestro, este Ay, se me fue el nombre, nuestra estructura organizacional. Finalmente, al tener proyectos con SDT más cortos, con menos tiempo ¿Por qué me digo que más cortos y con menos tiempo? Preasum es una herramienta automatizada, como bien lo mencionó Nancy al principio de la sesión, tenemos más de veinte años trabajando este tipo de proyectos y con herramientas que se han ido madurando a lo largo de este período y se han ido robusteciendo, de modo tal que no necesitamos inventar el hilo negro cuando llegamos con un nuevo cliente, prácticamente instalamos nuestro software, podemos hacer uno que otro ajuste dependiendo de las necesidades de la empresa, pero, prácticamente, los procesos están automatizados. Entonces, si nuestra compañía hoy tiene configurados diez, doce módulos con dos personas, podemos migrar todo lo que tienen estos doce módulos hacia nuestro S4HANA de una manera rápida y sencilla por procesos automatizados. Por lo mismo, también disminuimos el tiempo, la cantidad de recursos y, este, al ser un proyecto más barato, el retorno de la inversión va a ser mucho más rápido y más acelerado que si lo hiciéramos con algún otro tipo de metodología. Entonces, esto es lo que nosotros tenemos en SDT, es una opción flexible, intermedia, entre el Greenfield y el Brownfield. Y, bueno, una vez que nosotros estamos en un proyecto de migración, podemos enfocarnos, por ejemplo, como es flexible, nosotros podemos acercarnos más a un enfoque brownfield o más a un gridfield, dejarlo en medio, el cliente nos dirá cuál va ser su su estrategia y y y de qué manera podríamos cubrir su requerimiento de la mejor manera. Entonces, si nosotros nos estamos apegando más a un tipo brownfield, en el cual vamos a mantener todo nuestro repositorio a va y vamos a migrar una cantidad grande de de datos, pues, con con Presum podemos ofrecerle también a nuestros clientes el que sea más sencillo migrar a nuestro sistema destino. Cuando hablamos de un brownfield, normalmente es migrar a la nube privada para que podamos mantener todos nuestros programas y nuestras personalizaciones, o quedarnos on premise, donde nosotros somos los dueños de los servidores y son servidores físicos. Con SSDT podemos nosotros también migrar temas de nómina, BW, y podemos anonimizar datos. También es muy sabido que últimamente los gobiernos en varios países están cuidando mucho el tema de la privacidad de los datos. Entonces, si nosotros tenemos en productivo datos sensibles de nuestros clientes, como su RFC, su correo electrónico, sus cuentas bancarias, si nosotros vamos a utilizar esto para refrescar nuestros sistemas de calidad y desarrollo, en esos sistemas muchas personas se pueden conectar y no hay tanto control sobre qué pueden ver o qué no pueden ver. Entonces, nosotros tenemos también una herramienta que puede, no borrar los datos, bueno, los puede borrar, pero también los puede anonimizar. ¿Para qué? Para que cuando hagamos pruebas y necesitamos que tenga esto o algún valor para poder generar nuestro proceso completo, pues el campo no esté vacío, tenga un dato que es ficticio, que cumpla las características que debe de tener, pero es un dato ficticio y salvaguardamos la privacidad de los datos de nuestros clientes, y puede ser con los proveedores y puede ser con distintos elementos. También en algunos países estamos obligados a que, si ya no tenemos operación con un tercero en más de tres o cuatro años, debemos eliminar esa información sensible, incluso de nuestros sistemas productivos. Entonces, también podemos hacer esa anonimización a ese nivel. Cuando nos referimos ahora a a pegarnos más a un tipo greenfield, igual, nosotros vamos a implementar la nueva caja, nuevo servidor, donde se va a alojar todo esto, y podemos hacer una copia selectiva donde vamos a pasar toda la configuración. Eso le va a ahorrar a los proyectos un gran esfuerzo, donde ya no tienen que hacer la reimplementación de todos los módulos, probarlo y demás, lo copiamos, toda la configuración pasa tal y como está. Una vez que ya tenemos la configuración en nuestro servidor, ahora sí, con s d t, elegimos qué datos vamos a llevar, qué datos nuestros de qué compañías y los datos transaccionales, con cuánto tiempo de historia los vamos a los vamos a migrar. También en este tipo de enfoques podemos utilizar estas herramientas de anonimización para salvaguardar esos datos sensibles. Ahora, una pregunta que nos hacen mucho y es muy recurrente, oye, Omar, pero si vamos a migrar solamente los últimos dos años o los últimos tres años, ¿qué pasa con los flujos que quedan en medio? Es decir, tú ya tienes la tu factura y tu factura está en ese intervalo de tiempo, entonces, la vas a migrar, pero lo que la detonó, o sea, todos los procesos previos, pues son un poquito más viejitos de esos tres años. Entonces, si tú migras esa factura, me vas a dejar ahí en mi sistema, en S-ForHANA, flujos a la mitad, flujos partidos. Bueno, pues una de las magias que tiene Prison es que cuando encuentra este tipo de escenarios, va a, ok, ya identifica que esta factura está abierta y que pertenece al período de tiempo que vamos a migrar, pero va a leer desde dónde viene, su historia, qué tan atrás va. Y aunque esta historia esté fuera del período que estamos migrando, en en vez de no dejar un flujo incompleto, para ese caso en particular va a migrar datos que sean incluso más viejos. Pueden ser de cuatro años, cinco años, los que sean, pero si el flujo inició más atrás, lo va a llevar completo, de modo tal que tengamos esa integración y todo ese escenario completo en nuestro sistema destino. Bueno, ahora bien, cuando estamos hablando de que vamos a migrar a un sistema S4HANA, principalmente aparecen estos cinco rubros, que son los desafíos que las empresas enfrentan. El primero, este, reducir los costos. Es bien sabido que nuestro sistema productivo puede ser robusto y puede contener muchos datos. Si nosotros elegimos una estrategia más apegada a un brownfield en el que vamos a migrar varios datos, bueno, eso no significa que perdamos la oportunidad de ahorrar costos en cuanto a almacenamiento y base de datos, porque nuestro landscape no solamente está construido por un sistema de producción, también tenemos un sistema de calidad, también tenemos un sistema de desarrollo, que si bien no vale la pena que hagamos una copia íntegra de productivo, porque sería muy grande y muy pesado, con s d t podemos llevar a estos sistemas una cantidad reducida de datos, pero datos frescos, datos reales, para que estos sistemas puedan seguir siendo muy útiles al momento de que necesitemos configurar una nueva funcionalidad, que necesitemos dar entrenamiento a algún equipo, que necesitemos replicar algún escenario que nos está generando algún problema en producción. También en el momento en el que necesitamos hacer pruebas para instalar un nuevo support pack o, este, alguna mejora, entonces primero lo lo instalamos en estos sistemas, lo probamos y ya después lo liberamos a producción. Entonces, a reducir mucho el tamaño de estos sistemas no productivos, lo cual también es ahorro de costos. La reducción de riesgos. Aquí, en este tema, lo que les comentaba, podemos anonimizar los datos sensibles, podemos transformar datos y poder hacer cumplimiento a las reglas que nos están imponiendo hoy en día los diferentes países. Una gestión eficaz en el proceso en el que vamos a migrar a nuestro sistema S4HANA, que puede ser un RISE, es con armonización de todo el proyecto. La optimización de costos en productivo, esto va a que si nosotros no vamos a migrar un brownfield, sino vamos a tener un SDT, en el cual migramos solamente unas cuantas compañías, solo migramos unos cuantos años, pues la cantidad de los juez se disminuye, por lo tanto, los costos de licenciamiento van a ser más baratos. Y, finalmente, la agilización en una migración. Como les comentaba, estos procesos que nosotros tenemos son automáticos y, pues son mucho más rápidos que tener que llegar a hacer una adaptación y construir reportes, construir programas para extraer, para cargar, para convertir, todos nosotros lo obtenemos de una manera muy, muy armonizada y muy automatizada, lo cual, pues hace mucho más rápido y más sencillo un proyecto de de upgrade, como sería este caso. Muy bien. También en el, hace unos momentos les platicaba que muchos clientes están tratando como de hacer esta migración lo más lejos posible, cuando de plano no nos quede de otra, es cuando vamos a dar el brinco y, pues, agarraremos un proyecto de estos. Pero el hacer esto trae varios problemas y varios costos ocultos, donde no siempre va a ser la mejor opción. Por ejemplo, el primer bullet que tenemos aquí, el riesgo, el riesgo aumenta. ¿Por qué? Porque cada vez que nosotros perdemos esta costo de oportunidad de migrar de una vez, si nos vamos acercando al dos mil veintisiete o al dos mil treinta, va ser que no podamos hacer una migración de forma planificada y escalada en diferentes fases, vamos a tener que hacerlo en un big bang. Y si lo hacemos en un big bang, si tenemos un problema, va a afectar a todas las compañías en todos los procesos y, este, o, bueno, no en todos los procesos, pero sí puede afectar a todas las compañías al mismo tiempo. Entonces, vamos a tener ahí jornadas largas de hyper care tratando de resolver los problemas de la forma más inmediata, porque está generando una disrupción. Entonces, el riesgo de que esto suceda aumenta, caso contrario de que si lo haces de forma planificada, como lo mencionábamos, vamos corrigiendo los errores de las empresas más simples, después migramos a otra, la cual, pues, ya no va a vivir con estos problemillas y va a ser más sencillo que podamos hacer esa cobertura a todas las empresas que necesitamos migrar. Gasto ineficiente, tener que reescribir las mismas personalizaciones dos veces. Esto se refiere a que el día de hoy nosotros tenemos una operación y tenemos un negocio que mantener y que atender. Van a seguir saliendo requerimientos nuevos en los cuales vamos a seguir generando programas, vamos a seguir generando configuraciones, y el día que tengamos que migrar a nuestro desforjana, pues nuestra casa ya está ya está más grande. Es como el ejemplo de que si te vas a mudar de casa, ya no compras muebles. ¿Por qué? Porque tu mudanza va a ser más complicada, más costosa, más riesgosa, mejor te esperas a que te mudes a tu nueva casa, y ahora sí, compras todos los muebles que que te hacían falta y que quieres tener. Básicamente es eso. El aumento del mantenimiento. Ok. Como nosotros seguimos trabajando con nuestra base de datos en SC, la cual ya es muy grande, que tiene mucha historia, pues el mantener estos landscapes operando, pues nos va a generar costos. Cada vez necesitáramos más más espacio, no podemos reducir ahí el tamaño de de nuestros sistemas, entonces, pues vamos a tener ahí que pagar más dinero para mantener estos sistemas trabajando. Otro punto es, perdemos la oportunidad de utilizar las nuevas innovaciones, la tecnología que SAP nos está brindando el día de hoy. Es muy famoso hoy en día el tema de la la inteligencia artificial, la cual ya trabaja en S4HANA, ya hay muchos procesos que se apalancan de la inteligencia artificial. Y si nosotros no migramos, pues simplemente no la vamos a utilizar, y tenemos un mercado muy agresivo y muy competente afuera, donde nuestros competidores ya lo están usando, donde ellos ya están haciendo las cosas de una forma más moderna y más óptima. Nos está dejando mal parados y, pues pues las las leyes de la evolución, ¿no? El que no se adapta finalmente, pues está condenando a a morir. Entonces, es muy importante también este punto para poder utilizar estas nuevas mejoras y ser eficientes en nuestro trabajo. Obstáculos de la transformación. Sí, mientras más tiempo pasa, cada vez va a ser más complejo nuestro proceso de migración, porque vamos a tener más procesos, vamos a tener más cosas que atender. Finalmente, no es buena idea irlo aventando hasta el final. Entonces, lo que, en primera idea, muchas empresas consideran que es beneficioso adelantar el proyecto de migración hacia lo más lejos posible, pues nos damos cuenta que no, que no es lo mejor. Mientras más lo posterguemos, más caro nos va a salir, más riesgoso va a ser, perdemos la oportunidad de trabajar con las nuevas mejoras y, pues, nos estamos quedando menos competitivos en un mercado que, como ya lo comenté, es muy dinámico y necesita que nosotros estemos preparados para enfrentar cada uno de las demandas que nos esté demandando, que nos esté poniendo enfrente. Muy bien. Los enfoques para la migración selectiva de datos durante una transición es forjana. Si bien, como habíamos comentado, déjeme pongo aquí el puntero en modo láser, listo. Si nosotros hacemos una implementación tipo green field, pues sí, prácticamente el resumen de lo que ya habíamos platicado es que se cumple con los estándares, es decir, al no llevar toda nuestra personalización de los programas Z, nuestros repositorios SAP, etcétera, estamos llegando a una caja donde eso no va a estar, está apalancado en los best practices de SAP, y nosotros tendremos que adaptarnos a ello. Vamos a tener un nuevo sistema, el cual no va a tener nada de de datos, nosotros tenemos ahí la oportunidad de migrar solamente con los saldos iniciales y hacer estas reestructuraciones a nivel de la estructura organizacional, de nuestros datos maestros, etcétera. Es una oportunidad que ahí tenemos para poderlo para poderlo implementar. En el brandfield mantenemos todo lo que ya teníamos en nuestro sistema, todos nuestros programas, todas esas personalizaciones las vamos a mantener. No tenemos grandes impactos en los procesos, no tenemos que convertirlos de forma tan tan compleja o drástica, porque todos ya están ahí y ya ya funcionan, solamente es irlos adaptando a los que podemos mejorarlos con estas innovaciones que tiene esta nueva tecnología, la inteligencia artificial. Podemos tener una adopción moderada de BTPs y, pues, una limpieza progresiva del código, o sea, poco a poco podremos irnos deshaciendo de programas para ir tratando de llegar a un best practice de SAP, donde podemos funcionar con con el estándar. Ahora bien, si nos vamos a un enfoque híbrido, nosotros podríamos iniciar esta nueva caja manteniendo nuestros programas en caso que vayamos a nube privada. Si vamos a nube pública, pues bueno, los programas ya no los tendríamos ahí, pero pasamos toda la configuración que hoy tienes para que no la tengas que reconstruir. Aprovechas la la tecnología que nosotros tenemos, nuestras herramientas, para hacer también esas reestructuraciones a nivel empresarial de una forma ágil y sencilla, de una manera más transparente, más que también tendremos la flexibilidad de elegir con qué datos vamos a viajar, hacer las maletas para poder mudarte de casa y solamente empacas lo que quieres mantener. Todo lo que ya no quieras, lo dejamos atrás. Entonces, estos son los tres enfoques de migración que pueden ser atendidos con Prison. Entonces, cuando nosotros hablamos de un SDT para Greenfield es porque va a eliminar todos los datos que ya no necesitamos, es decir, si vamos a migrar solo con el opening balance, el histórico que estamos obligados a mantener lo llevamos a archive central, y entonces S4HANA queda muy reducido en datos. Si nosotros nos vamos a una solución híbrida, sí podemos llevar un poquito más de datos a al sistema nuevo para mantener un año, dos años de historia y que puedas generar esos reportes en caso de que los necesitaras, y, este, y elegir qué empresas podríamos llevar y cuáles le caen en el camino. Y si nos vamos a un brownfield, pues realmente aquí el ahorro en en espacio no lo tendríamos en el sistema de producción, pero sí en los sistemas de desarrollo, calidad, preproductivo, los cuales los poblaríamos solamente con los datos que el cliente necesite llevar. Muy bien. Ahora, el siguiente punto es, ¿por qué Uprise y cuáles serían los triggers que podrían convertir a Uprise en una buena opción para los para los proyectos? Podemos tener proyectos que sean impulsados por temas de tecnología. Cuando me refiero a sistemas, perdón, cuando me refiero a términos de tecnología es, por ejemplo, esto que estamos hablando. SAP está haciendo un loopgrade, una nueva versión, entonces hay que migrar de SC a S4HANA. Y PRISOOM es lo suficientemente fuerte y robusto para poder migrar nóminas, b w para S4HANA, para migrar SuccessFactors y más sistemas legacy que pudiéramos tener. ¿Cuál es la ventaja? Que, bueno, la ventaja ahorita se las voy a platicar un poquito más abajo. El otro trigger que podríamos tener para tener un proyecto de Prison son, ahora sí, requerimientos a nivel negocio, separaciones lógicas que nosotros tenemos un grupo de empresas, ok, vamos a seguir manteniéndolas, pero ahora quiero sacar dos compañías de de este sistema y mandarlas a otro. Estrategias que tienen los negocios. Entonces, los podemos mandar a otro cliente, otro mandante, o los podemos migrar incluso a otro servidor. Si vamos a hacer una separación física, porque estamos vendiendo una parte del negocio, entonces sí, vamos a sacar todo lo que esta empresa tiene o lo que una planta de la empresa tiene para migrarla a otro sistema destino. También podríamos generar fusiones. Si dos compañías se van a unir, Prison va a funcionar para que también este tipo de proyectos sean mucho más eficientes, más más rápidos. Si nosotros compramos una nueva compañía o un nuevo modelo de negocio que vamos a incorporar a nuestra compañía, también Prison va a ayudarnos mucho a hacer esto, facilitando todos los flujos, ¿no? Entonces, estos son los dos detonadores de utilizar Prison en nuestros proyectos. Ahora sí, ¿cuáles son las ventajas y los beneficios de utilizar Prison? El primero es un software basado en modelos de objetos. Nosotros no migramos, por decir así, tablas, nosotros migramos objetos. Para poner un ejemplo en particular, cuando hablamos de un documento contable, sabemos que el documento contable guarda unos datos en la tabla de cabecera, otros datos en la del detalle, otra otros datos en la tabla de impuestos, otros datos en la de retenciones y así, van a ser varias tablas las que van a guardar información de ese documento contable. Entonces, nosotros lo que hacemos es leer el objeto completo, el cual está repartido en diferentes tablas, y va a migrar la información que le corresponde sin importar en dónde esté. Eso va a salvaguardar la integridad de los datos y que nuestro sistema destino no vaya a tener alguna complicación, porque algo se quedó en el camino, porque no sabíamos de qué esta tabla también está involucrada o demás, eso no sucede porque se migra el objeto, sin importar en qué tablas estén, las va a leer todas y va a migrar esa información. ¿Por qué utilizar igual Presum? Pues porque Presum está lo suficientemente maduro y tiene la capacidad de migrar S4HANA, SC, Payroll, W, SuccessFactors, las verticales de industrias que se pueden implementar en las distintas empresas. Entonces, pues es ver un landscape completo. Muchas veces nosotros podemos enfrentar retos de de migrar, y llegan proveedores que nos dicen, ok, yo te ayudo, pero yo te migro el el EPI. Habrá que ver cómo le haces tú para que puedas migrar tus otros legaces. Y entonces tienes que tener un integrador que esté tratando de hablar con cada una de las partes que tú tienes, delimitar responsabilidades, hasta dónde llegas tú, hasta dónde llevo yo, y finalmente se hace más complicado, lo cual eso da también otro beneficio de ir con Prison, porque aquí es una sola compañía la que es capaz de moverte todos esos sistemas hacia los ambientes destino, poder hacer esos upgrades. Entonces, no necesitas ese integrador ni ni hay temas de que no se comunicaron o de que algo se quedó fuera del radar, todo lo hace una misma herramienta. También, socio de desarrollo de SAP y parte de la red UPHOUSE, es otro de los beneficios que tiene Prison, la evaluación rápida de datos y de diseño de soluciones. Esto se refiere a que cuando nosotros tenemos los primeros acercamientos con un cliente, y les voy a mostrar un ejemplo un poquito más más adelante, lo primero que hacemos es correr un reporte en su sistema productivo o en una copia reciente de su sistema productivo, y esto es como una radiografía que nos va a mostrar de manera general cómo están hoy en día, cuál es su forma, cómo están parados, cuáles son los retos que tendrían para sus proyectos, qué tendríamos que atacar, cuáles son los riesgos, y, entonces, con eso podemos hacer una un análisis muy ágil y muy asertivo, de modo tal que, una vez que estamos ya en el proyecto, no salgan sorpresas de que, ah, es que esto no lo vimos antes y, pues, nos está sucediendo ahorita y necesitamos resolverlo de alguna u otra forma, porque si no, nos salimos. No, este tipo de de de sorpresas ya no sucede con Prison, gracias a que este reporte nos dio toda la información que se necesitaba desde el inicio. Entonces, todo se planea y se gestiona para poder cubrir el cien por ciento de los requerimientos. Igual, el análisis de la transformación de la automatización lo vamos a poder hacer gracias a este reporte y podemos sentarnos con el cliente para determinar cómo va a ser esta transformación hacia su nuevo hacia su nuevo sistema. Y finalmente, como también lo vimos en la presentación de la compañía, pues tenemos más de veinte años de experiencia haciendo proyectos de transformación y proyectos de de upgrade. Estos son los los beneficios y las cualidades que tiene PRISOOM y que tiene EPI-USE Labs. Para resumir un poquito lo que hemos platicado en imágenes, a veces una imagen dice más que mil palabras, tenemos estos dos cuadritos, los cuales, pues, se traducen a lo siguiente. Hoy en día nosotros tenemos nuestro sistema r tres o nuestro sistema s c, el cual se ve de esta manera. Tenemos nuestro repositorio con toda la configuración independiente demandante, los clientes estándar, el cero cero, el cero cero uno y el cero sesenta y seis, y, finalmente, todo lo que sí es dependiente demandante, nuestros usuarios y nuestros roles y perfiles, la configuración dependiente demandante, nuestros datos maestros y nuestros datos transaccionales. Gracias a ese EDT, en el que nosotros hacemos una migración híbrida entre un greenfield y un brownfield, podemos obtener como resultado final algo como esto, donde podemos mantener el repositorio, si es que el cliente lo desea, vamos a traer igual los clientes default. Claro, estos no son operativos, aquí crearíamos los clientes en los que la empresa va a operar. Y, finalmente, cómo se va a ver esta parte de aquí. Lo la configuración la podemos traer completa, de modo tal que no se pierda absolutamente nada en el camino, pero el master data y el transactional data se va a ver muy reducido a cómo estaba en su forma original, a cómo queda en nuestro sistema S4HANA. Entonces, esta es como que la, toda esta plática reducida en una imagen. Y también usuarios y roles también los podríamos reducir. Ahí hay algunas estrategias que platicamos con los clientes, si es que desean hacerlo, pero también pudiéramos reducir el tamaño de usuarios y de roles y perfiles. Muy bien. La minimización del tiempo de inactividad. ¿A esto a qué se refiere? Cuando estamos ya en un proyecto y vamos avanzando y vamos avanzando y llegamos al punto en el que ya estamos a punto de salir en vivo, Aquí es algo que que normalmente da mucha preocupación a los negocios. Si nosotros vamos a hacer una extracción de datos y los vamos a cargar en otro sitio, pues necesitamos un downtime. Ese downtime es donde nosotros inhabilitamos el sistema para la operación. ¿Para qué? Para que todo lo que extraigamos pueda servir como cifrado control para que cuando carguemos hagamos las comparaciones de que todo está cuadrado, que todo está alineado y que no hay ningún problema, y mientras más se alargue este tiempo de downtime, más problemas y más compleja se va a hacer la operación para el negocio durante ese tiempo. Con PRISUM hemos logrado asegurar que un fin de semana sea más que suficiente para poder migrar todos los datos que se tienen que que se tienen que mover, reduciendo al mínimo todo este proceso de downtime y de guardar nuestra operación por fuera para después replicarla en el sistema destino y demás, todo esto se se reduce demasiado. Eso se logra por el corte quirúrgico que la herramienta puede hacer, extrayendo solamente los datos que necesitamos y no echándose un clavado hacia el universo de datos que tiene el sistema, y con una segmentación lógica que automatiza el manejo de las tablas, haciendo que las tablas más grandes se puedan se puedan leer de una forma más eficiente y más ágil, y hacer más rápida nuestra nuestro proceso de transición. Y aquí tenemos también un esquema, un un ejemplo donde la primer cosa que nosotros podríamos hacer es crear el nuevo Shell o la nueva ambiente de de de SAP a donde vamos a migrar. Esto se puede hacer antes de ese proceso de downtime, antes de ese cutover. Son actividades que podemos hacer una semana antes, dos semanas antes con antelación de modo vocal, que se puedan hacer las diferentes pruebas técnicas sobre este nuevo ambiente. Está vacío, totalmente vacío, pero ahí podemos analizarlo y ver que que que está en buenas condiciones para que podamos migrar todos los demás DAOs. Pero cuando llegamos ya a ese momento de cutover, de nuestro blackout, entonces empezamos a hacer nuestras exportaciones con estas herramientas automatizadas, y podemos hacerlo incluso por lotes, podemos correrlo por procesos en simultáneo. Y una vez que nosotros estamos haciendo esa exportación, podríamos empezar a cargar en el sistema destino, aunque no hemos terminado con todas las exportaciones. Es decir, no necesito terminar el export para empezar a hacer el import, lo cual, pues, reduce los tiempos también de esta fase de migración. Y también, durante este proceso, en el que salen los datos de aquí y van a llegar acá, es donde entra nuestra otra herramienta que hace la transformación de datos para anonimizar o para cambiar la estructura de la compañía o para modificar datos maestros, etcétera. Todo eso sucede en este inter y ya tenemos los datos listos como los necesita el negocio en nuestro sistema destino. La metodología que nosotros utilizamos en este tipo de proyectos se llama Kinetic, la cual se divide en seis diferentes fases. La primera es la preparación, corremos nuestro reporte SLO, mostramos los resultados, los revisamos con el cliente, evaluamos qué es lo que vamos a hacer en los puntos de riesgo o en los puntos en los que podría haber más complejidad, y se toman esas decisiones. Después, aquí se hace todo ese tipo de de planificación para que cuando lleguemos a nuestra fase de realización, pues ya sea construir sobre cosas que ya están en nuestro blueprint, ya tenemos todas esas definiciones hechas, y entonces aquí empezamos a construir, hacemos nuestras pruebas unitarias, y cuando estas pruebas unitarias son exitosas, se libera para que los usuarios puedan hacer sus pruebas integrales, puedan validar que el sistema funciona tal y como se espera, que nada se queda, que no hay disrupción en algún proceso. Y una vez que todas estas pruebas son satisfactorias y que cumplen con las necesidades, hacemos ya el proceso del deploy. Esta es nuestra salida en vivo, vamos a tener actividades un poquito antes, actividades durante y actividades después, pero prácticamente esta es nuestra puesta en marcha. Después de que ponemos nuestro sistema ya en en la nueva caja, ya que migramos todos los datos y que el usuario empieza a operar, pues vamos a tener una fase de soporte para ayudarles a estabilizar y poder apoyar al negocio durante este proceso de transición, que muchas veces, a pesar de todo esto, de que está automatizado y de que se disminuyen los riesgos, siempre pueden quedar dudas o siempre puede haber algún temita por ahí que pueda surgir, y entonces, pues damos ese soporte que que es necesario. Muy bien. También hace un momento les comentaba sobre nuestro reporte SLO assessment, SLO system landscape optimization, esa es la definición en sus siglas, y se ve algo así. Obviamente, es más grande el reporte, pero aquí solamente copiaron unas cuantas, este, imágenes donde nos va a mostrar, por ejemplo, cuál es el tamaño de nuestro sistema, de nuestra base de datos, y cómo se divide, por ejemplo, en los temas de basies tenemos tanto tamaño, en nuestro sistema de payroll, cuánto tenemos, en el módulo d c d, en el módulo de CO, ahí podemos identificar cuáles son los módulos más robustos, los más complejos, nos va también dar una resumen de técnicamente cómo está el sistema, cuál es la versión de SAP, cuáles son los niveles de support pack en los que están trabajando, todo eso lo podemos ver ahí también. Nos va a mostrar cómo está la estructura organizacional que tenemos en el sistema, cuántas hay, cuántas organizaciones de compra están ligadas, cuántas organizaciones de venta, si tenemos una compañía SEO que tiene liga a una empresa o a muchas, todo eso lo podemos ver aquí también, lo cual, pues, es bastante bueno para dimensionar qué es lo que se tiene que migrar, ¿no? Cuál es la estructura que debemos de tener. Podemos ver todo el histórico de de documentos que tiene el el sistema, y al saber todo el histórico, cuántos documentos tiene y dividido por empresas, nos permite hacer un cálculo muy eficiente para saber cuánto voy a necesitar despacio en mi sistema destino. Es decir, si yo tengo un millón de documentos contabilizados en diez años para cuatro compañías, ¿qué pasa si solo migro dos años y solo migro una compañía? ¿Qué tanto se va a reducir en porcentaje el tamaño de nuestra base de datos? Entonces, este análisis también es muy, muy bueno para dimensionar el tamaño de la camisa que vamos a necesitar en S4HANA y contratarlas, pues, el licenciamiento correcto para nuestra empresa. Este último de acá, que es de los más importantes, nos va a dar un indicador de qué tan sencillo está en este sistema hacer esta segmentación por compañía y por tiempo. Entonces, desde aquí nosotros podemos saber si hay tablas que no tienen el timestamp o si no tienen algún indicador sobre a qué compañía o qué planta o a qué elemento de estructura pertenece, podemos identificar cuáles son y cuántos son los registros que están faltando de estas características para que nosotros metamos ahí alguna lógica adicional que pueda obtener esos datos y poder cumplir con los requerimientos de la selección, con la transición selectiva de datos. Entonces, todo esto lo vemos en nuestro reporte al inicio del proyecto y, entonces, ya sabemos qué es lo que tenemos que construir y a qué problemas nos enfrentamos. Entonces, este es nuestro reporte. Y finalmente, ¿por qué elegir PRISOM para S4HANA? Podemos conservar las partes del sistema, lo que funciona bien lo podemos mantener, los vicios ocultos, los problemas que hemos venido acarreando durante años, los podemos corregir, y entonces esa es una de las de las de las ventajas. Podemos personalizar la solución de migración sin tener que reconstruir todo el sistema, sin tener que rehacer toda la configuración, sin tener que hacer otra vez todo desde el principio, eso lo podemos mantener y con la opción de de migrar los datos históricos. ¿Qué tan viejos nos quedemos? El cliente lo dirá. Podemos cambiar los entornos, es decir, podemos hacer separaciones físicas, podemos consolidar, podemos adquirir, podemos separarlo, todas esas esos cambios estructurales del sistema los podemos realizar, vamos a reducir el riesgo del proceso en minimizando la interrupción del negocio, es decir, pues, con herramientas automatizadas y certificadas por SAP, eso se me pasó decírselos. Estas herramientas de Prison no son de SAP, sin embargo, están certificadas por SAP y están disponibles en el marketplace. Entonces, las pueden ir a ver ahí, las pueden descargar. Obviamente, el licenciamiento sería por medio de nosotros, pero, pues esto nos nos da un gran parámetro de saber que estas herramientas son seguras y que van a reducir el riesgo. También podemos tomar solamente los datos históricos que necesitamos sin traer toda la historia que venimos cargando hacia atrás, y podemos conservar los flujos de documentos en los cuales, pues nuestra historia se partió, ¿no? Les comentaba el ejemplo, la factura cae adentro del rango que vamos a migrar, pero sus pasos previos están fuera del rango, entonces, esos flujos los podemos migrar a pesar de que estén en este tipo de escenario. Vamos a reducir y optimizar el tiempo de inactividad, es decir, para nuestra puesta en marcha solamente es un fin de semana, lo cual, pues disminuye mucho este tiempo de downtime y es prácticamente transparente para los negocios. Podemos introducir nuevos procesos empresariales, armonizando estos datos históricos utilizando la nueva tecnología como la inteligencia artificial, y, finalmente, obtenemos la la la posibilidad de anonimizar datos y convertir o transformar datos en este proceso de migración. Son son ventajas bastante buenas, bastante robustas, por las cuales Prison se convierte en una muy buena opción. Y les comentaba también en unos, hace hace unos minutos que Prison es una solución bastante amplia y bastante robusta, la cual se compone de diferentes herramientas. Las voy a platicar muy brevemente, cada una podríamos profundizar durante mucho más tiempo, pero no es el el objetivo de esta reunión, pero solamente para que tengan un contexto de qué puede hacer Privacy. La primera herramienta se llama DSM System Builder o Shell Sync. System Builder funciona para crear nuevos entornos en SC y Shell Sync para nuevos entornos en S4HANA. Entonces, puedes crear una nueva máquina, puedes crear un nuevo servidor, instalarle el el sistema SAP manteniendo todo el repositorio avap y toda la configuración independiente demandante con esta herramienta. Una vez que ya tenemos esa esa caja lista, ahora hay que poblarla de datos, y Client Sync se va a encargar de mover todo lo dependiente demandante. Toda la configuración, los datos maestros y datos transaccionales que el que el negocio necesite los vamos a mover con Client Sync. Object Sync y Object Extractor, aquí nosotros podemos migrar, este, por escenario, por objeto. Tenemos un problema en productivo donde no podemos pagar una factura, tenemos que replicarlo en calidad. Entonces, Object Sync va a tomar esa factura que existe en productivo y va a replicar el escenario tal cual y como está en el ambiente de calidad, dándonos un panorama superbueno para poder hacer, este, solución de problemas, o puedo replicar datos para poder dar un entrenamiento, para poder hacer tipos de pruebas, pero aquí voy por escenarios en particular. Archive Central es la herramienta con la cual nosotros podemos salvaguardar todo el histórico de datos que necesitemos sin la necesidad de llevarlo a un S4HANA, para que S4HANA esté lo más light que se pueda, que utilice lo menos posible de base de datos, y entonces, todo lo demás lo podemos mantener en archive central, lo cual, pues, les comentaba, tiene las mismas columnas, información y funcionalidades que SAP. Query Manager, este le gusta mucho al a los usuarios, porque con este ellos pueden crear los reportes que necesiten sin el requerimiento de una BAP, no necesitas un programador, no necesitas hacer una especificación técnica ni que sea muy compleja, aquí el usuario final puede crear sus reportes. Entonces, pues esta es una muy buena alternativa también para poder tener esa toma de decisiones rápida y asertiva. Variance Monitor nos va a permitir la comparación de datos de nuestros módulos de Rh y entre el sistema de nóminas. Entonces, cualquier discrepancia que exista entre estos dos nos va a brincar y nosotros vamos a poder mantener siempre esa integridad y que todo haga match entre estos dos. Data transform es la que nos va a permitir hacer la transformación de datos de nuestra estructura de empresas, datos maestros y demás. Podemos enmascarar los datos, todo lo que es salvaguardar los datos sensibles, todo esto lo podemos gestionar con Data transform. Después tenemos data registration on BTP for ISDT to SuccessFactors. Esta es para las migraciones que tenemos de otros sistemas de RH hacia SuccessFactors. Con esto también facilitamos mucho todo ese tipo de de proyectos. Y finalmente, posting engine. Si nosotros estamos trabajando en un proyecto en el que estamos separando una parte de la empresa porque la estamos vendiendo, porque la estamos separando a otro sistema o lo que sea, pues muy bien, con Client Sync ya movimos esos datos, ya los pusimos en otra en otra caja, pero la fuente sigue estando aquí, o sea, todos los datos que nosotros copiamos y que ya estén en un sistema nuevo siguen estando en nuestro sistema origen. Entonces, posting engine permite hacer una compensación de todas esas partidas que migramos de una forma igual, automatizada, limpia y quirúrgica, lo cual reduce mucho el tiempo de de esta implementación. Y, este, finalmente teníamos aquí otras láminas que ejemplifican los casos de éxito más recientes que hemos tenido, pero por cuestiones de tiempo ya no se los vamos a poder explicar. De todas formas, están disponibles en nuestro website. Si ustedes quieren entrar, ahí lo van a poder consultar, y pues con esto, este, terminaríamos nuestra nuestra sesión. Por cuestiones de tiempo, no vamos a poder ahorita responder preguntas en vivo, pero si ustedes las tienen, por favor, escríbelas, escríbalas en el chat y nosotros nos aseguraremos de que se puedan responder y se les haga llegar esa información, de modo tal que no se queden con dudas, que puedan tener claro todo esto que que platicamos el día de hoy. Entonces, Nancy, no sé si quieras cerrar. Buenísimo, gracias, Omar. No puedo prender la cámara, no sé por qué, me me parece un error, quería saludar, pero les agradecemos un montón la asistencia, que se hayan quedado un poquito más del tiempo que habíamos previsto. Cualquier duda, comentario, estamos a disposición, quedamos a la espera de de de sus preguntas. Y muchas gracias, Omar, por por esta presentación. Que tengan muy buena tarde. Con todo gusto, muchas gracias. Luego.