Lean … o simplemente pragmatismo y sentido común

1 09 2009

Que el sector TIC es de los más inflacionistas de nuestro entorno es algo prácticamente fuera de toda duda. En los últimos tiempos, sin embargo, dicha inflación está tomando aires de exponencialidad, quizás no en lo estrictamente tecnológico pero sí en lo que respecta a las siglas y los “conceptos”.

Sólo hay que mirar un poco hacia atrás para ver como el marketing alrededor del sector propugnó lo novedoso de los servicios Web (WS) hace unos años. Al poco tiempo casi quedaron eclipsados por las arquitecturas orientadas a servicios (SOA), más recientemente por el software como servicio (SaaS), la computación en la nube (cloud computing), etc. Ninguno de estos conceptos es exactamente lo mismo que los otros, ni se substituyen en entre sí tecnológicamente hablando, se trata más bien de evoluciones naturales, … Sin embargo la maquinaria del mercado acaba generando momentum, o hype como gusta a la prensa americana, alrededor de cada nueva sigla (tenga un nuevo concepto asociado detrás o no).

Por otra parte, esta dinámica inflacionista, provoca cierta apetencia por adoptar términos provenientes de otros sectores. Dichos términos tienen un contenido real y original en su sector de origen, pero no siempre lo acaban teniendo al traerlos al contexto TIC, por lo menos no como para crear productos, servicios, cursos, etc. O al menos así lo vemos.

Uno de los términos que ha aparecido en el espectro recientemente es el término Lean, aplicado en diversas formas como Lean IT, Lean IT Service Management, etc. El término proviene del Lean Manufacturing o Lean Production, como filosofía genérica de gestión de procesos, términos acuñados anos después de que Toyota idease una forma de producción eficaz y eficiente, eliminado lo superfluo de sus procesos.

Por supuesto, todo ello puede aplicarse a la implementación de servicios TI, a su gestión, al desarrollo de software, a la gestión de proyectos, etc. sobre todo debido a dos factores:

  1. De un tiempo a esta parte es cada vez más frecuente pensar en TI en base a procesos, sobre todo desde la irrupción en masa de frameworks de buenas prácticas, normas y estándares de gestión, e.g. CMMI, ITIL, COBIT, ISO 20000, ISO 27000, etc.
  2. Estamos en plena crisis económica.

Dicho simplemente: hay mucho escepticismo sobre la aplicabilidad práctica y el éxito de todos esos frameworks que resultan muy complejos a los no iniciados (los clientes), y debido a la crisis económica todo lo que suene a reducir, simplificar, … ahorrar, es más que bienvenido (por los clientes).

Así pues, lo Lean se ha convertido en un poderoso argumento de marketing (otra vez) para que algunos vendan “nuevos” productos de gestión y “nuevos” servicios de consultoría, re-etiquetados pero que, muy probablemente, no son sustancialmente diferentes a lo que ya se venía ofreciendo.

¿O es que alguien prestaba servicios de adaptación de procesos a ITIL, por ejemplo, y lo hacía siguiendo al pie de la letra lo que ponía el manual correspondiente, sin entrar a comprender el negocio del cliente, su cultura organizativa, etc., y consecuentemente eliminado del modelo todo aquello que no aplicaba, no encajaba, etc.?

¿No será simplemente que el pragmatismo y el sentido común ahora tienen una etiqueta? ¿Una etiqueta más vendible?

Son suficientes preguntas para la reflexión, pero para ayudar en ella, ahí van un par de citas:

Todo lo que hemos aprendido en la era industrial se ha orientado a crear más y más complicaciones. Pienso que ahora cada vez más gente está entendiendo que lo mejor es simplificar, no complicar. La simplicidad es la máxima sofisticación.
John Sculley, Ex CEO de Apple y ex Vicepresidente de Pepsi.

Y del libro “The power of simplicity“:
… la vida profesional es mucho más sencilla de lo que muchos creen. Lo que pasa es que hay demasiada gente dedicada a complicarla…
Y más adelante da una receta simple y compleja a la vez para sobreponerse a la situación. A saber:
… simplificar lo complejo y, sobretodo, no complicar lo simple“.
Jack Trout, Presidente de Trout & Partners.

Lo dicho, no hace falta tanto marketing, tanta fachada, para proporcionar valores que deberían ser consustanciales a la propia consultoría: el pragmatismo y el sentido común, para aplicar lo esencial, lo que aplica, lo que tiene valor y nada más.





Norma BS 25777 sobre Gestión de la Continuidad TI

9 02 2009

En junio del año pasado tuvimos la oportunidad de asistir a la presentación de la traducción al castellano de la norma BS 25999 sobre Gestión de la Continuidad de Negocio (GCN). Desde entonces se han sucedido los eventos y los artículos sobre el tema, lo que ha contribuido a la difusión de esta norma así como a su progresiva implantación y al incremento de las organizaciones certificadas en ella en nuestro entorno.

Sin embargo, aún hoy existe cierta confusión al respecto de lo que significa “Gestión de la Continuidad de Negocio”. Y es que hemos podido constatar cómo a menudo ésta se relaciona directa, incluso exclusivamente, con los planes de continuidad TI. Es evidente que las TI son fundamentales para la continuidad del negocio de muchas organizaciones, sin embargo no lo son en todos los casos, ni la garantía de su continuidad, por sí misma, garantiza siempre la del negocio. La continuidad de éste tiene mucho más que ver con la gestión de la información, el conocimiento, las relaciones, etc.

Pero volvamos a lo esencial, y es que la interrupción de las TI en una organización puede representar un gran riesgo para ésta, pudiendo afectar gravemente a las operaciones, socavar su reputación pública, etc. Así pues, y dadas sus peculiaridades, es preciso disponer de procesos de Gestión de la Continuidad TI (GCTI) que den soporte específico a la GCN, asegurándose de que las infraestructuras y los servicios TI son robustos ante las amenazas y, cuando menos, en caso de interrupción pueden recuperarse en un marco temporal de acuerdo a las necesidades del negocio. Justamente éste es el propósito de la, recién publicada, norma BS 25777:2008. Esto es, proporcionar recomendaciones al respecto de la gestión de la continuidad TI, allí donde la norma BS 25999-1 no proporcionaba el detalle suficiente, dado su enfoque primordial en el negocio.

bsi_business_information

El origen de esta nueva norma se sitúa en 2006 cuando el British Standards Institution (BSI) publicó, en colaboración con diversas empresas del sector TI, un documento denominado PAS 77, como código de buenas prácticas para crear un plan de continuidad de servicios de TI. Originalmente se pensó en desarrollar el estándar BS 25777 a partir de PAS 77 en dos partes entre 2008 y 2009. Por una parte, BS 25777-1, como código de buenas prácticas sobre cómo abordar la gestión de la continuidad de servicios TI en una organización. Por otra parte, BS 25777-2, que especificaría los requisitos para establecer, implementar, operar, supervisar, revisar, probar, mantener y mejorar un sistema de gestión de continuidad de servicios TI, además de permitir auditar y certificar los sistemas de gestión de las organizaciones. La norma publicada el 31 de diciembre de 2008 corresponde a la primera parte, pero, a la vista de la numeración con la que se ha publicado y lo que se comenta en el sector, es posible que la segunda parte no llegue nunca, dando por bueno lo que al respecto ya especifica la norma BS 25999-2.

Así pues, habrá que ver cómo evoluciona esta nueva norma, qué grado de acogida tiene por sí misma, o si sólo la veremos en el contexto de la implementación de su hermana mayor la BS 25999. Por otra parte, será interesante ver hasta qué punto encaja con las buenas práctica recogidas en el proceso de Gestión de la Continuidad del Servicio TI de ITIL o con los objetivos de control de la ISO 27001 al respecto de la Gestión de la Continuidad de Negocio, por ejemplo.





El catálogo de servicios, o cómo mejorar el posicionamiento de SI/TI

28 01 2009

Desde hace un tiempo asistimos a un debate recurrente al respecto de qué papel deben jugar los SI/TI en una organización, de cuál ha de ser el rol del CIO, del alineamiento de los SI/TI con el negocio, etc. Lejos de converger en un punto de vista único y cerrar el debate con conclusiones consensuadas, el tema sigue en boga ya que, cuando menos, éste puede abordarse desde dos perspectivas bien diferentes que no siempre están en sintonía: la de la propia organización (dirección, usuarios, …) y la del área de SI/TI.

En este post vamos a revisar la segunda perspectiva. Así pues, una posible manera que el CIO tiene para abordar el citado alineamiento es reflexionar al respecto de cómo la organización percibe al área de SI/TI. Algunas visiones típicas incluyen las siguientes:

  • SI/TI es un agujero negro en el que se va una buena parte del gasto de la empresa.
  • SI/TI es un área muy estructurada, incluso burocratizada, con la que es complicado entenderse y obtener lo que se les requiere.
  • SI/TI es el área encargada de los ordenadores, las aplicaciones y que ejecuta proyectos. 
  • SI/TI proporciona asistencia a los usuarios. 
  • SI/TI es el área encargada de proporcionar servicios de tecnología e información para el soporte de los procesos de negocio del resto de las áreas de la organización.

Sin duda, esta última perspectiva es la más atractiva y beneficiosa para la organización, pero también lo es para el CIO y el área de SI/TI en general. Es más, el alineamiento con esta perspectiva dotará al área de SI/TI de más peso en la organización, de mayor presupuesto, etc. Por el contrario, las otras perspectivas son parciales y revelan una falta de enfoque común, lo que dificultará que el CIO pueda establecer un diálogo en el nivel apropiado con la dirección de la organización y, por ende, con los usuarios (sus clientes).

Así pues, si SI/TI adquiere la consideración de “conjunto de servicios al negocio”, el gasto en SI/TI tendrá una correspondencia con las funciones de negocio en las que la organización prefiera invertir, tornándose a su vez en una inversión. Cuando el área de SI/TI se alinea en torno a estos servicios, las aplicaciones redundantes, la superposición de proyectos, etc. se hacen más evidentes y las desviaciones pueden corregirse antes. Con ello se supera el clásico enfrentamiento SI/TI-negocio transformándose en una discusión de mayor nivel de madurez alrededor de los niveles de servicio, la optimización de costes, etc. 

Un elemento que puede facilitar este alineamiento es la construcción de un catálogo de servicios como fuente de información única y precisa para los usuarios sobre los servicios proporcionados, incluyendo los niveles de servicio que pueden esperarse. Cada servicio al negocio irá acompañado por la infraestructura y los servicios de SI/TI necesarios para su funcionamiento, así como los costes asociados, las capacidades requeridas, etc. Adicionalmente, esto debería complementarse (entre otras) con la figura del gestor del servicio, sobre el que recaerá la responsabilidad de garantizar que los SI/TI permitan satisfacer las expectativas de los usuarios para cada servicio de negocio concreto. 

Obviamente, este tipo de planteamientos suena bien, pero de todos es sabido lo complicado que puede ser llevarlos a la práctica, especialmente porque en muchas organizaciones, el área de SI/TI está demasiado centrada en la tecnología y no lo suficientemente en el negocio que debe sustentar. La aparición de ITIL puede ayudar en este sentido, pero a menudo su adopción se centra en la estabilización de los procesos de soporte al servicio, algo que siempre da quebraderos de cabeza al CIO por la presión que supone sobre el personal. En cambio, se suele reparar menos atención en la construcción del catálogo para dichos servicios, o en si los servicios son realmente los que el negocio precisa, o si están demasiado dirigidos por el aspecto tecnológico de los mismos, etc.

A este respecto en ITIL v2 el concepto de catálogo de servicios ya está presente como parte de las responsabilidades del proceso de gestión de niveles de servicio. Pero es en ITIL v3 donde se proporciona una perspectiva más amplia en este ámbito, incorporando además el concepto de cartera de servicios como núcleo central de la fase de estrategia del servicio, acompañado de los procesos de gestión de demanda de servicios y la gestión financiera. En este nuevo paradigma, el ciclo de vida de los servicios se inicia bajo el amparo de la perspectiva del negocio, es decir, de las demandas de servicios de SI/TI que éste tiene. Y el servicio se concibe teniendo en cuenta los recursos necesarios para ponerlo en práctica, los costes, el ROI, etc.

A la vista de lo anterior, queda claro que los servicios son para el negocio y que cualquier intento de presentarlos desde un punto de vista técnico no será bien recibido por la organización. Por el contrario, si el trabajo en la fase de estrategia (y posterior diseño) del servicio se hace correctamente, implicando a los diversos actores interesados de la organización y no sólo al área de SI/TI, los servicios que acaben formando parte del catálogo estarán mucho más alineados con el negocio en todos los sentidos.

Así pues, el CIO, como responsable del área de SI/TI, tiene en la elaboración de la cartera y el catálogo de servicios un arma muy valiosa para acercar el área de SI/TI tanto como sea posible al negocio, mejorar así su posicionamiento en la organización y, en última instancia, perseguir el tan manido alineamiento estratégico.





SOX, J-SOX, EuroSOX, … ¿qué más hace falta?

23 12 2008

A mediados del año 2002 se aprobaba en Estados Unidos la Ley Sarbanes Oxley, también conocida como SOX. Nacía de la voluntad de controlar a las empresas que cotizan en la bolsa de Nueva York y sus filiales, para evitar que los procesos con transacciones económicas pudieran ser alterados de forma fraudulenta, como había ocurrido en el famoso caso Enron.

Hace varios años que la SOX traspasó fronteras y hoy existen ya versiones de la misma normativa fuera de EEUU: existe la J-SOX (desde mediados del 2006) con el mismo propósito para Japón y la EuroSOX para la comunidad europea. Esta última cubre las directivas europeas de Auditoría Estatuaria y Representación de Informes de la Compañía.

La dirección de TI ocupa un importante papel a la hora de ayudar en el cumplimento de la SOX. Mediante el uso de mecanismos de control y gestión tales como los que proporcionan Committee of Sponsoring Organizations of the Treadway Commission (COSO),  Control Objectives for Information and related Technology (CoBIT) e Information Technology Infrastructure Library (ITIL) es posible implementar controles, identificar flujos, responsabilidades, …, que ayuden a monitorizar y mejorar dichos procesos de trabajo.

Dada la coyuntura actual, con una crisis financiera mundial y los numerosos casos de fraude como el de Bernard Madoff, que están apareciendo recientemente, es hora de reflexionar sobre qué está fallando. Lo que sí parece claro, es que disponer de estándares de control no és lo único necesario para garantizar el buen hacer de las empresas y el cumplimiento de las Leyes.





Dificultades en los planes de mejora de la gestión de servicios TI

7 11 2008

El ámbito de la gestión de servicios TI goza de un nivel de madurez creciente a nuestro alrededor. Sólo hay que ver la cantidad de artículos, actos, ofertas de trabajo, etc. que hacen alguna alusión a distintos marcos de referencia basados en buenas prácticas como ITIL o estándares como ISO/IEC 20000.

Esta popularidad, a veces impulsada desde la Administración, a veces desde las consultoras, a veces desde la prensa especializada, … está llevando a muchas organizaciones a plantearse la reorganización de su función de TI y a emprender un proceso de mejora de la gestión de los servicios TI que ofrecen internamente y/o a sus clientes. Si bien esto es muy loable, no hay que caer en la trampa de los “cantos de sirena” de las siglas, las certificaciones, las herramientas y muchos otros elementos que envuelven este ámbito de la consultoría.

ITIL, como conjunto de buenas prácticas, no es una metodología guiada que permita a una organización seguir un plan paso a paso que le lleve a la excelencia en la operación de sus procesos internos de TI. Tampoco se trata de un conjunto de herramientas que por sí mismas solventen los problemas de una gestión de TI deficiente. Por el contrario, ITIL recoge las “mejores prácticas” que han funcionado en diversos contextos a nivel internacional, pone orden en ellas, las sintetiza extrayendo los principios fundamentales y las facilita en forma de marco de referencia. A partir de aquí, en qué medida y de qué manera cada organización abrace ITIL, es una cuestión que depende de muchas variables.

Los beneficios de ITILizarse, si se admite el término, son numerosos y ampliamente aceptados. Sin embargo, también hay “peligros” que pueden desembocar en efectos contraproducentes para la organización si no se entiende bien que en el proceso debe prestarse especial importancia a aspectos como el compromiso de la Dirección, la concienciación global de la organización, el cambio cultural, etc.

Estos aspectos están bien recogidos en la literatura ITIL y vale la pena tenerlos en cuenta para no llevarse una sorpresa posteriormente. Sirva como muestra lo que se dice en el libro “Fundamentos de la Gestión de Servicios de TI. Basada en ITIL V3″ de itSMF

  • La introducción de ITIL en la organización puede llevar más tiempo y exigir un esfuerzo considerable, así como un cambio de cultura en la organización; un exceso de ambición puede dar lugar a frustración al ver que nunca se alcanzan los objetivos.
  • La calidad del servicio se puede resentir si las estructuras de procesos se convierten en un objetivo en sí mismas; en este caso, los procedimientos innecesarios o excesivamente complejos se consideran obstáculos burocráticos que hay que evitar en la medida de lo posible.
  • Los servicios de TI no mejorarán si no se tiene una idea clara de qué tienen que hacer los procesos, cuáles son los mejores indicadores de rendimiento y cómo se pueden controlar los procesos.
  • Las mejoras en la provisión de servicios y las reducciones de costes no serán apreciables si no existen datos de referencia y/o no se establecen los objetivos correctos.
  • El éxito de la implementación requiere la participación y el compromiso del personal a todos los niveles de la organización; encargar el desarrollo de las estructuras de procesos a un departamento especializado puede hacer que dicho departamento se sienta aislado y avance en una dirección distinta de la que desean otros departamentos.
  • Si la inversión realizada en formación y herramientas de soporte es insuficiente, no se sacará partido a los procesos y el servicio no mejorará; es posible que a corto plazo se necesiten más recursos y personal si la organización tiene un exceso de actividades rutinarias de Gestión de Servicios TI en las que no siga “Mejores Prácticas”.

Se nos ocurren algunos otros argumentos, pero los ya expresados son más que suficientes como para dejar clara la necesidad de ser muy prudente a la hora de abordar proyectos de este calado y, sobre todo, marcarse objetivos realistas. Ni que decir tiene que si el objetivo es además conseguir la certificación ISO/IEC 20000, los argumentos del primer punto de la lista anterior toman una especial relevancia si cabe.