archivo

Archivos diarios: diciembre 4, 2011

Han pasado casi tres años desde que escribí una serie de artículos dedicados a la definición de un plan de sistemas de información:

Plan de sistemas de información I
Plan de sistemas de información II
Plan de sistemas de información III
Plan de sistemas de información IV
Plan de sistemas de información V
Plan de sistemas de información VI
Plan de sistemas de información VII
Plan de sistemas de información VIII
Plan de sistemas de información IX

Llevaba pensando un tiempo pensando en escribir un nuevo artículo sobre los planes de sistemas, haciendo hincapié en uno de sus principales problemas: su carácter eminentemente predictivo, basado en un fotografía de la organización en un momento dado, algo que no se ajusta a la realidad de las entidades.

En resumidas cuentas, presenta el mismo problema que las metodologías software basadas en métodos predictivos como el ciclo de vida en cascada, lo que hoy puede ser válido (si es que la especificación realizada es buena, algo que no es sencillo), mañana puede dejar de serlo porque las condiciones de partida han variado sensiblemente.

Finalmente, unas series de tweets que leí ayer a Jon Kern (uno de los padres del manifiesto ágil) sobre gobierno ágil, me animaron a escribir sobre este asunto.

Básicamente Kern expresaba la dificultad de establecer planes de gobierno a largo plazo ante una situación basada en la incertidumbre.

Un plan de sistemas no es más que un plan de gobierno de los sistemas de información de una organización, en la que se estudia una situación inicial, se determina un modelo objetivo al que se quiere llegar y un plan de acción que nos permita llegar desde esa situación inicial al modelo objetivo. Se suelen definir con un período de vigencia de tres o cuatro años.

Como ya recomendaba cuando escribí esos artículos, el tránsito desde la situación actual a una situación que se aproxime a lo que consideramos como ideal (dadas las características de nuestra organización y su contexto), probablemente si la organización no se encuentra lo suficientemente madura a nivel de procesos relacionados con el desarrollo de software y el gobierno TIC, requiera de la realización de varios planes de sistemas de información.

Este enfoque iterativo incremental tiene en esencia fundamentos ágiles, sin embargo, el tiempo que hay entre planes de sistemas, difumina casi todos los atisbos de agilidad que pudieran existir.

Mi recomendación sería en primer lugar, disminuir el período de vigencia de un plan de sistemas, situándolo a lo sumo en dos años y existiendo la posibilidad de que tenga una vigencia anual si existen riesgos ciertos de cambios de contexto o se han producidos cambios no previstos en la organización, procesos, de la organización hacia el exterior, etc… En cualquier caso, tanto si se decide que la vigencia sea de dos años, como de uno, hay que estar abiertos a reorganizar las prioridades si fuera preciso, para poder adaptarnos a cualquier variación de las condiciones iniciales o para ayudar a la organización a conseguir algún objetivo operativo o táctico de mayor trascendencia.

Por otro lado, también recomiendo, ¿por qué no?, plantear desde el principio hacia dónde queremos llegar, pero no con el presente plan de sistemas, sino a nivel estratégico definiendo cuál es la política de sistemas de información que sería deseable tener y realizando ajustes a ese alcance final en cada plan de sistemas, el cual, a su vez pretenderá recorrer parte de ese camino que nos separa de esa meta.

Si se aplica este principio de Sun Tzu en un proyecto de desarrollo de software precisamente lo que estás haciendo es sentar las bases precisamente para que haya una guerra entre los stakeholders, unos contra otros o todos entre sí.

Un proyecto no se puede basar en el engaño sino en la confianza.

El engaño puede funcionar para una parte hasta que es descubierto. En ese momento no le funciona ni a esa parte, ni a ninguna, ya que lo más probable es que el proyecto se estrelle salvo que se reaccione pronto, que salga del mismo quien o quienes han engañado y se intente, dentro del ambiente de recelo que se habrá creado, volver a construir la confianza (eso requerirá muchos más hechos que palabras).

Ahora bien, fuera de un proyecto, cuando lo que se trata es competir entre organizaciones dedicadas a este negocio que luchan por un determinado segmento del mercado y no tienen ningún tipo de alianza, estamos hablando de otra cosa, de la subsistencia de la propia empresa.

Eso nunca justificará, desde mi punto de vista, el engaño ante el usuario final de unos productos o de unos servicios, ya que de la misma forma que en un proyecto, eso supondrá más pronto que tarde la aniquilación de quien engaña (además de hacer un daño importante al negocio en general, ya que la credibilidad del mismo, se construye entre todos los que participan en él), si bien, el engaño o el despiste sí que lo puedo entender en un ambiente de competencia ya que no pretenderás ganar la partida si tu adversario conoce todas tus cartas y él tiene la oportunidad de cambiar o elegir las suyas.

Cuando te indiquen que en un proyecto se realiza gestión del riesgo ponlo en cuarentena hasta que no te indiquen exactamente cómo la llevan a cabo, ya que en muchos casos lo que se hace es identificar una serie de riesgos al principio del proyecto y nada más, en otros, además de lo anterior, incluso se evalúan y se establecen las medidas a aplicar para cada uno de ellos, pero se abandona ahí, continuando el proyecto como si nada de eso se hubiera hecho.

Una gestión del riesgo para ser eficaz, debe tener en cuenta en primer lugar el tipo de proyecto con el que estamos trabajando porque de lo contrario podríamos estar matando moscas a cañonazos o cañonazos con moscas y una vez contemplado este factor, es algo que requiere ser tratado durante todo el ciclo de vida del proyecto ya que si estos están en continua adaptación al cambio, la gestión de riesgos también debe hacerlo.

Pero incluso lo anterior no es suficiente, la gestión del riesgo no es solo análisis y adaptación continua del mismo, la gestión del riesgo es acción para prevenir o acción para tratar la materialización del mismo y la gestión del riesgo es tomar decisiones.

Una gestión de riesgos que tenga en cuenta todos estos factores no es frecuente.