ERP 2007... Adquirir o Desarrollar?

  • Escrito por: Jorge Tsuboyama
  • Publicado: diciembre 27 2007



La pregunta más frequente durante este 2007... ERP adquirir o desarrollar?... ahí esta el dilema.

Muchas organizaciones en Latinoamérica optan por desarrollar sistemas ERP a medida. La causa de esta desición toma como premisa que el costo de desarrollar es menor al de adquirir... pero es esto cierto???

El mercado laboral Latinoamericano (programadores, analistas, jefe de proyectos) tiene una realidad y contexto que, en muchas ocasiones, justifica sueldos menores en comparación a otros mercados como Estados Unidos, Canadá o en Europa. Como consecuencia, organizaciones perciben al costo de desarrollar inferior al de adquirir, pero estamos tomando en cuenta la película completa? Analicemos lo que implica un desarrollo a medida...



1. Defina sus requerimientos. Esta es una actividad crítica para el éxito del proyecto donde se deben detallar las funciones y características del sistema y los beneficios que se obtienen de su aplicación. El gran desafío es definir dichas funciones de manera correcta desde el inicio... pero, cuál es la manera correcta?... lo que los usuarios exigen?, lo que los analistas especifican?, lo que el ejecutivo desea?, o lo que los programadores entendieron?... algo importante que debe considerar es que no todos pueden definir requerimientos de manera precisa, concreta y efectiva. Un buen punto de partida es el estándar UML (Unified Modeling Language) que simplifica/organiza el proceso de diseño. Si su equipo se familiariza con este estándar al menos se asegura que todos hablen el mismo lenguaje.

2. Defina el Road Map; dividir es conquistar... son palabras célebres que se aplican tanto en implantación ERP como desarrollo de software. El objetivo es definir un "Road Map" donde se agrupan los requerimientos por módulo y nivel de importancia (beneficio) permitiendo definir las etapas que tendrá el desarrollo. Cada etapa debe contener un conjunto de requerimientos que entregan un beneficio para la organización y permita a los usuarios utilizar partes del sistema mientras prosigue el desarrollo de la siguiente. Esta estrategia permite realizar ciclos de prueba y error, que normalmente son varios, de ahí que se tengan numerosas versiones del sistema. Si opta por esta estrategia le sugerimos analizar el uso de herramientas para la gestión de requerimientos como Rational Requisite Pro de IBM, TopTeam de TechnoSolutions, Analyst Real Team System de Goda Software. La gestión de requerimientos incluye definición de prioridades, gestión del road map, gestión de las versiones y algo muy importante denominado la gestión de cambios. Y, son los cambios de requerimientos que pueden convertir su proyecto en una pesadilla. Que significa esto? que en ocasiones los usuarios cambian de parecer y, en consecuencia, cambian los requerimientos lo que nos lleva al siguiente punto.

3. Mejores Prácticas. Muchas de las soluciones ERP en el mercado incluyen "Mejores Prácticas" de funciones y características de software. Es decir, funcionalidad que le permite a los usuarios realizar sus funciones eficiente y efectivamente. Durante una implementación ERP, la aplicación de estas "Mejores Prácticas" posibilita encontrar mejoras en la operación. Estas mejoras se trasladan en beneficios que los proveedores de soluciones ERP ya han encontrado a través de su experiencia e integrado en sus soluciones. Si opta por desarrollar o mantener su sistema ERP a medida hágase la siguiente pregunta: Quién es la fuente de Mejores Prácticas en su organización? Si tiene requerimientos cambiantes y su equipo estima que por cada paso adelante dan dos hacia atrás entonces debería considerar analizar soluciones ERP existentes para al menos conocer como éstas han atacado el problema.

4. Defina el ambiente de desarrollo. Tiene los requerimientos, el road map y ha revisado las mejores prácticas, ahora debe definir el ambiente de desarrollo, es decir, la plataforma y lenguaje de programación que debe utilizar. En específico esto usualmente lo puede definir el Arquitecto (Software Architect). Éste toma en consideración el número de usuarios y transacciones, rendimiento deseado, tecnología existente en su mercado y organización, experiencia del mercado laboral, cultura corporativa y propone los diferentes componentes, metodologías y herramientas ha utilizar. De esta propuesta dependerá la escalabilidad del sistema, si es posible encontrar personal preparado, el tiempo de desarrollo... obviamente seleccionar tecnologías muy modernas u obsoletas no es algo ideal puesto que el costo de entrenar al personal puede afectar al costo del desarrollo o incertidumbre del proyecto.

Hemos expuesto puntos que debe considerar antes de inciar el desarrollo de un sistema a medida y como afectan éstos al éxito o fracaso del proyecto. Ahora que la película completa ha sido expuesta le será posible calcular el verdadero costo total de propiedad o TCO (Total Cost of Ownership):

a) El costo de desarrollo debe incluir entrenamiento del personal en metodologías y estándares adecuados que aseguren el éxito de su proyecto.

b) El costo de desarrollo debe incluir las herramientas adecuadas para la gestión del mismo; a menos claro que su equipo este dispuesto ha asumir el riesgo de no usarlas.

c) El costo de desarrollo debe incluir el ciclo de vida completo del proyecto. En promedio, el desarrollo de un sistema ERP a medida tiene un ciclo de vida de 7 a 8 años tomando en cuenta avances y adopción de nueva tecnología, crecimiento del negocio y alcanzar un retorno de inversión o ROI (Return On Investment) positivo. Usualmente se considera que el costo inicial del primer año representa sólo el 30% de la inversión total. Por lo tanto, el costo del primer año lo debe multiplicar por 3.33 para poder estimar el costo del ciclo de vida completo del proyecto.

Una vez que cubra los puntos descritos anteriormente podrá comparar de igual a igual el desarrollo de un ERP a medida versus adquirir una solución ERP existente en el mercado. Desarrolar una solución ERP a medida es una opción válida siempre y cuando su equipo conozca el TCO y haya respondido también a las siguientes preguntas:

Existen soluciones ERP que cubren las necesidades de la empresa? Si no las hay, ha logrado su equipo cuantificar las diferencias, fortalezas y debilidades? Requiere su negocio un conjunto de funciones tan específico que no existe una solución ERP en el mercado para sus requerimientos? Tiene la necesidad de desarrollar funciones de software a medida que le entreguen una ventaja competitiva al negocio?

Y que hay de las ERP de código abierto (Open Source)? La película cambia un poco... aunque será otro tema ha tratar en una próxima entrada al blog.

Por el momento les deseamos unas Felices Navidad y un Feliz Año 2008!
 
comments powered by Disqus