El día que SAP entró en la empresa



RSS

Logotipo de SAP
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.

Dando una capa de pintura SAP al personal de TI
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

Etapas de las gestión del cambioCon 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 Gausspasará 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.

Trabajando en equipo
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.




RSS

6 comentarios

  1. Totalmente de acuerdo con tu opinión. Se ve que has profundizado en el impacto de la implantación de SAP. Para otro dia sería interesante la misma reflexion pero enfocada al usuario final y su direccion.

    ResponderEliminar
    Respuestas
    1. Ups. No es tarea fácil esa que propones. Por ejemplo, a mi me puede parece abominable (en lo estético) una aplicación en 3270 pero al usuario resultarle lo mejor de lo mejor porque tal vez su trabajo es de introducción de datos y lo que quiere es velocidad extrema en el 'ventaneo'. En ese contexto, el 3270, que es horroroso estéticamente, es inmejorable porque le da sopa con ondas a cualquier otro entorno. Es cien veces más rápido que cualquier aplicación en Windows y mil veces más rápido que cualquier cosa que hagas en la web. Eso sí, feo de narices.
      Hoy por hoy, me siento incapaz de hacer esa reflexión. Pero pensaré en ello. ;-)

      Eliminar
  2. Me ha gustado mucho Manu. Yo no soy tecnóloga pero entiendo que el cambio, en cualquier disciplina, significa evolucionar y eso... ¡siempre es bueno! Ya que estamos tanto tiempo en el currelo, que sirva para CONSTRUIR. Gracias por hacernos ver el futuro en el día a día. Sigue así please.

    ResponderEliminar
  3. Magnifico documento de opinión que refleja cuasi perfectamente la realidad, pero por ponerle un pero creo que deberías haber generalizado poniendo ERP´s en vez de SAP y hubieses tenido más adictos.

    Si bien has señalado perfectamente las etapas de la getión del cambio, creo que te ha faltado añadir una de las más interesantes que es la parte de continuidad. Al final del ciclo que has definido, se encuentra esa etapa en la que todas las empresas que se han metido en el mundo de los ERP´s estándares del mercado tiene que comenzar uno de los pasos más tediosos que consiste en la actualización a la nueva versión del ERP volviendo de nuevo a iniciarse todo el ciclo que has expuesto, sobre todo si el usuario final no ha sido muy colaborador y ha solicitado muchos cambios respecto al estándar.

    Es por eso que es tanto o más interesante que un buen gobierno de la parte TI vaya acompañado de un un buen gobierno en la parte del cliente. Es decir, que estos se abstraigan de sus antiguas aplicaciones y focalicen sus esfuerzos en conocer como funcionan los estándares porque de no ser así penalizarán en gran medida la labor de los equipos de TI y lo que es más importante minará en gran medida la moral de la tropa. En este punto es muy importante la labor del Consultor de SAP.

    Ya es bastante desesperante estar continuamente realizando cambios debido a la aplicación de parches para la correción de errores como para meterse en un cambio de versión cuando te has alejado del estándar.

    ResponderEliminar
    Respuestas
    1. Tienes razón Juan, casi todo lo descrito es aplicable a SAP y a cualquier otro ERP. Es más, creo que es aplicable a cualquier cambio traumático en TI. Sin embargo, creo que SAP lo enfatiza muchísimo más. Por ejemplo, tiene hasta su propio lenguaje de programación (ABAP), cosa que no ocurre con Navision o con las apps de Oracle.

      Salirse del estándar se paga, estoy de acuerdo. Hay pocas cosas más ilógicas que comprar una aplicación estándar y construir sobre ella un desarrollo 100% (o un porcentaje alto) a medida. O lo uno o lo otro porque ambas cosas a la vez implican más coste y menos ventajas.

      Eliminar


Los contenidos de Tons of IT están sujetos a licencia Creative Commons Reconocimiento 3.0 salvo donde se indique lo contrario.