8 maneras de sortear [asumir] fallas

Todo profesional relacionado con las TI ha oído hablar de la ley de Murphy. Algunos creen no haberla experimentado; otros dicen no haberla experimentado; otros niegan haberla experimentado. Tal vez [aún] no se han dado cuenta.

Sabemos que un error es causa de una falla, y ambos pueden ocurrir por diferentes razones -pero, como dijo Churchill, por ni una sola excusa; y que una falla (que, dependiendo del impacto, podríamos considerar como problema), puede conducir a uno o más incidentes. Con una adecuada formación en gestión de servicios podremos determinar los ámbitos de actuación de cada uno de estos términos.

Siguiendo a Deming, luego que resolvemos la condición negativa que se presentó [y que impactó el servicio o la seguridad de la información relacionada], ¿tomamos alguna acción? ¿Evaluamos los resultados de los cambios implementados en el valor de los servicios que se entregan, y/o en la seguridad de la información? Verificar el éxito del cambio ejecutado para [al menos] mantener la calidad del servicio entregado o su seguridad es bueno pero, en adición, debemos validar que la necesidad del cambio haya sido satisfecha, desde el punto de vista de la entrega de valor del servicio (SLA, clientes) como para los stakeholder (beneficios, cumplimiento, reguladores, regulaciones, evitar demandas o pago de moras, entre otros aspectos a considerar).

La tecnología juega un papel importante en todo esto, como también lo hace la cultura [organizacional, de servicio, de calidad, de seguridad, …].

En lugar de tratar con una, digamos, oportunidad de mejora, de forma individual -y hasta aislada, ¿realmente aprendemos de esta(s) tras aplicar mecanismos sistémicos apropiados y de manera oportuna y correcta? ¿está nuestra cultura [institucional] lo suficientemente madura para esto? ¿somos realmente un referente en esto –o al menos buscamos estar en camino de serlo? ¿utilizamos herramientas apropiadas para analizar la causa raíz de las oportunidades de mejora? ¿Son estas herramientas utilizadas por colaboradores competentes? ¿Gestionamos apropiadamente el triángulo procesos-personas-tecnología? ¿Qué tan proactivos somos al respecto? ¿Están clara y completamente identificados todos los involucrados, así como los límites, restricciones, expectativas, y presiones relacionados? ¿Hay vacas sagradas o el cliente es nuestra meta, no sólo de palabra sino con acciones concretas, duela a quien le duela? ¿Entendemos que habrá efectos negativos si hacemos mal las cosas?

¿Aprendemos de los errores de los demás? A propósito de las últimas noticias sobre ransomware. ¿Están los procesos establecidos y son seguidos? ¿Tienen las evidencias necesarias –ya mismo?

¿Sabemos qué información está disponible para las personas que trabajan en resolver problemas y qué tan rápido pueden obtenerla, para que puedan desarrollar pautas claras para evitar complicar el problema debido al estrés, la confusión o la fatiga? Información contextual, oportuna, clara, correcta, vigente, y completa, así como, objetividad y enfoque en la tarea, son condiciones primordiales en estos casos.

Tal vez nos centramos en buscar culpables, primero y siempre, afectando la moral –y perdiendo tiempo valioso, sin que nos importe nuestro cliente. Evitamos, consciente (limitaciones, presiones, carencias, inexperiencia, otros) o inconscientemente (confiamos ciegamente que la acción correctiva evaluada, elegida, y llevada a cabo es la definitiva), responder a la pregunta: si asumimos que podría ocurrir nuevamente, ¿cómo responderíamos mejor esta vez? ¿Son nuestros reportes del tipo ‘lecciones aprendidas’ (en sentido positivo) o del tipo ‘post mortem’ (en sentido negativo)?

Claro, errar es humano, y las estadísticas nos dicen que el ‘error humano’ bordea el 70% como causa de accidentes de tránsito en Lima. Bueno, tenemos factores como condiciones físicas del conductor (estado de alerta/lucidez, velocidad de reacción, ingestión de elementos alucinógenos o de bebidas alcohólicas, fatiga-cansancio-somnolencia), atención a la tarea –y no al celular, a la radio, al copiloto(a), exceso de confianza, temeridad, condiciones del vehículo, velocidad, estado de las vías, [des]conocimiento del reglamento de tránsito, señalización adecuada (bueno, si ‘Pepe el vivo’ las respeta porque ‘no hay policía que me vea’ ‑cuando el policía debía estar dentro nuestro), estilos de conducta en contextos de tráfico en relación a las variables: edad cronológica; estado civil; grado de instrucción; lugar de procedencia; pertenencia del vehículo; la conducción como ocupación principal; tiempo en la conducción; accidentes de tránsito; papeletas recibidas por infracciones; problemas de salud; problemas auditivos; problemas de motricidad; problemas familiares y problemas emocionales, entre otros. Nos damos cuenta que hay fallos activos (errores y violaciones, actos inseguros que tienen un impacto directo y son cometidos por los trabajadores que operan el ‘sistema’), y condiciones latentes (resultado de decisiones de los diseñadores y gerentes, las que se expresan en las condiciones del entorno, la política y cultura organizacional; influyendo así el desempeño de los trabajadores). Listo, introduje la palabra ‘sistema’ así que no nos salvamos y aplicamos el caso a las TIC. El verdadero problema son las herramientas y los procesos que no impiden (o al menos emiten advertencias sobre) los errores inevitables que la gente hace, o la falta de automatización que significa, en primer lugar, que alguien está haciendo una labor manual –posiblemente propensa a errores y con errores en la fuente. Por ejemplo, podría haber carencia u obsolescencia de documentación, procesos, procedimientos; tal vez exista un desconocimiento del ecosistema tecnológico en la empresa; podría no existir o ser inadecuado o estar mal programado el monitoreo, control, supervisión; podría no haber auditoría interna de seguimiento o ser aceptados y trabajados sus resultados; podrían no darse de manera oportuna y completa, o no sustentarse apropiadamente las inversiones necesarias desde el punto de vista del valor para el negocio; entre otros factores de consideración.

Tengamos presente que los errores podrían ser tolerados, pero no el ocultarlos o encubrirlos. Entendamos que hay valor en invertir en el desarrollo y el fomento de una cultura en la que los colegas reconozcan errores y errores de juicio, y apoyarlos para que reporten aquellas cosas que casi originaron una falla. Tratar la TI y la seguridad como un servicio del negocio en lugar de un punto de control ayuda a crear ese tipo de cultura.

No olvidemos la deuda técnica -el costo y los intereses a pagar por hacer mal las cosas (presión en el cronograma, escasez o carencia de recursos apropiados o suficientes, entre otros factores, que obligan a saltarse pasos [o funcionalidad]) –y que no se ven desde fuera, pero causan daño dentro –no nos engañemos con la falacia del “costo hundido”. La famosa filosofía “si funciona, no lo toques”, puede ser un grave error. La modernización tecnológica (de los activos críticos del servicio) y su seguridad ([in]cumplimiento, riesgos para el negocio si el activo se ve comprometido) es algo mandatorio en estos tiempos; sin embargo, es necesario planificar esta modernización.

Recordemos que la información resultante debe transparentarse, difundirse, utilizarse, proactivamente. Evitemos reinventar la rueda. Avancemos. Contribuyamos con el conocimiento. ¿Somos lo suficientemente maduros verdad? Se nos mide por lo que hacemos, no por lo que decimos que hacemos.

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

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

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

Doxware, una variante del ransomware o del extortionware

Doxware, ¿es una evolución, una variante de malware, una nueva tendencia, o sólo un nuevo nombre? –porque nos gustan los nombres nuevos, sobre todo para lo que resulte amenazante[1].

Según la RAE, secuestrar es “Retener indebidamente a una persona para exigir dinero por su rescate, o para otros fines”; extorsión es “Presión que se ejerce sobre alguien mediante amenazas para obligarlo a actuar de determinada manera y obtener así dinero u otro beneficio”.

Ransomware suele instalarse en un sistema a través de un archivo adjunto de correo electrónico malicioso [usualmente de modalidad phishing], una descarga de software infectado y / o visitando un sitio o enlace malicioso. Cuando el sistema (independiente de la víctima) está infectado con ransomware, se bloquea, se cifran los archivos del usuario o se restringe el acceso del usuario a las funciones clave del equipo[2]. No se necesita mover datos, sólo cifrarlos[3]. Para evitar ataques, no sólo de ransomware, asegúrese de que todos los sistemas y software estén actualizados, proteja su red con tantas capas de seguridad como su presupuesto lo permita, cifre los datos sensibles, trate de no poner todos los huevos en la misma canasta, prevenga, eduque. El Grupo Smartekh nos ofrece un análisis gratuito de riesgo por ransomware.

Haciendo un poco de historia, la palabra doxxing; doxxing o doxing es un derivado de la palabra “docs” [“documentos” en idioma inglés]; el término es una versión abreviada de “dropping dox”, un método de venganza (algo así como dejar datos de alguien en el baño) que se remonta a la cultura hacker (y no tan hacker) de principios de los años 90[4].

Cuando doxxing y ransomware se combinan, esta combinación letal se conoce como Doxware[5]. Doxware entonces es el término usado para la técnica de acoso de encontrar, [secuestrar, extraer] y luego publicar información personal sensible de un usuario, incluyendo direcciones, números de teléfono e incluso números de Seguro Social[6].

Doxware normalmente escanea los archivos buscando frases clave que indican que son comunicación privilegiada, confidenciales o privados; así, el alcance de los archivos que doxware tiene como objetivo es menor que el ransomware ordinario, que se dirige a los discos duros completos[7].

Más preocupante es que los ciber delincuentes pueden tener acceso permanente a los datos personales y pueden exigir un rescate más de una vez. Incluso si se cede al chantaje, no hay ninguna garantía de que los archivos que han exfiltrado se eliminarán (apareció el extortionware). Los ataques basados en extorsión probablemente no aumentarán para el público en general, pero puede ser preocupante para los objetivos de alto valor, conocidos por tener datos valiosos. Con doxware el ataque es más personal, más selectivo, busca los blancos más atractivos, los que rindan más beneficios, los que maximicen el ROI. Es más, doxware puede exponer a las víctimas a acoso y humillación, pero también puede dejarlas vulnerables al robo de identidad[8].

El shadow IT, las redes sociales, el autoservicio de TI, hummmm. De hecho, preocupa a más de uno.

Confiamos en que evitamos la pérdida de los datos con los respaldos que realizamos, y en que recuperamos los servicios desde ahí, pero, en adición al tiempo y esfuerzo relacionados con el retorno real a la operación (dependiendo de la plataforma tecnológica desplegada, las capacidades existentes, y el tamaño del recurso comprometido), y del costo total de propiedad inherente, ¿qué fue de la pérdida de privacidad de los datos, no sólo por en dónde estaban sino, además, de quién son? ¿qué hay de un usufructo no alcanzado u oportunidades perdidas? ¿qué hay de los datos que son publicados y/o de posibles acciones legales por exposición no autorizada? ¿qué hay de la confianza perdida?, entre muchas otras interrogantes.

Recordemos, la ignorancia no es una defensa y el anonimato percibido no es un escape[9].

[1]       Fuente: http://searchdatacenter.techtarget.com/es/cronica/Doxware-Nueva-amenaza-de-ransomware-o-solo-extortionware-renombrado; disponible en marzo/2017

[2]       Fuente: https://www.techopedia.com/definition/4337/ransomware; disponible en marzo/2017

[3]       Fuente: http://www.networkworld.com/article/3174678/security/the-latest-ransomware-threat-doxware.html; disponible en marzo/2017

[4]       Fuente: http://computer.howstuffworks.com/what-is-doxxing.htm; disponible en marzo/2017

[5]       Fuente: https://www.topsec.com/it-security-news-and-info/what-is-doxware-ransomware; disponible en marzo/2017

[6]       Fuente; https://www.merriam-webster.com/dictionary/dox; disponible en marzo/2017

[7]       Fuente: https://www.techopedia.com/definition/32411/doxware; disponible en marzo/2017

[8]       Fuente: https://www.quora.com/What-is-Doxware-Malware; disponible en marzo/2017

[9]       Fuente: http://www.independent.co.uk/life-style/gadgets-and-tech/news/online-abuse-internet-sexting-doxxing-trolling-new-legal-guidelines-crime-prosecution-service-a7353536.html; disponible en marzo/2017

Internet de las cosas -IoT

Según Gartner, el “Internet de las cosas (IoT) es la red de objetos físicos que contienen tecnología incorporada para comunicarse y detectar o interactuar con sus estados internos o con el entorno externo”[1]; y añade que “el valor real del Internet de las cosas va más allá de los dispositivos interconectados”[2][3].

La interacción crea más datos (más complejidad en su tratamiento, más aplicaciones, mejores y más seguras que los traten, mayor necesidad de almacenamiento y procesamiento); la comunicación acarrea más riesgos que deben ser apropiadamente gobernados, una necesidad de mayor y mejor gestión de servicios (decisiones de toda índole más difíciles, para usuarios y operadores); las condiciones actuales y posibilidades futuras requieren recursos y capacidades diferenciados para asegurar que se mantiene el valor de los servicios (que promulga ITIL®) que entregamos –la sostenibilidad operativa.

Todos estamos involucrados y somos responsables del buen o mal uso que hagamos del IoT, en todo nivel. Además, debemos considerar que hay muchas cosas que considerar[4]: capacitación, público objetivo, requisitos de construcción, servicios incorporados, dispositivos (tipos, compromiso de seguridad, manipulación no autorizada[5], otros), disponibilidad, aplicaciones, redes, conectividad, plataforma tecnológica, ecosistema, riesgos directos e indirectos, actualizaciones de firmware o de software, aplicaciones que incorporen la seguridad desde el diseño, la arquitectura de las aplicaciones a este respecto, cifrado de datos, protección de datos personales, categorización de datos, datos sensibles en general, control de acceso, normativas, regulaciones, estándares, metadatos de los dispositivos, sistemas de monitorización y de protección contra intrusiones y ataques, tanto a nivel individual como colectivo[6], monitoreo continuo, localización de los datos porque lo que es delito informático en un país puede no serlo en otro, resiliencia[7], confidencialidad, integridad y disponibilidad, entre muchas otras posibilidades.

IoT no es una cosa; es la integración de varias cosas en una solución de negocio, es el corazón del negocio digital –bueno, cuando ya no sea una buzzword y realmente se de una transformación digital y contemos con tecnología concreta utilizable hasta en nuestros hogares[8] y por todos (refrigeradoras que podrán avisar a sus dueños cuando no haya alimento en ellos[9] es la promesa ¿recuerdan?). Sería bueno saber cuántos y cuáles dispositivos están accediendo a nuestra red local, y algo ‘raro’ como deshabilitar el bluetooth y las funciones que los dispositivos no usan todo el tiempo[10]. No queremos que “alguien” nos haga “gastar” más electricidad de lo habitual. Ya conocemos las deficiencias de seguridad existentes, que no nos pesquen desprevenidos, por ellas al menos[11].

[1]       Fuente: http://www.gartner.com/it-glossary/internet-of-things/; disponible en marzo/2017

[2]       Fuente: http://www.gartner.com/technology/research/internet-of-things/?s=1; disponible en marzo/2017

[3]       Fuente: http://view.ceros.com/gartner/iot/p/1; disponible en marzo/2017

[4]       Fuente: https://ricveal.com/blog/10-retos-seguridad-iot/; disponible en marzo/2017

[5]       Fuente: http://aunclicdelastic.blogthinkbig.com/el-reto-de-la-seguridad-en-iot/; disponible en marzo/2017

[6]       Fuente: http://www.csuc.cat/es/internet-of-things-un-reto-para-la-seguridad; disponible en marzo/2017

[7]       Fuente: http://www.ibm.com/developerworks/ssa/library/iot-trs-secure-iot-solutions1/index.html; disponible en marzo/2017

[8]       Fuente: http://techcetera.co/el-reto-para-la-seguridad-para-el-internet-de-las-cosas/; disponible en marzo/2017

[9]       Fuente: http://www.nacion.com/tecnologia/informatica/Seguridad-principal-reto-Internet-Cosas_0_1571442852.html; disponible en marzo/2017

[10]     Fuente: http://techcetera.co/tiene-el-internet-de-las-cosas-iot-algun-riesgo-para-su-hogar/; disponible en marzo/2017

[11]     Fuente: http://www.symantec.com/content/en/us/enterprise/media/security_response/whitepapers/insecurity-in-the-internet-of-things.pdf; disponible en marzo/2017

Una relación entre la información [de calidad] y la [buena] motivación…

En la actualidad, el valor diferencial de una empresa radicará en cómo gestiona y explota su información[1]. La información es explotada por los equipos de trabajo.

Obvio, ¿cierto? Refraseo lo anterior pero emplearé el término colaborador y no fuerza laboral, trabajador, empleado, personal, mano de obra calificada, recurso/talento humano, funcionario, servidor [público], entre otros calificativos, para establecer que es una persona que da su contribución de manera integral[2] convirtiéndose así, por su individualidad (habilidades, conocimiento, experiencia), en el real diferenciador de la empresa.

La información [de calidad] es explotada por los equipos de trabajo, los [equipos de trabajo] que deberían estar conformados por colaboradores comprometidos [con la calidad] en su generación [redundo, de la información].

El compromiso del colaborador es la combinación del orgullo, la energía y el optimismo que alimenta su esfuerzo discrecional y su intención de quedarse[3].

El esfuerzo discrecional es todo aquel esfuerzo (energía e inspiración[4]) que, de forma espontánea y voluntaria realiza un empleado por encima del nivel mínimo requerido para conservar su puesto de trabajo[5] ¡qué tal motivación! Y, claro, sin presiones ¿verdad?

Bueno, lo cierto es que, para lograr lo anterior, las empresas han presionado y continúan presionando a sus colaboradores, con lo que han fomentado el estrés laboral y han llevado a una mayor rotación y a una menor motivación [de los colaboradores]. Esto es un riesgo, y los estrategas se enfrentan [además] a la [su] resistencia interna cuando tratan de presentar un plan para considerar las amenazas a largo plazo[6], plan producto muchas veces de un proceso de planeamiento mecánico también de corto plazo por tener que cumplir metas igualmente de corto plazo (ayer me solicitaron actualizar catorce proyectos de envergadura internacional para hoy), por miedo al fracaso (hicimos como organización en tres días lo que sabíamos demanda siete, porque el jefe lo exigió, y por supuesto que hubo quejas con los resultados), y por preocupación por aspectos operativos[7] (por ejemplo: aumento de la tasa de intercambio de información y aumento de la tasa de innovación[8] requerida para atender la demanda de los clientes; adopción de nuevos conceptos, filosofías, metodologías, normas, buenas prácticas; cambio de paradigmas). No interiorizan aún que el pensamiento a largo plazo (proactividad verdadera, prevención) es lo importante que impulsa el crecimiento.

Olvidamos completamente la retroalimentación positiva continua, para sentirnos personas capaces, confiadas y fuertes, y no sólo darla en la reunión de fin de año –como una vez más he sido testigo. Olvidamos que, como personas, valoramos en diferentes grados (por ejemplo, tomando en cuenta la Pirámide de Maslow) y de acuerdo a nuestra generación (millenials, baby boomers, X, Y, Z, otros[9]), contar con oportunidades de desarrollo, desafíos, logro personal, futuras oportunidades de carrera, estabilidad, un adecuado ecosistema laboral, una adecuada y oportuna comunicación y retroalimentación, un sano balance entre vida personal y trabajo, estrategias de responsabilidad social, tasa de crecimiento, y saber que existe y que se da una auténtica meritocracia, entre otros factores de satisfacción.

Aún no confiamos en la persuasión, sino en el poder y lo que conseguimos es sumisión -temporal, mero cumplimiento –y encima mal cumplimiento (por ejemplo, un órgano de calidad que aprueba diagramas de flujo mal hechos, incluso con base en sus propios lineamientos); no logramos para el futuro la interiorización, menos compromiso educado y consciente (involucramiento[10]) –querer hacer lo que se debe[11].

Se habrán dado cuenta que, potencialmente, si incurrimos en los errores y mantenemos los riesgos antes descritos –y sus interdependencias, la información que obtendríamos (los datos son un activo corporativo crucial), con la que deberemos tomar decisiones, no sería de calidad (una mala supervisión de la política de información impide la productividad y crea vulnerabilidades[12]) y, por consiguiente, los resultados podrían ser desastrosos. No olvidemos que debemos gestionar el conocimiento.

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

[2]   Fuente: http://www.gestiopolis.com/obrero-a-colaborador-transicion-incompleta-empresas/; disponible en dic/2016

[3]   Fuente: https://www.cebglobal.com/content/dam/cebglobal/us/EN/best-practices-decision-support/innovation-strategy/pdfs/ceb-strategy-engagement-insights.pdf; disponible en dic/2016

[4]   Fuente: http://factorhuma.org/index.php?option=com_content&view=article&id=2814&catid=4&Itemid=11&lang=es; disponible en dic/2016

[5]   Fuente: http://www.marketingdepymes.com/sala-de-lectura/instrumentos/los-esfuerzos-discrecionales-la-clave-de-la-motivacion; disponible en dic/2016

[6]   Fuente: https://www.cebglobal.com/content/dam/cebglobal/us/EN/best-practices-decision-support/innovation-strategy/pdfs/ceb-strategy-influence-key-stakeholders-white-paper.pdf; disponible en dic/2016

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

[8]   Fuente: https://www.cebglobal.com/content/dam/cebglobal/us/EN/best-practices-decision-support/innovation-strategy/pdfs/CEB-R&D-Accelerating-Speed-to-Market.pdf; disponible en dic/2016

[9]   Fuente: http://www2.cipd.co.uk/pm/peoplemanagement/b/weblog/archive/2016/12/12/rethinking-age-at-work.aspx; disponible en dic/2016

[10] Fuente: http://www.apoyo.com/engagement-mas-alla-del-compromiso-del-colaborador/; disponible en dic/2016

[11] Fuente: http://www.thinkingpeoplerecursoshumanos.es/desarrollo-de-rr-hh/compromiso-del-empleado/; disponible en dic/2016

[12] Fuente: https://www.cebglobal.com/content/dam/cebglobal/us/EN/best-practices-decision-support/finance/pdfs/ceb-first-quarterly-journal-q4-2016.pdf; disponible en dic/2016