Archivo de la etiqueta: Directores IT

JD Edwards EnterpriseOne: el primer ERP con movilidad totalmente integrada

Durante los últimos 3 años, JD Edwards ha venido haciendo un considerable esfuerzo por hacer de la movilidad una parte integrante de las posibilidades ofrecidas por su ERP. Todo comenzó durante los años noventa cuando JD Edwards se convirtió en el primer ERP con el que ese podía trabajar dese un navegador web. Fieles a su visión de adaptarse a los cambios que nos brinda la innovación tecnológico los de Colorado han sabido estar en a la cabeza de esta nueva revolución en la gestión empresarial.

movilidad_empresa2

El comienzo de una transición

Fue a finales de 2011 cuando JD Edwards anunció  la disponibilidad y soporte de JD Edwards en Ipad mediante navegador. El ser un ERP 100% web sin duda facilitó la tarea de adaptar JD Edwards para su visualización y trabajo sobre tabletas, ya que simplemente hubo que hacer unos pequeños ajustes en la aplicación para adaptarlo a la navegación táctil en tabletas mediante la incorporación de controles gestuales.

Esto hecho, no hizo más que poner de manifiesto hasta que punto había acertado la compañía en su estrategia.

Por aquel entonces las aplicaciones ya llevaban tiempo causando furor en  los mercados de consumo y desde Oracle se dio una importante muestra de audacia al lanzar la primera app móvil totalmente integrada con el ERP:  la de gestión de ordenes de trabajo. Esta aplicación permitía la gestión de órdenes de trabajo desde un móvil por parte de los responsables de mantenimiento de la empresa. Esta primera aplicación no se quedó en mera incursión y pronto vinieron más aplicaciones.

Extendiendo la movilidad a más áreas de la empresa

Con el lanzamiento de Oracle’s JD Edwards EnterpriseOne Mobile Requisition Self Service Approval, Oracle’s JD Edwards EnterpriseOne Mobile Purchase Order Approval y Oracle’s JD Edwards EnterpriseOne Mobile Sales Inquiry, a comienzos de 2012, JD Edwards logró mejorar la movilidad de departamentos como el de ventas y compras. Las nuevas aplicaciones permitieron a los comerciales la consulta al vuelo de todo tipo de información sobre pedidos y clientes. También se posibilitó a los  responsables de compras el aprobar las solicitudes de compra con un simplemente pulsar las pantallas de sus teléfonos móviles.

Y así hasta hasta más de 25 aplicaciones disponibles en la mayoría de los casos para tableta y para Ipad.  Las nuevas aplicaciones no sólo mejoraban la funcionalidad ofrecida a las áreas de la empresa con las que ya se estaba trabajando, sino que mejoraban la movilidad de otros departamentos permitiendo la aprobación de gastos de empleado,  consulta de inventarios, accediendo a direcciones de contacto de clientes o empleados, altas de caos servicios de postventa  e incluso ofreciendo la posibilidad de informar de accidentes laborales.

Además se dio un paso más en el soporte para tabletas con la creación de una aplicación para acceder a JD Edwards que mejoraba la experiencia de usuario de este tipo de dispositivos con una interfaz de usuarios y navegación totalmente adaptados.

El secreto de la capacidad de adaptación

La arquitectura tecnológica de JD Edwards basada en dos capas, una para tecnología y otra para aplicaciones unido a su apuesta por el SOA, son los principales pilares que han permitido a JD Edwards EnterpriseOne adelantarse a su competidores a la hora de integrar la movilidad en las soluciones ERP.

Por eso si su empresa está buscando un software capaz de adaptarse a los continuos retos a los que tienen que hacer frente las empresas con JD Edwards EnterpriseOne su empresa nunca se equivocará.

Durante los últimos 3 años, JD Edwards ha venido haciendo un considerable esfuerzo por hacer de la movilidad una parte integrante de las posibilidades ofrecidas por su ERP. Todo comenzó durante los años noventa cuando JD Edwards se convirtió en el primer ERP con el que ese podía trabajar dese un navegador web. Fieles a su visión de adaptarse a los cambios que nos brinda la innovación tecnológico los de Colorado han sabido estar en a la cabeza de esta nueva revolución en la gestión empresarial.

El comienzo de una transición

Fue a finales de 2011 cuando JD Edwards anunció  la disponibilidad y soporte de JD Edwards en Ipad mediante navegador. El ser un ERP 100% web sin duda facilitó la tarea de adaptar JD Edwards para su visualización y trabajo sobre tabletas, ya que simplemente hubo que hacer unos pequeños ajustes en la aplicación para adaptarlo a la navegación táctil en tabletas mediante la incorporación de controles gestuales.

Esto hecho, no hizo más que poner de manifiesto hasta que punto había acertado la compañía en su estrategia.

Por aquel entonces las aplicaciones ya llevaban tiempo causando furor en  los mercados de consumo y desde Oracle se dio una importante muestra de audacia al lanzar la primera app móvil totalmente integrada con el ERP:  la de gestión de ordenes de trabajo. Esta aplicación permitía la gestión de órdenes de trabajo desde un móvil por parte de los responsables de mantenimiento de la empresa. Esta primera aplicación no se quedó en mera incursión y pronto vinieron más aplicaciones.

Extendiendo la movilidad a más áreas de la empresa

Con el lanzamiento de Oracle’s JD Edwards EnterpriseOne Mobile Requisition Self Service Approval, Oracle’s JD Edwards EnterpriseOne Mobile Purchase Order Approval y Oracle’s JD Edwards EnterpriseOne Mobile Sales Inquiry, a comienzos de 2012, JD Edwards logró mejorar la movilidad de departamentos como el de ventas y compras. Las nuevas aplicaciones permitieron a los comerciales la consulta al vuelo de todo tipo de información sobre pedidos y clientes. También se posibilitó a los  responsables de compras el aprobar las solicitudes de compra con un simplemente pulsar las pantallas de sus teléfonos móviles.

Y así hasta hasta más de 25 aplicaciones disponibles en la mayoría de los casos para tableta y para Ipad.  Las nuevas aplicaciones no sólo mejoraban la funcionalidad ofrecida a las áreas de la empresa con las que ya se estaba trabajando, sino que mejoraban la movilidad de otros departamentos permitiendo la aprobación de gastos de empleado,  consulta de inventarios, accediendo a direcciones de contacto de clientes o empleados, altas de caos servicios de postventa  e incluso ofreciendo la posibilidad de informar de accidentes laborales.

Además se dio un paso más en el soporte para tabletas con la creación de una aplicación para acceder a JD Edwards que mejoraba la experiencia de usuario de este tipo de dispositivos con una interfaz de usuarios y navegación totalmente adaptados.

El secreto de la capacidad de adaptación

La arquitectura tecnológica de JD Edwards basada en dos capas, una para tecnología y otra para aplicaciones unido a su apuesta por el SOA, son los principales pilares que han permitido a JD Edwards EnterpriseOne adelantarse a su competidores a la hora de integrar la movilidad en las soluciones ERP.

Por eso si su empresa está buscando un software capaz de adaptarse a los continuos retos a los que tienen que hacer frente las empresas con JD Edwards EnterpriseOne su empresa nunca se equivocará.

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.

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.

 

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.

 

Los mandamientos de un proyecto ERP

Sin ánimo de dogmatizar, ahí van unos pocos preceptos que entendemos que ayudan a que  el proyecto de convierta en un éxito:

1. Hacer un análisis en profundidad del sistema actual: Si no conocemos bien nuestro actual ERP difícilmente podremos sacar partido a un nuevo sistema. Para ellos tenemos que evaluarlo con amplitud de miras:

¿Qué es lo que funciona bien?

–  ¿Qué es lo que funciona mal?

– ¿Qué cosas se podrían mejorar?

Y no solamente debemos de hacer un listado sin más, debemos de indaga un poco más e ir al porque de las cosas. Muchos problemas que se dan en las organizaciones no son tanto a causa del software sino de la manera de trabajar de la gente y de la forma de organizar los procesos por parte de la organización.

2. Tener claros los objetivos que queremos lograr: En un proyecto tan complejo como la implantación de un ERP es fácil perderse entre la cantidad de tareas, reuniones y cuestiones que tratar. Muchas veces una buena gestión del proyecto consiste en saber qué es primordial y que es lo que puede ser aplazado.

Para ello debemos de tener claras nuestras prioridades y saber qué pasos son necesarios para poder conseguirlas. La planificación del proyecto ha de estar basada en tareas e hitos. Los objetivos han de estar ponderados según su nivel de importancia. También debemos de ser flexibles porque conforme avanza el proyecto y nos vamos “metiendo en harina” a veces nos damos cuenta de que nuestras prioridades no eran realistas.

2. Crear un equipo interno de proyecto: Para que el proyecto sea un éxito no basta con contratar a una buena consultora. Se necesita una gran cantidad de trabajo interno e implicación en el proyecto, además de un cierto entusiasmo.

Imagen3

No hay nada que enquiste más un proyecto que una deficiente asignación de responsabilidades. Tiene que quedar perfectamente definido quien se va a encargar de cada área del proyecto. Además esas personas han de disponer de una cierta autonomía a la hora de tomar decisiones. No deben estar ahogados por las exigencias del trabajo diario en su puesto habitual.

Además, es imprescindible la figura de un jefe de proyecto que asuma la organización del mismo y que sea capaz de tomar decisiones cuando no haya acuerdo entre los otros miembros del proyecto.

3. Establecer un calendario de proyecto. A poder ser razonable: Para muchos el planificar y estimar tiempos de ejecución sea una actividad que les quita tiempo de su trabajo. La carencia de tiempo suele ser un síntoma de su mala administración.

Es casi un estándar en la industria que casi ningún proyecto se acaba como fue planeado. Esto no quiere decir que no se acabe a tiempo. Muchas veces algunos puntos acaban descartados y otros tantos que no habían sido contemplados se convierten en prioridad.  No obstante sin una referencia temporal bien establecida es casi imposible sacar un proyecto adelante que tenga un parecido mínimo con lo que tenemos en mente.

4. Mantener reuniones semanales para evaluar la marcha del proyecto: La mejor manera de sacar partido a la planificación establecida es hacer una revisión continua de la misma. Lo habitual es tener una breve, de una hora más o menos al final de cada semana, acompañadas por revisiones más exhaustivas a final de mes o cada vez que se alcanza un hito significativo.

Conociendo las desviaciones y las incidencias surgidas en los últimos días, podremos hacer una gestión más eficiente de las mismas, minimizando su impacto para así acercarnos al máximo posible a nuestro plan inicial.

5. Hacer una gestión del cambio planeado y eficaz.  Se puede dar el caso de tener un buen ERP perfectamente implantado, pero que acabe siendo un fracaso porque no ha sido bien acogido por la organización. En ese caso seguramente nos encontremos ante una gestión del cambio eficiente.

Para hacer una correcta gestión del cambio es necesario hacer un importante esfuerzo de comunicación a todas las partes implicadas en el proyecto para que conozcan sus beneficios y que el impacto del cambio se minimice. No es una cuestión menor, ya que requiere de mucha habilidad y son pocas las consultoras capaces de hacerlo con maestría.

7. Llevar una contabilidad del proyecto para poder establecer el retorno de inversión: Ya hemos dedicado varios artículos al retorno de inversión en proyectos IT y más en concreto al caso de los ERP. Muchas veces los beneficios de un nuevo ERP parecen tan evidentes que nadie se plantea hacer un estudio sobre el retorno de la inversión. Por otro lado el realizarlo suele ser mucho más complejo que cuando se adquieren otro tipo de bienes de inversión como maquinaria o equipos.

No obstante el realizarlo además de los beneficios propios, nos ayudará a hacer una aproximación mucho más realista al proyecto.

8. Tener una mentalidad abierta al futuro: Es imposible acometer un proyecto que responda a las necesidades actuales y futuras de nuestras empresa, por la sencilla razón de que las ultimas son imposibles de estimar. Esto no quiere decir que no tengamos que desechar las contingencias futuras por inciertas.

Los anglosajones tienen un proverbio que ilustra a la perfección la manera de actuar en estos casos: “prepárate para peor, espera lo mejor”. La mejor opción es no dejar ninguna puerta cerrada y optar por solucione flexibles que nos permitan adaptarnos con rapidez a los cambios que seguro nos encontraremos en el futuro.

 

La verdadera rentabilidad de un ERP

La rentabilidad de un ERP

Aun siendo un enemigo declarado de los acrónimos, me las he apañado para incluir 2 en 4 palabras. Tal vez sea porque el término retorno sobre la inversión me parece una penosa traducción de un término anglosajón para el que ya tenemos una palabra en español: rentabilidad.

La adquisición de un ERP viene a ser una inversión en bienes de equipo y como toda inversión debemos de prestar mucha atención a su rentabilidad. Cada inversión  responde a una decisión empresarial y por tanto tiene asociado un coste de oportunidad. El problema con los paquetes ERP es que es imposible saberlo, en la medida en que ese coste de oportunidad va asociado a otras decisiones de inversión descartadas que nunca podremos saber que tal hubieran funcionado. Hacer una simulación de cómo habría funcionado un ERP que nos adquirimos ese dedicarse hacer especulaciones cabalísticas.

Por lo tanto cualquier aproximación al ROI ha de  basarse sobre la situación previa a la implantación del ERP con respecto al sistema actual una vez estabilizado. El problema es que esto tampoco es sencillo, para comenzar en la mayoría de los casos carecemos de mediciones detalladas de cual era impacto del sistema de gestión en el funcionamiento de la empresa y la cuenta de resultados. Si el sistema de gestión cumple con unos requisitos mínimos de calidad comenzaremos a disponer de referencias.

¿Se  puede medir el ROI sin un sistema de referencias homologable? Si, pero para ello tendremos que plantearnos antes mucha cuestiones.

El problema de las dimensiones y la ponderación

Tomemos un ejemplo sencillo con el anterior sistema de gestión, el envío de pedidos y el servicio de atención al cliente eran deficientes y esto nos hacía perder clientes. Si estas deficiencias se corrigen con el nuevo sistema es lógico que tengamos un aumento de ventas además de una mejora en la retención de clientes. Por muy evidente que sea esa mejora, existen muchas variables que pueden influir en la mejora, por tanto es muy aventurado imputar la totalidad del aumento en las ventas a una mejora en el sistema de gestión.

Pero el verdadero nudo gordiano de la dificultad de medir la rentabilidad de un nuevo ERP, radica en el empecinamiento de intentar medir todo basándonos en unidades monetarias. Este enfoque resulta muchas veces insuficiente a la hora de conocer que mejoras nos aporta un nuevo ERP. Los incrementos ventas pueden venir acompañados de una disminución en la rentabilidad de la empresa o incluso pueden llegar a generar pérdidas. Una empresa puede mejorar su rentabilidad merced a una decisión estratégica pero a la  larga esta puede comprometer su viabilidad.

Las mejoras en la gestión pueden venir también en términos de un mejor conocimiento del negocio, una mejor capacidad de respuesta o un mayor control sobre los procesos. Algunas de estas cuestiones son imposibles de medir en términos cuantitativos, otras se pueden medir pero no necesariamente en euros.

Durante décadas la eficiencia se ha convertido en el credo universal de la gestión empresarial pero más eficiencia no siempre es mejor. Se puede llegar a hacer más cosas con menos recursos, pero hacerlas peor y por tanto perder clientes.

Imagínense que pasaría si Ferrían Adría pasase a servir hamburguesas en vez de complejos menús de degustación en su restaurante. Probablemente su capacidad para servir cenas aumentaría exponencialmente pero dudo mucho que la gente se acercara a su restaurante para paladear un sucedáneo de la Big Mac. Y es que el valor que aporta a sus clientes no es simplemente llenarles el buche.

Aquí se encuentra la clave para poder medir la rentabilidad que nos aporta un ERP a nuestra empresa y es la capacidad de aportar más valor a nuestros clientes. Esa es la base que debemos de utilizar para realizar cualquier valoración sobre la idoneidad de una inversión. Aportando más valor las ventas y la rentabilidad vienen por añadidura. No queramos construir la casa por el tejado.

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.

One to One BI: Un nuevo paradigma de inteligencia de negocios

Durante años hubo un paradigma que gozó de enorme aceptación dentro del mundo del marketing, el del one to one marketing. En un momento en el que se creía que la cultura de masas empeazaba a mostrar sintomas de agotamiento y el retorno de la publiciad tradicional era cada vez menor se planteó un modelo que  llevara la segmentación de los mercados hasta el nivel más básico: el del individuo. Se trataba de considerar a las personas como entes libres y no meras ovejas del rebaño.

El marketing directo fue tal vez la disciplina que mejor supo recoger esa orientación, de la cual se ha estado beneficiando en gran medida las técnicas más sofisticadas de marketing online y en general todo lo que pasa del puro spameo y la contratación de banners en base a coste por impresión.

Aunque este enfoque pudo parecer absolutamente novedoso en su momento en los mercados de consumo, hay que tener en cuenta que en algunos sectores como el B2B o los productos de lujo siempre se ha trabajado con muy pocos clientes. Una empresa de 100 empleados puede sobrevivir con 10.000 clientes o con uno solamente. Siempre y cuando sea capaz de pagar las facturas y llevarse algo bolsillo  a final de año.

Lógicamente conforme mayor sea el ratio empleados/clientes, mayor será el volumen de información y dedicación que corresponderá a cada cliente. Esto obliga a llevar una gestión más centrada en el detalle, menos dispersa en las abstracciones globales sobre segmentos. Lo que importa es el cliente como sujete de cargo, no las zonas territoriales ni las familias de productos.

Un cambio con implicaciones en los sistemas de información

Para poder afrontar estrategias de marketing basadas en este nuevo paradigma es necesario disponer de herramientas que nos permitan disponer de información extensiva sobre cada cliente, socio o proveedor. La naturaleza de las preguntas a las que tenemos que responder cuando tratamos de analizar a un individuo son muy diferentes a las que se nos plantean cuando intentamos detectar segmentos en grandes bolsas de individuos.

De entrada las posibilidades que nos ofrecen el procesamiento de los datos y aplicación de técnicas estadísticas es mucho menor. Hay que ir a un análisis detallado de los datos, la búsqueda de tendencias o subconjuntos pierde importancia, lo relevante es encontrar patrones que nos permitan conocer mejor al cliente en cuestión.

La capacidad de procesar y mover datos, se hace menos importante y lo realmente crucial es tener la habilidad de disponer la información de una manera visual y gráfica que nos permita captar sutilezas, patrones o nociones que se nos hayan podido escapar ante una lectura cruda de los datos.

Aunque tecnológicamente todo esto pueda lograrse con los medios disponibles, se echan en falta modelos conceptuales así como aplicaciones que los implementen y nos permitan llevar esto tipos de análisis a cabo.

¿Para cuándo contaremos con una paquete de One to One BI? En un entorno en el que la innovación se ha convertido en un nueva divisa imperial, parece raro que salvo la NSA y la CIA nadie haya intentado medrar en una campo de desarrollo tan prometedor.