Los sistemas administrativos – contables son sistemas enfocados en controlar las transacciones de dinero, mercadería y los informes contables, hay dos formas básicas de hacerlo: accrual (devengado) y cash (efectivo). Accrual indica que se debe registrar los movimientos en la fecha del compromiso, cash en la fecha del pago. Son dos esquemas contables incompatibles, todo el sistema contable debe tener una de las dos metodologías. Un ejemplo de la diferencia: una venta con tarjeta de crédito: accrual – registra la venta contra cuentas por cobrar, cash – registra la venta cuando se recibe el dinero. En algunas empresas se trabaja con el método cash. Vamos a dar soporte solo a accrual.

Los sistemas crecieron hasta cubrir el control de producción: MRP (planificación de los requerimientos de materiales) http://en.wikipedia.org/wiki/Material_Requirements_Planning y MRP II http://en.wikipedia.org/wiki/Manufacturing_resource_planning (planificación de los recursos de producción).

Componentes de un MRP II

MRP II se extendió hasta ser ERP con la inclusión de procesos de planificación, presupuesto y análisis. Con ERP no solo es importante el controlar lo que está pasando en la empresa, es importante el planificar que va a realizarse a futuro y las tendencias de mercado y competencia.

Componentes de un ERP

Los sistemas ERP http://en.wikipedia.org/wiki/Enterprise_resource_planning están extendiéndose y evolucionando hasta ser ERP-II (http://www.idg.es/iworld/articulo.asp?id=142527, http://www.itprofessionals.es/detalle_noticia.asp?Id=129, http://www.erpwire.com/erp-articles/erpII-vs-erp.htm).

Evolución de ERP a ERP-II

ERP II pone en relevancia la iteración de la empresa con sus socios de negocio: Clientes, Proveedores, Empleados, Público, Gobierno, competencia.

Pueden encontrar bastante información sobre ERP II poniendo en Google: “beyond erp”.

Information Week publicó un artículo sobre la segunda ola de aplicaciones ERP http://www.informationweek.com/711/11iuerp.htm “Beyond ERP: New IT Agenda”.

Proyecto

No estamos enfocando en empresas con poco personal administrativo, en dos segmentos distintos: < 10 y < 50.

• Una empresa con menos de 10 personas en el personal administrativo es normalmente una empresa estática en sus procesos, no tiene personal especializado para mejorar internamente, su personal está dedicado a realizar varias funciones y el gerente puede ser el dueño.
• Una empresa con menos de 50 personas en administración, es una empresa que tiene áreas dinámicas en su operación, posiblemente tenga contrato con una empresa de consultoría para mejorar sus procesos, pero su energía está enfocada en el crecimiento y los cambios operativos son implementados con cautela y luego de una aprobación del comité gerencial.

Si analizamos las empresas que conocemos, es muy probable que el 60% se encuentren en el segmento “< 10”, un 30% en “< 50” y el 10% restante son clientes de SAP, Baan, MS Dynamics, Oracle, IBM y otros proveedores de sistemas ERP.

El sistema que vamos a realizar está enfocado en el segmento “< 50”, con una especialización en “< 10”, la diferencia principal es la infraestructura IT que dispone la empresa. Los más pequeños pueden adquirir y administrar un servidor, utilizan los servicios de un hosting para su página web y tiene una persona que realiza todas las funciones de IT sea en rol o por contrato. El segundo grupo, pueden disponer de más de 1 servidor y es muy probable que tengan una cobertura geográfica amplia y tengan un equipo de personas dedicadas al área de IT.

Vamos a construir el sistema para que sea dinámico, pero sin llegar a ser declarativo como son los grandes ERP. Vamos a tener scripting pero sin ser ABAP (http://es.wikipedia.org/wiki/ABAP) o X++ de Microsoft Dynamics AX (http://msdn.microsoft.com/en-us/library/aa867122.aspx).

Framework Base

Para tener un mejor control vamos a escribir un API, y con este API vamos a escribir el ERP, así daremos la posibilidad de extender el sistema sin tener que usar el fuente.

Por qué un API: si se construye una aplicación comercial, se debe dejar margen para que futuros socios de negocio puedan construir componentes adicionales, parte del éxito de la mayoría de aplicaciones de Microsoft, IBM, Oracle, Adobe es que permite que los usuarios o empresas especializadas pueden construir extensiones al sistema.

Por eso, el API debe permitir el acceder a todo nivel del sistema, sin necesidad de modificar el código fuente, bajo el mismo control y nivel de calidad de la aplicación principal. Y vamos a usar éste API en la construcción del componente visual con el API, si necesitamos hacer algo adicional, primero extendemos el API y luego continuamos con el sistema, de esa forma podremos facilitar que alguien escriba un componente que use reconocimiento facial en lugar de clave de acceso o utilizar equipos especializados o inclusive adicionar una base de datos para almacenamiento SCADA, etc.

Uno de los problemas que tuve en la implementación de un ERP en una empresa fue la personalización que hicieron los consultores, cuando llego una actualización del sistema, se descubrió que muchas de éstas personalizaciones no eran usables con la nueva versión, debían ser reescritas, a un costo similar. La empresa tuvo que analizar que era más eficiente: seguir con la versión antigua personalizada o cambiarse a la nueva y personalizar nuevamente. Retrasaron la actualización hasta que la versión que tenían funcionando dejo de tener soporte. La solución para este problema es tener un API estable y separar el sistema central de las personalizaciones de forma de poder actualizar con el menor esfuerzo, esto está planificado en la capa de aplicación.

Framework Base – Diagrama de Componentes

Presentation Layer: MVC, MVP, MVVM

Con WPF y Silverlight están disponibles algunos frameworks, me gustaron dos; PRISM 4 de Microsoft y Cinch de Sasha Barber http://www.codeproject.com/KB/WPF/CinchCodeGen.aspx creo que Prism 4 es superior pero Sasha es más asequible en caso de requerir apoyo. Por eso utilizaremos Cinch. En realidad al construir el primer módulo probaremos que tan fácil es usar Cinch. Vamos a usar los controles de Developer Express. http://www.devexpress.com/

Application Layer

La capa de aplicación la dividí en tres capas: la primera donde estará el código genérico del ERP, es decir, el código que sirve para una empresa totalmente anónima. La segunda capa tendrá el código que es especializado para un mercado vertical, no es igual un ERP para una distribuidora o para una clínica. Y la tercera capa será para las personalizaciones que realice el cliente para su realidad particular. Kontac SmartRules http://www.kontac.net/portal/Portal/SmartRules.aspx o Jaxlab http://www.codeproject.com/KB/cs/Rules_In_Your_Apps.aspx

Como ejemplo: las comisiones a los vendedores se realiza normalmente en función de un % establecido cuando la factura ha sido pagada en su totalidad, pero en las empresas de tecnología los contratos pueden ser a largo plazo, por eso los % de comisiones se pagan sobre el valor del contrato sin tomar en cuenta la cobranza, y la empresa de tecnología “Tec LLC” quiere pagar la comisión en función de la rentabilidad del contrato. Entonces, el código para el cálculo de las comisiones de ventas en general estará en la capa de aplicación general, la variación para empresas de tecnología en la capa de aplicación vertical para empresas de tecnología y la persona que realiza la implantación en la empresa “Tec LLC” pone la regla de negocio para pago de comisiones en la capa de instancia. Al realizar el proceso de cálculo de comisiones a vendedores el proceso mira si hay una regla de instancia, sino mira si hay una de mercado vertical y si no hay, usa la general.

Business Layer

La capa de negocio, tiene el código requerido para todos los componentes del ERP funcionen:

· Reportes: Sql Server Reporting Services usa RDL para definir los reportes, hay un diseñador disponible, lo vamos a utilizar, pero para la impresión de documentos transaccionales como facturas, albaranes es necesario tener un mejor tiempo respuesta, hasta este momento, usaremos XtraReports de DevExpress.

· Configuración: Utilizaremos la Enterprise Library 5 (http://entlib.codeplex.com/releases/view/43135)

· Exportación / importación de datos: Existe una librería http://filehelpers.sourceforge.net/ que permite de una forma eficiente y declarativa la exportación e importación de datos a archivos de texto y Excel. Partiremos de ahí y la extenderemos hasta cubrir las necesidades del ERP.

· Workflow: Motor de ejecución de los flujos de trabajo definidos.

· Validaciones: Reglas de validación de la información, externas al código, Kontac SmartRules o Jaxlab.

· Reglas de negocio comunes: Igual, Kontac SmartRules o Jaxlab.

· Motor de scripting: Lenguaje embebido, el lenguaje que usaremos en el sistema está por definirse, puede ser http://jint.codeplex.com/ pero estoy buscando un lenguaje embebido que pueda ser echo debug sin tener el Visual Studio instalado y de preferencia sin un castigo importante en el tiempo de ejecución, 5% de tiempo adicional es aceptable, con los actuales procesadores … hasta un 20% más tiempo (entre el código en C# y su equivalente en el script) es totalmente aceptable.

Resource Layer

• Configuración: Enterprise Library 5.
• Actualizaciones: Updater Applicaction Block o algo similar para actualizar los cambios en las DLL (http://msdn.microsoft.com/en-us/library/ff650611.aspx)
• Recursos y Localización: Resource Factory, componente para acceder a textos, iconos, imágenes, etc. Supeditado a la configuración de país y negocio. Probablemente sea una (o varias) pequeña base de datos con SQL Server CE o SqLite que se actualizara en cada máquina cliente
• ORM: nHydrate, un ORM con generación de código, la primera versión tendrá tablas estáticas, estoy aprendiendo a usar nHydrate para ver de qué forma de extensibilidad se da a la DB en caso que se requiera aumentar campos a una tabla. La mejor idea (hasta este momento: poner campos XML en las tablas y aumentar los campos dentro de este campo XML)
• Ayuda: Help controller, los mensajes de ayuda deben ser dinámicos, en cada país la legislación y las costumbres hacen que la ayuda deba ser distinta, además del nivel de experiencia que tenga el usuario, esta es la parte más dura, la gran diferencia entre un sistema comercial grande y uno pequeño: los manuales.
• Addins: Add-In controller, usando MEF (es extensibilidad) y UNITY (es IOC)
• Control Acceso: Identity factory, el control de seguridad es crítico, si la empresa va a confiar su operación a un ERP debe confiar que solo los usuarios autorizados tienen acceso a los datos, la información y tener un nivel de rastreo y auditoría completo y funcional, he usado varios ERP que generan tanta información de auditoría que se vuelve totalmente inútil debido a la dificultad de asociar los registros de auditoría con procesos y documentos.
• Motor de scripting: igual que en las otras capas.

Servicios y Servidores

En ERP es básicamente un sistema administrativo con mejor arquitectura, más integración, más módulos pero con un motor de procesos BPM y manejo del flujo del trabajo. El construir un ERP completo es un trabajo extenso, pero como dice la sabiduría popular “divide y vencerás”. Todo el sistema lo dividí en varios servicios y servidores, vamos a utilizar sin cambios, en el código fuente, varios servidores existentes. El escribir un motor ESB es algo complejo y toma tiempo, por eso usaremos servidores existentes y escribiremos lo que no encontremos.

Ver http://geeks.ms/blogs/ifreire/archive/2011/03/06/peque-241-o-erp-con-calidad-comercial-definiciones.aspx para mas detalle.

 

Diagrama de Implementación

 

Equipo Cliente

• Identity Service

• Application Shell

 

Servidor de Aplicaciones

• Servidor de Proyectos

• Servidor Documental

• Servidor de Reportes

• Servidor Contable (ERP)

• Orquestador de Aplicaciones

 

Servidor de Datos

• Base de Datos

• Servidor de Entidades