Transformación digital -revisitado

El negocio digital representará un promedio del 36% de los ingresos totales de una empresa para 2020

En un artículo previo de nuestro blog tratamos este tema.

A estas alturas la definición parece haberse asentado.

En un artículo de Enterprisers Project, nos dicen que “La transformación digital es la integración de la tecnología digital en todas las áreas de una empresa, cambiando fundamentalmente la forma en que opera y brinda valor a los clientes. También es un cambio cultural que requiere que las organizaciones desafíen constantemente el statu quo, experimenten y se sientan cómodas con el fracaso”.

Suena bien, lo de integración, para la generación de valor.

Complicado, sin embargo, alcanzar el cambio cultural requerido y necesario [tal vez esto sea lo primero en lo que debamos concentrarnos].

¿Necesitamos un motivo?

Pero, antes que nada, deberíamos sustentar el motivo o la necesidad de realizar una transformación digital, estableciendo claramente los resultados que el negocio espera y cómo se alcanzarán, así como los criterios para verificar y validar estos resultados.

O, simplemente, tendremos más problemas que resultados.

Entre otros aspectos, son gravitantes para el éxito de una iniciativa de transformación digital, los siguientes:

A la acción

Así, si la necesita, no demore en tomar acción y, además de lo anteriormente señalado, es conveniente:

Recordemos

No esperar que los clientes lleguen a uno.

No negar la realidad [tenga en cuenta todas las dimensiones de la compañía].

Incluir a todos en la compañía.

No es solamente un ‘proyecto de TI’ -más.

Considere expertos en el tema.

26 errores en la gestión de servicios

El día a día

Sí, asegurar que los servicios estén operando es labor de todos los días.

El tema es cómo lo logramos.

Buscamos realizar esta titánica labor considerando la coyuntura, presupuestos [de seguridad, entre otros], recursos, capacidades, compromisos, niveles de servicio existentes, proveedores, la propia organización –su modelo de gestión, su cultura.

Sabemos que los recursos son tanto materiales como humanos, tangibles como intangibles, y que son escasos.

Es más, las cosas pueden no ir tan bien como deseamos.

Además, reconozcamos que durante nuestra gestión también cometemos errores o estamos sujetos a problemas o a fallas.

Veamos.

Durante toda gestión existen errores o fallas

Error 01: no contar con un caso [real] de negocio

No olvidemos que al negocio le interesa ganar dinero, y que está en el ADN de los gerentes el invertir sobre la base de un caso de negocio.

Así, es mejor orientar nuestras necesidades de inversión en infraestructura de TI sobre la base de un enfoque de negocios, no sobre aspectos técnicos de la inversión.

En adición, todo caso de negocio debe propiciar valor para el negocio; entonces, implica que TODO caso de negocio debe estar apoyado por el un ejecutivo que lidere/apueste/necesite la propuesta.

Error 02: no realizar [nosotros] el planeamiento estratégico

Complicado si realmente no conocemos la estrategia del negocio ¿cierto? ¿Nosotros debemos buscarla o es algo que nos la tienen que proporcionar? ¿La entendemos, en toda su extensión? ¿Participamos en su formulación?

Lo cierto es que la planificación estratégica de TI debe estar firmemente enraizada en el plan estratégico del negocio. El mejor plan de TI ya no es simplemente un resumen de la inversión financiera requerida o una lista de tecnologías para implementar. Más bien, es una evaluación de los cambios exigidos para lograr los objetivos del negocio.

Los entendidos sugieren no encargar a alguien que lo haga por nosotros porque, finalmente, el entregable dormirá en algún estante; tal vez esperando presupuesto [que tal vez no llegará]; tal vez porque era un mero cumplimiento; tal vez porque el contenido no es lo esperado y, más bien, atenta contra el statu quo.

Tampoco es buena idea tratar que nuestros colaboradores implementen algo de lo que no han sido partícipes, de lo que no se sienten [porque no han sido] parte, o que se comprometan a aquello que consideran responsabilidad de otros.

Seguramente existen muchos otros posibles tal vez, quizá, intenciones, obligaciones. Cada organización los identificará. Lo cierto es que el entregable [el planeamiento estratégico de TI] no se pone en práctica; o, en todo caso, [como es usual] no resulta como se esperaba.

Para evitar esto, Gartner aconseja crear un proceso “claro y realizable” para desarrollar el plan estratégico, utilizando cualquier plan existente o usado previamente como punto de partida, planear rápido, enfocándonos en el mediano plazo, definiendo los componentes esenciales, desarrollando métricas para el éxito [estableciendo indicadores de rendimiento clave basados en resultados], atando los principios rectores a la visión corporativa, haciendo coincidir la frecuencia de la planificación con la marcha del negocio.

Error 03: presupuesto escaso o inapropiado

El presupuesto de TI dice mucho sobre sus propietarios: si los ejecutivos tienen una hoja de ruta para el futuro y si están dispuestos a pagar por ella, si los líderes de la compañía valoran la innovación, o si aún ven la tecnología como una función detrás de bambalinas.

Todo se reduce a la cuestión de si la empresa desea crecer y prosperar o si permite que sus competidores la dejan atrás.

Consideremos nuestro presupuesto en comparación con otros [realmente] similares en el mercado, en la medida de lo posible; entender [razonadamente] si es mejor el CAPEX por sobre el OPEX [o al revés], garantizando siempre que cada alternativa elegida cumpla con las normas contables; trasladando el gasto a las líneas de negocios [¿ABC costing? ¿conocemos realmente el costo/consumo del servicio provisto por cada unidad de negocio?] de manera que éstas estarían más interesadas en que sus inversiones rediman los resultados de negocio comprometidos.

Necesitamos asignar fondos para el presente (sostenibilidad operativa) y futuro (sustentabilidad, innovación, transformación digital, modernización de la tecnología, re-entrenamiento, actualización de procesos), sin olvidar asignar fondos para arreglar [mantener] lo legado.

Error 04: promover al candidato equivocado

No olvidemos que un candidato no sólo debe calzar en el puesto, sino que también debe calzar con la filosofía de la organización.

Así, la organización tiene que definir con claridad qué está buscando en términos de habilidades, carácter y competencias.

No son buenas razones promover por recompensa, o para proporcionar una línea de carrera, o para sentirse como un buen gerente.

Debemos elegir de forma inteligente.

Error 05: aplicar metodología ágil a los sistemas centrales

Y, sobre todo, cuando creemos que aplican donde se requiere un fuerte y riguroso control de cambios.

Por ejemplo, en servicios netamente de TI como correo electrónico, telefonía, ERP, aplicaciones de oficina, entre otros.

Tenemos que establecer límites claros –los riesgos son muchos, y mayores en impacto. La agilidad [velocidad] para los sistemas del negocio; rigurosidad [prudencia] para los sistemas nucleares.

Se necesita un enfoque disciplinado. Pensemos en una empresa bimodal. Entendamos el propósito de DevOps.

Según Gartner, las organizaciones deberían embarcarse en una “destrucción creativa”: replantear la arquitectura, los procesos y la gente que se requieren en el ámbito de tecnología para enfrentar las cargas de trabajo de la siguiente generación, incluyendo el IoT.

Error 06: subestimar riesgos

Y hasta no identificarlos oportunamente o no dimensionar [mejor] su impacto.

Uno de los primeros aspectos a considerar en la implantación de la ISO27001/ISO27002 es el análisis de riesgos, y establecer su gestión.

Probablemente necesitemos ayuda. Reconozcamos nuestras fortalezas y debilidades, y actuemos en consecuencia.

Error 07: cautiverio –de proveedores (internos o externos)

Por ejemplo, sabemos que las relaciones con los proveedores, tanto internos como externos, pueden ser frágiles, que podríamos quedar cautivos de ellos (bajos precios, innumerables promesas, supuesta integración, transición), vernos impactados por sus errores o fallas, estar sujetos a sus agendas ocultas, o hasta afrontar problemas de corrupción y sus implicancias legales.

Claro, todas las áreas internas relacionadas deberían tener presente lo que se espera de ellas (OLA), y no olvidemos lo que se espera [mejor dicho, requiere] de los proveedores externos (UC) con relación a la entrega del servicio.

Debemos garantizar para nuestro cliente [o usuario] el valor del servicio provisto. Y esto es una labor de todos, así como la seguridad de la información.

Muchas veces blandimos y hasta nos escudamos en leyes o regulaciones, normas o políticas, para ‘cumplir’ con nuestras funciones. Pero ‘seguimos’ estas leyes, regulaciones, normas, o políticas, de forma ciega, buscando [algunas veces] realizar el menor esfuerzo.

Error 08: la solución es la nube –por la nube

Tal vez pensamos que la nube es una buena opción [y lo es, si planeamos las cosas bien].

Todos hemos escuchado sobre los modelos de nube y sus ventajas.

Pero si creemos que adoptar un modelo híbrido conlleva simplicidad porque pensamos que este modelo de nube lo podemos administrar como una extensión de nuestro centro de datos, bueno, pensemos nuevamente –y planifiquemos mejor, factores como costo, disponibilidad requerida, estabilidad, requerimientos de configuración, niveles de servicio, licencias de software.

Empecemos por realmente conocer nuestro ecosistema, y de qué pie cojeamos. Hagamos un análisis de brecha.

Recordemos que la nube no es para todos, y tampoco para todo.

Mantengamos nuestras opciones, evitemos depender [o ser cautivos] de un solo proveedor de nube.

Error 09: contrataciones inadecuadas

Se requiere un equipo para construir una empresa exitosa, pero solo se necesita un empleado incompetente con una mala actitud para derribar a todos y a todos.

Debemos buscar contratar el nivel de destreza y habilidad requeridos para que el servicio proporcione el valor que se espera de él.

Error 10: no ser asertivo

Y, decir no cuando debemos decir no, pero de forma positiva –postergando la respuesta en lo posible.

No es que bloqueemos la innovación en la empresa, o busquemos detener su crecimiento.

Démonos tiempo para evaluar la sensibilidad, el impacto, los riesgos.

Decir que sí con demasiada frecuencia hace que sea imposible mantener todo parchado y en cumplimiento; generamos desconfianza.

Error 11: pecar de controlista

Si TI no está en el circuito cuando alguien en marketing o en alguna otra unidad de negocio lanza alguna iniciativa de shadow IT, bueno, aceptemos y reconozcamos que TI perdió el control hace años  y no puede recuperarlo; pero, avancemos, capitalicemos.

TI sigue siendo relevante, pero solo si se adapta. No dejemos que se piense que TI es únicamente quien mantiene operando el correo electrónico, y no es gravitante [no aporta valor] para el negocio.

Consideremos una adecuada verificación o aprobación de los equipos de TI o seguridad frente a este tipo de iniciativas. El objetivo no es evitar que existan, sino facultar a los equipos que decidieron utilizar estos servicios a cumplir con los requisitos mínimos de protección de datos establecidos en y por la organización.

Error 12: propiciar el oscurantismo

No perdamos credibilidad; garanticémosla.

Las malas noticias nunca mejoran por sí mismas. Y cuanto antes la gente empiece a lidiar con eso, tenemos más oportunidad de recuperar el proyecto y retomar el camino –o, al menos, perder menos.

Busquemos crear oportunidades para hablar con el director financiero y otros líderes empresariales cuando no están en modo crisis.

Error 13: elección incorrecta del outsourcing

Podríamos considerar que la elección de un servicio tercerizado simplifica nuestra labor. Y, dependiendo de nuestra organización, posiblemente esta premisa es correcta; pero, para un verdadero éxito, debemos tener presente los siguientes consejos:

  • Al tomar un servicio de TI, tomemos el tiempo necesario para comprender completamente nuestro rol como cliente para una relación de aprovisionamiento exitosa, en lugar de culpar [siempre] al proveedor del servicio. Si hicimos bien nuestra tarea de búsqueda inicial de un proveedor idóneo, identifiquemos la causa raíz y evitemos perder tiempo en cambiar de proveedores.
  • Enfoquemos nuestros esfuerzos en identificar el problema [analizar la demanda y el BIA], para el que requerimos una solución [o herramienta], y cómo podemos solucionarlo, antes de buscar soluciones en el mercado a las que después deberemos adaptarnos. Esto es, la solución debe resolver nuestra necesidad; principalmente, y lo mejor posible, no olvidemos el principio del 80/20.
  • La innovación empieza y termina en casa, no en el proveedor –y sus soluciones; así, debemos construir un ambiente y cultura que fomente eso, pero dentro de nuestra organización.
  • No hay plantillas, ya que cada organización es diferente, tiene problemas diferentes, y los afronta de manera diferente. Las mejores prácticas de outsourcing requieren determinar el alcance, el marco financiero y el perfil de riesgo adecuados para su empresa y sus objetivos, objetivos y cultura.
  • Durante la contratación, el objetivo de la negociación debe ser garantizar la alineación con los requisitos de la organización y no poner al proveedor en la situación más apretada. Esto, finalmente, juega en contra de la organización.
  • No subestimar el factor humano (en toda la empresa). Debemos planear para el cambio requerido en un entorno subcontratado, que [seguramente] requerirá una amplia supervisión ya que [seguramente] será significativo. Es vital comunicarse de manera activa y honesta, atendiendo las inquietudes y necesidades específicas del grupo de interesados.
  • No desestimar la transición, incluyendo procesos, sistemas, niveles de servicio, volúmenes, contratos y excepciones, y planifiquemos explícitamente el proceso de transferencia de conocimiento.
  • Implantar un modelo y marco de gobierno robusto, que incluya el equipo de gestión de entrega de servicios, los interesados en el negocio, los ejecutivos y el equipo de gestión del proveedor.
  • Gestionar el SLA, no blandir el contrato.

Error 14: presionar el outsourcing

Expectativas poco realistas y falta de gobernanza a intereses desalineados y mala comunicación son, usualmente, causas por las que no se alcanzan los resultados esperados, pero no las únicas.

Aumentar el desgaste de los recursos de outsourcing nunca es una buena señal. Puede ocasionar una alta rotación del personal del proveedor, disidencia interna, cambios en el liderazgo, apatía en la innovación, corrupción del alcance, fallas en cumplir los SLA, métricas inalcanzables, costos crecientes.

Los cambios frecuentes a menudo indican que el cliente, el proveedor o ambos no han podido establecer procesos de trabajo efectivos.

Mantener los canales de comunicación abiertos y fomentar un ambiente de confianza con los proveedores actuales ayudará a garantizar que los clientes estén al tanto si hay alguna actividad que impactarían negativamente en los resultados del negocio.

Error 15: no cerrar la brecha de habilidades –¿o debilidades?

Las empresas deben tomar algunas decisiones difíciles sobre cómo llenar las necesidades de personal y qué debe hacerse, interna y externamente; especialmente en seguridad.

Surgen las preguntas de siempre, pero no limitadas a las siguientes: ¿qué se hará? ¿será necesario capitalizar sobre nuestro personal clave? ¿será necesario tercerizar? ¿quiénes son candidatos? ¿a quién elegimos? ¿por qué la elección? ¿cuándo necesitamos? ¿cómo se hará? ¿cómo lo hará? ¿con qué? ¿para cuándo lo necesitamos? ¿hasta cuándo es necesario? ¿cuáles son los riesgos de no hacerlo? ¿cuáles son los riesgos al hacerlo? ¿hemos definido/acotado el alcance real/necesario? ¿quién será el responsable de rendir cuentas? ¿quién será responsable de ejecutar? ¿contamos con los procesos necesarios y suficientes, vigentes, actualizados, entendidos, realmente implantados [no sólo implementados]? ¿están las normas correctamente planteadas y apoyan las políticas? ¿las políticas apoyan esta ‘iniciativa’?

Error 16: ‘ahorrar’ en las capacitaciones

Actualmente, la premisa burda, errada y antigua de que mantenerse al día con la tecnología es responsabilidad de cada empleado, no es más vigente que antes.

Creemos ser efectivos al buscar un especialista con mucha experiencia y muchas certificaciones, y pretender pagarle centavos.

El mundo de este siglo habla de retención del personal clave como un factor estratégico, ya que las habilidades de este personal son el diferenciador clave para las organizaciones.

Si bien este personal puede ‘disfrutar’ de su trabajo, el reentrenamiento es muy útil para mantenerlo de esa manera.

Esto es especialmente cierto si la tecnología, que sabemos, cambia constantemente, y lo que queremos es reducir la curva de aprendizaje, asegurar la entrega de valor (con los servicios), garantizar la estabilidad de la plataforma tecnológica, que se incremente el valor de vida de los clientes, alcanzar los resultados que el negocio espera –y para los que ha comprometido recursos y capacidades.

Los profesionales de TI calificados, capacitados y certificados son esenciales para que las inversiones en tecnología redunden en obtener los resultados económicos que el negocio se ha planteado.

Error 17: no caracterizar TI

Las empresas deben tomar algunas decisiones difíciles sobre cómo llenar las necesidades de personal y qué debe hacerse, interna y externamente; especialmente en seguridad.

Y podemos caracterizar la disyuntiva (opciones, alternativas, problemas) con herramientas básicas como 6W-2H, matriz RACI, técnica MoSCoW, FODA, entre otras.

Error 18: adquirir ‘soluciones’ antes de establecer requisitos

Cuanto mejores sean los procesos de involucramiento/compromiso y soporte, más eficiente y productivo será el negocio, incrementará la satisfacción, la resolución de incidentes en el primer contacto, reducción en costos de soporte (por ejemplo, transporte, si se utilizan herramientas de soporte remoto apropiadas).

Conviene establecer los procesos antes que buscar una solución en el mercado. Apliquemos la regla del 80/20, y utilicemos cuantas herramientas estén a nuestro alcance.

Error 19: no establecer los procesos adecuados para que los servicios sobrevivan los cambios organizacionales

Porque, usualmente, estamos sujetos a alguna agenda oculta, que busca sus propios intereses, mantener la zona de confort, el statu quo, el feudo, el control local; pero sin interesar los resultados que el negocio espera.

Es así importante que las organizaciones identifiquen las necesidades reales de servicios e implante las acciones correctivas concretas requeridas, incluso organizacionales, en favor del negocio.

Gobernanza, auditorías, controles efectivos, son aquí mandatorios.

Error 20: considerar la seguridad como un proyecto –un producto terminado

Un reciente estudio de seguridad de Forrester descubrió que el 82% de las organizaciones tienen problemas para identificar y proteger los dispositivos conectados a la red. Peor aún, la mayoría no tenía claro quién es responsable de administrar los dispositivos.

Creemos que estamos seguros tras implementar una determinada seguridad –y nos engañamos pensando que este sentido de seguridad permanecerá en inmutable.

Seguimos cometiendo los mismos errores. Ahí están las diferentes noticias que de tanto en tanto nos llegan sobre violaciones perpetradas, incluso a grandes empresas.

Error 21: no haber establecido un modelo de seguridad de la información en la organización

Un modelo de seguridad de la información nos dice que tengamos presente:

  • La seguridad de los datos: estando almacenados, al ser procesados, cuando son transmitidos.
  • Los pilares de la seguridad de la información: confidencialidad, integridad, disponibilidad.
  • Capacitación, procesos, políticas, y su correcta y oportuna implantación.

¿Hemos considerado todo esto en nuestra actual plataforma tecnológica, en nuestros actuales sistemas de información? ¿Lo estamos considerando en un futuro cercano? ¿Hemos establecido una línea de tiempo? Si es así, ¿están los recursos y capacidades necesarios, entendidos, aceptados, y comprometidos?

Error 22: ignorar consejos básicos de seguridad de la información

Si se desea mantener la seguridad de toda la información de la organización, se deberán considerar activamente mínimamente los siguientes consejos de seguridad:

Error 23: confiar únicamente en el hacking ético como norma de seguridad

En seguridad, hay hermanos, mucho que hacer.

Empezando por casa, primero es hacer nuestra tarea; es decir, identificar y provisionar la seguridad en profundidad y líneas de defensa necesarias.

  • Incorporar mecanismos de control de acceso suficientes y apropiados.
  • Asegurar la vigencia de los mecanismos de autenticación y autorización.
  • No depender únicamente de los cortafuegos.
  • Implantar mecanismos [incluyendo políticas, procesos y sus procedimientos] contra código malicioso (malware), phishing, y todo tipo de X-ware pernicioso para la seguridad –y productividad.

Error 24: no gestionar correctamente el cambio

El cambio es una constante, especialmente en la era digital, ya que las tecnologías y las formas de trabajo que evolucionan rápidamente transforman el lugar de trabajo; y no entender que se necesita procesos establecidos y consistentes para gestionar el cambio, es una fórmula para el fracaso.

Sí, el miedo a lo desconocido, en el paradigma del cambio, puede ser una fuerza poderosa y negativamente motivadora; esperemos por tanto, resistencia al cambio, pero también afrontémoslo y gestionémoslo.

Pero, la transformación, bien llevada a cabo, representa nuevas oportunidades de crecimiento y ventaja competitiva.

Error 25: mantener [y hasta insistir en] una arquitectura de TI incorrecta [o inadecuada]

¡Imposible! ¡eso no ocurre en nuestra empresa! ¡todo está controlado! Bueno, así nos podrían decir los entendidos en TI; pero, para los no iniciados, ¿cómo podríamos darnos cuenta? Porque existe una o más de las situaciones siguientes:

  • Reingreso manual de [los mismos] datos, conducente a su inconsistencia –pero que calificamos de verificación y/o validación.
  • Colecciones de soluciones puntuales -que enmascaramos como ‘personalizadas’.
  • Aplicaciones redundantes que no ofrecen nuevas funcionalidades para el negocio.
  • Datos redundantes, y además inconsistentes, al no mantener la sincronización de datos en múltiples bases de datos de forma correcta, lo que genera un esfuerzo desperdiciado en las actividades de conciliación.
  • Necesitamos [nosotros] ‘interfacear’ con varias aplicaciones para realizar nuestras funciones u obtener un entregable, con el consiguiente error humano.
  • Debemos alimentar un sistema con los datos de otro –una acción propensa a errores si esta tarea no se automatiza lo suficientemente bien.
  • Tenemos, incluso, una configuración de software o hardware [o más] que, aunque poco elegante, ineficiente, torpe o [hasta] parcheada, tiene éxito [aparente] al resolver un problema específico o realizar una tarea en particular –y le denominamos ‘solución alternativa’.
  • Mantener tecnología obsoleta, que hace más difícil la integración con nuevos sistemas y equipos.

Consideremos, además, que, cuantos más sistemas y bases de datos tengamos, más interfaces terminaremos construyendo y que, cuantas más interfaces tengamos, más frágiles serán nuestros sistemas y, consecuentemente, más difícil será darles mantenimiento.

Claro, podemos resolver este dilema de múltiples interfaces con un elegante sistema de integración de aplicaciones empresariales, o un bus de servicios, o alguna otra forma de middleware-más-metadatos que mantenga todo limpio.

Pero consideremos que esta [y, para todo efecto, cualquier] engañosa integración [aunque elegante] es tan frágil y difícil de mantener como el exceso de interfaces.

Aumenta, por supuesto, nuestra incapacidad para adaptar los sistemas a los requisitos comerciales nuevos y cambiantes.

Incluso, las ‘soluciones alternativas’ vuelven frágil nuestro sistema e incrementa el costo de mantenimiento con cada solución innecesaria, al igual que el tiempo de inactividad, el costo de la capacitación del personal y la complejidad de cada proyecto posterior.

Estas situaciones, en mayor o menor grado, agotan los recursos de la empresa, la apartan de su actividad primaria de creación de valor, ralentizan los procesos del negocio, aumentan los costos de capacitación porque requieren interfaces del sistema, y las plataformas que las sustenten y que deben ser compatibles entre sí.

Consideremos que las planificaciones de arquitectura de TI a largo plazo ya son cosa del pasado. Recordemos, debemos tener un plan que sea flexible (habiendo escuchado las necesidades de nuestros patrocinadores e interesados), y considerar que probaremos y fallaremos, pero debemos hacerlo rápido, para recuperarnos aún más rápido y con mínimo impacto negativo –sobre todo en el aspecto de la seguridad.

Error 26: fallar en nuestro liderazgo

Cierto, ya conocemos las frases [motivadoras]: “hacer más con menos”, “sí podemos”, “es coyuntural”, “saldremos adelante”, “quedamos los buenos”, “eliminamos la grasa”, entre otras.

Buscan esconder, tras presionar fuerte por alcanzar [muy] buenos resultados, que la moral del personal se impacta negativamente.

Por ejemplo, como líderes:

  • Fallamos en comunicar [si acaso lo hacemos] completa, apropiada y oportunamente cómo cada actividad que realizamos se relaciona con los objetivos y la estrategia del negocio.
  • Fallamos cuando entre nuestros objetivos no se encuentra el incluir capacitación y otras formas de desarrollar habilidades técnicas y / o comerciales, mínimamente al colaborador clave –se supone que los que quedan, son clave ¿verdad?
  • Fallamos si demoramos en proporcionar las herramientas en cantidad suficiente y con las características necesarias, si acaso lo hacemos.
  • Fallamos si no buscamos identificar, priorizar, y automatizar las tareas repetitivas.
  • Fallamos si no identificamos, desarrollamos e implantamos formas innovadoras para que el usuario [cliente] se auto-atienda –es decir, ahorrar tiempo para todos, justamente para hacer más.
  • Fallamos si continuamos seleccionando indicadores de rendimiento solamente importantes para TI y no para el negocio.
  • Fallamos cuando agotamos a nuestros colaboradores cada vez que insistimos en asignarles proyectos con poco tiempo de aviso, sin presupuesto y no previstos, con requisitos olvidados, sujetos a complicaciones imprevistas, mala gestión y errores humanos [como el código incorrecto] sin tener en cuenta [considerar] los que ya tienen en sus portafolios pendientes de entregar.
  • Fallamos si no propiciamos que nuestros colaboradores celebren las victorias rápidas –y, como gestores, además nos las apropiamos.
  • Fallamos en describir las contribuciones que cada uno de nuestros colaboradores puede hacer para entregar resultados hasta el siguiente nivel.
  • Fallamos cuando evitamos que cada colaborador reconozca el valor de los logros de los objetivos y cómo sus contribuciones afectan la realización de los beneficios esperados
  • Fallamos cuando insistimos en el micro control del colaborador –hostigando incluso. ¿Delegamos mal?
  • Fallamos al no considerar enfoques y métodos nuevos, y nos cegamos ante soluciones más simples que se alinean mejor con los procesos comerciales y son mucho más fáciles de implementar. ¿Ego?
  • Fallamos mientras sigamos considerando a nuestros colaboradores como recursos complementarios (Gestión 1.0) o sólo gestionamos procesos (Gestión 2.0), y no reconocemos la complejidad del entorno operativo actual y el poder de personas motivadas y motivadas para resolver problemas (Gestión 3.0).
  • Fallamos cuando pecamos de auto-suficientes, soberbia, o [incluso] negligencia, y no buscamos ayuda externa.
  • Fallamos cuando no entregamos el resultado esperado por el negocio. Podemos ser eficaces y hasta eficientes, pero si no somos efectivos [apreciación de nuestro cliente o usuario], fracasamos, lo que impacta negativamente nuestra credibilidad, imagen, reputación, ganancias o ingresos.

Y luego nos quejamos de alta rotación del personal, baja en el rendimiento, reducción de la calidad de los entregables, incremento de errores, deterioro de la credibilidad, entre otros factores negativos.

Y, para concluir

Busquemos un sentido de pertenencia, para lograr compromiso.

No olvidemos ser transparentes, tengamos una cultura de apertura, busquemos ser resilientes, mantengámonos abiertos al debate.

De lo contrario, las expectativas de los patrocinadores e interesados no se verán satisfechas; tampoco se alcanzarán los resultados que el negocio espera; menos entregaremos el valor que los usuarios y clientes esperan de los servicios que reciben.

50 principios y recomendaciones para tener éxito en implementar la seguridad de la información

Pongámonos en situación

Un principio es una idea fundamental [y/o ley] sobre la que se basa una teoría o a partir de la cual se puede formular un razonamiento.

Consideremos entonces los principios morales, como reflejo de nuestro comportamiento social, como la cultura y/o religión; y los principios éticos, que reflejan el comportamiento “adecuado” de personas y el uso de sus conocimientos específicos (que devienen de la ciencia) en áreas profesionales relevantes para la sociedad, como en las profesiones. Leamos este artículo con este contexto como base.

En un artículo previo, 16 habilidades de seguridad crítica que necesitamos, sugerimos de forma básica cómo empezamos a hacer algo a nuestro favor con respecto a la seguridad. De hecho, todo esto implica gestionar la seguridad de la información,(confidencialidad, integridad, disponibilidad, y sus relaciones con la privacidad, identificación y autenticación, no repudio, auditoría y responsabilidad), siempre apoyados en procesos y procedimientos de seguridad documentados, comprobados, y mantenidos.

Empecemos por lo básico –ya que, cuanto más cambian las cosas, más permanecen igual

  1. Implemente mecanismos para evitar el robo de nuestros activos físicos. Cadenas, candados, áreas [cerradas] restringidas y vigiladas, cámaras [infrarrojas], sensores de movimiento, sensores de consumo de energía [por encima o por debajo de umbrales pre establecidos como adecuados], entre otros, podrían ser útiles
  2. Así como un capitán conoce [perfectamente] su barco, así debemos conocer nuestra plataforma tecnológica. Consideremos responder preguntas importantes como qué necesito, dónde lo necesito, cuándo lo necesito, cómo lo necesito, cuánto necesito, cuánto costará, qué protejo, para qué protejo, a quién protejo, de qué protejo, durante cuánto tiempo protejo, quién debe proteger, quién debe asegurar que la protección sea efectiva, cuáles son los criterios y formas establecidas para verificar que la protección logra su cometido, cómo valido la continua necesidad de la protección, entre otros factores a considerar (proponga más, utilice su experiencia, su ingenio). Herramientas útiles podrían ser RACI, MoSCoW, 6W‑2H, SMART, KISS.
  3. Los sistemas operativos tienen fallas [no es raro –ni nuevo], o se actualizan [mejoran] –lo cual puede, potencialmente, ocasionar fallas. Parchar los sistemas operativos oportunamente es mandatorio, pero recordemos que los servicios actualmente en operación no deben verse alterados. Así, debemos considerar aspectos mínimos para la seguridad como: urgencia; exigencia; afectación; activo, vulnerabilidad; amenaza; riesgo; impacto; necesidad; ambiente de control; entre otros.
  4. Y con los sistemas operativos de las computadoras personales aparecieron los virus –que luego se extendieron a las computadoras de mayor nivel (llamados luego servidores) que están basados en tecnología similar. Luego se extendieron a otro tipo de dispositivos, con diferentes kernel.
  5. La protección luego comenzó a ampliarse a las herramientas, productos, o ‘servicios’ que utilizamos, como correo electrónico, sistemas de archivos, descargas desde Internet, entre otros.
  6. Además, la seguridad comenzó a combinarse [ampliando y complicando a la vez las cosas] con otras posibilidades de protección como firewall, anti‑phishing, anti‑keylogger, webcam, USB, entre otras.
  7. Respaldemos nuestros [los] datos, periódica y consistentemente. Esta actividad es un seguro (esperamos lo mejor), para cuando ocurra el evento que requiera los datos respaldados (preparándonos para lo peor).
  8. Reducimos el riesgo limitando el acceso (entregar los privilegios mínimos necesarios para realizar la tarea), acceso que debe estar vigente sólo durante el tiempo más breve necesario (luego del cual recuerde retirar los privilegios), y limitando los datos a los que se accede (reducir la superficie de ataque -compromiso), funciona de la mano con la prevención (evitando valores por defecto, ‘recomendaciones’ del fabricante o de empresas similares, implementando e implantando mecanismos para accesos, listas de control, autenticación, autorización, certificación, permisos, usuario y contraseña, MAC, DAC, RBAC, entre otros) y detección (análisis de logs, trazabilidad, herramientas apropiadas).
  9. Entrenamiento, capacitación, formación, educación, generar conciencia, fomentar una cultura positiva de seguridad. Nunca es suficiente, tampoco es una tarea que se realice sólo una vez. Se requiere constancia, perseverancia, continuidad, confirmación, conformidad, compromiso (la seguridad es tarea de todos), resultados, entre otros aspectos a considerar.
  10. Reduzcamos el riesgo de intrusos. Conocer quién se conecta a nuestra red desde el interior es bueno [usuarios autorizados], así como también desde el exterior (“¡bárbaros en la puerta!”).
  11. Permitimos entonces el acceso [utilizando mecanismos como firewall, VPN, IPS/IPS] sólo a aquellos [redes, usuarios] en quienes confiamos.
  12. Incrementemos la confiabilidad de los datos al validar su ingreso (restringir, rechazar y desinfectar los datos) a los sistemas de información (asegurar tipos, patrones y rangos válidos).

Ahora, incrementamos un poco nuestra preocupación por la seguridad

  1. Las medidas de seguridad apropiadas para una organización dependerán de sus circunstancias, sus objetivos institucionales, de entregar la calidad y valor que los interesados esperan, de proveer reportes de rendimiento con respecto a la seguridad conforme se ha establecido.
  2. Conviene entonces adoptar un enfoque basado en el riesgo para decidir qué nivel de seguridad se necesita: categorizar utilizando un sistema de información; seleccionar los controles de seguridad; implementar estos controles; valorar los controles; establecer las autorizaciones necesarias; monitorizar los resultados; y volver a empezar.
  3. Planifiquemos, establezcamos mecanismos, roles y responsabilidades, identifiquemos la tecnología necesaria, aseguremos que hagamos lo planeado.
  4. Monitoreo, control, supervisión, de las acciones planificadas (programadas y en ejecución, ya sean automatizadas o manuales) son temas evidentes que no pueden faltar –ni fallar.
  5. No olvidemos comprobar, asegurar los resultados, y de tomar la acción correctiva necesaria de forma oportuna (actualizar planes, procesos, procedimientos, formación, tecnología, proveedores, perfiles, otros).
  6. Implica identificar los activos de información (obviamente, esto incluye los datos), categorizarlos, tratarlos en consecuencia, analizar sus vulnerabilidades y amenazas, establecer los riesgos.
  7. No olvidemos resolver las brechas de seguridad de forma transparente –correctamente y rápido (reduciendo, por ejemplo, el tiempo entre detección y respuesta). La seguridad mediante el oscurantismo no es buena. De hecho, presuma mejor que sus secretos no son seguros.
  8. Ciertamente debemos saber quién se conecta a nuestra red, así como a qué redes nos conectamos. Necesitamos considerar [en el tiempo] la variada tecnología que podemos o debemos emplear –y gestionar. Es mandatorio gestionar la configuración interna y externa de nuestra plataforma tecnológica (la interrelación de los componentes mediante los que se entregan los servicios).
  9. Consideremos mecanismos adicionales para controlar [y asegurar] el acceso a nuestra plataforma tecnológica (HW, SW, software utilitario, motores de base de datos, sistemas de información), como separar los privilegios, jerarquizarlos, aislarlos.
  10. Diseñemos e implementos mecanismos de defensa en profundidad. Es una exigencia básica el cerrar las puertas traseras en nuestras redes -¿necesidad, cumplimiento normativo, regulatorio o legal, local o internacional? Tenemos entonces opciones como DLP, SIEM, UEM, entre otras. La tarea no tiene fin; así, debemos gestionar el cambio de forma continua.
  11. La cadena se rompe por el eslabón más débil. Es obvio que los ataques se dan contra los componentes que los hackers han identificado como menos seguros. Y no siempre es la tecnología el eslabón más débil; procesos, procedimientos, formación, proveedores, cultura organizacional, entre otros aspectos, son también de consideración.
  12. Podemos fallar, pero procuremos hacerlo de forma segura. Debemos planear para estos casos en que pueden/puedan ocurrir fallas. Esto implica gestionar la mejora continua. Lo que es evitable son los problemas de seguridad relacionados con la falla. Si la aplicación falla, aseguremos que los datos sensibles no queden sin protección –tras una falla, pasar a un modo seguro. El problema es que cuando muchos sistemas fallan de alguna manera, exhiben un comportamiento inseguro.
  13. No compartamos mecanismos de autenticación, a menos que confiemos en los usuarios de esos mecanismos. Aislamiento de objetos (cuyo acceso, individual y en cada momento, debe ser verificado por la autoridad necesaria para dicho acceso), independientemente de los rangos jerárquicos, y de los mecanismos utilizados para accederlos es una buena idea.
  14. Sin embargo, no es buena idea confiar demasiado. La confianza es transitiva –y eso puede ser un problema de seguridad. La confianza pasa por cinco niveles: valores compartidos, integridad, preocupación por otros, competencia (además carácter y comunicación, para un líder), confiabilidad/dependencia.

Siempre es bueno revisar otros aspectos –que usualmente pasamos por alto, damos por descontados o, peor, creemos que estamos en lo correcto

  1. La seguridad de la información se establece desde el diseño de los servicios que vamos a prestar y por ello es vital gestionar este diseño.
  2. Los principios de seguridad en la nube.
  3. Los principios de seguridad provistos por marcos de trabajo reconocidos internacionalmente.
  4. Los principios o fórmulas o recomendaciones de seguridad de los proveedores de equipos y/o de software.
  5. Establecer la necesidad de cifrar nuestros datos sensibles.
  6. Analizar el contenido de los archivos de registro (log) que estamos almacenando. Protejamos los log.
  7. Balancee la protección necesaria (¿sistemas críticos primero?) a implementar (revise sus recursos, analice sus capacidades) con su utilidad (no olvide considerar el valor percibido por los interesados de esta implementación).
  8. No olvide registrar los eventos –y proteger los registros, en cumplimiento legal. Ahora importan los exitosos tanto como los no exitosos. Con la potencia y capacidad actual de la tecnología, ya no son válidos argumentos del siglo pasado como lentitud, disco lleno, necesidad adicional de administración, costos no contemplados, capacitación insuficiente, entre otros.
  9. ¿Realizamos auditorías? Claro que son necesarias, en todos los niveles
  10. Debemos identificar la existencia de excepciones (para lo cual la empresa primero debe definir qué significa para ella una excepción) y, una vez identificadas, ¿cómo las manejamos?
  11. Ejecutemos pruebas frecuentes. Hay diferentes formas. Busquemos las formas y programemos. Recuerde, un hacker no es un criminal –al menos no siempre, a diferencia de un cracker –y no hablo de galleta, que comúnmente sí.
  12. No estamos solos así que, si tenemos problemas, busquemos ayuda.
  13. Adoptemos nuevas formas de trabajo, como LEAN, SCRUM, DEVOPS.
  14. Entendamos que el SHADOW IT, y otras formas que “atentan” nuestro statu quo, es una realidad y debemos aceptarlas y, más bien, buscar la manera de integrarlas. Posiblemente no nos hemos dado cuenta –o no queremos darnos cuenta- y estamos en etapa de transformación de una empresa bimodal0 a una bimodal 2.0.
  15. Promueva la privacidad de la información de identificación personal –ya sabemos, cuando está almacenada, en tránsito, o procesándose. La información de identificación personal no sensible puede ser fácilmente obtenida de registros públicos, guías telefónicas, directorios de empresas y sitios web; la sensible es, por ejemplo, información biométrica, información médica, información financiera con identificación personal, e identificadores únicos tales como números de pasaporte, DNI, AFP.

Claro, ¿y qué hay del [apropiado] gasto en seguridad? Seguro necesitamos presupuesto, pero, sugerimos realizar primero las siguientes acciones

  1. Empecemos por establecer las prioridades de seguridad –tenga en cuenta los objetivos de la empresa; concéntrese en las aplicaciones de misión crítica.
  2. Analicemos la cultura organizacional con respecto a la seguridad de la información –podría haber inconsistencias/incongruencias/contradicciones que conviene identificar con anticipación.
  3. No olvidemos que al elefante nos lo comemos por tajadas.
  4. ¿Podemos automatizar, hasta qué punto?
  5. Estandaricemos cuando y cuanto sea posible. Posiblemente requiramos simplificación y centralización.
  6. Establecemos un balance entre acciones reactivas y proactivas (fomentando un mayor número de proactivas al implementar acciones que reduzcan las reactivas).
  7. Haga pruebas de penetración internas –obtenga primero la autorización.
  8. Planifique escenarios para lo peor
  9. Establezca el costo para el negocio de cada hora sin servicio. Hable con la alta dirección en sus términos (dinero).

Conclusiones

El mantra de siempre: la seguridad de TI es un trabajo desafiante que requiere atención al detalle (establecer lo éticamente correcto), al mismo tiempo que exige un mayor nivel de conciencia (establecer lo moralmente correcto).

Busquemos, de ser posible, primero la mayor adopción – interiorización (sujeto, claro, a la cultura organizacional)- para que, tras la implementación subsiguiente (sujeta a menor resistencia), obtengamos los resultados comprometidos/esperados de la seguridad (que técnicamente hemos establecido como alcanzables).

ITIL®, COBIT®, PMBOK®, entre otros frameworks

Sabemos que para gestionar las TI existen diferentes framework o marcos. Están también los viejos conocidos como COBIT® y el PMBOK®.

Recordemos que un marco es una estructura real o conceptual destinada a servir como un soporte o guía para la construcción de algo que expande dicha estructura en algo útil. Es necesaria para evitar re-inventar la rueda (la tecnología, y su eficiencia) y enfocar esfuerzos (recursos, capacidades, presupuestos, entre otros) en las reglas del negocio. La necesidad de emplear un marco es variable, y hasta cierto punto. No olvidemos que hay que adoptar y adaptar las cosas a nuestra realidad.

Por ejemplo, ayer un exalumno estaba esperando rendir su examen de certificación en ITIL® Fundamentos, el cual aprobó, y me contó mientras esperaba, que recién con el curso que le di entendió todo lo que en su empresa existía desplegado referente a ITIL®.

Bueno, lo cierto es que ITIL® estaba desplegado, implantado, pero no estaba interiorizado, no había sido adoptado. Este mismo exalumno lo reconoció. Los usuarios internos no tienen conciencia de por qué hacen las cosas; simplemente las hacen -cumplen. Los que apoyan o administran los servicios, tampoco, ya que se preocupan por que sus ‘indicadores’ no arrojen resultados negativos. En general, la empresa no entiende lo que es una apropiada gestión de servicios –y este ex alumno me comenta que hay varios certificados en ITIL. Esto último es una mala propaganda y por ello muchas empresas no confían en las buenas prácticas de ITIL (no ahondaré si es la empresa la que ocasiona esto con su cultura o es producto de una adecuada aplicación). Los usuarios utilizan las herramientas principalmente para controlar tickets. Aparte de utilizarla mal, encima desconocen las verdaderas capacidades de la herramienta. Los nuevos usuarios no son capacitados; la capacitación utiliza el método Inca (de boca en boca); y otras situaciones que me enteré. Una pena, por la empresa y por sus clientes –mi opinión, ya que no importa cuán brillante es el producto o si hace mil cosas; si no estamos proporcionando el resultado que el usuario final espera (el valor del servicio que está pagando), estamos fracasando. Una noticia al respecto aquí (ojo, no es la empresa de la que hablo) que generan costos innecesarios de compensación y remediación, querellas judiciales, pago de moras, auditorías inopinadas, pérdida de beneficios, demandas judiciales, entre otros aspectos negativos. No es de extrañar saber de proyectos ‘de éxito reservado’, por asignación inadecuada o inoportuna de recursos, plazos excesivamente agresivos –algunas veces exigidos sin base o beneficio para el negocio, costos subestimados, requisitos olvidados –o mal identificados, complicaciones imprevistas –que no faltan, un mal gobiernos, y los [consabidos y omnipresentes] errores humanos como código defectuoso.

Lo anterior nos hace preguntarnos ¿para qué me servirá aplicar el marco tal o cual? Ojo, aplicar, no imponer. Resulta obvio revisar nuestra necesidad concreta y el enfoque de nuestra necesidad, alternativas –reales- de solución, compromiso con la adopción correctamente elegida, no mero cumplimiento –o moda.

Recordemos que hay una herramienta correcta para cada necesidad, la cual debe utilizarse en el momento preciso y por quien conoce cómo utilizarla –desde la primera vez.

Al igual que con cualquier proyecto, siempre se debe mantener las líneas de comunicación abierta entre las distintas partes, medir y monitorear el progreso de la implementación y buscar ayuda externa si es necesario.

Algunas ‘mejores prácticas’ de TI para el fracaso –y algunas ‘mejores prácticas’ para evitarlo

Así es, una mejor práctica no es una receta de cocina. La preparación que hagamos de un ‘platillo’ y su resultado depende de muchos factores referidos a las herramientas, nosotros mismos como çocineros’, de los ‘comensales’ y su entorno.

Una real mejor práctica es considerar la preparación del ‘platillo’ para garantizar su resultado. Así, intervienen el ecosistema tecnológico en operación –moderno, vigente, legacy, integrado, interconectado- plataforma tecnológica e infraestructura de soporte, la cantidad necesaria de especialistas con el perfil apropiado, la experiencia, competencias (conocimientos, aptitudes, actitudes), orientación técnica o de gestión, requisitos del negocio, apetito de riesgo, intereses personales, los recursos para la producción del servicio (en adición al ecosistema tecnológico y el personal de apoyo, se necesita información, aplicaciones, recursos financieros) y capacidades para asegurar el rendimiento esperado (modelo de gestión, organización implementada, procesos establecidos, conocimiento gestionado), ambos activos de servicio necesarios para entregar el servicio con el valor esperado (con la utilidad y la garantía de rendimiento esperada), aparte claro del presupuesto, coyuntura socio-económica, entorno regulatorio y legal, mercado (cultura, exigencias, demografía, restricciones, gobierno, importación/exportación).

Estamos propensos a decir sí o no a todo y esto varia como buena práctica de acuerdo a la cultura y clima organizacional, buscando no quedar mal –aunque esto es lo que ocurre al no cumplir si accedemos o no entregar si era posible y alguien después nos lo hizo ver.

Una real buena práctica es explicar qué debe hacer para satisfacer las solicitudes, luego de realizar el análisis previo correspondiente. Lo que sigue será una conversación más que una excusa.

Tampoco es una buena práctica blandir que se cumple con el acuerdo de nivel de servicio (SLA) aceptado por el cliente, o con el nivel de servicio organizacional (OLA) requerido y comprometido por las áreas internas de la empresa, cuando es evidente la existencia de reclamaciones al respecto, y tratamos de minimizar el impacto haciendo bromas a costa de clientes, usuarios –o peor, de nuestro soporte- ‘inexperto’. Puede haber un contrato en ambos casos, pero no es bueno mantener las relaciones a distancia.

Una real buena práctica es identificar y enfrentar cambios –incluso sustanciales, investiguemos con transparencia. Recuerde que las relaciones requieren confianza, que la confianza no sucede a menos que reconozca a los colegas y clientes como personas reales que, si les gusta, trabajarán con usted para arreglar lo que falla y que el propósito de los contratos no es definir las relaciones -es definir lo que sucede cuando no hay confianza y algo va seriamente mal.

Tomamos como buena práctica poner nombre a nuestros proyectos, desde hace poco incluso, no siempre ha sido así. Pero esta buena práctica de la dirección de proyectos la utilizamos para nombrar el proyecto como una implementación de software (y nos preocupamos de que el producto software funcione) y no como los resultados esperados por el negocio (no establecemos los requisitos y criterios de validación necesarios para el entregable). El trabajo de TI se realiza cuando el software satisface los requisitos y cumple con las especificaciones –se ha hecho el aseguramiento y control de calidad apropiados al producto software, su verificación. Entonces sabemos quién es culpable de no alcanzar los resultados esperados por el negocio ¿verdad?

Una real buena práctica implica identificar al real sponsor del proyecto. Me refiero no al que ha sido nombrado (otra ‘buena práctica’), sino al que le interesa el éxito del proyecto porque su reputación está en juego y actúa en beneficio del negocio, y no asume el encargo sólo por intereses personales. Otra es designar correctamente a alguien realmente encargado de realizar las validaciones oportunas, correctas y apropiadas.

Insistir en un retorno de inversión de la plataforma actual al instaurar la buena práctica del gobierno de TI es también una perjudicial para los proyectos donde la tecnología puede ayudar a los departamentos de negocios a ofrecer mejores resultados más rápido, o para aquellos proyectos que buscan ayudar a impulsar la satisfacción del cliente.

No podemos discutir que estos proyectos son críticos, por lo que una real buena práctica es que se necesita establecer correctamente los casos de negocio oportunos, necesarios y apropiados, y la organización debe implementar los cambios que sean identificados con prontitud.

El aumento de la eficacia de la misión y la eficiencia operativa son beneficios clave que se pueden lograr con el cloud computing. Recordemos la definición del NIST. Pero aplicar una estrategia al respecto es otra cosa, considerando por supuesto la seguridad en la nube. Tomamos como buena práctica la mera adopción de una solución comercial enfocada en IaaS, PaaS o SaaS. Sí hay orientaciones al respecto, pero dependerá de cada organización su definición y el éxito de su implementación ya que se deberá mantener las evaluaciones tecnológicas y las inversiones alineadas con las estrategias empresariales. Es una buena práctica reutilizar el recurso humano (exigirle más, por decirlo amablemente), pero debemos considerar que, probablemente, se requiera una reorganización de la organización de TI para ofrecer mayor agilidad empresarial y soporte a iniciativas empresariales clave.

Es una real buena práctica recordar que el ser humano es adaptable pero no es una máquina multitarea y tiene dignidad. Entonces conviene planificar –una buena práctica que muchas veces olvidamos por las presiones del mercado. Una buena planificación es muy importante porque en ella establecemos roles, responsabilidades, alcance del modelo de despliegue y servicios a emplear o entregar, controles, aspectos de diseño y de operación (que seguramente será necesario afinar), cumplimiento regulatorio y legal, integración de tecnología legacy con la nueva, cargas de trabajo, procesos establecidos, exposición al riesgo o apetito de riesgo, sponsor (real), ámbito de influencia, gobernabilidad, plazos, presupuestos, valor real para el negocio considerando las inversiones con base en su estrategia de negocio digital, entre otros muchos factores a considerar.  Otra real buena práctica es que todos los proyectos que se lancen deberían estar totalmente equipados, con “personal completo”, lo que significa que el proyecto nunca esperará a que un miembro del equipo esté disponible para trabajar en él.

Una buena práctica es emplear métodos ágiles, pero el pretender combinarla con la premisa de abaratar costos ya no lo es. La combinación es factible pero complicada en su control y gestión, y hasta contraproducente en cuanto a resultados esperados. Esto sólo si hablamos de contar con recursos y capacidades internas al país (on-shore); sin hablar de los recursos y capacidades que podrían verse interesantes fuera del país (off-shore).

Una real buena práctica es realizar una apropiada planificación tras reconocer que están implicados diferentes aspectos, no sólo el costo del recurso humano con el perfil adecuado, sino los costos de la tecnología a emplear y los mecanismos de seguridad necesarios, así como aspectos de locación, demográficos, culturares, idiomáticos, entre muchos otros.

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.

Cómo la organización necesita capacitar a sus colaboradores en ciberseguridad

Las encuestas seguramente mostrarán que los trabajadores siguen violando las políticas de seguridad para seguir siendo productivos.

Las amenazas de información modernas vienen en muchas formas: de los hackers que buscan robar propiedad intelectual a los empleados inconscientes que no saben que están poniendo los datos en riesgo.

Cierto, los seres humanos somos el eslabón más débil –hasta que los hacemos un activo fuerte.

[Sin duda] la empresa capacita a sus colaboradores de acuerdo con su política de seguridad para inculcarles el papel crítico que desempeñan en mantener su lugar de trabajo seguro mediante una vigilancia más estrecha para proteger contraseñas personales y datos confidenciales, y en reconocer las amenazas (¿ransomware por ejemplo?).

Toquemos el punto de la capacitación y preguntémonos:

  • ¿cómo realizamos estas capacitaciones? Por ejemplo, en línea o presencial, otras formas
  • ¿en dónde realizamos estas capacitaciones? Por ejemplo, en un local especialmente acondicionado (interno o interno a la organización), en la oficina del jefe inmediato, en el módulo de trabajo del colaborador al cual reemplazará o con el cual trabajará, otros
  • ¿en qué oportunidades realizamos esta capacitación? Por ejemplo, el primer día/semana/mes de labores, tan pronto o luego que el colaborador ha ingresado, o antes que el colaborador se integre formalmente a la empresa, agrupamos los colaboradores ingresantes en un periodo determinado, una vez al año, por pedido expreso, por necesidad evidente [una re-capacitación por ‘afianzamiento’ tal vez], otras opciones
  • ¿cuál es el propósito de la capacitación? Por ejemplo, una inducción, la que esperamos no sea sólo de seguridad ocupacional, difundir la política institucional, difundir la política de seguridad, aclarar el acuerdo de confidencialidad que el colaborador firmará al ingresar a laborar y que le será recordado por el área competente al retirarse de la empresa, otros
  • ¿mantenemos un registro de las capacitaciones realizadas? Por ejemplo, en archivo texto, hoja de cálculo, archivos personales, base de datos, otros, y consideramos también las evaluaciones de entrada y de salida, tanto de colaboradores como de capacitadores
  • ¿cómo aseguramos la asistencia? Por ejemplo, por disposición normativa, coordinación con el jefe inmediato, obligación contractual, amenaza a la continuidad laboral por incumplimiento, otros
  • ¿cómo controlamos la asistencia y entrega/accedo al material correspondiente? Por ejemplo, identificación de la computadora desde donde realizamos la capacitación [dirección IP, nombre de máquina], identificación del usuario que ingresa al módulo en línea de capacitación, presencial con un supervisor, listado actualizado de participantes, otros
  • ¿mantenemos un historial de estas capacitaciones por cada colaborador? Por ejemplo, para emplearlas como insumo de la evaluación semestral o anual
  • ¿de qué manera aseguramos el resultado esperado –y continuo- de esta capacitación? Por ejemplo, evaluaciones inopinadas periódicas con registro de resultados en el archivo personal, resultados tangibles [objetivos] de labores realizadas registrados en el archivo personal, otros
  • ¿por qué realizamos estas capacitaciones? Por ejemplo, por mero cumplimiento normativo, porque así lo pidió el jefe [actual], o porque la empresa realmente ha interiorizado la necesidad, entre otros
  • Seguramente tenemos algunas otras inquietudes. Compártanlas por favor, en beneficio de todos.

Démonos cuenta [si aún no lo hemos hecho] de que la seguridad es un facilitador.

Crear una cultura de seguridad en una empresa puede ser complicado. En la organización la cultura implica una balanceada intersección entre personas y organización –es lo que hace únicas a las empresas, afecta la forma en que implementamos las cosas y lo que tiene sentido en el ecosistema de la organización.

En este ecosistema, los profesionales de la seguridad de la información debemos darnos cuenta que hemos evolucionado de siempre ser vistos como meramente tecnólogos, a gente de proceso, a ser verdaderamente un socio comercial y profesional de negocios -me incluyo ¿te incluyes?

En aras de afianzar esta cultura de ciberseguridad, por ejemplo, nada como ser transparente en qué estamos haciendo y cómo lo estamos haciendo los profesionales de la seguridad de la información, y explicarlo en el lenguaje del negocio -¿de qué manera lo haces tú?

Pero, también es obvio que la organización debe evolucionar, debe buscar un equilibrio entre proteger los datos y capacitar a los colaboradores para que sean productivos (no olvidemos la triada procesos-personas-tecnología), incorporando los altos ejecutivos del negocio en este esfuerzo de capacitación para que entiendan a cabalidad [y con esfuerzo y tiempo, también interioricen que no es sólo responsabilidad del departamento de TI] los requerimientos y necesidades de ciberseguridad [algo que ya no se puede ignorar].

La organización busca protegerse contra el mal comportamiento del usuario final, amenazas de día cero, sitios Web comprometidos y hacks entre equipos de escritorio y entre equipos de escritorio y servidores, seguramente empleará para esto alguna herramienta especializada (¿secure desktop as a serviceSDaaS?).

Bastante se ha hablado también que no es una cuestión de si vamos a ser atacados [o que vaya a violar nuestra seguridad], es una cuestión de cuándo esto ocurrirá, y que debemos estar preparados.

El problema seguramente es cómo lograr que tanto la organización como los colaboradores interioricen esta necesidad y objetivo –de manera continua porque, recordemos que la seguridad es un proceso, no un producto.

¿Cómo pueden las compañías asegurarse de que sus políticas y procesos de seguridad estén al día con las amenazas modernas? Una política de seguridad clara y bien entendida sería un inicio. Una sensibilización y formación [en contraposición (o complemento tal vez) a una capacitación] apropiadas, seguidas de las auditorias correspondientes, serian también aconsejables. El tipo de sensibilización [compromiso e interiorización posterior] que logremos en estos programas de formación es la clave. Enfrentamos entonces el cómo, cuándo, con qué, quién, para qué, formamos y hay un desafío en el contenido y orientación de la formación.

Como estado, es evidente que hay bastante más que hacer. Los esfuerzos de PCM-ONGEI podrían no ser suficientes y están lejos de ser completos.

En el ámbito educativo, algunas universidades contemplan carreras de ingeniería que incluyen cursos de ciberseguridad en su currículo, y otras ofrecen carreras especificas relacionadas con la seguridad informática; sin embargo, este interés en la seguridad de la información se centra aún –erróneamente- en carreras de ingeniería relacionadas con las tecnologías de la información.

Las certificaciones ayudan, pero, a pesar que hay un gran número de ellas, podrían no ser suficientes [en el tiempo] o apropiadas [orientación, alcance] para todo tipo de organización [deberemos tener en cuenta sus prioridades, objetivos y metas estratégicas, sus impulsores de valor].

Seis factores críticos para crear una mejor estrategia de seguridad de TI

¿Qué necesitamos para establecer una hoja de ruta funcional de la seguridad de las TI de la empresa?

Recordemos que un solo tipo y un solo nivel de seguridad de la información podría no ser suficiente para una determinada organización. ¿Qué modelo de defensa en profundidad adoptaría, de entre los varios que existen? Tampoco debemos olvidar la estrategia a seguir si ocurriera alguna brecha en esta seguridad de la información.

Pero, debemos empezar, y lo hacemos de la siguiente manera:

  1. Identificar, clasificar, y etiquetar los recursos, los activos de información, considerando su importancia –o implicancia en los procesos de la organización, ya sean estos recursos físicos o virtuales, tangibles o intangibles.

Debemos responder con certeza el por qué debo considerarlos.

¿Convendría que los mismos sistemas que se han puesto en marcha se actualicen automáticamente en una base de datos ad-hoc a medida que cambia el inventario de recursos?

Las organizaciones deben tener pleno conocimiento de lo que tienen, valorar lo que tienen y lo que no pueden permitirse perder, además de crear un plan integral para proteger estos activos críticos.

Tendríamos, entonces, que pensar en un conjunto automatizado de herramientas para rastrear y clasificar los recursos.

  1. Proteger el acceso a los recursos, tratarlos conforme a su clasificación y prioridad establecida, de acuerdo a su impacto en el negocio (las consecuencias).

Claro, tenemos que sincerar el cómo realizaremos la protección para lo cual seguramente necesitaremos realizar primero un análisis de brecha. ¿Hemos realizado nuestro FODA?

Consideremos las nuevas tendencias para crear valor de TI, e incluso de los usuarios al emplear la tecnología como shadow IT o BYOD.

Tendríamos, entonces, que establecer una línea base correcta y sincerada –de todo, sin olvidar o menospreciar los recursos y capacidades existentes, desde el punto de vista del valor que se espera del servicio de TI.

El intercambio de información –correcta, completa, contextual, oportuna, clara- se vuelve crítico.

  1. Detectar amenazas y ataques, considerando el triángulo procesospersonas-tecnología, identificando riesgos en las operaciones que es donde se provee el valor de un servicio.

Tendríamos, entonces, que entender y asegurar que todos en la organización tengan claro que la detección de amenazas (un sospechoso siguiéndote a tu casa –bueno, tal vez una amenaza algo más sofisticada, especializada, escalable -¿que afecte la privacidad?, ¿porque el enemigo está adentro?), detección de vulnerabilidades (una ventana abierta –situación que se advierte con un escaneo de vulnerabilidades [y no debemos remitirnos solamente al perímetro]), y detección de ataques (el sospechoso metiéndose a tu casa por la ventana abierta) son tres cosas distintas.

De hecho, es crucial el dominio del tema, la provisión de la tecnología apropiada, y hacer y dejar hacer.

¿Recordamos los honeypot? De repente ya hemos sido víctimas de un hacker y aún no lo sabemos.

  1. Responder a las amenazas y ataques, considerando que posiblemente requiramos apoyo externo o una mayor capacitación y experiencia internas.

¿Cuáles serían las estrategias que adoptaríamos?

Tendríamos, entonces, que tomar medidas proactivas sobre un riesgo identificado y preparar las reactivas (de acción inmediata ante la ocurrencia del evento) –evitando acciones bomberiles.

Las medidas proactivas deberían ser pensadas, planeadas, diseñadas, implementadas, probadas, afinadas, y con responsabilidad asignada, con recursos y capacidades presupuestados, que den cumplimiento a normas internas y/o legales, que busquen evitar deudas, multas, pagos no presupuestados, litigios, pérdida de confianza y clientes, daños a la reputación y pérdida de confianza de las partes interesadas, publicidad negativa y pérdida de activos, entre otros aspectos negativos.

Es decir, una verdadera proactividad en una empresa con alto nivel de madurez, que está preparada para el cambio.

Realizar lo importante para evitar [en lo posible] las emergencias –o, al menos, reducir su frecuencia o impacto.

Ciertamente el error humano sigue siendo una amenaza para la seguridad, pero si trabajamos la cultura organizacional seguramente podremos compensar algunos riesgos de seguridad y privacidad de la información empresarial –los internos a la organización, por lo menos, concientizar al usuario.

  1. Es claro entonces que la educación en ciberseguridad debe ser parte integral de la cultura del lugar de trabajo, es hacer que la ciberseguridad sea tarea de todos. Sabemos que esta educación en ciberseguridad no significa asistir a un [solo] curso o seminario –por único que sea en su género, significa hacer de la seguridad una iniciativa cultural colaborativa y continua.

Es ayudar a todos en la empresa a comprender que los ciber delincuentes representan una amenaza no sólo para la empresa, sino también para ellos y sus familias, también (filtración de datos personales, por ejemplo, y las posibles amenazas que esto conlleva).

Sin embargo, cuando ocurra una brecha de seguridad, evitemos actitudes incorrectas en un líder o equipo de infosec porque pueden resultar en una peor violación de privacidad / seguridad y en una afectación negativa a la moral y motivación en el entorno laboral –lo que, potencialmente, podría conducir a la aparición de más riesgos o a elevar la graduación de los existentes.

La importancia de tener una actitud positiva y fuerte de seguridad y privacidad es tal que tanto los líderes como los empleados deben ver la privacidad como un valor que desean experimentar, promover, proteger y formar.

  1. Mejorar la analítica (para una mejora continua de todo el proceso).

Tendríamos, entonces, que realizar una labor analítica de predicción, porque nos dice dónde reforzar la protección –un poco de inteligencia de negocio siempre ayuda. Lo que implica un estado de cambio constante en los servicios y su gestión, lo que implica además gestionar proyectos.

Todo lo anterior es una tarea realizada de forma periódica (¿una auditoría particular o integrada?) o por demanda del mercado (¿tal vez necesidad?), siempre en evolución (nuevos hallazgos de día-cero, ahora además con la IoT –agregamos complejidad a lo complicado), un espacio, una oportunidad para mejorar.

Sigamos el ciclo de Deming, de mejora continua.

Tengamos presente que hemos pasado de un modelo donde se hacía hacking por diversión o fama, a la ciberguerra propiamente dicha, con objetivos claros y concretos, como destrucción, negación de un servicio, destruir la imagen de una empresa, incluso de monetizar la información obtenida.

 

Cómo crear un plan contra violación de datos en 9 pasos

Cómo crear un plan contra violación de datos en 9 pasos

Primero tengamos presente que se pueden considerar varios escenarios posibles en un plan contra violación de datos.

Esto porque no podemos anticiparnos a todas las situaciones posibles en que un determinado hackeo se puede desarrollar, y aun así este plan debe ser flexible, como un planeamiento para la recuperación de desastres y planificación de continuidad de negocio (la colaboración en lugar del aislamiento) –y veremos que es muy parecido. Interesante, varios proyectos pueden salir de este esfuerzo.

De hecho, conviene realizar un análisis de los procesos de negocio y las necesidades de continuidad, sin olvidar las necesidades de seguridad de la información, algo que cada empresa debe emprender, y dependerán de los objetivos de la organización sobre el punto de recuperación (RPO) y el tiempo de recuperación (RTO).

Bueno, al grano –y con anticipación porque es importante, de modo que podamos reducir las urgencias o el riesgo durante las urgencias.

  1. Sabemos que debemos empezar con una evaluación de riesgos, para priorizar qué sistemas recuperar y restaurar primero (establecer los componentes esenciales –inventario de por medio del hardware necesario y del software requerido para restaurar la producción; los datos, su tipo y sensibilidad, almacenado/procesados/transportados haciendo uso de estos componentes) –porque ponernos a pensar durante la emergencia podría ser contraproducente. Conviene realizar un análisis de impacto sobre el negocio (BIA) para identificar los procesos críticos (con sus procedimientos por supuesto) y priorizarlos de acuerdo con su impacto en la organización.
  2. No olvidemos implementar controles preventivos (con sus procesos estandarizados, normalizados, documentados), como primer paso tras analizar las brechas, de seguridad de la información, y de recursos y capacidades existentes (financieros, organizacionales, de personal, competencias, experiencia, entre otros).
  3. Conviene establecer umbrales y adecuarlos a los niveles correspondientes de respuesta que hayamos establecido –o que podamos establecer, así como los criterios de evaluación correspondientes al tipo de datos que se verían comprometidos, con base en nuestros recursos y capacidades internos o los que podamos conseguir.
  4. Así como los médicos en la sala de urgencias seleccionan y clasifican a los pacientes para evaluar la prioridad de su atención de acuerdo con sus posibilidades de supervivencia y recursos disponibles, igual debemos realizarlo nosotros, determinando el alcance de ese impacto, cuáles son los sistemas más importantes (misión crítica) y datos (más importantes) y que, por lo tanto, necesitan atención en primer lugar, cómo aislar y proteger los datos (nivel de seguridad necesario para los datos y aplicaciones, ubicación), y cuánto tiempo se espera que dure la interrupción –antes de activar otros medios de continuidad.
  5. De hecho, debemos construir flexibilidad de modo que la empresa pueda responder de la manera que, coyunturalmente (no siempre contará con los recursos y capacidades suficientes o apropiados), le convenga (para no incurrir en problemas legales por incumplimiento con la ley de protección de datos personales, por ejemplo).
  6. Es muy importante establecer, difundir, y mantener vigente la matriz RACI correspondiente, y que ésta sea lo más granular posible, para asegurar que los roles, funciones, y responsabilidades (del personal clave tanto interno como externo, y de apoyo, considerando su disponibilidad y la capacidad de su ubicación oportuna) sobre un conjunto de actividades sean conocidas, claras, justas, entendidas, asumidas, adoptadas, interiorizadas, comprometidas, evitando una situación de juez y parte. Por ejemplo, habría que identificar las personas en la organización que tienen la autoridad para declarar un desastre y por ende, colocar el plan en efecto.
  7. No olvidemos detallar cuándo y cómo invertir en el equipo ejecutivo de gestión de crisis para que se cumplan los requisitos legales y normativos adecuados con respecto a las infracciones de datos. Las personas de relaciones públicas de la compañía pueden ayudar a informar adecuadamente a los clientes y consumidores.
  8. El negocio deberá establecer sistemas alternativos, como decidir cuál de las funciones de la organización son esenciales, y repartir el presupuesto disponible conforme a este criterio, o a establecer acciones manuales (considerando por supuesto la sensibilidad de los datos) que se disparan ante un evento, en la medida que sea posible lo que requeriría posiblemente un esfuerzo de capacitación adicional.
  9. Por supuesto, debemos ejecutar simulacros [lo más reales posibles] de eventos basados en tipos específicos de desastres [no idea, sino realidad], incluyendo brechas de seguridad. Así, la organización deberá proveer los recursos necesarios, establecer si necesita ayuda externa, planificar y programar los simulacros (al elefante nos lo comemos por tajadas), difundir su realización, establecer las estrategias de recuperación, diseñar los escenarios, priorizarlos, evaluar cada qué tiempo realizarlos y obtener la autorización del cuándo realizarlos (no vaya a ser que programemos una prueba justo cuando existe en el mismo día un evento crucial para la organización), cómo los va a realizar (la creación previa de plantillas de verificación ayuda a simplificar este proceso), afinar los planes y mantenerlos vigentes (como dijo Dwight ‘Ike’ Eisenhower, “el plan es nada, la planificación lo es todo”), entre otros factores.

¿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.