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.

16 habilidades de seguridad crítica que necesitamos

16 habilidades de seguridad crítica que necesitamos

Pongámonos en situación

Seguramente este tema sobre seguridad es trillado para muchos, por lo [aparentemente] obvio del tema, a estas alturas.

Contamos con herramientas que seguramente dominamos. Esa es la parte tecnológica.

Pero no debemos dejar de lado que el ser humano ha desarrollado la tecnología con base en hechos científicos, como herramienta, para ayudarse en lo repetido, en lo meramente operativo y no pensante [bueno, otro tema son los continuos avances en inteligencia artificial].

 

 

Entendamos primero el concepto de habilidad

El concepto de habilidad se refiere a una capacidad y disposición para algo; hace referencia a la maña, el talento, la pericia o la aptitud para desarrollar alguna tarea. Es una aptitud innata.

En 1993 la División de Salud Mental de la Organización Mundial de la Salud (OMS) lanzó la Iniciativa Internacional para la Educación en Habilidades para la Vida en las Escuelas.

El propósito de esta actuación era difundir mundialmente la enseñanza de un grupo genérico de diez destrezas psicosociales, consideradas relevantes en la promoción de la competencia psicosocial de niñas, niños y jóvenes.

  1. Autoconocimiento
  2. Empatía
  3. Comunicación asertiva
  4. Relaciones interpersonales
  5. Toma de decisiones
  6. Solución de problemas y conflictos
  7. Pensamiento creativo
  8. Pensamiento crítico
  9. Manejo de emociones y sentimientos
  10. Manejo de tensiones y estrés

Estas diez habilidades psicosociales no son materia nueva. En cierta forma, son tan antiguas como la propia humanidad, porque todas tienen que ver con la manera en que manejamos las relaciones con nosotros mismos, con las demás personas y con el entorno social.

Es más, el Foro Económico Mundial en 2016, propuso en su artículo, 10 habilidades que se necesita para prosperar en la Cuarta Revolución Industrial, que hacia el 2020, se requerirán las siguientes habilidades:

  1. Solución de problemas complejos.
  2. Pensamiento crítico.
  3. Creatividad.
  4. Administración de personal.
  5. Coordinar a otros para trabajar en un fin común.
  6. Inteligencia emocional.
  7. Juicio y toma de decisiones.
  8. Orientado al servicio.
  9. Negociación.
  10. Flexibilidad cognitiva.

Y otro artículo, más reciente, Las habilidades más importantes del mañana, según cinco líderes mundiales, las siguientes habilidades adicionales:

  1. Habilidades blandas, como el trabajo en equipo, conocimiento de las herramientas digitales, la comprensión de las reglas y las regulaciones, la responsabilidad y el compromiso son las más relevantes.
  2. Explotar los torrentes de información que se generan a diario con una fuerte dosis de empatía.
  3. Habilidades que las computadoras nunca llegarán a dominar, y grandes maestros para enseñarlas.
  4. Olvidar el aprendizaje de memoria, y centrarse en habilidades transferibles como: pensamiento crítico, adaptabilidad, resolución de problemas, entre otras.
  5. Un espíritu emprendedor, y las habilidades para saber cómo aplicarlo.

Resulta importante considerar esto de la cuarta revolución industrial porque, en palabras del presidente ejecutivo de WEF, Klaus Schwab, cambiará “no sólo lo que hacemos sino lo que somos”, dado que “afectará nuestra identidad” en múltiples formas.

Más aún esta revolución se manifestará en nuestro sentido de privacidad, noción de propiedad, patrones de consumo, así como en la forma en la que cultivamos nuestro conocimiento e interactuamos con las personas.

Schwab está convencido que “[…] en el futuro, el talento, más que el capital, representará el factor crítico de la producción”.

Ciertamente son de importancia las habilidades consideradas en estos artículos.

Veamos, entonces, sabemos qué hacer en cuanto a seguridad

Pensamos que sabemos todo sobre el tema. Nuestras certificaciones en seguridad, riesgos, continuidad, y otras más, nos acreditan, y nuestra experiencia en dichos campos nos avala. ¿No acabamos de certificarnos en Hacking Ético? -y seguramente ya nos consideramos hackers.

Bueno, no es así para todos, aunque parezca [o debería], y a ellos va dirigido esta contribución.

Mucho tiene que ver [y empezar] con reconocer [sinceramente] nuestras propias fortalezas y debilidades, nuestro propio accionar, nuestras costumbres.

No es raro que el ecosistema en que nos desenvolvemos también juega un papel importante en esto, ya que muchas veces nos arrastra –y nos dejamos arrastrar.

Pero, ¿cómo empezamos a hacer las cosas?

Preguntémonos, por ejemplo:

  1. ¿Cuántas veces no hemos hecho nuestra tarea previa antes de realizar la instalación, implementación, personalización, configuración de un servicio?
    1. ¿Hemos analizado la real necesidad para el negocio, de algún cambio o de una nueva implementación?
    2. ¿Hemos entendido a cabalidad la envergadura del cambio requerido?
    3. ¿Hemos analizado los pre-requisitos?
    4. ¿Hemos identificado todos los datos involucrados y contamos con los correctos y necesarios?
    5. ¿Hemos evaluado los pormenores de nuestras acciones y planeado la ejecución de la tarea?
    6. ¿Hemos evaluado los riesgos antes, durante, y después de la ejecución planeada?
    7. ¿Hemos asegurado que contamos con lo necesario antes de empezar la tarea?
    8. ¿Contamos con mecanismos de remediación/recuperación/reversión realmente probados?
  2. ¿Cuántas veces hemos ingresado valores por defecto?
    1. Y no nos hemos preocupado de analizar y evaluar antes cómo se vería afectada nuestra seguridad, que tanto cuidamos, por estos valores.
    2. Por apuro/cansancio [u otra excusa de su preferencia, mi estimado lector].
    3. Por desconocimiento y por no tener a quién preguntar [o no querer preguntar por vergüenza].
    4. Y los dejamos así, sin evaluar cómo se ve afectada nuestra seguridad, que ya descuidamos, por nuestra acción.
  3. ¿Cuántas veces nos limitamos a las pocas opciones que el proveedor ha implementado en la herramienta [antigua o nueva]?, y sobre las que nos ha capacitado, ambas cosas por puro cumplimiento, pero luego no buscamos o aprendemos más allá [con lo que desperdiciamos la herramienta]
  4. ¿Cuántas veces nos limitamos a una determinada plataforma, y no entendemos que nuestro conocimiento es aplicable a otras, por igual? ¿O sólo llegamos a manejar información?

Y, ¿entendemos realmente en dónde y cómo debemos enfocar la seguridad?

  1. ¿Cuáles son las características únicas del negocio, mercados, clientes, infraestructura, industria?
    1. Todos estos aspectos informan la política de seguridad y cada empresa tiene problemas diferentes.
    2. Antes de comenzar a adquirir herramientas, ¿quién entiende de seguridad en la empresa?
  2. ¿Reconocemos que las habilidades de gestión de proyectos centradas en la seguridad son extremadamente importantes?
    1. Necesitamos descubrir cómo integrar las diferentes soluciones de seguridad que hemos identificado como necesarias, con el resto de los sistemas, agregar capacitación, mantenimiento, actualizaciones, por nombrar algunas.
    2. Y todo esto, ¿cuánto tiempo tomará, sujeto a qué presupuesto, considerando qué resultados?
  3. Las empresas están aprovechando DEVOPS y la automatización para poder gestionar el panorama de amenazas. Recordemos que DEVOPS es una forma de pensar y un enfoque para el desarrollo de software y los procesos de lanzamiento, no una categoría de producto o certificación específica.
    1. ¿Qué debemos considerar para implementar DEVOPS o cualquier otra opción, apoyando la agilidad y flexibilidad?
    2. ¿De qué manera, si aceptamos lo anterior, impacta en nuestra TI [bimodal]?
  4. ¿Estamos empleando en realidad un pensamiento crítico para [realmente] evolucionar?
    1. ¿Ya actualizamos nuestro FODA situacional?
    2. ¿Contamos con un real FODA estratégico? ¿o sólo nos enfocamos en debilidades?
    3. ¿Ya identificamos lo que verdaderamente necesita el negocio para prosperar, y la seguridad relacionada?
    4. ¿Conocemos y entendemos realmente nuestro ecosistema?
    5. ¿Ya actualizamos nuestro análisis de brecha?
    6. ¿Ya hemos puesto en marcha nuestra estrategia para cerrar la brecha?

No olvidemos identificar primero lo que debemos mejorar, cuál es la mejora, qué buscamos obtener con la mejora, cuándo realizarla, con qué recursos y capacidades contamos para llevarla a cabo, el cómo la llevaremos a cabo, quién será responsable de llevarla a cabo, y quién será responsable de los resultados para el negocio

  1. ¿Hemos incrementado nuestras destrezas programando, enfocados en la automatización?
    1. ¿Aprendimos nuevos lenguajes de programación?
    2. ¿Ya nos habituamos al entorno de línea de comando (CLI)?
  2. ¿Ya aprendimos a utilizar las soluciones de seguridad que se han implementado?
    1. ¿Sabemos ya por qué falló nuestra reciente implementación de DLP o SIEM, u otras opciones?
    2. ¿Seguimos dependiendo del proveedor del servicio para los incidentes? ¿o seguimos llamando a todo ‘problemas’?
    3. ¿Reconocemos dónde erramos, y por qué erramos? Sí, nosotros erramos. La tecnología falla, y se puede corregir. ¿Podemos decir lo mismo nosotros?
  3. ¿Entendemos que la experiencia ganada no se puede perder?
    1. ¿Cómo garantizamos la permanencia del personal clave relacionado con la seguridad?
    2. ¿Cómo aseguramos que el conocimiento adquirido [en la empresa] no se vaya con el personal [junto con su experiencia]?
    3. ¿Hemos desarrollado alguna forma de gestión del conocimiento?
  4. ¿Estamos en capacidad de realizar una autopsia o investigación forense después de un, digamos, ‘incidente’?
    1. ¿Nos interesa, pero no tenemos tiempo o recursos o competencias?
    2. Luego de nuestro análisis y evaluación de vulnerabilidades, utilizando nuestro recientemente adquirido conocimiento en hackeo ético, ¿se nos pasó algo? Claro, sino, no hubiera ‘incidente’.
    3. ¿No sería bueno aplicar nuestros conocimientos de hacking para apoyar a cerrar la brecha? Cierto, eso lo hace otro especialista ¿o no pensamos así?
  5. ¿Cómo están de maduras nuestras habilidades blandas?
    1. Serían útiles para determinar posibles amenazas internas a la organización ¿no creen?
    2. Serían útiles para entender el comportamiento de los usuarios frente a los esquemas / perfiles de seguridad que se implementan
  6. ¿Hemos identificado que un punto importante en este tema de seguridad, así como en muchos otros, es la pasión por lo que se hace?
  7. ¿Reconocemos si somos capaces de afrontar la implementación de distintas normativas de seguridad, consolidarlas, y ser eficiente en la implementación de los controles, sin afectar las metas de negocio?
  8. ¿Reconocemos que aún nos falta recorrer mucho en cuanto a seguridad?
    1. Verdadera proactividad
    2. Verdadera previsión [anticipación]
    3. Verdadera innovación
    4. Lidiar con nuestra rigidez cognitiva en ciberseguridad
    5. Planeamiento consciente y consistente de la seguridad
    6. Controlar realmente, monitorizar y tomar acción rápida y efectiva ante cualquier incidente
    7. Valorar lo importante para el negocio, en cuanto a la seguridad
    8. Asegurar que el alineamiento / articulación entre el negocio y la tecnología sea real y efectivo, considerando la seguridad
    9. Establecer correctamente los factores críticos de éxito, sus indicadores clave de rendimiento y las métricas asociadas, en cantidad y propiedad correctas
    10. Evitar postergar lo importante
    11. Reducir las ‘emergencias’
    12. Adoptar la seguridad y la calidad como una forma de vida
    13. Implementar correctamente marcos de trabajo, gobierno, estándares, buenas prácticas
    14. Respetar políticas, normas, procedimientos
    15. Madurar procesos, personas, y tecnología –cierto, también la empresa en su conjunto
    16. Pruebas reales, orientadas, contextuales, personalizadas, controladas, completas
    17. Automatización al máximo, identificando las posibilidades reales de nuestra plataforma tecnológica, y utilizándola al máximo con apoyo de nuestras destrezas
    18. Aprender de nuestra experiencia
    19. Asegurar lo aprendido
    20. Mejora continua –incluyéndonos a nosotros mismos
    21. Gestionar el conocimiento
    22. Muchos otros

Conclusiones

Sí, la seguridad parte del sentido común; es un compromiso, es algo que se adopta, se interioriza.

Reconozcamos que, en la seguridad, sí intervienen las habilidades tratadas, no sólo se trata de capacitarse [o certificarse].

Es y debe ser parte integral de la cultura del lugar de trabajo.

Es fácil encontrarnos con un ‘problema’ y decir que, con una nueva tecnología o herramienta, lo resolvemos. Esto es una falacia. ¿No será que encontramos un incidente [que es, además, repetitivo] y, dadas diferentes, digamos, situaciones, optamos por lo más fácil –y decimos que ‘transferimos’ el riesgo? Hagamos nuestra tarea primero, y bien.

Y sí, Deming con su PDCA está presente, incluso en la seguridad.

Una buena persona de seguridad tendrá una gran pasión por compartir, aprender y hacer crecer sus conocimientos todo el tiempo.

¿Coinciden conmigo en que las destrezas y habilidades antes presentadas tienen mérito de ser consideradas? ¿Y han considerado desde qué edades deben ser incorporadas en nuestro ADN? Interesante ver el resultado en unos años.

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.

¿Quién más desea ser un design thinker?

Para desarrollar una estrategia digital, tendremos que aprender (y usar) nuevas técnicas como el design thinking.

Este método está enfocado en fomentar la innovación en las organizaciones [con base en las personas, en sus conocimientos y en su habilidad por imaginar lo diferente] de una forma eficaz y exitosa.

Las organizaciones que son capaces de crear un clima de Innovación encuentran las grandes ventajas de la participación activa y entusiasta de sus equipos humanos, con ideas nuevas y proyectos motivadores.

Es obvio de lo anterior que el equipo de trabajo es la clave.

Hoy, a medida que el terreno de la innovación se expande para abarcar procesos y servicios centrados en el ser humano, así como productos, las empresas están pidiendo a los diseñadores que creen ideas en lugar de simplemente hacerlas estéticamente atractivas.

El design thinking lleva implícita la necesidad de observar a los usuarios [clientes] con el objetivo de buscar soluciones que se centren en ellos.

Entonces, en el ámbito actual de los negocios, podríamos anotar que es un enfoque en la empatía de los clientes y las soluciones de prototipado rápido a los problemas de los clientes (un sentido de urgencia para evitar que el pez chico se coma al grande), de una forma que sea tecnológicamente factible y comercialmente viable (que se obtenga valor para el cliente). Hablamos, por supuesto, del prototipado de las ideas más prometedoras, y no lo confundamos con el de una pantalla de menú de una aplicación de recursos humanos, por ejemplo.

Tradicionalmente son cinco pasos que se siguen [no precisamente de forma línea]:

  1. Empatizar con las personas que disfrutarán de nuestro trabajo, mediante observación y entrevistas, hay que entenderlas, intentar sentir lo que sienten, identificar lo que les interesa, es buscar descubrir y comprender los supuestos personales y organizacionales y las inclinaciones alrededor de un punto focal –cómo abordo el desafío.
  2. Definir, para identificar cuáles son sus actuales ideas, y poder seleccionar qué necesidades concretas del cliente vamos a solucionar, es identificar e interpretar las tendencias y patrones –cómo interpreto mis hallazgos.
  3. Idear, ya estamos listos para uno de los momentos más atractivos del método, la eclosión creativa para generar ideas (las reglas innegociables en toda sesión de lluvia de ideas son: no criticar las aportaciones de los demás, generar cuantas más ideas mejor y hacerlo en un clima distendido y de diversión profesionalizada), es desarrollar conjuntos de mapas divergentes y provocativos utilizando creatividad, datos, intuición e investigación –qué es lo que creo.
  4. Prototipar, convertir las mejores ideas en diseños reales que las personas puedan ver, tocar y con las que puedan interactuar, es informar esfuerzos de planeamiento de largo aliento, inspirar innovación, y crear hoy el futuro –cómo construyo mi idea.
  5. Testear, con una pequeña muestra, dejar que toquen y experimenten, aguantar la respiración [y esperar pacientemente saber qué funcionó y que no], sin perder la sonrisa, y escuchar sus opiniones finales (la bendita, esperada y preferible retroalimentación) –cómo pruebo y mejoro la idea

Bueno, creo que algunos de nosotros hemos estado utilizando este modelo (independiente a la profesión), por varios años, aunque no le llamamos así; de hecho, no le poníamos nombre y, a mi entender, y en algunos aspectos, es una cuestión de sentido común que se va ganando con la experiencia, compromiso y perseverancia.

No me malentiendan, evidenciarlo ahora, aunque no sea nuevo en concepto, resulta útil para todos, con o sin experiencia.

Design thinking no se trata de crear productos o empresas, sino de tomar medidas concretas para hacer de nuestro mundo un lugar mejor.

Es una forma de pensar, está centrada en las personas, es colaborativa, es optimista, es experimental. Busca una perspectiva adaptable, resistente y transformacional.

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.

 

¿Gestionas el cambio como un experto?

¿Gestionas el cambio como un experto?

Ya habíamos hablado de gestionar el cambio en una entidad pública. De hecho, también de limitaciones para un apropiado cambio, y máxime si se trata de proyectos.

Tenemos el know-how pero carecemos de la madurez para afrontar el cambio y reconocer dónde empezar.

Muchas veces esto está condicionado por el ambiente y la cultura de la empresa, lo que nos hace fallar y pensar que utilizamos una herramienta o contratamos el personal inadecuado o contratamos un consultor inexperto, y hasta que fuimos estafados –claro, fácil es echarle la culpa al otro ¿verdad?

Las organizaciones deben adaptarse a los cambios de escenario con proyectos cada vez más complejos, y entornos de gran incertidumbre y volatilidad. En toda empresa se realiza periódicamente un esfuerzo por determinar la mejor dirección para el negocio.

La cultura organizacional, su estructura, sus procesos, políticas, procedimientos y hasta sus valores pueden no estar en sintonía con ese cambio que se nos avecina y que demandará una nueva forma de interactuar, de pensar, de actuar.

El establecer controles que antes no existían ocasionará que, en la mayoría de los casos, las personas se resistan y respondan sólo por obligación a las exigencias de la organización.

De hecho, la cultura organizacional cambiará en la medida que cambien las personas y la posición que estas personas adopten frente al cambio, ya que son las personas las que hacen el cambio sostenible en el tiempo.

Una vez identificados los cambios que debemos realizar para asegurar esa dirección (entendiendo la necesidad del cambio y beneficios luego del cambio en el ecosistema de la organización), debemos establecer el valor del cambio y priorizar los principales ajustes (en procesos nuevos -o actualizándolos o complementándolos, procesos que pueden ser medidos, verificados y por ende adaptados en pro de la mejora continua, roles, estructura organizativa si es necesaria), entender a quién alcanza el cambio y cómo le beneficia (a clientes y stakeholders), establecer el compromiso e involucramiento de los participantes (recursos provistos en la oportunidad y cantidad requerida, personal suficiente, apropiado, capacitado, motivado), realizarlos (aplicando las 6W-2H), y mejorarlos.

Es sabido que el trabajo colaborativo genera pertenencia, nos permite apropiarnos del conocimiento, las habilidades y las actitudes que nos hace falta desarrollar para lograr los objetivos planteados. Es necesario entonces un poco de inteligencia emocional en el momento oportuno y de la manera apropiada y personalizada para sensibilizar a las personas ante lo que está por venir y así canalizar sus emociones –o motivación. Es importante entonces desarrollar una estrategia de comunicación y monitorizar la comunicación porque es clave para realizar ajustes cuando sea necesario.

Gestión de proyectos en la gestión pública

Ya antes habíamos comentado sobre los proyectos fallidos.

De hecho, mucho se habla hoy sobre este tema de que en la gestión pública se deben gestionar proyectos o, al menos, de que deberíamos emplear técnicas de gestión de proyectos en la gestión pública.

Interesante propuesta, e ideal desde todo punto de vista, pero ¿y la acción?

Hace un tiempo se pretendió utilizar una herramienta para gestionar proyectos en una entidad del estado. Obviamente esta iniciativa fracasó. Los motivos fueron, entre otros, pero no limitados a, la expectativa de alcanzar los beneficios siempre promulgados por una eficiente gestión de proyectos, además de una pronta toma de decisiones informada, pero sin tener en cuenta las restricciones y plazos de ley para ciertas actividades, las ocurrencias producto de una deficiente formulación de los expedientes técnicos, y formalismos establecidos, pero no estandarizados, de los diferentes actores. Hay aquí una relación e integración interesante de gobierno, riesgos, y cumplimiento, y se comprueba que todo proyecto debe ser continuamente monitorizado para validar que se mantiene entregando el valor esperado.

El gerente general deseaba conocer realmente el portafolio de proyectos de la institución. Deseaba dejar un portafolio de proyectos ordenado, organizado, y controlado. En la fecha de la presentación oficial del producto desarrollado, se dio cuenta este gerente que no iba a inaugurar una determinada obra -estratégica- durante su vigencia en el cargo. Los sub-gerentes se excusaron, adujeron carencia de información oportuna, apareció un sin número de actividades extra, y atacaron el producto. El ejercicio sirvió al gerente para tomar una decisión referente a la inauguración, y para corroborar, según él, que efectivamente no se le informaba ni oportuna ni apropiadamente, y que las gerencias no trabajaban en equipo.

El producto no tenía nada de malo. Se había desarrollado en conjunto con el personal asignado como un producto dinámico, de alcance holístico para la tarea. Este dinamismo permitía reducir, lo mejor posible, la incertidumbre y el riesgo[1], pero era necesario dedicarle –constantemente-un tiempo; no es que me pueda limitar horas antes a completar el cuadro, de forma aislada, para presentarlo en la fecha prevista, apoyándome en “mi experiencia pasada”. El alcance era holístico por cuanto involucraba todas las gerencias, desde la concepción de la idea hasta la inauguración del proyecto una vez terminado. Un problema es que los sub-gerentes lo consideraron un mero plan estático, y no un producto sujeto de continua actualización (¿una de las excusas del momento?). El compromiso de apoyo se dio, puntualmente para el momento y por exigencia del gerente general, atendiendo a únicamente su ámbito de competencia, y falló la comunicación interna, y la continuidad del compromiso (genuino) para las actualizaciones pertinentes y constantes, el sinceramiento de reconocer que se necesita y de adoptar una herramienta de control.

Si lo anterior se corrigiera, entendiendo que se requiere un cambio de real[2] contenido (estructura, procesos de negocios, sistemas de gestión, tecnología, cultura, las propias personas, etc.), seguramente mejoraríamos la calidad de los proyectos y obtendríamos mejores resultados, sobre todo, sostenibles en el tiempo.

[1]       Fuente: http://salineropampliega.com/2014/11/gestion-de-proyectos-en-la-administracion-publica.html

[2]       Fuente: http://salineropampliega.com/2017/02/entrevista-a-akira-bloise-sobre-como-implementar-la-direccion-de-proyectos-en-una-organizacion-12.html

Gobierno, riesgo, seguridad [de la información]

“Se requiere mantener la seguridad de la información de la plataforma tecnológica utilizada para proveer los servicios de TI”. Sí, sí, frase trillada –pero, ¿controlamos la seguridad de la información? ¿Qué significa mantener segura nuestra plataforma tecnológica en el creciente y cambiante entorno de las amenazas a las que está expuesta?

Bueno, es el mantra de la seguridad en nuestros días pero, ¿cuánta seguridad es necesaria o apropiada, cuándo aplicarla, en dónde aplicarla, cómo aplicarla, porqué aplicarla, a quién le interesa -o afecta…? [Sí, 6W-2H].

¿La seguridad debería o podría ser implementada por demanda?[1]; implica que las organizaciones de TI cuentan con la flexibilidad de ajustar su postura de seguridad mediante la adición de la funcionalidad que sea necesaria y posible, acorde con las exigencias crecientes y cambiantes de las necesidades del negocio y de los entornos de las amenazas a las que a diario [bueno, bueno, a cada instante -dramático ¿no?] estamos expuestos -o experimentamos. Cualquier ajuste implica monitorizar para evaluar, priorizar y controlar, con la visibilidad necesaria para el negocio. Lo que pueda ser posible de implementar estará en función de la capacidad de adaptación de la organización, para una fácil y rápida implementación –recordemos que el modelo actual de la seguridad es aditivo. Las cada vez cambiantes amenazas seguramente requerirán capacidades avanzadas de seguridad [lo que desde ya es un constante desafío, el contar con defensas que respondan apropiadamente a las actuales amenazas –la dinámica de la seguridad de la información], y estaremos más o menos expuestos por nuestras [posibles] limitadas habilidades de seguridad.

No olvidemos que el costo de un dispositivo móvil robado es nada en comparación con el valor de los datos perdidos[2]. Ya hemos tratado esto varias veces antes. Fatal si el dispositivo es propio [personal] pero si el dispositivo es propiedad de una empresa –en el afán de facilitar la usabilidad (o tal vez la ubicuidad)- deberemos tener cuidado con nuestras acciones al respecto –trabas a la usabilidad- porque está involucrada la intimidad de las personas –la privacidad de los empleados (seguridad de la información de por medio). Así, las organizaciones deberán, entre otras acciones pero no limitadas a las siguientes: implementar la tecnología necesaria [o cuando menos las políticas] para asegurar que los empleados no puedan descargar aplicaciones de repositorios no autorizados o no oficiales -gestión de aplicaciones móviles (MAM); la tecnología apropiada para crear entornos autenticados y cifrados de confianza, para almacenar, utilizar y compartir los datos empresariales –contenedores; buscar aislar los datos corporativos de los datos personales y de cualquier amenaza que pudiera estar presente en el dispositivo móvil – gestión de contenidos móviles (MCM); realizar análisis de reputación de aplicaciones para evaluar y responder a las vulnerabilidades y amenazas de aplicaciones móviles que pudieran poner en peligro los datos de negocios; incluso aplicar políticas de seguridad de aplicaciones móviles basadas en la identidad autenticada del usuario

Tampoco olvidemos los temas referidos a seguridad de la información -¿cumplimiento tal vez?- sobre el paradigma de computación en nube que tratamos antes, como agente disruptivo, paradigma que resumimos en la siguiente figura:

gráficos 01

Fuente: Chuman Zuñe, Freddy; Cárdenas Saldívar, Iván; Cáceres Meza, Jack Daniel. ” Diseño de una nube privada segura para el sector público peruano”. Universidad Tecnológica del Perú. Escuela de Posgrado. 2013.

Este paradigma es también una consideración de riesgo porque ¿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?, dentro del marco de la seguridad de la información por supuesto. Así, la figura siguiente presenta algunos de los riesgos identificados para la adopción del modelo de computación en nube, y también presenta algunos marcos de trabajo y normas que, correctamente aplicados, nos ayudan a gestionar estos riesgos:

Fuente:          Chuman Zuñe, Freddy; Cárdenas Saldívar, Iván; Cáceres Meza, Jack Daniel. " Diseño de una nube privada segura para el sector público peruano”. Universidad Tecnológica del Perú. Escuela de Posgrado. 2013.

Fuente:          Chuman Zuñe, Freddy; Cárdenas Saldívar, Iván; Cáceres Meza, Jack Daniel. ” Diseño de una nube privada segura para el sector público peruano”. Universidad Tecnológica del Perú. Escuela de Posgrado. 2013.

Muchas organizaciones se esfuerzan por implementar el software, hardware, y servicios que les permitan identificar y reducir los riesgos. Pero pocos involucran a su gente – las mismas personas que crean y utilizar la información que está siendo protegida e incluso la excluyen por desconfianza[3]. Bueno, sabiendo que el nuevo modelo de seguridad tiene cinco dimensiones, a saber:

  1. Enfocar la seguridad de la información en los activos críticos, nucleares –un enfoque basado en riesgos (lo que puede ser difícil para muchas organizaciones) para establecer el “mejor esfuerzo” podría ser más racional.
  2. Proteger los activos clave con varias capas de sistemas de defensa. Asumir que la empresa ya está comprometida (ya sea por los delincuentes cibernéticos, los competidores, o el gobierno – ¿para los paranoicos?), y desarrollar una estrategia en torno a esa suposición. Comprender que hay muchas fuentes de compromiso, no sólo el centro de datos, computadora personal o dispositivo móvil.
  3. Involucrar a las personas que utilizan la información para proteger los activos [de información] con los que trabajan –especialmente el personal ejecutivo y personal operativo que hemos identificado como claves. “Hazlo o no. No intentes”, ¿recuerdan?
  4. Formar equipo con socios comerciales para impulsar su (y sus) sistemas inmunológicos. Porque todo no se puede proteger de la misma manera. Así, habrá que desarrollar una declaración de aplicabilidad –sí, ayuda el 6W-2H, especialmente en este moderno ecosistema digital. De seguro recuerdan estas palabras: “El miedo es el camino hacia el lado oscuro. El miedo lleva a la ira. La ira lleva al odio. El odio lleva al sufrimiento”[4].
  5. Hacer de la seguridad un problema del negocio – no sólo un problema de TI, porque las posibles alternativas de solución no son siempre tecnológicas. Es hora de pensar en un modelo de seguridad holístico, donde se utilizan múltiples tecnologías y técnicas de gestión, con una amplia aceptación de las medidas estratégicas y tácticas a implementar y rendición de cuentas del valor obtenido de esta implementación –entra el gobierno corporativo de TI (COBIT), en capas y adaptado al riesgo [identificado, evaluado (evaluar los datos y sistemas; identificar los riesgos para dichos sistemas; evaluar los riesgos[5] para la probabilidad, gravedad e impacto (las variables no solo han cambiado, sino que se han multiplicado[6]); y la identificación de los controles[7], salvaguardias y medidas correctivas), y gestionado (el residual por supuesto, luego de haber realizado nuestro trabajo previo de mitigación y/o transferencia) –porque conocemos realmente el riesgo[8]] y el valor que han sido estimados. Sin olvidar, claro, que es igual de importante mantener el ojo en los cambios internos a través de la evaluación continua de la política de riesgos, tolerancia al riesgo, y los indicadores clave de riesgo; pruebas de control y de evaluación de resultados; e informar sobre las actividades de garantía, incluida la auditoría interna, gestión de control y cumplimiento[9]. La gestión del riesgo influye en muchas áreas de la compañía. Su correcta aplicación e involucramiento en la empresa permite que la organización sea más flexible, medible y rentable[10].

Surge entonces la necesidad de integrar [para evitar solapamiento de funciones] gobierno corporativo, gestión de riesgos y cumplimiento corporativo, tres pilares que trabajan en conjunto con el fin de garantizar que la organización cumple sus objetivos –obtiene el valor que sus stakeholders esperan (la idea que compraron y los hizo invertir). Recordemos que gobernar (estructuras, políticas, procesos y controles de la dirección y la gerencia ejecutiva[11]) es asegurar unos objetivos (controlar que se logren), en base a la estrategia empresarial acordada, a partir de la administración de unos recursos determinados y manteniendo el riesgo a niveles aceptables[12].

La figura siguiente muestra una base de esta integración –compleja evidentemente[13]. Por supuesto que existen diversas opciones comerciales pero su elección depende de nuestro correcto –y previo- entendimiento de los objetivos del negocio[14]. Para una adecuada implementación es necesario que existan definidas las metas estratégicas, los planes tácticos para alcanzar estas metas, y las actividades operativas necesarias y apropiadas para la realización de dichos planes.

Fuente:          http://www.slideshare.net/jack_caceres/curso-control-de-acceso-y-seguridad-05-gestin-de-riesgos-2

Fuente:          http://www.slideshare.net/jack_caceres/curso-control-de-acceso-y-seguridad-05-gestin-de-riesgos-2

El cumplimiento puede ser complicado (¿no es el actual ambiente de negocios cada vez más complejo y regulado?[15]), así como buscar reducir las pérdidas y mejorar la toma de decisiones[16], considerando los riesgos planteados en la figura anterior, además de la ciberdelincuencia, las redes sociales, las tecnologías emergentes, los partner o socios de negocio, estrategias más agresivas por parte de los competidores, necesidad de innovación permanente, necesidad de formación continuada y de valor, o disponer de asesoramiento externo experto en múltiples ámbitos, debido al entorno cambiante, mayor gradiente de obsolescencia en los modelos de negocio, entre otros factores a considerar. ISACA nos señala que la seguridad de la información es un componente central en el modelo GRC[17]. La siguiente figura muestra los factores que han propiciado la aparición de la GRC:

Motivos-GRC

La OCEG nos proporciona en la siguiente figura una vista de componentes del Modelo de Capacidad de GRC que esta promulga.

gráficos04

Cada Elemento que se muestra incluye un análisis de los controles y acciones de gestión y aborda consideraciones del diseño y la implementación. Los Elementos definen los aspectos centrales de las capacidades efectivas y pueden servir como un punto de arranque para la evaluación del estado actual del enfoque de una organización. Los Elementos pueden ser aplicados en todos los niveles de la organización para direccionar objetivos empresariales, capacidades departamentales o acciones o controles en áreas críticas. ¿Le son interesantes los elementos considerados? Yo creo que sí.

[1]       Fuente: http://resources.idgenterprise.com/original/AST-0165708_Level3QuickPulse.pdf; disponible en julio/2016

[2]       Fuente: http://searchdatacenter.techtarget.com/es/cronica/Cinco-formas-de-impulsar-la-seguridad-de-aplicaciones-moviles?utm_medium=EM&asrc=EM_EDA_60596204&utm_campaign=20160711_Cinco%20formas%20para%20impulsar%20la%20seguridad%20de%20las%20apps%20m%C3%B3viles_&utm_source=EDA; disponible en julio/2016

[3]       Fuente: http://core0.staticworld.net/assets/media-resource/17273/infoworld-new-security.pdf; disponible en julio/2016

[4]       Fuente: http://www.govinfosecurity.com/blogs/7-star-wars-day-cybersecurity-lessons-p-2121?rf=2016-05-05-eg&mkt_tok=eyJpIjoiTkdVME9HWTJaRFZpTW1ZeiIsInQiOiI2NUNwMGZqQnhuaUpzaU1udTNPT0xiU2NcL1ZMSk5MSEJrTlZQUklBYlBGZFduUmZwSHgydW9RZ1RIYjV4ZVZNcFJQRHlIRlBqb1d6UG1WN1VCK052YVZsbkZZUVdnQVlVbmNGYnJleEc2WkU9In0%3D; disponible en julio/2016

[5]       Fuente: http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-30r1.pdf; disponible en julio/2016

[6]       Fuente: http://www.pwc.es/es/soluciones/auditoria/grc-suite.html; disponible en julio/2016

[7]       Fuente: http://www.sans.edu/research/security-laboratory/article/security-controls; disponible en julio/2016

[8]       Fuente: http://www.cio.com/article/3065048/security/how-to-perform-a-risk-assessment.html?token=%23tk.CIONLE_nlt_cio_security_2016-05-06&idg_eid=0f3e0907b81179ebb4f3b209b6424bae&utm_source=Sailthru&utm_medium=email&utm_campaign=CIO%20Security%202016-05-06&utm_term=cio_security#tk.CIO_nlt_cio_security_2016-05-06; disponible en julio/2016

[9]       Fuente: http://www.oceg.org/resources/building-blocks-grc/; disponible en julio/2016

[10]     Fuente: http://www.deloitte.com.mx/agrc/grc.htm; disponible en julio/2016

[11]     Fuente; http://www2.deloitte.com/content/dam/Deloitte/mx/Documents/risk/mx(es-mx)ServiciosGRC.pdf; disponible en julio/2016

[12]     Fuente: http://www.aspectosprofesionales.info/2014/08/la-responsabilidad-penal-corporativa-el.html; disponible en julio/2016

[13]     Fuente: http://searchdatacenter.techtarget.com/es/definicion/Software-de-GRC-gobernanza-gestion-de-riesgos-y-cumplimiento; disponible en julio/2016

[14]     Fuente: http://searchdatacenter.techtarget.com/es/cronica/La-seleccion-de-herramientas-de-GRC-comienza-entendiendo-los-objetivos-de-negocio; disponible en julio/2016

[15]     Fuente: http://www.epicor.com/lac/solutions/enterprise-risk-management.aspx; disponible en julio/2016

[16]     Fuente: https://www-01.ibm.com/software/es/analytics/rte/an/risk-compliance/; disponible en julio/2016

[17]     Fuente: http://www.isaca.org/chapters7/Monterrey/Events/Documents/20101206%20Uniendo%20al%20Gobierno%20(GRC).pdf; disponible en julio/2016

Los proyectos –que apoyan los negocios

Moira Alexander[1] escribió para la revista especializada CIO[2] un artículo interesante donde planteaba algunos proyectos “que todo negocio puede poner en práctica este año para ayudar a asegurar que las personas, procesos y tecnologías están trabajando juntos de manera efectiva para crear mejores oportunidades o evitar perderlas”.

Estos proyectos son los siguientes:

  • Poner más énfasis en proyectos que apoyen la estrategia [de las organizaciones].
  • Re-evaluar las necesidades del comprador/cliente [retroalimentación].
  • Adoptar la mejora de procesos de negocio [incrementar la eficiencia –y rendimiento].
  • Revisar la oferta de servicios de los proveedores [las necesidades cambian].
  • Revisar y mejorar los sistemas de información y la tecnología [factor competitivo en este mundo globalizado].
  • Re-despliegue de recursos humanos [sin crear pánico, buscar que la tarea sea realizada de la manera apropiada por la persona apropiada y a la primera vez].

Sí, para sobrevivir debemos evolucionar; esto es, tener la capacidad de anticipar el futuro y transformar la empresa en una empresa digital[3]. Los CIO estratégicos aseguran que las inversiones en TI están siendo impulsadas por las ganancias que esta digitalización promueve, por el incremento en agilidad que se genera y por el incremento en la experiencia del usuario[4].

A la hora de las ideas, olvídese de los rangos –talento es talento (lo que hay dentro).

La comprensión de ITIL® nos permitirá optimizar los servicios de TI porque ahora podemos ver a estos servicios holísticamente –su ciclo de vida, y ayudará a crear mejores estrategias para mantener a los clientes contentos. Deberemos empezar entonces por evaluar la actual oferta de servicios de TI.

Aunque toda empresa es diferente, en cuanto a tecnología, siempre existirán las de adopción temprana y las tradicionales [que no siempre encuentran obstáculos]. No olvidemos establecer los factores críticos de éxito y sus respectivos indicadores.

Para mantener el talento emocionado por su trabajo, asegúrese de contar con un plan regular de rotación de proyectos para asegurar que van a obtener consistentemente proyectos frescos en adición a sus funciones, y de manera más regular. Y, claro, asegure que su talento balancee su carga laboral con la familiar (se distraiga) para evitar el stress.

[1]      Fuente: http://www.cio.com/author/Moira-Alexander/; disponible en mayo/2016.

[2]      Fuente: http://www.cio.com/about/about.html; disponible en mayo/2016

[3]      Fuente: http://www.cio.com/article/3072655/leadership-management/how-cios-can-guide-digital-business-transformation.html; disponible en mayo/2016

[4]      Fuente: http://core0.staticworld.net/assets/2016/01/14/2016-state-of-the-cio-executive-summary.pdf, disponible en mayo/2016

 

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