He completado los cursos de certificación de OpenERP y voy a iniciar la implantación del producto en 2 empresas distintas, revisando el esquema y framework que dispongo y el que tiene OpenERP he notado algunas diferencias que DEBEN ser tomadas en cuenta a futuro.

• He estado creando el framework poniendo como principal objetivo el crecimiento del producto, OpenObjects (de OpenErp) es un framework completamente genérico con el que construyeron un ERP, este es un enfoque que voy a adquirir, la mejor opcion es tomar nHydrate y extenderle con algunas herramientas para generalizar su uso, o usar la nueva herramienta de Microsoft LightSwitch o Sculpture de ModelinSoft (antes DawliaSoft) http://www.modelingsoft.com/ ahora estan con codigo cerrado pero el componente que esta en codigo abierto en http://visualstudiogallery.msdn.microsoft.com/b7057c6a-3392-4486-b914-940a2e1f1d5c es una posible fuente inicial.
• OpenERP no parte de un modelo de datos, parte de un ORM que construye la base de datos de acuerdo a los requerimientos del módulo que se esta activando, este esquema de implantación me parece genial y es evolutivo, permitiría el mejorar o reemplazar cualquier módulo en cualquier instante del tiempo.
• Model-View-Controler, desde el punto de vista de un ERP: Model - genera el codigo y el codigo necesario para administrar CRUD del módulo; descripción de las formas y reportes del módulo, descriptivo, capaz de correr en WPF o Silverligth (lo sencillo es SOLO silverlight); Controller: el componente del módulo que tiene el código que realiza las acciones definidas. OpenERP usa este esquema y funciona.

Con estas ideas en Mente, mi iKhanFramework usara nHydrate, NService, mi propio motor de scripting basado en Conscript de Colin Vella http://www.codeproject.com/KB/cs/Conscript.aspx o en jscript.net http://jint.codeplex.com/ o http://javascriptdotnet.codeplex.com/, por que mi propio motor? solo por seguridad, no quiero que alguien ponga en el script codigo que rompa la seguridad de la aplicación o del servidor.

Siguiente paso, construir un simple sistema que de mantenimiento a 1 tabla, 1 maestro-detalle y 1 relación N-N.

Estaba escribiendo un servidor documental y encontre uno ya existente que tiene una version gratuita, se llama M-Files, la version pagada tiene un workflow documental y soporta SQL Server como repositorio, la gratuita solo utiliza FireBird y tiene una limitación de 1'000.000 de documentos, como el proposito de este proyecto es usar lo existente, voy a utilizar este servidor documental M-Files

Estoy trabajando en una empresa que se convirtió en partner de M-Files, por lo que tengo acceso a bastante información técnica y la voy a utilizar para integrar el ERP a M-Files Express

Además la empresa se está convirtiendo de partner de OpenERP, por lo que voy a escribir el API del ERP basado en el API de OpenERP, pero utilizando el esquema planteado en este blog.

Cuando estaba buscando una herramienta para hacer pruebas, me llegó un mail de Telerik informando que hay una nueva versión de su librería OpenAccess ORM Free Edition que he utilizado en algunos proyectos y revisando el sitio web encontre 3 productos que pueden ayudar a realizar algunas funciones con el ERP

Testing Framework: nos va a ayudar a realizar pruebas automáticas de los clientes Web: asp.net mvc y silverlight

Just Mock Free Edition: nos va a apoyar a construir los mock requeridos para todas las pruebas del ERP

TeamPulse Community Edition: Soporta 5 usuarios y 1 proyecto, voy a probarlo con la construcción del servidor documental, pero estoy buscando el calificar con Atlassian para obtener las licencias comunitarias de todos los productos de su suite Jira Studio, que tiene una licencia gratuita para productos open source, son algo estrictos en sus requerimientos, pero espero lograr cumplirlos en los siguientes 60 a 90 días.

A todos los que necesitan herramientas para acelerar el desarrollo de productos de software, esta es una fuente valiosa de herramientas.

Uno de los temas es como poner reglas de negocio en SQL Server, estoy probando usar C# y el motor BRMS, pero en los ultimos años he utilizado T-SQL y adición dinámica de SPs a los procesos.

Primer problema: como controlar que el SP que se va a ejecutar es uno autorizado?

Si escribi un SP que hace el cálculo de las comisiones de venta, necesito controlar que el SP a ejecutar sea uno autorizado y no uno que puso otra persona (con acceso a la DB). Voy a usar AdventureWorks para el ejemplo

   1:  create procedure CalcTotalSalesCommision

   2:  as begin

   3:  SELECT sales.SalesOrderHeader.SalesPersonID, sum(Sales.SalesOrderHeader.SubTotal * Sales.SalesPerson.CommissionPct) as TotalComisionVenta

   4:  FROM Sales.SalesOrderHeader INNER JOIN Sales.SalesPerson ON Sales.SalesOrderHeader.SalesPersonID = Sales.SalesPerson.SalesPersonID

   5:  group by sales.SalesOrderHeader.SalesPersonID 

   6:  having sum(Sales.SalesOrderHeader.SubTotal * Sales.SalesPerson.CommissionPct) > 0.00 

   7:  end

Si ejecutamos la siguiente consulta

select object_id('CalcTotalSalesCommision')

obtenemos el id que usa internamente Sql Server para identificar al SP, en mi maquina obtuve: 1915153868

si cambiamos el create procedure a alter procedure, ejecutamos la modificación y volvemos a obtener el id del SP: 1915153868, para controlar un cambio, debemos obligar a que cambie el ID del SP, para hacerlo debemos eliminarlo y volverlo a crear, pero debemos obligar a que se borre y no se use la opcion alter. Para lograr este comportamiento, creemos un trigger a nivel de base de datos 

   1:  create TRIGGER ddl_trig_alterproc 

   2:  ON database 

   3:  FOR alter_procedure 

   4:  AS 

   5:  raiserror 50000 'no modificar SPs, eliminelo y vuelvalo a crear'

   6:  GO

 luego de crear este trigger, si queremos usar el comando alter procedure, obtenemos este error:

Msg 50000, Level 16, State 1, Procedure ddl_trig_alterproc, Line 6
no modificar SPs, eliminelos y vuelvalo a crear

Ahora, al hacer drop procedure y luego el create procedure, ejecutemos la consulta y obtenemos distintos valores.

Segundo Problema: aumentar SPs dinámicamente

El siguiente paso es almacenar el id en una tabla y verificar que ese id sea el mismo antes de permitir su ejecución, por propósito del artículo voy a dejar fuera la parte de criptografía, eso lo veremos en otro momento.

Creamos una tabla donde guardar el nombre del SP, su ID y el tipo

Tipo puede ser uno de los siguientes valores:

Esto significa que todos los SP de tipo 1 (PRE insert) deben ser ejecutados ANTES de realizar el insert en una tabla, asi en un SP

Una tabla REGLA donde vamos a almacenar las reglas que vamos a utilizar

   1:  CREATE TABLE REGLA (

   2:      id int NOT NULL ,

   3:      nombre varchar (255) NULL ,

   4:      tabla varchar (255) NULL ,

   5:      tipo int NULL ,

   6:      campo varchar (255) NULL ,

   7:      orden int NULL ,

   8:      usuario char (1) NULL DEFAULT ('N') CHECK ((usuario = 'N') or (usuario = 'S')),

   9:      PRIMARY KEY 

  10:      (

  11:          id

  12:      )

  13:  )

Y en los SPs vamos a poner el siguiente código (en este ejemplo es para DELETE)

   1:  select @ttabla = '<TABLA>'

   2:  select @ttipo = 7 -- PRE DELETE

   3:   

   4:  declare cr_d_<TABLA> cursor for

   5:  select nombre from regla

   6:      where tabla = @ttabla and 

   7:      tipo = @ttipo 

   8:  order by usuario,orden

   9:   

  10:  -- Reglas PRE DELETE

  11:  open cr_d_<TABLA> 

  12:  fetch next from cr_d_<TABLA> into @spnombre

  13:  while @@fetch_status = 0

  14:  begin

  15:      exec @errno = @spnombre

  16:          <F_EXEC>

  17:      if @errno <> 0

  18:      begin

  19:          close  cr_d_<TABLA>

  20:          deallocate  cr_d_<TABLA>

  21:          rollback transaction td_<TABLA>

  22:          goto fin

  23:      end

  24:      fetch next from cr_d_<TABLA> into @spnombre

  25:  end

  26:  close  cr_d_<TABLA>

  27:   

  28:  -- Ejecucion de la Accion

  29:  <ACCION>

  30:  if @@error <> 0

  31:  begin

  32:      raiserror 56001 'Error al eliminar de  "<TABLA>"'

  33:      close  cr_d_<TABLA>

  34:      deallocate  cr_d_<TABLA>

  35:      rollback transaction td_<TABLA>

  36:      goto fin

  37:  end

  38:   

  39:  -- Reglas POST DELETE

  40:  select @ttipo = 9 -- POST DELETE

  41:  open cr_d_<TABLA>

  42:  fetch next from cr_d_<TABLA> into @spnombre

  43:  while @@fetch_status = 0

  44:  begin

  45:      exec @errno = @spnombre 

  46:          <F_EXEC>

  47:      if @errno <> 0

  48:      begin

  49:          close  cr_d_<TABLA>

  50:          deallocate  cr_d_<TABLA>

  51:          rollback transaction td_<TABLA>

  52:          goto fin

  53:      end

  54:      fetch next from cr_d_<TABLA> into @spnombre

  55:  end

  56:  close  cr_d_<TABLA>

  57:  deallocate  cr_d_<TABLA>

En la línea 29 debe estar el código que realmente necesitamos para eliminar el registro que nos interesa.

Lo importante es que seleccionamos los SPs que nos interesan ejecutar ANTES y DESPUES de la acción requerida pero de una forma declarativa, podemos aumentar o cambiar la lista de procedimientos que deben ser utilizados. Este código puede generado usando CodeSmith o T4, tengo que actualizar las templetas y el código para usar las nuevas opciones que nos provee SQL Server 2008 R2.

Todos los campos que son argumentos del SP principal deben ser argumentos de los SPs que se usaran como regla, la templeta simplemente usa todos los campos que tiene la tabla.

Para el ERP vamos a modificar este código para tener reglas a nivel de Instancia, Vertical, Generales y por grupo de usuarios o un usuario en especial.

En el siguiente artículo veremos el problema 3 – como hacer que un usuario NO pueda ingresar, modificar o eliminar registros sin usar las reglas de negocio.

Para los interesados en la teoría de arquitectura de software, este documento http://www.cs.ubc.ca/~gregor/teaching/papers/4+1view-architecture.pdf describe un modelo para describir arquitectura de software, lo estoy usando para la documentación técnica de éste proyecto.

Muchos me han preguntado por qué un ERP si hay varios y muy buenos en Open Source.

Buscando una lista de los ERP con código fuente disponible llegue a wikipedia http://en.wikipedia.org/wiki/List_of_ERP_software_packages  que pone esta tabla

Free and Open Source ERP software

Que es lo importante de esta tabla: 8 en Java, 5 en Python, 3 en Php, 2 en Perl, 1 en Ruby y 1 en C++.

No he encontrado ni uno solo en C#, hay muchos comenzados pero ni uno solo funcionando.

Si alguien conoce de un ERP en .NET con Open Source, favor indicarme el link.

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

Luego algunas discusiones filosóficas se decidió trabajar con WPF y Silverlight 4.

Y los componentes ya están definidos:

Enterprise Service Bus:

http://www.nservicebus.com/ la versión comunitaria tiene como limitación: 30 mensajes por segundo o 2.5 millones de mensajes por día, para propósito de este ERP ... suficiente. Todos los mensajes estarán serializados en JSON http://www.json.org .

Servidor de Datos

- Base de datos: SQL Server Express 2008 R2 with Advanced Tools: Estoy usando el modelo de datas de Apache OfBiz como base, con Embarcadero ER/Estudio (versión 8) http://www.embarcadero.com/products/er-studio-data-architect, RedGate me obsequió (por ser MCT) una licencia de su producto SQL/Toolbelt http://www.red-gate.com/products/sql-development/sql-toolbelt/, esta algo anticuada pero funciona y muy bien.

- Servidor de Entidades: nHydrate http://nhydrate.codeplex.com

Servidor de Aplicaciones

- Servidor y Repositorio de reportes: Reporting Services, los reportes generados por el usuario serán almacenados en el repositorio documental, los links de los documentos se enviaran por mail a los subscriptores, el orquestador será el responsable de iniciar la generación de los reportes. La generación de reportes en XBRL http://www.xbrl.org/Home/ hay que programarla, tengo un motor pero no puedo usarlo en un proyecto open source.

- Servidor y repositorio documental: Usare MojoPortal http://www.mojoportal.com/ (TODO: migrar MojoPortal a Silverlight) como interface visual sobre SQL Server como repositorio, usando filestream. Tengo que encontrar librerías para digitalización de documentos open source o usare la versión gratuita de  http://www.atalasoft.com/products/dotimage/features 

- Project Server: Solo encuentro servidores de proyectos en java o PHP, si alguien conoce uno en .net … favor indicarme. Pero usare http://www.dotproject.net/ esta en PHP y MySql, creo que lo podemos migrar a Phalanger con SqlServer http://phalanger.codeplex.com/. Y como herramienta visual http://openproj.org/ hasta tener una propia.

- Servidor contable: por programar. La base es Apache OfBiz, en este link esta los modelos de datos https://cwiki.apache.org/confluence/display/OFBTECH/Data+Model+Diagrams las reglas fiscales de cada pais y los mensajes serán externos, comenzare con las reglas de Ecuador, Colombia, Mexico y USA.

- Orquestador de procesos y flujo de trabajo: http://nginn.codeplex.com/ creo que cubre las necesidades presentes del proyecto. Y http://simplescheduler.codeplex.com/ da un motor para manejo de tareas usando http://quartznet.sourceforge.net/. El motor de BRMS (business rules management system) tengo la licencia de http://www.kontac.net/portal/Portal/SmartRules.aspx y un motor sencillo en open source http://www.codeproject.com/KB/cs/Rules_In_Your_Apps.aspx si no puedo adaptarlo para tener el mismo API, usare SmartRules.

Servidor de Integración y Seguridad (visible públicamente)

- Servidor de Comunicaciones, integración B2B y correo electrónico: comenzaremos usando http://mailsystem.codeplex.com/ , tengo el motor para transacciones bancarias (en java), tengo que migrarlo a C#.

- Servidor de identidades: por programar, el servicio WCF esta listo. Para la criptografía usare http://www.bouncycastle.org/ 

- Servidor de log, trace y monitoreo: por programar usando Enterprise Librabry 5, usará el mismo motor WCF del servidor de identidades, con objetos JSON.

- Servidor de sesiones y certificados transaccionales: por programar, comparte el motor WCF con el servidor de identidades.

- Servidor ECM – Enterprise Content Manager – http://www.sensenet.com/ la versión comercial está en Silverlight, una posiblidad es utilizarlo también para el servidor documental (en lugar de MojoPortal), pero hay algunos requerimientos de auditoría que suguieren el separar los componentes internos de los públicos, no sería nada agradable que alguien obtenga los informes financieros por "accidente".

En la maquina cliente:

- Servicio de identidad: por programar, el motor de comunicaciones esta listo.

- Shell de la aplicación: usare http://cinch.codeplex.com/ para crear la aplicación cliente usando WPF y Silverlight. Dispongo de una licencia de http://devexpress.com/Subscriptions/DXperience/editionEnt.xml creo que usare sus controles.

En empresas pequeñas todos los servidores estarán en la misma máquina, quizá para ese caso se escriba el código de comunicación con el motor ESB de forma condicional: Si es el mismo servidor use conexión directa sino use ESB.

Tengo 4 empresas reales para usar como banco de prueba:

Empresa A: Comercializadora, importa productos electrónicos y ofrece los servicios de instalación, mantenimiento y crédito directo. Oficina matriz, bodegas y almacén. 1 Servidor.

Empresa B: Comercializadora de productos de construcción, importaciones y ventas a mayoristas, distribuidores y ventas corporativas, bodegas y no tiene almacenes. Ofrece algunos servicios de ensamblaje y distribución por partes en diferentes ubicaciones, flota propia de camiones. Financiamiento directo basado en proyectos. 1 Servidor.

ONG C: Comercializadora de productos médicos y dueña de varios centros de salud. Importaciones, ventas a distribuidores, venta directa y consumo en atención al cliente. Dos hospitales del día (2 quirófanos cada uno) y más de 30 centros de salud, muchos sin conexión de alta velocidad a internet, deben funcionar con servidores remotos controlados. 2 Servidores en la matriz y 1 servidor en cada centro de salud. 1 sola empresa con varias ubicaciones.

Empresa D: Grupo de empresas distribuidoras de productos de construcción y maquinaria. Holding, y 19 empresas asociadas. Una hace la parte de importación. 12 con menos de 6 empleados, 6 con menos de 20 y la principal que no tiene almacén con menos de 30 personas.2 servidores en la matriz, 1 servidor en la holding, 1 servidor en cada empresa. 20 empresas distintas con integración contable como holding para análisis.

No creo poder hacer a la primera algo completo, por ejemplo: ESB, existe un componente en codeplex que cumple con las especificaciones ESB http://keystrokeesbnet.codeplex.com/ , inclusive se integra con servidores de terceros. Para propósito de este proyecto voy a usar un servidor WCF que hará de servidor ESB, dejando el camino para que se pueda usar en su momento un servidor ESB completo como puede ser Microsoft BizTalk o ESB.NET.

Igualmente existe un servidor BPM que cumple con una implementación de BPMN http://scenarioframework.codeplex.com/ , vamos a comenzar con un modelador sencillo de procesos, usando BPMN pero sin las capacidades de orquestación externa, exclusivamente para permitir describir los procesos administrativos cubiertos en el sistema. En las pequeñas empresas las mayores variaciones en implementación están en cómo se aprueba un proceso, si hay o no algún documento: por ejemplo la requisición de compra y 3 ofertas puede no ser necesaria. Creo que voy a utilizar http://nginn.codeplex.com/

Lo que si va a ser funcional desde el comienzo es el sistema contable, inventarios, tesorería y MRP.

Una de las limitaciones es enfocarse "empresas pequeñas de < 10 usuarios" y crecer hasta "empresas medianas de < de 50 usuarios".

El servidor documental no será Alfresco pero permitirá el almacenamiento y publicación documental, de echo tengo ya echo uno para una organización estatal que tiene algunos millones de páginas y la parte visual será con MojoPortal, DotNetNuke o algún otro existente.

En este momento solo está definido:

1.       Usar SQL Server 2008 R2 y escribir la mayor cantidad de código de aplicación en SP (sea TSQL o C#).

2.       Usar nHydrate para la escritura del servidor de entidades.

3.       Usar un esquema ESB para conectar entre servidores.

4.       Usar un motor BRMS para todas las reglas de negocio usando scripting y algo similar a Kontac SmartRules

5.       La primera versión será Windows Forms usando los controles de DevExpress y las formas serán almacenadas en XML, no en código.

6.       Se usara como modelo el schema de Apache Ofbiz http://ofbiz.apache.org/

 TODO COMENTARIO SERA APRECIADO, GRACIAS

Servidor de Datos

- Base de datos: SQL Server Express 2008 R2 with Advanced Tools: Se va a trabajar usando stored procedures y vistas, en ninguna parte del sistema se tendrá acceso a una tabla, esto permitirá al DBA dar soporte, configuración y adaptaciones sin afectar a la correcta operación del sistema, se escribirá el código para que los procesos administrativos requeridos luego de una transacción se ejecuten en un pool, por un agente SQL, en ambientes con muchos usuarios, el tiempo de respuesta luego de almacenada la transacción puede ser un problema si el servidor está en los límites de respuesta, por eso, las tareas administrativas serán realizadas posteriormente. Por ejemplo: registro del ingreso de una compra, el recalculo de los costos de inventario se haría por el pool, al completar el ingreso de la compra, se ordenara la ejecución del SP que hace el ajuste de costos, pero la ejecución será encolada para mantener un tiempo de respuesta predecible, en ambientes con poca carga transaccional, serán inmediatos. Trataremos en lo posible de convertir al SQL Server de un servidor de datos en un servidor de aplicaciones.

- Servidor de Entidades: Voy a usar nHydrate, es gratis y se ve bastante robusto, me gustaría utilizar IdeaBlade DevForce, pero la versión gratuita permite el tener solo 10 entidades simultáneamente y es un posible problema. En caso de necesitarse implementar ubicaciones múltiples, el servidor de entidades puede estar en un equipo diferente. Se comunicara usando WCF al servidor de datos.

Servidor de Aplicaciones

- Servidor y Repositorio de reportes, uno de los problemas que existe en implementaciones de ERP es la compartición de reportes, dashboards y PKIs, cuando un usuario cree un nuevo reporte tendrá la posibilidad de publicarlo, para todos los usuarios del ERP, para el grupo al que pertenece o solo para su uso, se escribirá el código para que un agente pueda disparar la generación automática del reporte en un horario planificado y enviar por mail a uno o varios destinatarios. El resultado del reporte será almacenado en el servidor documental y se dará acceso a los destinatarios y por mail ira el link para acceder al reporte. Deberá generar reportes en XBRL http://www.xbrl.org

- Servidor y repositorio documental, el tener acceso al archivo físico de un proyecto o contrato puede ser complejo, es mucho mejor que exista un repositorio documental que permita el disponer de forma inmediata la visualización de los documentos requeridos, en compras la imagen de la factura del proveedor, en proyectos es útil el contrato, en equipos los manuales de instalación, mantenimiento, publicidad del fabricante, copia del comercial que fue enviado a radio, prensa, televisión, etc, etc. Hay que crear un centro de registro documental, el cual recibe los documentos físicos, los indexa y asocia a los objetos del ERP y continúa el proceso definido.

- Project Server: en un sistema ERP se puede descontrolar la ejecución de tareas, y el ir documento por documento modificando las fechas esperadas de terminación o el registro del avance... puede tomar mucho tiempo, es mejor disponer de un servidor de proyectos que permita en forma visual ver la carga de trabajo de cada uno de los recursos de la organización y si se modifica una tarea, esta cambie los registros transaccionales automáticamente.

- Servidor contable: El sistema administrativo financiero, toda operación administraba tendrá su propio servidor, y los componentes serán creados como dad-in, esto dará la posibilidad de adicionar un tipo completamente nuevo de producto o forma de pago o proceso, en la mayoría de los procesos, básicamente será el gestor de llamadas el proceso que estará en el servidor SQL. Debe cumplir con las PCGA, FASB, NIIF y las normas legales de cada país.

- Orquestador de procesos y flujo de trabajo: la diferencia entre la empresa A y B, (en el mismo mercado vertical) suele ser a nivel de flujo de aprobaciones y autorizaciones, por eso, se construirá un BPM simplificado a la operación interna de la empresa, y su asociación con los roles y perfiles de usuarios, durante la ejecución del proceso el orquestador construirá el flujo del documento. El monitor permitirá el ver el estado de cada proceso, las personas que han participado y sus tiempos de respuesta. En caso que haga falta el administrador del proceso podrá reasignar a los participantes en un proceso específico, se necesita un control de versiona miento y de fechas de operación del proceso, para que el especialista en procesos pueda modificar con tiempo un proceso. Inicialmente los documentos que inicien en una versión del proceso, terminarán en esa versión, en la segunda edición del ERP se dará la posibilidad de mover flujos a versiones nuevas de procesos. Por propósito de este ERP, proceso es la definición conceptual de las relaciones entre documentos y las operaciones realizadas por los usuarios. Flujo es la ejecución real de un proceso.

Servidor de Integración y Seguridad (visible públicamente)

- Servidor de Comunicaciones, integración B2B y correo electrónico: todo ERP necesita estar comunicado, este servidor se dedicara a la recepción de correos, su asociación a un flujo, ruteo al funcionario responsable y en algunos casos la ejecución de comandos en el ERP, el poder exportar e importar documentos de otros sistemas y el enviar ofertas, copias de facturas u otro documento, reporte o imagen requerida. En caso de instalarse en un grupo empresarial, este servidor se encargará de los procesos de replicación e integración con el servidor central. Por ejemplo el servidor de un almacén, se conectará con el servidor central y se replicara para la integración.

- Servidor de identidades: Al ingresar un usuario al sistema se generará una identidad digital que tendrá limitaciones temporales para reducir la posibilidad de intrusión, a futuro se integrara con Directorio Activo y LDAP. Control de perfiles, roles, usuarios, niveles de acceso y en caso de definirse información sensible, la petición de autorización de acceso. Un ejemplo: en un almacén el cajero necesita eliminar o cambiar una venta, el administrador puede autorizar desde la caja o desde su consola, lo ideal: desde su celular o Tablet.

- Servidor de log, trace y monitoreo: permitirá el tener un control externo de todas las operaciones de todos los servicios y servidores que están en el sistema, el nivel de granularidad de monitoreo deberá llegar a niveles que permitan inclusive el visualizar de forma remota la estación de un funcionario en específico y verla en tiempo real o cuando sea necesario, debe integrarse al servidor de identidad.

- Servidor de sesiones y certificados transaccionales: el mayor problema es el controlar que se complicado el que un intruso pueda realizar operaciones no autorizadas, una forma que he utilizado es utilizando identidades digitales generadas al hacer login al sistema, más un certificado generado por cada sesión (por ejemplo: al crearse una nueva orden de compra, se crea el certificado de esa operación) que estará activo mientras esa operación no se complete y un certificado adicional de muy corto tiempo de vida para iniciar el proceso de conexión con el servidor o servidores que deben realizar la operación. Básicamente: con el certificado de identidad se solicita la creación del certificado de sesión y con estos dos se realiza la operación: begin - commit en la base de datos, al completarse el commit o rollback, el certificado de transacción desaparece, de esta forma un intruso debería tener pocos segundos para robar el certificado y hacer algo no autorizado.

- Servidor ECM – Enterprise Content Manager – Portal, blogs, foros: Ahora se necesita el mantener portales de la empresa para el público, portales para los socios de negocio (clientes, proveedores, socios) y para el personal de la empresa, lo ideal sería utilizar SharePoint framework, pero encontré un ECM en open source y estoy analizando si se utiliza ese o SharePoint. Aun no estoy seguro del licenciamiento de SharePoint para acceso web, de esto dependerá si se usa o no.

En la maquina cliente: Servicio de identidad y el Shell de la aplicación: En las estaciones de trabajo, puede volverse tedioso el esperar que se comunique el Shell con los servidores, para facilitar este proceso se escribirá un servicio Windows que se mantendrá conectado con el servidor de identidad, reduciendo este tiempo y debe ser un cliente el orquestador. Además debe realizar las actualizaciones de los componentes en caso que algún dll o configuración sea cambiada.

TODOS los servidores se conectarán entre si usando ESB (Enterprise service bus), básicamente existirá un solo servicio web (por servidor) para todo el ERP, excepto entre el servidor de entidades y el servidor de datos que será un canal WCF.

Desde el inicio se tendrá esta arquitectura, las funcionalidades de cada uno de los servidores será extendido hasta lograr el cumplimiento de los requerimientos. De inicio: servidor de identidad, servidor ESB, servidor contable, servidor entidades y servidor de bases de datos, servicio de identidad y Shell de la aplicación.

Esta arquitectura permite el crear anillos de confianza entre los servidores, lo ideal sería: maquina cliente -> firewall (control de intrusos) -> servidor de integración -> firewall interno (control de accesos no autorizados) -> servidor de aplicaciones (red interna) -> firewall (control de auditoria) -> servidor de entidades -> servidor de datos.

Esta arquitectura permite cumplir con las normas Sarbanes-Oaxley. http://es.wikipedia.org/wiki/Ley_Sarbanes-Oxley, y las normas internacionales se Auditoría Informática y Auditoría forense.

Todas las reglas de negocio estarán en archivos XML (criptografiados) para su facil distribución y uso. 

Uno de mis libros favoritos es “Accounting Information Systems” de James A. Hall, en este libro se hace un recuento de la evolución de los sistemas de registros de asientos contables, a los sistemas administrativos, los sistemas MRP, MRP II y el surgimiento de los ERP (nombre originado por el Gartner Group)

Sistema Tradicional

Un ERP es un sistema que agrupa los procesos clave de una organización: como el registro de órdenes de compra, inventarios, manufactura, rol de pagos y otros, por eso un ERP es conocido como el sistema “Back-Office” de un negocio.

http://es.wikipedia.org/wiki/Planificaci%C3%B3n_de_recursos_empresariales

ERP

En la actualidad toca disponer de mas herramientas, ahora se tiene los CRM (Customer Relationship Management) que se están extendiendo a ser ERM (Enterprise Relationship Management), SCM (Supply Chain Management), gestión de activos empresariales tanto intelectuales como estratégicos y documentales.

Todos estos sistemas unidos forman lo que ahora se llama de forma genérica sistemas estratégicos empresariales.

Una fuente de información es “Beyond ERP Systems: An Outline of Self-Referential Enterprise Systems”, ICB-Research Report No. 31 de abril de 2009 ( http://www.icb.uni-due.de/researchreports_en/nc/?sword_list%5B%5D=31 )

Si ponen en cualquier buscador “beyond ERP” encontrarán una cantidad considerable de información y discusiones sobre este concepto

Para llegar a cubrir un buen porcentaje de este concepto, usaremos una serie de herramientas y código existente actualmente en el mundo el “open source” .NET, hay realmente cientos de componentes y aplicaciones disponibles, vamos a buscar las que más se acerquen a los requerimientos y las utilizaremos o si hace falta escribiremos los que se necesiten.

Por ejemplo, siempre es cómodo el disponer de un grupo de componentes visuales, si tienen unos buenos que puedan ser utilizados, favor mandarme el link, mientras se encuentra unos buenos, la mejor opción es utilizar la oferta de DevExpress https://www.devexpress.com/Products/Free/NetOffer/, 60 controles gratuitos para Windows Forms.

En codeplex encontré algunas implementaciones de servidores y servicios ESB, estoy buscando algo sencillo y de fácil uso, como el objetivo es contruir un ERP completo en la misma plataforma, las opciones de integración las dejaremos para la segunda versión.

Para motor de reglas de negocio, me gusta SmartRules http://www.kontac.net/portal/Portal/SmartRules.aspx, antes existía una versión gratuita, lamentablemente la eliminaron, así q utilizare un motor para reglas de negocio que este disponible en la web, sera modificado para igualar el API de SmartRules y poder utilizar la versión pagada en algún momento.

Para el motor de scripting existen varias opciones, una de las mejores es un motor jscript http://jint.codeplex.com/ escrito en C#, lo estoy probando, en esta área mi mayor preocupación es la de utilizar un motor de scripting que dé acceso a toda la potencialidad de .NET y generar problemas de seguridad a largo plazo.

Para el acceso a datos, en proyectos comerciales prefiero IdeaBlade DevForce http://www.ideablade.com/, la versión gratuita está limitada a 10 entidades, y eso puede ser un problema, en su momento probare algunas opciones y espero sugerencias para seleccionar la más efectiva. Pero me gusta lo que ofrece nHydrate http://nhydrate.codeplex.com/

Para soporte, me gusta la Enterprise Library http://entlib.codeplex.com/, la versión 5 trae varias mejoras, igualmente CAB http://msdn.microsoft.com/en-us/library/ff648747.aspx para el manejo de iteración con el usuario es una buena opción, pero no se aún si será posible usar CAB con formas diseñadas y almacenadas en XML, no quiero tener las formas en código, quiero que todas las formas sean almacenadas en XML. Y CAB es a WIndows Forms como PRISM 4 http://compositewpf.codeplex.com/ para WPF y Silverlight.

Durante los últimos 30 meses estaba trabajando para Sage Software North América (http://www.sagenorthamerica.com), en el producto Peachtree (www.peachtree.com).

Razón por la que no podía avanzar en este proyecto sin un conflicto de intereses.

Pero ahora puedo retornar a este proyecto y tomar un camino basado en un modelo de datos de un ERP existente en Open Source.

Para disponer de un sistema ERP funcional se requieren algunos componentes:

Servidor de Datos

- Base de datos: SQL Server Express 2008 R2 with Advanced Tools, se tomarán todas las medidas posibles para facilitar al DBA sus tareas.

- Servidor de Entidades: Puede ser con Entity Framework o NHibernate o IdeaBlade express

Servidor de Aplicaciones

- Servidor y Repositorio de reportes

- Servidor y repositorio documental

- Project Server

- Servidor contable

- Orquestador de procesos y flujo de trabajo

Servidor de Integración y Seguridad (visible publicamente)

- Servidor de Comunicaciones, integración B2B y correo electrónico

- Servidor de identidades

- Servidor de log, trace y monitoreo

- Servidor de sesiones y certificados transaccionales

- Servidor ECM – Enterprise Content Manager – Portal, blogs, foros

En la maquina cliente: Servicio de identidad y el Shell de la aplicación

Para simplificar las comunicaciones se utilizara un ESB (Enterprise Service Bus) simplicado construido con WCF, toda interacción entre los servidores será usando el canal ESB, usando un certificado de identidad, certificado de sesión y certificado de transacción.

Posteriormente se adicionara un servidor OData (http://www.infoq.com/news/2009/11/OData-GData-Microsoft-Google) para acceso transaccional desde móviles tanto Android, iOS, RIM y Windows pone 7.

Si el tiempo lo permite se pondrá un servidor SData en lugar del OData (gracias Sage por hacer público SData http://sdata.sage.com/ ).

Se mantendrá un diseño por capas manteniendo todos los servicios, servidores y ejecutables con la siguiente organización:

Capa recursos: Enterprise library, servicio de actualización de componentes (updater application block), proveedor de recursos (textos, help, iconos) y conexión al servidor de entidades.

Capa reglas de negocio: reportes en RDL (integración con SQL Reporting Services), Reglas de negocio de configuración, herramienta para exportar o importar datos de archivos texto o XML, motor de ejecución de los flujos de proceso y trabajo, reglas de validación de datos, monitor reglas de negocio y motor de scripting.

Capa de aplicación: 3 capas, 1) para toda la aplicación, 2) para especificar reglas para un mercado vertical y 3) para especificar reglas de la implementación (cliente).

Capa de presentación: replicación de las reglas para reducir al mínimo el tiempo de espera, motor de scripting. En lo posible se tratara de reusar el código tanto para Windows Forms como para WPF y Silverlight.

Todas las capas se conectaráon con motores de trace, log, WMI, excepciones y un monitor.

El motor de trace estara enfocado a llevar un rastreo de las operaciones internas del sistema, tanto por depuración como para auditar al sistema.

El motor de excepciones estara enfocado en apoyar a las correcciones y mejoras de la aplicación

El monitor estara enfocada en la operación, ejecución y apoyo, Permitira monitorear procesos, operaciones, usuarios, documentos y PKI.

Metodologicamente se tratara de hacer todo el sistema basado en plug-ins usando MEF.

Normalmente se trabaja por etapas

pero cuando completamos la etapa de diseño, NO tenemos el 50% de avance del trabajo.

Si empezamos a trabajar con una de las metodologías ágiles

podemos lograr avances y al llegar al 20% del tiempo, tenemos un 20% del sistema … usable y funcional.

Durante los 2 últimos años he trabajado utilizando SCRUM, en las charlas de Microsoft y en clases … la pregunta es: usando SCRUM como se inicia un proyecto desde 0 (cero)?.

Hasta ahora no he encontrado un proyecto que haya empezado desde cero con SCRUM, he empezado alguno proyectos pero utilizando un híbrido

Utilizar Waterfall hasta llegar al diseño conceptual, arquitectonico y funcional del proyecto y continuar con el diseño detallado del sprint 1, con SCRUM. He logrado que funcione y luego es facil continuar solo con SCRUM.

Para acelerar el proceso, voy a partir de un ERP existente, y realizar las primeras etapas usando un producto existente como si fueran los requerimientos del cliente.

Entonces, primer paso: seleccionar un ERP Open Source a utilizar como “objetivo”, no voy a migrar o reescribir el ERP seleccionado, solo a utilizarlo como requerimiento: “el nuevo debe hacer por lo menos lo que existe en el ERP xxx”

Que requerimientos se tomó en cuenta para llegar a este diagrama?

Uno de los problemas mas repetitivos que he tenido que padecer es la actualización de versiones, tratando de proteger los cambios realizados para una implementación específica.

Debido a esto se han tomado algunas desiciones:

El framework esta dividido en 5 componentes principales:

1. Resource Access Layer
2. Business Layer
3. Application Framework
4. Client Layer
5. Support Framework

Resource Access Layer

Se le construyo utilizando Microsoft Enterprise Library 4.1 (Octubre 2008)  (http://www.codeplex.com/entlib), una version modificada del Update application block (http://msdn.microsoft.com/en-us/library/ms978574.aspx) un motor de script creado internamente usando como modelo CS-Script (http://www.csscript.net/) y la utilización de la versión gratuita de IdeaBlade DevForce for the Entity Framework (http://www.ideablade.com), este componente esta en estudio, puede que se utilice Telerik Open Access ORM (http://www.telerik.com/products/orm.aspx) o CSLA.NET (http://www.lhotka.net/cslanet/)

En http://www.zachmaninternational.com/index.php/the-zachman-framework está una de las visiones mas claras de los requerimiento de una organización.

Y voy a realizar lo necesario para lograr que este proyecto cubra las necesidas de las empresas siguiendo el ZIFA Framework.

He pasado investigando varios frameworks que pueden ser usados, y leyendo código ... miles de lineas de código.

Usar un framework u otro ... como la disyuntiva de Shakespeare ... ser o no ser.

Por el momento:

CSLA.NET 3.6.2  http://www.lhotka.net/Default.aspx y un utilitario para generar código http://www.eurowisesoft.com/CodeComplete/Productinfo/Overview/tabid/453/language/fr-FR/Default.aspx realmente funcionan muy bien.

Ya tengo el diseño de la base de datos, una combinación entre Baan, SAP, Navision y OfBiz, con algo de OpenERP y otros ERP open source.

En los siguientes meses voy a construir los 2 componentes mas importantes (desde mi punto de vista) de un ERP, el motor de proyectos y el GL (libro mayor) - control de tiempo y dinero).

Para eso debo completar el framework.

Estoy haciendo un proyecto para un institución financiera y empece a escribir el framework.

Estoy reactivando la pagina web www.empresadotnet.com y voy a publicar los diseños y espero que en julio ya tenga el alpha usable.

La complejidad del OpenFramework esta en http://www.empresadotnet.com/Productos/OpenFramework/tabid/146/Default.aspx y voy a mantener este esquema hasta tener una prueba de concepto o ... morir en el intento.

He trabajado con varios sistemas ERP, (baan, sap, MS Dynamics GP, MS Dynamics AX y otros), apoyando la instalación o configuración o en alguna de las cientos de posibles tareas que se requiere para que entre en producción un ERP en una empresa de tamaño mediano.

He visto uno que otro éxito y varios fracasos. Los fracasos en su mayoría fueron por la falta de organización en la empresa para poder soportar sistemas integrados y basados en procedimientos. Las empresas no estaban listas para sistemas que limiten las "facilidades" de los usuarios en realizar su trabajo diario. Obviamente, la culpa es del software, esa fue siempre la opinión final.

En la realidad, desde mi punto personal de vista, el fracaso fue por la falta de facilidades de configuración de los sistemas ERP de calidad mundial, en el mundo altamente desorganizado de américa latina. El recuerdo más vivido es el de una empresa textil que tenía un oligopolio en unos productos; cada fin de semana el dueño se dedicaba a pensar nuevas formas de vender y aumentar su participación del mercado sin llegar a que el gobierno interviniera diciendo "monopolio". Y su creatividad era muy superior a la del software de configurarse para esos escenarios.

Por eso:

Requerimiento 6: Todos los procesos deben ser cambiables en tiempo de ejecución, ser puestos en un servidor de reglas de negocio, en tablas de reglas, en parámetros, en código "script". Configurables sin necesidad de disponer del código fuente.

Requerimiento 6.1: Todos los módulos deben ser "loose coupled" para facilitar las actualizaciones y el incremento de nuevas opciones.

Requerimiento 6.2: Se debe disponer de un SDK para la creación o reemplazo de componentes; para ser usados por los clientes o socios de negocio que deseen construir componentes adicionales.

Requerimiento 7: El sistema debe soportar el cambio de las versiones tratando de disminuir el impacto a las configuraciones realizadas en la instalación y operación del sistema.

Requerimiento 8: Debe soportar las leyes, reglas, normas y costumbres de los diferentes país de habla hispana. Igualmente las monedas, idioma y ayudas.

Por donde comenzar?

Es la pregunta de mis alumnos, la respuesta es simple:

1. Requerimientos
2. Planificación del proyecto
3. Análisis y diseño de la arquitectura del sistema
4. Diseño del plan de pruebas de la arquitectura
5. Análisis y diseño del framework base
6. Diseño del plan de pruebas del framework base
7. Análisis y diseño del API del sistema
8. Diseño del plan de pruebas del API
9. Creación del plan de desarrollo usando SCRUM
10. Programación y pruebas unitarias del framework base
11. Programación y pruebas unitarias del SDK para la construcción del sistema
12. Programación y pruebas unitarias del sistema
13. Pruebas del sistema
14. Programa piloto de uso

Suena largo y extenso, si, pero es la única forma de tener un sistema comercial.

Que diferencia un sistema comercial de un sistema interno de una empresa? La respuesta es el número de usuarios y el costo de soporte, en un sistema comercial el precio de venta está definido por mercadeo, el costo de soporte está supeditado a la calidad del sistema, menor calidad mayor costo de soporte, por eso los esquemas de open source que algunas organizaciones ponen en su desarrollo, el costo del soporte lo comparten con los usuarios ... en realidad son subsidiados por ellos.

La otra diferencia es la durabilidad de un sistema comercial, conozco productos de software que tienen mas de 10 años de uso, con mejoras contínuas, donde la primera versión no tiene relación con la última, desde el punto de vista del usuario, pero tiene un gran porcentaje del mismo código fuente desde el punto de vista de los programadores.

Otro punto importante es la documentación para el usuario, el control de calidad del producto y el soporte al usuario final. Los productos mas exitosos en el mercado no han sido los mejores sino los que cuentan con mejor soporte.

Por años he escuchado la misma opinión de gerentes generales y gerentes de tecnología: "no es el mejor producto, pero tienen el mejor soporte" y pagan por eso.

Requerimiento 1: El sistema debe estar enfocado a pequeñas (< 10 usuarios) y medianas empresas (< 50 usuarios). Dando todas las facilidades para la operación diaria y facilitando el crecimiento de la solución hasta cubrir las necesidades de la organización.

Nota 1: Lo que cuenta son los usuarios del sistema, no los empleados o los montos de la organización. En la actualidad un pequeña empresa puede tener cientos de empleados (factorías, tercerizadoras, agrícolas, distribución) y solo unos pocos usuarios del sistema.

Requerimiento 2: El sistema debe estar enfocado en la operación diaria de la empresa, no en el seguimiento de transacciones. Todo debe estar enfocado en la administración del proceso.

Requerimiento 3: Todo el sistema debe ser declarativo, configurable y modificable por el que instala o por el usuario final.

Requerimiento 4: Todo debe tener un "wizard" para facilitar el proceso de creación de componentes como empresa, usuarios, productos.

Requerimiento 5: Debe existir una versión de 1 usuario que utilice pocos recursos, pero que se integre con la versión general.

Asi que, tenemos que empezar por la arquitectura de la aplicación y que herramientas vamos a usar.

Por que .NET?

La razón es simple, me gusta .NET. He trabajado con productos de Microsoft durante años y ésta es la primera vez que estoy de acuerdo con Microsoft: .NET es una maravilla (comparado con lo anterior de Microsoft) y tengo acceso a las herramientas y componentes.

Herramientas 

Microsoft .NET Framework 3.5, Visual Studio 2008, SQL Server 2008.

Red-Gate Sqltoolbelt, Embarcadero ER-Studio, VersionONE

TODO COMENTARIO ES BIENVENIDO.

Existen varios sistemas administrativos (Contabilidad, inventarios, tesorería, nómina, etc) funcionales, pero no he encontrado uno de buena calidad como los que disponibles en Ingles (Peachtree, Quickbooks, Office Acounting, etc).

Estoy comenzando el desarrollo de un sistema, en este blog voy a mantener el punto de analisis y discusión sobre este sistema, el cual se encontrara en www.empresadotnet.com.

Espero comentarios, ideas y colaboración para que este sistema sea útil y funcional.

Obviamente sistemas como los mencionados son realizados por equipos de 100 o más técnicos, asi que lo que busco en este desarrollo es mostrar las formas de utilizar componentes y el desarrollo orientado al negocio.

Voy a utilizar varias librerías existentes, unas gratuitas otras pagadas como: Enterprise Library 4.1, Kontac SmartRules, Developer Express, IdeaBlade DevForce, CSLA.NET, Castle entre otras. Parte del proceso será el probar éstos componentes y ver cual nos ofrece ventajas en el desarrollo de este proyecto.

El proceso será el siguiente

• Definir el alcance del proyecto
• Realizar el diseño conceptual del proyecto
• Planificar usando SCRUM
• Empezar con los sprints

Veamos como nos va!!!!