Innovación y gestión del cambio

Desde hace ya algún tiempo pero con el advenimiento de la actual crisis, todavía más, se habla de que la economía del futuro se basa en el conocimiento y en la innovación. Pero, ¿qué pasa cuando un departamento de una empresa se pone a innovar?. Pues en primer lugar, probablemente se produzca un cambio de "lenguaje" en ese departamento que lo va a distanciar del resto de la empresa lo que provoca un rechazo que finalmente acaba por echar a la parte más débil (el innovador).

¿Qué se puede hacer para que esto no ocurra?. Pues se puede intentar "gestionar el cambio". Para ello hay que tener presente algunas cosas:
Cuando alguien se enfrenta a un cambio, lo primero que se sufre es miedo. Miedo a la magnitud del cambio, luego desconfianza, se empieza a pensar que para qué se va a cambiar si todo va perfectamente, pueden entrar en juego incluso emociones y que alguien se lo tome como algo personal y finalmente, puede que el cambio no sea posible por falta de capacidad para realizar el mismo (conocimiento, medios materiales, ...).

Pues bien, si se evalúa el cambio en dos ejes, se puede hablar de un eje "hard" en el que se representaría la eficiencia operativa del cambio y un eje "soft" en el que estarían los aspectos culturales de la empresa. Una primera aproximación es envolver el plan "hard" dentro del "soft". Es decir, empezar por identificar las barreras contra el cambio, da los primeros pasos, observa quién está dispuesto a seguirlos y otórgale poder o alguna clase de beneficios, da publicidad a estos logros (tanto a nivel operativo como de beneficios para los seguidores del cambio) y vuelve a repetir el proceso.

Por supuesto, este proceso tiene que estar liderado por alguien que realmente tenga potestad (y preferiblemente autoridad también) para llevarlo a cabo. Y una cosa muy importante en todos los cambios organizativos, dar sensación de "URGENCIA".

Hermeneutica

La Hermeneutica es el arte de la interpretación de textos para determinar la idea exacta que se quiere expresar.
Desconozco si Booch, Rumbaugh y Jacobson creadores del UML eran conocedores de la existencia de la Hermeneutica pero desde luego no les habría venido mal.

Probablemente les hubiese venido bien para evitar que el lenguaje UML carezca de una semántica precisa, lo que dificulta una interpretación objetiva de un modelo UML, que factores como serialización y persistencia, muy importantes en sistemas distribuidos no estén descritos en este lenguaje.

En fin, quizá es el momento de volver a Alejandría y plantearnos cuál es la mejor manera de transmitir ideas entre humanos.

Norma ISO 20000

Las empresas dependen cada vez más de sus sistemas de información y afortunadamente se exige cada vez más una gestión profesional de los recursos de TI. Por lo tanto, los departamentos de tecnología han desarrollado sus propias "armas defensivas" por las cuales aseguran a la organización que están haciendo lo correcto y no están malgastando la inversión que se ha hecho en infraestructura de TI.
Una de estas armas es la ISO 20000 pero, un momento, ¿no estaba siendo una tal ITIL la defensora de la virtud de los departamentos de TI?.

Bueno, en el fondo son primos hermanos. Las principales diferencias serían:

La ISO 20000 es una norma internacional respaldada por un organismos oficial (la ISO y en España AENOR) mientras que ITIL son “buenas prácticas” aunque sea el "estándar de facto".
La ISO 20000 tiene referencias al control de proveedores lo que en el actual panorama es muy importante ya que casi ninguna empresa gestiona su TI con personal 100% propio.
Los informes al comité tienen entidad propia y se considera un proceso independiente.
En ITIL no es obligatorio el plan de continuidad de negocio y la ISO 20000 incluye además la norma ISO 27001 de seguridad de la información.

Hay alguna otra diferencia pero que no dejan de ser matices sobre lo mismo.

Software Craftmanship

Es ya un viejo tema la posibilidad de "industrializar" la creación de software. Lo cierto es que los proyectos no suelen acabar a tiempo y normalmente no se ven usuarios pegando saltos de alegría con el producto final.

También es cierto que se han hecho muchos intentos para mejorar la creación de software usando diferentes metodologías que han obtenido resultados desiguales.

A la vista de esto, se me ocurre que a pesar de la metodología aplicada, la última línea de defensa es el programador que teclea por lo que su talento es fundamental. Es como si en una empresa de construcción de coches que usa el "just in time" el encargado de colocar las ruedas al coche no sabe donde colocarlas y le echamos la culpa al proceso. Con esto no quiero decir que la metodología no importe, que importa, si no que está claro que al final del proceso siempre está el programador.

Por otro lado, la mayoría de lenguajes empleados en la programación están hechos para que lo entiendan las personas y por supuesto las líneas de código plasman conceptos. Esto quizá diferencie la construcción de software y la de coches.

Black Swan

En el año 2007 Nassim Nicholas Taleb publicó un libro llamado "The Black Swan" (en español el cisne negro). En ese libro, expone su teoría (The black swan theory) según la cual la mayor parte de los grandes avances científicos y en general los hechos impactantes y difíciles de predecir son eventos que no deberían ocurrir (de ahí el nombre de la teoría, cisne negro, ya que se supone que los cisnes son blancos).

En el fondo, lo que Taleb nos cuenta es que aunque nos guste pensar que podemos explicar las cosas que pasan, las verdaderamente impactantes son efecto de la casualidad y no de acciones dirigidas a obtener el efecto que finalmente ha ocurrido. Taleb pone de ejemplo el auge de Internet, el ordenador personal, la Primera Guerra Mundial y el 11 de Septiembre.

No es que consuele mucho pero cuando tu sistema redundado, con recovery automático falla estrepitosamente siempre puedes decir que "también existen cisnes negros" y sino que se lo digan a Wallstreet.

La organización del departamento de IT

El departamento de IT de una empresa suele ser un lugar bastante complejo. El hecho diferencial con respecto a otras áreas de la empresa es que no sólo se da servicio a clientes externos (los otros departamentos de la empresa) sino que existen relaciones clientelares dentro del propio departamente de IT. Así por ejemplo, desarrollo es cliente de sistemas, sistemas es cliente de comunicaciones, etc...

Existe un tipo de organización del departamento de IT que es la organización por tareas en la que existen grupos especializados en una determinada función. Estos grupos siguen el modelo de caja negra, es decir, reciben inputs por un lado (peticiones) y generan outputs (las tareas realizadas).
Esto tiene muchas ventajas pero principalmente se consigue un ahorro de costes ya que con pocos recursos (pocos miembros en estos grupos especializados) se consigue atender a muchos clientes. El problema (y gordo) es que al ser una caja negra, los grupos especialista necesitan un gran detalle en la petición ya que desconocen la finalidad y el contexto en el que ésta se ha hecho.
Otro gran inconveniente es la dilución de responsabilidad. ¿De quién es la culpa de que no hayamos cumplido el plazo?, ¿la petición estaba bien hecha?, ¿le faltaba una coma y no he entendido que querían?...

Existe otra manera de organizar el departamente de IT que es la organización por proyectos. En este modelo, no existen grupos de especialistas sino que se asignan especialistas a cada proyecto. Aquí las responsabilidades están claras y todo el mundo tiene el mismo objetivo (que tu proyecto, en el que estás asignado, salga bien) pero tiene otro gran incoveniente. Se necesita más gente ergo es más caro.

El coste de inventario

Existe un concepto comúnmente manejado en la industria que es el coste de inventario.
Los inventarios son un conjunto de bienes o productos almacenados. Este almacenamiento funciona como un buffer que amortigua ineficiencias o errores en la cadena de suministro.
Por supuesto, las empresas conocen perfectamente que tener inventarios suponen costes. Por ejemplo tendríamos costes por la compra de los productos que forman el inventario, costes de obsolescencia, costes de manipulación, costes de ocupación y finalmente gastos varios.

Como se puede observar, el coste total es la suma de varios componentes. No siempre todos los conceptos se pueden aplicar en todas las situaciones pero el coste de inventario quizá sea aplicable a más casos de los que normalmente se consideran.
Así, se me ocurren dos preguntas:
¿Para qué quiere una empresa logística, manufacturera, industrial, etc..., un CPD?
¿Será por esto de los costes de inventario que está de moda el tema del Cloud Computing?

LAISSER FAIRE, LAISSER PASSER

El "laisser faire, laisser passer" (dejar hacer, dejar pasar) es un término económico que está detras de la filosofía del liberalismo económico. 

Básicamente, lo que el término "lasser faire" indica, es que el máximo beneficio se obtendrá cuando todos los actores de un determinado sistema actúen libremente según sus intereses sin que nadie externo regule esta actuación. 

Estamos viendo últimamente que esta filosfía tiene sus problemas ya que en muchos casos se intenta tener un beneficio a corto plazo aunque a largo plazo esto sea el fin.

Bueno, pues algo parecido pasa en los departamentos de sistemas. Se recibe una petición de un equipo de desarrollo para hacer un pase a producción, ¿que le interesa al departamento de sistemas?, Laisser faire, laisser passer.