Ios

Informaros que el próximo 29 de Octubre tendrá lugar en “Torre Espacio” de Madrid (Paseo de la Castellana, 259) el EPM FORUM organizado por Oracle, que tratará todos los aspectos relacionados para asegurar que su compañía esté realmente manejando el riesgo y optimizando el rendimiento de su negocio en este nuevo clima económico.

El EPM Forum es una cita obligada para los responsables de gestionar la información para la dirección, de planificar, de definir estrategias, así como los profesionales de TI que dan soporte a las funciones financieras.

Para recibir información detallada o inscribirte en este evento, puedes enviar un mail a Almudena.sanz@ios.es o llamar al 916587656 y quedarás registrado.

La inscripción es gratuita y el aforo limitado así que INSCRÍBETE YA!

Juan Carlos García Fito

Hagamos un poco de historia sobre el producto original de donde y como nació el producto que hoy en día Oracle abandera como uno de sus productos líderes en plataformas iSeries.

En 1977 nace JD Edwards World Solution Company en Denver, Colorado y desarrolló una aplicación básica de contabilidad para sistemas /34 y /36 de IBM. Con posterioridad, IBM lanzo su nuevo sistema llamado AS/400 que incorporaba como base de datos DB2/400, esto hizo que JD Edwards lanzara al mercado su producto totalmente remodelado y adaptado a las nuevas necesidades del mercado con nuevas funcionalidades que le hizo convertirse en una aplicación ERP llamada “WorldSoftware” o popularmente “World”. En 1996, ante el boom de sistemas con arquitectura cliente/servidor, JD Edwards lanza al mercado su versión denominada “OneWorld” (que nada tiene que ver con “Oneworld”, la alianza de aerolíneas comerciales), la cual era independiente a las plataformas iSeries, (aunque compatible ya que se puede utilizar el iSeries como Enterprise Server), con la cual se abarcaba el nuevo mercado emergente y a la vez cubría todo el espacio de mercado con las dos versiones del producto, que indudablemente tenían y tienen tecnologías totalmente diferentes.

En 2003 Peoplesoft absorbe a JD Edwards, renombrando los dos productos por Peoplesoft Word y Peoplesoft One adaptándolos a los nombres de todos los productos Peoplesoft, a mi entender un error que provocaba perder una referencia a tantos años de experiencia. Esta situación duró poco tiempo, ya que en 2005 Oracle Corporation firmó la adquisición de Peoplesoft y devolvería, con nuevas versiones de los dos productos totalmente remodelados, su antigua entidad y nombre, “JD Edwards World” y “JD Edwards EnterpriseOne”.

En la actualidad, y después de más de 30 años en el mercado, el hermano mayor de los productos “JD Edwards World” sigue siendo el Nº 1 con la mayor base instalada en plataformas IBM iSeries.

Jose Tejedor

 ¿Cómo podemos controlar nuestros gastos? En estos días de crisis económica, ésta es una pregunta que las empresas de todos los sectores se hacen a diario. Resulta vital para la supervivencia de las empresas el llevar un riguroso control de los gastos tanto a largo plazo, como en el día a día. Para ayudarnos a llevar a cabo estas labores de “vigilancia”, podemos hacer uso de las muchas posibilidades que ofrece un ERP como JD Edwards.

En primer lugar gracias al módulo de compras de JD Edwards EnterpriseOne, podemos establecer un control sobre nuestro proceso de compras más básico, el llamado “Purchase to Pay”: hacer la compra, recepcionarla, y pagarla. La ventaja que tiene este proceso es que todo está perfectamente relacionado, y se puede configurar de manera que el sistema ejerza un férreo control: sólo puedo recepcionar aquello que figura en el pedido de compra que he hecho, y únicamente puedo pagar aquello que he recibido. De esta forma se evita tener material que no hemos pedido en nuestro almacén o tener que realizar devoluciones al proveedor; y por otro lado, sabemos exactamente que nos debe facturar nuestro proveedor, sin posibilidad de errores, ya que lo validamos con nuestra recepción.

Pero además, existen otras funcionalidades menos conocidas del módulo de compras de JD Edwards EnterpriseOne que pueden optimizar nuestras compras y ayudarnos a capear mejor el temporal.

Por ejemplo, podemos establecer un sistema de solicitudes internas que permitan crear una central de compras interna; de este modo, se realiza un único pedido al proveedor para todos los departamentos de la empresa, obteniendo descuentos por volumen y permitiendo reducir los costes de transporte.

Para incrementar el control sobre los gastos, podemos usar las rutas de aprobación, que permiten retener un pedido de compra cuando éste supera una cantidad determinada, estableciendo distintos niveles de aprobación según su importe y escalando automáticamente la aprobación según sea necesario.

También podemos optimizar nuestras compras haciendo uso de los controles por importe mínimo, que bloquean los pedidos de compra que no lleguen al valor mínimo para un proveedor determinado. Con esto logramos evitar que se realicen muchos pedidos pequeños en lugar de uno grande.

Otra posibilidad que se nos ofrece es la de establecer presupuestos para los distintos departamentos de la empresa, de manera que cada compra que realicen tenga en cuenta este presupuesto, y se bloqueen los pedidos hasta su aprobación o rechazo.

Por supuesto, en EnterpriseOne toda la información referente a los proveedores con los que trabajamos, como cumplimiento de plazos de entrega, calidad del material enviado, etc. queda reflejada en el sistema, y es posible realizar consultas sobre cada proveedor para seleccionar únicamente aquellos realmente fiables para trabajar con nosotros.

La ventaja que tienen estos controles es que pueden activarse en cualquier momento, tanto si se trata de una implantación, como si llevamos tiempo trabajando con nuestro ERP y queremos aprovecharlo al máximo.

Todos estos controles permiten optimizar las compras de nuestra empresa, reducir costes y facilitar la toma de decisiones, por lo que JD Edwards supone una ventaja que debemos aprovechar en estos momentos difíciles.

Angel F. Viartola

En una implantación de EnterpriseOne llega el momento de hacer una personalización.  ¿Qué se hace? ¿Se copia el objeto estándar y se modifica o se trabaja directamente contra el estándar? Es un debate que frecuentemente se da en los foros de JD Edwards. Yo tengo mi opinión al respecto: modificar el estándar siguiendo las recomensaciones de Oracle, siempre y cuando sea posible.

¿Cuales son las razones que me hacen elegir esa opción?

Copiar los estándares modificados a objetos nuevos implica perder toda posibilidad de mantenimiento por parte de Oracle: los parches se aplican sobre programas del estándar JD Edwards, no sobre programas de usuario. Y además, bajo determinadas condiciones, la aplicación de un parche no va a suponer la pérdida de nuestras modificaciones, siempre y cuando se hayan hecho con la metodología adecuada. Oracle en su serie de documentos “EnterpriseOne Modifications General Recommendations and Guidelines” explica detalladamente cómo se debe modificar el estándar, qué cambios son fácilmente reaplicables, qué cambios se perderán en el caso de actualización

En uno de los documentos de esa serie (ott-03-0020) se señala lo siguiente:

“Should I make a copy or should I modify the standard object? This is a judgment call. If the application has a lot of ER, is heavily used, often requires ESU’s, and is a big part of the day’s daily process, then modifying the standard object may be the best option.

If you make a copy of an object, you are making a snapshot of that object at a point in time when the copy is performed. When an ESU becomes available for the standard PeopleSoft EntepriseOne application that fixes a bug or adds functionality to the object you copied, the change is not included for the copied custom object. You can not direct the changes in the ESU to any object you want, such as a copy of the same object the ESU is intended for. The changes in the ESU are only applied to the object they are intended for.  Therefore any changes would have to be manually retrofitted to the custom object when an ESU is applied.”

“¿Debo hacer una copia o debería modificar el objeto estándar? Este es un juicio personal. Si la aplicación tiene un montón de ER, es muy usada, a menudo requiere de ESU (parches de la aplicación), y es una gran parte del proceso diario, entonces modificar el objeto estándar puede ser la mejor opción.

Si usted hace una copia de un objeto, usted está haciendo la copia de objeto en un momento concreto. Cuando un ESU que se disponga para el estándar de EntepriseOne corrija un error o aumente la funcionalidad del objeto que se ha copiado, el cambio no se incluye en cada objeto personalizado copiado (únicamente en el objeto original). Usted no puede aplicar los cambios del ES  a cualquier objeto que desee, como por ejemplo una copia del objeto estándar. Los cambios en los ESU sólo se aplican al objeto que están destinados. Por lo tanto, cualquier modificación tendría que ser manualmente aplicada para el objeto personalizado cuando se aplique un ESU al objeto original.”

Esto es: trabajar con programas copiados implica perder el mantenimiento, perder las posibles ampliaciones de funcionalidad, perder todo soporte por parte de Oracle.

Utilizar el estándar siempre es la mejor opción, sólo hay que diseñar las personalizaciones bajo un prisma de conocimiento adecuado de la aplicación, saber qué se guarda y qué se pierde (”what preserves and what replaces”) cuando se hace una actualización y ser conscientes de lo que es el desarrollo en EnterpriseOne. Hay herramientas y técnicas más que suficientes tanto para personalizar como para reaplicar los cambios sin perder nada y con una inversión de tiempo mínima si se hacen las cosas correctamente.

Un saludo a todos.

Angel F. Viartola

Una de las afirmaciones sobre Oracle  JD Edwards EnterpriseOne es que es una aplicación independiente de la base de datos.

¿Qué significa “independiente de la base de datos”?

En muchas instalaciones de EnterpriseOne no se tiene en cuenta la posibilidad de que EnterpriseOne funcione de forma absolutamente independiente de la base de datos, siendo irrelevante que ésta sea Oracle, SQL Server o DB2. La aplicación es la misma en todos los casos, sólo variando en el proceso de instalación la forma de crear la base de datos o instalar el Enterprise Server, que lógicamente varía en función de la plataforma utilizada. Pero una vez realizada la instalación, desde el punto de vista de desarrollo y en el día a día, el hecho de que la base de datos o la plataforma sea una u otra es absolutamente irrelevante.

En muchas ocasiones encontramos que para realizar cargas de datos desde otros sistemas se exportan los datos a ficheros planos para después cargarlos de nuevo en JD Edwards, con lo que ello conlleva tanto a nivel de desarrollo como en posibilidades de error.

Pero si tenemos nuestro sistema corriendo en una BBDD Oracle y el control de almacén en SQL Server, ¿qué nos impide acceder directamente desde EnterpriseOne a una información almacenada en ese SQL Server? ¡¡Nada!!

Para tomar o dejar datos bastaría con crear un “Database Datasource” que apuntara al servidor al que queremos acceder, configurar el usuario de sistema adecuado, asociarlo al usuario que necesitar ese acceso y eso es todo: nos olvidamos de exportar, importar, carpetas de intercambio y demás complicaciones, simplificándolo y dejándolo en un acceso directo a la base de datos que necesitemos.

A partir de ahí la integración con otros sistemas, tanto a la hora de tomar como de dejar información se simplifica. Más aún cuando podemos jugar con toda la tecnología de JD Edwards a la hora de utilizar ese acceso: creación de pantallas, aplicaciones batch, uso del diccionario de datos, tablas, triggers de tabla, todo ello será perfectamente válido a la hora de acceder a esa nueva fuente de datos, sea o no una de las estándares de EnterpriseOne.

Probadlo… os sorprenderá.

Un saludo a todos.

Miguel Angel Hernández

En primer lugar, decir que el presente artículo ha sido redactado desde el punto de vista del mercado español y teniendo en cuenta el mercado de las soluciones ERP, foco principal de IOS. No se ha tenido en cuenta otros países, que pudieran tener otras características, ni tampoco el software libre, el cual se escapa de nuestro alcance.

Con el paso de los años, el mercado de las soluciones ERP ha sufrido notables cambios. Entre otros aspectos, hemos pasado de un escenario con dos estratos claramente diferenciables y que a continuación clasificamos, a otro escenario mucho más disperso y entremezclado. De forma muy general, los dos grandes bloques a los que hago referencia son:

• “Grandes” soluciones ERP para “grandes” empresas: Son soluciones generalistas que previa adaptación y “parametrización” tienen cabida en todos los sectores. Generalmente atienden a proyectos de gran alcance, alta componente tecnológica, altos plazos de implantación (más de 1 año). Provienen de grandes fabricantes como Oracle , SAP, Microsoft, etc.
• “Pequeñas” soluciones para “pequeñas” empresas: Soluciones de carácter mucho más específico, con funcionalidad más reducida, menos capacidad de adaptación, baja componente tecnológica y reducido tiempo de implantación (varios meses o incluso semanas). Para compensar sus carencias funcionales, presentan muchos procesos desarrollados exclusivamente para atender a la necesidad del cliente, convirtiéndolas en soluciones perfectamente verticalizadas. Normalmente son distribuidas por “pequeños” fabricantes de software, muchas veces nacionales.

La línea de separación entre estos dos grandes bloques siempre ha estado claramente diferenciada hasta el punto de que simplemente por el tamaño de la compañía ya estabas condicionado a una solución u otra. Atendiendo a dicho tamaño así como al de la solución, podemos establecer la siguiente clasificación y su relación con la solución ERP implantada:

Grandes Compañías, empresas con más de 250 empleados y un volumen de negocio superior a los 50 M€. Por lo general ya tienen implantada una “gran” solución.

Mediana empresa: Entre 20 y 250 empleados y con una facturación comprendida entre los 3 M€ y los 50M€. Por lo general, o bien tienen una gran solución muy adaptada (que no verticalizada) a sus necesidades, o bien tienen una solución de las “pequeñas” perfectamente verticalizada, de nueva adquisición o con la que llevan trabajando desde que eran una pequeña compañía, o bien, un desarrollo a medida con grandes limitaciones.

Pequeñas empresas: Menos de 20 empleados y facturación inferior a los 3 M€. Estas compañías por lo general, o bien tienen una solución de nicho totalmente sectorizada y limitada, o un desarrollo a medida, o no tienen solución ERP.

Nos centraremos principalmente en el caso de las Grandes compañías y el de las Medianas empresas, al ser en este entorno, donde se produce la mezcla de intereses.

Desde mi punto de vista, y dejando al margen el posible efecto de la situación económica, existen varios factores que han motivado el cambio de escenario, o quizás mejor decir, la mezcla o choque de escenarios:

• La notable disminución de grandes compañías o multinacionales demandantes de nuevos productos y/o soluciones ERP, ya que no sale una gran compañía todos los días, y las existentes ya poseen una gran solución ERP.
• Como consecuencia del punto anterior, los grandes fabricantes de software se han visto obligados a “mirar” hacia abajo en la pirámide empresarial y más concretamente en el caso español, al estar compuesto en su mayoría por Pymes.
• Las “pequeñas” soluciones que trabajando en el marco de la pequeña y mediana empresa, al ofrecer productos de reducida funcionalidad, comparado con las grandes soluciones, se han visto obligadas a desarrollar en sus proyectos, funcionalidades demandadas por sus clientes. Estas funcionalidades han hecho de estos “pequeños” productos, unos sistemas perfectamente adaptados a la problemática de sus clientes, es decir, se han verticalizado. Esta verticalización ha dado como resultado un notable aporte de valor añadido a sus soluciones, lo que les ha empujado a mirar hacia arriba en la pirámide empresarial.

¿Serán capaces los grandes fabricantes de software de adaptar completamente sus estrategias a este mercado intermedio? ¿Es la verticalización el camino para estas grandes soluciones? ¿Será rentable esta verticalización para el gran fabricante teniendo en cuenta el alto coste de licencias, expertis, complejidad tecnológica, etc? ¿pondrán estos fabricantes toda su experiencia en la realización de estos verticales o serán sus Partners los que tengan que asumir el reto? ¿Están las Pymes en situación de abordar proyectos de verticalización con grandes soluciones? ¿Podrán competir en precio con las experimentadas “pequeñas” soluciones ya verticalizadas? ¿Hasta que altura de la pirámide llegarán los pequeños fabricantes? ¿o hasta donde bajarán los grandes? ¿prefieren los clientes una solución que se les de una pronta y sencilla salida a sus problemas o invertirán en soluciones de más largo recorrido?

Todas estas cuestiones y muchas otras son motivos suficientes que nos llevarán a escribir otros artículos.

En este artículo he intentado dar mi opinión en unas pequeñas pinceladas sobre el mercado de ERP. Tan amplio y complejo es este sector que hasta el orden de los conceptos es difícil de conseguir. Espero de vuestros comentarios para entre todos ponerlos en consonancia.

Un saludo