Guía Implantación ERP

Escola Tècnica Superior d’Enginyeria Informàtica
Universitat Politècnica de València
GUÍA PARA LA IMPLANTACIÓN DE UN SISTEMA

DE INFORMACIÓN BASADO EN SOFTWARE ERP
Trabajo Fin de Grado*
Grado en Ingeniería Informática
Autor: Francisco Javier Martínez Nueda
Tutora: Eva María Cutanda García
2017-2018
* La presente copia incorpora un título más acorde a los objetivos,

así como corrección de erratas respecto al original publicado en Riunet
GUÍA PARA LA IMPLANTACIÓN DE UN SISTEMA DE INFORMACIÓN BASADO EN
SOFTWARE ERP
Con mi agradecimiento a Julia.
2
SOFTWARE ERP
Resumen
El presente estudio compone un recorrido por los aspectos más relevantes del proceso de
implantación de un ERP. Fase inicial: motivación, requerimientos, selección del software,
planificación de recursos y análisis de costes. Fase implantación: análisis funcional,
establecimiento de fases del proyecto, identificación y modelado de flujos de trabajo, pruebas
piloto, conversión de datos de otros sistemas, documentos e información de salida y
planificación de reemplazo del sistema anterior. Ciclo de mantenimiento: procesos de mejora
continua y gestión de cambios. Aspectos transversales: gestión de las personas, usuarios clave,
liderazgo y gestión de incidencias.
Palabras clave: Sistema de información, ERP, gestión de proyectos, procesos industriales,

logística, expediciones, compras, reaprovisionamiento, fabricación, gestión del cambio.
Abstract
This study intends to be a review of the most relevant aspects of the ERP implementation
process. Initial phase: motivation, requirements, software selection, resource planning and cost
analysis. Implementation phase: functional analysis, determine project phases, identification and
modelling of workflows, pilot tests, conversion of data from other systems, documents and
other output information and replacement planning of the previous system. Maintenance cycle:
steady improvement processes and change management. Transversal themes: human resources
management, key users, leadership and incident management.
Keywords: Information system, ERP, project management, industrial processes,

logistics, shipping, purchasing, restocking, manufacturing, change management.
3
SOFTWARE ERP
Tabla de contenidos
Introducción........................................................................................................................ 9
Antecedentes. ..................................................................................................................... 9
¿Qué es un ERP?................................................................................................................. 9
Ámbito de análisis y metodología del estudio. ......................................................................10
Objetivos. ..........................................................................................................................10
CAPÍTULO I. ETAPA INICIAL. ........................................................................................ 11
1. Justificación del proyecto. ........................................................................................... 11
1.1. Adaptación. ............................................................................................................ 11
1.2. La dimensión personal. ............................................................................................ 11
1.3. Obsolescencia o inadecuación. ................................................................................. 12
2. Toma de requerimientos general. ................................................................................. 13
2.1. Tipología de las empresas. ....................................................................................... 13
2.2. Identificación de las áreas afectadas por el proyecto. ................................................. 13
2.3. Detección de restricciones importantes. .................................................................... 14
3. Evaluación de soluciones. ............................................................................................ 15
3.1. Preselección. ........................................................................................................... 15
3.2. Sector. .................................................................................................................... 15
3.3. Tipo de clientes. ...................................................................................................... 15
3.4. Ámbito geográfico. ................................................................................................. 15
3.5. Sedes. ..................................................................................................................... 16
3.6. Presupuesto............................................................................................................. 16
3.7. Origen. ................................................................................................................... 17
3.8. Funcionalidad. ........................................................................................................ 17
3.9. Aproximación cuantitativa de una clasificación cualitativa. ........................................ 19
3.9.1. Base instalada. .................................................................................................... 19
3.9.2. Vertical vs horizontal. .......................................................................................... 19
3.9.3. Facilidad de adaptación. ....................................................................................... 19
3.9.4. Facilidad de configuración. ................................................................................. 20
3.9.5. Coste total de propiedad. ..................................................................................... 20
3.9.6. Usabilidad y curva de aprendizaje. ....................................................................... 20
3.9.7. Usuarios.............................................................................................................. 21
3.9.8. Accesibilidad. ..................................................................................................... 21
4
SOFTWARE ERP
3.9.9. Tecnología que utiliza y uso de estándares. ........................................................... 21

3.9.10. Proyección futura o roadmap del ERP. .................................................................. 21
4. Evaluación de proveedores. ........................................................................................ 23
4.1. Fabricante del software. .......................................................................................... 23
4.1.1. Estabilidad y trayectoria. ..................................................................................... 23
4.1.2. Tamaño.............................................................................................................. 23
4.1.3. Tecnología. ........................................................................................................ 23
4.1.4. Modelo de comercialización. ............................................................................... 23
4.1.5. Garantía. ............................................................................................................ 24
4.2. Consultora de implantación. .................................................................................... 25
4.2.1. Tamaño.............................................................................................................. 25
4.2.2. Experiencia. ....................................................................................................... 25
4.2.3. Liderazgo. .......................................................................................................... 25
4.2.4. Soporte y comunicación. ..................................................................................... 25
4.2.5. Salud financiera. ................................................................................................. 25
5. Planificación de recursos humanos y materiales. .......................................................... 26
5.1. Asignación de roles, responsabilidades y motivación de usuarios clave. ..................... 26
5.1.1. Líder procedente de plantilla. .............................................................................. 26
5.1.2. Líder nuevo en la empresa. .................................................................................. 26
5.1.3. Inicio del proyecto. ............................................................................................. 26
5.1.4. Usuarios clave. ....................................................................................................27
5.1.5. Recursos materiales. ............................................................................................27
6. Análisis de costes....................................................................................................... 28
6.1. Coste total de propiedad. ........................................................................................ 28
6.2. Coste de oportunidad. ............................................................................................. 29
7. Análisis de viabilidad del proyecto. .............................................................................. 31
7.1. Operativa. ............................................................................................................... 31
7.2. Técnica................................................................................................................... 31
7.3. Económica y financiera. .......................................................................................... 31
CAPÍTULO II. FASE IMPLANTACIÓN. .......................................................................... 32
1. Áreas de gestión habituales en las empresas. ................................................................ 32
1.1. Ingeniería de producto. ........................................................................................... 32
1.2. Ventas. .................................................................................................................. 34
1.2.1. Gestión comercial. .............................................................................................. 34
1.2.2. Fuerza de ventas. ................................................................................................ 35
1.3. Finanzas. ............................................................................................................... 36
5
SOFTWARE ERP
1.3.1. Contabilidad financiera. ...................................................................................... 36

1.3.2. Contabilidad analítica. ........................................................................................ 36
1.3.3. Facturación. ........................................................................................................37
1.3.4. Cobros, pagos, vencimientos, remesas...................................................................37
1.3.5. Tesorería, previsión de necesidades y financiación. ................................................37
1.3.6. Gestión del riesgo. .............................................................................................. 38
1.3.7. Conciliación bancaria. ........................................................................................ 38
1.3.8. Amortizaciones. ................................................................................................. 38
1.3.9. Impuestos. ......................................................................................................... 39
1.4. Recursos humanos.................................................................................................. 39
1.5. Producción............................................................................................................. 40
1.6. Logística................................................................................................................ 42
1.7. Almacén. ............................................................................................................... 42
1.8. Compras. ............................................................................................................... 43
1.8.1. Acreedores. ........................................................................................................ 43
1.8.2. Proveedores. ...................................................................................................... 43
1.9. Dirección. .............................................................................................................. 44
2. Evaluación de requerimientos. .................................................................................... 46
2.1. Entrevistas con los usuarios clave de cada área. ........................................................ 46
2.2. Revisión de procedimientos. ................................................................................... 46
2.3. Interdependencias, cuellos de botella y secuencialidad. ..............................................47
3. Pruebas. .................................................................................................................... 48
3.1. Pruebas unitarias. ................................................................................................... 48
3.2. Pruebas funcionales. ............................................................................................... 49
3.3. Pruebas de carga y pruebas de estrés. ........................................................................ 51
4. Conversión de datos del SI antiguo. ............................................................................ 52
4.1. Clasificación de datos a convertir. ........................................................................... 52
4.1.1. Clasificación de datos por naturaleza. .................................................................. 52
4.1.2. Clasificación de datos por nivel de complejidad. ................................................... 53
4.1.3. Temporización de las conversiones. ..................................................................... 53
5. Planificación del abandono del SI antiguo.................................................................... 54
5.1. Establecimiento de fases de implantación................................................................. 54
6. Análisis de documentos que hay que implementar: nuevos y versiones nuevas de otros ya
existentes. ......................................................................................................................... 56
6.1. Evolución de las salidas (output) del sistema de información. .................................... 56
6.2. Sustitución de los documentos existentes. ................................................................. 57
6
SOFTWARE ERP
7. Interfaces para integrar con otros sistemas (de entrada y de salida). ............................... 58
7.1. Sistemas de información complementarios en la empresa. ......................................... 58
7.2. Integración con sistemas de terceros. ....................................................................... 59
CAPÍTULO III. LOS ASPECTOS TRANSVERSALES DURANTE UNA IMPLANTACIÓN.
........................................................................................................................................ 60
1. Mantenimiento y mejora continua. .............................................................................. 60
1.1. Mantenimiento. ...................................................................................................... 60
1.2. Mejora continua. .................................................................................................... 60
2. Gestión del cambio y desarrollo de la motivación. ........................................................ 62
2.1. Papel de la Dirección y del Director de Proyecto. ..................................................... 63
2.1.1. Aptitudes del líder del proyecto. .......................................................................... 64
2.1.2. Funciones del líder del proyecto .......................................................................... 64
2.1.3. Retos para el líder del proyecto............................................................................ 65
2.1.3.1. Exceso de información. ................................................................................... 65
2.1.3.2. Sobrecarga de tareas........................................................................................ 65
2.1.3.3. Colaboración vs competencia........................................................................... 65
3. Gestión y resolución de incidencias durante la ejecución del proyecto. ...........................67
3.1. Errores de análisis. ..................................................................................................67
3.2. Errores de alcance. ..................................................................................................67
3.3. Costes ocultos. ....................................................................................................... 68
3.4. Errores en la asignación de recursos. ....................................................................... 68
3.5. Falsas objeciones. .................................................................................................. 69
3.6. Saboteadores. ......................................................................................................... 69
4. Propuestas de mejora: gestión ágil................................................................................ 71
5. Conclusiones. .............................................................................................................72
Bibliografía ....................................................................................................................... 75
Notas.................................................................................................................................76
7
SOFTWARE ERP
Índice de ilustraciones y tablas

Tabla 1. Comparativa de soluciones por origen............................................................... 17
Recuadro 1. Amortización vs alquiler. ............................................................................ 28
Tabla 2. Ejemplo de ingeniería sobrecargada con información irrelevante. ................. 33
Tabla 3. Ejemplo de ingeniería ajustada a la información relevante. ............................ 33
Ilustración 1. Flujo de trabajo de ejemplo. ..................................................................... 40
Ilustración 2. Ejemplo de diagrama de Gantt .................................................................47
Recuadro 2. Posponer las modificaciones del estándar. ................................................ 49
Ilustración 3. Ejemplo de proceso de ventas. ................................................................. 50
Recuadro 3. Prueba del software. .................................................................................... 51
Recuadro 4. Replantearse los viejos procedimientos de trabajo..................................... 57
8
SOFTWARE ERP
Introducción.
Antecedentes.
Desde los tiempos de la Segunda Guerra Mundial el gobierno americano utilizó aplicaciones
informáticas para la gestión logística militar.
En la década de 1960 se introdujo el concepto de planificación de reaprovisionamiento

(MRP por sus siglas en inglés). Paulatinamente se fueron añadiendo nuevas funciones e
integrándolas con estas aplicaciones, como la gestión de compras y ventas, y sus transacciones
asociadas de pagos y cobros.
En la década de 1980 se añade MRP II, que proporciona una planificación más flexible y
realista con el entorno variable de las empresas, con limitaciones de capacidad, prioridades y
planificación cambiantes día a día y gestión de restricciones variables de desabastecimiento de
recursos.
En la década de 1990 los sistemas de información evolucionan de manera que se unifican en

un único sistema de información e interfaces de usuario los procesos de negocio más críticos
para la operación de las empresas. Este es el concepto clave de ERP1, como sistema de gestión
integral de la empresa. Comienzan también a ser habituales los sistemas capaces de interactuar e
integrarse con otros sistemas periféricos y con otros sistemas de información de terceros
(clientes, proveedores). Se extiende paulatinamente a la gestión de la cadena de suministro
(SCM por sus siglas en inglés).
Desde comienzos del nuevo milenio se extienden las capacidades de los ERP al concepto
más amplio de e-business, entendido como el aprovechamiento de la progresiva madurez de la
conectividad segura utilizando redes inseguras como Internet y su integración con los procesos
de negocio. Entre los ámbitos destacados de dicha integración encontramos el modelo de
gestión comercial CRM, el comercio electrónico, el intercambio electrónico de datos (EDI por
sus siglas en inglés) o la gestión digital de la logística (e-logistics).
¿Qué es un ERP?
Por simplicidad, denominaremos en adelante ERP al conjunto de aplicaciones informáticas
que soporta el sistema de información habitualmente más relevante en una organización, en
nuestro caso una empresa industrial. El ERP modela procesos de negocio interrelacionados
entre sí que involucran a múltiples departamentos y que pueden facilitar a la organización
alcanzar sus objetivos. La competitividad de la empresa está condicionada a múltiples factores
relacionados con este sistema de información, como, por ejemplo: la agilidad de imputación de
datos; el grado de sofisticación de los procesos; si los procesos modelados en el ERP están
ajustados en mayor o menor medida a cómo los llevan a cabo en realidad las personas
involucradas; o la flexibilidad del sistema de información para adaptarse al entorno siempre
cambiante de la organización. Por estos motivos, las empresas invierten cuantiosos recursos en
implantar sistemas de información que les permitan alcanzar cotas altas de eficiencia y, por
ende, mejorar su competitividad.
Es habitual que el conjunto de aplicaciones que conforman el ERP se amplíe y ajuste a las
necesidades de las empresas con el paso del tiempo. También puede ocurrir que este
9
SOFTWARE ERP
“ecosistema” no se adapte adecuadamente, debido a factores como limitaciones de la

arquitectura del software, obsolescencia tecnológica o empresas que cambian con demasiada
rapidez. En estos casos surge la necesidad de cambio.
El cambio de un ERP es un proceso que requiere grandes esfuerzos por parte de la

organización, humanos y económicos. Los errores en la ejecución de este cambio pueden tener
consecuencias catastróficas y hasta en el peor de los casos terminar con la organización.
Ámbito de análisis y metodología del estudio.

Este Trabajo de Fin de Grado ofrece un recorrido por algunos de los aspectos relevantes del
proceso de implantación de un ERP en las empresas industriales. En la fase inicial, con el
establecimiento del equipo, la asignación de recursos y la selección del software. En la etapa de
implantación se hará un repaso por la evaluación de requerimientos, las pruebas piloto y las
pruebas de integración, las conversiones de datos anteriores y la planificación operativa del
cambio. Se tratarán el mantenimiento y mejora continua. Por último, se tratarán aspectos
transversales como la gestión de las personas y la gestión de incidencias.
La metodología empleada es la consulta de las referencias bibliográficas y la recopilación y

organización de datos basados en la experiencia profesional del autor. Además, se ha
enriquecido con información obtenida a lo largo de un año y medio a partir de una serie de
consultas puntuales sobre detalles de determinadas áreas, realizadas de manera informal con
colegas que se dedican a la consultoría funcional de implantación de sistemas de información.
Objetivos.
El presente estudio pretende servir de guía genérica en los proyectos de implantación de un
ERP. Objetivos específicos:
• Enumerar los recursos materiales necesarios.
• Establecer una relación de diligencias debidas previas al comienzo de la implantación.
• Describir las cualidades del equipo humano que aportarán valor.
• Remarcar aquellos aspectos concretos de su desarrollo a los que haya que prestar
atención especial por su complejidad.
• Describir una serie de buenas prácticas que ayuden a suavizar el impacto del cambio en
la organización.
10
SOFTWARE ERP
CAPÍTULO I. ETAPA INICIAL.

1. Justificación del proyecto.
1.1. Adaptación.
La actividad en las empresas cambia con el transcurso del tiempo. Este cambio puede ser
más rápido o más lento dependiendo de múltiples factores:
- Adaptación reactiva a los cambios en los mercados.

- Voluntad de sus dirigentes de explorar nuevas oportunidades.
- Ejecución de planes estratégicos encaminados a expansión o contracción.
- Ejecución de planes de mejora continua en sus procesos.
- Nuevos productos o servicios, diversificación.
- Necesidad de ser más competitivos.
El software ERP soporta y modela los procesos de la organización en un sistema de
información digital. Por lo tanto, los cambios en las actividades de las empresas deben ser
modelados a su vez en el sistema de información. En otras ocasiones no se trata de cambios en
los procesos, sino de la identificación de oportunidades de mejora en los sistemas de
información que permitirían incrementar la eficacia o la productividad, por ejemplo, mediante la
automatización de tareas repetitivas o mecánicas.
El “remodelado” de los procesos en el software ERP se llevará a cabo en la medida que sea
posible. En ocasiones el margen de flexibilidad del software permitirá el cambio en el proceso
sin tener que modificar aquel. En otras ocasiones serán necesarias adaptaciones cuya relación
coste / beneficio la empresa debe valorar antes de aprobar. En todos los casos es conveniente
actualizar la documentación de los procedimientos o instrucciones de trabajo y notificar a todas
las personas afectadas.
Una aproximación a la valoración de las adaptaciones de los sistemas de información viene

determinada por el coste de oportunidad que supone para la empresa (cuánta riqueza deja de
generar) si no modifica su sistema de información para que se adecue a sus procesos de negocio.
1.2. La dimensión personal.

Las características del software de gestión de la empresa pueden tener un impacto en
aspectos intangibles de la relación de las personas con la organización.
- Imagen externa, algunos ejemplos:

o El diseño y la usabilidad de los documentos comerciales.
o Los sitios web y los servicios que se ofrecen en ellos (nivel de accesibilidad,
usabilidad adecuada, corrección del diseño, efectividad de la comunicación).
- Accesibilidad de la información y eficiencia para los empleados, algunos ejemplos:
o Cuánto tiempo se tarda en elaborar un documento comercial.
o Cómo de fácil es obtener y enviar una información solicitada por un cliente.
Un sistema de información lento, con información inconsistente o en el que resulta difícil
obtener la información requerida genera desconfianza y disminuye la calidad del puesto de
11
SOFTWARE ERP
trabajo de los empleados. Contribuye a generar un clima de ineficiencia general de la

organización y perjudica la proyección de su imagen hacia el exterior.
1.3. Obsolescencia o inadecuación.

Puede ocurrir que el conjunto de los sistemas de información de la empresa no pueda
adaptarse adecuadamente, debido entre otros factores a:
- Limitaciones en la arquitectura del software:

o Dificultad de adaptación de las características y funciones disponibles
o Dificultad de integración o incompatibilidad con sistemas operativos
o Estándares de integración en Internet o formatos comunes de intercambio de
información (interfases)
o Tecnología de desarrollo propietaria o que no usa lenguajes o estándares
comunes en la industria del software (factor interno)
- Empresas que cambian algún aspecto básico de sus procesos con rapidez:
o Ampliación de la cartera de productos y servicios hacia sectores que le son
afines pero cuyos procesos son sustancialmente diferentes de los que venía
realizando hasta ahora. Ejemplo: estudio de arquitectura que abre una línea de
negocio de interiorismo. Aunque sean afines, ambos servicios se pueden ofrecer
por separado.
o Integración hacia delante: dentro del mismo sector, verticalización de la oferta
de productos y servicios para vender más a la cartera de clientes existente.
Ejemplo: una ingeniería de proyectos que además comienza a ofrecer la
dirección de obra de sus proyectos.
o Cambios en el canal de ventas: reciclaje de la fuerza de ventas y apoyo en el
nuevo canal de comercio electrónico.
Otro escenario que puede darse es una suma de pequeñas deficiencias en el software cuyo
coste de oportunidad de forma aislada es poco significativo pero tomadas en su conjunto se
convierten en un freno importante para la gestión. Podemos estar entonces ante una brecha
importante entre el nivel de gestión requerido y la funcionalidad que ofrece el software.
También puede tratarse de obsolescencia del software.
Cuando el coste de las adaptaciones del software supone un porcentaje significativo del coste
total de propiedad y se da también la circunstancia que el coste de oportunidad es elevado, la
organización debe decidir si inicia un proceso de cambio del ERP.
Es el momento en que la organización se debe plantear un análisis en profundidad y de

forma cuantitativa: ¿cuánto frena nuestro desarrollo no disponer de la tecnología adecuada?
12
SOFTWARE ERP
2. Toma de requerimientos general.

2.1. Tipología de las empresas.
En primer lugar, es necesario situar el marco del presente estudio en cuanto a los tipos de
empresas susceptibles de aplicación de los contenidos expuestos de forma general. La
clasificación economicista de los tipos de empresas describe:
- Sector primario: extracción de recursos naturales, incluye entre otros, minería,

agricultura, ganadería.
- Sector secundario: transformación de los recursos naturales mediante procesos
industriales.
- Sector terciario: servicios que no producen bienes materiales.
El sector secundario se puede subclasificar a su vez en:
- Industria pesada: transformación de materias primas en productos semielaborados,

como la industria extractiva del petróleo o la metalúrgica.
- Industria ligera: transformación de materias primas en bienes de consumo.
- Industria de bienes de equipo: transformación de materias primas en productos para
otras empresas, que a su vez los utilizarán para producir otros bienes de equipo o de
consumo.
Estos dos últimos grupos son los más frecuentes en número y en variedad. Se pueden
encontrar empresas cuya facturación anual oscila entre decenas de miles de euros a miles de
millones, y con tamaños desde microempresas de uno o dos empleados a decenas de miles, con
actividades tan dispares y especializadas como la fabricación de estuches para instrumentos
musicales de lujo con producción de unas pocas unidades hasta los grandes fabricantes de
productos lácteos.
Dentro de la clasificación anteriormente expuesta, la siguiente subclasificación corresponde

al sector de actividad. A este nivel ya es posible hablar de ERP especializados constitutivos de
soluciones sectoriales. Esto es necesario debido a que las necesidades de gestión varían
ampliamente entre distintos sectores. Considerar, por ejemplo, las diferencias que puede haber
entre una fábrica de zapatos y una fábrica de productos lácteos.
2.2. Identificación de las áreas afectadas por el proyecto.

Hay que dedicar un tiempo razonable a documentar el funcionamiento general de la empresa.
Se trata de identificar los principales procesos que añaden valor. Estos procesos pueden incluir,
de forma genérica:
- I+D+i y diseño de producto

- Ingeniería y reingeniería (cambios, versiones de producto)
- Producción
- Marketing
- Logística
- Comercialización
- Servicio posventa
- Finanzas
- Controlling2
13
SOFTWARE ERP
- Procesos de dirección, con sus propios requerimientos, principalmente de análisis de

datos para la toma de decisiones
El “tiempo razonable” para estas labores de análisis de la empresa vendrá dado, entre otros
factores, por la complejidad de la gestión de la empresa, la variedad de tipos distintos de bienes
que produzca, el número de sedes y el grado de centralidad/descentralización de su gestión. Y
como siempre, otro factor es la limitación impuesta por los recursos asignables a esta fase,
humanos y presupuestarios.
Esta toma de requerimientos general debería estar disponible antes de contactar con ninguna
empresa de consultoría que vaya a proponer ningún software en particular. Ahorrará tiempo y
dinero, y transmite la idea de que la empresa ya ha estado “haciendo los deberes” y tiene una
idea general de lo que necesita.
2.3. Detección de restricciones importantes.

A la toma de requerimientos anterior habrá que añadir las restricciones existentes.
De calendario.
Puede que exista algún factor condicionante que obligue a disponer el nuevo sistema de
información en unas fechas límite.
De disponibilidad de recursos.
Puede que el ciclo de ventas sufra una marcada estacionalidad que determine una ventana de
tiempo en la que el personal tiene mayor carga de trabajo y no va a poder atender la sobrecarga
que supone el cambio de ERP: entrenamiento y formación, pruebas, validaciones, introducción
de datos en tablas auxiliares, reuniones para discutir sobre los nuevos flujos de trabajo, etc.
Otra restricción puede venir dada por la necesidad de liberar de parte de la carga de trabajo
actual a los usuarios clave, de manera que puedan ocuparse del trabajo asignado en la
implantación. Puede que haya que asignar nuevos recursos de forma temporal o reorganizar los
existentes para conseguir la disponibilidad requerida.
Presupuestarias.
Por último, las restricciones presupuestarias siempre existen. Hay un rango de inversión que
la empresa está dispuesta a considerar inicialmente. En este sentido, la empresa debería tener en
cuenta parámetros de referencia como el promedio de inversiones en TI en su sector. También
consultará si existen ayudas públicas disponibles, créditos en condiciones ventajosas, incentivos
al empleo generado con el proyecto o los periodos de amortización permitidos legalmente,
factores que pueden contribuir a disminuir el impacto financiero de la inversión.
Cabe destacar que el rango de inversión considerado aceptable inicialmente puede verse
modificado durante las etapas de evaluación de soluciones y de proveedores en función de los
resultados del análisis de la oferta disponible en el mercado, por ejemplo, a la vista de las
propuestas económicas. También podría verse modificada con la aportación de nueva
información que modifique otros aspectos del proyecto como el alcance inicialmente previsto
(ampliado o reducido), o el escalonamiento de fases que alargue el plazo de la inversión y
potencialmente disminuya el riesgo.
14
SOFTWARE ERP
3. Evaluación de soluciones.
3.1. Preselección.
En el mercado existe una oferta muy amplia de software ERP.
Es imposible conocerlos todos, pero se puede hacer una criba muy importante atendiendo a
unos pocos criterios iniciales de descarte.
- Sector
- Tipo de clientes (B2C / B2B)
- Ámbito geográfico de operaciones
- Organización de sedes
- Presupuesto disponible
- Origen geográfico del software
3.2. Sector.
El software debe estar preparado para trabajar con nuestro sector, esto es una obviedad.
Cuando se trata de alcanzar un nivel de gestión elevado que tenga un verdadero impacto en la
competitividad de la empresa, es necesario que los procesos que se realizan se puedan modelar
en el sistema de información con la mayor fidelidad posible. Por ejemplo, no requiere el mismo
tipo de gestión una empresa que se dedica a fabricar perfiles de aluminio que otra empresa que
fabrica ventanas con los perfiles de la primera.
Si tenemos en cuenta que un buen software ERP estará basado en buenas prácticas de gestión
empresarial, debe ser lo suficientemente adaptable y flexible como para que se pueda configurar
según las necesidades de la empresa. Por este motivo también podría ser posible utilizar un
software preparado para un sector con requisitos funcionales similares.
3.3. Tipo de clientes.

Las necesidades de gestión varían si se trata de una empresa que vende a consumidor final o
a otras empresas (B2C / B2B). Por ejemplo, hay directivas de nivel europeo para protección de
los consumidores3, desarrolladas en la legislación de cada uno de los países, y que afectan al
servicio posventa, entre otras actividades. Por otra parte, las transacciones entre empresas se
rigen por una serie de reglas comerciales específicas, como son los escalados de descuentos o
rappel, los acuerdos de nivel de servicio, la integración de proveedores en la cadena de
suministro, etc.
3.4. Ámbito geográfico.

Las necesidades de gestión varían si la empresa opera solamente en ámbito nacional,
intracomunitario o internacional. Estas necesidades afectan a la naturaleza y periodicidad de la
liquidación de tributos, a los impuestos aplicables según el tipo de operación comercial, a la
información que se debe incluir en los documentos comerciales en cada caso y en general, al
conocimiento de las leyes en materia de comercio que afectarán a las transacciones con otros
países. Muy posiblemente también afecte a los idiomas en los que habrá que disponer los
formatos de documentos comerciales y los contratos. En el ámbito de recursos humanos,
15
SOFTWARE ERP
también afecta a la capacitación necesaria del personal de la empresa para comunicarse con
clientes y proveedores de otros países.
El software ERP debe estar preparado para facilitar todos los modelos de impuestos
requeridos, la elaboración de documentación comercial correcta y completa de acuerdo con las
leyes de los países de destino y si es necesario los formatos multiidioma. Si dispone de portales
específicos online para sus clientes, considerar también si es necesaria una configuración
multiidioma según el perfil de cliente. Otro aspecto en el que se debe considerar las capacidades
multilenguaje del software es la posibilidad de configurar el entorno de los usuarios en su
idioma preferido.
3.5. Sedes.
Las necesidades de una empresa con varias sedes son más complejas, pueden condicionar la
elección del software en función de la disponibilidad del sistema desde las delegaciones. ¿Se
puede desplegar el ERP en un datacenter externo? Habrá que considerar los costes asociados a
alojar las aplicaciones fuera de la empresa.
¿Funcionan bien las redes de comunicaciones? ¿Podrán todos los usuarios, sea cual sea su
ubicación, disfrutar de una conectividad satisfactoria? ¿Se requiere trabajar con archivos
adjuntos muy pesados?
Hay que tener en cuenta que el rendimiento de la aplicación tiene un impacto directo en la
experiencia de usuario. Una experiencia de usuario deficiente tiene a su vez un impacto en la
productividad y en la aceptación del sistema por parte de los usuarios.
Si los usuarios deben conectarse al servicio por medio de internet, se tendrán en cuenta
requisitos como el uso de clientes ligeros o basados en web. Si es necesario instalarlo en el
entorno de red local de una de las sedes, habrá que considerar la penalización de rendimiento
que supone esto para el resto de usuarios de otras sedes o si existe alguna solución técnica que
resuelva esto de otra manera.
3.6. Presupuesto.
El presupuesto disponible también va a condicionar poder acceder a implantar un software u
otro, dentro de la oferta disponible que sea adecuada para la empresa.
El presupuesto debe estar especificado con claridad y ser completo, es decir, el cliente debe
asegurarse que el presupuesto incluye realmente todas las partidas que la empresa va a tener que
desembolsar, que no existan costes ocultos no contemplados, que se incluya el desarrollo,
implantación y servicios relacionados que vayan a ser necesarios para lograr los alcances
propuestos. Estos alcances también deben estar bien definidos en funcionalidad y plazos.
16
SOFTWARE ERP
3.7. Origen.
El origen del software puede constituir también un elemento de decisión. Los internacionales
suelen requerir una inversión más elevada. Los que han sido desarrollados en otros países tienen
ventajas e inconvenientes:
Origen Ventajas Inconvenientes

Nacional
Mejores condiciones de Base instalada más reducida

soporte local
Menor número de partners
Proveedores cercanos
Menos funciones para
internacionalización
Internacional
Procesos de negocio Las “buenas prácticas” del

normalizados de acuerdo a sector pueden diferir de un
buenas prácticas en el sector país a otro
de referencia
Mayor dificultad de
Mejor compatibilidad de adaptación de los usuarios a
interacción con terceros. formas de trabajar diferentes
Estandarización de
operaciones si la empresa
cuenta con sedes fuera del
país matriz
Tabla 1. Comparativa de soluciones por origen.
Es necesario asegurar que la oferta de mantenimiento, soporte e implantación local es lo

suficientemente amplia como para no tener problemas a la hora de encontrar proveedores
cercanos que puedan colaborar en la implantación. Los gastos de traer consultores lejanos para
que se ocupen del proyecto pueden hacerlo inviable, aun teniendo en cuenta la facilidad actual
que nos proporcionan las comunicaciones por Internet. En la práctica, esto restringe bastante la
elección de un software desarrollado en otro país, salvo los ERP con una base instalada amplia y
un canal bien nutrido de partners para las implantaciones.
3.8. Funcionalidad.
En cuanto al grado de sofisticación de los procesos y la funcionalidad del ERP, tenemos
cotas directamente relacionadas con la carga administrativa que introducen. A su vez, dicha
carga administrativa está relacionada con el esfuerzo necesario para mantener el sistema en
condiciones adecuadas de operación, es decir, en última instancia, cuánto personal
administrativo se necesita para “alimentar” el ERP de forma consistente.
La cota alta la tenemos en sistemas muy sofisticados. Las implantaciones requieren una
inversión elevada, bastante tiempo y recursos, y obligan a definir los procesos con mucho
17
SOFTWARE ERP
detalle. Son adecuados para empresas grandes que no cambian con rapidez, con múltiples sedes,
muchos usuarios y que pueden aprovechar las ventajas de mantener los procesos normalizados
en una forma de trabajar.
No son recomendables para PYME dinámica cuya ventaja por su tamaño es una capacidad
de adaptación más rápida, como es el caso de la PYME industrial en proceso de cambio,
centrada en la innovación de producto diferenciado y procesos que le permitan competir a un
nivel superior al de los mercados que funcionan principalmente a precio.
La cota baja la tenemos en sistemas que, si bien cuentan con módulos de producción, las
interfaces4 son básicas, los procesos están poco desarrollados, el coste de licencias es bajo y las
implantaciones están centradas en el desarrollo a medida de adaptaciones. Si la capa de
personalización está bien diseñada, esto no tiene por qué ser un problema. Sin embargo, el nivel
de incertidumbre sobre el éxito de proyectos basados en esta aproximación es más alto que si
partimos de un software que esté más desarrollado. Se habla en estos casos de software con
funcionalidad horizontal 5 , en referencia a un conjunto más o menos amplio de funciones
genéricas y polivalentes para diferentes entornos de ejecución, pero que no están adaptadas en
toda su profundidad a las necesidades de un determinado sector.
En algunos casos los ERP disponen de versiones verticales: conjuntos de adaptaciones

específicas y configuraciones que ya llegan parametrizadas para un determinado tipo de
industria y que reducen de forma notable el esfuerzo necesario para adaptar el ERP estándar a
las necesidades de un sector.
Otro caso relacionado con la funcionalidad disponible es el del desarrollo descentralizado.

Se trata de sistemas en algunos casos bien modularizados, con un fabricante centrado en el
núcleo principal y una red de partners tecnológicos que desarrollan otros módulos que añaden
funcionalidad. La arquitectura del sistema debe en estos casos ser de muy buena calidad y estar
muy bien estructurada, con el fin de facilitar a terceros la integración de sus propios desarrollos.
Una implantación basada en el desarrollo de adaptaciones a partir de una solución horizontal

introduce un elevado riesgo en los proyectos de implantación de ERP:
• Corrección de las especificaciones, ya que en la mayoría de los casos siguen estando

redactadas en lenguaje natural.
• Cumplimiento de plazos.
• Desviaciones presupuestarias.
• Incertidumbre sobre cómo están implementados los procesos en el nuevo ERP.
• Incapacidad del cliente para validar ante los desarrolladores qué es lo que realmente quieren o
necesitan.
En la mayoría de los casos es mejor tomar como punto de partida una solución cuya
funcionalidad disponible ya de partida se acerque lo más posible a las necesidades de gestión
existentes.
18
SOFTWARE ERP
3.9. Aproximación cuantitativa de una clasificación cualitativa.

Hay numerosos aspectos para tener en cuenta durante la evaluación de software ERP. Una
vez realizada la primera criba de descarte, se puede realizar una aproximación cuantitativa
sencilla consistente en otorgar un peso de uno a diez a cada uno de los elementos de decisión
cualitativos y sumar para elaborar una clasificación.
3.9.1. Base instalada.

Se denomina base instalada al número de implantaciones que se encuentran operativas en un
periodo de tiempo y un ámbito geográfico determinados. Serán indicadores relevantes:
- La base instalada actualmente a nivel global

- La base instalada en nuestro entorno más cercano
- De especial relevancia: la base instalada en empresas del mismo sector al que
pertenece la empresa que está considerando implantarlo
Cuanto mayor sea la base instalada cercana, presumiblemente mayor será la oferta de
servicios disponible.
También serán indicadores relevantes la oferta de empresas de servicios de consultoría que

operen en el entorno del cliente y que estén probadamente capacitados para acompañar durante
el proceso de implantación y posteriormente desde el inicio de la etapa de mantenimiento y
soporte.
3.9.2. Vertical vs horizontal.

En base a lo anteriormente expuesto en el apartado de preselección, se valorará el grado de
adecuación a los requerimientos de la empresa del que parte el software antes de plantear
acometer ninguna adaptación.
3.9.3. Facilidad de adaptación.

Algunos ERP están basados en arquitecturas bien estructuradas que permiten establecer una
capa de adaptaciones personalizadas que no resultan afectadas por las actualizaciones del núcleo
del sistema. Siempre con limitaciones, en muchos casos este nivel de encapsulamiento puede ser
muy útil si es utilizado con pericia siguiendo las reglas establecidas por el fabricante.
En otros casos se puede utilizar la capacidad de sobrecarga que permiten algunos lenguajes
de programación.
En otras ocasiones la empresa consultora de la implantación puede mantener un estricto

control de versiones que incluye exactamente las adaptaciones implementadas para cada uno de
sus clientes y se ocupa de mantener la compatibilidad con la versión estándar. Esta solución
puede permitir una gran flexibilidad funcional, sin embargo, puede ser costoso y generará una
gran dependencia con el proveedor.
Si el sistema no permite aplicar una capa de personalización mediante la que aplicar las
posibles adaptaciones requeridas, cuando esta necesidad se produzca se podría generar una
brecha creciente entre las versiones estándar y la adaptada que mantenga en la práctica a la
empresa “prisionera” de la versión adaptada si resulta demasiado costoso acceder a nuevas
versiones mientras se mantienen las adaptaciones.
19
SOFTWARE ERP
3.9.4. Facilidad de configuración.

Consideraremos configuración como el conjunto de tareas cuyo objetivo es adecuar el
entorno de ejecución del ERP a las necesidades de la empresa. A continuación, algunos
ejemplos de configuraciones:
- Datos en tablas auxiliares como países, formas de pago, divisas, traducciones, tipos de
terceros, impuestos, etc. La facilidad de configuración requiere que todos estos datos se
puedan introducir y mantener (modificar, dar de baja) por personal no técnico desde las
propias interfaces del sistema. Una aún mayor facilidad de configuración implica que se
puedan cargar registros en lote desde archivos de texto plano con determinado formato.
- Parámetros: variables configurables a nivel de aplicación que hacen que varíe el
funcionamiento del sistema. Ejemplos: “número de copias a imprimir de las facturas”,
“cerrar línea de pedido al emitir albarán si la cantidad pendiente es menor que x
unidades”, “lanzar órdenes de producción por cantidad mayor o igual al lote mínimo”.
Deberían estar concentradas en un único sitio y debidamente documentadas.
- Personalización de interfaces: facilidad por la que cada usuario puede variar la
apariencia de su entorno en función de las operaciones más frecuentemente realizadas,
algunos ejemplos: accesos directos a determinadas operaciones, menús personalizados,
columnas y ordenación personalizadas en vistas tabulares de consulta. Sería deseable
que el sistema facilite que cada usuario personalice su entorno e idioma de las interfaces
sin ayuda de personal técnico.
3.9.5. Coste total de propiedad.

Se deberá tener en cuenta el coste total de propiedad, detallado más adelante en la sección de
Análisis de costes.
3.9.6. Usabilidad y curva de aprendizaje.

En función de la naturaleza de la actividad de la empresa es conveniente analizar cómo de
eficientes son en el uso diario las interfaces de usuario. Un parámetro de referencia de la
adecuación de las interfaces a distintas necesidades son el número de documentos
comerciales emitidos por la empresa, así como el importe medio por documento.
• Ejemplo 1: proporcionalmente, el coste de gestión administrativa de un pedido con 100

líneas es sustancialmente menor que el coste de gestión de 100 pedidos con una sola
línea cada uno.
• Ejemplo 2: el coste de gestión administrativa de un pedido de un artículo de 1000 euros
es sustancialmente menor que el de un pedido de 100 artículos distintos de 10 euros
cada uno (sin tener en cuenta otros factores como el margen bruto).
Se valorará también la disponibilidad de ayuda integrada en las propias interfaces de la
aplicación, contextual a las funciones.
Las interfaces de usuario diseñadas de acuerdo con estándares comúnmente aceptados

deberían ser reconocibles por los usuarios incluso a primera vista, de manera que puedan usar el
sistema con unas pocas horas de entrenamiento, en especial si la rotación de personal es
considerable.
Uniformidad de las interfaces de usuario: las pantallas con funciones análogas deberían
presentar un diseño y controles uniformes, con los mismos colores, misma ubicación de botones
de acción y menús, ubicación de información análoga, similar distribución de información en
20
SOFTWARE ERP
pestañas, tipografía y tamaño de fuente, teclas de función y manejo. Ejemplos: pantallas de tipo
CRUD6 de los ficheros maestros.
Algunos sistemas cuentan con mecanismos de ayuda tales como:
- Asistentes que indican el estado de avance de un determinado flujo de trabajo.

- Tolerancia a errores humanos basados en controles automáticos, dobles
comprobaciones, bloqueos que requieren la intervención de otro usuario.
- Sistemas poka yoke7 que evitan los errores humanos.
3.9.7. Usuarios.
El número de empleados y el número de usuarios influyen en la complejidad de la
implantación. Por ejemplo, en una planta de producción en la que el número de operarios que
tienen que imputar fichajes de órdenes de producción en los terminales de planta es elevado o
muy concentrado en determinadas horas, entonces cobra relevancia la elección de un sistema
cuyas interfaces para esa aplicación permitan reducir las pulsaciones (y los segundos) que debe
pasar cada operario ante los terminales para realizar las operaciones más frecuentes.
3.9.8. Accesibilidad.
¿Habrá usuarios con algún tipo de discapacidad que deban utilizar el sistema? ¿Están las
interfaces preparadas de forma adecuada para todos los tipos de usuarios y las circunstancias
ambientales en las que se tiene que usar? ¿Se debe acceder a las aplicaciones únicamente
mediante aplicaciones de escritorio o también habrá usuarios en movilidad con ordenadores
portátiles, tabletas digitales o smartphones? ¿Hay que preparar un conjunto de interfaces
específicas para cada tipo de dispositivo? ¿Qué subconjunto de funciones debemos poner a
disposición de los usuarios en cada tipo de dispositivo?
Más importante aún: ¿cómo de preparado está el ERP en su edición estándar para dar
respuesta a estas necesidades? ¿Cuánto esfuerzo será necesario para prepararlo?
3.9.9. Tecnología que utiliza y uso de estándares.

Se valorará positivamente el uso de lenguajes de programación con presencia amplia en el
mercado y con un coste de licencias de ejecución (runtime) asumible. Lo mismo es aplicable al
motor de base de datos y al resto de elementos del entorno de ejecución del ERP, como:
- Sistemas operativos servidores y clientes

- Dispositivos de entrada, scanner, lectores de código de barra (ej. estándares EAN),
etiquetas de identificación por radio frecuencia (RFID).
- Formatos de intercambio de datos con otros sistemas (ej. XML, texto plano, json).
- Interfaces de programación de aplicaciones (API, ej. REST, SOAP, Java RMI)
El uso de estándares en la industria del software facilita la compatibilidad e integración con
otros sistemas.
3.9.10. Proyección futura o roadmap8 del ERP.

Es importante recabar la información disponible acerca de los planes de los fabricantes
acerca del futuro desarrollo de las soluciones analizadas. Antigüedad, evolución tecnológica,
frecuencia de publicación de versiones y garantías contractuales que ofrece el fabricante en el
caso de abandonar el desarrollo.
21
SOFTWARE ERP
Evaluaremos qué funcionalidades son las que se se están trabajando actualmente y cuales se
van a mejorar en el futuro, para determinar si coinciden con los intereses de la organización.
También recabaremos información sobre planes para interactuar con otros sistemas, cambios o
actualizaciones de partes del sistema que pertenecen a otros fabricantes, como pueden ser
herramientas integradas de análisis y reporting, motores de base de datos, lenguajes de
programación, extensiones de servicios web, etc.
22
SOFTWARE ERP
4. Evaluación de proveedores.
4.1. Fabricante del software.
La implantación de un ERP conlleva un gran esfuerzo para la organización y no se puede
cambiar con frecuencia. En este contexto, el proveedor del software es una empresa con la que
se establece una relación comercial a largo plazo. Atendiendo a estas premisas, se detallan los
aspectos más relevantes que se deben valorar.
4.1.1. Estabilidad y trayectoria.

Estable y con proyección de futuro. Conviene asegurarse que no tienen un historial notorio
de proyectos fallidos y que en los foros de usuarios del ERP hay suficientes valoraciones
positivas. Si es posible, contactar o visitar a algún otro cliente que use el mismo ERP,
preferiblemente que desempeñe una actividad similar.
4.1.2. Tamaño.
Un fabricante muy pequeño tiene más riesgo de “desaparecer” o no ser capaz de dar
respuesta en tiempo y forma a las necesidades del mercado, por no disponer de personal
cualificado suficiente. Por otra parte, puede que cada cliente sea muy importante para ellos y se
tomen muy en serio cuidarles bien y dar respuesta a sus necesidades. Son más sensibles a las
malas referencias, sobre todo si operan en un entorno más bien local.
Un fabricante muy grande con un software muy horizontal puede que preste menos atención
a las solicitudes de un determinado cliente. Es posible que entre su canal de partners se
encuentre alguna empresa a la que interese desarrollar un conjunto de funcionalidades que
puedan desarrollarse como “paquete estándar” y que puedan servir para satisfacer las
necesidades de un sector o nicho de mercado. Esta situación se da con cierta frecuencia puesto
que sería imposible para el fabricante tratar de abarcar todas las oportunidades de negocio a la
vez.
4.1.3. Tecnología.
Asegurarnos que la tecnología que emplean no está obsoleta o próxima a desaparecer, y que
es suficientemente flexible y escalable de acuerdo a la proyección de la empresa.
4.1.4. Modelo de comercialización.

El modelo comercial de explotación del ERP está relacionado con cómo se plantea
estratégicamente el fabricante obtener el retorno de inversión del esfuerzo dedicado al desarrollo
de su software y su competitividad en el mercado. Es importante evaluar en su conjunto los
costes del proyecto, y no solamente el coste de las licencias o los servicios de consultoría de la
etapa inicial. Más información detallada en la sección de Análisis de costes.
El mercado ofrece una variedad amplia de modelos de comercialización, a continuación se

describen algunos de ellos.
Licencias de tipo copyleft Open Source: licencia gratuita del núcleo de la aplicación. Suele
estar basado en una comunidad de empresas con intereses comerciales en la prestación de
servicios vinculados al software cuyo uso ofrecen de forma gratuita. Ejemplos: MIT, GPL. Se
permite su redistribución con ninguna o pocas limitaciones. Además, puesto que el código
23
SOFTWARE ERP
fuente está disponible, se permite la modificación del software por cualquier persona o entidad
con los conocimientos técnicos necesarios. La licencia suele estar sujeta a cláusula de exención
de responsabilidad por parte del fabricante. Puede que algunas partes (módulos) de uso más
específico o avanzado sean de pago o incluso que estén sujetos a otro tipo de restricciones de
acuerdo a su propia licencia.
Licencias Freeware: código propietario y cerrado, no modificable por terceros. No se paga

por la licencia de uso. El fabricante y sus partners (socios tecnológicos que distribuyen e
implantan el ERP) cobran por los servicios de consultoría de implantación.
Modelo Freemium: el fabricante pone a disposición del público de forma gratuita una
versión completamente operativa del software con un conjunto de funcionalidades reducidas.
Las empresas con menos requerimientos pueden aprovechar estas ediciones y las que necesitan
funcionalidades más avanzadas o un nivel de servicio mayor pueden optar por las distintas
ediciones Premium de pago.
Modelo de pago por uso o suscripción: el fabricante cobra una cantidad por periodo de
tiempo de acuerdo al uso que haga el cliente. El uso puede referirse a la cantidad de usuarios, a
los módulos funcionales contratados, al número de transacciones, al espacio de almacenamiento
y/o cualquier otro parámetro vinculado a la intensidad de uso. Puede resultar apropiado si el uso
en el tiempo es muy irregular. Suele aplicarse a sistemas disponibles online, pero también se
puede aplicar a instalaciones on-premises9.
Licencias de pago por aplicación y/o usuario: software de código cerrado y propietario, en
el que el fabricante pone un precio al uso de la aplicación y sus módulos. En algunos casos
carga al cliente una cantidad por separado por cada usuario que utiliza la aplicación. Estas
licencias de usuario pueden a su vez ser nominales, de manera que cada usuario tiene una
licencia reservada, o bien concurrentes, de manera que las licencias se van consumiendo del
número total contratado a medida que los usuarios abren las instancias de aplicación y se van
liberando de nuevo a medida que las cierran. Esto último es más útil si la aplicación no se usa
de forma continuada durante la jornada o si los usuarios están ubicados geográficamente en
husos horarios distintos.
4.1.5. Garantía.
Es importante verificar las condiciones del contrato que especifican bajo qué garantías se
suministra el software ERP. En los casos en que el código fuente no sea accesible, se puede
negociar el depósito notarial periódico de cada actualización importante, para usar ante la
eventualidad de que el fabricante cese actividad o abandone el desarrollo.
Conviene también verificar en qué condiciones el fabricante ofrece la posibilidad de

incorporar modificaciones en la funcionalidad disponible, e incluso en qué condiciones se
pueden cofinanciar las funcionalidades con otros clientes o el propio fabricante, si son
interesantes para incorporar a la edición estándar. Estas condiciones pueden incluir plazos de
ejecución, frecuencia de liberación de nuevas versiones, el compromiso del fabricante a no
negarse a implementar las modificaciones requeridas por el cliente y también los costes
aplicables a las jornadas de los analistas y programadores.
Los contratos de mantenimiento y soporte son el ámbito en el que se definirán otros aspectos
de la garantía, como tiempos de resolución de incidencias por uso indebido o por fallos del
24
SOFTWARE ERP
propio sistema, y concretamente qué tipo de incidencias están cubiertas por estos contratos y
qué otras son facturables de forma adicional.
4.2. Consultora de implantación.

4.2.1. Tamaño.
Una consultora muy grande puede ser más estable y suele ser más cara ya que tienen que
soportar mayores costes de estructura. También puede que nuestro proyecto sea menos
importante para ellos.
Una empresa con un equipo reducido, pero bien dimensionado, puede permitirse precios más
ajustados. También son más sensibles a la publicidad negativa, de manera que cada proyecto es
más importante para ellos.
4.2.2. Experiencia.
Investigar acerca de la experiencia que puedan tener en procesos de negocio del mismo sector o
sectores afines al cliente.
4.2.3. Liderazgo.
Se debe poder contar con un proveedor capaz llevar con claridad todos los procesos de la
implementación del ERP a los procesos de negocio de la empresa en un lenguaje comprensible
por los usuarios clave10.
4.2.4. Soporte y comunicación.

Es importante asegurar que pueda ofrecer soporte técnico para solucionar las necesidades de
la empresa dentro de unos costes controlados y asumibles. También es aplicable lo expuesto
anteriormente en el apartado de garantía del fabricante relativo a los contratos de mantenimiento
y soporte.
Es relevante que las estructuras organizativas de comunicación sean flexibles y efectivas. La

relación debe ser colaborativa, atenta, y con una fuerte orientación al cliente. También es
necesario que se dé en las condiciones necesarias para que el cliente lo perciba de esta manera,
aunque esto depende en mayor medida de una correcta asignación de recursos humanos, así
como de la transmisión de la motivación previa al proyecto.
Respuesta adecuada ante las consultas y requerimientos, y con rapidez ante las situaciones
críticas.
Flexibilidad necesaria para trabajar con la empresa cuando lo solicite, dentro de unos
tiempos de respuesta adecuados.
4.2.5. Salud financiera.

En el apartado referente a evaluación de soluciones hemos mencionado la importancia de la
“salud” de las compañías fabricantes de los ERP candidatos.
Requiere ahora también mención especial la evaluación de la compañía elegida para

acompañarnos en la implantación, ya que es posible que se trate de una distinta.
25
SOFTWARE ERP
5. Planificación de recursos humanos y

materiales.
5.1. Asignación de roles, responsabilidades y motivación de usuarios
clave.
La responsabilidad última del proyecto recae sobre la Dirección de la empresa. Es habitual
que el órgano de Dirección delegue el liderazgo del proyecto en la figura de una persona con la
que mantendrá reuniones periódicas de evaluación y control. La persona que lidere el proyecto
puede ser experta en Tecnologías de Información, pero no necesariamente. A su vez, esta
persona deberá encargarse de solicitar y disponer los recursos humanos y materiales necesarios
para el éxito del proyecto, bajo la aprobación y supervisión de la Dirección.
Esta figura de liderazgo del proyecto puede ser un empleado de la empresa o puede ser un
nuevo miembro, ya sea personal contratado expresamente para el proyecto o una persona
externa subcontratada.
Véase también el apartado Papel de la Dirección y del Director del Proyecto en el

CAPÍTULO III. ASPECTOS TRANSVERSALES DE LA IMPLANTACIÓN.
5.1.1. Líder procedente de plantilla.

En el caso de que se trate de personal que estuviese ya anteriormente en plantilla, debería ser
relevado de sus funciones durante la implantación en la medida que le permita dedicar el tiempo
y atención necesarios a la dirección del proyecto. Se pueden reasignar parte de sus tareas a otras
personas con menor carga que puedan desempeñarlas o incluso contratar a otra persona para
delegar en ella las tareas que requieran un perfil de responsabilidad menor. Una de las ventajas
de asignar esta responsabilidad a alguien de la empresa es que puede conocer bien la actividad y
los procesos que se llevan a cabo, de manera que podrá hablar con autoridad sobre muchos
temas sin necesidad de consultarlo, y para las cuestiones que no pueda resolver directamente
sabrá con rapidez a quién dirigirse. Esto repercute en una mayor capacidad resolutiva ya que no
tiene que producirse la transmisión de conocimiento para tomar muchas pequeñas decisiones.
5.1.2. Líder nuevo en la empresa.

Cuando no es posible asignar esta responsabilidad a alguien que estuviese ya en plantilla, la
empresa puede necesitar incorporar a alguien para este cometido. En este caso debería ser un
perfil con conocimientos y experiencia probados en gestión empresarial, preferiblemente en el
mismo sector de actividad. Una de las ventajas de una persona externa es, paradójicamente, que
debe aprenderlo todo acerca de la empresa. Este factor le permite tener una visión no viciada
previamente y cuestionar procedimientos que se venían dando por hecho y que pueden
mejorarse con una visión externa y la pericia adecuada.
5.1.3. Inicio del proyecto.

Al inicio del proyecto es importante que una persona del órgano de Dirección se reúna con
todo el personal participante y les presente el proyecto. Debe quedar claro el apoyo por parte de
Dirección y debe transmitirse el mensaje de que se van a asignar los recursos necesarios para su
ejecución. La presentación también debe incluir:
26
SOFTWARE ERP
- La definición del alcance del proyecto

- El calendario de implantación previsto y las fases
- El equipo humano involucrado, que en numerosas ocasiones estará integrado por
personal de distintas empresas
- Las figuras de responsabilidad de cada parte
- Los usuarios clave de cada área organizacional
- Los recursos materiales y herramientas disponibles
- Los canales de comunicación habilitados
5.1.4. Usuarios clave.

Con el fin de hacer un uso adecuado de los recursos disponibles, en cada área objeto del
alcance de la implantación es útil designar una persona como usuario clave. Estos usuarios
pueden ser los responsables de área o simplemente ser empleados con suficiente experiencia
para conocer todos los procesos relevantes de su área funcional. Por ejemplo, una persona de
cada perfil en contabilidad, administración comercial, producción, almacén, logística, equipo
comercial, marketing, ingeniería. Estos usuarios clave deben ser también relevados de sus
funciones parcialmente, aunque en menor medida que el líder del proyecto. Los usuarios clave
consultarán con otras personas de sus respectivos departamentos cuando necesiten aclarar
determinadas cuestiones, pero en general deberán tener la autoridad suficiente para resolver por
sí solos la mayoría de los temas.
Es responsabilidad del líder del proyecto mantener a lo largo de la ejecución del proyecto la
motivación de los usuarios clave, que podrían no tener una visión global del estado de avance.
5.1.5. Recursos materiales.

Aunque el coste mayor del proyecto estará destinado al esfuerzo del equipo y los servicios de
consultoría de implantación, habrá también que coordinar en el cronograma de la implantación
la asignación de los recursos materiales necesarios, de manera que no se produzcan cuellos de
botella por falta de previsión en el momento en que se necesiten comenzar a utilizar.
Estos recursos pueden incluir, entre otros:
- Provisión de servidores de aplicación de acuerdo con los requisitos recomendados por el

fabricante del ERP.
- Provisión de servidores de base de datos de acuerdo con los requisitos.
- Adquisición de licencias de terceros que formen parte de los prerrequisitos del ERP.
- Adquisición y preparación de los equipos de escritorio de acuerdo con los requisitos.
- Instalación y configuración de infraestructuras de comunicaciones, instalación física de
redes locales cableadas o inalámbricas, redes privadas virtuales, servicios de escritorio
remoto.
- Instalación y configuración de hardware específico como impresoras de etiquetas,
controles biométricos, lectores RFID, lectores de códigos de barras, sistemas OCR,
cámaras de visión artificial, tarjetas de adquisición de datos, PLC.
27
SOFTWARE ERP
6. Análisis de costes.
Existe cuantiosa teoría sobre el cálculo de costes. Una aproximación práctica a los costes
más relevantes para un proyecto de implantación de ERP, objeto de este estudio, quedará
centrado en el coste total de propiedad y en el coste de oportunidad.
Es un ejercicio interesante dedicar algo de tiempo a calcular una estimación de todos los
costes previstos que van a suponer en conjunto el pago de las licencias, la consultoría de
implantación y el coste total de propiedad durante los tres primeros años desde el inicio del
proyecto, e incorporar esta estimación a la evaluación de cada una de las soluciones analizadas.
6.1. Coste total de propiedad.

El coste total de propiedad incluye los costes asociados a:
- Adquisición o alquiler de:

o Equipos de hardware: servidores, terminales de taller, PDA industriales,
equipos de escritorio, tabletas digitales, terminales móviles, PLC, cámaras, etc.
o Licencias de software: ERP, sistemas operativos, sistemas de virtualización,
motores de base de datos, software de seguridad (backup, firewall, antivirus),
frameworks de otros fabricantes necesarios para usar el sistema y cualquier otro
software vinculado a la infraestructura que soporta el ERP.
¿Adquisición o alquiler?
La adquisición supone un desembolso inicial mayor. Desde el punto de vista de la inversión,
es la opción de mayor riesgo. Si el fabricante ofrece el acceso al software mediante pago por
suscripción puede ser una opción interesante y de menor riesgo al no haber un desembolso
inicial tan elevado. Hay que tener en cuenta si el contrato involucra un periodo mínimo de
permanencia, aunque la facturación sea mensual. El alquiler, entendido como pago periódico
que habilita el acceso al ERP, supondrá un desembolso mayor acumulado después de un
tiempo.
Se puede elaborar un cuadro comparativo que incluya las cuotas mensuales comparado con
los vencimientos de la modalidad de adquisición de licencia para determinar en cuánto
tiempo se equipara la inversión y comienza a ser más cara la modalidad de alquiler. No hay
que olvidar incluir en ambos casos las cuotas correspondientes a mantenimiento y soporte.
Es posible que el fabricante ofrezca la conversión de un contrato de suscripción a adquisición
en ciertas condiciones comerciales ventajosas. Esta puede ser también una opción interesante
una vez que la empresa tiene claro que el proyecto se puede llevar a éxito. Más información
en el apartado referido al Modelo de comercialización.
Recuadro 1. Amortización vs alquiler.
- Mantenimiento y soporte de hardware: Recursos dedicados al mantenimiento operativo

de los equipos, personal, contratos de asistencia a domicilio, seguros de rotura
accidental de dispositivos de misión crítica, contratos de renting o leasing.
- Mantenimiento y soporte de software: contratos de soporte y actualizaciones del ERP y
renovaciones de las licencias de otras aplicaciones o software base relacionados con el
uso del ERP.
- Puesta en marcha: servicios de consultoría de implantación y coste de los recursos
internos destinados desde las fases más tempranas del proyecto hasta el inicio de la fase
de mantenimiento y soporte.
- Administración: consideraremos administración como el conjunto de tareas cuyo
objetivo es mantener el entorno de ejecución del ERP operativo y seguro (integridad,
28
SOFTWARE ERP
confidencialidad, disponibilidad). Una vez puesto en marcha, debería poder llevarlo a

cabo personal técnico dentro de unos costes razonablemente bajos.
o Automatización del mantenimiento de cambios de divisas con conexión a
servicios online confiables.
o Facilidad de actualización.
o Automatización de copias de seguridad.
o Facilidad de restauración de copias de seguridad con garantía de consistencia
del sistema.
- Costes de operación. ¿Qué carga administrativa acarrea mantener el sistema en un
estado consistente? Si la empresa va a incorporar en el nuevo sistema de información
más elementos de gestión de los que había anteriormente, es muy probable que la carga
de trabajo administrativo aumente.
- Costes indirectos relacionados con capacitación adicional del personal.
- Costes relacionados con gastos de dietas y desplazamientos del equipo.
- Costes de logística y cambios operativos de transición al nuevo sistema.
Los costes de operación pueden ser los más cuantiosos, ya que involucran a todos los
usuarios del sistema, ya sea para imputar datos, ejecutar procesos o consultar información.
Dentro de los costes de operación, interesa considerar la carga administrativa de las operaciones
cotidianas, como por ejemplo “minutos necesarios para introducir un pedido en promedio”.
Por otra parte, también interesa prestar atención el coste de personal asociado a otros
procesos periódicos, como pueden ser: actualización de tarifas de venta, actualización de
cambio de divisas, alta de artículos, cambios de ingeniería, actualización de fichas de
amortización, conciliación de movimientos bancarios, punteos de contabilidad, conversión de
documentos comerciales siguiendo el ciclo de ventas, actualización de tarifas de agencias de
transporte, imputación de costes marginales de importación.
Algunas de estas tareas pueden consumir una gran cantidad de tiempo. Son necesarias, pero
los usuarios aportan poco valor ejecutándolas de forma mecánica y repetitiva. Los ERP más
avanzados disponen de procesos semiautomatizados diseñados para reducir significativamente
el tiempo y esfuerzo para completar dichas tareas, disminuir considerablemente la posibilidad
de errores humanos, mientras se mantiene la supervisión necesaria y en definitiva, aumentar la
eficiencia y la satisfacción del usuario. La disponibilidad de procesos asistentes para este tipo de
tareas en el ERP debe ser valorada.
6.2. Coste de oportunidad.

Siempre hay restricciones. Pueden ser de naturaleza diversa: presupuestarias, de
capacitación, de plazos, etc. Puede que algunas de las restricciones conduzcan a elegir la
solución más conveniente, pero no la mejor. En este caso la empresa debería poner en la balanza
el coste de oportunidad, entendido como el beneficio no obtenido por tomar una decisión frente
a otra.
A continuación se expone un caso práctico para ilustrar el concepto de coste de oportunidad:
Cliente del sector de inyección de plástico con una facturación anual de 8 millones de euros.
Quieren disponer de un nuevo ERP lo antes posible para estar bien preparado ante sus
expectativas de crecimiento.
29
SOFTWARE ERP
La solución A nos permitirá completar toda la implantación en seis meses, cumple con el
resto de requisitos, pero no dispone de expediciones con PDA, y para este cometido habría que
desarrollar un nuevo módulo. El fabricante del ERP es una empresa local con muy buena
disposición a mejorar su producto. El coste total de propiedad a tres años es de 60.000 euros.
Por otra parte, la solución B no puede estar implantada antes de un año y medio, cumple con
todos los requisitos, incluida la expedición con PDA y tiene más módulos opcionales que se han
descartado para la implantación, pero podrían ser interesantes más adelante. El fabricante es una
multinacional con bastantes clientes en el mismo sector y país. Su coste total de propiedad a tres
años es de 150.000 euros.
El cliente podrá tratar de dar una respuesta cuantitativa a algunas de estas cuestiones:
- ¿Qué coste tiene para la empresa retrasar la puesta en marcha del ERP un año?
- ¿Qué coste tendría para la empresa cambiar la solución A si en unos pocos años su
funcionalidad ya no responde satisfactoriamente al crecimiento de la empresa?
- ¿Qué coste estimado tendría el desarrollo del nuevo módulo de expediciones? ¿Y plazo?
¿Qué coste interno tendrá para la empresa ser el primer cliente, y por tanto, los testers
de este nuevo módulo?
- ¿Qué coste tendría para la empresa si elige la solución A y el pequeño fabricante cesa su
actividad o abandona su desarrollo?
- Si elige la solución A, ¿qué coste puede tener para la empresa el hecho de no poder
optar a los módulos adicionales?
30
SOFTWARE ERP
7. Análisis de viabilidad del proyecto.

Antes de comenzar es necesaria una reflexión sobre el riesgo y las posibilidades de ejecutar
con éxito el proyecto. Para este cometido podemos analizar diversos factores que inciden en la
viabilidad global.
7.1. Operativa.
¿Disponemos realmente de los recursos humanos necesarios? ¿Se ha podido formar un
equipo cohesionado con capacidad para trabajar conjuntamente por la consecución de los
objetivos
¿Necesitan capacitación complementaria como fase previa al inicio del proyecto?
¿Tienen suficiente disponibilidad? ¿Se les ha relegado de forma suficiente de sus funciones
habituales para poder ocuparse del proyecto?
¿Se han establecido planes de contingencia en caso de dificultades imprevistas durante la

implantación? ¿Podría la empresa mantenerse operativa? En caso negativo, ¿por cuánto tiempo
y cual sería el perjuicio derivado (clientes, imagen)?
¿Hay algún impedimento operativo importante desde el punto de vista operativo en la

organización o alguna restricción de calendario importante para comenzar con el proyecto?
7.2. Técnica.
¿El software elegido satisface todos los requerimientos importantes que se ha marcado como
objetivos mínimos la organización? Cuanto más lejos esté el estándar de estos requisitos
mínimos, mucho mayor es el grado de incertidumbre sobre la viabilidad del proyecto.
¿El software elegido puede satisfacer con un esfuerzo razonable el resto de requisitos que se
ha marcado como objetivos deseables la organización? Véase el apartado Facilidad de
adaptación.
¿Cuál es la solidez financiera de cada una de las empresas externas cuya tecnología o
servicios se van a adquirir? Se puede ponderar según su importancia y la facilidad de
sustitución. Por ejemplo, una empresa de instalaciones de infraestructura de red se puede
sustituir con un impacto considerablemente menor que el fabricante del ERP.
¿Qué nivel de compromiso contractual en este sentido ha ofrecido el fabricante del software
o la empresa consultora de implantación?
7.3. Económica y financiera.

¿La empresa dispone de los recursos materiales necesarios para afrontar el proyecto o bien
capacidad para obtener financiación?
¿Se han tenido en cuenta todos los costes relacionados? Véase la sección Análisis de costes.
¿Qué impacto económico puede tener en la organización costes derivados de retrasos o

imprevistos durante la implantación?
31
SOFTWARE ERP
CAPÍTULO II. FASE IMPLANTACIÓN.

1. Áreas de gestión habituales en las
empresas.
A continuación se presentan las operaciones habituales de las áreas de gestión de las
empresas para situar el marco de aplicación y presentar a continuación las características
funcionales de los ERP que pueden dar respuesta a dichas operaciones.
1.1. Ingeniería de producto.

La ingeniería de producto define:
- La descomposición de un producto final en sus componentes, que pueden ser materias

primas o semielaborados.
- La cantidad necesaria y procedencia de estos componentes, que pueden ser comprados o
a su vez fabricados.
- Las operaciones por realizar sobre cada uno de los componentes hasta convertirlo en el
producto final.
- El orden de ejecución de las operaciones.
La definición completa del árbol de componentes y operaciones de un producto final
constituye su escandallo. El escandallo se utilizará también para el cálculo de costes.
El ERP debería contar con herramientas potentes para la configuración de nuevos productos
y para los cambios de ingeniería que se produzcan a lo largo de la vida del producto. Facilidades
para copiar escandallos, sustituir componentes, actualizar consumos, establecer fechas de
entrada en vigor de los cambios de ingeniería sin que afecte a las órdenes de fabricación en
curso, proveer acceso al historial de cambios de ingeniería.
En sistemas avanzados que soporten gestión de trazabilidad, se debería poder determinar

para cualquier lote de producto con qué versión de ingeniería del producto fue fabricado.
Si la ingeniería de producto es muy compleja y se dan cambios frecuentes que afectan a

algunos de los componentes, es posible que la oficina técnica del desarrollo de producto desee
integrar sus aplicaciones CAD con el ERP, de manera que puedan enviar los cambios de
ingeniería directamente. Esta integración puede disminuir la posibilidad de errores y evitar
inconsistencias entre el archivo documental de CAD y la ingeniería definida en el ERP.
También requiere un estricto control de versionado de documentos.
La definición de las ingenierías y su corrección afectan principalmente al aprovisionamiento,

a producción y a ventas. La configuración de las ingenierías debería limitarse a:
- Los elementos que sea relevante imputar en el sistema para el funcionamiento correcto
de los procesos afectados, como el lanzamiento de órdenes de producción, el
mantenimiento de un nivel de existencias adecuado y la gestión de los pedidos de
cliente.
- Mantener la carga de gestión dentro de unos costes asumibles por la organización.
32
SOFTWARE ERP
Esto significa que se deben establecer tantos niveles de ingeniería como realmente se
necesiten, pero teniendo en cuenta que cada nivel introducido implica mayor complejidad de las
estructuras y más trabajo para mantener el sistema bien informado. Lo mismo es aplicable a las
operaciones.
Ejemplo, ingeniería de un coche de juguete:
Producto Componentes Consumo Operaciones

Ford Rally - Embalaje, QC
Chasis 1 ud Poner pegatinas
Chasis pintado 1 ud Pintar
Chasis 1 ud Art. Compra
(zamac)
Pintura 2 ml Art. Compra
Pegatinas Rally 2 ud Art. Compra
Base (ABS) 1 ud Art. Compra
Tornillo 1 ud Art. Compra
Eje (2 ruedas) 2 ud Art. Compra
Cajita expo 1 ud Art. Compra
Tabla 2. Ejemplo de ingeniería sobrecargada con información irrelevante.
Compras nos informa que las cajitas expositoras sirven para todos los coches de la colección,
se compran desmontadas en cajas de 900 unidades y el control de stock es visual: cuando
quedan dos cajas el operario que empaqueta pasa nota a compras.
Los tornillos se compran en cajas de diez mil, y también se usa el mismo modelo para los
otros coches de la colección y otros juguetes que fabrica la empresa. Control de stock visual.
La pintura sirve para todas las bases de zamac de juguetes del mismo color. Se pinta
agrupando lotes semanales de productos del mismo color.
Las pegatinas son exclusivas de este modelo, vienen en paquetes de 500 unidades. Control
de stock visual.
La suma del coste de las cajitas expositoras, los tornillos, la pintura y las pegatinas suponen
menos del 5% del coste total del producto, por lo que se decide la siguiente simplificación de la
configuración de ingeniería en el ERP:
Producto Componentes Consumo Operaciones

Ford - Embalaje, QC
Rally
Chasis 1 ud Pintar, poner pegatinas
Chasis 1 ud Art. Compra
(zamac)
Base (ABS) 1 ud
Art. Compra
Eje (2 ruedas) 2 ud
Art. Compra
Otros - Sin control de stock, a efectos de
imputación de costes
Tabla 3. Ejemplo de ingeniería ajustada a la información relevante.
33
SOFTWARE ERP
Este tipo de simplificaciones suponen aproximaciones al modelo real ideadas para reducir la
cantidad de órdenes de producción a lanzar, los fichajes, los artículos con stock a controlar y las
estructuras de ingeniería que hay que mantener. Una decisión de este tipo puede ahorrar a la
empresa cientos de horas de gestión al cabo del año.
Por otra parte, un error por exceso de simplificación puede acarrear que se disponga de
información insuficiente sobre la producción, costes, márgenes o también sobre las estadísticas
de ventas.
1.2. Ventas.
A grandes rasgos, al personal de gestión comercial “le compran”, mientras que la fuerza de
ventas se dedica activamente a vender.
1.2.1. Gestión comercial.

El área de gestión comercial está integrada por personal con habilidades comerciales que
realizan tareas administrativas relacionadas con las ventas. Están supervisados por la figura de
la Dirección Comercial. Sus atribuciones pueden incluir:
- Conocer bien los productos que ofrece la empresa.

- Comunicarse con soltura con los clientes en un idioma en el que aquellos se
desenvuelvan con comodidad, preferiblemente el suyo.
- Recibir solicitudes de presupuesto de clientes habituales.
- Proporcionar toda la información detallada que necesiten los clientes para solicitar sus
presupuestos de acuerdo con sus necesidades, sin ambigüedades ni errores.
- Informar a los clientes de forma detallada de las condiciones comerciales de las ventas:
opciones, precios y descuentos, plazos de entrega, condiciones de garantía, formas y
plazos de pago, etc.
- Preparar la documentación y los contratos de acuerdo con las necesidades de las
transacciones comerciales, atendiendo a las leyes aplicables en cada caso: hojas de
pedido, albaranes de entrega, listas de embarque, documentación aduanera, facturas.
- Mantener a los clientes informados del estado de avance de la preparación de sus
pedidos y de cualquier incidencia relacionada. Por ejemplo: alteración de los plazos de
entrega o informar de cuándo un pedido ha sido expedido.
- Informar a Dirección Comercial de las necesidades detectadas en el curso de la relación
con los clientes que no están previstas en la oferta de productos y servicios relacionados
de la empresa. Por ejemplo: preguntas reiteradas por la disponibilidad de un producto en
un determinado color no disponible.
- Asistir a la fuerza de ventas cuando lo necesiten.
Este tipo de actividades implica que habitualmente utilizarán el ERP desde su equipo de
escritorio. Se requieren interfaces de usuario ágiles, diseñadas de manera que se puedan utilizar
indistintamente con teclado y ratón o solamente con teclado (y teclas de atajo), según las
preferencias de cada usuario. Es deseable que se puedan configurar menús personalizados con
las opciones más frecuentemente utilizadas, que las pantallas ofrezcan acceso fácil a la
modificación de datos y que estén diseñadas con controles automáticos para reducir la
posibilidad de error.
34
SOFTWARE ERP
Se valorará:
- Si la ingeniería de los productos que fabrica la empresa está muy compleja y la

capacidad de las interfaces de imputación de documentos comerciales para adaptarse a
esta naturaleza. Se deberá estudiar la mejor aproximación a esta implementación
(estructurándola en mayor o menor medida) para alcanzar un equilibrio entre facilidad
de uso y estructura de la información para reducir la ambigüedad de las instrucciones a
producción o también para posteriormente poder obtener información útil de
estadísticas de ventas.
- Las facilidades de automatización disponibles, como las plantillas de documentos. Los
documentos básicos de esta etapa del proceso comercial son el presupuesto o propuesta
de pedido y el pedido.
- Las facilidades para establecer datos habituales como valores por defecto, como el tipo
de impuestos aplicables según el cliente.
- Las facilidades para incluir datos desde un documento relacionado sin necesidad de
teclear de nuevo, como por ejemplo: crear un pedido a partir de una selección de líneas
de propuestas de pedido anteriormente creadas del mismo cliente.
- La cantidad de tiempo necesaria para elaborar un documento comercial completo.
- La flexibilidad del sistema para cambiar la configuración de valores por defecto,
formatos comerciales, etc., así como el esfuerzo necesario para llevar a cabo estos
cambios.
- La posibilidad de disponer descripciones personalizadas en distintos idiomas para los
artículos, incluyendo idiomas con disposición RTL y alfabetos distintos a los
occidentales.
- La posibilidad de utilizar unidades de medida alternativos, como el imperial frente al
métrico decimal, y funciones de conversión automáticas.
1.2.2. Fuerza de ventas.

El área de fuerza de ventas está integrada por agentes comerciales de la empresa o
representantes externos. Están supervisados por la figura de la Dirección Comercial. Sus
atribuciones pueden incluir la mayoría de las mismas que las del personal de gestión comercial,
con algunos cometidos adicionales:
- Establecer relaciones de confianza y detección de necesidades de nuevos clientes

mediante visitas, llamadas, correos personalizados, etc.
- Generar nuevas oportunidades comerciales con los clientes nuevos y con los ya
existentes.
- Estar al tanto de las actividades de la competencia.
- Investigar los intereses de los clientes y transmitirlos a Dirección Comercial.
- Llevar a cabo actuaciones coordinadas con el personal de marketing para impulsar las
ventas, como eventos y campañas.
- Investigar nuevos mercados.
- Reportar su actividad periódicamente a Dirección Comercial.
- Diferencia: en algunos casos la elaboración de la documentación comercial se delega al
personal de gestión comercial.
El trabajo de los agentes comerciales es más dinámico y requiere herramientas que les
permitan realizar parte del trabajo fuera de la oficina o durante sus visitas a los clientes. Es
habitual que usen ordenadores portátiles pequeños y ligeros, tabletas digitales y smartphones.
Estos equipos deben disponer de las herramientas adecuadas de conectividad que faciliten
35
SOFTWARE ERP
acceso a los recursos que los comerciales necesitarán usar en sus procesos de ventas: catálogos
digitales, información técnica, tarifas, fotografías, planos, etc.
Se valorarán:
- Características del ERP para gestión CRM o funcionalidades de integración con

software CRM11 de terceros.
- Aplicaciones para dispositivos móviles (tabletas digitales, smartphones) especialmente
diseñadas para acceso a aquella información comercial que les pueda resultar más útil.
También se valorarán las posibilidades de personalización que ofrezcan las interfaces de
usuario de estas aplicaciones.
- Posibilidades de conexión remota a información del ERP en tiempo real, por ejemplo:
estado de los pedidos, disponibilidad de existencias, situación comercial de clientes, etc.
1.3. Finanzas.
Los requerimientos básicos del área financiera incluirán gestión de los distintos aspectos de
la gestión económica de la empresa de acuerdo con la legislación vigente. Por este motivo es
muy importante que el fabricante garantice que el funcionamiento de este módulo esté siempre
actualizado y sea conforme con el cumplimiento de las leyes aplicables a las operaciones
mercantiles y a las obligaciones fiscales.
1.3.1. Contabilidad financiera.

Es la contabilidad oficial que las empresas están obligadas a presentar por ley. Está
normalizada según una estructura normalizada definida por las Normas Internacionales de
Contabilidad12. Entre los documentos que la contabilidad financiera provee destacan la cuenta
de Pérdidas y Ganancias, el Balance de Situación y la Memoria Anual de cuentas.
Todas las operaciones económicas se registran en el libro diario en orden cronológico en

forma de asientos. Cada asiento se estructura en forma de apuntes. Cada apunte se realiza en una
cuenta contable. La vista del libro diario ordenado por cuentas contables constituye el libro
mayor, en el que cada hoja presenta las operaciones relacionadas con una determinada cuenta
contable.
Características habituales en los módulos contables de los ERP:
- Generación automática de asientos.

- Búsquedas avanzadas de apuntes por cuenta, importe, fechas.
- Comprobaciones (punteo) de apuntes relacionados entre sí.
- Herramientas avanzadas de edición de asientos.
- Configuración de cuentas contables vinculadas a las operaciones de compras, ventas,
amortizaciones, cobros, pagos, impuestos y cuentas bancarias.
- Herramientas para facilitar la gestión de las operaciones en divisas.
1.3.2. Contabilidad analítica.

También denominada contabilidad de costes. No es obligatorio mantenerla, sin embargo a
muchas empresas les interesa aplicarla para conocer la eficiencia del uso de sus recursos y poder
así tomar medidas encaminadas a incrementar la rentabilidad de los mismos.
36
SOFTWARE ERP
Las características básicas de un ERP en cuanto a contabilidad de costes son:
- Definición de los centros de coste.

- Definición de las cuentas de reparto para cada tipo de coste.
- Procesos automáticos que generarán la atribución de costes a cada centro.
- Herramientas de análisis por diferentes criterios, por ejemplo: centro de costes, por
cliente, por productos o familias de productos…
1.3.3. Facturación.
La facturación es el proceso por el que se genera un documento mercantil que acredita una
transacción comercial entre un proveedor y un cliente y que incluye toda la información
relacionada.
A continuación, características habituales en los módulos de facturación de un software ERP:
- Facilidades para relacionar una factura con los pedidos y albaranes de los que incluye
líneas, así como la posibilidad de trasladar líneas de pedidos y albaranes en las facturas,
sin introducirlas de nuevo.
- Facilidades para relacionar abonos o facturas rectificativas con las rectificadas.
- Facilidades para relacionar facturas de anticipos con la factura final.
- Integración con contabilidad financiera: generación automática de asientos.
1.3.4. Cobros, pagos, vencimientos, remesas.

La gestión de cobros y pagos vincula la tesorería con las compras y con las ventas
(facturación). La negociación de cobros y pagos tiene un impacto directo en los flujos de caja.
Características habituales en los módulos de cobros y pagos de los ERP:
- Herramientas para facilitar la gestión de las operaciones en divisas: obtención de

contravalor en tiempo real, agrupación y división de cobros y pagos en divisas,
localización de operaciones por sus importes en divisa, etc.
- Configuración de formas de cobro y pago.
- Configuración de vencimientos. Las relaciones comerciales requieren flexibilidad en las
formas de cobro: periodos de no cobro y/o pago; facilidades de automatización del
cálculo de vencimientos por porcentaje, importe o mixtos; integración con normas
bancarias para automatizar los vencimientos con las entidades financieras;
modificaciones de vencimientos; anticipar giros; añadir/excluir vencimientos de
remesas emitidas, etc.
- Integración con contabilidad financiera: generación automática de asientos.
1.3.5. Tesorería, previsión de necesidades y financiación.

Los flujos de caja determinan la evolución en el tiempo del saldo positivo o negativo de los
recursos de tesorería en función de las entradas y salidas. Por tanto, tiene un impacto directo en
las necesidades diarias de tesorería. Por otra parte, un examen de las necesidades de tesorería
con suficiente antelación sirve para determinar si la empresa dispone de recursos propios
suficientes o necesita financiación externa, y en este caso negociarla en buenas condiciones.
37
SOFTWARE ERP
Como consecuencia de todo esto, una buena gestión de cobros y pagos puede suponer una
reducción importante de los costes financieros.
Entre las características que podemos encontrar en los ERP se encuentran herramientas de
ayuda para determinar de forma anticipada flujos de caja, en forma de consultas por pantalla,
listados, gráficos, cuadros de mando de tesorería, etc.
1.3.6. Gestión del riesgo.

El riesgo comercial es la incertidumbre de cobro en que incurre una empresa por el hecho de
aceptar el compromiso de servir un pedido a un cliente en una fecha, y equivale al valor de
venta del pedido, una vez excluidos los anticipos si los hubiese. El riesgo financiero es el valor
no cobrado aun de la mercancía ya servida. El riesgo puede ser asumido en su totalidad por la
empresa o bien puede ser asegurado total o parcialmente por un precio por una compañía
externa de crédito y caución.
El software ERP puede ayudar a la gestión del riesgo si incluye:
- Indicación de los capitales asegurados, la compañía aseguradora y la fecha de vigencia

de la autorización de riesgo concedido para cada cliente.
- Automatización del cálculo del riesgo a una fecha dada teniendo en cuenta las
operaciones con cobros pendientes de vencimiento.
- Posibilidad de consultas de riesgo y su evolución en el tiempo de toda la cartera o por
cliente.
1.3.7. Conciliación bancaria.

Las empresas obligadas a mantener una contabilidad oficial deben cuadrar exactamente los
movimientos bancarios con su contabilidad. La conciliación consiste en cotejar los apuntes de
los asientos contables con los movimientos bancarios.
Algunos ERP permiten realizar este proceso de una forma semiautomatizada: basándose en
los importes y en las fechas, pueden presentar una sugerencia sobre a qué apunte contable
corresponde cada entrada o salida en las cuentas bancarias, a fin de que el usuario la valide o
rectifique. La norma 43 de la AEB13 define una estructura unificada de los ficheros en formato
digital para realizar estas operaciones.
1.3.8. Amortizaciones.
La amortización es un instrumento financiero que permite contabilizar la depreciación de los
activos a lo largo del tiempo, en lugar de hacerlo por su importe total en el ejercicio fiscal en
que se adquirieron. Este instrumento puede suponer una ventaja fiscal importante para las
empresas.
El software ERP puede ayudar a gestionar las amortizaciones si incorpora procesos de

generación asistida de las fichas de amortización, que definen los importes amortizables
basándose en:
- Los métodos de cálculo que autorizan las leyes vigentes para cada tipo de activo.
- Entre los métodos legalmente aplicables, aquellos que interesen más a la empresa.
38
SOFTWARE ERP
1.3.9. Impuestos.
Entre las obligaciones legales de las empresas figuran las fiscales, las mercantiles o las
estadísticas. Existen numerosos modelos de declaraciones informativas y autoliquidaciones de
impuestos que deben presentarse en tiempo y forma ante las autoridades competentes.
Es importante remarcar que el ERP debe gestionar la información de acuerdo a las leyes
vigentes, y el fabricante anticipar la entrada en vigor de nuevas leyes, modificaciones que
resulten en una obsolescencia del tratamiento de la información o de los procesos que se
ejecutan. Ejemplos: cambio de la peseta al euro, en 2002, o el sistema de información inmediata
a la agencia tributaria española, en 2017.
El ERP cuenta con la mayor parte de la información necesaria para la elaboración de estos
modelos, y es habitual que entre sus características se encuentre la posibilidad de generarlos e
incluso conectar con servicios de presentación online.
1.4. Recursos humanos.

Si el módulo de recursos humanos cuenta con una gestión de nóminas, el fabricante debe
garantizar su adecuación a ley. Los cambios en este ámbito suelen ser frecuentes en España, de
manera que si el módulo debe calcular el importe de nóminas de cierta complejidad será una
parte del ERP muy especializada que requerirá actualizaciones tan frecuentes como los cambios
legales exijan. Por este motivo, algunos ERP ofrecen una interfaz básica que permite imputar
directamente los totales o importar desde otro software las cuantías de las nóminas con el fin
únicamente de generar los apuntes contables. Los ERP que no cuentan con esta característica
aun permiten generar manualmente los asientos en contabilidad.
Las fichas de los operarios pueden incluir: datos personales básicos, categoría profesional,
perfiles de cualificación, horarios y centros de trabajo, datos de absentismo, gestión de
solicitudes de permisos con o sin retribución y las fechas. Además, también pueden incluir coste
por unidad de tiempo, información que se podrá utilizar en los procesos de cálculo de costes de
producción. El ERP puede además contar con funciones de control de presencia, y facilitar el
acceso a datos estructurados de los empleados: control de presencia, vacaciones pendientes, etc.
En algunas empresas la configuración de turnos de trabajo es compleja. Entonces se requiere

de herramientas avanzadas para la optimización de turnos teniendo en cuenta todas las
restricciones aplicables (necesidades de la producción, requisitos legales, descansos
obligatorios, etc.). Si el ERP no dispone de esta función también puede ser aceptable una
integración con otra aplicación específica para este cometido.
39
SOFTWARE ERP
1.5. Producción.
El siguiente diagrama de flujo muestra una aproximación a grandes rasgos de un entorno de
producción simplificado.
Ilustración 1. Flujo de trabajo de ejemplo.

1. Comercial graba los pedidos de venta.
2. A partir de la ingeniería de los productos vendidos, se generan las órdenes de

fabricación necesarias. Para esto hay que tener en cuenta las existencias:
a. De producto terminado
b. De componentes semielaborados
c. De materias primas
40
SOFTWARE ERP
Para el cálculo de existencias es necesario tener en cuenta:
- El stock físico
- Las unidades de fabricación que están en curso
- Las unidades de compras que están pedidas a proveedor
- Las unidades en pedidos de ventas
El stock disponible a una fecha dada será un cálculo basado en estos valores.
3. A partir de la carga de trabajo completa de la fábrica, priorización de las órdenes de

trabajo y lanzamiento a fabricación de un lote seleccionado. Los criterios pueden ser
heterogéneos: agrupación por lotes para mejorar los costes de producción, reducción de
tiempos de cambio de tareas, tipos de piezas o ajuste de maquinaria, agrupación por
colores o tamaños, fechas de entrega comprometidas con los clientes, criterios laborales
por nivel de penosidad de las tareas, etc.
4. Al mismo tiempo, la gestión de compras debe procurar la entrega en los plazos más
convenientes a cuando se vaya a utilizar los materiales o los productos de
subcontratación.
5. Una vez terminado el lote de OF, la mercancía se lleva desde el almacén a la zona de
expediciones (picking) para preparar su expedición (packing), junto con toda la
documentación necesaria: albaranes, listas de embarque y etiquetas identificativas de
producto y de envío en los embalajes.
Entre las características habituales presentes en los ERP modernos para la producción
destacan:
- La generación automática de órdenes de fabricación a partir de los pedidos de clientes.

- Agrupación de órdenes de fabricación por criterios configurables, como los ya
expuestos en el párrafo 3.A más arriba.
- Fichaje de operaciones contra órdenes de fabricación. El progreso de estos fichajes
debería también de forma automática generar la entrada en existencias de los
semielaborados y productos terminados y a su vez la salida en existencias de los
componentes consumidos. Puede ir ligado a las funciones de control de presencia.
- Registro de costes reales de fabricación a partir de los tiempos de ejecución de las
órdenes y las mermas de materias primas y componentes que hayan registrado los
operarios.
- Registro de incidencias en la producción y atribución a causas relacionadas o no con las
órdenes. Puede afectar al cálculo de los costes reales.
- Facilidades para planificación de la producción. Puede disponer desde una planificación
básica basada en la carga de trabajo actual de la fábrica hasta sistemas de planificación
más avanzados como MRP o MRP II. Por norma general, planificación más avanzada
implica mayor carga de gestión, de manera que es importante valorar la relación
coste/beneficio. Puede que la empresa necesite ser más flexible en lugar de gestionar su
producción de una manera más rígida.
- Picking de aprovisionamiento de componentes hasta el emplazamiento de su consumo,
puede estar basado en terminales móviles tipo PDA o tabletas digitales especialmente
diseñadas para uso en entornos industriales. Pueden disponer de lectores de códigos
impresos (EAN, QR) o de etiquetas de identificación por radio frecuencia (RFID).
- Gestión de la trazabilidad. Una adecuada identificación de los lotes de fabricación de
cada componente puede permitir determinar las causas de un defecto de fabricación
41
SOFTWARE ERP
tiempo después que el producto final haya llegado a su destino, procedencia, fechas,
operarios, etc. Esta gestión supone una sobrecarga administrativa importante. Es
obligatoria en algunos sectores, como la alimentación o el aeroespacial, donde la
seguridad es extremadamente importante.
1.6. Logística.
Es frecuente que la entrega de los bienes o servicios esté acreditada mediante un documento
denominado albarán o nota de entrega. A veces también existe un documento complementario
denominado lista de embarque. El albarán puede ir o no valorado, y puede incluir información
de todo un envío. La información debe ser coherente con la de la factura, en especial si las
mercancías tienen que pasar controles aduaneros. Por su parte, la lista de embarque contiene el
detalle de un determinado embalaje o conjunto de embalajes, con identificación de los bultos y
el contenido de cada uno de ellos.
Una vez que la mercancía prevista para una expedición está disponible en los almacenes, la
preparación de las expediciones (picking, packing) basadas en terminales móviles, de igual
manera que se ha descrito para el picking de producción.
Por otra parte, las funciones del ERP en cuanto a logística de aprovisionamiento deben
proveer las facilidades de seguimiento necesarias de trabajos externos y compras para asegurar
que estos componentes llegan con antelación suficiente para su utilización en fábrica.
Los sistemas avanzados en industrias avanzadas como la del automóvil disponen de una
secuenciación que provee las piezas en el preciso instante de su utilización (sistemas JIT, Just In
Time). Aunque su complejidad es elevada, se reducen la manipulación, los costes y los errores.
1.7. Almacén.
La gestión de almacenes determina la correcta ubicación en cada momento de materias
primas, semielaborados y otros activos como utillajes o piezas de recambio. Está vinculado a la
valoración de inventario. La automatización del registro de movimiento de materiales (entradas,
salidas, desplazamiento a otra ubicación), supone un gran avance para facilitar la localización de
las mercancías. Esta automatización se puede alcanzar con dispositivos preparados para trabajar
con tecnologías específicas como códigos de barras o etiquetas de identificación por
radiofrecuencia.
En cuanto a los ERP, muchos de ellos disponen de módulos de gestión de almacén. El

trabajo de esta parte de las aplicaciones se centra en:
a) Obtener el mejor aprovechamiento posible de las ubicaciones de acuerdo a la naturaleza

de los materiales que vayan a contener.
b) Obtener el mejor rendimiento posible en cuanto a los movimientos de materiales, en
función de parámetros como la frecuencia de uso o los recorridos habituales que hagan
estos materiales (inteligencia de ubicación).
Incluso en almacenes relativamente pequeños, si los materiales no están codificados de
forma adecuada o no se registran de manera precisa todos los movimientos, a efectos prácticos
es como si estuviesen perdidos, con la consiguiente pérdida de su valor. Esta situación
permanecerá al menos hasta la siguiente verificación de inventario. Incluso entonces, realizar las
correcciones oportunas tiene un coste más elevado de gestión y manipulación.
42
SOFTWARE ERP
En aquellas empresas donde las necesidades no quedan cubiertas con los módulos estándar
de gestión de almacén del ERP, es habitual encontrar Sistemas de Gestión de Almacén (SGA)
como aplicaciones informáticas específicas para este propósito, y que se deben integrar con el
ERP.
Otras funciones avanzadas de este tipo de aplicaciones pueden incluir:
- Control de lotes: usado en empresas que controlan la trazabilidad de los productos y sus
componentes.
- Picking guiado por voz: instrucciones simples guían al operario de almacén.
- Picking guiado por luz: indicaciones luminosas guían al operario de almacén.
- Picking agrupado (pick to box): agrupa en una ruta el picking y se va depositando
directamente en las cajas de envío o en una gaveta para su posterior embalaje.
- Gestión de ubicaciones que puedan contener varios artículos.
- Gestión de ubicaciones de distintos tamaños y que puedan contener distintos tipos de
contenedores.
- Gestión de distintos formatos de ubicación para un mismo artículo.
1.8. Compras.
La gestión de compras se divide en dos grandes grupos: proveedores de bienes o trabajos
directamente relacionados con la producción, y acreedores para todo lo demás.
1.8.1. Acreedores.
Se trata de suministros de bienes o servicios no relacionados directamente con la actividad
principal de la empresa, como, por ejemplo, gastos de telecomunicaciones o alquileres. La
imputación de facturas de acreedores no requiere en muchos casos informar en el ERP el
detalle, basta indicar los importes totales, los impuestos aplicables y las cuentas de gastos a las
que se imputarán los asientos contables correspondientes. En muchas ocasiones no estarán
relacionados con un pedido previo.
El ERP puede implementar facilidades como valores por defecto y formularios diseñados
para agilizar la imputación de este tipo de facturas, la generación de los vencimientos de sus
pagos y los asientos contables automáticos.
1.8.2. Proveedores.
Se trata de suministros de bienes o servicios relacionados directamente con la actividad
principal de la empresa, como, por ejemplo, materias primas utilizadas en la fabricación de los
productos. Suelen tener un ciclo de documentación que comprende pedido de compras – albarán
de recepción – factura.
La imputación del pedido de compra puede ser manual. Entre los requisitos deseables del
ERP están:
- Facilidades para el mantenimiento de tarifas de proveedor.

- Recepción basada en dispositivo móvil y vinculado a líneas de pedidos de compra
pendientes de recepción, con posibilidad de modificar las unidades recibidas.
- Generación de albaranes de recepción sin pedido previo, también basado en dispositivos
móviles.
- Generación de facturas a partir de una selección de líneas de albaranes de recepción.
43
SOFTWARE ERP
- Facilidades para relacionar códigos y descripciones de artículo propias del proveedor

con otras propias en el ERP de la empresa.
- Entrada automática de existencias al crear los albaranes de recepción, con indicación
del almacén.
- Gestión de devoluciones.
- Imputación de costes marginales de importación a la mercancía (aranceles, costes de
transitarios).
1.9. Dirección.
Uno de los ámbitos más habituales de las necesidades de Dirección se centra en la obtención
de conocimiento útil para la toma de decisiones. Los datos de los sistemas transaccionales
(ERP) son procesados para obtener información, a partir de la cual a su vez se puede generar
conocimiento14. Entre las herramientas que podemos encontrar para este cometido se encuentran
consultas, informes y cubos multidimensionales.
Entre las necesidades que puede tener la Dirección encontramos:
- Cuadros de mando para Dirección Financiera: evolución financiera, balance y PyG

siempre al día.
- Cuadros de mando para Dirección Comercial: análisis de ventas, clasificación y
fidelización.
Otros usos departamentales para BI:
- Cuadros de mando para control de Tesorería: flujos de caja, previsiones.

- Mejora de costes de almacenamiento mediante ajuste del aprovisionamiento.
El grado de madurez actual de las tecnologías de la información ha permitido la penetración
en las organizaciones de aquello que se ha denominado “estrategias digitales”: analítica de
datos, automatización de procesos, gestión por procesos (workflow / BPM 15 ), oficinas sin
papeles, sistemas de gestión documental, etc.
El verdadero reto ahora está en desplazar el foco de dicha estrategia digital a la recuperación
del verdadero objetivo importante: el desarrollo de las estrategias de la empresa utilizando las
herramientas de las que ya nos ha provisto la transformación digital. Este es un argumento
importante para ayudar a la Dirección en las empresas.
La mayoría de los ERP disponen de herramientas más o menos avanzadas para la

elaboración de consultas e informes, basados en criterios simples de filtrado, agrupación y
ordenación. Estas son las herramientas más básicas que podemos considerar para la gestión del
conocimiento y están disponibles desde hace décadas en los sistemas de información.
Por otra parte, de forma más reciente han aparecido en el mercado numerosas aplicaciones
software en el ámbito de la inteligencia de datos16. Los ERP pueden disponer de módulos que
cubren este propósito, aunque es frecuente que las empresas prefieran integrar aplicaciones
específicas de terceros e integrarlas con su ERP.
Las herramientas de BI se han posicionado en los últimos años como una evolución más
potente a los clásicos listados en papel, para los que era necesario que un técnico configurase
cada plantilla de informe solicitado. En estas aplicaciones el usuario toma parte activa y cambia
la presentación de la información de acuerdo con sus necesidades, mediante el uso de interfaces
44
SOFTWARE ERP
de usuario especialmente diseñadas para este propósito. La decisión acerca del sistema elegido
dependerá de varios factores: precio de licencias; facilidad de uso y cambio para el usuario;
rendimiento; requisitos técnicos: consumo de memoria, tiempo requerido por los procesos de
extracción, transformación y carga y, por último, esfuerzo requerido para la preparación de las
nubes de datos por personal técnico.
45
SOFTWARE ERP
2. Evaluación de requerimientos.
En el apartado anterior hemos visto una descripción de los procesos habituales en cada área y
las correspondientes funciones en el ERP que dan respuesta a las necesidades.
La evaluación de requerimientos debe realizarse desde un procedimiento sistematizado y

exhaustivo. A continuación se describe una posible aproximación a este proceso.
2.1. Entrevistas con los usuarios clave de cada área.

Consiste en una ronda de entrevistas personales con los usuarios clave. Si se detectan dudas
o cuestiones a debatir con otras personas, se anotarán para consulta posterior. Es importante
convocar solamente a las personas que pueden aportar la información más cualificada sobre los
procesos de cada área, esto supone una muestra de respeto por el tiempo de cada persona, hace
las reuniones más eficaces, evita los “convidados de piedra” y la sensación de estar perdiendo el
tiempo.
La recopilación de información debe comprender al menos:
- identificación de los procesos,

- detalles de los flujos de trabajo,
- interrelación temporal o funcional con otros procesos,
- actores involucrados,
- mecanismos de seguimiento y control y
- documentación asociada.
Esta información puede ser redactada en lenguaje natural, pero aun así es útil preparar, a
partir de las anotaciones, diagramas de flujo esquemáticos que describan de una forma gráfica y
pongan en relación todos estos elementos anteriormente enumerados. Estos diagramas pueden
ser presentarlos a los usuarios clave para su validación y sirven como realimentación para el
avance y detección de errores de interpretación.
Es conveniente que estas entrevistas sean llevadas a cabo por personal con la suficiente
experiencia en gestión de las áreas involucradas. También es útil que conozcan las funciones
que implementa el ERP en las áreas analizadas. Este conocimiento puede facilitar el modelado
posterior de las tareas en el ERP.
A partir de estos diagramas se elaborarán los procesos piloto, ya sobre las propias interfaces
de usuario del ERP, que constituirán las pruebas unitarias descritas más adelante.
2.2. Revisión de procedimientos.

Es posible que durante esta fase de observación se identifiquen procesos que se llevan a cabo
de una forma que llame la atención a los analistas, por distintos motivos:
- Se llevan a cabo con una complejidad aparentemente innecesaria

- Excesiva dependencia de determinadas personas
- Las llevan a cabo personas que claramente sufren una sobrecarga de tareas
- No tienen un responsable definido o se ejecutan sin un criterio uniforme
- Es muy costoso mantenerlas externalizadas
- Es muy costoso realizarlas dentro de la empresa
46
SOFTWARE ERP
- Se llevan a cabo de una manera ineficiente

- Resultan innecesarias en la actualidad
Estos problemas se pueden identificar y documentar, y a continuación delegar la revisión.
Puede ser el responsable de gestión de la Calidad u otros mandos intermedios. Estos procesos
deberán quedar establecidos como validados o bien como revisados preferiblemente antes del
final de esta fase y en cualquier caso antes de la fase siguiente de pruebas unitarias en las que se
validarán los circuitos de información.
2.3. Interdependencias, cuellos de botella y secuencialidad.

Se puede elaborar un diagrama de Gantt simple que sirva como guía con la estimación del
plan de ejecución del proyecto de implantación. El conocimiento de este plan permitirá a los
usuarios conocer con antelación suficiente cuándo se les requerirá dedicar tiempo a las
exigencias de la implantación y evaluar el estado de avance. Para esto también es importante
que el Gantt se revise periódicamente para incluir las modificaciones que sean necesarias de
acuerdo con la marcha del proyecto.
Este diagrama debe ser consensuado también con los usuarios clave de manera que se
puedan validar las interdependencias de tareas, es decir, aquellas que no pueden ser acometidas
hasta que se hayan solventado otras de las que dependen. También permitirá anticipar cuellos de
botella de recursos o a causa de la naturaleza de las tareas, y en algunos casos reorganizar la
asignación de recursos para permitir el paralelismo de tareas cuando convenga.
En cuanto a la secuencialidad de la implantación, la planificación puede variar mucho

dependiendo de factores como:
- Los recursos disponibles.

- El nivel de gestión de partida.
- Las necesidades operativas y/o de plazos de la empresa.
Abordar muchos cambios simultáneamente puede ser muy problemático, de manera que lo
más recomendable es establecer las fases separadas que se pueda, para poder estabilizar el uso
de cada módulo o grupo de módulos antes de añadir mayor complejidad al proyecto.
A continuación se incluye un diagrama de este tipo a modo de ejemplo:
Ilustración 2. Ejemplo de diagrama de Gantt17
47
SOFTWARE ERP
3. Pruebas.
Las pruebas del sistema se clasifican en:
- Pruebas funcionales, centradas en la verificación de la lógica de los flujos de trabajo y

comprobación de que corresponden al proceso que modelan. En este grupo entran las
pruebas unitarias, las pruebas funcionales, las pruebas de integración y las del sistema
completo.
- Pruebas destinadas a determinar la respuesta del sistema de información ante
determinados escenarios, como cargas de trabajo elevadas, errores y fallos accidentales
o provocados.
3.1. Pruebas unitarias.

A partir de los flujos de trabajo recopilados en las entrevistas con los usuarios ya se pueden
preparar pruebas piloto. Estas pruebas deben cumplir:
- Utilizar datos lo más asemejados posible a los reales.

- Deben incluir ejemplos que recojan la casuística más variada.
- Deben tener en cuenta casos hito o casos límite, es decir, casos que si bien no se dan
con mucha frecuencia es importante que cuando se dan se puedan resolver sin
incidencias, como por ejemplo: cierres contables, presentación de impuestos, ajustes de
inventario, facturas rectificativas, modificación de datos por error humano o fallo
técnico, etc.
Cada prueba piloto preparada debe ser mostrada a los usuarios que la deben validar. Si la
demostración es aceptada, se puede formar a los usuarios para que puedan practicar con el
sistema mientras reproducen la prueba con distintas variantes de casos reales. Se les puede
asignar un plazo relativamente corto para llevar a cabo esta validación, no más de una semana.
Es responsabilidad del líder del proyecto o sus delegados confirmar que tras el plazo pactado los
usuarios han llevado a cabo las tareas encomendadas, y obtener la realimentación pertinente:
- Número y variedad de casos probados.

- Qué dificultades han encontrado.
- Qué partes del proceso se pueden mejorar en funcionalidad, rendimiento, número de
pulsaciones u otras facilidades.
- Qué casos no se han podido resolver.
- Qué casos no probados prevén que pueden plantear problemas.
Después de la primera evaluación se puede valorar si hay que realizar o no ajustes de alguna
clase en el proceso, puede tratarse de:
- Ajustes de configuración.
- Alguna clase de adaptación de las interfaces de usuario.
- Definir un caso en la documentación de procedimientos internos para gestionarlos de
forma especial. Esto puede darse si el caso descubierto se da con muy poca frecuencia y
no interesa cambiar nada más en el software.
Una vez hechos los ajustes y de nuevo validados por los usuarios, se contará con un conjunto
consistente de pruebas unitarias y el proyecto puede dar paso a las pruebas funcionales.
48
SOFTWARE ERP
Posponer las modificaciones del estándar

Es importante tomar conciencia de que esta fase no se debe utilizar para solicitar una serie de
adaptaciones del software con la finalidad de asimilar su comportamiento a “la forma habitual
en que se venían haciendo las tareas hasta ahora”. El equipo consultor debe ser capaz de
distinguir en qué casos hay un problema con un proceso que no se puede modelar en el nuevo
ERP, que ocurrirá rara vez, y en qué otros casos los usuarios deben adaptarse dentro de lo
razonable a una nueva forma de trabajar.
Presumiblemente el ERP elegido contará con procesos diseñados con una base de buenas
prácticas en el sector en cuestión, y no supondrá cambios aberrantes en el desarrollo de las
tareas cotidianas.
Esto implica que se deben restringir con rigor en esta etapa la cantidad de adaptaciones del
ERP a las que se de paso para su solicitud como modificaciones del software, sujetas por lo
tanto a un ciclo completo de análisis, valoración de esfuerzo, aprobación presupuestaria,
desarrollo a medida, instalación, pruebas y validación.
En los casos en que esto no se tiene en cuenta, la mayoría de las modificaciones son probadas
como innecesarias o irrelevantes al cabo de poco tiempo (meses) de su instalación.
Por el contrario, ofrece mejores resultados esperar a que el estándar, con la menor cantidad
posible de modificaciones, haga su “rodaje” en la empresa durante un tiempo, transcurrido el
cual si se evalúa que una modificación es aconsejable, puede pasar a evaluación de
viabilidad.
Recuadro 2. Posponer las modificaciones del estándar.
3.2. Pruebas funcionales.

Las pruebas funcionales son bastante más complejas, debido fundamentalmente a que deben
tener en cuenta todas las interacciones entre flujos de trabajo de diferentes áreas de gestión. Se
pueden dibujar diagramas que reflejen los procesos principales de la gestión de la empresa o
macroprocesos y sus interrelaciones. Una herramienta gráfica recomendable son los diagramas
en notación BPMN 18 . Existen numerosas aplicaciones software que permiten diseñar con
rapidez diagramas con esta notación, y son relativamente fáciles de comprender por personal no
técnico.
Las interrelaciones entre elementos de un proceso pueden darse por vencimiento temporal,
periódicamente, por eventos de mensaje generados por una persona u otro proceso automático,
etc.
Nuevamente en esta etapa debe primar la directiva de atenerse al estándar y minimizar el

número de adaptaciones.
Algunas clasificaciones consideran también las pruebas de aceptación. En la práctica, para la

mayor parte de los escenarios, se pueden orientar las pruebas unitarias y las pruebas funcionales
de manera que se utilicen también como pruebas de aceptación, dado que se someten a
evaluación por parte de los usuarios.
Al contrario que las pruebas unitarias, en las que puntualmente se puede ver involucrado más
de un usuario, para las pruebas de integración se debe poner en práctica un flujo de trabajo de
ámbito mayor que con frecuencia afectará a más de un usuario. La comunicación entre estas
personas debe integrarse como parte de la prueba, de manera que se pueda verificar que el flujo
de trabajo será completo durante la ejecución de las instancias de este proceso una vez
implantado el ERP y los usuarios estén operando de forma cotidiana.
49
SOFTWARE ERP
La figura siguiente describe de forma gráfica un ciclo de ventas hipotético. Se identifican al

menos cinco roles. A partir de la figura se describen algunas de las pruebas funcionales que se
podrían realizar a partir de este flujo de trabajo.
Ilustración 3. Ejemplo de proceso de ventas.

Con el proceso de solicitud de oferta pueden ir implícitos otros subprocesos como el de
cualificación y alta de cliente o el de autorización de la operación por parte de Dirección
Comercial.
Como parte del acuerdo de los detalles de la operación, productos, plazos de entrega y
condiciones de pago, puede que de nuevo deba intervenir Dirección Comercial y a veces
también alguien de finanzas para autorizar el riesgo o asegurar la operación si procede.
La generación de las órdenes de fabricación puede desencadenar todo un subproceso

completo de aprovisionamiento de materias primas y de semielaborados, que a su vez pueden
implicar al departamento de Compras, a Logística, en algunos casos a Finanzas y a
Administración.
El proceso de expedición afecta a almaceneros, picking y packing en aplicaciones específicas

en terminales móviles, transportistas y generación de documentación para el procedimiento
logístico.
50
SOFTWARE ERP
Tanto el aprovisionamiento como el seguimiento de facturación acarrean también

intervención de Administración para los cobros y pagos correspondientes.
Conviene realizar una simulación completa de estos procesos con intervención de los
usuarios reales. Durante estas pruebas es frecuente que los usuarios involucrados planteen
dudas, elementos de gestión que no se habían tenido en cuenta y situaciones menos frecuentes a
las que también se debe dar respuesta. Será necesario valorar la importancia de cada caso y la
mejor manera de resolverlo, siempre de manera consensuada con los usuarios clave y si fuese
necesario someterlo a consulta de superiores.
Si el ERP integra todos estos flujos de trabajo se puede registrar todo el proceso con sus
metadatos para referencia posterior, como por ejemplo, personas y fechas que solicitaron y
autorizaron la operación comercial. Si el ERP no dispone de facilidades propias de esta gestión,
entonces son los usuarios quienes deben gestionarlo manualmente. En cualquier caso, los
procesos deben estar documentados debidamente en forma de instrucciones operativas en la
documentación de Calidad de la empresa.
3.3. Pruebas de carga y pruebas de estrés.

Las pruebas de carga tienen como propósito establecer si el rendimiento del ERP es el
adecuado en determinadas situaciones, por ejemplo, qué pasa si un usuario pide un listado que
deba procesar un gran número de registros o qué ocurre cuando hay muchos usuarios
demandando procesos pesados. El sistema debería ser capaz de tener una buena respuesta o bien
ser capaz de gestionar a nivel de aplicación las limitaciones para dar a los usuarios una respuesta
comprensible.
Por su parte, las pruebas de estrés están encaminadas a medir la robustez del sistema, como
intentos de uso malintencionado, ataques externos, recuperación ante caídas inesperadas debido
a factores externos como fallo en el fluido eléctrico, fallos de hardware, fallos de red o
comunicaciones, o restauración de copias de respaldo, entre otros.
Prueba del software

Existe otra categoría de pruebas propias del ciclo de vida del software, formadas por un
conjunto de pruebas muy enfocadas en aspectos técnicos relacionados con las
especificaciones del desarrollo. Esta prueba del software también incluye pruebas unitarias
(módulos o unidades funcionales separadas), pruebas de integración de varios módulos,
pruebas del sistema (globales) y pruebas de carga y estrés. En el ciclo de vida de una release
de un ERP, todas estas pruebas deberían ser llevadas a cabo por el equipo de desarrollo y por
un equipo de testers en una etapa anterior a la implantación en una empresa. La diferencia es
que las pruebas mencionadas anteriormente están más centradas en el funcionamiento del
ERP en el entorno de configuración y ejecución específico del ERP, y al menos en teoría, no
deberían ocurrir errores como consecuencia de carencias durante la depuración. Se asume que
cuando un ERP se instala en una empresa, debe haber superado ya esta etapa.
Recuadro 3. Prueba del software.
51
SOFTWARE ERP
4. Conversión de datos del SI antiguo.

La conversión de datos es una tarea laboriosa. Requiere de un perfil consultor que conozca
bien el modelo de datos del nuevo ERP y sea capaz de valorar la relación coste/beneficio de la
conversión de cada entidad. Una regla básica para esta decisión puede ser considerar el tiempo y
coste/hora necesarios para preparar una conversión automatizada, ejecutarla y revisarla frente al
tiempo y coste/hora necesarios para introducir manualmente esta información. Además se puede
considerar también otros factores, como:
- La disponibilidad del personal de la empresa para ejecutar la imputación manual.

- El beneficio que supone permitir a los usuarios practicar con la imputación manual de
los datos.
- La posibilidad de detección de casos no contemplados y errores de especificación que
supone hacer que los usuarios realicen la imputación de los datos de forma manual.
Un perfil técnico puede encargarse de la transformación y carga de datos. Mejor aún si se
encarga de todo el proceso una persona que combine la cualificación funcional con la técnica.
Es conveniente recabar la información que haya disponible sobre las estructuras de

información del sistema que se va a abandonar. Si esto no es posible, habrá que hacer uso de
técnicas de ingeniería inversa para establecer la ubicación y formato de dichas estructuras.
Existen numerosas utilidades software para llevar a cabo las conversiones de datos. Una de
las más populares por su sencillez y flexibilidad es el formato de texto plano con columnas
delimitadas o de ancho fijo. Es posible también que haya más de una fuente de datos disponible
en varias tecnologías diferentes. La mayoría de sistemas ERP están soportados por bases de
datos relacionales de los que se puede extraer los datos y volcar a este tipo de formatos
mediante lenguajes de interrogación como SQL.
4.1. Clasificación de datos a convertir.

En cuanto al tipo de información que se vaya a convertir, se pueden establecer una
clasificación en función de su naturaleza, nivel de complejidad y temporización.
4.1.1. Clasificación de datos por naturaleza.

Por una parte, ficheros maestros y auxiliares, como pueden ser: clientes, proveedores,
direcciones, artículos, agentes comerciales, formas de pago, series comerciales, calendarios,
operarios, operaciones, fases, países, provincias, secciones, máquinas, etc. Se crea una cantidad
de nuevos registros a un ritmo relativamente bajo. Los auxiliares cambian con una frecuencia
baja.
Por otra parte, ficheros transaccionales, como pueden ser: pedidos, albaranes, facturas, y sus
respectivas líneas y sublíneas de detalle; cobros, pagos y vencimientos; órdenes de trabajo y
fichajes de órdenes de trabajo; fichajes de control de presencia; libro mayor de contabilidad, etc.
Tienen un ritmo elevado de creación de nuevos registros.
52
SOFTWARE ERP
4.1.2. Clasificación de datos por nivel de complejidad.

Lo más probable es que las estructuras de datos de los ficheros maestros y auxiliares varíen
entre el sistema de origen y el de destino. Esta variabilidad es menor entre las estructuras de
datos de los ficheros maestros y auxiliares, y sustancialmente mayor entre las estructuras de
datos de los ficheros transaccionales, debido a que la implementación del modelo de datos está
más ligada a la propia implementación de los procesos en cada ERP, es decir, el “cómo se ha
ideado programar los procesos” determina cómo se implementan las estructuras de las
relaciones en la base de datos que soporta dichos procesos.
Por su parte, estas diferencias entre las estructuras de datos de uno y otro sistema están
directamente relacionadas con la complejidad para llevar a cabo la conversión de datos entre
ambos.
4.1.3. Temporización de las conversiones.

Se puede ejecutar la conversión de datos del sistema antiguo y volcar en el nuevo sistema en
cuanto esté resuelto técnicamente. Esta ejecución se debe probar con antelación suficiente antes
del “arranque” en producción del nuevo sistema. Se pueden migrar al nuevo sistema con
antelación aquellos datos que se prevea que pueden cambiar muy poco o nada. Para todos los
demás, es conveniente preparar utilidades o scripts de carga que permitan ejecutar el proceso de
migración de datos en repetidas ocasiones, de forma completa o diferencial, según el caso. De
esta manera, las primeras ejecuciones pueden proveer un conjunto de datos suficiente para hacer
pruebas con datos reales y se puede planificar una última carga para el último momento antes de
la entrada en producción.
Otra utilización de los scripts de conversión es permitir la preparación de un entorno staging

o entorno de pruebas, constituido por un entorno de ejecución cuya configuración y datos son
idénticos al entorno de producción, y en el que se pueden ejecutar todo tipo de procesos sin que
afecten a la gestión real de la empresa. Tipos de pruebas que se pueden hacer en la instancia
staging:
- Pruebas piloto para validación por parte de los usuarios clave.

- Pruebas funcionales como se han descrito con anterioridad.
- Modificaciones en datos para verificar casos límite y determinar el comportamiento del
sistema.
- Pruebas de rendimiento.
- Cambios en parámetros de aplicación que modifican el comportamiento de algún
proceso.
- Pruebas de modificaciones de otros elementos configurables como consultas
personalizables, listados e informes.
- Pruebas con adaptaciones.
53
SOFTWARE ERP
5. Planificación del abandono del SI

antiguo.
Hay casos en que no existe un sistema de información con anterioridad, como en unidades de
negocio de nueva creación o cuando la empresa desea propiciar un avance cualitativo
importante e incrementar su nivel de gestión al incluir procesos que antes no estaban soportados
por su sistema de información. En estos casos la puesta en marcha reemplaza procesos de un
nivel de complejidad inferior, o procesos de gestión manual. En estos casos, si ya se han hecho
las suficientes pruebas, puede ser menos problemático.
Por otra parte, será frecuente enfrentarse en la práctica a escenarios en los que hay que
sustituir en un periodo muy breve de tiempo el sistema anterior por el nuevo. Será necesario
establecer cuidadosamente una planificación lo más realista posible de todos los recursos
técnicos, materiales y humanos necesarios.
En algunos casos se plantea la posibilidad de que ambos sistemas convivan durante un

periodo de tiempo, de manera que la transición sea lo menos problemática posible para los
procesos básicos que requieren una interacción con el exterior, como introducir un pedido de
cliente, presentar los impuestos en plazo o expedir mercancía. Cuando se da este caso es preciso
que el periodo de convivencia esté también cuidadosamente planificado de manera que sea lo
más corto posible. Mantener los dos sistemas en producción supone un enorme esfuerzo para el
personal interno, produce una creciente divergencia entre los datos de ambos sistemas y es una
fuente de errores introducidos por las personas, cuyo objetivo permanecerá de forma natural
más alineado con el proceso de negocio (facturar, expedir…) que con mantener la calidad de los
datos de dos sistemas de información en paralelo.
5.1. Establecimiento de fases de implantación.

Una estrategia recomendable siempre que sea posible es el establecimiento de fases de
alcance acotado y que requieran un despliegue de recursos asumibles por la organización. El
establecimiento de dichas fases puede requerir de soluciones transitorias hasta que todas las
partes del sistema estén funcionando de forma integrada. Algunos ejemplos de estas situaciones
de transición:
- Posponer el fichaje de órdenes de producción por parte de los operarios hasta que toda
la ingeniería de producto esté completamente definida desde producto final hasta las
materias primas.
- Gestionar parte del reaprovisionamiento de forma manual hasta que esté funcionando el
lanzamiento de órdenes de fabricación.
- Poner en marcha la gestión de almacén cuando estén definidos los almacenes, las
ubicaciones, el tipo de organización del almacén, los artículos, sus embalajes y
formatos.
Dentro del orden marcado de forma natural por los circuitos de información en la empresa, el
establecimiento de fases de implantación del ERP puede variar dependiendo de cada escenario
concreto, de factores condicionantes como la estacionalidad, imperativos legales, o incluso del
presupuesto disponible. Una posible aproximación consistiría en seguir el circuito de la relación
comercial:
54
SOFTWARE ERP
- Comenzar por Ventas, con propuestas y pedidos de cliente. Para llegar a introducir
pedidos de venta es posible que se necesite definir la ingeniería de producto hasta un
cierto nivel.
- De forma inmediata acometer Contabilidad y Finanzas, para poder sacar las
liquidaciones de impuestos, balances y resultados de explotación.
- Compras, Logística para poder llevar a cabo expediciones y reaprovisionamiento.
- Producción y subcontrataciones. Definir las ingenierías por completo, los centros de
trabajo, las operaciones y las fases de cada producto y semielaborado.
- Por último, transcurrido un tiempo en el que se haya acumulado ya una cantidad de
datos suficiente en los ficheros transaccionales, dar respuesta a las necesidades de
información por parte de Dirección, mediante cuadros de mando y herramientas de
Business Intelligence.
En algunas ocasiones la empresa podrá valorar si puede permitirse hacer un paréntesis entre
cada fase de implantación para asegurar que todos los usuarios afectados hasta el momento
están operando diariamente de forma estable y que el número e importancia de las incidencias
decrece. Unos pocos meses deberían bastar para alcanzar esta situación.
Existen otros procesos que pueden intercalar a lo largo de la implantación o acometerse en

fases posteriores. Ejemplos: módulos CRM, ECM, BPM, control de presencia, contabilidad
analítica, sistemas EDI, integración con comercio electrónico, etc. La empresa deberá
determinar la importancia estratégica para cada uno de ellos con el fin de establecer las
prioridades y recursos adecuados. Más adelante se desarrolla un apartado dedicado a sistemas de
información complementarios.
55
SOFTWARE ERP
6. Análisis de documentos que hay que

implementar: nuevos y versiones
nuevas de otros ya existentes.
6.1. Evolución de las salidas (output) del sistema de información.
Las extracciones de información del sistema han experimentado una transformación
sustancial en las últimas dos décadas. Para analizar esta transformación, en primer lugar,
podemos hacer la siguiente clasificación de dichas salidas en función de su finalidad:
- Consumo de información más o menos elaborada para uso interno de los empleados de
la empresa. En este grupo tendríamos: listados con información de clientes, ventas,
productos, existencias, etc. También informes elaborados a partir de la agregación por
distintos criterios de los datos anteriores, e información relacionada entre sí, por
ejemplo, ventas por cliente en un periodo y área geográfica determinados.
- Documentos en papel necesarios en los procesos de negocio relacionados con terceros:
etiquetas, albaranes, listas de embarque, facturas, hojas de pedido, contratos,
documentación aduanera, liquidaciones de impuestos, etc.
De todas estas extracciones de información, una parte notable se intercambia ahora mediante
procedimientos telemáticos que hacen innecesario el uso del papel, como:
- El Intercambio Electrónico de Datos (EDI por sus siglas en inglés)

- La factura electrónica
- La presentación telemática de impuestos
- La evolución de interfaces de usuario que permiten ahora “navegar” entre entidades de
información relacionada dentro del sistema.
- El uso de sistemas de inteligencia de negocio (BI), que ha sustituido en buena medida a
los clásicos listados interminables en papel.
Por otra parte, aquellos documentos que se han de elaborar necesariamente (como las
etiquetas de embalajes o las listas de embarque), tienen ahora unos requerimientos mucho más
demandantes de:
- Un gran nivel de detalle.

- La consistencia más exigente con los datos del ERP.
- Un diseño personalizado y acorde con la identidad gráfica de la empresa.
- La relación de idiomas en que debe estar disponible la emisión de cada documento.
56
SOFTWARE ERP
6.2. Sustitución de los documentos existentes.

Una situación frecuente durante el análisis de los documentos en papel a elaborar en el nuevo
sistema se presenta cuando los usuarios buscan formas análogas de realizar los procesos de
negocio que venían realizando anteriormente por medios manuales o en el antiguo ERP. Los
responsables del proyecto deben poner atención en este hecho.
No dar nada por sentado

Está muy claro que hay que reemplazar el formato de factura de ventas actual por otro en el
nuevo ERP, y elaborar un formato robusto y completo que responda a toda la casuística que
se pueda presentar. Sin embargo, es posible que el viejo listado de almacén con el que se
hacía inventario una vez al mes ya no sea necesario, porque el nuevo sistema incluye una
gestión de inventario permanente y si hay que hacer algún ajuste se hará de forma
semiautomática desde un terminal industrial.
Recuadro 4. Replantearse los viejos procedimientos de trabajo.
Puede que la supresión de documentos en papel ponga nerviosos a algunos usuarios, que
llevan años aferrándose a una supuesta seguridad del formato papel. Un análisis más detallado
revelará que lo que realmente cambia no es un listado de más o de menos, sino la sustitución de
un procedimiento más manual frente a otro más o menos automatizado. En este sentido juega un
papel importante la gestión del cambio, tema tratado en un apartado posterior.
La elaboración de formatos destinados a su consumo en papel es costosa en recursos

humanos, ya que requiere:
- Análisis detallado del proceso de negocio que genera la necesidad del documento
- Conocimiento detallado del modelo de base de datos para la elaboración de las
consultas necesarias para preparar los datos con sus filtros y niveles de agrupación
adecuados.
- Programación de trabajos automatizados tipo ETL19 si hay que preparar las estructuras
de datos con antelación y de forma periódica.
- Conocimiento de las herramientas específicas que provea el ERP para la preparación de
formatos de documentos.
Por estos motivos es fundamental realizar un análisis con criterios rigurosos y discriminar
aquellos documentos que son realmente necesarios. En este sentido, siguiendo el principio de
prudencia, se puede posponer la elaboración de aquellos formatos que no sean estrictamente
necesarios para el arranque de cada fase y evaluar con los usuarios la evolución de la
implantación durante los primeros meses para detectar las carencias que vayan detectando.
57
SOFTWARE ERP
7. Interfaces para integrar con otros

sistemas (de entrada y de salida).
7.1. Sistemas de información complementarios en la empresa.
En la introducción se hacía mención a la creciente extensibilidad de los ERP, y cómo la
evolución en las últimas dos décadas ha permitido la integración con otros sistemas de
información complementarios.
Existen numerosas aplicaciones informáticas que dan soporte a modelos de gestión cuyo
objetivo suele ser un avance en los procesos de mejora continua de las organizaciones. Este tipo
de aplicaciones cubren una gran variedad de ámbitos. En este apartado se enumeran algunas de
las que han tenido una aceptación considerable en las PYME20.
Un aspecto remarcable es que, aunque las aplicaciones informáticas pueden dar soporte a los
modelos de gestión, no funcionan en sí mismas como modelos de gestión. Si consideramos el
ejemplo de CRM, se suele usar para designar software CRM. Sin embargo, instalar una
aplicación CRM y hacer que los usuarios comiencen a usarla sin tener unos objetivos comunes y
claros definidos por la organización tiene un alto riesgo de fracasar en el intento de mejorar la
gestión21. En la mayoría de las ocasiones implican cambios en la forma de trabajar, es decir, son
más bien modelos de organización del trabajo soportados por un software y no al contrario, y
por eso es importante motivar y formar antes a los usuarios afectados. ¿Qué empresa no quiere
tener más información sobre su actividad comercial? Por otra parte, esto también significa
mayor disciplina y carga de trabajo para el equipo comercial. Es conveniente tener en cuenta el
coste de “registrar todo”. ¿Qué beneficios se obtiene a cambio de la sobrecarga administrativa
para los comerciales? Es imprescindible para el éxito de la implantación definir muy bien los
indicadores que se desean estudiar, descartar los innecesarios y establecer controles de
cumplimiento, a veces vinculados a alguna ventaja para los miembros del equipo comercial
(comisiones especiales, premios…)
El modelo de gestión por procesos (BPM por sus siglas en inglés), también denominado o
flujos de trabajo (workflow), evoca organizaciones muy bien estructuradas donde los usuarios
siempre tienen el trabajo al día, son felices y nunca omiten tareas. Sin embargo, la gestión por
procesos no es adecuada para todos los procesos de gestión de la empresa. Si no están bien
especificados conllevan periodos de implantación largos y costosos e introducen rigidez en la
organización. Son más adecuados para empresas medianas y grandes, con procedimientos y
perfiles de puesto de trabajo muy claramente definidos y son más aconsejables para procesos
que se repitan con frecuencia y tengan un flujo muy estructurable, repetitivo y con poca
variación.
Las aplicaciones de soporte del modelo de gestión CRM, BI 22 y BPM son software más
recientemente integrados como unidades modulares opcionales que ofrece el mismo fabricante
del ERP. En muchos casos las organizaciones prefieren, por diversos motivos, utilizar otras
aplicaciones de terceros porque aquellas que son más potentes permiten un grado alto de
integración con el ERP de la empresa. Esta especialización se debe a que en sí mismos, estos
módulos constan de una serie de funcionalidades complejas cuya implementación queda
bastante fuera del núcleo de desarrollo de un ERP y, por tanto, del centro del negocio de los
fabricantes de ERP, incluso en el caso de algunos considerablemente grandes.
58
SOFTWARE ERP
Por otra parte, si alguno de los módulos opcionales que integra el ERP ofrece una
funcionalidad suficiente para la organización, puede suponer una ventaja tenerlo todo integrado
en un único sistema.
7.2. Integración con sistemas de terceros.

En la etapa de análisis se deben identificar las entradas automatizadas con las que debe
contar el nuevo ERP, a partir de datos procedentes de sistemas externos, de clientes o
proveedores. Ejemplos:
- Sistemas de intercambio electrónico de datos (EDI) con clientes.

- Un fichero en formato de texto separado por delimitadores (csv) enviado de forma
automática por email que contiene las líneas de pedidos de compras a proveedores con
los que se trabaja sobre una planificación de órdenes de fabricación diarias.
Del mismo modo deben tenerse en cuenta las salidas de datos procedentes del ERP que
deben ponerse a disposición de clientes o proveedores. Ejemplos:
- Integración con plataformas de comercio electrónico de terceros (tienda Amazon).

- Integración para proporcionar a los clientes de la empresa el código de seguimiento de
los envíos del operador logístico.
Para cada integración hay que valorar al menos:
- Esfuerzo necesario y costes.

- Posible necesidad de adquisición de licencias adicionales.
- Planificación de la puesta en marcha.
- Un plan de contingencia. ¿Qué ocurre si un día falla la integración? Identificar puntos
únicos de fallo, es decir, sin redundancia de recursos; evaluación del coste de
oportunidad; plan de recuperación y plan de contingencia durante la recuperación, en
caso necesario.
59
SOFTWARE ERP
CAPÍTULO III. LOS ASPECTOS

TRANSVERSALES DURANTE UNA
IMPLANTACIÓN.
1. Mantenimiento y mejora continua.
1.1. Mantenimiento.
Todos los ERP sufren errores. Los errores pueden tener muchas causas:
- Casos límite no contemplados que causan resultados incorrectos.

- Errores en tiempo de ejecución: se produce una condición no prevista en los datos de
entrada a un proceso que causan un funcionamiento incorrecto y fallo de la aplicación.
- Errores lógicos: programación que no corresponde a la especificación o que puede tener
causa en errores en la propia especificación.
- Interfaces de usuario inconsistentes o con problemas de robustez que permiten utilizar
el sistema por parte de los usuarios de formas no previstas inicialmente por los
programadores.
- Cambios en el entorno de ejecución del sistema, por ejemplo, interacción con un virus o
la instalación de una actualización o nuevas versiones del software base (sistema
operativo, sistema gestor de bases de datos, telecomunicaciones…)
Los ERP son sistemas considerados de misión crítica y pueden llegar a suponer la parada de
buena parte de la actividad de la empresa. Es importante contar con un plan de actuación
conocido por todos los usuarios para la resolución de incidencias, con una clasificación en
función de su gravedad y unos tiempos de respuesta pactados con el servicio técnico contratado.
Personal debidamente cualificado para el mantenimiento y la resolución de problemas
específicos del ERP de la empresa. En muchos casos se tratará del servicio técnico que provea
la empresa consultora que asistió durante la implantación o en su defecto el servicio técnico del
fabricante del ERP.
El servicio técnico se provee bajo la premisa de un contrato de mantenimiento, con unos

precios negociados en la fase inicial de contratación del proyecto de implantación y puede
incluir un acuerdo de nivel de servicio muy detallado que puede contemplar hasta las
indemnizaciones pactadas por lucro cesante.
Para más información, véase también el apartado correspondiente a Coste total de

propiedad, en el que se han descrito otra parte importante de las operaciones de mantenimiento
que pueden estar a cargo de personal con un conocimiento más superficial de la operación del
ERP.
1.2. Mejora continua.

Las empresas son organizaciones evolutivas. Esto implica que los requerimientos también
evolucionan en el tiempo con la propia empresa y que la especificación que se realizó al inicio
del proyecto comenzará a sufrir de inmediato una divergencia respecto a las necesidades del
sistema de información de la empresa. Se puede mantener una documentación de
60
SOFTWARE ERP
requerimientos por áreas, y establecer un control de versiones, así como señalar los cambios de
esta documentación. Esto permitirá mantener la documentación siempre al día, de manera que
no quede obsoleta después de la implantación inicial.
Cuando llega el momento en que los procesos básicos del sistema funcionan de forma
estable y se ha culminado la fase anterior, se puede planificar el inicio de una nueva iteración en
el que se planifique la implantación de mejoras. Este puede ser un buen momento para evaluar
la conveniencia de dar respuesta a los casos que se descartaron en las etapas anteriores. En este
momento los usuarios estarán más capacitados para determinar cómo de importantes son y
ayudar al director del proyecto a valorar la relación coste/beneficio.
Los usuarios solicitantes de los cambios están por lo general más capacitados que nadie para
determinar cómo de importante es dicho cambio. Para ayudarles en este cometido se pueden
plantear preguntas como “¿con qué periodicidad utilizarías esta función?” o “¿cuántas horas al
mes podrías dedicar a otras tareas si esto no te consumiese tanto tiempo?”.
61
SOFTWARE ERP
2. Gestión del cambio y desarrollo de la

motivación.
La evolución de las empresas supone cambios en la organización, en los perfiles de puestos
de trabajo, en cómo se llevan a cabo los procesos de negocio. Estos cambios requieren a su vez
de varios elementos para su consecución exitosa:
- Herramientas adecuadas para alcanzar las mejoras deseadas, por ejemplo, un ERP.
- Capacitación del equipo, es decir, proporcionarles la formación específica requerida.
- Motivación, una serie de mecanismos emocionales.
La motivación es el recurso más difícil de desarrollar de los tres mencionados. Su cometido
es incrementar la implicación de los empleados en los objetivos de negocio de la empresa, en la
medida que corresponda a cada uno, y con ello mejorar su propia percepción sobre el valor que
aportan a la organización y su capacidad de mantener este estado de ánimo y transmitirlo a otros
grupos de interés dentro y fuera de la empresa.
Desde el punto de vista subjetivo, la motivación puede ser intrínseca, la que generan las
personas por sí mismas, o extrínseca, como resultado de aquellas actividades o incentivos que
dispone la empresa para este propósito. La combinación de ambas puede mantener un elevado
grado de compromiso de los empleados en el proyecto de la empresa: se habla de engagement
empresarial.
Todas las organizaciones tienen una serie de valores que transmiten de forma más o menos
explícita a sus grupos de interés: clientes, proveedores, empleados, propietarios, medios de
comunicación y a la sociedad en general. Las empresas tienen el deber de mantener alineados
sus objetivos de negocio con los intereses de su capital humano, que suele ser el de mayor valor,
en el marco de sus esfuerzos por gestionar el talento con el fin de retenerlo. La empresa debe
prestar atención para mantener un adecuado nivel de motivación de sus empleados, entre otros
aspectos puede disponer:
- Ayuda para los empleados en su plan de carrera profesional, satisfacer sus necesidades e
intereses profesionales, así como determinados intereses personales.
- Los recursos necesarios para fomentar su satisfacción por el trabajo y autoestima.
- Los recursos necesarios para capacitarles para el ejercicio de su trabajo.
- Comunicarles los objetivos estratégicos en la medida posible.
- Establecimiento de canales de comunicación confiables que les permitan participar
activamente en los procesos de mejora continua, de forma libre y sin reservas.
- Los medios necesarios para evitar conflictos y promover la confianza y las relaciones
saludables entre empleados, independientemente de cuál sea su posición en el
organigrama.
- Transmisión de seguridad en el futuro de la empresa y de sus puestos de trabajo.
62
SOFTWARE ERP
2.1. Papel de la Dirección y del Director de Proyecto.

El apoyo de la Dirección de la empresa al proyecto juega un papel fundamental, como ocurre
con todos los cambios. El apoyo puede darse en varios ámbitos:
- Mediante la asignación de los recursos humanos y materiales necesarios, desde personal

de apoyo contratado expresamente para el proyecto hasta la disposición de
equipamiento o contratación de servicios necesarios para facilitar el trabajo del equipo
involucrado.
- De forma explícita mediante las oportunas reuniones de motivación a todos los
involucrados al inicio del proyecto, Dirección puede aprovechar la ocasión para
presentar al equipo en el que va a delegar la ejecución. Este carácter de oficialidad en el
otorgamiento de responsabilidades servirá para legitimar las acciones posteriores que
lleven a cabo los miembros del equipo ante otras personas dentro y fuera de la
organización.
- Mediante reuniones periódicas de control con el líder del proyecto. Respaldarle,
escuchar los problemas, identificar los importantes y legitimar las decisiones para
resolverlos.
La delegación eficaz según Acosta23 consiste en:
- Definir alcance de las atribuciones, autoridad y grado de responsabilidad.

- Comunicar a todos los afectados.
- Apoyar al delegado en sus dificultades y establecer controles.
- Concederles el derecho a equivocarse, ya que la responsabilidad se delega, pero se
mantiene íntegra.
En cuanto al Director del Proyecto, es importante que esté debidamente capacitado y
emocionalmente preparado para enfrentarse a situaciones de estrés, frustración y cansancio
experimentadas por sí mismo y por todos sus compañeros, derivados del sobreesfuerzo que
conlleva el proceso de cambio.
Aunque se ha escrito abundante literatura sobre la gestión del cambio en las últimas décadas,
así como guías de buenas prácticas para la implantación exitosa de ERP, el proceso concreto de
cambio que se da en cada organización durante la implantación es único, a diferencia de los
procesos de negocio que ocurren de forma sistemática en la actividad cotidiana de la empresa.
Este hecho tiene como consecuencia que puede existir incertidumbre sobre algunos aspectos de
la planificación.
63
SOFTWARE ERP
2.1.1. Aptitudes del líder del proyecto.

Algunas de las aptitudes personales deseables en el líder del proyecto que le permitirán
gestionar el cambio de forma exitosa son:
- Capacidad para visualizar las metas y comunicarlas a otras personas transmitiendo

confianza con entusiasmo y optimismo. Constituir un ejemplo de actitud positiva.
- Capacidad para establecer relaciones “yo gano-tu ganas” con otras personas y negociar
en ese sentido sobre una base de respeto mutuo. “Con-vencer” entendido como
concepto de ganar juntos.
- Capacidad para reunir los datos relevantes, descartar los irrelevantes, procesarlos de
forma analítica y tomar decisiones sabias con seguridad, orientadas siempre a la
consecución de los objetivos de alto nivel del proyecto.
- Capacidad empática y voluntad de ayudar a los demás a adquirir las competencias
necesarias.
- Capacidad para cambiar enfoques obvios por otros más creativos para resolver
problemas.
- Paciencia, firmeza y flexibilidad.
2.1.2. Funciones del líder del proyecto

Entre las funciones que el líder del proyecto debe atender de forma constante en la gestión
del cambio24 se encuentran:
- Mantener abiertos canales de comunicación informales con el resto de miembros del

equipo para obtener feedback. Mantener una actitud receptiva puede ayudar a detectar
problemas de forma temprana. Véase también el apartado de Gestión y resolución de
incidencias durante la ejecución del proyecto.
- La gestión del equipo. Mantener una visión global de las interrelaciones entre los hitos
del proyecto y coordinar a los involucrados para evitar cuellos de botella que puedan
frenar el avance general.
- Identificar y potenciar a los aliados, aislar y relevar a los saboteadores y trabajar la
persuasión y la motivación sobre los escépticos. Generar compromiso, pactos y
coaliciones.
- Incentivar el compromiso mediante la compensación. Averiguar qué resortes funcionan
mejor para motivar a cada persona. La remuneración económica es la menos frecuente.
Otros incentivos pueden ser el reconocimiento público, un cambio de atribuciones, días
de vacaciones, una mayor flexibilidad horaria o un simple cambio de despacho a uno
más luminoso.
- Mantener en todo el equipo un ritmo de trabajo adecuado y unas expectativas altas de
consecución de objetivos de negocio.
- Recurrir a la imposición autoritaria solo en casos excepcionales: tiene un coste elevado
contra la implicación del equipo, que sentirá que la comunicación es unidireccional y
que no tienen voz ni voto en las decisiones.
- Basar la persuasión en relaciones de confianza. Hay líderes capaces de generar vínculos
de confianza con rapidez. Hay escenarios más hostiles en los que generar estos vínculos
cuesta más tiempo. En todos los casos, un paso en falso puede destruir estos vínculos
con extrema rapidez, y son muy difíciles de recuperar.
- Diseñar y desarrollar planes específicos de formación para capacitar a cada persona
afectada en la medida de sus necesidades. La ausencia de formación puede convertir a
un escéptico en un saboteador, mientras que una capacitación adecuada puede convertir
a un escéptico en un aliado.
64
SOFTWARE ERP
- Mantener un adecuado nivel de información a varios niveles: dirección, usuarios clave y

el resto de usuarios afectados. Las sesiones de control con dirección servirán al líder del
proyecto para sentirse respaldado. Las sesiones de información al resto servirán para
hacerles sentir seguros, entender cómo va la marcha del proyecto, mantener una visión
general de los objetivos, darles la oportunidad para compartir sus inquietudes. La suma
de todo esto aumentará su implicación.
2.1.3. Retos para el líder del proyecto

2.1.3.1. Exceso de información.
Uno de los retos a los que debe enfrentarse el líder del proyecto es un exceso de información.
Se habla de “parálisis por análisis” como un cuadro de comportamiento de los decisores en el
que se pondera toda la información relacionada con la toma de una decisión o el avance en la
consecución de un objetivo en un círculo sin fin. Es una forma de procrastinación activa, y
puede tener su origen en diversos factores: inseguridad, sentir una falta de apoyo (real o no) por
parte de dirección, temor a las consecuencias de una decisión errónea o un enfoque demasiado
perfeccionista. Por el contrario, el líder del proyecto debe ser ejecutivo. Experiencia e intuición
juegan su papel a la hora de seleccionar la información relacionada con los factores más
relevantes que influyen en la toma de una decisión. También debe mantener una actitud positiva
y resiliente frente a los errores propios o de sus subordinados.
2.1.3.2. Sobrecarga de tareas.

Otro de los elementos que pueden tener un impacto negativo en el trabajo del líder del
proyecto es la sobrecarga de tareas. Existen numerosas técnicas de gestión adecuada del tiempo,
entre ellas Getting Things Done25 de Allen o la matriz de decisión de Eisenhower, extendida
posteriormente por Covey26. La naturaleza de las tareas importantes en pocas ocasiones requiere
atender varias de ellas a la vez, de lo que se desprende que esta situación se suele dar con tareas
urgentes, pero poco importantes. Si de toda la lista demasiadas tareas son importantes y
urgentes, entonces hay que reasignar prioridades o recursos, ya que este cuadrante debería
permanecer vacío casi todo el tiempo. Las tareas poco importantes y no urgentes se delegan o
directamente se descartan. Entre los efectos negativos de la sobrecarga de tareas tenemos un
bajo rendimiento debido al acoplamiento o reanudación de tareas, tomar malas decisiones
debido a la falta de concentración y un aumento del número de errores.
2.1.3.3. Colaboración vs competencia.

Cada vez están más extendidos los equipos basados en la colaboración en contraposición a la
competencia. El modelo de desarrollo de software open source basado en una comunidad de
pequeñas empresas locales que comparten intereses es uno de ellos. En las organizaciones
empresariales exitosas se está imponiendo también un modelo similar.
Es competencia del líder del proyecto identificar los objetivos en los que se puede hacer
causa común e incentivar el trabajo en equipo para su consecución, y solicitar a Dirección los
recursos necesarios para poner todo esto en práctica de forma perceptible por los implicados. Se
deben identificar y erradicar los objetivos divergentes y que se excluyan entre sí para disminuir
las amenazas y los impedimentos: el éxito colectivo converge con el éxito personal.
65
SOFTWARE ERP
Crear equipos compactos, miembros que se ayudan entre sí y a largo plazo, una elevada
retención del talento. Para facilitar esto también es importante que cada miembro del equipo
sepa con claridad cuáles son sus responsabilidades y las de sus compañeros.
66
SOFTWARE ERP
3. Gestión y resolución de incidencias

durante la ejecución del proyecto.
El líder del proyecto debe estar atento a cualquier elemento que pueda suponer una
desviación de los objetivos en plazos, presupuesto u otros recursos asignados. Una detección
temprana puede ayudar a reevaluar la situación, tomar decisiones, corregir el rumbo y disminuir
el impacto.
La mejor forma de gestionar las incidencias es de forma preventiva, es decir, conceder más
importancia a la toma de requisitos y al análisis de la solución. Cuando a pesar de esto se
producen estas situaciones, reconocerlas puede ayudar a determinar el mejor enfoque posible
para resolverlas. Para esto no hay manual ni receta mágica: cada incidencia debe resolverse de
la manera más creativa, satisfactoria y menos costosa posible, en términos de tiempo y esfuerzo.
La aplicación de técnicas de gestión de proyectos como el agilismo27 pueden ayudar a paliar sus
efectos negativos. Véase la sección Propuestas de mejora.
Por otra parte, conviene tener presente que no todo se puede prever ni sistematizar en los
proyectos de implantación y que suele ser mejor buscar vías de colaboración que incluyan a
todos los implicados en la consecución del fin común. No obstante, en algunos casos es
necesario depurar responsabilidades y exigir el cumplimiento de los compromisos adquiridos a
alguno de los compromisarios. A continuación se describen algunas de las incidencias más
frecuentes.
3.1. Errores de análisis.

El modelo recogido en las especificaciones refleja de forma incompleta el proceso de
negocio al que representa, o bien lo refleja de forma inexacta. El impacto es muy variable.
Algunos de estos errores pueden resolverse de forma sencilla, como por ejemplo, mediante la
modificación de una interfaz de usuario o la adición de unos cuantos campos personalizados.
En los casos más extremos, un error grave de análisis puede comprometer la viabilidad del
proyecto completo, si afecta a un proceso de negocio clave y no es viable una solución, bien sea
por imposibilidad técnica o porque los costes de la solución a posteriori son demasiado
elevados. Afortunadamente, la naturaleza adaptable del software y la creciente adaptabilidad de
los ERP logran que estos casos sean infrecuentes.
3.2. Errores de alcance.

El alcance delimita el grado de complejidad con el que se va a modelar el conjunto de los
procesos en una determinada etapa de la implantación, y en definitiva, con el que se va a dar
respuesta a una serie de objetivos de negocio. Los errores de alcance pueden ser por exceso, por
incluir demasiadas tareas en una misma etapa del proyecto y por defecto, dejar de incluir tareas
que pueden suponer un problema en momentos críticos como la puesta en marcha de
determinadas áreas de gestión.
Ejemplo 1: la decisión de incluir en la primera fase del proyecto la migración del maestro de
artículos del sistema de información anterior.
67
SOFTWARE ERP
Si el maestro de artículos tiene unas cuantas decenas de referencias activas, cada pedido de
venta dos o tres líneas simples, y se generan solo unos pocos pedidos al día, puede que la
empresa prefiera que el personal que imputa los pedidos vaya haciendo el alta manual de los
artículos a medida que los necesiten. Les servirá para familiarizarse con el nuevo sistema y les
permitirá “limpiar” las referencias obsoletas. Puede ser una buena idea excluirlo.
En cambio, en otra empresa donde haya decenas de miles de referencias, con fichas
complejas con muchas variantes y varios cientos de pedidos al día, es inviable que se gestionen
las altas de artículo en el momento de hacer los pedidos. Excluir la migración del maestro de
artículos sería un grave error de alcance por defecto.
Como ejemplo de error de alcance por exceso se puede considerar pretender incluir en el
arranque demasiadas áreas de gestión. Véase para más información los apartados
Interdependencias, cuellos de botella y secuencialidad y también el apartado
Establecimiento de fases de implantación.
3.3. Costes ocultos.

Los costes ocultos son costes relacionados con la puesta en marcha del proyecto, el
requerimiento obligatorio de actualizar o adquirir licencias de aplicaciones informáticas de
terceros, licencias de sistemas operativos, ordenadores, servidores, periféricos especiales, la
adecuación de las instalaciones de la empresa. Estos costes pueden ser repercutidos por el
fabricante del ERP, por la empresa consultora de la implantación, o más frecuentemente, por
terceros.
El fabricante del ERP y la empresa consultora contratada para la implantación considerarán

que es responsabilidad del área de TI de la empresa determinar los recursos complementarios
necesarios. Puede que el personal de TI, si es que lo hay, o Dirección, si no hay personal interno
de TI, consideren que aquellos deberían haber presentado una relación completa de todos los
recursos necesarios. Esta brecha en la comunicación puede resultar en costes inesperados y
reproches mutuos. Una aproximación para evitarlo es que por parte de los proveedores se
apliquen buenas prácticas basadas en la ética profesional y se trate este asunto de forma
explícita. Del mismo modo, es una responsabilidad compartida para el cliente preguntar por
otros costes no relacionados directamente con el ERP y los servicios de implantación pero que
vayan a formar parte de los requisitos necesarios para la ejecución del proyecto, visto de forma
global.
3.4. Errores en la asignación de recursos.

Este tipo de errores también pueden tener como consecuencia costes imprevistos, pero
requieren mención especial. Se trata de errores de cálculo en la planificación que pueden ser
detectados de forma tardía, y por ello son especialmente perniciosos.
En la parte más significativa de los casos afectan a los recursos humanos, que suelen ser
también los más costosos. En cuanto a personal de la empresa, podría darse la necesidad de
contratar personal de manera temporal durante el desarrollo del proyecto o incluso la necesidad
de crear nuevos puestos de trabajo de forma permanente porque se ha decidido incrementar el
nivel de gestión en un área determinada y no se había previsto que no lo podrían cubrir con el
equipo existente. Las necesidades en materia de recursos humanos después de la implantación
son difíciles de calcular antes de comenzar, de manera que en cualquier caso es necesario hablar
68
SOFTWARE ERP
de ello y al menos hacer una estimación del balance: qué tareas se podrán realizar de manera
más productiva y previsiblemente disminuirán la carga administrativa y qué otras nuevas se van
a generar o cambiarán para incrementar dicha carga.
En otra parte de los casos afectarán a recursos materiales, algunos ejemplos:
- Se requiere más espacio en el almacén como consecuencia de una reorganización de las

ubicaciones y de la introducción de carretillas eléctricas que obligan a hacer pasillos
más amplios. (¡Glubs! ¿Hay que alquilar otra nave o mudarse?)
- Después de intentar usar el antiguo servidor durante unos meses, se concluye que va
demasiado lento y que hay que cambiar la infraestructura de hardware servidor para que
soporte la carga de procesamiento generada por el nuevo ERP. Hay que comprar nuevos
puestos de trabajo con mayor potencia. Por si fuera poco, habrá que actualizar la suite
ofimática porque la que hay ahora no es compatible con el sistema operativo de los
nuevos equipos.
3.5. Falsas objeciones.

Algunos miembros del equipo pueden reportar de manera más o menos insistente al líder del
proyecto quejas sobre determinados aspectos de la implantación, relacionadas con dificultades
para llevar a cabo su trabajo, ya sea por falta de formación, sobrecarga de trabajo, problemas
técnicos, consecuencias no previstas y una amplia variedad de otras causas. Es cometido del
líder del proyecto determinar si las causas de cada queja son reales o detrás de estas objeciones
existen otras, como pueden ser:
- Temor a no ser capaz de asumir nuevos procedimientos de trabajo.

- Temor a un mayor control y un creciente nivel de exigencia.
- Temor a perder atribuciones, hacerse “menos imprescindible” o incluso temor a la
pérdida del puesto de trabajo.
- Temor a pérdidas de poder conseguidas a lo largo de años.
- También podría tratarse, sencillamente, de una resistencia natural al cambio durante el
periodo de adaptación.
La habilidad del líder del proyecto en materia de relaciones interpersonales será
determinante en estos casos. Evidentemente, si las quejas son fundadas, es necesario gestionar la
causa de forma eficaz para facilitar a la persona poder avanzar. Las quejas mal gestionadas
pueden generar saboteadores, mientras que bien gestionadas contribuirán a aumentar la
autoestima y la implicación de la persona a la que se le han solucionado los problemas. Se
conseguirá un aliado fiel.
3.6. Saboteadores.
Los saboteadores pueden realizar tareas de formas extrañas e imprevistas que dificulten el
trabajo de otras personas o que retrasen el avance del proyecto. Pueden hacer todas estas cosas
sin ser siquiera conscientes de ello o haber parado por un momento a analizar por qué se sienten
así.
Los saboteadores son personas a las que hay que reconducir hacia la alianza del equipo y sus
objetivos comunes o apartar del proyecto. Son personas a las que no se ha gestionado
correctamente y que ponen en peligro su éxito. Entre las causas: puede que no se les haya hecho
partícipes en las etapas tempranas, puede que tengan miedo por algunas de las causas descritas
en el apartado anterior Falsas objeciones, es posible que no tengan la capacitación para el
69
SOFTWARE ERP
cambio o simplemente no se les ha informado de cómo les va a afectar. En los peores casos,
cuando no es posible recuperar su confianza y conseguir su colaboración deberán ser apartados
discretamente hacia atribuciones donde no perjudiquen el avance del proyecto.
70
SOFTWARE ERP
4. Propuestas de mejora: gestión ágil.

A lo largo de décadas se han sucedido diversos paradigmas de gestión de proyectos
relacionados con los sistemas de información y el desarrollo de software. En los últimos años se
ha extendido la práctica de la metodología ágil, e incluso la sexta edición del PMBOK 28 ,
publicada en 2017, se ha publicado junto con la Agile Practice Guide, como parte del estándar.
Su desarrollo está basado en el manifiesto ágil29, redactado por un conjunto de consultores

tecnológicos y suscrito después por miles de otros profesionales de las tecnologías de la
información.
En la sección anterior se analizaban diversos tipos de incidencias desde un punto de vista

reactivo: errores de análisis, errores de alcance, costes ocultos, errores en la asignación de
recursos, falsas objeciones y saboteadores.
El enfoque ágil pretende ir más allá, constituye en parte un enfoque preventivo y en parte un
enfoque que minimiza el impacto de los problemas habituales del desarrollo de software, y es
aplicable también en buena medida a las implantaciones.
Los principios por los cuales la metodología ágil puede ayudar a gestionar los proyectos de
implantación son:
• El software funcional es el indicador de progreso más relevante, y denota una fuerte

orientación al cliente como principio fundamental.
• Entregas frecuentes que permiten a los usuarios probar funciones y proporcionar
realimentación a los desarrolladores acerca del grado de cumplimiento de objetivos. De dos a
ocho semanas, preferentemente el periodo más corto posible.
• Flexibilidad de cambio de especificaciones, incluso en fases avanzadas de la implantación.
La experimentación con el nuevo sistema suele “abrir” la mente de los usuarios, que son
capaces de ver nuevas mejoras que pueden dar a la empresa ventajas competitivas.
• Excelencia en la gestión de las personas, para mantener alta la motivación.
• Comunicación estrecha y hablada entre todos los miembros del equipo, incluidos los
consultores funcionales y los desarrolladores. La palabra escrita solo puede servir de soporte
posterior a la discusión cara a cara.
• La excelencia en la ejecución y el buen diseño van parejos a la simplicidad y conducen a
economizar la mayor cantidad posible de esfuerzo innecesario.
• La mejora continua es uno de los principios del equipo al que se presta atención de forma
periódica.
71
SOFTWARE ERP
5. Conclusiones.
Los objetivos propuestos al inicio del presente estudio se consideran satisfechos con las
aplicaciones descritas a continuación:
• Su ordenación se estructura como una visión global del proceso de implantación de ERP,
útil para los directores de las organizaciones que tengan planeado abordar un cambio del
sistema de información principal en sus organizaciones en un futuro próximo.
• También puede ser de utilidad como herramienta de consulta para aquellas personas que
hayan sido designadas por la dirección de la empresa para asumir la tarea de liderar el
cambio por parte de la organización, que no sean expertos en sistemas de información.
• Por último, puede constituir también una herramienta de consulta, a modo de lista de
comprobación, para cualquier profesional de la consultoría funcional de implantaciones
de ERP.
Los ERP son sistemas de información que han evolucionado hasta ser capaces de gestionar
la totalidad de las áreas de las empresas, y extender sus capacidades integrándose con otros
sistemas.
La implantación de un sistema de información que abarque las áreas principales de gestión

es uno de los procesos de cambio más complejos que puede abordar una organización, y
requiere ser dotado de los recursos materiales y humanos adecuados.
El mercado de los ERP es un mercado maduro. Sin embargo, sigue siendo un proceso
complejo desde las fases más tempranas de la evaluación y selección hasta el comienzo del
mantenimiento, una vez ya en marcha. Por este motivo es fundamental prestar especial atención
a todos los aspectos de la contratación con las empresas externas que se van a convertir en
socios tecnológicos a lo largo de todo el ciclo de vida del ERP en la empresa.
Las metodologías ágiles de gestión de proyectos están orientadas a satisfacer al cliente,

mantener un nivel alto de compromiso de todas las partes y establecer un ritmo incesante de
trabajo durante el desarrollo. La capacidad de reacción rápida y la adaptación constante
resuelven buena parte de los problemas de estancamiento y falta de progreso de metodologías
anteriores.
Concluye así un recorrido por los aspectos más relevantes del proceso de implantación de un
ERP en las empresas industriales. Desde la fase inicial, con el establecimiento de la motivación
que se debe comunicar en su momento a las personas, la toma de requerimientos, el proceso de
selección del software y de la empresa consultora que dirigirá la implantación, la planificación
de recursos humanos y materiales y el análisis de costes.
En la etapa de implantación se desarrolla un repaso por la evaluación de requerimientos de

todas las áreas afectadas: Comercial, Finanzas, Producción, Logística, Compras y Dirección, en
este último caso con especial hincapié en el análisis de datos y su conversión en información
útil. Continúa con la validación de flujos de trabajo de forma unitaria, y posteriormente pruebas
de integración de cada flujo en el contexto de toda la organización. Otro aspecto relevante que
considera incluye las posibles conversiones de datos del sistema de información anterior, así
como la planificación en el tiempo e hitos de su abandono definitivo.
72
SOFTWARE ERP
Las implantaciones de cierta complejidad escalan su alcance en fases. Estos hitos permiten
afianzar el camino recorrido, en algunos casos “arrancar” partes del sistema de información y no
tratar de abarcar alcances demasiado amplios que pueden comprometer la viabilidad del
proyecto global, que puede prolongarse durante periodos desde unos pocos meses a varios años,
en función de la complejidad del cambio y de la organización.
Eventualmente, las sucesivas iteraciones de cada fase desembocarán en un ciclo de

mantenimiento, en el que la organización deberá ocuparse de la planificación de la mejora
continua, gestionar de forma adecuada la petición de cambios y definir criterios para la
evaluación de nuevos requerimientos.
En el tercer capítulo se tratan aspectos transversales como la gestión del equipo, la

motivación de los usuarios clave, el papel de la Dirección de la empresa y la figura del líder del
proyecto, y la gestión y resolución de incidencias a lo largo del proyecto, cuyo número y
dificultad crecen más conforme a la duración del proyecto y la complejidad del sistema de
información.
En cuanto al equipo, es clave la figura del líder, que debe tener habilidades y experiencia en
gestión de proyectos, y el equipo de consultores, que deben contar asimismo con la debida
experiencia en todos los aspectos tanto funcionales como técnicos del software. La empresa
debe también asignar recursos para afrontar el sobreesfuerzo de todos los usuarios afectados, y
propiciar una adecuada gestión del cambio.
73
SOFTWARE ERP
74
SOFTWARE ERP
Bibliografía
Acosta, J.M. (2009). El tiempo, la PNL y la inteligencia emocional. Ed. Gestión 2000.
Allen, D. (2001). Getting Things Done. Penguin Book Business.
Covey, S.R. (rev. 2015). Los siete hábitos de la gente altamente efectiva. Ed. Planeta.
Davenport, T.H., Prusak, L. (2001). Conocimiento en acción: cómo las organizaciones manejan
lo que saben. Prentice-Hall.
Kane, W.S. (2008). The Truth About Thriving in Change. Financial Times Press.
Martin, J. (1983). Managing the Data-base Environment. Englewood Cliffs, Prentice-Hall. p.

381
Misiurek, B. (2016). Standardized Work with TWI (Training Within Industry): Eliminating
Human Errors in Production and Service Processes. Productivity Press.
Peppers, D., Rogers, M. (2011). Managing Customer Relationships: A Strategic Framework.

Ed.Wiley.
Project Management Institute (5ª ed, 2013). Guía de los fundamentos para la dirección de
proyectos. Ed. Project Management Institute, Inc.
Shore, J., Warden, S. (2007). The Art of Agile Development. O'Reilly. p. 122
75
SOFTWARE ERP
Notas
1ERP: acrónimo de Enterprise Resource Planner, o Sistema de Planificación de Recursos
Empresariales.
2Controlling: Sistema de control de la gestión de la empresa. Diccionario Económico. Diario
Expansión. Rodríguez Martín y Alejandro Ramón. http://www.expansion.com/diccionario-
economico/controller.html
3 Web oficial de la Unión Europea. https://europa.eu/european-union/topics/consumers_es
4 De forma general, salvo especificación en contra, las referencias a “interfaces” se refieren a
interfaces de usuario, es decir, las pantallas en las que el usuario interactúa con el software,
donde se imputan datos, se presenta la información y se ejecutan los procesos.
5 James Shore, Shane Warden (2007). The Art of Agile Development. O'Reilly. p. 122
6Martin, James (1983). Managing the Data-base Environment. Englewood Cliffs, Prentice-
Hall. p. 381
7 Misiurek, Bartosz (2016). Standardized Work with TWI (Training Within Industry):
Eliminating Human Errors in Production and Service Processes. Productivity Press.
8 Plan o guía para acciones futuras. Collins English Dictionary.
https://www.collinsdictionary.com/dictionary/english/road-map
9On-premises: referido a la ubicación física de cualquier aplicación informática en alguna de las
sedes de la empresa que lo utiliza.
10 Ver sección de planificación de recursos humanos.
11CRM: acrónimo de Customer Relationship Management, modelo de gestión comercial
centrado en la interacción con las personas vinculadas a las empresas clientes y la
estructuración de la información que constituye el historial completo de dicha relación.
12 NIC, véase introducción en http://eur-lex.europa.eu/legal-
content/ES/TXT/?uri=uriserv%3Al26040
13 Asociación Española de Banca. http://www.aebanca.es
T.H. Davenport, L. Prusak (2001). Conocimiento en acción: cómo las organizaciones
14
manejan lo que saben. Prentice-Hall.

15 BPM: acrónimo de Business Process Management, modelo de gestión basado en el modelado
de los procesos reales de las organizaciones en un sistema de información en forma de flujos de
trabajo.
16También conocida como BI, acrónimo de Business Intelligence. Sistemas capaces de procesar
grandes cantidades de datos de los sistemas transaccionales para el análisis de información.
17Por Vheilman (trabajo propio) [CC-BY-SA-3.0 (www.creativecommons.org/licenses/by-
sa/3.0)], via Wikimedia Commons
18 BPMN, acrónimo de Business Process Management Notation. Notación normalizada para el
modelo de gestión por procesos BPM. http://www.bpmn.org/
19ETL, acrónimo de Extraction, Transform and Load. Proceso por el cual se preparan los
almacenes de datos con anterioridad al momento de su uso.
20PYME: pequeñas y medianas empresas, representan aproximadamente el 65% del Producto
Interior Bruto en España. Fuente: Ministerio de Economía, Industria y Competitividad (2015).
D. Peppers, M. Rogers (2011). Managing Customer Relationships: A Strategic Framework.
21
Ed.Wiley.
76
SOFTWARE ERP
22BI: Business Intelligence, o inteligencia de negocio. Por extensión, aplicaciones informáticas

para el análisis de información útil para la toma de decisiones por parte de Dirección o Control
Financiero.
23 J.M. Acosta (2009). El tiempo, la PNL y la inteligencia emocional. Ed. Gestión 2000.
24 W.S. Kane (2008). The Truth About Thriving in Change. Financial Times Press.
25 D. Allen (2001). Getting Things Done. Penguin Book Business.
26 S.R. Covey (rev. 2015). Los siete hábitos de la gente altamente efectiva. Ed. Planeta.
27Metodología de desarrollo de software centrada en las personas, dirigida a resultados, con una
fuerte orientación hacia el cliente y una capacidad alta de respuesta positiva al cambio.
28Project Management Body of Knowledge, Fundamentos para la Dirección de Proyectos, es
una publicación del Project Management Institute. La quinta revisión, publicada en 2013, no
incluía aun referencias a la gestión ágil.
29 Principios del manifiesto ágil. http://agilemanifesto.org/iso/es/principles.html
77

Guía Implantación ERP

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Guía Implantación ERP

Transféré par

Droits d'auteur :

Formats disponibles

Escola Tècnica Superior d’Enginyeria Informàtica

Universitat Politècnica de València

GUÍA PARA LA IMPLANTACIÓN DE UN SISTEMA

Trabajo Fin de Grado*

Grado en Ingeniería Informática

Autor: Francisco Javier Martínez Nueda

Tutora: Eva María Cutanda García

* La presente copia incorpora un título más acorde a los objetivos,

Con mi agradecimiento a Julia.

Palabras clave: Sistema de información, ERP, gestión de proyectos, procesos industriales,

Keywords: Information system, ERP, project management, industrial processes,

3.9.9. Tecnología que utiliza y uso de estándares. ........................................................... 21

1.3.1. Contabilidad financiera. ...................................................................................... 36

Índice de ilustraciones y tablas

En la década de 1960 se introdujo el concepto de planificación de reaprovisionamiento

En la década de 1990 los sistemas de información evolucionan de manera que se unifican en

“ecosistema” no se adapte adecuadamente, debido a factores como limitaciones de la

El cambio de un ERP es un proceso que requiere grandes esfuerzos por parte de la

Ámbito de análisis y metodología del estudio.

La metodología empleada es la consulta de las referencias bibliográficas y la recopilación y

CAPÍTULO I. ETAPA INICIAL.

- Adaptación reactiva a los cambios en los mercados.

Una aproximación a la valoración de las adaptaciones de los sistemas de información viene

1.2. La dimensión personal.

- Imagen externa, algunos ejemplos:

trabajo de los empleados. Contribuye a generar un clima de ineficiencia general de la

1.3. Obsolescencia o inadecuación.

- Limitaciones en la arquitectura del software:

Es el momento en que la organización se debe plantear un análisis en profundidad y de

2. Toma de requerimientos general.

- Sector primario: extracción de recursos naturales, incluye entre otros, minería,

- Industria pesada: transformación de materias primas en productos semielaborados,

Dentro de la clasificación anteriormente expuesta, la siguiente subclasificación corresponde

2.2. Identificación de las áreas afectadas por el proyecto.

- I+D+i y diseño de producto

- Procesos de dirección, con sus propios requerimientos, principalmente de análisis de

2.3. Detección de restricciones importantes.

3.3. Tipo de clientes.

3.4. Ámbito geográfico.

Origen Ventajas Inconvenientes

Mejores condiciones de Base instalada más reducida

Procesos de negocio Las “buenas prácticas” del

Tabla 1. Comparativa de soluciones por origen.

Es necesario asegurar que la oferta de mantenimiento, soporte e implantación local es lo

En algunos casos los ERP disponen de versiones verticales: conjuntos de adaptaciones

Otro caso relacionado con la funcionalidad disponible es el del desarrollo descentralizado.

Una implantación basada en el desarrollo de adaptaciones a partir de una solución horizontal

• Corrección de las especificaciones, ya que en la mayoría de los casos siguen estando

3.9. Aproximación cuantitativa de una clasificación cualitativa.

3.9.1. Base instalada.

- La base instalada actualmente a nivel global

También serán indicadores relevantes la oferta de empresas de servicios de consultoría que

3.9.2. Vertical vs horizontal.

3.9.3. Facilidad de adaptación.

En otras ocasiones la empresa consultora de la implantación puede mantener un estricto

3.9.4. Facilidad de configuración.

3.9.5. Coste total de propiedad.

3.9.6. Usabilidad y curva de aprendizaje.

• Ejemplo 1: proporcionalmente, el coste de gestión administrativa de un pedido con 100

Las interfaces de usuario diseñadas de acuerdo con estándares comúnmente aceptados

Algunos sistemas cuentan con mecanismos de ayuda tales como:

- Asistentes que indican el estado de avance de un determinado flujo de trabajo.

3.9.9. Tecnología que utiliza y uso de estándares.

- Sistemas operativos servidores y clientes