Uso de Infografías en los Sistema de Gestión de la Calidad

Llevo una buena temporada preocupado por la falta de integración del Departamento de Calidad en las organizaciones, especialmente en aquéllas que ofrecen servicios.

Los argumentos tradicionales para justificar su existencia han comenzado a mostrar cierta debilidad. Ya no resulta suficiente con afirmar que, por el simple hecho de seguir las directrices de una cierta normativa, se ofrece un mejor servicio o aumenta la satisfacción de los clientes.

Los tiempos en los que se suponía un valor añadido o diferencial al Departamento de Calidad ya han pasado. Es necesario dar un paso adelante y demostrar esta aportación si no queremos convertirnos en una carga para la organización, en un mal necesario.

En este proceso de cambio, el Departamento de Calidad debe transformarse para ser capaz de aportar valor al negocio, y poder demostrarlo con datos objetivos.

En un artículo anterior (ver Quality as a Service)  proponía una forma de emprender este proceso de transformación en cuatro fases:

• Definiendo y difundiendo un porfolio de servicios que clarifique el valor aportado

• Analizando los esfuerzos dedicado a cada servicio (¿enfocamos nuestro trabajo a ofrecer valor o andamos perdidos intentando atender las peticiones de unos auditores demasiado exigentes?)

• Definiendo indicadores que expongan el valor que aportamos en cada uno de los servicios 

• Estableciendo acuerdos (SLA, Service Level Agreements) con el resto de la organización que marquen nuestras metas.

Es un proceso largo que, sin embargo, puede acometerse en diferentes fases y escenificarse desde un principio con pequeños pero importante gestos. Uno de ellos pasa por cambiar la forma en que exponemos nuestro trabajo, en incorporar el marketing a nuestras actividades.

En Calidad, es bastante habitual esperar al final del año para elaborar un concienzudo informe en el que analizamos cada uno de los procesos de la organización, mostramos la evolución de ciertos indicadores, las acciones correctoras emprendidas  y los resultados de la auditorías internas y externas. Esperamos con este informe convencer a la Dirección de la relevancia de nuestro trabajo y de la necesidad de disponer de los recursos adecuados para continuar con tan importante labor.

Pocas veces lo conseguimos. Quizás el problema no está en los fundamentos de nuestro trabajo sino en la forma de exponerlo. Seguramente, el Comité de Dirección no dispone de tiempo para analizar en detalle un extenso documento de 100 páginas, ni siquiera logrará captar su atención un lustroso Powerpoint de 40 transparencias.

Pero puede que sí se sienta a traído por una sola página, una infografía, en la que, de forma extremadamente visual, mostremos los principales logros del departamento. Si así conseguimos captar su atención, después ya habrá tiempo para analizar pormenorizadamente cada detalle.

En Calidad hablamos poco de dinero y esto nos cuesta muy caro

Continuamente me encuentro en los foros con gente que pregunta o se queja sobre la falta de implicación de la Dirección en el SGC. Una buena parte de las respuestas recalca su importancia o la necesidad de hacer partícipes a los diferentes estamentos de la empresa y otras hablan de asociar los objetivos de calidad con los institucionales. Todas están bien encaminadas, pero muy pocas ofrecen soluciones concretas o profundizan lo suficiente en la causa real del problema.

En mi opinión, la única forma de involucrar a la Dirección es hablar en su propio idioma y éste no es otro que el dinero.

En teoría, la promoción de la Mejora Continua o la búsqueda de la Excelencia deberían, por sí solas, garantizar la mejora de los beneficios empresariales haciendo los procesos más eficientes, reduciendo costes, mejorando la productividad y aumentando los márgenes. Pero como toda buena teoría, debemos demostrar su validez día a día con datos experimentales. Tampoco podemos obviar otra de las premisas del método científico: cuando los datos se empeñan en refutar una teoría seguramente debamos cambiarla.

Y es ahí donde la mayor parte de los Departamentos de Calidad exponen con mayor claridad sus carencias, recurriendo a aspectos técnicos o normativos para justificar las medidas planteadas y dando por supuesto que el resto de la organización entenderá que darán beneficios a medio o largo plazo.

Cuatro Indicadores clave para valorar la relación con tus Clientes

Hace poco hablábamos de un buen conjunto de indicadores para controlar nuestra cartera de proyectos y servicios (más información...). Nos dicen cuanto dinero estamos ganando en cada proyecto (MOP: Margen Operativo) y cuan bien estamos cumpliendo con los compromisos contractuales con los clientes: ¿entregamos a tiempo? (OTD: On Time Delivery), ¿ofrecemos lo que el cliente espera? (QOD: Quality of Delivery), ¿cometemos errores? (RFT: Right First Time).

El dinero debería asegurarnos la satisfacción de los accionistas, cumplir los plazos entregando con la suficiente calidad la de nuestros clientes.

Pero, ¿en verdad están nuestros clientes satisfechos con los servicios o productos que les ofrecemos?, ¿cómo podemos estar seguros?. De nuevo, podemos recurrir a unos cuantos indicadores para hacernos una buena idea.

CPS (Customer Profiability Score)

Una herramienta para incorporar el análisis de Riesgos y Oportunidades en el proceso de Revisión por la Dirección

No en todas las normas se da la suficiente relevancia al proceso de análisis y gestión de riesgos y oportunidades. Es un punto crítico en normas como la ISO 14001 (gestión medioambiental) o la ISO 27001 (Seguridad de la Información). También lo encontramos en la ISO 20000 (Gestión de Servicios) y en algunas más. Sin embargo, no está presente en la más genérica, la norma ISO 9001, aunque lo estará en la próxima revisión que será publicada en 2015 (ver más adelante).

Esta ausencia tan significativa es consecuencia de la complejidad de implementar este proceso en todos los niveles de la organización. En CMMI, por ejemplo, la gestión de riesgos no se introduce de forma global  hasta el cuarto nivel de madurez de los cinco establecidos.

Por el contrario, muchas organizaciones le restan importancia limitando su alcance a las operaciones (al desarrollo de productos y servicios) y reduciendo la gestión de riesgos a la mera selección de unos cuantos entre los expuestos en listas previamente preparadas y su posterior evaluación en cuanto a probabilidad de ocurrencia y posible impacto.

Aplicación de las 8 Disciplinas en la gestión de Quejas y Reclamaciones

Según el diccionario:

• Una queja es una muestra de dolor, pena, descontento o enfado, una muestra de disconformidad, oposición o protesta por alguna cosa.

• Una reclamación es la protesta u oposición que se hace a una cosa que se considera injusta o insatisfactoria, la exigencia de una cosa que se hace con derecho o insistencia

En ambas hay una PROTESTA, una expresión de DISCONFORMIDAD aunque, en las reclamaciones, el énfasis recae más en la EXIGENCIA, en la REPARACIÓN de un agravio.

Sea como fuere, establecer un proceso adecuado para la gestión de quejas y reclamaciones es uno de los puntos clave en la implantación de cualquier sistema de gestión al estar íntimamente relacionado con el negocio y con el grado de satisfacción de los clientes.

Esta gestión dependerá en gran medida del entorno en el que se desarrolle la actividad de una organización. No puede diseñarse el mismo proceso para una empresa que lance al mercado productos de gran consumo, ofrezca servicios en línea o desarrolle productos a medida para un selecto conjunto de clientes. Aún así existen aspectos comunes, actividades que, con un mayor o menor grado de desarrollo, siempre deben acometerse.

Aprender de las Lecciones Aprendidas

APRENDER DE LA EXPERIENCIA

Dicen que gestionar las Lecciones Aprendidas constituye el penúltimo paso en un Sistema de Gestión. Y lo es porque no resulta suficiente con registrar lo qué hemos aprendido tras desarrollar un producto o entregar un servicio. Es también necesario (si no imprescindible) analizar la información recopilada para extraer conclusiones, plantear propuestas de mejora o corrección y establecer Mejores Prácticas que puedan extrapolarse a otros proyectos, servicios o áreas de la organización.

Y es aquí donde fallan la mayoría de los Sistemas de Gestión de Lecciones Aprendidas por motivos de muy diversa índole:

• Las Lecciones Aprendidas se registran al final del proyecto cuando ya es demasiado tarde para reaccionar. Pueden ser valiosas en el futuro pero hemos perdido un tiempo precioso
• No se ha establecido un proceso sistemático de análisis de las Lecciones Aprendidas que permita extraer conclusiones globales sobre la salud de los diferentes procesos o herramientas
• La transferencia del conocimiento adquirido no se realiza de forma eficaz
• No se han establecido indicadores que permitan conocer la rentabilidad del sistema
• Las Lecciones Aprendidas están limitadas a las operaciones olvidando la posibilidad de gestionarlas en otros procesos y, especialmente, en los trasversales
• Las Lecciones Aprendidas son demasiado específicas y no pueden transferirse a otras áreas de la organización
• No se han establecido canales de comunicación que permitan difundir lo aprendido al conjunto de la organización
• Se establecen políticas que priman la cantidad frente a la calidad.

¿CUÁNDO APRENDEMOS?

La primera pregunta que podemos hacernos es: ¿cuándo debe registrase una Lección Aprendida?.

En demasiadas ocasiones, este proceso se realiza tras finalizar un proyecto, recurriendo a términos un tanto tétricos como "autopsia" o "análisis post-mortem". Estos análisis, necesarios a todas luces, responden a la problemática planteada por George Santayana (en realidad, Jorge Ruiz de Santayana, un filósofo y ensayista español aunque afincado en Estados Unidos) "aquéllos que olvidan el pasado están condenados a repetirlo" o, de forma más campechana, "el hombre es el único animal que tropieza dos veces en la misma piedra".

Sin embargo, por muy detalladamente que se realice la autopsia de un proyecto, por muy útil que pueda resultar un buen análisis para esquivar la piedra, siempre llegarán demasiado tarde. Si hemos adquirido un valioso conocimiento, éste debería difundirse tan pronto como sea posible, convirtiendo la gestión de las Lecciones Aprendidas en una poderosa herramienta para la promoción del cambio.

Por tanto, a la hora de diseñar un sistema de gestión de Lecciones Aprendidas, es importante que éstas se puedan registrar en cualquier momento y que se establezcan los canales de comunicación adecuados para garantizar que serán analizarlas con la suficiente diligencia.

¿QUÉ APRENDEMOS?

En un análisis post-mortem solemos preguntarnos en qué hemos acertado, en qué nos hemos equivocado y por qué. Evaluamos cómo hemos gestionado el proyecto, qué tal ha ido la relación con el cliente o si hemos sido capaces de cumplir con los plazos de entrega. Analizamos el pasado pero, con cierta frecuencia, nos olvidamos del futuro.

Sin embargo, no es infrecuente que, durante la ejecución del proyecto, detectemos carencias en ciertas herramientas, nos veamos obligados a alterar algún proceso (para aligerarlo o hacerlo más robusto) o resolvamos una cuestión técnica de una manera diferente a la prevista. La mayoría de estos cambios serán tan específicos que sólo resultarán de utilidad para el proyecto concreto. Pero habrá algunos de alcance más global que puedan ser aprovechados por otros proyectos del mismo área, por otras áreas o incluso por la organización en su conjunto.

Con cierta frecuencia también olvidamos que la organización debe ser capaz de aprender de cualquier actividad que realiza y no sólo de las operaciones (ver "Learning Organization: cuando una organización aprende a aprender"). En consecuencia, la recopilación de Lecciones Aprendidas debe abarcar todos los procesos (compras, recursos humanos, formación, gestión comercial, etc.) y debe, como ya hemos comentado, poder realizarse en cualquier momento..

En función de todo lo anterior, para cada Lección Aprendida deberíamos registrar, al menos, la siguiente información

• Autor y fecha
• Origen: proyecto, proceso, departamento, etc
• Problemática detectada
• Proceso, Método o Herramienta afectada
• Solución Adoptada
• Acciones realizadas
• Resultados Obtenidos 
• Impacto económico
• Transferencia: si las acciones planteadas pueden ser de aplicación en otros proyectos, áreas de competencia, departamentos o en la organización en su conjunto

TRANSFERENCIA DEL CONOCIMIENTO

Tenemos ya un sistema que permite registrar lo aprendido en una base de conocimientos que podemos utilizar, cuando consideremos oportuno, para recopilar la experiencia adquirida en cualquiera de las actividades emprendidas por la organización.

Así que: ¡manos a la obra!. Planteamos un proceso de gestión del cambio incluyendo, acciones de formación y concienciación para transmitir la relevancia estratégica del nuevo sistema. Y lo lanzamos para descubrir con cierta sorpresa (o con cierto pavor) que, por una vez, hemos hecho bien nuestro trabajo. Tenemos la base de datos colapsada por docenas o cientos de Lecciones Aprendidas provenientes de los lugares más insólitos. Todo un éxito.

Toca ahora analizar la información recopilada. Seguramente encontraremos algunas descripciones extremadamente precisas sobre cómo configurar el entorno de pruebas proporcionado por un cliente o sobre cómo calibrar un cierto aparato de medida (demasiado específicas para sacar partido de ellas más allá del entorno del proyecto). Otras versarán sobre la importancia de reunirse con el cliente, planificar correctamente o realizar un seguimiento de los riesgos (un vano intento por recalcar lo que cualquier metodología de gestión ya propone) y algunas más resultarán incomprensibles. Pero también encontraremos algunas que proponen el uso de una nueva herramienta para mejorar la productividad del equipo o que plantean la redundancia de algunos mecanismos de uso obligado en el proyecto.

Es sobre estas últimas donde debe recaer la atención de la organización (considerándola en su conjunto) para transformarlas en Peticiones de Cambio (Change Requests) de los procesos, métodos, técnicas o herramientas establecidas por el Sistema de Gestión. Es más, sería mucho más conveniente que, en el momento de registrar la Lección Aprendida, se lanzara automáticamente la petición para ser evaluada y, si procede, realizar las mejoras necesarias.

Convertimos así las Lecciones Aprendidas en una potente herramienta para promocionar el cambio en la organización y en uno de los mejores mecanismos para fomentar la Mejora Continua y la Innovación. Además es un buen instrumento para reconocer el trabajo de los equipos de desarrollo pues verán sus esfuerzos por mejorar trasladados a otros áreas o al conjunto de la organización.

El proceso de transferencia del conocimiento adquirido cobra tal importancia que algunas organizaciones no conciben las Lecciones Aprendidas sin las peticiones de cambio correspondientes.

RETORNO DE LA INVERSIÓN

Mediante el sistema propuesto podemos evaluar el impacto económico que ha supuesto cada cambio individual en un proyecto o proceso concreto, un indicador que hay que tratar con cierta precaución pero siempre interesante.

Podemos, además, analizar el número de peticiones recibidas y el número de mejoras implantadas; es un indicador mucho más fiable y fácil de calcular. Si además somos capaces de evaluar el impacto económico de cada uno de los cambios realizados dispondremos de un mecanismo para justificar el Retorno de la Inversión del sistema implantado para recopilar y gestionar las Lecciones Aprendidas.

CONCLUSIONES

En resumen, un buen sistema de gestión de Lecciones Aprendidas deberá:

• Permitir registrarlas en cualquier momento y no sólo cuando finalizan los proyectos
• Contemplar cualquier actividad emprendida por la organización 
• Proporcionar información estructurada incluyendo los procesos, métodos, técnicas o herramientas que se ven afectados y el impacto económico de los cambios realizados.
• Facilitar la transferencia de lo aprendido hacia otras áreas de competencia, departamentos o a toda la organización
• Permitir las peticiones de cambio en los sistemas que, de ser aceptados, supondrán la transferencia efectiva del conocimiento adquirido.
• Ofrecer instrumentos para reconocer los esfuerzos de mejora de los equipos de desarrollo o de los diferentes departamentos.
• Facilitar el establecimiento de indicadores y la evaluación del impacto económico para poder así justificar el Retorno de la Inversión del sistema implantado

Learning Organization o cuando un empresa aprende a aprender

LA ORGANIZACIÓN QUE APRENDE

Desde tiempos inmemoriales (una década cuando hablamos de tecnología) se ha planteado un agrio debate entre educadores y tecnólogos para establecer las fronteras entre el aprendizaje y el conocimiento.

He pasado años coordinando proyectos de investigación relacionados con la colaboración, el trabajo en grupo, la gestión del conocimiento y el aprendizaje electrónico y a distancia (eLearning y Distance Education son conceptos realmente diferentes aunque a veces se confunden). En todos estos consorcios, empresas y universidades luchaban por dominar un área de gran potencial de crecimiento (aún lo sigue siendo, queda mucho por hacer). ¿Conozco al aprender o aprendo cuando conozco?. Un debate un tanto académico (¿qué fue primero el huevo o la gallina?) pero fundamental como tan bien ha demostrado el paso del tiempo.

En 1994, Peter Senge publicó "La Quinta Disciplina", una propuesta que, con el tiempo, ha conseguido decantar la balanza en favor del aprendizaje (me temo que he salido derrotado en aquel debate). En el libro se propone por primera vez el concepto de "Learning Organization" considerándola como "un grupo de personas que trabajan juntas y de forma colectiva para mejorar sus capacidades y obtener los mejores resultados".

Para lograr este objetivo, Senge propone cinco disciplinas (perdonadme los términos en inglés, pero creo que la traducción al español no les hace justicia):

• Systems Thinking: se ocupa de analizar las relaciones internas entre los miembros de la organización y de resolver los conflictos que puedan suponer obstáculos para el aprendizaje colectivo. ¿En cuántas organizaciones nos encontramos con departamentos aislados que guardan (y ocultan) celosamente sus mejores logros?

• Personal Mastery: otorga un papel prominente a los miembros de la organización. En un acto sincero (poco común en muchas empresas) reconoce la mejora individual (self-improvement) como el motor principal del resto de los procesos de aprendizaje. Las personas trabajan para crecer personal y profesionalmente; el altruismo no es una opción.

• Mental Models: trata sobre la cultura de la organización, su forma de pensar y de entender los aspectos básicos de su funcionamiento. Es necesaria una profunda y precisa comprensión de estos mecanismos para poder embarcar a una organización en un proceso de transformación continua.

• Shared Vision: estudia los procesos necesarios para dotar a la organización de una visión común, compartida por todos sus miembros. Los objetivos personales deben estar imbricados con los estratégicos de forma que la consecución de los primeros garantice el cumplimiento de los segundos.

• Team Learning: subraya la importancia de la colaboración. Se ocupa, por tanto, del análisis de los mecanismos que deben implantarse para favorecerla.

Uno de los aspectos más loables de este modelo es su capacidad para combinar la simplicidad con los grandes conceptos de la gestión empresarial. Habla de la Gestión del Cambio (System Thinking), de la Cultura Empresarial (Mental Models),  fomenta el Desarrollo Profesional y reconoce la necesidad de Crecimiento Personal (Personal Mastery) y de la Colaboración (Team Learning) como principales medios para la consecución de los Objetivos Empresariales (Shared Vision).

Y lo hace de una manera trasgresora. Aunque no lo parezca, las cinco disciplinas son en sí mismas importantes mecanismos de aprendizaje; a través de ellas aprendemos a aprender. No se platea un modelo categórico ("para conseguir esto hay que hacer esto"), en posesión de la verdad absoluta. Por el contrario, fomenta el análisis, el estudio de cada aspecto que pueda frenar el progreso de la organización. Se propone un proceso continuo de aprendizaje en todos los niveles, un cambio cultural permanente para transformar la empresa en una organización capaz de aprender de sus procesos internos, de sus errores, de los empleados, de los proveedores, de los clientes, del mercado o de la interacción con la sociedad.

Como no podía ser de otra manera (están muy de moda), os dejo una infografía que resume, aunque no de forma exhaustiva, algunos aspectos relevantes de las organizaciones que aprenden (fuente larninginfographics.com). Por cierto, ¿os habéis fijado que, por una vez, el término en español es más conciso y elegante que el anglosajón?

También puede resultar de interés esta otra, en donde se enlazan las cinco disciplinas con prácticas, principios y herramientas.

ALGUNOS ERRORES DE CONCEPTO

Como ocurre con casi todas las buenas ideas, no han tardado en surgir propuestas para extender el concepto de Learning Organization incorporando las tendencias más en boga de la gestión empresarial. Algunas son demasiado oportunistas, dándole al calzador para incrustar en el modelo las áreas de competencia de sus autores.

¿Que mi empresa se dedica a ofrecer consultoría en coaching o mentoring?, no hay problema, hablo de las barreras para conseguir una integración efectiva de los empleados (falta de tiempo, motivación, conocimiento de los objetivos de la empresa) e incorporo una nueva capa al modelo, innecesaria a todas las luces. ¿Que me dedico a la educación?, ¿acaso no habla precisamente de esto el modelo?. Así que nada, me aprovecho de la popularidad de la propuesta y de la presencia de "Learning" en su denominación, y me montó una organización orientada a la enseñanza.

Sin embargo, el modelo propuesto por Peter Senge bebe de otras fuentes. Habla del análisis, de la transformación continua, de la necesidad de colaboración y del desafío individual como medio para alcanzar los objetivos empresariales. Establecer un proceso de mentoring o fomentar la formación son meras herramientas, adecuadas o no en función de las necesidades y cultura de la organización.

Otro error frecuente parte de considerar una "Learning Organization" como una especie de comuna hippy; el famoso "Venga chicos, todos a colaborar con la máxima ilusión para engrandecer a la empresa". Empero lo que pueda pensarse, el modelo no sólo no descarta la Competitividad, tanto individual como grupal, sino que la fomenta en todos los estamentos. Es necesario colaborar, sí, pero como medio para el crecimiento personal y colectivo.

HACIA UNA EMPRESA INTELIGENTE

Hablaba al principio del debate para establecer las fronteras entre la Gestión del Conocimiento y el Aprendizaje. Confirmo mi derrota frente a aquéllos que proponían un alcance más global para este último. En realidad, las propuestas de mis contendientes iban por derroteros algo diferentes a los propuestos aquí, pero es verdad que su planteamiento era algo más acertado.

Las nuevos modelos encaminados a establecer el funcionamiento de empresas capaces de sobrevivir en la Sociedad del Conocimiento (curiosamente, al principio de los tiempos se hablada de la Information Society, poco más tarde de la Knowledge Society, quizás ahora habrá que referirse a ella como la Learning Society) dejan la Gestión del Conocimiento por los suelos, en el nivel más bajo de la escala de valor.

La Gestión del Conocimiento (Knowledge Organization) se convierte así en el primer paso, en el componente de más bajo nivel, del proceso de aprendizaje empresarial (Learning Organization), el cual es, a su vez, un mero instrumento para transformar la empresa en una máquina innovadora (Innovation Organization) y, finalmente, en una Empresa Inteligente (Smart Organization).

La pirámide elegida para ilustrar esta evolución (Knowledge->Learning->Innovation->Smart) también sirve para constatar el afán existente por colocar algunos conceptos en los niveles más cercanos a la cúspide. ¿Sabéis a que me estoy refiriendo?.

En el tercer nivel aparece la Innovación atosigada por la Mejora Continua. La mejora es fundamental y está (o debe estar) presente en todos los procesos y en todos los aspectos de la existencia: ¿acaso no vivimos y trabajamos para mejorar?.  Pero podemos hacerlo poco a poco, conociéndonos mejor, aprendiendo de cada actividad que realizamos, de las personas que la vida pone en nuestro camino. No siempre necesitamos fomentar cambios sustanciales, no siempre necesitamos innovar para mejorar. Enlazar ambos conceptos es, desde mi punto de vista, un error demasiado frecuente.

Sea como fuere, la capacidad de innovación es un factor crítico para cualquier empresa que pretenda sobrevivir en un mercado tan cambiante como el actual: "Renovarse o morir". No hablamos sólo de la capacidad para lanzar nuevos productos y servicios o de mejorar los existentes, el proceso de innovación debe abarcar los procesos internos, la cultura empresarial y los modelos mentales que rigen el funcionamiento de cualquier organización. Y debemos ser capaces de cambiar cada vez con mayor celeridad. Antes se hablaba de ciclos de cinco años para marcar la necesidad de reorganización en una empresa. Ahora se piensa en ciclos de tres o incluso dos años.

Otro aspecto fundamental se refiere a la oportunidad del cambio. En el pasado las empresas actuaban de forma reactiva: algo va mal, el mercado ha cambiado, las ventas bajan, tenemos que adaptarnos o desaparecer. Ahora se busca la proactividad, la anticipación a futuros cambios en el entorno. Es fácil proponer el cambio cuando una empresa está en dificultades, lo difícil es embarcarse en él cuando todo va bien.

Concebimos así la Empresa Inteligente (Smart Ogranization) como una organización capaz de gestionar y explotar el conocimiento adquirido en cada una de las actividades que emprende, capaz de analizar con honestidad sus capacidades, capaz de reinventarse a sí misma para crear una cultura empresarial que elimine las barreras, fomente el crecimiento individual y la colaboración en pos de lograr un entendimiento común que facilite la consecución de los objetivos estratégicos. La Empresa Inteligente debe embarcarse en un proceso continuo de transformación, de renovación de los procesos internos, de las herramientas disponibles, de los modelos mentales que marcan su funcionamiento, innovando en todos los niveles para ofrecer productos y servicios mejorados capaces de competir en un mercado que cambia y se transforma a un ritmo acelerado.

Las Guías de Adaptación en la Gestión de Proyectos

"Mi proyecto es un tanto peculiar". ¿Cuántas veces revisamos un proyecto y recibimos esta respuesta al constatar que el Jefe de Proyecto no está siguiendo la metodología de gestión establecidas por la empresa?. No son sólo los métodos de trabajo; seguramente haya desarrollado herramientas propias (algún Excel tendrá por ahí), alterado algunos formularios de la organización (algún campo le sobrará y echará de menos otros que considera imprescindibles) y haya decido saltarse pasos de, por ejemplo, la fase de establecimiento del proyecto al considerar que no le aportan valor alguno.

Da igual cómo de robusta sea la metodología de gestión y desarrollo de proyectos que propone la empresa, es indiferente que esté basada en estándares reconocidos internacionalmente, el Jefe de Proyecto, cual Sherlock Holmes de la gestión, siempre encontrará algo que no encaja.

En mi empresa, donde nos enorgullecemos de fomentar una Cultura de Innovación, es el pan nuestro de cada día. Todos somos inconformistas, todos buscamos las mejores soluciones y todos opinamos sobre cualquier cosa.

No me malinterpretéis. La duda, el inconformismo, la inquietud son palancas imprescindibles para promover la innovación y con ella la mejora. Debemos admitirlas y promoverlas pero, sobretodo, debemos poder controlarlas y saber cómo sacar partido de ellas.

Análisis de las causas que nos impiden identificar las verdaderas causas de los problemas (5W)

Simplificando, las causas principales de los problemas pueden agruparse en las siguientes categorías:

• Problemas Técnicos
• Comportamiento Inadecuado
• Falta de Recursos
• Procesos mal establecidos

Están ordenadas en función de un indicador mágico: el grado de satisfacción que provocan en el Responsable de Calidad cuando es capaz de identificarlas.

Perdonadme este desfalco a la honestidad, profesionalidad y responsabilidad del Responsable de Calidad. Es una inocente ocurrencia para reflexionar sobre uno de los grandes problemas: llegar al fondo de las causas que provocan los problemas y asumir las consecuencias de tales hallazgos.

Mi intención no es desarrollar una taxonomía exhaustiva de la causa raíz, ni exponer las diferentes técnicas que pueden aplicarse para la detección y solución de problemas. En su lugar, voy a centrarme en algunos problemas típicos cuyas causas reales suelen ser mal identificadas. Estos ejemplos permitirán analizar las causas que provocan la mala identificación de las causas de los problemas.

PROBLEMAS TÉCNICOS

¿Hay algo mejor que detectar un fallo en un sistema de gestión o en el algoritmo que calcula un indicador?.

Desde la perspectiva del Responsable de Calidad, un fallo técnico es una gran noticia. La causa del problema está clara (hay un error de programación, por ejemplo), la solución también (basta corregir el error) y, analizar la eficacia, casi evidente (se prueba el sistema y se comprueba que todo funciona correctamente).

Por desgracia, ésta no suele ser la causa raíz del problema. Si lo fuera, estaríamos hablando de un fallo puntual que podría corregirse de forma inmediata sin necesidad de un plan de acciones correctoras. En consecuencia estaríamos declarando que el análisis realizado nos lleva a pensar que el problema no se va a reproducir en el futuro. Conociendo a los informáticos (y yo soy uno de ellos) esto no va a ser así.

Si profundizamos un poco más, por ejemplo utilizando la técnica de análisis de los "5 porqués", quizás lleguemos a conclusiones muy diferentes:

1. ¿Por qué ha fallado el sistema?: porque ha habido un fallo de programación en un módulo
2. ¿Por qué ha habido un fallo de programación?: porque se han realizado unos cambios recientes en otro módulo que han provocado efectos laterales que se ha transmitido al que ha fallado
3. ¿Por qué no se han controlado los efectos laterales?: porque las pruebas de integración no se realizaron de forma adecuada
4. ¿Por qué las pruebas no detectaron el problema?: porque no hubo tiempo para hacerlas de forma exhaustiva
5. ¿Por qué las pruebas no se realizaron de forma exhaustiva?: porque había que realizar la entrega a tiempo y el producto salió de sistemas demasiado tarde
6. ¿Por qué no hemos dispuesto de tiempo suficiente?: porque se planificó mal el nuevo desarrollo o porque fallaron las estimaciones o porque no había recursos suficientes o porque los programadores no están correctamente cualificados.

Un problema que se puede solucionar con un simple cambio en la programación se ha convertido ahora en un gran dolor de cabeza. ¿Despedimos a los programadores?, ¿solicitamos más recursos para el Departamento de Sistemas a sabiendas que no los van a conseguir?, ¿cambiamos la metodología de desarrollo empleada para hacerla más pesada y menos tolerante al fallo lo que supondrá la necesidad de disponer de más recursos?, ¿compramos mejores herramientas de testing para que, con los mismos recursos humanos, podamos mejorar la validación del producto?.

Todas son soluciones factibles pero todas suponen cambios importantes y planes de acción que se van a extender en el tiempo al igual que la evaluación de la eficacia. Cambiar a un programador o instalar una nueva herramienta no garantiza "per se" la mejora. Habrá que analizar el número de fallos detectados en los próximos meses, analizar cada uno de ellos, etc.

Así que, con cierta probabilidad, optaremos por planificar una formación en pruebas de sistemas, la panacea de la solución de casi todos los problemas (es un decir).

Una curiosidad, Panacea era la hija de Lampetia y Asclepio (Eusculapio para los romanos), dios de la medicina y la sanación adorado en Epidauro y en todo el Peloponeso. Su hermana más conocida es Higia de donde ha derivado el término higiene; una familia con bastante presencia en el diccionario.

COMPORTAMIENTO INADECUADO

Si no podemos encontrar algún problema técnico, siempre podemos recurrir al fallo humano:

• Ha sido un despiste
• No hay suficiente conciencia de la importancia de seguir el proceso
• No se conoce suficientemente bien el proceso que debe seguirse
• El Jefe de Proyecto ha estado dos semanas de baja

Otra gran noticia: instamos a la persona a que no sea tan despistado, planificamos una formación, una acción de concienciación o esperamos a que el Jefe de Proyecto recupere el tiempo perdido. En todos los casos, el fallo detectado puede corregirse de forma casi inmediata.

No digo que no sean acciones que haya que plantear o que puedan alegarse como causas circunstanciales, pero me temo que tampoco son la causa raíz del problema.

• ¿Por qué se ha despistado el Jefe de Proyecto?: porque no le ha dado la suficiente importancia al proceso
• ¿Por qué no le ha dado importancia al proceso?: porque no lo considera un aspecto crítico en su trabajo
• ¿Por qué no lo considera crítico?: porque no le aporta suficiente valor para dedicar los recursos necesarios
• ¿Por qué no le aporta valor?: porque el proceso o metodología no se adapta a sus necesidades
• ¿Por qué el proceso no se adapta a sus necesidades?: porque está mal diseñado

Y, nada, nos tomamos otra aspirina. Tenemos que redefinir la metodología de gestión y desarrollo de proyectos, crear nuevas herramientas de control (por ejemplo, checklists o herramientas de gestión de proyectos), planificar formaciones y acciones de concienciación. Y, finalmente, ver si con todo esto se consigue que se produzcan menos "despistes".

Por último, comentar que la baja médica no es la causa raíz de ningún problema; es un síntoma de un enfermedad mucho más grave de la que hablaremos a continuación.

FALTA DE RECURSOS

Descartados los problemas técnicos y los fallos humanos, siempre podemos investigar un poco más para ver si los recursos asignados al proyecto no son adecuados:

• Hay demasiadas bajas médicas 
• Hay demasiada carga de trabajo
• La rotación del personal es muy elevada
• La capacitación del personal no es adecuada

Fácil de nuevo. Las bajas o la carga de trabajo podemos considerarlos temas puntuales; la rotación del personal es consecuencia de la situación del mercado, no hace sino constatar la excelencia de los profesionales de la empresa tan deseados por la competencia; planteamos algunas formaciones y, en seis meses,  convertimos a un junior sin experiencia en un senior.

Tampoco ahora nos enfrentamos con una buena enumeración de causas primeras. En realidad hemos identificado algunos síntomas de una grave enfermedad que afecta a los fundamentos de la organización. Las acciones que podamos tomar para aliviarlos serán como los medicamentos para la gripe: alivian los síntomas pero la enfermedad sigue allí, latente.

Profundizando un poco más:

1. ¿Por qué no hemos entregado a tiempo?: porque ha habido rotación, bajas medicas y una carga de trabajo excepcionalmente alta.
2. ¿Por qué estos factores han afectado a la entrega?: porque no se han considerado en las estimaciones del proyecto
3. ¿Por qué no se han realizado correctamente las estimaciones?: porque el análisis de riesgos no se ha realizado de forma adecuada
4. ¿Por qué el análisis de riesgos no es correcto? porque no se han planificado acciones de mitgación eficaces

Esta línea de razonamiento no es la única, las hay mucho peores:

1. ¿Por qué no hemos entregado a tiempo?: porque carecemos de los recursos adecuados
2. ¿Por qué no disponemos de recursos?:  porque el presupuesto del proyecto no lo permite
3. ¿Por qué el presupuesto no se ha corregido?: porque de hacerlo no habríamos ganado el proyecto
4. ¿Por qué no podemos ganar el proyecto?: porque nuestros costes nos dejan fuera del mercado

El azar como causa raíz de un problema, se ha convertido, en el mejor de los casos, en una mala planificación o, en el peor, en la constatación  de la quiebra inminente de la empresa.

Concentrándonos en la primera causa, la mala planificación (la segunda requiere de un plan estratégico y un replantamiento global que afectará a todos los estamentos de la empresa) necesitaremos, probablemente, planificar un conjunto amplio de acciones, todas dolorosas (en el sentido de que requieren un gran esfuerzo para ser implementadas con éxito):

• Mejorar el proceso de análisis y control del ramp-up de recursos del proyecto (la planificación futura de la carga de trabajo estimada) que será la base para el subsiguiente análisis de riesgos
• Incluir la disponibilidad de recursos en los análisis de riesgos y asegurar que se definen acciones de mitigación incluyendo el coste, coste que debe ser asumido en el presupuesto del proyecto lo que provocará una bajada del margen operativo o pérdida de competitividad al obligar a incrementar la oferta económica
• Establecer un proceso de análisis, validación y revisión de las competencias de los equipos de trabajo de los proyectos. De este análisis deberán surgir acciones de formación (cuando el proyecto lo permita) o la solicitud de nuevos recursos
• Crear una Oficina de Gestión de Programas que garantice la disponibilidad y adecuación de los recursos en el todo momento

Todas ellas requieren un alto nivel de madurez en la organización, suponen un coste y asumir que, a veces, no podemos vender al precio que exige el mercado.

PROCESOS MAL ESTABLECIDOS

Casi todo lo expuesto anteriormente queda reflejado en una mala definición de los procesos de la organización: causas mayores.

Si un Jefe de Proyecto no da importancia a realizar un correcto análisis de riesgos, seguramente es porque no le encuentra utilidad alguna. Puede ser incompetente, pero es más probable que hayamos reducido este análisis a la selección de unos cuantos elementos de una lista definida hace años por un comité de sabios a los que luego debe asignar una probabilidad y un impacto a partir de unas escalas definidas siguiendo un proceso similar. Es un problema del proceso de estimación, no del Jefe de Proyecto.

En la elaboración del presupuesto de un proyecto debe siempre incorporarse el riesgo como un factor que incrementa el coste: se calcula el presupuesto en condiciones ideales y se aplica el factor de riesgo obtenido a los costes estimados. Aumenta el precio pero también aumenta el margen (si todo va bien) o lo aseguramos en cierta medida si hay problemas. ¿Qué va a ocurrir?. Probablemente, el Jefe de Proyecto tienda a subestimar los riesgos a sabiendas de que el cliente no aceptará una oferta económica más elevada o se vea forzado por la necesidad de obtener un cierto margen impuesto por la organización. Y esto no se puede evitar pero sí controlar. Cuando se detecta una desviación es siempre necesario analizar el plan de riesgos establecido y el grado de incertidumbre trasferido al presupuesto. Y, sobretodo, exigir responsabilidades cuando estos análisis hayan sido mal realizados o menospreciados.

Cuando no disponemos de los recursos técnicos o humanos adecuados está de nuevo fallando el proceso de estimación pero también el proceso de selección (recrutamiento) o el proceso de capacitación. También es posible que no seamos capaces de mover los recursos con la suficiente celeridad de unas áreas a otras. Probablemente no exista un proceso que nos permita conocer de forma global las necesidades de recursos a corto y medio plazo (el famoso ramp-up).

Las situaciones expuestas requieren, probablemente, la creación de una Oficina de Proyectos/Programas y la redefinición de algunos de los procesos de gestión para, entre otras cosas, hacer a la nueva oficina partícipe en ellos.

Y cambiar un proceso de forma sustancial implica, en ocasiones, un cambio cultural y, casi siempre, unos costes iniciales elevados (nuevos roles y responsabilidades, formación, etc.) que, en no pocas ocasiones, tardan en ser rentabilizados. No se puede hacer magia, los márgenes o la calidad de las entregas no van a cambiar en unas semanas. No se puede mejorar la capacitación de los equipos de trabajo con veinte horas de formación.

Una aspirina no va ser suficiente cuando el Responsable de Calidad plantea este tipo de acciones, va a necesitar una buena inyección de morfina.

LAS CAUSAS DE LAS CAUSAS

De las anteriores reflexiones podemos deducir algunas de las causas que provocan un incorrecto análisis de las causas de los problemas:

1. ¿Por qué no analizamos correctamente las causas?: porque tendemos a buscar sólo la que ofrece la solución más sencilla o inmediata.
2. ¿Por qué la facilidad o la inmediatez son factores determinantes en la selección de una solución?:  porque cuanto más sencilla e inmediata sea menos recursos deberemos dedicar a la ejecución, seguimiento y medida de la eficacia de los planes de acción. Tenemos recursos limitados y no siempre queremos o podemos asumir las consecuencias de un análisis más sincero.
3. ¿Por qué no disponemos de los recursos necesarios?: porque no resulta sencillo transmitir a la organización el coste de la "no-calidad"
4. ¿Por qué no somos capaces de transmitir el coste de la no-calidad a la organización?. Porque es complicado demostrar el Retorno de la Inversión de algunos cambios sustanciales y más aún demostrar con datos empíricos las consecuencias de no implementarlos.
5. ¿Por qué no somos capaces de justificar el retorno de la inversión?. Porque no siempre se obtendrá a corto plazo y las organizaciones suelen estar presionadas por la inmediatez, por la necesidad de obtener resultados antes de que termine el año fiscal.

Este análisis no es el único que puede realizarse pero si es sustancial. Incluye un factor humano (siempre tendremos a no buscar más problemas de los necesarios), un factor organizacional y económico (tenemos que trabajar con los recursos de que disponemos; debemos ser realistas) y un factor técnico o metodológico sobre el que se lleva décadas discutiendo: cómo justificar el coste de la no-calidad.

Workplace: Lecciones Aprendidas

Lección Aprendida: Una buena práctica de trabajo, experiencia o enfoque innovador que es obtenido y compartido para promover aplicaciones repetidas. Una lección aprendida puede también ser una mala práctica de trabajo o experiencia adversa que es obtenida y compartida para evitar su recurrencia.

Aún comenzando con una definición, no es mi intención dedicar este espacio a hablar sobre las Lecciones Aprendidas, los modelos para su definición, la forma de analizarlas o su importancia para los Sistemas de Gestión de la Calidad y, en particular, la Mejora Continua.

Me limitaré a explicar cómo podemos incorporarlas al Espacio de Trabajo que estamos construyendo de un forma sencilla, utilizando los formularios de Google Docs.

COMENTARIOS Y VALORACIONES

Antes de pasar a las lecciones, podréis comprobar que el Portal Web que estamos utilizando como ejemplo ofrece en todas sus páginas la opción de incorporar comentarios y de pulsar sobre el, más o menos, famoso botón G+1 (ver ejemplo).

Nunca debemos denostar estas dos opciones. Aunque no aportan información estructurada y es, por tanto, más complicado emprender cualquier análisis sobre ellas, serán probablemente las alternativas que se usen con mayor profusión. Y lo serán por una sencilla razón: son fáciles de usar. ¿Qué cuesta hacer un Click?. ¿No apetece más escribir unas cuantas líneas sobre un tema que acabo de consultar por primera vez que adentrarme en un complejo formulario de lecciones aprendidas?.

Yo recomiendo ofrecer siempre estas dos opciones en cualquier contenido que ofrezcáis a la organización. Nos son costosas de implementar y favorecen en gran medida la comunicación e interacción entre los implicados. Incluso pueden llegar a ser suficientes para detectar oportunidades de mejora o defectos en los procesos.

LECCIONES APRENDIDAS

Para implementar este sistema vamos a crear un formulario en el DRIVE. Será quizás demasiado sencillo pero. como he dicho, no pretendo aquí entrar a debatir sobre los diferentes modelos que pueden implementarse para recopilar Lecciones Aprendidas.

Desde el punto de vista la implementación, Google nos ofrece la posibilidad de crear cualquier tipo de formulario mediante un sencillo interfaz accesible a usuarios de cualquier nivel.

El sistema está más orientado al envío de cuestionarios (nos vendrá muy bien cuando hablemos de evaluar la satisfacción del cliente) pero puede ser utilizado sin problemas para cubrir otras funcionalidades.

Pulsando sobre el botón CREAR en alguna carpeta del área pública del DRIVE (si lo hacemos desde el área privada, no podrán acceder a él la mayoría de las personas), nos aparecerá una lista de posibles objetos que podemos crear y, entre ellos, uno de tipo FORMULARIO.

Tras ponerle un nombre y elegir un diseño, podremos pasar a definir las diferentes área del cuestionario:

• Problemática detectada
• Área de Mejora
• Plan de Acción
• Impacto de las acciones emprendidas
• ¿Es posible aplicar la experiencia en otras áreas de la empresa?
• ¿En cuáles?

Si quieres probar el formulario, pulsa AQUÍ.

Creado el formulario/cuestionario podrás acceder a él desde el DRIVE y enviarlo a las personas que consideres oportuno (utilizando la opción compartir o enviar del menú contextual que aparece pulsando sobre el formulario con el botón derecho/secundario). No es la forma en que vamos a utilizarlo, pero puede ser útil para solicitar que se informe sobre las lecciones aprendidas en proyectos donde hayamos detectado algún problema.

El siguiente paso es definir dónde quieres que se guarden las respuestas. Puedes hacerlo desde el editor del formulario dando un nombre a una hoja de cálculo e indicando una carpeta donde quieres guardar la información. Aquí hay dos opciones: hacerlo en un área privada si no quieres que la información esté disponible o en el área pública dando acceso a toda o parte de la organización. En ambos casos, dispondrás de una hoja de cálculo (que puedes convertir fácilmente a Excel) con la lista completa de lecciones aprendidas. Desde ella podrás hacer cualquier tipo de análisis, incluir gráficos, etc. Y, por supuesto, será actualizando automáticamente a medida que se vaya recibiendo información.

En la imagen puedes ver los dos documentos asociados con el sistema de Lecciones Aprendidas (el formulario y la hoja de cálculo con la información que vayamos recibiendo) alojadas en el área pública del WorkPlace.

INTEGRACIÓN CON EL PORTAL WEB

Como siempre, vamos a ofrecer los sistemas que estamos desarrollando de una forma mucho más amigable. Para ello, incluiremos en cada una de las secciones del portal dos enlaces. El primero permitirá comunicar una lección aprendida sobre el tema que se esté consultando. El segundo dará acceso a las lecciones aprendidas ya recopiladas sobre ese área.

Podéis ver un ejemplo sobre lecciones aprendidas asociadas al Proceso de Gestión de Cambios (Change Requests) pulsando AQUÍ.

Es fácil configurar el sistema para que filtre las lecciones del tema que estamos consultando. En este EJEMPLO, veréis sólo las relacionadas con los Change Requests.

También he añadido una opción en el menú principal para acceder a la base de datos completa de lecciones aprendidas.

CONCLUSIONES

Tras esta nueva ampliación, tenemos un Espacio de Trabajo que ofrece la documentación a toda la organización mientras nos permite controlar las revisiones de cada contenido y publicar de forma controlada.

En cada sección podemos incluir comentarios, expresar nuestro interés y añadir lecciones a aprendidas.Tenemos también mecanismos sencillos para analizar esta información y para ofrecerlas al conjunto de la organización desde diferentes puntos de vista.

Son herramientas al alcance de cualquier persona que se maneje con un cierto desparpajo por Internet o las Redes Sociales. No quiero decir con esto que se aprenda a manejarlas en 5 minutos, los interfaces de Google son un tanto peculiares quizás por ser demasiado minimalistas. Pero, tras unos cuantos experimentos, comenzaréis a comprender el funcionamiento y a cada paso os será más sencillo sacarles partido.

Para acabar comentar que es posible ampliar las funcionalidades que ofrecen los formularios hasta donde queramos incluyendo algo de programación. Si disponéis de alguna capacidad de desarrollar software podréis convertirlos en una herramienta realmente potente.

---

Primeros pasos para construir un Workplace con Google Apps for Business

INTRODUCCIÓN

Comienza con éste una serie de artículos que explicarán como crear un Espacio de Trabajo (Workplace) en La Nube.(más...). El Sistema de Gestión de la Calidad quedará embebido en esta plataforma hasta hacerse casi imperceptible (más...). También conseguiremos quitarnos de encima esos ficheros Excel que andan pululando por todas las organizaciones (más...)

Para ello utilizaremos algunas de las herramientas que nos ofrece Google en una aproximación necesariamente sencilla. No obstante, al final, quizás tengamos en nuestras manos un plataforma capaz de ofrecer funcionalidades que no están al alcance de todas las organizaciones.

He creado un ejemplo concreto que puede utilizarse para seguir algunas de las explicaciones. Si tienes una cuenta en Google+ podrás ir creando tu propio Workplace; como comprobarás no se necesitan conocimientos técnicos, sólo manejarse con cierta soltura en Internet.

ANTES DE COMENZAR

Si aún no lo has hecho, deberías consultar estos dos enlaces:

• Construir un Workplace, un espacio en la nube donde trabajar hacia la Excelencia
• ¿Debería subirme a la Nube de la mano de Google?

También es importante que entiendas la diferencia entre Google y Google Apps for Business. La segunda es la versión empresarial de la primera, es decir, ofrece las mismas herramientas pero limitadas al entorno de una organización.

Para esta serie de artículos utilizaremos la versión estándar, desarrollando un espacio de trabajo público pero, si te importa un ápice la seguridad, deberías contratar la versión empresarial para tu proyecto. No te preocupes, no te saldrá muy caro.

Dos detalles finales:

• Voy a dejar de hablar del Sistema de Gestión de la Calidad (SGC) para referirme al Sistema de Gestión (SG)
• Tampoco hablaré de usuarios de las plataforma. Los nombraré como colaboradores y, a veces, como clientes (internos, externos, proveedores, etc.) (más...)

EL ESPACIO DE TRABAJO

Podéis acceder al ejemplo que utilizaremos en esta serie de artículos a través del siguiente enlace:

https://sites.google.com/site/sgcejemplo/

Por el momento no esperéis demasiado, lo iremos construyendo a medida que avancemos.

Si queréis ir haciendo el vuestro, podéis utilizar GOOGLE SITES accediendo a esta dirección:

https://sites.google.com/

Simplemente seleccionar la opción CREAR NUEVO SITIO y seguir los cuatro pasos que se indican (poner un nombre, elegir un diseño y una plantilla y poco más)

LA DOCUMENTACIÓN DEL SISTEMA DE GESTIÓN (SG)

Comenzaremos la serie explicando como gestionar y ofrecer la documentación del SG a nuestros clientes. Cubriremos así algunos aspectos del SGC como la Gestión Documental, el Control de Versiones, el Archivo y la Gestión de Documentación Obsoleta, la Identificación y Registro y la Comunicación. También añadiremos alguna cosilla más para comenzar a gestionar Lecciones Aprendidas y Mejores Practicas relacionadas con Mejora Continua.

Y espero poder hacerlo en los próximos veinte párrafos.

Nuestro Sistema de Gestión Documental quedará estructurado como sigue:

• Un área privada donde trabajar sobre los documentos del sistema (el Departamento de Calidad pero también el resto de los Propietarios de los Procesos de la organización)
• Un espacio público donde publicaremos los documentos ya aprobados. Esto ya sí lo hará el Departamento de Calidad copiando desde el área privada los documentos tan pronto sean validados.
• Un Portal Web donde ofreceremos la documentación del SG de una manera mucho más amigable.

Los clientes podrán así navegar por el espacio público de una forma más tradicional o utilizar el Portal Web en donde podrán, además, comentar los contenidos, establecer alertas para recibir avisos cuando algo cambie, etc.

ÁREA PRIVADA Y ÁREA PÚBLICA: EL DRIVE

GOOGLE DRIVE es un espacio de almacenamiento en la Nube donde podemos subir documentos de cualquier naturaleza. Para entendernos, es equivalente a DropBox. Google ofrece a todos los usuarios 15Gb (más que suficiente para nuestro propósito) de forma totalmente gratuita que pueden ampliarse hasta varios Terabits previo pago (en la versión empresarial cada usuario tiene 30Gb por defecto).

Una ventaja adicional radica en la posibilidad de enlazar el Drive con el Explorador de Archivos de tu ordenador de forma que puedes trabajar en local con los documentos y éstos se irán sincronizando de forma totalmente automática en el espacio reservado en la Nube (más info...).

Lo primero que debemos hacer es crear los dos espacios en el Drive: uno privado (sólo daremos acceso a personas específicas) y otro público (daremos acceso a toda la organización). Deberíamos acabar teniendo algo así:

Ahora debemos desarrollar la estructura de carpetas de las dos áreas.

Para el ejemplo he optado por un clasificación basada en procesos en el área privada mientras que, en el la parte pública, la documentación quedará organizada por puestos de trabajo o funciones.

La idea es que la jerarquía de carpetas se adapte a las personas que la vayan a utilizar y no al revés.

Os animo que os conectéis para verlo en directo pulsando AQUÍ. Es un enlace al Visualizador de Drive, una herramienta menos potente que el propio Drive. Lo siento, pero sin compartir un dominio no puedo ofreceros más.

Tampoco podréis probar una ventaja adicional. Ya desde este primero momento se puede utilizar toda la potencia del buscador de Google para localizar documentos en nuestro Workplace. Es una herramienta que hace cosas increíbles como, por ejemplo, leer documentos escaneados. Puedes poner la Política de Calidad escaneada con la firma del presidente incluida y, unos pocos segundos después, se habrá convertido a texto y podrás localizarla con el buscador.

EL PORTAL WEB: EL SITE

El siguiente paso es enlazar la documentación que tenemos disponible en el área pública del Drive con un Portal Web creado con Google Sites.

No voy a entrar en cómo crear un Site; en realidad estamos hablando de Gestión de la Calidad, Pero os dejo unas ideas básicas.

Lo primero es crear una página que explicará el objetivo de la sección y ofrecerá un índice sencillo a cada área del sistema. A partir de ella iremos creando todas las demás. Podéis verla AQUÍ.

Es importante que cada página tenga siempre una estructura similar aunque adaptada en su propósito. En este caso he optado por:

Pulsa en la imagen para ver el ejemplo

Título de la Página Propósito General Documentos Asociados Índice de sub-secciones Acceso directo al Drive para un acceso más avanzado Botón de Google+ Posibilidad de incluir Comentarios

ÚLTIMOS DETALLES

Sin hacer nada más tenemos ya acceso móvil a la documentación del sistema (instalando Google Drive en tu móvil desde Google Play). También podemos acceder al Portal Web desde el navegador del móvil. Esta última funcionalidad  debería desarrollarse más para ofrecer Responsive Design, una tecnología ya común en las redes sociales que ajusta los contenidos a las dimensiones y capacidades del smart phone. En cualquier caso, conociendo a Google no tardará en llegar.

En cuanto a la forma de ofrecer la documentación, he optado por construir algo parecido a una Wikipedia pero se puede enlazar el Site con el Drive de una forma mucho más directa. Os dejo AQUÍ un ejemplo.

SIGUIENTES PASOS

En la siguiente entrega de esta serie descubriremos que ya casi tenemos listo el sistema de control de versiones. Veremos como establecer alertas a diferentes niveles y añadir un sistema de lecciones aprendidas.

---

WORKPLACE: Control de Versiones, Alertas y Notificaciones

>>

¿Se puede evaluar la satisfacción del cliente con un sólo indicador?

La respuesta es: CASI. En realidad propongo utilizar sólo cuatro indicadores: tres relacionados con la evaluación objetiva de la satisfacción del cliente y uno sólo más relacionado con la evaluación subjetiva de la satisfacción.

Antes de comenzar, indicar que lo expuesto a continuación está enfocado principalmente a empresas que ofrecen servicios o desarrollan productos llave en mano para un único cliente. Aunque algunas ideas pueden resultar útiles en otros entornos (por ejemplo, en la venta masiva de un producto en el mercado), hay que tomarlas con precaución

EVALUACIÓN OBJETIVA

Cuando montamos un sistema de evaluación de la satisfacción  casi siempre nos olvidamos que, además de analizar si cumplimos con las expectativas de los clientes, debemos también considerar si  satisfacemos las de nuestra organización (más...).

Básicamente estas expectativas son tres:

• Entregar el producto al cliente a tiempo
• Entregar el producto con la calidad esperada
• Mantener los costes de producción dentro de los límites esperados

En definitiva, asegurar el cumplimiento de las tres líneas base del proyecto: Tiempo, Calidad y Coste. Si lo hacemos el cliente quedará satisfecho y la empresa también.

Sobre el coste no merece la pena extenderse. Una organización debería ser capaz de saber el margen operativo (ingresos menos gastos) previsto y el resultado final. El margen podría ser un candidato primer indicador (indicadores financieros hay muchos así que elegid el que sea más relevante para la Dirección)


INDICADORES DE ENTREGA

Disponemos de otros dos indicadores que, poco a poco, se van convirtiendo en un estándar:

• On Time Delivery (OTD)
• On Quality Delivery (OQD)

Calcular el primero es realmente sencillo:

OTD = Número de entregas realizadas a tiempo / Número de Entregas realizadas

Puede utilizarse para caracterizar un único proyecto, los que realizamos para un mismo cliente o todos los de la organización. Es posible así establecer criterios de comparación objetiva del desempeño de unas áreas y otras. Otra valor añadido de este indicador es que podemos (y debemos) calcularlo en una ventana de tiempo (por ejemplo en un mes)

El segundo es algo más complicado ya que implica evaluar la calidad de un entrega. Sin embargo, suele definirse como:

OQD = Número de entregas realizadas sin no-conformidades / Número de entregas realizadas

Entendiendo que una entrega con una no-conformidad es aquella rechazada por el cliente y que requiere realizar una acción de corrección antes de proceder a su reenvío. Cambios menores en su contenido o propuestas de mejora no constituyen una no-conformidad

El indicador tiene las mismas ventajas que el anterior pero requiere una cierta madurez en la organización que entrega y en la que recibe. El proceso de entrega debe estar especificado sin fisuras y los criterios de validación y aceptación claramente establecidos.

Net Promote Score (NPS)

Para mí este es el indicador de evaluación subjetiva de la satisfacción del cliente por excelencia. Está relacionado con la única pregunta que siempre se debe hacer a un cliente:

¿Nos recomendaría a un familiar o amigo?

La mayoría de empresas incluyen esta pregunta en sus cuestionarios de satisfacción y muchas de ellas ya sólo incluyen esta.

La parte más importante, y quizás la menos perceptible, tiene que ver con la perspectiva emocional. No le preguntamos si nos recomendaría a otra empresa o a un socio; queremos saber si lo haría a una persona en la que confía. Si nos recomienda a su hermano, ¿cómo va a dudar en recomendarnos a otra empresa?. Es, por tanto, un indicador relacionado con las expectativas de crecimiento de nuestra organización.

Si un cliente no nos recomendaría a un miembro de su círculo más cercano, podemos estar seguros que hay algún problema en el servicio que le estamos ofreciendo. Es aquí, cuando se detecta algún problema, cuando debe comenzar un proceso de investigación más exhaustivo. Quizás decidamos entrevistarnos con el cliente o enviarle un cuestionario más detallado que nos permita analizar mejor las causas de su insatisfacción.

Para calcular este indicador, se le ofrece al cliente un escala entre 0 y 10 donde el valor mínimo se corresponde con "no os recomendaría de ninguna manera" y el máximo con "os recomendaría con total seguridad". 

En función de esta respuesta los clientes se clasifican como:

• DETRACTORES: respuesta entre 0 y 6. Necesario investigar las causas
• PASIVOS: respuesta entre 7 y 8
• PROMOTORES: respuesta entre 9 y 10.

La siguiente escala muestra esta diferenciación y cómo se calcula el NPS global de la compañía:

De la formula anterior se deduce que NPS varía entre -100 (todo el mundo es detractor) a 100 (todo el mundo es promotor). Se considera que un índice superior a 50 está en niveles de Excelencia.

Dos ventajas adicionales. La primera radica en su versatilidad. El indicador puede considerarse para evaluar la satisfacción de un cliente en un proyecto concreto, de la empresa en su conjunto e incluso para evaluar la satisfacción de proveedor y empleados (clientes internos, en definitiva). La segunda es inherente a la propia simplicidad del proceso y el poco esfuerzo que requiere por parte del cliente (a parte de su compromiso emocional). No hará falta de que le intentemos convencer de que sólo le llevará 5 minutos completar la encuesta: tardará un segundo.

En realidad tardará algo más. Es más que frecuente completar tan mínima encuesta con dos preguntas abiertas:

• ¿Qué hemos hecho mal?
• ¿Cómo podemos mejorar?

La primera nos permite adelantar el proceso de análisis de la causa raíz cuando hay algún problema. La segunda facilita la identificación de áreas de mejora.

Ambas aportan honestidad a nuestra empresa.

ANÁLISIS DEL INDICADOR

Una forma habitual es realizar análisis comparativos entre el NPS y otros indicadores. En el ejemplo de la izquierda, realizado por una operador de cable, se relaciona NPS con el indicador CLV (Customer Lifetime Vaue), la estimación (en euros) que una empresa otorga a la relación con un cliente. CLV es un indicador financiero, frío, casi cruel, que puede resumirse en la frase "some customers are more equal than others".

Se observa que el CLV para el grupo de promotores (el de más a la derecha) se encuentra sobre el 40% mientras que los detractores, a la izquierda, se sitúan rondando el 25%.

Es también frecuente relacionar NPS con las cifras de venta o los indicadores de crecimiento (más...) e incluso con la cuota de mercado (más...)

CONCLUSIONES

Deberíamos al menos plantearnos si nuestro sistema de evaluación de la satisfacción del cliente es excesivamente complejo. Quizás tenga indicadores que poco aportan, que son complejos de analizar o sobre los que es realmente complicado actuar.

En mi opinión, este es un juego más que interesante de indicadores:

• %MOP: Porcentaje del Margen Operativo
• OTD: On Time Delivery
• OQD: On Quality Delivery
• NPS: Net Promote Score

¿Hacen falta más?, ¿Qué opináis?