Archivo de la categoría: Tecnología

La formación, factor clave de un proyecto ERP

La implantación de un sistema ERP tiene dos caras, una técnica y tecnológica y otra humana. Es imposible pretender el cambio de un sistema que da soporte a la práctica totalidad de las operaciones de la empresa no tenga ningún impacto en las personas que la integran. No solamente tienen un impacto a nivel de individuo, sino que también puede llegar alterar los departamentos y grupos de poder dentro de la empresa y los equilibrios que entre ellos se establece.

Y esta es la clave del asunto, que hemos repetido en otras ocasiones. Da igual que  compremos el mejor software del mundo (si es que alguno de recibir es título), que la implantación haya sido perfecta, ajustándose totalmente a un concienzudo documento de requerimientos del sistema. Si no conseguimos que la gente aprenda a utilizar la herramienta de la manera más productiva posible. Y no sólo eso, también es necesario que tengan una actitud positiva hacia el proyecto y la herramienta. Y para eso es necesario hacer un proyecto enfocado a las personas, en el que la formación juegue un papel fundamental.

Una industria centrada en las herramientas

La industria del software empresarial y todo su aparato circundante, principalmente las empresas de consultoría y servicios asociados tiene una fijación con la herramienta, debido a las estructuras de mercado y a la alta inversión requerida para poder crear una solución o prestar un conjunto de servicios solventes alrededor de la misma.

El caso es la herramienta es importante, pero más importante todavía es el uso y el dominio que se tiene de ella. El hábito no hace al monje, ni al artista ni al empresario. Vemos continuamente ejemplos de grandes obras de arte creadas sobre una taza de café, o con arena de playa creadas con herramienta rudimentarias. Así mismo grandes empresas han sido creadas en garajes.

Imagen1

Está claro que no es posible edificar el Vaticano con un cubo de arena y unas palas y  que no se puede gestionar la General Motors con una libreta y un boli. Pero eso sí siempre hará más un equipo preparado con libreta y boli que no un equipo incapaz con el ERP más potente del mundo.

Puntos clave para una formación exitosa

Los puntos clave para que la formación nos permita rentabilizar al máximo nuestra inversión en cualquier sistema de gestión son los siguientes:

  1. Generar ilusión en el usuario acerca del impacto positivo que tendrá la herramienta en su
  2. Capacitar al personal para que pueda realizar su trabajo. Haciendo hincapié en las diferencias con el anterior sistema y especialmente en las modificaciones a nivel de proceso que se hayan planteado.
  3. Transferir conocimiento a nivel de usuario que permita manejar la herramienta con más fluidez y soltura: navegación general, atajos, trucos, menús rápidos.
  4. Incluir ejercicios prácticos guiados.

Comparativa Axapta vs JD Edwards (VI): Logistica: Almacén, Transporte

jd_vs_axaptaEn este articulo revisaremos la funcionalidad disponible en ambas en el apartado de logística, en el que incluimos: inventarios, gestión de almacenes, transporte y en general toda la funcionalidad relativa al movimiento y almacenaje de mercancias, materias primas y suministros.

Gestión de Inventarios:

Ambas soluciones disponen de una gestión de inventarios muy capaz, que posibilita la gestión de varios de almacenes. También son capaces de manejar lotes y distintos métodos de gestión de inventario como FIFO y LIFO, así como análisis de tipo ABC. Ambas soluciones distinguen entre materias primas, productos terminados, y demás. Desde su versión 2012 Axapta ha incorporado las múltiples unidades de medida para artículo que ya venían incorporadas en JD Edwards desde hace años.  La capacidad de ambas aplicaciones para incluir información es bastante notable.

Los dos ERP permiten el comercio intracompañías de un mismo grupo, facilitando la creación órdenes de venta y compra asociadas así como los movimientos de mecancias entre subsidiarias.

Cabe aquí destacar la capacidadd de JD Edwards para manejara artículos multiatributo de forma nativa, gracias a su módulo de Apparel Management. También es imporatante destacar la capacidad de JD Edwards para Gestión de graneles funcionalidad que no hemos podido hallar en Microsoft AX. Tampoco hemos podido verificar la capacidad de Microso AX para gestionar  Kits y componentes que si que hemos verificado para el ERP de Oracle.

Gestión de Almacenes:

Tanto JD Edwards como Axapta disponen de capacidad para gestión de almacenes basadas en ubicaciones físicas de los artículos, dando soporte operaciones de picking, reposición y entrada de stock.  Ambas soluciones disponen además de capacidad para integrar soluciones de RFID junto con el ERP. Tambén los dos paquetes nos ofrecen cierta discreccionalidad a la hora de organizar nuestro almacén, con zonas de almacenamiento de distinta priorida o almacenamiento caótico.

No obstante JD Edwards destaca también en este apartado al aportar alguna funcionalidad extra muy valiosa como el Cross Docking, la selección de proximidad y en general una mayor posibilidad de parametrización lo que se traduce en mucha más flexbilibdad a la hora de gestionar nuestro almacén.

Gestión de Transportes:

Esta funcionalidad es exclusiva de JD Edwards con un módulo dedicada a tal propósito. La funcionalida de Axapta en este apartado es bastante limitada. El modulo en cuestión nos permite la gestión de transporte tanto de bienes empaquetados como productos a granel. Permite la utilización de reglas predefinidas por el usuario para enrutados, selección de fletes y carreras, etc.. También esta preparado para la monitorización de envíos en directo.

Esto es todo por ahora. Esperamos que os sea de ayuda

¿Como funciona Oracle Fusión?

Oracle-fusion1

La respuesta de Oracle ante las demandas de los clientes de una funcionalidad más específica, totalmente integrada y con menores costes de despliegue y mantenimiento, es ofrecer una arquitectura basada en dos capas: tecnología y aplicaciones con un modelo unificado de datos. Esto permite que las aplicaciones puedan ser fácilmente desplegadas e integradas. Las aplicaciones de Oracle Fusion están construidas para trabajar e integarse fácilmente con otras aplicaciones.

Todas las aplicaciones corren sobre una plataforma tecnológica común, que gestiona sesiones seguridad, presentación en pantalla, integraciones, workflow y otras capacidades subyacentes del sistema. Además comparte un modelo de datos unificado, que integra los principales dimensiones y métricas de sistemas ERP, SCM, CRM y HCM. Lo que facilita la integración entre ellas.

Oracle ha construido una paltaforma totalmente basada en estándares bien establecidos como el XML para metadatos y BPEL para workflow, etc…  De esta manera se lleva la arquitectura SOA al corazón de la solución. Con más de 11.000 servicios preconstruidos.

Esto permite a las empresas disponer de un mejor acceso al talento a la hora de desarrollar y adoptar sus sistemas, reduciendo costes de implantación y simplificando la gestión e integración con otras aplicaciones.

Pero además de todo esto Oracle Fusion también aporta característica innovadoras que llevan las aplicaciones empresariales a un nuevo nivel como la experiencia de usuario basada en roles. Que nos solamente ofrece interfaces totalmente adaptadas a las necesidades de los distintos puestos en la organización, sino que además guía al usuario a través de su trabajo, ofreciéndole en todo momento información sobre que debe hacer, como lo puede hacer y con quien puede colaborar.

La integración total de las aplicaciones permite un diseño de flujos de trabajo muy avanzado. El usuario puede mediante herramientas gráficas configurar los procesos de su empresa que implican a distintos usuarios utilizando múltiples aplicaciones. Teniendo la seguridad de que su sistema es el soporte perfecto para desarrollar el modelo de negocio de su empresa.

Oracle Fusion incorpora el fenómeno de la web 2.0 con herramientas que aportan conectividad, contextualización y seguridad a lo usuarios.

La inteligencia de negocios está totalmente embebida en las aplicaciones y adaptada a las necesidades de cada usuario.

¿Por qué Oracle Fusion?

Oracle-fusion1

La evolución del mercado de aplicaciones empresariales

Durante los años sesenta se comenzó el desarrollo a  gran escala de aplicaciones para empresas. En principio eran soluciones de propósito específico que servían a un área funcional concreta de la empresa: contabilidad, fabricación. Fue así como se fueron naciendo los MRP y las suites financieras.  Con el paso de los años las corporaciones fueron conscientes de la complejidad que suponía tener integrados varios sistemas y esa así como surgieron los ERP,  grandes paquetes de aplicaciones que integraban en una única solución todas las áreas funcionales de la empresa.

Los ERP son por naturalezas modulares y extensibles, lo que permiten incluir desarrollos específicos para adaptarlos a las necesidades de cada compañía. Parecía que los modelos de arquitectura de soluciones de negocio habían alcanzado su cenit. Pero no fue así.

Lo realmente curioso es que el siguiente movimiento fue una involución. Comenzaron a surgir aplicaciones de nicho que cubrían las necesidades muy específicas en determinadas áreas de cada empresa. En cierto modo las aplicaciones CRM fueron las primeras en romper esta brecha. Las ventas son en el área más difícil de estandarizar de una empresa. Los departamentos de ventas están en contacto continuo con el entorno de la empresa. Han de captar rápidamente los cambios y adaptarse al vuelo  para poder dar respuesta. Los ERP en cierta medida suponen una burocratización de la empresa y esto no deja crear cierta urticaria en los vendedores, que siempre han visto los sistemas de gestión como unos ladrones de tiempo y una forma de control. Unos ladrones de tiempo que les hacen perder una o dos horas de tiempo al día rellenando partes y unas herramientas de control que intentan fiscalizar su trabajo como si fuera operarios de máquina.

Sea como sea, el surgimiento del CRM evidencia un cierto fracaso en la filosofía del ERP ya que a día de hoy todavía no he conocido un solo paquete que haya conseguido una total integración del área de ventas  satisfactoria. En el hueco de esta brecha han ido aflorando aplicaciones como Salesforce, Sugar CRM y un largo etc.. Pero esto sólo fue el principio, otras áreas funcionales les han seguido como el Marketing, la gestión de transportes, los SGA.

Los suites de inteligencia de negocios, disociados del propio ERP también son una muestra más de la incapacidad de estos paquetes transaccionales para dar respuesta a un importante requisito en la empresa actual: la explotación analítica de todos los datos que genera la empresa en sus multiples operaciones.

Las razones de una involución: ¿Quién mucho abarca poco aprieta?

Si la evolución de la tecnología y la gestión en las empresas habían conducido de manera clara a la filosofía de integración del ERP,  ¿cómo puede haber tenencias totalmente contrarias en el mercado?  Las razones son de los más dispares.

Para comenzar, no hay una fórmula mágica que funcione para todos. Cada empresa es un mundo, incluso compañías que compiten en los mismos mercados tienen modelos de negocio  totalmente diferentes. A veces la complejidad y el sobrecoste que genera tener varios sistemas dentro de la empresa se ve compensada por la capacidad operativa  y la funcionalidad específica que incorporan-

En segundo lugar debemos, los sistemas ERP son complejísimos y a veces la única manera de integrar muchas áreas funcionales es base de que cada una de ellas renuncie a un poco. El ejemplo más claro lo vemos en las interfaces gráficas. Lo idóneo sería que existiera una interfaz gráfica para cada rol de usuario: gestión de pedidos, colección de deudas, planificación de fabricación, etc.. Lo que en realidad sucede es que con unos pocos elementos comunes se construyen todas las interfaces de usuario, lo que hace que al final todas sean bastante inespecíficas, poco diferenciadas y estén pobremente adaptadas a las necesidades de cada usuario. A la postre la experiencia de usuario tiende a ser muy pobre nicho  a pesar de que los fabricantes se están esforzando últimamente por salvar este escollo, algo que no sucede en las aplicaciones de nicho.

Pero existe todavía una razón más de fondo, que hace  muy complejo el modelo de desarrollo puesto en práctica por los grandes ERP´s. Este es el funcionamiento a la inversa de la ley de economías de escala en cuanto al desarrollo de software se refiere, o lo que es lo mismo. Las economías de escala no funcionan en absoluto en este negocio.

La programación es principalmente un proceso mental e interno que se traduce en output externo: el código.  Para trabajar varios programadores juntos tienen en cierta medida sincronizar sus mentes. Tener una visión clara del proyecto, saber con precisión que tiene que hacer cada uno y establecer una metodología para que el código desarrollado por distintos programadores pueda ser integrado. Además cuando se trabaja en grupos de desarrollo es necesario documentar exhaustivamente el proyecto lo que ralentiza la velocidad de desarrollo de cada programador.

Este fenómeno ya fue notado en los años 70 por Fred Brooks que escribió su mítico libro: “El mítico hombre mes”, donde nos viene a decir que en el desarrollo de software menos es más. Cuanta más gente añadamos a un proyecto que va retrasado más se retrasará.

El problema surge no solamente de la dificultad de coordinar el trabajo tantos programadores debido a la gran cantidad de canales de comunicación que se abren con cada nuevo fichaje. La clave está también en que para que un sistema sea realmente utilizable ha de tener integridad conceptual. Lograr esto en un gran sistema como un ERP no es una tarea imposible pero casi….

Aplicando la lógica descubrimos por tanto que las aplicaciones desarrolladas por equipos pequeños y que se ocupan de cuestiones más específicas siempre estarán más cerca de satisfacer las necesidades de los usuarios. Si cogemos a un equipo de desarrollo que está haciendo un módulo de CRM para un ERP y lo ponemos a desarrollar un CRM como aplicación independiente, seguramente el resultado del último será mucho más satisfactorio. Los programadores tendrán menos restricciones debidas a la necesidad de integrar el módulo con el resto del paquete, mayor libertad a la hora de elegir plataformas tecnologías y un largo etc… Y sobre todo una menor carga burocrática y por tanto una mayor productividad.

Nos encontramos ante un encrucijada por un lado las pequeñas aplicaciones centradas en un área específica de la empresa cumplen mejor con su cometido. Por el otro la acumulación de sistema e islas de datos provoca una complejidad difícil de gestionar y de mantener. Y sobre todo una falta de una visión única en cuanto a la realidad de la empresa.

La respuesta de Oracle: Fusion

A parte de estas tendencias la irrupción de los dispositivos móviles, las tecnologías de búsqueda y el comercio social han trastocado profundamente la forma de hacer negocios con multiples y profundas implicaciones. Por tan sólo citar un ejemplo, la experiencia de usuario que nos han brindado las aplicaciones móviles ha marcado un nuevo estándar en usabilidad y adaptabilidad del software. Esto ha hecho que los usuarios de aplicaciones empresariales tengan una percepción negativa sobre las estas, ya que consideran que las interfaces de usuario son funcionalmente pobres y su diseño está poco cuidado.

De forma paralela ha habido importantes avances en la integración de aplicaciones tipo SOA, web Services e incluso JSON. El middleware o los sistemas encargados de la integración de otros sistemas han experimentado un importante avance en los últimos, Oracle cuenta con un liderazgo claro en este tipo de tecnologías.

En resumen las empresas demandan cada vez más funcionalidad más específica, mejor experiencia de usuario y menores costes de despliegue, mantenimiento y formación. Vamos que lo quieren todo. Para dar respuesta a todos estos retos Oracle ha lanzado su nueva familia de aplicaciones: Fusion

 

¿Qué es Oracle Fusion?

Oracle-fusion1

Desde hace varios años Oracle ha anunciado una línea de productos denominada como Fusion. Mucho se ha hablado sobre ella pero hasta el momento el público general no tiene muy claro que es lo que se esconde tras esta denominación.

Básicamente es una nueva forma de concebir el software para empresas que pretende aunar lo mejor de dos mundos: la funcionalidad altamente específica de  las aplicaciones de nicho  y la integración entre áreas de la empresa que ofrecen los sistemas ERP.

Oracle Fusion supone rehacer prácticamente desde cero, toda la familia de aplicaciones empresariales de Oracle. Decimos prácticamente desde cero porque lógicamente para crear Oracle Fusion se ha tomado como base las mejores capacidades de las aplicaciones existentes como la SCM de JD Edwards, la gestión de RR.HH de Peoplesoft, la gestión financiera de OBS, el CRM de Siebel.

Pero Oracle Fusion no es solamente un refrito de otras aplicaciones es mucho más. A la plataforma se le han añadido funcionalidades importantes en cuanto a experiencia de usuario, conectividad, analítica integrada y colaboración social. Ofreciendo no solamente una funcionalidad operativa de primer nivel, sino también ofreciendo a los usuarios nuevas posibilidades de sacarle partido mediante la colaboración y el análisis.

¿Cómo se puede lograr esto?

Oracle ha desarrollado potentes de soluciones de middleware que son las encargadas de lograr la magia requerida para que funcionen dos conceptos tan contrapuestos. Por middleware entendemos cualquier software cuya principal misión es la integración entre terceros paquetes.

Todas las aplicaciones corren sobre una plataforma tecnológica común, que gestiona sesiones seguridad, presentación en pantalla, integraciones, workflow y otras capacidades subyacentes del sistema. Además comparte un modelo de datos unificado. Lo que facilita la integración entre ellas.

Un breve repaso al catálogo de Oracle Fusion

Las aplicaciones de Oracle Fusion además de la plataforma tecnológica han sido agrupadas en grupos funcionales identificados con las principales áreas de la empresa como: Finanzas, SCM, Compras, relaciones con los clientes, proyectos, gobernanza, etc… Aparte de las aplicaciones basadas en soluciones previas de Oracle, se han añadido unas 20 aplicaciones nuevas que vienen a cubrir los huecos que la modularidad puede ocasionar en las soluciones empresariales. La gestión del talento es un buen ejemplo de ellas.

oracle_fusionI

Comparativa Axapta vs JD Edwards (V): Ventas y Compras

jd_vs_axapta

Por fin llegamos a lo bueno. En las áreas funcionales más complejas como son Distribución y Fabricación es donde realmente se demuestra la capacidad de un ERP. Máxime cuando este pretende cubrir las necesidades de grandes empresas, como es el caso de nuestros dos contendientes.

Diferencias en la agrupación funcional del área de distribución

Como hemos comentado en previos artículos, son enormes las diferencias que cada compañía tiene al definir los diferentes módulos que cubren todas las áreas funcionales de cada empresa. En aras de hacer más comprensible esta comparativa, hemos decidido utilizar las estructuras más sencillas posibles. De hecho esta una tendencia totalmente contraria a la  de Microsoft, que en la versión 2012 de AX pasó a aumentar el número de módulos, dividiendo muchos en varias partes (ver documento)

Por ejemplo, en el área de distribución hemos incluido todos los módulos asociados al movimiento de mercancías y servicios , excluyendo las operaciones de fabricación. Por tanto hemos incluido en este grupo módulos como son los de ventas, compras, planificación de demanda, almacén, transporte y etc…

A continuación pasamos a analizar la funcionalidad más en detalle.

Gestión de pedidos de venta

La comparación en un campo tan esencial como este resulta especialmente difícil, dado que Microsoft no cuenta con un módulo específico de gestión de pedidos de venta. ¿Significa esto que no podemos crear pedidos de venta con Microsoft AX? No,  AX dispone de un módulo denominado como Trade Management que agrupo la funcionalidad de pedidos de venta y de compra.

JD Edwards en cambio tiene un módulo específico que se denomina Sales Order Management. Con él se pretende mejorar el proceso de gestión de pedidos con una trazabilidad total durante todo el ciclo de vida del pedido, desde su generación hasta su clasificación.

Ambas soluciones disponen programas que facilitan la entrada de pedidos de forma rápida. Ambas soluciones soportan: cotizaciones, órdenes de crédito,  EDI, envíos directos y de división y acuerdos con partners.  También los dos paquetes permiten la configuración precios no personalizados no solamente para clientes sino  que nos permiten crear condiciones basándonos en grupos de clientes.

JD Edwards ofrece un módulo específico de Gestión Avanzada de Precios con funcionalidad muy avanzada, permitiéndonos establecer precios en base a cestas de productos, incentivos por volumen y fechas de vigencia.

Ambas soluciones ofrecen funcionalidad para dar respuesta a situaciones de escasez, en las que tenemos varios pedidos abiertos que no podemos atender con el stock disponible. Axapta lo resuelve mediante notificaciones y el establecimiento de ciertos parámetros para asignación de unidades. Pero en este caso JD va también un paso más allá ofreciendo un módulo de Gestión de Escasez (Fullfilment Management) que nos permite establecer reglas de prioridad para la asignación de unidades disponibles, evitando así que los clientes más importantes o aquellos con los tenemos acuerdos de servicio cuyo incumplimiento puede provocarnos severas penalizaciones, se queden desatendidos.  El sistema asigna automáticamente las unidades a los pedidos pendientes. Por supuesto esta asignación siempre puede ser revisada antes de ser cerrada.

JD Edwards además ofrece otros módulos incluidos en el de gestión de pedidos que no se encuentra en Axapta y que merece la pena que destaquemos.

El primero de ellos es de Gestión de Acuerdos Comerciales o Agreement Managament , que nos permite integrar la gestión de este tipo de acuerdos dentro de nuestro ERP. Estos acuerdos se basan en cuatro pilares: fechas efectivas, productos específicos, orígenes y destinos de producto, cantidades esperadas y penalizaciones por incumplimiento.

Otro módulo importante de JD Edwards es el de Gestión de Productos Multiatributo o Apparel Managament que nos permite la gestión productos multiatributo, tan frecuentes en sectores como la moda, la electrónica y el mobiliario, por solo citar algunos ejemplos.

Gestión de compras

En este caso concreto, JD Edwards vuelve a ofrecer un módulo específico mientras en AX la funcionalidad de Gestión de Compras se halla dividida entre varios módulos o piezas funcionales: Trade Managament, Fabricación (para subcontratación de operaciones de  manufactura) y el Enterprise Portal. La creación de pedidos se hace mediante el Trade Management y mediante el Enterprise Portal se pueden crear portales de proveedores.

El módulo de compras de JD Edwards está formado por varios componentes.

Los módulos de gestión de Acuerdo y Avanzado de precios, vistos antes, también se utilizan para compras. Además también existe el Requisition Self Services que permite a los propios empleados comunicar las necesidades de suministros y compras.  También incorpora un portal de proveedores para que los proveedores operen directamente con nuestro sistema.

Esperamos que está información haya sido de vuestro interés.

 

Comparativa JD Edwards vs Axapta (III): Módulos disponibles

jd_vs_axapta

Funcionalidad de Axapta vs JD Edwards

Nos encontramos frente a dos auténticos pesos pesados dentro de la industria del software empresarial. Por un lado JD Edwards un ERP originalmente concebido para grandes corporaciones que ha sabido adaptarse a las necesidades de la mediana empresa y por el otro lado Axapta,  que tras una importante inversión en mejoras por parte de Microsoft aspira a buscarse un lugar entre los grandes jugadores de la escena.

Hacer una comparativa de todos los módulos disponibles en ambas aplicaciones supone un pequeño reto. En primer lugar, no es fácil conseguir un listado con todos los módulos y la funcionalidad básica. Para conseguirlo hay que navegar un poco por internet. Las listas de precios son la fuente más fiable para conseguir información, aunque en este aspecto hemos de reconocer que es mucho más clara  la información aportada por Oracle, aunque si quieren pueden juzgar ustedes: AxaptaJD Edwards. Una vez conseguido esto es necesario completar el cuadro añadiendo la funcionalidad específica de cada módulo o submodulos.

Así las cosas vamos a hacer un repaso a la funcionalidad aportada a cada área de la empresa ya que a la postre esta es la manera más certera para lograr una visión global de lo que nos ofrece cada ERP.

Área de Finanzas:

Ambas soluciones incluyen un módulo de gestión financiera, que sobre el papel tienen funcionalidad similar. Esto no quiere decir que ambos funcionen igual de bien, sino que sobre el papel, al menos, son capaces de hacer cosas parecidas: Contabilidad general, Cuentas a pagar y cobrar, etc..  Otra cosa será con que eficacia y eficiencia lo hacen y en qué medida tienen la flexibilidad suficiente para adaptarse a las necesidades de cada empresa.

Ambas aplicaciones están preparadas para trabajar con varias divisas, compañías y localizaciones.  Por supuesto el paquete de finanzas en ambas soluciones se halla estrechamente integrado con el resto de módulos de la aplicación.

Ambas soluciones nos permiten la creación de varias compañías, libros contables así como dimensiones contables además el uso diferentes dimensiones contables que nos permitan evaluar la rentabilidad de los productos, filiales o unidades de negocio.

Ofrecen los tradicionales módulos de Contabilidad General, Cuentas a pagar y Cuentas a Cobrar. Dentro del área de finanzas ambas aplicaciones ofrecen módulos de Gestión de Gastos y gestión de activos fijos. En el último caso la funcionalidad ofrecida por JD Edwards es mucho más completa, contando con una solución para contabilidad de activos fijos.

En cuanto a contabilidad analítica se refiere hemos constatado que la capacidad de JD Edwards es mayor dada su flexibilidad para configurar estructuras contables. No obstante en el siguiente artículo de comparativa sobre la funcionalidad en finanzas de ambas aplicaciones entraremos en más detalle.

principalJD

Gestión de la cadena de suministros:

En esta área funcional es donde más se complica la labor de realizar una comparativa. La arquitectura modular y la forma de agrupar la funcionalidad difieren enormemente. Para comenzar Microsoft incluye el MRP en el módulo de SCM y en JD Edwards viene dentro del módulo de fabricación. La funcionalidad del módulo de Axapta denominado como  Supply Chain Management  está mayoritariamente incluida en el módulo de compras de JD Edwards EntepriseOne. A su vez el módulo de Axapta denominado como Inventory Management and Warehousing recoge la funcionalidad incluida en el módulo de Supply Chain Management de JD Edwards y parte de la funcionalidad del módulo Supply Demand Planning.  Vemos aquí un ejemplo de cómo un nombre idéntico es utilizado para agrupar funcionalidades totalmente distintas, la del área de compras en el caso de Microsoft y la del área de Logística y Gestión de Almacenes en el caso de JD Edwards.

Axapta por su parte desgrana demasiado la funcionalidad, incluyendo como submodulos algunas aplicaciones que se supone que deben de ser un estándar para cualquier módulo de compras. En cualquier caso parece que la funcionalidad ofrecida por Axapta para toda el área de SCM se queda algo corta en algunos casos, a juzgar por las soluciones ofrecidas por algunos partners, para ampliarla.

En cuanto al área de gestión de compras el enfoque planteado dista bastante. JD Edwards propone el enfoque del autoservicio de proveedores y de solicitudes de compra por parte de clientes que no encontramos en Axapta.  JD Edwards además incluye funcionalidad para gestión de contratos con proveedores y la subcontratación de operaciones.

Para el área de Logística y almacenes ambos productos ofrecen funcionalidad para gestión de inventarios y almacenes. JD  Edwards además también ofrece un módulo para  gestión de gráneles imprescindible para muchos sectores como el de las materias primas así como un módulo de gestión de transportes. En la documentación encontrada sobre Axapta no hemos podido localizar funcionalidad análoga.

Los datos de producto y lista de materiales en Axapta vienen incluidos en el módulo de inventario y almacén, mientras que en JD Edwards se incluyen en el de Fabricación, dentro del módulo denominado como Product Data Managament.

En cuanto a la Planificación de la Demanda JD Edwards ofrece un módulo específico para estas operaciones que incluye las aplicaciones de Demantra.

Gestión de ventas y relaciones con clientes:

Ambos paquetes incluyen soluciones para asignación de unidades a clientes ante situaciones de escasez de producto. A su vez ambas soluciones incluyen la posibilidad de fragmentar las entregas dentro de un pedido en varias expediciones, para adaptarse a situaciones de escasez de mercancía o simplemente adaptarse a las preferencias del cliente.

Axapta incluye en este módulo cuestiones como la gestión de las comisiones de comerciales, gestión de clientes y de reclamaciones que JD incluye en su módulo de CRM. JD Edwards por su parte incluye funcionalidad muy importante como la gestión avanzada de precios y la gestión de acuerdos y   contratos.

En cuanto al CRM, Axapta ofrece un módulo de marketing y otro que JD no incluye ya que esta parte se deja a la integración con otras aplicaciones de Oracle mucho más completas. Por su parte JD incluye gestión de casos (Servicio Técnico), Portal de clientes, gestión avanzada de precios y gestión avanzada de filiales.

Gestión de Activos Fijos:

El módulo de gestión de activos Fijos de JD Edwards incluye operaciones de mantenimiento que en Axapta vienen incluidas en el módulo de Service Management. JD Edwards además ofrece  como extra el módulo de Contabilidad de Activos Fijos.

Gestión de la Fabricación:

En cuanto a la  fabricación ambos  productos ofrecen funcionalidad para la gestión de la producción, rutas de fabricación, gestión de planta y planificación. JD Edwards además ofrece un módulo de Gestión de Calidad y de fabricación por proyectos.

Módulos adicionales:

JD Edwards en una de sus últimas release incorporó el módulo Gestión de Salud y Seguridad Laboral en la empresa, con su correspondiente extensión con el Oneview Reporting. Axapta no incluye funcionalidad similar.

Módulos verticales:

Por otro lado JD Edwards también incluye otros módulos como el de Construcción y Gestión Inmobiliaria, Agrícola y Bodegas, Apparel funcionalidad que tampoco encontramos en Axapta. La funcionalidad de estos “módulos verticales” será analizada más en profundidad en próximos artículos .

Comparativa Axapta vs JD Edwards (II): Plataformas tecnológicas

jd_vs_axapta

A  nivel de plataforma tecnológica vemos las importantes diferencias entre ambas soluciones. A pesar de tratarse de dos paquetes de software que compiten en segmentos de mercados parecidos lo hacen con planteamientos totalmente diferentes.

Microsoft apuesta por un modelo basado en cliente pesado con instalaciones en cada equipo de usuario y una plataforma tecnológica cerrada que descansa íntegramente sobre productos de Microsoft: : Windows Server y base de datos SQL Server.

Oracle por el contrario, a pesar ser el principal fabricante de bases de datos del mundo y contar con la tecnología de RedHat para servidores Linux, opta por un modelo multiplataforma con soporte para varias base de de datos y sistemas operativos. De hecho un JD Edwards puede funcionar perfectamente sobre base de datos SQL Server y Servidores Windows.

Cliente pesado vs navegador web

A pesar de de las insinuaciones por parte de Microsoft de que sus ERP pronto podrán ser accesibles vía web, a día de hoy, Axapta es una plataforma basada en cliente pesado. Es decir, tiene que ser instalada en cada uno de los equipos en los que  se vaya acceder a la aplicación. Esto presenta varios inconvenientes.

Limita bastante la movilidad del personal así como la accesibilidad al sistema. Condiciona el hardware y el software a instalar en los equipos de los usuarios de la empresa, que estarán obligados a instalar Windows con el consiguiente pago de licencias. Dado que lo más habitual es que en las empresas se tenga una cierta uniformidad en cuanto IT se refiere, esto condicionará a utilizar una plataforma Microsoft no solamente a los usuarios de la aplicación sino seguramente al resto de la empresa.

Si algún día la empresa quiere reducir sus costes  de IT optando por opciones como Ubuntu, tendrá que abandonar Axapta. Los equipos con OSX o iOS de Apple tampoco pueden ejecutar Dynamics AX.

JD Edwards fue el primer ERP de Tier 1 que apostó por una solución 100% web. Consideramos que con el tiempo, esta apuesta ha demostrado ser un verdadero éxito. La principal pega que se ponía a las aplicaciones web  era una funcionalidad y experiencia de usuario más pobre. Debido a las mejoras experimentadas en los estándares web, materializadas en el  HTML5, CSS3 y mejoras en Javascript, se puede decir que esta desventaja inicial, ha sido totalmente superada. Hoy en día este tipo de aplicaciones ofrecen una experiencia de usuario totalmente homologable a las aplicaciones de escritorio.

Por otro lado este modelo de aplicación presenta importantes ventajas. No olvidemos que las aplicaciones más complejas del mundo como son Facebook o los servicios de Google, funcionan sobre arquitectura web. Para comenzar puede accederse a la aplicación  desde una máquina con cualquier sistema operativo instalado: Linux, Windows, OSX, Android, etc.. Solamente se necesita un navegador web, sin necesidad de instalación previa. Las actualizaciones son automáticas ya que al estar toda aplicación almacenada en el servidor simplemente basta con actualizar este. Esto por otra parte facilita las labores de mantenimiento.

Arquitectura básica

Axapta opta por modelo basado en Servidor de aplicaciones y Servidor de base de datos. Todo ello alojado en servidores con sistema Operativo Windows Server. La base de datos requerido es Microsoft SQL Server y servidor de Aplicaciones es Application Object Server (AOS) de Microsoft. Otros paquetes de software adicionales requeridos son los siguientes: Enterprise Portal, Enterprise Search, Help Server, Reporting Services Extensions  y Analysis Services integration. Además es necesario la instalación de un cliente en cada uno de los equipos que se va conectar  a la aplicación. Si el mismo está fuera de la red exige un programa adicional de comunicaciones (Terminal Server, Citrix).

JD Edwards opta por una solución más compleja a la que añade un servidor web que es el encargado de generar el código HTML que se visualiza en los navegadores. Por otro lado para lograr una arquitectura que soporta varias bases de datos y sistemas operativos se apoya en una capa intermedia de software denominada como middleware que se encarga de la interconexión entre los distintos sistemas.

A la hora de configurar existe un dilema por el que tendremos que decantarnos, simplicidad vs flexibilidad. A mayor flexibilidad mayor complejidad y a mayor simplicidad menos flexibilidad. Está claro que ante este dilema Microsoft y Oracle han optado por caminos muy distintos.

¿Para que sirve realmente un ERP?

Un sistema de anotación y registro

esquema_erp

Un ERP nos permite llevar un registro detallado y estructurado de todos los movimientos y transacciones de nuestra empresa. Es lo que técnicamente se denomina un sistema transaccional.

Una de las principales características de este tipo de sistemas es que son reversibles, permitiendo “modificar hacia atrás” cualquier operación o conjunto de operaciones que queramos. Esto nos permite minimizar el impacto de fallos u errores.

Un buen ERP ha de ser capaz darnos una fotografía exacta de la situación de nuestra empresa en cada momento. A demás debería de darnos respuestas a preguntas concretas sobre situaciones pasadas, como por ejemplo: ¿Cuál era el stock del artículo X a 23-03-2012? ¿Cuánto nos debían nuestros clientes de Albacete el 23-02-2013?

Nótese que ninguna de estas características de un ERP es ajena a los sistemas de gestión manuales. La principal diferencia es la velocidad y fiabilidad que nos otorga el ERP.

Un autómata administrativo

automata_administrativo

La administración es el arte de coordinar el esfuerzo para lograr objetivos. Una de las ventajas principales de los sistemas ERP es su capacidad para facilitar todas las tareas de administración o administrativas.

Cualquier trabajo o proyecto realizada por varios personas requerirá de dos tipos de tareas, las propias del proyecto y las necesarias  para coordinar las tareas de los  miembros del equipo. En los trabajos realizados de forma unipersonal este tipo tareas no son necesarias. Desde los orígenes de la civilización, esta gestión ha sido realizado mediante flujos de documentos.

El  ERP contiene un sistema de documentos estructurados y relacionados, es lo que se denomina la base de datos. En base a plantillas y reglas predefinidas un ERP es capaz de generar nuevos documentos cada vez que sucede un evento predefinido en el sistema, además de modificar documentos existentes. Todo esto llevando una completa trazabilidad de los cambios realizados y de los usuarios implicados. Esta característica permite ahorrar gran cantidad de trabajo frente a otros sistemas de gestión. Para ello hay que invertir un esfuerzo considerable en el diseño y la implementación del sistema, tareas que requieren  menos esfuerzos en sistemas más informales. Generalmente el esfuerzo siempre merece la pena.

Conforme aumentan la complejidad de los proyectos aumenta la complejidad de su gestión. Un ERP ha de ser capaz de facilitar ese trabajo, reduciendo los costes asociados a la gestión de grandes estructuras.

Una herramienta de coordinación y colaboración

El ERP como herramienta de colaboración

Un ERP facilita la colaboración entre departamentos y equipos. Al servir de soporte a procesos estandarizados y prefijados, permite que los distintos departamentos o grupos implicados puedan centrarse en sus tareas propias, minimizando la necesidad de negociaciones y gestiones con el resto de departamentos. El ERP por tanto, es una herramienta que facilita la especialización, cada recibe unas entradas que han de generar unas salidas y desarrolla este procedimiento con un alto nivel de opacidad con respecto al resto de compartimentos.

Además tienen la de gestionar los flujos de procesos, automatizando multitud de tareas  y organizando los procesos de la empresa. Esto facilita la coordinación y previene la aparición de errores debido al tratamiento manual.

Este además de facilitar la coordinación facilita la colaboración, ya que al disponer toda la empresa de un único repositorio de información es mucho más fácil coordinar el trabajo y poner de acuerdo a la gente. Se evitan un porcentaje importante de horas de discusión y estudio sobre qué es lo que están pasando ya que todos los miembros de la organización disponen de información homogénea.

Los campos calculados en Openbravo: el reporting instántaneo

Openbravo tiene un alto nivel usabilidad, lo que la convierten en una de las soluciones ERP más productivas para los usuarios. Hoy vamos a destacar los campos calculados. Una funcionalidad estándar aplicable a todas las vistas de datos en modo grid, que nos permite añadir columnas calculadas y sumatorios. Combinando estas dos funcionalidades podemos cubrir una gran parte de las necesidades más inmediatas de reporting, que pueden ser generados por parte los usuarios, sin necesidad de acudir al personal del Departamento IT

Una de los costes operativos más importante de un sistema ERP es  la generación de informes. Continuamente los usuarios de los diferentes departamentos solicitan la generación de reports operativos. Estos informes son imprescindibles para el funcionamiento diario y la toma de decisiones.  Además suelen tener un caracter efímero, por lo que rara vez son reutilizados.

El inteligente enfoque que plantea Openbravo es de lejos la mejor solución al problema que hemos visto hasta a la fecha, ya que nos da respuestas rápidas a preguntas sencillas que se nos plantean en el día a dia, evitándonos exportaciones a excel y la utilización de horas de desarrollo.

Creación de vistas personalizas con campos calculados y sumatarios en Openbravo

Y como para verlo, nada mejor que un ejemplo, os vamos a proponer uno sencillo y rápido. Partiendo de un listado histórico de todas las facturas emitidas a clientes

imagen_1

Podemos fácilmente realizar agrupaciones, ordenaciones, sumatorios y campos calculados sobre el mismo formulario y guardarlo como una vista personalizada. El objetivo es conocer de manera rápida que importe tenemos pendiente de pago y cuanto corresponde a cada cliente y factura.

Comenzamos agrupando las facturas por cliente, esto nos permitirá aislar y acceder de manera rápida a los datos de cada cliente:

imagen_2

imagen_3

A continuación creamos campos calculados de tipo fórmula operando sobre campos importe existentes así como sumatorios de los campos importe para totalizar los datos:

imagen_4

imagen_5

Resultando el siguiente listado que puede guardarse como una vista para utilizarse en otras ocasiones:

imagen_6

Este es tan sólo un pequeño ejemplo, el potencial que ofrece esta herramienta es sin duda prometedor. Esperamos que este pequeño artículo os haya sido de ayuda.

zp8497586rq