ANÁLISIS, DESARROLLO E IMPLANTACIÓN DE APLICACIONES ERP CON CÓDIGO ABIERTO

Transcripción

1 RESUMEN ANÁLISIS, DESARROLLO E IMPLANTACIÓN DE APLICACIONES ERP CON CÓDIGO ABIERTO Nicolás Serrano Bárcena Javier Santos García Rafael Menéndez Teillet Ismael Ciordia Vela Escuela Superior de Ingenieros - Universidad de Navarra nserrano@ceit.es; jsantos@ceit.es; rmteillet@ceit.es; iciordia@ceit.es La necesidad de un sistema de información ERP se extiende a la mayoría de las empresas. Las soluciones actuales se basan en desarrollos a medida o adopción de soluciones estándar. Los inconvenientes de estas soluciones se resolverían con aplicaciones de código abierto que permiten el desarrollo a medida de las particularidades de cada empresa mientras se mantiene un tronco común. El presente trabajo expone los puntos a considerar y las características de un desarrollo de este tipo, pretendiendo finalmente obtener una aplicación operativa para un gran número de empresas. Palabras clave: ERP, código abierto, tecnologías de la información, XML. INTRODUCCIÓN La evolución de los sistemas de información de las empresas se puede constatar que se ha realizado en el tiempo afectando a dos factores de los mismos: las funcionalidades que incorporan y el tamaño de las empresas que los implantan. Funcionalidades de los sistemas Por un lado el número de funcionalidades o áreas de la empresa que engloba el sistema de gestión ha ido creciendo generación tras generación de software. La primera generación se limitaba a la realización de la nómina, la contabilidad, la facturación, considerándola un proceso mecánico: se le daban todos los datos y se procesaba la información. Posteriormente se incorporó la gestión del proceso: el pedido o la orden de trabajo o la previsión de ventas es el desencadenante de una serie de operaciones, lo que da lugar a que la información no se tenga que introducir sólo para procesarse, si no que se introduce para realizar la propia operación. Con ello se consigue una integración de las diversas áreas de la empresa evitando una duplicación de esfuerzos en muchas de ellas. Un ejemplo típico de esta integración es la gestión comercial desde la realización de la oferta hasta la gestión en contabilidad de los efectos de cobro generados, una vez que se ha pasado por la realización del pedido, preparación del mismo, envío, facturación y gestión del cobro. Las siguientes generaciones de sistemas de información incorporaron sistemas que funcionaban de forma autónoma como podía ser la contabilidad analítica, el control de la producción y la planificación; es la era de los MRP. En la situación actual se intenta completar el marco integrando todos los aspectos internos y externos de la empresa que incluyen a los clientes, los proveedores, las alianzas, y en 1

2 definitiva cualquier sistema que pueda aportar o necesite información de nuestra empresa o sistema de información es decir el Enterprise Resource Planning. Tamaño de las empresas Por otro lado, los sistemas de información que en un principio sólo eran viables para grandes empresas, van siendo accesibles a empresas de cada vez menor tamaño, incorporando con un cierto retraso, en función del tamaño de la empresa, las funcionalidades con las que contaban poco tiempo antes sólo las grandes empresas. Esta incorporación de nueva funcionalidades se ha acelerado en los últimos tiempos tanto por las necesidades de las empresas de una información cada más inmediata y completa, como por los suministradores de aplicaciones que quieren aumentar su sector de mercado. Por ello, por ejemplo las empresas proveedoras de ERP s, han ido progresivamente descendiendo las barreras de facturación o empleados de tal forma que en un futuro cercano, prácticamente cualquier empresa estará en disposición de disponer de un ERP. Representando estos dos factores en una gráfica (figura 1), para distintos tamaños de empresa ( A > B> C>...), las funcionalidades tienden a crecer en todas ellas, disminuyendo progresivamente el tiempo en que se alcanzan los nuevos escalones. Funcionalidades ERP MRP Gestión Mecanización Tamaño A Tamaño B Tamaño C Tamaño Figura 1: Evolución de las funcionalidades de los sistemas de información De esto se deduce que la implantación de un sistema ERP en las empresas va a ser una de las tareas imprescindibles en la misma o la actualización de los sistemas existentes a las nuevas tecnologías. Sin embargo, una de las dificultades que se encuentran la mayoría de las empresas es que la implantación de un sistema de este tipo supera habitualmente sus recursos humanos y tecnológicos por lo que una de las decisiones que debe tomar la empresa es la forma de proveerse de dicho sistema de información. Actualmente las posibilidades son un desarrollo a medida o implantar una solución estándar. Cada una de las alternativas presenta una serie de inconvenientes que son los que motivan el estudio que se presenta. SOLUCIONES ACTUALES Como se ha comentado, las dos soluciones que se plantea actualmente una empresa para la implantación de un sistema ERP es un desarrollo a medida o la incorporación de una solución estándar. Desarrollo a medida Tiempo 2

3 La alternativa de desarrollarlo a medida exige un elevado tiempo de desarrollo por lo que la implantación se retrasará respecto a las intenciones de la empresa y la experiencia en los proyectos de desarrollo de software muestra que existirán otros retrasos de cuantía no despreciable. El desarrollo a medida exige también mayores recursos de la empresa puesto que aunque cada empresa tenga sus particularidades sí que hay unos procesos comunes que es necesario volver a desarrollar con lo que se pierde un tiempo y dinero innecesario reinventando la rueda. El proyecto desarrollado necesitará de un mantenimiento que debe asumir la empresa o depender de la empresa desarrolladora externa. Tampoco se debe olvidar que se trata de una aplicación que no ha sido probada en otra empresa por lo que el número de errores o cuestiones no tenidas en cuenta en el desarrollo puede ser considerable. Solución estándar La alternativa de utilizar una solución estándar soluciona parte de estos inconvenientes, pero presenta otros nuevos, como el problema de que es la empresa la que se tiene que adaptar a la filosofía de la aplicación existente, porque aunque el producto se puede configurar para cada empresa esta configuración sólo es posible dentro de las previsiones realizadas por la empresa suministradora del producto en su aplicación original. Lo normal en estas soluciones es disponer de una versión ejecutable del producto por lo que no es posible su modificación por parte del cliente y en muchos casos ni el cambio de sistema operativo en el que se ejecuta sin un cambio en la licencia. La decisión de la empresa entre las dos alternativas dependerá de una serie de factores como son las necesidades que no pueden adaptarse a una aplicación estándar, el tiempo y recursos disponibles, fiabilidad del proveedor, etc., pero reflejan una decisión no óptima para los deseos de la empresa. SOLUCIÓN DEL CÓDIGO ABIERTO Una solución para la empresa sería la de disponer de código abierto para implementarlo directamente o realizar las modificaciones necesarias para particularizarlo para sus necesidades. Código abierto (open source) supone eliminar las restricciones que tiene cualquier licencia de software tradicional, en la que se impide la copia, distribución, modificación, y en definitiva todo lo que resolvería los inconvenientes planteados en las soluciones actuales. Ventajas del código abierto Con el código abierto, al disponer de los ficheros fuente de las aplicaciones se evita la posible dependencia futura del creador de la aplicación por cambio de política, propietario de la empresa o cualquier factor que altere la disponibilidad de nuevas versiones. El código fuente, se puede trasladar a nuevos sistemas operativos o realizar las modificaciones necesarias sin el esfuerzo de comenzar la tarea desde el principio. Además los desarrolladores pueden acceder a él para instalarlo, estudiarlo, modificarlo o redistribuirlo sin limitación de licencias de una empresa suministradora. Esto supone una libertad, que no es sólo económica, si no que resuelve los inconvenientes descritos anteriormente. Lo aquí expuesto parece que no tiene objeción por parte de la empresa cliente que podría obtener una aplicación completa sin invertir en licencias. Parece deducirse que el problema es la existencia de dicho código abierto y que sea posible su realización. Este hubiera sido un tema de discusión hace unos años pero hoy basta referirnos a las experiencias que podemos ver en el mercado para observar que este desarrollo es algo posible y real. 3

4 Desarrollos en código abierto La principal aplicación que existe hoy en día de código abierto es Linux y tras años de expectativas y multitud de experiencias ha demostrado ser la mejor solución para muchos escenarios. El hecho de que se trate de una aplicación de complejidad elevada al tratarse de un sistema operativo, junto a la existencia de multitud de otros desarrollos de código abierto que se han realizado en campos tan diversos como las aplicaciones de ofimática, navegadores de internet, bases de datos, servidores de aplicaciones, utilidades de programación, etc. muestran las posibilidades de este tipo de desarrollo. ERP en código abierto La idea del proyecto que se propone es el trasladar esta forma de trabajo a las aplicaciones ERP, un tipo de aplicación que es tan necesaria para una empresa como lo es un sistema operativo para un ordenador. Las aplicaciones ERP existentes en la actualidad en las empresas corresponden a alguna de las soluciones planteadas en el apartado anterior. Las soluciones estándar al tener que abarcar las posibilidades de cualquier empresa cliente se convierten en aplicaciones de características gigantescas que suponen una nueva barrera para su introducción puesto que requiere la intervención de especialistas, no ya en las aplicaciones, si no en los módulos de las mismas. Al tratarse en este caso de código abierto no es necesario inicialmente alcanzar el mismo grado de profundización de estas aplicaciones puesto que el problema de particularizar o añadir los aspectos concretos de una empresa se resuelve de mejor manera abordando el problema concreto que generando una solución general que luego se particulariza para cada empresa. Características del código abierto La forma de desarrollar este proyecto se expone en los siguientes apartados, en este concretaremos desde el punto de vista de la empresa las ventajas que obtendría con este tipo de desarrollo. La empresa dispondría de un código y por tanto de una aplicación con las siguientes características: Disponibilidad inmediata. Posibilidad de modificación y particularización de sus necesidades. Probada y mejorada por la contribución de otros usuarios en los módulos comunes. Independencia del suministrador. Distribución gratuita. DESARROLLO DEL PROYECTO El desarrollo de software libre no se debe limitar al código si bien es el término al que nos referimos al hablar de código abierto. El código es quizá la parte más visible del desarrollo de cualquier proyecto informático si bien no la mayoría de las veces la más importante. Análisis El código abierto debe comenzar con el análisis de la aplicación, generando una documentación tanto de usuario como de desarrollo a la que cualquiera pueda tener acceso para 4

5 conseguir los objetivos expuestos y para atraer al mayor número de participantes en el desarrollo y posteriores implantaciones de las aplicaciones desarrolladas. En la situación actual todo el mundo relacionado con las tecnologías de la información está de acuerdo que este análisis se desarrolle en UML (Unified Modeling Language). El análisis debe realizarse no sólo desde un punto teórico sino viendo la implantación de dicho sistema en empresas reales. Precisamente uno de los principales objetivos del análisis es la validación por parte del usuario. Gestión del proyecto Del tamaño del proyecto y la variedad de los componentes aquí surge una de las tareas críticas del proyecto, la gestión de diversos recursos sobre los que no se dispone de un control tan completo como el que pudiera tener una empresa respecto a sus trabajadores. La experiencia de otros proyectos de código abierto y en organización de empresas y proyectos debe establecer las normas y métodos para maximizar, optimizar y motivar los recursos disponibles. Implantación Otra de las tareas importantes que no debe dejarse para una fase posterior es la utilidad de los resultados obtenidos, es decir lograr implantar las aplicaciones desarrolladas en amplio número de empresas con un buen resultado. Para ello es necesario la localización de estas empresas desde las fases previas del proyecto y conseguir su implicación en el proyecto y que vean en él la concreción de un proceso de mejora y la obtención de una mejora competitiva. Desarrollo modular La aplicación resultante debe ser útil para cualquier tipo de empresa por lo que debe de tener un desarrollo modular, abarcando desde los módulos más básicos de facturación, contabilidad, tesorería, pedidos, ventas, compras, almacenes, etc. hasta otras no necesarios para todas las empresas como gestión de producción, control presupuestario, control de presencia, mantenimiento y los que surjan de la iniciativa de los participantes y necesidades de los usuarios. El desarrollo de estos módulos se debe realizar de una forma gradual de tal forma que con los módulos iniciales se disponga de un sistema completamente operativo para empresas con funciones no muy amplias y las empresas de mayor complejidad comprueben la ventaja de utilizar el trabajo desarrollado para completar sus necesidades específicas. Este desarrollo modular debe permitir asimismo aprovechar el trabajo desarrollado para empresas de sectores distintos a la empresa comercial o productiva tradicional, como pueden ser los servicios en su aspecto más general (bancarios, seguros, sanitarios, asistencia, etc.). TECNOLOGÍAS DE LA INFORMACIÓN Una de las características que debe tener la aplicación desarrollada es la de utilizar las actuales tecnologías de la información y estar preparada para la incorporación de las emergentes. Entre estas características deben encontrarse su independencia del sistema operativo y la posibilidad de su utilización en una red privada (intranet y extranet) o pública (internet). Otros aspectos importantes son la utilización de estándares como son Java y XML además del ya mencionado UML. 5

6 Internet Internet se ha consolidado como el entorno en el que se deben ejecutar las aplicaciones de la empresa para poder tener acceso a ellas desde cualquier punto y evitar las instalaciones locales de software, por el trabajo de mantenimiento que conllevan a pesar de las herramientas existentes para su gestión. Por ello una aplicación ERP que pretende que todos los trabajadores de la empresa sean sus usuarios debe estar desarrollada para trabajar en internet, ya sea como intranet o extranet. Arquitectura La arquitectura de las aplicaciones informática ha evolucionado desde los sistemas mainframe con terminales de acceso al sistema central al modelo conocido como cliente - servidor donde los datos residen en un servidor y las aplicaciones se ejecutan en los ordenadores clientes. Con el avance de internet y el desarrollo de aplicaciones para este entorno la arquitectura ha vuelto a devolver la carga principal de trabajo a los servidores si bien dividiéndolos en distintas categorías (servidor de datos, servidor de aplicaciones, servidor de Web). Las características del ERP hacen que se confirme esta tendencia, por lo que el desarrollo se centrará en el modelo de datos, las reglas de negocio y la presentación de los datos a clientes de diferentes tipos (navegadores, móviles, agendas, otros sistemas de intercambio de datos). Java Para el desarrollo de una aplicación en internet el lenguaje admitido actualmente como mejor elección es Java, que tras unos años en los cuales ha sido utilizado fundamentalmente para realizar aplicaciones en el cliente, se está consolidando como lenguaje para la programación en el servidor. Esta elección está unida a la arquitectura elegida, donde la información (datos, reglas, presentación) se elabora en el servidor y se presenta a los clientes independientemente de su contenido. Las reglas de negocio se implementan con EJB s (Enterprise Java Beans), la presentación de los datos se realizan con servlets de Java que permiten gestionar la información de cada cliente a través de sus distintas conexiones y la información se almacena en bases de datos relacionales. Estándar XML Muchas de las tareas de un sistema ERP se basan en la edición de la información de las tablas de la base de datos, ya sea de una forma prácticamente directa (por ejemplo, la edición de los datos de un cliente) o mediante procesos (por ejemplo, introducción de un pedido). Las aplicaciones tradicionales realizan para cada una de estas tareas un formulario particular en el que se codifica el aspecto de dicho formulario, las tablas y campos de la base de datos en el que se realiza el registro de la información, las operaciones que se pueden realizar con los distintos registros (consultar, navegar, editar, modificar, borrar, añadir, ordenar, ). Si lo que se deseamos es realizar una aplicación que sea fácilmente configurable por cada empresa y deseamos un rápido desarrollo de la aplicación es necesario el desarrollo de utilidades que permitan la creación de los formularios de una forma unificada. 6

7 Para esta labor se adecua el estándar XML (Extended Markup Language). En realidad no se trata de un lenguaje sino de un método para definir lenguajes dirigidos a la publicación de información y al intercambio de información. Se trata de una adaptación del SGML en el que está basado HTML pero que permite a cada usuario (empresa, asociación, sector, etc.) definir las etiquetas (tags) que se utilizarán en la definición de la información. El estándar XML ha sido adoptado por las principales empresas de las tecnologías de la información y se están desarrollando documentos de definición para las más variadas aplicaciones y sectores. Este punto unido a las herramientas que se están desarrollando para el tratamiento de la información en XML en aplicaciones Java hacen que la decisión sobre su utilización esté justificada. La forma de utilizar el estándar XML es definiendo los formularios de la aplicación ERP en este lenguaje. Para ello se define un DTD (Document Type Definition) con la sintaxis de los elementos que se pueden utilizar para definir los formularios. Estos elementos serán los distintos controles del formulario, las referencias a la base de datos y todos los elementos que permiten la funcionalidad de los formularios. La interacción de los clientes se realizará con una aplicación servidor que es la que lee la estructura de los formularios que se utilizan y en función de ellos genera la presentación del cliente. El cliente interactúa con esta presentación y como resultado se vuelve a solicitar o / y enviar información al servidor que es el que tiene registrada la situación de la sesión del cliente lo que le permite comportarse como una aplicación y no como una simple navegación. La aplicación servidor es una aplicación genérica que muestra los formularios en función de los ficheros XLM. Esta aplicación servidor puede construirse de diferentes formas, por ejemplo puede servir ficheros HTML o enviar información XML que recoja un applet o una aplicación genérica en el cliente para mostrar dicha información. Características Algunas de las características con las que contará la aplicación son: Administración de los formularios gestionados por el servidor, con conocimiento de los usuarios que emplean cada uno. Posibilidad de cambiar los formularios en tiempo de ejecución, de manera que dos usuarios puedan estar trabajando con versiones diferentes del mismo formulario. Ayuda en línea, definida en el mismo fichero XML. Opciones de auditoría para posibilitar el registrar operaciones discriminando por tipo de operación, formulario o usuario. Seguridad de acceso basada en usuarios y claves de la base de datos o en seguridad por usuario. CONCLUSIONES Se trata de un proyecto ambicioso por su magnitud y el alcance de la aplicación desarrollada pero que se considera asequible por las razones expuestas. El objetivo de este trabajo es establecer las bases e iniciar las condiciones para el desarrollo del proyecto. Esperamos que el siguiente trabajo sea la situación del desarrollo o los resultados obtenidos. REFERENCIAS G. BOOCH, J.RUMBAUGH, and I. JACOBSON (1999): The Unified Modeling Language Users Guide, Addison Wesley Longman, Inc 7

8 BRUCE ECKEL (1998): Thinking in Java, Prentice-Hall Inc. GRAHAM HAMILTON, RICK CATTELL, and MAYDENE FISHER (1997): JDBC Database Access with Java, Addison Wesley Longman, Inc. JOSÉ ANTONIO HERNÁNDEZ MUÑOZ (1998): Así es SAP R/3, Osborne Mc Graw-Hill. BENOIT MARCHAL (1999): XML by Example, QUE. 8