ICTs and development in practice
POVERTY REDUCTION Empowerment
La orientación de esta metodología se encuadra en el ámbito de las de aplicación específica a los sistemas ERP. Constituye un modelo básico para los procesos de selección de software, destacando dos conceptos sobre los que argumenta todo el contenido:
• Exigencia de requisitos y características mínimas. • Procedimiento de selección de candidatos.
El primer concepto agrupa a las tareas incluidas en la Fase de definición y consiste en la declaración formal y documentada de los requisitos exigibles y comprobables del software así como de las condiciones a cumplir por los proveedores candidatos para este proceso. El objetivo es garantizar un umbral de calidad mínimo desde el inicio y a lo largo de todo el proyecto de implementación.
Esta declaración se articulará en torno a los siguientes puntos: 1) En la etapa de selección previa, se considerarán sólo
33 a la terminología propia del sector del que se trate y similitud de procesos con la organización. Cada sistema se orienta hacia un sector determinado, algunos, incluso, evolucionan desde la orientación a la especialización, lo que en muchos casos supone ofertas de módulos específicos para un determinado sector productivo junto a las funcionalidades comunes, lo que exigirá un esfuerzo adicional de valoración.
2) En esta etapa preliminar del proceso, se analiza si el sistema incluye herramientas de usuario para tareas simples de programación, sin que sea necesaria la intervención de personal especialista ni de mantenimiento del sistema. En general, estas herramientas abarcan temas como:
1. Elaboración de material para formación de usuarios. 2. Facilitar la elaboración de procedimientos de usuario. 3. Añadir textos de ayuda en menús o pantallas.
4. Elaboración de documentación e información del proceso de implementación.
5. Programación de interfaces de conversión de datos.
3) Analizar la posibilidad de configuración que ofrece el software por medio de parametrización, sin necesidad de modificar código fuente ni realizar programación. Toda modificación en el código fuente de una aplicación estándar acorta su ciclo de vida y, por lo tanto, es un factor que encarece el proyecto. Si algún proceso o función fundamental del negocio no estuviera incluida en la aplicación estándar, el incumplimiento de esta exigencia la elimina como opción candidata.
4) El software ha de permitir diferentes modos o secuencia de acciones para realizar procesos, como parte de las opciones de reingeniería de negocio.
5) Facilidad de integración con otros sistemas, tanto propios como de otros desarrolladores, con programas de interfaz entre aplicaciones (API´s: Application Programs Interface), cuyo diseño está orientado a facilitar la interoperatibilidad entre aplicaciones. Se trata de una exigencia cada vez más demandada, a pesar de las ventajas que presenta la
implantación de un sistema integrado o Suite (de un solo desarrollador), frente a las soluciones singulares o Best-of-bred (cada función es ofrecida por fabricante individual), generalmente preferidas en temas tecnológicamente avanzados, como son el comercio electrónico, la gestión de relaciones con clientes, la extensión de la cadena de suministro, la planificación y programación avanzada, etc. 6) Se valorará si la aplicación en su versión estándar incluye
módulos de preintegración con las soluciones líderes en temas específicos y de última generación. No se trata de comprobar una integración universal, con todos los sistemas, sino valorar esa preintegración como una medida de calidad del software, diferenciándola de una estrategia de mantenimiento de cuota de mercado.
7) Además de esa preintegración y desarrollo de herramientas de programación que faciliten la interoperatibilidad entre sistemas, se valorará la oferta de herramientas de intercambio de información, a través de Internet, usando datos en formato XML (eXtended Making Lenguage), que dan acceso a nuevas posibilidades de intercambio sin necesidad de programación adicional.
8) El software ha de estar totalmente desarrollado y no se deben aceptar ofertas con módulos en desarrollo que comprometan plazos y objetivos. Se trata de comprobaciones muy complejas que sólo expertos pueden detectar, porque los fallos en el funcionamiento de un módulo sólo se ponen de manifiesto en un marco de circunstancias muy específico, que no se considera en fase de selección.
9) Se recomienda asegurar la ausencia de errores de diseño, programación y la estabilidad en el funcionamiento, definiéndola como el periodo de tiempo entre paradas del sistema, provocadas por un mal funcionamiento del software. Se exigirá un valor muy elevado, de carácter no cíclico y de naturaleza extraordinaria.
10) Se garantizará en fase contractual la corrección de errores en una nueva versión (Release) de la
35 aplicación. El elemento de comprobación de este requisito se sitúa en las referencias disponibles e independientes sobre producto y proveedor.
11) La oferta del software incluirá opciones de configuración estándar aplicable al sector económico en el que se ubica la empresa, sirviendo como opción de arranque inicial, que, sin tratarse del procedimiento más aconsejable a seguir en la implantación de un sistema ERP, proporciona una sensación de seguridad de los responsables de la implementación frente a terceros.
En resumen, se trata de tareas cuyos contenidos presentan gran dificultad para ser detectados, evaluados y cuantificados en fase preliminar, pero, por su enorme incidencia en el resto del proceso, se destaca su importancia y se recomienda su desarrollo y cumplimiento.
Recomienda, Murrell, investigar referencias de instalaciones del software, con antigüedad mínima de 1 año cuyas conclusiones, sin ser determinantes, resultan de gran utilidad.
Las exigencias sobre las empresas suministradoras candidatas se organizan en torno a los siguientes aspectos:
1) Detalle de las previsiones de mejora o desarrollo del producto software que nos proporciona un indicador de la importancia y futuro del producto según el propio fabricante. El detalle de estas previsiones ha de incluir información sobre:
1. Nuevos módulos en desarrollo. 2. Tecnologías a aplicar.
3. Inversión en (I+D) / año.
4. Sector industrial objetivo del fabricante.
2) Detalle de los módulos identificados con un determinado sector económico, por tratarse de desarrollos orientados para satisfacer necesidades específicas.
3) Estimaciones de frecuencia de actualización del producto. Detalle del cumplimiento y efectividad de las previsiones de actualización en los dos o tres años anteriores.
4) Evaluación de las previsiones futuras del proveedor, para evaluar las probabilidades de presencia en el mercado en un
horizonte temporal de 5 años. Análisis de la estabilidad financiera como estimación de las probabilidades de fusión o expulsión del mercado.
5) Análisis de la empresa a través de sus datos más significativos: a) Nº de Empleados.
b) Beneficios.
c) Evolución de ingresos y ventas. d) Estabilidad del equipo directivo. e) Accionistas mayoritarios.
6) Oferta de soporte y servicios para: a) Definición y rediseño de procesos. b) Configuración del producto.
c) Mantenimiento del sistema.
d) Metodologías de implementación. 7) Oferta de modalidades de soporte:
1. Canal de consulta y resolución de problemas (Hot line). 2. Elaboración de documentación.
3. Herramientas y ayudas.
4. Formación específica "a medida".
5. Conversión de datos y configuración de procesos. 6. Documentación de actividades de configuración. 7. Procesos de implementación:
1. Técnicos. 2. Funcionalidad.
3. Aseguramiento de la calidad. 4. Gestión del proyecto.
8) Por último, considerar las impresiones derivadas de la relación con el personal en esta fase de carácter comercial, que, aunque de carácter subjetivo, orientan sobre las condiciones futuras de convivencia y trabajo en común, que sin duda constituirán un factor importante en la consecución del éxito del proyecto.
El otro concepto básico que destaca la exposición de Murrell se articula en torno al proceso de selección de candidatos, describiendo tres alternativas, cada una de las cuales se materializa en un conjunto diferenciado de actividades.
37 1) Alternativa 1: Selección inicial de múltiples candidatos.
Consiste en una investigación de mercado para identificar el mayor número de aplicaciones que puedan satisfacer a grosso modo las exigencias y requisitos característicos del sector productivo en el que se ubica la organización que va a adquirir el sistema.
El resultado de esta investigación es una pre-selección de aplicaciones, generalmente extensa (20 o más candidatos), de manera que se aplica un primer filtro en la selección de candidatos.
Suele aplicarse en el sector público, por exigencias de tipo legal o reglamentario, o bien en actividades para las que todavía no se dispone de un conocimiento preciso respecto a posibilidades, requerimientos o exigencias.
Los sistemas ERP presentan una antigüedad en oferta comercial superior a 5 años y se consideran aplicaciones maduras para las que el mercado ya ha efectuado su propia selección.
2) Alternativa 2: Selección cualificada de candidatos.
Esta alternativa parte de una pre-selección de aplicaciones candidatas, líderes en el mercado del software de sistemas ERP, que se considera suficiente para garantizar una correcta elección final, centrándose el proceso de selección en profundizar en el conocimiento individual para determinar las características de cada una de ellas.
En principio, se acepta que las aplicaciones ejecutan satisfactoriamente las funcionalidades tradicionales. Esto se comprobará en una fase final, pero sólo para la aplicación cuya adquisición se recomienda.
El proceso de selección consiste en detectar las diferencias o funcionalidades que son específicas de cada una, determinando la influencia que han de tener en la ejecución de los procesos y en las oportunidades que su uso puede ofrecer como ventajas competitivas frente a terceros. El buen desarrollo de esas tareas requiere contar con expertos con
conocimiento de sistemas ERP, así como en procesos de implementación.
3) Alternativa 3: Análisis de candidato único. Prueba y confirmación de conceptos.
Se aplica cuando se sabe a priori cuál es la aplicación más apropiada y pretende confirmar su idoneidad antes de proceder a la firma del contrato de adquisición o licencia de uso.
Cuando existe una aplicación líder de uso generalizado en el sector, que encaja en funcionalidades, la detección de candidatos se reduce a un único posible ofertante.
Sin embargo, no se deben subestimar los beneficios derivados de las tareas de un proceso de selección con múltiples candidatos que permiten un mejor conocimiento del sistema, que implica ventajas materiales y temporales críticas a lo largo del proceso de implementación.
El proceso consiste en experimentar con un proyecto piloto en el que el usuario tiene acceso al software de forma real para la toma inicial de contacto con el sistema, así como para la elaboración de escenarios a medida que suelen desarrollarse durante un periodo de cuatro o cinco semanas. El resultado del proceso, más que una selección, es una comprobación de funcionamiento, además de un entrenamiento operativo de la aplicación, que, con toda seguridad, ha de tener una influencia positiva en el proceso de implementación posterior.
Como resultado del proceso, se obtiene una buena comprensión del sistema, especificaciones de necesidades, conocimiento de las carencias de la versión del sistema que estamos estudiando y la enumeración de los procesos que hemos de implementar.
Se trata de una alternativa que simplifica el proceso de evaluación, considerando sólo la alternativa de apto frente a la de no apto.
39 En la elección de alternativa influyen multitud de factores cuya cuantificación orientará el proceso de decisión y con carácter orientativo citaremos los siguientes:
1. Normativa de la organización respecto a compras y adquisiciones.
2. Autonomía del equipo de selección.
3. Experiencia y conocimientos del equipo de selección.
4. Grado de complejidad de las exigencias técnicas y funcionales.
5. Disponibilidad y acceso a: 1. Documentación. 2. Referencias.
3. Experiencias de implementación de sistemas informáticos.
En los primeros años de la década de los 90, la alternativa seguida para la selección de candidatos a suministrar aplicaciones ERP era la de múltiples candidatos. En la actualidad, al tratarse de paquetes de amplia divulgación y sobre los que hay numerosas referencias, se considera más adecuado el modelo de análisis reducido de candidatos, aceptando que ello implica:
1) Los paquetes de software, generalmente, hacen frente a las necesidades planteadas por la empresa en un porcentaje que oscila entre el 80% y 90%.
2) Dentro de las aplicaciones comercializadas, no suele haber más de seis líderes o aplicaciones reconocidas como idóneas para cada sector.
3) El proceso de selección es conveniente que se centre en torno a esos líderes reconocidos, que pueden garantizar, hasta donde es posible, su permanencia en el mercado y, con ello, su evolución y soporte.
Tales implicaciones afectan a los módulos tradicionales pero no a las nuevas funcionalidades que constituyen un mercado emergente con características diferentes.
Para estas nuevas funcionalidades, muchas veces no es posible considerar la opción de selección reducida, al ser muy escasa la oferta, por lo que la única opción disponible será la de candidato único, convirtiéndose en un proceso de prueba y formación más que de selección de candidatos.