Estudio comparativo de paquetes ERP en el ámbito del SW libre

Proyecto Final de carrera Proyecto Final de carreraProyecto Final de carrera Proyecto Final de carrera II IIII II- -- -A AA A- -- -DOEEFC DOEEFCDOEEFC DOEEFC- -- - 74 74 74 74 Estudio comparativo de paquetes Estudio comparativo de paquetesEstudio comparativo de paquetes Estudio comparativo de paquetes ERP en el ámbito del SW libre ERP en el ámbito del SW libreERP en el ámbito del SW libre ERP en el ámbito del SW libre Índice 2 Índice ÍndiceÍndice Índice Índice 3 ÍNDICE 1.- Objetivos del proyecto pág. 6 2.- Introducción pág. 8 3.- Software Libre pág. 11 3.1.- ¿Qué es el Software Libre? pág. 13 3.2.- Ventajas del Software Libre pág. 14 3.3.- Historia pág. 17 3.3.1.- Breve historia de Linux pág. 18 3.3.2.- La aparición de las distribuciones de GNU/Linux pág. 18 3.4.- Licencias pag. 19 3.4.1. - Licencias de Software Libre pág. 20 3.4.2. - Open Source pág. 22 4.- Sistemas de Información pág. 23 4.1.- Introducción pág. 25 4.2.- La transición hacia la sociedad de la información pág. 27 4.3.- Características pág. 28 4.4.- Definición pág. 30 4.5.- Estructura de un S.I pág. 34 4.6.- Integración frente a independencia pág. 36 4.7.- Funciones básicas de tratamiento de la información pág. 37 4.8.- Actividades de un sistema de información pág. 40 4.9.- Tipos y Usos de los Sistemas de Información pág. 42 4.10.- Construcción de un sistema de información pág. 48 4.11.- Evolución de los sistemas de información pág. 51 5.- Entreprise Rosurces Planning (ERP) pág. 55 5.1.- Introducción pág. 58 5.2.- Definición pág. 58 5.3.- Estructura de un ERP pág. 60 5.3.1.- El sistema básico de un ERP pág. 60 5.3.2.- Módulos de Aprovisionamiento pág. 62 5.3.3.- Módulo de producción pág. 63 5.3.4.- Módulos de ventas pág. 63 5.3.5.- Módulo de finanzas pág. 64 5.3.6.- Módulo de recursos humanos pág. 64 5.3.7.- Módulo de gestión de medios técnicos y mantenimiento pág. 65 5.4.- Características generales de un ERP pág. 65 5.4.1.- Capacidad de parametrización pág. 65 5.4.2.- Adaptación a la estructura de la empresa pág. 65 5.4.3.- Interfaz de usuario avanzada y flexible pág. 66 5.4.4.- Integración con otras aplicaciones pág. 66 5.4.5.- Capacidad de acceso a información pág. 66 5.4.6.- Otras características pág. 66 5.5.- El ERP como cadena de valor extendida pág. 66 5.6.- Evolución histórica de los sistemas ERP pág. 69 5.6.1.- Antecedentes del software de gestión pág. 69 5.6.2.- Primera etapa: la gestión informatizada de las listas de materiales pág. 70 5.6.3.- La gestión de necesidades de material: el MRP pág. 71 5.6.4.- El MRP a ciclo cerrado: la gestión de cargas y capacidades pág. 73 5.6.5.- El MRP II: la gestión de recursos de fabricación pág. 74 5.6.6.- ERP: planificación de recursos de empresa pág. 75 5.6.7.- SCM: la gestión de la cadena de suministros pág. 76 5.6.8.- Los retos actuales: CRM Y PLM pág. 77 5.7.- Situación de los ERPs en la empresa pág. 78 5.8.- Proceso de implantación de un ERP pág. 80 5.8.1.- Introducción pág. 80 5.8.2.- Aspectos a considerar pág. 80 Índice 4 5.8.2.1.- Expectativas generadas ante la implantación de un ERP pág. 80 5.8.2.2.- Costes asociados a la implantación de un ERP pág. 81 5.8.2.3.- Componentes de una implantación de un ERP pág. 82 5.8.2.4.- Fases de una implantación pág. 84 5.8.2.5.- Ventajas e Inconvenientes de su implantación pág. 86 5.8.3.- Enfoque metodológico pág. 87 5.8.3.1.- Análisis de la situación actual pág. 88 5.8.3.2.- Análisis de Requisitos pág. 88 5.8.3.3.- Identificación Alternativas pág. 88 5.8.3.4.- Selección Alternativa pág. 89 5.8.3.5.- Planificación Implantación pág. 89 5.8.4.- Elección del ERP: Parámetros pág. 89 6.- CRM (Customer Relationship Management) pág. 92 6.1.- Introducción pág. 94 6.2.- Antecedentes de la Gestión de las Relaciones con el Cliente (CRM) pág. 94 6.3.- Delimitación del concepto de CRM pág. 98 6.4.- Principales factores para la implantación exitosa de CMR en las organizaciones pág. 106 6.5.- Principales problemas y barreras para la implantación exitosa de CRM pág. 110 6.6.- Modelo de Implantación de CRM en la organización pág. 113 6.7.- Conclusión pág. 118 7.- Criterios comparativos de paquetes ERP pág. 119 7.1.- Introducción pág. 121 7.2.- Cobertura funcional pág. 122 7.3.- Flexibilidad pág. 123 7.3.1.- Personalización pág. 123 7.3.2.- Actualizaciones flexibles pág. 124 7.3.3.- Internacionalización pág. 124 7.3.4.- Facilidad de uso pág. 125 7.3.5.- Arquitectura pág. 125 7.3.6.- Escalabilidad pág. 127 7.3.7.- Seguridad pág. 127 7.3.8.- Interfaces pág. 127 7.3.9.- Independencia del sistema operativo pág. 128 7.3.10.- Independencia del sistema de bases de datos pág. 128 7.3.11.- Lenguaje de programación pág. 128 7.4.- Soporte pág. 129 7.4.1.- Infraestructura de Soporte pág. 129 7.4.2.- Formación pág. 129 7.4.3.- Documentación pág. 129 7.5.- Continuidad pág. 129 7.5.1.- Estructura del proyecto pág. 131 7.5.2.- Actividad de la comunidad pág. 131 7.5.3.- Transparencia pág. 131 7.5.4.- Frecuencia de las actualizaciones pág. 132 7.5.5.- Otros efectos acordados pág. 132 7.6.- Madurez pág. 133 7.6.1.- Estado del desarrollo pág. 133 7.6.2.- Lugar de referencia pág. 133 8.- Características ERPs analizados en profundidad pág. 134 8.1.- Introducción pág. 137 8.2.- Tablas comparativas pág. 137 8.3.- Características ERPs analizados pág. 142 8.3.1.- Abanq pág. 142 8.3.1.1.- Flexibilidad pág. 142 8.3.1.2.- Soporte pág. 146 8.3.1.3.- Continuidad pág. 147 Índice 5 8.3.1.4.- Madurez pág. 148 8.3.2.- Adempiere pág. 149 8.3.2.1.- Flexibilidad pág. 150 8.3.2.2.- Soporte pág. 153 8.3.2.3.- Continuidad pág. 154 8.3.2.4.- Madurez pág. 155 8.3.3.- Compiere pág. 156 8.3.3.1.- Flexibilidad pág. 156 8.3.3.2.- Soporte pág. 159 8.3.3.3.- Continuidad pág. 160 8.3.3.4.- Madurez pág. 161 8.3.4.- Oasis erp pág. 163 8.3.4.1.- Flexibilidad pág. 164 8.3.4.2.- Soporte pág. 165 8.3.4.3.- Continuidad pág. 166 8.3.4.4.- Madurez pág. 167 8.3.5.- Openbravo pág. 168 8.3.5.1.- Flexibilidad pág. 168 8.3.5.2.- Soporte pág. 172 8.3.5.3.- Continuidad pág. 173 8.3.5.4.- Madurez pág. 174 8.3.6.- Openerp pág. 175 8.3.6.1.- Flexibilidad pág. 175 8.3.6.2.- Soporte pág. 179 8.3.6.3.- Continuidad pág. 180 8.3.6.4.- Madurez pág. 181 8.3.7.- OpenXpertya pág. 183 8.3.7.1.- Flexibilidad pág. 183 8.3.7.2.- Soporte pág. 187 8.3.7.3.- Continuidad pág. 188 8.3.7.4.- Madurez pág. 189 8.4.- Conclusiones a partir de los puntos anteriores pág. 190 8.4.1.- Flexibilidad pág. 190 8.4.2.- Soporte pág. 191 8.4.3.- Continuidad pág. 192 8.4.4.- Madurez pág. 193 8.4.5.- Conclusión pág. 193 8.5.- Instalación Openbravo pág. 194 8.5.1.- Requisitos de intalación pág. 194 8.5.2.- Entorno pág. 195 8.5.2.1.- Componentes pág. 195 8.5.2.2.- Módulos pág. 196 8.6.- Instalación Abanq pág. 197 8.6.1.- Requisitos de intalación pág. 197 8.6.2.- Entorno pág. 198 8.6.2.1.- Módulos pág. 198 8.6.2.2.- Área de facturación pág. 198 8.6.2.3.- Área financiera pág. 199 8.7.- Conclusiones instalación pág. 200 9.- Business Process Management (BPM) pág. 202 9.1.- Introducción pág. 204 9.2.- Definición pág. 204 9.3.- El BPM clave en las organizaciones pág. 206 9.4.- Alcance del BPM pág. 207 9.5.- Arquitectura Empresarial – Modelos de Negocio pág. 208 9.6.- Automatización y orquestación de procesos, organización y sistemas pág. 210 9.7.- Beneficios pág. 212 9.8.- Monitorización de procesos y recursos empresariales pág. 213 Índice 6 9.9.- Diez prácticas recomendadas de BPM pág. 213 9.10.- Los diez escollos a evitar en BPM pág. 215 9.11.- Conclusiones pág. 216 10.- Business Intelligence pág. 217 10.1.- Introducción pág. 219 10.2.- Definición pág. 219 10.3.- Componentes de Business Intelligence pág. 221 10.3.1.- Fuentes de información pág. 222 10.3.2.- Calidad de los datos pág. 224 10.3.3.- Proceso de extracción, transformación y carga (ETL) pág. 226 10.3.4.- Herramientas ETL pág. 231 10.3.5.- Datawarehouse o almacén de datos pág. 232 10.3.6.- Gestión del datawarehouse pág. 240 10.3.7.- Herramientas de Business Intelligence pág. 240 10.3.8.- Visualización pág. 244 10.3.9.- ¿Quiénes son los usuarios de las herramientas de Business Intelligence ? pág. 244 10.4.- Necesidad y fases de planificación de un proyecto BI pág. 245 10.5.- Elementos clave para el éxito o fracaso de un proyecto BI pág. 252 10.6.- Usos de Business Intelligence y nuevas tendencias pág. 252 10.7.- Conclusiones pág. 256 11.- Conclusion pág. 258 12.- Anexo paquetes ERP pág. 262 13.- Bibliografía pág. 413 7 Objetivos del proyecto Objetivos del proyectoObjetivos del proyecto Objetivos del proyecto Objetivos del proyecto 8 1. 1.1. 1.- -- - O O O Objetivos del Proyecto bjetivos del Proyectobjetivos del Proyecto bjetivos del Proyecto • La introducción al lector en el término de software libre, sus ventajas, desventajas y características, así como los tipos de licencias actuales, teniendo en cuenta en cada punto a su competidor, el software propietario. • Introducir el concepto de información, así como los sistemas de información, sus características relevantes y su evolución, para el correcto uso de los mismos. • Introducir el concepto de planificación de recursos empresariales ERP, su estructura, sus características fundamentales, así como su evolución y situación actual de manera que el lector se sitúe en el contexto adecuado para entender la base del proyecto. • Mostrar el concepto de CRM o gestión de las relaciones con los clientes como herramienta imprescindible en la actualidad para las empresas, explicando su evolución, modelo, características y los factores adecuados para una implantación exitosa. • Mostrar los criterios comparativos en profundidad que nos servirán para analizar los ERPs posteriormente. • Estudiar a través de los criterios comparativos ya citados, una serie de ERPs de software libre de manera que el lector logré tener una perspectiva objetiva a la hora de elegir su herramienta ERP. • Introducir el termino BPM, como herramienta de mejora de procesos de negocio, su arquitectura así como factores clave para su correcta implantación. • Conocer las herramientas de análisis de información de Business Intelligence, sus características y su composición, así como las fases y elementos clave para su correcta implantación. • Finalmente se anexarán distintos manuales proporcionados por las herramientas analizadas de manera que el lector pueda ampliar sus conocimientos sobre los mismos. 9 Introducción IntroducciónIntroducción Introducción Software libre 16 servicios de soporte sobre una aplicación, de esta manera si un proveedor desaparece, siempre se podrá continuar mejorando dicho programa. • Fomento de la industria local: Este es uno de los grandes beneficios del Software Libre, ya que las empresas TIC locales pueden ampliar su modelo de negocio con productos libres, sin depender de proveedores foráneos. La mayor parte del software propietario que se utiliza en España procede de empresas foráneas, con lo que el dinero invertido en software favorece a otros países. Sin embargo, al utilizar Software Libre es posible recurrir a empresas locales para obtener servicios sobre un programa concreto. Fomentando de esta manera la industria local y el empleo. • Mejores prestaciones con el mismo hardware: Por lo general los requisitos de procesamiento y memoria del Software Libre son menores que en las aplicaciones propietarias y optimizan los recursos del ordenador. Esto permite no tener que renovar el parque informático de una empresa cada pocos años o recuperar equipos informáticos obsoletos ya retirados para realizar algunas acciones determinadas. • Libertad de uso y redistribución: Las licencias de Software Libre existentes permiten la instalación del software tantas veces y en tantas máquinas como el usuario desee sin tener que pagar nada por ello. • Aumento de la productividad: El acceso al código fuente permite el desarrollo de nuevos productos sin la necesidad de desarrollar todo el proceso partiendo de cero. El secretismo tecnológico es uno de los grandes frenos y desequilibrios existentes para el desarrollo en el modelo de propiedad intelectual. • Soporte y compatibilidad a largo plazo: Este punto, más que una ventaja del Software Libre es una desventaja del software propietario, y la elección de Software Libre evita este problema. Al vendedor, una vez alcanzado el máximo número de ventas que puede realizar de un producto, no le interesa que sus clientes continúen con él y optan por sacar un nuevo producto. Y para obligar al usuario a que deje de utilizar la versión anterior acaban por no dar soporte ni solucionar fallos que puedan surgir, y en ciertos casos por producir formatos de ficheros incompatibles entre versiones diferentes del mismo programa. Véase diferentes versiones de Windows que dejan de ser Software libre 17 soportadas por Microsoft o software de grabación que no admite nuevos modelos de grabadoras ópticas sin una actualización, aún cuando la grabadora nueva emplee el mismo mecanismo de grabación que la antigua. • Formatos estándar: Los formatos estándar permiten una interoperatividad más alta entre sistemas, evitando incompatibilidades. Los estándares de facto son válidos en ocasiones para lograr una alta interoperatividad si se omite el hecho que estos exigen el pago de royalties a terceros y que por razones de mercado no interesa que se perpetúen demasiado tiempo. • Mayor estabilidad y seguridad: Los sistemas GNU/Linux cuentan con una mayor estabilidad de trabajo, no siendo necesario reiniciar el computador con frecuencia debido a la pérdida de rendimiento. Pueden funcionar de forma continuada un gran número de horas. Así mismo, la seguridad en sistemas operativos GNU/Linux es mucho más alta que en otro tipo de sistemas, desde el control de usuarios y la ejecución de aplicaciones hasta los problemas inexistentes de virus. Estas características son las que hacen que el Software Libre esté presente en la mayoría de servidores de Internet y de las grandes empresas. El acceso al código fuente permite además que tanto hackers como empresas de seguridad de todo el mundo puedan auditar los programas, por lo que la existencia de puertas traseras es ilógica ya que pondría en evidencia el producto y la comunidad que lo genera. • Corrección más rápida y eficiente de fallos: El funcionamiento e interés conjunto de la comunidad ha demostrado solucionar más rápidamente los fallos de seguridad en el Software Libre, algo que en el software propietario es más difícil y costoso. En ocasiones cuando se notifica a las empresas propietarias del software algún problema en su software, éstas niegan inicialmente la existencia de dichos fallos por cuestiones de imagen y cuando finalmente admiten la existencia de esos Bugs, tardan semanas o meses hasta proporcionar los parches de seguridad. • Métodos simples y unificados de gestión de software: Actualmente la mayoría de distribuciones de Linux incorporan algún sistema que unifican el método de instalación de programas, librerías, etc. Esto simplifica hasta el grado de marcar o desmarcar una casilla la gestión del software, y permiten el acceso a miles de aplicaciones de forma segura y gratuita. Este sistema de acceso y gestión del software se hace prácticamente utópico si se extrapola al mercado propietario. Software libre 18 • Sistema en expansión: Las ventajas especialmente económicas que el Software Libre aporta a muchas empresas y las aportaciones de la comunidad han permitido un constante crecimiento del Software Libre, hasta superar en ocasiones, como en el del Software para Internet, al mercado propietario. El Software Libre ya no es una promesa, es una realidad y se utiliza en sistemas de producción de algunas de las empresas tecnológicas más importantes como Telefónica, IBM, SUN Microsystems, Google, Sony, Hewlett-Packard, Oracle o incluso la NASA. Podemos augurar sin lugar a dudas un futuro crecimiento de su empleo y una consolidación bien merecida. 3.3. 3.3.3.3. 3.3. - -- - Historia Historia Historia Historia Durante los años 60 y 70 era muy habitual que los programadores y desarrolladores compartieran entre si sus programas sin ninguna restricción, hasta que a finales de los años 70 comenzaron a surgir los acuerdos de licencia, pero no fue hasta la década de los 80 cuando aparecieron los primeros sistemas operativos privativos que forzaban a los usuarios a aceptar condiciones restrictivas que impedían realizar modificaciones del software. Fue el 27 de septiembre de 1983 cuando Richard Stallman anunció públicamente el proyecto GNU (GNU's Not Unix) con el objetivo de crear un sistema operativo completamente libre compatible con Unix: el sistema GNU. Al anuncio original, siguieron otros ensayos como el “Manifiesto GNU”, donde refleja las motivaciones para iniciar el proyecto, entre las que destaca "volver al espíritu de cooperación que prevaleció en los tiempos iniciales de la comunidad de usuarios de computadoras". En 1985 surgió la Free Software Foundation (FSF), fundada de nuevo por Richard Stallman, con el propósito de difundir el movimiento del “Software Libre”. Fue entonces cuando Stallman definió el concepto de “Free Software” o “Software Libre” y el concepto de "copyleft", que restringe la apropiación del software y otorga la libertad a los usuarios. GNU se encaminó principalmente al desarrollo de un sistema operativo gratuito, compatible con UNIX, que pudiese modificarse según las necesidades de cada usuario. Después de algunos años se disponía de lo básico para un sistema operativo: intérprete de lenguajes y editor de texto, herramientas para el trabajo en red y un compilador; aunque aún faltaba el Kernel o Núcleo para hacer funcionar todo el sistema. El Kernel del sistema operativo GNU, surgió en 1990 cuando el universitario finlandés Linus Torvalds decidió ampliar el sistema operativo Minix, al que llamó Linux, desarrollado por el profesor Andrew S. Tanenbaum con fines educativos. Gracias al desarrollo de Linux, Stallman y Software libre 19 sus colaboradores encontraron lo solución que necesitaban para GNU, el Kernel, a partir de aquí nace GNU/Linux que es la unión de GNU y de Linux. Actualmente los sistemas GNU/Linux son una solución real utilizada por multitud de empresas, administraciones y usuarios de todo el mundo. GNU/Linux ofrece un sistema estable, potente y seguro junto a una gran cantidad de Software Libre que crece y se mejora día a día por millones de personas. 3.3.1. Breve historia de Linux 3.3.1. Breve historia de Linux 3.3.1. Breve historia de Linux 3.3.1. Breve historia de Linux La historia de Linux empieza en Finlandia (1991), cuando el estudiante de la Universidad de Helsinki, Linus B. Torvalds, se planteó aprovechar mejor los recursos de su ordenador (un PC con procesador Intel 386) y se instaló en él una versión reducida del sistema operativo Unix (http://www.unix-systems.org) llamada Minix. Sin embargo, debido a las limitaciones del Minix, Linus decidió reescribir algunas partes del sistema, añadiéndole mayor funcionalidad. Posteriormente, decidió difundir el código fuente por Internet, de manera gratuita y con el nombre de Linux (contracción de Linus y Unix). El anuncio inicial de Linux tuvo lugar en agosto de 1991. Era la versión 0.01. La primera versión "oficial", la 0.02, se hizo pública el 5 de octubre de 1991, para la que se incorporaron algunos programas GNU http://www.gnu.org/home.es.html como el shell bash o el compilador GCC. La versión estable de Linux fue la 1.0 y apareció en marzo de 1994. Gracias al uso de Internet, Linux ha tenido un crecimiento espectacular en los últimos tiempos, siendo un proyecto con cada vez más colaboradores que mejoran día a día el sistema. Hay que hacer hincapié también en que el término Linux se refiere al núcleo del sistema (parte que interactúa con el hardware de la máquina). Cuando se habla de todo el conjunto que forma el núcleo, y todos los demás proyectos GNU (shells, compiladores, escritorios y las distintas aplicaciones en general), se debe hablar ya del sistema operativo GNU/Linux. A lo largo de la historia de GNU/Linux han surgido muchas variantes suyas, conocidas como distribuciones. Una distribución GNU/Linux es una variante de ese sistema operativo que incorpora determinados paquetes de software para satisfacer las necesidades de un grupo específico de usuarios, dando así origen a ediciones domésticas, educativas o empresariales. 3.3.2. La aparición de las distribuciones de GNU/Linux 3.3.2. La aparición de las distribuciones de GNU/Linux3.3.2. La aparición de las distribuciones de GNU/Linux 3.3.2. La aparición de las distribuciones de GNU/Linux Software libre 20 En 1992 apareció la primera distribución Linux, conocida como MCC Interim. A mediados de 1992 la distribución de Linux más popular era SLS Linux (Softlanding Linus System). Slackware apareció en 1993 como resultado de los cambios y limpieza que realizó Patrick Volkering a la distribución Linux SLS. A partir de Slackware. Otra distribución que se basó en Slackware es la conocida distribución SUSE Linux, en 2004 esta distribución fue comprada por la multinacional americana Novell, después en 2005 fue liberada para que fuera la comunidad la que desarrollara esta distribución, que pasó llamarse openSUSE. En el año 1993 Ian Murdik fundó el proyecto Debian junto al manifiesto base para la creación de la distribución Debian. Esta es una de las comunidades de Software Libre más prestigiosas y reconocidas del mundo. A partir de Debian han surgido muchas otras distribuciones como son Corel, Skolelinux o Knoppix. También ha sido la distribución elegida por Mark Shuttleworth y su empresa Canonical Ltd. Ubuntu, que nació en 2004 con el objetivo de acercar a todos los usuarios los sistemas GNU/Linux. Actualmente es una de las distribuciones más populares por su facilidad de uso y sus actualizaciones continuas. Debido al éxito alcanzando por Ubuntu han surgido multitud de distribuciones derivadas de ésta como es el caso de Molinux (http://molinux.info), que es la distribución desarrollada por la Junta de Comunidades de Castilla-La Mancha para acercar las Tecnologías de la Información a la sociedad castellano-manchega. Entre las ventajas de esta distribución regional se encuentran: software completamente en español, versiones actualizadas semestralmente y soporte gratuito a través de teléfono, correo electrónico o foros web. Podemos encontrar el árbol genealógico de GNU/Linux en: http://www.linux-es.org/files/distribuciones_en_el_tiempo.png 3.4. 3.4.3.4. 3.4. - -- - Licencias Licencias Licencias Licencias Como ya se ha comentado, fue en la década de los 80 cuando comenzó a aparecer software sujeto a licencias que limitaba las libertades de los usuarios. Una licencia es, desde el punto de vista del Derecho, un contrato mediante el cual una persona recibe de otra el derecho de uso de varios de sus bienes, normalmente de carácter no tangible o intelectual, a cambio del pago de una cantidad determinada por el uso de los mismos. Al adquirir una licencia software, ya sea pagando o gratuitamente, podemos encontrar dos roles principales que median la transacción como se muestra a continuación (Figura 3.1). Software libre 21 Figura 3.1: Roles de la adquisición de una licencia software. Fuente: Guía Molinux para Pymes. Sin embargo hay importantes diferencias en cuanto a los derechos y limitaciones que obtenemos a la hora de adquirir una licencia software libre o propietario. Cuando el usuario adquiere una licencia de software propietario, aparte de abonar un precio por ella, verá que sus derechos como usuario están bastante restringidos: • Ejecutar el programa. • Aprovechar sus aplicaciones. • Hacer una copia de seguridad del mismo. Pero, si se adquiere una licencia de software libre, las libertades del usuario son mucho más amplias, pudiendo: • Usar el software libremente sin ningún tipo de restricción. • Estudiar como funciona y modificarlo según tus necesidades. • Redistribuirlo con o sin modificaciones, ya sea de manera gratuita o cobrando. 3.4.1. Licencias de Software Libre 3.4.1. Licencias de Software Libre3.4.1. Licencias de Software Libre 3.4.1. Licencias de Software Libre Software libre 22 Una licencia es aquella autorización formal con carácter contractual que el autor de un producto da a los usuarios de ese bien. Pueden existir tantas licencias como acuerdos concretos se den entre el autor y el licenciatario. Pero para que una licencia pueda ser considerada de software libre ha de cumplir una serie de condiciones que vienen dadas en la definición de software libre por la Fundación de Software Libre, en inglés Free Software Foundation (FSF), y que son: • Libertad para usar el programa con cualquier propósito • Libertad para estudiar cómo funciona el programa y para modificarlo • Libertad para mejorar el programa • Libertad para redistribuir tanto copias del programa como las propias modificaciones Las libertadas del software están garantizadas por una serie de condiciones que se plasman en una licencia. En el siguiente enlace (http://www.fsf.org/) se puede encontrar un listado con algunas de la licencias de software más conocidas y reconocidas por la FSF y el proyecto GNU. También puede consultarse un listado de licencias reconocidas por la Open Source Initiative (OSI) en su página Web, que salvo excepciones en ambos movimientos coinciden. Una de las características del software libre es la libertad para hacer obras derivadas por parte de terceros, siendo éstas legalmente obras nuevas. Las licencias de software libre se pueden clasificar en dos grandes grupos según la licencia con la que se pueda redistribuir las obras derivadas: • Por un lado están las licencias robustas o también conocidas como licencias con copyleft que obligan a que las obras derivadas mantenga los términos de la licencia original. Ejemplo de esta licencia es la Licencia Publica General, GNU GPL en la que el autor conserva los derechos de autor (copyright), y permite la redistribución y modificación bajo términos diseñados para asegurarse de que todas las versiones modificadas del software permanecerán siempre libres. Esto hace que no sea imposible crear un producto con partes no licenciadas bajo la GPL u otra licencia compatible. • En el otro lado se encuentran las licencias permisivas o sin copyleft, las cuales no restringen el tipo de licencia de las obras derivadas, pudiendo distribuirse incluso bajo una licencia no libre, ejemplo de estas licencias son la BSD o Apache. En algunas ocasiones el titular de los derechos de autor (copyright) de un software puede publicarlo al mismo tiempo bajo diferentes licencias dual. Este tipo de licenciamiento se conoce como Dual. Por ejemplo, podría Software libre 23 publicarse un software bajo licencia libre y también una versión modificada bajo otro tipo de licencia. Esta técnica ha sido usada en ocasiones como modelo de negocio por empresas que desarrollan Software Libre, como por ejemplo MySQL, que aunque se distribuye con licencia GPL permite distribuirse en productos no libres a través de una licencia comercial; esta práctica no restringe ninguno de los derechos otorgados a los usuarios de la versión libre. 3.4.2. Open Source 3.4.2. Open Source3.4.2. Open Source 3.4.2. Open Source En 1998 nace el término Open Source fruto de una reunión entre Eric S. Raymon, Bruce Perens, Am Ockman, Todd Anderson, Chris Peterson, John Hall y Larry Augustin, entre otros. Entre sus objetivos se encontraba evitar la confusión del término Free Software, ya que en inglés, free tiene el significado de libre y de gratis. La diferencia principal entre el Software Libre (Free Software) y el Open Source (Código Abierto) son principalmente filosóficas, de hecho ambos reconocer casi las mismas licencias. Los principales ideales del movimiento Open Source son: • Apostar por la excelencia técnica como el objetivo prioritario, siendo la compartición del código fuente un medio para dicho. • Darle mayor relevancia a los beneficios prácticos de compartir el código fuente. • Interesar a las principales casas de software y otras empresas de la industria de la alta tecnología en el concepto. • Evitar la ambigüedad del termino inglés free (gratis o libre) en “Free Software”. Mientras que en el Software Libre el principio fundamental es la libertad para los usuarios y la comunidad. Sistemas de Información Sistemas de InformaciónSistemas de Información Sistemas de Información Sistemas de información 25 4. 4.4. 4.- -- -Sistema de Información Sistema de InformaciónSistema de Información Sistema de Información 4.- Sistemas de Información 4.1.- Introducción 4.2.- La transición hacia la sociedad de la información 4.3.- Características 4.4.- Definición 4.5.- Estructura de un S.I. 4.6.- Integración frente a Independencia 4.7.- Funciones básicas de tratamiento de la información 4.8.- Actividades de un sistema de información 4.9.- Tipos y Usos de los Sistemas de Información 4.10.- Construcción de un sistema de información 4.11.- Evolución de los sistemas de información Sistemas de información 32 Borko (Borko H. Information Science: What is it? American Documentation), al intentar definir la Ciencia de la Información , parte del criterio de que es una “ciencia interdisciplinar”, punto de convergencia de varios campos del conocimiento, como por ejemplo, la lógica matemática, la lingüística, la psicología, la bibliotecología, la administración y las técnicas computacionales, entre otras. La escuela soviética, identificada con los preceptos de Mijailov y Guliarevskii (Mijailov A, Guiliarevskii RS. Curso introductorio sobre informática-documentación. La Habana), también reconocía la integración de las ciencias como un fenómeno inherente a su especialización y parte constituyente de las leyes del desarrollo científico. Saracevic (Saracevic T. Interdisciplinary nature of Information Science, 1995) afirmaba que el problema básico para la comprensión de la información y de la comunicación, de sus manifestaciones y efectos sobre el ser humano, de sus principios y sus aplicaciones para hacer accesible el conocimiento acumulado, particularmente con el uso de las tecnologías, es que no puede resolverse desde una sola disciplina. A pesar de reconocer que la Ciencia de la Información es por naturaleza interdisciplinar, y en consonancia, sus enfoques deben partir permanentemente desde la perspectiva holística (ver cada parte como un todo), algo que se encuentra, al menos, durante muchos años a la hora de encarar su estudio, son una serie de distintos sistemas como “sistemas de almacenamiento y recuperación de la información”, “sistema de clasificación decimal”, “sistema de información documental”, “sistemas de archivos”, “sistemas de bibliotecas públicas”, entre otros. Esto se corrobora si se considera que el tratamiento sobre “sistemas de información”, que provienen del campo de estudio que nos compete, según la literatura revisada, aparecen en fuentes que datan de la década de los años 80 - la primera que encontramos data de 1983 y se halla en la versión original del Glosario de la ALA (La Asociación Americana de Bibliotecarios, por sus siglas en inglés) de Bibliotecología y Ciencia de Información; entonces, puede deducirse que surgen de manera tardía con respecto a otras disciplinas. La ALA identifica como un sistema de información aquel “ sistema completo diseñado para la generación, colección, organización, almacenamiento, recuperación y difusión de la información en una institución, organización u otra área institucional definida ” (ALA. Glosario de la ALA de Bibliotecología y Ciencias de la Información. México: Ediciones Díaz de Santos). Muñoz Cruz (Muñoz Cruz V. Gestión y planificación de sistemas y servicios de información) señala que “un sistema de información es un conjunto de elementos o componentes relacionados con la información que Sistemas de información 33 interaccionan entre ellos para lograr un objetivo : facilitar y recuperar información” . Las definiciones anteriores coinciden en el carácter funcionalista que se otorga a los sistemas de información. Tanto la ALA como Muñoz Cruz , los reducen básicamente a la “recuperación” y “difusión” de información. Buckland (Buckland M. Information and information systems. New York: Greenwood Press) introduce una perspectiva cognitiva al entender que los sistemas de información “ facilitan el proceso de aprendizaje, estimulan la curiosidad, suprimen la memorización de hechos y datos que pueden perjudicar el desarrollo del pensamiento crítico y la autoestima” . Revela la intencionalidad implícita de obtener información para que el sistema pueda denominarse como tal, basándose en la necesidad de conocimiento. A propósito de la intencionalidad que propone Buckland, es vital este indicador en el proceso no sólo de obtención de información sino de adquisición de conocimientos. Sólo cuando el sujeto tiene la intención de conocer los objetos y sujetos es cuando pueden considerarse fuente de información. Capurro (Capurro R. Epistemología y Ciencia de la Información) afirma que “ está dirigido a sustentar la producción, recolección, organización, interpretación, almacenamiento, recuperación, diseminación, transformación y uso de los conocimientos y debe concebirse en el marco de un grupo social concreto y para áreas determinadas. Sólo tiene sentido hablar de un conocimiento como informativo en relación a un presupuesto conocido y compartido con otros con respecto al cual la información puede tener el carácter de ser nueva y relevante para un grupo o para un individuo” , introduciendo un enfoque social a la definición de sistemas de información Baiget (BAIGET, T.: Análisis, diseño y gestión de sistemas de información) aporta el enfoque técnico al definir el sistema de información como “ la entidad constituida por partes que interaccionan entre ellas de una forma dinámica, coordinadas para conseguir objetivos comunes ”. Por " dinámica " hace referencia a no ser necesariamente lineal o proporcional, y adaptada a cada situación momentánea. Ponjuán (Ponjuán Dante G. Los sistemas de Información. En: Los sistemas de información: principios y aplicaciones. La Habana: Félix Varela; 2004) es del criterio de que el objetivo concreto particular de los sistemas de información se traduce en responder a la satisfacción de necesidades de una organización o de un individuo o grupo de individuos. Por tanto, permanentemente se intenta comprobar su grado de eficiencia, introduciendo abiertamente el enfoque de gestión. Sistemas de información 34 En esencia, y sobre la base de los apuntes de Codina (La investigación en sistemas de información. En: Tramullas Saz J (ed). Actas del seminario Tendencias de investigación en Documentación.,1996), puede definirse un sistema de información como el conjunto de los elementos y procesos que intervienen dinámicamente en la explotación de información cognitiva concebida en el marco de un grupo social concreto y para áreas determinadas, cuyo propósito es facilitarles el acceso al conocimiento y apoyarlos en la toma correcta de decisiones . Son sistemas altamente complejos que, en su dinámica, tienden a superarse a sí mismo, porque no sólo manipulan, analizan e interrogan para recuperar información, sino que, también son capaces de generar informaciones evaluadas para el apoyo a la toma de decisiones, incluso sobre productos muy sofisticados que surgen con los nuevos enfoques de gestión. Ahora, deben superarse, una vez más, para adelantarse en la difícil propuesta de organizar y potenciar los activos cognitivos totales. Al idearse como la implicación e interrelación de todos los flujos de información de la organización, transitan hacia lo abierto, en la formación de organizaciones que clasifican como sistemas de información en pos del conocimiento. Bueno Campos (Economía de la empresa: Análisis de las decisiones empresariales, ed. Piramide, 1996) señala que los sistemas de información constan de los siguientes elementos: • La información: conjunto de datos estructurados según los mensajes a comunicar. • Los beneficiarios de la información: los miembros de la organización y agentes relacionados con ella. • Los elementos soporte: Proceso de tratamiento de información, sistemas de análisis de datos, procedimientos de comunicación o difusores de información y soportes de información. Particularmente interesante su propuesta, al considerar los beneficiarios de la información como parte integrante del sistema. Los sistemas de información son un entramado de sistemas y subsistemas donde los flujos de información se bifurcan para responder a beneficiarios que, en algunos momentos, se hallan en el contexto del ambiente, mientras que, en otros, son proveedores o procesadores de dicha información, para asumir así diferentes funciones en el sistema. Es por ello, que resulta muy difícil pensar que algún sistema de información pueda por sí solo contener todos los recursos de información que necesita y actuar de manera independiente para responder a entes o entidades, cuyas necesidades pueden modificarse abruptamente de acuerdo con contextos determinados. Sistemas de información 35 Es, por tanto imperioso cambiar los modelos mentales tradicionales donde los sistemas de información se han visto durante mucho tiempo como sistemas aislados, cerrados mediante “murallas” espacio-temporales; enmarcados en una organización; para decididamente transitar hacia lo abierto, en la conformación de organizaciones que clasifican como sistemas de información en pos del conocimiento. Para el análisis y diseño de un sistema de información, se consideran diferentes tipos de modelos. El profesor López Yépez (El desarrollo de los sistemas de información y documentación. Cuadernos E.U.B.D. Complutense 1991.), a partir de varios criterios, distingue tres modelos de sistemas de información que son básicos para comprender, diagnosticar y ver con amplitud un escenario posible de sistemas de información: • Modelo A : Sistema que contempla desde una perspectiva general, individual y con subsistemas. Su estudio sirve para el desarrollo del resto de los modelos. Se compone básicamente de los procesos de “adquisición de los datos, transmisión, proceso que incluye el almacenamiento y recuperación de la información, utilización y transferencia, este último como sinónimo de comunicación o diseminación”. • Modelo B : Sistema basado en el enfoque de gestión de información, que parte de consideraciones como que “la información es un bien económico, la información es el nervio de la organización y la organización es en sí un sistema de información” . • Modelo C : Es el resultado de la conjunción de redes y centros de información, enmarcado en las políticas nacionales y territoriales de información. El autor especifica que el sistema actúa como una red bajo el principio de coordinación de centros en que, por delegación, se invisten de determinada responsabilidad en la recolección y difusión de fuentes. Es, en este modelo, donde intervienen las políticas, estrategias, y todo un entramado regulatorio que se relaciona con el mundo de las decisiones. Los tres modelos aportan elementos vitales para la visión de un nuevo modelo, llamémosle Modelo D, donde confluyen los procesos dinámicos de la gestión de información a la que se le agregaría el modelado de los ambientes de colaboración para la gestión del conocimiento. En definitiva, Entenderemos como sistema de información (S.I.) el conjunto de procedimientos, manuales y automatizados, y de funciones dirigidas a la recogida, elaboración, evaluación, almacenamiento, recuperación, condensación y distribución de información, dentro de una organización, orientadas a promover el flujo de las mismas desde el punto en el que generan hasta el destinatario final de las mismas. 4.5. 4.5. 4.5. 4.5. – –– – Estructura de un S.I Estructura de un S.I Estructura de un S.I Estructura de un S.I. Sistemas de información 36 Un S.I. completo para una gran organización es un instrumento enormemente complejo que está constituido por un gran número de partes, o subsistemas, que interaccionan unos con otros en grado diferente y cuya estructuración tiene simultáneamente una dimensión vertical y horizontal. Estructura vertical: Estructura vertical:Estructura vertical: Estructura vertical: En su dimensión vertical el S.I. posee distintos niveles jerárquicos: a) Nivel operacional. En el que se manejan los procedimientos de rutina relacionados con las distintas actividades de la organización. En este nivel tiene lugar el grueso del tratamiento de datos y el sistema mantiene vínculos estrechos con los procesos físicos realizados por la organización. Así los subsistemas operacionales recogen datos de los sucesos del mundo real. Los datos entran en el S.I. y se almacenan en una Base de Datos que se actualiza para reflejar las consecuencias del suceso. Habitualmente el resultado del proceso se materializa en un documento de trabajo específico. b) Nivel táctico. Trata de las tomas de decisiones a plazo relativamente corto basadas en información elaborada a partir de datos transaccionales o procedentes de fuentes externas formalizadas. Las decisiones tomadas a nivel táctico se implementan generalmente a través de la parte operacional del S.I. mediante un procedimiento automatizado en un S.I. integrado o a través de medios más informales en otros casos. c) Nivel estratégico. Trata las decisiones más amplias, a mayor plazo, apoyadas menos en información formal procedente de datos transaccionales y que dependen en gran medida de fuentes de información externa. El límite entre los componentes tácticos y estratégicos es difuso. En cualquier caso las decisiones a nivel estratégico son más generales y menos susceptibles de formalización. Estructura horizontal: Estructura horizontal:Estructura horizontal: Estructura horizontal: En su estructura horizontal, y dentro de cada nivel, las funciones se subdividen en aplicaciones o procedimientos. Así por ejemplo el nivel operativo de una empresa de fabricación incluiría subsistemas de entrada de pedidos, control de inventario, etc… Estos subsistemas pueden estar directamente conectados unos con otros aportando un alto grado de integración o por el contrario pueden estar concebidos bajo un enfoque separado o autónomo que contempla cada Sistemas de información 37 aplicación o procedimiento de manera separada e independiente de los restantes procedimientos automatizados de la organización. 4.6 4.6 4.6 4.6 – –– – Integración frente a Independencia Integración frente a Independencia Integración frente a Independencia Integración frente a Independencia Como hemos mencionado anteriormente, una cuestión fundamental en el diseño de un sistema es el equilibrio entre integración e independencia. Un sistema integrado, M.I.S. (Management Information System) según algunos autores, es aquél que tiene un alto grado de coordinación con entrada y salidas rígidamente establecidas, teniendo en cuenta los efectos de un subsistema sobre los otros y en el que los recursos son ampliamente compartidos. Las principales ventajas derivadas de un enfoque integrado so las siguientes: a) Mayor eficiencia conjunta y una interrelación más efectiva de actividades entre subsistemas. b) Incorporación de hábitos para compartir ampliamente los recursos obteniendo beneficios potenciales, debidos a economías de escala y especialización. c) Posibilidad de abordar las decisiones desde la perspectiva del sistema común conjunto en vez de sobre una base subóptima que utilice información y objetivos locales. Como contrapartida, el coste fundamental de la integración es la complejidad y riesgo añadidos. En la práctica, intentar diseñar un sistema completamente integrado puede resultar una tarea demasiado compleja para ser realizada con éxito. Además la integración estricta tiene también el riesgo de ser más vulnerable a incertidumbres. Así la fragmentación tiene su precio en términos de eficiencia, pero sin cierto grado de duplicación y elasticidad, el riesgo de un fallo generalizado puede ser inaceptablemente alto para cualquier organización. Por su parte, el enfoque independiente, separado o autónomo, anteriormente mencionado, aporta al sistema simplicidad, sensibilidad y consistencia frente a un entorno incierto. Sin embargo, la consecución con éxito de objetivos subóptimos en subsistemas independientes solo puede aproximarse a los objetivos globales del sistema. Habitualmente los diseñadores de un sistema se enfrentan a difíciles elecciones entre la integración y la independencia. Sistemas de información 38 No se trata de decidir un enfoque integrado o no en sentido estricto, sino de determinar el equilibrio relativo aconsejable entre integración e independencia, el grado en que un sistema dado deba favorecer una u otra. Cuestiones como el tamaño de la organización su grado de diversificación y el análisis de las interacciones entre sus principales divisiones determinarán el grado de descentralización más adecuado. Por otra parte, los avances tecnológicos tienen efectos combinados en esta cuestión. Así los procesadores de gran capacidad de los grandes ordenadores y las herramientas de desarrollo potentes hacen viable operar la mayor complejidad de las aplicaciones que propician un acoplamiento estricto y una comparación de datos de gran volumen mientras que los minis y microordenadores de bajo coste y potentes facilitan el cálculo económico distribuido y la asunción por los usuarios de un panel más importante en la atención de sus propias necesidades de información. 4.7. 4.7. 4.7. 4.7. – –– – Funciones básicas de tratamiento de la información Funciones básicas de tratamiento de la información Funciones básicas de tratamiento de la información Funciones básicas de tratamiento de la información Dentro de la complejidad general del S.I., las funciones realizadas dentro de cada subistema tienden a ser conceptualmente claras. Así los datos entran en el sistema y luego son transmitidos, almacenados, manipulados y presentados. Veamos ahora brevemente los principales aspectos de las funciones básicas de tratamiento de la información dentro del S.I. Ingreso de datos Ingreso de datosIngreso de datos Ingreso de datos a) Técnicas más apropiadas (operación de teclado manual o reconocimiento óptico de caracteres) a emplear y su coste. b) Control de errores a través de procesos de verificación y edición. c) Enfoque integrado capturando solamente una vez un elemento dado de datos y a continuación compartirlo con todas las aplicaciones que lo necesitan. Para grandes volúmenes de entradas, los pros y contras antes mencionados en relación con la integración o independencia, casi siempre favorecen una sustancial comparación de datos. d) Interactividad como medio para mejorar sustancialmente la eficacia y calidad de las operaciones al estar directamente apoyadas por personal operativo y ser susceptibles de controles de error inmediatos. Almacenamiento de datos Almacenamiento de datosAlmacenamiento de datos Almacenamiento de datos El S.I. debe mantener grandes ficheros de datos destinados a suministrar la información para el tratamiento de transacciones y para la toma de decisiones. Los principales aspectos a considerar son: Sistemas de información 39 a) Papel de la Base de Datos en la organización a fin de que se mantenga como una representación suficientemente fiable de la realidad. b) Organización de la Base de Datos de forma que se facilite el acceso a partes específicas. c) Almacenamiento en línea versus fuera de línea. (online vs. offline). Este aspecto contempla el estudio de procedimientos que minimicen las necesidades de almacenamiento y el tiempo necesario para generar la información útil. Estos objetivos se logran proporcionando al sistema un medio de almacenamiento a largo plazo para datos con una pequeña probabilidad de acceso y sustituyendo algunos datos detallados de transacciones, por datos resumidos que se preparan y conservan mediante almacenamiento en línea. Cálculo CálculoCálculo Cálculo La forma habitual de cálculo implícita en la mayoría de los S.I., se refiere a cálculos matemáticos, manipulación de datos y ejecución de diversas acciones de acuerdo con los resultados obtenidos. Mediante los cálculos el S.I. transforma los datos brutos en información utilizable por el propio sistema e en forma ajena al mismo. Como respuesta a la necesidad de cálculo prevista el diseño de un S.I. debe contemplar la necesaria potencia de tratamiento de los equipos soporte. En este sentido es conveniente señalar que asistimos en la actualidad a una demanda insaciable de potencia de cálculo a bajo coste, fundamentalmente provocada por el hecho de que cierto número de tareas de soporte al usuario son extraordinariamente intensivas en cálculo. Presentación de los resultados Presentación de los resultadosPresentación de los resultados Presentación de los resultados La función de presentación de un S.I. proporciona una conexión esencial, o interfaz, entre el sistema y el usuario. Su finalidad es presentar la información de tal modo que mejore la capacidad del usuario para percibir y actuar sobre los hechos reflejados por la información. La eficacia de este interfaz se está convirtiendo en algo de la mayor importancia a medida que nos desplazamos rápidamente al uso casi universal de sistemas interactivos de respuesta rápida, que dependen fuertemente de una relación estrecha entre usuario y máquina. Un diseñador dispone actualmente de una gran variedad de opciones para presentar la información. La tendencia apunta a mayor resolución multiplicidad de colores y dispositivos multifunción, tanto para las salidas impresas como para las presentaciones en pantalla. A pesar de los avances tecnológicos experimentados, el verdadero problema sigue estando en el diseño del Interfaz humano, de modo que el sistema proporcione el modo más eficaz de presentación de los resultados a los usuarios. Sistemas de información 40 Comunicaciones ComunicacionesComunicaciones Comunicaciones Los sistemas de Información actuales se diferencian muy notablemente de los del pasado en su creciente apoyo en las comunicaciones. Los avances experimentados en los Sistemas de Información están estrechamente relacionados con los avances realizados en el mundo de las telecomunicaciones. Así hemos asistido a sistemas que dependían muy poco o nada de las telecomunicaciones y donde los datos eran comunicados mediante transporte físico de medios de almacenamiento. Más tarde pasamos al uso extendido de terminales de entrada de tareas a distancia que no incorporaban ninguna capacidad de procesamiento. Ahora asistimos a la implantación de sistemas informáticos distribuidos en los que los ordenadores a través de la organización están conectados por medio de una red de telecomunicaciones. Cada ordenador remoto sobre la red tiene, generalmente, capacidades de cálculo autónomo significativas para servir a las necesidades especializadas de sus usuarios locales proporcionando también acceso a recursos mantenidos en otras localizaciones, eventualmente en un ordenador central con una potencia de procesamiento considerable y gran capacidad de almacenamiento en línea sobre disco. Un sistema distribuido de este tipo es el vehículo por el que un Sistema de Información alcanza todas las partes de la organización. A nivel operativo, los terminales de trabajo individuales soportan la entrada de datos y los procesos de transacciones. Para la toma de decisiones a nivel táctico y estratégico, proporcionan cálculo autónomo y acceso a información selectiva almacenada en la Base de Datos personal del usuario. Los recursos necesarios no disponibles sobre un terminal de trabajo personal (estación de trabajo) pueden ser alcanzados a través de la red a nivel departamental si la comparación es rápida, conveniente y eficiente o a nivel corporativo si se trata de recursos demasiado costosos para estar duplicados a nivel departamental. Los diseñadores de la red de telecomunicaciones deberán seleccionar una combinación específica de topología de red, anchos de banda, protocolos de comunicaciones, equipo terminal y proveedores de comunicaciones. Su objetivo será un diseño que cumpla con las necesidades particulares de la organización a un coste aceptable. Los factores a considerar son el número y distribución geográfica de las estaciones de trabajo y de los ordenadores conectados a la red, el volumen esperado de tráfico entre los nodos, las demoras permitidas por colas en conexión de comunicaciones compartidas y los requisitos de fiabilidad y seguridad. Sistemas de información 41 Hay que señalar por último que una de las grandes ventajas de una arquitectura distribuida es que no fuerza a un equilibrio de alternativas: cada tarea individual puede ser analizada con el fin de determinar si debería estar distribuida o no. En general, las aplicaciones grandes y complejas, para las que el equilibrio entre ventajas y desventajas tiende a favorecer la centralización, se mantendrán sobre el ordenador central; las aplicaciones de complejidad media tenderán a desplazarse a miniordenadores distribuidos a nivel departamental y las aplicaciones sencillas individuales se centrarán en los microordenadores (estaciones de trabajo). El desarrollo de un sistema distribuido de este tipo es un reto importante para las organizaciones. Los usuarios deben desempeñar el papel dominante en la definición de los requisitos y la asunción de responsabilidades de desarrollar un entrono agradable para que los usuarios realicen sus tareas. Este entorno requiere una gestión efectiva de las Bases de Datos compartidas y de las disponibilidades de comunicaciones, un soporte técnico de alta calidad para los usuarios y un conjunto accesible de estándares que permita a los usuarios desarrollar aplicaciones con el resto de sistemas. 4. 4.4. 4.8 88 8. .. .- -- - Actividades de un sistema de información Actividades de un sistema de información Actividades de un sistema de información Actividades de un sistema de información Un sistema de información es un conjunto de elementos que interactúan entre sí con el fin de apoyar las actividades de una empresa o negocio. El equipo computacional: el hardware necesario para que el sistema de información pueda operar. El recurso humano que interactúa con el Sistema de Información, el cual está formado por las personas que utilizan el sistema. Un sistema de información realiza cuatro actividades básicas: entrada, almacenamiento, procesamiento y salida de información. Entrada de Información: Entrada de Información:Entrada de Información: Entrada de Información: Es el proceso mediante el cual el Sistema de Información toma los datos que requiere para procesar la información. Las entradas pueden ser manuales o automáticas. Las manuales son aquellas que se proporcionan en forma directa por el usuario, mientras que las automáticas son datos o información que provienen o son tomados de otros sistemas o módulos. Esto último se denomina interfaces automáticas. Las unidades típicas de entrada de datos a las computadoras son las terminales, las cintas magnéticas, las unidades de diskette, los códigos de barras, los escáners, la voz, los monitores sensibles al tacto, el teclado y el ratón, entre otras. Sistemas de información 48 Cualquiera puede conducir una junta electrónica y el sistema puede ser usado de manera distribuida. Las juntas se pueden realizar con los participantes en el mismo lugar o diferentes lugares, al mismo tiempo o a distintos tiempos. Aunque no pretende reemplazar las juntas cara a cara, su uso permite reducir los costos de viaje, la rapidez de toma de decisiones lo que resulta en una mejor eficiencia y productividad de las juntas. El sistema funciona en terminales de trabajo que pueden estar o no en el mismo lugar, la interacción se realiza a través del teclado y el monitor de la computadora. Otro sistema es el CRUISER cuyas siglas son para Computer Supported Spontaneous Interaction. La importancia de este sistema se basa en la interacción informal. CRUISER está diseñado alrededor del concepto de comunidad o grupo virtual que existe sólo en un mundo virtual, donde las distancias geográficas entre los participantes no son importantes. Por sus características este sistema provee acceso instantáneo a cualquier persona y cualquier lugar. La importancia del sistema está basada en dos ideas. La primera, los usuarios pueden navegar a través del mundo virtual en búsqueda de encuentros sociales. La segunda, el mundo virtual es independiente del mundo físico y puede ser organizado de acuerdo a las necesidades del usuario. En la práctica el usuario recorre pasillos, oficinas y áreas comunes, todas ellas generadas por computadora. Los usuarios se comunican a través de audio y video. CRUISER ataca uno de los problemas de los trabajos en equipo, reconoce la importancia de la comunicación informal. Provee además características de la práctica de trabajo permitiéndole diferentes niveles de privacidad. Sistema de ejecutivos: Sistema de ejecutivos: Sistema de ejecutivos: Sistema de ejecutivos: ESS, executive support system, o sistemas de apoyo a ejecutivos. Un ejemplo es el sistema comprado por Pratt & Whitney, una corporación que se dedica a la producción de motores de propulsión a chorro. Ellos compraron el sistema denominado Commander EIS que permite representaciones a todo color y un menú imaginativo que puede aprenderse intuitivamente, con variaciones y excepciones que son destacadas mediante colores. Los usuarios pueden accesar datos mediante una pantalla táctil, ratón o teclado y pueden agrandar las imágenes para mayores niveles de detalle, ya sea navegando por sí mismos o siguiendo caminos previamente definidos. El Commnander EIS permite a la organización hacer el seguimiento de los parámetros de la calidad y factibilidad de las medidas tomadas para cada motor a reacción por tipo de cliente. Los datos aparecen de los sistemas actuales de producción y proporcionan información sobre la confiabilidad, disponibilidad de motores y partes, y sobre las entregas. Sistemas de información 49 Otro ejemplo es el sistema implantado por la New York State Office of General Services que es responsable de dar servicio a otras dependencias en Nueva York. El sistema permite que los ejecutivos verifiquen el estado por programa, comparando el presupuesto con el gasto real y mostrando el gasto estimado hasta el final del año fiscal. La administración puede bajar para ver los detalles específicos en cada categoría. El sistema sólo contiene datos crudos, permitiendo a los usuarios una gran flexibilidad para agregarlos y analizarlos para satisfacer sus necesidades. El sistema es operado por medio de un menú muy fácil de usar. Los nuevos usuarios son capacitados mediante una demostración que dura media hora, y la experiencia ha demostrado que es todo lo que necesitan. No se cuenta con un manual del usuario. 4. 4.4. 4.10 1010 10. . . . – –– – Construcción de un sistema de información Construcción de un sistema de información Construcción de un sistema de información Construcción de un sistema de información En este proceso se genera el código de los componentes del Sistema de Información, se desarrollan todos los procedimientos de operación y seguridad y se elaboran todos los manuales de usuario final y de explotación con el objetivo de asegurar el correcto funcionamiento del Sistema para su posterior implantación. Para conseguir dicho objetivo, en este proceso se realizan las pruebas unitarias, las pruebas de integración de los subsistemas y componentes y las pruebas del sistema, de acuerdo al plan de pruebas establecido. Asimismo, se define la formación de usuario final y, si procede, se construyen los procedimientos de migración y carga inicial de datos. En la actividad Preparación del Entorno de Generación y Construcción (CSI 1), se asegura la disponibilidad de la infraestructura necesaria para la generación del código de los componentes y procedimientos del sistema de información. Una vez configurado el entorno de construcción, se realiza la codificación y las pruebas de los distintos componentes que conforman el sistema de información, en las actividades: • Generación del Código de los Componentes y Procedimientos (CSI 2), que se hace según las especificaciones de construcción del sistema de información, y conforme al plan de integración del sistema de información • Ejecución de las Pruebas Unitarias (CSI 3), dónde se llevan a cabo las verificaciones definidas en el plan de pruebas para cada uno de los componentes • Ejecución de las Pruebas de Integración (CSI 4), que incluye la ejecución de las verificaciones asociadas a los subsistemas y componentes, a partir de los componentes verificados individualmente, y la evaluación de los resultados. Sistemas de información 50 Una vez construido el sistema de información y realizadas las verificaciones correspondientes, se lleva a cabo la integración final del sistema de información en la actividad Ejecución de las Pruebas del Sistema (CSI 5), comprobando tanto las interfaces entre subsistemas y sistemas externos como los requisitos, de acuerdo a las verificaciones establecidas en el plan de pruebas para el nivel de pruebas del sistema. En la actividad Elaboración de los Manuales de Usuario (CSI 6), se genera la documentación de usuario final o explotación, conforme a los requisitos definidos en el proceso Diseño del Sistema de Información. La formación necesaria para que los usuarios finales sean capaces de utilizar el sistema de forma satisfactoria se especifica en la actividad Definición de la Formación de Usuarios Finales (CSI 7). Si se ha establecido la necesidad de realizar una migración de datos, la construcción y pruebas de los componentes y procedimientos relativos a dicha migración y a la carga inicial de datos se realiza en la actividad Construcción de los Componentes y Procedimientos de Migración y Carga Inicial de Datos (CSI 8). Tras la descripción de las actividades los siguientes esquemas muestran las actividades mencionadas, la conexión entre ellas, así como su ubicación temporal para realizar la construcción del sistema de información. Sistemas de información 51 Figura 4.4.- Construcción de un sistemad de información. Fuente: Ministerio de Administraciones Públicas Sistemas de información 52 4.11 4.114.11 4.11. .. .- -- - Evolución de los sistemas de información Evolución de los sistemas de información Evolución de los sistemas de información Evolución de los sistemas de información Del capítulo 4.7 se desprende la evolución que tienen los Sistemas de Información en las organizaciones. Con frecuencia se implantan en forma inicial los Sistemas Transaccionales y, posteriormente, se introducen los Sistemas de Apoyo a las Decisiones. Por último, se desarrollan los Sistemas Estratégicos que dan forma a la estructura competitiva de la empresa. En la década de los setenta, Richard Nolan, un conocido autor y profesor de la Escuela de Negocios de Harvard, desarrolló una teoría que impactó el proceso de planeación de los recursos y las actividades de la informática. Según Nolan, la función de la Informática en las organizaciones evoluciona a través de ciertas etapas de crecimiento, las cuales se explican a continuación: • Comienza con la adquisición de la primera computadora y normalmente se justifica por el ahorro de mano de obra y el exceso de papeles. • Las aplicaciones típicas que se implantan son los Sistemas Transaccionales tales como nóminas o contabilidad. • El pequeño Departamento de Sistemas depende en la mayoría de los casos del área de contabilidad. • El tipo de administración empleada es escaso y la función de los sistemas suele ser manejada por un administrador que no posee una preparación formal en el área de computación. • El personal que labora en este pequeño departamento consta a lo sumo de un operador y/o un programador. Este último podrá estar bajo el régimen de honorarios, o bien, puede recibirse el soporte de algún fabricante local de programas de aplicación. • En esta etapa es importante estar consciente de la resistencia al cambio del personal y usuario (ciberfobia) que están involucrados en los primeros sistemas que se desarrollan, ya que estos sistemas son importantes en el ahorro de mano de obra. • Esta etapa termina con la implantación exitosa del primer Sistema de Información. Cabe recalcar que algunas organizaciones pueden vivir varias etapas de inicio en las que la resistencia al cambio por parte de los primeros usuarios involucrados aborta el intento de introducir el ordenador a la empresa. Sistemas de información 53 Etapa de contagio o expansión. Los aspectos sobresalientes que permiten diagnosticar rápido que una empresa se encuentra en esta etapa son: • Se inicia con la implantación exitosa del primer Sistema de Información en la organización. Como consecuencia de lo anterior, el primer ejecutivo usuario se transforma en el paradigma o persona que se habrá que imitar. • Las aplicaciones que con frecuencia se implantan en esta etapa son el resto de los Sistemas Transaccionales no desarrollados en la etapa de inicio, tales como facturación, inventarios, control de pedidos de clientes y proveedores, cheques, etc. • El pequeño departamento es promovido a una categoría superior, donde depende de la Gerencia Administrativa o Contraloría. • El tipo de administración empleado está orientado hacia la venta de aplicaciones a todos los usuarios de la organización; en este punto suele contratarse a un especialista de la función con preparación académica en el área de sistemas. • Se inicia la contratación de personal especializado y nacen puestos tales como analista de sistemas, analista-programador, programador de sistemas, jefe de desarrollo, jefe de soporte técnico, etc. • Las aplicaciones desarrolladas carecen de interfases automáticas entre ellas, de tal forma que las salidas que produce un sistema se tienen que alimentar en forma manual a otro sistema, con la consecuente irritación de los usuarios. • Los gastos por concepto de sistemas empiezan a crecer en forma importante, lo que marca la pauta para iniciar la racionalización en el uso de los recursos computacionales dentro de la empresa. Este problema y el inicio de su solución marcan el paso a la siguiente etapa. Etapa de control o formalización. Para identificar a una empresa que transita por esta etapa es necesario considerar los siguientes elementos: • Esta etapa de evolución de la Informática dentro de las empresas se inicia con la necesidad de controlar el uso de los recursos computacionales a través de las técnicas de presupuestación base cero (partiendo de que no se tienen nada) y la implantación de sistemas de cargos a usuarios (por el servicio que se presta). Sistemas de información 54 • Las aplicaciones están orientadas a facilitar el control de las operaciones del negocio para hacerlas más eficaces, tales como sistemas para control de flujo de fondos, control de órdenes de compra a proveedores, control de inventarios, control y manejo de proyectos, etc. • El departamento de sistemas de la empresa suele ubicarse en una posición gerencial, dependiendo del organigrama de la Dirección de Administración o Finanzas. • El tipo de administración empleado dentro del área de Informática se orienta al control administrativo y a la justificación económica de las aplicaciones a desarrollar. Nace la necesidad de establecer criterios para las prioridades en el desarrollo de nuevas aplicaciones. La cartera de aplicaciones pendientes por desarrollar empieza a crecer. • En esta etapa se inician el desarrollo y la implantación de estándares de trabajo dentro del departamento, tales como: estándares de documentación, control de proyectos, desarrollo y diseño de sistemas, auditoría de sistemas y programación. • Se integra a la organización del departamento de sistemas, personal con habilidades administrativas y preparadas técnicamente. • Se inicia el desarrollo de interfases automáticas entre los diferentes sistemas. Etapa de integración. Las características de esta etapa son las siguientes: • La integración de los datos y de los sistemas surge como un resultado directo de la centralización del departamento de sistemas bajo una sola estructura administrativa. • Las nuevas tecnologías relacionadas con base de datos, sistemas administradores de bases de datos y lenguajes de cuarta generación, hicieron posible la integración. • En esta etapa surge la primera hoja electrónica de cálculo comercial y los usuarios inician haciendo sus propias aplicaciones. Esta herramienta ayudó mucho a que los usuarios hicieran su propio trabajo y no tuvieran que esperar a que sus propuestas de sistemas fueran cumplidas. • El costo del equipo y del software disminuyó por lo cual estuvo al alcance de más usuarios. • En forma paralela a los cambios tecnológicos, cambió el rol del usuario y del departamento de Sistemas de Información. El departamento de sistemas evolucionó hacia una estructura descentralizada, permitiendo al usuario utilizar herramientas para el desarrollo de sistemas. Sistemas de información 55 • Los usuarios y el departamento de sistema iniciaron el desarrollo de nuevos sistemas, reemplazando los sistemas antiguos, en beneficio de la organización. Etapa de administración de datos. Entre las características que destacan en esta etapa están las siguientes: • El departamento de Sistemas de Información reconoce que la información es un recurso muy valioso que debe estar accesible para todos los usuarios. • Para poder cumplir con lo anterior resulta necesario administrar los datos en forma apropiada, es decir, almacenarlos y mantenerlos en forma adecuada para que los usuarios puedan utilizar y compartir este recurso. • El usuario de la información adquiere la responsabilidad de la integridad de la misma y debe manejar niveles de acceso diferentes. Etapa de madurez. Entre los aspectos sobresalientes que indican que una empresa se encuentra en esta etapa, se incluyen los siguientes: • Al llegar a esta etapa, la Informática dentro de la organización se encuentra definida como una función básica y se ubica en los primeros niveles del organigrama (dirección). • Los sistemas que se desarrollan son Sistemas de Manufactura Integrados por Computadora, Sistemas Basados en el Conocimiento y Sistemas Expertos, Sistemas de Soporte a las Decisiones, Sistemas Estratégicos y, en general, aplicaciones que proporcionan información para las decisiones de alta administración y aplicaciones de carácter estratégico. • En esta etapa se tienen las aplicaciones desarrolladas en la tecnología de base de datos y se logra la integración de redes de comunicaciones con terminales en lugares remotos, a través del uso de recursos computacionales. Entrepise Resources Planning Entrepise Resources PlanningEntrepise Resources Planning Entrepise Resources Planning Entreprise Resources Planning (ERP) 57 5. 5.5. 5.- -- -Enterprise Resources Planning (ERP) 5.1.- Introducción 5.2.- Definición 5.3.- Estructura de un ERP 5.3.1.- El sistema básico de un ERP 5.3.2.- Módulos de gestión de compras 5.3.3.- Módulo de producción 5.3.4.- Módulos de ventas 5.3.5.- Módulo de finanzas 5.3.6.- Módulo de recursos humanos 5.3.7.- Módulo de gestión de medios técnicos y mantenimiento 5.4.- Características generales de un ERP 5.4.1.- Capacidad de personalización 5.4.2.- Adaptación a la estructura de la empresa 5.4.3.- Interfaz de usuario avanzada y flexible 5.4.4.- Integración con otras aplicaciones 5.4.5.- Capacidad de acceso a información 5.4.6.- Otras características 5.5.- El ERP como cadena de valor extendida 5.6.- Evolución histórica de los sistemas ERP: de la gestión de materiales a la empresa digital 5.6.1.- Antecedentes del software de gestión 5.6.2.- Primera etapa: la gestión informatizada de las listas de materiales (BOM) 5.6.3.- La gestión de necesidades de material: el MRP 5.6.4.- El MRP a ciclo cerrado: la gestión de cargas y capacidades 5.6.5.- El MRP II: la gestión de recursos de fabricación 5.6.6.- ERP: planificación de recursos de empresa 5.6.7.- SCM: la gestión de la cadena de suministros 5.6.8.- Los retos actuales: CRM Y PLM 5.7.- Situación de los ERPs en la empresa 5.8.- Proceso de implantación de un ERP 5.8.1.- Introducción 5.8.2.-Aspectos a considerar 5.8.2.1.- Expectativas generadas ante la implantación de un ERP 5.8.2.2.-Costes asociados a la implantación de un ERP 5.8.2.3.- Componentes de una implantación de un ERP 5.8.2.4.- Fases de una implantación. 5.8.2.5 Ventajas e Inconvenientes de su implantación 5.8.3.- Enfoque metodológico 5.8.3.1.- Análisis de la situación actual Entreprise Resources Planning (ERP) 64 Además, este módulo puede ofrecer la posibilidad de consultar el historial de los proveedores y de los movimientos de materiales que se han realizado. En definitiva, el módulo de gestión de compras deberá dar soporte a todos los procesos de compra, desde la gestión de proveedores y tarifas hasta el control de los procesos de pedidos, conciliación de facturas y otras fases implicadas en el gestión de compras, tanto de productos como de materias primas, bienes de inversión o servicios, así como la gestión de contratos de suministro. 5.3.3. 5.3.3.5.3.3. 5.3.3.- -- - Módulo de producción Módulo de producción Módulo de producción Módulo de producción El módulo de producción se encarga de gestionar los materiales y servicios empleados en la cadena de producción de una empresa, así como los recursos (máquinas, utillaje, personal) utilizados en ésta. Este módulo facilita la planificación de los materiales y de las capacidades de los recursos, lanzando las órdenes de montaje o de fabricación y adaptándose a las características específicas de los distintos sistemas de fabricación: fabricación contra stock, fabricación a medida contra pedido (build to order) o montaje (únicamente se realiza el ensamblaje final de las distintas piezas que componen el producto). Para contribuir a una adecuada gestión de los stocks de materiales, este módulo debe estar totalmente integrado con el módulo de gestión de compras. Además, este módulo puede incorporar diferentes funcionalidades adicionales como la planificación a capacidad finita, la captura de datos en planta, la gestión de subcontrataciones, etc. 5.3.4. 5.3.4.5.3.4. 5.3.4.- -- - Módulos de ventas Módulos de ventas Módulos de ventas Módulos de ventas El módulo de ventas se ocupa de la relación de la empresa con los clientes, dando soporte a todas las actividades comerciales preventa y postventa. Asimismo, facilita la gestión y configuración de los pedidos, la logística de distribución, la preparación de entregas, la expedición y el transporte. Para un correcto funcionamiento, el módulo de ventas deberá estar integrado con los módulos de almacén, logística, módulo financiero, etc. Asimismo, cada vez se exige un mayor nivel de integración entre ventas y compras, reflejo de una progresiva orientación a una operativo “bajo pedido”. Entreprise Resources Planning (ERP) 65 5.3.5. 5.3.5.5.3.5. 5.3.5.- -- - Módulo de finanzas Módulo de finanzas Módulo de finanzas Módulo de finanzas El módulo de finanzas se encarga de la contabilidad y de la gestión financiera de la empresa. Se trata de un módulo esencial dentro del sistema ERP, ya que va a estar totalmente integrado con los restantes módulo. Por este motivo, resulta fundamental para la correcta implantación del ERP. Este módulo proporciona herramientas flexibles y aplicaciones orientadas tanto a la contabilidad financiera, como a la contabilidad analítica o de costes. Entre sus múltiples funciones relacionadas con la operativa financiera y contable podemos destacar las siguientes: • Contabilización de las operaciones de la empresa (generación de asientos contables). • Elaboración de los balances y de la cuenta de resultados. • Elaboración de presupuestos, generación de informes y análisis de desviaciones. • Gestión de la tesorería (control de flujos de cobros y pagos, gestión de cuentas corrientes, etc.) • Gestión de activos. Asimismo, este módulo proporciona funciones específicas para el departamento de administración de una empresa: • Facturación • Liquidación de los impuestos • Gestión de cobros y reclamación de impagados. En general todos los sistemas ERP disponen de un gran número de informes financieros y contables estándar e incorporan herramientas de diseño a medida para facilitarles la generación de informes adaptados a las necesidades de cada cliente, como en el caso de la liquidación de impuestos de cada país. 5.3.6. 5.3.6.5.3.6. 5.3.6.- -- - Módulo de recursos humanos Módulo de recursos humanos Módulo de recursos humanos Módulo de recursos humanos El módulo de recursos humanos de un ERP permite gestionar la información relacionada con los empleados de una organización (datos personales, formación recibida, experiencia, ocupación, etc.). Entre las múltiples funciones que facilita podemos destacar las siguientes: • Definición de estructuras organizativas. • Planificación de las necesidades de personal. Entreprise Resources Planning (ERP) 66 • Soporte al proceso de evaluación y selección de personal. • Control de presencia, relacionado generalmente con el módulo de producción. • Soporte a la contratación de personal. • Gestión de las acciones formativas. • Registro de gastos de representación y de dietas por desplazamientos. • Soporte a la generación de nóminas. 5.3.7. 5.3.7.5.3.7. 5.3.7.- -- - Módulo de gestión de medios técnicos y mantenimiento Módulo de gestión de medios técnicos y mantenimiento Módulo de gestión de medios técnicos y mantenimiento Módulo de gestión de medios técnicos y mantenimiento Este módulo facilita el control de los recursos materiales y técnicos de la empresa, maquinaria, elementos de trasporte y repuestos, integrando las funciones empresariales de compras y mantenimiento para asegurar la disponibilidad de estos recursos en las operaciones empresariales. 5.4. 5.4.5.4. 5.4.- -- - Características generales de un ERP Características generales de un ERP Características generales de un ERP Características generales de un ERP A continuación se presentan de forma detallada algunas características comunes a los principales ERPs del mercado: 5.4.1. 5.4.1.5.4.1. 5.4.1.- -- - Capacidad de personalización (customize) Capacidad de personalización (customize) Capacidad de personalización (customize) Capacidad de personalización (customize) Se trata de la característica diferencial de los ERPs frente a la mayor parte de las soluciones de gestión orientadas a pequeñas empresas. La personalización (algunos textos la denominan parametrización, que es un termino no reconocido en la Real Academia de la Lengua española) de un ERP permite adaptar el funcionamiento del sistema a las necesidades concretas de cada empresa así como incorporar nuevas funciones o modos de funcionamiento a medida que la empresa en cuestión lo requiera. La personalización del ERP exige un gran conocimiento tanto del producto como de las necesidades de la empresa y, por ello este trabajo requiere de un importante esfuerzo de consultoría, que supone un capítulo fundamental en un proyecto de implantación de un ERP. 5.4.2. 5.4.2.5.4.2. 5.4.2.- -- - Adaptación a la estructura de la empresa Adaptación a la estructura de la empresa Adaptación a la estructura de la empresa Adaptación a la estructura de la empresa Entreprise Resources Planning (ERP) 67 Otra de las características comunes de los ERPs es su capacidad para adaptarse a la estructura organizativa de la empresa, a las funciones asignadas a cada uno de los usuarios, las políticas de venta y de compra, los centros de fabricación, los centros de distribución, los almacenes, las zonas de carga, etc. 5.4.3. 5.4.3.5.4.3. 5.4.3.- -- - Interfaz de usuario avanzada y fl Interfaz de usuario avanzada y fl Interfaz de usuario avanzada y fl Interfaz de usuario avanzada y flexible exibleexible exible Normalmente, los ERPs incorporan las últimas tecnologías y avances en la interfaz de usuario, con facilidades gráficas o la posibilidad de definir diversos dispositivos de acceso: ordenadores personales, terminales de radiofrecuencia, PDAs, etc. 5.4.4. 5.4.4.5.4.4. 5.4.4.- -- - Integración con otras aplicaciones Integración con otras aplicaciones Integración con otras aplicaciones Integración con otras aplicaciones Esta característica facilita la comunicación e intercambio de datos por medio de interfaces estandarizadas con paquetes de software EDI, herramientas de Internet, aplicaciones ofimáticas, soluciones de Business Intelligence, etc. 5.4.5. 5.4.5.5.4.5. 5.4.5.- -- - Capacidad de acceso a información Capacidad de acceso a información Capacidad de acceso a información Capacidad de acceso a información Los ERPs cuentan con un conjunto de salidas e informes predefinidos y, además, posibilitan la interacción desde distintas herramientas de acceso a datos: OLAP, aplicaciones ofimáticas, paquetes software DSS o EIS, etc. 5.4.6. 5.4.6.5.4.6. 5.4.6.- -- - Otras características Otras características Otras características Otras características Entre estas otras características de los ERPs, podríamos citar la incorporación de herramientas de seguridad, ayuda online, etc. 5.5. 5.5.5.5. 5.5.- -- - El ERP como cadena de valor extendida El ERP como cadena de valor extendida El ERP como cadena de valor extendida El ERP como cadena de valor extendida La tecnología basada en la Red mueve la información a lo largo de la cadena de valor logística, uniendo grupos separados previamente, que pueden comunicarse más rápida y eficientemente por teléfono, fax o correo electrónico, que cara a cara. Esta tecnología tiene la capacidad de proporcionar información instantáneamente a un coste muy bajo. El sistema ERP de cada compañía se conecta directamente a los sistemas ERP de proveedores y clientes. El EDI ofrece un modelo similar, aunque en el modelo EDI cada empresa debe crear protocolos únicos para cada proveedor o cliente. En un modelo basado en Internet con estándares Entreprise Resources Planning (ERP) 68 abiertos, una compañía puede conectar a través de la tecnología basada en la red con cada proveedor y cada cliente. Debido a que la información es más fácilmente disponible usando la tecnología basada en Internet para conectar ambos, proveedores y clientes, la oportunidad existente para una empresa de crear nuevas estrategias de negocio basadas en transformar una cadena de valor en una red integrada de valor. La razón para esto reside en los atributos únicos de información: • La información puede ser consumida múltiples veces. • La información puede ser condensada. • El valor de la información cambia con el tiempo y el uso. • La información abre las puertas. Cuantas más empresas estén conectadas a la red integrada, mayor valor hay para cualquier otra empresa en conectarse a esta red. A la vez que los socios de la red integrada aprenden a trabajar juntos mejor, el beneficio del cliente se incrementa a la vez que los costes decrecen y los niveles de servicio mejoran. Esta dinámica llega ser un círculo vicioso, conduciendo a los miembros de la empresa extendida a mejorar constantemente sus propios procesos internos así como los procesos de la red extendida de empresas. Los miembros de la red integrada se esfuerzan por la eficacia y reducción de costes. A la vez que las compañías adopten los estándares abiertos que incluyen el ERP dentro de las tecnologías Internet, sus arquitecturas de sistemas cambiarán espectacularmente. La siguiente figura (figura 5.1) muestra la arquitectura del sistema en su estado final para la compañía del siglo XXI. Entreprise Resources Planning (ERP) 69 Figura 5.1.- Arquitectura de sistemas del siglo XXI (Fuente: El futuro tecnológico de las Terminales Marítimas de Vehículos: La integración de sus sistemas de información, UPC – Departament de Ciència i Enginyeria Nàutiques Barcelona, 2004) En el centro está el sistema ERP de la compañía, que es su motor de transacciones y generador de sus datos internos. Estos datos, son almacenados en un Almacén de datos (Data Warehouse), pueden ser cortados y analizados en cualquier número de formas por el software que soporta las decisiones de la compañía, y que esta utiliza para realizar sus análisis de negocio. Con la tecnología basada en Internet, la compañía puede transferir información hacia y desde sus clientes, proveedores y socios del negocio. En suma, la tecnología permite a la empresa utilizar fuentes de investigación externa para sumar calidez y robustez a sus análisis de negocio. La tecnología para soportar las decisiones asiste a los gerentes a todos los niveles de la organización de manera que puedan tomar decisiones coherentes, dándoles una clara imagen de la información relevante desde ambos sitios, dentro y fuera de la compañía. En un sistema como tal, los datos de fuentes internas y externas pueden ser consolidados y comparados Entreprise Resources Planning (ERP) 70 con los objetivos de una compañía como parte del sistema de medida del rendimiento, convirtiendo los datos en información de gestión. 5.6. 5.6.5.6. 5.6.- -- - Evol Evol Evol Evolución histórica de los sistemas ERP: de la gestión de materiales a ución histórica de los sistemas ERP: de la gestión de materiales a ución histórica de los sistemas ERP: de la gestión de materiales a ución histórica de los sistemas ERP: de la gestión de materiales a la empresa digital la empresa digitalla empresa digital la empresa digital 5.6.1. 5.6.1.5.6.1. 5.6.1.- -- - Antecedentes del software de gestión Antecedentes del software de gestiónAntecedentes del software de gestión Antecedentes del software de gestión Los primeros ordenadores fueron fruto de grandes proyectos de desarrollo tecnológico desarrollados durante la segunda guerra mundial para cubrir necesidades de cálculo militares (generación de tablas balísticas, investigación de los procesos de fisión nuclear, etc.). Estas primeras máquinas eran demasiado caras para ser utilizadas en la industria, pero generación tras generación de computadoras, la tecnología fue mejorando, aumentando la velocidad y capacidad de cálculo y disminuyendo los costes como en ningún otro sector industrial. En la década de los 50 los ordenadores comienzan a expandirse por las universidades y ya en 1955 se crea la asociación SHARE (Society to Help Allieve Redundant Effort, primer grupo de usuarios de ordenadores) para compartir conocimientos y evitar en la medida de lo posible labores redundantes (History of Computing, Computer Society, 2003). A finales de esta década, los ordenadores para uso industrial comienzan utilizarse en el entorno empresarial (An Overview of the History of the Software Industry, Software History Center, 2003). A comienzos de los 60 se fundan numerosas empresas dedicadas al desarrollo de software. En esta época, la práctica habitual es incluir el software básico gratis con la venta del hardware, teniendo que contratar desarrollos a medida para cubrir cualquier otra necesidad. De todas formas, se empiezan a crear las primeras librerías de utilidades, en las que se pueden conseguir ciertas aplicaciones gratuitamente. En este caldo de cultivo, van surgiendo los primeros intentos de aplicar la tecnología a la problemática de gestión de materiales y en 1959 Bosch desarrolla una aplicación que puede considerarse la primera aproximación a lo que posteriormente se conoció como Material Requirement Planning (MRP) o Planificación de Necesidades de Materiales. El concepto de software como producto comienza a considerarse viable comercialmente y en 1967, la compañía International Computer Programs, Inc. (ICP) crea el primer catálogo de software con 49 aplicaciones (Software History Center, 2003). Como fecha significativa, cabe citar que IBM anuncia que a partir del uno de enero de 1970 ciertos paquetes de software iban a comenzar a venderse por separado, dando por finalizada la era en la que el Entreprise Resources Planning (ERP) 71 software se consideraba un derecho ilimitado inherente a la compra del hardware. 5.6.2. 5.6.2.5.6.2. 5.6.2.- -- - Primera etapa: la gestión informatizada de las listas Primera etapa: la gestión informatizada de las listas Primera etapa: la gestión informatizada de las listas Primera etapa: la gestión informatizada de las listas de materiales de materiales de materiales de materiales (BOM) (BOM)(BOM) (BOM) Las prácticas de gestión utilizadas en los años 60, se basaban en los modelos tradicionales de punto de pedido y lote económico de compra. La disponibilidad comercial de computadoras propició el inicio de una nueva era del procesamiento de la información de negocios, con un impacto profundo de las nuevas tecnologías en la dirección de operaciones. Probablemente, en ningún área ha supuesto un impacto mayor (al menos potencialmente) que en el área de logística de fabricación, por ejemplo en la gestión de inventarios y en la planificación de la producción (Orlicky, Joseph (1975), MRP, The New Way of Life in Production and Inventory Management. McGraw-Hill Book Company). Hasta la llegada de la computadora, estas funciones constituían un problema crónico e intratable para todas aquellas empresas que se dedican a la fabricación de productos que requieren múltiples etapas en su proceso de transformación. Las soluciones conocidas y disponibles eran imperfectas, parciales y generalmente insatisfactorias desde el punto de vista de gestión. Las primeras aplicaciones informáticas, hacia 1960, orientadas a la gestión de inventarios, representaron el comienzo de la ruptura con la tradición. La disponibilidad de computadoras, capaces de manejar un gran volumen de información a velocidades previamente inimaginables, supuso la eliminación de las fuertes restricciones relacionadas con el procesamiento de la información y la súbita obsolescencia de muchos métodos y técnicas desarrollados en base a estas restricciones. Los planteamientos tradicionales en los días previos a las computadoras, no podían ir más allá de los límites impuestos por las herramientas. Debido a esto, casi todas aquellas técnicas eran imperfectas. Funcionaban a modo de muleta e incorporaban métodos aproximados, a menudo basados en asunciones poco realistas, otras veces forzando la aplicación de conceptos a la realidad para poder utilizar las técnicas. El salto cualitativo, en esta área, radica en el simple hecho de que una vez que se dispone de un ordenador, el uso de dichos métodos y sistemas ya no es obligatorio. Es posible evitar, revisar o descartar las técnicas previas e instaurar nuevas que hasta el momento había sido imposible utilizar. Analizando los casos de las compañías pioneras en la gestión computerizada de inventarios (años 60), puede verse que los mejores resultados no fueron obtenidos por aquellos que eligieron mejorar, refinar y acelerar las técnicas existentes, sino por aquellos que plantearon una Entreprise Resources Planning (ERP) 72 completa revisión de sus sistemas. En este contexto, surgen los primeros sistemas que tratan la gestión de demanda dependiente, es decir, la gestión de productos cuya descomposición implica que la cantidad demandada de un componente depende de las cantidades demandadas de todos los productos finales en los que toma parte. Estos primeros intentos, basados en iniciativas de empresas individuales y con las carencias propias de la falta de experiencia previa y por lo tanto la inexistencia de metodologías estandarizadas, son catalogadas hoy en día bajo la denominación de gestores de listas de materiales o gestores del BOM (Bill Of Materials). En el área de gestión de inventario industrial, las innovaciones más exitosas están englobadas en lo que se ha dado a conocer como sistemas MRP (Material Requirements Planning o Planificación de Necesidades de Materiales). 5.6.3. 5.6.3.5.6.3. 5.6.3.- -- - La gestión de necesidades de material: el MRP La gestión de necesidades de material: el MRP La gestión de necesidades de material: el MRP La gestión de necesidades de material: el MRP Joseph A. Orlicky está considerado como el padre del MRP moderno. En la siguiente figura (figura 5.2) se muestra el diagrama de definición del sistema MRP de su obra “MRP, The New Way of Life in Production and Inventory Management “(1975). Figura 5.2.- Diagrama de definición del MRP Fuente: MRP, The New Way of Life in Production and Inventory Management, Joseph A. Orlicky Entreprise Resources Planning (ERP) 73 Según la definición de Orlicky, el MRP consiste en una serie de procedimientos, reglas de decisión y registros diseñados para convertir el Programa Maestro de Producción en Necesidades Netas para cada Periodo de Planificación. El objetivo con el que se desarrolló la metodología MRP, fue sustituir los sistemas de información tradicionales de planificación y control de la producción (Cooper, R.B. y Zmud, R.W. (1990), “Information technology implementation research: a technological diffusion approach”,). Las dos hipótesis de base de los sistemas MRP son las siguientes (Orlicky, Buffa, E.S. y Miller, J.G. (1979), “Production-Inventory Systems Planning and Control”, 3rd ed., Richard D. Irwin, Homewood, IL): • La planificación y el control de la producción no dependen de los procesos. • Los productos terminados son determinísticos. Es decir, el sistema MRP está construido alrededor del BOM (lista de materiales) y su validez depende de la exactitud del mismo (Chung S.H.y Snyder C. A. (2000) “ERP adoption: a technological evolution approach”. International Journal of Agile Management Systems 2/1). Según George Plossl, uno de lo padres del MRP, «el MRP calcula qué necesito, lo compara con lo que tengo y calcula qué voy a necesitar y cuándo». Este es el verdadero avance del MRP I: por primera vez la planificación de necesidades de materiales es capaz de dar respuesta al CUÁNDO (Ptak, C.A. y Schragenheim, E. (2000), “ERP: Tools, Techniques, and Applications for Integrating the Supply Chain”, CRC Press-St Lucie Press). Debido a las limitaciones de capacidad de cálculo de los ordenadores de la época, la metodología MRP I asume ciertas simplificaciones. Para realizar estos cálculos, las órdenes se planifican sobre la última fecha posible para así minimizar el stock. Este método de programación hacia atrás provoca que al no disponer de tiempos de sobra, todas las actividades forman parte del camino crítico. Así pues, al no disponer de margen para recuperar el tiempo perdido, cualquier retraso o problema causa inevitablemente un retraso en la entrega al cliente. Esta limitación del sistema condujo a definir tiempos de entrega holgados para prevenir los efectos negativos de los pequeños problemas ocasionales. Entreprise Resources Planning (ERP) 80 atracción o bien conservación de clientes. Los sistemas de ERP forman parte fundamental de las estrategias de las grandes empresas actuales. En el estudio, “Soluciones ERP en la PYME española”, se desprenden las siguientes conclusiones: • El 58,9% de las compañías tiene implantada una solución de gestión integrada, siendo mayor el porcentaje en aquellas que tienen decisión corporativa. • Las principales razones que llevan a una empresa a plantearse la implantación de un ERP son la obsolescencia del sistema anterior (52%) y la ampliación del crecimiento de la empresa (49,6%). • Una vez tomada la decisión de adquirir una solución ERP, el 45% consultan en primer lugar a su proveedor habitual, el 11,6% recurren a consultores y en un 11,5% de los casos recogen información por medios corporativos. • La principal característica valorada, a la hora de elegir una solución ERP, fue las prestaciones de dicha solución, con un 72,2%, seguida de otros factores como fiabilidad, seguridad, precio y confianza en el integrador. Si bien hasta finales de los años noventa la implantación de sistemas ERP se había llevado a cabo en su mayoría en empresas de gran tamaño, desde principios del nuevo milenio está extendiéndose cada vez más a empresas de tamaño mediano y pequeño, mediante el lanzamiento de sistemas más económicos y con tiempos de implantación más cortos. El principal reto de los sistemas ERP sigue estando en su correcta implantación. No es meramente una cuestión de alta complejidad técnica, sino que suele conllevar un cambio de filosofía empresarial, por lo que muchas veces tiene que ser concebido dentro de un programa de gestión del cambio. De ahí que cada vez más, la implantación de un ERP deja de ser una cuestión de sistemas de información y se convierte en un aspecto de la estrategia de negocio. Para tomar decisiones racionales acerca de cómo comprometer recursos para implantar un ERP, cualquier compañía necesita conocer su situación inicial así como su estado final deseado. Teniendo en cuenta esto, se pueden definir cuatro posibles escenarios en los que se puede encontrar una empresa: 1. Carencia de sistemas o “desde cero”; no existen sistemas de información Entreprise Resources Planning (ERP) 81 2. Sistemas no integrados; existen gran número de sistemas de información no integrados, con varias plataformas hardware y sistemas operativos, numerosos programas de aplicación y lenguajes de programación. Se crea la necesidad de interfaces para paliar las limitaciones de acceso a datos y permitir que varios sistemas “hablen” entre sí. 3. ERP limitado a funciones individuales; existen sistemas ERP instalados para operar en un área funcional individual (finanzas, ventas o distribución) de una división o de toda la empresa. 4. ERP integrado para toda la empresa; existen procesos completos de uno a otro extremo y a lo largo de toda la compañía, elementos de datos comunes a través de las unidades de negocio y software de aplicación ERP estandarizado, con un único conjunto de aplicaciones aplicado a través de toda la compañía. 5.8. 5.8.5.8. 5.8.- -- - Proceso de implantación de un ERP Proceso de implantación de un ERP Proceso de implantación de un ERP Proceso de implantación de un ERP 5 55 5.8.1. .8.1..8.1. .8.1.- -- - Introducción Introducción Introducción Introducción La implementación de un sistema de ERP, por lo general, es larga y compleja, ya que implica rediseñar los esquemas de trabajo. Su implementación es de alto riesgo, ya que implica complejidad, tamaño, altos costos, un equipo considerable de desarrollo, además de inversión de tiempo. En la mayoría de las empresas, se requiere remplazar la infraestructura existente, lo que implica inversión de capital adicional, especialización y hasta la posibilidad de parar el negocio temporalmente para la implementación, por otra parte es importante señalar que el grado de experiencia de los proveedores es un factor importante para el buen funcionamiento del sistema. Después de la implementación es importante centrarse en el aseguramiento de la calidad y en la mejora del desempeño, para que así el sistema funcione correctamente a largo plazo. También se debe analizar constantemente el retorno de inversión y aspectos clave como la optimización, la cual proporciona ideas que no fueron consideradas durante la implementación como por ejemplo la expansión del software implementado; es importante ver a la optimización como un proceso de mejora continua. 5.8.2. 5.8.2.5.8.2. 5.8.2.- -- -Aspectos a considerar Aspectos a considerarAspectos a considerar Aspectos a considerar 5.8.2.1. 5.8.2.1.5.8.2.1. 5.8.2.1.- -- - Expectativas generadas ante la implantación de un ERP Expectativas generadas ante la implantación de un ERP Expectativas generadas ante la implantación de un ERP Expectativas generadas ante la implantación de un ERP En la ponencia “Elección de ERP: Criterios y Costes de Implantación de un Entreprise Resources Planning (ERP) 82 ERP” expuesta en el salón Softgest 2003, se enumeran las expectativas que se generan ante la implantación de un ERP: • Disponer de un sistema integral para todas las áreas de la empresa • Disponer de información financiera y operativa on-line • Definición y mejora de procesos y herramientas de control de gestión • Reducir costes de operación (ROI) • Incrementar ingresos operativos del negocio (ROI) • Mejorar eficiencia operativa en todas las áreas (ROI) • Mejorar la imagen de la empresa • Mejora en procesos equivale a incremento de la competitividad • Utilizar el ERP como base para proyectar nuevos negocios • Implantar un ERP que disponga de herramientas E-Business 5.8.2.2. 5.8.2.2.5.8.2.2. 5.8.2.2.- -- -Costes asociados a la impla Costes asociados a la implaCostes asociados a la impla Costes asociados a la implantación de un ERP ntación de un ERPntación de un ERP ntación de un ERP En la ponencia citada en el punto anterior, también se hace referencia a los costes asociados a la implantación de un ERP, tanto los externos como los internos: Costes externos (Figura 5.5) : • Infraestructura técnica (hardware, red, comunicaciones). • Software (licencias, módulos a implantar, actualizaciones). • Servicios de consultoría, desarrollo, implantación y mantenimiento. Entreprise Resources Planning (ERP) 83 60% 10% 30% Infraestructura Servicios Software Figura 5.5.- Distribución de costes externos. Fuente: El futuro tecnológico de las Terminales Marítimas de Vehículos: La integración de sus sistemas de información UPC – Departament de Ciència i Enginyeria Nàutiques Barcelona, 2004 . Costes internos (Figura 5.6): • Dedicación necesaria por parte de los recursos de la compañía. • Costes asociados a la aparición del ERP en la empresa. 20% 80% Dedicación recursos compañía Costes asociados Figura 5.6.- Distribución costes internos Fuente: El futuro tecnológico de las Terminales Marítimas de Vehículos: La integración de sus sistemas de información UPC – Departament de Ciència i Enginyeria Nàutiques Barcelona, 2004 . 5.8.2.3. 5.8.2.3.5.8.2.3. 5.8.2.3.- -- - Componentes de una implantación de un ERP Componentes de una implantación de un ERP Componentes de una implantación de un ERP Componentes de una implantación de un ERP Debido a la complejidad asociada a la implantación de un ERP, es importante considerar todos aquellos aspectos que pueden afectar durante dicha implantación: 1. El ERP. Existen multitud de ERPs, cada uno de ellos con unas características determinadas. Algunos ERPs sirven para cualquier tipo de organización y Entreprise Resources Planning (ERP) 84 para cualquier sector, es lo que se denomina, solución horizontal. También existen ERPs específicos para atender a las necesidades concretas de un sector, es lo que se denomina, solución vertical. De hecho, hay ERPs que disponen de ambas soluciones: horizontal y vertical. Es importante tener en cuenta que cada organización tiene unas necesidades concretas y que el ERP y su personalización dependerán de estas necesidades, por ello, no existe una implementación “tipo”, lo que en una organización funciona puede no ser válido para otra organización. 2. Las personas y la gestión del cambio . En función de cómo se enfoque, la gestión del cambio permitirá u obstaculizará el proceso de implantación del ERP. Por ello, el correcto análisis de los requerimientos de los usuarios e integrarlos desde el primer momento de la implantación es clave para conseguir buenos resultados con el proyecto. Además, se deben definir exactamente las mejoras que va a obtener cada una de las personas de la organización con la implantación y definir un plan de comunicación para “vender” el proyecto a todas las personas de la organización. Además, es poco habitual que las organizaciones cuenten con personal con una visión tanto de negocio como de tecnología que consiga liderar el proyecto por lo que el trabajo de consultores externos, y en concreto del director de proyecto, es muy importante. 3. La estrategia. El proceso “ideal” sería que el plan tecnológico, incluyendo el ERP y su hardware asociado, soporte la estrategia corporativa y no al contrario. Básicamente, la idea es que teniendo perfectamente definida la estrategia de la organización, se asocie a ella los recursos tecnológicos necesarios para que sea posible ejecutarla. 4. El hardware. Aunque en principio el hardware no es la parte más compleja de la implantación, en algunos casos puede ocurrir que la mala elección del hardware o diseño del sistema haga disminuir el rendimiento global de la implantación. Entreprise Resources Planning (ERP) 85 En este sentido es básico definir exactamente los requerimientos del sistema y así diseñar la solución de manera que no se invierta ni más ni menos de lo necesario. 5. Los procesos. Se ha de considerar que además de las personas, los procesos son los que definen la eficiencia y eficacia de la organización. Por ello en el proyecto de implantación de ERP se deben redefinir los procesos para mejorar su eficiencia y eficacia. El enfoque correcto es redefinir los procesos como un paso previo a la implantación y que los nuevos procesos sean soportados por el ERP. Sin embargo, lo habitual es encontrar implantaciones de ERPs en los que, tras la implantación, se ejecutan los procesos exactamente igual que antes del ERP. Este es un gran problema ya que no se consigue ninguna mejora en los costes o tiempos de los procesos. Aunque tengamos el mejor ERP del mundo, si los procesos no se remodelan, seguirán siendo igual de eficientes o ineficientes como lo eran hasta el momento de la implantación y entonces, la implantación del ERP tendrá bajo o nulo impacto en la eficacia y eficiencia. 6. El resto de aplicaciones de gestión existentes en la organización . Cada vez es más usual que las organizaciones tengan distintas aplicaciones para la gestión. Entre las aplicaciones más habituales están las herramientas propias o sectoriales, las de Gestión de Relaciones con los clientes (CRM), Business Intelligence, Gestión de la cadena de suministro (SCM), etc. En la mayoría de las ocasiones, todas las aplicaciones han de estar conectadas con el ERP para conseguir una gestión de la información eficiente. Por ello, la integración entre las distintas aplicaciones (EAI) es una tarea cada vez más compleja y que condiciona los resultados finales de la implantación. 5.8.2.4. 5.8.2.4.5.8.2.4. 5.8.2.4.- -- - Fases de una implantación Fases de una implantación Fases de una implantación Fases de una implantación En toda implantación de ERP hay dos fases totalmente distintas: 1. La "pre-implantación", es decir, el análisis previo para definir los objetivos del proyecto, alcance funcional, coste total, recursos necesarios, Entreprise Resources Planning (ERP) 86 necesidades concretas de la organización, calendarios, etc. para conseguir evaluar la rentabilidad que supondrá la implantación del ERP. 2. El proyecto propio de implantación incluyendo desarrollos, personalizaciones, formación, etc. Habitualmente la fase de pre-implantación es infravalorada y en muchas ocasiones ni se realiza este análisis llevando a implantaciones con objetivos poco definidos y con multitud de problemas. Es habitual encontrar organizaciones que no han desarrollado correctamente el análisis pre-implantación y por tanto no han elegido bien la solución. Por todo ello, el análisis previo debe contener al menos los siguientes apartados: a) Análisis inicial de la estrategia, tecnología, procesos, personas y organización. En esta fase, se debe realizar un profundo análisis de la estrategia, personas, procesos y tecnología para así plantear la mejor solución tanto desde el punto de vista tecnológico como de gestión del cambio asociado. En esta etapa se crearán equipos de trabajo para hacer este análisis y para el trabajo posterior. b) Definición de objetivos de la implantación del ERP. Claramente, habrán objetivos tangibles (reducción de costes, mejora de eficacia y eficiencia de procesos, reducción del plazo de entrega, reducción de los niveles de inventario, etc.) y otros intangibles como por ejemplo disponer de más cantidad de información y conocimiento para la toma de decisiones. Obviamente, todos estos objetivos deben estar integrados dentro de la estrategia de la organización. c) Definición de las mejoras en los procesos y organización que aportará la implantación del ERP. Esto no debe ser una declaración de intenciones sino que se deben haber modelado los procesos de la organización y reconocer el impacto sobre ellos de la implantación del ERP. En esta fase se deben definir objetivos cuantificados de mejora para cada uno de los procesos y deben estar integrados en el calendario del proyecto. d) Definición del plan de gestión del cambio para conseguir el cambio de manera no traumática. Dentro de este plan, la comunicación interna es muy importante para "vender" los beneficios del proyecto a los integrantes de la organización, y conseguir que todo el mundo perciba una mejora con el proyecto ERP. e) Elección de la solución tecnológica. Así como el implantador más adecuado en función del análisis realizado en la primera fase así como los módulos y personalizaciones necesarias. Entreprise Resources Planning (ERP) 87 f) Definición de un calendario aproximado y presupuesto asociado. Obviamente esta fase estará directamente relacionada con la fase anterior ya que en función de la elección tecnológica y de los desarrollos anexos, el calendario y el presupuesto variarán. g) Definición del retorno de la inversión (ROI). Y los parámetros clave KPI, para definir el seguimiento de la implantación así como un análisis de sensibilidad ante la variación de determinados parámetros. h) Implantación del ERP. Seguimiento y control estricto de los objetivos previamente definidos así como de los elementos críticos para la rentabilidad del proyecto. Es muy importante que haya un estricto control del proyecto para que se cumplan los objetivos definidos en las primeras etapas. 5.8.2.5 5.8.2.5 5.8.2.5 5.8.2.5 Ventajas e Inconvenientes de su implantación Ventajas e Inconvenientes de su implantaciónVentajas e Inconvenientes de su implantación Ventajas e Inconvenientes de su implantación Ventajas Los sistemas ERP, integran los procesos relevantes de una empresa. Las ventajas que ofrece la implementación de un sistema ERP son: control de la operación, eficiencia administrativa, productividad, servicio a clientes, ahorros en costos operativos, visibilidad de las operaciones, soporte a toma de decisiones, preparación para e-business, etc. Los ERP otorgan a la empresa la posibilidad de reducir sus costos y de ser más competitivas además de tomar ventaja con respecto a su competencia si ésta no cuenta con un sistema como este. Los sistemas ERP ofrecen un enorme potencial de ahorro tangible e intangible. Entre los primeros destaca la reducción de recursos humanos necesarios y de inventario. Por otra parte, los ERP aportan un incremento la cantidad y la calidad de información de los consumidores, lo que representa un beneficio intangible muy valorado. Estos sistemas permiten ver y gestionar la red extendida de la empresa, sus proveedores, alianzas, y clientes como un todo integral. Entre otros beneficios, esto repercute en una mejora de la cadena de procesos, una mayor estandarización y mayor eficacia en la respuesta a los clientes. Inconvenientes Entreprise Resources Planning (ERP) 88 Por otra parte, la implantación de un ERP, conlleva una serie de inconvenientes que es muy importante valorar y tener en cuenta. Los más relevantes son: • Hay que tener en cuenta que la implementación suele ser larga, cara y difícil. • La implementación puede costar varias veces más que la licencia. • La empresa tiene que adaptar sus procesos al sistema. • Dependencia de un solo proveedor. • La fijación de un estándar a veces lleva a adoptar el mínimo común denominador. • Imponer un sistema ERP desde arriba puede ser un gran error. • Empresas cambiantes y altamente descentralizadas no deben usar un ERP. • Algunos proveedores se han especializado solo en ciertas industrias. 5.8.3. 5.8.3.5.8.3. 5.8.3.- -- - Enfoque metodológico Enfoque metodológico Enfoque metodológico Enfoque metodológico Permitirá conocer los procesos de negocio de las compañías, identificar los criterios clave de selección de herramientas de gestión, analizar la oferta existente en el mercado, seleccionar aquella solución que mejor se adapta a las necesidades de la compañía (Figura 5.6). Figura 5.6.- Enfoque metodológico Fuente: El futuro tecnológico de las Terminales Marítimas de Vehículos: La integración de sus sistemas de información UPC – Departament de Ciència i Enginyeria Nàutiques Barcelona, 2004 . Entreprise Resources Planning (ERP) 89 5.8.3.1. 5.8.3.1.5.8.3.1. 5.8.3.1.- -- - Análisis de la situación actual Análisis de la situación actual Análisis de la situación actual Análisis de la situación actual Objetivo: Conocer los procesos de negocio clave de las compañías, la interrelación entre ellos, y los Sistemas e Infraestructuras existentes. Actividades: • Identificación Procesos y Reglas de Negocio actuales. • Identificación Arquitectura Tecnológica actual. Resultados: • Plan de Proyecto. • Modelo de Procesos / Reglas de Negocio. • Descripción de funciones. • Esquema de Infraestructura Tecnológica. 5.8.3.2. 5.8.3.2.5.8.3.2. 5.8.3.2.- -- - Análisis de Requisitos. Análisis de Requisitos. Análisis de Requisitos. Análisis de Requisitos. Objetivo: Conocer las necesidades de los usuarios con respecto al Modelo de Procesos de Negocio que tienen la compañía, y las expectativas respecto al nuevo sistema. Actividades: • Toma de requisitos. • Selección de las “best practices” sectoriales. • Identificación de los procesos necesarios para las “best practices”. Resultados: • Modelo de Procesos mejorado. • Requisitos de usuario (de negocio, técnicos). 5.8.3.3. 5.8.3.3.5.8.3.3. 5.8.3.3.- -- - Identificación Alternativas Identificación Alternativas Identificación Alternativas Identificación Alternativas Objetivo: Identificar los ratios que servirán para evaluar las diferentes alternativas y seleccionar aquellas que se ajustan a las necesidades establecidas. Actividades: • Definición de ratios de evaluación. Customer Relationship Management 96 De forma similar a lo anterior, Winer (Winer, R. (2001); A Framework for Customer Relationship Management ) sostiene que la necesidad por comprender mejor el comportamiento del cliente y el interés de numerosos directivos por focalizarse hacia esos clientes, quienes pueden generar beneficios a largo plazo, han modificado la manera como los especialistas en marketing venían concibiendo el mundo. Tradicionalmente, los especialistas estaban entrenados para conseguir clientes, tanto nuevos, es decir, quienes nunca habían adquirido el producto/servicio anteriormente, como aquellos que actualmente forman la cartera de clientes de la competencia. Por lo tanto, el énfasis de la conversión ha sido cambiado desde la denominada adquisición (captación) de clientes hacia la retención. Este paulatino cambio de, donde el enfoque transaccional que predominó en el marketing durante varias décadas parece moverse hacia un enfoque centrado en las relaciones. Por otra parte, Dawson, Reichheld y Rigby (Dawson, C., Reichheld, F. y Rigby, D. (2003); Winning Customer Loyalty Is The Key To a Winning CRM Strategy ) sostienen que con la aparición de Internet, es más difícil que nunca mantener a los clientes. Ellos disponen de amplias elecciones y con sólo marcar un par de teclas en el ordenador, les permite chequear la oferta de la competencia para formarse una visión más amplia. En efecto, una compañía con una impresionante tasa de retención cercana al 90% perderá más de la mitad de sus clientes en el lapso de cinco años. En esta misma línea, Albert, Goes y Gupta (Albert, T., Goes, P. y Gupta, A. (2004); GIST: A model for design and management of content and interactivity of customer ) advierten que, con la amplia proliferación de las herramientas de la tecnología y la comunicación, los sistemas centrados en el cliente y basados en la Web, tales como sitios Web de comercio electrónico o sitios que apoyan las actividades de CRM son en sí mismos sistemas complejos, de múltiples componentes y de amplia variedad de información, pero su diseño y mantenimiento requieren seguir de manera amplia diferentes enfoques de los tradicionales sistemas del ciclo de vida. Mientras algunos usuarios finales pueden ser, ya sea clientes actuales o potenciales, muchos de ellos son visitantes no transaccionales, a menudo anónimos que son parte de la extensa población de usuarios de Internet. Esos usuarios pueden manifestar una amplia variedad de preferencias y motivos hacia el sitio, lo cual dificulta su captura. Sin duda alguna, los conceptos de lealtad y retención, han sido los temas dominantes entre los especialistas interesados en la gestión de las relaciones con el cliente (CRM). Aunque los progresos se han centralizado, precisamente, en la gestión de dichas relaciones, todavía se observan altas tasas de deserción (Thomas, J., Blattberg, R. y Fox, E. (2004); Recapturing Lost Customers ; Journal of Marketing Research). De hecho, los mismos autores sostienen que, aunque todos los aspectos de CRM necesitan ser asumidos y las estrategias y tácticas deben desarrollarse, un área que ha sido inmensamente ignorada en la literatura del marketing son las Customer Relationship Management 97 estrategias de reconquista (recuperación) del cliente. La reconquista del cliente es el proceso de revitalización de las relaciones de la compañía con aquellos clientes que han desertado. Por lo tanto, los antecedentes básicos que justifican el surgimiento de CRM deben buscarse en los estudios que apoyan la relevancia de fomentar la retención y lealtad de los clientes, así como también y cada vez con mayor intensidad, en la relevancia que implica la construcción y establecimiento de relaciones orientadas a recuperar a los clientes perdidos o que manifiestan comportamientos irregulares en la adquisición de bienes y servicios de una determinada compañía. No obstante lo anterior, la principal complejidad que implica abordar el tema relacionado con CRM estriba en el hecho que su impulso y justificación responde a una serie de factores y variables que subyacen en su aplicación. Por una parte, se relaciona estrechamente con el concepto de calidad de servicio , pudiendo ser considerada como una extensión de las diversas aplicaciones orientadas a proporcionar un nivel de calidad óptimo en la provisión de determinado servicio. Dentro de la literatura en torno al concepto de calidad, se ha insistido reiteradamente en la necesidad de proveer productos y servicios que satisfagan e incluso superen las expectativas de los clientes, con los consecuentes beneficios que esta situación conlleva para las utilidades de la empresa. En dicho sentido, Zeithaml (Zeithaml, V., Rust, R. y Lemon, K. (2001); The Customer Pyramid: Creating and Serving Profitable Customers ) reconocen que hasta antes de los años noventa, la conexión general entre calidad de servicio y rentabilidad aún estaba siendo cuestionada, pero desde principios de los noventa esta relación ha sido persuasivamente asumida. De hecho, el estudio de Buzzell y Gale (Buzzell, R. y Gale, R. (1987); The PIMS Principles ) puede ser considerado como un referente destacado que permitió demostrar la correlación entre calidad y beneficios tanto en compañías manufactureras como en empresas de servicios. Numerosos estudios han demostrado las estrechas relaciones entre calidad de servicio y rentabilidad. En esta línea, Bolton y Drew (Bolton, R. y Drew, J. (1991); A Longitudinal Analysis of the Impact of Service Changes on Customer Attitudes ) demostraron que los esfuerzos de mejora en el servicio producían un incremento en los niveles de satisfacción del cliente, tanto a nivel de proceso como de atributo. Keiningham, Zahorik y Rust, (Keiningham, T., Zahorik, A. y Rust, R. (1994); Getting Return on Quality ; Journal of Retail Banking) demostraron que el incremento de la satisfacción del cliente en el proceso o a nivel de atributo explicaban un incremento de la satisfacción global del cliente. En línea con lo anterior, Zeithaml, Berry y Parasuraman (Zeithaml, V., Berry, L. y Parasuraman, A. (1996); The Behavioral Consequences of Service Quality ) demostraron que una más alta calidad de servicio o satisfacción del cliente repercutían en un incremento en las intenciones de Customer Relationship Management 98 conducta, especialmente en un aumento considerable de la intención de recompra. Bolton (Bolton, R. (1998); A Dynamic Model of the Duration of the Customer’s Relationship with a Continuous Service Provider: The Role of Satisfaction ) demostró que un incremento en la conducta de intencionalidad repercutía en el impacto conductual, incluyendo la recompra o la retención del cliente, una positiva disposición hacia la publicidad boca-oído (word-ofmouth) y un incremento en el nivel de uso. Además, Zahorik y Rust (Rust, R., Zahorik, A. y Keiningham, T. (1995); Return on Quality (ROQ):Making Service Quality Financially Accountable ) demostraron que el impacto en la conducta genera un aumento en la rentabilidad y en otros resultados financieros. Tal como señalan Zeithaml, para construir y mejorar sobre la segmentación tradicional, los negocios han estado intentando identificar segmentos – o, más apropiadamente, los niveles de rentabilidad de los clientes – que difieren en su nivel de rentabilidad actual y futura para la compañía. Incluso, tales autores llegan a identificar por medio de un ejemplo empírico, cuatro condiciones absolutamente necesarias para que los diversos niveles de clientes sean explotados por la compañía: en primer lugar, tales niveles tienen perfiles diferentes e identificables; en segundo lugar, los clientes en cada uno de los niveles aprecian la calidad de servicio de manera diferente; en tercer lugar, existen factores diferentes que influyen en la incidencia y volumen del nuevo negocio a través de tales niveles y, por último, la rentabilidad derivada del impacto de la mejora en la calidad de servicio varía ampliamente en los diferentes niveles de clientes. Otro antecedente que se relaciona con el potencial de CRM como herramienta para fomentar las relaciones con los clientes y aumentar la rentabilidad de cada uno de los diversos grupos identificados, es lo que Zeithaml denomina la “alquimia del cliente”. Básicamente la definen como el arte de reconvertir a los clientes menos rentables en clientes más rentables. Esa reconversión tiene lugar en alguno de los niveles de la “Pirámide del Cliente”, advirtiendo, eso si, que es más difícil concretarlo en unos niveles más que en otros. Por ejemplo, es muy difícil ascender a un cliente “plomo” hacia los niveles “oro” o “platino” y, frecuentemente, es necesario asumir el hecho de dejar a ese cliente en esa misma categoría más que intentar trasladarlo a las categoría superiores. No es de extrañar, entonces, que una vez identificada y demostrada la conexión entre calidad de servicio y nivel de beneficios (rentabilidad), el desafío lógico a asumir consistía en comprender las necesidades de los clientes e identificar aquellos grupos de consumidores más rentables (Rigby, D.; Reichheld, F. y Berez, S. (2002b); Custom Fit ; Optimize). Ello, indudablemente, conduce a centrar la atención en la construcción e intensificación de las relaciones con aquellos clientes o grupos de clientes que pueden resultar más rentables para la compañía, lo que puede considerarse el antecedente clave que lleva al surgimiento de CRM como Customer Relationship Management 99 una herramienta de gestión que permita conseguir dicho objetivo de la manera más eficiente. 6.3. 6.3.6.3. 6.3.- -- - Delimitación del concepto de CRM Delimitación del concepto de CRM Delimitación del concepto de CRM Delimitación del concepto de CRM Definitivamente, el ímpetu por el interés en el CRM se origina en una investigación de Reichheld, quien demostró un incremento dramático en los beneficios a partir de pequeños incrementos en la tasa de retención de clientes. Su estudio mostró que un incremento tan leve como un 5% en la retención de cliente generó impactos tan altos como el 95% sobre el valor actual neto generado por los clientes (Winer, R.). De hecho, la importancia e impacto de la recuperación del cliente es un elemento clave en la estrategia de CRM de la compañía que no puede ser subestimado. Las investigaciones han mostrado que una compañía tiene entre 60% - 70% de posibilidad de repetir exitosamente la venta en el caso de un cliente activo; entre 20% - 40% de oportunidad de repetir la venta exitosamente en un cliente que se consideraba perdido y sólo entre 5%-20% de oportunidad de cerrar la venta exitosamente cuando se trata de un cliente nuevo (Thomas). No obstante, aunque existe un interés considerable por las relaciones con el cliente, también existe un alto nivel de confusión e incertidumbre. Numerosas empresas están apoyando un importante número de iniciativas de CRM aún cuando la mayoría de ellas no sabe cuánto de esas iniciativas ayudará a incrementar o disminuir la rentabilidad de sus organizaciones (Battista, P. y Verhun, D. (2000); Customer Relationship Management. The promise and the reality ; CMA Management). A pesar del poderoso atractivo que generan las cifras anteriormente señaladas, Rigby, Reichheld y Schefter (Rigby, D.; Reichheld, F. y Schefter, P. (2002); Avoid the Four Perils of CRM; Havard Business Review) señalan que la promesa de CRM es cautivante, pero en la práctica puede ser arriesgada. Cuando se trabaja en sintonía con CRM permite a las compañías recolectar información velozmente, identificar durante todo el tiempo a la mayoría de los clientes que reportan los más altos beneficios – valor – e incrementar la lealtad del cliente mediante la entrega de productos y servicios a la medida – customization-. Además, reduce los costes de servir a tales clientes y hace más fácil conseguir (captar) clientes similares conforme se avanza en el día a día. El riesgo, por lo tanto, es que CRM se convierta en una especie de “panacea” que dará solución, por la vía de una gestión eficaz apoyada en las múltiples opciones que despliegan las nuevas tecnologías de la información y la comunicación (TIC’s) al desafío de proporcionar productos/servicios a medida, aumentando con ello los niveles de satisfacción de los clientes, quienes retribuirían dicho esfuerzo mediante Customer Relationship Management 100 una estrecha y permanente relación conducente a mejorar los niveles de fidelización y lealtad para con la empresa o compañía. El primer modelo de CRM empezó a ser discutido hace menos de una década atrás.Desde entonces, trozos y piezas del modelo han sido desplegados en algunas organizaciones y se detecta un nivel considerable de experimentación, con resultados muy heterogéneos (Hansotia, Hansotia, B. (2002); Gearing up for CRM: Antecedents to Successful Implementation ; Journal of Database Marketing). En este sentido, un punto de vista bastante crítico es el que proporciona Patron (Patron, M. (2002); If Database Marketing was so good, why is CRM so bad? ; Journal of Database Marketing), quien señala que las cosas estaban mucho mejor antes de que se empezara a utilizar el término CMR. El Marketing de Base de Datos – Database Marketingera consistente y tenía un auspicioso futuro. El panorama actual, sin embargo, demuestra que sobre el 80% de los proyectos de CRM fracasan en Europa. Agrega que las empresas ya han sacado partido del marketing de base de datos y ahora ya conocen quienes son sus mejores clientes. Ahora las empresas están desarrollando capacidades de CRM para que puedan proporcionar la oferta correcta, a la persona correcta, en el momento adecuado y a través del canal más idóneo, situación que es mucho más compleja que el marketing de base de datos. Nairm (Nairn, A. (2002); CRM: Helpful or full of hype? ; Journal of Database Marketing) sostiene que gran parte del avance y proliferación de herramientas orientadas a maximizar los beneficios derivados de las relaciones entre proveedor y cliente, viene apoyado por el impresionante desarrollo tecnológico de los últimos años, proponiendo un esquema de evolución (Figura 6.1) en el cual es posible visualizar los avances previos que han posibilitado el surgimiento de la denominada gestión de las relaciones con el cliente: Customer Relationship Management 101 Figura 6.1.- Evolución de la tecnología. Fuente: Nairn, A. (2002); CRM: Helpful or full of hype? ; Journal of Database Marketing Un aspecto que resulta notable de destacar es el vertiginoso crecimiento que ha experimentado la implantación de iniciativas de CRM en numerosas organizaciones en los últimos años. De hecho, los resultados de una investigación sobre herramientas globales de gestión desarrollado por la consultora Bain, aplicada a directivos experimentados en negocios con alto grado de tecnología, demostró que el uso de las diversas aplicaciones de CMR aumentó a casi el doble en el lapso de tan sólo una año – desde un 35% en 2001 a un 72% en 2002. No obstante, el espectacular aumento de las aplicaciones de CRM en numerosas organizaciones parece ir acompañado de importantes tasas de fracaso, quizá como respuesta a una situación más bien guiada por la novedad que por una seria apuesta estratégica que permita alinear la organización con una nueva filosofía de gestión del negocio. Como señalan Gillies, Rigby y Reicheld (Gillies, C., Rigby, D. y Reichheld, F. (2002); The Story Behind Successful Customer Relations Management ), son muy pocos los líderes que han sido capaces de resistirse a una tecnología que promete identificar rápidamente a sus clientes más rentables, seleccionándolos como objeto central de campañas orientadas a incrementar tanto sus compras y su lealtad, siempre al más bajo coste. A modo de ejemplo, un estudio desarrollado el año 2001 por la empresa consultora Gartner sobre una muestra de grandes compañías, determinó que un 55% de las iniciativas de CRM fracasaron al analizar el retorno de la inversión que, habitualmente, oscila entre $60 millones y $130 Customer Relationship Management 102 millones de dólares. Además, el mismo año, una investigación desarrollada por Bain mostró que CRM ocupaba el lugar número veintiuno entre veinticinco herramientas evaluadas por altos directivos, identificando, además, que una quinta parte de los usuarios de CRM habían abandonado las herramientas en su conjunto. Recurriendo a una revisión de la literatura disponible, son numerosos los trabajos que han intentado proporcionar una definición precisa acerca del concepto de CRM. En una primera aproximación al concepto, Hansotia (Hansotia, B. (2002); Gearing up for CRM: Antecedents to Successful Implementation ) señala que CRM es esencialmente un esfuerzo intensivo de información acerca del cliente. Además, puntualiza que en el núcleo central de CRM subyace la habilidad de la organización para tratar la información del cliente de modo creativo, eficaz y eficiente para diseñar e implementar estrategias focalizadas hacia el mismo. Por su parte, Rigby (Rigby, D.; Reichheld, F. y Berez, S. (2002); Custom Fit ) proponen que CRM consiste, simplemente, en comprender a los grupos de clientes y tratar a cada uno de una forma que se maximice su valor, recurriendo habitualmente al uso de softwares que apoyen y faciliten el proceso. Para ellos, CRM es una herramienta más que forma parte de las numerosas aplicaciones enfocadas a fomentar la lealtad de los clientes. En este sentido, identifican que dentro de tales iniciativas existen aplicaciones más tradicionales como la segmentación de los clientes, el marketing one-toone, la satisfacción de los clientes y la retención de los mismos. Y, al mismo tiempo, agregan que conforme a sus dilatadas observaciones, CRM ha sido la herramienta con la tasa más alta de abandono por parte de la mayoría de las compañías que han analizado (con una tasa cercana al 18%). De manera similar, Gillies define CRM como una forma de enlazar las técnicas y elementos tratados y probados en la segmentación de clientes para determinar con cuáles clientes se quiere ‘CR’ (create relationships), es decir, establecer o crear relaciones y con cuáles se desea gestionar el coste (‘CM’, cost-manage). Para Croteau y Li, CRM es un concepto que permite a una organización confeccionar productos y servicios específicos para cada cliente individual. Por su parte, Piccoli entienden CRM como una filosofía de gestión que permite a la empresa llegar a establecer relaciones más familiares con sus clientes. Agregan que la empresa que apoya iniciativas de CRM se esfuerza por proveer un servicio consistente y personal al cliente durante todo el tiempo y a través de múltiples puntos de contacto. En otras palabras, CRM es una filosofía de gestión que clama por la reconfiguración de las actividades de la compañía alrededor del cliente. Customer Relationship Management 103 En un escenario más avanzado, CRM se puede entender como una herramienta que se utiliza para crear una experiencia personalizada, de uno en uno, que otorgará al cliente una sensación de estar bien tratado y cuidado, lo que permite generar nuevas oportunidades de marketing basadas en las preferencias e historial del cliente (Peppers Peppers, D., Rogers, M. y Dorf, B. (1999) ; Is Your Company Ready for One-to-One Marketing ). Morris Morris, T. (2000); Custom Made. Adding Value to Your EBusiness Strategy ) se refiere a CRM como un software, no como un proceso integrado de gestión, mientras que Nairm entiende CRM como una filosofía de negocio a largo plazo que se orienta, básicamente, a recolectar, comprender y utilizar de manera inteligente la información del cliente y tratar a los clientes diferentes de manera distinta, proporcionando un alto nivel de servicio para los mejores clientes; de la combinación simultánea de esas dos acciones se intenta alcanzar los objetivos de incrementar la lealtad del cliente y la rentabilidad. Por último, para Piccoli CRM puede entederse como un compromiso global de la empresa para identificar clientes individuales y crear relaciones entre la compañía y esos clientes durante todo el tiempo para que dicha relación sea mutuamente beneficiosa. A partir de las definiciones anteriores, queda en evidencia que no existe un consenso general que permita delimitar exactamente el concepto de CRM y sus implicaciones para las organizaciones que la utilizan. En este sentido, quizá la dificultad de identificar una definición sobre qué es exactamente CRM se puede encontrar en las reflexiones planteadas por Reinartz(Reinartz, W. y Kumar, V. (2002); The Mismanagement of Customer Loyalty) . Para ellos, no existe una clara evidencia en cuanto a las características de los enfoques exitosos de CRM ni de las razones por las que CRM puede potencialmente fracasar. Es más, la literatura académica existente y las aplicaciones prácticas de CRM no proveen una indicación clara sobre qué exactamente constituye la implantación de los procesos de CRM. Algunas compañías ven CRM principalmente como inversiones en tecnología y software, mientras otras tratan CRM más ampliamente y son agresivas en desarrollar estrechas y productivas relaciones con los clientes. Mucho más crítica es la visión que aporta Nairn quien sugiere que CRM, en su conjunto, no es más que una extensión de la antigua y bien establecida idea de la segmentación, lo que lleva a plantearse la siguiente interrogante: ¿por qué repentinamente surge un marcado frenesí y por qué los analistas giran nerviosamente en torno al concepto con un afán excesivo de proliferación de acrónimos? Y agrega, ¿por qué se percibe un sentimiento de que CRM es un bombo publicitario? Sin embargo, a pesar de lo anterior, se puede detectar que tras las numerosas definiciones acerca de CRM se puede extraer un objetivo común Customer Relationship Management 104 que justifica su aplicación en la organización. Los objetivos clave que subyacen en las inversiones de CRM descansan en el intento de reforzar la afinidad de los clientes con marcas particulares o específicas, al mismo tiempo que se intenta disminuir el coste de dicha interacción. Otra clara situación derivada del énfasis que se viene otorgando a las iniciativas de CRM en el ámbito del marketing de relaciones es el hecho que la notoria preocupación y atención sobre dicha herramienta ha provocado que numerosas empresas se enfrenten a una permanente lucha por la necesidad de desarrollar estrategias de relaciones y establecer procesos operacionales que sintonicen con la captación, servicio y retención de clientes (Battista y Verhun). En consecuencia, parece que contrariamente a lo que sucede con numerosos conceptos tratados durante el desarrollo de la presente investigación, el término CRM, aunque universalmente utilizado, hasta la fecha carece de una definición formal. Así, un número importante de proveedores, aprovechando el movimiento del mercado en esa dirección empezaron a catalogar como CRM a las mismas aplicaciones que venían existiendo e implementándose desde hace varios años. Por este motivo, si se revisa la literatura disponible respecto al tema, la gran mayoría de las definiciones provienen de empresas consultoras y de asesoría en tecnologías y aplicaciones informáticas. En dicho sentido, Winer, señala que el problema principal es que CRM significa diferentes cosas para diferentes personas. Para algunos, CRM significa correo electrónico directo. Para otros, implica customización masiva o el desarrollo de productos/servicios que se ajusten a las necesidades individuales de los clientes. Para los consultores de IT – tecnologías de la información-, CRM se traduce en una complicada jerga relacionada con términos tales como OLAP – on-line analytical processing – y CIC’s - customer interactions centers -. Considerando los antecedentes anteriormente señalados y para los efectos de la presente investigación, CRM puede entenderse como una estrategia de negocios destinada a focalizar los recursos de las empresas a partir del conocimiento real de todas las interacciones de la compañía con el cliente y de las respuestas que éste da a cada estímulo. También se puede definir como un modelo de negocio que tiene por objetivo establecer relaciones con clientes de forma individual para luego utilizar las informaciones recogidas que permitan tratar clientes diferentes de manera diferente. Dicha interpretación encuentra similitudes con los planteamientos del Gartner Inc. (Gartner, Inc. (2004); Emerging Technologies) – empresa proveedora líder en investigación y análisis de la industria de la información y nuevas tecnologías – para quienes CRM es una estrategia de negocio volcada al Customer Relationship Management 105 conocimiento anticipado de las necesidades de los clientes actuales y potenciales de una empresa. Desde el punto de vista tecnológico, CRM comprende la captura de datos del cliente a lo largo de toda la empresa, la consolidación de todos los datos, tanto interna como externamente, en un banco de datos central, el análisis de tales datos consolidados, la distribución de los resultados de dicho análisis a los diversos puntos de contacto con el cliente y, por último, utilizar esa información en beneficio de la interacción con el cliente a través de cualquier punto de contacto entre éste y la empresa. Se refiere a aquellas aplicaciones que las empresas pueden utilizar para administrar todos los aspectos de sus encuentros con los clientes. Un sistema CRM puede incluir todo, desde tecnología para la recolección de datos en las llamadas telefónicas del área de ventas hasta sitios web de autoservicio donde los clientes pueden informarse y aprender acerca de los productos/servicios que la compañía les ofrece. Desde otra óptica, CMR puede ayudar a lo que Zeithaml denominan “vínculos estructurales” con el cliente – learning relationships -. Estos vínculos estructurales se crean para proveer servicios al cliente que habitualmente están diseñados de manera correcta dentro del sistema de distribución del servicio para ese cliente. Por lo general, estos vínculos se crean para proveer servicios a medida de cada cliente y están basados en tecnología con la finalidad de hacer al cliente más productivo. En dicho sentido, Day, Dean y Reynolds (Day, J., Dean, A. y Reynolds, P. (1998); Relationship Marketing: Its Key Role in Entrepreneurship ) orientan sus observaciones hacia los beneficios que reporta el uso de CRM. En primer lugar, por medio del desarrollo de una relación más estrecha y cercana con el cliente, la empresa puede ganar una ventaja competitiva y, a través de un incremento de los costes de cambio, puede ser capaz de defenderla. De hecho, durante todo el tiempo, los clientes individuales proporcionan información a la compañía acerca de sus necesidades, deseos y preferencias individuales un proceso costoso que, por lo general, ellos son reacios a repetir con una empresa rival. Por lo tanto, el hecho de conocer estrechamente a los clientes crea una barrera para la imitación de la estrategia del líder. En segundo lugar, una iniciativa de CRM eficaz puede incrementar la satisfacción del cliente. Adecuadamente implementado, el diálogo clientecompañía facilita la adaptación de los productos y servicios a las necesidades individuales y el desarrollo de nuevos productos y servicios satisfacen las necesidades cambiantes e incluso se anticipan a las necesidades futuras. En tercer lugar, el uso de las técnicas de CRM contribuye a disminuir el gasto global de marketing. Se estima que adquirir nuevos clientes es más costoso que mantener a los ya existentes. Customer Relationship Management 112 cliente, (3) gestión del proceso de cliente, (4) gestión de la experiencia del cliente y (5) gestión del conocimiento acerca del cliente. Los mismos autores señalan, además, que la principal barrera para la implantación exitosa de las iniciativas de CRM no descansa en una cuestión relacionada con el enfoque estratégico, sino más bien, en una cuestión relacionada con el uso y apliaciones de las nuevas tecnologías. De esta manera, las principales barreras relacionadas con la tecnología para la implantación de CRM son: • inconsistencia de la información y pérdidas de datos. • la legalidad de los sistemas. • la proliferación de canales de distribución y comunicación. • el coste. • la falta de habilidades empresariales. • la gestión del cambio. También es importante destacar que algunos estudios se han centrado en determinar la aparente contradicción que se empieza a visualizar entre avance tecnológico y la necesidad por una atención más personalizada y cálida y las serias dificultades e incoherencias que suelen presentarse en la gestión de las bases de datos, de los call centres y de los sistemas de comunicación con el cliente, ya sea en los contactos cara a cara, por teléfono, por correo escrito tradicional o por correo electrónico, todos soportes ampliamente utilizados por las iniciativas de CRM (De Torcy, De Torcy, G. (2002); A New Wave in Creating Customer Satisfaction ). Incluso, el mismo autor sostiene la necesidad por diferenciar claramente la aparente confusión que existe entre los conceptos de customización versus personalización. Para McKim (McKim, B. (2002); The Differences Between CRM and Database Marketing ) la principal dificultad de las inicativas de CRM descansa en sus elevados costes requeridos para su adecuada implantación. Dicho autor apoya la utilización de los ampliamente difundidos principios y técnicas del marketing de base de datos en detrimento de CRM, justificando su visión en el hecho que ambas disciplinas tienen características y costes de implementación muy similares, permitiendo obtener una visión de 360º del cliente y manejar toda la información en un sistema común, pero cuyos resultados tienden a ser menos favorables en el caso de la herramienta más reciente. Customer Relationship Management 113 Incluso, el factor tiempo se agrega como una variable en contra de las iniciativas de CRM. Normalmente, los sistemas de CRM requieren una media de un año para su instalación y funcionamiento a pleno rendimiento, mientras que los sistemas de marketing de base de datos generarán información y resultados en un lapso comprendido entre cuatro a seis meses como promedio. Siguiendo con las aportaciones de McKim, el autor clasifica los principales problemas con las iniciativas de CRM en tres áreas distintas conforme a las observaciones realizadas en los últimos años, los que se exhiben en la figura siguiente: Una visión diferente es la que propone Hansotia, para quien el principal foco de atención respecto a CRM ha estado puesto en la plataforma tecnológica que apoya las interacciones con el cliente y la automatización de las ventas, sin embargo, son muy escasos y puntuales los estudios que se han centrado en analizar el éxito de la altas tasas de retorno sobre los esfuerzos e inversiones en infraestructura de marketing. El autor considera que la justificación clave que explica dicha situación descansa en una falta de inversión en los dos principales requisitos de CRM: el diseño estratégico y una adecuada planificación y análisis . Agrega que si una empresa está buscando desarrollar un proyecto de demostración de CRM, tal situación puede implicar que la empresa no desea realizar un esfuerzo firme por el diseño de su estrategia, lo cual significaría el mayor error si sólo se focaliza en la tecnología que permite la interacción con el cliente sin considerar modelos y análisis que ayuden a planificar y guiar la ejecución (Figura 6.4). Figura 6.4.- Identificación de los Principales Problemas para la Implantación Exitosa de Iniciativas de CRM. Fuente: The Differences Between CRM and Database Marketing; Journal of Database Marketing Customer Relationship Management 114 6.6. 6.6.6.6. 6.6.- -- - Modelo de Implantación de CRM en la organización. Modelo de Implantación de CRM en la organización. Modelo de Implantación de CRM en la organización. Modelo de Implantación de CRM en la organización. López Fernández (Fernández López, J. (2000); CRM o Cómo Aprovechar al Máximo los Datos del Cliente ) propone un modelo de implantación de CRM que intenta favorecer su paulatina inserción dentro de la organización que pretende llevarlo a cabo, poniendo de relieve la necesidad de abordar aspectos y etapas clave si lo que se desea es alcanzar resultados beneficiosos para la empresa (Figura 6.5). Figura 6.5.- Fases de un CRM. Fuente: CRM o Cómo Aprovechar al Máximo los Datos del Cliente; MK Marketing+Ventas Dentro de cada una de estas fases y siguiendo se pueden detectar las siguientes tareas y funciones básicas a desarrollar: Fase I: Diseño de un Sistema Corporativo de Medida. La idea es que, para el cliente el valor se mide como el cociente entre la calidad percibida y el precio que ha debido invertir para su adquisición. El sistema corporativo de medida debe verificar lo que se hace en relación con la competencia del mercado y el beneficio que reporta al cliente. Fase II: Medición Cualitativa. Este tipo de medición revela cuál es la percepción del cliente respecto a los productos/servicios que le ofrece la empresa. Las herramientas más utilizadas en este proceso suelen ser tres: la realización de dinámicas de grupo, en donde se analiza lo que el cliente necesita; los paneles de consumo, donde se revisan los aspectos del producto/servicio que demandan y necesitan los consumidores y la técnica de incidentes críticos, que permite profundizar en la información generada a través de las técnicas anteriores. Customer Relationship Management 115 Fase III: Medición Cuantitativa. Consiste en dar inicio al proceso de medición por medio de un conjunto de unidades de métrica interna, respondiendo al principio de que no se puede mejorar externamente lo que no se mide internamente. Para la consecución de este objetivo, se debe intentar establecer una conexión entre las mediciones internas con las externas, siguiendo una secuencia similar a la que sigue: a) Determinar el valor percibido por el cliente. b) Descomponer el valor en factores de percepción, como el nivel de uso del producto/servicio a partir de experiencias tangibles, estrategias, entorno y prestación de servicio. c) Desarrollar los procesos: precios, créditos y garantías. d) Definir las expectativas de los clientes. e) Desarrollar métricas internas que permitan evaluar la conducta del personal. Fase IV: Cálculo de Índices. Básicamente se recurre al uso de dos tipos de índices: de satisfacción y de proceso. Las mejores herramientas de medición son las que generan índices financieros de satisfacción al cliente y de porcentaje de cuota de mercado. Fase V: Encuestas a clientes. Su diseño y aplicación deberá responder al objetivo de permitir que sea el cliente quien defina el producto/servicio de cada uno de los procesos según sus necesidades. Fase VI: Diseño de una Nueva Cultura Corporativa. Por regla general, cuando por medio de un CRM se incentiva la participación del cliente para que valore y opine sobre los productos/servicios y de la estrategia global de la empresa, se suelen obtener buenas referencias y una respuesta de lealtad. Esta nueva cultura requiere, por lo tanto, que la empresa se dirija tanto a los clientes como a sus empleados, vale decir, la organización deberá establecer una operativa Customer Relationship Management 116 interna y sistemas ágiles que faciliten y potencien la relación en ambas direcciones. En una línea similar a los planteamientos anteriores, Winer sostiene que el paso inicial primordial para aplicar una solución CRM es la construcción de una potente y detallada base de datos del consumidor o un archivo de información. Esta tarea resulta relativamente simple en aquellos negocios que basan buena parte de sus ventas en el comercio electrónico, puesto que las transacciones del consumidor y la información de contacto están acumuladas como componente habitual de la interacción con los consumidores. No obstante, para las empresas que no han recolectado previamente información sobre sus consumidores/clientes, la tarea incluirá la búsqueda de información de contacto histórico del consumidor a partir de fuentes internas, tales como la contabilidad y el servicio al cliente. No obstante lo anterior, algunos autores advierten que las inversiones sustanciales en CRM no son adecuadas para todos. En un pequeño negocio es relativamente fácil mantenerse ajustado a las preferencias de los clientes. De hecho, una gran aerolínea o una importante cadena hotelera internacional deben gestionar, sustancialmente, grandes cantidades de información, lo que un pequeño hostal o establecimiento de alojamiento puede alcanzar de modo similar en las relaciones con sus clientes. Las compañías, tradicionalmente, han utilizado una amplia variedad de métodos para elaborar sus bases de datos. Las empresas manufactureras de bienes de larga duración utilizan información a partir de las tarjetas de garantía para configurar la información descriptiva básica. Desafortunadamente, las tasas de respuesta de tales herramientas están en un rango entre 20-30%, lo que deja enormes vacíos en las bases de datos. En contraposición, las empresas basadas en la explotación de servicios lo tienen mucho mejor, ya que la propia naturaleza de la actividad facilita la recolección de información. Por ejemplo, los bancos han estado a la vanguardia en la implantación y aplicaciones de herramientas CRM desde hace varios años. Las empresas de telecomunicaciones también disponen de una cantidad amplia de información acerca de sus clientes. Por lo tanto, se trata de llegar a determinar un perfil exhaustivo y lo más cercano a la realidad de cada cliente. La información acerca del perfil del cliente puede incluir: cuantificación del valor mediante las ventas y margen bruto, historial de compra, ciclos de compra, preferencias de producto servicio, aplicaciones de producto, condiciones financieras, frecuencia y tipo de contacto, aspectos demográficos e intenciones futuras. También puede incluir registros individuales acerca de satisfacción del cliente, intención de recompra y recomendación e indicadores claves de lealtad que calibran la relación de la compañía con el cliente. Para Piccoli CRM permite generar una más alta rentabilidad debido al incremento de las ventas, la disminución de los costes de adquisición de Customer Relationship Management 117 clientes y al incremento de la rentabilidad de los clientes dispuestos a pagar un poco más a cambio de un mejor servicio. En este sentido, los autores proponen una representación gráfica respecto a cómo opera CRM: Desde otra perspectiva, Hansotia considera tres componentes esenciales del CRM: • diseño estratégico y disponibilidad organizacional. • planificación y análisis. • ejecución de las interacciones con el cliente. Agrega, además, que cuando el cliente se convierte en el punto focal de la estrategia de la compañía, resulta inevitable que la implantación de CRM (Figura 6.6) se relacionará con casi todas las partes, áreas o unidades que integran una organización (finanzas, diseño y desarrollo de producto/servicio, servicio al cliente, comunicaciones, marketing, recursos humanos, entre otras). Por lo tanto, de manera permanente, todas las áreas o unidades de la organización deberán reinventarse a sí mismas – reingeniería – si la compañía en su globalidad pretende estar enfocada al cliente. En este sentido, los directivos necesitan crear una cultura cuyo enfoque esté centrado en el cliente y una organización basada en el aprendizaje constante (learning organization) que se adapte acertadamente a los nuevos procesos. Figura 6.6.- Modelo de CRM. Fuente: Customer Relationship Management: A Driver for Change in the Structure of U.S. Lodging Industry Customer Relationship Management 118 Por otra parte, para Croteau y Li tres funciones organizacionales principales están apoyadas en iniciativas tecnológicas dentro del escenario de CRM: • apoyo y servicio al cliente. • automatización de la fuerza de ventas. • automatización del marketing de la empresa. La función de apoyo y servicio al cliente (CSS, customer support and service) cubre el modo en el cual un producto es distribuido, empaquetado, descrito, pagado, instalado, reparado, renovado y rediseñado. Por su parte, la automatización de la fuerza de ventas (SFA, sales force automation) implica aplicar las mejores prácticas de venta en un paquete informático que puede ayudar a los equipos de ventas de la organización a atraer y retener los clientes rentables. Por último, la automatización del marketing de la empresa (EMA, enterprise marketing automation) busca el mismo impacto automático y poderoso que tiene la SFA sobre las ventas, pero orientado al marketing. Considerando las características hasta ahora señaladas, (Hansotia Figura 6.7) propone el siguiente diseño estructural de alto nivel para apoyar la correcta ejecución de CRM: Figura 6.7.- Modelo estructural de alto nivel de CRM. Fuente: Hansotia, B. (2002). Gearing up for CRM: Antecedents to Successful Implementation ; Journal of Database Marketing Customer Relationship Management 119 En definitiva, CRM depende de una cuidadosa planificación y una favorable disposición organizacional. La tecnología que subyace en las aplicaciones de CRM es necesaria para gestionar con eficiencia y eficacia los contactos iniciados con los clientes, pero si las empresas no construyen actividades específicas que sirvan de apoyo al constante flujo de caja generado por los clientes, CRM puede convertirse en una acción financieramente inviable. 6.7. 6.7.6.7. 6.7.- -- - Conclusión Conclusión Conclusión Conclusión Se puede entender entonces que para la implementación de un CRM es mas que hacer una solicitud a un proveedor de software con las cotizaciones y una presentación de los beneficios que se obtendrán, hay que analizar si la organización esta preparada y quiere un cambio de estrategia orientado hacia el cliente para poder así garantizar el éxito, o por lo menos minimizar el riesgo de fracaso de dicha implementación. Con la implementación y el uso de CRM las organizaciones pueden conservar y conseguir más clientes, y de esa manera permanecer en el mercado competitivo que estamos viviendo. Una implementación de CRM se hace y se planea de forma pausada, así tendremos la posibilidad de que los riesgos sean menores y evidenciaremos los resultados poco a poco; de esta forma se podrán incrementar los casos de éxito. Debemos recordar que el CRM debemos verlo también, como una estrategia de negocio, es por eso que debemos aprender continuamente del comportamiento de nuestra herramienta, debemos observar los movimientos que la competencia esté realizando, así como tener siempre presente que el cliente y su satisfacción son primero. Criterios comparativos de paquetes ERP Criterios comparativos de paquetes ERPCriterios comparativos de paquetes ERP Criterios comparativos de paquetes ERP Criterios comparativos ERP 121 7. 7. 7. 7. - -- - Criterios comparativos Criterios comparativosCriterios comparativos Criterios comparativos ERP ERP ERP ERP 7.1.- Introducción 7.2.- Funcionalidad 7.3.- Flexibilidad 7.3.1.- Personalización 7.3.2.- Actualizaciones flexibles 7.3.3.- Internacionalización 7.3.4.- Facilidad de uso 7.3.5.- Arquitectura 7.3.6.- Escalabilidad 7.3.7.- Seguridad 7.3.8.- Interfaces 7.3.9.- Independencia del sistema operativo. 7.310.- Independencia del sistema de bases de datos 7.4.- Soporte 7.4.1.- Infraestructura de Soporte 7.4.2.- Formación 7.4.3.- Documentación 7.5.- Continuidad 7.5.1.- Estructura del proyecto 7.5.2.- Actividad de la comunidad 7.5.3.- Transparencia 7.5.4.- Frecuencia de las actualizaciones 7.5.5.- Otros efectos acordados 7.6.- Madurez 7.6.1.- Estado del desarrollo 7.6.2.- Lugar de referencia Criterios comparativos ERP 128 web. Flujo de trabajo es la automatización de un proceso de negocio, durante el cual, la información se pasa a lo largo del sistema de acuerdo a un conjunto de reglas. 7. 7.7. 7.3.6. 3.6.3.6. 3.6.- -- - Escalabilidad Escalabilidad Escalabilidad Escalabilidad El sistema debería aceptar grandes volúmenes de transacciones con tiempos de respuesta constantes. La escalabilidad es altamente dependiente de la arquitectura y por lo tanto del servidor de aplicaciones y de la tecnología de bases de datos. "Un sistema que no escala para apoyar a todos sus futuros usuarios es un desastre a punto de ocurrir". 7.3.7. 7.3.7.7.3.7. 7.3.7.- -- - Seguridad Seguridad Seguridad Seguridad La seguridad se puede dar a nivel de usuario o de mejor manera a través de mecanismos de seguridad basados en roles que permiten la definición de los distintos niveles de derechos de acceso. Los usuarios están autorizados para ver y cambiar sólo los datos que necesitan para su trabajo. El nivel de detalle lo podemos definir a partir de la forma, materia y el nivel de fila. El nivel de seguridad por fila restringe el acceso a nivel de datos. Por ejemplo, un usuario solo puede ver las transacciones de las que él es responsable. 7.3.8. 7.3.8.7.3.8. 7.3.8.- -- - Interfaces Interfaces Interfaces Interfaces El interfaz es el límite de comunicación de un sistema ERP. El interfaz de usuario se comento en el apartado de facilidad de uso mencionado anteriormente. Otro tipo de interfaces serán descritas a continuación. Se suele conectar el sistema ERP con otros sistemas o se usa para el intercambio de datos en general. El primero se conoce como Enterprise Application Integration (EAI) y usa interfaces de servidor estándar como CORBA (Common Object Request Broker Arquitecture), XML-RPC (XML-Remote Procedure Call) y SOAP (Standardized Object Access Protocol) para automatizar los procesos de negocio más allá de los límites del sistema. Pero también la integración a nivel de base de datos puede ser suficiente en especial para leer los datos únicos que no tiene se basa en la lógica de negocio. Como este tipo de integración es la única base de datos específica, no será evaluado aquí. El envío y recepción de mensajes de correo electrónico y el manejo de archivos adjuntos de correo electrónico son importantes para las relaciones de comunicación de un CRM y las notificaciones de usuarios. Por parte del cliente, adjuntar archivos a los datos ERP, como documentos CAD, recepción de imágenes escaneadas o imágenes del producto deberán ser soportadas. Criterios comparativos ERP 129 Otras interfaces a menudo utilizadas manualmente son la integración con office, la exportación e importación CSV e información general. Las interfaces locales para las autoridades públicas y los bancos se abordarán cuando tomen parte del sistema. En general, la proporciona el soporte contratado. 7.3.9. 7.3.9.7.3.9. 7.3.9.- -- - Independencia del sistema operativo. Independencia del sistema operativo. Independencia del sistema operativo. Independencia del sistema operativo. La independencia del sistema operativo permita ejecutar el sistema ERP en varias plataformas. Es una característica necesaria para el cliente, si los usuarios tienen diferentes sistemas operativos. 7.3.10. 7.3.10.7.3.10. 7.3.10.- -- - Independencia del sistema de bases de datos Independencia del sistema de bases de datos Independencia del sistema de bases de datos Independencia del sistema de bases de datos Las bases de datos están altamente influenciadas por la escalabilidad del sistema, o dicho de otra manera por la habilidad para poder hacerse más grande sin perder calidad en sus servicios. Algunos prefieren las bases de datos de software libre para los sistemas ERP de software libre. Existen situaciones contrapuestas entre la independencia de las bases de datos y las características de las mismas. Una alta independencia de las base de datos implica el uso mínimo de las características comunes proporcionadas por el soporte de bases de datos. Algunas características que se pierden por la independencia del sistema de bases de datos pueden ser proporcionadas a través de la aplicación o del servidor de aplicaciones. 7.3.11. 7.3.11.7.3.11. 7.3.11.- -- - Lenguaje de programación Lenguaje de programación Lenguaje de programación Lenguaje de programación ¿Qué es código abierto sin conocer la fuente del lenguaje? El lenguaje puede ser un criterio para aprovechar las posibilidades disponibles por el bajo nivel de personalización. Los lenguajes de programación de los sistemas ERP seleccionados son lenguajes de scripting de código abierto (Python, Perl) y Java. Python es conocido por tener una sintaxis fácilmente legible y concisa así como sus capacidades integradas de refactorización (Refactoring es la reorganización del código fuente para mejorar la coherencia interna y la claridad). Perl es ampliamente utilizado, pero requiere más disciplina de desarrollo para obtener un código más profesional. Java cuenta con el apoyo fuerte de la industria y dispone de muchas herramientas de ingeniería de software. El conteo de las líneas de código es un mal indicador de funcionalidad por las siguientes razones: los lenguajes de alto nivel de scripting necesitan menos líneas de código. La flexibilidad de los metadatos basados en el Criterios comparativos ERP 130 diseño también necesita menos líneas de código a parte de que los metadatos pueden ser definidos en el código o externamente. 7.4. 7.4.7.4. 7.4.- -- - Soporte Soporte Soporte Soporte 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 ayuda a implementar y mantener el sistema ERP open source. 7.4.1. 7.4.1.7.4.1. 7.4.1.- -- - Infraestructura de Soporte Infraestructura de Soporte Infraestructura de Soporte Infraestructura de Soporte El soporte fiable y responsable es muy importante. Puede ser de manera local u on-line. La mayoría de proyectos de ERP de sw libre resuelven los problemas relativos a los diferentes requisitos a nivel nacional a través de redes asociadas al proyecto. Un socio (partner) local puede proporcionar servicios de consultoría, soporte, módulos complementarios y requisitos a nivel nacional tales como normas de contabilidad, interfaces con autoridades públicas y bancos. A parte de lo anteriormente citado también poseen conocimientos específicos de la industria. Soporte on-line en los foros públicos, sin censura y las listas de correo también son importante, porque ofrece a los usuarios y los desarrolladores oportunidad de leer y discutir temas. 7.4.2. 7.4.2.7.4.2. 7.4.2.- -- - Formación Formación Formación 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. 7.4.3. 7.4.3.7.4.3. 7.4.3.- -- - Documentación Documentación Documentación Documentación Integridad, actualizaciones y documentación de desarrollo son completamente necesarias para el usuario. Muchos proyectos usan sistema de gestión de contenidos Wiki para la colaboración en la creación y mantenimiento de la documentación. 7.5. 7.5.7.5. 7.5.- -- - Continuidad Continuidad Continuidad 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, comentado en el libro (Adventages of using a flexible ERP Package), corre el riesgo de que éste nunca llegue a ponerse en práctica. Este problema lo Criterios comparativos ERP 131 podemos denominar como Independencia 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 el 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. El software libre reduce el riesgo de la inversión ya que al ser código abierto el usuario es capaz de mantenerlo, aunque 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 peligrosas de las personalizaciones de los sistemas ERP se necesita un software de diseños 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. Las compañías open source son muy dependientes de la comunidad de usuarios, ya que una pequeña parte de los usuarios están interesados en comprar servicios adicionales. Tanto las estrategias de venta como el blindaje de desarrolladores de la comunidad así como el frenado de las características de las versiones open source, junto con un fuerte enfoque en la venta de una versión comercial, puede perjudicar el crecimiento de la comunidad. Una pequeña comunidad a su vez dificulta la venta de servicios tales como documentación adicional, formación, consultoría y certificaciones. • La participación de la comunidad y el tamaño de la misma clasifican a los diferentes miembros de las comunidades on-line y los modelos de participación de la misma. Aplicado a los sistemas ERP open source existe 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, y 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 proyecto. Si el proyecto se aloja en Sourceforge, una plataforma ampliamente utilizada para proyectos open source, entonces podemos usar las estadísticas proporcionas como indicador. Para 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 Criterios comparativos ERP 132 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 proyecto hace que sean cuestionables. Algunas razones como por ejemplo que hay proyectos o bien que no usan los servicios que les ofrecen o bien los usan sólo en parte, otra razón sería que no mantienen la web Sourceforge, esto lo podemos explicar con el siguiente ejemplo, los desarrolladores cambian las versiones del sistema de CVS que ofrece Sourceforge a una nueva versión sin borrar los datos antiguos del CVS. • 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 proyecto. Un sistema que sea bueno y que tenga uso es complicado que desaparezca en la comunidad. 7.5.1. 7.5.1.7.5.1. 7.5.1.- -- - Estructura del proyecto Estructura del proyecto Estructura del proyecto Estructura del proyecto La evaluación del los proyectos son impulsados por empresas o comunidades. Que una empresa los impulse quiere decir que una empresa es la responsable del desarrollo, proporciona servicios y asegura a los socios soporte a nivel local. Una típica empresa impulsadora 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 “impulsadora” (community driven) significa que el desarrollo es cooperativo y no existe una única empresa responsable. 7.5.2. 7.5.2.7.5.2. 7.5.2.- -- - Actividad de la comunidad Actividad de la comunidad Actividad de la comunidad 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 utilizan el número de mensajes en foros y las listas de correo. A parte 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. 7.5.3. 7.5.3.7.5.3. 7.5.3.- -- - Transparencia Transparencia Transparencia 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 fiable plan de trabajo documentado ayuda a estimar el foco Criterios comparativos ERP 133 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 que 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. 7.5.4. 7.5.4.7.5.4. 7.5.4.- -- - Frecuencia de las actualizaciones Frecuencia de las actualizaciones Frecuencia de las actualizaciones 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. 7.5.5. 7.5.5.7.5.5. 7.5.5.- -- - Otros efectos acordados Otros efectos acordados Otros efectos acordados Otros efectos acordados Además de los acuerdos en el mismo proyecto, los posibles efectos secundarios pueden derivar del uso (por ejemplo comerciales) de componentes, tecnologías o dependencias en otros proyectos open source. La independencia del sistema operativo, de las bases de datos y del lenguaje Criterios comparativos ERP 134 programación, los cuales se comentaron en el apartado de flexibilidad citado anteriormente, son también criterios acordados. 7.6. 7.6.7.6. 7.6.- -- - Madu Madu Madu Madurez rezrez rez Introduce el Modelo de madurez de open source (Open Source Maturity Model) como un proceso general para la selección, evaluación e implementación de productos open source. Aquí madurez se utiliza en un contexto más estrecho y su significado se basa en la calidad del software. Partiendo de que la flexibilidad se basa en conceptos técnicos y en el diseño del software, la madurez nos dice lo bien y libre de errores que ha sido implementado y probado. 7.6.1. 7.6.1.7.6.1. 7.6.1.- -- - Estado del desarrollo Estado del desarrollo Estado del desarrollo Estado del desarrollo Algunos paquetes ERP de código abierto no están listos para la producción todavía. El concepto del estado de desarrollo de Sourceforge también es aplicado a los proyectos open source no alojados en Sourceforge. Pueden estar en el estado de planificación, alfa, beta o estables. Planificación implica que las especificaciones del software se han definido pero no esta disponible el programa ejecutable. La primera versión de un programa de ordenador se llama versión alfa o alfa release. Es probable que sea inestable e incompleta, pero útil para fines de demostración y como prototipo que se seguirá desarrollando. La versión beta o beta realease es una versión de una aplicación que está todavía en desarrollo, pero publicada para fines de comprobación o testeo. La funcionalidad no ha sido plenamente probada y pueden aparecer errores. Después de que una versión beta ha sido ampliamente probada y los errores importantes solucionados, el programa se convierte en una versión estable. Sólo entonces se admiten errores que no afecten a la funcionalidad. 7.6.2. 7.6.2.7.6.2. 7.6.2.- -- - Lugar de referencia Lugar de referencia Lugar de referencia Lugar de referencia La calidad de una versión estable puede ser probada por la implementación y el amplio testeo del software. Existe el riesgo que el sistema resulte ser inadecuado. Por lo tanto es mejor ver el sistema ERP en práctica y discutir las cuestiones de implementación y operaciones con el cliente que ya conoce el sistema. Los criterios relevantes son los lugares de referencia que aparecen en la página web del proyecto y la disponibilidad de casos de negocio documentados. Características ERPs analizados Características ERPs analizadosCaracterísticas ERPs analizados Características ERPs analizados en profundidad en profundidad en profundidad en profundidad Características ERPs analizados en profundidad 136 8.- Características ERPs analizados en profundidad 8.1. – Introducción 8.2. – Tablas comparativas 8.3. - Características ERPs analizados 8.3.1.- Abanq 8.3.1.1.- Flexibilidad 8.3.1.2.- Soporte 8.3.1.3.- Continuidad 8.3.1.4.- Madurez 8.3.2.- Adempiere 8.3.2.1.- Flexibilidad 8.3.2.2.- Soporte 8.3.2.3.- Continuidad 8.3.2.4.- Madurez 8.3.3.- Compiere 8.3.3.1.- Flexibilidad 8.3.3.2.- Soporte 8.3.3.3.- Continuidad 8.3.3.4.- Madurez 8.3.4.- Oasis erp 8.3.4.1.- Flexibilidad 8.3.4.2.- Soporte 8.3.4.3.- Continuidad 8.3.4.4.- Madurez 8.3.5.- Openbravo 8.3.5.1.- Flexibilidad 8.3.5.2.- Soporte 8.3.5.3.- Continuidad 8.3.5.4.- Madurez 8.3.6.- Openerp 8.3.6.1.- Flexibilidad 8.3.6.2.- Soporte 8.3.6.3.- Continuidad 8.3.6.4.- Madurez 8.3.7.- OpenXpertya 8.3.7.1.- Flexibilidad 8.3.7.2.- Soporte 8.3.7.3.- Continuidad 8.3.7.4.- Madurez 8.4. – Conclusiones a partir de los puntos anteriores 8.4.1. – Flexibilidad 8.4.2. – Soporte 8.4.3. – Continuidad Características ERPs analizados en profundidad 137 8.4.4. – Madurez 8.4.5. - Conclusión 8.5. – Instalación Openbravo 8.5.1. – Requisitos de intalación 8.5.2. – Entorno 8.5.2.1. - Componentes 8.5.2.2. – Módulos 8.6. - Instalación Abanq 8.6.1. – Requisitos de intalación 8.6.2. – Entorno 8.6.2.2. – Módulos 8.6.2.2. – Área de facturación 8.6.2.2. – Área financiera 8.7. – Conclusiones instalación Características ERPs analizados en profundidad 144 El motor de Abanq lee e interpreta los metadatos (información sobre tablas, formularios, scripts, etc.) que el Sistema Gestor de Base de Datos (SGDB) le proporciona. Estos metadatos se organizan en lo que llamamos módulos. Cada módulo agrupa un conjunto de metadatos que implementan una funcionalidad concreta (facturación, almacén, etc.). Flexibilidad de las actualizaciones Flexibilidad de las actualizacionesFlexibilidad de las actualizaciones Flexibilidad de las actualizaciones La flexibilidad de las actualizaciones en Abanq depende del grado de personalización propio que la aplicación tenga, es decir que a más personalización más complicada será la actualización a nuevas versiones. Mientras que un usuario sólo haga uso de los módulos de la rama oficial sin ninguna modificación, el problema de actualizar a nuevas versiones oficiales es mínimo ya que sólo deberá cargar estas versiones de los módulos conforme sean liberadas. Es decir, estos nuevos módulos están preparados para funcionar correctamente siempre y cuando sólo se usen versiones oficiales sin ninguna modificación y de las que se sabe en todo momento su comportamiento. La situación es algo más compleja si un usuario tiene versiones de módulos modificadas respecto a la rama oficial. Las nuevas versiones de la rama oficial sólo se instalan con total garantía cuando todas las versiones anteriores sean también oficiales. En el momento que tengamos alguna modificación estamos abriendo un nuevo camino, una nueva rama personalizada. En una rama personalizada las actualizaciones tienen que tener en cuenta las diferencias con la rama oficial, y se deberá crear una versión que respete esas diferencias que cubren ciertas necesidades específicas y que a la vez aproveche las mejoras de la rama oficial. A las diferencias a nivel de código entre la rama oficial y una rama personalizada se denominan parche. Esta simple expresión aritmética nos ofrece una idea representativa de los que es un parche: rama oficial + parche = rama personalizada. En la práctica un parche es un conjunto de textos con código de distintos lenguajes utilizados por AbanQ y que contiene la funcionalidad o funcionalidades específicas. La solución que adoptan, consiste en la detección de esos parches y tratar de resolver los conflictos que surgen con la nueva versión. Internacionalización InternacionalizaciónInternacionalización Internacionalización El grado de internacionalización mostrado por la aplicación Abanq es a nivel de idioma, reflejando su página web, una traducción completa de los Características ERPs analizados en profundidad 145 módulos en alemán, castellano y catalán, al 90% al inglés y en proceso a idiomas como el euskera y el portugués. Los requisitos legales a nivel nacional, especialmente en la contabilidad no han sido especificados. Los criterios anteriormente citados ayudarán en un futuro a la internacionalización a un alto nivel, así como a su expansión. Facilidad de uso Facilidad de usoFacilidad de uso Facilidad de uso En este apartado hay mucho que comentar ya que la aplicación, a pesar de su completitud y relativa complejidad es muy fácil de usar incluso para usuarios noveles o con pocos conocimientos de contabilidad. En cuanto a diseño la aplicación sigue un mismo patrón de diseño para todo, pero esto influye directamente en la funcionalidad, ya que los procesos usando el programa son siempre iguales, facilitando enormemente la tarea al usuario. La manera de moverse por los menús, de acceder a las opciones, de crear un dato (ya sea un cliente o un artículo) o de rellenar los campos son siempre iguales. Se trata de un sistema homogéneo. Además hay muchos detalles positivos que se pasan a comentar. Los iconos para realizar las acciones no solo son representativos, si no que a veces se agrupan por la misma tonalidad de color, así, se sabe que las acciones en “verde” son las relativas a clientes y las “moradas” a proveedores, por ejemplo. Rellenar formularios puede ser uno de los quebraderos de cabeza de los empleados si tienen que crear decenas o cientos de entradas. Para ello, como se ha explicado, existe una conexión entre módulos que facilita el rellenado de los campos, mostrando listados de opciones ya creadas anteriormente para el campo que se quiere rellenar. Pero además si el usuario quiere más rapidez a la hora de rellenar estos campos, y hacer dos o tres clicks le resulta incómodo, puede introducir directamente el número de registro, que seguramente ya conozca si un campo se repite mucho o trabaja mucho con él. Para más facilidad, si al desplegar la lista no hay ninguna entrada creada, está la opción de crear en ese instante ese nuevo dato mediante un nuevo formulario, por lo que todo está indexado. Además AbanQ en sus formularios incluye siempre la opción de almacenar el registro que se acaba de rellenar y pasar a crear otro nuevo del mismo tipo. Así, se abre un nuevo formulario directamente para empezar con la creación de una nueva entrada, lo que facilita la vida si se tienen que crear, por ejemplo, 100 clientes. Otras virtudes de usabilidad en los listados donde aparecen todas las entradas creadas (por ejemplo una lista de artículos), son la inclusión de un campo para realizar búsquedas, o mostrar datos utilizando un filtro. Otra opción útil que se incluye en la ventana de todos los módulos es la de saltar directamente a otro módulo instalado, lo que facilita la navegación por el programa. Características ERPs analizados en profundidad 146 Además para ciertos casos donde se necesitan datos creados para realizar acciones, la aplicación da la opción de trabajar con datos de prueba, lo que facilita la práctica con la aplicación sobre todo si la usamos por primera vez. Por ejemplo, se puede trabajar con una empresa de prueba. Arquitectura ArquitecturaArquitectura Arquitectura En la figura se observa el esquema general de la arquitectura Abanq. Vemos como todo se almacena en la base de datos y sólo el servidor puede acceder directamente a ella, sirviendo a los clientes los datos y los módulos de aplicación, y gestionando el control de acceso a los usuarios. Figura 8.1.- Arquitectura Abanq Estructura A3D Estructura A3DEstructura A3D Estructura A3D Clientes: Los clientes son las máquinas que se encuentran conectadas directamente al SGBD (sistema gestor de base de datos) pudiendo acceder a la base de datos. En cada terminal o máquina cliente se ejecuta el software que denominamos aplicación base. SGBD: El gestor de base de datos se encarga de almacenar y mantener dos tipos de información (y aquí está la clave): Datos: En esta zona de la base de datos se almacenan los datos concretos que la aplicación maneja y que tienen sentido para el usuario (datos de clientes, facturas, etc.). Son los datos "tradicionales". Módulos de metadatos: Los módulos contienen la información necesaria para implementar las aplicaciones de usuario: formularios, definiciones de tablas y campos, código de los scripts que realizan los procesos, formato y definición de los informes. Características ERPs analizados en profundidad 147 Los metadatos residen en la base de datos, pero previamente deben ser cargados desde el directorio en disco en el que han sido alojados tras su descarga. La estructura de directorios en los módulos presenta cuatro niveles: • Nivel 1. Directorio raíz (ejemplo: directorio modulos) • Nivel 2. Área (ejemplo: directorio facturacion) • Nivel 3. Módulo (ejemplo: directorio almacen) • Nivel 4. Metadatos (ejemplo: directorio tables) En el nivel 4 existen varios directorios, uno por cada tipo de metadatos: • tables. Definiciones de las tablas. Cada tabla se define en un archivo de extensión mtd • forms. Definiciones de los formularios. Cada formulario se define en un archivo de extensión ui • scripts. Definiciones de los scripts. Cada script se define en un archivo de extensión qs • queries. Definiciones de las consultas. Cada consulta se define en un archivo de extensión qry • reports. Definiciones de los informes. Cada informe se define en un archivo de extensión kut • translations. Listados de traducciones. Cada listado de traducciones para un determinado idioma se define en un archivo de extensión ts Seguridad SeguridadSeguridad Seguridad El módulo de control de acceso proporcionado para AbanQ permite establecer permisos sobre distintas partes de la aplicación dependiendo del usuario que accede. Este módulo sólo funciona a partir de la versión 2.0 de la aplicación base. El módulo permite definir usuarios y grupos de usuarios y establecer para ellos permisos de lectura, escritura o lectura-escritura sobre las tablas de datos y formularios del sistema hasta el nivel de campo, permitiendo controlar el acceso de cualquier usuario a cualquier parte de la aplicación. 8.3.1.2. 8.3.1.2.8.3.1.2. 8.3.1.2.- -- - Soporte Soporte Soporte Soporte Soporte de la infraestructura Soporte de la infraestructuraSoporte de la infraestructura Soporte de la infraestructura Hay un foro (http://abanq.org/laboratorio/minibb/index.php) para transmitir todo tipo de problemas, dudas o sugerencias, que además se divide en una zona para usuarios y otra para desarrolladores. También se Características ERPs analizados en profundidad 148 puede contactar vía formulario (http://abanq.org/infosial/contactar.php9) o con el webmaster http://abanq.org/infosial/webmaster.php. A través de su página cualquier usuario registrado puede realizar preguntas, resolver dudas de la aplicación, en el caso de que esa información sea más especializada, la opción es el contrato de paquetes de horas de soporte, proporcionando mayor calidad en las actividades de soporte, pero con el coste económico que conlleva. Formación FormaciónFormación Formación Al igual que el soporte anteriormente mencionado, en su página Web existen accesos a formación a distinto nivel, debiéndose poner en contacto, de manera que se acuerden las condiciones, ya sea de desplazamiento de uno o de otros. Otra opción es la de cursillos online, ambas opciones conllevan coste económico. Documentación DocumentaciónDocumentación Documentación Existe documentación a nivel de usuario y de programador, en mi opinión no es demasiado amplia y bastante costosa de entender, la cual cosa conlleva de una formación extra casi obligada. 8.3.1.3. 8.3.1.3.8.3.1.3. 8.3.1.3.- -- - Continuidad Continuidad Continuidad Continuidad Estructura del proyecto Estructura del proyectoEstructura del proyecto Estructura del proyecto Bajo la marca Abanq G2 se ha constituido el primer Grupo Empresarial para el Desarrollo del Open Source, S.A., que ha sido fundado por empresas españolas de software para la investigación, desarrollo y colaboración en proyectos informáticos relevantes para las Empresas y la Administración y que hasta ahora sólo estaban al alcance de grandes corporaciones. Inicialmente son cinco las empresas que forman Abanq G2: Calidae, Gestiweb, InfoSiAL, Isolix y KLO, aunque la estructura es flexible y está orientada a facilitar nuevas incorporaciones, siempre que se demuestren capacidades e implicación decidida en el Proyecto. Actividad de la comunidad Actividad de la comunidadActividad de la comunidad Actividad de la comunidad A través del foro alojado en su Web se deduce un flujo constante de información entre usuarios pertenecientes a la misma. Características ERPs analizados en profundidad 149 Frecuencia de las Actualizaciones Frecuencia de las ActualizacionesFrecuencia de las Actualizaciones Frecuencia de las Actualizaciones No existe suficiente información para comentar este punto ya que tanto en su página principal, así como en sourceforge, no queda claro este punto, la última versión data de 2008. Pero en su página ya existe la versión 2.3 para descargar, que data del mismo año. Tras la formación de Abanq G2 se espera una nueva versión. 8.3.1.4. 8.3.1.4.8.3.1.4. 8.3.1.4.- -- - Madurez Madurez Madurez Madurez Lugares de referencia Lugares de referenciaLugares de referencia Lugares de referencia Basicamente son estos: www.abanqg2.com http://www.abanq.org/ Características ERPs analizados en profundidad 150 8.3.2. 8.3.2.8.3.2. 8.3.2.- -- - ADempiere ADempiere ADempiere ADempiere Esta sección está basada en las características del sistema ERP de software libre ADempiere. Adempiere Sub-criterio Descripción FLEXIBILIDAD 1 Personalización ok 2 Flexibilidad de las Actualizaciones ok 3 Internacionalización Multiidoma 4 Facilidad de uso ok 5 Arquitectura 2 capas cliente/servidor previsión 3 capas 6 Escalabilidad ok 7 Seguridad ok 8 Interfaz CSV, OAGSIS, OFX 9 Independencia del S.O Unix, Windows, Linux y Mac OS X 10 Independencia de la Base de datos SQLJ 11 Lenguaje de Programación Java SOPORTE 1 Soporte de la infraestrucura ok 2 Formación ok 3 Documentación ok CONTINUIDAD 1 Estructura del proyecto Compañía + Comunidad 2 Actividad de la Comunidad ok 3 Transparencia ok 4 Frecuencia de Actualizaciones ok 5 Otras efectos acordados - MADUREZ 1 Estado del desarrollo ESTABLE 2 Lugares de referencia ok Características ERPs analizados en profundidad 151 8.3.2.1. 8.3.2.1.8.3.2.1. 8.3.2.1.- -- - Flexibilid Flexibilid Flexibilid Flexibilidad adad ad Personalización PersonalizaciónPersonalización Personalización Además de la posibilidad de personalizar las Interfaces de Usuario, Reportes y Extensiones, ADempiere proporciona capacidades de personalización adicionales: • Preferencias Default o elecciones preseleccionadas o Preferencias de Login: Organización, Lenguaje, Fecha de Transacciones e Impresora. o Preferencias definidas por el Usuario, tales como tipos de transacciones específicas. • Personalización de la Barra de Menú, permitiendo guardar cualquier entrada en la barra (Ventanas, Procesos, Reportes) como un acceso rápido. • La Terminología puede ser cambiada. Por ejemplo si los usuarios en lugar de Productos utilizan Ítems o Artículos, o a la Organización la denominan Sucursal, etc. • Los Textos de Ayuda pueden ser modificados y extendidos por el usuario para proporcionar sugerencias y ayudas específicas. Las personalizaciones son definibles a diferentes niveles: • Sistema o implementación • Ventana, si es apropiado (por Ej. para preferencias) • Cliente • Organización • Usuario Específico Los niveles más específicos tienen preponderancia sobre los más bajos. Los cambios efectuados a nivel del sistema pueden ser guardados y definirse como personalizaciones si se requieren reaplicar luego de la instalación. Las extensiones funcionales son implementadas utilizando la tecnología de "callout". Los clientes pueden proporcionar funcionalidad adicional en Java o inclusive funcionalidad nativa en C, por ejemplo para validaciones adicionales o alimentación de datos. Los callouts pueden ser invocados antes o después del ingreso de datos en cualquier campo. Adempiere asegura que los callouts no permitan la caída o corrupción del sistema. Flexibilidad de l Flexibilidad de lFlexibilidad de l Flexibilidad de las actualizaciones as actualizacionesas actualizaciones as actualizaciones Características ERPs analizados en profundidad 152 Además del diccionario interno de la aplicación, ADempiere tiene también la posibilidad de extender la aplicación utilizando Java Business API’s. A diferencia de otras aplicaciones, las extensiones de clientes son posibles en ambientes con datos centralizados y son preservadas durante las actualizaciones del producto a nuevas versiones. Internacionalización InternacionalizaciónInternacionalización Internacionalización Adempiere está traducido a los siguientes idiomas:Árabe, Bosnio, Brasileño, Portugués, Catalán, Chino (Simplificado), Inglés, Alemán, Indonesio, Italiano, Japonés, Rumano, Ruso, Español, Tailandés. A nivel de módulos de adecuación a la economía de cada país, están en proyecto o finalizados, a nivel español, existen reseñas del proyecto pero nada concluyente, el intento de contactar con las empresas españolas que en teoría llevan el proyecto, no ha dado fruto alguno. Facilidad de uso Facilidad de usoFacilidad de uso Facilidad de uso A causa del alto grado de personalización del ERP Adempiere, el interfaz de usuario puede ser diseñado con la información necesaria para cada tarea, es lo que llaman interfaz de usuario inteligente. Como resultado se obtiene una interfaz de usuario consistente, que permite navegar rápidamente en áreas de la aplicación que no son familiares. Este método también permite que el layout (esquema de distribución, lógico y ordenado de un sistema) de las pantallas pueda ser modificado o extendido y que se puedan generar nuevas pantallas, creadas por el administrador del sistema, sin necesidad de modificar el código; los usuario automáticamente ven las nuevas pantallas la próxima vez que ingresen a la aplicación. ADempiere proporciona un sistema de ayuda multinivel integrado y personalizable. Cada tarea, reporte y ventana, tiene información general, cada campo tiene un “tool-tip” (ventana de ayuda contextual) hint y un texto de ayuda. Si la ayuda no es suficiente, el usuario puede hacer un “zoom” desde la ventana de ayuda hacia el sistema de ayuda online de ADempiere, para obtener información actualizada, consejos y secciones de Preguntas Frecuentes (FAQ). Arquitectura ArquitecturaArquitectura Arquitectura ADempiere es una aplicación cliente-servidor escrita enteramente en Java, que soporta el procesamiento de grandes volúmenes de información y una interfaz gráfica de usuario con un alto grado de diseño. Características ERPs analizados en profundidad 153 Está prevista en un futuro la migración hacia una arquitectura de 3 capas. El servidor de aplicaciones está implementado en Java, con la tecnología J2EE, utilizando la infraestructura del servidor de aplicaciones JBoss. Este servidor puede estar corriendo de manera stand alone o en el mismo equipo que el servidor de la base de datos. Para la administración del servidor se utiliza JMX (Java Management Extensions). El acceso a la base de datos se realiza mediante el protocolo JDBC (Java Database Connectivity). Está planificado que futuros releases de ADempiere soporten otros servidores de aplicaciones que cumplan con las especificaciones de J2EE (por Ej. IBM Websphere, Oracle Application Server, etc.). Además del estándar HTTP, se utiliza el protocolo SSL para la implementación de la funcionalidad Web Store. Los componentes de la aplicación Cliente están escritos enteramente en Java, diseñados para utilizar las capacidades que brindan los PC’s actualmente. La aplicación Java o cliente Java Applet es la elección ideal para altos volúmenes de datos y proporciona una interfaz gráfica de usuario alta en diseño. Se comunica vía thin JDBC (Java Database Connectivity) con la base de datos y mediante RMI (Remote Method Invocation) con el servidor de aplicaciones. El cliente puede acceder a los servidores a través de Internet o de una Intranet. En aquellos casos donde la instalación o descarga de la aplicación no sea posible, es posible utilizar un cliente HTML. Este está implementado mediante Java Servlets y Java Server Pages almacenadas en Servidores de Servlet. Si bien este cliente proporciona mucha funcionalidad, es menor a la soportada por el cliente Java Applet. Seguridad SeguridadSeguridad Seguridad ADempiere proporciona una infraestructura de seguridad completa y flexible para cumplir con las necesidades del usuario, y soporta función, seguridad de datos, como así también auditoria. La función de seguridad está basada en Roles de Usuario, la cual controla el acceso a Ventanas, Reportes y Procesos. Por otro lado, la seguridad de los datos está basada en Cliente y Organización, y es mantenida a nivel del contexto de seguridad de la base de datos. Este es un nivel adicional de seguridad posterior al login normal de usuario de la base de datos. Antes de acceder a cualquier dato, el usuario debe identificarse mediante un store procedure con un nombre de usuario, contraseña, rol y opcionalmente la preferencia de lenguaje. Todas las contraseñas se almacenan de manera encriptada. Business Intelligence 256 Tradicionalmente, las herramientas de Business Intelligence se utilizaban en planificaciones estratégicas a medio y largo plazo: partiendo de lo que había sucedido, se utilizaba la información para poder planificar. En la actualidad, las herramientas de Business Intelligence se utilizan cada vez más para gestionar el día a día, el corto plazo: las tareas más operacionales. Ello implica que las cargas de la información sean mucho más frecuentes, llegando en algunos casos a lo que se ha denominado “ Real time ”, o tiempo real. En muchas organizaciones siguen teniendo un uso privilegiado las hojas de cálculo, destacando el líder del mercado Microsoft Excel. Las tendencias indican que se seguirán usando las hojas de cálculo, pero no como repositorios de información, sino tan sólo como herramientas de acceso y visualización de la información residente en los datawarehouses . Otra tendencia es la externalización del Business Intelligence : Aunque de una forma incipiente, comienzan a aparecer experiencias de externalización del Business Intelligence fuera de las organizaciones. El principal inhibidor de esta tendencia es que las organizaciones son reticentes a externalizar la información de la que disponen. Los movimientos en el mercado Los movimientos en el mercadoLos movimientos en el mercado Los movimientos en el mercado Dentro del mercado de las herramientas de Business Intelligence se están produciendo distintos movimientos: • Los fabricantes de soluciones ERP están comercializando sus propios productos (por ejemplo: Business Warehouse de SAP, o su solución de Business Intelligence para SAP Business One). • Los fabricantes de BI se están especializando en soluciones concretas, por ejemplo: Soluciones CPM (por ejemplo Cognos con Cognos Planning). • Los fabricantes de motores de BBDD tienen sus propias soluciones de Business Intelligence (por ejemplo: Oracle con sus productos y los de Siebel Analytics, y Microsoft con SQL 2005). • Disminución de los precios de algunas soluciones. • Aparición de las soluciones Open Source . • Futuras compras entre fabricantes. En el mercado de las Tecnologías de la Información y de la Comunicación siempre se debe estar atento a los cambios que se producen. Business Intelligence 257 Existen algunas consultoras independientes que evalúan continuamente la evolución de los productos: Gartner, Forrester, etc., a las que podemos dirigirnos cuando tengamos que decidir en qué herramienta invertir. 10.7. 10.7. 10.7. 10.7. – –– – Conclusiones Conclusiones Conclusiones Conclusiones En el apartado partimos de la definición teórica de Business Intelligence para poder mostrar la amplitud del término y a partir de ella ver sus posibilidades de uso en las organizaciones. Una vez descritos todos los componentes, les hemos propuesto distintas metodologías para que les ayuden en el desarrollo de los proyectos, y a continuación hemos propuesto los usos más habituales de Business Intelligence y las nuevas tendencias en este campo. En sus inicios, Business Intelligence se aplicaba en las organizaciones a nivel táctico, es decir: analizo, tomo la decisión y establezco las políticas a aplicar. La segunda ola de Business Intelligence subió al nivel de la estrategia, como una herramienta que ayuda a la planificación estratégica. Hoy hablamos de Business Intelligence operativa, que es la que está ligada a la toma de decisiones en el día a día, con el objetivo de ser más ágiles en dicho proceso. De las experiencias de los proyectos se desprenden distintos factores críticos de éxito: • La importancia de tener un patrocinador del proyecto, si es posible, al máximo nivel de responsabilidad o dirección de la organización. El patrocinio por su parte nos ayudará a conseguir proyectos de mayor alcance y más ligados con la estrategia de la organización, lo que nos facilitará probablemente un mayor retorno de la inversión y un mayor apoyo durante la ejecución de los mismos. • A lo largo del apartado hemos insistido mucho en la utilización de una metodología. Este aspecto es clave para conseguir el éxito en el proyecto. La improvisación no es una buena compañera de los proyectos, y menos de los de sistemas de información para la toma de decisiones. • El equipo multidisciplinario formado por miembros tanto del área de negocio como de la tecnológica. Compartir los proyectos facilita la comprensión de las distintas necesidades y mejora sin duda las relaciones entre ellos. • La participación de los usuarios en el proyecto es fundamental, ya que ellos serán los que consigan los éxitos con el uso de las soluciones de Business Intelligence . Es fundamental que se registren los éxitos Business Intelligence 258 obtenidos con el uso de las soluciones. El poder compartirlos nos asegurará la continuidad y los recursos necesarios para seguir avanzando. • La definición de unos objetivos alcanzables y alineados con los de la organización. Los mayores éxitos de las organizaciones que compiten mediante el uso de Business Intelligence se obtienen cuando somos capaces de aportar información sobre áreas estratégicas de la organización. Normalmente, estas áreas están relacionadas con los clientes: el nivel de servicio, tiempo del ciclo, optimización de costes, selección de personal, etc. • Debemos establecer un seguimiento del proyecto que nos permita evaluar su nivel de avance y de obtención de resultados. Cuando las organizaciones se acercan a la madurez en el uso de estas tecnologías dejan de plantearse proyectos individuales y los gestionan como una forma de competir. • La mayoría de las empresas que compiten con Business Intelligence no han ido invirtiendo de forma progresiva: estas inversiones, en la mayoría de los casos, se han generado por la aparición de nuevas necesidades y por el propio aprendizaje de las organizaciones. • La evaluación continua de los resultados del proyecto nos permite mostrar cuáles han sido los obtenidos: al comunicarlos podemos generar el interés en nuevas áreas de análisis, creando nuevos modelos interdepartamentales que sin duda mejoran los resultados de la organización. • El uso de las soluciones de Business Intelligence nos mostrará resultados que nos obligarán a tomar decisiones, por lo que es necesario que estemos preparados para ello. • La tecnología debe ser coherente con nuestra organización y nuestros usuarios. En conclusión lo deseable con la ayuda de Bussines Intelligence es conseguir organizaciones más eficientes, más eficaces y más competitivas, para que con ello puedan contribuir a la creación de puestos de trabajo y al desarrollo de una sociedad más humana, más sostenible, más respetuosa con el medio ambiente y más responsable socialmente. 259 Conclusiones ConclusionesConclusiones Conclusiones Conclusiones 260 1 11 11 11 1. .. .- -- - CONCLUSIONES CONCLUSIONES CONCLUSIONES CONCLUSIONES Tras el estudio de este proyecto es sencillo constatar la importancia del software libre en la actualidad, como una ciencia más, puesta en manos de la sociedad, para su estudio, adaptación e incluso mejora de la misma para el beneficio común, en una época tecnológica que algunas han vaticinado como de piratería, resurge el modelo de software libre, el modelo de comunidad, el modelo de bien común. El software libre como herramienta empresarial a todos los niveles, da oportunidad a las empresas de dotar de la tecnología software adecuada para el manejo de la información, de manera que podamos cubrir todas las áreas funcionales sin previo coste de licencias software. Las herramientas ERP de software libre no difieren de lo anteriormente citado, la descarga de paquetes ERPs completos para su posterior uso y modificación a todos los niveles, con el fin de adaptarla a cada empresa y no al contrario (que es lo que viene sucediendo con gran parte de herramientas de software propietario), adquiere mayor significación si consideramos la disminución del peligro del software obsoleto, que en este caso disminuye de manera drástica, debido a que somos poseedores de todas las herramientas necesarias para que esto no ocurra. La elección a partir de los criterios nombrados con anterioridad, nos ayuda a escoger, dependiendo de nuestras necesidades, de la herramienta que mejor se adapte a nuestra empresa, todo ello sin coste alguno de licencias. En contraposición, hay que ser conscientes de la sociedad actual en la que vivimos, maximizar el beneficio económico es la finalidad fundamental que una empresa de carácter privado tiene, en el tema que hemos analizado contiene similitudes constatables. De entre las herramientas ERPs de software libre que hemos analizado, es constatable que versiones renovadas y con multitud de nuevas funcionalidades pierden el concepto inicial de software libre, ya que es obligado el previo pago para su correspondiente uso, otros paquetes, siguen fieles al dogma del software libre y de comunidad, no adoptando la opción anteriormente citada. Tras el transcurso del proyecto mi credulidad acerca del software libre, de alguna forma a sido cambiante, en un principio la creencia de que cualquier empresa era capaz de soportar toda su infraestructura de sistemas, la veía como una realidad actual, es más, grandes empresas lo constatan, pero también es cierto que esas grandes empresas poseen departamentos de sistemas informáticos con un nivel y unos recursos que son complicados de ver en la sociedad española, independientemente del Conclusiones 261 beneficio que saquen con ello. Para una pyme es impensable un gasto “más allá de lo necesario” en un departamento de sistemas informáticos, con lo cual la dependencia con empresas relacionadas para gozar de un soporte adecuado, así como de una adecuación de la aplicación a su negocio, se hace fundamental. Es aquí donde comienzan las dudas, el software libre, es un concepto distinto del que muchos creen, si te regalan un coche, no significa que vayas a tener transporte toda tu vida, el software libre conlleva un coste, que a priori será menor que el de un software propietario. La elección de un software adecuado y teniendo en cuenta la importancia del mismo no es una decisión que se deba tomar a la ligera, tener la información adecuada es lo que he tratado de mostrar en este proyecto, qué empresas están detrás de cada ERP, que seguridad de continuidad tenemos, tras nuestra decisión de adoptar esa herramienta en particular, qué nos ofrece y que nos ofrecerá. Son factores tan importantes a tener en cuenta que pasarlos por alto nos podría llevar al abandono del proyecto con todo lo que conlleva. Con todo lo anterior la elección de un ERP adecuado es lograr una aplicación global que contiene o debiera contener toda la información de la empresa. La importancia del uso de la información de manera adecuada, así como mejora de los procesos de negocio, la mejora en la relación con los clientes y la representación de la información importante para la toma de decisiones adecuadas, son puntos tratados con anterioridad a tener muy en cuenta. 262 263 Anexo p Anexo pAnexo p Anexo paquetes ERP aquetes ERPaquetes ERP aquetes ERP Anexo paquetes ERP 264 12. 12. 12. 12. – –– – Anexo paquetes ERP Anexo paquetes ERP Anexo paquetes ERP Anexo paquetes ERP Abanq AbanqAbanq Abanq En este breve documento veremos el funcionamiento general de la aplicación en cuanto a módulos, áreas y formularios. Organización de los módulos Organización de los módulosOrganización de los módulos Organización de los módulos La configuración está estructurada en los siguientes elementos: • Áreas. Representan grandes agrupaciones funcionales (facturación, contabilidad, producción,...). • Módulos. Cada área, a su vez, está dividida en módulos, que cubren una determinada faceta del área a la que pertenecen (por ejemplo, en el área Facturación, los módulos tesorería, almacén...). • Acciones. Las acciones determinan las posibles operaciones que el usuario puede realizar en un determinado módulo (por ejemplo en el módulo almacén del área Facturación, están las acciones de gestión de artículos, gestión de stocks, etc.). Generalmente, accedemos a las acciones desde la ventana principal de cada módulo. Dependencias. Los módulos están integrados unos con otros. Por ejemplo, al usar el módulo facturación del área Facturación para dar de alta un pedido a cliente, podemos seleccionar dicho cliente de una lista que reside en el módulo principal del área de Facturación. Esta integración, necesaria para reaprovechar datos y funcionalidad existentes, implica que algunos módulos no pueden ser instalados sin haber instalado previamente aquellos de los que dependen. Abanq controla estas dependencias y avisa al usuario cuando alguna de ellas no se cumple. Modo general de funcionamiento Modo general de funcionamientoModo general de funcionamiento Modo general de funcionamiento Abanq muestra la información al usuario siguiendo un esquema maestro - detalle. La interfaz de usuario se estructura de la siguiente forma: Ventana de inicio Ventana de inicioVentana de inicio Ventana de inicio El la ventana de inicio por defecto de Abanq, y la que da acceso a las áreas. Cada área despliega sus módulos. También accedemos a las opciones generales del programa (Configuración). Anexo paquetes ERP 265 Ventana de inicio Ventana principal del módulo Ventana principal del móduloVentana principal del módulo Ventana principal del módulo Cada módulo tiene una ventana en la que se ofrece al usuario el conjunto de acciones disponibles. Estas acciones son accesibles desde la barra de menú o la barra de herramientas de la ventana. En cada una de las ventanas principales disponemos de un menú Módulos que permite cambiar a otras áreas y módulos. Anexo paquetes ERP 272 Arrancamos Abanq y seleccionamos el área Administración. Pulsamos el botón Cargar Módulo y seleccionamos el fichero *.mod correspondiente al módulo que deseamos cargar. Si todavía no existe el área correspondiente al módulo que estamos instalando, Abanq nos preguntará si queremos crearla en este momento. Contestamos Sí, e introducimos la descripción del área. Abanq cargará los ficheros que componen el módulo, mostrando su icono en el menú del área correspondiente. Con esto hemos terminado la instalación del módulo. Podemos probarlo pulsando sobre el icono. Desinstalación de módulos Desinstalación de módulosDesinstalación de módulos Desinstalación de módulos Seleccionamos el área Sistema y el módulo Administración. Pulsamos el botón Modulos y seleccionamos el fichero correspondiente al módulo que deseamos desinstalar, pulsamos el botón Eliminar Registro. La desinstalación de un módulo implica que la funcionalidad que dicho módulo proporciona deja de estar disponible para el usuario, aunque Anexo paquetes ERP 273 los datos (tanto de usuario como de definición del módulo) se mantienen en la base de datos. Recarga de nuevas versiones Recarga de nuevas versionesRecarga de nuevas versiones Recarga de nuevas versiones Seleccionamos el área Sistema y el módulo Administración. Pulsamos el botón Cargar Módulo y seleccionamos el fichero .mod correspondiente al módulo que deseamos recargar. Puesto que el modulo ya existe, debemos confirmar que deseamos recargar el módulo. A continuación Abanq cargará automáticamente todos aquellos ficheros que componen el módulo y tengan alguna modificación. Cuando cambiemos de módulo Abanq se reiniciará para cargar los nuevos datos. Por seguridad, es recomendable hacer un backup de los datos antes de recargar un módulo. Editar ficheros desde el módulo de sistema (para programadores) Editar ficheros desde el módulo de sistema (para programadores)Editar ficheros desde el módulo de sistema (para programadores) Editar ficheros desde el módulo de sistema (para programadores) Cuando cargamos un módulo desde disco utilizando el área de sistema, todos los ficheros del módulo son almacenados en la base de datos. En el área de sistema, la acción Módulos permite gestionar estos ficheros residentes en la base de datos. Al abrir un módulo de la lista, la ventana resultante nos mostrará un listado de los ficheros que componen dicho módulo. Si abrimos uno de ellos, nos aparecerá la un formulario. El botón Editar fichero va a lanzar la aplicación adecuada para editar el archivo según su extensión: si se trata de una tabla abrirá un editor de textos, por ejemplo. Procedim ProcedimProcedim Procedimiento para realizar modificaciones (para programadores) iento para realizar modificaciones (para programadores)iento para realizar modificaciones (para programadores) iento para realizar modificaciones (para programadores) Hemos visto cómo Abanq incorpora varios editores que son accesibles desde el módulo de sistema para modificar los ficheros contenidos en la base de datos. Dependiendo del tipo de fichero, Abanq abrirá el editor adecuado. Este sistema es útil a la hora de mostrar la flexibilidad y facilidad de modificación del programa, o para realizar pequeños cambios sobre la marcha. Sin embargo, a la hora de realizar modificaciones más serias, o de entrar en un desarrollo real, el procedimiento recomendado es el siguiente: 1. Abrir directamente los ficheros a modificar en el directorio correspondiente y con el editor adecuado: las tablas, scripts y consultas en un editor de texto, los formularios con QT Designer, cuyo ejecutable es designer, instalado en el mismo directorio que el ejecutable de Abanq. Anexo paquetes ERP 274 2. Realizar las modificaciones oportunas 3. Volver a Abanq y recargar el módulo 4. Probar las modificaciones realizadas 5. Repetir los pasos 2 , 3 y 4 hasta finalizar las modificaciones Volcado a disco de los módulos Volcado a disco de los módulosVolcado a disco de los módulos Volcado a disco de los módulos Según hemos visto, una vez cargado un módulo, éste pasa a la base datos para ser operativo. Es importante recordar que aunque la estructura de ficheros de los módulos reside en disco, es de la base de datos de donde Abanq toma los módulos previamente cargados. Abanq integra varias herramientas para editar los módulos, tales como un procesador de textos. Para usar éstas herramientas integradas debemos abrir uno de los ficheros que integran un módulo desde el área de sistema. No obstante, si vamos a realizar modificaciones importantes en los módulos, resulta más eficiente trabajar sobre los ficheros de los módulos en disco y, una vez modificados, recargarlos a la base de datos desde Abanq. Si, por ejemplo, deseamos insertar nuevos campos en una tabla, podemos abrir el archivo .mtd correspondiente dentro del directorio tables del módulo correspondiente con nuestro editor de texto favorito. Una vez modificado el fichero para insertar los nuevos campos, recargaremos el módulo tal como hemos visto en apartados anteriores. Es importante notar que si ya hemos realizado cambios desde el área de sistema, estos cambios residen en la base de datos pero no han sido trasladados a los ficheros en disco, por tanto si recargamos un módulo desde el disco podemos perder los cambios realizados. Para evitar esto existe la posibilidad de volcar a disco un módulo. Para ello abriremos, dentro del área de sistema y la acción módulos, el módulo que deseamos volcar. Pulsando el botón indicado en la figura se creará una copia en disco de los ficheros residentes en la base de datos. Anexo paquetes ERP 275 Introducción a la estructura de Abanq Introducción a la estructura de AbanqIntroducción a la estructura de Abanq Introducción a la estructura de Abanq En este breve artículo vamos a tratar de clarificar la estructura de Abanq, paso previo muy importante antes de comenzar la programación y personalización de los módulos. Arquitectura del Sistema Arquitectura del SistemaArquitectura del Sistema Arquitectura del Sistema En la figura se observa el esquema general de la arquitectura Abanq. Vemos cómo todo se almacena en la base de datos y sólo el servidor puede acceder directamente a ella, sirviendo a los clientes los datos y los módulos de aplicación, y gestionando el control de acceso a los usuarios. Estructura A3D Clientes: Los clientes son las máquinas que se encuentran conectadas directamente al SGBD (sistema gestor de base de datos) pudiendo acceder a la base de datos. En cada terminal o máquina cliente se ejecuta el software que denominamos aplicación base. SGBD: El gestor de base de datos se encarga de almacenar y mantener dos tipos de información (y aquí está la clave): Anexo paquetes ERP 276 Datos: En esta zona de la base de datos se almacenan los datos concretos que la aplicación maneja y que tienen sentido para el usuario (datos de clientes, facturas, etc.) . Son los datos "tradicionales". Módulos de metadatos: Los módulos contienen la información necesaria para implementar las aplicaciones de usuario: formularios, definiciones de tablas y campos, código de los scripts que realizan los procesos, formato y definición de los informes. Los metadatos residen en la base de datos, pero previamente deben ser cargados desde el directorio en disco en el que han sido alojados tras su descarga. La estructura de directorios en los módulos presenta cuatro niveles: • Nivel 1. Directorio raíz (ejemplo: directorio modulos) • Nivel 2. Área (ejemplo: directorio facturacion) • Nivel 3. Módulo (ejemplo: directorio almacen) • Nivel 4. Metadatos (ejemplo: directorio tables) En el nivel 4 tendremos varios directorios, uno por cada tipo de metadatos: • tables. Definiciones de las tablas. Cada tabla se define en un archivo de extensión mtd • forms. Definiciones de los formularios. Cada formulario se define en un archivo de extensión ui • scripts. Definiciones de los scripts. Cada script se define en un archivo de extensión qs • queries. Definiciones de las consultas. Cada consulta se define en un archivo de extensión qry • reports. Definiciones de los informes. Cada informe se define en un archivo de extensión kut • translations. Listados de traducciones. Cada listado de traducciones para un determinado idioma se define en un archivo de extensión ts Comparando Abanq con el sistema de navegación Web Comparando Abanq con el sistema de navegación WebComparando Abanq con el sistema de navegación Web Comparando Abanq con el sistema de navegación Web Desde el punto de vista de un programador o usuario avanzado, el SGBD funciona como un servidor de páginas web, mientras que la aplicación base hace las veces de un navegador. La aplicación base no es más que un intérprete de los datos que recibe del SGBD. Cuando la aplicación base se conecta al SGBD, descarga del mismo tanto los datos como los metadatos. En Abanq los formularios y la funcionalidad residen en el servidor de la base de datos, no en la aplicación base, al igual que las páginas web no residen en el navegador. Siguiendo con la analogía web, podemos comparar los scripts de Abanq con scripts de Javascript que son descargados al navegador y Anexo paquetes ERP 277 ejecutados en el ordenador del internauta; los formularios podrían ser tablas o formularios HTML, también aparecen en el navegador pero proceden así mismo del servidor. Sabemos que nuestro navegador puede conectarse a un número ilimitado de sitios web; igualmente la aplicación base de Abanq puede escoger la base de datos a la que se conecta en el momento del arranque. Sabemos también que un navegador web depende del sistema operativo sobre el que se instala: Mozilla Firefox para Windows o Linux, Safari para MacOsX, etc. Sin embargo cualquiera de estos navegadores puede conectarse a Google.com De igual modo, varias aplicaciones base Abanq para distintas plataformas pueden acceder a una misma base de datos central y no sólo compartir los datos, también los informes, formularios y funcionalidades. Cuando se requiere una actualización, basta con actualizar una vez en la base de datos. Cuando una aplicación base cliente se conecte a la misma, automáticamente aparecerán las últimas tablas, informes o scripts cargados. ¿Cómo es posible esta portabilidad? la respuesta es de nuevo análoga al sistema web: la aplicación base recibe los metadatos en formato de texto plano -igual que el HTML o el código javascripty los interpreta en tiempo real. Anexo paquetes ERP 278 Tutorial. Programación en Abanq (I). Primer contacto Tutorial. Programación en Abanq (I). Primer contactoTutorial. Programación en Abanq (I). Primer contacto Tutorial. Programación en Abanq (I). Primer contacto Este es el primero de una serie de tutoriales orientados a programadores y usuarios avanzados acerca de programación sobre Abanq. En este tutorial veremos cómo realizar una personalización básica y muy sencilla, pero que nos va a dar una idea de la flexibilidad de la aplicación y la facilidad con que se pueden realizar cambios sobre la estructura de los datos y el aspecto de los formularios. Requerimientos Antes de comenzar a trabajar: • Descargar e instalar la aplicación base de Abanq (recomendamos la versión más reciente) instalada • Descargar los módulos públicos. Para este tutorial bastarán los módulos del área de Facturación • Arrancar Abanq con una nueva base de datos y cargar los módulos Algunos conceptos previos: el área de Sistema Algunos conceptos previos: el área de SistemaAlgunos conceptos previos: el área de Sistema Algunos conceptos previos: el área de Sistema Abanq no es sólo un software de gestión, incluye además un entorno de desarrollo que permite realizar cambios y personalizaciones desde lo más básico a lo más avanzado. Desde el área de sistema no sólo podemos cargar los módulos, también podemos modificar los ficheros de tablas, formularios, informes, etc que forman parte de un módulo. Para ello abriremos el módulo de Administración dentro del área de sistema. Pulsamos en el menú Principal -> Módulos. Veremos un listado de lo módulos instalados. Si abrimos, por ejemplo, el módulo flfactppal (principal de facturación) accedemos al listado de ficheros. Algunos ejemplos: clientes.mtd es la tabla de clientes; clientes.ui es el formulario de clientes, etc. Los principales tipos de ficheros que maneja Abanq son: • tablas (extensión mtd) • formularios (extensión ui) • scripts (extensión qs) • plantillas de informes (extensión kut) • consultas sql para informes (extensión qry) Desde el listado de ficheros de un módulo podemos abrir un fichero para ver su contenido (siempre textual). Si pulsamos el botón Editar fichero, Abanq reconoce automáticamente el tipo de fichero y abre el editor adecuado. Anexo paquetes ERP 279 Algunos ejemplos: para las tablas se abrirá un editor de texto, para los formulario el editor de formularios QDesigner. Todas estas herramientas son incorporadas durante la instalación de Abanq. Cambios básicos en tablas y formularios Cambios básicos en tablas y formulariosCambios básicos en tablas y formularios Cambios básicos en tablas y formularios Vamos a utilizar las herramientas que incorpora Abanq para realizar algunos cambios sencillos en tablas y formularios de los módulos previamente cargados 1. Cambio de propiedades de un campo Cambio de alias. El alias de un campo es el nombre que aparece en los formularios y las tablas maestras. Para los almacenes vamos a modificar el alias del campo ("Código") cambiándolo por "Código de Almacén". En primer lugar abrimos el módulo almacén en el área de facturación. En el menú Almacén -> Almacenes mostramos el listado de almacenes de nuestra base de datos. Podemos ver que el primer campo tiene el alias Código. Los alias de los datos se especifican en las tablas. Desde el módulo de sistema: administración, abrimos el módulo flfactalma (almacén), y a continuación la tabla Almacenes (almacenes.mtd). En el campo codalmacen cambiamos la propiedad alias. Anexo paquetes ERP 280 Nuevo alias de un campo Aceptamos todos los formularios. Podemos verificar el cambio abriendo de nuevo el formulario de almacenes y comprobando el alias nuevo. 2. Cambio de la longitud máxima de un campo. Para las familias de artículos, el campo Código tiene una longitud máxima de 4 caracteres. Vamos a ampliar esta longitud hasta 6 caracteres. Dentro del módulo Almacén abrimos la tabla Familias (familias.mtd) y en el campo codigo cambiamos la propiedad lenght de 4 a 6: Anexo paquetes ERP 281 Nueva longitud máxima de un campo Podemos verificar el cambio abriendo el formulario de familias y comprobando que efectivamente el código admite ahora hasta 6 caracteres. 3. Cambios en el diseño de los formularios A la hora de trabajar con formularios vamos a utilizar la herramienta QT Designer. Tal como vimos, cuando editamos un fichero con extensión .ui en el módulo de sistema, el editor que aparece es QT Designer. Algunos aspectos importantes acerca de QT Designer: • Los componentes de un formulario pueden cambiarse de posición pulsando sobre ellos con el ratón y arrastrando • Los componentes pueden agruparse en layouts, utilizando los botones correspondientes (menú Window / Toolbars / Layout) Anexo paquetes ERP 288 Modificando el formulario de países en QT Designer Anexo paquetes ERP 289 Tutorial. Programación en Abanq (II). Acciones En el capítulo anterior de esta serie de artículos sobre programación en Abanq vimos cómo realizar pequeñas modificaciones sobre módulos ya existentes. Básicamente eran modificaciones sobre tablas y formularios en las que añadíamos campos o modificábamos sus propiedades. En el presente artículo describiremos la forma de realizar lo que Abanq denomina acciones completas. Esto quiere decir que aprenderemos a crear nuestras propias tablas y formularios, y a relacionarlos con otros elementos ya existentes. Además, dotaremos a nuestros formularios de funcionalidades añadidas mediante la programación de scripts, veremos la estructura del lenguaje QSA y usaremos las clases más importantes que Abanq pone a disposición de los programadores. Para terminar, confeccionaremos un informe sencillo para obtener un resumen bien presentado de los datos contenidos en las nuevas tablas. Antes de comenzar Antes de comenzarAntes de comenzar Antes de comenzar Realizaremos todos los ejemplos prácticos sobre el módulo Principal del área Facturación. Por ello es necesario acceder a una base de datos con este módulo cargado, tal y como hicimos en el artículo anterior. Si queremos disponer de una base de datos nueva para realizar estos ejemplos, basta con especificar el nuevo nombre de base de datos al arrancar Abanq, y cargar a continuación el módulo Principal de Facturación. Las acciones en Abanq Las acciones en AbanqLas acciones en Abanq Las acciones en Abanq Como vimos en el artículo anterior, el motor de Abanq lee e interpreta los metadatos (información sobre tablas, formularios, scripts, etc.) que el Sistema Gestor de Base de Datos (SGDB) le proporciona. Estos metadatos se organizan en lo que llamamos módulos. Cada módulo agrupa un conjunto de metadatos que implementan una funcionalidad concreta (facturación, almacén, etc.). Vamos a ver ahora la estructura interna de estos módulos. El fichero de metadatos que define esta estructura es el fichero de acciones, y su nombre es id_modulo.xml, donde id_modulo es el identificador que cada módulo t¡ene asignado en la tabla Módulos del módulo de Administración. Tomaremos como ejemplo el módulo Principal del área de Facturación. Su código es flfactppal, por tanto el fichero de acciones será flfactppal.xml. Lo visualizaremos de la forma ya descrita en el artículo anterior (Área de Sistema -> Módulo de Administración -> Módulos -> Anexo paquetes ERP 290 Editar flfactppal -> Seleccionar flfactppal.xml -> Ver registro). Aparecerá una ventana similar a la de la figura siguiente: Fichero de acciones flfactppal.xml Vemos que el fichero de acciones está compuesto por nodos <action>. Cada uno de estos nodos define una acción. Una acción es una unidad funcional concreta, que agrupa una serie de elementos necesarios para su correcto funcionamiento. Cada acción puede contener los nombres de una tabla, un formulario maestro, un formulario de edición, un script de formulario maestro y un script de formulario edición. Anexo paquetes ERP 291 Por ejemplo, la acción clientes agrupa las funcionalidades de la gestión de clientes: la tabla donde se almacenan sus datos, los formularios utilizados para acceder a dichos datos, los scripts que gestionan los formularios, etc. Las etiquetas que conforman cada acción son: • <name> Nombre de la acción. • <alias> Alias o título de la acción • <description> Descripción de la funcionalidad acción • <table> Nombre de la tabla asociada a la acción. • <form> Nombre del formulario maestro asociado a la accion. • <formrecord> Nombre del formulario de edición asociado a la acción. • <scriptform> Nombre del script asociado al formulario maestro. • <scriptformrecord> Nombre del script asociado al formulario edición. Veremos qué significa cada una de estas etiquetas a medida que progresemos en el desarrollo de nuestro ejemplo. Creando nuestra acción Vamos a suponer que nos es necesario llevar un control de los empleados de nuestra empresa. Para ello es necesario recoger los datos personales de cada uno de ellos. Cada empleado está asociado a un departamento de la empresa, y queremos poder emitir informes con un listado de los empleados de alta agrupados por departamento. Para realizar esta ampliación, el primer paso será crear la acción empleados (la acción departamentos ya existe en el módulo principal). Editaremos el fichero de acciones flfactppal.xml, añadiendo un nuevo nodo <action> tal y como aparece en la figura siguiente (recuerda que para editar el fichero debes pulsar Editar Registro y seguidamente Editar Fichero). Anexo paquetes ERP 292 Acción empleados en flfactppal.xml En la nueva acción indicamos que la tabla de empleados debe definirse en el fichero empleados.mtd, y que los formularios maestro y de edición (veremos qué significan estos términos más adelante) son i_master.ui y empleados.ui. Por ahora no indicaremos los nombres de los scripts. Una vez guardados los cambios (Aceptar -> Aceptar cambios del fichero -> Aceptar cambios del módulo) ya tenemos nuestra acción creada. Para terminar este apartado, vamos a crear un acceso desde la ventana principal del módulo de Facturación, de manera que podamos acceder a la gestión de empleados desde una opción de menú o desde un botón de la barra de herramientas. Las ventanas principales de cada módulo son formularios cuyo nombre sigue el esquema id_modulo.ui. En nuestro caso, deberemos editar el formulario flfactppal.ui. Una vez abierto el formulario mediante QtDesigner, incluiremos una nueva opción Empleados en el menú Tablas Generales. Anexo paquetes ERP 293 Menú Tablas Generales de flfactppal.ui Al crear esta nueva opción y pulsar Intro hemos creado una nueva acción en la ventana principal del módulo. Para editar esta acción debemos abrir el editor de acciones (opción de menú Window -> Views -> Action Editor). Vemos que se ha creado una acción cuyo nombre por defecto es tablas_generalesEmpleadosAction. Nueva acción creada en el Action Editor Cambiaremos este nombre y el resto de propiedades de la acción en la ventana de propiedades (Property Editor) como muestra la figura a continuación. Anexo paquetes ERP 294 Property Editor de QtDesigner Como podemos ver, hemos añadido un icono y especificado las teclas de acceso rápido a la acción. Para incluir un botón en la barra de herramientas arrastraremos el icono desde el Action Editor hasta la posición de la barra en la que deseemos ubicar el botón. Cada acción de la ventana principal del módulo debe corresponderse con una acción del fichero de acciones. Esta correspondencia se establece haciendo coincidir la propiedad name de la acción de la ventana con la etiqueta <name> del correspondiente nodo action del fichero de acciones. En nuestro caso este valor es empleados. Nos falta por último determinar qué sucederá cuando se seleccione la acción empleados en la ventana principal del módulo. Lo que haremos será abrir el formulario por defecto asociado a la acción. Para ello, en el Action Editor, seleccionamos la acción empleados y pulsamos el botón de conexiones: En la ventana View and Edit Connections nos aparece la lista de conexiones establecidas. La última entrada de la lista nos propone conectar la acción empleados con el objeto FLWidgetApplication. Como veremos más adelante, es muy común en la arquitectura de Abanq establecer conexiones entre objetos. Estas conexiones determinan que Anexo paquetes ERP 295 cuando un objeto -el emisorenvíe una determinada señal, otro objeto -el receptorejecutará un determinado método o slot. En nuestro caso, deseamos que cuando el objeto acción empleados se active (emita la señal activated), el objeto ventana principal de la aplicación Abanq (FLWidgetApplication) muestre el formulario por defecto de la acción (slot openDefaultForm). La conexión debe quedar por tanto tal y como describe la figura siguiente. Ventana de conexiones Una vez establecida la conexión pulsamos Ok y guardamos los cambios en flfactppal.ui. Ya podemos probar nuestra acción. Si accedemos al módulo Principal del área de Facturación y pulsamos el botón o la opción de menú Empleados, Abanq nos mostrará una ventana como la de la figura siguiente. Anexo paquetes ERP 296 Formulario de la acción empleados El mensaje 'No hay metadatos' hace referencia a que no hemos definido todavía la tabla empleados. En el siguiente punto veremos cómo hacer esto. Creando las tablas Creando las tablasCreando las tablas Creando las tablas Las tablas se definen dentro del directorio tables de los módulos, y tienen la extensión mtd. El nombre del fichero de la tabla, según nuestra nomenclatura, debe ser empleados.mtd. Insertamos un registro en el módulo, igual que hicimos con la creación del fichero de acciones, para la nueva tabla con el nombre anterior y el contenido siguiente: <!DOCTYPE TMD> <TMD> <name>empleados</name> <alias>QT_TRANSLATE_NOOP("MetaData","Empleados")</alias> <field> <name>codempleado</name> <alias>QT_TRANSLATE_NOOP("MetaData","Código")</alias> Anexo paquetes ERP 297 <null>false</null> <pk>true</pk> <type>string</type> <length>18</length> </field> <field> <name>coddepartamento</name> <alias>QT_TRANSLATE_NOOP("MetaData","Departamento")</alias> <null>false</null> <pk>false</pk> <type>string</type> <length>6</length> <relation> <table>departamentos</table> <field>coddepartamento</field> <card>M1</card> </relation> </field> <field> <name>nombrecompleto</name> <alias>QT_TRANSLATE_NOOP("MetaData","Nombre Completo")</alias> Anexo paquetes ERP 304 7: fdbDeBaja debaja 8: fdbSueldoBruto sueldobruto 9: fdbImpuestos impuestos 10: fdbSueldoNeto sueldoneto 11: fdbCausaBaja causabaja Hemos optado por establecer los nombres de los controles como fdb + NombreCampo. Aunque la propiedad name puede tomar cualquier valor, en este ejemplo es recomendable mantener los de la tabla anterior, para que los scripts que crearemos a continuación no tengan que ser retocados. En el campo 5 vamos a mostrar el nombre del departamento al que pertenece el empleado. Como este campo no pertenece a la tabla de empleados sino a la de departamentos, debemos establecer el resto de propiedades tal y como ya describimos en el artículo anterior. Una vez guardado el formulario ya podemos probarlo. Si abrimos la acción empleados aparecerá el fomulario maestro (i_master.ui). Si pulsamos ahora sobre el botón Insertar Registro, se abrirá nuestro formulario empleados.ui con el aspecto de la siguiente figura. Formulario de edición de empleados Anexo paquetes ERP 305 Podemos apreciar cómo dependiendo del tipo de campo, el control FLFieldDB correspondiente toma el aspecto adecuado para mostrar su valor. Llegados a este punto ya podriamos comenzar a trabajar con esta ventana. Los botones de aceptar y cancelar, así como las validaciones de datos de cada campo están plenamente operativos, de forma que si establecemos todos los campos requeridos (marcados como <null>false</null> en empleados.mtd) y pulsamos aceptar habremos creado nuestro primer empleado. Creando los scripts Creando los scriptsCreando los scripts Creando los scripts Vamos a dotar a nuestros formularios de una mayor funcionalidad asociándoles un script. No vamos a hacer una descripción demasiado formal del lenguaje QSA usado en Abanq, simplemente diremos que es muy similar a JavaScript e incluiremos comentarios en el código de los ejemplos que aclaren su funcionamiento. Algo que sí es importante recalcar es que, al margen de las clases y funciones que QSA ofrece al programador de scripts, el motor de Abanq también publica una serie de clases que nos permiten acceder a ciertos objetos internos del motor. Como veremos, esto da una gran potencia a los scripts, ya que permite hacer muchas operaciones que de otra manera sólo podrían conseguirse recompilando el código C++ del motor. Podemos consultar la documentación de QSA en http://doc.trolltech.com/qsa-1.2/index.html, y la de la interfaz de objetos de Abanq en el apartado de documentación de esta web. Lo primero será añadir las referencias a los scripts en el correspondiente nodo <action> del fichero de acciones. Anexo paquetes ERP 306 Añadiendo las referencias a los scripts en la acción empleados Hemos asociado al formulario maestro el script masterempleados.qs, y al formulario de edición el script empleados.qs. Crearemos primero el script asociado al formulario de edición, empleados.qs. A continuación mostramos el código completo del scrip que contiene algunas de las principales funciones que son llamadas automáticamente por el motor de Abanq en ciertos momentos de la ejecución del formulario. El sistema de clases y herencias escapa al ámbito de este tutorial y se verá con posterioridad. /********************************************************************** ***** empleados.qs - description ------------------- begin : lun jul 1 2007 copyright : (C) 2007 by InfoSiAL S.L. email : [email protected] ********************************************************************** *****/ /********************************************************************** ***** Anexo paquetes ERP 307 * * * This program is free software; you can redistribute it and/or modify * * it under the terms of the GNU General Public License as published by * * the Free Software Foundation; either version 2 of the License, or * * (at your option) any later version. * * * ********************************************************************** *****/ /** @file */ /** @class_declaration interna */ //////////////////////////////////////////////////////////////////////////// //// DECLARACION /////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////// //// INTERNA ///////////////////////////////////////////////////// class interna { var ctx:Object; function interna( context ) { this.ctx = context; } function init() { this.ctx.interna_init(); } function validateForm() { return this.ctx.interna_validateForm(); } function calculateField(fN:String):String { return this.ctx.interna_calculateField(fN); } } //// INTERNA ///////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////// /** @class_declaration oficial */ Anexo paquetes ERP 308 ////////////////////////////////////////////////////////////////// //// OFICIAL ///////////////////////////////////////////////////// class oficial extends interna { function oficial( context ) { interna( context ); } function bufferChanged(fN:String) { return this.ctx.oficial_bufferChanged(fN); } } //// OFICIAL ///////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////// /** @class_declaration head */ ///////////////////////////////////////////////////////////////// //// DESARROLLO ///////////////////////////////////////////////// class head extends oficial { function head( context ) { oficial ( context ); } } //// DESARROLLO ///////////////////////////////////////////////// ///////////////////////////////////////////////////////////////// /** @class_declaration ifaceCtx */ ///////////////////////////////////////////////////////////////// //// INTERFACE ///////////////////////////////////////////////// class ifaceCtx extends head { function ifaceCtx( context ) { head( context ); } } const iface = new ifaceCtx( this ); Anexo paquetes ERP 309 //// INTERFACE ///////////////////////////////////////////////// ///////////////////////////////////////////////////////////////// /** @class_definition interna */ //////////////////////////////////////////////////////////////////////////// //// DEFINICION //////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////// //// INTERNA ///////////////////////////////////////////////////// /* Función que se llama al iniciar el formulario Conecta la señal bufferchanged (cambio en el buffer,cambio en un campo) con el slot o función bufferChanged Si se la llama en modo alta inhabilitará el campo 'Causa de la baja' */ function interna_init() { var cursor:FLSqlCursor = this.cursor(); // Objeto FLSqlCursor asociado al formulario connect(this.cursor(), "bufferChanged(QString)", this, "iface.bufferChanged"); if (cursor.modeAccess() == cursor.Insert) this.child("fdbCausaBaja").setDisabled(true); } /* Función que calcula el valor de un campo. En este caso el sueldo neto cuando a partir del bruto y los impuestos fN: Nombre del campo a calcular Resultado: Valor del campo Anexo paquetes ERP 310 */ function interna_calculateField(fN) { var cursor:FLSqlCursor = this.cursor(); // Objeto FLSqlCursor asociado al formulario var valor:String = ""; switch(fN) { // El sueldo neto será el sueldo bruto tras descontarle los impuestos case "sueldoneto": var sueldoBruto = parseFloat(cursor.valueBuffer("sueldobruto")); var impuestos = parseFloat(cursor.valueBuffer("impuestos")); valor = sueldoBruto * (100 - impuestos) / 100; break; } return valor; } /* Función que se llama al pulsar el botón aceptar y que decide si los datos del formulario son válidos. Si los datos no son válidos, los datos no se guardarán y el formulario de edición no se cerrará. Resultado: true si los datos son válidos, false en caso contrario */ function validateForm() { Anexo paquetes ERP 311 var cursor = this.cursor(); var util:FLUtil = new FLUtil(); // La fecha de alta no puede superar la fecha actual var hoy = new Date(); var fechaAlta = cursor.valueBuffer("fechaalta"); if (util.daysTo(fechaAlta, hoy) < 0) { MessageBox.warning(util.translate("scripts", "La fecha de alta no puede ser superior a la fecha actual"), MessageBox.Ok, MessageBox.NoButton); return false; } return true; } //// INTERNA ///////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////// /** @class_definition oficial */ ////////////////////////////////////////////////////////////////// //// OFICIAL ///////////////////////////////////////////////////// function oficial_bufferChanged(fN:String) { switch (fN) { case "sueldobruto": case "impuestos": Anexo paquetes ERP 312 this.child("fdbSueldoNeto").setValue(this.iface.calculateField("sueldo neto")); break; } } //// OFICIAL ///////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////// /** @class_definition head */ ///////////////////////////////////////////////////////////////// //// DESARROLLO ///////////////////////////////////////////////// //// DESARROLLO ///////////////////////////////////////////////// ///////////////////////////////////////////////////////////////// Una vez creado el fichero podemos probar el script ejecutando el formulario y comprobar que cada una de estas cuatro funciones funciona correctamente. Vamos a mejorar un poco más nuestro script. Por un lado, vamos a habilitar nuestro control Causa de la baja cuando el usuario active el check De baja. Para ello ampliaremos la función bufferChanged para que realice esto. El código será: ... case "debaja" : // Si se activa el control, el campo Causa de la baja se habilitará if (cursor.valueBuffer("debaja") == true) form.child("fdbCausaBaja").setDisabled(false); else { form.child("fdbCausaBaja").setValue(""); form.child("fdbCausaBaja").setDisabled(true); } Anexo paquetes ERP 313 break; ... Ya tenemos plenamente operativo nuestro primer script. Vamos ahora con el script asociado al formulario maestro, masterempleados.qs. Este script conectará el botón Imprimir del formulario con la función que lanzará el informe de empleados que realizaremos en el siguiente apartado. Su código es el siguiente: /********************************************************************** ***** masterempleados.qs - description ------------------- begin : lun jul 1 2007 copyright : (C) 2007 by InfoSiAL S.L. email : [email protected] ********************************************************************** *****/ /********************************************************************** ***** * * * This program is free software; you can redistribute it and/or modify * * it under the terms of the GNU General Public License as published by * * the Free Software Foundation; either version 2 of the License, or * * (at your option) any later version. * * * ********************************************************************** *****/ /** @file */ /** @class_declaration interna */ //////////////////////////////////////////////////////////////////////////// Anexo paquetes ERP 320 Por último cerraremos el informe con un pie de página (Page Footer) en el que mostraremos la fecha de generación del informe y el número de página. Cada uno de estos datos se consigue insertando un campo de tipo Special, la fecha con Type = 0 y el número de página con Type = 1. El informe debe presentar un aspecto similar al de la siguiente figura. Plantilla del informe de empleados Una vez guardado ya podemos probar el informe. El visor de informes debe mostrarnos algo parecido a lo siguiente. Anexo paquetes ERP 321 Informe de empleados Bien, nuestro informe funciona, pero todavía no estamos en condiciones de ir enseñándolo por ahí. Ahora debemos darle una buena presentación. Como este trabajo es cuestion de gustos, dejaremos que cada uno dé al informe la apariencia que prefiera. Podemos obtener más información sobre las distintas propiedades de las secciones y campos de los informes en el apartado Documentación de http://www.Abanq.org Como ejemplo de presentación podemos ver el informe que muestra la siguente figura. Anexo paquetes ERP 32 2 Ejemplo de formato de informe Anexo paquetes ERP 323 ADEMPIERE 1 Vista General 1.1 Introducción a ADempiere Business Solution ADempiere Business Solution es una sofisticada solución de negocios Open Source que se posiciona como una fuerte alternativa a los productos propietarios. La mayoría de las soluciones ERP disponibles en el mercado actualmente, proporcionan similar funcionalidad, y muchas organizaciones evalúan soluciones basándose en las capacidades funcionales medidas en un instante de tiempo en particular. Este enfoque es común, pero no es la metodología más apropiada para evaluar y seleccionar una solución de negocio a largo plazo. Este enfoque puede conducir a diferentes resultados cuando un producto es evaluado en diferentes momentos, a raíz de nuevas versiones que pueden ser liberadas al mercado. El ciclo de vida de una solución ERP se estima generalmente en diez o incluso más años, y durante este período de tiempo la tecnología y los requisitos del negocio cambian. Así como la capacidad funcional de un producto es importante, es también muy importante tener en cuenta la tecnología en la que dicho producto está basado y la posibilidad que éste brinda para ser modificado y adaptado a las necesidades de la organización, las cuales se van renovando a medida que las reglas del negocio van cambiando. También es crítico asegurarse que los cambios esenciales realizados no comprometan la posibilidad de migrar a futuras versiones del producto, y preserven la integridad de las modificaciones específicas efectuadas para su negocio. El verdadero poder de ADempiere queda demostrado cuando, siendo funcionalmente rico, tiene la posibilidad de incorporar los cambios específicos de su negocio y preservarlos en la liberación de nuevas versiones. 1.2 Fortalezas de ADempiere 1.2.1 Flexibilidad 1) ADempiere adopta estándares abiertos, lo cual permite: · La estandarización, estabilidad e interoperabilidad de sistemas · Descripciones de datos y comportamientos claros, públicos y visibles 2) Independencia de Hardware y Sistemas Operativos 1.2.2 Viabilidad a largo Plazo 1) ADempiere se protege de la obsolescencia, cumpliendo con los estándares de la industria y utilizando un conjunto de herramientas que sostienen estos estándares: a) Permite a ADempiere cambiar los componentes fundamentales. Anexo paquetes ERP 324 b) Asegura la disponibilidad de una gran base de desarrolladores, quienes conocen las herramientas utilizadas. 2) La disponibilidad del código fuente reduce los riesgos de la nodisponibilidad de soporte a largo plazo. 3) Sumamente escalable para sostener un crecimiento orgánico o explosivo producido, por ejemplo, por una adquisición. 4) No es dependiente de la viabilidad en el largo plazo de la organización responsable por el desarrollo del producto. Por ejemplo, Peoplesoft ha adquirido recientemente JD Edwards, causando una significativa incertidumbre en los usuarios finales de los productos de JD Edwards. Del mismo modo, Oracle ha tomado Peoplesoft con la revelada intención de convertir a los usuarios finales de Peoplesoft al producto Oracle Financials. La viabilidad continuada del software Open Source NO está sujeta a la supervivencia de ninguna organización en particular. 1.2.3 Bajo Costo de Propiedad (TCO) 1) Sin cargos por Licencias de Software (sujeto a la elección de la base de datos). 2) Bajo incremento del costo a medida que la cantidad de usuarios crece. 3) No tiene que pagar por las actualizaciones anuales. 4) No requiere adoptar costosos, y frecuentemente no garantizados, ciclos de actualización. Bajos costos de contratos de soporte. 1.3 Fortalezas del Open Source Algunas de las ventajas que puede obtener con la utilización de una solución Open Source como ADempiere son: 1.3.1 Reducción de la dependencia de un solo proveedor del producto 1) Minimiza el riesgo de tecnología propietaria. 2) Elimina la dependencia de un proveedor que provea las licencias. 1.3.2 Auto dependencia 1) Proceso flexible en el desarrollo, con mayor enfoque en las necesidades específicas del negocio. 2) Mayor grado de participación y entendimiento entre el proveedor y el usuario final. 3) Independencia tecnológica. 4) Mejor receptividad para direccionar las necesidades locales y las oportunidades de negocios identificadas. 5) Las prioridades de desarrollo son manejadas por el usuario NO por el proveedor. 1.3.3 Amplio rango de opciones de soporte Anexo paquetes ERP 325 1) Soporte comercial brindado por muchas organizaciones. 2) Soporte gratuito, disponible en: a) Comunidad de Desarrolladores b) Listas de correo c) Archivos d) Base de datos de soporte Las experiencias de soporte son generalmente más responsables que con las aplicaciones propietarias. 1.3.4 Técnicamente Superior 1) Los productos Open Source están más alineados con los estándares abiertos que los productos propietarios, alcanzando así un mayor grado de interoperabilidad. 2) La revisión permanente por parte de la comunidad de desarrolladores, lleva a productos generalmente de una calidad superior. 1.4 Soporte de ADempiere Una solución Open Source, muchas veces es asociada con un menor costo a lo largo de todo su ciclo de vida, pero también es percibida con un menor nivel de soporte y un alto riesgo, comparada con un sistema propietario. Este no es el caso justamente. El nivel de soporte proporcionado por organizaciones de Open Source, puede ser considerablemente superior que el proporcionado por un revendedor que distribuye aplicaciones de software propietarias. El primero motivo es que el código fuente está disponible, y por lo tanto puede ser modificado para resolver el problema localmente, a diferencia de los productos propietarios donde el código fuente normalmente no está al alcance de la organización que brinda el soporte; éstos dependen de su desarrollador para proporcionar una corrección. Y esto generalmente se hace en una nueva versión, unos seis a doce meses más tarde. Adicionalmente, es posible obtener soporte entre la comunidad de desarrolladores, partners y usuarios del software, los cuales responden a las consultas realizadas en los foros, muchas veces en cuestión de horas e inclusive de minutos de realizado el requerimiento. Además del soporte, la mayoría de las organizaciones buscan obtener “garantías” de que el software adquirido está libre de defectos, o en caso de existir alguno, el mismo se solucionará rápidamente. La historia reciente y la experiencia indican que comprar un software a un proveedor no es garantía de libertad de errores. La realidad es que en soluciones de Open Source, la lista de errores es conocida y el código fuente está disponible para la organización de soporte, lo cual le permite corregir cualquier error que surja. Este no el caso del software propietario, donde generalmente los errores no se publican y el Anexo paquetes ERP 326 código fuente no está disponible para las organizaciones que lo distribuyen y dan soporte. 1.5 ADempiere – Requerimientos de Infraestructura & Hardware 1.5.1 Infraestructura nfraestructura de Red y Hardware ADempiere tiene la capacidad de operar en una variada gama de redes y sistemas operativos. Esta flexibilidad le da al usuario la libertad de escoger el hardware y sistemas operativos que mejor se adapten a sus necesidades individuales. 1.5.2 Sistemas Operativos ADempiere puede correr sobre un amplio rango de sistemas operativos, tales como Unix, Windows, Linux y Mac OS X, permitiendo al usuario elegir desde una amplia gama de sistemas operativos abiertos, hasta los sistemas propietarios ofrecidos por los proveedores tradicionales. 1.5.3 Servidor de Aplicaciones ADempiere utiliza el servidor de aplicaciones Jboss, por el cual no hay que abonar ningún cargo. 1.6 Licencias del Software NO existen cargos para el uso del software ADempiere. 1.6.1 Licencias 1) Licencias de productos intermedios: No existen licencias o CALs requeridas para correr ADempiere. Todos los productos utilizados por ADempiere son productos abiertos de la industria estándar, los cuales están libres de cargos por licencias. 2) Licencias de Base de Datos: los usuarios de ADempiere puede elegir entre adquirir su propia licencia de Oracle o seleccionar otras bases de datos, algunas de las cuales son Open Source (Oracle XE, PostgreSQL) u otros productos comerciales ofrecidos sin costo o a un bajo precio. 1.6.2 Gastos Recurrentes 1) Soporte de Hardware: los costos dependerán de la elección de hardware realizada por el usuario. La elección sobre que tipo de hardware utilizará ADempiere, dependerá de los requerimientos individuales del usuario y muchas veces, de las relaciones de éste con sus proveedores de hardware habituales. 2) Licencia de Mantenimiento de Base de Datos: vea los comentarios referidos antes en la sección de Licencias. Anexo paquetes ERP 327 3) Mantenimiento (upgrades) del Software de Aplicación: los usuarios de ADempiere tienen la posibilidad de descargar sin costo alguno todos los cambios y mejoras del producto y efectuar las migraciones de la base de datos utilizando recursos propios. El contrato de soporte de ADempiere, también incluye la migración de la base de datos y soporte para actualizar a versiones posteriores de la aplicación. 4) Soporte del Software de Aplicación: el contrato de soporte puede ser adquirido con las organizaciones que dan soporte a ADempiere, o efectuarlo el mismo usuario con recursos propios, muchas veces utilizando los foros de soporte de ADempiere, los cuales son de acceso público y abierto. 5) Extensiones y Modificaciones: ADempiere ha sido diseñado para facilitar las extensiones o modificaciones, realizadas por o para un usuario de ADempiere. La incorporación de un Diccionario de Datos Activo (Active Data Dictionary) posibilita la modificación del diccionario, que puede ser efectuado muchas veces por personas que no tengan conocimientos de codificación y sin depender de proveedores externos. También pueden ser efectuadas, si el usuario lo desea, por organizaciones como OPENBIZ, con un cargo básico. 1.6.3 Términos de la Licencia Muchos software Open Source están licenciados bajo los términos de la GNU Public License. Esta licencia requiere que las modificaciones efectuadas al producto (distintas que las realizadas para uso interno) deban ser retornadas a la comunidad Open Source. El sistema ADempiere Business Solution está licenciado bajo los términos de la General Public License (GPL). Esta licencia permite a los usuarios a desarrollar funcionalidades adicionales y utilizarlas internamente ó inclusive licenciarla mediante un cargo a terceras partes, sin la obligación de retornar la mejora a la comunidad Open Source. Los términos de la licencia de ADempiere se encuentran detallados en http://www.ADempiere.org/license.html 2.- ADempiere Business Solution Generalidades ADempiere brinda una funcionalidad completa, fácil de usar y de primer nivel para empresas del rango medio. A diferencia de los sistemas tradicionales, ADempiere está organizado en procesos de negocios y no en módulos. Se suministra como un sistema unitario, integrado y completo, en lugar de una serie de módulos acoplados con transferencia de datos entre ellos. De esta manera el usuario obtiene una vista unificada del negocio, con procesos que involucran a toda la organización y no solo a unos cuantos departamentos o unidades tratados como islas. Con ADempiere tiene todos los módulos en uno. Esta integración se aplica tanto al CRM Anexo paquetes ERP 328 (Administración de Relación con el Cliente), el Web Store (tienda Web), como a la información del ERP tradicional. 2.1 Organización de ADempiere – Procesos de Negocios El diseño de ADempiere permite manejar los procesos de negocios, en lugar de los departamentos tradicionales; actualmente, y especialmente en el caso de las empresas medianas, los empleados frecuentemente realizan el proceso de negocio entero o procesos relacionados entre sí. La tabla anterior muestra cómo se ven los procesos de ADempiere respecto a los módulos encontrados en los sistemas propietarios tradicionales. 2.2 Conceptos de ADempiere ADempiere proporciona servicios a múltiples clientes . Cada uno de ellos es una entidad, tal como una compañía padre o de máximo nivel equivalente. Cada cliente entonces tiene múltiples subsidiarias, departamentos, divisiones, llamadas organizaciones . Se permiten efectuar transacciones entre las organizaciones . Por ejemplo, un pago por una organización de un gasto para otra organización resultará automáticamente en una transacción interorganización en ambas, además de las entradas por el pago y el gasto. Anexo paquetes ERP 329 Cada entidad externa con la cual la organización efectúa transacciones de negocio se denominan socios de negocios . Por ejemplo, clientes y proveedores son socios de negocios . Los empleados también son tratados como socios de negocios . Cada transacción está asociada con un documento . Por ejemplo, facturas de venta, recibo de materiales, documentos de entregas, pagos a proveedores o recibos de clientes. Cada documento tiene predefinido un número de documento automático y es almacenado bajo ese número. También es posible adjuntar imágenes para cada documento . Además, para cada documento el usuario puede definir las consecuencias contables causadas por el procesamiento del mismo. 2.3 Proceso de Cotización a Ingresos Cubre los procesos de negocios utilizados para la creación de cotizaciones, administración de órdenes de venta, facturación y recepción de dinero por cobranzas. Esta funcionalidad se integra con la Administración de la Cadena de Suministro (SCM) y con la Administración de Relaciones con el Cliente (CRM) de ADempiere. En sistemas tradicionales, esta funcionalidad se encuentra en los módulos de órdenes de venta y cuentas a cobrar. 2.4 Proceso de Requerimiento a Pagos Cubre el proceso de negocio utilizado para la creación de órdenes de compra, procesamiento de facturas de proveedores y pagos efectuados. Se integra con la Administración de la Cadena de Suministro (SCM). Esta funcionalidad se encuentra generalmente en los módulos de compras y cuentas a pagar. 2.5 Administración de Ítems Pendientes Cubre el proceso de negocio utilizado para la creación de órdenes de compra, procesamiento de facturas de proveedores y pagos efectuados. Se integra con la Administración de la Cadena de Suministro (SCM). Esta funcionalidad se encuentra generalmente en los módulos de compras y cuentas a pagar. 2.6 Administración de Relaciones con el Cliente (CRM) Es un módulo integrado que provee una vista lógica de todas las actividades relacionadas con clientes y prospectos. En contraste con los sistemas de CRM tradicionales, no existe la necesidad de efectuar procesos batch ni sincronizaciones con la funcionalidad del backoffice. 2.7 Administración de Relaciones de Socios Anexo paquetes ERP 336 5 Proceso de Administración de Ítems Pendientes Este proceso automatiza la entrada y asignación de dinero recibido de los clientes y los pagos efectuados a proveedores. También provee la conciliación bancaria y libros de caja, teniendo en cuenta los pagos en tránsito, cargos bancarios y la creación de pagos por transferencias directas. 5.1 Reglas de Pago para Cuentas a Pagar Los pagos son creados de manera automática, basados en el conjunto de reglas de pago establecidos para la factura del proveedor. Estas reglas pueden cambiarse en cualquier momento, para reflejar el método efectivamente utilizado, en caso de utilizar uno alternativo. ADempiere soporta las siguientes reglas de pago: · Efectivo: se crea una entrada automáticamente en el Libro de Caja en ese día. · Cuenta corriente: es el término de pago por defecto para el Socio de Negocio, salvo que se especifique otro diferente. · Tarjeta de Crédito: las transacciones por tarjeta de crédito pueden ser procesadas online. Las facturas son marcadas como pagadas y el cargo se mantiene como pagos sin conciliar. Este método puede requerir un procesador externo para las tarjetas de crédito. · Cheques: luego de seleccionar el banco apropiado, se pueden ingresar los cheques al sistema. Las facturas son marcadas como pagadas y el cheque se mantiene en el sistema como pago sin conciliar. 5.2 Asignaciones La asignación liga el pago, o múltiples pagos, a las facturas (o múltiples facturas) o acredita Notas de Crédito y registra los descuentos en pagos y cancelaciones de cuentas por cobrar. El usuario selecciona los documentos correspondientes e ingresa o confirma las diferencias como pagos parciales, descuentos o cancelaciones. 5.3 Conciliación Bancaria Pueden ser ingresadas manualmente o cargadas automáticamente de manera electrónica, provista por la institución financiera. ADempiere posibilita la conciliación de pagos en tránsito y cargos bancarios o la creación de transferencias de débito directas. 5.4 Libro de Caja Todas las facturas pagadas y/o cobradas por caja chica son ingresadas de manera automática al libro de caja. Para ello se crea un diario de caja por día y organización. El diario de caja es utilizado también para: · Gastos generales, para las cuentas definidas en el libro de caja. Anexo paquetes ERP 337 · Ingresos generales, para las cuentas definidas en el libro de caja. · Diferencias de caja chica, para las cuentas definidas en el libro de caja. · Cargos · Transferencias desde o hacia una cuenta bancaria. 5.5 Cargos Son utilizados en ADempiere para permitir procesar costos o ganancias no relacionados con productos, tales como cargos por transportes, cargos bancarios e intereses. Los cargos son ligados a cuentas de la contabilidad general, y varios tipos de cargos pueden apuntar a la misma cuenta contable. Por ejemplo, los cargos “Resma de Papel” y “Cartuchos de Impresora” pueden apuntar ambos a la cuenta “Gastos de Impresión”. Un cargo puede referir tanto a un gasto como a un ingreso. Así por ejemplo el cargo “Transporte” puede ser acreditado a una cuenta de ganancia si es ingresado en una factura de venta, o a una cuenta de gasto si aparece en una factura de proveedor. El sistema determinará el tipo, en base al contexto en el que se ingrese. Un cargo en una factura a cliente es una ganancia, mientras que en una factura de proveedor es un gasto. Por otro lado, un cargo con signo positivo en el Libro de Caja será una ganancia, mientras que si es con signo negativo será un costo. Los cargos pueden ser definidos para debitar o acreditar en diferentes cuentas contables, de acuerdo con un porcentaje de división preestablecido. El usuario puede también definir el tratamiento de impuesto para los cargos. El importe de los cargos puede estar predefinido, para ganar velocidad y seguridad en su registración. Por otro lado, el importe de un cargo no tiene asociada una moneda específica, sino que ella está determinada en base a la moneda del documento. Algunas otras características del proceso de administración de ítems abiertos son: · Invertir asignaciones · Análisis de deudas por antigüedad · Procesamiento online de Tarjetas de Crédito y Cheques electrónicos · Procesador de pagos mediante VeriSign PayFlowPro (no disponible en Argentina) · Recordatorio de Deudas (es el proceso de recordar a los clientes la deuda mantenida. Puede comenzar con simples recordatorios hasta notas más firmes conforme las deudas sean más antiguas). Anexo paquetes ERP 338 6 Administración de la Cadena de Suministro Este proceso cubre todas las actividades de administración de materiales, incluyendo recepción, despachos, movimientos y balances de stock, dentro de una compañía y sus sucursales, y entre proveedores y clientes. El Catálogo de Productos lista los productos y servicios con la lista de materiales y sustitutos opcionales. El sistema le permite importar y actualizar precios de compra desde sus proveedores. Los productos se organizan en categorías y jerarquías, y pueden ser buscados también en base a atributos que se aplican sobre un determinado número de productos, por ejemplo “todos las camisas amarillas de manga corta”. ADempiere soporta múltiples listas de precios para todos los ítems comprados y vendidos. La funcionalidad del precio de lista de compra, permite un control simple de los descuentos desde el proveedor y el sistema posibilita la existencia de listas de precio de ventas generales o específicas por cliente. 6.1 Control de Depósitos ADempiere soporta las siguientes características en el manejo avanzado de depósitos: · Múltiples almacenes físicos y cada uno de ellos ser descompuesto en múltiples almacenes lógicos, como ser recepción, control de calidad y testeo, almacenamiento y entrega. · Almacenar en cada almacén en una ubicación referenciada por 3 ejes (pasillo, cajón y nivel) definido por el usuario. Anexo paquetes ERP 339 · Múltiples unidades de Medida (por ejemplo almacenar en cajas y vender en unidades). · Prioridades de salida, para asegurarse que salen de una ubicación con una secuencia preestablecida. · Prioridades de usuario para despachos o recepción. · Los movimientos de inventario entre ubicaciones o almacenes pueden configurarse para que se efectúen con la documentación adecuada y el manejo de stock “en tránsito”. · La toma y los ajustes de inventario pueden ser procesados en paralelo con las actividades de venta. · El stock utilizado para propósitos internos puede ser fácilmente descontado para registrar el decrecimiento de stock y las consecuencias financieras de la contabilidad general. 6.2 Administración de Materiales La documentación de entrega, puede ser creada en forma serial (batch) o individualmente una por orden. Los bienes recibidos de los proveedores pueden ser comparados directamente con la orden de compra o la factura del proveedor. El sistema permite tener un “disponible para prometer”, calculado teniendo en cuenta las reservaciones para despachos a realizar a clientes y las recepciones esperadas del proveedor. Las Listas de Reabastecimiento de Material, son creadas basadas en reglas de reabastecimiento de inventario. Los pedidos y órdenes de compra pueden ser generados automáticamente desde el Reporte de Reabastecimiento de Material. ADempiere además permite: · Seguimiento de Lotes/Series y manejo de números de serie. · Listado de número de parte del proveedor y otros atributos. · BOM o desmontaje. · Fusión de productos. · Cantidades de stock negativas. · Administración de Activos. 6.3 Listas de Materiales (BOM) Una Lista de Materiales puede contener uno o más Productos, Servicios o inclusive otros BOM. No existe un límite en cuanto a la cantidad de elementos ni niveles que pueda contener un BOM. La limitación está solamente en que un BOM tiene que ser “no-circular”, es decir que no puede tener referencias a él mismo ni a sus partes (ejemplo de estos casos se encuentran en las recetas de industrias químicas). ADempiere maneja dos tipos de BOM: Anexo paquetes ERP 340 · Almacenado: si se indica que el BOM es almacenado, es tratado como si fuera un producto normal en términos de disponibilidad. Para crearlo, es necesario “ensamblarlo” (o desensamblarlo) mediante “Producción”. La disponibilidad representa la cantidad que existe en stock, no lo que se podría producir. Si el precio establecido es 0.00, entonces es calculado de manera dinámica (por ejemplo, sumando las partes individuales) y para este caso se requiere que el BOM y todos sus componentes estén en la lista de precios seleccionada. Normalmente se imprime solo la información del BOM, pero para las facturas, entregas y listas tiene la opción de imprimir el detalle (allí se imprimen las cantidades también). · No almacenado: generalmente se utilizan por una conveniencia en el ingreso de datos. Cuando se procesa la orden o la factura, se generan las líneas de los productos involucrados. La cantidad disponible en un BOM no almacenado se calcula dinámicamente en base a cada ítem y representa lo que podría estar disponible. Para este tipo de BOMs, el precio es siempre la suma de precios de los ítems individuales que lo componen. 7 (CRM) Administración de Relaciones con el Cliente El CRM en ADempiere no es un módulo independiente, sino una vista lógica de todas las actividades relacionadas con los clientes o potenciales clientes (llamados prospectos). Anexo paquetes ERP 341 En ADempiere las funciones de CRM son una parte integral del proceso de negocio, por lo tanto no se requieren procesos batch ni de sincronización, como es habitual en los sistemas de CRM tradicionales. Puede administrar la creación, distribución y seguimiento del cliente, proveedor y los pedidos generados internamente, para asegurar un tiempo de respuesta oportuno, crecimiento de acuerdo a procesos y tiempos definidos. ADempiere soporta los siguientes tipos de requerimientos en el área de CRM: · Información: requerimiento no estructurado originado desde la Web o vía email. · Servicios: requerimientos estructurados para realizar un servicio en un lugar y fecha determinados. · Cargos: requerimiento estructurado para reembolso de costos. Anexo paquetes ERP 342 · Cuenta: requerimiento estructurado relacionado con una orden, factura, despacho o pago relativo a un proveedor o cliente en particular. · Garantía: requerimiento estructurado relacionado con un problema con un servicio o producto. · Ayuda: requerimiento estructurado de servicios a clientes. Dependiendo del tipo de requerimiento que se trate, este puede ser convertido automáticamente a un documento (por Ej. una oferta, orden o factura). Es posible enviar manual o automáticamente un e-mail de confirmación con un número de seguimiento y, utilizando ese número, el autor del requerimiento puede actualizar información en el mismo. Los requerimientos pueden ser asignados a usuarios del sistema, para que tome acciones o realice el seguimiento. Los requerimientos pueden ser generados también en base al estado de la cuenta (por Ej. fecha de la última venta, pago vencido, etc.) para el seguimiento por parte de la fuerza de ventas o de atención al cliente. 7.1 Administración de Campañas de Marketing La retención de clientes es una misión crucial para cualquier compañía; se calcula que retener un cliente cuesta 6 veces menos que conseguir uno nuevo. ADempiere soporta esto mediante la creación de mailing o requerimientos para facilitar el seguimiento de la fuerza de ventas (o tele-ventas). Los criterios para las campañas de retención podrían ser última venta, volumen de ventas, productos comprados u otros motivadores. Para atraer nuevos clientes se pueden importar perspectivas desde mailing o requerimientos. La eficiencia de estas campañas de marketing puede ser medida por la ganancia o beneficio bruto generada por cada una, ligando cada documento (por Ej. factura u orden) a cada campaña en el momento que se genera el documento. Esta información está disponible dentro de ADempiere, para reportes y análisis. 7.2 Análisis de Ganancias de Cliente Los reportes de ganancias y beneficios brutos de clientes específicos o grupos de clientes en un determinado período de tiempo, pueden obtenerse utilizando la posibilidad de generar reportes que provee ADempiere, o utilizando generadores de reportes de terceros y/o visores OLAP. 7.3 Autoservicio para pedidos online ADempiere permite el acceso vía Web de Socios de Negocios autorizados (por Ej. clientes, proveedores o empleados), con el propósito de ver o consultar información relevante para ese socio de negocios, utilizando para ello un browser Web. La información puede incluir saldos de cuentas, Anexo paquetes ERP 343 facturas o cosas por el estilo, o iniciar el seguimiento y efectuar pagos sobre ítems abiertos. Esta funcionalidad de auto servicio, puede ser utilizada también para permitirle a los clientes registrarse a fin de recibir material de marketing seleccionando áreas de interés o para descargar archivos con datos seguros, por ejemplo listas de teléfonos donde solicitar soporte. 8 Administración de Socios La Administración de Socios vincula diferentes clientes entre sí, permitiendo manejar prioridades de distribución, gastos de marketing, o proporcionar servicios centralizados. Básicamente la Administración de Socios proporciona la funcionalidad de CRM a través de los clientes de ADempiere, intercambiando automáticamente los requerimientos con Socios de Negocios que están conectados a ADempiere. Aquellos Socios que no están conectados, pueden hacer seguimiento de información mediante la interfase Web. ADempiere puede ser utilizado para crear guías y distribuirlas a los Socios de Negocios. El sistema puede utilizarse también para seguir y Anexo paquetes ERP 344 monitorear progresos y resultados. También le permite a los Socios de Negocio crear facturas por cargos directamente por gastos en actividades de marketing. ADempiere facilita la administración y provisión de servicios compartidos (por Ej. contabilidad, despachos, help desk, etc.) para los Socios de Negocios tales como franquicias. Como proveedor de servicios, el usuario solo tiene acceso a la información que necesita para sus tareas, a través de múltiples clientes y organizaciones. El sistema puede mantener datos centralizados, tales como productos, listas de precios, información contable para todos sus socios. Estos pueden agregar entidades adicionales, pero no pueden modificar los elementos que son mantenidos centralmente, por una cuestión de consistencia y seguridad. La combinación de información mantenida centralmente y localmente, posibilita la administración de una “red de organizaciones”; un típico ejemplo de ello son las operaciones de franquicias o aquellas organizaciones que proveen funciones centralizadas para asociados independientes. 8.1 Contador de Documentos ADempiere proporciona una funcionalidad que permite a organizaciones independientes pero relacionadas, a generar automáticamente un documento en otra organización. Esta funcionalidad reduce considerablemente el esfuerzo implicado en el doble procesamiento de las transacciones (una vez en cada organización) y asegura que los impuestos sean manejados de manera correcta entre personas jurídicas separadas. Por ejemplo, un franquiciado puede colocar una orden de compra en el concesionario y la orden de venta será creada automáticamente en el libro de contabilidad de este último. Cuando el concesionario despacha al franquiciado, el recibo de material será creado en la contabilidad del franquiciado y así cada transacción que ha sido configurada automáticamente creará un contador de documentos. Además permite que sean registrados diferentes costos en las cuentas del franquiciante y el franquiciado. ADempiere permite configurar de manera más sofisticada la situación descripta, permitiendo por ejemplo que el receptor de la mercadería “confirme” la recepción, permitiendo la administración de bienes en tránsito y asegurar que no pueda emitirse una factura automática, hasta que el receptor de los bienes no haya confirmado su recepción. Anexo paquetes ERP 345 9 Análisis de Resultados Esta funcionalidad cubre el costeo y dimensiones contables de la aplicación y se encuentra generalmente en los módulos de Reportes y Contabilidad general en los sistemas tradicionales. 9.1 Reglas Contables Las entradas contables son generadas automáticamente en base a reglas que son aplicadas a documentos de transacciones y son definidas por el sistema, pudiendo ser extendidas por el usuario si lo desea. Estas reglas, definen los códigos de cuentas para cada grupo de transacciones generadas por un documento contable, permitiendo que la mayoría de las transacciones sean ingresadas al sistema sin que los usuarios deban conocer los números de cuentas a imputar. El sistema también permite el ingreso manual para generar imputaciones adicionales (actual, presupuesto y estadística). 9.2 Reportes Integrados, Data Warehousing y OLAP Los reportes pueden ser creados para cada tipo de documento en el sistema. El usuario puede definir el layout, secuencia, formato y totalizar cualquier reporte y poner este a disposición de cualquier usuario del sistema u organización, configurando la seguridad de manera apropiada. Las facilidades de reportes permiten desde navegar dentro de los mismos (por ejemplo, desde una orden de compra ir a socio de negocio, Anexo paquetes ERP 352 A diferencia de otras aplicaciones ERP y CRM, el Workflow no está “por encima” de la aplicación, sino que ADempiere está basado en Workflow. El motor de Workflow de ADempiere es el corazón del administrador de transacciones, razón por la cual todos los procesos en ADempiere son activados por Workflows y son fáciles de extender y modificar. Al estar los Workflows completamente integrados son fáciles de mantener y proveen mucho más funcionalidad que los Workflows externos o agregados que ofrecen algunos otros proveedores de ERP y CRM. 12.3.1 Tipos de Workflows ADempiere ofrece tres tipos de Workflows: · General: proporcionan guías e instrucciones paso a paso para cumplir una tarea. Por ejemplo, los wizards de configuración. Este tipo de Workflow lo inicia el usuario desde el menú. · Procesador de Documentos: controlan los pasos de procesamiento de todos los documentos y se inician automáticamente cuando se procesa un documento. Pueden ser extendidos, por ejemplo para solicitar autorización en una orden de compra si el importe de la misma supera un cierto valor. · Por Valor de documentos: es iniciado automáticamente cuando una entidad cumple con una condición especificada por el usuario. Por ejemplo, requerir un proceso de aprobación para definir el crédito de un cliente nuevo. 12.3.2 Acciones de Nodos y Transiciones Un Nodo en el Workflow de ADempiere puede tener las siguientes acciones: · Proceso Automático: Cualquier acción en Proceso, Reporte, Tares, Workflow, Documento. · Acción de Usuario: Cualquier pantalla o formulario donde un usuario necesita confirmar la realización. Anexo paquetes ERP 353 · Establecer una Variable: Cualquier Columna a Constante o Variable. · Selección de Usuario: Cualquier selección, por ejemplo aprobar o selección en una Lista. · Wait (Espera): puede ser utilizado para iniciar, finalizar, etc. La transición entre los nodos puede, opcionalmente, tener condiciones y además se permite el procesamiento paralelo mediante múltiples transiciones de un nodo. Esto permite modelar escenarios complejos a través de la funcionalidad que proporcionan los Workflows de ADempiere. 12.3.3 Aprobaciones (Personas Responsables) El usuario puede definir una jerarquía para aprobaciones o utilizar la de la organización. La persona responsable de un Workflow puede ser un usuario específico o el invocador, un grupo (rol) o el supervisor de una organización. Pueden también existir diferentes responsables para cada nodo/paso del Workflow. 12.3.4 Prioridad, Avances, Alertas Es posible administrar las prioridades dinámicamente, lo cual permite que sea usado para ruteos de Call Centers y soporte basado en las prioridades de cliente. Además los usuarios pueden definir reglas de avance por inactividad y enviar alertas a los responsables del Workflow y/o supervisor. 12.4 Opciones de Implementación ADempiere tiene los siguientes componentes principales: · Cliente • Aplicación Java • Applet Java • Basado en HTML · Servidor de Servlet para aplicación basada en HTML · Servidor de Aplicaciones · Servidor de Base de Datos Anexo paquetes ERP 354 Todos los componentes pueden ser implementados en cualquier plataforma que soporte Java: Windows (NT, 2000, XP), Unix, Linux, Mac, etc. Se soportan una gran variedad de configuraciones; cuando el ancho de banda lo permite, es posible instalar el la aplicación cliente Java. Se pueden obtener accesos seguros utilizando herramientas estilo Terminal Services, ya sean soluciones propietarias u open source. Para utilizar el cliente HTML, se necesita un Servidor de JSP y Java Servlet, y para implementar la funcionalidad del Web store se requiere el protocolo SSL, adicional al estándar http. El servidor de aplicaciones JBoss puede ser instalado de manera stand alone o en el mismo servidor de la base de datos; se utiliza JMX (Java Management Extensions) para la administración del servidor. El servidor de la base de datos almacena los datos y la lógica de la aplicación, y se accede a él mediante el protocolo estándar JDBC. Anexo paquetes ERP 355 13 Arquitectura de la Aplicación Debido a que las aplicaciones de negocios cambian constantemente, es necesario utilizar nuevas tecnologías y siempre existe la necesidad de proveer soporte a funcionalidades adicionales. Las aplicaciones deben también soportar la incorporación de nuevas funcionalidades específicas para el cliente, aunque muchas veces no sean adecuadas para la integración con la funcionalidad central de la aplicación (por Ej. personalizaciones y ciertas extensiones). Si bien es sabido que los requisitos para las aplicaciones cambian constantemente, son pocas las que están diseñadas para resistir cambios y agregados. Estas aplicaciones de negocios pueden tener una larga expectativa de vida y tender a proporcionar mayor funcionalidad en el tiempo, por lo cual es muy importante proporcionar un buen armazón que permita administrar este crecimiento de complejidad. En caso contrario, si no están diseñadas para soportarlo, se volverán inestables al añadir funcionalidad extra a la aplicación base. ADempiere utiliza los siguientes principios de diseño a fin de crear una arquitectura que sea sustentable: · Arquitectura MVC de Smalltalk (desconectado del Model-ViewController) · Desconexión Asincrónica de procesos vía mensajes. · Motor de Reglas Explícito, para implementar la lógica compleja. · Transacciones seguras de fallas y recuperación. ADempiere tiene una Object Architecture (comparada con ObjectOriented, Object-like o las arquitecturas tradicionales), en la cual cada Objeto es tan independiente de otros Objetos como sea posible, incluyendo el desacoplado de las transacciones. Las primeras versiones de la arquitectura de ADempiere se diseñaron a mediados de los 80 utilizando Smalltalk, uno de los primeros lenguajes y ambientes verdaderamente orientado a objetos. Otras raíces de la Anexo paquetes ERP 356 arquitectura están basadas en el proyecto “Next Generation” de ADV/Org, que era muy similar al proyecto original R/3 de SAP. 13.1 Interfase de Usuario Inteligente La interfase de usuario de la aplicación y las pantallas HTML son generadas en tiempo de ejecución, basada en reglas del Diccionario de la Aplicación. Como resultado se obtiene una interfase de usuario consistente, que permite navegar rápidamente en áreas de la aplicación que no son familiares. Esta metodología de generación de la interfase de usuario permite un rápido desarrollo y el sistema resultante es mucho más estable que en otras aplicaciones. Este método también permite que el layout de las pantallas pueda ser modificado o extendido y que se puedan generar nuevas pantallas, creadas por el administrador del sistema, sin necesidad de modificar el código; los usuario automáticamente ven las nuevas pantallas la próxima vez que ingresen a la aplicación. El Diccionario de Datos sabe de las estructuras y dependencias, permitiendo al usuario el acceso directo mediante zoom desde una lista a la ventana del dato, donde puede actualizarlo o ingresar nueva información. Esto permite que, por ejemplo, un usuario pueda ingresar un nuevo cliente mientras carga una orden, sin salir de la ventana original. Los usuarios pueden Consultar registros. Esto reduce el número de registros en una ventana, y le permiten ingresar uno o más criterios de selección en una ventana. Por otro lado, un usuario con los permisos adecuados, puede personalizar los layout de las ventanas y puede acomodar ventanas para una situación y cliente específico. Todos los usuarios pueden establecer valores por defecto en los campos de sus pantallas, a fin de evitar la selección de valores utilizados comúnmente. 13.2 Reportes Inteligentes En muchas otras aplicaciones, los Reportes son entidades separadas o agregadas. Los reportes de ADempiere están basados en el diccionario de datos. Al tener acceso a la definición desde el visor de reportes, es posible navegar dentro de un reporte desde una entidad referenciada en él, hacia otros reportes. Los links son generados automáticamente y son señalados mediante un subrayado en el mismo reporte. La navegación está sujeta a las definiciones de acceso y seguridad que fueran configuradas oportunamente. Las Vistas de Negocios están diseñadas para los usuarios finales y permiten acceder a la información utilizando herramientas estándar de SQL, sin necesidad de crear joins de tablas con SQL. La mayoría de las Vistas de Negocio son generadas en base al Diccionario de la Aplicación. Anexo paquetes ERP 357 Las salidas de los reportes pueden ser vistas en pantalla antes de enviarlas a una impresora o generar archivos en diferentes formatos (por Ej. Excel, HTML, Word y PDF). 13.2.1 Drill-down Cuando utiliza drill-down se genera un nuevo reporte basado en la entidad seleccionada. Por ejemplo, en el reporte de una orden es posible navegar a las líneas de la misma haciendo un doble clic sobre la cabecera de la orden. Adicionalmente el drill-down está disponible con las transacciones. Por ejemplo: · Reportes donde un número mostrado es la sumatoria de otros números. · Navegar desde un monto totalizado mensualmente hacia las transacciones originales. 13.2.2 Drill-across Permite crear un nuevo reporte al usuario donde se utiliza una entidad específica. Por ejemplo, en un reporte de producto, un usuario puede seleccionar una línea específica (producto); de allí navegar hacia el detalle de una orden o factura, que muestre solamente las líneas donde aparece dicho producto. 13.2.3 Tipos de Reportes ADempiere proporciona tres tipos de reportes: · Reportes por listas desde cada ventana. · Reportes Financieros. · Vistas OLAP (utilizando la herramienta OLAP de Oracle u otras herramientas OLAP de terceras partes). Las listas están basadas en información de las ventanas y es posible generar múltiples reportes para cada ventana en el sistema. Cualquiera de esos reportes pueden ser iniciados desde dentro de una ventana en particular o, alternativamente, colocarlos en el menú, incluyendo parámetros definidos por el administrador del sistema. Los visores OLAP proporcionan diferentes dimensiones (como cuentas, productos, clientes) que serán LAP de terceros que seleccione el usuario. Los datos pueden ser almacenados también en datawarehouses de terceros que elija el usuario. 13.2.4 Personalización de Reportes Anexo paquetes ERP 358 ADempiere diferencia la “vista” del “modelo”. La aplicación provee un número de vistas estándar predefinidas, pero es posible que el usuario cree vistas adicionales de los datos utilizando sentencias Select SQL provistas por el mismo. A diferencia de otras aplicaciones, el usuario no necesita resolver referencias a claves foráneas (que requeriría conocer el modelo de datos) o preocuparse por la seguridad de los datos, ya que ADempiere resuelve esos temas de manera automática. Generalmente, la gente tiene diferentes preferencias en cuanto a la forma en que cada reporte debería mostrarse. Por ello ADempiere permite que el usuario defina los reportes a nivel del Sistema, Cliente, Organización o inclusive Usuario: · Columnas del reporte · Orden de las columnas · Orden dentro del reporte · Cabecera de las columnas · Sumas, conteos de cantidad, mínimo, máximo, desviación, media y varianza (para las columnas numéricas). · Agrupación El lenguaje del reporte se encuentra basado en el lenguaje que el usuario escogió en el momento de ingresar a la aplicación y cada usuario puede tener uno diferente. La selección de datos se hace mediante los parámetros del reporte ingresados cuando se inicia el reporte, o mediante el panel de Consulta avanzado, lo cual permite al usuario ingresar un criterio en un estilo “consulta por ejemplo” (“query by example”) extendido. 13.3 Seguridad ante Fallas Generalmente las aplicaciones son diseñadas para ser seguras a fallas, lo cual asume que todos los trabajos y los datos son ingresados de manera correcta y consistente. En caso de fallas, los expertos deberán buscar las causas y verificar los daños producidos. El usuario normalmente nota el problema tiempo después que ha ocurrido y la realidad es que las aplicaciones algunas veces fallan. En contraste, ADempiere ha sido diseñado para ser seguro ante fallas. Cada transacción puede ser repetida y regenerada. Muchas de las fallas que se producen son identificadas por el sistema y el usuario puede intentar reparar el problema. En caso de no ser posible la recuperación, el error es aislado y el resto del sistema continúa trabajando. El diseño de transacciones desacopladas de ADempiere permite esta posibilidad. Cada transacción realiza solamente una tarea, por lo que es simple de estabilizar y aislar el impacto ante una falla, facilitando además su identificación. Anexo paquetes ERP 359 La comunicación entre las transacciones individuales está basada en mensajes, permitiendo lotes asincrónicos de transacciones. Así mismo, es más fácil de implementar funcionalidad adicional, y el costo de agregarla en ADempiere es mucho menor que en otras aplicaciones. El usuario puede continuar trabajando con restricciones menores si la transacción principal (por Ej. Un ajuste de inventario) es exitosa. Las transacciones restantes pueden ser generadas posteriormente, cuando el problema haya sido solucionado. El sistema regularmente verifica si una transacción está completa; en caso de no estarlo, o de no ser consistente, da una falla y el administrador y el usuario son informados de ello mediante un mensaje. A medida que las aplicaciones se van haciendo más complejas, la posibilidad de errores crece exponencialmente. ADempiere proporciona un marco o framework de validación, y si eso falla, aísla el problema asegurando una alta disponibilidad de las funciones centrales. 13.4 Seguridad del Sistema ADempiere proporciona una infraestructura de seguridad completa y flexible para cumplir con las necesidades del usuario, y soporta función, seguridad de datos, como así también auditoria. La función de seguridad está basada en Roles de Usuario, la cual controla el acceso a Ventanas, Reportes y Procesos. Por otro lado, la seguridad de los datos está basada en Cliente y Organización, y es mantenida a nivel del contexto de seguridad de la base de datos. Este es un nivel adicional de seguridad posterior al login normal de usuario de la base de datos. Antes de acceder a cualquier dato, el usuario debe identificarse mediante un store procedure con un nombre de usuario, contraseña, rol y opcionalmente la preferencia de lenguaje. Todas las contraseñas se almacenan de manera encriptada. La funcionalidad de auditoria incluye registro de accesos (que funciones/datos fueron utilizados), registro de cambios (que datos fueron cambiados, que valor tenían y cuales se establecieron; incluyendo datos borrados), como así también archivos (documentos y reportes generados). Si bien, el tema de seguridad es complejo para desarrollar, se brindan algunos aspectos relacionados con el tema, que muestran la flexibilidad y poder que proporciona ADempiere. 13.4.1 Roles Anexo paquetes ERP 360 Definen el primer nivel de seguridad en ADempiere. Los usuarios ingresan a la aplicación con un Rol específico. Si bien un usuario puede tener muchos roles, el acceso a ADempiere se obtiene basado en el Rol que se escogió al momento de ingresar. Los roles definen la Organización, Ventanas, Procesos, Formularios, Workflows y Tareas (en adelante llamadas entidades) a las que el usuario puede acceder. El usuario no ve ítems de menú a los que no tiene acceso; no es que los tiene deshabilitados, sino que sencillamente no los puede visualizar. Los Roles también definen las acciones que el usuario puede efectuar en las entidades a las que tiene acceso. 13.4.2 Control de Roles La definición de Rol permite que una serie de acciones pueda ser habilitada o deshabilitada para cada Rol en particular: · Mostrar Contabilidad: le permite al Rol acceder a los Tabs y Ventanas con información contable. En caso de estar deshabilitado, los usuarios con este rol no podrán ver ni modificar información contable. · Reportes: permite al Rol el acceso a reportes. · Exportar: permite la exportación de datos. Para permitir la exportación, el Rol debe tener habilitado Reportes también. · Bloqueo Personal: le permite al Rol bloquear registros para que no puedan ser accedidos por otro Rol. · Acceso Personal: le permite al Rol acceder a registros que han sido bloqueados. · Solo Lectura: controla que el Rol tenga permitido hacer modificaciones a los registros. · Entidad Dependiente: controla si el acceso debe estar restringido para otras pantallas y procesos que usan ese registro; por ejemplo permitir que alguien que trate con Términos de Pago pueda ver Ordenes, Facturas, etc., donde se utilice algún Término de Pago. · Sobrescribir Precio Límite: controla la posibilidad de sobrescribir los precios límites cuando se ingresan órdenes o facturas. · Mantener Log de Cambios: determina si el sistema debe mantener un registro de los cambios efectuados por los usuarios de este Rol. · Acceso a Todas las Organizaciones: controla el acceso a las Organizaciones. Si no está habilitado, es posible restringir el acceso a una organización asignada para un usuario específico. Nivel de Preferencias: controla la posibilidad de los usuarios del rol de establecer preferencias a nivel de Cliente, Organización, Ventana o Usuario. 13.4.3 Acceso a Datos por Rol Anexo paquetes ERP 361 Es el segundo nivel de seguridad de ADempiere. Para un determinado Rol y privilegios, es posible además establecer el acceso a tablas, columnas o registros específicos. Por Ejemplo: · Que determinados usuarios solo puedan crear Ordenes de Venta con el Término de Pago Inmediato; así, no podrán seleccionar, por ejemplo, el Término de Pago Crédito. · Prevenir que ciertos usuarios puedan utilizar determinadas cuentas contables en el Diario o ver información de esas cuentas. 13.4.4 Bloqueo Personal Cuando un Rol tiene habilitado el Bloqueo aparece un icono de bloqueo en la barra de herramientas. El bloqueo en posición abierta, indica que el registro está abierto a todos los usuarios, mientras que en posición cerrada significa que solo está abierto para el usuario que lo bloqueó y para aquellos que tengan habilitado Acceso Personal. Anexo paquetes ERP 368 15 Personalización e Interfases Externas 15.1 Diccionario de Datos A diferencia de la mayoría de las aplicaciones, donde los desarrolladores deben diseñar, codificar y probar cada pantalla, ADempiere utiliza un concepto más avanzado de Diccionario de Datos Central, llamado Repositorio de Información, que permite facilitar esta tarea. El Diccionario de Datos de ADempiere, alojado en la capa de metadatos, sabe como acceder a los datos y como se relaciona la información. Contiene definiciones de entidades de datos (tipos, validaciones, etc.), como se muestran (títulos sobre pantallas y reportes, ayudas, posición relativa con respecto a otros datos, etc.) y las reglas para mostrarlos. También se almacenan aquí las reglas de seguridad y acceso. Este diccionario es “activo”, significando con ello que es utilizado en tiempo de ejecución y es sensible al contexto. Es extensible por el usuario y puede incluir reglas e información especificada por el usuario. También les permite a usuarios autorizados, agregar nuevas tablas, nuevas pantallas y datos adicionales sobre pantallas ya existentes en la aplicación. Toda esta información agregada está automáticamente disponible en los listados y reportes. 15.2 Personalización Además de la posibilidad de personalizar las Interfases de Usuario, Reportes y Extensiones, ADempiere proporciona capacidades de personalización adicionales: · Preferencias Default o elecciones preseleccionadas o Preferencias de Login: Organización, Lenguaje, Fecha de Transacciones e Impresora. o Preferencias definidas por el Usuario, tales como tipos de transacciones específicas. · Personalización de la Barra de Menú, permitiendo guardar cualquier entrada en la barra (Ventanas, Procesos, Reportes) como un acceso rápido. · La Terminología puede ser cambiada. Por ejemplo si los usuarios en lugar de Productos utilizan Ítems o Artículos, o a la Organización la denominan Sucursal, etc. · Los Textos de Ayuda pueden ser modificados y extendidos por el usuario para proporcionar sugerencias y ayudas específicas. Las personalizaciones son definibles a diferentes niveles: · Sistema o implementación · Ventana, si es apropiado (por Ej. para preferencias) · Cliente [Document text truncated for crawler view.]