En estos casos, nuestra respuesta siempre es la misma. La empresa que solicita cambiar, debe realizar un análisis de todos los procesos que quieren informatizar, enfocado esencialmente a un ERP, y de ser posible, a OpenERP.
Es una buena idea utilizar un consultor externo, o, en la medida de lo posible, que sea la empresa especializada en el producto la que realice el documento.
Todas las empresas implantadoras tienen capacidad para realizar estos análisis.
Las claves para el éxito son muy claras:
Personal involucrado e integrado, desde la elaboración del análisis de requisitos, y a lo largo de todo el proceso del desarrollo, hasta la implantación y puesta en marcha.
Suficiente aportación de los usuarios. Para cubrir todas las áreas y hacerlo correctamente es necesaria el máximo posible de información por parte de todos los departamentos. Estudiar los procesos de trabajo específicos y la manera de trabajar con la documentación el programa que se utiliza actualmente también ayuda.
Especificaciones correctamente definidas: antes de comenzar, se tiene que elaborar, por escrito, un análisis detallado con todas las funcionalidades que se desean resolver antes de la implantación, y contar con la aprobación del implantador y del cliente. Un análisis con la planificación de tiempos, costes y claúsulas específicas es el mejor contrato que pueden tener ambos.
Espectativas realistas y fijadas. Hay que tener muy claro lo que se desea, definiendo al máximo posible todo lo que se espera tras marcar unos objetivos y ser concientes de los cambios y mejoras que se realizarán en la empresa, tanto en la primera fase de la implantación, como en las sucesivas. Es fundamental saber hasta donde nos limita el software elegido, y conocer los tiempos para las parametrizaciones propias.
Presencia de un consultor externo. Incluso si la empresa tiene conocimientos y un departamento informático propio para implantar el ERP. Es fundamental contar con al menos una figura externa, que no esté abituada a las formas de trabajar propias de la empresa.
Buena comunicación. Entre departamentos, con el implantador, la comunicación tiene que ser bidireccional y todas las decisiones y objetivos a establecer tienen que hacerse con el consenso de todos.
Metodología de implantación clara. Normalmente el cambio de ERP es un proceso “doloroso”, que resta tiempo e incomoda a todos los implicados. Es esencial que todos conozcan el papel que van a jugar, cómo va a influir en su rutina de trabajo. Además es clave conocer cual será el impacto negativo de la implantación en el momento del cambio.
Conclusiones:
Conociendo y trabajando sobre todas estas recomendaciones, la implantación sin duda contará con muchas más garantías de éxito.
Además, la transición será más suave, detectando y poniendo solución a todos los problemas potenciales antes de que ocurran.
También estamos recibiendo peticiones para OpenERPs “implantados”, con carencias muy graves, ya sea a nivel de desarrollo (o parametrización), a nivel de formación .
Algunas empresas, con conocimientos de programación se “atreven” con OpenERP, pero con resultados nefastos, dado que no conocen el producto.
De hecho, algunos implantadores que conocen OpenERP y sus funcionalidades, (e incluso pueden parametrizarlo y formar a sus clientes), no poseen conocimientos para desarrollar las funcionalidades requeridas, o migrar sus bases de datos, y la implantación acaba fácilmente en desastre.
Afortunadamente, este tipo de clientes que recurren a otro proveedor en estas circunstancias (pueden hacerlo sin problemas puesto que el programa es libre/GPL), no culpan al programa, y son conscientes de que los fallos se deben al implantador. Pero bueno, esto merece otro artículo para algún otro día.
Que OpenERP es un producto cada vez más conocido y difundido es un hecho. Cada vez vienen más clientes y la mayor parte de ellos ya tienen la decisión tomada, sólamente requieren encontrar un buen implantador y un presupuesto que les cuadre.
Comparativamente, es el único producto de software libre (entendiendo como software libre aquel que respeta las 4 libertades del usuario), y no tiene, por tanto, costes de licencias ni añadidos “sorpresa” para el usuario final.
Sin embargo, de vez en cuando vienen clientes que han intentado realizar una selección de ERPs libres, y OpenBravo aparece en la lista.
Sin entrar en valoraciones sobre los aspectos técnicos, número de módulos y funcionalidades de los mismos (en los que claramente OpenERP es superior, aquí una pequeña comparativa).
Lo cierto es que, tal y como menciona Cheli Pineda, uno de los implantadores con más experiencia en OpenBravo; Openbravo es una empresa de software privativo que dice que hace un ERP libre.
Los clientes potenciales acaban confundidos sobre si el software o la licencia de uso son libres (no lo son).
Y desde la empresa matriz, juegan a mezclar términos como opensource (que no es más que código abierto) con software libre.
Sin llegar a definir muy bien en qué punto se encuentra su producto.
Lo cierto es que si bien empezó como un producto de código abierto (basado en Compiere), cada vez es más restrictivo y parecido, al modelo de negocio a los desarrollos propietarios. Aspecto que los usuarios están notando.
Confiemos en que con el tiempo, y más allá de OpenERP, aparezan otros productos 100% libres que ofrezcan alternativas reales y que mejoren la oferta de productos.Y, por tanto, las opciones de los “compradores”.
Estaremos cerca de Trython, un fork de OpenERP ahora mismo todavía en pañales, pero con grandes ambiciones.
La deuda técnica es una metáfora de Ward Cunningham. La cual, describe como hacer las cosas rápido y mal va generando, con mecanismos propios de las burbujas financieras, una deuda similar a nivel técnico.
En realidad el problema no es nuevo en absoluto en el mundo del software. Se puede ver como una variante de lo que ya denominó en los años 60 como la “crisis del software”.
La deuda técnica, tiene asociado el pago de intereses, que se concretan en el esfuerzo extra necesario en el futuro por una elección rápida y mala de diseño, la cosa va creciendo y se vuelve cada vez más insostenible.
Al igual que en el mundo financiero, si te pasas, el exceso acabará en un gran desastre.
Del cual, en el mejor de los casos, se “sale”. Pero, con un costoso rescate que conlleva, una nueva deuda como lo puede ser en las TIC.
La sustitución apresurada de un sistema o conjunto de sistemas ante un problema inminente e insalvable, fruto de errores pasados, por otros nuevos que tampoco se habían examinado lo suficiente.
En otros casos el desastre a nivel informático puede ser más sutil, pero no menos importante: se puede manifestar en una estructura de costes que al haber perdido control va creciendo poco a poco hasta un punto que pone en duda el sentido de las aplicaciones en cuestión o dicho de otro modo: que la supuesta mejora de productividad que se logra con la utilización de estas aplicaciones corporativas se vuelve negativa.
El Software Libre es superior al privativo en muchos aspectos. Por norma general (siempre hay excepciones) el FLOSS es superior técnicamente . El desarrollo abierto de un programa informático posibilita la colaboración de mucha gente a lo largo y ancho del mundo. Los programas derivados de un desarrollo abierto son normalmente más robustos, flexibles y seguros. El ritmo de actualizaciones es mayor que en su alternativa privativa por lo que a priori su ciclo de renovación es más corto.
El soporte técnico es inmensamente superior. La comunidad posibilita que un usuario pueda resolver un problema por si mismo. Además, normalmente existen empresas dedicadas a ofrecer servicio técnico que pueden ser muy útiles en entornos empresariales. Por el contrario, el servicio técnico de algunos productos privativos deja mucho que desear. No tienes la posibilidad de arreglar un problema por ti mismo, tienes que acudir a la empresa que ha desarrollado el programa y confiar en ellos.
La personalización del Software Libre es simplemente brutal. Puedes contratar a un par de programadores para que adecuen un programa libre a tus exigencias. No tienes que diseñar un programa desde cero, puedes tomar el código de otros desarrollos y crear un programa a partir de éstos. En el software privativo esto es impensable. El deplorable sistema de patentes así lo demuestra.
Por norma general el software libre es más barato, aunque vuelvo a repetir que libre no es gratis. El ahorro por pago de licencias es considerable si se usa Software Libre. En una época en la que oímos todos los días “crisis económica” en los medios de comunicación, las administraciones públicas se gastan varios millones al año en el pago de licencias privativas.
El Software Libre te hace libre. Sabes lo que estás haciendo y lo que está haciendo el sistema informático. No hay nada que no puedas averiguar y no estás obligado a aceptar condiciones restrictivas para usar el sistema.
Sin embargo, las anteriores ventajas del FLOSS son condicionantes importantes pero no determinantes para mí. La razón por la que defiendo el Software Libre a capa y espada, lo que ha cambiado mi vida es el acceso libre a la información. Nunca he aprendido tantas cosas como en éste último año. No solo de informática, ya que he leído a Carl Sagan, me he quedado boquiabierto con los documentales de Brian Cox, he descubierto la cautivadora historia de Nikola Tesla, he mejorado mi inglés una barbaridad, he escuchado música buenísima en Jamendo y me he hastiado sobremanera al ver las filtraciones de WikiLeaks o el comportamiento del Gobierno Español.
Cuando ponderéis si comprar software privativo o usar software libre, no os fijéis solo en las características técnicas o el precio. Ponderad si os va a permitir aprender cosas de él, si os permite usarlo de otra forma o si al comprarlo vais a perjudicar a otra persona.
Yo lo tengo muy claro, uso software libre porque me permite estar en continua evolución y porque soy más libre. Ahora te toca a ti.
A continuación, le dejamos el enlace a nuestra web por si necesita más información, haciendo clic aquí.
Si estas interesado, o buscas un trabajo como programador de OpenERP/Software libre, debes de seguir leyendo este articulo.
Comenzaremos con una breve explicación sobre los requisitos esenciales para ocupar cada uno de los puestos que se ofertan.
Requisitos para el puesto de programador web:
A continuación, detallaremos las competencias necesarias para desempeñar correctamente el puesto de programador web.
Programadorweb: conocimientos html5, css, mysql, php. Se valorarán conocimientos sobre Joomla y Magento. El enfoque del trabajo será básicamente crear y mantener portales corporativos y tiendas virtuales. Necesario conocimiento de administración de servidores GNU/Linux e imprescindible utilizar linux a nivel de usuario. Se valorarán conocimientos de Django y Python.
Requisitos para el puesto de programador junior:
A continuación, detallaremos las capacidades necesarias para el puesto de programador junior.
Programador junior: para incorporar a equipo de trabajo OpenERP. Necesario conocimiento en el desarrollo de aplicaciones orientadas a objetos, especialmente Python. Se valorarán conocimientos de OpenObject, experiencia con otros ERPs, participación en comunidades de software libre (traducción, localización…) Herramientas colaborativas libres y de nuevo, utilizar linux como sistema operativo a nivel de usuario.
Se ofrece incorporación inmediata en Domatix. El trabajo se realizará en nuestras oficinas, en horario comercial, con una dinámica flexible y variable.
La retribución económica será acorde con los conocimientos y experiencia del candidato.
Interesados pueden enviar el CV a info(a)domatix(punto)com
Ya han actualizado http://doc.openerp.com a la versión 6, parece que han ampliado algunos puntos… habrá que verlo a fondo.A continuación trataremos algunos aspectos sobre la Documentación de OpenERP V6.
Pero lo que más me ha llamado la atención es que por fin han añadido otros idiomas. Si miras en la parte superior derecha hay un enlace para ver la documentación de la versión 5 y otro para cambiar de idioma.
Entre los idiomas disponibles está el español, pero en realidad a primera vista lo único que hay traducido es el prefacio y poco mas, que traduje cuando hice el manual para colaborar en la traducción.
