El día que SAP entró en la empresa

Un buen día SAP entra en la empresa. Alguien, probablemente de algún área de negocio, ha tomado la decisión de implantar el módulo XX de SAP para resolver una parte importante del negocio y el personal de TI aún no es consciente de la cantidad de cambios que se le avecinan.

Y los cambios llegan

Llegarán cambios en el área de operación. Las promociones de código entre entornos o deploys en terminología Java pasarán a llamarse transportes. Se harán desde el propio entorno SAP que dispondrá de herramientas para guiar todo el proceso que, en general, no estarán integradas con el resto de procesos de gestión del cambio y configuración de la instalación. Los jobs o procesos batch ahora pasarán a llamarse cadenas y también serán gestionadas desde un planificador propio de SAP que, como es de esperar, no se integra con el planificador corporativo. Y también habrá que decirle a los técnicos que vayan olvidando todo lo que conocían sobre los procesos de backup ya que serán completamente nuevos a todo lo visto hasta ahora.

Habrá cambios en el área de sistemas e infraestructuras. Todo lo aprendido hasta ahora sobre tunning de base de datos será, en general, algo del pasado. Será el propio SAP quien se encargue de toda esa gestión. Lo mismo aplicará en general para la configuración de los monitores transaccionales o los servidores de aplicaciones ya que será el propio SAP quien, en general, lo gestione todo. Los procesos de cambio de versión y aplicación de parches al software de base serán completamente diferentes a todo lo vivido hasta ahora.

Habrá también cambios en el área de desarrollo. Tendrán suerte los programadores COBOL porque en ABAP encontrarán algo muy similar a un COBOL orientado a objetos. Aunque tendrán que olvidarse de su creatividad ya que, con toda seguridad, mucho de lo que quieran hacer estará ya resuelto por un proceso estándar que únicamente habrá que adaptar. Más complicado lo tendrán los programadores Java ya que, pese a que WAS (el servidor de aplicaciones de SAP) es compatible con J2EE, no es aventurado decir que la programación Java en SAP se parece a lo que ya conocen de Java como un bit a una lechuga. El concepto de JSPs, más o menos, se transformará en algo llamado Web dynpro que encapsulará toda la lógica de negocio y lo cambiará todo.

Por último, habrá también cambios en la estructura de los equipos de trabajo. En la informática de siempre existía la figura del programador, del analista y del jefe de proyecto (cada organización le da un nombre diferente pero en general, quizá añadiendo o refundiendo algunos de ellos, los conceptos se mantienen).

Pero al llegar SAP aparece el consultor de SAP. No es el jefe de proyecto, tampoco es equiparable al analista y está muy lejos del programador. Y tampoco es el consultor de negocio habitual propio de las grandes consultoras. Su función es trasladar los requerimientos del cliente al modelo estándar de SAP y, en general, su mayor potencial no es conocer el negocio en sí sino el modelo de datos y procesos del estándar del módulo SAP en cuestión.

Gestionando el cambio

Con esos antecedentes, es prácticamente imposible que el personal de TI de la compañía reciba el nuevo proyecto SAP con los brazos abiertos. De hecho, lo más probable es que se produzca un gran shock en el que los ya existentes y los nuevos se vean mutuamente como una amenaza.

Tras el shock inicial habrá un 10 por ciento de personas que se adaptarán al cambio con gran rapidez y valentía; habrá otro 10 por cierto que, si el cambio es potente, probablemente se quedará por el camino y nunca llegará a adaptarse.

El 80 por ciento restante -la parte central de la campana de Gauss- pasará una por una por todas las etapas habituales de la gestión del cambio y si las cosas se hacen bien, gestionando en paralelo los cambios en la parte técnica y en la humana, probablemente no sin esfuerzo se llegará a la ansiada integración. El tiempo para esta travesía variará en función de la persona pero lo que es seguro es que no será inferior a los dos o tres años.


Integración

Es decir, al final deberá producirse la integración de las aplicaciones y formas de hacer del modelo SAP con las aplicaciones y formas de hacer ya existentes en la Organización. Así, habrá que empezar integrando el área de operación con herramientas y procesos comunes -en aplicaciones SAP y no SAP- para las copias de seguridad, la planificación de procesos o la gestión de la configuración y el cambio entre entornos.

Después llegará la integración del área de infraestructuras. Los técnicos de sistemas del resto de entornos irán familiarizándose con SAP hasta el punto de llegar a integrarlo en sus quehaceres diarios.

Por último se producirá la integración de los diferentes modos de planificar, diseñar y desarrollar aplicaciones. Los programadores y analistas de las aplicaciones pre-existentes descubrirán que SAP no es [tan] diferente de lo habido hasta el momento. Y a medida que se vayan familiarizando irán ganando en soltura dentro del entorno, tanto para el desarrollo en sí como para la parametrización del estándar. Será el momento para plantear conexiones e intercambios de datos entre los dos mundos.

Y si todo eso se realiza con éxito, simplemente, el consultor SAP externo dejará de ser tan vital. Los profesionales de la compañía -analistas reconvertidos a consultores o consultores reconvertidos a analistas- tendrán tanto el conocimiento del estándar como el conocimiento del negocio y la organización interna, lo que hará que la necesidad del consultor SAP externo se reduzca al máximo.

Es posible que la verdadera integración con SAP llegue cuando a la contabilidad se le vuelva a llamar contabilidad y no FI, cuando a los procesos de compra se les llame también por su nombre y no MM, cuando ya nadie se refiera a las aplicaciones de producción como PP, cuando un documento se guarde en el gestor documental y no en RM o cuando las aplicaciones de gestión de personas vuelvan a tener su bonito nombre, personas, y no HR.

No es trabajo de un día pero se hace camino al andar.

Enlaces relacionados:

     › John P. Kotter. Leading Change. Harvard Business School Press, 1996
     › Tons of IT: ¡Qué poco sexy eres COBOL!
     › Tons of IT: El mainframe frente a sí mismo


Nota: Todo lo aplicado a la gestión del cambio con aplicaciones SAP es válido para otros cambios traumáticos como la evolución de mainframes IBM hacia sistemas abiertos o la migración a Open Source. Es habitual que quienes plantean este tipo de proyectos se centren exclusivamente en lo técnico y tiendan a olvidar que las etapas de duelo profesional por el entorno que se nos fue se miden en un orden de magnitud de años.

www.tonsofit.com