El soporte ayuda a acortar el tiempo de implementación debido a la transferencia de conocimientos de la empresa. Ayuda a desarrollar habilidades internas de la propia empresa o a través de consultores externos a implementar y mantener el sistema ERP open source.

Infraestructura de Soporte

El soporte fiable y responsable es muy importante. Puede ser realizado en la propia empresa (on-site) o fuera de ella (Off site).

Un socio (partner) local puede proporcionar servicios de consultoría, soporte, módulos complementarios y solución a requerimientos a nivel nacional tales como normas de contabilidad, interfaces con autoridades públicas y bancos. Además de lo anteriormente citado también poseen conocimientos específicos de la industria.

Formación

La calidad y la frecuencia de la formación técnica a nivel de usuario así como la organización de conferencias periódicas gozan de gran importancia.

Documentación

Mantener la integridad del sistema, garantizar las actualizaciones y proveer la documentación de desarrollo son completamente necesarias para el usuario. Muchos proyectos usan sistemas de gestión de contenidos tipo Wiki para la colaboración en la creación y mantenimiento de la documentación.

Continuidad

La continuidad del proyecto asegura que los gastos del sistema ERP sean una inversión sostenida. Cuando una empresa se centra en un sistema, corre el riesgo de que éste nunca llegue a ponerse en práctica. Este problema lo podemos denominar como dependencia de la estrategia de proveedor.

La consolidación en el mercado ERP y los continuos cambios en la tecnología pueden forzar a los clientes a seguir la estrategia de producto del proveedor y por tanto quedar expuestos al posible upselling (Estrategia de desarrollo de clientes que trata de maximizar la ganancia por venta y por cliente) o las costosas propuestas de migración de los vendedores de sistemas ERPs.

Existe el riesgo de la suspensión del sistema a causa del proveedor, como por ejemplo una bancarrota del mismo o cambios en la tecnología.

Los casos del software libre y del Open Source

SI bien el software libre reduce el riesgo de la inversión ya que al ser código abierto el usuario es capaz de mantenerlo, para obtener ventajas es importante el respaldo de empresas dedicadas a ese sistema en particular, así como una comunidad activa basada en el paquete ERP usado.

Para actualizaciones de las personalizaciones de los sistemas ERP se necesita un software de diseño flexible. Por otra parte, cuando el proyecto es llevado por una única empresa, se corre el riesgo de que las nuevas versiones sean publicadas bajo licencias distintas. Incluso en este caso, las empresas open source tienen menos poder para llevar a cabo cambios de estrategia, porque existe el riesgo de que el proyecto se desvíe, cuando la estrategia cambia de rumbo, haciendo que los clientes quedan descontentos.

Una pequeña comunidad a su vez dificulta la venta de servicios tales como documentación adicional, formación, consultoría y certificaciones.

Categorías de socios

La participación de la comunidad y el tamaño de la misma dan lugar a una clasificación de los diferentes miembros y los modelos de participación en la misma.

Aplicado a los sistemas ERP open source existen cuatro categorías de socios o miembros pertenecientes a la comunidad que forman:

  • Los usuarios virtuales que son activos en foros.
  • Los testeadores beta (beta testers) que proporcionan descripción de errores.
  • Los creadores de contenido que proporcionan documentación y especificaciones de requisitos.
  • Los desarrolladores que proporciona mejoras del sistema.

Cuanto más grande y activa es la comunidad de un proyecto ERP, menos es el riesgo de que el proyecto se abandone. No podemos tener en cuenta el número de clientes que utilizan sistemas de ERP de código abierto como indicador de continuidad ya que los clientes no necesitan dar cuentas a los creadores del software.

Fuente: Evaluando Software-Estudio de software libre

Fuente: Evaluando Software-Estudio de software libre

Cómo medir el uso

Si el software se aloja en Sourceforge, una plataforma ampliamente utilizada para proyectos open source, entonces podemos usar las estadísticas proporcionadas como indicador. Hay algunos resultados estadísticos sobre los proyectos ERP de código abierto alojados en Sourceforge, como el número de desarrolladores, vida útil, actividad CVS (sistema de control de versiones), así como el número de descargas describen las medidas y las características del proyecto. La utilidad de las estadísticas de Sourceforge sin un análisis detallado del software hace que sean cuestionables. Algunas razones son: hay usuarios de software que no usan los servicios que se les ofrecen o bien los usan sólo en parte.

El número de mensajes en las lista de correo o en los foros es un indicador medible. Es más importante para la estimación de la continuidad, la satisfacción del usuario así como el desarrollo de la comunicación. Obteniendo también una pista de la madurez del software. Un sistema que sea bueno y que tenga uso difícilmente desaparecerá de la comunidad.

Estructura del proyecto

La evaluación de los proyectos son impulsados por empresas o comunidades. Que una empresa los impulse quiere decir que alguien es responsable del desarrollo, proporciona servicios y asegura a los socios soporte a nivel local. Una típica empresa impulsora tiene los siguientes participantes: empresa con proyecto open source, empresas asociadas, clientes con contratos de soporte, clientes sin contrato de soporte y usuarios que trabajan con el sistema. Una comunidad “impulsora” (community driven) significa que el desarrollo es cooperativo y no existe una única empresa responsable.

Actividad de la comunidad

El tamaño de una comunidad no es medible, pero sí su actividad comunicativa en ciertos canales de comunicación. Aquí se utiliza el número de mensajes en foros y las listas de correo. Aparte de la cantidad, las respuestas competentes y los tiempos de respuestas de las mismas son importantes. La creación de sitios web, así como las entradas en la Wikipedia son una parte del soporte y la documentación.

Fuente: Evaluando Software-Estudio de software libre

Fuente: Evaluando Software-Estudio de software libre

Transparencia

Trata sobre las barreras que pueden tener los desarrolladores y las posibilidades para la comunidad de contribuir e influenciar los procesos, la calidad de la gestión del proyecto, así como la documentación del proceso de desarrollo. Un plan de trabajo fiable, documentado ayuda a estimar el foco actual y la orientación futura del proyecto.

Una de las razones del porqué algunos proyectos no tienen un plan de trabajo detallado con horarios de trabajo es que la nueva funcionalidad necesita ser patrocinada. Como los desarrolladores son profesionales, un cliente necesita contratarlos para implementar ciertas funcionalidades, excepto si es visto como esencial para el proyecto inicial.

Un sistema público de seguimiento informa sobre detalles de errores y el tiempo que se tardará en solucionarlos, las características previstas y sus prioridades sobres estas últimas.

Sobre todo cuando el proyecto es impulsado por una empresa, es interesante saber y de qué manera se entiende la participación activa del desarrollo por la empresa.

El grado de participación de la comunidad en el proceso de desarrollo constituye otro factor de independencia del fabricante, en este caso la independencia de la compañía open source o los líderes del proyecto. Con el acceso al código de versiones del sistema junto con la documentación técnica podemos estimar las posibilidades de participación de forma activa en el proceso de desarrollo.

El código fuente tiene que ser legible y documentado. Las versiones del código fuente del sistema necesitan un registro de los cambios de forma detallada y comprensible, para poder ser utilizadas. La documentación de herramientas de desarrollo y construir procedimientos de ayuda a los nuevos desarrolladores de manera que se involucren en el proyecto con mayor facilidad. La gestión del código aportado es especialmente importante para tener bien acoplados los sistemas ERP destinados a cubrir una amplia variedad de requisitos. Aparte del control de calidad del código y su encaje en la arquitectura del software que asegura que la nueva funcionalidad es para el uso general de la comunidad y no enfocada a un cliente en particular.

Frecuencia de las actualizaciones

La introducción continua de nuevas funcionalidades y el arreglo de los errores son una prueba de la continuidad del desarrollo. Un documento de información sobre modificaciones informa acerca de las características de las nuevas versiones mostrando la actividad de actualización pasada. Considerando que la actividad de la comunidad se basa en la comunicación, las actualizaciones periódicas muestran la actividad del desarrollo.

Otros efectos acordados

Además de los acuerdos en el mismo proyecto, los posibles efectos secundarios pueden derivar del uso de componentes, tecnologías o dependencias en otros proyectos open source. La independencia del sistema operativo, de las bases de datos y del lenguaje programación, los cuales se comentaron en el apartado de flexibilidad citado anteriormente, son también criterios acordados.

Autor: Martí Pico Francesc, Universitat Politécnica de Valencia

Adaptados por la División Consultoría de EvaluandoERP.com

 
Share This
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!