Después de 3 meses vuelvo a tener tiempo para escribir en este blog. Creo que esta entrada va a ser la más personal que he escrito hasta ahora.
Llevaba un año y medio preparándome para obtener la certificación PMP pero estos últimos meses han sido los más intensos, estudiando y preparándome en “modo test” para el examen. Finalmente me presenté el pasado jueves 19 de abril (de 2012) y aprobé.
Pero, ¿qué significa tener la certificación PMP? ¿se es mejor project manager por disponer de esta certificación? No es fácil de responder.
Lo que me ha aportado hasta ahora el PMP no es tanto el propio certificado como todo lo que he aprendido a lo largo del proceso de preparación. Técnicas, buenas prácticas, metodologías, conocimiento de buenos profesionales y formadores en gestión de proyectos y también el hecho de demostrarme a mi mismo que sigo en condiciones de marcarme un objetivo ambicioso y esforzarme al máximo hasta conseguirlo.
Prepararse para el PMP requiere tiempo y esfuerzo y no es fácil hacerlo en el actual contexto de crisis en el que en el trabajo debes hacer cada día más con menos y al llegar a casa te esperan tus obligaciones familiares. Los ratos que se pueden dedicar a la preparación no siempre son los más productivos del día.
En todo este proceso he tenido algunas ayudas que ahora me gustaría compartir (siguiendo la filosofía de este blog) porque creo que pueden ser útiles para quien se quiera presentar al examen:
Herramientas complementarias: en la parte final de la preparación para el examen me ha ido bien utilizar
PM Flashcards, ayudan mucho al hacer un repaso final por áreas de conocimiento.
PM Formulas, permite entender bien todas las fórmulas susceptibles de aparecer en el examen y asegurarte de que no se te escapa ninguna. Además viene con 105 preguntas de examen sobre fórmulas. Muy práctico.
El blog de Josh Mankivel (en inglés) es muy interesante y proporciona consejos útiles basados en su experiencia con muchos aspirantes a PMP.
Quiero agradecer a Angel Águeda Barrero toda la información que habitualmente publica en su blog y especialmente la recopilación de exámenes gratuitos. Me ha resultado muy útil.
Para acabar, mi agradecimiento también a otro PMP y compañero en el MGTI, Victor Carazo. Sus consejos y la información que ha compartido conmigo no tienen precio.
Acabo repitiendo el mensaje fundamental de esta entrada; si te estás preparando para el PMP no te limites sólo al resultado final, procura disfrutar y aprender al máximo durante todo el proceso.
En este blog hablo exclusivamente de cuestiones profesionales por lo que voy a limitarme a analizar las implicaciones que este proceso de transición tiene en un entorno empresarial, dejando de lado las afectaciones a los usuarios domésticos.
El cambio es necesario y no negociable
No es una cuestión de decidir si me cambio o no a IPv6. Si no hacemos nada a nivel de empresa y seguimos trabajando con IPv4, en los próximos meses nos podemos encontrar con varios efectos:
1. Podemos empezar a tener problemas para acceder a determinadas páginas web. Por ejemplo, si tenemos proveedores en China podría darse el caso de que no pudiéramos acceder a sus páginas web. En la región de Asia Pacífico ya se han quedado sin direcciones IPv4. Eso significa que cuando un nuevo usuario de esa zona del mundo vaya a su ISP y le pida nuevas direcciones públicas éste le va a decir que ya no puede dárselas en IPv4. Este nuevo usuario podrá optar por implementar sus servicios con IPv6 (en China ya llevan años haciéndolo) o trabajar con IPv4 pero no con una dirección IP pública sino privada (asignada por el ISP y compartida con otros usuarios mediante NAT).
La consecuencia para mi es que si este usuario chino decide montar su portal web en IPv6 puede que yo no sea capaz de llegar hasta su portal (estamos suponiendo que nosotros nos quedamos en IPv4) o que si opta por trabajar con IPv4 bajo NAT determinados servicios y/o partes de su portal web no sean accesibles para mi (es bastante complejo desarrollar aplicaciones web que funcionen a través de varios niveles de NAT).
2. Si la web corporativa de mi empresa sólo funciona con IPv4 no podrá ser accedida por usuarios que trabajen exclusivamente con IPv6 (como ya empieza a pasar en algunas regiones del mundo). Las aplicaciones de mi organización, como por ejemplo el portal web corporativo, deben ser capaces de funcionar con una doble pila IPv4-IPv6 si quiero que sigan manteniendo su funcionalidad actual.
Ese es un primer paso que pretende forzar a los ISP a la transición a IPv6 y que antecederá al despliegue de nuevos servicios basados en las nuevas características de IPv6 de las que carece IPv4.
Eso significa que si no hago cambios y sigo en IPv4 no podré acceder a esos nuevos servicios.
Fotografía cortesía de Blacknight (CC BY 2.0)
Necesito un plan
Como consecuencia de lo expuesto en el apartado anterior, aunque sólo sea para seguir manteniendo los servicios actuales, necesitaremos elaborar un plan (un proyecto en sí mismo en el caso de organizaciones de cierto tamaño) para organizar la transición.
¿Qué elementos deberemos tener en cuenta? Siguiendo las recomendaciones de Jordi Palet, será conveniente que nuestro plan incluya los siguientes puntos:
1. Formar en IPv6 al departamento TIC.
2. Hacer un nuevo plan de direccionamiento IP.
Y no sirve intentar traspasar lo que hay en IPv4 de forma análoga a IPv6. Eso sería un error porque los cambios en el nuevo protocolo nos llevan a una nueva estrategia de direccionamiento de partida. Es muy recomendable utilizar un plan de direccionamiento NO contiguo (que puede ser gestionado por un dispositivo IPAM) y que nos permite aprovechar las nuevas prestaciones de IPv6 y dificultar ataques de escaneo de puertos
3. Obtener direcciones IPv6.
En el caso de una empresa que trabaje con varios ISP aquí hay una novedad. Hay que gestionar la obtención de las nuevas direcciones globales con RIPE NCC directamente (en el caso de Europa y Oriente Próximo y parte de Asia Central). Es lo que se llama direccionamiento IPv6 Independiente del Proveedor o “portable” y se regula mediante lo que se conoce como “contrato de usuario final”.
RIPE NCC nos va a entregar direciones IPv6 de tipo /48, por defecto. Si sólo trabajamos con un ISP y gestionamos la obtención de direccionamiento IPv6 con él deberemos exigirle ésto mismo.
4. Auditar la red.
Se trata de analizar si nuestro equipamiento actual (cortafuegos, balanceadores de carga, IDS, proxys, …) soporta IPv6.
5. Planificar actualizaciones y/o adquisiciones.
Aquí incluyo tanto aplicaciones (propias o ajenas) como sistemas operativos, firmware, o incluso certificados ssl.
Un punto importante es hacer las gestiones necesarias de forma que desde “ya” no se adquiera ningún nuevo equipamiento en la organización que no soporte IPv6.
Para empresas de gran tamaño todo este proyecto puede llevar tiempo y ser costoso. Parece, en ese caso, razonable abordarlo en 2 fases: primero asegurarme de que mis clientes y proveedores puedan acceder a mis servicios y aplicaciones y después conseguir que mis usuarios puedan acceder a internet con IPv6.
La estrategia de transición a IPv6 de mis ISP
¿Cómo nos afectará la estrategia de transición de nuestros proveedores de internet? Pues mucho. Los ISP españoles se van a quedar sin direcciones IPv4 a lo largo de los próximos meses (de hecho, Jordi Palet nos comentó que alguno de ellos ya las habría agotado) y han empezado a gestionar la solicitud de direcciones IPv6 a RIPE NCC.
Pero no van a dar soporte IPv6 de la noche a la mañana. Eso significa que utilizarán mecanismos de transición (generalmente basados en túneles) como NAT444 o Dual Stack Lite. Son mecanismos que, en general, trasladan el NAT del CPE a la propia red del operador, lo que se conoce como Carrier Grade-NAT (CGN).
Como consecuencia, las mismas direcciones ip son compartidas entre varios usuarios del ISP repartiendo el conjunto de puertos entre ellos (a razón de 2000 puertos por cliente). En este escenario muchas aplicaciones dejan de funcionar, no es posible hospedar servidores en “puertos conocidos” y es preciso utilizar complejos mecanismos como ALG para traspasar el NAT del ISP y lograr que algunas cosas funcionen.
Conclusiones
1. No podemos esperar más. Hay que planificar y ejecutar la transición a IPv6 en nuestras organizaciones.
2. Debemos informarnos detalladamente de los planes de transición de nuestros ISP para ver cómo nos van a afectar y decidir si nos conviene su estrategia o si será necesario un cambio de proveedor.
Para acabar esta entrada, os dejo un enlace hacia un buen libro introductorio a IPv6 que se puede descargar de forma gratuita; “IPv6 para todos“.
La pasada semana he asistido a un evento sobre cloud computing organizado por un conocido grupo de comunicación en el sector de las TIC. Este es un tema que me interesa especialmente porque creo que es el futuro. Sin embargo, siendo un concepto muy tratado, cada organización puede aproximarse a él de formas muy diversas.
La nube: el concepto
El cloud computing se basa en la facilidad de acceso a sitios remotos que hoy en día proporciona internet. El concepto engloba la provisión de aplicaciones, datos, almacenamiento e infraestructuras de forma transparente para el usuario, que no precisa conocer ni la configuración de los sistemas ni su ubicación física.
, via Wikimedia Commons”]
La nube proporciona transparencia y flexibilidad al usuario final. Eso es bueno para “organizaciones líquidas”, concepto que he conocido a través de Jaime García Cantero (@jaimegcantero), que es en lo que se están convirtiendo nuestras empresas progresivamente: con límites y formas cambiantes, cada vez menos definidos y en constate trasformación.
Como he apuntado antes, no hay una única forma de consumir el cloud computing. Cada organización deberá adaptarlo a sus propias necesidades y circunstancias: habrá quien contrate aplicaciones como servicio, quien busque sistemas de almacenamiento ubicuos y flexibles, quien desee mantener servicios como el correo electrónico bajo su control directo o quien lo contrate como servicio a grandes proveedores como Google, quien virtualice, quien comparta servidores con otras organizaciones y quien trabaje con su nube privada.
, via Wikimedia Commons”]
En cualquier caso, creo que la mejor forma de aproximarse al tema es analizando servicio a servicio todos los que son prestados por el departamento de TIC, considerando sus necesidades de disponibilidad, su criticidad, las normativas legales que en cada caso apliquen, … y buscando un buen socio que nos acompañe en todo el proceso, asesorándonos sobre los mejores proveedores y la mejor estrategia a seguir.
Y es que el mercado de la nube está todavía poco maduro, en pleno crecimiento, como lo demuestra que el número y pelaje de los proveedores de cloud computing vaya en aumento día a día. Hay operadoras de telecomunicaciones, proveedores tradicionales de servicios de housing y hosting, grandes corporaciones internacionales, …
, via Wikimedia Commons”]
Y también hay mucho marketing. Se habla mucho de la nube pero, como pudimos comprobar en el evento al que hacía referencia al principio de la entrada, las empresas todavía la usan poco. No ocurre así con los particulares, ya muy habituados a gmail, dropbox, spotify, etc.
Incógnitas
¿Cómo evolucionará este mercado? ¿Quienes acabarán siendo los players principales? ¿Cómo se acabará segmentando? ¿Qué beneficios reales acabarán obteniendo las organizaciones? ¿Será suficientemente seguro?
Y yendo más hacia las afectaciones concretas de un departamento de TIC, ¿cómo afectará la nube a nuestra base instalada (nuestros activos)? ¿seremos capaces de convertir aplicaciones (cloud) estándar en aplicaciones de negocio (personalizadas)?
Y, en particular, los CIO y/o responsables del área de TIC, ¿serán capaces de transformarse de gestores de activos en gestores de servicios?
Conclusiones
En conclusión; mi impresión es que por ahora hay mucho marketing y demasiadas cuestiones abiertas. Sin embargo, creo que es un camino que nuestros departamentos de TIC deberán transitar si nuestras organizaciones quieren seguir siendo competitivas. Habrá que ir poco a poco, dando pasos lentos pero firmes y tratando de ir resolviendo incógnitas por el camino.
Una de las personas con las que tuve oportunidad de charlar me explicó que en la anterior empresa para la que había trabajado, en el sector de la construcción, no le permitía incorporar en el presupuesto las actividades relacionadas con la gestión de los riesgos. Estaba indignado.
Un riesgo en un proyecto es un evento incierto que puede afectar (positiva o negativamente) al coste, el plazo, el alcance o la calidad.
Según las buenas prácticas del PMBOK, es necesario gestionar los riesgos del proyecto. De forma muy breve; hay que identificarlos, priorizarlos, decidir qué se va a hacer con cada uno de ellos, hacerlo y seguir su evolución a lo largo del proyecto.
Se trata de un proceso iterativo porque las acciones realizadas para mitigar, eliminar, o transferir los riesgos afectan a la gestión del alcance, los costes, los plazos o la calidad del proyecto y, además, pueden dar lugar a nuevos riesgos previamente no identificados.
Gestionar los riesgos tiene costes; costes de gestión, de aplicación de las medidas y planes de contingencia, de control y seguimiento de los riesgos, … El hecho de no incorporar estas actividades en el presupuesto del proyecto, como una supuesta medida para mejorar la competitividad en costes frente a la competencia, creo que sólo puede deberse a que, o bien no se gestionan los riesgos en el proyecto, o bien se identifican y registran pero no se realiza ninguna actividad para mitigarlos o eliminarlos. Simplemente se aceptan.
No sé cual de las dos opciones me parece peor. Si realmente queremos mejorar nuestra competitividad no puede ser en base a gestionar mal. Si ignoramos los riesgos de un proyecto estamos jugando a la lotería; puede que no se materialicen y gano o puede que lo hagan y pierdo.
En las últimas dos semanas me he visto involucrado en una nueva actividad, añadida a las que desarrollo habitualmente. Como responsable de calidad de la empresa debo encargarme del aseguramiento de la calidad en un proyecto dirigido por otros gestores de proyectos.
Se trata de un proyecto complejo, distribuido en varias regiones (de ahí que haya varios gestores) y que se apoya en otras empresas para la ejecución de algunas de las actividades. Para acabarlo de arreglar, nuestro cliente es una empresa extranjera, de reciente implantación en España y con una cultura muy distinta a la nuestra.
Aseguramiento de la calidad vs. control de calidad
En los procesos de control de calidad se utilizan diversas técnicas para medir determinadas variables que permitan conocer si un proceso o un entregable disponen del nivel de calidad requerido.
Por el contrario, el aseguramiento de la calidad se centra en verificar que se siguen los procedimientos internos (y en nuestro caso también del cliente), las normativas legales, etc. que se habrán identificado previamente en el Plan de Calidad del proyecto.
El otro gran objetivo del aseguramiento de la calidad es intentar mejorar los procesos que se estén utilizando.
Herramientas
¿De qué armas disponemos para enfrentarnos con este reto?
revisar el Plan de Calidad y utilizar los resultados de las medidas tomadas en los controles de calidad
auditorías de calidad (internas y/o externas)
análisis de procesos: en el caso de este proyecto hay determinados paquetes de trabajo que se repiten en el tiempo. Las lecciones aprendidas tras la revisión del proceso de ejecución de los primeros paquetes de trabajo nos pueden dar una información muy valiosa.
Resultados
¿Qué resultados esperan obtener mi empresa y el cliente de este proceso de aseguramiento de la calidad?
Sellando la calidad
Básicamente, podríamos decir que los resultados serían solicitudes de cambio, acciones correctivas y preventivas, mejoras y actualizaciones de los procesos, … que deberían derivar en entregables que cubran las necesidades y expectativas de nuestro cliente y, por supuesto, estén libres de defectos.
Para mucha gente, entre la que me encuentro, las vacaciones son un buen momento para reflexionar y dedicar tiempo a pensar en aquellos temas a los que el día a día no le deja tiempo. También es importante usarlas para desconectar.
En estas últimas semanas de agosto, sin entradas en el blog, he estado dedicando algunos ratos a pensar en la arquitectura de aplicaciones a la que me gustaría llegar en mi empresa en 1 o 2 años. En septiembre la empezaré a discutir con mi equipo.
Las capas de la arquitectura
La infraestructura de aplicaciones de una organización, esté estructurada o no, escrita en un documento o no, se organiza en 4 capas básicas, según el esquema siguiente:
Arquitectura de aplicaciones
De estas 4 capas, en esta entrada me interesan 2, la arquitectura de aplicaciones y la arquitectura de la información. La segunda se apoya en la primera, según se intuye en la figura.
La arquitectura de aplicaciones es básicamente lo que entenderíamos como el catálogo de aplicaciones con sus interfaces.
La arquitectura de información se basa en los flujos de información, las relaciones entre entidades de datos así como las herramientas y actividades que el negocio (capa superior) impone.
La arquitectura actual y la arquitectura objetivo
Para definir la arquitectura de aplicaciones yo utilizo básicamente 3 documentos:
Un inventario de aplicaciones por área funcional, estructurada en base a aplicaciones de planificación, de operaciones y de análisis.
Una descripción de la forma como estas aplicaciones se comunican entre ellas y con otros sistemas internos y externos.
Una descripción de cada aplicación y su razón de ser, incluyendo:
sistema
nombre
funcionalidades
plataforma en que se sustenta, …
Periódicamente es conveniente revisar la arquitectura de aplicaciones existente en base a:
cómo le afectarán los proyectos en curso o futuros que la organización tiene previstos.
qué aplicaciones se encuentran ya en la etapa final de su ciclo de vida
Estrategia y Plan de Migración
A partir de aquí se puede definir una estrategia de aplicaciones que nos marque qué aplicaciones cabe retirar, cuales deben ser actualizadas y dedicarles más recursos, en cuales debe ajustarse el nivel de servicio y los recursos empleados y en cuales, simplemente debemos seguir como hasta ahora.
A partir de la estrategia anterior ya estamos en condiciones de diseñar la arquitectura de aplicaciones objetivo (con los mismos documentos que hemos utilizado para definir la arquitectura actual).
Para llegar a esta imagen futura (que puede ser a 1, 2, o incluso 3 años vista) deberemos establecer un Plan de Migración, obtener recursos, presupuesto, … pero eso ya es otro tema.
¿Qué opinas? ¿utilizas un sistema similar en tu organización? ¿cómo documentas la arquitectura de aplicaciones?
Recuerdo que cuando estudiaba Planificación de Sistemas de Información en el MGTI de La Salle nuestro profesor nos preguntaba con frecuencia si queríamos que nuestro departamento de TI fuera operativo o estratégico.
Su intención era convencernos de que el departamento TIC ideal debe ser capaz de ayudar a elaborar la estrategia corporativa y, sobretodo, debe ser un facilitador para llevarla a cabo. Debe existir un alineamiento entre el departamento de sistemas de información y la estrategia corporativa.
Hasta aquí todo bien. Este afán de ser estratégico es un objetivo ambicioso para cualquier departamento de TI. Es lo que nos gustaría ser de mayores. Pero primero lo primero.
El departamento debe ser capaz de cubrir primero las necesidades básicas de la organización en materia de TIC antes de intentar liderar y marcar la estrategia.
La primera cualidad del responsable de sistemas, a mi entender, debe ser el pragmatismo. Es básico conseguir una infraestructura que asegure las operaciones y el día a día de la organización sin problemas. Cuando el departamento deja de pasarse el día apagando fuegos entonces puede empezar a dedicarse a tareas más elevadas como mejorar su conocimiento del negocio o mantenerse al día de los nuevos desarrollos tecnológicos.
Lo básico no es tan “interesante” como la definición de nuevos proyectos o probar nuevas tecnologías pero para un responsable de sistemas va a ser difícil convencer a la Dirección de la empresa de que implante un sistema de Business Intelligence si el departamento tiene dificultades para proporcionar a la organización un servicio de correo electrónico con un nivel de disponibilidad mínimamente razonable.
Interpretación de la jerarquía de necesidades de Maslow
Es lo que John Baschab y Jon Piot definen como la pirámide de Maslow de las TIC en su libro The Executive’s Guide to Information Technology. Sin cubrir los niveles inferiores de la pirámide no podemos aspirar a la cumbre.
Y eso es algo que se olvida con frecuencia en muchos departamentos de TI. ¿Estáis de acuerdo?
A principios de este año uno de los analistas más influyentes de este país en el mundo de las TIC ya lo anunciaba; se espera un avance importante en el ámbito del pago mediante el teléfono móvil durante 2011. Mi interés por las tecnologías relacionadas con el comercio electrónico, incluyendo los medios de pago, me ha llevado a ir siguiendo las novedades que es están produciendo y las previsiones para el futuro.
En esta infografía que he encontrado en G+ se resume muy bien la evolución esperada de los medios de pago por móvil, los players más importantes a nivel internacional y el funcionamiento de la tecnología NFC.
Lo cierto es que el reciente anuncio del estreno de Google Wallet ha puesto este asunto en todos los medios. Tras la experiencia del fracaso de la iniciativa Mobipay en España es posible que se necesite el impulso de alguien como Google para implantar un sistema de este tipo a nivel mundial.
Requerimientos de un sistema de pago
De un sistema de pago, electrónico o no, se debe esperar que tenga las siguientes propiedades:
Reconocimiento, por una comunidad lo suficientemente grande (masa crítica)
Apoyo, por parte de las principales entidades bancarias, estados, agentes económicos, etc.
Versatilidad, para adaptarse a distintos tipos de pagos (de importe pequeño y mediano)
Facilidad de uso, para que sea accesible al máximo número de usuarios potenciales
Facilidad de implantación, basándose en elementos que el usuario ya conoce o de los que dispone (como el teléfono móvil o la tarjeta de crédito)
Seguridad, que le haga resistente a los ataques informáticos
Dos propiedades deseables adicionalmente serían:
Grado de anonimato, que permite al comprador
Lincabilidad de los pagos, que permite relacionar los diferentes pagos realizados por un mismo comprador aunque éste sea anónimo.
Google Wallet puede llegar a cumplir con todas estas propiedades, pero todavía es pronto para saber si lo logrará. En este vídeo podemos comprobar su facilidad de uso:
Conclusiones
Creo que para que un sistema de este tipo triunfe es necesario que no esté ligado ni a un sistema operativo, ni a una tecnología de pago concreta, ni a un terminal o familia de terminales específico. Cuanto más abierto sea mucho mejor para que sea ampliamente reconocido y utilizado.
Google Wallet funciona por el momento en el terminal Nexus S, con sistema operativo Android, utilizando la tecnología de MasterCard, con tarjetas de Citi o prepago de la propia Google y en la red del operador norteamericano Sprint.
Parece ser que Google está abierto a que Wallet pueda funcionar con otros sistemas operativos. En este sentido, que otros players como Apple puedan estar pensando en incorporar el pago por móvil en sus nuevos dispositivos sería positivo, siempre que su tecnología sea compatible con la de Google. Sin embargo, la utilización de paypass deja fuera, por el momento, a un actor importante de los medios de pago como Visa.
Hace unas semanas participé en un taller de calidad en RTM.
El objetivo era mejorar la efectividad de los sistemas de gestión de la calidad implantados en las empresas de los asistentes. Tratamos muchos temas pero a mi me interesaba especialmente mejorar la definición de indicadores y objetivos.
Un sistema de gestión de la calidad como ISO 9001 está basado en procesos. Para conocer el nivel de madurez de un proceso es preciso definir indicadores representativos y medirlos. Recordemos la famosa cita de Lord Kelvin “Lo que no se define no se puede medir, lo que no se mide no se puede mejorar y lo que no se mejora se degrada siempre”.
Algunas de las conclusiones que extraje del taller, en relación con la definición de indicadores fueron:
deben ser representativos del proceso
deben ser fáciles de calcular
se debe definir la frecuencia con la que se calculan
deben establecerse unos objetivos en relación con cada indicador
tras su cálculo con la frecuencia prevista, deben definirse acciones que corrijan la situación en caso de estar fuera de los objetivos.
Pero, ¿cómo se relacionan estos indicadores, más bien operativos, con los objetivos estratégicos de la compañía? Hasta ahora sólo estamos midiendo para conocer el estado de nuestros procesos de negocio pero ésto no sirve de mucho si no somos capaces de hacer que lo que medimos nos permita conocer lo cerca o lejos que estamos de nuestros objetivos corporativos.
Por ejemplo, el nº de visitas realizadas al mes por un vendedor puede ser un indicador que mida el proceso comercial pero no nos garantiza el cumplimiento de un determinado objetivo de facturación que puede ser estratégico.
En ocasiones, se puede dar la circunstancia de que algunos de los indicadores definidos para nuestros procesos de negocio ya nos permitan conocer si nos estamos acercando o no a nuestros objetivos estratégicos. Pero, como hemos visto, puede que no siempre sirvan.
En este último caso será preciso definir indicadores adicionales específicos para medir lo cerca o lejos que estamos de nuestros objetivos corporativos. Como resultado tendremos un cuadro de mando con indicadores más o menos operativos, para el día a día, y con otros más estratégicos.
Un último comentario: puede llevar varios años conseguir definir un buen cuadro de mando, con los indicadores adecuados y que nos sea útil. Se trata, creo, de un proceso de ensayo y error. De hecho, es de nuestros errores de lo que más podemos aprender.
¿Qué opinión tienes sobre estas conclusiones? ¿qué tipo de indicadores utilizas? ¿cómo los relacionas con los objetivos estratégicos de la organización? Compartiendo nos enriquecemos; espero vuestras aportaciones.
Mi objetivo era conocer la norma ISO 20000, a la que me acercaba por primera vez, con las novedades que aporta la nueva versión . La oportunidad era muy interesante, dado el nivel de los ponentes: Lynda Cooper, ITIL Master -una de las pocas personas en el mundo con esa titulación- y redactora de la parte 1 de la norma y Diego Berea, Director de Ozona Consulting y co-redactor de la parte 2 de la norma ISO 20000.
La norma ISO 20000 certifica los servicios prestados por el área de TI de una organización a sus usuarios, ya sean éstos internos o externos. Diego Berea lo explica muy bien en esta entrevista.
Hay varios aspectos que me han interesado de la nueva versión de la norma; su mejor alineamiento con ITIL y su nueva organización que facilita su incorporación en un sistema de gestión unificado con otros estándares como ISO 9001 o ISO 14001.
No obstante, mi impresión es que es una norma más pensada para ser aplicada en organizaciones con departamentos de TI de cierto tamaño, cosa que excluye a muchas de las pymes de nuestro país. Ésto se debe a que la norma incorpora 13 procesos certificables y deben implantarse todos ellos. En empresas con departamentos TI reducidos no parece razonable que tengan que haber algunas personas siendo responsables de muchos de estos procesos a la vez. En estos casos, mi opinión es que parece más conveniente la aplicación de algunas de las buenas prácticas de ITIL, sin ánimo de certificar la organización (ITIL sólo certifica a personas).
Sin embargo, como se explica en ésta otra entrevista España cuenta con cerca de 100 empresas certificadas desde el año 2006 a marzo de 2011 y está muy destacada en este aspecto a nivel internacional. No es normal. La explicación, como se ha indicado en las conferencias del Forum, viene dada por las subvenciones del Plan Avanza.
Mi impresión final es que, si bien a empresas con departamentos de TIC de tamaño reducido la ISO 20000 les viene grande y probablemente les resulte más adecuado adoptar selectivamente algunas buenas prácticas ITIL, en el caso de subcontratar servicios de TI a empresas especializadas del sector sí que será recomendable pedir que éstas estén organizadas (y certificadas) internamente según la ISO 20000. Es un elemento diferenciador y garantiza un cierto nivel organizativo y de calidad.
Esta exigencia a nuestros proveedores puede tener todavía mayor sentido cuando los servicios ofrecidos por éstos sean entregados en la modalidad de cloud computing. La certificación ISO 20000 además de ser un elemento diferenciador puede contribuir a ayudar a homologar (y facilitar la comparación de) los servicios de TI ofrecidos por organizaciones desde paises diferentes del nuestro.
Technology at the service of humans 