¿Qué Software es apto para su empresa?

Acceda a nuestros evaluadores

Cuando se trata de una implantación de un software en ERP open source las metodologías tradicionales pueden no ser el mejor camino para llegar al éxito del proyecto. Los problemas surgen del hecho que el Cliente y el Proveedor no juegan los roles habituales definidos por la litera especializada, generando todo un nuevo mapa de situaciones que debe ser tenido en cuenta.

El proceso de implantación de un software de un ERP es un tema muy documentado que ha generado un completo y probado conjunto de “Buenas Prácticas”. La idea subyacente es la definición de dos arquetipos claramente establecidos: Un cliente “receptor” que deberá colaborar de la mejor manera posible para la implantación de un software de un ERP en su Organización y una – o varias – Empresas Proveedoras, que transferirán los conocimientos necesarios para la correcta adecuación y utilización de una tecnología por ellas desarrollada.

Sin embargo, cuando el software ERP a implantar está basado en código de fuente abierta (open source) es conveniente tener en cuenta varias consideraciones adicionales.

Primero y principal: El problema no es el mismo

La diferencia radica en la inexistencia de los arquetipos básicos por cuanto, y desde el primer momento, ambas partes trabajan sobre un territorio común y compartido que es el código fuente de la aplicación a instalar. De hecho, es muy común que, cuando una Empresa Proveedora es contactada para brindar servicios de implantación de un software, el cliente lleve un tiempo – a veces considerable – analizando las características del producto y evaluando su flexibilidad incluso desde las entrañas de su programación.

Tenemos, entonces, que el Proveedor perderá su condición de “gurú” de una tecnología sólo por él conocida, debiendo tomar un rol de “acelerador” del proyecto, ya que sólo tendrá sentido su contratación si los servicios que brinda son capaces de ahorrar tiempo, es decir dinero, al cliente final.

Segundo y no menos importante: El método de trabajo debe ser diferente

Una implantación de un software exitosa depende entonces de un conjunto particular y muy focalizado de “buenas prácticas”:
1- Planificar para integrar al cliente activamente
2- Priorizar las herramientas orientadas a la Interfase de Usuario (UI)
3- Trabajar en etapas
4- Aplicar buenas ideas de la Ingeniería de Software

1-Planificar para integrar al cliente activamente

La empresa cliente no sólo elige un producto open source para ahorrar dinero – al menos desde el punto de vista de la adquisición de licencias – sino que, en la mayoría de los casos, su motivación principal es ganar control en un proceso crítico para el futuro de la Organización. Tampoco es extraño que la decisión de avanzar con un producto de código abierto venga de uno (o varios) fracasos anteriores en el objetivo de implantar un ERP.

Este escenario nos da un cliente que quiere participar activamente en el proceso, con un nivel de profundidad que dependerá no sólo de los recursos con que cuente sino también de la decisión política de su Gerencia respecto al grado de involucramiento pretendido.

Es por ello fundamental la definición de un “Plan de implementación” que contemple estas circunstancias. En tal sentido, es recomendable comenzar el trabajo con una consultoría acotada – no mas de tres días – en formato “taller” o “workshop” en la que, y basado en el trabajo de preventa, se discuten y analizan los requerimientos de alto nivel, la disponibilidad de recursos, y la arquitectura y capacidades actuales del ERP. El objetivo es generar un “Plan de Implementación” que contenga claramente los criterios de integración entre el personal del “Proveedor” y del “Cliente”.

2-Priorizar las herramientas orientadas a la Interfase de Usuario

Aunque el Cliente y el Proveedor posean recursos humanos con similar nivel de formación, su ámbito de trabajo es fundamentalmente diferente, por lo que no se debe caer en la tentación de seleccionar herramientas de perfil exclusivamente técnico. La realidad indica que los usuarios finales – no técnicos – seguirán estando presentes (y con gran poder de decisión).

Es, entonces, preferible trabajar con formatos visuales (prototipos descartables, generadores de pantallas y reportes, storyboards, etc.) que nos garanticen una comprensión común de, al menos, la parte visible de la solución. Con un equipo mixto, es infinitamente mejor trabajar con una sucesión ordenada de pantallas antes que con un Caso de Uso, aunque los cultores de UML y herramientas puras de análisis orientado a objetos se escandalicen ante esta afirmación.

3-Trabajar en etapas en una implantación de un software

En una implantación de un software open source, y especialmente cuando se le ha asignado al Cliente Final un rol activo, es conveniente maximizar el foco en el control y visibilidad del proyecto.

Lo mejor es dividir el trabajo tanto como se pueda y avanzar en etapas claras y definidas (departamentos, circuitos, sucursales, etc). La “suma de las partes” será aquí mucho más que un “todo apresurado”.

Un conjunto de etapas exitosas, donde ha habido un pequeño espacio entre ellas para ajustar mecanismos y actores, es el camino más seguro al éxito. El patrimonio común (el código fuente del producto) sigue estando allí y el Cliente Final puede ajustar el proyecto a su ritmo minimizando el stress sobre todo el conjunto de la Organización.

4-Aplicar buenas ideas de la Ingeniería de Software

Aunque no sea necesario modificar el código del proyecto, la Ingeniería de Software ha estudiado a fondo buenas prácticas que conviene incorporar:

  • Gestión de Riesgos: Tan formal como un procedimiento, o tal informal como una reunión entre los Líderes del Proyecto, la Gestión de Riesgos debe estar presente. Alguien debe pensar en los riesgos que se pueden materializar y establecer las mejores alternativas para mitigarlos.
  • Control de Cambios: Una gestión ordenada de cambios y modificaciones resulta fundamental en cualquier implantación ERP, pero mucho más al momento de integrar dos equipos de trabajo diferentes.
  • Revisiones Formales en el proceso de Calidad: Muchas veces se considera que el control de calidad incluye sólo testeo de aplicaciones y circuitos. Sin embargo, es conveniente recordar que la base de todo proceso de QA es detectar los problemas en la etapa más temprana posible. Debemos, entonces, programar revisiones formales donde el especialista (el proveedor) analiza y verifica el diseño de los artefactos del proyecto (diseños, documentos, programas), mucho antes del testeo formal de los circuitos.

El secreto final: No olvidar el “Triángulo de McConnell

Steve McConnel, ex editor de la Revista Software de la IEEE y, tal vez, el más didáctico de los especialistas en Ingeniería de Software, enseña una relación que es perfectamente aplicable al mundo de la implantación de un software ERP.

Para el desarrollo de un proyecto, el tiempo asignado, el presupuesto aprobado, y la funcionalidad a cubrir son las magnitudes de un triángulo:

Podemos actuar sobre la magnitud tiempo (acelerar la puesta en marcha) si asignamos más dinero o establecemos un alcance más limitado del proyecto.

Podemos actuar sobre el presupuesto disminuyendo el número de actores (alargando el tiempo) o definiendo un alcance más limitado del proyecto.

Podemos definir un proyecto de Funcionalidad muy ambiciosa si asignamos los recursos suficientes (dinero) en el tiempo adecuado.

Lo que nunca podemos hacer es materializar un proyecto ambicioso con un presupuesto mínimo en un tiempo irracionalmente corto. Más allá de las virtudes del modelo open source, pretender esto es el camino más corto al fracaso.

Por Mario Mauprivez – Director General de DISYTEL – www.disytel.com

 

¿Qué Software es apto para su empresa?

Acceda a nuestros evaluadores

Suscríbase a nuestras novedades

Suscríbase a nuestras novedades

¿está interesado en nuestros contenidos de ERP? Suscríbase para nuestros newsletter y no deje de estar informado.

¡Listo, ya está suscripto!

Share This