Buenas…

Hoy OpenERP  SA ha publicado, una primera versión del memento funcional de OpenERP.

http://training-openerp.blogspot.com/2010/08/functional-memento.html

Así como cuando publicaron el memento técnico me pareció un trabajo impresionante que resumía todos los elementos técnicos de OpenERP, imprescindible como manual de consulta e incluso potente base para elaborar cualquier documentación relacionada con una formación técnica, el memento funcional me ha parecido muy incompleto, poco organizado, sin definición de procesos y sobre todo poco útil tanto para usuarios finales (que no entenderán nada) como para los consultores que ya conocen en parte la funcionalidad de la herramienta (porque no profundiza en ninguna área, ni enlaza nada con nada)

Sin ánimo de tirar por tierra el trabajo de nadie y con la pretensión siempre de realizar una crítica constructiva, bajo mi modesta opinión, es absolutamente complejo intentar resumir la funcionalidad de OpenERP en 3 páginas. Tal y como nos han dado feedback algunos de nuestros alumnos del curso funcional, incluso 40h son pocas para ver todas sus posibilidades por lo que resumir esto o sacar únicamente puntos clave del sistema es tarea harto complicada. No obstante, intentaré detallar algunos puntos que incluiría en dicho memento y perdón a todo el mundo si en ocasiones mi expresión puede parecer ruda o excesivamente crítica. No es mi intención que sea así.

En general, no habla en ninguna de las áreas de los workflows predefinidos, ni de la interrelación entre los procesos entre los distintos objetos. La gracia de OpenERP es que todo está relacionado con todo. Una de las mayores dificultades del área funcional es explicar con claridad estas interrelaciones entre las distintas áreas al cliente o futuro consultor. Por ejemplo, no vale de nada saber dar de alta un pedido, si no se conoce cuales son sus estados y qué pasa dentro del sistema cuando un pedido cambia dicho estado. Si el usuario final no entiende este funcionamiento, pasarán cosas que no entenderá y por tanto tenderá siempre a decir que no funciona. Este riesgo se minimiza si el usuario conoce a la perfección la configuración que debe realizar para que el sistema cumpla sus expectativas.

Adicionalmente falta mencionar mucha funcionalidad existente en cada una de las áreas.

CRM:

• Menciona únicamente iniciativas y oportunidades. Es decir, preventa.
• No se menciona nada de la postventa (reclamaciones, errores) y otras secciones de casos que se pueden tratar.
• No se menciona qué es un caso (cosa a veces complicada de explicar a un cliente que nunca ha usado un CRM).
• No se menciona que un cliente simplemente puede configurar una sección de casos a su manera, sin que esto tenga que estar predefinido con anterioridad según sus necesidades.
• No se menciona que CRM está estrechamente relacionado con ventas. El objetivo de la preventa es llegar a la venta. El de la postventa es resolver las posibles complicaciones con dicha venta.

Ventas:

• Da de alta un cliente, da de alta un producto, haz el pedido. Correcto, pero totalmente incompleto. El cliente y el producto son los maestros principales de OpenERP. No vale con dar de alta un cliente y dar de alta un producto. El usuario final debe conocer cada una de las solapas, cada uno de los campos de dichas fichas y saber exactamente qué está configurando. Si no sabe dar de alta estos 2 elementos principales de la aplicación, de nuevo no podrá sacar todo el provecho posible del sistema ni sabrá porqué después la operativa no concuerda con lo que él esperaba.
• Ejemplo clarísimo: Configuración de abastecimientos, tiempos de entrega, campos contables en la ficha del cliente, especificación de campos de ubicaciones recíprocas, asignación de tarifas entre otras cosas. El usuario, al menos quien da de alta clientes y productos debe conocer con todo lujo de detalles qué impacto tienen cada una de estas configuraciones en la operativa posterior.
• Adicionalmente: El flujo definido como ejemplo únicamente es válido para productos almacenables. Los pedidos que contengan productos de servicios, no necesitan calcular el “delivery cost”. Tampoco aplica incluir en este apartado un módulo que en ocasiones no es imprescindible instalar. Adicionalmente fija la factura desde pedido cuando hay múltiples formas de iniciar el tratamiento de un pedido en función de cómo se van a enviar las mercancías (si las hay) y como se van a facturar dichos envíos. En enfoque del memento es demasiado simple.
• Se mezclan proyectos y analítica con ventas. A mi parecer no aplica aquí.
• Delivery son albaranes. No aplica aquí.

Tarifas:

• Es uno de los puntos complejos de explicar. El motor tarifario de openERP es potentísimo. Una vez conocido cómo funciona agiliza mucho la gestión de tarifas y la asignación de precios pero hay que explicarlo a detalle.

Recursos Humanos:

• Faltan un montón de conceptos que se manejan en recursos humanos. Relación empleado-usuario, departamentos, contratos…
• Conceptualmente, es complicado también hacer entender porqué se asocia un producto a un empleado y cómo esto enlaza con analítica. Recomendaría que se explique un poco a más detalle.
• Adicionalmente, RRHH no sólo contempla la posibilidad de definir empleados para facturar su coste desde analítica, sino que permite gestionar mucho más: contratos, solicitudes de vacaciones, control de presencias, hojas de servicio, horas de trabajo… etc, etc, etc. además de los que ya se mencionan como horarios, curriculums, evaluaciones periódicas etc…

Proyectos:

• Inicia los pasos indicando: Crea un empleado. Es incorrecto. No es necesario crear un empleado para utilizar proyectos. Proyectos se basa en proyectos/subproyectos y tareas. Adicionalmente se pueden asignar tareas a un empleado y controlar las horas que dicho empleado invierte en realizar una tarea de un proyecto.
• Un proyecto habitualmente se asocia a una cuenta analítica, un subproyecto a una subcuenta analítica (aunque no es obligatorio que sea así)
• No se menciona que uno de los puntos principales de proyectos es la asignación de un equipo de proyecto y la asignación de tareas a las personas que forman parte de dicho equipo.
• No se mencionan los estados de los proyectos ni su workflow, ni de que existe la posibilidad de delegar tareas de un usuario a otro.
• Menciona que se pueden crear tareas automáticamente desde ventas pero no menciona en qué condiciones, ni con qué configuración de producto se generan estas tareas, ni cómo se enlaza esta tarea con un proyecto y a su vez con una cuenta analítica, de forma automática si todo está correctamente configurado.

Area financiera:

• Me parece bastante complicado definir dentro de un memento generalista la funcionalidad ofrecida por el área fiscal y financiera.
• Solo el apartado de facturación y todas sus opciones ocuparían perfectamente 3 páginas.
• No habla de vencimientos, de cierres, de informes oficiales, de cartera de efectos de cobro y pago…
• Creo que este apartado debería ser completado por cada uno de los paises y su configuración fiscal concreta y requeriría de por sí un memento funcional dedicado en exclusiva.

Compras:

• De nuevo simplifica todas las opciones posibles de definición de los procesos de compras tal cual he comentado en Ventas. Con la complejidad de que en la entrada existen mil excepciones que pueden suceder. Lo que te envían no coincide ni en número ni en precio con lo que pediste. No te envían todo, te envían de más. Todas estas situaciones son gestionables y configurables en OpenERP.
• No se menciona la trazabilidad en entrada.
• Es posible facturar tanto desde el pedido como desde el albarán.
• Es posible facturar uno único o también varios albaranes recepcionados a lo largo de un periodo de tiempo.
• Es posible recepcionar varios pedidos en un único albarán, un pedido en varios albaranes, un albarán por pedido completo. La casuistica cubierta es enorme y muy completa. No hay una única opción como se da a entender.

Almacenes:

• Inicia el proceso con “define reglas de stock mínimo”. Esto es sólo en caso de que el abastecimiento para el producto sea definido contra stock. Si los abastecimientos son contra pedido no es necesario.
• Ejecuta el scheduler: No es necesario si mrp_jit está instalado.
• Scheduler se lanza cada noche: Esto es cierto, si scheduler está activado y si su lanzamiento se ha definido a diario y si su hora de lanzamiento se ha definido por la noche.
• Hay que explicarlo muchísimo más a detalle para que se entienda y faltan muchos conceptos de explicar. Lo más básico: abastecimiento contra pedido o contra stock, en qué consisten los movimientos de doble entrada, cómo está definido y qué campos contiene un movimiento de mercancía entre ubicaciones.

Fabricación:

• Dentro de la funcionalidad ofrecida por openERP en fabricación es lo que veo más acorde a lo que hay.

Espero no haber sido demasiado dura y también espero que OpenERP SA no se tome a mal mi crítica constructiva, pero es que la parte funcional es la que más me toca y me ha dolido bastante ver un documento tan incompleto que puede dar una visión muy limitada y distorsionada de las posibilidades reales de esta gran herramienta.

Cordiales saludos!!

Ana