Moprosoft es el modelo de procesos para la industria del Software creado en México y que ha tenido una gran aceptación, principalmente derivado del impulso que la Secretaria de Economía a través del programa de apoyos “PROSOFT” le ha brindado a quienes deciden adoptarlo como modelo de referencia para sus empresas.
Quienes hayan trabajado en proyectos de implementación de este u otro modelo en sus empresas sabrán los retos que esto conlleva, tiempo, esfuerzo, dinero y hasta un cierto desgaste en el personal involucrado en el proyecto. Es común escuchar comparaciones con CMMI, decir que Moprosoft es un modelo muy cuadrado o simplemente terminar hablando en lenguaje Moprosoft debido a la intensa adopción del modelo, seguido e interpretado tal cual viene redactado en los libros de la norma.
Después de un largo camino recorrido como consultor para la implementación de Moprosoft en una gran cantidad de organizaciones a lo largo del país, les presento los que considero los errores más comunes al momento de tratar de implementar este modelo en sus organizaciones.
Copiar los procesos de la parte 3 de la norma.
Tal vez este sea el caso más común y promovido erróneamente por muchos consultores y estoy seguro de que es una de las principales causas para no continuar con el uso del modelo.
El libro 3 de la norma es solo un ejemplo para definir los procesos, es una sección considerada informativa, es decir, no es normativo.
Dicho lo anterior, bajo ninguna circunstancia es aceptable copiar estos procesos y adoptarlos como propios, ya que estos procesos no representan la realidad de la operación de sus empresas. Si te estas preguntando si con estos procesos pueden pasar una evaluación, la respuesta es: SI, pero solo de nivel 1 o 2.
Además, estos procesos abarcan prácticas y productos de trabajo de todos los niveles, por lo tanto, seguramente terminaras con procesos definidos de manera errónea para tu nivel y en algunos casos, con productos de trabajo que no hacen sentido en tu operación o simplemente con una implementación deficiente pensando que el modelo no es nada flexible y no se adapta a tu organización.
Adoptar de manera textual los nombres de los productos de trabajo, sus secciones y los roles.
Si bien esto no es del todo incorrecto, tampoco es obligatorio tomar los nombres de manera textual como se describen en la norma. Lo mismo sucede con las diferentes secciones de cada producto de trabajo y los roles descritos.
Es posible y muy aconsejable nombrar las cosas como nosotros nos sea más cómodo, más conveniente o simplemente de la manera en que estemos mas familiarizados, la norma nos permite ajustar todos estos elementos a conveniencia y gusto del cliente. Es importante entender que cada producto de trabajo como viene descrito en la norma, no necesariamente debe tener esa forma y orden, aunque si debemos cumplir con todos los elementos aunque sean nombrados de manera distinta o estén divididos o distribuidos en diferentes documentos o herramientas.
Evitemos terminar hablando en lenguaje Moprosoft y enfoquemos nuestro esfuerzo en optimizar la operación del negocio con los recursos actualmente disponibles.
Verle forma de Excel y Word a todo, automatización es la clave.
Pareciera que la tendencia de las personas al leer los productos de trabajo descritos en la norma, que ya de por sí son bastantes, lo primero que se les viene a la mente es ponerlo en forma de Word o Excel.
Si bien es cierto que no todas las empresas cuentan con los recursos necesarios para adquirir las herramientas y/o software necesarios para hacer más eficiente o automatizar de cierta manera la administración y operación de sus empresas, también es de considerarse el echo de que en la actualidad existen un sin número de herramientas gratuitas o libres disponibles en la red.
Parte importante de una implementación exitosa de un modelo de procesos, es el hacer un uso eficiente de nuestros recursos disponibles a través de los procesos descritos, definitivamente llenarnos de documentos digitales o en papel hoy en día no representa una opción muy viable si hablamos de facilitar y optimizar el trabajo.
Proyectos, modelos y niveles mal vendidos.
Este punto se explica por sí mismo, es frecuente encontrarte con casos donde el modelo a implementar que se les ha vendido para su proyecto de consultoría no es el adecuado y es difícil ajustarse a las practicas definidas por el mismo modelo debido a que simplemente el vendedor (empresa de consultoría) no ha entendido por completo el giro de la empresa.
Es común ver como las empresas de desarrollo de software durante su crecimiento en algún momento pueden convertirse en empresas que más que desarrollar, solo hacen mantenimiento o parametrizaciones a productos que actualmente venden como empaquetados; en estos casos el enfoque del negocio se centra principalmente en brindar un servicio a sus clientes más que en el desarrollo de software como tal.
De igual manera sucede al momento de determinar el nivel de madurez o capacidad objetivo para tu proyecto, en estos casos es importante considerar las buenas prácticas que de manera natural y por su misma experiencia la empresa ha desarrollado, así como el tamaño y madurez de las diferentes áreas de la organización.
Falta de apoyo de la alta dirección.
La actual tendencia en México para la adopción de modelos de calidad viene fuertemente impulsada por los apoyos de la Secretaria de Economía a través de su programa PROSOFT; definitivamente ha jugado un papel fundamental para incrementar drásticamente los números de empresas certificadas o verificadas en algún modelo de procesos.
Si bien ha sido un rotundo acierto el impulso que ha generado en las PyMEs este tipo de apoyos, también nos encontramos con los casos que no son del todo aislados de empresas que simplemente optan por implementar un determinado modelo por el simple echo de los beneficios que representa el recibir estos apoyos, en algunos casos es una práctica fuertemente promovida por las mismas casas consultoras y en ocasiones es el mismo cliente quien ve el modelo como un simple paso para tener a su alcance otros beneficios, haciendo a un lado o ignorando las buenas practicas que el modelo per se pudiera aportarle a su negocio.
Lo que nos lleva al siguiente punto…
Resistencia al cambio en los miembros de la organización.
Uno de los factores determinantes en el éxito de un proyecto de implementación de un modelo de procesos es la correcta administración del cambio de manera estratégica entre los miembros de la organización. Es difícil lograr que cada uno de los colaboradores modifique sus hábitos de trabajo y dé paso a nuevas maneras de realizar sus actividades, impidiendo que los nuevos procesos logren institucionalizarse en la operación diaria de la empresa y en ocasiones llegan a representar la principal oposición al momento de intentar evolucionar a una manera más eficiente y sistemática de trabajo.
Identificar a los agentes de cambio dentro de la organización es la clave para lograr permear las nuevas buenas prácticas hacia el resto de los miembros, así como involucrar a cada uno de ellos en las diferentes actividades de definición de los nuevos procesos. Esto es una manera de generar un sentimiento de pertenencia tanto en el proyecto, como en la nueva manera de operar dentro de la empresa y a su vez logramos definir procesos creados por ellos mismos y evitar generar un sentimiento de imposición entre los distintos colaboradores y niveles de la organización.
Es importante contar con un apoyo total en todos los niveles jerárquicos, principalmente de parte de las áreas directivas que son quienes suelen llevar el liderazgo y representar un papel fundamental en la toma de decisiones. Cuando la alta dirección no se involucra de manera suficiente en el proyecto, difícilmente lograremos el apoyo del resto de la organización; como se mencionó en el punto anterior, si las áreas operativas y gerenciales no perciben un apoyo real en la implementación del proyecto de mejora de parte de la dirección difícilmente el resto de las distintas áreas se comprometerán a llevar a cabo y sacar adelante el proyecto de mejora.
Falta de experiencia del consultor para adaptar el modelo a la organización y entender su contexto.
Por desgracia, una de las practicas más utilizadas por los mismos consultores, es el uso de plantillas, es decir, el consultor le entrega al cliente formatos de ejemplo al cliente de cada uno de los productos de trabajo descritos en el modelo y en el peor de los casos le indica al cliente que solo debe personalizarlos y llenarlos, afirmándole que con esto cumplirá con los requisitos de la norma.
Desde mi perspectiva esta es una de las peores prácticas al momento de implementar un modelo de calidad y representa una visión completamente errónea y alejada del ideal de generar una estrategia de mejora continua, además de perjudicar la reputación del modelo haciendo creer al cliente que “eso” le ayudara a mejorar su negocio.
El modelo debiera ser interpretado y adaptado según las necesidades de cada organización, además de buscar complementarlo con las técnicas y metodologías que correspondan a cada caso.
El modelo nos dice el QUE, no el COMO.
Apoyarnos en el PM Book, Agile, BABOK, Rational, Casos de Uso, Balanced Scorecard, por mencionar algunos ejemplos, puedes complementar de manera positiva el logro de los objetivos de mejora de la organización y pueden ser integrados dentro de los procesos que se están definiendo bajo el apego del modelo de procesos.
Implementación deficiente de productos de trabajo clave.
Implementación de los PAC’s.
Tal vez sea el producto de trabajo en el que exista más discrepancia en cuanto a su interpretación e implementación, además de que se encuentra en cinco de los nueve procesos.
Me he encontrado con distintas maneras de darle uso, pero el denominador común en cada cliente es una sensación de confusión en cuanto al valor que este puede aportar a la organización.
- No está claro si es un plan o una solicitud y el flujo que este debe seguir.
- En qué momento deben usar el PAC y qué cosas incluir.
- En el peor de los casos me he encontrado que incluyen cosas que adquirieron en el pasado o que ya cuentan con ellas, solo por enlistarlas como adquisiciones que se han realizado.
En lo personal creo que es un producto que tiene mucho valor y peso en cuanto a la correcta administración de recursos se refiere, pero definitivamente es de esos productos de trabajo que deben llevar mucho fondo en su implementación y no solamente seguir los puntos marcados por la norma en cuanto a la forma y flujo se refiere.
Hace falta entender los flujos de capital y recursos de la empresa, además de la distribución y aplicación de los mismos dentro de las diferentes áreas para lograr un correcto funcionamiento de los Planes de Adquisición y Capacitación.
Lamentablemente en la mayoría de los casos, evaluando de manera informal proyectos Moprosoft, la realidad es que termina siendo un producto de trabajo mas, realizado solamente por el apego a la norma, además de que sus usuarios desconocen la utilidad del documento.
Como evaluador (informal) esta representa una de las primeras señales de una implementación deficiente del modelo y abre las puertas a seguir indagando más a fondo en busca de hallazgos que seguramente se verán como reflejo en otros procesos.
Entender diferencia entre verificaciones y validaciones en Moprosoft
No podemos hablar de un nivel 2 de Moprosoft sin referirnos al tema de las “Verificaciones y Validaciones” y el papel que estas juegan en niveles superiores al momento de institucionalizar un programa de mejora continua en la organización.
Tal es la relevancia de este producto de trabajo, como los conflictos que genera al momento de su implementación, principalmente debido a un deficiente entendimiento tanto del concepto de cada uno de ellos, como en el fondo de comprenderlos como una de las principales fuentes de detección de áreas de mejora en los procesos, además de ayudar a garantizar la integridad, calidad y contenido de los entregables.
En lo personal tengo la tendencia y el gusto por verlos integrados de manera gloriosa al mero estilo de PPQA en CMMI, pero la realidad es que en la mayoría de los casos te encuentras un par de hojas firmadas y archivadas conteniendo los cinco puntos referidos en la norma y sin más valor que el hacer bulto dentro de una gaveta.
Un solo tipo de proyectos, no tipificar.
Aunque este tema es propio de un nivel 3 en Moprosoft, soy de la idea de que este es un punto que puede tener sus bases incluso desde nivel 1 y principalmente hago esta afirmación ya que es uno de las principales inconformidades de los clientes en el sentido de que no todos los proyectos son del mismo tamaño y los procesos que están definiendo no se ajustan de manera adecuada a ellos, en especial cuando tratamos con proyectos pequeños.
Definitivamente no se puede dar el mismo trato a un proyecto de un par de decenas de horas de desarrollo que el que se le da a un proyecto que te puede llevar meses con un equipo de trabajo a tiempo completo.
La lista pudiera continuar, como podemos darnos cuenta el éxito de un proyecto de esta envergadura depende en gran medida de una correcta administración del cambio y el apoyo e interés de los directivos.
Mi mejor recomendación antes de iniciar tu proyecto de mejora sería que buscaras asesoría de un profesional para guiarte en el camino de adoptar un modelo adecuado a tus necesidades y sobre todo que sea capaz de aportar el conocimiento y experiencia necesaria para adaptar el modelo de acuerdo a tus objetivos de negocio y no terminar por convertir la operación de tu negocio en una fastidiosa copia textual del modelo.
“El modelo debe adaptarse a tu organización, no tu organización al modelo”.
Si tienes alguna experiencia, duda o recomendación que gustes compartir, te invito a que dejes un comentario en esta publicación o a través de mi página de contacto.
