Desarrollo de un sistema ERP con SQL Server 2008 R2, C# 4.0, WPF
- Con Calidad Comercial Los sistemas administrativos - contables
son sistemas enfocados en controlar las transacciones de dinero,
mercadera y los informes contables, hay dos formas bsicas 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 metodologas. Un
ejemplo de la diferencia: una venta con tarjeta de crdito: accrual
registra la venta contra cuentas por cobrar, cash registra la venta
cuando se recibe el dinero. En algunas empresas se trabaja con el
mtodo cash. Vamos a dar soporte solo a accrual. Los sistemas
crecieron hasta cubrir el control de produccin: MRP (planificacin
de los requerimientos de materiales)
http://en.wikipedia.org/wiki/Material_Requirements_Planning y MRP
IIhttp://en.wikipedia.org/wiki/Manufacturing_resource_planning
(planificacin de los recursos de produccin).
Componentes de un MRP II
MRP II se extendi hasta ser ERP con la inclusin de procesos de
planificacin, presupuesto y anlisis. 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
Componentes de un ERP
Los sistemas ERP
http://en.wikipedia.org/wiki/Enterprise_resource_planning estn
extendindose 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/erparticles/erpII-vs-erp.htm).
Evolucin de ERP a ERP-II
ERP II pone en relevancia la iteracin de la empresa con sus
socios de negocio: Clientes, Proveedores, Empleados, Pblico,
Gobierno, competencia. Pueden encontrar bastante informacin sobre
ERP II poniendo en Google: beyond erp. Information Week public un
artculo sobre la segunda ola de aplicaciones
ERPhttp://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 esttica en sus procesos,
no tiene personal especializado para mejorar internamente, su
personal est dedicado a realizar varias funciones y el gerente
puede ser el dueo. Una empresa con menos de 50 personas en
administracin, es una empresa que tiene reas dinmicas en su
operacin, posiblemente tenga contrato con una empresa de consultora
para mejorar sus procesos, pero su energa est enfocada en el
crecimiento y los cambios operativos son implementados con cautela
y luego de una aprobacin 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 especializacin en <
10, la diferencia principal es la infraestructura IT que dispone la
empresa. Los ms pequeos pueden adquirir y administrar un servidor,
utilizan los servicios de un hosting para su pgina web y tiene una
persona que realiza todas las funciones de IT sea en rol o por
contrato. El segundo grupo, pueden disponer de ms de 1 servidor y
es muy probable que tengan una cobertura geogrfica amplia y tengan
un equipo de personas dedicadas al rea de IT. Vamos a construir el
sistema para que sea dinmico, 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 aplicacin comercial, se debe dejar margen para que
futuros socios de negocio puedan construir componentes adicionales,
parte del xito de la mayora 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 cdigo fuente, bajo el mismo control y
nivel de calidad de la aplicacin principal. Y vamos a usar ste API
en la construccin 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 implementacin de un ERP en una empresa fue la
personalizacin que hicieron los consultores, cuando llego una
actualizacin del sistema, se descubri que muchas de stas
personalizaciones no eran usables con la nueva versin, deban ser
reescritas, a un costo similar. La empresa tuvo que analizar que
era ms eficiente: seguir con la versin antigua personalizada o
cambiarse a la nueva y personalizar nuevamente. Retrasaron la
actualizacin hasta que la versin que tenan funcionando dejo de
tener soporte. La solucin 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 aplicacin.
Framework Base Diagrama de Componentes
Presentation Layer: MVC, MVP, MVVM Con WPF y Silverlight estn
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 ms asequible en caso de requerir apoyo.
Por eso utilizaremos Cinch. En realidad al construir el primer
mdulo probaremos que tan fcil es usar Cinch. Vamos a usar los
controles de Developer Express. http://www.devexpress.com/
Application Layer La capa de aplicacin la divid en tres capas: la
primera donde estar el cdigo genrico del ERP, es decir, el cdigo
que sirve para una empresa totalmente annima. La segunda capa tendr
el cdigo que es especializado para un mercado vertical, no es igual
un ERP para una distribuidora o para una clnica. 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
Jaxlabhttp://www.codeproject.com/KB/cs/Rules_In_Your_Apps.aspx Como
ejemplo: las comisiones a los vendedores se realiza normalmente en
funcin de un % establecido cuando la factura ha sido pagada en su
totalidad, pero en las empresas de tecnologa 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
tecnologa Tec LLC quiere pagar la comisin en funcin de la
rentabilidad del contrato. Entonces, el cdigo para el clculo de las
comisiones de ventas en general estar en la capa de aplicacin
general, la variacin para empresas de tecnologa en la capa de
aplicacin vertical para empresas de tecnologa y la persona que
realiza la implantacin en la empresa Tec LLC pone la regla de
negocio para pago de comisiones en la capa de instancia. Al
realizar el proceso de clculo 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 cdigo requerido para todos los componentes del
ERP funcionen: Reportes: Sql Server Reporting Services usa RDL para
definir los reportes, hay un diseador disponible, lo vamos a
utilizar, pero para la impresin de documentos transaccionales como
facturas, albaranes es necesario tener un mejor tiempo respuesta,
hasta este momento, usaremos XtraReports de DevExpress.
Configuracin: Utilizaremos la Enterprise Library 5
(http://entlib.codeplex.com/releases/view/43135) Exportacin /
importacin de datos: Existe una librera
http://filehelpers.sourceforge.net/ que permite de una forma
eficiente y declarativa la exportacin e importacin de datos a
archivos de texto y Excel. Partiremos de ah y la extenderemos hasta
cubrir las necesidades del ERP. Workflow: Motor de ejecucin de los
flujos de trabajo definidos. Validaciones: Reglas de validacin de
la informacin, externas al cdigo, 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 ejecucin, 5% de tiempo adicional es
aceptable, con los actuales procesadores hasta un 20% ms tiempo
(entre el cdigo en C# y su equivalente en el script) es totalmente
aceptable. Resource Layer
Configuracin: 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 Localizacin: Resource Factory, componente para acceder a
textos, iconos, imgenes, etc. Supeditado a la configuracin de pas y
negocio. Probablemente sea una (o varias) pequea base de datos con
SQL Server CE o SqLite que se actualizara en cada mquina cliente
ORM: nHydrate, un ORM con generacin de cdigo, la primera versin
tendr tablas estticas, 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
dinmicos, en cada pas la legislacin y las costumbres hacen que la
ayuda deba ser distinta, adems del nivel de experiencia que tenga
el usuario, esta es la parte ms dura, la gran diferencia entre un
sistema comercial grande y uno pequeo: los manuales. Addins: Add-In
controller, usando MEF (es extensibilidad) y UNITY (es IOC)
Control Acceso: Identity factory, el control de seguridad es
crtico, si la empresa va a confiar su operacin a un ERP debe
confiar que solo los usuarios autorizados tienen acceso a los
datos, la informacin y tener un nivel de rastreo y auditora
completo y funcional, he usado varios ERP que generan tanta
informacin de auditora que se vuelve totalmente intil debido a la
dificultad de asociar los registros de auditora con procesos y
documentos. Motor de scripting: igual que en las otras capas.
Servicios y Servidores En ERP es bsicamente un sistema
administrativo con mejor arquitectura, ms integracin, ms mdulos
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 sabidura popular divide y vencers. Todo el sistema lo divid en
varios servicios y servidores, vamos a utilizar sin cambios, en el
cdigo 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-comercialdefiniciones.aspx
para mas detalle.
Diagrama de Implementacin
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
