¿Revolución o evolución?

Junto con la mediana empresa química Zschimmer & Schwarz, Consolut llevó a cabo una migración para obtener las innovaciones que simple Finance ya ofrece en la actualidad.

La posibilidad de llevar a cabo una migración en un sistema del cliente alejado de cualquier "condición de laboratorio" era a la vez un incentivo y un reto. Por parte de Zschimmer & Schwarz, la atención se centró principalmente en opciones de generación de informes más rápidas y mejoradas y, además, en un acceso simplificado a las tablas de la base de datos para poder diseñar interfaces de forma más eficiente en un entorno de sistemas heterogéneo.

El niño necesita nombres

En junio de 2015 había llegado el momento. Como sistema de prueba se utilizó un Hana (SAP ERP 6 EHP 7 sFin 1503), que se creó como copia del sistema productivo. Paralelamente, se creó un sistema no Hana correspondiente (SAP ERP 6 EHP 7, Windows) para realizar pruebas comparativas.

Aquí nos dimos cuenta por primera vez de lo que más tarde se convirtió en una certeza: SAP cambia los nombres de los productos y la designación de los lanzamientos a intervalos cortos. Al principio se utilizaron los términos Smart Financials y Simple Finance, pero en junio siempre se habló de sFin.

SAP Simple Finance add-on 2.0 for SAP Business Suite powered by SAP Hana" se convirtió en "SAP Simple Finance, on-premise edition 1503". Mientras que los estados de lanzamiento se diferenciaban inicialmente por una numeración ascendente clásica, SAP decidió este verano marcar el lanzamiento con el año y el mes de entrega (por ejemplo, 1503 = marzo de 2015).

Esto también se aplica a los paquetes de soporte. Desde el punto de vista de SAP, se trata de una migración con la versión "SAP Simple Finance, on-premise edition 1503, SPS 1505".

El núcleo de los cambios en sFin son los cambios en las estructuras de las tablas en el área de FI/CO. Anteriormente, existían tablas en SAP ERP para partidas individuales y saldos en los módulos de libro mayor, contabilidad de activos fijos, cuentas a cobrar, cuentas a pagar y controlling, pero éstas han sido sustituidas por una nueva tabla central (ACDOCA, ahora denominada "diario universal").

En consecuencia, todas las contabilizaciones de estas áreas deben reunirse de forma centralizada en este cuadro. La contabilidad financiera y el controlling se combinan en la base de datos. Hasta aquí la teoría. SAP combina este novedoso concepto con la garantía de que se mantendrá la estabilidad de todos los programas de aplicación.

Esto queda garantizado por el hecho de que, según el nuevo concepto, se puede seguir accediendo a algunas tablas que ya no son necesarias (por ejemplo, BSID, BSAD, COSP) a través de las denominadas vistas de compatibilidad. De este modo, los programas de aplicación siguen utilizando las tablas y vistas conocidas.

Sin embargo, los datos reales se recuperan a través de nuevas vistas, en sentido estricto a partir de la nueva tabla ACDOCA. Esto permite a SAP implantar un nuevo concepto de tabla sin tener que realizar cambios masivos en los programas de aplicación.

El impacto de este enfoque en el rendimiento conduce a algunos resultados sorprendentes. Sin embargo, no todas las tablas se sustituyen por vistas de compatibilidad. Por ejemplo, el BSEG y el COEP siguen existiendo y se rellenan en paralelo al ACDOCA. De este modo, la información se mantiene deliberadamente redundante.

Enfermedades infantiles

Antes de entrar en el nuevo mundo de las "finanzas simples", SAP ha creado una cabina para migrar los datos. Está claramente estructurado y cualquiera que ya haya realizado una migración al nuevo libro mayor o similar encontrará rápidamente el camino.

A través de una serie de pasos, los datos de las tablas de partidas y saldos anteriores deben transferirse a la nueva tabla universal ACDOCA. Hay un poco de personalización aparte, y a cada paso de migración le sigue al menos otro programa de pruebas.

Así, probablemente se podría realizar una migración en unas horas si no hubiera mensajes de error en los programas de comprobación en algún momento. Aquí es donde la contabilidad de activos resulta ser una fuente de problemas.

No es de extrañar, ya que las operaciones de la contabilidad del inmovilizado repercuten en varios ejercicios debido a su duración. Un cambio de personalización de la década pasada puede parecer erróneo desde la perspectiva actual, aunque los programas de aplicación no se hayan visto afectados por él a lo largo de los años.

Por si fuera poco, la gestión de datos en la contabilidad de activos fijos suele ser algo más compleja que en la contabilidad general o el controlling. Llegados a este punto, el proyecto ya no podía continuar sin un mensaje de OSS a SAP.

Al principio, el apoyo de Walldorf nos llevó a importar lo que parecían más de cien notificaciones, la mayoría de cuyas fechas de publicación se acercaban a la fecha actual. Ya era agosto y nuestra suposición de que un estado del programa de mayo del mismo año era base suficiente para la migración resultó ser una falacia.

Por muy útil que fuera el soporte de SAP en la tramitación, desde su punto de vista teníamos un estado del programa irremediablemente desfasado. En conversaciones posteriores, quedó claro que los programas de migración para la contabilidad de activos fijos de nuestro paquete de soporte presentaban algunas deficiencias conceptuales que sólo se subsanarían en el siguiente paquete de soporte.

Finalmente, SAP nos ayudó a evitar todos los escollos y a completar con éxito la migración. Esto se combinó con la afirmación de que entretanto se habían eliminado estos errores. Hay muchos indicios de que es así.

Una vez alcanzado este hito, nuestro interés se centró en las innovaciones de la aplicación. Un hallazgo importante: prácticamente no hay cambios en la SAPGUI. Aquí es donde SAP se pone al día con su estrategia inteligente.

Dado que la nueva concepción no requiere ninguna adaptación de los programas de aplicación, actualmente no hay ninguna ventaja adicional. ¿Qué ocurre con las tan promocionadas aplicaciones Fiori? Aquí, nuestra conclusión sigue siendo indecisa por varias razones.

Actualmente, el número de aplicaciones Fiori sigue siendo limitado y, en algunos casos, sólo se diferencia ligeramente de la SAPGUI mediante la reducción de las opciones de selección. En los portales de vídeo y presentaciones pertinentes, SAP presenta con demasiada frecuencia los mismos procesos especiales, lo que solidifica la impresión de que las ventajas adicionales de Fiori son aún manejables por el momento.

Visualmente, las aplicaciones Fiori representan sin duda un progreso. Sin embargo, gran parte de ellos no parecen coherentes por el momento y evocan asociaciones con un mayor desarrollo de las conocidas transacciones Enjoy. Cabe añadir que algunas publicaciones dan la impresión de que la función y el número de apps Fiori disponibles aumentarán significativamente en un futuro próximo.

Naturalmente, todos los implicados tenían grandes expectativas en el rendimiento del sistema Hana. Para permitir la comparación, el sistema productivo de Zschimmer & Schwarz (System i) se copió en una VM de Windows y en una VM de Hana con idéntico hardware. La comparación del rendimiento se llevó a cabo a nivel de SQL (véase la tabla).

Las pruebas #1 y #4 muestran la fortaleza del sistema Hana. En ambos casos, se observa un aumento significativo del rendimiento en el acceso a las tablas. La consulta de la prueba #4 es comparable en líneas generales a la de la prueba #3.

Los resultados de las pruebas #3 y #4 fueron sorprendentes. El acceso necesario en Hana a través de la vista de compatibilidad reduce significativamente la velocidad de acceso de lectura, de modo que Hana es incluso más lento aquí que los otros dos sistemas en comparación.

Señalamos que el hardware utilizado para Hana no estaba certificado por SAP. Es de esperar que con un Hana certificado (y, por tanto, más potente), los tiempos de acceso a las tablas BSID y BSAD se sitúen en el rango de SAP ERP en Windows.

Hasta ese momento, no estábamos muy contentos con los resultados que habíamos obtenido hasta entonces. Recientemente, analizamos la posibilidad de realizar "informes en tiempo real" con Hana. Una posibilidad es utilizar Hana Live.

SAP ofrece Hana Live Content para sFin. Esto permite acceder a los datos de la tabla ACDOCA directamente con las herramientas de BI de SAP (por ejemplo, BO Analysis for Office o BO Design Studio).

La segunda opción es utilizar un "BW incrustado" en el sistema Hana. Para ello, se crea un cliente BW adicional en el sistema Hana. Allí, SAP también proporciona contenido que puede utilizarse para acceder a los datos maestros y de transacciones de sFin en tiempo real.

Dado que se accede a los datos a través de InfoCubes virtuales, los informes pueden crearse fácil y rápidamente con herramientas SAP BI estándar. En ambos casos, no es necesario cargar los datos. Los documentos están disponibles para la elaboración de informes inmediatamente después de su contabilización. El rendimiento del acceso a los datos fue muy rápido en ambas opciones.

Revolución y evolución

SAP ha introducido un diseño de tablas orientado al futuro en FICO con sFin. En el momento de nuestro proyecto, los programas de migración seguían presentando errores. Sin embargo, estos errores deberían eliminarse en gran medida con un nivel de paquete de soporte actual.

El beneficio de las aplicaciones Fiori es actualmente todavía manejable. Todavía hay potencial aquí en los próximos años. Lo mejor llegó al final. Desde nuestro punto de vista, las posibilidades de los informes en tiempo real son actualmente el argumento más fuerte para una migración a sFin.

Desde el punto de vista de Zschimmer & Schwarz, actualmente existe un valor añadido especialmente para los clientes de SAP cuyo entorno ERP completo se ejecuta bajo SAP. Esta ventaja aún no se aprecia en los sistemas híbridos.

Por ello, Zschimmer & Schwarz ha decidido esperar a nuevos desarrollos y, en caso necesario, volver a evaluar la versión de software disponible más adelante. Quizás entonces haya suficiente valor añadido para hacer el cambio si es necesario.