El Departamento de TI: Eficiencia y Eficacia

No es objeto de esta entrada discutir sobre lo que estas palabras significan y su interpretación en diferentes ámbitos. Partiré, de cara a la posterior “discusión” de la siguiente definición:

“La eficiencia es hacer las cosas bien, la eficacia es hacer las cosas correctas” – Peter Drucker considerado el padre del management como disciplina y el mayor filósofo de la administración en el siglo XX (Wikipedia).

Aceptando esta definición, la primera conclusión a la que llegamos es obvia: la eficacia precede a la eficiencia. No tiene sentido hacer las cosas bien si lo que estamos haciendo no es lo correcto, es decir, no nos lleva a nuestros objetivos. Podemos incluso decir que ser eficaz equivaldría a responder al ¿Qué he de hacer? mientras que ser eficiente equivaldría a responder al ¿Cómo he de hacerlo de manera que maximice el valor de lo que hago, o lo que es lo mismo, obtenga el  máximo provecho con los mínimos recursos?

Simplificando, podríamos incluso llegar a decir, desde el punto de vista del departamento de TI, que cumplir con los requerimientos del negocio nos hace ser eficaces. Por otro lado, proporcionar al negocio nuevas formas de trabajar o trabajar mejor en base al uso de nuevas tecnologías y sistemas de información o en base al uso diferente de las ya existentes, les hace a ellos (el negocio) ser más eficientes.

Si intentamos responder a la pregunta de la eficacia dentro del ámbito de un departamento de TI (¿Qué hemos de hacer?), las respuestas podrían ser las siguientes:

En el ámbito de la seguridad de la información, el qué, se obtiene de los riesgos del negocio y de las obligaciones legales, regulatorias y contractuales a las que éste debe hacer frente. Si las medidas técnicas, organizativas y procedimentales que implementemos en nuestra organización no provienen de dar cumplimiento a estos dos requerimientos, simplemente no seremos eficaces.

En el ámbito más general de los servicios de TI que dan soporte a los procesos de negocio, el qué, se obtiene de la utilidad y garantía esperada por el negocio y del equilibrio existente entre ambas. La utilidad viene de cumplir con las necesidades específicas del negocio y la garantía de asegurar que dicho servicio estará disponible cuando el negocio lo necesite. No conocer o presuponer estas necesidades y niveles de servicio requeridos o presuponer cómo darles cumplimiento, de nuevo, nos puede hacer ser ineficaces.

De la Continuidad Tecnológica a la Continuidad de Negocio

Es indudable que en los últimos años ha crecido la preocupación en las organizaciones por garantizar la continuidad de las operaciones críticas del negocio.   Esta tendencia  puede ser debida a diversos factores, como las numerosas normas o estándares que abordan esta problemática (ISO 27000, la BS 25999 o la ISO 22301…),  los marcos metodológicos que aúnan buenas prácticas en la materia (COBIT, ITIL®…), organizaciones sin ánimo de lucro que tratan y fomentan la temática (ISACA, Business Continuity Institute…) o los numerosos antecedentes de eventos no deseados  que han provocado impactos muy importantes  en organizaciones muy conocidas. Todos recordareis el incidente del WindSord, el ataque sufrido por la plataforma PlayStationNetwork de Sony, el atentado a las Torres Gemelas, la reciente caída del servicio WhatsApp…

El problema que se encuentran muchas organizaciones que quieren proteger sus operaciones críticas es, dentro de la complejidad que tiene cada negocio, cómo comenzar a aplicar buenas prácticas en materia de continuidad de negocio.  Lo recomendable en una situación de este tipo es comerse el elefante en pequeños trozos que permitan ir expandiendo el foco. Y justo en este momento nos acordamos de las tecnologías de la información y comunicaciones (en adelante TIC).  Hay que tener en cuenta que gran parte de la operativa de las compañías está soportada por TICs y que  la tendencia tecnológica al alza en la que vive el mundo actual ha hecho que haya aumentado la dependencia que el negocio tiene de ellas.

Nuestra experiencia nos dice que el departamento de TI es un excelente punto de partida para, partiendo de un plan de contingencia de TI (identificar procesos críticos, sistemas TI clave, tiempos de recuperación mínimos, puntos de recuperación objetivos, existencia de procesos manuales alternativos, definición de estrategias de recuperación, establecimiento de Roles y Responsabilidades y del Plan de Recuperación frente a Desastres…) extender el concepto de continuidad hacia los niveles superiores de la organización, dando un paso clave de madurez en una compañía… “de la continuidad tecnológica a la continuidad de negocio”.

Para dar este paso es muy importante que el CIO asuma tanto el liderazgo como  el reto de transmitir a la Alta Dirección que “su” hoja de ruta simplifica las cosas, porque ya hay una estructura de roles y responsabilidades (Cultura de Comités, Equipos de Recuperación, Responsable de Continuidad…), ya se habla de riesgos, de cómo mitigarlos, de procesos críticos, de estrategias de recuperación, de planes de recuperación asociados…. y que si la organización aprovecha esa inercia obtenida a partir del plan de contingencia será más fácil impulsar y elevar el concepto de “continuidad”. En ese momento el CIO trasladará la “pelota” al techo de la Alta Dirección, que comenzará a pensar en términos de continuidad, identificando necesidades y fomentando la toma de decisiones.  Si se consigue captar el interés de la Alta Dirección  se percibirá la necesidad. A veces esto se consigue de manera curiosa, recuerdo una reunión en la que los miembros del Comité de Dirección no entendían la diferencia entre una incidencia normal y otra que diera lugar a la activación del plan de continuidad. El conocimiento que el CIO había obtenido le permitió  explicarles que necesitaban el Análisis de Impacto en el Negocio (BIA) porque introducía un elemento fundamental, la variable temporal. Esta variable era lo que convertía una incidencia de un tipo en una de otro.
  

Esta hoja de ruta es la que aconsejamos seguir en clientes de muy diversos sectores y con problemáticas de muy diversos tipos. En próximas entradas explicaré cómo mantener el sistema de Gestión de Continuidad de Negocio a través de la implantación de una Oficina de Continuidad. 

Ideas para hacer un Plan Estratégico de TI

Repasando artículos interesantes en mi bandeja de entrada de Evernote, me he reencontrado con un artículo de Jerry Bishop en su blog blog.thehigheredcio.com. El artículo se titula 5 – S’s to IT Strategic Planning. Las 5 S se refieren a Strategic, Simplification, Service, Sustainability y Savings. La idea del artículo es articular un Plan Estratégico de TI entorno a estos 5 conceptos.

Resumiendo, os aconsejo que leáis el artículo, podemos decir que el Plan Estratégico debe articularse de la siguiente manera:

• Pensar en dos o tres iniciativas para ayudar a vuestra organización a alcanzar sus objetivos estratégicos. Estos pueden ser, entre otros, el crecimiento del negocio y la mejora de los márgenes o, como decía un financiero con el que trabajé, “simplemente” vender, facturar y cobrar.

• Pensar en cómo eliminar la complejidad y, en consecuencia, sus costes y falta de calidad asociados. En tanto que ofrecemos servicios de TI dicha complejidad puede estar presente en la tecnología, los procesos, las personas o incluso la relación con nuestros proveedores. En este punto, por tanto, podemos tener la tentación de disminuir drásticamente la complejidad asociada a la operación y gestión de nuestras TI, pero ojo con hacerlo a costa de perder totalmente el control de las mismas o de casarnos con alguien para luego acordarnos de lo bien que vivíamos solos.

• Pensar en dos o tres servicios a mejorar que, por supuesto, estén directamente relacionados con las iniciativas encaminadas a ayudar a los objetivos estratégicos de la empresa y en los que sea posible y adecuado aplicar medidas de simplificación (eliminación de la complejidad).

• Pensar en términos de sostenibilidad, es decir, en proyectos de continuidad y en proyectos asociados al Green IT.

• Por último, en base a las acciones planificadas de simplificación y sostenibilidad,  estimar como pueden disminuir los costes asociados a mantener y operar las TI con el objetivo de asignar estos recursos económicos a los proyectos estratégicos. En este punto, el autor nos aconseja seguir el modelo run, grow and transform de Gartner. Por supuesto esta es la parte más compleja en tanto en cuanto hay departamentos de TI que, a estas alturas, ven comprometido el presupuesto operativo ya más que rebajado durante estos últimos años.

Cuando lo leí me pareció un artículo muy interesante porque establece de una manera clara, concisa y con sentido común el mapa básico sobre el que trabajar. Como se suele decir, si bien el mapa no es la ruta, si usamos un mapa erróneo o incompleto podemos acabar siguiendo el camino – siguiendo una moda, eligiendo el proyecto, implantando la solución, apostando por una tecnología…- equivocado.

Consumerización de TI

Partamos de la premisa de que parece claro que la comoditización y consumerización de las TI está acelerando la transición hacia los servicios básicos (commodity) de TI a la vez que está permitiendo la toma de decisiones sobre TI, fuera del departamento de TI, por parte del resto de líneas o áreas de negocio de la organización.

La comoditización lleva inevitablemente al Director de TI o CIO a discutir de precios con el negocio, a que determinados servicios que presta el departamento de TI se vean únicamente cómo un coste. Esto es así porque el negocio no aprecia valor en ellos y no está dispuesto a gastar más de lo necesario por un servicio que considera básico.

La consumerización, especialmente a través de las soluciones y servicios cloud, pone al alcance de los responsables de negocio un abanico ingente de soluciones fácilmente parametrizables (aunque no necesariamente integrables) al margen del control del departamento de TI. Esto les ayuda a tener la sensación, a veces real, de que por fin las TIC se mueven a su misma velocidad, la del negocio.

Respecto de la comoditización, parece claro que la única manera de huir de ella, y de ser vistos única y exclusivamente como un centro de coste, es creando y demostrando valor. Y la mejor manera de hacerlo es conociendo qué es importante para el negocio en general y para las diferentes áreas y sus responsables en particular.

Respecto de la consumerización, el Departamento de TI tiene básicamente dos opciones. La primera consistiría en tratar de “poner puertas al campo” restringiendo el uso de tecnología internamente y, en consecuencia, acabando con la innovación que les solicita el negocio. En la segunda opción, el departamento de TI proporcionaría servicios centrales de apoyo al uso de dichas tecnologías proporcionando, además, un marco de cumplimiento, gestión e incluso operación de las mismas.

Parece claro, por tanto, que como respuesta a estas dos tendencias, el Departamento de TI debe potenciar la provisión de sus servicios profesionales de TI. Es decir, de aquellos servicios que asesoran al negocio en base la experiencia en determinadas áreas conocimiento específico.

Me estoy refiriendo a servicios de alto valor para el negocio que debe realizar o liderar el departamento de TI. Un ejemplo podría ser la realización de un Plan Director de Seguridad, de un Plan Director de Sistemas, de un Plan de Contingencia de TI (BIA y Análisis de Riesgos incluido) o de un análisis de los riesgos o implicaciones del uso de aplicaciones de social media para comunicarse con los usuarios o clientes. Incluso, y debido al carácter transversal del Departamento de TI, éste puede ser el mejor preparado para realizar un Plan de Continuidad de Negocio o un análisis de riesgos operacionales del negocio.

Gestión del servicio: de la contención a la construcción

Se entiende por Gestión del Servicio el conjunto de competencias especializadas de la organización que proporcionan valor a los clientes en forma de Servicios (ITIL® 2011 Edition: Service Strategy Glossary).

Si el delivery se visualiza como una escala en la que los polos corresponden a "bueno" o "malo", estaremos más cerca de un extremo o del opuesto en función de múltiples factores: económicos, organizativos, humanos, etc. No obstante, lo que determina indudablemente cuál será su posición de valor real es la consciencia que el proveedor de servicios de TI tenga de la gestión del servicio en sí misma. Si el espíritu con el que lo afronta es de contención, o bien de construcción. Esta diferencia de enfoque determina cuál es su actitud final frente al cliente:

• Actitud de contención 

Nunca suele ser una actitud de partida en un contrato de servicios. Se llega a ella tras un tiempo de provisión del servicio que no se percibe por parte del cliente como satisfactorio. La gestión del servicio, lejos de construir, dedica todos sus esfuerzos a contener y canalizar el descontento del cliente para mantener a flote el contrato.

• Actitud de construcción 

Existe una cultura de servicio. El cliente es la principal prioridad y por tanto, existe un programa de mejora continua implantado y en funcionamiento que recoge el feedback de éste. Se conocen bien sus características y sus requerimientos. El valor que se proporciona es en forma de garantía del servicio. La gestión del servicio se realiza en un marco de colaboración y crecimiento.

El rasgo diferencial subyacente entre ambas actitudes reside en la existencia o, en su defecto, en la carencia de una estrategia de servicio implementada en la organización proveedora de los servicios de TI. Por tanto, la evolución de una actitud de contención a una actitud de construcción pasa inevitablemente por desarrollar esta estrategia. No obstante, su desarrollo no es precisamente algo trivial ni fácil de llevar a cabo, requiere un gran conocimiento tanto del cliente o clientes, como de la propia organización proveedora de los servicios de TI ¿Por dónde empezar?

Detallamos a continuación 3 aspectos que son esenciales:

1. Identificar los diferentes tipos de cliente para adaptar nuestra organización proveedora de servicios TI a sus diferentes requerimientos y necesidades. No todos los clientes son iguales, y en consecuencia, nuestros servicios deben ser suficientemente flexibles para poder atenderlos en su particularidad.
2. Identificar adecuadamente las expectativas del cliente, es decir, conocer lo que es realmente importante para el cliente, no lo que suponemos o percibimos que puede ser.
3. Gestionar su demanda, es decir, ajustar las expectativas anteriores a nuestra capacidad real, como proveedores, para prestar ese servicio de forma satisfactoria para ambos.

When we turn on a water tap, we expect to see water flow from it. When we turn on a light switch, we expect to see light fill the room. Not so many years ago, these very basic things were not as reliable as they are today. We know instinctively that the advances in technology have made them reliable enough to be considered as utility. But it isn't just the technology that makes the service reliable. It is how they are managed [1]

---

[1] ITIL® Service Strategy. 2011 Edition Pag.15.

¿Cuáles son los tres errores más comunes a la hora de abordar la seguridad de TI?

1. Abordar el tema desde un punto de vista donde prevalece el aspecto técnico

Las personas que iniciamos nuestra carrera profesional como técnicos tenemos tendencia a intentar resolver los problemas también desde un punto de vista técnico. Es de esta manera como pensamos en abordar los retos asociados a la seguridad de la información. La gran mayoría de las soluciones existentes en el mercado tienen su nicho de mercado, su utilidad y su beneficio para la organización. Sin embargo nos olvidamos de dos aspectos fundamentales asociados a la seguridad:

• Más vale poner una tirita en la herida que una venda fuera de ella

Esto básicamente significa que las medidas de seguridad que implantemos deben estar asociadas a los riesgos que tengamos y a las obligaciones legales que sea necesario cumplir. Esto hará, sobretodo, que la seguridad sea rentable para la organización ya que ayudará a hacer un uso racional de los recursos en base a la eliminación de inversiones innecesarias o ineficientes. Una vez tenemos claros los requisitos de seguridad podemos pensar en qué solución existente en el mercado se adapta mejor.

• La seguridad de nuestra organización viene determinada por la seguridad del eslabón más débil.

Si únicamente vemos la seguridad como un “problema” técnico es como si estuviéramos poniendo una puerta blindada en nuestra casa mientras dejamos la ventana abierta. No podemos olvidarnos de las personas y de los procesos que nos van a ayudar a ser eficientes y eficaces a la hora de trabajar la seguridad.

2. No pensar en montar un sistema de gestión

Las organizaciones y su entorno son organismos vivos. La regulación, los procesos de negocio, los servicios de TI, la infraestructura, personas y  procesos que los soportan cambian con el tiempo.

El sistema de gestión nos va a permitir planificar los proyectos y tareas necesarios para garantizar la seguridad de nuestra organización, ejecutar adecuadamente dichos proyectos y tareas, chequear que se están realizando según lo planificado y actuar en consecuencia. En definitiva el sistema clarifica qué se debe hacer, quién y cuándo gracias a la introducción de un modelo de mejora continua que garantice que los objetivos de seguridad se alcanzan y mantienen e incluso mejoran a lo largo del tiempo.

3. Pensar en que la seguridad es sólo un problema del Departamento de TI

Nuestra experiencia nos dice que, generalmente, el negocio ve como algo burocrático, “molesto”, innecesario, las medidas de seguridad que pretende adoptar el departamento de TI. Para que el negocio vea que estas medidas son útiles es necesario que se justifiquen por la necesidad de reducir o eliminar riesgos asociados a los procesos de negocio. Es por tanto imprescindible realizar un análisis de riesgos y un análisis de impacto den el negocio. Es obvio que además es importante concienciar,  formar e implicar a toda la organización en temas de seguridad de TI.

La paradójica existencia de las "guerrillas" IT

Se ha escrito muchísimo sobre el llamado "Sun-Tzu" o "Arte de la Guerra" como un clásico de estrategia militar de actual aplicabilidad al mundo de los negocios y de la estrategia empresarial (véase por ejemplo "El Arte de la Guerra para Directivos" de Gerald Michaelson). Un aspecto muy recurrente de los muchos que se tratan en todas estas publicaciones, es la comparación del enemigo con la competencia directa externa, pero curiosamente, la mayoría de las veces, no hay que irse tan lejos para observar que los "mini campos de batalla" se suceden día tras otro, en nuestro entorno más cotidiano dentro de la propia compañía e incluso dentro de la propia área.

A lo largo de mi experiencia, he tenido la oportunidad de llevar a cabo proyectos para diferentes organizaciones, el desarrollo de los cuales, ha acontecido en el "campo de batalla" de sus áreas IT, eso sí, bajo un aparente clima de calma. Lo paradójico de esta situación y como sucede en todas las guerras, es que nunca produce vencedores, sino únicamente estancamiento y pérdida por igual.

Mi posición de observadora accidental en esta particular guerra IT encubierta, me ha permitido reflexionar sobre esta cuestión y sobre los posibles motivos que la fomentan, llegando a la conclusión que, salvando la predisposición tan humana al conflicto, son principalmente consecuencia de:

• Una carencia clara de estrategia, o bien de alineación entre la estrategia tecnológica y la corporativa de negocio de la organización, cuya primera implicación es la divergencia de directrices, objetivos y prioridades. Esto se traduce en la máxima: "a falta de criterio, el mío es el que vale".

• La consolidación del efecto "Reino de Taifas", cuyas características más destacadas son a mi modo de ver, por un lado, el establecimiento de "facciones" de poder que implican el posicionamiento de los integrantes de rango y por otro lado, una acentuada problemática de comunicación y coordinación entre "reinos" que impacta en el desarrollo normal de las actividades del área IT y por tanto, en el negocio.
  

• La inexistencia de la práctica del análisis de carácter iterativo (mejora continua) y en consecuencia, la resistencia como respuesta a la crítica y la oposición al cambio: "crítica vs fiscalización".

• Las propias aptitudes de liderazgo de sus componentes.

En resumen, estamos hablando de estrategia, trabajo en equipo, comunicación, metodología y liderazgo: ¡todo un clásico!.

Tomando como referencia el tratado de Sun-Tzu (capítulo 1) y salvando las distancias, estas problemáticas, analizadas bajo el prisma de los cinco fundamentos del arte de la estrategia, ponen de manifiesto que tanto éstas como cualquier otra proclive a la "guerra de guerrillas", no se rigen por criterios de gobierno y sin gobierno no hay victoria.

Como conclusión, y puesto que ya se ha escrito mucho sobre el tema, me quedo con esta reflexión:

Preveer una victoria que un hombre ordinario puede preveer, no es el espíritu de la excelencia. No importa si triunfas en la batalla y eres aclamado universalmente como "experto", pues levantar una hoja caída no requiere tener gran fuerza, distinguir entre el día y la noche no es prueba de gran visión, oír un trueno no es muestra de oído agudo.
(...)
Los que son expertos en la guerra cultivan sus políticas y se adhieren estrictamente a las reglas trazadas. De este modo, tienen en su poder el control de los acontecimientos.

(Sun-Tzu - El Arte de la Guerra, capítulo 4: Disposiciones)