Tag Archives: gestión de calidad

Feb 11 2018

¿Problemas en TI?

Algunos indicios

Usualmente los problemas empiezan cuando somos los últimos en enterarnos de los cambios en la estrategia del negocio.

Los usuarios dejan de quejarse –porque han optado por el shadow IT, la organización está implementando mecanismos alternativos de soporte a usuarios, mecanismos alternativos de operación y, luego, posiblemente, ocurran despidos y rotación o traslado de personal.

Los usuarios dejan de llevarnos sus grandes ideas. Esto podría deberse a que el gerente de TI no fomentó una cultura de colaboración y experimentación, a una falta de madurez o mucho ego.

Ya no es copiado en los correos institucionales –mejor pensamos, las reuniones eran improductivas.

Seguramente hemos comenzado a ver personas extrañas circulando por la empresa, o se nos han asignado “ayudantes” para apoyarnos con la carga de trabajo.

Expectativas no aterrizadas sobre el ritmo esperado del cambio, o resistencia burocrática al cambio producto de un estancamiento de la organización a nivel alto.

No se evidencia una articulación con la estrategia. Se pide conexión con los clientes y generar ingresos, a la vez que se debe reducir costos y mejorar las eficiencias operativas.

Pero seguramente nosotros mismos somos parte de la ecuación –y lo negamos, ya sea consciente o inconscientemente

La deuda técnica y/o la obsolescencia técnica probablemente nos mantengan realizando los mismos trabajos, o resolviendo los mismos problemas, una y otra vez.

Nos escudamos en la falacia del costo perdido, del costo hundido, cuando la mejor solución es deshacerse de los viejos sistemas problemáticos y comenzar de cero con otros nuevos, capitalizando el conocimiento aprendido de esa [mala] experiencia.

De alguna manera estamos cautivos de algún proveedor. Tal vez nos encandiló una funcionalidad aún no [suficientemente] explotada, porque no estamos preparados para capitalizar esta funcionalidad [y, peor, tal vez nunca lo estaremos]. O porque buscamos [obtuvimos] el precio más bajo [CAPEX], sin considerar el [OPEX]. O porque era más fácil gestionar al proveedor que implementaba la “solución”, que [realmente] conocer dicha solución.

Consideramos que, como se habla de nubes híbridas, la nube puede ser una extensión de nuestro centro de datos. Debemos detenernos y considerar –bastante- que hay diferentes SLA (¿o la nube no nos cuesta diferente a nuestro centro de datos?).

Preparamos un caso de negocio “técnicamente sólido”. Pero perdemos de vista el objetivo –y, peor, no utilizamos el lenguaje- del negocio.

Aplicar metodología ágil a los sistemas centrales. Querer ser una bimodal 2.0 cuando tenemos que evaluar primero nuestra posición como bimodal 1.0. Tal vez si realizamos una evaluación previa y logramos acotar el alcance o conveniencia, con el correcto balance entre agilidad y estabilidad…

O los clásicos que argumentamos

Decir sí a todo –o a casi todo, sin buscar ser asertivo, para darnos tiempo de  realizar las evaluaciones correspondientes. Manejamos proyectos ¿verdad?

Pretender esconder los problemas, creyendo que se podrán resolver antes que nuestro superior se entere. Gestionamos las comunicaciones, y los cambios, como parte de la gestión de proyectos y de la gestión de servicios ¿verdad? O utilizando la técnica del oscurantismo.

Contratar [o no contratar] (por ego) o promover (por conveniencia) al candidato equivocado. Olvidar que la destreza ganada a través de la experiencia importará menos que la habilidad de aprender otras nuevas destrezas.

Mantener el dilema ético de ser juez y parte –y saber gestionar [sobrellevando y asumiendo] lo que viene después.

No identificar y menos ejecutar las acciones correctivas necesarias.

Conflictos de poder.

La tecnología es [siempre, o casi siempre] la culpable –pero no buscamos una real solución.

Esbozar que la innovación o búsqueda de la mejora continua no está en el manual de funciones por las que fuimos contratados.

Realizar tareas sólo por cumplimiento normativo, regulatorio, legal, ya sea local o internacional, dependiendo del ámbito de actuación de la organización.

Falta, pero empecemos por lo siguiente

Debemos sentirnos cómodos con abrazar el fracaso. Debemos enfrentarlo (somos profesionales) -y aprender (es nuestra habilidad innata).

De igual manera, debemos aceptar los resultados de una [real] auditoría de TI –y definir y ejecutar las acciones correctivas necesarias.

Evitando que sea el usuario final el que nos reporte un incidente.

Asegurar los SLA comprometidos.

May 1 2017

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

Abr 25 2017

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.
Mar 21 2017

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

Feb 27 2017

El Modelo Esencial. ¿Qué modelar en el Análisis? ¿El Sistema Actual? ¿El Sistema Futuro? Los detalles de implementación ? Los requerimientos esenciales. – ppt descargar

El Enfoque Clásico: Modelo Físico Actual – Modelo Lógico Actual – Modelo Lógico Futuro – Modelo Físico Futuro

Origen: El Modelo Esencial. Que modelar en el Análisis? El Sistema Actual ? El Sistema Futuro ? Los detalles de implementación ? Los requerimientos esenciales. – ppt descargar

Ago 17 2016

DevOps – ITIL: riesgos y oportunidades

DevOps es un término con diferentes significados para diferentes personas. De hecho, no hay –aún- algo como un “manifiesto”.

Tampoco es que un NetOp o un SysAdmin o algún otro rol se conviertan por arte de magia en un DevOp[1]. Tampoco es una tecnología en concreto[2]. No se trata de resolver un problema de TI sino de innovación, del negocio.

Bueno, sí, la relación entre desarrollo de software (valor traducido en la funcionalidad requerida) y operaciones (valor traducido en estabilidad tangible) está en las siglas pero, por la literatura que circula al respecto, aún no hay una definición estándar[3]. Pero, de hecho, usualmente encontramos  el “yo me ocupo sólo de mi parte” o “en mi máquina funciona, es tu problema” o “es tu culpa”[4], entre otros muchísimos aspectos sociales o técnicos de la “relación”; así, la palabra “relación” es circunstancial –algo que DevOps e ITIL buscan eliminar.

devop01

Está el enfoque técnico pero también está la necesidad del negocio. Las personas, los procesos y la tecnología van de la mano en este moderno enfoque estratégico.

devop02

De hecho, cada negocio es distinto y cada empresa tendrá que analizar la velocidad de los despliegues y la frecuencia de los mismos para someter a consideración la más apropiada y mejor alternativa de solución –una solución a la medida para cada empresa, considerando que a algunas les contará más trabajo que a otras la adopción de este paradigma[5]. Flexibilidad, adaptabilidad y velocidad son aspectos que los usuarios y clientes valoran de los servicios que consumen porque están convencidos de que con estos servicios logran una ventaja competitiva -pueden llegar a ser más eficientes, efectivos, productivos.

devop03

En la siguiente figura se muestra la brecha entre Dev y Ops:

devop04

Así, es requerida una plataforma tecnológica (hardware, software, infraestructura) altamente automatizada (pruebas de código incluidas), con un flujo de trabajo automatizado (versiones, personalizaciones, configuraciones), y monitorizada de forma continua para asegurar que se cumple con los niveles de servicio comprometidos por el negocio (se valida y verifica que se alcanzan los objetivos estratégicos) y que el servicio está garantizado ya que satisface los requerimientos de: seguridad (seguridad de la información por supuesto, una necesidad en la estrategia DevOps[6] para generar confianza); capacidad (rendimiento, escalabilidad, tanto del hardware y software base como de las aplicaciones); disponibilidad, continuidad; soporte; confiabilidad –recordemos la garantía de valor según ITIL; ¿estarán los procesos de la organización preparados para este paradigma?

devop05

En ambos entornos hay bastante que mejorar ya que lo requerido por el negocio es la satisfacción del cliente o consumidor con el servicio recibido (el valor del servicio estratégico que ha sido diseñado y transicionado a producción se valida, verifica y aprecia en la operación con el cumplimiento de los SLA). Esto implica poner en práctica las mejores recomendaciones de nunca pasar un defecto conocido por los centros de trabajo, de no permitir nunca que una optimización local o particular genere una degradación global, de siempre buscar incrementar la fluidez de las comunicaciones, y de siempre buscar alcanzar una profunda comprensión del sistema (según Deming). Debemos entonces tener en cuenta el rendimiento del servicio completo, de extremo a extremo, y no de individuos, componentes, áreas o departamentos por separado.

La retroalimentación es entonces clave para saber y reconocer si las expectativas del negocio se están aterrizando completa y correctamente[7] –preguntemos a los stakeholders su visión y apreciación holística de los resultados[8]. Entendamos y respondamos sus inquietudes, acerquemos y amplifiquemos los lazos de retroalimentación cuando y donde sean necesarios, incorporemos el conocimiento donde –con conciencia- lo requiramos. ¿Serán efectivos los procesos de gestión de cambios, de configuraciones, de versiones, de accesos, y de problemas, entre otros?, ¿estarán a la altura de las nuevas necesidades?, ¿estarán a punto los ambientes de prueba necesarios[9]?, ¿estamos midiendo los resultados esperados –el valor para el cliente- o todavía medimos salidas de componentes/sistemas/áreas/departamentos individuales? Las profesiones son diferentes (know-how, habilidades, conocimientos, necesidades de capacitación, etc.), los roles son diferentes, y es claro que la responsabilidad es compartida[10].

Los marcos de trabajo y herramientas también son numerosas y diferentes para cada profesión; usualmente hablamos de “llevar” a la nube y tal vez también sea bueno considerar “traer” de la nube. Incluso las diferentes herramientas que existen también tienen enfoques digamos, “sesgados” en uno u otro entorno. Sin embargo, hay buenas noticias: existen varias alternativas; pero también hay malas noticias: existen varias alternativas. Esto implica adoptar e interiorizar una cultura que fomente: (a) experimentación continua, correr riesgos y aprender de los fracasos –la búsqueda de la innovación, reducir el “time-to-market”, salir de nuestra zona de confort, entre otros aspectos positivos; y (b) la comprensión de que la repetición y la práctica es el requisito previo para la maestría –incrementar la resiliencia, estabilidad, garantía, cumplimiento, seguridad de la información, eficiencia, efectividad, rapidez, flexibilidad y adaptabilidad para responder a nuevas o cambiantes necesidades, empleo eficiente de modernas tecnologías disruptivas, entre otros beneficios. Integrar las diferentes alternativas de solución es lo importante –y es lo riesgoso para el negocio, aunque a nosotros los especialistas esta integración nos resulte interesante. ¿Cuánta integración es necesaria, en cuántas fases lo lograremos, cuál es el plazo o cuáles son los plazos, quién realizará esta integración (o con quién), con qué se realizará?, son algunas preguntas que deberemos responder.

Requisitos y beneficios podrían verse mezclados y esto podría ocasionar confusión –y problemas- en su adopción; así, cada empresa deberá establecer los principios, métodos y prácticas DevOps que sean más apropiados para sus negocios.

Creo que a todos nos duele la cabeza el sólo pensar las mejoras que debemos implementar en nuestros respectivos ecosistemas tecnológicos, empezando por un cambio de cultura para eliminar los silos; aportar transparencia en las actividades de desarrollo y de operaciones; adoptar e interiorizar la calidad[11] y la colaboración[12]; trabajar en equipo, de forma más cercana, en un marco de respeto mutuo, generando confianza, aportando mayor agilidad al negocio y notables incrementos de productividad[13]; establecer procesos y responsabilidades claras; identificar mejoras necesarias en los procesos, tecnología y capacidades, habilidades, y conocimiento de las personas.

Para tener éxito con un DevOps disciplinado, necesitamos ocuparnos de las 5P de la mejora[14] (donde tal vez sean las personas lo más importante, como ya hemos visto):

  • Propósito/Objetivo: involucra todos los elementos que constituyen la intención de la organización. Esto incluye la misión, visión, objetivos y estrategias de la organización. Implica identificar los principales puntos fuertes, puntos débiles, oportunidades y amenazas;
  • Principios: son las filosofías que guían la empresa, los supuestos, o actitudes sobre las que la organización debe operar y cómo debería conducir sus negocios. Esto incluye la base de integridad, ética, y valores nucleares a los cuales se espera que los empleados se comprometan cuando son contratados. Implica identificar la cultura y los valores de la organización;
  • Procesos: son las estructuras organizacionales, sistemas, y procedimientos que se utilizan para fabricar los productos o desarrollar los servicios que provee la organización, así como la infraestructura y reglas que apoyan estos sistemas y procedimientos. Implica una lista de todos los procesos y exponerlos mediante diagramas de flujo, mapas de procesos, técnicas como 6W-2H; identificando los responsables de cada proceso;
  • Personas: son los individuos (y equipos de personas) que realizan el trabajo que es consistente con los Principios y Procesos de una organización para lograr su Propósito. Son los componentes activos que obtienen resultados. Implica determinar en qué medidas las personas están calificados para las funciones que desempeñan; identificar las necesidades de formación;
  • Rendimiento: involucra todas las métricas, mediciones y resultados esperados que muestran el estado de la organización, y son utilizados para la toma de decisiones. Los resultados son re‑alimentados al proceso de gestión estratégica con el fin de proveer retro‑alimentación y control. Implica identificar las medidas de rendimiento usados; establecer indicadores clave de rendimiento (KPI); establecer un sistema métrico.

El modelo de negocio determinará el marco de trabajo, mejor práctica, o norma que se empleará[15] y el contexto en el que actuarán (ITIL y DevOps, por ejemplo, complementándose ambos), enderezando el timón cuando y cuantas veces sea necesario. Es buscar agregar/obtener valor a/de los servicios que la empresa entrega. Esto implica buscar convertirnos en seres realmente proactivos –una nueva especie en el mundo informático de más de una empresa.

[1]       Fuente: https://www.quora.com/Is-DevOps-the-new-name-for-SysAdmin-Why-are-all-DevOps-tools-related-to-infrastructure-and-system-admin; disponible en agosto/2016

[2]       Fuente: http://searchdatacenter.techtarget.com/es/consejo/Definicion-de-DevOps-mejor-explicamos-lo-que-no-es; disponible en agosto/2016

[3]       Fuente: https://www.youtube.com/watch?v=o7-IuYS0iSE; disponible en agosto/2016

[4]       Fuente: http://es.slideshare.net/therobot/que-demonios-es-eso-de-devops-y-porquedebera-interesarme; disponible en agosto/2016

[5]       Fuente: http://www.javiergarzas.com/2014/12/devops-en-10-min.html; disponible en agosto/2016

[6]       Fuente: https://www.newcontext.com/devops-needs-security/; disponible en agosto/2016

[7]       Fuente: http://itrevolution.com/the-three-ways-principles-underpinning-devops/; disponible en agosto/2016

[8]       Fuente: http://www.drdobbs.com/architecture-and-design/getting-devops-right-the-lay-of-the-land/240062639; disponible en agosto/2016

[9]       Fuente: http://www.itproguy.com/devops-practices/; disponible en agosto/2016

[10]     Fuente: https://www.youtube.com/watch?v=_I94-tJlovg; disponible en agosto/2016

[11]     Fuente: https://www.paradigmadigital.com/techbiz/que-es-devops-y-sobre-todo-que-no-es-devops/; disponible en agosto/2016

[12]     Fuente: http://blog.itlinux.cl/blog/2013/10/23/que-es-devops/; disponible en agosto/2016

[13]     Fuente: http://www.claranet.es/devops-que-es-y-como-lo-aplicamos-como-proveedor-de-cloud-hosting; disponible en Agosto/2016

[14]     Fuente: http://www.12manage.com/description_pryor_5_ps_model.html; agosto/2016

[15]     Fuente: http://www.ca.com/us/rewrite/articles/devops/devops-and-itil-always-let-your-business-context-be-your-guide.html; disponible en 2016

Jul 9 2016

Seguridad de la información? –sí, seguridad de la información

Un(a) estudiante reclamó alguna vez por su nota argumentando que había respondido la mayoría de las preguntas a un examen de carrera, en ciclo avanzado.

Sin embargo, su argumento es una falacia ya que no se puede inferir que, a más preguntas respondidas se debe obtener una mayor nota. Hay diversos y muchos factores que considerar.

Sabemos que la nota obtenida en cada examen siempre es una función de la calificación otorgada a todas y cada una de las respuestas a las preguntas formuladas en cada examen, tomando como base el puntaje propuesto para cada pregunta. Así, la calificación varía de acuerdo con la exactitud o la calidad de la respuesta formulada, dependiendo del contexto en que se desarrolla la materia evaluada. La exactitud está representada por la capacidad de memoria del estudiante al repetir un texto palabra por palabra, o por proporcionar el resultado correcto a un problema matemático. La calidad es el nivel de comprensión y dominio que el estudiante demuestra haber alcanzado en la materia. La calidad de las respuestas es algo que se debe evaluar en forma de conocimiento adquirido y aplicado correctamente.

Haciendo una extrapolación –forzada si gustan- hacia la seguridad de la información, tendemos a exagerar –por encontrar un término amable- nuestra posición frente a cuánta seguridad de la información o controles de seguridad tenemos implementados (o hemos logrado implementar) en la plataforma tecnológica de nuestra responsabilidad, pero no tenemos una base concreta para sustentar la calidad de esta seguridad y la continuidad de nuestra confianza en el ecosistema de seguridad desplegado.

Bueno, es posible que me equivoque en esa apreciación pero, ¿serán suficientes las auditorías internas para evaluar esta calidad? Por seguridad, díganme que primero han sincerado los recursos y capacidades asignados o comprometidos en garantizar la disponibilidad de la plataforma tecnológica desplegada, la integridad de los datos que almacenamos, procesamos o transmitimos, y la confidencialidad de estos datos; a continuación han sincerado los criterios que determinan la (su) confianza en las medidas de seguridad desplegadas; y luego evalúan los resultados de los indicadores implementados para establecer que la seguridad de la información no se ha visto comprometida. Porque sí han sincerado los recursos y capacidades, han establecido criterios de evaluación, han implementado los indicadores necesarios y apropiados, realizan mediciones según han planificado y toman las acciones correctivas necesarias ¿verdad?

Jul 3 2016

Algo sobre ciberseguridad

Cierto, la ciberseguridad nos preocupa[1] y por ello debemos ocuparnos en entender nuestros propios ambientes de operación y por controlar las puertas y ventanas abiertas en el plano digital de nuestro ecosistema, identificar los riesgos y determinar el verdadero impacto que un incidente podría tener para nuestro negocio.

¿Sería bueno esforzarnos en realizar un FODA de nuestra seguridad de la información? No sólo situacional sino, además, estratégico. ¿Mantenemos actualizados nuestros activos de información? ¿Qué dejamos de proteger y por qué? ¿Qué nos falta por hacer o mejorar? ¿Qué recursos y capacidades están involucrados, han sido desplegados y han sido comprometidos en los servicios que entregamos[2]? ¿Existen limitaciones o restricciones, cuáles y por cuánto tiempo lo serán? ¿Hemos implementado algún tipo de ‘ciber’ defensa como los antiguos honey pot ¿los recuerdan?, con la finalidad de conocer el comportamiento de algún atacante dentro de nuestra plataforma tecnológica así como las técnicas que podría utilizar? ¿Es mejor invertir en herramientas de seguridad, o en la construcción de sistemas –no sólo de información- con un menor número de vulnerabilidades? ¿Cuáles herramientas, cuáles sistemas? ¿Empezamos?, ¿con qué empezamos? ¿Hemos desarrollado algún cronograma para realizar las evaluaciones? ¿Qué hay de las acciones de monitoreo y control? ¿Cuáles son los sistemas críticos para la operación de la empresa, de su día a día? ¿Qué servicios de TI que ya gestionamos o estamos todavía diseñando son los primeros que debemos considerar en nuestra evaluación de su seguridad de la información? ¿Cuáles serán los criterios de aseguramiento de calidad y de control de calidad que estableceremos para esa evaluación? ¿Consideramos la mejora continua en todos los casos? ¿Cómo han sido personalizados y configurados estos servicios cuya información debe permanecer segura? ¿Estamos gestionando los cambios a los servicios que podrían afectar la seguridad del ecosistema actual? ¿Estamos gestionando las configuraciones de los servicios en cuanto a la seguridad de la información? Humm.

No nos es extraño que cuanta mayor y mejor tecnología exista, más elaborados son los ataques y en mayor cantidad, y que no precisamente son realizados por gurús. Además, cada vez es más complicado y toma tiempo identificar el punto de entrada y el número de registros o dispositivos que se han visto comprometidos. Seguramente ya pasamos por el mantra de: conocer dónde se encuentran los datos, sobre todo los identificados, catalogados y tratados como sensibles –sin olvidar cómo, dónde y con qué se procesan o transmiten (no olvidemos a dónde y de qué manera); monitorizar el ciclo de vida de los datos; otorgar permisos según la política consabida de necesidad de conocer, gestionando identidades y autorizaciones según corresponda –recordemos el concepto IAM[3]; protegernos del malware; utilizar apropiadamente (adoptar y adaptar) el concepto BYOD; utilizando las capacidades integradas de los dispositivos móviles; aislando y ocultando dispositivos terminales según sea necesario o prudente; educación, interminable, constante, continua, actualizada, personalizada, activa y de calidad, entre otros atributos; concientizar; comunicar; entender para prevenir, descuidos y comportamientos de los usuarios con relación a la seguridad de la información.

Entonces, entendiendo nuestra organización, qué se debe proteger, y los riesgos que enfrenta, debemos enfocar lo mejor posible nuestros esfuerzos en cuanto a gestionar el riesgo a fin de motivar la adopción de una postura acorde con el grado de exposición y lo crítico de una situación porque sabemos que existen muchas variables a considerar de forma responsable, entre otras, las operativas, humanas, funcionales y tecnológicas. No olvidemos que los riesgos permanecen en cambio constante, más con el grado actual de globalización el cual incrementa el entorno de las amenazas modernas alterando –por decirlo gentilmente, y si está vigente, cualquier plan de respuesta a incidentes.

Es decir, debe existir una estrategia de seguridad exhaustiva con objetivos de seguridad y medidas alineadas con las estrategias empresariales y metas, donde la seguridad sea una prioridad en la mente de todos y sujeta a una evaluación y reevaluación continua, con alternativas de análisis de datos de calidad que ayuden a proteger información confidencial –para que funcionen realmente opciones como DLP y SIEM, y que podamos determinar cuáles posturas de seguridad que se han adoptado han sido las más efectivas.

[1]      Fuente: http://docs.media.bitpipe.com/io_13x/io_131511/item_1334211/HB_Consejos%20de%20ciberseguridad%20para%20las%20empresas%20de%20hoy_final.pdf; disponible en julio/2016

[2]      Fuente: http://learn.alienvault.com/5-security-controls-or-an-effective-soc/home; disponible en julio/2016

[3]      Fuente: http://www.itnews.com/article/3088084/security/gartner-s-top-10-security-predictions.html?token=%23tk.ITN_nlt_ITnews_Daily_2016-06-24&idg_eid=0f3e0907b81179ebb4f3b209b6424bae&utm_source=Sailthru&utm_medium=email&utm_campaign=ITnews%20Daily%202016-06-24&utm_term=ITnews_Daily; disponible en julio/2016

Jun 9 2016

COBIT 5 Fundamentos

Introducción

Este curso se preparó para Sistemas UNI, junio/2016.

Sumilla

COBIT® 5 ayuda a maximizar el valor de la información mediante la incorporación de las últimas técnicas de Gobierno y Gestión de la empresa.

En consecuencia, el curso busca proveer al interesado principios y prácticas mundialmente aceptadas así como herramientas analíticas y modelos para ayudar a incrementar la confianza y el valor de sistemas de información alineados con los objetivos del negocio.

El curso está dirigido, pero no limitados a, los siguientes interesados:

  • Ejecutivos de negocios
  • Dueños de procesos de TI, responsables de la función de TI
  • Responsables de riesgos y de implementar y asegurar controles, responsables de evaluar y auditar los controles de TI, responsables del cumplimiento, aseguramiento y control interno de TI, profesionales en aseguramiento de calidad de TI
  • Proveedores de servicios de TI, prestadores de servicios de TI, terceros responsables de apoyar la función de TI
  • Usuarios de TI
  • Cualquier interesado en el gobierno corporativo de TI y en la generación de valor para el negocio.
Feb 20 2016

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

La computación en nube es un acontecimiento disruptivo en TI[1] –no es novedad, así como la movilidad, la seguridad, Big Data y las redes sociales (mayor cobertura con los smartphones y sus cada vez mayores funcionalidades) son factores disruptivos para los actuales modelos de negocio.

Como suele ser el caso, lo que debe hacerse en primer lugar como factor competitivo diferenciador [mayor conocimiento, mejor organización del conocimiento, mejores decisiones, mejor gestión de riesgos, entre otros beneficios], es establecer un fuerte enfoque de liderazgo en el cultivo de una cultura centrada en los datos (articulados claro con los objetivos del negocio) [implica tecnología, herramientas, experiencia, talento, cultura organizacional y, claro, liderazgo –nada nuevo ¿verdad?] pero esto casi siempre sucede en último lugar[2].

Además, [trabajar con, para y en] la nube requiere un conjunto único de habilidades del personal responsable de TI[3] -tampoco es novedad, si está esto bien enfocado.

¿Un ejemplo de enfoque? Como vi en una convocatoria CAS hace unos días, solicitaban un abogado especializado en planes de contingencia, con maestría en gestión pública, y experiencia en el cargo de más de cinco años en empresas extranjeras –por S/.4,500 Nuevos Soles mensuales. Dieron en el clavo los que señalaron que esta convocatoria quedó desierta –y no creo equivocarme que fue por el monto a pagar (nadie se presentó) más que por cumplimiento del perfil. No sería de extrañar que contraten un extranjero que “dice” cumple con los requisitos y pagándole más de lo presupuestado, utilizando alguna argucia legal porque: no se encuentra el profesional “calificado” en Perú [uno al que [podamos baratear exprimiendo su necesidad para] pagarle lo “presupuestado” por realizar las “funciones del cargo” [lo que deberían hacer varios profesionales y no uno] que [no] han pasado apropiadamente por los filtros correspondientes para efectuar la definición funcional correspondiente] –y después nos quejamos de los resultados. ¿O será que se requiere en realidad un servicio de consultoría y no debe entonces canalizarse como CAS? ¿Aspectos presupuestales o Pepe el vivo?

O el caso –que seguramente todos conocen y hasta vivido (yo sí pero fue descubierto a tiempo –de por medio, monitorización y trazabilidad ¿mencioné auditoría?, análisis del entorno económico-político [hacia dónde se dirigen las cosas], conocimiento del ecosistema, ¿ya planteé riesgos?)- de un administrador de sistemas “motivado” para “impactar negativamente” en la organización[4].

Y en el contexto de nube privada, seguramente [espero] los CIO no estarán pensando en [sugiero que no] reducir personal, por lo menos no bajo la ‘perspectiva’ de “verse” más [hum, digamos] eficientes [paraguas usualmente mal utilizado]. Antes seguramente han pensado en cómo proteger [y asegurar claro] la propiedad intelectual empresarial del servicio que se entrega ¿verdad que primero ya implementaron un buen sistema de gestión del conocimiento que funciona en toda la organización [me refiero a que es operado, actualizado, utilizado, optimizado], que está interiorizado y está sujeto a mejora continua con base en procedimientos documentados?

Flexibilidad, agilidad y ahorros económicos son los principales motivos –en adición a “sentirse en” control de la seguridad o justificar la “soberanía” de la información, independiente de su localización geográfica, lo que limita la adopción de este paradigma. Estos son viejos desafíos para las empresas y “bussiness as usual [el día a día]” para los equipos de TI [el proveedor interno]. Viejas historias.

No olvidamos el planeamiento previo, profundo y concienzudo que debemos hacer –para evitar errores [¡hey!, ¿no somos humanos?]. Sí, lo reconocemos [y no hay forma de olvidarlo] y algunos dirán que es mejor pensar conforme avanzamos [haciendo… bueno… depende de -o teniendo que aceptar- lo que resulte…]. Al respecto nuestras experiencias son variadas –por ponerlo amable. El diseño, implementación, gestión y mantenimiento de una nube privada es algo complejo –e intimidante para algunos. Sí, sí, cuento con algunas certificaciones al respecto [por lo que puedo hablar del tema] pero igual me intimido por supuesto, por las expectativas puestas en los proyectos –sobre todo si no contamos [o resulta “difícil” contar] con los recursos suficientes y apropiados, tanto humanos como materiales, pasando por plazos, factores externos, apoyo interno [la organización en su conjunto] y externo [proveedores, otras organizaciones], difusión y comunicación apropiada del proyecto [a TODOS los INTERESADOS], entre otros pero no únicos factores a considerar.

Sí, están las nuevas operaciones –propias del nuevo entorno de servicio entregado [suena bien y estamos ansiosos por trabajar en lo nuevo ¿verdad?]- y las legacy –propias del día a día [claro, las ahora aburridas (pero que no descuidamos ¿verdad? aun cuando somos humanos ¿cierto?) cuando tenemos a la vista algo nuevo], y tan habituales como la función de mesa de ayuda. Hay [hoy] normas y estándares internacionales que deberíamos seguir –y, claro, cada vez estamos más obligados [considerando lo apropiado caso por caso –es decir, con el sustento claro y completo por supuesto]. Cumplamos pero, con y por convicción, no sólo para la foto [¿el Mercado?].

Hace varias semanas estuve conversando con un cliente [una entidad pública] y su requerimiento era más tecnología, nueva tecnología, mejor tecnología. ¿Por qué y para qué? “Para operar mejor” fue prácticamente la respuesta [una horrible y muy lamentable similitud con el cuento de Perrault que escuchamos de niños]. No en balde los proveedores siempre preguntan primero si se cuenta con presupuesto y a cuánto asciende. A pesar de la redundancia y contingencia desplegada de la que hacía gala este cliente (centros de datos en activo-activo, y otras sutilezas), ocurrió un percance y ninguna redundancia o contingencia implementada lo salvó de ver sus servicios desplegados a nivel nacional paralizados –varias horas, en horario laboral. Pasado esto, ante las mismas preguntas de antes, la respuesta seguía siendo la misma.

¿Ya hablé de sostenibilidad [continuidad de operaciones sin menoscabo de la capacidad de desarrollo futuro] y sustentabilidad [las razones por las cuales invertir en la sostenibilidad o en la plataforma tecnológica para el caso]?[5] No olviden a Murphy. ¿Habrán por lo menos considerado la tercerización o externalización [claro, para aprovechar el know-how, alinear capacidades, suplir carencias, facilitar el acceso a especializaciones, economía de escala, acceder a más servicios –o mejor provistos, ampliar la oferta de servicios, optimizar costos, reducir el CAPEX [las inversiones] y optimizar el OPEX [el recurrente], mejorar la competitividad, adoptar el modelo de servicio, proporcionar continuidad al negocio, obtener resultados, entre otros motivos], o el formar un ecosistema bien balanceado con los proveedores? ¿[Aún] no? Pero seguramente ya lo están considerando ¿verdad?

Mucho que pensar ¿verdad? Y eso que falta considerar cumplimiento normativo y legal –ups, olvidé las relacionadas con certificaciones alcanzadas, cargas de trabajo a elegir entre ser procesadas localmente [nube privada] o en la nube [pública], ¿alguien dijo aplicaciones móviles?, el lidiar con la uniformidad de las plataformas en nube, o la complejidad de trabajar con nubes híbridas [qué va en dónde, cómo, cuánto y hasta cuándo], entre otros muchos factores. La mezcla correcta, por supuesto, puede variar de un cliente a otro en función de las necesidades específicas, tales como la disponibilidad, costos, el rendimiento de cada servicio en la cartera de la organización.

Gartner definió en 2012 una plataforma de gestión de nube como las capas superiores de la solución en nube e indica que se debe considerar lo siguiente:

  • Una arquitectura empresarial deservicio en nubetiene cinco nivelesde funcionalidad: gestión de acceso (auto servicio, subscripción, identidad y acceso, entre otros aspectos a considerar), gestión de servicios (proveedores, contratos, catálogo de servicio, modelo de servicio, configuración, provisión, nivel de servicio, disponibilidad, rendimiento, demanda, capacidad, finanzas, mediciones, facturación, entre otros aspectos a considerar), optimización de servicios (gobierno, orquestación, federación, entre otros aspectos a considerar), gestión de recursos (gobierno, estado, rendimiento, seguridad, entre otros aspectos a considerar), yla capasubyacente de recursos (APIs, recursos físicos y virtuales tanto internos como externos, entre otros aspectos a considerar).
  • Idealmente, las capas de servicios en nubedebenser lógicamenteindependientes entre sí, deben maximizar laflexibilidad de implementacióny debenpermitir que elpotencial de sustituciónde variosproveedores –recordemos que la arquitectura de nube no es monolítica.
  • Los servicios en nubepueden haber reducidolos requerimientosparauna capa degestión de servicios-por ejemplo,en pre-producción, donde generalmente se aplican menos procesosformalesde gestión de TI [pero debemos tener cuidado en no “aligerar” demasiado el control necesario].
  • Las empresas tienen la posibilidad de acabarcon muchosconjuntos derecursos de nube que probablemente tengan repartidos entre recursosinternos yexternos, y deberían evitar obstaculizar el desplazamiento eficiente de los recursos [diseñando y aplicando procedimientos apropiados, adecuados y optimizados].
  • Se debe evitar la dependencia de proveedores únicos, pero tener [MUCHO] cuidado de que seleccionar los componentes significa para la organización de TI que debe [asumir los riesgos de] convertirse en su propio integrador de sistemas. Seguramente ya tiene una estrategia de computación en nube a seguir ¿o no?
  • Se debe elegir una plataforma de gestión de nube que permita la gestión de los recursos y servicios híbridos, los que operan tanto a nivel interno como externo.

No olvidemos la tecnología –pero a la inteligencia artificial aún le falta para ser “humana” (para bien o mal) –en un par de siglos tal vez. La aplicación del concepto de “TI debe funcionar como un negocio” será obligatoria en este entorno, ya que las organizaciones de TI tendrán que aprender y perfeccionar áreas tales como el catálogo de productos [ok, ok, servicios], gestión de la capacidad, gestión del rendimiento, gestión de la configuración, gestión de la demanda [ITIL/ISO20000], aseguramiento de la continuidad [ISO27000], la gestión financiera, optimización y gobierno del servicio [COBIT/Kaplan y Norton] y, en general, la orientación al servicio [inherentemente calidad de servicio (conociendo al cliente y su entorno), innovación, ISO9000]. Esto requerirá nuevas habilidades y transformación [inteligencia emocional] porque los diferentes servicios probablemente requerirán diferentes modelos de gestión.

El tema es que hoy por hoy todos los acontecimientos disruptivos han impactado la forma en que se compran y consumen los bienes y servicios, la forma en que las empresas se conectan con sus clientes, la forma en que los gobiernos interactúan con sus ciudadanos [¿podremos finalmente utilizar eficientemente la Plataforma de interoperabilidad del estado -PIDE?], e incluso la forma en que colaboran a diario [la agenda digital peruana[6] [7]]. En consecuencia, las empresas y los gobiernos deben centrarse menos en commodities [hardware y software], y más en la forma en que TI ayuda a resolver problemas de negocios –un poco más de inteligencia en las políticas de empleo de los recursos –incluso a nivel gobierno con el Sistema Nacional de Inversión Pública (SNIP) tenemos ya importantes inclusiones de recomendaciones y mejores prácticas como la gestión de proyectos en el marco del PMI.

[1]      Fuente: http://docs.media.bitpipe.com/io_11x/io_111063/item_741189/HP_Gartner%20Newsletter_Cloud.pdf, febrero/2016

[2]      Fuente: http://resources.idgenterprise.com/original/AST-0143462_EIU_Teradata_The_Virtuous_Circle_of_Data_briefing_paper_1_.PDF, febrero/2016

[3]      Fuente: http://searchcloudcomputing.techtarget.com/answer/Should-I-build-a-dedicated-private-cloud-staff?utm_medium=EM&asrc=EM_NLN_51771055&utm_campaign=20151229_Google%20cloud%20grows%20up%20in%202015,%20but%20work%20remains_kcasey&utm_source=NLN&track=NL-1814&ad=904943&src=904943, diciembre/2015

[4]      Fuente: http://community.spiceworks.com/topic/334270-how-to-fire-a-sys-admin-when-it-pros-go-rogue?utm_campaign=digest&utm_medium=email&utm_source=digest&utme=topic+featured, febrero/2016

[5]      Cáceres Meza, Jack Daniel. Propuesta para la implementación de normas de calidad que apoyen la gestión de clientes en una empresa proveedora de Internet. Lima, 2013. viii, 293 h. : il. ; 30 cm. Tesis (Mg. en Dirección Estratégica de las Telecomunicaciones) -Universidad Nacional Mayor de San Marcos. Facultad de Ingeniería Electrónica y Eléctrica. Escuela de Post-Grado, 2013

[6]      Fuente: http://www.codesi.gob.pe/, febrero/2016

[7]      Fuente: http://www.codesi.gob.pe/docs/AgendaDigital20_28julio_2011.pdf, febrero/2016