Informática Corporativa
martes, 20 de enero de 2009

En muchas organizaciones, y muy notablemente en la Administración, se viene creando un departamento (o movimiento, o tendencia, o normativa...) de "Informática Corporativa". Procede de que la organización crece horizontalmente y la informática, que es transversal (ya que afecta y se desarrolla en todos los departamentos), se vuelve heterogénea en la organización. Esta heterogeneidad es vista como algo negativo, ya que en apariencia aumenta los costes:

• El personal es menos flexible, ya que un especialista en la tecnología de un departamento puede no serlo para otro.
• Los recursos hardware son menos versátiles, ya que las aplicaciones desarrolladas en un departamento no son desplegables en otro.

Para dar forma a esta informática corporativa se establecen unos procedimientos (casi siempre a medida, síndrome NIH) que dan lugar a una arquitectura común para los desarrollos.
Esto, visto desde el punto de vista funcional, desde la organización se pretende interpretar como algo fantástico: durante uno o dos (o más) años estudiamos las tecnologías disponibles, para seleccionar la más mejor, especializarnos en ella, y utilizarla para todo.
En la práctica, lo que sucede es que las organizaciones tardan dos años en seleccionar una tecnología que ya está obsoleta para cuando se implanta por primera vez, y se pelea contra ella durante años. Los errores cometidos durante el estudio (todos nos equivocamos) en vez de solventarse se parchean, para mantenerse de forma supuestamente ortodoxa en la normativa. El personal de toda la organización se especializa (en el mejor de los casos) en herramientas que carecen de interés en muy poco tiempo, y se estancan en ellas. Por tanto, todo intento de cambio se percibe como una amenaza, una intromisión en su trabajo. Además, como la arquitectura se convierte en normativa, se prohíbe la instalación en la red interna de todo aquello que se salga de ella.
La informática cambia con mucha frecuencia. Y, aunque no cambiase, no hay balas de plata. Intentar hacer norma de una tecnología es una locura: no hay nada que sirva para todo (ni en metodologías ni en herramientas) y lo menos malo para todo lo es hoy pero no mañana.

No me gusta señalar problemas sin proponer alternativas. ¿Solución? Normaliza el cambio:

• Establece una política de formación que permita que la gente no sólo se recicle periódicamente, sino que también evolucione constantemente.
• Haz una revisión tras cada proyecto para analizar los puntos positivos y negativos.
• Haz un estudio de viabilidad real, en el que de verdad se estudien alternativas de implementación.

El cambio es bueno. ¡Esto no significa que cada mes tengas que hacer las cosas de forma diferente! Si tienes gente formada, y haces un estudio de viabilidad real, el cambio surgirá de forma progresiva y natural: se irán incorporando cosas nuevas, se sustituirán componentes mejorables... Incluso los "cambios radicales" (piensa en un primer proyecto con Python en vez de J2EE) parecerán normales, ya que, en el fondo, los conceptos son los mismos.

PD: mañana tengo que trabajar en mostrar que un cambio es positivo, ¡deseadme suerte! ;)

Posted by Juan Ignacio Sánchez Lara 21:56    

1 Comment:

1. javi santana said...
   21 de enero de 2009 07:53  
   Personalmente me ha pasado muchas veces que pienso en hacer un cambio o introducir una mejora en un software. Normalmente empiezas con alegría, luego empiezas a pensar en lo que tendrías que hacer y finalmente terminas descartando o porque es mucho trabajo, porque puede desestabilizar, etc.
   
   Es muy común que se esté diciendo en una empresa "hay que hacer tal cambio en tal proyecto" pero que se vaya abandonando y nadie lo haga.
   
   Al final, lo que siempre me ha resultado más útil ha sido quitar los miedos y meterme a por ello. En el peor de los casos "pierdes" un día (uno no tarda más en darse cuenta de que está metiendose demasiado) y aprendes algo. Yo incluso diría que es bueno el darte una leche pecando de machote :)

Post a Comment