Universidad de las Ciencias Informáticas Facultad 1
“Vistas de arquitectura de sistema y datos de la solución Finanzas del proyecto ERP Cuba.”
Trabajo de Diploma para optar por el título de Ingeniero en Ciencias Informáticas
Autora: Gregseen Wilson Bailly
Tutores: Ing. Larisa González Álvarez Ing. César Lage Codorniú
Ciudad de la Habana, 2010
DECLARACIÓN DE AUTORÍA
Declaro que soy el único autor de este trabajo y autorizo al Centro para la Informatización de Gestión de Entidades de la Universidad de las Ciencias Informáticas; así como a dicho centro para que hagan el uso que estimen pertinente con este trabajo.
Para que así conste firmo la presente a los ____ días del mes de ________ del año ________.
Ing. Larisa González Álvarez
_________________
Firma del Tutor
Ing. César Lage Codorniú
_________________
Firma del Tutor
Gregseen Wilson Bailly
_________________
Firma del Autor
… los que van al fondo de los problemas y no se cansan de preguntar y estudiar, están en condiciones de hacer descubrimientos y aplicarlos luego en beneficio de la humanidad. Sólo as í el hombre se hace gigante, pone la naturaleza en servicio de la humanidad.
Vilma Espín
Resumen
Cuba está dedicada al desarrollo de un sistema de planificación de recursos empresariales que abarque la gestión financiera de las entidades presupuestadas y empresariales del país. En aras del cumplimiento de dicho objetivo se propone la solución Finanzas como parte del producto Cedrux.
Esta investigación está orientada a conformar y formalizar la descripción de los elementos arquitectónicamente significativos y las decisiones tomadas por los arquitectos del proyecto ERP Cuba en la obtención de las vistas de sistema y datos de la solución Finanzas. Esta descripción arquitectónica está regida por los lineamientos del Documento Línea Base de Subsistema y los parámetros de arquitectura de datos definidos como artefactos fundamentales para el flujo arquitectónico del proyecto. Esta información arquitectónica será el punto de referencia para el soporte y mantenimiento del sistema. Además, permite la continuidad del proceso de desarrollo y servirá como referencia para la creación de nuevas versiones de la solución o de nuevos sistemas de gestión financiera de alcance nacional. Finalmente, con este trabajo se favorece que los interesados puedan comprender claramente cada parte del sistema.
La arquitectura propuesta es orientada a componentes, cada uno de ellos internamente aplica el patrón Modelo-Vista-Controlador combinado con elementos adicionales de validación y servicios que robustecen la solución. La solución de datos aplicada se rige por estándares de construcción que la hacen legible incluso para personas ajenas a la informática y facilita la capacidad de ejecución del sistema en otros motores de bases de datos.
Palabras claves: arquitectura, descripción arquitectónica, ERP, gestión financiera.
Índice
Introducción...1
Capítulo 1: Fundamentación teórica...6
1.1 Introducción...6
1.2 Arquitectura de software ...6
1.2.1 Estilos, patrones y lenguajes ...7
1.2.2 Corrientes de la arquitectura ...14
1.3 Documentación de la arquitectura ...15
1.4 Sistemas de Planificación de Recursos Empresariales...21
1.4.1 Características de un ERP ...21
1.4.2 Arquitectura de un ERP ...23
1.4.3 Estructuración de un ERP ...24
1.5 Estudio de algunos ERP y su solución financiera...25
1.6 Conclusiones...32
Capítulo 2: Vista de arquitectura de sistema de la solución Finanzas. ...33
2.1 Introducción...33
2.2 Análisis de los artefactos obtenidos en el análisis para la solución Finanzas ...33
2.2.1 Control y seguimiento de cuentas bancarias ...34
2.2.2 Administración de cajas y sus fondos ...35
2.2.3 Reconocimiento de derechos y obligaciones...37
2.3 Diseño de la solución Finanzas ...40
2.4 Estructura y empaquetamiento de los componentes ...41
2.5 Propuesta de vista de arquitectura de sistema para la solución Finanzas ...42
2.5.1 Subsistema Banco ...43
2.5.2 Subsistema Caja...45
2.5.3 Subsistema Cobros y Pagos ...47
2.5.4 Componente de integración comunfinanzas...48
2.6 Conclusiones...49
Capítulo 3: Propuesta de vista de arquitectura de datos para la solución Finanzas ...50
3.1 Introducción...50
3.3 Estándares utilizados en la solución Finanzas ...51
3.3.1 Subsistema Banco ...52
3.3.2 Subsistema Caja...53
3.3.3 Subsistema Cobros y Pagos ...55
3.3.4 Componente de integración comunfinanzas...56
3.4 Pruebas de concepto ...56
3.5 Conclusiones...58
Conclusiones Generales...59
Recomendaciones ...60
Bibliografía ...61
Referencias bibliográficas...64
Glosario de términos ...66
Anexos ...67
Índice de tablas
Tabla 1: Propuestas de estilos arquitectónicos...8
Tabla 2 : Vistas de arquitectura ...16
Tabla 3: Módulos financieros de las soluciones estudiadas ...29
Tabla 4: Trazabilidad componente estadocuenta-tablas del esquema del subsistema Banco ...53
Tabla 5: Trazabilidad componente configuracion-tablas del esquema del subsistema Caja ...54
Tabla 6: Trazabilidad componenteconciliacion-tablas del esquema del subsistema Cobros y Pagos..55
Índice de figuras
Figura 1: Estructura del patrón MVC aplicada a Cedrux ...13
Figura 2: Representación del modelo 4+1 vitas...17
Figura 3: Vistas definidas para el sistema Cedrux...18
Figura 4: Infraestructura de un ERP...24
Figura 5: Relación entre los conceptos cuenta bancaria y tipo de cuenta ...35
Figura 6: Tratamiento del concepto anticipo ...36
Figura 7: Tratamiento de concepto derecho u obligación...38
Figura 8: Paquete Banco ...39
Figura 9: Paquete Caja ...39
Figura 10: Paquete Caja ...40
Figura 11: Diseño de Finanzas...41
Figura 12: Estructura de un componente ...41
Figura 13: Mapa de componentes para el subsistema Banco...43
Figura 14: Mapa de componentes para el subsistema Caja ...45
Figura 15: Mapa de componentes para el subsistema Cobros y Pagos ...47
Figura 16: Estructura de comunfinanzas...49
Figura 17: Estructura arbólica de la tabla nom_talonariofnz ...56
Figura 18: Tablas utilizadas en la prueba para el requisito Anticipo y liquidación de gastos de viaje ..57
Introducción
La evolución de la informática y las telecomunicaciones ha propiciado la aplicación de tecnología de punta en diversas esferas de las ciencias. Dichos avances mejoran la calidad e imponen un alto índice de eficiencia en los procesos y servicios que son objeto de automatización, promoviendo la investigación científica y adjunto a ello la generación de grandes volúmenes de datos . Para gestionar los volúmenes de información generados, surgen los sistemas de gestión de información que cuentan con bases de datos capaces de almacenar grandes volúmenes de datos, interfaces amigables y fáciles de manipular, evitando el engorroso trabajo sobre la copia dura. Los sistemas de gestión han evolucionando de acuerdo con el desarrollo tecnológico hasta pretender rediseñar y optimizar los procesos de la empresa; y es en este punto en el que surgen los sistemas de planificación de recursos empresariales (ERP1, del inglés).
Cuba ha decido no quedarse al margen de la revolución tecnológica y la automatización de procesos, por lo que se encuentra inmersa en la labor de informatización de la mayor parte de la información y se enfrasca en la tarea de construir un sistema de planificación de recursos empresariales cubano (Cedrux) que sea aplicable a cualquier empresa dedicada a la producción de bienes o servicios. Los ERP son sistemas de gestión de información, que permiten automatizar e integrar los procesos de negocio de las áreas funcionales que contempla una organización. Dichos sistemas son extremadamente costosos, pero en el caso de una implantación exitosa pueden obtenerse una serie de beneficios, pues un solo sistema incluiría otros sistemas especializados en cada una de las áreas funcionales de la organización.
El ERP cubano tiene entre sus objetivos integrar la información financiera de una organización, unificando el juego de datos financieros de esa empresa con el de las diferentes unidades comerciales que interactúen con el software en una sola versión. La integración financiera de Cedrux se gestiona mediante la solución Finanzas, en la que están contenidos los subsistemas: Banco, Caja y Cobros y Pagos y el componente de integración comunfinanzas. Esta solución tiene a su cargo el control y seguimiento de las cuentas bancarias y los instrumentos bancarios asociados a ellas, el procesamiento de las operaciones que tienen lugar sobre los fondos monetarios depositados en cada caja y relaciona la entidad con los clientes y proveedores mediante el establecimiento de los derechos de cobro u obligaciones de pago que
1 Enterprise Resource Planning: Sistema de informac ión integral que permite la ejecuc ión y automatizac ión de los procesos de negocio de todas las áreas funcionales de un modo combinado.
contraen entre sí. Es importante señalar que la solución Finanzas realiza las operaciones financieras considerando la dualidad monetaria existente en Cuba, permitiendo a las entidades realizar operaciones en distintas monedas.
Esta solución se acoge a las guías generales establecidas para el proyecto ERP Cuba, lo que se conoce como arquitectura de software. Particularmente para la solución Finanzas debe desarrollarse una arquitectura que tenga en cuenta requerimientos de disponibilidad, escalabilidad y rendimiento. Esta arquitectura debe asegurar que los diagramas correspondientes reflejen claramente como se distribuyen e interactúan las partes que conforman el software. También englobará un proceso de descripción de los artefactos generados, capaz de nutrir a los desarrolladores y usuarios finales de un conjunto de información que exprese en detalles el sistema, la forma adecuada de operar con él, y permita corregir e interpretar los errores, así como conocer los procesos que tienen lugar en esta solución.
El ERP cubano es un sistema funcional en el que como en todo proceso de desarrollo, se tuvieron en cuenta qué variables podrían afectar la calidad del producto, fijándose o priorizándose el tiempo de desarrollo y haciéndose girar en torno a él, el costo y el alcance. En estas condiciones la fase correspondiente a la descripción arquitectónica se vio afectada, algo que en ese momento no tuvo gran connotación, pero con el crecimiento del sistema en cuanto a implementación comenzaron a avizorarse las formas para escalarlo y mantenerlo; y es en este punto donde se hace imprescindible contar con una descripción de los elementos de diseño y las decisiones arquitectónicas tomadas. A esta situación se suma la constante variación en el personal que conforma el equipo de desarrollo. Si el nuevo personal no dispone de la descripción arquitectónica puede verse limitada la continuidad del proceso de desarrollo.
La falta de descripción arquitectónica:
Provoca la carencia de una guía para otras etapas del desarrollo (diseño) y en general de la construcción del software.
Impide el correcto entendimiento del sistema a los interesados (usuarios, compradores, desarrolladores, etc.).
Obstaculiza la detección y reparación de los errores del sistema y sobre esta base, la construcción de nuevas versiones.
Dificulta el trabajo de mantenimiento y soporte del sistema.
Influye directamente en el fracaso de la aplicación después de haber sido desplegada, debido a que no es seguro que hayan sido cubiertos todos los requerimientos propuestos.
Por lo anteriormente expuesto el problema científico que motiva esta investigación es: El estado actual de la descripción arquitectónica de sistema y datos de la solución Finanzas, afecta la capacidad de entendimiento de los involucrados y por consiguiente el soporte y desarrollo de nuevas versiones del sistema.
Para resolver el problema anterior se define como objeto de estudio la: Arquitectura de sistema y datos, enmarcando la investigación en el campo de acción: Arquitectura de sistema y datos de la solución de Finanzas.
Este trabajo se traza como objetivo general: Construir las vistas de arquitectura de sistema y datos de la solución Finanzas para facilitar su entendimiento a los involucrados y apoyar el soporte y desarrollo de nuevas versiones del sistema. Para dar cumplimiento al objetivo general se derivan los objetivos específicos:
1. Realizar el marco teórico de la investigación.
2. Realizar la vista de arquitectura de sistema de la solución Finanzas.
3. Realizar la vista de arquitectura de datos de la solución Finanzas.
Para alcanzar estos objetivos se desarrollarán las siguientes Tareas Investigativas:
1. Sintetizar el estudio del estado del arte en materia de arquitectura de software y soluciones financieras para resumir el estado actual.
2. Procesar y evaluar la información obtenida de la investigación del tema y adoptar una posición.
3. Llevar a cabo un estudio de los artefactos generados en el análisis y que constituyen entrada al diseño.
4. Identificar y documentar la línea base de la solución Finanzas.
5. Evaluar los artefactos existentes para la arquitectura de datos de la solución Finanzas y generar los que faltan.
6. Actualizar el expediente de arquitectura de datos correspondiente a la solución Finanzas.
Esta investigación defiende la siguiente idea: Si se construyen las vistas de arquitectura de sistema y datos de la solución Finanzas se facilitará su entendimiento a los involucrados y apoyará el soporte y desarrollo de nuevas versiones del sistema.
Se utilizarán como Métodos de Investigación Científica los listados a continuación:
Analítico – Sintético
Para analizar el sistema descomponiéndolo en partes, de forma que se pueda determinar cuáles son sus componentes esenciales y las relaciones entre ellos, con el objetivo de lograr un mejor entendimiento y poder definir las deficiencias y mejoras que conducen a la obtención del resultado esperado.
Histórico – Lógico
Para determinar cómo ha evolucionado el sistema, cuál es su lógica interna y la teoría en la que se basó su desarrollo.
Entrevista
Realización de entrevistas a los analistas y arquitectos de datos de la solución Finanzas, para profundizar en el conocimiento y entendimiento del negocio.
El contenido del trabajo se estructura en 3 capítulos:
Capítulo 1. Fundamentación teórica.
En este capítulo se realiza un estudio del estado del arte de la arquitectura de software que brinda elementos relacionados con su evolución, principales tendencias, definiciones y estilos arquitectónicos más significativos en el desarrollo de sistemas empresariales actualmente. Se ofrece además, un estudio de las soluciones financieras con que cuentan algunos sistemas de planificación de recursos empresariales existentes
Capítulo 2. Vista de arquitectura de sistema para la solución Finanzas
Este capítulo ofrece un estudio de los artefactos generados en las fases previas al diseño arquitectónico que constituyen entrada para este flujo. Se generan también los artefactos que conforman la vista de arquitectura del sistema, con el objetivo de registrar las decisiones arquitectónicamente significativas que sustentan el desarrollo de la solución Finanzas.
Capítulo 3. Vista de arquitectura de datos para la solución Finanzas
En este capítulo se actualizan los artefactos que conforman la vista de arquitectura de datos, con el fin de dejar plasmada la solución de datos aplicada en la solución Finanzas y determinar cuan óptima resulta.
Capítulo 1: Fundamentación teórica
1.1 Introducción
En este capítulo se realiza un estudio de los aspectos concernientes a la arquitectura de software y los elementos fundamentales que define: los estilos, los patrones, los lenguajes y las vistas. Se resalta de este último elemento su función vital en el momento de describir la arquitectura. Se hace además, un análisis de algunos sistemas ERP que se encuentran vigentes, teniendo en cuenta la forma en que gestionan sus finanzas y la arquitectura que emplean.
1.2 Arquitectura de software
La arquitectura de software integra componentes, conectores, configuraciones y restricciones. Estos elementos son la base de los modelos o vistas que describen la arquitectura, mediante su identificación es posible establecer bajo qué estilos, patrones y condiciones tendrá lugar la dinámica del sistema. Existen diversas definiciones de arquitectura de software, lo que podría interpretarse como la existencia de una contrariedad respecto al tema, sin embargo, todas las definiciones emitidas de manera general describen y delimitan el trabajo del arquitecto del software.
El trabajo de un arquitecto de software se resume en la determinación correcta del fraccionamiento en componentes apropiados para el sistema, la determinación de módulos y el análisis de las herramientas y las unidades de software, para lograr establecer una arquitectura ajustada a las necesidades del proyecto.
Thomas G. Lane en el primer libro publicado por el Software Engineering Institute SEI referente a este tema, en 1990, define la arquitectura de software como:
“Arquitectura de software es el estudio de la estructura a gran escala y el rendimiento de los sistemas de software. Aspectos importantes de la arquitectura de un sistema incluye la división de funciones entre los módulos del sistema, los medios de comunicación entre módulos y la representación de la información compartida.” (Lane, 1990). Esta definición constituye una muestra de cómo los componentes, aquí llamados división de funciones entre módulos y los conectores denominados medios de comunicación, estaban haciéndose un lugar esencial dentro de la estructura de los sistemas.
Mary Shaw y David Garlan sugieren que las cuestiones estructurales incluyen organización a grandes rasgos y estructura global de control, protocolos para la comunicación, la sincronización y el acceso a datos, la asignación de funcionalidad a elementos del diseño, la distribución física, la composición de los elementos de diseño, escalabilidad y rendimiento, y selección entre alternativas de diseño. (Reynoso, 2004). En esta definición comienzan a manifestarse los otros dos aspectos por los que responde la arquitectura de software, dígase configuración y restricciones, pues esta, sin abandonar la organización estructural del sistema, pretende incluir en qué condiciones los componentes de esa organización se relacionarán.
Sin entrar en detalles David Garlan establece que la arquitectura de software constituye un puente entre el requerimiento y el código, ocupando el lugar que en los gráficos antiguos se reservaba para el diseño.
(Reynoso, 2004)
Debido a que las definiciones anteriores no agrupaban los cuatro elementos fundamentales de la arquitectura de software, la definición que guiará esta investigación será la que brinda el Instituto de Ingenieros Electricistas y Electrónicos en el documento Std 1471-2000. Esta definición ha sido adoptada también por Microsoft, y reza así:
“La Arquitectura de Software es la organización fundamental de un sistema encarnada en sus componentes, las relaciones entre ellos y el ambiente y los principios que orientan su diseño y evolución”.
(Reynoso, 2004)
Sobre la base de esta última definición puede afirmarse que la arquitectura de software ideal es aquella capaz de conducir una aplicación al éxito, mediante el establecimiento de elementos que especifiquen normas para su construcción de la manera más conveniente.
1.2.1 Estilos, patrones y lenguajes
Uno de los elementos especificados por la arquitectura de software son los estilos arquitectónicos, los que permiten aclarar la estructura de la solución aplicada a un sistema. Normalmente, un estilo no define los patrones posibles de las aplicaciones, ni permite evaluar las arquitecturas alternativas proponiendo
ventajas y desventajas conocidas ante diferentes conjuntos de requerimientos no funcionales. Los estilos se encuentran enfocados a las maneras de organización del sistema.
Mary Shaw y Paul Clements identifican los estilos arquitectónic os como un conjunto de reglas de diseño que identifica las clases de componentes y conectores que se pueden utilizar para componer un sistema o subsistema, junto con las restricciones locales o globales de la forma en que la composición se lleva a cabo. (Reynoso, 2004)
Son muchos los autores que han ofrecido sus apreciaciones sobre el tema de los estilos arquitectónicos.
Algunas de las agrupaciones propuestas se muestran en la Tabla 1:
Tabla 1: Propuestas de estilos arquitectónicos.
(Reynoso, 2004)
Autor Propuesta de estilos
Mary Shaw y David Garlan 1994
Tubería y filtros
Organización de abstracción
de datos y orientación a
objetos
Invocación implícita, basada en
eventos
Sistema s en capas
Repositorios Otros
Buschmann , Meunier, Rohnert, Sommerlad y Stal 1996
Del fango a la estructura
Sistema s distribuidos
Sistema s interactivos
Sistema s adaptables
_ _
Bass, Clements y Kazman 1998
Flujo de datos
Llamado y retorno
Componente s independientes
Centrados en datos
Máquina virtual
_
Roy Fielding 2000
Estilos de flujo de
datos
Estilos de replicación
Estilos jerárquicos
Estilos de código
móvil
Estilos peer- to-peer
Transferencia de estado representacio-
nal (REST)
David Garlan 2001
Flujo de datos
Llamada y Retorno
Procesos interactivos
Repositorio Orientado a
Datos
Datos Compartidos
Jerárquicos
Debido a la diversidad de agrupaciones existentes esta investigación se acoge a la agrupación de los estilos más representativos y vigentes realizada por Reynoso y Kiccillof en su artículo “Estilos y Patrones en la Estrategia de Arquitectura de Microsoft”:
Estilos de Flujos de Datos.
Tubería y filtros.
Estilos Centrados en Datos.
Arquitecturas de pizarra o repositorio.
Estilos de Llamada y Retorno.
Modelo-Vista-Controlador (MVC).
Arquitectura en capas.
Arquitecturas orientadas a objetos.
Arquitecturas Basadas en Componentes.
Estilos de Código Móvil.
Arquitecturas de máquinas virtuales.
Estilos Heterogéneos.
Sistemas de control de procesos.
Arquitecturas basadas en atributos.
Estilos Peer-to-Peer.
Arquitecturas basadas en eventos.
Arquitecturas orientadas a servicios (SOA).
Arquitecturas basadas en recursos.
Otro elemento son los patrones arquitectónicos, que están asociados a las características que distinguen a cada objeto o clase según el entorno establecido para el sistema. Cada patrón contempla para la descripción de un problema, un esbozo de una solución válida.
Un patrón arquitectónico se define por un modelo de sistema que captura intuitivamente la forma en que están integrados los elementos, componentes, conectores que establecen las reglas de la interacción entre los componentes y una estructura de control que gobierna la ejecución. (Reynoso, 2004)
Un estilo puede ser descrito a través de diagramas o del lenguaje natural, aunque lo más factible sería utilizar un lenguaje de descripción arquitectónica (ADL). Los ADL funcionan como un manual que provee estándares de documentación, mediante los que se pueden crear notaciones para la representación de los elementos de la arquitectura. Un ADL es un lenguaje descriptivo de modelado que se focaliza en la estructura de alto nivel de la aplicación antes que en los detalles de implementación de sus módulos concretos (Kiccillof, 2004). Existen muchos de estos lenguajes por ejemplo: Acme que apoya el intercambio de decisiones arquitectónicas, Adage que asiste la descripción de los marcos de trabajo arquitectónicos de navegación y orientación aérea y SADL que proporciona una base formal para el refinamiento de la arquitectura.
Los lenguajes de descripción arquitectónica presentan diversos problemas para su utilización, no son amigables para presentar la arquitectura a personas ajenas a la construcción del software, no tienen herramientas ni metodologías de apoyo, algunos se encuentran especializados solo en un tipo particular de sistemas, sólo tienen en cuenta una sola estructura del sistema. (Gil, 2006).
Debido a lo expuesto anteriormente la mayoría de las empresas usan el Lenguaje Unificado de Modelado (UML), pues está sustentado por metodologías que posibilitan la representación de una arquitectura, mediante una serie de diagramas en los que estarán contenidos cada componente y su tipo, las restricciones a las que está sujeto y su relación con otras estructuras. UML, mediante la combinación del desarrollo incremental e iterativo, define la función del sistema aplicando un enfoque basado en escenarios (desde el punto de vista del usuario). Entonces acopla la función con un marco de trabajo arquitectónico que identifica la forma que tomará el software. (Pressman,2002)
El equipo central de arquitectura del proyecto ERP Cuba ha definido que al sistema Cedrux le sean aplicados los fundamentos del estilo de Arquitectura basada en componentes, siguiendo los principios del estilo arquitectónico Arquitectura orientada a servicios y la estructura ofrecida por el patrón Modelo-Vista- Controlador. (Campins, 2009) El modelamiento y descripción del sistema no se realizará mediante un ADL, se utilizará el UML.
Arquitecturas basadas en componentes
En este estilo el sistema será descompuesto en componentes, promoviendo el desarrollo y utilización de componentes reutilizables. Cada componente es reutilizable desde el punto de vista de su posible uso en un contexto diferente a aquel para que el que fue concebido. El concepto central de esta arquitectura es el componente:
“Un componente es una unidad de composición de aplicaciones software, que posee un conjunto de interfaces y un conjunto de requisitos, y que ha de poder ser desarrollado, adquirido, incorporado al sistema y compuesto con otros componentes de forma independiente, en tiempo y espacio” (Fuentes, 2003)
Cada componente definido contará con una interfaz que determina tanto las operaciones que el componente implementa como las que precisa utilizar de otros componentes durante su ejecución.
Arquitectura orientada a servicios
Este estilo está orientado al logro de la integración de aplicaciones independientes de forma que desde la red pueda accederse a sus funcionalidades, que serán tratadas como servicios. Debido al planteamiento anterior se hace necesario que la interfaz de cada componente se defina bajo un estándar; garantizando que un servicio desarrollado en CSharp pudiera ser usado por una aplicación Java. La arquitectura orientada a servicios se basa en contratos, donde el proveedor establece las reg las de comunicación, el transporte y los datos de entrada y salida que serán intercambiados por ambas partes. Los principios que sustentan este estilo son: (Erl, 2008)
Los servicios deben ser reusables: Todo servicio debe ser diseñado y construido pensando en su reutilización dentro de la misma aplicación, dentro del dominio de aplicaciones de la empresa o incluso dentro del dominio público para su uso masivo.
Los servicios deben proporcionar un contrato formal: Todo servicio desarrollado debe proporcionar un contrato en el cual figuren: el nombre del servicio, su forma de acceso, las funcionalidades que ofrece, los datos de entrada de cada una de las funcionalidades y los datos de salida.
Los servicios deben tener bajo acoplamiento: Es decir, que los servicios tienen que ser independientes los unos de los otros. Para lograr ese bajo acoplamiento, lo que se hará es que cada
vez que se vaya a ejecutar un servicio, se accederá a él a través del contrato, logrando así la independencia entre el servicio que se va a ejecutar y el que lo llama.
Los servicios deben permitir la composición: Todo servicio debe ser construido de tal manera que pueda ser utilizado para construir servicios genéricos de más alto nivel, el cual estará compuesto de servicios de más bajo nivel.
Los servicios deben de ser autónomos: Todo servicio debe tener su propio entorno de ejecución.
De esta manera, el servicio es totalmente independiente y nos podemos asegurar que así podrá ser reutilizable desde el punto de vista de la plataforma de ejecución.
Los servicios no deben tener estado: Un servicio no debe guardar ningún tipo de información para evitar problemas de inconsistencia de datos. La solución es que un servicio sólo contenga lógica y que toda información esté almacenada en algún sistema de información sea del tipo que sea.
Los servicios deben poder ser descubiertos: Todo servicio debe poder ser descubierto de alguna forma para que pueda ser utilizado, consiguiendo as í evitar la creación accidental de servicios que proporcionen las mismas funcionalidades.
Modelo-Vista-Controlador
El patrón conocido como Modelo-Vista-Controlador separa el modelado del dominio, la presentación y las acciones basadas en datos ingresados por el usuario en tres clases diferentes: El modelo en el que estará la lógica de negocio de nuestra aplicación, la vista que agrupa las clases y ficheros que tengan que ver con la presentación y el controlador que al recibir los eventos de la interfaz, se encarga de llamar en el modelo al experto del negocio que sabe que es lo que hay que hacer con la petición del usuario. Una vez que el modelo ha realizado su tarea se lo comunica al controlador pudiendo además transferirle algunos datos a este. El controlador entonces le dice a la vista o interfaz que se actualice con los c ambios hechos en el modelo. Puede suceder que al ocurrir un cambio en el modelo él mismo envíe una notificación a la vista para que se actualice. (Equipo de debug_mode=ON, 2009)
Esta separación permite construir y probar el modelo independientemente de la representación visual.
Este estilo soporta múltiples vistas, se adapta fácilmente a los cambios, pero aumenta ligeramente la complejidad de la solución e implica un alto costo de actualización.
Figura 1 : Estructura del patrón MVC aplicada a Cedrux
Este estilo fue reimplementado por el equipo central de arquitectura, de manera que como se muestra en la Figura 1, la comunicación entre la vista y el modelo únicamente puede efectuarse mediante controlador.
Lenguaje Unificado de Modelado (Unified Modeling Language, UML)
UML es un lenguaje que proporciona un vocabulario y reglas para permitir una comunicación. Este lenguaje se centra en la representación gráfica de un sistema. Los objetivos de UML son muchos, pero se pueden sintetizar sus funciones (Orrallo, 2002):
Visualizar: UML permite expresar gráficamente un sistema de forma que otro lo puede entender.
Especificar: UML permite especificar cuáles son las características de un sistema antes de su construcción.
Construir: A partir de los modelos especificados se pueden construir los sistemas diseñados.
Documentar: Los propios elementos gráficos sirven como documentación del sistema desarrollado que pueden servir para su futura revisión.
Aunque UML está pensado para modelar sistemas complejos con gran cantidad de software, el lenguaje es lo suficientemente expresivo como para modelar sistemas que no son informáticos, como flujos de trabajo (workflow) en una empresa, diseño de la estructura de una organización y por supuesto, en el diseño de hardware (Orrallo, 2002).
1.2.2 Corrientes de la arquitectura
Actualmente se pueden distinguir a grandes rasgos unas seis tendencias de la arquitectura de software (Reynoso, 2004):
Arquitectura estructural, basada en un modelo estático de estilos, ADLs y vistas
Es la tendencia fundacional y clásica de la disciplina. Está representada por figuras como: Mary Shaw, Paul Clements, David Garlan, etc. Dentro de ella existen algunas contradicciones en cuanto a la inclusión o no del modelo de datos como parte de la arquitectura. No considera los términos clases y objetos, ni que el diseño arquitectónico coincida con la configuración explicita de la aplicación. Pueden apreciarse tres modalidades en cuanto a la formalización: oficialización a través de diagramas o descripciones verbales, oficialización mediante lenguajes de descripción de arquitectura y oficialización usando lenguajes formales como el CHAM y Z.
Arquitectura como etapa de ingeniería y diseño orientada a objetos
Esta modalidad defiende una arquitectura de software orientada a aspectos formales en el momento del desarrollo. Está representada por figuras como James Rumbaugh, Ivar Jacobson, Grady Booch, Craig Larman y se encuentra directamente ligada al mundo de UML y Rational. Considera el nivel esencial de la abstracción y el ocultamiento de la información y confunde la arquitectura con el modelado, el diseño y los estilos con los patrones. Se concentra en el modelado y tiende al exceso de diagramas minuciosamente detallados.
Estructuralismo arquitectónico radical
Se trata de un desprendimiento de la corriente anterior, que asume una actitud más confrontativa con el mundo UML. En el seno de este movimiento hay al menos dos tendencias, una que excluye de plano la relevancia del modelado orientado a objetos para la arquitectura de software y otra que procura definir nuevos metamodelos y estereotipos de UML como correctivos de la situación.
Arquitectura basada en patrones
En esta modalidad predomina cierta tolerancia hacia modelos de procesos tácticos y las premisas de la programación extrema. Esta arquitectura reconoce la importancia de un modelo de datos que resuma la historia del diseño. Está basada en el texto sobre patrones de la serie POSA de Buschmann. El diseño
consiste en identificar y articular patrones preexistentes, que se definen en forma parecida a los estilos de arquitectura.
Arquitectura procesual
Esta tendencia está respaldada por el SEI y figuras como Rick Kazman, Len Bass, Paul Clements, Felix Bachmann, etc. Desde comienzos del siglo XXI trata de implantar modelos de ciclo de vida y técnicas de refinamiento de requerimientos, diseño, análisis, selección de alternativas, validación, comparación, estimación de calidad y justificación económica específicas para la arquitectura de software; aunque contiene otras variantes que caracterizan las etapas del proceso desde otros puntos de vista (extracción de arquitectura, generalización y reutilización).
Arquitectura basada en escenarios
Es la corriente más nueva. Rescata el vínculo de la arquitectura con los requerimientos y la func ionalidad del sistema, un poco perdido en la arquitectura estructural clásica. Habitualmente se utilizan diagramas de casos de uso UML como herramienta informal, los casos de uso no están orientados a objetos. Algunas figuras representativas de esta modalidad son: Philips Research, Mugurel Lonita, Dieter Hammer, Jan Bosch etc.
El ERP cubano se fundamenta en una guía que contempla los elementos arquitectónicos mencionados en la modalidad arquitectónica procesual que promueve el SEI. La modalidad procesual solo se ajusta a algunas distinciones del sistema como la relación con los requerimientos y los métodos de evaluación, por lo que incorpora elementos arquitectónicos de otras corrientes como los escenarios arquitectónicos y las vistas.
1.3 Documentación de la arquitectura
Definir la arquitectura es tan importante como trasmitirla, pues si los interesados (usuarios, integrantes del equipo de desarrollo, etc.) no entienden la arquitectura se pierde el esfuerzo de haberla hecho.
Documentar el software equivale a la conservación de su historia, simplifica la utilización del software por parte del usuario y disminuye los costos de operación y ejecución del proyecto. Primeramente debe definirse una metodología de desarrollo que guíe el proceso a seguir, luego ese modelo podrá dividirse en
los varios tipos de vistas que sustentarán el sistema. Mediante estas vistas cada decisión tomada podrá ser justificada. Cada vista estará orientada a diferentes funcionalidades y requerimientos de calidad importantes para el sistema.
Amplias son las propuestas que existen en cuanto a las vistas que deberían conformar un sistem a como se muestra en la Tabla 2
Tabla 2 : Vistas de arquitectura
Propuestas para definir vistas de la arquitectura
Vista s Microsoft
Vista Conceptual Vista Lógica Vista Fí sica
Vista Implementación
SEI (´02): Racionalización de Vista s
Vista de Asignación
Vista Componente y Conector Vista Modular
“Software Systems Architecture” por Nick Rozanski y Eóin Woods
Vista funcional Vista de información Vista de concurrencia Vista de desarrollo Vista de despliegue
Siemens Corporate Research (´95)
Vista conceptual Vista de módulos Vista de ejecución Vista de código
David Parnas (´74)
Estructura de módulos Estructura de uso Estructura de procesos
Uno de los modelos más aceptados a la hora de establecer las vistas necesarias para describir una arquitectura de software es el modelo 4+1 como se muestra en la Figura 2: (Kruchten, 1995)
La vista lógica describe el modelo de objetos del diseño. La vista de procesos describe los aspectos de concurrencia y sincronización del diseño. La vista física describe el mapeo del software en el hardware y refleja los aspectos de distribución. La vista de desarrollo describe la organización estática del software en su ambiente de desarrollo. Escenario ilustra las descripciones arquitectónicas en un conjunto de casos de uso o escenarios, a partir de los que evolucionará el sistema.
Figura 2 : Representación del modelo 4+1 vitas (Kruchten, 1995)
Estas clasificaciones en casos de sistemas muy complejos no resultan apropiadas, debido a que no contemplan algunos aspectos por ejemplo Kruchten en su modelo 4+1 vista, descuida los temas referidos a datos, seguridad, presentación y sistema. David Parnas, trata elementos a los que Siemens Research hace adiciones, pero ninguno incluye los temas que aborda el SEI, sin embargo, a este le faltan los aspectos relacionados con la presentación, datos y seguridad. Por su parte Perry y Wolf proponen vistas que enfatizan ciertos aspectos arquitectónicos útiles para diferentes propósitos, pero es una definición no muy específica. Por su parte Nick Rozanski y Eóin Woods, abordan 5 vistas bastante abarcadoras, pero tampoco tratan las disciplinas de seguridad e integración.
Pueden existir modelos simplificados que se ajusten al contexto, pero no todos los sistemas requieren de todas las vistas. Por ejemplo para un simple procesador pudiese eliminarse la vista de despliegue y para programas muy pequeños, puede obviarse la vista de implementación, aunque si el software es muy complejo entonces para mejor organización se recomienda añadir las vistas de datos y seguridad.
El ERP cubano, apoyándose en el modelo de 4+1 vista de Kruchten, las propuestas de vistas arquitectónicas de Microsoft y los modelos Microsoft Solution Framework (MSF) y Views and Beyond (V&B) Approach del SEI define tres vistas principales (Figura 3):
Figura 3 : Vistas definidas para el sistema Cedrux (Fernández, 2010)
Vista de sistema
La vista de arquitectura de sistema es una de las disciplinas más complejas dentro de la arquitectura del software, esta es responsable de definir cohesionados, acoplados e interrelacionados los elementos computacionales del producto. Esta vista representa una proyección simétrica de alto nivel de los procesos de negocio o arquitectura de negocio que se trabaja, expresada en elementos, conectores, configuraciones y restricciones.
Establece además, los principios de empaquetamiento del diseño arquitectónico de un sistema, que tienen alto impacto en el diseño de la solución, ya que esta actividad está asociada con los niveles de colaboración de los elementos computacionales, los principios de reutilización y los niveles de abstracción y encapsulamiento en función del problema que se modela. Una adecuada selección de los mismos suele
implicar mejor organización del equipo de desarrollo y paralelización de las tareas de implementación, más facilidad en los procesos de gestión de configuración de s oftware y una granulación adecuada de las partes del software con implicación positiva en la gestión de la integración continua y el propio mantenimiento del sistema. Otros elementos a tener en consideración durante los procesos de empaquetamiento son las colaboraciones entre los elementos de software, principios de integración y los niveles de accesos a recursos o componentes horizontales. Esta vista comprende otras tres:
Vista de datos
La vista de datos tiene la responsabilidad de diseñar las soluciones de datos e integración de los mismos en cada uno de los subsistemas. Esta vista define también metodologías para la definición de soluciones de réplica, el control y actualización de versiones de la base de datos (BD), es responsable de la construcción y el mantenimiento del script de instalación de la BD, así como de la gestión de los servicios que esta ofrece. Igualmente esta vista establece la metodología de trabajo de la arquitectura de datos que contiene las métricas, estándares e indicadores que guiarán el desarrollo. Esta vista constituye una guía para los arquitectos de datos asegurando para ellos un completo plan de formación.
Vista de integración
La vista de integración establece los protocolos de comunicación y las reglas de intercambio de información mediante el análisis de los procesos del negocio. Identifica los conceptos m ás críticos en la integración de los procesos del negocio; determinando cuales tendrán mayor nivel de incidencia en los procesos de integración. Esta vista tiene en cuenta las entradas y salidas de cada componente identificado por la arquitectura de sistema, lo que permite identificar los lazos de colaboración entre componentes y clasificarlos según la estrategia de integración identificada por el grupo de arquitectura, construyéndose de esta manera la matriz de integración del negocio.
Vista de Componentes
La vista de componentes define bajo que clasificación quedarán estandarizados los componentes definidos por el proyecto. Se encarga además, de especificar de cada componente sus características y su composición estructural interna.
Vista tecnológica
La vista tecnológica garantiza un soporte tecnológico para el desarrollo de las configuraciones que propone el resultado de la arquitectura de sistema, así como las bases tecnológicas para los marcos de trabajo especializados de la arquitectura de sistema o de otras áreas como la integración. Es el área responsable de identificar las tecnologías y recursos a usar en la realización del software. También define la factibilidad técnica del producto. En esta disciplina se define la mejor arquitectura posible utilizando una tecnología en particular, igualmente es aquí donde se definen las soluciones técnicas para la optimización del software, es decir, para garantizar la portabilidad, flexibilidad y rendimiento del software.
Vista de presentación
La vista de presentación tiene como propósito la búsqueda de mejores diseños para la presentación de la información y su comprensión. Esta vista prioriza la usabilidad, que estudia el conjunto de características del diseño y funcionamiento de una interfaz de usuario, para obtener una correcta operación y comprensión de los contenidos. Es la disciplina encargada del estudio, análisis, organización, disposición y estructuración de la información o presentación en espacios de información y de la selección y presentación de los datos en los sistemas de información interactivos y no interactivos.
Vista de seguridad
La vista de arquitectura de seguridad sirve de guía para el desarrollo y norma todos los aspectos a tener en cuenta en cada fase: las políticas de codificación segura, los estándares de validación de los datos, el grado de fortaleza de las claves de los usuarios del sistema y de la BD, configuración s egura para el servidor de datos de aplicaciones, del lenguaje de programación y de la herramienta de control de versiones, protocolos de comunicación segura, políticas de salvas de seguridad, ofuscador de código y mecanismo de comprobación de integridad de la estructura de la base de datos y de las aplicaciones web.
Esta área se encarga de establecer toda la política de seguridad a seguir en las diferentes fases o entornos del sistema. Para lograrlo debe identificar claramente todas las debilidades que puedan s er aprovechadas para un ataque.
Vista de infraestructura
La vista de infraestructura es responsable de mantener el entorno tecnológico y los usuarios finales. Esta vista se encarga de planificar el hardware, la red, el software básico como el sistema operativo, la base de datos, y también herramientas de monitoreo que ayuden a controlar que estas funcionen sin problemas.
De acuerdo con sus vistas Cedrux define un Expediente tecnológico en el que se acumulará la documentación de la arquitectura que ampara la funcionalidad del sistema. Este expediente actualmente cuenta con carpetas como: Arquitectura de Datos, Arquitectura de Infraestructura, Arquitectura de Presentación, Arquitectura de Seguridad, Arquitectura de Sistema y Arquitectura de Tecnología en cada una de ellas se guardan los artefactos que se generan según lo establecido en cada vista, teniendo en cuenta el modelo de desarrollo establecido para el proyecto.
1.4 Sistemas de Planificación de Recursos Empresariales
Sistema de planificación de recursos empresariales es un término empleado para describir un sistema de información empresarial integrado que unifica y ordena toda la información de la empresa en un solo lugar; de este modo cualquier suceso queda a la vista de forma inmediata, posibilitando la toma de decisiones de forma más rápida y segura, acortando los ciclos productivos. Con un ERP aumenta el control de la empresa y se incrementa la calidad de los servicios y productos. Estos sistemas son capaces de eliminar las barreras inter-departamentales, integrar la información y los procesos de negocio de una organización y promover el uso adecuado de los recursos, organizar el flujo de información entre las áreas funcionales de la organización. Este tipo de software garantiza el flujo de datos por toda la empresa eliminando los problemas asociados a la falta de información.
Los sistemas ERP se describen como “Paquetes de sistemas de información configurables que integran información y procesos de negocio basados en la información dentro y entre áreas funcionales en una organización”. (Rodríguez, 2002)
1.4.1 Características de un ERP
Las características que distinguen a un ERP de cualquier otro software empresarial, es que deben ser sistemas integrales, modulares y adaptables. (Arquitectura Empresarial para el Valor en Contribuciones a la Economía, 2009)
Integrales
Permiten controlar los diferentes procesos de la compañía entendiendo que todos los departamentos de una empresa se relacionan entre sí, es decir, que el resultado de un proceso es punto de inicio del siguiente. En una compañía, el que un cliente haga un pedido representa que se cree una orden de venta que desencadena el proceso de producción, de control de inventarios, de planeación de distribución del producto, cobranza y por supuesto sus respectivos movimientos contables. Si la empresa no usa un ERP, necesitará tener varios programas que controlen todos los procesos m encionados, con la desventaja de que al no estar integrados, la información se duplica, crece el margen de contaminación en la información (sobre todo por errores de captura) y se crea un escenario favorable para malversaciones. Con un ERP, simplemente se captura el pedido y el sistema se encarga de todo lo demás, por lo que la información no se manipula y se encuentra protegida.
Modulares
Los ERP entienden que una empresa es un conjunto de departamentos que se encuentran interrelacionados por la información que comparten y que se genera a partir de sus procesos. Una ventaja de los ERP, tanto económica como técnica es que la funcionalidad se encuentra dividida en módulos, los cuales pueden instalarse de acuerdo con los requerimientos del cliente. Ejemplo: Ventas, Materiales, Finanzas, Control de Almacén, etc.
Adaptables
Los ERP están creados para adaptarse a la teoría de cada empresa. Esto se logra por medio de la configuración o parametrización de los procesos de acuerdo con las salidas que se necesiten de c ada uno. Por ejemplo, para controlar inventarios, es posible que una empresa necesite manejar la partición de lotes pero otra empresa no. Los ERP más avanzados suelen incorporar herramientas de programación de cuarta generación para el desarrollo rápido de nuevos procesos. La configuración es el valor añadido fundamental que se debe hacer con cualquier ERP para adaptarlo a las necesidades concretas de cada empresa.
Otras características no menos importantes son: (Aravena, 2008)
Base de datos centralizada por lo que pueden integrar los datos de toda la empresa, entregando una amplia visión de ésta a la administración.
En un sistema ERP los datos se ingresan sólo una vez y deben ser consistentes, completos y comunes.
Suele haber un software para cada unidad funcional.
Al ser software de tipo universal, están dotados de las mejores prácticas aplicadas en el mundo.
Las interfaces son estándar con otras aplicaciones, por lo que no existen complicaciones al interactuar con aplicaciones de distintos proveedores, siempre y cuando sean compatibles.
No existe dependencia del equipo en que se instala, dando a la empresa la libertad de elegir los equipos informáticos necesarios y los sistemas operativos, de tal manera que pueda aprovecharse al máximo la tecnología existente.
1.4.2 Arquitectura de un ERP
Los sistemas de planificación de recursos empresariales no han estado exentos del desarrollo tecnológico, adjunto a él, han evolucionado no solo en cuanto a los servicios que prestan, también ha mejorado la arquitectura a la que responden hoy en día este tipo de software. En los 80 cuando surgieron se implantaban con la arquitectura cliente-servidor, luego comenzaron a desarrollarse bajo los fundamentos de la arquitectura de tres capas y con la aparición de la Internet, las arquitecturas tecnológicas evolucionaron al ambiente web y sus arquitecturas fueron multicapas.
Los sistemas de ventajas competitivas se fundamentan en la automatización de los procesos de negocio que están soportados en dos infraestructuras: la infraestructura operacional de negocios y la infraestructura técnica. Por tanto, la infraestructura de un sistema ERP se sustenta por diferentes recursos tecnológicos de hardware y software y diferentes especialidades dentro del campo de la informática. La Figura 4 muestra una arquitectura genérica para los sistemas de planificación de recursos empresariales:
Figura 4 : Infraestructura de un ERP (Rodríguez, 2002)
1.4.3 Estructuración de un ERP
La conformación de un sistema de planificación de recursos empresariales habitualmente se basa en los 6 procesos primordiales en una empresa: Comercio, Finanzas, Inventarios, Manufactura, Recursos Humanos y Contabilidad. Convenientemente con estos procesos un ERP se estructura en módulos que están a cargo de la funcionalidad.
Un sistema del tipo ERP, está formado por un conjunto finito de módulos que pueden adquirirse total o parcialmente. Hay en general tres grandes grupos, el primero corresponde al área financiera, un segundo grupo del área logística y finalmente un grupo del área Recursos Humanos. (Vera, 2006)
Los módulos del área financiera ofrecen una visión completa de las funciones contables y financieras, incluyendo un amplio sistema de información y de generación de informes que facilite a los ejecutivos una mayor rapidez para la toma de decisiones. Estos módulos se describen a continuación:
Módulo de Gestión Financiera: Proporciona las funciones que controlan el aspecto operativo de la contabilidad general y la información financiera de la empresa. Se conecta e integra con otros módulos
financieros como la tesorería y la contabilidad de costos, así como con otras aplicaciones de recursos humanos.
Módulo Contabilidad de Costos: Es utilizado para presentar las estructuras de costos de las empresas y los factores que influyen en ellos, lo que genéricamente se conoce como contabilidad interna de las organizaciones. Es decir, abarca los movimientos de costos e ingresos de la organización.
Módulo Corporativo: Es una importante herramienta para la toma de decisiones, integra los datos proporcionados por el resto de las aplicaciones financieras. Se encarga de monitorear los factores críticos del funcionamiento de una organización, así como las cifras clave de la empresa desde el punto de vista del auditor.
Módulo Gestión de Inversiones: Este fue introducido por SAP (mayor productora de software para aplicaciones de negocio denominada Sistemas, Aplicaciones y Productos para Procesamiento de Datos ) en la versión 3.0, está diseñado para planificar y gestionar los presupuestos y proyectos de inversión de capital. Permite realizar una planificación detallada capaz de monitorear continuamente la evolución de las inversiones tales como: costos planificados, cifras reales, recursos disponibles, etc.
Módulo Tesorería: Integra las previsiones y gestión de recursos de caja con las aplicaciones financieras y logísticas. Proporciona las herramientas necesarias para analizar presupuestos, procesos de asientos contables electrónicos, análisis del mercado de divisas, etc.
1.5 Estudio de algunos ERP y su solución financiera
Los sistemas de gestión de finanzas concentran toda la información financiera de la empresa, integrando los movimientos de fondos registrados por ventas, cobros, compras y pagos. Posibilitan la definición de movimientos de fondos (cajas, cuentas bancarias, cheques de terceros, documentos a cobrar, obligaciones a pagar, etc.), así como el procesamiento de aportes de socios, saldos iniciales, devolución de préstamos, adelantos al personal, sueldos, retiros de socios e impuestos. Generan todos los elementos necesarios para registrar los movimientos que facilitan el análisis de los saldos ac tuales y los resultados futuros. Permiten la identificación y el seguimiento de estados de carteras de valores y documentos . Emiten informes financieros flexibles que permitan analizar el flujo de caja, las causas y los medios de
pago, el estado de las distintas carteras de valores y los estados bancarios. Administran el proceso de conciliación bancaria y los distintos modelos de presupuestos financieros.
En nuestro país se han desarrollado y usado algunos sistemas de gestión financiera por ejemplo el SABIC (Sistema Automatizado para la Banca Internacional de Comercio), que es un sistema formado por un módulo central (encargado del control de accesos, actualización de ficheros y los procesos de inicio y cierre del día contable) y otros secundarios (módulos de transacciones, listados y procesos); caracterizado por la contabilización en tiempo real, la contabilización multimoneda y la generación automática de los asientos contables. También el VERSAT-Sarasola que es un sistema integrado de gestión económica con el objetivo de brindar una herramienta de planificación, control y análisis de la gestión económica, está formado por subsistemas (nóminas de salarios, presupuesto maestro, configuración, activos fijos, costos y procesos, inventarios, control y pago, caja y banco, administración, contratación y facturación) que giran alrededor de la Contabilidad General.
La mayoría de los sistemas ERP contemporáneos incluyen un software para la gestión financiera y adjunto a ello, según los procesos de negocio considerados, los módulos que se encargarán de la funcionalidad. Algunos de ellos usan software libre como:
Compiere: es una solución 100% Java sobre base de datos Oracle, con servidor de aplicaciones JBOSS.
Utiliza como base de datos PostgreSQL u Oracle y está desarrollado utilizando la herramienta OpenACS basada a su vez en el servidor web AOLserver. Se ejecuta bajo la licencia pública Compiere (CPL), que permite el paso a privativo de dicho software transcurridos dos años desde su fecha de lanzamiento.
Mantiene una arquitectura modelo-vista-controlador, basada en web y en la interfaz de usuario. Considera cada cliente como una entidad que tiene la posibilidad de ejecutar transacciones, las cuales estarán asociadas a un documento (facturas de venta, recibo de materiales, documentos de entregas, pagos a proveedores o recibos de clientes). Este sistema se organiza en procesos de negocio y no en módulos.
Los procesos referentes a la gestión financiera Tabla 3, se encargan de administrar las órdenes de ventas, facturar y recepcionar pagos en efectivo, crear órdenes de compra, procesar las facturas de los proveedores y pagos efectuados, efectuar la conciliación bancaria y libros de caja, cubrir las entradas contables y el costeo de recursos.
Entre las desventajas de este software pueden considerarse que está específicamente desarrollado para el mercado anglosajón, necesita tecnología propietaria para funcionar (librerías de ficheros PDF y bibliotecas Sun Microsystems). Además, no cuenta con los módulos de Recursos Humanos y Sueldos que son de gran importancia para empresas constructoras. Otro punto en contra es que la versión de libre distribución se encuentra en inglés que limita de cierta manera el buen uso y manejo del ERP, es posible obtenerlo en español, pero hay que cancelar la Licencia Comercial.
Openbravo: Solución creada a partir del código de Compiere, por lo que está desarrollada en Java siguiendo la filosofía MVC. Licenciado bajo Openbravo Public License Version 1.1 (”OBPL”) (adaptación de la licencia libre Mozilla Public License). Se ejecuta sobre Apache y Tomcat, soporta bases de datos Oracle y PostgreSQ. Utiliza tecnologías aunque modernas, confiables como: Javascript, SQ L y PL/SQL, XML, HTML, con arquitectura cliente/servidor. La solución de contabilidad proporcionada por Openbravo ERP está diseñada para minimizar la introducción manual de datos por parte del usuario. El área financiera (ver estructura en la Tabla 3) actúa como un recolector de todos los hechos relevantes que se van generando desde el resto de las áreas de gestión, de manera que éstos tienen un reflejo automático en la contabilidad general, en las cuentas a cobrar y en las cuentas a pagar en cuanto se producen. Está diseñada para definir planes contables, capaces de llevar balances de sumas y saldos, tratar impuestos según sus categorías, diario de caja, diario de asientos, etc.
Este sistema estructura rotundamente los procesos por lo que se necesita de un experto para configurar el sistema. No permite enviar facturas por correo electrónico. Tiene una usabilidad pobre. Es 100% web y aun tiene este aspecto muy poco trabajado. El software es gratuito pero la implementación no es barata.
De forma general el producto aún está incompleto, tiene una contabilidad analítica muy limitada. No permite manejar simultáneamente varios idiomas.
OpenXpertya: está desarrollado completamente en Java (Eclipse IDE), lo que lo hace compatible con cualquier sistema operativo (Windows, Solaris, Linux, Aix, etc). Soporta varias bases de datos (Oracle, PostgreSQL, Firebird, Sybase, etc), sobre el servidor de aplicaciones JBOSS (aunque también Apache y TomCat). Está liberado bajo licencia basada en la CDDL basada en la MLP de Mozilla. Este sistema cuenta con un diccionario de datos propio. Tiene una arquitectura cliente/ servidor en un modelo original de 3 capas.
La gestión financiera en este sistema comprende la realización de transacciones de acuerdo con la personalización de periodos contables: reconocimiento de descuentos financieros y comerciales, facturación y emisión de informes de ventas, control de procesos de cierre y consolidación, algunos módulos de los empleados en esta solución se señalan en la Tabla 3. Este sistema está orientado especialmente a las formas contables españolas.
Otros sistemas desarrollados sobre software privados son:
Isis: es una solución desarrollada en el lenguaje Microsoft Visual Basic 6.0, con base de datos en Microsoft SQL Server, utiliza Business Objects Crystal Reports XI para emitir reportes. Utiliza arquitectura cliente/servidor. Este sistema se rige por una seguridad de acceso personalizado a los distintos procesos e informes por cada usuario, independientemente del puesto de trabajo.
En cuanto a las finanzas propone claves de autorización para cambios en órdenes de compra, facturas de compra, presupuestos de ventas, pedidos de venta, facturas de venta, anticipos y pagos a cuenta.
Recepciona, tramita y reporta las órdenes de compras. Gestiona los procesos de movimiento de fondo, depósito, conciliación, venta y liquidación de cheques. Emite libro diario, balances, mayores y listados contables. La estructura modular con la que da cumplimiento a las finanzas, se señala en la Tabla 3.
Epicor: es una solución empresarial construida sobre Microsoft.NET y está orientada a servicios (SOA);
una tecnología única que almacena toda la lógica de negocio del cliente en forma de metadatos XML. Así este sistema podrá ejecutarse en dispositivos móviles. Epicor ICE, junto con herramientas de productividad como Epicor Portal Epicor, Epicor Service Connect, Epicor Information Worker y las aplicaciones empresariales de la próxima generación de Epicor proporcionan nuevos niveles de flexibilidad, usabilidad y escalabilidad.
En este software la solución financiera es capaz de automatizar y agilizar sus procesos mediante la administración de cuentas por cobrar, caja de seguridad, créditos y cobranzas, cuentas por pagar, transferencia electrónica de fondos, cotejamiento de órdenes automatizadas, libro mayor, adjudicaciones, consolidaciones y eliminaciones, administración de efectivo, conciliación bancaria e interfaces de estados de cuenta, nómina, activo fijo e impuestos, presupuestos, pronósticos y planeación. La solución financiera correspondiente se estructura como se indica en la Tabla 3.
