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

Todos quieren ser globales

Erase una vez que se era en el mundo de la informática en el que existían empresas dedicadas al hardware, empresas dedicadas a la seguridad, empresas dedicadas al almacenamiento, empresas dedicadas al networking, empresas dedicadas a hacer potentes gestores de bases de datos, empresas dedicadas al software en general, empresas dedicadas a la consultoría, empresas dedicadas a los sistemas operativos,... y algunas -muy pocas- dedicadas a todo ello.

En esos años, no era muy difícil asociar a Oracle con las bases de datos, a Microsoft con Windows, a Google con los buscadores, a Cisco con la electrónica de red, a Checkpoint o Juniper con los firewalls, a Symantec, Mcfee o Panda con los antivirus y la seguridad, a EMC, StorageTeck o Hitachi con el almacenamiento, a Compaq, Dell o HP con el hardware de PCs y servidores, a SAP con los ERPs, a Telefónica con la telefonía, a Accenture con la consultoría, a ninguna empresa con el software libre o a IBM con todo.

Es posible e incluso probable que si se le preguntase a cada una de estas empresas todas dijesen que estaban en algún otro sector adicional al descrito pero en general se podía acotar sin demasiadas dificultades el core de su negocio.


Centrarse en el core del negocio

La tendencia era deshacerse de todo aquello que no estaba en el corazón del negocio y en esa línea quizá IBM fue una de las pioneras. Se deshizo de su división de networking al tiempo que firmaba un contrato estratégico con Cisco. Posteriormente, se deshizo de su división de equipamiento de usuario (PCs, PDAs -que oemizaba de Palm-, impresoras, ...) mediante la venta a la china Lenovo. Más tarde vendió su división de impresión profesional a Ricoh (absorbida mediante InfoPrint).

El fin último era centrarse en el software, en el hardware (servidores, mainframe y almacenamiento) en el ámbito empresarial y, sobre todo, en los servicios. Todo lo demás sobraba. Se trataba de llegar al éxito mediante la especialización con presencia únicamente en los segmentos más rentables.

De su principal competidor (HP, tras la integración con Compaq que a su vez había comprado Digital) llegó a decirse, y así fue en la mayor parte de los casos, que tras la fusión con Compaq únicamente mantendría en su portfolio de productos aquellos en los que estuviera al menos en el tercer lugar en cuota de mercado. El resto eran rémoras que no hacían sino detraer recursos de los negocios más rentables. Y aunque la estrategia de HP e IBM no han sido exactamente paralelas (HP mantiene muy vivo su negocio de printing así como el de consumo) lo cierto es que ambos coincidían en la especialización.


Pero todo cambió...

De un tiempo a esta parte se está asistiendo a un nuevo periodo de concentración y des-especialización. Un periodo en el que todos quieren poder hacer de todo. Un periodo en el que todos quieren estar en todos los mercados y un periodo en el que parece que nadie quiere depender de nadie.

Hoy, Cisco e Hitachi son competencia de Dell, HP o IBM en el mercado de servidores, Intel es competencia de Symantec o Panda en el mercado de los antivirus, Oracle vende hardware, es competencia de SAP en el mercado de ERP y CRM e incluso de sí mismo con MySQL, EMC -a través de VMWare-
es competencia de Microsoft, Google con su Gizmo5 es competencia de Skype e incluso de Telefónica, Telefónica a su vez lo es de Facebook tras comprar Tuenti, Sony es competencia de Microsoft y pronto lo será de Google en el mercado del entretenimiento, Apple es competencia de Facebook en redes sociales y de Google en el mercado de la televisión online y la telefonía móvil, Accenture es competencia de IBM y HP en outsourcing y a su vez, IBM y Microsoft son competencia de Google o Amazón en los servicios de Cloud.

Algunas de estas concentraciones son entendibles -en términos de un economista son integraciones verticales, hacia adelante o hacia atrás dependiendo del caso-, como es el caso Telefónica con Tuenti, Google con Gizmo5 (Google Voice) o incluso Cisco con Skype -si finalmente la compra-. En ese caso se trata de estar en el mercado de los contenidos cuando ya se está en el mercado de las líneas de comunicaciones o viceversa.

Un operador tiene gran interés en generar más y más contenido dado que eso generará un mayor torrente de datos y con ello una mayor facturación. Y al revés, quien produce los contenidos que son consumidos por los usuarios tiene interés en estar en el negocio de las líneas de datos. Estas compras pueden ser entendidas desde la óptica de unificación de las comunicaciones IP. Tarde o temprano las llamadas de voz y vídeo, la radio, la televisión y en general cualquier medio de transmisión de datos acabará estando soportado por protocolos IP con lo que se producirá una convergencia de medios y con ello fricciones entre empresas que vienen de diferentes sectores y que se encuentran en un punto común: la Red.


Otras concentraciones no tan evidentes

Se están produciendo otras concentraciones cuya explicación no resulta tan evidente. De repente, los grandes fabricantes de sectores tan aparentemente dispares como el almacenamiento, el networking o la computación (servidores en general) están tomando posiciones a marchas forzadas para ser proveedores integrales. Estos movimientos se han hecho muy visibles en la reciente disputa entre HP y Dell por la compra de 3Par.

Es el caso de Cisco, Hitachi Data Systems, HP, Oracle o IBM. Cisco vende ya servidores además de su tradicional networking, HP se posiciona como un referente en el networking tras la compra de 3Com unido a sus tradicionales ProCurve, Oracle dispone de toda la línea de servidores y almacenamiento provenientes de la compra de Sun, HDS fabricará servidores integrados con su almacenamiento,... El siguiente paso natural parece ser que IBM compre una compañía de networking tras haber desmantelado la suya hace unos años (¿qué tal Juniper o Brocade?). ¡Todos quieren ser el corazón del Datacenter!

Estos movimientos no se explican con razonamientos puramente económicos. O no al menos con los mismos razonamientos que se usaban para justificar los movimientos anteriores en los que se podía hablar de diversificaciones verticales, sinergias en la función técnica,... y resto de jerga de los economistas. En este caso, la clave parece estar en la gestión de los futuros Datacenters y en el Cloud Computing porque parece -o eso es lo que estas compañías creen- que quien no esté ahí no sobrevivirá.

El Cloud Computing -o el outsourcing de siempre al estilo de Internet, porque realmente no es mucho más que eso- proyecta cambiar la forma en que las empresas conciben la infraestructura. Este hecho, junto a la virtualización y los blades, plantea a la mayor parte de los fabricantes la necesidad de ser globales. La razón es que con la tecnología actual no hay problemas técnicos para que el networking (switches, routers, firewalls, ids/ips, balanceadores,...), junto con el almacenamiento (san, nas, iscsi,...) y los servidores se encuentre todo junto en un mismo cajón, el cajón de blades, gestionados por un software único y resolviendo por diseño todas las complejidades de esa interconexión.

Tanto HP como IBM tenían ya un formato de cajón para incluir sus servidores, su almacenamiento y su electrónica de red, y lo mejor de todo, con un software de gestión que minimiza cuando no elimina las complicaciones derivadas de la interconexión de dispositivos. Es decir, los servidores, el almacenamiento y la red integrados out of the box por el propio fabricante. Esta situación es la quimera de quienes deben cuidar al máximo los costes -en sentido amplio- de la infraestructura para dar servicios gestionados desde la nube. Para ellos, la reducción de complejidad implica menores costes de gestión, menores costes en espacio (plantean incluso meter los CPDs en containers 100% autónomos en cualquier lugar el mundo), menores costes energéticos,...

Entonces, ¿cómo quedan los fabricantes que tenían una visión parcial de la infraestructura? ¿En qué situación se queda Cisco con sus dispositivos de red o Hitachi con su almacenamiento? El movimiento era inevitable y todos los jugadores de esos mercados parciales debían convertirse en globales.

Es por ello que Cisco ya vende servidores en su propio formato blade junto a su electrónica de red -y probablemente en el futuro junto a su almacenamiento-. Lo mismo pasa con Hitachi que comenzará a vender servidores integrados por diseño con su almacenamiento o con Dell que ha pujado hasta el final con HP por hacerse con una compañía de gestión del almacenamiento.


¿Qué dice la lógica que va a ocurrir a partir de ahora?

El punto de partida para responder a esto es que, a la vista de los hechos, en el corto o medio plazo habrá al menos cuatro o cinco proveedores que querrán competir por el mercado global ofreciendo soluciones completas e integradas. Entre ellos estarán Cisco, Oracle, IBM, HP, Dell y probablemente Hitachi.

Dicho así, suena incluso bien para los clientes. La competencia provoca aumentos en la eficiencia y es de esperar que esto genere tensiones que hagan contener el precio y aumentar las prestaciones. No es previsible que ninguno de los proveedores de este mercado global canibalice los productos pero no hay duda de que una mayor oferta es siempre buena para el cliente.

Pero ¿y en el largo plazo? La tendencia natural del mercado, de cualquier mercado, invita a pensar que tras un tiempo de expansión en el que todos harán y venderán de todo vendrá un tiempo de nueva concentración.
Los mercados maduros no permiten la existencia de más de dos proveedores, el líder y el retador, que hasta ahora eran IBM y HP, no necesariamente en ese orden. El resto serán proveedores residuales que serán fagocitados por los vencedores, enviados de nuevo a su mercado origen, reposicionados en un nicho o quién sabe qué.

Es decir, que compañías como IBM, HP o Dell corren el riesgo de pasar a no ser líderes en el segmento de las infraestructuras al tiempo que compañías como Cisco u Oracle corren el riesgo de comprometer su cuenta de resultados con el negocio de la infraestructura hasta el punto de que un mal resultado afecte a su negocio tradicional, en el que son líderes.

Algunos dirán que ser líder y referente en la electrónica de red o en el almacenamiento no es justificación suficiente para serlo también en el mercado de los servidores. Por contra, otros dirán que llegar a un nuevo mercado sin prejuicios ni rémoras del pasado permite innovar. El tiempo dará y quitará razones.