13 fuerzas que dan forma al futuro de la TI

La tecnología siempre nos sorprende, ya sea por sus saltos cuánticos (en China, en cifrado de datos, memoria, nanotecnología) o, al menos, por una constante evolución y socialización (desde las primeras herramientas de la Edad de Piedra, hasta las supercomputadoras de hoy). La fuerza impulsora es variada, desde la supervivencia hasta más allá del mero conocimiento o descubrimiento, pasando por guerras y riquezas.

Con respecto a las tecnologías de la información, las fuerzas son varias. En ese sentido apoyan las nuevas formas del Centro de Datos, el empleo de la computación social (redes sociales), de nuevos dispositivos (smartphones, superficies inteligentes, IP-TV, 3D) o formas de trabajo (BYOD seguras), o de nuevas formas de lugar de trabajo (autenticidad, transparencia, confianza, cultura, cambios demográficos, virtual, entre algunas formas).

Algunas ya son conocidas. Tenemos, por ejemplo, (1) automatización de las tareas comunes (pero controladas), que decanta en (2) velocidad para tomar decisiones y desarrollar estrategias que tengan un impacto directo en el negocio, (3) agilidad entre departamentos estableciendo habilidades blandas y colaboración eficiente, y (4) flexibilidad requerida para hacer frente a la competitividad globalizada  y siempre cambiante de nuestro mundo actual (coyuntura, mercado, gustos, preferencias, servicios, entre otros factores a considerar), que genera una (5) hipercompetición la cual conduce a acuerdos de menor costo en el mercado de compradores de servicios TI, siendo la amenaza real la sostenibilidad de estos acuerdos, la (6) consumerización porque el comportamiento de los consumidores tiene el poder de redefinir el modo en que las empresas de TI trabajan, sin olvidar que todo eso acarrea problemas de (7) seguridad y privacidad, tanto en la identificación de los agujeros en la seguridad como en la búsqueda de talento para hacerles frente, y la necesidad de que el (8) gasto en TI esté más gobernado que antes.

Otras son innovadoras en su planteamiento. Tenemos, por ejemplo, una mayor (9) colaboración entre TI y otras unidades de negocio, además que la nube proporciona más opciones que antes (controlando aspectos de nivel de servicio, seguridad en la transmisión y almacenamiento de datos, localización de datos, entre otros a considerar), siendo su utilización muchas veces resultado de decisiones estratégicas y tácticas para la tecnología impulsadas por las unidades de negocio no-TI, o la creación de una (10) simbiosis entre la automatización, que provee los datos suficientes y patrones repetibles, y la inteligencia artificial para impulsar el proceso, de modo que, considerando (11) la información correcta, en el momento y lugar adecuados (ubicuidad de la información), se podría acelerar el desarrollo y la puesta en marcha de nuevos servicios.

Otras son resultado de la (12) acumulación de datos, y la necesidad inherente de aplicar (13) analítica. No perdamos de vista que los servicios financieros también serán alterados radicalmente –no sólo por el ransomware, lo que acarreará también mayores innovaciones en las TI.

Varias maneras de mejorar tu SLA

Es importante revisar cómo este tema avanza y, aunque lo vemos a diario ya que las bases están cubiertas, aún no lo interiorizamos apropiadamente.

Ya hemos conversado sobre la importancia que reviste un SLA apropiado para colocar servicios en la nube, aunque los proveedores de servicios en nube son (normalmente) reticentes a cualquier modificación en sus SLA estándar.

También hemos comentado cómo para una TELCO 2.0, un SLA correctamente ideado e implementado es un diferenciador importante, y una garantía de éxito.

Has contratado un servicio que establece lo que está comprendido en él y lo que no (alineado con los objetivos del negocio –estando articulados TI y el negocio en primer lugar –objetivos, expectativas, planificación, rediseño de procesos pueden ser factores previos importantes de considerar), y su vigencia.

El servicio contratado contempla recursos y capacidades que se deben entregar, está sujeto a restricciones, a plazos, a una calidad en la prestación, disponibilidad comprometida, responsabilidades de cada parte, procedimientos de escalamiento, pago, compensaciones, entre otros factores. Decir que se entrega algo que ha sido contratado no es lo mismo que evidenciarlo. Lo que buscamos son evidencias de dicho cumplimiento. Para ello gestionamos el servicio al establecer los estándares de medición, procedimientos para los reportes (contenido, frecuencia, entre otros aspectos a considerar), procesos para resolver controversias, cláusulas de indemnización en caso de incumplimiento por propios o terceros, mecanismos de actualización del SLA sobre todo cuando cambian los requisitos del servicio por cambios en la coyuntura socio-económica-cultural, modernización de la tecnología subyacente, cambios en las cargas de trabajo, existen mejoras en los procesos y herramientas de medición, o los recursos o las capacidades del proveedor del servicio (interno, y lo llamamos OLA o nivel de servicio organizacional, o externo, los SLA).

Chris Drumgoole, de Terremark, nos dice que “todo el mundo sabe que las cosas se rompen – es la naturaleza de la vida. Es cómo responder a las cosas que se rompen lo que te diferencia como proveedor de servicios en la nube”.

Entonces, resulta razonable establecer criterios para desarrollar las métricas que ambas partes deberán utilizar para realizar sus mediciones. Comúnmente medimos la disponibilidad del servicio, la tasa de defectos, la calidad técnica (incluyendo precisión y exactitud), tiempo de respuesta del personal de soporte, nivel de seguridad, velocidad, capacidad de respuesta y la eficiencia. Todo esto y más dependiendo del servicio contratado. Es más, podríamos considerar como SLA los resultados del negocio, una evolución más para reflejar la adición de nuevos servicios. Lo importante es que estas métricas hayan sido definidas con cuidado, sean periódicamente revisadas y actualizadas, sean las realmente necesarias, puedan realmente obtenerse (si es automático, mejor), estén controladas, tengan sentido, y motiven un comportamiento apropiado de ambas partes.

No debemos olvidar nuestro ecosistema tecnológico, el que controlamos normalmente (independiente de nuestro modo de operación), y el que aparece con el Shadow IT el cual también debe ser apropiadamente gobernado. Es evidente debemos incluir la Shadow IT en la Gestión de eventos, incidentes, problemas y solicitudes y, por ende, estaría representada esta gestión en los contratos con terceros o UC según ITIL®, y formaría parte del sistema de reportes de rendimiento y cuadros de mando.

Esto ayuda a incrementar el reconocimiento del valor que entrega IT al negocio como un todo.

¿Quién desea una TI Bimodal?

¿Quién desea una TI Bimodal?

Según Gartner, bimodal es la práctica de la gestión de dos estilos distintos pero coherentes de trabajo: uno centrado en la previsibilidad; la otra en la exploración.

Revisemos:

  • El Modo 1 (más gobierno, menos cambio) está optimizado para las áreas que son más predecibles y son bien entendidas. Lidiamos aquí con, pero no limitados a, estabilidad, robustez, estándares, planificación cuidadosa, cumplimiento, gobierno, riesgos, eficiencia, seguridad, precisión, disponibilidad, presupuestos, niveles de servicio y requisitos.
  • El Modo 2 (menos gobierno, más cambio) es exploratorio [pero requiere un enfoque riguroso y disciplinado -para que las cosas no se escapen de las manos], experimentando para resolver nuevos problemas, agilidad centrada en el tiempo de lanzamiento al mercado [velocidad], la rápida evolución de la aplicación y, en particular, la estrecha alineación con las unidades de negocio.

En la siguiente figura Gartner gráfica lo anterior:

Estas iniciativas a menudo comienzan con una hipótesis que se prueba y se adapta durante un proceso que implica iteraciones cortas, adoptando potencialmente un enfoque de producto viable mínimo (MVP) -experimentación.

Tengamos presente que un equipo de TI exploratorio no es fácil porque tienes que desafiar el pensamiento convencional [de las personas, claro], aceptar los riesgos [la empresa] y sentirte cómodo con un ritmo de cambio [motivación de todos] que es muy diferente de la forma actual en que opera TI.

Ninguna iniciativa es igual a otra, dadas las particularidades de cada negocio, mercado, o empresa. Cada empresa debe conocer su ecosistema, para adaptarse conforme convenga, e innovar rápidamente para responder a las amenazas y oportunidades.

Sabemos que, en el contexto empresarial, el estilo de trabajo, el modelo de decisión y la gobernanza, son los que hacen la diferencia; por tanto, cada empresa debe evaluar -a través de prueba y error- cómo enfrenta este paradigma, porque seguramente requerirá equipos multidisciplinarios [manpower], consultorías, nuevos contratos de soporte, nuevas negociaciones, nuevas herramientas, nuevos procesos, nuevas competencias, nuevas habilidades, nuevos conocimientos, nuevos recursos, y nuevas capacidades. No dejemos de lado el costo total de propiedad y los niveles de servicio acordados.

Seguramente deberemos considerar incluir cosas como aplicaciones móviles y su desarrollo, experiencia para el lado del cliente, IoT [Internet de las cosas] para obtener cierta experiencia en la captura de grandes flujos de datos y analizarlos desde diferentes dispositivos, ya sean estos dispositivos de consumo, dispositivos industriales, lo que se tenga a mano. Podría acabar ocurriendo que los ingenieros recién entrenados quieren usar nuevas técnicas en sistemas antiguos, y crear silenciosamente work-arounds en lo que se ha conocido como “shadow IT“. Trataríamos entonces de incorporar y estandarizar esta shadow IT y permitir a los innovadores innovar, pero dentro de la estructura corporativa. Esto implicaría una reingeniería de la gestión tecnológica y del papel de la empresa en su implementación.

Pero, tengamos presente que no por utilizar métodos ágiles o DevOps ya somos bimodales. La organización también está involucrada, no solo es un asunto de pura tecnología. Tampoco significa dedicarse a producir código porque se arriesga una mayor complejidad arquitectónica y de aplicación, lo que reduce la agilidad de la empresa. Recordemos que la cadena se rompe por el eslabón más débil, ¿o será que avanzaremos siempre al paso del más lento? [el impacto en los clientes, específicamente, es parte del segundo efecto secundario].

Ambos modos son esenciales, según Gartner, [tienen una relación simbiótica] para crear un valor sustancial, e impulsar un cambio organizativo importante, ninguno es estático y, probablemente, para el futuro tampoco sean suficientes. Combinar [y balancear] una evolución más predecible de productos y tecnologías (Modo 1) con lo nuevo e innovador (Modo 2) es la esencia de una capacidad bimodal empresarial. Ambos modos juegan un papel esencial en la transformación digital.

Sin embargo, el Modo 1 podría erróneamente considerarse negativo [¿desmotivación por creer que debe mantenerse con lo legacy (islamiento), con el día a día, aunque exista la nube?]. Y no vemos que se debería centrar en la explotación de lo que se conoce, pero renovando a la vez el entorno heredado a un estado que es apto para un mundo digital –renovar el core es la clave. De igual modo, el Modo 2 podría considerarse erróneamente positivo, (siempre iterando / ¿arriesgando, sobre simplificando, sin normas, con prácticas no lineales?), y siempre debería siempre estar ¿planeando para el futuro? [¿flexibilidad?, ¿motivación por mantenerse en lo nuevo?]. Capacidad de respuesta frente a estabilidad.

¿Y si cambiamos el ejemplo de los corredores a las velocidades de una bicicleta de carrera? ¿o de blanco y negro al espectro de colores? ¿cuán segregada/dividida/segmentada podrían estar TI? Esto sugiere que este modelo bimodal podría ser una sobre simplificación de lo realmente requerido. Por ejemplo, una mejor alternativa, según John C. McCarthy, analista de Forrester, es que las organizaciones trabajen más para entender sus desafíos y hacer “los cambios necesarios para conducir la simplicidad”. El enfoque en los clientes, más que la velocidad o una disciplina en particular, es el diferenciador crítico en las empresas que están teniendo éxito.

También debemos tener cuidado y considerar que los modos podrían competir inevitablemente por los fondos, recursos, habilidades y la atención de la dirección, sin dejar de lado estándares, disciplina, reducir complejidad, gestionar riesgos, en todo momento. Ambos conceptos pueden funcionar mejor cuando son compartidos por los elementos front-end y back-end del ecosistema de TI. Iterar es bueno, pero con la verificación y la metodología de las TI tradicionales de back-end.

Ah! la eficiencia –hacia una cultura de productividad

Peter Drucker dijo que la eficiencia es hacer bien las cosas[1].

El pensamiento lean[2] (sin grasa, ¿recuerdan el término de los ’90?) es lograr hacer las cosas correctas[3] dijo Pascal Dennis, teniendo como base fundamental para este “hacer” a los equipos de trabajo, y al cliente como centro[4] porque es el cliente quien define lo “correcto”, de modo que, en una cadena de producción o en la provisión de un servicio, aseguremos que sólo se usen recursos que agreguen valor al cliente final[5].

Desde un punto de vista productivo, el pensamiento lean busca eliminar desperdicios como: tiempos de espera innecesarios (entre etapas del proceso, plazos inadecuadamente comprometidos); por defectos (que tras una inspección –o varias- generan correcciones, iteraciones entre desarrollo del producto o servicio y el control de calidad); por movimientos innecesarios (de materiales en físico cuando puede emplearse medios digitales); mantener un inventario innecesario (inmovilizado ‘por si acaso’, excedente, no sólo de materia prima sino también de herramientas); por el procesamiento innecesario (muchas manos, pocos o ningún responsable, criterios no establecidos, delegación/empoderamiento inadecuado) o manipulación innecesaria (incremento de riesgos, accidentes, errores que se busca subsanar al final y no en la fuente[6] o de inmediato); por el transporte (o desplazamiento del colaborador cuando una acción remota puede ejecutarse) para su entrega al usuario final (cuando se puede emplear métodos alternativos como vídeo conferencia); y, por supuesto, sobredimensionamiento.

Desde el punto de vista de TI, en la era digital, el mandato de la tecnología se ha convertido en liderar como una ventaja competitiva a través de la diferenciación de [recursos y] capacidades y velocidad para explotar los cambios en los negocios[7]. En la siguiente figura se muestra cómo la TI empresarial propicia el cambio en el negocio, transformándose entre el paradigma tradicional (gestionar un proyecto para [buscar] garantizar el éxito de implementar una metodología secuencial, para entregar eficientemente el cambio de negocio a gran escala) y el paradigma digital (mentalidad en el producto, implementando una metodología iterativa, entregando cambios en pasos más pequeños, rápidos, confiables y eficientes):


picture4-100664754-orig

Fuente: http://www.cio.com/article/3078824/leadership-management/is-your-it-ready-for-the-digital-age.html

Esto implica ser adaptables y flexibles[8] como lo exige el ecosistema actual, en cuanto a la entrega de servicios, seguridad de la información, gobierno –recordemos que el valor diferencial de una compañía radicará en cómo gestiona y explota su información[9], más que en cómo gestiona la tecnología con paradigmas operacionales[10] obsoletos[11].

Requerimos entonces una TI eficiente. Pero también implica que debemos eliminar lo que no aporta, y tenemos una TI lean –lo que implica un cambio de paradigmas, de mentalidad, de procesos, como lo demostró Toyota, no de la fuerza laboral[12].

En la siguiente figura se muestra el valor incremental de la TI lean sobre la TI eficiente:

lean-it-levers-100687430-orig

Fuente: http://www.cio.com/article/3128277/it-strategy/the-chasm-between-efficient-it-and-lean-it.html

El siguiente extracto del artículo es particularmente ilustrativo: “La calidad genera valor al abordar problemas en la fuente. Piense en una gota de tinta en una piscina. Con una acción rápida, la tinta se puede limpiar con una sola inmersión de un cubo. Si se retrasa, la tinta se difunde por toda la piscina y requiere que el agua de la piscina sea reemplazada por completo. Del mismo modo, los defectos que permanecen en el sistema bastante tiempo causan nuevos defectos, y una corrección se vuelve exponencialmente más costosa”.

El 2016 State of DevOps Report[13] nos recuerda que hay mucho más en el rendimiento de TI que en las prácticas técnicas. Con el fin de crear un alto rendimiento sostenido, las organizaciones necesitan invertir tanto en sus personas y procesos como lo hacen en su tecnología. Entre sus conclusiones cuentan que la seguridad es una parte integral de la entrega continua, que, al incorporar calidad y seguridad en el ciclo de desarrollo de software, las empresas de alto rendimiento gastan menos tiempo en trabajos no planificados, que estas empresas pasan menos tiempo resolviendo problemas de seguridad y pasan más tiempo en nuevos trabajos de valor añadido, entre otros factores distintivos.

Analicemos nuestra brecha digital y comprometámonos a cerrarla –rápido (consolidación, habilidades digitales, servicios gestionados, servicios compartidos, costo total de propiedad, entre otros aspectos[14]).

[1]  Fuente: http://www.cio.com/article/3128277/it-strategy/the-chasm-between-efficient-it-and-lean-it.html; disponible en dic/2016

[2]  Fuente: http://aelit.congresoaelit.com/; disponible en dic/2016

[3]  Fuente: https://www.lean.org/WhoWeAre/LeanPerson.cfm?LeanPersonId=45; disponible en dic/2016

[4]  Fuente: http://aunclicdelastic.blogthinkbig.com/lean-it-una-declaracion-de-objetivos/; disponible en dic/2016

[5]  Fuente: http://www.ibermatica.com/sala-de-prensa/opinion/lean-it-aplicando-experiencias-industriales-para-la-mejora-de-la-eficacia-it; disponible en dic/2016

[6]  Fuente: http://www.cio.com/article/3143195/it-strategy/whats-next-for-enterprise-it.html?idg_eid=0f3e0907b81179ebb4f3b209b6424bae&token=%23tk.CIONLE_nlt_cio_enterprise_2016-11-30&utm_source=Sailthru&utm_medium=email&utm_campaign=CIO%20Enterprise%202016-11-30&utm_term=cio_enterprise#tk.CIO_nlt_cio_enterprise_2016-11-30; disponible en dic/2016

[7]  Fuente: http://www.cio.com/article/3078824/leadership-management/is-your-it-ready-for-the-digital-age.html; disponible en dic/2016

[8]  Fuente: http://www.cio.com/article/3143195/it-strategy/whats-next-for-enterprise-it.html?idg_eid=0f3e0907b81179ebb4f3b209b6424bae&token=%23tk.CIONLE_nlt_cio_enterprise_2016-11-30&utm_source=Sailthru&utm_medium=email&utm_campaign=CIO%20Enterprise%202016-11-30&utm_term=cio_enterprise#tk.CIO_nlt_cio_enterprise_2016-11-30; disponible en dic/2016

[9]  Fuente: http://www.silicon.es/lean-it-una-futura-tecnologia-delgada-y-valerosa-2209541; disponible en dic/2016

[10]                Fuente: https://www.standishgroup.com/sample_research_files/Modernization.pdf; disponible en dic/2016

[11]                Fuente: https://www.cebglobal.com/content/dam/cebglobal/us/EN/best-practices-decision-support/innovation-strategy/pdfs/ceb-strategy-putting-the-strategy-back-in-strategic-planning-summary.pdf; disponible en dic/2016

[12]                Fuente: http://www.cio.com/article/3146921/it-strategy/its-not-the-workforce-but-the-system-that-needs-a-fix.html; disponible en dic/2016

[13]                Fuente: https://techbeacon.com/sites/default/files/gated_asset/2016-state-of-devops-report.pdf; disponible en dic/2016

[14]                Fuente: http://www.cio.com/article/3128277/it-strategy/the-chasm-between-efficient-it-and-lean-it.html; disponible en dic/2016

Transformación digital

McKinsey[1] nos dice que la transformación es quizás el término más usado en los negocios. A menudo, las empresas lo aplican libremente, a cualquier forma de cambio, por pequeño o rutinario que sea.

Así, el término “transformación digital” se ha utilizado para describir cualquier cosa, desde una aplicación técnica hasta el desarrollo de una estrategia de medios sociales, pero en realidad la verdadera transformación necesita involucrar mucho más que el producto final[2].

Veamos.

Las empresas han evolucionado, como lo muestra la siguiente figura, que propone una combinación de fuerzas económicas y tecnológicas que han cambiado el mundo y han creado y crean disrupción –nadie está a salvo. Interesante el trío de tecnologías habilitadoras:

the-digital-enterprise-wave

Fuente: High Level Digital Transformation Diagnostic, Agile Elephant

Forrester[3] nos alerta que el mundo se ha vuelto digital ‑la competencia se basa cada vez más en la fuerza de sus experiencias digitales y negocios digitales. Así, buscamos realizar hoy una transformación digital para competir mañana y lo hacemos por diversas razones:

  • Porque hemos fallado en evolucionar como empresa, nuestros proyectos no han sido exitosos, y es una cuestión de transformar o perecer[4], ya que la competencia lo está haciendo. Forrester nos informa que 46% de los ejecutivos encuestados por creen que para el año 2020 lo digital tendrá un impacto en más de la mitad de sus ventas[5].
  • Porque buscamos crecer. PWC[6] nos informa lo que los negocios realmente quieren tras esta iniciativa: aumentar las ganancias; aumentar los ingresos; crear una mejor experiencia del cliente.

pwc-chasing-digital-value

Fuente: PWC, 2015 Digital IQ Survey

  • Porque es una transformación del negocio lo que buscamos siendo que lo digital está [o debería estar] ya imbuido en el negocio y porque lo digital está muy arraigado en el consumidor actual o, como dice Altimeter[7] “un realineamiento de modelos de negocio y procesos para generar un nuevo valor para los clientes y empleados con el fin de competir efectivamente en una economía digital en constante cambio” –lo que podría potencialmente abarcar a todos los clientes.
  • Porque los proyectos de transformación digital deben producir algo valioso para el consumidor y el negocio y esto requiere de una visión clara del líder para que el negocio la compre y se comprometa, ‑porque si no, nada se transforma. Liderar el cambio digital requiere que los gerentes tengan una visión de cómo transformar su empresa para enfrentar un mundo digital. Algo valioso para el usuario podría ser, por ejemplo, la experiencia en la navegación y personalización, considerando además un muy probable comportamiento cambiante. Para el negocio, algo valioso podría ser, por ejemplo, una capacidad superior de analítica de datos (grandes volúmenes de datos y una aplicación avanzada), integración de tecnologías, agilidad y flexibilidad operativas para enfrentar nuevos requerimientos –teniendo siempre en cuenta el costo total de propiedad.
  • Porque buscamos una manera de decir que nos movemos a la nube [primero[8]], en cuyo caso, deberemos conocer los pasos que deberemos seguir, determinar si debemos crear nuevos puestos de trabajo o contratar consultorías especializadas, establecer la garantía del servicio, por ejemplo.

Lo cierto es que la transformación digital es imperativa para cualquier negocio, grande o pequeño ‑declaración bastante trillada además. Pero tengamos presente que la transformación digital implica invertir en la tecnología que sea y cuando sea apropiada, porque la tecnología por sí sola no es una solución –es un medio, no una estrategia; es un viaje, no un destino.

Según un artículo del MIT Sloan Management Review[9], cuanto mayor sea la madurez digital de una empresa, mejores serán sus resultados financieros. La madurez digital está dada por la intensidad digital, que es el nivel de inversión en iniciativas que son posibles con la tecnología y que significan cambiar la forma en que opera la empresa; y por la intensidad en la gestión de la transformación, que es el nivel de inversión en las capacidades de liderazgo necesarias para crear la transformación digital dentro de una organización, y el gobierno correspondiente. Y Deloitte[10] nos dice que es la estrategia digital la que impulsa la madurez digital, y la agenda digital se conduce desde arriba. El líder digital debe tener la capacidad de articular el valor de las tecnologías digitales con el futuro de la organización –no precisamente ser un experto en tecnología. Las empresas van desde una madurez temprana, pasando por un estado de desarrollo de la madurez, y van madurando digitalmente.

De hecho, PWC ha identificado las siguientes diez capacidades críticas que se correlacionan con un fuerte rendimiento financiero –evidentes, por cierto, todos los puntos, y especialmente el de ciberseguridad: liderazgo, de arriba para abajo, compromiso, estrategia compartida en toda la organización, abordar los temas desde afuera, impulsado por la ventaja competitiva, uso eficiente de los datos del negocio (analítica, tecnología adicional a las propuestas por Agile Elephant: nube, social, móvil), ciberseguridad, ruta digital clara, medición consistente y continua.

digital-iq-survey

Fuente: PWC, 2015 Digital IQ Survey

Crear una nueva forma interna de trabajar y comunicarse es parte del proceso. Es un cambio cultural para muchas organizaciones. Las personas, sus habilidades y la cultura de la organización son esenciales para que una transformación tenga éxito. Agile Elephant[11] nos sugiere emplear el modelo de las 7 S de McKinsey[12] para diseñar la transformación, y no olvidarnos de la parte “blanda” anterior, ya que usualmente nos enfocamos sólo en la parte “dura”, y es que la transformación digital es un problema de personas, y agregaría, motivadas:

mckinsey-7-s-model

Debemos fomentar la innovación [sin grandes volúmenes de datos de calidad que “alimente” la innovación, el proceso se detendrá], la capacidad de innovación, y nuevos modelos de negocio[13], buscar cambiar la organización de un enfoque legacy a nuevas formas de trabajar y pensar usando tecnologías digitales, sociales, móviles y emergentes con la finalidad de propiciar cambios en las relaciones con clientes, procesos internos y propuestas de valor[14]. Lo cual implica, según Gartner[15], modernizar las aplicaciones nucleares, extender las capacidades de estas aplicaciones, transicionar a nuevos modelos de consumo como SaaS, entre otras posibilidades de abordar el tema. Gartner también nos sugiere construir software diferenciado, innovador y no estándar o software con servicios profesionales (para requisitos de personalización e integración), o soluciones cada vez más originarias de empresas emergentes, disruptores o proveedores locales especializados, y no comprar aplicaciones ya hechas. ¿No les parece una ola esto?; es decir, ¿no lo habían escuchado antes?

Operar dentro de los límites de los paradigmas tradicionales sin propósito ni visión desafía finalmente la dirección, la capacidad y la agilidad para prosperar en una economía digital. El camino hacia la transformación suele ser moldeado por la persona o el grupo que dirige el esfuerzo, lo cual puede limitar la implementación de una transformación holística, persistente y significativa en toda la empresa; por ejemplo, impulsando las inversiones digitales desde una perspectiva operativa o tecnológica sin la empatía del cliente o el conocimiento de cómo y por qué las nuevas expectativas, preferencias y valores que generan la disrupción de los mercados. Crean lo que Schumpeter acuñó como “destrucción creativa”[16].

El cambio cultural requiere que las organizaciones desafíen continuamente el statu quo, experimenten a menudo –tomar riesgos es una norma cultural, y se sientan cómodos con el fracaso. El compromiso con los empleados y gerentes necesita tener un contexto, una visión y un llamado a la acción que resuene con cada persona individualmente. Este tipo de personalización es lo que motiva a una fuerza de trabajo. La incorporación de los procesos y enfoques de trabajo de la transformación en actividades cotidianas deben darse desde el inicio de la transformación para asegurar que el impulso del rendimiento continúe acelerándose después de la transformación.

Además, necesitamos saber dónde está ocurriendo el cambio[17], dónde tiene el mayor impacto –y cuán rápido está ocurriendo. Es importante mirar más allá de su propio sector: la interrupción digital no respeta las fronteras de la industria.

La optimización del contacto que tiene el cliente con la marca obliga a una empresa a identificar todas las herramientas y tecnologías –apropiadas para la tarea, procesos, capacidades y transiciones necesarias para ofrecerle una gran experiencia[18] -e incrementar el valor de vida del cliente[19] por supuesto.

La forma en que las organizaciones han estado planificando y administrando cambios a gran escala ya no funciona, se necesita ahora un enfoque iterativo, ágil (el ritmo del cambio en el mundo digital es [muy] rápido), automatizado, basado en los resultados y orientado a la experiencia del cliente. La transformación no es ensamblar cosas o combinar soluciones de las plataformas empresariales existentes. Es cuestionar cómo funciona la estructura y lo que se necesita para hacerlo mejor, no sólo reunir todo lo existente –incluyendo lo legacy- de formas diferentes –o “innovadoras”.

Así, es vital: la colaboración interna; la creación de procesos holísticos y no fragmentados[20] que apoyen la visión, no sólo la propuesta de actividades o metas; la creación de equipos multifuncionales que integren diversas funciones en el negocio, conformados por el personal correcto y adecuado para ejecutar la estrategia[21], competente, bien entrenado y capacitado, con la mentoría apropiada, o los proyectos fallarán; el desarrollo de incentivos para compartir por una entrega –final- exitosa; y cuidar de no subestimar necesidades o recursos y capacidades.

Para crear impulso, los equipos multifuncionales necesitan un apoyo visible de la alta dirección, un mandato claro para hacer las cosas con el empoderamiento oportuno y apropiado, suficientes recursos para construir un programa de trabajo donde las inversiones deberían estar ligadas al progreso y no a ciclos presupuestales fijos, y responsabilidad por las ganancias y pérdidas y rendición de cuentas.

Debemos tener presente que deberemos eliminar barreras y contar con una estrategia de visión transformadora, que nuestra cultura debe tender a ser integrada e innovadora, con un talento humano realmente comprometido que sigue un liderazgo con buenas habilidades digitales.

[1]      Fuente: http://www.mckinsey.com/business-functions/mckinsey-recovery-and-transformation-services/our-insights/transformation-with-a-capital-t; disponible en dic/2016

[2]      Fuente: https://www.marketingweek.com/2016/04/14/what-does-digital-transformation-really-mean/; disponible en dic/2016

[3]      Fuente: https://solutions.forrester.com/consulting/digital-business/; disponible en dic/2016

[4]      Fuente: https://enterprisersproject.com/what-is-digital-transformation; disponible en dic/2016

[5]      Fuente: http://blogs.forrester.com/nigel_fenwick/15-12-08-the_state_of_digital_business_2016_to_2020; disponible en dic/2016

[6]      Fuente: http://www.pwc.com/gx/en/advisory-services/digital-iq-survey-2015/campaign-site/digital-iq-survey-2015.pdf; disponible en dic/2016

[7]      Fuente: http://www.altimetergroup.com/pdf/reports/Six-Stages-of-Digital-Transformation-Altimeter.pdf; disponible en dic/2016

[8]      Fuente: http://www.businesswire.com/news/home/20151104005180/en/; disponible en dic/2016

[9]      Fuente: http://sloanreview.mit.edu/article/the-advantages-of-digital-maturity/; disponible en dic/2016

[10]    Fuente: https://dupress.deloitte.com/content/dam/dup-us-en/articles/digital-transformation-strategy-digitally-mature/15-MIT-DD-Strategy_small.pdf; disponible en dic/2016

[11]    Fuente: http://www.theagileelephant.com/digital-transformation-diagnostic/; disponible en dic/2016

[12]    Fuente: http://www.12manage.com/methods_7S_es.html; disponible en dic/2016

[13]    Fuente: http://www.theagileelephant.com/what-is-digital-transformation/; disponible en dic/2016

[14]    Fuente: http://sloanreview.mit.edu/article/the-nine-elements-of-digital-transformation/; disponible en dic/2016

[15]    Fuente: http://www.gartner.com/newsroom/id/3119717; disponible en dic/2016

[16]    Fuente: http://www.centroschumpeter.org/2015/05/la-innovacion-proceso-destruccion-creativa/; disponible en dic/2016

[17]    Fuente: http://www.mckinsey.com/business-functions/organization/our-insights/nine-questions-to-help-you-get-your-digital-transformation-right; disponible en dic/2016

[18]    Fuente: http://www.i-scoop.eu/digital-transformation/#Digital_transformation_and_the_customer_experience; disponible en dic/2016

[19]    Fuente: http://www.marketingguerrilla.es/que-es-el-customer-lifetime-value/; disponible en dic/2016

[20]    Fuente: http://www.cmswire.com/digital-experience/7-reasons-your-digital-transformation-project-may-fail/; disponible en dic/2016

[21]    Fuente: https://cloudfabrix.com/blog/digital-transformation/why-most-of-the-digital-transformation-projects-are-failing/; disponible en dic/2016

Autoservicio de TI

Desplegar tecnología para lograr que los usuarios de ésta se ayuden cuando tienen dificultades con la tecnología (sí, más tecnología para la tecnología) es algo que por mucho tiempo se ha tratado –y en algunos casos esta “innovación” ha funcionado y en otros no; bueno, siempre hay espacio para mejorar.

Los medios de acceso son variados. Existen versiones de respuesta humana o incluso robótica. Las interfaces son cada vez más útiles y usables. Sistemas de información y flujos de trabajo unos más integrados –y útiles- que otros. Actividades unas mejor implementadas que otras, como emisión y renovación de la identificación del usuario, entrenamiento, disponibilidad de opciones tipo push-pull para instalaciones o actualizaciones, ejecución de políticas de retención, solicitudes variadas (provisión de recursos, programación de atenciones, consultas sobre funcionalidad u operación, requerimientos de reparación, de información), entre otras[1]. Todos gozan de una interesante y mayor agilidad, los que entregan (TI tradicionalmente), y los que reciben (siempre el usuario). La experiencia de usuario está garantizada –depende del usuario calificarla.

fig1

Empoderar a los consumidores (usuarios y clientes) de servicios especializados para que ellos mismos se auto atiendan cuando tienen necesidades relacionadas con la tecnología de la información está muy de moda hoy en día[2].

Los usuarios finales obtienen las herramientas que necesitan para maximizar la productividad, tienen acceso a una vasta base de conocimiento[3] –y hasta a información a la que antes no tenían acceso (y no hablo de seguridad sino de alcance, disponibilidad, re-utilización porque esta iniciativa depende de la calidad y cantidad de información disponible y las facilidades disponibles para accederla[4] y generarla, incluso por comunidades de usuarios[5], y las medidas adoptadas para retener su control), y los departamentos de TI reducen la tensión cotidiana de las llamadas que llegan al servicio de atención al cliente[6].

Interesante. Se reducen costos al pasar del “modo bombero” a un estado de eficiencia y efectividad, y se re-enfoca la mesa de servicio a incrementar la satisfacción del cliente o del usuario.

Sí, nada nuevo hasta aquí. Pero, Gartner[7] nos alerta de las generalidades en que hemos incurrido antes, lo cual nos fuerza a sincerar los resultados frente a las expectativas de esta innovación –y preparar un buen caso de negocio primero.

  • El autoservicio de TI reduce costos en el soporte nivel 1 principalmente con relación a las solicitudes varias que ya comentamos. Algunas cosas todavía requerirán una llamada al servicio de TI o la asistencia de un técnico de soporte. Es una mezcla cuyo balance debe ser cuidadosamente considerado con respecto al valor esperado, con el objetivo de no incurrir en gastos innecesarios –aunque suene trillado esto último.
  • El autoservicio de TI requiere cuidado y actualización constante; no es una inversión que se realiza una sola vez y nos olvidamos luego. Es un continuo asegurar que el servicio lo seguimos entregando ‑como área de TI- como fue comprometido, y nuestro “consumidor” lo sigue recibiendo –su apreciación del valor- de forma oportuna, consistente y constante. El conocimiento, hemos mencionado, juega un papel vital y como tal debe ser gestionado apropiadamente para mantener su vigencia y utilidad.
  • Los usuarios finales acudirán a los autoservicios sólo si no tienen alternativa, lo cual dependerá de la estrategia que implemente la organización para su “adopción”, ya que la inclinación a su aceptación potencialmente será variada –tanto como la cultura organizacional, la mentalidad de los usuarios, la brecha generacional, así como los plazos límite que se establezcan.
  • Para una implementación exitosa del autoservicio de TI se requiere de requisitos previos que lo complementen, como un conjunto correctamente seleccionado de herramientas y procesos, adecuados, probados, afinados, y mantenidos, por personas con roles y competencias técnicas apropiadas, que apoyen, por ejemplo: la automatización de las actividades antes enumeradas, entre otras; y a los usuarios en las decisiones que deben tomar y en las tareas que deben realizar. Si se implementa adecuadamente, el autoservicio puede mejorar la satisfacción del cliente, proporcionar análisis de tendencias de incidentes, identificar oportunidades de capacitación, permitir ejecutar escenarios del tipo “que pasa si” para determinar a dónde llegarán las finanzas de la compañía para el trimestre, y consolidar el conocimiento que existe actualmente en los silos en toda la organización de soporte. La retroalimentación obtenida de un piloto o varios] es atractiva –y útil, para identificar la diversidad de información que sea requerida y permitir flexibilidad y agilidad en satisfacerla.
  • Así es, no dejemos de lado la utilidad, usabilidad, garantía, no sólo de los servicios entregados, con base en procesos gestionados y sujetos a una mejora continua, sino también de los medios utilizados para su entrega, como la interface de usuario utilizada –portal bien diseñado, amigable e intuitivo por supuesto, con el que sea fácil pedir ayuda.

Como siempre, una buena venta del valor del servicio ayudará a que los usuarios lo adopten voluntariamente (menor rechazo inicial; servicios conscientes del contexto que conocen su rol, ubicación y equipo[8]; adopción más rápida; disponibilidad de diferentes medios de contacto; apoyo a las aplicaciones actualmente en uso –aunque no hayan sido provistas por el departamento de TI; naturalidad, facilidad y flexibilidad en el procesamiento de solicitudes; compromiso consciente; finalmente interiorización), buscar qué necesitan hacer, qué quisieran hacer y no pueden –aún, qué les ha funcionado, qué les molesta, y otros posibles aspectos a considerar[9] -una mejora continua de funcionalidad y alcances, promocionar lo realizado, buscando cada vez una mayor aceptación. Identificar los temas correctos que ayudarán a los usuarios a ayudarse a sí mismos, toma tiempo y esfuerzo, no olvidemos considerar el costo total de propiedad de la solución integral.

[1]        Fuente: http://www.techrepublic.com/blog/10-things/10-ways-it-can-use-self-service/; disponible en dic/2016

[2]        Fuente: http://www.computerworld.com/article/2500959/enterprise-applications/self-service-it.html; disponible en dic/2016

[3]        Fuente: http://www.servicenow.com/products/express/it-self-service-portal-for-smb.html; disponible en dic/2016

[4]        Fuente: http://whatis.techtarget.com/definition/customer-self-service-CSS; disponible en dic/2016

[5]       Fuente: https://www.atlassian.com/it-unplugged/best-practices-and-trends/technologies-for-self-service-success; disponible en dic/2016

[6]        Fuente: http://www.axiossystems.com/solutions/end-user-self-service; disponible en dic/2016

[7]        Fuente: http://www.gartner.com/newsroom/id/1426813; disponible en dic/2016

[8]        Fuente: http://www.bmc.com/it-solutions/it-self-service.html; disponible en dic/2016

[9]        Fuente: http://www.informationweek.com/strategic-cio/team-building-and-staffing/7-ways-to-avoid-self-service-it-pitfalls/a/d-id/1297292; disponible en dic/2016

Más sobre el marco de la computación en nube -cloudcomputing -Parte 1

Sabemos que cuando las organizaciones se ven impulsadas a invertir se preguntan primero ¿cuáles son los objetivos de negocio que la organización espera alcanzar?, ¿cómo encajan estos objetivos dentro de la estrategia global de la organización?

Lo anterior funciona bien para tecnología convencional [claro, si queremos mantener la estadística de que días después de que algo entra en funcionamiento, ya está desactualizado, aparecen nuevas soluciones, nuevos parches, nuevas actualizaciones y así, como gerentes de TI, sólo nos mantenemos persiguiendo la curva de valor todo el tiempo –no muy buen porvenir ¿verdad?] pero, en cuanto a la nube, ¿sabemos si nuestra estrategia de negocio está lista para la nube?[1] –claro, y todas las demás preguntas.

¿Nos hemos preguntado si estamos pensando en la nube para ahorrar o para crecer, por un aspecto táctico o por una solución expresa y personalizada, está la infraestructura “completamente” o “en gran medida” optimizada para la estrategia de [nuestro] negocio? ¿Hemos definido los criterios para evaluar lo anterior? ¿No? bueno, deberíamos. Tengamos presente también que cuando existe una relación con uno o más proveedores externos, la transición a la nube [o de la nube] suele complicarse.

Sería bueno encontrar maneras en que las tecnologías de nube se ajusten a las necesidades y capacidades únicas de su organización [sincerando -alineando- la infraestructura de TI con los requerimientos del negocio y asegurando que la estrategia en nube evoluciona en consonancia]. Así, conviene adoptar la tecnología en nube con la misma seriedad que se aplica a los mecanismos de despliegue de TI más tradicionales. Atención, la madurez en la nube no significa abandonar las nubes privadas, sino el uso de la herramienta adecuada para la tarea y, en última instancia, el alineamiento de la estrategia en infraestructura y la gobernanza.

No olvidemos a los “nativos digitales” y su continua ansia por la nueva y menor tecnología que puedan comprar -¿alguien ha explotado todo lo que esta nueva tecnología puede hacer? ¿Recuerdan cuando La gente estaba acostumbrada a tener una mejor tecnología en el trabajo de la que tenía en casa [y estaban menos propensos a cuestionar el hecho]? Claro, BYOD –flexibilidad, agilidad, adaptabilidad, rendimiento, escalabilidad, rapidez[2], libertad… fomentando una cultura que hace uso seguro de la tecnología digital[3] [pero asegúrese de que la seguridad, la privacidad y el cumplimiento legal se abordan desde el principio –no olvide desarrollar las estructuras de gobierno exigidas por la nube, y adaptar o remodelar los procesos de gobierno para implicar más a los líderes]. La leyenda urbana dice que para ampliar el uso de la nube con responsabilidad y cosechar sus beneficios, las empresas deben ser capaces de utilizar la nube de forma segura.

Preparémonos para invertir más tiempo y esfuerzo en evaluar un número creciente de proveedores de nube (IaaS, PaaS, SaaS, XaaS para el caso) y soluciones puntuales –ojo con las soluciones “llave en mano” ya sean propietarias (Amazon y Microsoft entre otras) o de código abierto[4] (OpenStack). El entorno se complica cuando se involucra a otros grupos de interés internos como responsables de la conformidad (la aceptación de la implantación y la migración podría ser complicada por lo que debemos asegurar el cumplimiento legal y normativo), y líderes de negocio –seguramente habrán dudas en cuanto a la seguridad de la información. En última instancia, todos debemos prepararnos para la transición. Acuerde los detalles con sus proveedores actuales –no se olvide de exigir garantías, y aproveche toda su experiencia –hasta puede obtener orientación estratégica, busquemos socios que estén preparados para mantener una relación de colaboración y aprendizaje constantes (sería ideal compartir ideas sobre mejoras en la tecnología y la plataforma –y hasta tener la posibilidad de influir de forma innovadora en la del proveedor).

Apuesto que creían que olvido al integrador. No es así. Debemos elegir un integrador, alguien que se haga cargo de la integración de los servicio de nube, ya sea un empleado o un consultor técnico de confianza[5]. Debemos asegurar que se orqueste adecuadamente nuestra red de [los mejores] proveedores –¿o considera sabio poner todos los huevos en la misma canasta?, sin olvidar el intercambio de datos y las diferencias entre los procesos de los distintos centros de datos. Como somos entendidos en la materia nos habremos dado cuenta que para garantizar el éxito de la adopción de la nube debemos establecer un plan de ruta para esta integración‑migración y que debemos gestionar este plan [apropiadamente] como un proyecto.

Además, en la vida diaria cosas malas suceden, y nos ocurrirán cuando y donde más nos afecte -¿recuerdan a Murphy? Las necesidades del negocio cambian y más vendedores aparecen (con ofertas más atractivas) o los actuales vendedores salen del mercado (local, lo que nos deja sin soporte apropiado, o simplemente quiebran y quedamos desamparados), a veces las relaciones de nube no duran (porque no obtuvimos del proveedor los servicios –funcionalidad y soporte- como nos ofreció, porque ¿la nube no estuvo a la altura de nuestras necesidades? –y no obtuvimos las ganancias financieras esperadas[6] [en parte quizá porque en primer lugar no estuvimos “preparados” para la nube], porque hubo pérdida de datos –improbable dicen algunos pero sin embargo posible, porque el proveedor está atrasado tecnológicamente, porque se impactó negativamente en alguno de los factores CID de la seguridad de la información, porque ocurrieron apagones de la nube y permanecen en la oscuridad la gravedad y el estado exacto de los trabajos de restauración[7] -y este oscurantismo medioeval no nos gusta, entre otros aspectos a considerar).

En fin, a veces tenemos que hacer un cambio, y a veces hay eventos fuera de nuestro control que lo hacen por nosotros; así, no podemos o logramos permanecer en un servicio que es “el más adecuado”. Bien pensado, tampoco queremos vernos “atados” a un proveedor. Cuando eso sucede, tener un plan [¿sería mejor considerar una estrategia de salida?] puede significar la diferencia entre un ligero contratiempo del cual la organización puede recuperarse rápidamente, o enfrentar caos, tiempo de inactividad y una interrupción importante para el negocio.

En otras palabras, la estrategia de salida de nube [“migración en reversa” o “uncloud”[8] o “de-cloud” si nos ponemos al día con la terminología –ajá, ¿cuántos hemos reconocido estos términos?] es la elaboración de un plan de acción para asegurar que cualesquiera sean los servicios de nube que apoyan las actividades actuales del negocio, estos [servicios de nube] se pueden reemplazar [se puede realizar la transición] sin una interrupción grave[9]. El objetivo es realizar la transición en el plazo más breve posible[10] así que, entre otras cosas, no olvidemos considerar herramientas, personal calificado, niveles de servicio acordados con terceros [¿nuestros clientes?], otras responsabilidades adquiridas, mapeo de dependencias, mapeo de aplicaciones con la plataforma tecnológica, las propias aplicaciones, pruebas.

Así, tengamos presente qué servicios en nube reemplazamos e igualmente importante, con qué servicios en nube los reemplazamos –las alternativas tecnológicas pueden ser hasta iguales, pero centrémonos en lo que el negocio requiere (seguramente hemos realizado o deberemos realizar un BIA para un BCP[11] por ejemplo); así también es importante el cómo estamos utilizando los [actuales] servicios en nube (costos, rendimiento, jugadores clave, características del servicio, tratamiento de datos, niveles de servicio, soporte, aspectos legales y de cumplimiento, gobierno, no olvidemos las necesidades de privacidad y trazabilidad[12], entre otros aspectos a considerar –¿ya mencioné los factores CID de la seguridad de la información?).

Un análisis de impacto en el negocio (BIA) es un proceso sistemático mediante el cual una organización reúne y analiza información sobre sus funciones esenciales [y sus prioridades] y procesos (aplicaciones, datos, redes, sistemas de información, instalaciones, etc.). Esta información se utiliza para determinar cómo se vería afectada la organización (impacto potencial y costos en casos de desastre/acontecimiento/suceso) si estas funciones y procesos fueron interrumpidos por un desastre[13]/acontecimiento/suceso. En otras palabras, es fundamental analizar cuál es la tolerancia de su negocio a la no disponibilidad de sus funciones críticas[14]. ITIL®[15] nos dice que el BIA define los requisitos de recuperación de los servicios de TI. Estos requisitos incluyen tiempos de recuperación objetivos, puntos de recuperación objetivos y los objetivos mínimos de nivel de servicio para cada servicio de TI.

En la actualidad garantizar la operación no es una opción. Los clientes, proveedores y accionistas esperan respuesta sin importar lo que suceda en el exterior [sin importar las circunstancias que se presenten en el ecosistema donde se desarrolla la organización, sea ésta del tamaño que sea, pública, privada o entidad gubernamental]. La continuidad del negocio (BC) describe los procesos y procedimientos que una organización pone en marcha para garantizar que las funciones esenciales puedan continuar durante y después de un desastre/acontecimiento/suceso –esto no sólo involucra a TI y su Plan de recuperación ante desastres o DRP (¿alguno lo tiene? Como procedimiento documentado[16] quiero decir). La Planificación de la Continuidad del Negocio (BCP) trata de evitar la interrupción de los servicios de misión crítica (seguramente más de una vez caeremos) y restablecer el pleno funcionamiento de la forma más rápida y fácil que sea posible[17] (lo importante es levantarnos, cada vez). Usualmente los procesos críticos de negocio mantienen una íntima interdependencia con la tecnología; así, no consideremos que esto es un gasto sino más bien una inversión.

No esperamos –o deseamos- que nuestra relación con el o los proveedores de nube se vea interrumpida o falle. Pero prestemos atención al refrán: “cuando el río suena es porque piedras trae”. Otro refrán dice más o menos así: “esperamos lo mejor preparándonos para lo peor” –o que Dios nos coja confesados.

[1]      Fuente: http://whitepapers.siliconweek.es/wp-content/uploads/2015/05/CIOs-Mapping-the-cloud-maturity-curve-The-fundamental-five.pdf, mayo/2015

[2]      Fuente: http://whitepapers.siliconweek.es/wp-content/uploads/2015/02/CIOs-Cloud-Bound.pdf, febrero/2015

[3]      Fuente: http://whitepapers.siliconweek.es/wp-content/uploads/2015/05/CIOs-Mapping-the-Cloud-Maturity-Curve.pdf, mayo/2015

[4]      Fuente: http://www.channelbiz.es/2014/09/25/openstack-un-repaso-esta-alternativa-cloud-en-codigo-abierto/, setiembre/2014

[5]      Término acuñado, a mi mejor entender, por Garcerán Rojas de PQC.es

[6]      Fuente: http://searchcloudprovider.techtarget.com/tip/How-to-uncloud-Best-practices-for-exiting-the-public-cloud, noviembre/2015

[7]      Fuente: http://cioperu.pe/articulo/17264/como-utilizar-openstack/, noviembre/2014

[8]      Fuente: http://searchcloudprovider.techtarget.com/definition/uncloud-de-cloud, setiembre/2015

[9]      Fuente: http://searchcloudsecurity.techtarget.com/tip/Create-a-cloud-exit-strategy-to-prepare-for-the-unknown?utm_medium=EM&asrc=EM_NLN_49188871&utm_campaign=20151028_Dridex%20banking%20Trojan,%20botnets%20wreaking%20havoc%20again%20despite%20DOJ%20takedown_oeckerson&utm_source=NLN&track=NL-1820&ad=903816&src=903816, octubre/2015

[10]    Fuente: http://blogs.gartner.com/kyle-hilgendorf/2013/09/18/cloud-exit-strategies-you-do-need-them/, setiembre/2013

[11]    Fuente: http://searchdisasterrecovery.techtarget.com/essentialguide/Essential-guide-to-business-continuity-and-disaster-recovery-plans, 2015

[12]    Fuente: http://www.bbb.org/blog/2013/08/6-steps-for-de-clouding-yourself/, agosto/2013

[13]    Fuente: http://searchsecurity.techtarget.com/feature/Conducting-an-effective-business-impact-analysis, febrero/2003

[14]    Fuente: http://searchdatacenter.techtarget.com/es/opinion/BCP-y-DRP-El-arte-de-levantar-un-negocio-caido, noviembre/2013

[15]    Fuente: http://wiki.servicenow.com/index.php?title=File:ITIL_2011_Spanish_%28Latin_American%29_Glossary_v1.0.pdf#gsc.tab=0, junio/2012

[16]    Fuente: http://iso9001calidad.com/procedimientos-documentados-exigidos-por-la-norma-151.html, 2013

[17]    Fuente: http://searchdatacenter.techtarget.com/es/definicion/Continuidad-de-negocios-BC, setiembre/2013

Seguridad de la información con la tendencia BYOD

El crecimiento y las innovaciones que brindan las redes sociales y las tecnologías de conectividad plantean una serie de oportunidades y riesgos para las empresas[1].

Bring Your Own Device (BYOD) es una tendencia cada vez más generalizada en la que las empresas permiten a los trabajadores llevar[2] [y utilizar –comprometiendo la seguridad de la información] sus dispositivos portátiles personales para llevar a cabo tareas del trabajo y conectarse a la red y recursos corporativos –la tecnología más avanzada aprovechable por la empresa pero sin los costos inherentes [¿qué tan cierto es esto y en qué grado?].

BYOD se requiere en algunos mercados verticales, como hospitales, escuelas, y algunas empresas manufactureras siguen exigiendo la movilidad y el uso que ofrecen estos dispositivos. ¿Su empresa requiere apoyar esta tendencia? ¿En dónde se requieren estos dispositivos? ¿Habrá que re-diseñar la red de datos?

Los usuarios adquieren dispositivos de su agrado y mantienen su status; ahorran los que permiten su uso –claro la empresa (menos costos en aparatos, licencias, renovaciones, seguros, entre otros –er, ahorros)[3]. En cualquier caso, su uso se incrementa:

BYOD

Todos ganan flexibilidad y movilidad; las empresas ganan además acceso remoto redefiniendo lo que significa “estar en la oficina”[4] [¿alguien dijo teletrabajo?] y personal más productivo [tal vez discutible esto último] pero, consideremos lo siguiente:

  • El control se complica:
    • Impacto en la confidencialidad-integridad-disponibilidad;
    • Re-evaluación de la clasificación de la información –y sus riesgos;
    • Los roles y autorizaciones;
    • Necesidad de incrementar recursos de red –para evitar degradación [¿qué consume más ancho de banda de comunicaciones, un Smartphone personal del cual ignoramos su configuración (aplicaciones instaladas) o una computadora propiedad de la empresa?];
    • Con BYOD, voz, vídeo, comunicaciones unificadas, y aplicaciones hambrientas de ancho de banda están siendo transportadas a través de la infraestructura inalámbrica, que probablemente no esté preparada para esta carga sin precedentes;
    • ¿Malware y rootkits? –claro que sí[5];
    • Necesidades adicionales/diferentes de protección Wi-Fi;
    • Control de tráfico;
    • Control de accesos;
    • Seguridad en la transmisión [¿VPN tal vez[6]?] y almacenamiento de los datos –cifrado de datos seguramente será una consideración de importancia;
    • ¿Problemas de identidad o filtración de información?;
    • Entre otros.
  • El entorno de trabajo se complica
    • Se debe reforzar el soporte técnico y mantenimiento de TI;
    • No olvidemos la gestión que sería requerida y los aspectos normativos y legales inherentes[7] [¿conocen –algunos seguramente recuerdan- términos como precedente jurídico?].
    • Entre otros.
  • Se vuelve menos confiable por la diversidad de alternativas tecnológicas, y su configuración[8].

Así, sería muy importante disponer de una solución Mobile Device Management (MDM) con la cual, entre otras funcionalidades se podría contar con[9]:

  • La instalación masiva de aplicaciones en los terminales conectados a la red
  • El control de las apps que pueden ser utilizadas permitiendo al personal de TI gestionar y bloquear tipos concretos de aplicaciones según categorías
  • El control de acceso de los dispositivos
  • La localización y el seguimiento de cualquier dispositivo
  • El bloqueo de funciones
  • La sincronización de archivos
  • El control de consumo telefónico y de datos
  • El borrado remoto de los datos de cualquier terminal
  • Y el establecimiento de una contraseña de bloqueo desde el servidor
  • Aplicación de políticas de DLP, cifrado y cumplimiento de normativas, mediante el bloqueo de dispositivos no cifrados o desbloqueados ilícitamente
  • Penalizaciones en caso de incumplimiento de roles[10]

La visibilidad lleva al control y el control lleva a la protección[11]. Así es, cada empresa tiene mucho que evaluar. Sobre todo porque el dispositivo NO le pertenece a la empresa así que hay MUCHAS limitaciones –pero el empleado debe ser consciente que para trabajar con sus propios dispositivos muchas veces debe renunciar a parte de su libertad y privacidad[12]. Entonces se debe establecer una política BYOD  para controlar su uso[13] la que debería tener en consideración lo siguiente:[14]

  • Personalización. Haga políticas específicas para casa caso sobre el uso y el acceso a la información por parte de los usuarios, puesto que cada uno de los trabajadores necesitará ciertas aplicaciones que quizá no le interesen a otros.
  • Restricción. La política de privacidad debe ser selectiva y restrictiva, ya no solo según el usuario, sino también según el tipo de datos a los que se tenga acceso [BYOD resulta atractivo porque las estrictas líneas de demarcación sobre lo que puede visitarse, descargarse y utilizarse en un dispositivo propiedad de la empresa se difuminan en un dispositivo propiedad del empleado, que incluye contenido tanto personal como profesional por diseño] –atenta contra el auto-servicio a que estaría acostumbrado el empleado.
  • Vincule las políticas y procesos de MDM con la estrategia general de administración y seguridad.

En adición a tener que implementar políticas de seguridad más estrictas –o “razonables” [cierto, ¿quién y cómo se definen? –no olvide crear la política antes de obtener la tecnología[15]], también se debe Invertir en sensibilización y capacitación de los usuarios. Los empleados deben ser entrenados en la importancia de adherirse a la política BYOD y los estragos que pueden ser causados por un fallo de seguridad. Una vez que la política BYOD está en su lugar y se comunica a los usuarios, debe haber una manera de monitorear y hacer cumplir la misma.

Tal vez sea conveniente analizar y sopesar si se debe desarrollar apps dedicadas –y seguras por supuesto- o continuar utilizando acceso web a los sistemas de información críticos. Recordemos no bajar la guardia –los ataques seguramente serán cada vez más selectivos. Si no tenemos madurez tecnológica para cumplir con las reglas y acuerdos establecidos para mantener la seguridad, poco se puede exigir [tal vez crear un perfil “de trabajo” y uno “personal”, para mantener separados apps y datos de cada uno podría ser una buena idea] -evitando proteger los datos corporativos con códigos de acceso personal[16].

No olvidemos nuestros procedimientos documentados [¿recuerdan las ISO, sobre todo la ISO9000?]. La auditoría es fundamental, para que sepamos cuándo se ha accedido a una aplicación, quién lo ha entrado, qué documentos ha utilizado, modificado, descargado, otros.

[1]      Fuente: http://www.welivesecurity.com/wp-content/uploads/2014/01/documento_guia_byod_W.pdf, enero/2014

[2]      Fuente: http://computerhoy.com/noticias/moviles/que-es-byod-ventajas-e-inconvenientes-7250, diciembre/2013

[3]      Fuente: http://www.isaca.org/chapters8/Montevideo/Events/Documents/presentacion%20-%20maximiliano%20alonzo%20-%20byod%20ventajas%20desventajas%20y%20consideraciones%20de%20seguridad.pdf, noviembre/2015

[4]      Fuente: https://www.cisco.com/web/about/ac79/docs/re/byod/BYOD_Horizons-Global_ES.pdf, 2012

[5]      Fuente: https://www.sophos.com/es-es/products/your-needs/technology-case-studies/byod.aspx, noviembre/2015

[6]      Fuente: http://blog.ontrackdatarecovery.es/6-tips-para-mejorar-la-seguridad-byod/, agosto/2014

[7]      Fuente: http://viewer.zmags.com/publication/60f900a3, noviembre/2015

[8]      Fuente: http://www.flukenetworks.com/expertise/topic/byod, noviembre/2015

[9]      Fuente: http://www.trendmicro.es/productos/mobile-security/, noviembre/2015

[10]    Fuente: http://www.ibm.com/developerworks/ssa/cloud/library/cl-cloudbasedBYOD/, mayo/2013

[11]    Fuente: http://media.kaspersky.com/sp/business-security/win-security-battle.pdf, 2014

[12]    Fuente: http://www.pymesyautonomos.com/tecnologia/politicas-de-fugas-de-datos-seguridad-y-byod-cuando-el-enemigo-esta-detras-del-teclado, diciembre/2014

[13]    Fuente: http://searchdatacenter.techtarget.com/es/consejo/Como-crear-una-politica-de-BYOD, enero/2014

[14]    Fuente: http://www.raona.com/es/Solutions/Template/164/C%C3%B3mo-establecer-una-buena-pol%C3%ADtica-de-seguridad-para-tu-estrategia-BYOD, 2013

[15]    Fuente: http://content.maas360.com/www/content/eb/maas360-ten_commandments_of_byod_bring-your-own-device.pdf, octubre/2011

[16]    Fuente: http://f6ce14d4647f05e937f4-4d6abce208e5e17c2085b466b98c2083.r3.cf1.rackcdn.com/tips-to-avoid-seven-deadly-sins-mobile-security-pdf-6-w-1851.pdf, julio/2015

CICLO DE VIDA DE UN SERVICIO DE TI

Ciclo de vida de un servicio de TI

Seminario dictado durante la Semana tecnológica de la Universidad Simón Bolívar -USB

SLA en el marco de la computación en nube -cloudcomputing

La mayoría de las transiciones a una solución de cloud computing implican un cambio de una solución gestionada técnicamente (“yo lo construyo, yo lo mantengo”) a una solución administrada por contrato (“alguien más está haciendo esto por mí, ¿cómo puedo asegurarme de que están haciendo lo que se supone deben hacer? “).

Este cambio requiere una mayor capacidad de negociación del contrato de TI para establecer los términos de la relación (“¿Qué obtengo?”) Y habilidades de gestión de proveedores para mantener la relación (“¿Cómo puedo asegurarme de que lo obtenga?”)[1]. Esto implica identificar primero los requerimientos del negocio y establecer los indicadores clave de rendimiento esperados[2]. No olvidemos que hablamos de un servicio –y lo necesitamos para proveer servicios.

Por un lado, Kristin Knapp, editor del sitio de SearchCloudComputing, nos recuerda que los acuerdos de nivel de servicio (SLA) establecen confianza; los usuarios quieren seguridad de que su proveedor le garantiza un cierto nivel de servicio.

Tenemos que ser capaces de articular nuestras expectativas cuando se está negociando el acuerdo con el proveedor –y no es sólo mirarlo a los ojos cuando buscamos una respuesta, ni conviene acelerar su proceso. Un SLA no es una solución de una sola parte[3] [sabemos que en todo SLA existen dos partes]. Una de las partes -el proveedor de servicio en la nube, por ejemplo- no debe imponer decisiones acerca de cómo deben hacerse las cosas, sobre todo cuando la otra parte -el cliente de servicios de nube, por ejemplo- tiene diferentes expectativas sobre cómo debería formularse el SLA. Existe un impacto tecnológico y legal, especialmente cuando buscamos utilizar una nube pública[4].

Ninguno de nosotros desea que un proveedor simplemente reconozca el problema –luego que nosotros como usuarios asentamos la reclamación correspondiente primero. Debe haber un vínculo con la cura – como un tiempo de respuesta de una media hora para los problemas de servicio de mayor gravedad.

También es importante entender lo que el SLA cubre en términos de lo que recibirás y cómo va a recibirlo si el proveedor incumple el acuerdo. Así, igual de importante, deseamos la seguridad de que nuestro proveedor deberá pagar (o reembolsar) si no se cumplen las garantías acordadas[5] -pero no sólo con crédito, que los usuarios en general podríamos aplicar a nuestra factura de nube o para la compra de otro servicio en la nube, ya que rara vez se compensa la pérdida financiera o de negocio que puede ocurrir después de una interrupción (o degradación) en el servicio.

De hecho, no [siempre] se trata de dinero, se trata de la capacidad de ofrecer un servicio. No es de extrañar que los precios de los servicios en nube bajen con el tiempo y así, la elección de un proveedor se va a centrar todo sobre la prestación del servicio y el mayor tiempo de actividad que ofrezca.

Por otro lado, los clientes deben estar a la altura, por sanidad. Y una de las mejores maneras de hacerlo es construir aplicaciones en la nube que son resistentes, tolerante a fallos y diseñadas específicamente para la nube. Y realmente se necesita diseñar contra fallos por cuanto los proveedores cuentan con [se apoyan en] esto para proporcionar sus servicios “diferenciados”. No olvidemos que ya existe la ISO/IEC 27017 aplicada a la seguridad en nube, y que la CSA está tras este punto.

Un SLA de nube debe incluir términos más granulares alrededor de la respuesta del proveedor y el tiempo de recuperación. En concreto, los SLA de nube deben incluir términos que abarcan el “ciclo de gestión de fallos” completo de un servicio en la nube, sugirió Jason Andersen de Stratus Technologies. Esto incluye cinco fases clave de fallo de un servicio en la nube:

  1. Darse cuenta de que hay un hecho/problema ocurrido
  2. Localizar el hecho/problema
  3. Aislar el hecho/problema
  4. Recuperación del hecho/problema
  5. Recuperación completa del hecho/problema

Muchos términos del SLA sólo hablan de la disponibilidad en nube en términos de un servicio que está “operativo” o “caído” –lo que hace atemorizante y confusa la tarea de establecer un SLA, y no tienen en cuenta los distintos niveles de desempeño que siempre existen entre ambos. ¿Cuánta degradación es requerida para que un servicio se considere ‘caído’? ¿Cuál es el tiempo de resolución ofrecido (el tiempo que tarda un proveedor de nube para resolver completamente un problema con su servicio)? En la granularidad de los términos utilizados está el asunto –el diablo está en los detalles (definiciones y terminología entre otros).

Por lo anterior, Tom Nolle de CIMI Corporation[6] nos sugiere establecer un SLA en nube como un pequeño proyecto.

Uno de los desafíos de establecer un SLA en la nube es que la experiencia entregada por una aplicación en nube depende de varios aspectos o zonas de servicio por lo que la primera tarea es desarrollar un mapa de entidades que muestre quién provee qué porción del servicio en nube y cómo esta porción transita entre estas entidades.

Por ejemplo, las comunicaciones empleadas, si son accesos locales o remotos, los dispositivos empleados, las cargas de trabajo exigidas, los flujos de trabajo generados –que son en última instancia la base de los SLA.

Para una buena gestión del SLA y decisiones de su política, es necesario medir el comportamiento de cada uno de los proveedores de las diferentes zonas que componen el servicio en nube. Podemos comenzar con mecanismos para medir el tiempo de respuesta y pasar de eso a las condiciones de medición en los puntos de frontera de estas diferentes zonas. Un buen inicio es medir en el punto de conexión del usuario. Para la observación de la zona frontera alguna forma de supervisión de tráfico o protocolo es difícil de superar.

Sin la consideración y herramientas adecuadas, incluso un buen SLA probablemente fallará porque no se sabrá que está siendo violado ni por qué. Recopile datos en un repositorio de forma natural. Esta recopilación de datos le permite ejecutar consultas para analizar el rendimiento y las condiciones en el tiempo y establecer líneas de base para un comportamiento normal, así como los umbrales de lo que se considera que son violaciones al SLA. La analítica de red puede ser una base sólida para basar las decisiones alrededor de los acuerdos de nivel de servicio de computación en nube.

Para que el SLA de computación en nube y los servicios que ofrece tengan éxito es fundamental tomar un enfoque organizado para el SLA y las decisiones que surgen de su cumplimiento.

Así que la pregunta es, entonces, ¿Qué estás haciendo para monitorear el servicio [de tu proveedor en nube] y qué estás haciendo para asegurarte de que estás [el servicio que ofreces está] disponible?

Dan Sullivan[7] nos recuerda que si bien no existe precisamente una plantilla [proporciono un ejemplito[8]], hay puntos que no debemos olvidar –aunque nos parezcan obvios ahora pueden escapársenos en el momento:

  • Suacuerdo de nivel deservicio en la nube(SLA) debe especificar los nivelesmínimos derendimiento paracada servicio, codificadocon parámetros específicos –insisto, debemos ser específicos, y no aceptar generalidades[9].
  • Tenga en cuenta losrequisitospara documentaruna interrupcióny el tiempo quetiene para presentaruna reclamación.
  • Esvital entenderlos procedimientos de documentaciónde interrupciónantes de usar cualquierservicio en la nube.
  • Sobre la transferencia de datos utilizando procedimientos establecidos y protocolos seguros –y que nuestros datos permanezcan siendo nuestros [o definir a priori la manera de recuperarlos].
  • Seguridad de los datos en la nube –lo que es una responsabilidad compartida: proveedor-usuario[10]; todos esperan que alguien [usted] sea responsable.
  • Gobierno de la nube -de probar procesos internos a comprobar el cumplimiento de su proveedor con las regulaciones.
  • Contratos firmados –locales e internacionales (buen viaje).
  • Tarifas y costos ocultos.
  • Dependencias con terceros.
  • Retención de datos.
  • Servicios de datos –controles de seguridad por ejemplo.
  • Versiones, versiones, versiones –de todo y para todo.
  • Licencias, licencias, licencias –de todo y para todo.
  • Estándares empleados –porque heredamos las certificaciones.
  • No olviden lo básico[11]:
    • Codifica losparámetros específicosy los nivelesmínimos requeridospara cada elementodel servicio [y busquemos utilizar las mejores prácticas que encontremos para que no olvidemos ninguno, ITIL® por ejemplo], así como los recursospor incumplimiento deesos requisitos.
    • Sobre la transferencia de datos utilizando procedimientos establecidos y protocolos seguros, afirmar la propiedad de nuestra institución de sus datos almacenados en el sistema del proveedor de servicios [y que nuestros datos permanezcan siendo nuestros], y especifica sus derechos para recuperarla [definiendo a priori la manera de recuperarlos].
    • Detalles dela infraestructura del sistemay las normasde seguridadque deben mantenersepor elproveedor de servicios, junto con sus derechospara auditarsu cumplimiento o al menos teneracceso a susinformes de auditoríaescritos porun tercero de confianza –de verdad, no es broma.
    • Especificasus derechos ycosto paraseguirydejar de utilizar el
  • Ni tampoco olvidar que debe existir un balance entre seguridad y riesgos[12] [redundancia, disponibilidad, continuidad, resiliencia, y otros términos relacionados], comprender la noción de niveles “aceptables” de riesgo[13], y los riesgos de firmar un contrato estándar[14] porque importa:
    • Tiempo de actividad / inactividad.
    • Periodo de tiempo de inactividad (inactividad recurrente en un periodo pre-establecido).
    • Rendimiento y tiempo de respuesta –niveles máximos de latencia aceptados, QoS, entre otros aspectos.
    • Tiempo de inactividad programado.
    • Tiempo de corrección de errores.
    • Infraestructura /

Para garantizar un modelo de responsabilidad compartida en nube -o un enfoque por el que tanto el proveedor de la nube y sus clientes son responsables de ciertos aspectos de la seguridad- las empresas deben definir claramente sus propias responsabilidades, junto con las del proveedor de la nube. Por tanto, debe establecerse una línea clara [que podría llegar a ser muy delgada] que indique cuál de las partes es responsable no sólo de ciertos aspectos de la seguridad de los datos, sino además de la seguridad de las aplicaciones, máquinas virtuales, interfaces, configuraciones de servicio y más en la nube. “La infraestructura de nube ofrece la capacidad de escalar una aplicación horizontalmente, pero sólo si la aplicación posee una arquitectura para aprovechar esa capacidad”, dijo Ed Featherston, Senior Enterprise Architect and Director en Collaborative Consulting. Si la aplicación no escala debido a un defecto de diseño, el proveedor puede seguir cumpliendo con los requisitos del SLA[15]. De ahí que convenga separar la nube de la aplicación; TI debe ser capaz de distinguir los problemas potenciales de infraestructura de problemas de la aplicación.

“Va a ser dependiente del contrato, pero está en nosotros como empresa, asegurar de que está muy claramente indicado en el contrato dónde está dicha línea”, dijo Peter Keenan, Director de Seguridad de la Información en Lazard, una firma de asesoría y gestión de activos financieros en Nueva York. “Creo que se va a realizar caso por caso y servicio por servicio”.

No olvide asegurarse de tener un seguimiento continuo del ecosistema de su proveedor porque las cosas cambian diariamente. Claro, es aconsejable utilizar herramientas especializadas e integradas lo mejor posible para nuestro ecosistema de nube.

De igual forma, cuanta más supervisión regulatoria enfrente tu empresa, más tienes que preocuparte por cuestiones de jurisdicción de datos. Consulta con tus propios auditores de gobierno, asegúrate de saber si existen regulaciones estatales o locales que podrían aplicarse a los datos almacenados en la nube, y asegúrate de que sabes dónde almacenará los datos tu proveedor de nube[16].

Probablemente si aplicamos la herramienta 6W-2H nos ayude a determinar cosas importantes como: estado, acceso, tiempo de respuesta, tiempo de caducación, versionamiento, fallo, entre otros. ¿Cuántos nueves deseamos de disponibilidad? ¿Quién es culpable de qué, cuándo y por qué?…

Sugiero al lector [si aún está interesado] revisar la exhaustiva información de la Comisión Europea sobre Acuerdos de Nivel de Servicio en Cloud Computing[17].

[1]      Fuente: http://er.educause.edu/articles/2010/6/if-its-in-the-cloud-get-it-on-paper-cloud-computing-contract-issues, junio/2010

[2]      Fuente: http://searchcloudcomputing.techtarget.com/tip/Defining-the-right-cloud-SLA-requirements-up-front, junio/2012

[3]      Fuente: http://www.ibm.com/developerworks/cloud/library/cl-slastandards/, enero/2013

[4]      Fuente: http://searchcloudcomputing.techtarget.com/tip/Embrace-these-cloud-service-level-agreement-best-practices, setiembre/2015

[5]     Fuente: http://searchcloudcomputing.techtarget.com/news/4500252585/IT-pros-crave-a-new-kind-of-cloud-SLA, agosto/2015

[6]     Fuente: http://searchcloudapplications.techtarget.com/tip/Avoid-the-cloud-computing-SLA-trap?utm_medium=EM&asrc=EM_NLN_48206904&utm_campaign=20151002_How%20will%20microservices%20impact%20the%20cloud?_fchurchville&utm_source=NLN&track=NL-1806&ad=903291&src=903291, setiembre/2015

[7]      Fuente: http://searchcloudcomputing.techtarget.com/answer/Sidestep-problems-be-your-own-cloud-SLA-watchdog, julio/2014

[8]      Fuente: http://clkrep.lacity.org/onlinecontracts/2009/C-116359_c_11-20-09.pdf, noviembre/2009

[9]      Fuente: http://searchcloudapplications.techtarget.com/answer/When-cloud-providers-fail-Recovering-from-an-SLA-violation, octubre/2013

[10]    Fuente: http://searchcloudcomputing.techtarget.com/news/4500256467/Cloud-security-requires-shared-responsibility-model, octubre/2015

[11]    Fuente: http://er.educause.edu/articles/2010/6/if-its-in-the-cloud-get-it-on-paper-cloud-computing-contract-issues, junio/2010

[12]    Fuente: http://lts.lehigh.edu/services/explanation/guide-evaluating-service-security-cloud-service-providers, 2015

[13]    Fuente: http://searchcloudcomputing.techtarget.com/tip/Cloud-data-security-outside-the-vacuum-Find-acceptable-levels-of-risk, noviembre/2013

[14]    Igual que Nota 1.

[15]    Igual que Nota 4.

[16]    Fuente: http://searchcloudcomputing.techtarget.com/tip/Dont-let-governance-methods-die-after-a-cloud-migration, enero/2014

[17]    Fuentes (entre otras):
https://ec.europa.eu/digital-agenda/en/cloud-select-industry-group-service-level-agreements
https://ec.europa.eu/digital-agenda/en/news/cloud-service-level-agreement-standardisation-guidelines
https://ec.europa.eu/digital-agenda/en/news/cloud-computing-service-level-agreements-exploitation-research-results
https://ec.europa.eu/digital-agenda/en/news/study-report-standards-terms-and-performances-criteria-service-level-agreements-cloud-computing , octubre/2015