Ios

Mario Garcimartín

Durante toda mi carrera profesional y prácticamente en casi todas las empresas donde he desarrollado mi profesión, siempre he recibido, en mayor o menor grado, seminarios sobre el buen hacer profesional. Dan vueltas alrededor de los grandes conceptos y vuelven a aparecer con periodicidad matemática. Expongo algunos ejemplos: 

-         Dentro de cada individuo hay un potencial sin explotar.

-         Ante los problemas se debe tener una actitud positiva.

-         No dudes de la valía de otros porque su opinión difiera de la tuya.

-         Hay que jugar el juego que realmente nos interesa.

-         Para cambiar mi entorno, primero debo analizar mi comportamiento.

-         Etc.., etc….

Todos estos consejos, y otros cientos parecidos, figuran siempre en los seminarios y que suelo denominarlos afectuosamente “cursos doctrinales”. Tienen una gran virtud: ninguno es discutible, pero tienen tanta influencia práctica como el efecto placebo; no tienen contraindicaciones, pero raramente curan algo. Aunque cada día estoy más convencido de que el éxito es consecuencia del trabajo bien hecho, todas las recomendaciones que posteriormente enumeraré son un intento de aproximarme, desde distintas perspectivas, a la única verdad que una vez leí y guarde en mi memoria como un tesoro. Y que dice así: 

-         ¿Cómo puede uno conocerse a sí mismo?

-         Nunca por la contemplación: solo por el obrar.

-         ¿Pero cuál es mi deber?

-         Lo que pida el momento.

Después de horas pensando en fines de semana, he pergeñado una serie de normas, que creo de aconsejable seguimiento para todos aquellos que en alguna medida pretendemos alcanzar un alto rango en eficacia. La empatía y el interés por los que nos rodean, o por los que nos encontramos en el largo camino de la actividad profesional, la ética y la proximidad en el trato, son virtudes que siempre suelen terminar por tener su premio. Mantener siempre un elevado nivel de autoexigencia, de curiosidad por los avances, la búsqueda de la perfección sin despilfarros, el aprovechamiento óptimo del tiempo, la programación de objetivos alcanzables, la comunicación eficiente y la capacidad de innovar son factores importantes en la consecución del éxito.

Sin olvidar nuestra salud, nuestra apariencia y nuestros modales, porque como dijo una vez Quevedo es su “Buscón”: Te reciben como te presentas y te despiden como te comportas.

Y sin más dilación, a continuación expongo los principios que considero fundamentales para alcanzar un nivel óptimo de excelencia y que he dejado entrever en párrafos previos: 

-         Interesarse por los demás.

-         Cultivar la autoexigencia.

-         Controlar el entorno.

-         Marcarse objetivos.

-         Programar las acciones.

-         Comunicar con eficiencia

-         Trabajar en equipo.

-         Tomar decisiones.

-         Ser creativo.

-         Ocuparse de uno mismo.

 En días sucesivos intentaré desarrollar cada uno de los puntos expuestos.

 Saludos.

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.

Fernando Álvarez

Voy a dedicar estas líneas a intentar resumir y clarificar la localización y clases de objetos utilizados en las aplicaciones de JD Edwards EnterpriseOne, en concreto para la versión 8.12 y tools superior a la 8.96.

Hay diferentes tipos de objetos: aplicaciones interactivas, reports, funciones de negocio, tablas, etc.

Atendiendo a su forma de almacenamiento, se distinguen tres tipos de objetos: Objetos Centrales, Objetos Replicados y Objetos Serializados.

Objetos Centrales : son especificaciones y componentes C. Las especificaciones se almacenan en una Base de Datos en el Servidor de BBDD. Los componentes C se guardan en directorios en el Deployment.

Objetos Replicados : se crean durante el proceso de construcción de Paquetes a partir de los Objetos Centrales. En este caso las especificaciones se almacenan en formato XML y se guardan (según el spec.ini del Deployment) tanto en una BD MSDE en el Deployment (a la que accederán los Clientes Pesados), como en un repositorio compartido de specs en el Servidor de BBDD (según el spec.ini del Enterprise, y al que accederán tanto el Enterprise como el Web Server), por ejemplo: Central Objects – DV812. En el caso de los Objetos Replicados, los componentes C ya se encuentran vinculados y compilados y se almacenan en directorios del Deployment, Enterprise y Clientes Pesados.

Objetos Serializados : son creados y almacenados en el Web Server a partir del repositorio compartido de especificaciones. Se convierten en código Java y se hacen visualizables a través de un navegador web. Estos objetos serializados se almacenan en las tablas F989998 y F989999.

Si esto ha aclarado algo a alguien, habrá valido la pena.

Un saludo y hasta pronto.

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.

Emilio Mayoral

Mucha es la documentación que en un proyecto es necesaria. A continuación os trasmito mi opinión personal sobre uno de estos documentos que se está quedando en desuso y que me parece es de gran importancia en el ciclo de desarrollo del software. Os hablo del plan de pruebas.

La finalidad del plan de pruebas es básicamente, la detección de errores a todos los niveles. Este documento debe de empezar a generarse al inicio del proyecto e irse incrementando durante el desarrollo del mismo, ya que es vital que estos errores se detecten cuanto antes para que el coste de la corrección de los mismos sea el menor posible.

¿Por qué está desapareciendo?

Todos nos hemos dado cuenta que en la actualidad, a la velocidad en la que nos vemos inmersos a la hora de desarrollar nuestro trabajo de consultoría, la documentación ha pasado al plano de lo estrictamente necesario. Un análisis funcional, un orgánico (que por funcionalidad se ha embebido por el anterior) y un cuaderno de carga por cada módulo independiente que desarrollamos, es lo que más nos estamos encontrando. Pero, ¿y un plan de pruebas?, qué ha pasado, ¿por qué ha dejado de utilizarse?

Realmente, hay que reconocer, que es un documento muy laborioso que implica la participación:

• De los funcionales, para definir los resultados los distintos módulos del proyecto y la interconexión entre ellos.
• De los técnicos, que deben de definir el resultado de cada uno de los programas que desarrollan.
• De los jefes de proyecto, que definirán los recursos, calendarios, hitos, planes de contingencia,etc.
• Usuarios, que deben dar el visto bueno a los resultados obtenidos.

 Y que además, el plan de pruebas, es un documento que estará vivo hasta el final del proyecto, por no olvidar que puede llegar a niveles de ingeniería, a mediciones de rendimiento, pruebas de estrés, de estabilidad, etc.

Tenemos que tener en cuenta, que el plan pruebas no se puede considerar un simple documento, si no que sirve de estabilizador del proyecto, al ser el nexo entre la toma de requerimientos y el producto final y que obliga a la participación de todos los miembros del equipo de proyecto, incluido por supuesto, el usuario final.

Este último punto es muy importante ya que supone la participación activa y comprometida del usuario final y obliga al cliente a aceptar, o mejor dicho, participar, en las pruebas realizadas al producto desarrollado. Esto puede ser algo tedioso ya que dependemos de la aptitud y compromiso de usuarios que en múltiples ocasiones nos pondrán pegas y provocarán mayor esfuerzo del que esperábamos, pero nos asegura que a la larga nos dará la tranquilidad necesaria para ir avanzado a siguientes hitos del proyecto sin dejar casos pendientes que nos vayan retrasando cada vez que debamos retomarlos.

Para resumir sólo identificar algunos (no todos), de los beneficios de la realización de un buen plan de pruebas:

• División de programas en módulos analizables individualmente.
• Implicación de todo el equipo en el proyecto
• Detección de errores a tiempo.
• Detección de problemáticas no tenidas en cuenta en el análisis inicial.
• Integración del usuario mediante compromisos de aceptación. 

Un saludo

Juan Sáenz de Tejada

Cada 5 – 10 años sale al mercado un nuevo acrónimo que viene a complicarnos un poco más la vida; tenemos BI, ERP, SCM, CRM y ahora viene el SaaS, es decir el Software como Servicio que se supone que nos va a cambiar a todos la visión del mundo tal y como la conocemos, pero ¿es algo realmente nuevo? ¿Nunca hasta ahora se había planteado la venta del software como un alquiler mensual, sin más?  Y además, ¿ha ayudado a que las herramientas de software estén disponibles para la pequeña y mediana empresa en España? La respuesta es no, no y no.

Ya a finales de los años 90 del siglo pasado se empezó a hablar del software en ASP (¡otro acrónimo!).  Estos Proveedores de Servicios de Aplicaciones (es decir ASP) te intentaban vender algo que parecía un alquiler de software pero que finalmente no lo era. Simplemente era un Housing de tus sistemas por el que te pasaban un importe mensual pero realmente te estaban repercutiendo los costes tecnológicos (servidores, comunicaciones, etc.) más los costes de las licencias y además te incluían unos servicios de “personalización”. Cogían este total y te lo distribuían por número de usuarios y por meses y al final te decían son XXX€  (sí, un importe de tres cifras) al mes por usuario si firmas con nosotros por 3 años!!!!!! La única ventaja que tenías era que tu empresa podía pasar a externalizar el departamento informático, siendo ese gasto además deducible financieramente. Como consecuencia sólo a empresas con un tamaño grande  y con una plantilla elevada les merecía la pena, por lo que se daba la paradoja que una  solución pensada principalmente como una herramienta para acercar el software de gestión a las Pymes era una solución más para la facturaciones por encima de 50MM€.

Si miramos la composición del tejido empresarial español vemos que:

Fuente:Solmicro

Es decir más del 96% de las empresas españolas tienen menos de 10 empleados. De ellas un tercio no tiene ningún empleado. Estas empresas normalmente cuentan con poca experiencia en ERP, sus conocimientos informáticos no suelen ser muy altos (no se puede ser vendedor, financiero e informático a la vez) y además cuentan con pocos recursos económicos para inversiones tecnológicas. La pregunta ahora es ¿cómo ayudar a estas empresas?¿Cómo proporcionarles tecnología fácil de usar, con un alcance funcional limitado y con garantía de crecimiento? ¿Cómo hacer que se despreocupen de la tecnología? Y sobretodo ¿cómo hacer todo esto a un coste muy reducido?

Para contestar a estas preguntas está el modelo SaaS.

Gracias a este modelo de negocio, cualquier empresa por pequeña que sea puede tener un conjunto de aplicaciones que le permitirán ser más eficaces, tener una información empresarial mucho mas precisa y por tanto posibilitando el competir con otras empresas más grandes. Esto se hace alquilando la solución informática por un precio mensual muy asequible. El proveedor de servicio nos ofrece todo lo necesario para empezar a trabajar y su posterior mantenimiento ya va incluido en el pago mensual que realizamos.  ¿Pero cuales son las ventajas de este modelo?

Ventajas de SaaS:

• Acceso a potentes aplicaciones a precios reducidos (CRM, ERP, Emai y Colaboración Inteligente)
• Eliminar inversiones en compra de licencias
• El cliente paga sólo por lo que usa
• Disponibilidad 24×7
• Eliminación de costes ocultos, mantenimientos, copias de seguridad etc.
• Cambiamos el concepto de inversión por “gasto predecible”
• Accesibilidad desde cualquier lugar a cualquier hora
• Disponibilidad inmediata del servicio

Fuente: Quer System

Y la pregunta del millón, ¿hay alguien que ofrezca este modelo?

Pues sí. Solmicro ha presentado en el último ECCO 2009 su estrategia en éste modelo llamado SaaS Agilizate.  Solmicro ha llegado a una alianza con el Grupo IE Soluciones Tecnológicas como proveedor de la solución técnica. Este Grupo realiza el Outsourcing informático de empresas de primer nivel y de bancos nacionales y es el responsable de proveer de la infraestructura técnica. Asimismo Solmicro ofrece por un precio razonable de menos de 60€ al mes por usuario la posibilidad de utilizar la potencia del ERP eXpertis  en las siguientes áreas:

• Facturas de Venta y Compra
• Impuestos
• Gestión de cartera de cobros y pagos
• Contabilidad General y presupuestaria

Otra de las ventajas adicionales es que se asegura el crecimiento de la empresa hacia otros modelos más tradicionales en caso de que las necesidades vayan creciendo. La pega que yo le veo es que sería necesario quizás el incorporar algunas de las funcionalidades de ventas en cuanto al seguimiento de ofertas, conversión a pedidos, gestión de los contactos y llamadas, ya que por esa parte se queda cojo pero prometen que toda la funcionalidad de CRM estará disponible en el corto plazo. Otro tema es la posibilidad de usar alguno de los 9  verticales que disponen en modo SaaS, posibilidad que a fecha de hoy se está barajando pero que no se está realizando.

Por lo demás me parece una buena oferta e interesante para todas aquellas empresas que necesitan la funcionalidad de un ERP sin necesitar tenerlo físicamente en sus oficinas.