¿Debo dar acceso a los clientes al Sistema de Gestión?

La respuesta es: SÍ, rotundamente SÍ. Ahora bien, si alguna vez ha sido importante meditar ciertas decisiones, seguramente, ésta es una de ellas.

Lo primero que debemos plantearnos son las siguientes preguntas:

• ¿Para qué quiero darles acceso?
• ¿Qué voy a ofrecer a los clientes?
• ¿Qué me aportarán los clientes?
• ¿Qué riesgo estoy dispuesto a asumir?
• Cómo puede ofrecerles un acceso tan ágil como controlado

¿PARA QUÉ QUIERO DAR ACCESO A LOS CLIENTES?

Me he encontrado en ocasiones con empresas que dan acceso a los clientes (o proveedores) a su red interna para que puedan consultar las políticas, la documentación del SGC o para explicarles las bondades de la compañía. Si sólo quieres esto, mejor utiliza la Web Corporativa. Crea una sección específica para clientes y déjala en manos del Departamento de Comunicación o Marketing.

Mucho más interesante es hacer partícipes a los clientes de nuestros procesos y, en particular, de los procesos ligados a la gestión de los proyectos (productos o servicios) que les ofrecemos.

¿QUÉ VOY A OFRECER A LOS CLIENTES?

Entre otras muchas cosas, podríamos ofrecerle información sobre:

• Entregas realizadas
• Planificación de próximas entregas
• Indicadores de cumplimiento de SLA (Service Level Agreements)
• Análisis de riesgos y oportunidades del proyecto
• Paneles de mejora donde realizar propuesta y ver el estado de las que estén en curso o vayan a implementar (por ejemplo un panel Kanban)
• Documentación del proyecto como normativas de referencias (de la empresa o del propio cliente), actas de reunión, informes de seguimiento, etc
• Un sistema dónde reportar incidencias y reclamaciones
• Un sistema para evaluar su grado de satisfacción con el proyecto

¿QUÉ ME VAN A APORTAR LOS CLIENTES?

Cómo he dicho, los clientes deberían tener una participación activa en nuestros procesos y no sólo limitarnos a ofrecerle información. Conseguiremos así:

• Aligerar el trabajo del equipo de desarrollo y, en especial, del Director del Proyecto. Normalmente las actas de reunión, de seguimiento, informes de indicadores o cualquier documentación que se envíe al cliente se elabora en local, se sube a un servidor y finalmente se envía por correo electrónico al cliente para que la apruebe (o se aprueba por defecto si no responde en unos cuántos días). Si nuestra plataforma permite definir flujos de aprobación, podríamos trabajar directamente sobre el documento y cuándo estuviera listo lo enviaríamos para que sea validado. Casi todas incorporan sistemas de notificaciones así que el cliente podría estar enterado de cualquier cambio sin necesidad de esfuerzos adicionales.

• Mejorar los canales de comunicación con el cliente facilitando su vida y la nuestra. Un sistema de incidencias y de reclamaciones integrado en la plataforma nos evitará tener que recibir correos, registrar la información, procesar la incidencias y volver a enviar correos cuando sea resueltas. Un formulario de satisfacción que pueda rellenar cuando lo desee nos permitirá conocer en todo momento la situación del proyecto. También agilizaremos el proceso de entrega (productos, informes, seguimientos) requiriendo su aprobación a través del sistema o la certificación de los trabajos cuando el proyecto se encuentre en la fase de cierre

• Hacerle partícipe del proceso de mejora continua del proyecto, permiténdole aportar ideas, ver la evolución de las mejoras que estén planteadas, etc. También le informaremos de los riesgos que le afecten o de posibles oportunidades que puedan surgir

• Y, por último, mejoraremos su confianza y la imagen de la empresa profesionalizando la gestión del proyecto, la comunicación con las parte implicadas y la transparencia en nuestras operaciones.

¿QUÉ RIESGO ESTOY DISPUESTO A ASUMIR?

El principal riesgo que subyace tras esta propuesta es la posibilidad de que el cliente acceda a información que no queremos mostrarle (riesgos internos, documentos no finalizados, indicadores económicos, incidencias internas, problemas, etc).

Como sabéis, el riesgo nunca es cero y menos cuando hablamos de seguridad. Por muchas precauciones que tomemos, siempre existe la posibilida
d, por pequeña que sea, de que se produzca un error humano o técnico.

Lo importante aquí es definir un protocolo claro sobre la forma en que los clientes accederán al sistema, quién lo controlará y los riesgos reales que esto implica. De este protocolo y del análisis de riesgos deberán surgir planes de mitigación para disminuir el riesgo hasta unos niveles que sea aceptados por la organización.

¿CÓMO PUEDO OFRECERLES ACCESO?

Obviamente dependerá de la plataforma que tengáis montada. Yo aquí sólo puedo contaros mi experiencia

En nuestro caso tenemos un portal Sharepoint por cada uno de los proyectos que ejecutamos (y son muchos entre 300 y 500 al año). Estos portales se crean de forma automática según ciertas plantillas pre-definidas adaptadas al tipo de proyecto (por ejemplo, los portales para los proyectos que se ejecutan siguiendo las buenas prácticas de CMMI incorporan mucho más funcionalidad que los que sólo deben cumplir la ISO 9001). A partir de aquí, el Jefe de Proyecto nombra un administrador y es él quién gestiona la seguridad interna. Puede asignar permisos a personas de la organización (presentes en nuestro dominio) pero no a personas externas (clientes o proveedores).


Para dar acceso externo, el Administrador del Portal asociado al proyecto, debe poner una incidencia, justificar el motivo y especificar cómo se van a controlar los accesos. Si estamos conformes, se crea un usuario local (en el servidor Sharepoint y fuera del dominio corporativo) al que luego se le puede asignar los permisos y otorgar a las áreas del portal que se considere oportunas.

Aquí caben tres posibilidades:

• Dar acceso al cliente a ciertas áreas del portal en el que trabaja el equipo
• Crea un portal específico para el cliente enlazado con el del equipo de trabajo.
• Dar acceso completo al portal del proyecto

La primera, la preferida por la mayoría de los JPs cuando comenzamos a implantar la plataforma, es más ágil pues se integra en un mismo área de trabajo al equipo y al cliente. Pero es también más arriesgada al tener que controlar qué se publica y dónde.

La segunda, implica crear un subportal dentro del portal de trabajo e ir publicando allí lo que queramos que vea el cliente. Si tenemos unos cuantos riesgos, unos que conciernen al cliente y otros que no queremos mostrarle, tendremos que tener la lista de los riesgos completa en el área privada e ir copiando los que correspondan en el área pública. En definitiva, más trabajo pero también más seguridad.

La tercera requiere un mayor grado de madurez por parte del cliente y del equipo. Ambos comparten la misma información de forma que se reduce el trabajo extra necesario y se mejora la transparencia. Es la
opción más arriesgada pero a la que tienden la mayor parte de los Jefes de Proyecto en la actualidad. Volviendo a los riesgos, ¿de verdad le tenemos que ocultar al cliente los relativos a nuestra gestión interna?, ¿aún pensamos que los clientes esperan que seamos perfectos?. Comprenden (o deberían) que habrá rotaciones, que hay gente más joven y otra más experimentada, que los proveedores se retrasan de vez en cuando, que las pruebas de integración falla o que a veces nos equivocamos en los diseños.

¿Y EL DEPARTAMENTO DE CALIDAD?

Dar acceso al cliente a los sistemas de gestión evita que Departamento de Calidad tenga que intervenir en los procesos de gestión del proyectos enfocándose más en la labor de inspección y mejora continua.

Una buena colaboración con el cliente en la plataforma nos permitirá disponer en tiempo real de las aprobaciones de las entregas y su proceso de validación, asegurar que el cliente comprende los riesgos del proyecto, recibir incidencias y reclamaciones, evaluar su grado de satisfacción en cada una de las fases del proyecto, etc. Y todo ello ocultando nuestro sistema de gestión de la calidad y reduciendo al máximo el uso de formularios en papel, Word o Excel.