Archivo de la etiqueta: sistemas informáticos

La gestión del cambio en proyectos ERP

La gestión del cambio en un proyecto ERP son todas las acciones encaminadas a minimizar el impacto negativo de la adopción de un nuevo sistema en la empresa. También el objetivo es acelerar la obtención de los potenciales beneficios por parte de la empresa acortando el periodo de retorno de inversión.

El principal problema es que un cambio de ERP no es simplemente un cambio de sistema informático. El ERP es el soporte vital de las operaciones de la empresa moderna e integrado junto con otras aplicaciones han de ser reflejo del modelo de negocio de la empresa. Ha de reflejar y servir de soporte a todos los procesos de la empresa. Es a su vez un repositorio de datos interconectados sobre entidades y transacciones. En definitiva un ERP constituye el sistema nervioso de una empresa a través del cual fluye la información que necesita para realizar sus funciones.

Por si fuera poco cada vez que se una empresa se plantea un proceso ERP, lo lógico es aprovechar para hacer una rediseño de los flujos de trabajo en la empresa, eliminando los procesos innecesarios y optimizando todos aquellos que ofrezcan un margen razonable para la mejora. Muchas veces estos cambios vienen acompañados de restructuraciones a nivel de personal e incluso ajustes en plantilla. Esto  implica que el trabajo de muchas personas  se verá afectado.

En definitiva cuando en una empresa se rumorea que va a haber un cambio de ERP, el personal se asusta, ya que entiende que van importantes cambios que pueden amenazar su estatus quo.

La natural resistencia al cambio

Los seres humanos somos por naturaleza reluctantes al cambio, especialmente si este no va a conducirnos de manera cierta a una mejora.  Por lo general conforme avanzamos en edad nos volvamos más reservados, o cautos, a la hora de conceder credibilidad a las promesas de mejora.

Todo cambio lleva asociado un componente de incertidumbre, sólo un necio puede estar seguro de conocer el futuro.

Por tanto la primera acción de una Gestión del cambio ha de ir encaminada a reducir esa incertidumbre dando información general sobre proyecto, así como información específica que sirva a cada persona para evaluar cual será el impacto sobre su situación como individuo. La mejor manera de evitar un motín es ofrecer a cada persona herramientas para que pueda pensar en sí mismo. Conforme más desdibujado vemos nuestro futuro más fácilmente nos unimos a movimientos de agitación. Es imprescindible  hacer partícipe al equipo de esta transformación y que vean las ventajas que el proyecto puede aportarles.

La planificación la mejor herramienta para gestionar el cambio.

El enfoque metodológico más adecuado es aprovechar el conocimiento disponible sobre cambios y conflictividad para trazar una serie de acciones que adaptadas a la casuística particular de cada proyecto permitan controlar la aparición de resistencias y conflictos. El objetivo es incorporar  al proyecto al mayor número de profesionales posibles y ayudarles a que este sirva para favorecer su desarrollo profesional.

cambio

En el siguiente gráfico vemos de manera simplificada cuales son las distintas fases que podemos prever durante un proyecto de implantación de ERP. La gestión del cambio intentará modificar esa curva de resistencia para que el proyecto fluya de la manera más adecuada.

No podemos olvidar que el mejor software con la mejor adaptación posible a las necesidades de una empresa se convertirá en un absoluto fracaso si no logramos involucrar al equipo de profesionales de la empresa en su uso, adopción y expansión.

La clasificación de los ERP (I)

Tradicionalmente se ha venido utilizando una clasificación basada en Tiers (o  niveles) para diferenciar de las distintas soluciones ERP. Debido a la falta de un organismo regulador o un consorcio tipo www3 encargado de la estandarización de las soluciones ERP, estas clasificaciones no dejan de tener un componente arbitrario que varía dependiendo de la institución o analista que realice esa clasificación. No obstante existe un cierto consenso sobre la metodología utilizada.

En primer lugar se aceptan tres niveles Tier que vienen a corresponderse grosso modo con las siguientes categorías:

–          Tier 1:  Soluciones orientadas a grandes negocios globales

–          Tier 2: Soluciones orientadas al midmarket.

–          Tier 3: Soluciones orientadas a negocios de tamaño pequeño y medio.

Algunos analistas han propuesto la existencia de un Tier4, orientado a empresas más pequeñas todavía. No obstante cuesta creer que las soluciones orientadas a este tipo de empresas puedan considerarse como auténticos ERP.

El principal problema de basar nuestra clasificación en criterios de tamaño de la empresa destinataria de la solución es que este criterio varía entre regiones económicas e incluso entre países de una misma área económica, como pueden ser Portugal y Alemania.

Otra forma de definir un poco más esta clasificación es basarnos también en la funcionalidad ofrecida. Para los productos de Tier1 la cuestión está bastante clara. Las soluciones de Tier1 tienen un altísimo nivel de escalabilidad, llegando a lograr que decenas de miles de usuarios estén conectados a la solución.

Los productos Tier1 al haber sido diseñados para servir las necesidades de las multinacionales y tiene que ser capaces de gestionar muchas compañías integradas en un único sistema, sujetas a distintas regulaciones y normas fiscales y con usuarios trabajando en distintos idiomas.  Sin duda estas cuestiones suponen la principal barrera entre el Tier1 y el resto.

No obstante, las soluciones de Tier1 ofrecen también una funcionalidad mucho más amplia, con un mayor número de módulos. Necesitan de menos desarrollos para poder adaptarse a las necesidades de cada empresa y las adaptaciones son llevadas a cabo basándose en parametrizaciones.  Esto tiene muchas ventajas, la principal es una menor complejidad a la hora de migrar a nuevas versiones.

Lógicamente los requerimientos en infraestructura y hardware para soportar este tipo de soluciones son mayores también y están casi siempre fuera del alcance de las compañías de tamaño medio. La arquitectura del software propiamente dicha es también mucho más compleja.  Todo este tiene un reflejo en el coste final de la  solución a todos los niveles: licencias, hardware, servicios, soporte, etc…

Si los fabricantes detrás de las soluciones de Tier1 son capaces atender una demanda a nivel global, los de Tier2, aunque cada vez más presentes en más países, suelen tener un alcance geográfico mucho más limitado. Los fabricantes de Tier3 suelen limitar la presencia a su país de origen.

La complejidad de los mercados

Para complicar todavía más las cosas algunos fabricantes de soluciones Tier1 con el tiempo han intentado ofrecer versiones más simples de su producto que pudieran llegar a empresas más pequeñas. Otros fabricantes que como Oracle, mediante adquisiciones de terceras compañías, se han encontrado con dos soluciones de Tier1 en su cartera, han optado por reposicionar una de ellas en el segmento que podríamos denominar Tier 1.5

No obstante el sistema de clasificación basado en Tier1 es simplemente una aproximación a la hora de abordar la problemática del mercado. La realidad como siempre nos brinda casos complejos que los recogidos en el canón.

Data scientist vs Data Artist

datartist

La génesis del data scientist

La figura del Data Scientist es una de las más demandas dentro de los puestos de perfil de tecnológico. En los ultimos tiempos han adquirido mucha imporatncia y las ofertas de empleo se han multiplicado para profesionales de ramo. Pero, ¿Qué es un data scientist? Hace 3 años casi nadie había oído hablar de esta singular profesión, a día hoy están en boca de mucha gente. Su principal función es la extracción de valor de las montañas de  datos que gestionan las empresas hoy en día.  En definitiva han de ser capaces de definir la forma del bosque a partir de los millones de ramas que divisan.

Hay gente que no está nada emocionada con esta figura y que piensa que los Data Scientist son una ligera evolución de la figura de DBA y analista de negocio. Salvo que con aura mucho más científica. Polémicas aparte, siempre es positivo que haya una figura en la empresa que intente convertir los datos en información para poder alcanzar el conocimiento. A diferencia de un típico analista de datos, el data scientist ha de ser capaz de lidiar con muchas fuentes de datos y ser capaz de detectar problemas y oportunidades. Han de ser capaces de dar un significado a todas esas “toneladas de datos”, buscando patrones, reglas y narraciones que expliquen las variaciones en los datos.

En tiene que conocer varias disciplinas que no se enseñan juntas en ninguna carrera: habilidades para el hackeo, conocimiento de matemáticas y estadísticas además de unas grandes dosis de cultura general y concreta sobre la cuestión que se está investigando.

Si algo debería distinguirles de los DBA es no tienen que ocuparse de cuestiones técnicas sobre infraestructura, lo que tienen que saber es extraer valor de los datos. No es la primera vez que la evolución tecnológica divide lo que era una profesión en dos. Si seguimos por la senda de la especialización lo lógico es que de profesión surja otra nueva. Fenómeno que ya estamos viviendo.

La génesis del data artist

Una vez extraídas conclusiones sobre el análisis de los datos es necesario presentarles con un formato que facilite su asimilación y comprensión. Esa sería la misión de los data artist. En realidad ya podemos encontrar toneladas de ellos. Son los que están realizando  las otrora populares infografías.

Son los encargados de pintar los datos de una manera artística. Exponiendo en forma gráfica y fácil de asimilar no solamente los conclusiones extraídas de los datos. Nos dice más ver iconos con distintos tamaños para saber cuál es la renta per cápita de un país que  leer los datos en formato texto. No solamente eso jugando con textos, imágenes, tamaños, orden y relaciones visuales pueden representar fenómenos complejos de una manera muy condensada lo que nos ayuda a tener una comprensión clara y rápida, de que es lo que se nos quiere transmitir.

Comparativa Axapta vs JD Edwards (IV): Gestión Financiera

jd_vs_axapta

Comparar soluciones ERP es algo ya complejo de por sí, intentar comparar la funcionalidad en cuanto a gestión financiera es todavía más complicado.

A diferencia de un almacén que puede ser gestionado con una cierta discrecionalidad por parte de cada de empresa (aunque luego casi todas se adapten a unos pocos modelos de gestión), las cuentas de una empresa están fuertemente sujetas a las regulaciones y normativas fiscales.  Por tanto, sólo existe una manera de hacer las cosas, lo que tiende a homogeneizar en cierta medida las soluciones aportadas por los distintos fabricantes.

Ambos paquetes cuentan sobradamente con la funcionalidad más estándar: cuentas a pagar, cuentas a cobrar, activos fijos, gestión de gastos, reports, analítica y demás . Ambas soluciones son multicompañia, multimoneda y disponen de multiples localizaciones para países de todo el mundo.  No obstante cuando entramos a valorar en detalle la solución de Oracle resulta ser bastante más completa.

Obtener información detallada de la funcionalidad es dificil por la forma de exponera que tienen los fabricantes. Cuando uno revisa la documentación no es extraño leer frase del tipo: “Obtener una visión general del beneficio financiero, realizar previsiones estratégicas y tomar decisiones más fiables”. Muchas veces uno llega a plantearse si la documentación ofrecida tiene el  objetivo de informar o de confundir. Cuando uno pasa varias horas leyendo la documetación comercial y técnica disponible un termina ahogado entre tanta frase vacua y tanta jerga técnica que amenaza continuamente con romper las más elementales normas de la construcción gramatical. Pasamos detallar las características principales de los distintos submódulos:

Contabilidad General: Ambas soluciones ofrecen flexibilidad a la hora de establecer periodos contables así como la configuración distintos libros diarios. No obstante JD Edwards parece ir un paso más allá en la flexibilidad ofrecida para configurar estructuras contables.

Ambas soluciones establecen procedimientos para el control y aprobación de los asientos contables.

Axapta ofrece la asignación automática basada en porcentajes para cuentas y dimensiones. Este es un método permite automatizar la entrada de asientos contables. JD Edwards ofrece las Instrucciones de Contabilidad Avanzadas  que son una opción más avanzada pero a la vez más compleja.

Ambas soluciones parecen bien preparadas para la gestión de múltiples compañías, países y divisas. No obstante para emitir un juicio certero sería necesario realizar un análisis más en profundidad, pero por las opiniones que he conseguido reunir ambas suites van bastante parejas en este aspecto.

Cuentas a pagar:   En este aportado la funcionalidad de JD Edward es sin duda superior. La documentación aportada por los fabricantes es bastante pobre, algunas funcionalidades que se dan por supuestas apenas son mencionadas. Hay que destacar que el listado de funcionalidad aportado por Oracle es mucho más detallado.

Ambas soluciones soportan varios métodos de entrada de factura. Son capaces de gestionar de manera automática el pago de intereses.

Cabe destacar la capacidad de JD Edwards para soportar la  gestión procesos de negocio y como permite customizar el proceso de cobros. Oracle destaca 35 características esenciales frente 10 aportadas por Microsoft. Algunas son tan complejas y avanzadas como la inclusión de algoritmos predefinidos por el usuario o el establecimiento de relaciones padre hijo. En este apartado sin duda JD Edwards aporta más funcionalidad.

Cuentas a cobrar:  Ambos paquetes soportan la  gestión de pagos en múltiples divisas así como diversos métodos y condiciones de pago. De JD Edwards sabemos que permite el pago fraccionado así como el pago por parte de terceros, AX también ofrece opciones de pago flexible. Ambas suites realizan también el registro de facturas.

En este apartado JD Edwards también aporta funcionalidad adicional como la detección de facturas duplicadas, la doble comparación de cotización así como múltiples cuentas de banco en las que recibir pagos.

Gestión de activos:  Las dos soluciones realizan una gestión completa de todo el ciclo de vida del activo con diversos métodos de amortización.

No obstante las posibilidades que ofrece JD Edwards son mucho más completas. La gestión de activos es un apartado del módulo de Finanzas en Axapta. JD Edwards en cambio dispone de un módulo completo dedicado enteramente a la gestión de activos fijos, que incluye la gestión del mantenimiento así como el análisis de costes de los equipos.

Analítica y reporting

Una parte importante de la gestión financiera en la empresa es la elaboración y extracción de reports e informes. Este aspecto puede ser clave Para más inri tanto Microsoft como Oracle han hecho un importante esfuerzo en la mejora de las herramientas ofrecidas para reporting.

Microsoft ha incorporado los centros de funciones para Director Financiero, Director de Cuentas, Controller, Coordinador de Pagos, Administrador de cobros, contable.  Los centros de funciones vienen a ser una especie Cuadros de Mando orientados a roles de usuario/empresa en los que se muestran gráficas sobre indicadores clave así como enlaces a informes. Viene a ser una especie de pantalla de inicio orientada  roles de usuario.

JD Edwards ha hecho una apuesta muy concreta en los últimos años por integrar de manera sencilla el reporting operativo en todos sus módulos con la solución OneView Reporting. Esto unido a las capacidades de embeber aplicaciones en JD Edwards y de configurar las pantallas de usuario con total libertad, permite llevar un paso más allá las opciones de personalización por parte del usuario. Este aspecto le otorga una enorme libertad para configurar la herramienta de la manera que le sea más productiva. Este capacidad se muestra más en profundidad en los siguientes videos:

 

Esperamos que este breve análisis os haya sido de ayuda. Recibid un cordial saludo.

 

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.

Comparativa JD Edwards vs Axapta (I): Introducción a ambas herramientas

jd_vs_axapta

Como hemos comentado en anteriores artículos comparar productos tan complejos como soluciones de software ERP, no es una tarea de sencilla. En primer lugar es casi imposible encontrar una persona que conozca ambos paquetes con la suficiente profundidad como para hacer una comparativa realista.  Generalmente una persona se especializa en uno o varios módulos de una solución. Ya es raro encontrar un especialista que conozca en profundidad todos los módulos de un ERP, así que estoy prácticamente convencido de que nadie conoce con ese nivel de profundidad dos soluciones tan potentes como son Axapta y JD Edwards.

Aunque se diera ese caso, los dos productos son soluciones complejas y flexibles que pueden no encajar igual de bien en empresas distintas. Para colmo muchas veces el encaje o no de un ERP depende en gran medida del trabajo hecho por el implantador. Esto se traduce en que en la práctica todo análisis que pretenda ofrecer un resultado del estilo A es mejor que B en un 20%, sea algo inviable y posiblemente un fraude comercial.

A pesar de todo siempre es interesante hacer una comparativa de ambas aplicaciones para conocer sus principales características, así como sus defectos, virtudes, diferencias y similitudes. Consideramos que esta tarea es un paso muy recomendable antes de analizar más en profundidad cualquiera de las dos soluciones.

Un poco de historia

En ambas casos nos encontramos con aplicaciones históricas, que provienen de familias de productos que llevan decadas en el mercado. En la industria del software, esto es todo un hito.

La que tiene un linaje más antiguo es sin duda JD Edwards. Los orígenes de esta familia de productos se remontan a 1977 cuando fue creada la compañía que alcanzo el éxito con un programa de contabilidad para los miniordenadores de IBM. Poco a poco fueron añadiendo funcionalidad a su solución hasta convertirla en un E.R.P al que se le puso el nombre de OneWorld en 1996.  Este fue el embrión del producto que hoy en día se conoce como JD Edwards EnterpriseOne. En 2002 JD Edwards fue adquirido por Peoplesoft que a su vez fue adquirido por Oracle mediante una OPA hostil en 2003. Desde entonces las nuevas actualizaciones y mejoras han sido continuas y Oracle ha establecido un Roadmap detallado para este producto que considera estratégico dentro de su línea de aplicaciones.

Axapta o Microsoft Dinamics AX fue desarrollado originalmente por  IBM y posteriormente comprado por Damgaard Data una empresa Danesa. Con el paso de los años Dammgard y su rival Danesa Navision se unieron y posteriormente  fueron compradas por Microsoft, convirtiéndose ambos productos en el pilar de central de la cartera de productos de Microsoft  en Software de Gestión Empresarial. Axapta está enfocado al segmento medio-alto del mercado mientras que Navision   fue enfocado a empresas de menor tamaño.

Dos conceptos totalmente diferentes

A pesar de ser dos productos enfocados a un mismo segmento de mercado y que  por tanto han de compartir una funcionalidad parecida, no tienen nada absolutamente que ver entre sí. Vemos conceptos totalmente distintos a nivel de plataformas tecnológicas,  interfaz de usuario, modelo de desarrollo, integración con otras aplicaciones y demás.  Son productos absolutamente diferentes.

Por tanto esto complica aún más una comparativa entre ambas soluciones, cuestión que como ya planteábamos antes no es nada sencilla.

zp8497586rq

ERP, tres letras y dos mentiras

El ERP, gestión de los recursos empresariales

// ]]>

Si algo tenía de interés el estudio de las lenguas muertas como el latín o el griego en los programas educativos, era la oportunidad que nos brindaba para conocer el origen de las palabras. Conociendo su origen, comprendemos mejor su significado y somos más capaces de entender sobre que estamos hablando.

En idiomas como el español casi todas las palabras más o menos complejas vienen de la combinación de términos grecolatinos como: agricultura, ingeniería, neocapitalismo, astronomía, oligarquía metrópolis y un largo etc…. En España no tenemos esa costumbre tan teutónica de juntar palabras de nuestro idioma para forma palabras nuevas, preferimos decir problemas de aprendizaje a aprendeproblemas, por ejemplo.  Este tipo de construcciones nos suenan raras, incluso traen reminiscencias de la neolengua expuesta por Orwell.

En España preferimos inventar nuevas palabras, utilizar símiles, importar términos de otros idiomas o tirar del uso de acrónimos. Una costumbre muy extendida en el mundo anglosajón y que goza de notable aceptación en España, especialmente en el ámbito tecnológico. De ahí vienen los laser (Light Amplification by Stimulated Emission of Radiation), la tecnología CUDA, la informática, el estraperlo y como no el ERP.  Algunos de ellos acaban por adquirir un significado propio al margen de su raíz tal es el caso del ERP.

La planificación de los recursos empresariales

Y es que lo que hoy denominamos como ERP, o sistema informático capaz de soportar de manera integrada casi todos los procesos empresariales. ERP es el acrónimo de Enterprise Resource Planning, un nombre compuesto que dista mucho de decirnos lo que realmente hace la herramienta en cuestión.

En Aragón hay un dicho que reza que “Villanueva de Gállego” es la localidad de las tres mentiras ya que ni es villa, ni es nueva, ni pasa el río Gállego por ella. Con el ERP pasa algo parecido, con el tiempo y la evolución de este tipo de herramientas ninguna de las tres siglas da en el clavo.

La primera “Enterprise” que traducido tal cual viene a significar “empresa”, aunque contextualizado encajaría mejor con corporación o gran empresa. Bien es sabido que los ERP no sólo son implantados por grandes empresas y que hace tiempo que las medianas y pequeñas empresas vienen contando con este tipo de sistemas.

El ERP en la organización de la empresa

Del MRP al ERP

Los ERP nacen de la integración de los distintos tipos de programas informáticos que eran usados en la empresa y que a finales de los 80 convergieron en lo que actualmente conocemos. En el origen de  todo se encuentran los MRP (Material Resource Planning) nacidas en los años 70, unas aplicaciones incluidas hoy en día en la mayoría de ERP´s y cuya principal función era el cálculo de los recursos necesarios para sacar adelante una producción  determinada. Los MRP II incorporaron funcionalidad específica de Control de Planta, Almacen y demás.

Las otras dos letras

El concepto recurso en crudo viene a significar una fuente de suministro de la cual se puede producir un beneficio. Los recursos son muy importantes en la actividad empresarial pero la empresa tiene que gestionar mucho más que recursos y los ERP también. Vemos por tanto que el ERP no solo va de recursos o “resources”, sino que también gestiona deudas, expectativas, direcciones, devoluciones, reparaciones, mantenimientos, accidentes laborales y un largo etc.. Cuestiones a los que tal vez algún sesudo economista sea capaz de meter en la categoría de recursos. Nosotros, no nos vemos capaces.

En cuanto a la planificación es simplemente una parte de la funcionalidad total que incluye un ERP, eso en caso de que la incluya, ya que las suites más modestas, generalmente no incluyen este tipo de capacidades o si lo hacen es de forma más que modesta.

Y hasta aquí esta pequeña reflexión que espero nos sirva de ayuda para saber de que estamos hablando con hablamos de ERP.

El ERP y el cálculo de beneficios: en búsqueda de la rentabilidad (II)

Tal y como explicábamos en nuestro anterior artículo, para poder abordar en profundidad el tema del cálculo de beneficios tendremos primero que tomar una serie de decisiones:

¿A qué nivel de detalle queremos llegar? ¿Nos interesa simplemente conocer el beneficio que obtenemos con cada producto o queremos saber cuánto ganamos con cada producto y con cada cliente, cada semana?

El conocimiento es poder, por lo que nosotros recomendamos llegar cuanto más lejos mejor. Muchas veces asumimos que hay que vender los productos al mismo precio a todos los clientes, cuando la rentabilidad que obtenemos con ellos es menor o incluso negativa.  Si queremos llegar a ser realmente competitivos tendremos que saber perfectamente por donde entra y sale cada céntimo.

¿Cómo asignamos nuestra estructura de costes indirectos? Este es un ejercicio que requiere de un profundo conocimiento  y comprensión del modelo de negocio de la empresa, además de dedicar un buen número de horas la incómoda tarea de pensar.

Pero si no estamos dispuestos a realizar a fondo este paso más nos vale que no avancemos más en el proceso. Si no lo hacemos, corremos el riesgo de acabar alimentando un sistema que nos es útil, ya que al basarse en unos supuestos pocos realistas acaba suministrándonos datos inconsistentes que nos llevan a tomar decisiones erróneas.

– ¿Cómo recogemos e integramos toda esa información? Si nuestra empresa  cuenta con un ERP completamente integrado que recoja nuestros procesos, casi toda la información debería de estar contenida en la base de datos, pero este caso no suele ser el más común.

Muchas empresas cuentan con otros sistemas como  CRM, PM, PLM, CMS que muchas veces pueden contener información sustancial, que es necesario incorporar. Otras veces la información puede provenir de fuentes de terceros o incluso no estar recogida en ningún tipo de soporte informático. Es necesario que desarrollemos un sistema de recogida e integración de toda esa información capaz de reflejar la estructura de costes que hemos inferido.

¿Qué criterios de clasificación utilizamos para separar el grano de la paja? No podemos estar analizando cada una de las cifras obtenidas con todo detalle. Tenemos que establecer unos umbrales de rentabilidad tanto negativa como positiva a partir de los cuales debamos de prestar atención. Es conveniente establecer también estos umbrales a distintos niveles de agregación (cliente/producto, territorio/producto, etc..)

 

De la contabilidad B hasta la contabilidad XYZ

Algunos de los sistemas ERP más avanzados nos ofrecen la posibilidad de configurar una infinidad de libros contables esto especialmente útil en el caso de querer realizar una contabilidad avanzada de costes que nos permita focalizarnos en nuestras operaciones más rentables.

No todas las suites del mercado disponen de la funcionalidad suficiente como para realizar este procedimiento con todo tipo detalles. Las de más prestigio del mercado en cambio sí que son capaces.

En el caso de JD Edwards EntepriseOne por citar un ejemplo, nos ofrece hasta 30 códigos de categoría adicionales para clasificación adicional de las distintas unidades de negocio dentro de la empresa ya sea por criterios geográficos, organizacionales o de productos.

Disponemos además de 23 códigos de categoría adicionales para clasificar la naturaleza de la operación registrada con los que podemos almacenar información relativa a cuentas y subcuentas contables. Toda este información también puede ser asociada a una persona o entidad concreta, como por ejemplo un empleado, un proveedor o un cliente. Todo esto es más que suficiente para poder dar soporte al sistema más exigente y significativo que podamos concebir.

Tratamiento y selección masiva de datos

Con nuestro ERP podemos ser capaces de extraer toda la información procesada que nos arroje los resultados definitivos. Pero dado al uso intensivo del sistema corremos el riesgo de sobrecargar el sistema, especialmente la base de datos.

Para este tipo de tareas es mucho más conveniente disponer de una sistema de inteligencia de negocios que se encargue de realizar todas las labores de extracción y proceso durante periodos de inactividad, como por la noche. Con ello garantizaremos la operatividad de nuestro sistema.

Además este tipo de herramientas nos ofrecen formatos de presentación impecables que facilitan enormemente el estudio detallado de la información. Otros son capaces mediante sistemas de alertas de estudiar los resultados y solo informarnos de aquellos casos excepcionales que se encuentren fuere de los márgenes de seguridad que hayamos preconfigurado.

Esperamos que os hayan sido de utilidad estos dos artículos.

Anterior artículo de la serie:

El ERP y el cálculo de beneficios (I)

zp8497586rq

El ERP y el cálculo de beneficios: en búsqueda de la rentabilidad (I)

Un poco de historia

La invención de la escritura surgió de la necesidad de establecer un sistema contable. Hace como unos seis mil años, los templos y ciudades sumerios, habían alcanzado tal nivel de prosperidad que se hizo necesario la creación de un método para llevar la contabilidad de los bienes gestionados. En un principio se utilizaron sellos que al ser presionados sobre tablas de arcillas fresca, creaban marcas al estilo de las hendiduras sobre huesos utilizadas por pueblos más primitivos. La principal  novedad aportada por los sumerios fue que las marcas eran una representación pictográfica de los elementos a contabilizar, además de otras marcas que ayudaban a identificar personas y fechas.

Posteriormente comenzaron a utilizar sellos insertados en rodillos, lo que hizo más rápido el proceso, además de dotar a los documentos de un formato más organizado que facilitaba su lectura.  El llegar hasta nuestro actual sistema de numeración posicional de base diez, costó unos 3.000 años y sólo fue 13 siglos más tarde cuando ese sistema fue importado a Europa gracias a Fibonacci.

Solo un siglo más tarde, alrededor del 1340 en Génova surgió el sistema de contabilidad por partida doble, que no fue fundamentado de manera escrita hasta finales del siglo XV por Luca Paccioli. Desde entonces las aportaciones teóricas han sido más bien escasas, las pocas conocidas parecen haber sido bastante desaventuradas.  Algunos  afirman que una parte importante de la actual crisis se debe al cambio de normas contable. Concretamente de la valoración de los activos, pasando del principio de valoración conservadora al método de valoración a precios de mercado.

Sea como fuere, el objetivo de último de un sistema contable es el cálculo del  beneficio o la pérdida, una simple operación substractiva que puede convertirse en complejísima.

El concepto beneficio y su profundidad

Cuando hablamos de beneficio, todos pensamos en una cifra global a final de año, que nos arroja el resultado global de una empresa. Lo cierto es que cada operación, al igual que cada acción en la vida tiene un coste y  un beneficio y es aquí donde la cosa realmente se complica.

Surge la cuestión de los costes que no son directamente  imputables a ninguna operación en concreto.  Otras veces los costes que sí que son directamente imputables, son difíciles de cuantificar, como por ejemplo los costes comerciales. A veces es muy difícil saber cuánto tiempo ha invertido un comercial en cada operación o cliente.

Llegado a este punto la lógica formal deja de tener tanta importancia  y  lo sustancial viene a ser lo que tiene sentido para la forma de funcionar de cada empresa. Esto incluye la cuestión de hasta donde quieren llegar con esto del cálculo de beneficios. Porque cálculo de los beneficios y pérdidas es una actividad que consume tiempo y recursos.  Con la informatización de los sistemas de administración el coste de realización de cálculos ha caído enormemente, en unos pocos segundos podemos realizar miles de cálculos que hace cien o cuatrocientos años hubieran supuesto días enteros de trabajo.

Pero esto no quiere decir que el coste haya desaparecido, estos sistemas han de ser configurados y es necesario decirles que es lo que tienen calcular. Además toda la información obtenida tiene que ser revisada, clasificada, analizada, asimilada e interpretada. Por si fuera poco muchos de los sistemas ERP que encontramos en el mercado carecen de la flexibilidad necesaria para llegar a llevar una contabilidad del beneficio hasta el nivel más alto de detalle.

Si somos lo bastante afortunados de contar con ERP capaz de llegar  a ese nivel detalle tal vez nos demos cuenta de que para tratar de manera adecuada semejante nivel de información necesitaremos un sistema de inteligencia de negocios. Aunque eso, “es harina de otro post”.

Siguiente artículo de la serie:

El ERP y el cálculo de beneficios (II)

765qwerty765