Blog de JoseMPelaez

Aprendimiento: aprender del entorno con atrevimiento

Posts Tagged ‘ERP’

Paradojas en la arquitectura maestra

Posted by josempelaez en Miércoles, 2 julio 2008

En las dos notas precedentes reflexioné sobre los programas orientados a procesos y a datos, y sobre la integración de aplicaciones empleando estructuras comunes de datos, entre otros medios. En ambos casos eché mano de mis recuerdos informáticos con la idea de explicar-me —”a mí, mismamente”, a mi penfriend Luis y a quienquiera leerlas— por qué no comulgo con la idea de que los datos maestros de las aplicaciones transaccionales deben estar en un sitio común.

ERP monoliticoCierto es que los llamados ERPs (Enterprise Resource Planning), que también se han denominado «paquetes integrados de gestión empresarial» precisamente por ello, resolvieron varios problemas derivados de las lagunas e inconsistencias de la información procesada con aplicaciones que formaban sistemas deslavazados. Por cierto, que quien empleó lo de planificación para referirse a estos sistemas transaccionales no debía de saber mucho de operaciones, o le encantaban las paradojas. Además, hubiera sido mucho más veraz referirse a controlar, y no a planear.

No obstante, en la misma década de los 90 en que se propagaron los anteriores, también se difundían modelos de interoperabilidad de sistemas. El CORBA del OMG en el plano de la aplicaciones, y el DCE/RPC del OSF en un nivel más bajo, fueron promovidos por algunas empresas relevantes de tecnología como alternativas flexibles al monolitismo de la base y modelo de datos únicos.

Sin embargo, a pesar del buen nombre de sus promotores, se impuso el modelo integrado de datos para construir los nuevos sistemas de información (SI) empresariales frente al de las interfaces técnicas entre aplicaciones especializadas. Ello sucedió, de nuevo paradójicamente, en el marco de una gran expansión del empleo de las redes locales (LAN) y la arquitectura C/S derivada. Creo que la clave está en que SAP, como gran propulsor de modelo triunfador, era una empresa de programación que nació para resolver un problema importante de los financieros.

Además, en 1993, tras haber logrado el apoyo de las dos grandes empresas de miniordenadores de la época (HP y DEC), supo ceder servicios de implantación para poder crecer más rápido aliándose con las grandes empresas de consultoría de negocio. Éstas vendían el BPR a los miembros (y “miembras”, según Aído) de los comités de dirección de sus clientes empresariales. Prometían que la “nueva” herramienta (R/3) de SAP, que promovían y en la que habían formado a su gente, iba a materializar los deseados cambios. ¡Y vaya si tuvieron que cambiar para adaptarse al modelo funcional del nuevo paquete, aunque no creo que fueran exactamente esos sus ansiados deseos!

Las suites de aplicaciones comenzaron a aparecer al poco por dos motivos adicionales a los tradicionales de especialización y flexibilidad. Por un lado, como resultado de las adquisiciones de business software hechas para crecer más rápido por empresas como Oracle, Descartes Systems, i2 Technologies, SAP, etc. Había que integrarlas con las existentes y, con sus bases de clientes, no se podían permitir el rehacerlas desde el núcleo para que tuvieran las mismas estructuras maestras que las aplicaciones del adquirente.

Por otro, los ERP transaccionales derivados de los programas de contabilidad (FABS), o de los de planificación de la producción (MRP), no cubrían importantes áreas de actividad cotidiana (CRM, SRM, PLM…). Ni para el director financiero ni el de producción las visitas comerciales debían de ser relevantes para “sus negociados”. Tampoco cubrían las funciones más propias de los DSS, que sí interesaban a ambos, pero que se dejaban fuera porque entonces podían “tumbar” los servidores con algunas de sus “potentes queries“.

Creo que la situación actual es la descrita al final de la entrada sobre Estructuras maestras. El uso de internet (una arquitectura C/S abierta, al fin y al cabo) ha determinado que los «servicios web», herederos del CORBA, estén predominando en la interacción entre sistemas modernos, que ya no son los ERPs. HP llegó a llamar e-speak a este enfoque a mediados de 1999. Microsoft comenzó a referirse a un concepto similar con la etiqueta .Net un año después. IBM hablaba de e-business desde años antes.

Las necesidades del comercio internacional (OASIS y UN/CEFACT), y el apoyo del consorcio de estándares de internet (W3C), han ido afianzando la difusión del XML como elemento esencial de dichos servicios de conectividad e interacción. En el terreno de las aplicaciones para consumidores, los agregadores de contenido (RSS) y las interfaces gráficas de usuario (GUI) basadas en Ajax también lo difunden con profusión.

¿Quieres saber las implicaciones y lo que opino sobre todo lo anterior? Por favor, lee la entrada siguiente y última de esta serie sobre estructuras de datos maestros comunes titulada «Paradojas en el proceso».

[Ilustración 1: Software as a concrete block. Blog ZDNet Phil Wainewright]
[Ilustración 2: Esquema de mySAP Business Suite. SAP]

Posted in integración | Etiquetado: , , , , , , , | Leave a Comment »

Flexibilidad del SaaS

Posted by josempelaez en Lunes, 23 junio 2008

plexus web siteHoy me he llevado una pequeña alegría al toparme con Plexus Systems y su aplicación online para gestión de empresas manufactureras. ¡Por fin encontramos a alguien con quien poder compararnos en el SaaS de operaciones!

En su web ofrecen una explicación ilustrativa sobre las capacidades de su herramienta. He tomado nota para cuando hagamos la nuestra. Me ha parecido un buen ejemplo visual en línea con las presentaciones de Xplane, aunque interactiva.

He llegado a ella al haberme encontrado previamente un artículo en el que su máximo responsable advierte contra el secuestro del término SaaS que hace una buena parte de la industria de IT. No voy a entrar ahora en lo que sostiene sobre las antiguas ofertas de los ASPs, las viejas aplicaciones habilitadas para la web, o el nivel de multi-tenancy requerido para poder ser calificado como un verdadero SaaS. Lo que ha llamado mi atención es una frase donde dice que:

«All customers run off of the same code base. […] Customers can deploy the application very rapidly, since they don’t have the lead time and hassles associated with configuring their local environments.»

¿Qué querrá decir con que los clientes no tienen que lidiar con las dificultades asociadas a las configuraciones locales de su entorno? ¿Se refiere sólo a la plataforma técnica? ¿Incluye también el software?

No estando seguro he buscado más en su web para ver si salía de dudas. Sólo he sido capaz de encontrar algo relacionado en unos puntos de su apartado de beneficios. En ellos dicen:

  • «[…]Fully integrated system
  • Flexible
  • Standard modules for all aspects of manufacturing
  • Special configuration where required[…]»

No es mucho, pero lo de «especial cuando se requiera» me ha dejado pensativo. También me ha sorprendido observar que organizan la funcionalidad de su ERP en términos de «áreas de software», a pesar de decir que son expertos en fabricación.

Por otra parte, en sus áreas, no incluyen nada relativo a los flujos de trabajo que desencadenan las peticiones de servicio, pedidos de clientes, órdenes de compra, etc., aunque sí hablan de programación de la producción y tareas de mantenimiento (orientación interna de optimización de la producción). Tampoco se refieren entre sus características a la posibilidad de configurar de manera estándar diferentes procesos operacionales (fábrica, almacén, taller, etc.) en función de las circunstancias.

Visto lo visto, y a riesgo de equivocarme, he llegado a la conclusión de que parecen modernos en su modelo de oferta informática, pero que deben de ser bastante antiguos en su enfoque de gestión de la empresa industrial.

En su página de portada también dicen que:

«Plexus is the only company in the world to deliver a comprehensive software solution for manufacturers via the software as a service delivery model, speeding technology deployments, lowering costs, and accelerating time to value.»

Además de no estar de acuerdo con la primera parte de su declaración (tenemos clientes que usan el nuestro para prestar a los suyos un servicio compartido y personalizado de gestión de “cajas” y de información), creo que no han profundizado bien en las implicaciones del SaaS.

Opino que éste no se refiere sólo a que todos los clientes comparten el código y estructuras de datos y documentos en una sola instancia, accediendo cada uno a sus datos de forma exclusiva, controlada y segura, obviamente. También debe poder lograrse de manera estándar (con plantillas y configuraciones que no sean “especiales”) que sus procesos operacionales de fabricación, logística y servicios sean específicos y acordes con sus necesidades.

Es decir, los modelos SaaS también deben distinguirse por su nivel de flexibilidad. Hay quienes se refieren sólo a que se pueden emplear unos módulos u otros según la empresa cliente, con pantallas según los usuarios, y con campos según sus necesidades.

Por otro lado, están los que sostenemos que la flexibilidad también ha de referirse, sobre todo, a que cada cliente de la instancia multi-tenant pueda introducir sus propias reglas y parámetros del flujo de proceso. Ello afecta a todas las actividades que median desde el tratamiento de los pedidos a los criterios de costeo y facturación de productos (bienes o servicios).

Todos los vecinos de un edificio en comunidad comparten ciertos servicios (ascensores, tuberías ascendentes y bajantes, piscina y jardín, etc.) y normas de uso de los espacios comunes, pero cada uno reforma y amuebla su casa como quiere, y desarrolla en ella las actividades que le apetece (siempre que no sean molestas, insalubres, peligrosas…, claro).

[Imagen de Plexus]

Posted in software | Etiquetado: , , , , , , | 3 Comments »