Nos basamos en el listado de cualidades del software que aparece en el texto clásico "Fundamentals of Software Engineering" de Ghezzi, Jazayeri y Mandrioli, por entender que de esta manera se aseguran ciertas características necesarias para el software. Para establecer los aspectos funcionales de los requerimientos nos basamos esencialmente en dos ERPs, SAP R/3 4.6C y J.D. Edwards A7.3 por tratarse en el caso de SAP del líder del mercado y por tener experiencia directa con J.D.Edwards.
La mayoría de los requerimientos son conocidos, por los que muchos solamente serán mencionados. Nos extenderemos cuando apliquen consideraciones específicas para ERPs o hayamos variado ligeramente la categoría para adecuarla al tipo de software en cuestión.
Debido a que una ERP maneja una única base de datos, la seguridad cobra más importancia. Por ejemplo, debe aportar controles en el ingreso de datos para evitar inconsistencias, respaldo, roles para acceder al sistema, etc. Muchos de los requerimientos de seguridad, sin embargo, están cubiertos en el anexo: Estudio de GNU/Linux como solución integral para Empresas, capítulo 3 sección 2.1.2 (seguridad) y capítulo 6 sección 2 (bases de datos).
A continuación se incluye una lista de funcionalidades mínima para garantizar la seguridad seguida de la explicación de la misma.
Seguridad por módulo
Seguridad por nivel de acceso
Usuarios oficiales de seguridad
Usuarios de auditoría interna
Manejo de roles
Anulación
Anulación total
Anulación con registro de 'comprobante anulado'
Anulación mediante ingreso de comprobante opuesto
Controles de carga
Validación por información del sistema (rest. func.)
Validación por información ya ingresada (clave foránea)
Validación de no duplicación (clave primaria)
Contingencias
Facturar sin conexión con sistema principal
Sincronización de datos
Mantenimiento de datos de contingencia
A los efectos de tener control sobre quien hace que cosas, es necesario que el sistema controle los usuarios. Los usuarios deben poder pertenecer a grupos de usuarios con roles específicos que habiliten ciertos permisos (p.ej. el personal de compras no debería poder hacer ingreso de mercadería para evitar fraudes). Debe existir la figura del administrador y la del oficial de seguridad con capacidades de definir y modificar esos roles. También es conveniente un rol de auditor con capacidad de ver, pero no modificar, todos los datos.
Los errores son frecuentes en la rutina de la administración, por lo que el sistema debe poder permitir corregirlos. Sin embargo estas correcciones deben ser de tal modo de eliminar riesgos de fraude, etc. En general se entiende que no hay perjuicio en anular sin dejar registro aquellos comprobantes que no muevan fondos, p.ej. asientos contables no financieros, facturas en cuenta corriente, ordenes de compra, pedidos, etc. Por otro lado, es indispensable que queden registrados asiento original y contraasiento cuando se anulan comprobantes que mueven fondos, p.ej. ingresos de dinero de cobranzas o salida de dinero de pagos.
Que los sistemas permitan la anulación a través de contraasientos que revierten la operación pero la dejan registrada. Al principio puede parecer poco intuitivo que la manera de anular una venta (que se ingresó mal) sea mediante una devolución. Pero es una solución elegante que si bien no refleja la realidad de la empresa (la mercadería no llegó a entregarse) presenta una manera estándar y sencilla de revertir la operación, generando los contraasientos correspondientes. En muchos casos el tipo de anulación de un comprobante dependerá de la etapa en que se encuentre (p.ej. ingresado, confirmado, impreso).
Como se tiene una sola base de datos, es importante que los datos ingresados sean correctos. A la vez, al ser una base de datos única, en algunos casos es posible ejercer mayores controles a la consistencia. Estos controles se pueden homologar a hacer cumplir las restricciones de integridad de la base de datos.
Las fechas deben controlarse contra el calendario existente, por ejemplo emitiendo una advertencia cuando se intenta hacer una transacción con fecha de un día feriado, o en un año fiscal diferente del actual. De este modo se evitan problemas como p.ej. ingresar un remito de un proveedor en una fecha previa a la orden de compra. Estas son restricciones de integridad funcionales.
También debe controlarse la integridad de las claves foráneas. Esto, desde el punto de vista del sistema, representa que no se pueda p.ej. ingresar el cabezal de un comprobante de pago (p.ej. un cheque) en una moneda y las líneas en otra moneda. Otro ejemplo es el caso de las facturas y el tipo de IVA del cliente, que deben ser consistentes.
Por último, debe controlarse la integridad de las claves primarias. Sirve para evitar que se cargue dos veces el mismo comprobante, y constituye un requerimiento fundamental para asegurar el cumplimiento de algunas normas legales (p.ej. que el número legal de la factura no esté duplicado).
Estos controles pueden dejarse del lado de la base de datos o del sistema (por ejemplo, tener un trigger definido en la base de datos para resolver estas excepciones). La manera de hacer estos controles no importa en tanto el sistema los realice y no se genere ninguna excepción no monitoreada.
Si el servidor no está disponible, especialmente en el caso de una empresa de venta al público que las ventas no se paralicen y se cuente con un sistema que permita facturar hasta que se resuelva la contingencia. Esto implica que los datos deberán sincronizarse en un sentido y en otro (por ejemplo, el inventario del sistema de contingencia debe incluir los últimos productos, y a partir de los datos de contingencia, poder generarse automáticamente los movimientos y asientos en la ERP). El tipo de contingencia que puede dar lugar a esta situación no depende exclusivamente del software, por ejemplo puede haber un problema con las líneas de transmisión de datos.
Determinar como afecta la carga del sistema al funcionamiento, y si se pueden recuperar las transacciones, etc. Muchos de los requerimientos de robustez están vinculados al DBMS que la ERP utilice.
Determinar como afecta la carga del sistema al tiempo de respuesta. En el caso de las ventas al público, con puntos de venta, es indispensable que los tiempos de respuesta entre que se ingresa una factura y se procesa; otro tanto vale para quienes negocian con proveedores, que deberán tomar decisiones muy rápidamente.
Determinar si cuando la empresa crece, la organización cambia o se produce una fusión o escisión, el sistema puede adaptarse o deberá cambiarlo.
Determinar si es capaz de satisfacer las necesidades de empresas de diversos rubros.
Determinar si se puede agregar o modificar funcionalidad de manera sencilla, mediante herramientas de productividad. El contar con el código fuente es un avance, pero el diseño puede hacer muy difícil la incorporación de modificaciones, p.ej. si permite al usuario elaborar sus propios reportes.
El objetivo es determinar si hay herramientas automáticas para generar reportes, o modificar workflows, p.ej. los estados por los que atraviesa una orden de venta. Por citar un ejemplo: JD Edwards tiene herramientas para crear reportes (Dream Writer, World Writer, etc.) que usan los contadores, y herramientas que generan fuentes de programas con los requerimientos mínimos de integración. SAP R/3 tiene ABAP, etc.
Deteriminar si los módulos se integran adecuadamente entre sí, si el sistema se integra adecuadamente con el DBMS y con herramientas de productividad (importar y exportar información a planillas, etc.).
Determinar si es fácil construir interfaces entre éste y otros sistemas, exportar sus datos, exportar su funcionalidad para cooperar a nivel semántico, etc.
Determinar si el uso del sistema es intuitivo, si mantiene la misma interfaz, si tiene ayuda en línea, si tiene buena documentación de usuario, etc.
Impresión
Múltiples impresoras
Modificar formato de impresión
Exportar a documentos electrónicos (PDF, SXW, HTML, etc.)
Importar de formatos electrónicos
Visualización
Mismos datos imprimibles
Funciones de búsqueda
Herramientas para hacer consultas SQL visuales
Es evidente la necesidad de poder imprimir formularios, informes, comprobantes, etc. El formato de estos documentos debe poder ser fácilmente modificable (p.ej. cuando se añadió el COFIS fue necesario agregarlo en las facturas y las ordenes de compra). También debería poderse configurar el poder imprimir en la impresora en red deseada por el usuario, y exportar los datos a los formatos más populares.
Por otro lado, a los efectos de ahorrar papel, en lugar de imprimir los informes y otros documentos, estos deberían poder ser consultados en línea. Una forma de hacerlo es a través de impresión a un formato electrónico y luego su visualización. Otra forma es mediante una interfaz adecuada que incorpore funciones de búsqueda y ordenamiento. Esta interfaz podría incluir la funcionalidad de modificación (en función del rol del usuario y sus permisos).
La información en las bases de datos debe poder consultarse de manera sencilla y útil, para filtrar solamente la información de interés. Aunque se puede hacer esto mediante consultas a la Base de Datos, es preferible si los propios interesados cuentan con herramientas para confeccionar sus propios informes. Algunos ejemplos de listados son: ventas por cliente, ventas por vendedor, ventas por zona, listado de I.V.A. para ventas, etc.
Importar los datos de estos formatos para ingresarlos al sistema puede ser útil para cargar conjuntos de datos grandes, por ejemplo una importación de 500 artículos diferentes.
Determinar si el sistema soporta múltiples monedas y conversión, múltiples idiomas, adecuación de reportes y generación de documentos para requerimientos legales específicos de un país, manejo de múltiples compañías.
Estudio del Open/Free (GNU/Linux) como plataforma de servicios de red en entornos empresariales
Daniel Caraballo - Mario Madera - Marcelo Odin
Tutor: Ariel Sabiguero Yawelak
2004 - 2005.