Archivo de la etiqueta: sistemas de informació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 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

El ERP como motor de creación de valor: más allá de la eficiencia

crear_valor

Hace  tiempo que tenía ganas de escribir este artículo, hoy leyendo este magnifico post,  en el blog de Anibal Goicoechea sobre el cambio de paradigma en los proyectos tecnológicos me he decidido. En el sector de las nuevas tecnologías todas las empresas llevamos años vendiendo la burra de la eficiencia, que está muy bien, pero el software para empresas debería de ser algo más que simplemente eso.

Que las soluciones ERP sirven para mejorar la eficiencia es un mantra bien sabido y repetido por fabricantes, partners y expertos en decenos de folletos, páginas webs, catálogos, post de blogs, tweets e inlcuso hasta en Facebook. Nadie pone en duda este axioma, pero a nuestro juicio, la verdadera cuestión es la siguiente: ¿los ERP solamente sirven para mejorar la eficiencia? ¿Es esta su principal misión?

¿Hacia donde nos lleva la eficiencia?

La eficiencia es un camino de una sola dirección, generalmente sólo hay una manera más eficiente de hacer un trabajo. Reconozcamos que aprovechar el papel higiénico usado para limpiarse los mocos es una formula muy eficiente de minimizar el gasto en consumibles, pero  que nadie está dispuesto a implementar.

La teoría general de sistemas nos dice los sistemas cerrados son mucho más eficientes que los sistemas abiertos, desgraciadamente las empresas, los seres humanos y los grupos sociales son sistemas abiertos. Algunos ejemplos de sistemas cerrados son una olla a presión o un pistón mecánico, así que ya lo saben si nuestro objetivo es eficiencia debemos aspirar a convertirnos en un mecanismo.

¿Existe algún otro objetivo que perseguir ?

Ahora bien en muchos casos la importancia de la eficiencia es secundaria cuando no irrelevante, tomemos cómo sencillo ejemplo el de la industria del lujo. En este tipo de productos, la eficiencia es un atributo a evitar, su sobriedad austera no encaja nada con la pompa y el exceso tan característico de productos cuya principal ventaja es que sirven para la ostentación. Está claro que es un ejemplo extremo, pero tenemos claros que a la hora de escoger un producto u otro lo que nos hace decantarnos es el valor que nos aporta, en relación a su precio.

La eficiencia empresarial que garantiza la mayoría de los fabricantes de soluciones ERP, principalmente tienes efectos sobre la segunda variable de los costes, que nos permite o bien bajar precios o ser más rentables, pero por muy eficiente que sea su empresa, sino aporta valor no irá muy lejos.

El objetivo principal que tendríamos que tener en mente a la hora de implantar, no sólo un ERP, sino cualquier solución empresarial, debe de ser incrementar la capacidad de la empresa para crear valor, una empresa eficiente que crea menos valor para sus clientes que la compentencia no es nada. Esta claro  que podemos generar valor mediante la eficiencia, pero este sólo es una pequeña parte del total.

zp8497586rq

Reduciendo el coste del reporting en la empresa

Al igual que en cualquier tarea importante muchas veces lo más dificil es saber por donde tenemos que comenzar. En un artículo anterior del mes de Febrero, definimos con claridad cual es eran los princpales componentes del coste del reporting en la empresa. Teniendo claros estos conceptos, podemos emprender de manera mucho más fácil acciones que nos permitan reducir su coste para nuestra empresa.

Mejorando la infraestructura

A nivel de infraestructura es siempre el personal de la propia empresa el que mejor puede determinar acciones para reducir costes. No obstante, una de las principales razones de sobrecostes en la que incurren muchas empresas suele ser un uso de diversos sistemas de reporting.

El escenario que se plantea en muchos casos es el siguiente: una compañía utiliza diversos sistemas para sus distintos departamentos, delegaciones o divisiones. Cada una de estas herramientas cuenta con su propia solución de reporting. Esto al final no solamente representa  en un mayor coste, sino que además impide una visión compartida acerca de la realidad de la empresa a nivel interno. Por tanto una mayor integración a todos los niveles suele redundar en una importe disminución de los costes, en hardware, licencias y software  y en el coste final de la información, mejorando casi siempre la fiabilidad de la misma.

Si queremos disminuir los gastos de nuestra empresa en consumibles, la digitalización es sin duda nuestra mejor opción. Minimizando el coste en papel, impresoras, carpetas de colores y demás consumibles, no solamente ahorraremos una gran cantidad de dinero, sino que también mejoraremos la seguridad de la información en la empresa. Previniéndonos contra potenciales problemas  que se puedan derivar de la pérdida de información.

Mejorando la eficiencia

El apartado donde más podemos recortar los costes de reporting es sin duda en el tiempo que emplean los usuarios en buscar y procesar la información que necesitan. Estudios previos indican que algo más del 20% del tiempo de los empleados para los que el conocimiento forma una parte importante de su trabajo (oficinas, técnicos, informáticos, etc…), es utilizado en la obtención de información que resulta importante para su trabajo. Esta cifra sube hasta un 40% cuando hablamos de profesionales cuyo trabajo son principalmente tareas administrativas.

Sea cual sea la posición que ocupe cualquier persona en la organización, con buena información podrá hacer mejor su trabajo. Pero no sólo se trata de una cuestión eficiencia, la seguridad también es importante. Una gran cantidad de los recursos que se de reporting que se utilizan a día de hoy en las empresas se corresponde a labores de control y supervisión, tanto a nivel operativo como estratégico.  Las labores de control, consisten básicamente en cerciorarse que todo marcha bien y de que no se produce ninguna anomalía no prevista en el transcurso de las operaciones.

Pues bien, a día de hoy con un buen sistema de inteligencia de negocios este tipo de tareas pueden automatizarse. Podemos establecer criterios que indiquen al sistema en que podría consistir esas anomalías: una rotura de stock, un nivel demasiado alto de impagos por parte de un cliente,  una  disminución de un 20% en el número de pedidos de una zona. Después solo tenemos que poner a trabajar a nuestro sistema que se encargará de ir rastreando nuestros datos comprobando que no se haya producido anomalía que les hemos indicado. En cuanto lo  detecte, enviará notificaciones mediante mensajes a las personas responsables o con capacidad para resolver ese problema en cuestión.

 

8 cosas que no debe tener tu implantador de ERP

1. Un equipo para las demos y otro para las implantaciones:   Cuando estamos en un proceso de elección de un ERP, es recomendable que las personas que realizan la demo, sean las mismas que luego implantarán la solución. Es algo similar al concepto informático del WSWYG(En inglés, lo que ves es lo que obtienes).  En la mayoría de las consultoras, existen roles definidos, hay consultores preventa e implantadores. Si se da este caso, debemos de solicitar conocer  en profundidad al equipo encargado de la implantación, así como disponer de sus currículos y el máximo nivel de detalles de su experiencia profesional y académica.

En un mundo ideal, no sería necesario hacer esto. En el mundo real, muchas empresas tienen a sus dos o tres gurús haciendo demos: conocen el producto, saben comunicar y tienen empatía con el cliente. El problema es que después de firmar, el cliente  espera encontrar lo mismo durante el proyecto. Muchas veces el parecido de lo real con lo firmado es similar al que tienen un huevo y una castaña. Cuanto menos importantes seamos como clientes para la  consultora, más posibilidades tendremos de que nos envíen a los segundas espadas y que los cracks estén colocados en otro cliente. Esto en si tampoco sería malo si van como parte del equipo de apoyo y en la factura está diferenciado, es decir, paga lo que compra.

2. Falta de personal especializado para el producto a implantar:   A veces se da la circunstancia de que algunas consultoras gestionan una gran cartera de productos. Su labor es poco más que comercial y carecen del personal adecuado para afrontar un proyecto de implantación de un ERP en todas sus fases. Lo  que implica que tengan que subcontratar el trabajo,  esto en principio no tendría por qué ser malo, pero añade una complejidad estructural al proyecto, añade sobrecostes y el riesgo de que la calidad a entregar baje es más elevado.

La clave para evitar este problema, es la misma que la del punto primero, debemos de tener siempre claro que personas formaran el equipo que implantará nuestro proyecto.

3. Equipos de consultores poco definidos:   La implantación de soluciones ERP es un trabajo de equipos, en plural. Muchas veces un equipo de pocas personas, acostumbradas a trabajar juntas, con buena relación y bien estructurado,  puede hacer más que un equipo con el doble de personas que no tienen rodaje como tal. En los equipos bien establecidos el trabajo se vuelve más fluido, la comunicación más directa y la empatía con el resto de miembros hace más fácil la realización del proyecto.

Desde el punto de vista de la empresa que está contratando a un implantador, esto es difícil de verificar, ya que puede ser engañada más fácilmente. Aun así, sigue siendo importante comprobarlo, porque en este tipo de detalles es de donde surgen los sobrecostes y un mal rendimiento del sistema a posteriori.

4. Metodología poco definida: Muchas empresas tienen una metodología de implantación pulcramente definida que exhiben a sus potenciales clientes en las demostraciones. Luego, cuando llega la hora de la implantación la ignoran completamente. Aun en este caso, siempre es mejor que una empresa que ni tan siquiera ha hecho un esfuerzo por definir su metodología, en este tipo de casos nos estamos exponiendo a un grave riesgo. Puede que sean capaces de llevar el proyecto a buen puerto, pero la falta de concreción en este punto denota a su vez una falta de profesionalidad.

En el otro extremo podemos encontramos a las consultoras que tienen una metodología y que además la aplican. Esto es una garantía para la empresa contratante, los servicios son productos intangibles y muchas veces no sabemos lo que estamos comprando hasta que lo hemos comprado. Las consultoras con este modus operandi ofrecen g que los podemos encontrar durante el proyecto. Eso es muchísimo más que nada. (esto no lo entiendo)

5. No tener un plan B para los sobrealcances:   Salvo que se realice un trabajo de consultoría inicial que determine las necesidades de la empresa, no es posible determinar en el alcance del proyecto todo lo que la necesitaremos. Las empresas no son organismos inertes, están expuestos al vaivén de su entorno y a los propios cambios internos. Hasta aquí, todo normal, lo que no es normal es no prever contingencias de este tipo y no haber dispuesto  un protocolo de actuación para este caso.

Este, es sin duda es un punto delicado en el que dos partes tendrán que ser flexibles, ni la empresa puede pretender que la consultora trabaje gratis, ni la consultora debe intentar desangrar a su cliente. ¿Cómo minimizar el sobre-alcance? Esto nos lleva al siguiente punto.

6. Planificar los proyectos a la ligera:   Cuanto más detallada y escrupulosamente planifique los proyectos el implantador muchísimo mejor.  La realidad siempre es tozuda y seguro que hará todo lo posible para alterar nuestros planes. Pero siempre es mejor rectificar el rumbo que no ir a la deriva, “no hay viento favorable para el barco que no tiene rumbo”. Al igual que en el punto anterior una planificación detallada nos otorga un cierto grado de certeza, además de una mayor capacidad para que la empresa planifique y se adapte al proyecto en base a un escenario planteado con el máximo nivel de realismo posible.

7. Rotación de personal: Ha de garantizarse la continuidad del equipo a lo largo de todo el proyecto. Es importante que siempre sean las mismas personas, ya que los cambios continuos han dado al traste con muchos o proyectos o han multiplicado considerablemente la factura. Si es posible inclúyalo en las clausulas de su contrato.

8. Falta de capacidad para gestionar el cambio: Implantar un ERP es mucho más que un proyecto tecnológico con desarrollos y configuraciones. Es un sistema vital que da soporte a casi todas las operaciones de la empresa y cualquier modificación tiene un impacto en las mismas. Hablar de un cambio total de sistema, son palabras mayores. Para esto no simplemente basta con tener la capacidad técnica necesaria para llevar a cabo el trabajo, se necesita además ser capaz de gestionar el lado humano del proyecto. Cualquier cambio de ERP en una empresa suele encontrarse resistencias, por muy favorable que sea el ambiente.

Para poder valorar la capacidad de gestionar el cambio de un implantador siempre es interesante poder hablar con referencias de ese partner y a poder ser, no solamente con las que ellos nos faciliten. Todos tenemos amigos y enemigos, gente dispuesta a hablar a nuestro favor y contra nosotros. Para poder establecer un juicio sensato, es recomendable poder escuchar ambos tipos de testimonio.

Esperamos que estos breves consejos os sean de ayuda

zp8497586rq

Análisis de la nueva interfaz de usuario de JD Edwards EnterpriseOne 9.0

Siguiendo con la anterior con la serie de artículos en las que analizamos la interfaz de usuario de Openbravo, hoy le toca el turno a JD Edwards y los cambios incorporados en su versión 9.0 que a nuestro juicio han mejorado bastante la usabilidad de la aplicación. Todas las imágenes del artículo son ampliables haciendo click encima en modo “lightbox”, lo que os permitirá observar con más detalle el aspecto concreto de la interfaz.

Lo primero que podemos comprobar en la nueva interfaz en comparación con la interior es la desaparición del menu lateral de navegación de la parte lateral, que teníamos en las anteriores versiones (segunda imagen),  esto ha liberado una parte importante importante de la pantalla lo que mejora enormemente la visibilidad.

índice

Pantalla antigua JD Edwards:

jd_antiguo

Todas las funciones de navegación de la sección lateral han sido desplazadas a la parte de superior de la pantalla, que podeis encontrar en la siguiente imagen. En la parte izquierda de la pantalla debajo del logo se encuentran, los menús de navegación por la aplicación. El primer enlace nos lleva la home, con el segundo mediante menús desplegables de múltiples níveles tenemos acceso a cualquier aplicación dentro de nuestro JD Edwards.

El tercer, cuarto y quinto enlace de la zona izquierda abren sendos menús desplegables a Aplicaciones abiertas, Reports recientes y Favoritos. Lo que nos permite tener una acceso mucho má rápido a los elementos que más utiliza cada usuario. Esto es especial útil en aplicaciones tan grandes como un ERP, donde la mayoría de los usuarios sólo utiliza una fracción de los programas y reports. El fast path, o campo de búsqueda por códigos de aplicación, tan usado por los usuarios avanzados ha sido desplazado a la parte superior derecha de la aplicación, junto con las opciones de usuario, de visualización y de loggeo.

A mi juicio resulta todo una acierto está nueva configuración de las herramientas de navegación, ya que libera nos permite un espacio de trabajo mayor. Para lograr este espacio equivalente en la anterior versión, teniamos que ocultar el menu lateral, con el consiguiente incoveniente de tener que estar ocultándolo y mostrándolo continuamente.

menu_superiro

A continuación vemos un ejemplo de menú desplegable. Como vemos tiene múltiples niveles. Cabe destacar que los desplegables saltan mediante click y no pasando el cursor por encinma de las opciones. Esto a nuestro jucio es un acierto, ya que aunque le resta un pelín de velocidad, hace el menú mucho más manejable y evita que nos desperezca el menú si movemos el curso un pelín fuera de la selección.

menu_desplegable

Otras de las principales incorporaciones en esta nueva versión las nueva versión de la Home,  que es un carrousel configurable  en el que podemos incluir los distintos workflows de la empresa o incluso páginas web externas, como la ayuda online de JD Edwards o la web de nuestra empresa donde podemos consultar información que neceistamos. Los workflows son gráficos donde se nuestra manera visual los distintos procesos de nuestra empresa.

El de la siguiente imagen recoje el proceso de compra, desde la solicitud de compra hasta el pago de la factura a proveedor, haciendo click en cada uno de los cuadros vamos a la aplicación que se utiliza en cada paso. Si por ejemplo quisieramos revisar y aprobar órdenes de compra simplemente tendriamos que hacer click en el icono de la segunda columna y accederiamos directamente al programa en cuestión.

workflow

Otras de las recientes mejoras es la incorporación de una barra de acceso rápido, en la parte inferior, con un aspecto más visual basada en iconos y pestañas. Siempre es más fácil identificar las imágenes que el texto. Esta mejora bien utilzada permite mejorar mucho la productividad de los usuarios. Este espacio es totalmente configurable y además sino nos gusta este tipo de navegación lo podemos ocultar.

acceso_rapido

Por ultimo tenemos una imagen de las pantallas de aplicación con sus formularios, aquí los cambios han sido mínimos por varias razones. El sistema es bastante efectivo y el realizar grandes cambios hubiera penalizado a los usaurios de versiones anteriores. ¿Porque cambiar algo cuando funciona bien?

pantalla_general

Esperamos que os haya sido útil este repaso, para cualquier cuestión relacionada no dudeis en contactar con nosotros.

zp8497586rq

Nuevo video de Golive: Empresas más competitivas con Aplicaciones Web

En el canal de Youtube de Golive hemos estranado una nueva serie de videos. Se  trata de una colección de videos cortos en las que intentamos mostrar en forma de píldoras de conocimiento, algunos de los puntos más destacados de nuestra filosofía. Esto es, los puntos principales sobre los que una empresa ha de construir su estrategia en cuanto a nuevas tecnologías se refiere.

En esta primera ocasión hemos querido destacar las ventajas que el uso de aplicaciones web ofrecen para las empresas. Este tema ya ha sido mencionado en algún artículo en la web de Golive. No obstante los gráficos en movimiento nos ofrecen la posibilidad de ilustrar los mismo conceptos de una manera más rápida y con más dinamismo. Esperamos que sea de vuestro agrado.

Cualquier comentario duda o sugerencia son siempres bienvenidos.

Exprimiendo Oracle BI al máximo: gestor documental y actualización de registros

oracle_bi_slide

Cuando se trabaja con paquetes de aplicaciones  completos como Oracle BI, es fácil que parte de su funcionalidad nos pase inadvertida e incluso podemos llegar a sorpendernos de las cosas que podemos realizar con una misma aplicación.

Dentro de la suite de OBIEE encontramos quizás la más popular de todas sus aplicaciones, Oracle BI Answers, es una herramienta de análisis que procesa los datos desde múltiples orígenes para mostrarlos en un entorno web, y los usuarios pueden consultar y compartir los informes, cuadros de mando, kpi´s,… de todas las maneras y formatos posibles.

Estamos acostumbrados a usar la herramienta de Oracle para los usos que en principio se diseño, pero muchas veces obviamos algunas capacidades que la herramienta puede ofrecernos y que nos salven de utilizar otros interfaces ó tecnologías.

1.- Utilizarlo como gestor documental.

Recordemos que un gestor documental es un sistema para administrar documentos, organizarlos, compartirlos y dotarlos de seguridad.

En Oracle BI, administramos los informes con el catálogo, la herramienta nos permite subir todo tipo de ficheros de cualquier extensión, por lo que podremos subir a la plataforma imágenes y documentos para luego organizarlos, compartirlos y dotarles de seguridad para limitarlos a los usuarios que queramos.

Gestor_Documental

Además podremos usar, el buscador para encontrar nuestros documentos y consultarlos.
2.- Utilizarlo para insertar ó actualizar registros de un origen.

Sí, lo has leído bien, Oracle BI permite insertar, actualizar ó eliminar registros directamente de una base de datos ó actualizar una Excel, su implementación es muy sencilla, y su nombre es “writeback obiee”.

Modificar_empleados

Llegado el caso, te preguntarás ¿para qué necesito utilizar una herramienta de análisis para insertar registros, cuando para eso está mi ERP ó mi aplicación?

Siempre aparecen especificaciones nuevas que no las tiene contempladas nuestro ERP ó aplicación y no podemos asumir el coste ó el tiempo de modificarla donde habitualmente insertamos los registros,  además necesitamos que lo puedan modificar los usuarios a su antojo.

Con esta opción podemos ofrecerle al usuario un formulario de inserción, actualización y eliminación de registros, de manera rápida y sencilla, para luego consultarlos en la misma plataforma.

Supongamos que el responsable de ventas dispone de un informe de las ventas reales y quiere compararlos con los objetivos que mantiene en un excel. Quizás le interese poder modificar esos objetivos en la misma plataforma para después visualizarlos y compararlos con su valor real.

En definitiva, son usos menos conocidos los que nos brinda esta herramienta, que sin lugar a duda la hace la más completa del mercado.