i
Equation Chapter 1 Section 1
Trabajo Fin de Máster
Máster Universitario en Organización Industrial y
Gestión de Empresas
Selección de herramienta ERP.
Aplicación en el sector bancario español
Autor: Daniel Ignacio Valenzuela López
Tutor: José Miguel León Blanco
Dep. Organización Industrial y Gestión de
Empresas I
Escuela Técnica Superior de Ingeniería
Universidad de Sevilla
Sevilla, 2016
ii
iii
Trabajo Fin de Máster
Máster Universitario en Organización Industrial y Gestión de Empresas
Selección de herramienta ERP.
Aplicación en el sector bancario español
Autor:
Daniel Ignacio Valenzuela López
Tutor:
José Miguel León Blanco
Profesor colaborador
Dep. Organización Industrial y Gestión de Empresas I
Escuela Técnica Superior de Ingeniería
Universidad de Sevilla
Sevilla, 2016
iv
v
Trabajo Fin de Máster: Selección de herramienta ERP. Aplicación en el sector bancario español.
Autor: Daniel Ignacio Valenzuela López
Tutor: José Miguel León Blanco
El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros:
Presidente:
Vocales:
Secretario:
Acuerdan otorgarle la calificación de:
Sevilla, 2016
El Secretario del Tribunal
vi
A mi familia
A mis maestros
vii
Resumen
El presente proyecto, consiste en la selección de una herramienta ERP1 corporativa, que se adecue a los
requerimientos funcionales (procesos de negocio) y tecnológicos de un Grupo Bancario en el mercado español.
Para ello, será necesaria la consecución de los siguientes objetivos:
Analizar los procesos que engloba un Grupo Bancario en su gestión diaria.
Analizar las alternativas existentes en el mercado, y especialmente, las utilizadas por otros Grupos
Financieros con visión global.
Elaborar una metodología de evaluación de herramientas ERPs, en cuanto a su funcionalidad,
costes y referencias en el mercado español.
Analizar las capacidades de las herramientas objeto de evaluación, para dar respuesta a las
necesidades identificadas tanto desde una perspectiva funcional como técnica.
Elección de una herramienta ERP.
1 Aplicación informática, que permite gestionar todos los procesos de negocio de una compañía, en forma integrada. Sus siglas provienen del término en inglés ENTERPRISE RESOURCE PLANNING. (21)
viii
ix
Abstract
The project for the selection of the corporative ERP tool for a Financial Group, aims for the evaluation of
a short list of tools, in order to identify the solution that offers the best coverage to the necessities of the
area. These necessities, embodied into a realistic business model, also look for:
- Simplifying the system map, unifying all tools into one.
- Offering a technology coverage to the business areas of the budget and budget check, and
purchases.
- Unifying the work procedures in identified business areas.
- Getting to an updated solution.
To achieve that evaluation, a set of key criteria was taken into consideration, with the according
importance to each one of the parts:
- Level of coverage of the business procedures identified, regarding to the proposed functionalities
for each solution.
- A 6 years projection of secondary costs of the implementation of each solution.
- Presence of the solution in the Spanish Financial Area.
The results of the carried evaluation are:
- Oracle ERP Cloud is the answer that presents the best assessment in the Functional Axis, due
to the level of functional coverage of its solution which approximates to 100% of the necessities
of the Financial Area, and also to its greater coverage of the requirements, both operative and
technical, distinguishing above the rest of the tools, the marks related to: evolutive strategies of
the solution, administration and movability.
- SAP is the solution which has the most presence in the Spanish financial area, and so it obtains
the best mark in the Reference Axis.
- Oracle ERP Cloud is the solution with the lowest added cost within 6 years, closely followed by
Microsoft AX in Cloud, obtaining both of these solutions, the best mark in the Economic Axis.
x
xi
Índice
Resumen vii
Abstract ix
Índice xi
Índice de Tablas xiii
Índice de Ilustraciones xiv
Índice de Gráficos xv
1 Enfoque 17 1.1 Identificación y clasificación de requisitos 17 1.2 Preselección de herramientas ERP 17 1.3 Evaluación de las herramientas preseleccionadas con respecto a los requisitos identificados 17 1.4 Selección de herramienta 17
2 Alcance del Proyecto 18 2.1 Visión del proyecto 18 2.1.1 ¿De dónde partimos? 18 2.1.2 ¿Dónde queremos llegar? 18
3 Análisis de Procesos 19 3.1 Objetivo 19 3.2 Mapa de los procesos de negocio 19 3.3 Inventario de procesos 19 3.3.1 Presupuestación 20 3.3.2 Compras 21 3.3.3 Contratación 22 3.3.4 Facturación 22 3.3.5 Pagos 23 3.3.6 Contabilidad Analítica 23 3.3.7 Contabilidad General 24 3.3.8 Cuentas a Cobrar 24 3.3.9 Gestión de Activos Fijos 25 3.3.10 Gestión de Proyectos 26 3.3.11 Gestión de Empleados 27
4 Lista Larga de ERP 28 4.1 Objetivo 28 4.2 Metodología utilizada 28 4.3 Selección 28 4.3.1 Fabricantes 28 4.3.2 Lista Larga de ERPs 30
5 Lista Corta de ERP 31 5.1 Objetivo 31 5.2 Metodología utilizada 31 5.3 Selección de la lista corta 32 5.3.1 Funcionalidades cubiertas 32
xii
5.3.2 Presencia en el mercado español 35 5.3.3 Presencia en el sector bancario 36 5.3.4 Criterio estratégico de implantación 38 5.4 Modelo de costes 44 5.5 Definición de la lista corta 45
6 Metodología de Evaluación 48 6.1 Objetivo 48 6.2 Metodología 48 6.2.1 Definición de los criterios de evaluación 48 6.3 Asignación de “pesos” para ponderar los resultados 50 6.3.1 Valoración de requerimientos 51 6.4 Evaluación de cada solución en base a los tres ejes 52 6.5 Extracción de conclusiones 52
7 Evaluación de Herramientas 53 7.1 Eje Funcional 53 7.1.1 Grado de Cobertura de Procesos 54 7.1.2 Requisitos Técnicos 55 7.1.3 Requisitos Operativos 55 7.2 Eje Económico 55 7.3 Eje Referencias 56 7.4 Puntuación General 57
8 Conclusiones 59
Bibliografía 61
Anexo – Desglose de Puntuaciones 63 1. Evaluación: Eje Funcional 63 2. Evaluación: Eje Económico 101 3. Evaluación: Eje Referencias 101
xiii
ÍNDICE DE TABLAS
Tabla 1 Cuota de mercado de los fabricantes en 2015 29
Tabla 2 Lista larga de ERPs 30
Tabla 3 Funcionalidades por herramienta ERP 33
Tabla 4 Cobertura de funcionalidades por herramienta ERP 34
Tabla 5 Fabricantes en el mercado español 36
Tabla 6 Presencia en el sector bancario español 37
Tabla 7 Alojamiento de herramientas ERP en cloud 40
Tabla 8 Ventajas e inconvenientes de un modelo cloud vs un modelo on-premise 43
Tabla 9 Coste aproximado de licencias de las herramientas ERP 44
Tabla 10 Coste aproximado de licencias anuales de las herramientas ERP 44
Tabla 11 Criterios de evaluación de fabricantes 46
Tabla 12 Ponderación de ejes 50
Tabla 13 Ponderación de sub-ejes 50
Tabla 14 Factores de puntuación del eje Funcional 51
Tabla 15 Factores de puntuación de Costes 51
Tabla 16 Factores de puntuación de Otros Criterios 52
Tabla 17 Puntuación Eje Funcional 53
Tabla 18 Puntuación Grado de Cobertura de Procesos 54
Tabla 19 Puntuación Requisitos Técnicos 55
Tabla 20 Puntuación Requisitos Operativos 55
Tabla 21 Puntuación Eje Económico 55
Tabla 22 Puntuación Eje Referencias 56
Tabla 23 Puntuación General 57
xiv
ÍNDICE DE ILUSTRACIONES
Ilustración 1 Enfoque del proyecto 17
Ilustración 2 Mapa de los procesos de negocio 19
Ilustración 3 Proceso de Planificación y Presupuestación 20
Ilustración 4 Proceso de Gestión de Solicitudes de Compra 21
Ilustración 5 Proceso de Gestión del Registro de Contratos 22
Ilustración 6 Proceso de Registro de Facturas 22
Ilustración 7 Proceso de Pago de Facturas 23
Ilustración 8 Proceso de Gestión de Contabilidad Analítica 23
Ilustración 9 Proceso de Contabilidad General 24
Ilustración 10 Proceso de Registro de Facturas y Cobros 24
Ilustración 11 Proceso de Gestión de Activos Fijos 25
Ilustración 12 Proceso de Gestión de Proyectos 26
Ilustración 13 Proceso de Gestión de Empleados 27
Ilustración 14 Cuota de mercado de los fabricantes en 2015 29
Ilustración 15 Criterios de evaluación de la metodología 48
xv
ÍNDICE DE GRÁFICOS
Gráfico 1 Puntuación Eje Funcional (I) 53
Gráfico 2 Puntuación Eje Funcional (II) 54
Gráfico 3 Puntuación Eje Económico 56
Gráfico 4 Puntuación Eje Referencias 57
Gráfico 5 Puntuación General (I) 58
Gráfico 6 Puntuación General (II) 58
xvi
17
1 ENFOQUE
l enfoque llevado a cabo a lo largo de este documento, debe dar respuesta a las siguientes cuestiones que
se plantearán en cada fase del proyecto:
Ilustración 1 Enfoque del proyecto Fuente: Elaboración propia
1.1 Identificación y clasificación de requisitos
- ¿Qué objetivos funcionales se persiguen?
1.2 Preselección de herramientas ERP
1.3 Evaluación de las herramientas preseleccionadas con respecto a los requisitos
identificados
- ¿Cómo pueden cubrir las alternativas tecnológicas contempladas, los requisitos funcionales recogidos?
- ¿Soportan los procesos identificados a los requisitos contemplados?
- ¿Es necesario alguna herramienta adicional a las contempladas inicialmente?
1.4 Selección de herramienta
- ¿Qué cobertura funcional proporcionan las herramientas evaluadas?
- ¿Cuáles son las soluciones tecnológicas óptimas a utilizar?
E Selección de una
herramienta
Evaluación de las herramientas
preseleccionadas con respecto a los
requisitos identificados
Preselección de herramientas
ERP
Identificación y clasificación de requisitos
18
2 ALCANCE DEL PROYECTO
a propuesta para la selección de la herramienta ERP, se basará en un análisis exhaustivo de las
siguientes dimensiones, que constituyen el eje sobre el que se soportará la toma de decisión de la
solución a implantar:
- Dimensión Funcional: desde un punto de vista funcional, el alcance del proyecto incluirá los procesos
involucrados en las siguientes áreas: contabilidad general, cuentas a pagar, cuentas a cobrar, activos fijos,
gestión de proyectos, presupuestación y contabilidad analítica, compras y empleados.
Objetivo: Obtener la visión de los procesos con perspectiva global y de largo plazo, contemplando asimismo
las necesidades específicas del negocio.
- Dimensión Económica
Objetivo: Evaluar los costes relacionados a cada herramienta y su modalidad de despliegue (on-premise o
cloud).
- Dimensión Referencial
Objetivo: Evaluar la presencia de las herramientas en el sector financiero español.
2.1 Visión del proyecto
2.1.1 ¿De dónde partimos?
- Conocer y documentar los objetivos desde el punto de vista de procesos.
- Clasificar y priorizar los procesos a analizar.
2.1.2 ¿Dónde queremos llegar?
- Identificar y valorar las potenciales áreas de evolución funcional.
- Aportar tendencias sectoriales y tecnológicas que puedan completar el modelo futuro.
- Confirmar modelo de procesos y sistema futuro.
- Evaluar las alterativas tecnológicas seleccionadas.
L
19
3 ANÁLISIS DE PROCESOS
on el fin de poder encontrar la herramienta ERP que se adapte de mejor manera a las necesidades de un
Grupo Bancario en el mercado español, en el presente capítulo se desarrollará un análisis exhaustivo de
los procesos que son requeridos a la hora de llevar a cabo las diferentes tareas de gestión del negocio. De
esta forma, cuando se valoren las herramientas ERP existentes en el mercado, se podrán seleccionar aquellas
que cubran de mejor manera los procesos identificados.
3.1 Objetivo
El objetivo de este apartado, será identificar los procesos que puede englobar cualquier Grupo Bancario en su
gestión diaria.
Para facilitar la revisión del análisis, este se ha articulado a través de los siguientes soportes:
- Mapa de los procesos de negocio. Representación gráfica de las actividades que se desarrollan en cada uno
de los procesos, así como una descripción detallada de cada actividad.
- Inventario de procesos. Relación de procesos que se consideran necesarios.
3.2 Mapa de los procesos de negocio
En la siguiente imagen, se representan los procesos de negocio genéricos que se pueden encontrar en un Grupo
Bancario.
Ilustración 2 Mapa de los procesos de negocio
Fuente: Elaboración propia
3.3 Inventario de procesos
El análisis se centra en identificar los procesos de negocio soportados por un Grupo Bancario, en la gestión de
su negocio; por lo que a continuación se detallan y desglosan los procesos identificados:
C
20
3.3.1 Presupuestación
El proceso de Presupuestación descrito, tendrá como objetivo llevar un control del gasto e inversión de un Grupo Bancario. Contendrá los subprocesos de Elaboración de
Presupuesto, Seguimiento y control, y Cierre.
En el siguiente diagrama de flujo, se representa el proceso de Planificación y Presupuestación:
Ilustración 3 Proceso de Planificación y Presupuestación
Fuente: Elaboración propia
21
3.3.2 Compras
El proceso de compras, describe el proceso de abastecimiento de un Grupo Bancario, y contempla los procesos de demanda, negociación con el proveedor, adjudicación y
certificación del trabajo.
En el siguiente diagrama de flujo, se representa el proceso de Gestión de Solicitudes de Compra:
2
Ilustración 4 Proceso de Gestión de Solicitudes de Compra
Fuente: Elaboración propia
2 RFP: Las siglas “RFP” en inglés significan invitación o convocatoria para enviar propuestas de proyectos. El glosario de The Nonprofit Good Practice Guide define el término de la siguiente manera: “Una invitación general al sector social de parte de una fundación donante a enviar solicitudes para un programa específico con un propósito específico.” (25)
22
3.3.3 Contratación
El objetivo del proceso, es la elaboración de la documentación contractual de las compras de un Grupo Bancario, de forma que se ajuste a las normas y condiciones
estandarizadas del sector.
En el siguiente diagrama de flujo, se representa el proceso de Gestión del Registro de Contratos:
Ilustración 5 Proceso de Gestión del Registro de Contratos
Fuente: Elaboración propia
3.3.4 Facturación
El proceso de facturación, describe el procedimiento desde la recepción de la factura del proveedor hasta su aprobación y contabilización.
En el siguiente diagrama de flujo, se representa el proceso de Registro de Facturas:
Ilustración 6 Proceso de Registro de Facturas
Fuente: Elaboración propia
23
3.3.5 Pagos
El proceso de pagos, describe las actividades que se ejecutan para el pago de las facturas.
En el siguiente diagrama de flujo, se representa el proceso de Pago de Facturas:
3
Ilustración 7 Proceso de Pago de Facturas
Fuente: Elaboración propia
3.3.6 Contabilidad Analítica
El proceso tendrá por objetivo, obtener un análisis de los gastos e ingresos a partir de los elementos de imputación definidos.
En el siguiente diagrama de flujo, se representa el proceso de Gestión de Contabilidad Analítica:
Ilustración 8 Proceso de Gestión de Contabilidad Analítica
Fuente: Elaboración propia
3 SEPA: La zona única de pagos en euros (SEPA por su acrónimo en inglés) es el área en el que ciudadanos, empresas y otros agentes económicos pueden efectuar y recibir pagos en euros en Europa,
dentro y fuera de las fronteras nacionales, en las mismas condiciones y con los mismos derechos y obligaciones, independientemente del lugar en que se encuentren. (26)
24
3.3.7 Contabilidad General
En el siguiente diagrama de flujo, se representa el proceso de Contabilidad General:
Ilustración 9 Proceso de Contabilidad General
Fuente: Elaboración propia
3.3.8 Cuentas a Cobrar
El proceso de Cuentas a Cobrar, contempla las actividades de gestión de clientes, facturación y cobro.
En el siguiente diagrama de flujo, se representa el proceso de Registro de Facturas y Cobros:
Ilustración 10 Proceso de Registro de Facturas y Cobros
Fuente: Elaboración propia
25
3.3.9 Gestión de Activos Fijos
El proceso de gestión de activos describe las actividades de alta, capitalización, amortización, ajustes y traspasos de los bienes de inversión de un Grupo Bancario.
En el siguiente diagrama de flujo, se representa el proceso de Activos Fijos:
Ilustración 11 Proceso de Gestión de Activos Fijos
Fuente: Elaboración propia
26
3.3.10 Gestión de Proyectos
El proceso responde a las necesidades de control de las actividades de los proyectos, así como de la obtención del detalle analítico requerido para la activación de las horas
de personal.
En el siguiente diagrama de flujo, se representa el proceso de Gestión de Proyectos:
Ilustración 12 Proceso de Gestión de Proyectos
Fuente: Elaboración propia
27
3.3.11 Gestión de Empleados
Este proceso describe las actividades de alta de empleados, hojas de gastos, imputación de tiempos y gestión de ausencias.
En el siguiente diagrama de flujo, se representa el proceso de Gestión de Empleados:
Ilustración 13 Proceso de Gestión de Empleados
Fuente: Elaboración propia
28
4 LISTA LARGA DE ERP
omo primer acercamiento hacia la selección e implementación de una herramienta ERP, se realizará una
lista con los ERPs que actualmente se encuentran en el mercado, teniendo en cuenta que cubran a grandes
rasgos las necesidades identificadas en el capítulo 3. El listado se construirá teniendo en cuenta tres
criterios: fabricante, funcionalidad y tamaño de la empresa.
4.1 Objetivo
Identificar un listado largo de ERPs que sirva como base, para que ya una vez analizados los requerimientos
funcionales de un grupo bancario, en una fase posterior permita componer una lista corta de ERPs que serán
evaluados en mayor detalle.
4.2 Metodología utilizada
Los criterios de selección utilizados, han sido los siguientes:
- Fabricante
Se han evaluado fabricantes, teniendo en cuenta la cuota de mercado global de ERPs. Esto asegura que se
selecciona un proveedor implantado globalmente, con capacidad para cubrir los requerimientos locales, con
un sistema de soporte eficiente que dé garantía al producto. Los fabricantes seleccionados por este método,
representan una cuota total del 63% del mercado (1).
Adicionalmente, se ha incluido a dos fabricantes que por estar focalizados en mercados locales, no aparecen
en el ‘top ten’ por cuota de mercado.
- Funcionalidad
A partir del análisis de procesos de negocio realizado en el capitulo anterior, se utilizará este como criterio
de selección de herramientas ERPs, condicionando que cubran en mayor medida los procesos de negocio
identificados bancario (2).
- Tamaño de la compañía
Una de las segmentaciones del mercado de ERPs es el tamaño de las compañías en las que son implantados,
medido desde el punto de vista de ingresos. Se ha determinado orientar el estudio hacia este segmento de
grandes compañías, con el objetivo de asegurar una escalabilidad futura del sistema (2).
4.3 Selección
4.3.1 Fabricantes
Como primera selección, se ha incluido a los diez fabricantes con más cuota de mercado durante 2015 según la
consultora Gartner (1); adicionalmente, se ha incluido otros dos fabricantes que aun no cumpliendo el criterio
de cuota de mercado, se consideran relevantes en este análisis. La mayor parte de los fabricantes, comercializan
varios ERPs con versiones ‘on-premise’ y ‘cloud’.
C
29
El motivo por el que se ha incluido a EPICOR e IFS dentro de la lista larga de ERPs, se debe a que si bien estas
herramientas no cumplen con la cuota de mercado para estar entre los diez ERPs con mayor cuota de 2015 según
el estudio de Gartner, estos cubren en gran medida los procesos de negocio estudiados en el capítulo 3 (3) (4).
2015 Posición Fabricante Cuota 2015 (%)
1 SAP 22,7
2 Oracle 11,6
3 Sage 6,3
4 Infor 5,8
5 Microsoft 4,9
6 Workday 3,5
7 Kronos 2,9
8 Ultimate Software 1,9
9 IBM 1,9
10 NetSuite 1,8
EPICOR < 1
IFS < 1
Tabla 1 Cuota de mercado de los fabricantes en 2015
Fuente: (1)
Ilustración 14 Cuota de mercado de los fabricantes en 2015
Fuente: Elaboración propia a partir del informe
‘Market Share Analysis ERP Software, Worldwide, 2015’ de Gartner (1)
30
4.3.2 Lista Larga de ERPs
De los fabricantes anteriormente listados, se han seleccionado los ERPs que más se ajustan a los requerimientos
funcionales de un Grupo Bancario, identificados en el capítulo 3.
La selección final de ERPs que compondrán la lista larga, ha sido elaborada en base a los criterios definidos,
teniendo en cuenta además factores como el tamaño de la compañía, la madurez del sistema, la tendencia del
mercado y la penetración en el mercado local.
Fabricante ERP Modalidad de Despliegue
SAP SAP S/4 HANA on-premise
cloud
Oracle Oracle e-Business Suite R12 on-premise
Oracle ERP Cloud cloud
Sage Sage X3 on-premise
Infor Infor Cloud Suite Business cloud
Infor10 ERP Enterprise on-premise
Microsoft
Microsoft Dynamics AX on-premise
cloud
Microsoft Navision 2016 on-premise
cloud
Epicor Epicor ERP on-premise
cloud
IFS IFS ERP Applications on-premise
cloud
Tabla 2 Lista larga de ERPs
Fuente: Elaboración propia
31
5 LISTA CORTA DE ERP
ras la elaboración de la lista larga de ERPs del capítulo 4, en este se incorporarán nuevos criterios de
evaluación para que la lista larga se reduzca, y de esta forma, poder obtener los ERPs que finalmente serán
evaluados.
5.1 Objetivo
El objetivo de este apartado es definir una lista corta de ERPs, que serán evaluados con mayor detalle en la
siguiente fase del proyecto, con el fin de proponer una herramienta ERP en base a criterios sólidos.
5.2 Metodología utilizada
La definición de la lista corta, se ha llevado a cabo teniendo en cuenta los siguientes criterios:
- Se ha tomado como punto inicial la lista larga de ERPs obtenida en el capítulo 4.
- Se ha realizado un análisis de ERPs a nivel Funcional, Tecnológico, Organizativo y Económico.
- Se han tomado como fuentes de información, una serie de documentos de análisis de consultoras
especializadas como: Gartner y Nucleus Research (1) (3) (4) (5) (6) (7) (8) (9).
Teniendo el carácter generalista que tienen los estudios realizados por Gartner y Nucleus Research en
cuanto a herramientas ERP, estos han sido utilizados como base para el estudio en el sector bancario.
- Se han tenido en cuenta nuevos criterios, con el fin de poder seleccionar las herramientas de la lista corta.
Estos criterios, que se desarrollarán más adelante, son los siguientes:
- Funcionalidades ofrecidas por las distintas soluciones y cobertura a los requerimientos a alto
nivel, identificados en un Grupo Bancario.
- Presencia en el mercado español.
- Presencia en el sector bancario español.
- Escalabilidad de la solución.
Además de estos criterios anteriormente detallados, se han mantenido los criterios que sirvieron para definir la
lista larga de ERPs:
- Cuota de mercado global: se han evaluado fabricantes, teniendo en cuenta la cuota de mercado global de
ERPs. Esto asegura que se está eligiendo un proveedor implantado globalmente, con capacidad para cubrir
los requerimientos locales, con un sistema y servicio de soporte eficiente, que dé garantía al producto.
Los fabricantes seleccionados por este método, representan una cuota total del 63% del mercado (1).
- Funcionalidades a alto nivel: se han seleccionado ERPs que cubrían las funcionalidades a alto nivel
requeridas por cualquier Grupo Bancario, basándose en informes especializados por área de negocio (2).
- Tamaño de compañía: uno de los criterios de segmentación del mercado de ERPs, es el tamaño medio de
las compañías desde el punto de vista de empleados que posee. El segmento que se ha tenido en cuenta, son
los ingresos de las compañías que implementan las soluciones, y de esta forma, centrar el estudio en el
segmento de grandes compañías, con el objetivo de asegurar una escalabilidad futura de la herramienta
seleccionada (2).
T
32
5.3 Selección de la lista corta
Partiendo de la lista larga obtenida en el capitulo 4, integrando los requerimientos del sector bancario y
consultando distintas fuentes de información de consultoras estratégicas especializadas, se han definido los
criterios que permitan seleccionar tres fabricantes, que estarán incluidos en la lista corta.
En los siguientes apartados se profundizarán y detallarán esos criterios, además de las razones que se han tenido
para descartar fabricantes de la lista corta.
5.3.1 Funcionalidades cubiertas
En la definición de la lista larga de ERPs, se han tenido en cuenta funcionalidades a alto nivel ofrecidas por las
distintas soluciones, que cubrían las necesidades identificadas en el capitulo 3.
Para esta lista corta se ha profundizado en esas funcionalidades, para revisar el grado de adecuación funcional
que ofrecía cada una de las herramientas seleccionadas en la lista larga, con los requerimientos identificados en
el sector bancario.
Como resultado de ello, se presenta primero la siguiente tabla con las funcionalidades cubiertas por área, para
cada una de las herramientas. Aunque ciertas funcionalidades no se necesiten en el sector bancario, el objetivo
de este ejercicio es dibujar el abanico de posibilidades que ofrece la herramienta, de cara a asegurar que esta
pueda acompañar el crecimiento futuro de un Grupo Bancario.
33
FINANZAS COMPRAS PROYECTOS BI EMPLEADOS
Fabricante Herramienta
Co
nta
bil
ida
d G
en
era
l
Co
nta
bil
ida
d A
na
líti
ca
Ges
tió
n i
nte
rco
mp
añ
ías
Presu
pu
est
ació
n
Co
nso
lid
ació
n
Cu
enta
s a
Pa
ga
r
Ap
rob
aci
ón
de f
actu
ra
s
Cu
enta
s a
Co
bra
r
Acti
vo
s F
ijo
s
Ges
tió
n T
eso
rería
Hu
b d
e c
on
tab
iliz
ació
n
Co
ntr
ol
presu
pu
est
ario
Ges
tió
n d
e p
ro
veed
ores
Ca
tálo
go
s d
e C
om
pra
s
Neg
ocia
ció
n p
ro
veed
ores
Po
rta
l d
e P
ro
veed
ores
Ela
bo
ra
ció
n d
e C
on
tra
tos
Peti
ció
n d
e c
om
pra
Ap
rob
aci
ón
de c
om
pra
s
Ges
tió
n d
e p
ro
yecto
s
Ges
tió
n d
e r
ecu
rso
s
Ges
tió
n d
e c
ost
es
Fa
ctu
ra
ció
n p
ro
yecto
s
Imp
uta
ció
n d
e h
ora
s
Rep
orti
ng
An
alí
tico
RR
.HH
.
Ga
sto
s d
e e
mp
lea
do
s
Pet
icio
nes
vaca
cion
es y
au
sen
cias
Nó
min
as
Ges
tió
n d
el
Ta
len
to
Fo
rm
ació
n
SAP SAP S/4 HANA on-
premise
SAP SAP S/4 HANA
cloud
ORACLE E-Business Suite R12 on-premise
ORACLE ERP Cloud
SAGE X3 on premise
INFOR Infor10 ERP
Enterprise on-premise
INFOR Infor Cloud Suite
Business
MICROSOFT Dynamics AX 2012
on-premise
MICROSOFT Dynamics AX 2012 cloud
MICROSOFT Navision 2016 on-
premise
MICROSOFT Navision 2016 cloud
EPICOR Epicor ERP on-
premise
EPICOR Epicor ERP cloud
IFS IFS ERP Applications
on-premise
IFS IFS ERP Applications
cloud
Cubre funcionalidad No cubre funcionalidad Funcionalidad requerida
Tabla 3 Funcionalidades por herramienta ERP
Fuente: Elaboración propia a partir de las siguientes fuentes: (10), (11), (12), (13), (14), (15), (16) y (17).
34
El siguiente ejercicio realizado en torno a las funcionalidades de las herramientas de la lista larga, ha sido
determinar en la siguiente tabla, el grado de cobertura ofrecida por cada solución a los requerimientos a alto
nivel en el sector bancario:
Tabla 4 Cobertura de funcionalidades por herramienta ERP
Fuente: Elaboración propia a partir de las siguientes fuentes: (10) (11) (12) (13) (14) (15) (16) (17) (18).
Las conclusiones de este ejercicio, permiten identificar las herramientas que no cubren ciertas funcionalidades
requeridas por el sector bancario:
- Contabilidad Analítica: Infor e IFS
- Aprobación de facturas: Infor
- Control Presupuestario: Microsoft Navision 2016
- Negociación con proveedores: Microsoft Navision 2016, Infor e IFS
- Portal de Proveedores: Microsoft Navision 2016, Sage, Infor, IFS e Epicor
- Gestión de costes de proyectos: IFS e Epicor
- Facturación de proyectos: IFS
- Imputación de horas: Microsoft Navision 2016, Sage e Epicor
- Gastos de empleados: Microsoft Navision 2016
35
Es necesario recordar en este punto, que no se ha realizado un análisis en profundidad de cada uno de los
requerimientos identificados en el sector bancario con la cobertura detallada ofrecida por cada herramienta, dado
que esta tarea se realizará en la siguiente fase del proyecto, con el fin de determinar la cobertura detallada de la
solución del modelo objetivo.
El análisis que se ha realizado en este punto, sólo pretende profundizar en las funcionalidades a alto nivel
ofrecidas por las distintas soluciones, para revisar con más detalle lo que ofrecía cada una de las herramientas
seleccionadas en la lista larga.
5.3.2 Presencia en el mercado español
Otro de los criterios que se ha utilizado para definir la lista corta, es la presencia en el mercado español de las
herramientas ERPs seleccionadas en la lista larga.
Se han utilizado los siguientes criterios para medir la “Presencia” del fabricante en el mercado español:
- Cuota de mercado: mediante la cuota de mercado del fabricante, se puede evaluar la penetración de la
solución en las empresas españolas y obtener así, un criterio cuantitativo del reparto del mercado total de las
herramientas ERPs implantadas en España, por fabricantes. Si bien esta información es publicada
regularmente por consultoras especializadas como Gartner, se trata sólo de la información a nivel mundial.
No existen como tal, informes publicados en España acerca de las cuotas de mercado de los distintos
fabricantes de herramientas ERPs, por lo que no ha sido posible obtener esa información.
- Historia del fabricante en el mercado español: mediante este criterio, se pretende identificar desde cuándo
está presente el fabricante en España, su “arraigo” en el mercado español a través de la plantilla de
empleados que tiene en España, y las previsiones de crecimiento en el mercado de España. Para realizar el
estudio, se han considerado estos criterios como básicos a la hora de asegurar que la herramienta ERP
seleccionada pertenece a un fabricante implantado en España, con una presencia histórica en el mercado
español, una plantilla de empleados importante y unas previsiones de crecimiento que aseguren una apuesta
fuerte del fabricante por el mercado español.
- Red de partners: El siguiente criterio que se quiere valorar para definir la presencia del fabricante en el
mercado español, es su red de partners (entendiendo “partners” como las empresas homologadas por parte
del fabricante, para la comercialización de sus soluciones ERPs). Es obvio que una red amplia de partners,
asegura que la solución tiene una presencia fuerte en el mercado, y que existe un abanico más grande de
empresas susceptibles de apoyar en la implantación, mantenimiento y evolución de la futura herramienta
ERP Corporativa. Por lo contrario, una red de partners reducida conlleva el riesgo de contar con pocas
alternativas y ser demasiado dependientes de unos cuantos partners, a la vez que se traduce por un nivel de
madurez menor de la solución en el mercado español.
- Solidez del fabricante: Mediante este último criterio, se quiere evaluar la solidez financiera del fabricante
y su apuesta por la herramienta que está comercializando. De esta forma, se asegura la situación financiera
de la empresa que distribuye la herramienta que se está evaluando, y de su “seriedad”.
36
Por lo tanto, y para evaluar la presencia en el mercado español de los distintos fabricantes seleccionados en la
lista larga, se ha confeccionado la siguiente tabla, con el fin de recoger la información de los distintos criterios
comentados anteriormente:
Fabricante Oficinas en España Plantilla empleados Antigüedad en España Partners
SAP Madrid, Barcelona 440 1987 137
ORACLE Madrid, Barcelona, Sevilla, A Coruña,
Valencia, Málaga, Bilbao
900 1987 410
MICROSOFT Madrid, Barcelona, Sevilla, Bilbao, Valencia 700 1988 65
SAGE
Ávila, Bilbao, Madrid, Mérida, S.C. Tenerife,
Tarragona, Zaragoza, Barcelona, Lleida,
Málaga, Sevilla, Valencia
1100 2003 35
INFOR Madrid, Barcelona 120 2002 25
IFS Madrid 40 2001 9
EPICOR Sin oficina Sin empleados Sin presencia en España 1
Tabla 5 Fabricantes en el mercado español
Fuente: Elaboración propia a partir de las siguientes fuentes: (10) (13) (14) (15) (16) (19).
La información recabada, pone en riesgo la presencia de estos 2 fabricantes en la lista corta:
- IFS: Si bien es cierto que las previsiones de crecimiento anunciadas para el 2016 están por encima del 10%,
IFS sólo cuenta con 40 empleados en España y sólo se apoya en una red de 9 partners (16). Estos números
no cumplen con los mínimos marcados para la selección de una herramienta ERP corporativa de garantía.
Es por ello, que IFS no se tendrá en cuenta como uno de los fabricantes a seleccionar en la lista corta.
- EPICOR: A pesar de ser uno de los mayores fabricantes de ERPs en el mundo, y de aparecer con frecuencia
en los distintos informes de las consultoras especializadas sobre el mercado de los ERPs, Epicor no dispone
de oficina en España (17). En 2013, firmó su primer y por ahora, único acuerdo de colaboración con una
empresa española, para la distribución y comercialización de sus soluciones en España. Debido a su ausencia
en el mercado español y a su nula red de partners, Epicor no se tendrá en cuenta como uno de los fabricantes
a seleccionar en la lista corta.
5.3.3 Presencia en el sector bancario
Otro criterio utilizado para definir la lista corta, es la presencia en el sector bancario de los fabricantes
seleccionados en la lista larga.
El objetivo es evaluar el nivel de penetración y aceptación de los fabricantes evaluados, dentro de las entidades
que componen el sector bancario español.
Se trata de un criterio clave a la hora de seleccionar los fabricantes y soluciones de la lista corta, ya que permite
obtener una visión clara de las apuestas de las demás entidades del sector bancario, en cuanto a su herramienta
ERP corporativa.
Debido a la complejidad que se ha encontrado a la hora de obtener las diferentes herramientas ERP utilizadas
actualmente en el sector bancario, sólo se ha podido realizar el estudio de 16 bancos, de los cuales se pasa a
describir sus soluciones implementadas en la siguiente tabla:
37
Entidad / Área de Negocio Finanzas Compras Proyectos RR.HH. Formación
BBVA SAP SAP SAP Oracle Peoplesoft Cornerstone
Santander SAP Oracle Peoplesoft Cornerstone
ISBAN (Grupo Santander) SAP SAP SAP Oracle Peoplesoft
Caixabank SAP SAP
Bankia HR Access SAP Success Factors
Sabadell – TSB SAP SAP Ariba SAP
Banco Popular SAP Success Factors
Banco Popular-e Microsoft Navision
Bankinter Conerstone
Ibercaja Microsoft AX Meta4
Fundación Ibercaja Microsoft AX
SAREB SAP SAP
Caja Laboral SAP
Inversis Oracle e-Business Suite
Andbank Oracle e-Business Suite Oracle e-Business Suite
EVO Consumer Finance Microsoft Navision
Solución en cloud
Tabla 6 Presencia en el sector bancario español
Fuente: Elaboración propia a partir de encuestas
38
De la información que se ha podido recopilar de entidades del sector bancario español, destacan algunos
fabricantes:
- SAP: SAP destaca claramente dentro del panorama bancario al estar presente en la gran mayoría de las
entidades, especialmente en aquellas de mayor tamaño, de las que se ha podido obtener información.
- MICROSOFT: La solución de Microsoft Navision se ha implementado recientemente en 2 entidades
del sector bancario. En cuanto a la solución de Microsoft Dynamics AX, está implementada en
IBERCAJA en el área de compras, y en la Fundación IBERCAJA para finanzas.
- ORACLE: Oracle está presente como fabricante en el sector bancario español, a través de varias
soluciones:
- ORACLE E-Business Suite: en el área de Finanzas.
- PEOPLESOFT: en el área de RR.HH.
- HYPERION Financial Management: en el área de consolidación financiera.
- HYPERION Planning: en el área de presupuestación.
- TALEO: en el área de gestión del talento.
Se observa con esta información, que la tendencia actual del sector es trabajar bajo un concepto de “best-of-
breed”4, teniendo diferentes soluciones para diferentes necesidades. Aunque es importante recalcar que esta
tendencia está cambiando últimamente, con los procesos de racionalización del mapa de herramientas llevado a
cabo por varias entidades del sector bancario en España, en los que se busca reducir el número de herramientas
utilizadas.
Otra de las conclusiones es, que no están incluidos algunos de los fabricantes de la lista larga: SAGE, INFOR,
IFS y EPICOR. Su no-presencia en las entidades del sector bancario a las que hemos tenido acceso, cuestionan
su inclusión en la lista corta.
5.3.4 Criterio estratégico de implantación
Otro criterio que se quiere poner de relieve, y en el que se basará la elección de la solución de cada fabricante
que conforma la lista corta, es el criterio estratégico a la hora de decidir entre la implantación de una herramienta
on-premise o una herramienta en cloud.
Para evaluar este criterio, se ha considerado:
- Estudios e Informes ofrecidos por las consultoras especializadas.
- Análisis de las tendencias del mercado a través de la información disponible del modelo de implantación de
herramientas ERP en el sector bancario.
- Cumplimiento legal de los fabricantes, en cuanto a la Ley de Protección de Datos en vigor en España.
- Elaboración de una comparativa a modo de resumen, con las ventajas e inconvenientes de cada una de las
modalidades de implantación.
El objetivo será determinar desde el punto de vista estratégico, cuál es la modalidad de implantación
recomendada.
Con esta última pauta, se dará por finalizado el análisis de los distintos criterios tenidos en cuenta y desarrollados
en los apartados anteriores, para la selección de los 3 fabricantes de la lista corta (Funcionalidades cubiertas,
presencia en el mercado español, presencia en el sector bancario español y criterio estratégico de implantación).
4 Término que suele utilizarse en el mundo del software para describir a aquel sistema que se podría catalogar como la mejor solución para desarrollar una actividad concreta.
39
5.3.4.1 Estudios e Informes de consultoras especializadas
Los estudios publicados por las consultoras especializadas acerca de la comparativa entre modelos on-premise
y cloud, apuntan todos hacia la misma dirección, y es el crecimiento contínuo de las implantaciones cloud con
respecto a las implantaciones on-premise. Ya no se habla de una tendencia que puede o no confirmarse en el
futuro, los datos avalan que el crecimiento de los modelos cloud con respecto a los modelos on-premise no tiene
marcha atrás, y pronto las instalaciones en cloud superarán a las instalaciones on-premise (en algunas
herramientas como el CRM, las implantaciones en cloud han alcanzado este año a las implantaciones on-
premise).
“Los sistemas on-premise serán tecnología obsoleta en 2 años” (18):
De acuerdo al estudio de Gartner, para el 2017 los ERP on-premise con un alto nivel de personalización, se
tratarán como tecnología obsoleta, y para el 2018 alrededor del 30% de las compañías habrán movido todas sus
aplicaciones de gestión empresarial a la nube. Como resultado, es posible que se realice una migración a un
conjunto de aplicaciones líderes en cada campo (ERP, CRM, HRM y demás) para ofrecer a las empresas unas
soluciones de gestión de procesos completas y en la nube.
“Los proyectos de herramientas Cloud consiguen más del doble de ROI5 que los proyectos de
implantación on-premise” (9):
Según el informe de la consultora Nucleus Research, los proyectos de implantación de herramientas en cloud
aportan 2.1 veces el ROI de un proyecto de implantación de herramientas on-premise. El estudio analiza casos
de empresas que emplean un amplio abanico de herramientas en Cloud, como ERP, HCM, CRM o SCM, y
explica que el multiplicador de ROI de una herramienta Cloud es alimentado por varios factores, como un coste
menor de entrada, un coste menor de mantenimiento y la capacidad de esta herramienta a generar más valor en
el tiempo que una herramienta on-premise, dado que no tiene que soportar costes de actualizaciones o subidas
de versiones de la herramienta.
En este estudio, también se profundiza sobre las diferencias en los costes de implantación y de mantenimiento
de una herramienta cloud, con respecto a una herramienta on-premise:
- El coste de implantación de una herramienta Cloud es 63% menor a una herramienta on-premise.
- El coste de mantenimiento de una herramienta Cloud es 55% menor a una herramienta on-premise.
Y se concluye, que con tal información es difícil encontrar argumentos que vayan en contra de los modelos
cloud.
5.3.4.2 Análisis de las tendencias en el sector bancario español
Se observa a partir de la información recabada del sector bancario español, que en su gran mayoría las
herramientas ERPs instaladas en dicho sector son “on-premise”, pero se va dibujando una tendencia de
sustitución de las herramientas on-premise por herramientas cloud.
Estas herramientas en cloud se centran por ahora en el área de RR.HH., donde el esfuerzo de sustitución de las
herramientas on-premise por nuevas herramientas en cloud es muy importante:
- Oracle Taleo
- Oracle HCM Cloud
- Cornerstone
- Success Factors
Al margen del área de RR.HH., cabe destacar que el Banco Sabadell tiene también una herramienta en Cloud
en el área de Procurement (SAP – Ariba).
5 Retorno de la inversión: compara el beneficio o utilidad obtenida en relación con la inversión realizada. Es utilizada para analizar el rendimiento de una inversión desde el punto de vista financiero.
40
Si bien es cierto, que las herramientas en cloud identificadas en el sector bancario español se centran casi
exclusivamente en el área de RR.HH., no se trata de un movimiento aislado (Santander, BBVA, Sabadell y
Bankia) y va sentando las bases de la tendencia que se viene observando en otros sectores, algo que todas las
consultoras especializadas predicen y es el cambio de modelo “on-premise” por el modelo en cloud.
Los actores del sector bancario, se encuentran en su mayoría con herramientas on-premise en las áreas de
Finanzas y Procurement con cierta antigüedad, y tendrán que llevar a cabo en un futuro cercano, un proceso de
renovación de esas herramientas mediante subidas de versiones (upgrades), reimplantaciones o implantación de
nuevas herramientas. Ese panorama es el más propicio para el movimiento de sustitución del modelo on-premise
por el modelo en cloud, dibujado por las distintas consultoras especializadas.
5.3.4.3 Cumplimiento legal
Ante la posibilidad de optar por una solución en cloud, es necesario revisar lo que marca la ley de protección de
datos en vigor en España, acerca de esta modalidad.
Para ello, el análisis se basará en el documento publicado por la Agencia Española de Protección de Datos:
“Guía para clientes que contraten servicios de Cloud Computing” (19). En cuanto a dicha ubicación, se comenta
lo siguiente:
- La localización de los datos, tiene importancia porque las garantías exigibles para su protección, son
distintas según los países en que se encuentren.
- Los países del Espacio Económico Europeo, ofrecen garantías suficientes y no se considera legalmente
que exista una transferencia internacional de datos. El Espacio Económico Europeo, está constituido
por los países de la Unión Europea e Islandia, Liechtenstein y Noruega.
- Si los datos están localizados en países que no pertenecen al Espacio Económico Europeo, habría una
transferencia internacional de datos, en cuyo caso, y dependiendo del país en que se encuentren, deberán
proporcionarse las garantías jurídicas adecuadas.
En la siguiente tabla, se ha recopilado información acerca de los países europeos en los que se alojan los
servidores cloud, de las soluciones de los distintos fabricantes de la lista larga:
Tabla 7 Alojamiento de herramientas ERP en cloud
Fuente: Elaboración propia a partir de las siguientes fuentes: (10) (13) (14) (15) (16) (19).
41
El único fabricante que no aloja los datos de sus clientes europeos en Europa, es EPICOR. Los demás
fabricantes, alojan los datos de sus clientes europeos en servidores propios, o servidores de otros proveedores
(Microsoft, Amazon, etc.) presentes en la Unión Europea.
Ningún fabricante aloja datos en servidores en España.
5.3.4.4 Ventajas e inconvenientes de un modelo cloud vs un modelo on-premise
A modo de resumen, y para finalizar este apartado acerca del criterio estratégico a tener en cuenta con respecto
al modelo de implantación de la herramienta ERP, se ha realizado la siguiente tabla, donde viene recogida la
valoración de distintos aspectos de los modelos en cloud y de los modelos on-premise:
42
ASPECTO CLOUD ON-PREMISE
Infraestructura Infraestructura IT nula y no requiere de perfiles expertos para el soporte. Soporte sólido del sistema y de la infraestructura, con necesidades de perfiles
expertos en el software. (instalación, configuración y administración)
Perfil de la compañía
Empresas de crecimiento rápido, que quieran invertir en una solución a su alcance,
capaz de crecer con ellos. Empresas que quieren la facilidad de acceder desde cualquier parte, sin invertir en
infraestructura IT propia.
Empresas en proceso de sustitución de sus herramientas ERP, con la reducción de costes como driver.
Empresas con la capacidad de realizar la inversión inicial para la adquisición e
implantación del sistema. El marco de tiempo mínimo para el ROI de una solución on-premise está entre 5 y 7 años.
Curva de aprendizaje Menor curva de aprendizaje. La curva de aprendizaje es mayor, debido a la mayor complejidad de un sistema
on-premise, que favorece grandes desarrollos y procesos a medida.
Tasa de adopción
Mayor tasa de adopción por parte de los usuarios, debido a: interfaces de usuario
mejoradas, acceso desde dispositivos móviles, herramientas de colaboración
sociales, etc.
La tasa de adopción por parte de los usuarios es menor, por culpa de la mayor
complejidad de una herramienta on-premise y por no contar con las ventajas de
usabilidad que ofrecen las herramientas en cloud.
Costes de software
Modalidad de Pago por Servicio.
Concepto de Pago por lo que utilizó.
El pago mensual cubre tanto el coste de licencia, como la infraestructura, el soporte técnico y las actualizaciones. Este pago se realiza en función del número de
usuarios.
El pago de la licencia permite a la compañía ser propietaria del software.
El coste de la licencia es mayor y a este coste, se tienen que sumar otros costes
relacionados con el mantenimiento y evolución del software.
Costes iniciales
Los costes de entrada son menores que los de las soluciones on-premise, ya que la
instalación, la preparación de la infraestructura y parte de la configuración, la realiza el fabricante. Asimismo, el precio de coste inicial de licencias suele ser menor que
en modalidad On-premise.
Los costes de entrada son mayores. Al coste inicial de licencias de software,
coste de infraestructura y de instalación, se tienen que sumar los costes de implantación.
Para un proyecto on-premise, se estima que se invierte entre 1€ y 2€ por cada €
gastado en la licencia inicial del software, tanto para la preparación de infraestructura como para la instalación.
Costes continuados
La evolución del sistema, está incluida en el servicio contratado con el fabricante y
la realiza el propio fabricante.
No se requieren perfiles especializados para realizar estas tareas.
Para asegurar la evolución del sistema con las actualizaciones del software, se
requiere de perfiles expertos que realicen esta labor, con su correspondiente
coste. Así mismo, para realizar subidas de versión más complejas, será necesaria la
configuración de un equipo de proyecto para llevar a cabo esa tarea,
considerando además, un coste medio del 50% del coste de la implantación inicial.
Costes de hardware
Una conexión a internet estable y estaciones de trabajo para los usuarios. Componentes como hardware y software de servidores en sus distintos entornos,
copias de seguridad, almacenamiento, recuperación de desastres, acceso remoto
y conectividad de la red.
Interfaz del usuario
Tecnología web que permite una interfaz intuitiva y normalmente personalizable, con muchas de las características fáciles de usar, que los usuarios de internet utilizan
en la mayoría de aplicaciones basadas en la web.
Tecnología con una interfaz adecuada al sistema operativo utilizado.
Personalización del software
Capacidades de personalizaciones menores que en una solución on-premise.
Hablamos de personalizaciones en la interface de usuario y posibilidad de crear campos adicionales.
Capacidades de personalizaciones más profundas, mediante desarrollos.
Apropiado para compañías que necesitan un alto nivel de personalización o que necesitan una gran cantidad de servicios de programación propios.
43
ASPECTO CLOUD ON-PREMISE
Integración con otros sistemas Modelo que acepta varios formatos de entrada de datos y que privilegia las APIs
para favorecer la integración con otros sistemas.
Capacidad de integración con menos formatos de entrada de datos que en un
modelo en cloud, y que se suele suplir mediante personalizaciones de interfaces.
Tiempo de implantación
Menor que el tiempo de implantación on-premise, ya que la instalación, la preparación de la infraestructura y parte de la configuración la realiza el fabricante.
Según estudios de firmas especializadas, el coste de implantación es, de media, un
63% menor.
Más largo, ya que involucra varias fases. Los costes de implantación son, de media, un 63% mayor que para soluciones en
cloud.
Tabla 8 Ventajas e inconvenientes de un modelo cloud vs un modelo on-premise
Fuente: Elaboración propia a partir de las fuentes: (20) (22) (23) (24) (25)
44
5.4 Modelo de costes
Con el fin de manejar un orden de magnitud, con respecto al modelo de costes de las herramientas de la lista
corta, se ha recabado información acerca de los costes de licencias de cada solución.
Para poder obtener una cotización aproximada de cada una de las herramientas, se ha tenido en cuenta el número
de usuarios promedio que pudiese tener un Grupo Bancario de tamaño medio.
- Finanzas: 25 usuarios
- Compras: 5 usuarios
- Proyectos: 5 usuarios
- Imputaciones de Horas y Notas de Gastos: 300 usuarios
- Solicitudes de compra: 1500 usuarios
- Aprobadores: 50 usuarios
Los datos ofrecidos a continuación, sólo sirven de información acerca de los costes aproximados de licencias de
las soluciones con mejor valoración. No se puede utilizar esa información como criterio de selección, al no
disponer de las cotizaciones exactas para las soluciones.
Coste Licencias Coste Infraestructura Upgrade de versión
Fabricante Herramienta Adquisición Recurrente
Anual Adquisición Mantenimiento
Anual Coste
asociado Adquisición
SAP SAP S/4 HANA on-premise * 450.000,00 € 90.000,00 € Sí Sí Sí 450.000,00 €
SAP SAP S/4 HANA cloud * No aplica 250.000,00 € No aplica No aplica No aplica No aplica
ORACLE E-Business Suite (on-premise) * 300.000,00 € 66.000,00 € Sí Sí Sí 300.000,00 €
ORACLE ERP Cloud * No aplica 245.000,00 € No aplica No aplica No aplica No aplica
MICROSOFT AX 2012 on-premise * 282.000,00 € 56.400,00 € Sí Sí Sí 282.000,00 €
MICROSOFT AX 2012 cloud * No aplica 236.000,00 € No aplica No aplica No aplica No aplica
Tabla 9 Coste aproximado de licencias de las herramientas ERP
Fuente: Elaboración propia a partir de las siguientes fuentes: (12) (18) (22)
Fabricante Herramienta Coste de licencias Anual
MICROSOFT AX 2012 on-premise * 282.000,00 €
MICROSOFT AX 2012 cloud * 236.000,00 €
SAP SAP S/4 HANA on-premise * 450.000,00 €
SAP SAP S/4 HANA cloud * 250.000,00 €
ORACLE ERP Cloud * 266.000,00 €
ORACLE E-Business Suite (on-premise) * 471.000,00 €
Tabla 10 Coste aproximado de licencias anuales de las herramientas ERP
Fuente: Elaboración propia a partir de las siguientes fuentes: (12) (18) (22)
45
Nota: Los costes indicados no incluyen IVA, son aproximados y no tienen en cuenta posibles descuentos que el
fabricante pueda acordar. Se han tenido en cuenta, el nº mínimo de usuarios exigibles por los fabricantes.
- AX 2012 on-premise *: el coste incluye las licencias del servidor y de distintas tipologías de usuarios
(Enterprise, Functional y self-service - para solicitudes de compras, registro de horas y hojas de gastos).
- AX 2012 cloud *: el coste incluye, las licencias de distintas tipologías de usuarios (Enterprise, Task-user y
self-service - para solicitudes de compras, registro de horas y hojas de gastos).
- SAP S/4 HANA on-premise y cloud *: el coste incluye, las licencias de distintas tipologías de usuarios
para las soluciones de Financials, Procurement y Projects.
- ERP Cloud *: el coste de licencias incluye, las siguientes soluciones: Financials, Purchasing, Projects, Time
and Labor, Expenses, OCR, OTBI y entorno adicional de pruebas.
- E-Business Suite (on-premise) *: el coste de licencias incluye, las siguientes soluciones: Financials,
Purchasing, i-Procurement, Projects, Time and Labor e i-Expenses.
5.5 Definición de la lista corta
Como se ha comentado anteriormente, para poder seleccionar los 3 fabricantes que conformarán la lista corta,
la metodología seguida ha permitido tener en cuenta una serie de “inputs”, lo más relevantes y exhaustivos
posibles, para obtener unas conclusiones sólidas que permitan ir seleccionando y descartando fabricantes, para
llegar a la lista corta.
Para ello, se tomarán en cuenta las siguientes consideraciones:
- Se ha tomado como referencia la lista larga de ERPs, seleccionados con anterioridad.
- Se ha realizado un análisis de requerimientos del sector bancario, desde los puntos de vista Funcional,
Económico y Referencial.
- Se han tomado como fuentes de información, una serie de documentos de análisis de consultoras
especializadas como: Gartner y Nucleus Research.
Se han evaluado los fabricantes y herramientas, bajo el prisma de los siguientes criterios:
- Funcionalidades cubiertas por las distintas soluciones, y cobertura a los requerimientos identificados en la
fase de análisis de requerimientos del sector bancario.
- Presencia en el mercado español.
- Presencia en el sector bancario español.
- Escalabilidad de la solución.
46
El resultado de la evaluación, de cada uno de los criterios para cada fabricante, es el siguiente:
Tabla 11 Criterios de evaluación de fabricantes
Fuente: Elaboración propia
El primer criterio (funcionalidades cubiertas), nos lleva a descartar las soluciones de Microsoft Navision, Sage,
Infor, IFS e Epicor, al no cubrir la totalidad de las funcionalidades requeridas por el sector bancario.
El segundo criterio (presencia en el mercado español), nos lleva a descartar las siguientes soluciones:
- IFS ERP Applications on-premise y cloud, así como Epicor ERP on-premise y cloud, al no cumplir con
los criterios mínimos establecidos, para asegurar una presencia fuerte en el mercado español.
El tercer criterio (presencia en el sector bancario español), nos lleva a descartar los siguientes fabricantes, que
no están presentes en las entidades del sector bancario a las que hemos tenido acceso: SAGE, INFOR, IFS e
EPICOR.
El cuarto criterio (escalabilidad de la solución), nos lleva a descartar la solución de IFS ERP Applications on-
premise y cloud, al no ofrecer la escalabilidad necesaria para acompañar el crecimiento del Grupo Bancario y
cubrir las funcionalidades del Grupo, con el objetivo de ser su ERP Corporativo.
El resultado de este análisis y evaluación, arroja los siguientes fabricantes que conforman la lista corta que se
propone a continuación:
- SAP: S/4 HANA (Cloud) y S/4 HANA (On-Premise)
- MICROSOFT: Dynamics AX 2012 (Cloud) y Dynamics AX 2012 (On-Premise)
- ORACLE: Oracle ERP Cloud (Cloud) y Oracle E-Business Suite R12 (On-Premise)
47
En base a las conclusiones expuestas en los apartados ‘Cumplimiento Legal’ y ‘Ventajas e inconvenientes de un
modelo cloud vs un modelo on-premise’, se recomienda centrarse en la evaluación de las herramientas en cloud,
de los fabricantes seleccionados en la lista corta:
- SAP: S/4 HANA (Cloud)
- MICROSOFT: Dynamics AX 2012 (Cloud)
- ORACLE: Oracle ERP Cloud (Cloud)
La elaboración de la lista corta es un hito importante del proyecto, que condiciona los siguientes pasos que
tendrán por objetivo, seleccionar las soluciones de los fabricantes de la lista corta y evaluarlas mediante:
- Cobertura de las herramientas al modelo de negocio objetivo.
- Matriz de evaluación de las herramientas.
Y que tendrá por resultado, la selección de una de las soluciones como la herramienta ERP, que mejor se adapta
a las necesidades del sector.
48
6 METODOLOGÍA DE EVALUACIÓN
l presente capítulo, describe la metodología a utilizar para la evaluación de las herramientas ERP
preseleccionadas en la lista confeccionada en el capítulo 5 (lista corta de herramientas): Oracle ERP
Cloud, SAP S/4HANA cloud, Microsoft Dynamics AX cloud.
6.1 Objetivo
Con esta metodología, se pretende ofrecer una herramienta que ayude a tomar una decisión con respecto a la
elección del producto, que mejor se adapte a las necesidades de un Grupo Bancario.
La metodología abarcará tres ejes considerados indispensables a la hora de valorar una herramienta ERP:
cobertura funcional, esfuerzo económico y referencias.
Para facilitar la valoración de las mismas, se empleará el análisis comparativo de las herramientas a través de
los siguientes componentes:
- Ponderaciones: donde se detalla el peso de cada eje, criterios y sub-criterios en la evaluación final.
- Análisis: donde se detallan las ponderaciones, resultados de la evaluación y resultados del análisis por
cada herramienta evaluada.
- Evaluación del Catálogo de Requisitos: criterios de evaluación de cobertura de procesos por módulos
(contabilidad general, cuentas por pagar, etc.).
- Otros Requisitos criterios de evaluación de los requisitos técnicos (Escalabilidad, movilidad,
interoperabilidad, etc.) y operativos (usabilidad, Reporting, trazabilidad de la herramienta). También
contendrá el resumen de la evaluación económica y de las referencias.
- Gráficos: representará los resultados obtenidos en el apartado de ‘Análisis’.
6.2 Metodología
Como premisa fundamental para la realización del análisis planteado, resulta de obligado cumplimiento la
definición y el consenso frente a la misma de la metodología a utilizar para la valoración de los productos. Para
la definición de la metodoogía se ha utilizado como ejemplo, la desarrollada en la fuente: (27).
Los pasos definidos para la metodología de evaluación, son los siguientes:
6.2.1 Definición de los criterios de evaluación
Ilustración 15 Criterios de evaluación de la metodología
Fuente: Elaboración propia
E
Eje Económico
Eje Funcional
Eje Referencias Evaluación de
ERP
49
Dentro de cada eje, se analizarán los siguientes criterios:
- Eje Funcional: permite conocer el potencial de la herramienta, para dar soporte a los procesos de negocio
de un Grupo Bancario, identificados en el capítulo 3.
Dentro de este eje, se evaluarán los siguientes criterios y sub-criterios:
- Requerimientos Funcionales.
Grado de cobertura de procesos: Nivel de cobertura de la solución para cada uno de los
requerimientos de negocio, identificados en el capitulo 3.
- Requerimientos Técnicos.
- Escalabilidad: Capacidad para cubrir necesidades futuras.
- Movilidad: Posibilidad de utilizar la herramienta con dispositivos móviles.
- Integración con operacionales y otros sistemas: Capacidad de comunicaciones con resto de
sistemas.
- Seguridad: Nivel de cumplimiento de normativas de seguridad aplicables a un Grupo
Bancario. En este criterio se evaluarán los siguientes sub-criterios: acuerdo de nivel de servicio
(SLA), mecanismo de recovery, país donde se alojan los datos en las modalidades cloud y si
los fabricantes son propietarios de los centros de datos.
- Administración: Facilidad y sencillez en la administración de herramienta evaluada.
- Requerimientos Operativos
- Estrategia de evolución de la herramienta: Capacidad de actualización de funcionalidades,
y flexibilidad en la incorporación de las mismas.
- Capacidad de Personalización/Adaptación: Se medirán criterios, como la capacidad de
personalización y adaptación a particularidades de los procesos del sector bancario.
- Workflows: Disponibilidad de una herramienta de configuración de flujos de trabajo.
- Trazabilidad: Capacidad para realizar seguimiento completo de los procesos.
- Reporting: Primará la posibilidad de obtener informes adaptados a las necesidades de un
Grupo Bancario.
- Usabilidad: medirá la fácil interacción de la herramienta con los usuarios.
- Eje económico: permite evaluar los costes relacionados a cada herramienta.
- Eje referencias: permite evaluar la presencia de las herramientas en el sector bancario español.
50
6.3 Asignación de “pesos” para ponderar los resultados
Tras la definición del detalle y profundidad de la evaluación a realizar, a continuación se detalla una propuesta
de peso para cada eje, con el fin de ponderar los resultados obtenidos:
Eje Porcentaje
Funcional 40%
Económico 50%
Referencias 10%
Tabla 12 Ponderación de ejes
Fuente: Elaboración propia
Cada uno de estos ejes se descompone en otros niveles con sus propias ponderaciones, tal y como muestra la
siguiente tabla:
Eje Funcional
Requisitos funcionales
Peso Criterio 70%
Contabilidad general y analítica 10%
Cuentas por pagar 15%
Cuentas por cobrar 10%
Activos Fijos 5%
Gestión de proyectos 15%
Presupuestación 20%
Compras 20%
Empleados 5%
Requisitos técnicos
Peso Criterio 10%
Escalabilidad 20%
Movilidad 20%
Integración con operacionales y otros sistemas 30%
Seguridad 10%
Administración 20%
Requisitos operativos
Peso Criterio 20%
Estrategia de evolución de la herramienta 15%
Capacidad de personalización/adaptación 10%
Workflows 20%
Trazabilidad 20%
Reporting 15%
Usabilidad 20%
Eje Producto
Coste agregado de la herramienta a 6 años 100%
Eje Referencias
Posicionamiento en el Sector Financiero 100%
Tabla 13 Ponderación de sub-ejes
Fuente: Elaboración propia
51
Las ponderaciones propuestas para cada módulo en los Requisitos Funcionales tienen por objetivo reflejar las
siguientes consideraciones:
- Importancia del módulo y de sus funcionalidades en los procesos de negocio, que se están evaluando y que
se incluirán en el ERP.
- Nivel de “estandarización” de los procesos de negocio de un Grupo Bancario, con respecto a las
funcionalidades propuestas por cada módulo. Por ello el módulo de Activos Fijos solo tiene un 5%, dado
que se ha considerado que las funcionalidades requeridas, son las mismas que las propuestas por el módulo
en las distintas soluciones y no difieren de las necesidades de otras empresas. Y, el módulo de Cuentas a
Cobrar tiene un 10%, dado que tiene que soportar la facturación en base a proyectos, donde los requisitos
son específicos para cada empresa. Por lo tanto se quiere “premiar” la cobertura del módulo a los
requerimientos de negocio, dando un mayor peso a los módulos que deben de cubrir requerimientos más
dispares y más complejos.
De esta forma, se obtiene un conjunto de criterios suficientemente significativos para el Benchmarking a realizar.
6.3.1 Valoración de requerimientos
Con respecto a la evaluación/puntuación de cada uno de los requerimientos que conforman cada eje, criterio y
sub-criterios, se propone distinguir entre la evaluación de cobertura funcional, evaluación de costes y el resto de
criterios.
Así, para el eje Funcional, se puntuará el grado de cobertura de procesos conforme a la siguiente tabla:
Normalizado Descripción Factor de puntuación 0 No cubre / Gran desarrollo 0%
1 Cubre con desarrollo medio 33,33%
2 Cubre con pequeño desarrollo 66,66%
3 Cubre con estándar 100%
Tabla 14 Factores de puntuación del eje Funcional
Fuente: Elaboración propia
Por otro lado, para la valoración de las estimaciones económicas, se procederá de la siguiente forma:
Coste estimado Valoración Factor de
puntuación
Cmín < Ci <= Cmín*1,1 3 0% Cmín*1,1 < Ci <= Cmín*1,3 2 33,33%
Cmín*1,3 < Ci <= Cmín*1,4 1 66,66% Ci > Cmín*1,4 0 100%
Tabla 15 Factores de puntuación de Costes
Fuente: Elaboración propia
52
Donde:
- Ci, es el coste del producto a valorar.
- Cmín, es el coste mínimo de los estimados entre todos los productos.
Por último, para los criterios que no puedan ponderarse de acuerdo al desarrollo que impliquen (por ejemplo
escalabilidad), se puntuará según los siguientes valores:
Normalizado Descripción Factor de
puntuación 0 No cubre las necesidades 0%
1 Casi nunca cubre 33,33%
2 Cubre con la mayoría de los casos 66,66%
3 Cubre en todos los casos 100%
Tabla 16 Factores de puntuación de Otros Criterios
Fuente: Elaboración propia
De esta forma, el resultado final se obtiene en función de la suma del producto de los pesos, por las puntuaciones
para cada uno de los niveles.
6.4 Evaluación de cada solución en base a los tres ejes
En base a los criterios y ponderaciones definidos anteriormente, se asigna a cada herramienta una puntuación
para obtener una valoración final de éstas.
La valoración de cada herramienta, vendrá dada por el siguiente cálculo:
- Val. del criterio = ∑Ponderación del sub-criterio * (Promedio de las características evaluadas).
- Val. del eje = ∑Ponderación del criterio * Valoración del criterio.
- Valoración de la herramienta = ∑Ponderación del eje * Valoración del eje.
Para la evaluación del sub-criterio de funcionalidades de negocio, los requerimientos o características
obligatorias tendrán un peso doble frente a los opcionales. Para el resto de sub-criterios, no se realizará dicha
distinción.
El detalle con todos los cálculos realizados, se incluirá en el Anexo – Desglose de Puntuaciones.
Así, cuanta más alta sea la valoración obtenida, más reflejará la adaptación de la herramienta al conjunto de
necesidades identificadas en este proyecto de selección (necesidades funcionales, tecnológicas, económicas,
etc.).
6.5 Extracción de conclusiones
El resultado de la evaluación de cada eje se puede interpretar mediante los gráficos incorporados en el análisis,
que permiten poner de relieve los puntos fuertes de cada solución y detectar puntos débiles a tener en cuenta.
Todo eso permite, llegar a unas conclusiones más allá de la única puntuación conseguida en el punto anterior, e
identificar los puntos fuertes y débiles de cada solución.
Además permite, recomendar la mejor solución para cubrir las necesidades de cualquier Grupo Bancario.
53
7 EVALUACIÓN DE HERRAMIENTAS
n este capítulo, se asignará una puntuación a cada una de las herramientas preseleccionadas en la lista corta,
confeccionada en la fase inicial del proyecto: Oracle ERP Cloud, SAP S/4HANA cloud, Microsoft
Dynamics AX cloud, a través de la metodología descrita en el capítulo 6. El detalle de cada una de las
evaluaciones indicadas a lo largo del capítulo, se encuentra en el Anexo – Desglose de Puntuaciones, ubicado al
final de documento.
7.1 Eje Funcional
Oracle ERP
Cloud
SAP S/4 HANA
Cloud
Microsoft Dynamics
AX Cloud
Score Score
Ponderado Score
Score
Ponderado Score
Score
Ponderado
0,96 0,83 0,88
Requisitos funcionales: grado
de cobertura de procesos 70% 0,99 0,69 0,91 0,64 0,90 0,63
Requisitos técnicos 10% 0,86 0,09 0,69 0,07 0,73 0,07
Requisitos operativos 20% 0,93 0,19 0,58 0,12 0,88 0,18
Tabla 17 Puntuación Eje Funcional
Fuente: Elaboración propia
A partir de la anterior tabla, se puede concluir que Oracle ERP Cloud es la solución que presenta una mayor
valoración en el eje funcional. Esta se aproxima al 100% de las necesidades del Grupo Bancario.
Adicionalmente, tanto en los requisitos operativos como en los técnicos, Oracle ERP Cloud es la solución que
presenta mayor valoración, destacando sobre el resto de herramientas la puntuación de los apartados relativos a:
estrategia de evolución de la solución, administración y movilidad.
Gráfico 1 Puntuación Eje Funcional (I)
Fuente: Elaboración propia
E
54
Gráfico 2 Puntuación Eje Funcional (II)
Fuente: Elaboración propia
A continuación, se pasa a desglosar cada una de las puntuaciones representadas en la tabla anterior:
7.1.1 Grado de Cobertura de Procesos
Oracle ERP
Cloud
SAP S/4 HANA
Cloud
Microsoft Dynamics
AX Cloud
Score Score
Ponderado Score
Score
Ponderado Score
Score
Ponderado
0,99 0,91 0,90
Contabilidad general y
analítica 10% 0,98 0,10 0,97 0,10 0,91 0,09
Cuentas a pagar 15% 1,00 0,15 0,99 0,15 0,88 0,13
Cuentas a cobrar 10% 0,99 0,10 0,96 0,10 0,97 0,10
Activos Fijos 5% 0,96 0,05 0,90 0,05 0,94 0,05
Gestión de proyectos 15% 1,00 0,15 0,87 0,13 0,95 0,14
Presupuestación 20% 0,99 0,20 0,80 0,16 0,94 0,19
Compras 20% 1,00 0,20 0,95 0,19 0,81 0,16
Empleados 5% 0,93 0,05 0,95 0,05 0,88 0,04
Tabla 18 Puntuación Grado de Cobertura de Procesos
Fuente: Elaboración propia
55
7.1.2 Requisitos Técnicos
Oracle ERP
Cloud
SAP S/4 HANA
Cloud
Microsoft Dynamics
AX Cloud
Score Score
Ponderado Score
Score
Ponderado Score
Score
Ponderado
0,86 0,69 0,73
Escalabilidad 20% 1,00 0,20 1,00 0,20 1,00 0,20
Movilidad 20% 0,83 0,17 0,50 0,10 0,50 0,10
Integración con operacionales
y otros sistemas 30% 0,67 0,20 0,67 0,20 0,67 0,20
Seguridad 10% 0,92 0,09 0,92 0,09 0,92 0,09
Administración 20% 1,00 0,20 0,50 0,10 0,67 0,13
Tabla 19 Puntuación Requisitos Técnicos
Fuente: Elaboración propia
7.1.3 Requisitos Operativos
Oracle ERP
Cloud
SAP S/4 HANA
Cloud
Microsoft Dynamics
AX Cloud
Score Score
Ponderado Score
Score
Ponderado Score
Score
Ponderado
0,93 0,58 0,88
Estrategia de evolución de la
herramienta 15% 1,00 0,15 0,78 0,12 0,78 0,12
Capacidad de
personalización/adaptación 10% 1,00 0,10 0,67 0,07 0,80 0,08
Workflows 20% 1,00 0,20 1,00 0,20 1,00 0,20
Trazabilidad 20% 1,00 0,20 0,67 0,13 1,00 0,20
Reporting 15% 1,00 0,15 0,00 0,00 1,00 0,15
Usabilidad 20% 0,67 0,13 0,33 0,07 0,67 0,13
Tabla 20 Puntuación Requisitos Operativos
Fuente: Elaboración propia
7.2 Eje Económico
Oracle ERP
Cloud
SAP S/4 HANA
Cloud
Microsoft Dynamics
AX Cloud
Score Score
Ponderado Score
Score
Ponderado Score
Score
Ponderado
1,00 0,00 1,00
Coste agregado de la
herramienta a 6 años 100% 1,00 1,00 0,00 0,00 1,00 1,00
Tabla 21 Puntuación Eje Económico
- A partir del estudio realizado, se concluye que Oracle ERP Cloud es la solución con el menor coste
agregado a 6 años, seguida muy de cerca por Microsoft AX en cloud. Es por ello que se ha valorado
ambas soluciones con un 100%. En cuanto a la solución proporcionada por SAP, se ha valorado con un
0%, ya que los costes de implementación de ésta, es mucho más elevado que el de las primeras dos
soluciones.
56
Gráfico 3 Puntuación Eje Económico
Fuente: Elaboración propia
7.3 Eje Referencias
Oracle ERP
Cloud
SAP S/4 HANA
Cloud
Microsoft Dynamics
AX Cloud
Score Score
Ponderado Score
Score
Ponderado Score
Score
Ponderado
0,67 1,00 0,67
Posicionamiento en el Sector
Financiero 100% 0,67 0,67 1,00 1,00 0,67 0,67
Tabla 22 Puntuación Eje Referencias
Fuente: Elaboración propia
A partir del estudio realizado, se obtiene que SAP es la solución que más presencia tiene en el sector bancario
español. Su solución de compras (SAP Ariba), también está presente en entidades bancaria españolas.
Las soluciones de Oracle y de Microsoft AX tienen una presencia similar en el mercado español.
57
Gráfico 4 Puntuación Eje Referencias
Fuente: Elaboración propia
7.4 Puntuación General
Oracle ERP
Cloud
SAP S/4 HANA
Cloud
Microsoft Dynamics
AX Cloud
Score Score
Ponderado Score
Score
Ponderado Score
Score
Ponderado
0,95 0,43 0,92
Funcional 40% 0,96 0,39 0,83 0,33 0,88 0,35
Económico 50% 1,00 0,50 0,00 0,00 1,00 0,50
Referencias 10% 0,67 0,07 1,00 0,10 0,67 0,07
Tabla 23 Puntuación General
Fuente: Elaboración propia
Del estudio realizado, se pueden efectuar las siguientes conclusiones:
- Oracle ERP Cloud es la solución con la mejor puntuación.
- La segunda solución mejor puntuada, es la solución de Microsoft AX en cloud.
- Las diferencias entre estas 2 soluciones que encabezan la evaluación realizada, se encuentran en el eje
funcional, motivadas por el alto grado de cobertura funcional de Oracle ERP Cloud a los requerimientos
evaluados, así como por la mayor valoración alcanzada en los requisitos operativos y técnicos, por parte de
la solución 100% cloud de Oracle.
58
Gráfico 5 Puntuación General (I)
Fuente: Elaboración propia
Gráfico 6 Puntuación General (II)
Fuente: Elaboración propia
59
8 CONCLUSIONES
os resultados del proyecto de selección de la herramienta ERP a implantar en un Grupo Bancario, muestran
las 2 soluciones mejor valoradas, Oracle ERP Cloud y Microsoft AX 2012 en cloud, obteniendo la
primera la mayor puntuación (0,95).
Más allá de los propios números arrojados por la evaluación realizada a través de los criterios y sus
ponderaciones, me gustaría como conclusión, proponer unas recomendaciones basadas en la interpretación de
estas evaluaciones y en la experiencia obtenida a los largo de este proyecto.
Confirmando la evaluación obtenida en el proyecto de selección, mi recomendación a la hora de seleccionar una
herramienta ERP para cualquier Grupo Bancario es, la herramienta de Oracle ERP Cloud por las siguientes
razones:
- Producto:
- La herramienta propone un alto grado de cobertura a los requerimientos y necesidades
identificadas, como queda reflejado en la puntuación obtenida en el criterio de “Requisitos
Funcionales”: 0,99.
- Esta cobertura se consigue mediante funcionalidades estándares, reduciendo al máximo el
número de desarrollos adicionales y su posterior mantenimiento y evolución.
- La herramienta ofrece una solución de Business Intelligence integrada, que permite al usuario un
acceso rápido a la información para su análisis y toma de decisiones.
- El fabricante garantiza la evolución y actualización del producto, sin costes adicionales,
permitiendo al cliente disponer siempre de la última versión actualizada, sin necesidad de
acometer y financiar proyectos de subidas de versiones.
- Herramienta Cloud:
- Al ser una herramienta desarrollada 100% en cloud, está pensada y diseñada para ese despliegue,
aprovechando las últimas tecnologías disponibles y los últimos estándares de programación e
integración.
- La herramienta es 100% web con acceso mediante URL desde PC y Tablet.
- La herramienta es modular y ofrece flexibilidad en su implantación, con la posibilidad de
implantar módulos de forma gradual, acompañando así el crecimiento de cualquier Grupo
Bancario.
- El “Look & Feel” y facilidad de navegación de la herramienta.
- Varias aplicaciones móviles están disponibles para la gestión de las notas de gastos, la imputación
de tiempos y la gestión de las aprobaciones.
- Económica:
- La herramienta ha sido evaluada como la más económica en un horizonte a 6 años.
- La solución solo lleva asociada costes de suscripción. Este modelo ofrece una mejor visibilidad de
los costes asociados al ERP, y facilita las tareas de presupuestación, evitando “imprevistos” y la
necesidad de reservar partidas presupuestarias excepcionales.
- No es necesario invertir en la adquisición de infraestructura.
- Desaparecen los costes asociados a la implantación y mantenimiento de la infraestructura.
- Desaparecen los costes asociados al mantenimiento de las licencias.
- No es necesario invertir en proyectos de subidas de versión.
L
60
- Estratégica:
- La implantación de un ERP en cloud, es una decisión estratégica que permitiría abrazar una
tendencia que se está dibujando últimamente en el sector bancario, con la implantación de
soluciones en cloud.
- Esta decisión posicionaría a cualquier Grupo Bancario en el centro del mapa del sector bancario,
con la utilización de una herramienta moderna y actual, permitiendo un acceso más rápido a la
información, una gestión más eficiente de los recursos, con las consiguientes ganancias de
productividad asociadas.
- Tomar la decisión de implantar una herramienta on-premise, retrasaría más años la decisión de
implantar una herramienta en cloud y sería dejar escapar una oportunidad de cambio.
61
BIBLIOGRAFÍA
1. Chris Pang, Robert P. Anderson, Nigel Montgomery. Market Share Analysis: ERP Software, Worldwide,
2015. s.l. : Gartner, 29 de Abril de 2016.
2. Rayner, Nigel. Market Guide for Core Financial Management Applications. s.l. : Gartner, 23 de Diciembre
de 2014.
3. EPICOR. Planificación de Recursos Empresariales. [Online] http://www.epicor.com/lac/solutions/erp.aspx.
4. IFS. Software ERP ágil y fácil de usar. [Online] http://www.ifsworld.com/es/solutions/enterprise-resource-
planning/.
5. Deborah R Wilson, Michelle A. Brosnahan, John E. Van Decker, Alexander Drobik, Nigel Rayner.
Modernizing Finance and Procurement Applications Primer for 2016. s.l. : Gartner, 21 de Enero de 2016.
6. Desere Edwards, Deborah R Wilson, Nigel Montgomery, Ray Barger Jr. Cool Vendors in Procurement and
Sourcing Technology, 2016. s.l. : Gartner, 9 de Mayo de 2016.
7. Hestermann, Christian. Critical Decision Points for Cloud-Based ERP Selection. s.l. : Gartner, 10 de Mayo
de 2016.
8. —. How to Select the Right Cloud ERP/Business Application. s.l. : Gartner, 12 de Febrero de 2016.
9. WETTEMANN, Rebecca. TECHNOLOGY VALUE MATRIX FIRST HALF 2015 ERP. s.l. : Nucleus
Research, Abril de 2015.
10. Wettemann, Rebecca. CLOUD DELIVERS 2.1 TIMES MORE ROI. s.l. : Nucleus Research, Abril de 2016.
11. UNIT4. Software ERP para Gestión de Empresas. [Online] http://www.unit4.com/es/productos/erp.
12. SAP. SAP HANA. [Online] http://go.sap.com/spain/product/technology-platform/hana.html.
13. Oracle. Oracle E-Business Suite. [Online]
https://www.oracle.com/es/products/applications/ebusiness/overview/index.html.
14. —. Oracle Fusion Applications. [Online]
https://www.oracle.com/lad/products/applications/fusion/overview/index.html.
15. SAGE. Capacidades del producto. [Online] http://www.sagex3.com/es-es/product_capabilities.
16. INFOR. Infor LN. [Online] http://es.infor.com/product_summary/erp/ln/.
17. Microsoft. Microsoft Dynamics NAV. [Online] Microsoft. https://www.microsoft.com/es-es/dynamics/erp-
nav-overview.aspx.
18. —. Solución ERP de Microsoft (Dynamics). [Online] Microsoft. https://www.microsoft.com/es-
es/dynamics/erp-ax-overview.aspx.
19. ORACLE. ORACLE. [Online] https://www.oracle.com/applications/erp/index.html.
20. Predicts 2014: The Rise of the Postmodern ERP and Enterprise Applications World. s.l. : Gartner, 2014.
21. Datos, Agencia Española de Protección de. Guía para clientes que contraten servicios de Computing.
[Online] 2013.
http://www.agpd.es/portalwebAGPD/canaldocumentacion/publicaciones/common/Guias/GUIA_Cloud.pdf.
22. Pat Phelan, Carol Hardcastle, Terri-Lynn B. Thayer. Change Your ERP and Business Applications. Support
Strategies as You Move to the Cloud. s.l. : Gartner, 3 de Marzo de 2016.
23. Michael Guay, Chris Pang, Christian Hestermann, Nigel Montgomery. Magic Quadrant for Single-Instance
ERP for Product-Centric Midmarket Companies. s.l. : Gartner, 9 de Diciembre de 2015.
24. Christopher Iervolino, John E. Van Decker. Magic Quadrant for Strategic Corporate. Performance
Management Solutions. s.l. : Gartner, 31 de Mayo de 2016.
62
25. Anderson, Robert P. Competitive Landscape: ERP for Services-Centric Industries. s.l. : Gartner, 7 de Enero
de 2016.
26. SAP. SAP. [Online] http://go.sap.com/product/enterprise-management/s4hana-
erp.html?campaigncode=CRM-ES16-3DI-
PPC_ITAC&gclid=COGi0taMjc4CFVDaGQodApYLag&gclsrc=ds.
27. Chiesa, Florencia. Google Académico. [Online] [Cited: Julio 24, 2016.]
http://www.jfsalazar.com/sistemas2/metodologia-para-seleccion-de-sistemas-erp.pdf.
28. Guide, Nonprofit Good Practice. http://www.npgoodpractice.org/. [Online]
29. SEPA. http://www.sepaesp.es. [Online] http://www.sepaesp.es/sepa/es/faqs/sepa/.
63
ANEXO – DESGLOSE DE PUNTUACIONES
1. Evaluación: Eje Funcional
a. Grado de Cobertura de Procesos
i. Contabilidad General y Analítica
Oracle ERP Cloud SAP S/4 HANA Cloud Microsoft Dynamics AX Cloud
Nº Req. Descripción de
requerimiento Prioridad
Grado de
Cobertura Descripción
cobertura Grado de
Cobertura Descripción cobertura Grado de
Cobertura Descripción cobertura
A Maestros
REQ-GP-CG-1 Estructura
organizativa
El sistema debe permitir la gestión de
varias sociedades y varias
organizaciones o unidades operativas
Requerido 3
Es sistema es multisociedad y
también permite definir unidades
operativas
3 En SAP se permite la existencia de varias
sociedades 3
Sí, es un sistema multiempresa, sin límite de empresas a
gestionar y con posibilidad de que las empresas tengan
configuraciones iguales o distintas entre sí. También
permite establecer relaciones jerárquicas entre empresas
para posterior consolidación y/o Reporting.
REQ-GP-CG-2
Gestión de
periodos
contables
El sistema debe ofrecer un calendario
con 12 periodos contables y un número
configurable de periodos de ajustes
Requerido 3
Se pueden crear calendarios con los
periodos requeridos, especificando
periodos solamente de ajustes 3
Entre las diferentes opciones de SAP, se
permiten hasta 4 periodos de ajuste además de
los 12 periodos naturales. 3
El sistema permite establecer periodos contables de forma
configurable, así como cerrar periodos a una fecha que se
quiera o cierres o bloqueos parciales
REQ-GP-CG-3 Plan de
cuentas
Posibilidad de disponer de varios
planes de cuentas. Requerido 3
Se pueden mantener de forma
paralela diferentes planes de
cuentas. Incluso para la misma
sociedad se pueden diferentes planes
de cuenta mapeados
3 SAP permite trabajar con varias planes de
cuentas asociados a una sociedad 3
Posibilidad de disponer de varios planes de cuentas para
las distintas empresas. Es decir n planes contables para n
empresas
REQ-GP-CG-4
Gestión de
cuentas
contables
Alta centralizada de cuentas contables Requerido 3
Se pueden definir las cuentas
contables como se requiera. Se
puede compartir el mismo plan de
cuentas para diferentes sociedades
3
SAP permite que el alta de cuentas contables
esté centralizada a través de objetos de
autorización. 3 Desde cada empresa, o plan contable
REQ-GP-CG-5
Información
adicional de
las cuentas
contables
Posibilidad de definir para cada cuenta
contable, una serie de información
adicional (p.e.: si requiere impuestos, si
es de analítica, si es una cuenta de
impuestos, si permite apuntes
negativos, si es posible contabilizar
directamente o está limitada a apuntes
de contabilidades auxiliares, si permite
presupuestación).
Requerido 3
Se permite definir muchos atributos
de la cuenta: cuenta de detalle o
resumen, si admite o no
presupuestación, si permite o no
contabilizaciones, el tipo de cuenta
(activo, pasivos, ingresos, gastos,
capital,..)
3 Se cubre con la parametrización de los status
de campo. 3
Esta funcionalidad está disponible por configuración en el
maestro de cuentas contables.
REQ-GP-CG-6
Gestión de
dimensiones
analíticas
Permitir la creación y gestión de
diferentes dimensiones o variables
analíticas, como la empresa, cliente,
grupo de clientes, productos, ubicación
geográfica, proyecto, centro de coste,
Requerido 3
En la estructura organizativa se
definen los segmentos analíticos
necesarios. Los valores de cada
segmento pueden ser agrupados con
3 Existen diferentes dimensiones que pueden ser
ampliadas con un pequeño desarrollo 3
Permite la creación de dimensiones analíticas ilimitadas,
tanto con valores personalizados, como utilizando los
valores de algunos de los maestros (clientes,
proveedores..) como dimensión analítica
64
Oracle ERP Cloud SAP S/4 HANA Cloud Microsoft Dynamics AX Cloud
Nº Req. Descripción de
requerimiento Prioridad
Grado de
Cobertura Descripción
cobertura Grado de
Cobertura Descripción cobertura Grado de
Cobertura Descripción cobertura
etc. jerarquías padre/hijo
REQ-GP-CG-7 Estructura
analítica
El sistema debe permitir definir la
estructura analítica del Grupo por
división, unidad de negocio, producto,
cliente, proyecto…
Requerido 3
En la estructura organizativa se
definen los segmentos analíticos
necesarios. Los valores de cada
segmento pueden ser agrupados con
jerarquías padre/hijo
3 Existen diferentes dimensiones que pueden ser
ampliadas con un pequeño desarrollo 3 Permite crear y configurar dimensiones analíticas
REQ-GP-CG-8 Jerárquica
analítica
El sistema debe permitir la
organización en jerarquías de los
diferentes elementos y variables
analíticas.
Requerido 3
Los valores de cada segmento
pueden ser agrupados en un o más
jerarquías. Estas jerarquías pueden
mantener históricos temporales de
cambio
3 Se permite tanto la creación de estructuras de
centros de coste como de centros de beneficio 3 Las dimisiones pueden tener jerarquías y dependencias
B Operaciones
REQ-GP-CG-9
Asientos
contables
manuales
El sistema debe permitir realizar
cualquier tipo de asiento contable
manual. El sistema puede identificar
cuáles son manuales de los que
provienen de los módulos auxiliares
Requerido 3
Se pueden entrar asientos contables
manualmente. Si el asiento proviene
de otro módulo, siempre queda
grabado el módulo auxiliar
3
SAP permite diferenciar tanto por clase de
documentos, como por cuenta contable si se
puede realizar contabilizaciones manuales o
automáticas
3 Se puede hacer asientos contables manuales, automáticos
así como establecer plantillas.
REQ-GP-CG-10
Asientos
contables
masivos
El sistema debe permitir importar
asientos contables de forma masiva
mediante plantillas en Excel
Requerido 3
Existen plantillas específicas de
Excel para la entrada de asientos
contables. Con un add in que
permite buscar información de
valores, campos desplegables y la
lógica de validación al importar la
información
3 Se pueden crear plantilla para la importación
de asientos contables 3
Existe un add in de Excel que se integra con Dynamics
AX
REQ-GP-CG-11 Contabilizació
n automática
El módulo de Contabilidad General
recibirá asientos automáticos
provenientes de cualquiera de los
módulos auxiliares (compras,
proyectos, cuentas a pagar, cuentas a
cobrar, activos fijos).
Requerido 3
Todos estos módulos generan
asientos contables con capacidad de
definir reglas de creación a través de
un motor configurable
3 Todas las contabilizaciones de los libros
auxiliares se reflejan en la contabilidad general. 3
También se establece el control para el cuadre de saldos
entre contabilidad y gestión.
REQ-GP-CG-12 Validaciones
Contables
El sistema debe permitir establecer
reglas de validación respecto a los
componentes de la estructura contable
(cuentas contables y segmentos
analíticos) de forma que se valide el
cumplimiento de las mismas ante
cualquier registro, ya sea manual o
automático. En dichos casos se
mostrará un mensaje de error indicando
que no se permite guardar la
información inconsistente.
Requerido 3 Se pueden establecer todas las reglas
de validación necesarias. 3
Se realiza a través de la definición de
validaciones y/o sustituciones 3
Permite la configuración de estructuras contables con Cta.
contable y dimensiones analíticas configurable por el
usuario que permite control y validación de apuntes. Así
como avisar en caso de inconsistencias
REQ-GP-CG-13
Identificación
de apuntes
contables
El sistema debe permitir diferenciar los
distintos apuntes contables a través de
categorías de asientos o tipos de
asientos.
Requerido 3 Se pueden crear los tipos de asientos
que se requiera 3
Las contabilizaciones en SAP se realizan en
documentos pudiendo definir tantos como
necesitemos.
3
Configuración de distintos diarios por tipo de asiento con
funcionalidad específica para cada uno de ellos (cobros,
pagos, contabilización, etc.)
65
Oracle ERP Cloud SAP S/4 HANA Cloud Microsoft Dynamics AX Cloud
Nº Req. Descripción de
requerimiento Prioridad
Grado de
Cobertura Descripción
cobertura Grado de
Cobertura Descripción cobertura Grado de
Cobertura Descripción cobertura
REQ-GP-CG-14 Numeración
de apuntes
El sistema deber permitir numerar los
apuntes contables de forma
diferenciada por tipo de movimiento y
con la posibilidad de que la secuencia
de numeración se reinicie cada año.
Requerido 3
Para cada tipo de movimiento se
puede crear un contador diferente y
que se reinicien cada año 3
Cada documento puede contar con un rango de
números específico. 2 La secuencia numérica puede reiniciarse manualmente
REQ-GP-CG-15
Generación de
apuntes
automáticos
El sistema debe permitir registrar
apuntes periódicos de forma
automática.
Requerido 3
A través de la funcionalidad del
allocation manager se pueden crear
asientos repetitivos que se ejecuten
de forma periódica
3 Funcionalidad de documentos periódicos. 2 Existen diarios periódicos, pero el proceso debe ser
iniciado por el usuario
REQ-GP-CG-16
Diferentes
libros
contables
Existencia de diferentes libros de
contabilidad definibles por sociedad
para organizar las diferentes
transacciones contables de cada
sociedad que conforman el Grupo.
Opcional 3 Se pueden crear varios libros
contables para cada sociedad 3 SAP permite varios libros contables 3
Cada entidad jurídica podrá tener sus libros contables en
función de su configuración (tipo de actividad por
ejemplo)
REQ-GP-CG-17
Operaciones
intercompañía
s
El sistema debe permitir identificar en
todo momento en que empresa se está
haciendo el apunte contable y mantener
un registro de las operaciones
intragrupo que faciliten el proceso
posterior de consolidación.
Opcional 3
La empresa forma parte de un
segmento obligado de la cuenta
contable.
Para poder indicar si una transacción
es intercompany, se puede utilizar
uno de los segmentos de la
estructura contable
3 SAP permite la contabilización intercompany 3
El sistema identifica la empresa y se pueden marcar
asientos como intercompany a nivel analítico. Así como
funcionalidad intercompany específica.
REQ-GP-CG-18 Operaciones
de cierre
El sistema deber permitir realizar las
tareas de cierre mensual y anual:
arrastre de saldos, valoración de
partidas en otras monedas,
reclasificación de deuda. El proceso de
cierre debe controlar que no quedan
partidas pendientes de contabilizar en
ningún módulo, y que todos los
módulos a su vez están cerrados.
Requerido 3
El sistema permite todos estos
procesos mensuales o anuales. Se
puede controlar el estado de cada
módulo y compañía a través de un
monitor de cierre. También se
visualizan por módulo todas las
transacciones pendientes de
contabilizar
3 SAP cuenta con funcionalidades específicas
para realizar los procesos de cierre. 2
Lo que no hace el estándar es la verificación de que no
queden partidas pendientes. Puede ser un desarrollo
sencillo
REQ-GP-CG-19 Operaciones
de cierre
Posibilidad de cerrar módulos de forma
independiente (p.e.: cerrar Cuentas a
Pagar y Cuentas a Cobrar y dejar
abierto Contabilidad General)
Requerido 3 Se permite el cierre gradual de
módulos 3
SAP permite cerrar periodos de forma
independiente por módulos. 3
Cierres parciales por módulos, grupo de usuarios, o
incluso cuentas contables concretas por fechas
REQ-GP-CG-20 Operaciones
de cierre
Generación automática de asientos de
apertura y cierre de ejercicio. Requerido 3
Es una de las funcionalidades
ofrecidas por el módulo de
Contabilidad General 3
Con los procesos de cierre se realizan las
contabilizaciones necesarias 3 Estándar de cierre de año y asientos correspondientes
REQ-GP-CG-21 Imputaciones
analíticas
El sistema debe permitir que se
imputen de forma analítica cualquier
ingreso o gasto (o apunte contra una
cuenta de balance) desde cualquier
módulo.
Requerido 3
Desde cualquier módulo se pueden
realizar imputaciones analíticas al
nivel requerido de forma manual o
automática
3 Los objetos de imputación en SAP permiten
recibir imputaciones desde cualquier módulo 3
Permite la introducción de datos especificando la
información analítica en toda la aplicación
REQ-GP-CG-22 Repartos de
costes
Permitir repartos de los gastos o
ingresos imputados a un objeto
analítico a otros objetos a partir de
Requerido 3
Existe una funcionalidad específica
(allocation manager) que permite
realizar repartos
3 Se permite el reparto de costes desde un objeto
a otro. Dependiendo del tipo de objeto y
criterio puede ser necesario un desarrollo
3 Desde el módulo de Cost Accounting, se pueden hacer
repartos analíticos
66
Oracle ERP Cloud SAP S/4 HANA Cloud Microsoft Dynamics AX Cloud
Nº Req. Descripción de
requerimiento Prioridad
Grado de
Cobertura Descripción
cobertura Grado de
Cobertura Descripción cobertura Grado de
Cobertura Descripción cobertura
indicadores de reparto. adicional
REQ-GP-CG-23 Indicadores de
reparto
Permite informar de indicadores de
negocio de fuentes externas al ERP
para poder definir criterios de reparto.
Requerido 3
Se permite la importación de
indicadores de reparto mediante
asientos estadísticos 2
Se necesita un desarrollo para la importación
de esas fuentes externas 2
Se necesita un desarrollo para la importación de esas
fuentes externas
C Reporting
REQ-GP-CG-24 Trazabilidad
directa
El sistema debe permitir identificar el
usuario que creó el asiento de diario,
fecha de creación, y último usuario y
fecha en que fue modificado.
Requerido 3 Los asientos quedan grabados con
toda esta información 3
SAP registra en cada uno de los documentos
quien y cuando se creó y si ha sufrido
modificaciones, quien /es y cuando se han
realizado dichas modificaciones.
3 Existe un log de cambios configurable para los
movimientos que se desee trazar
REQ-GP-CG-25 Trazabilidad
inversa
En movimientos correspondientes a
transacciones de facturas, cobros,
pagos, compras, activos fijos, etc. el
sistema debe permitir profundizar
desde el asiento contable hasta el origen
de la transacción en el módulo auxiliar
(Drill-Down).
Requerido 3
Siempre se permite realizar un drill-
Down desde el saldo hasta la
transacción original 3
SAP permite navegar hasta el documento
contable desde operación de los módulos
auxiliares. 3
Existe navegabilidad de la transacción a contabilidad y en
sentido contrario. Navegabilidad estándar de Dynamics
AX
REQ-GP-CG-26 Informes
oficiales
Permitir obtener de forma automática
los informes oficiales de España: libro
diario, balances, cuenta de pérdidas y
ganancias, informes de IVA, etc.
Requerido 3
Las localizaciones españolas
contemplan estos procesos excepto
el balance y cuenta de resultados
que debe ser definido según el plan
de cuentas específico de la
compañía pero utilizando
herramientas de Reporting
entregadas.
3 SAP permite extraer del sistema la información
legal. 3
Con el módulo específico para reportes, Management
Reporter, se pueden crear todo tipo de informes.
REQ-GP-CG-27 Consultas on-
line
El sistema deber permitir en todo
momento realizar consultas por pantalla
o mediante informes de la información
incluida en el módulo de Contabilidad
General.
Requerido 3
Se permiten realizar consultas de
toda la información entrada en el
módulo
3 SAP cuenta con multitud de informes y
permite desarrollar informes a medida 3
Existe la posibilidad de personalizar la información que
los usuarios ven en pantalla por perfiles o de forma
individual. El usuario puede ser autosuficiente para
mostrar o consultar la info sobre la que tiene permisos de
acceso.
REQ-GP-CG-28
Construcción
de reporte por
usuarios
Se requiere que el usuario pueda
realizar consultas sin necesidad de
conocimientos técnicos. Todos los
reportes deben ser exportables
fácilmente a Excel.
Requerido 3
Todos los informes y consultas se
pueden pasar al Excel. Mediante
asistentes se pueden crear informes
fácilmente gracias al BI integrado y
sus esquemas de estrella
3 SAP permite tanto la generación de queries
como de reports. 3
Integración Nativa Office. Posibilidad de generar
informes sobre Excel. Existe la posibilidad de
personalizar la información que los usuarios ven en
pantalla por perfiles o de forma individual. El usuario
puede ser autosuficiente para mostrar o consultar la info
sobre la que tiene permisos de acceso.
D Integración
REQ-GP-CG-29 Integración
con proyectos
Integración del módulo de contabilidad
general y analítica con el módulo de
gestión de proyectos de forma que
cualquier operación registrada de
proyectos que requiere de una
contabilización (contabilización de
costes, ingresos, facturación, traspaso a
costes de horas a proyectos) se registre
automáticamente en el libro contable
Requerido 3 La integración con proyectos es total 3 Todos los módulos de SAP están integrados. 3 Todos los módulos están integrados y forman parte de un
todo modular.
67
Oracle ERP Cloud SAP S/4 HANA Cloud Microsoft Dynamics AX Cloud
Nº Req. Descripción de
requerimiento Prioridad
Grado de
Cobertura Descripción
cobertura Grado de
Cobertura Descripción cobertura Grado de
Cobertura Descripción cobertura
REQ-GP-CG-30
Integración
con Cuentas a
Pagar
Integración del módulo de contabilidad
general con el módulo de Cuentas a
Pagar de forma que cualquier operación
registrada que requiere de una
contabilización (facturas, anticipos,
abonos, pagos, etc.) se registre
automáticamente en contabilidad
general y analítica.
Requerido 3
Cualquier operación realizada desde
módulos y con reflejo contable crea
automáticamente apuntes en
contabilidad general
3
Toda operación realizada en el módulo de
cuentas a pagar tiene su reflejo en la
contabilidad general. 3
Todos los módulos están integrados y forman parte de un
todo modular.
REQ-GP-CG-31
Integración
con Cuentas a
Cobrar
Integración del módulo de contabilidad
general con el módulo de Cuentas a
Cobrar de forma que cualquier
operación registrada de clientes que
requiere de una contabilización
(facturas, abonos, cobros, etc.) se
registre automáticamente en
contabilidad general y analítica.
Requerido 3
Cualquier operación realizada desde
módulos y con reflejo contable crea
automáticamente apuntes en
contabilidad general
3
Toda operación realizada en el módulo de
cuentas a cobrar tiene su reflejo en la
contabilidad general. 3
Todos los módulos están integrados y forman parte de un
todo modular.
REQ-GP-CG-32
Integración
con Activos
Fijos
Las operaciones realizadas en el
módulo de Activos Fijos que requieren
de una contabilización (altas, bajas,
capitalización, amortizaciones, etc.)
deben quedar registradas de forma
automática en contabilidad general y
analítica.
Requerido 3
Cualquier operación realizada desde
módulos y con reflejo contable crea
automáticamente apuntes en
contabilidad general
3
Toda operación realizada en el módulo de
activos fijos tiene su reflejo en la contabilidad
general.
3 Todos los módulos están integrados y forman parte de un
todo modular.
REQ-GP-CG-33
Integración
con otros
sistemas
Permitir la integración de asientos
contables en el módulo de contabilidad
general mediante las herramientas
disponibles en el sistema (interfaces,
webservices, ficheros .csv, etc.)
Requerido 3
las integraciones pueden ser
mediante webservices, ficheros de
interface o a través de Excel
3 SAP permite la integración con otros sistemas
tanto si son SAP como si no lo son. SAP PI 1
Requiere un análisis detallado de las herramientas para su
integración
REQ-GP-CG-34
Extracción de
información y
envío a otros
sistemas
Permitir extraer información del
módulo de Contabilidad general, en
ficheros, para poder remitirlos a los
sistemas externos en caso de que se
requiere alguna integración
Requerido 3
El sistema permite extraer
información de cualquier tabla en
formato fichero gracias a la utilidad
de BI Publisher
3 SAP permite la integración con otros sistemas
tanto si son SAP como si no lo son. 3
Capacidad de extracción y generación de ficheros
estándar, Excel, XML, ASCII, etc.
REQ-GP-CG-35
Integración y
conciliación
de
información
de otros
sistemas
Permitir importar información contable
desde fichero y conciliar la información
de saldos que venga en ese fichero con
la información de saldos en el ERP
Requerido 1
El sistema permite importar
información contable desde un
fichero Excel pero será necesario un
desarrollo para conciliar esa
información con la información del
ERP
1
Se pueden crear plantilla para la importación
de saldos contables pero hay que realizar un
desarrollo para el proceso de conciliación
1 Requiere un desarrollo adicional
68
ii. Cuentas por Pagar
Oracle ERP Cloud SAP S/4 HANA Cloud Microsoft Dynamics AX Cloud
Nº Req. Descripción de
requerimiento Prioridad
Grado de
Cobertura
Descripción
cobertura Grado de
Cobertura Descripción cobertura Grado de
Cobertura Descripción cobertura
A Maestros
REQ-GP-CP-1 Maestro de
proveedores
Permitir dar de alta proveedores y
mantenerlos en un maestro de
proveedores y acreedores con
información obligatoria y adicional
Requerido 3
Existe un maestro de proveedores /
acreedores con la información
comentada, de carácter obligado o
adicional
3
Dentro de los datos maestros de terceros se
puede especificar qué información es
obligatoria y cual es opcional
3
Maestro de proveedores configurable y con posibilidad de
añadir o reducir campos. Así como establecer campos
obligatorios.
REQ-GP-CP-2
Homologació
n de
proveedores
Una vez registrado el proveedor, el
sistema deberá ofrecer herramientas
que permitan distinguir si el proveedor
está homologado o no.
Requerido 3
Mediante el módulo de evaluación
de proveedores podemos validar si
el proveedor está homologado o no
y realizar un seguimiento de que
esté al corriente de sus obligaciones
o certificaciones durante toda el
ciclo de vida de relación con el
tercero.
3 SAP permite la homologación de proveedores 2
La Homologación del proveedor se puede definir a través
del WorkFlow de proveedores, incorporando información
a definir para valorar cada homologación
REQ-GP-CP-3
Direcciones
de
proveedores
Permitir que cada proveedor pueda
contar con información diferenciada en
función de las direcciones o
ubicaciones de los mismos, así como de
las distintas sociedades que pudiese
tener un Grupo Bancario.
Opcional 3
Los proveedores pueden tener
diferentes sites con información
específica de datos de proveedor
3 Se permiten diferentes direcciones: Dirección
de facturación, dirección de entrega…. 3
Capacidad de múltiples direcciones por proveedor así
como de gestionar distintos sitios de una empresa.
REQ-GP-CP-4 Formas de
pago
Permitir registrar en el maestro de
proveedores y acreedores la forma de
pago acordada (cheque, transferencia
bancaria, pagarés, contado, etc.) y
poder obtener el formato electrónico
correspondiente para su envío al Banco.
Requerido 3 Se define al proveedor la forma de
pago acordada por defecto 3
SAP permite la parametrización de diferentes
formas de pago 3
Formas de pago por defecto para proveedores y
acreedores. Formato electrónico de envió a banco según
normativa SEPA
REQ-GP-CP-5 Condiciones
de pago
Permitir la definición de las
condiciones de pago y su posterior
asignación a los proveedores.
Requerido 3
Se definen las condiciones de pago
y luego se asignan a los proveedores
como condiciones por defecto
3 SAP permite la parametrización de diferentes
condiciones de pago 3
Condiciones configurables, por vencimientos, periodos
días de pago o no pago, así como cálculo automático de
los vencimientos.
REQ-GP-CP-6
Cuentas
bancarias de
proveedores
Permitir la creación y asignación de
cuentas bancarias de proveedores de
forma centralizada en la aplicación con
todos sus datos (datos de control como
el código SWIFT, grupo bancario,
dirección, etc.).
Requerido 3
A nivel centralizado podemos
definir todas las entidades/sucursales
con toda la información comentada.
A Nivel proveedor sus cuentas
bancarias específicas incluida su
cuenta IBAN
3 Dentro de los datos maestros de terceros se
recogen la información de la cuentas bancarias 3
En el maestro de proveedores se define la info del
proveedor y existe un formulario para el alta de cuentas
bancarias de proveedor
REQ-GP-CP-7
Posibilidad de
bloquear e
inactivar
proveedores y
acreedores
Posibilidad de retener el pago a
proveedores.
Permitir la inactivación de proveedores
y acreedores.
Requerido 3
Se pueden inactivar proveedores a
nivel de site o bien retener los pagos
de todas sus facturas a nivel global 3
SAP permite bloquear tanto pagos a terceros
como bloquear la contabilización de nuevos
documentos en un tercero 3
En el maestro de proveedores se puede modificar su
estado a:
- Factura: Permite realizar compra, recepción de las
mismas, pero bloquea la creación de la factura.
- Todo: No se puede realizar operaciones con el
proveedor.
- Pago: Sólo bloqueo del pago
- Pedido: Sólo bloqueo de la creación de pedido.
- Nunca: Proveedor que nunca se debe de bloquear.
Se puede informar del motivo y fecha del cambio de
estado, pudiendo aplicar el cambio a todas las entidades
69
Oracle ERP Cloud SAP S/4 HANA Cloud Microsoft Dynamics AX Cloud
Nº Req. Descripción de
requerimiento Prioridad
Grado de
Cobertura
Descripción
cobertura Grado de
Cobertura Descripción cobertura Grado de
Cobertura Descripción cobertura
jurídicas.
REQ-GP-CP-8
Numeración
de
documentos
Disponer de numeración diferente para
cada tipo de documento (facturas,
abonos, anticipos).
Opcional 3
Se pueden definir secuencias de
numeración diferentes por
categorías 3
En SAP se permite que cada clase de
documento tenga un rango de números
específico. 3 Posibilidad de configuración de series alfanuméricas
B Operaciones
REQ-GP-CP-9
Registro
preliminar de
facturas
Permitir el registro de una factura
"pendiente de autorizar" que no permita
su contabilización hasta que no se
produzca la autorización de la misma.
Requerido 3 Se pueden entrar o registrar facturas
en un estado pendiente de validación 3
SAP permite el registro de documentos
preliminares no teniendo reflejo contable, hasta
su completa contabilización/autorización. 3
Se pueden establecer workflow de aprobaciones de
facturas
REQ-GP-CP-10
Datos
automáticos
en factura
Permitir que a la hora de registrar una
factura se hereden datos del maestro de
proveedores, susceptibles de ser
modificados.
Requerido 3
Al entrar una factura se heredan por
defecto los datos del maestro del
proveedor como las condiciones de
pago
3
Cuando se registran documentos, SAP propone
datos (condiciones de pago, modos de pago…)
heredados del dato maestro, siendo estos
susceptibles de cambio.
3
Esta es la funcionalidad de AX genérica. Recibe los
valores por defecto pero se pueden cambiar para un
registro o documento en concreto.
REQ-GP-CP-11
Permitir la
carga masiva
de facturas
mediante
ficheros
Permitir cargar facturas de forma
masiva mediante ficheros Requerido 3
Se pueden cargar facturas mediante
ficheros, servicios web o hojas de
cálculo Excel 3
Se pueden crear plantilla para la importación
de facturas 1
Se requiere un desarrollo para poder importar facturas
mediante plantillas
REQ-GP-CP-12
Workflow de
aprobación de
factura
Permitir definir niveles de aprobación
de facturas Requerido 3
Existe un workflow de aprobación
de facturas que puede ser modelado
mediante la herramienta BPM
incorporada. Se podrán definir los
niveles requeridos, en serie o
paralelo.
3 SAP permite realizar workflows de aprobación
con diferentes niveles. 3
Work Flows configurables para aprobaciones. Pueden ser
por importe, tipo, departamento, grupo de usuarios, etc.
REQ-GP-CP-13 Contabilizació
n de facturas
Permitir la contabilización de la
facturación Requerido 3
Las facturas pueden ser
contabilizadas de forma individual o
bien masiva
3
SAP permite registrar facturas tanto desde el
módulo de cuentas a pagar como desde el
módulo de compras.
3 Es facturación integrada y permite facturación manual o
automática.
REQ-GP-CP-14 Digitalización
de Facturas
Disponer de una herramienta OCR en
el ERP para realizar el escaneo y
registro de facturas.
Requerido 3
El ERP incorpora una herramienta
de solución de imágenes que incluye
el proceso de reconocimiento OCR,
el almacenamiento en el contenedor
de imágenes y el enrutamiento a la
persona o departamento que deba
validar
3 SAP cuenta con SAP VIM para cubrir esta
funcionalidad 1
Es necesario incorporar una herramienta OCR e integrarla
con el ERP. AX se integra con las principales
herramientas OCR del mercado.
REQ-GP-CP-15
Registro de
pagos según
criterios
Permitir generar pagos atendiendo a
unos determinados filtros seleccionados
(p.e.: fecha de vencimiento de las
facturas a pagar).
Permitir la generación de una propuesta
de pagos en la que se podrán quitar y
añadir pagos
Requerido 3
Existe la funcionalidad de
generación de propuestas de pago
masivas en función de plantillas de
selección y fechas de vencimiento.
Una vez generadas las propuestas de
pago se pueden quitar pagos, añadir
de nuevos,…
3 SAP cuenta con el programa de pagos
automáticos 3
Se pueden hacer filtros sobre cualquier información de la
aplicación
REQ-GP-CP-16 Bloqueo de
pagos Capacidad de retener el pago de una
factura, indicándolo en la propia Requerido 3
Se pueden retener facturas para el
pago 3 SAP permite bloquear pagos. 3 Se puede retener el pago de forma en algunos casos de
forma automática dependiendo de parámetros
70
Oracle ERP Cloud SAP S/4 HANA Cloud Microsoft Dynamics AX Cloud
Nº Req. Descripción de
requerimiento Prioridad
Grado de
Cobertura
Descripción
cobertura Grado de
Cobertura Descripción cobertura Grado de
Cobertura Descripción cobertura
factura. establecidos en Workflows de pagos o de forma manual.
REQ-GP-CP-17
Norma
Bancaria
CSB34
De forma automática se deberá, tras el
registro de los pagos, permitir generar
de forma automática la norma CSB34
Requerido 3
La normativa CSB34 está incluida
dentro de las localizaciones
españolas como formato de pago 3
Desde el programa de pagos automáticos de
SAP se genera de forma automática, entre
otras, la norma CSB34. 3 Genera ficheros según normativa SEPA
REQ-GP-CP-18 Mail aviso de
Pagos
Permitir generar mails automáticos a
proveedores con el detalle de los pagos
realizados
Opcional 3
Existe un proceso estándar que
permite enviar mails a los
proveedores con las notificaciones
de los pagos realizados
3 SAP permite correspondencia. 1 Posibilidad de generar emails de forma manual. Hacerlo
de forma automática requiere un desarrollo
REQ-GP-CP-19
Creación de
anticipos de
proveedores
Permitir generar anticipos y
compensarlos con las correspondientes
facturas.
Requerido 3
Al entrar una factura ya se avisa que
el proveedor tiene anticipos
pendientes de aplicar. Se pueden
asignar los anticipos a facturas para
disminuyendo así el importe de
pago
3 SAP permite tanto los registros de anticipos
como la compensación posterior. 3 Gestión de anticipos de forma estándar en la solución
C Reporting
REQ-GP-CP-20 Consultas on-
line
El sistema deber permitir en todo
momento realizar consultas por pantalla
de la información incluida en el módulo
de Cuentas a Pagar
Requerido 3 Existen pantallas para visualizar
toda la información necesaria 3
SAP cuenta con multitud de informes y
permite desarrollar informes a medida 3
Existe la posibilidad de personalizar la información que
los usuarios ven en pantalla por perfiles o de forma
individual. El usuario puede ser autosuficiente para
mostrar o consultar la info sobre la que tiene permisos de
acceso.
REQ-GP-CP-21
Informes de
Cuentas por
Pagar
El sistema debe ofrecer informes que
permitan obtener información acerca de
las transacciones registradas en el
módulo de Cuentas a Pagar
Requerido 3 Existen informes acerca de todas las
transacciones registradas 3
SAP cuenta con multitud de informes y
permite desarrollar informes a medida 3
Generación de informes a través de herramientas propias
de AX así como integración con Excel, Power BI
REQ-GP-CP-22
Construcción
de reporte por
usuarios
Se requiere que el usuario pueda
realizar consultas sin necesidad de
conocimientos técnicos. Todos los
reportes deben ser exportables
fácilmente a Excel.
Requerido 3
Se pueden generar informes
mediante la herramienta de BI
Transaccional, BI Publisher,… con
asistentes para usuarios
3 SAP permite tanto la generación de queries
como de reports 3 Integración Excel nativa
D Integración
REQ-GP-CP-23
Integración
con
Contabilidad
General
Integración del módulo de Cuentas a
Pagar con el módulo de contabilidad
general de forma que cualquier
operación registrada que requiere de
una contabilización (facturas, anticipos,
abonos, pagos, etc.) se registre
automáticamente en contabilidad
general.
Requerido 3
Cualquier operación de cuentas a
pagar con reflejo automático genera
apuntes a contabilidad general
3
Toda operación realizada en el módulo de
cuentas a pagar tiene su reflejo en la
contabilidad general.
3 Todos los módulos están integrados y forman parte de un
todo modular.
REQ-GP-CP-24 Integración
con Proyectos
Posibilidad de imputar a proyectos,
facturas de gastos e inversión y facturas
de subcontratación
Requerido 3
Se pueden imputar gastos contra
proyectos al estar totalmente
integrado 3
Dentro de los documentos SAP se permite
realizar imputaciones. 3
Se permite la imputación de gastos ingresos a proyectos y
dentro de los proyectos al nivel que se requiera (partida,
capitulo, etc.)
REQ-GP-CP-25 Integración
El sistema debe integrarse con el
módulo de compras para poder capturar Requerido 3
Permite el matching de la factura 3 El módulo de compras está integrado. 3 Todos los módulos están integrados y forman parte de un
todo modular. Podemos navegar desde la gestión a la
71
Oracle ERP Cloud SAP S/4 HANA Cloud Microsoft Dynamics AX Cloud
Nº Req. Descripción de
requerimiento Prioridad
Grado de
Cobertura
Descripción
cobertura Grado de
Cobertura Descripción cobertura Grado de
Cobertura Descripción cobertura
con Compras los datos relativos al pedido al que hace
referencia la factura recibida del
proveedor y recuperar información por
defecto del pedido de compra.
contra pedidos y/o recepciones contabilidad y viceversa. Es Dato único
REQ-GP-CP-26
Importación
masiva de
facturas
Permitir la importación de facturas, ya
sea a través de ficheros o Web Services. Requerido 3
Se pueden importar facturas de
ambos modos 3
SAP permite la conectividad a través de
webservice 1
Se requiere un desarrollo para poder importar facturas
mediante plantillas
REQ-GP-CP-27
Generación de
fichero con
información
contable
De forma automática se deberá, tras el
registro de facturas y pagos, generar de
forma automática un fichero con la
información contable de estas
transacciones, para su envío a otro
sistema.
Requerido 3
Se deberá crear un proceso de
extracción de la contabilidad para
ser interfasada a otro G/L. Se puede
utilizar herramientas como el BIP
para realizar este proceso de
extracción
2 SAP permite la integración con otros sistemas
tanto si son SAP como si no lo son. 2
Puede generarse un fichero con la información obtenida
de AX, pero no de manera automática
REQ-GP-CP-28
Generación de
fichero con
información
fiscal
De forma automática se deberá, tras el
registro de facturas y pagos, generar de
forma automática un fichero con la
información contable de estas
transacciones, para su envío a otro
sistema.
Requerido 3
Se deberá crear un proceso de
extracción de la contabilidad para
ser interfasada a otro G/L. Se puede
utilizar herramientas como el BIP
para realizar este proceso de
extracción
3
SAP permite la generación de ficheros con
información fiscal cubriendo las necesidades
de los modelos oficiales.
2
Se requiere el número y el análisis de los ficheros. Puede
generarse un fichero con la información obtenida de AX,
pero no de manera automática
REQ-GP-CP-29
Extracción de
información y
envío a otros
sistemas
Permitir extraer información del
módulo de Cuentas a Pagar, en
ficheros, para poder remitirlos a los
sistemas externos en caso se requiere
alguna integración
Requerido 3
Con las herramientas entregadas se
permite extraer información y
volcarla a otros sistemas. También
existen procesos estándar vía fichero
o web services
3 SAP permite la integración con otros sistemas
tanto si son SAP como si no lo son. SAP PI 3
Capacidad de extracción y generación de ficheros
estándar, Excel, XML, ASCII, etc.
REQ-GP-CP-30
Generación y
envío de
ficheros de
pagos
Permitir la generación y el envío a otro
sistemas del fichero de la Norma 34 o
SEPA con la información de los pagos
de facturas realizados.
Requerido 3
La normativa CSB34 está incluida
dentro de las localizaciones
españolas como formato de pago 3
Desde el programa de pagos automáticos de
SAP se genera de forma automática, entre
otras, la norma CSB34. 3 Genera ficheros según normativa SEPA
72
iii. Cuentas por Cobrar
Oracle ERP Cloud SAP S/4 HANA Cloud Microsoft Dynamics AX Cloud
Nº Req. Descripción de
requerimiento Prioridad
Grado de
Cobertura
Descripción
cobertura Grado de
Cobertura Descripción cobertura Grado de
Cobertura Descripción cobertura
A Maestros
REQ-GP-CC-1 Maestro de
clientes
Permitir dar de alta clientes y
mantenerlos en un maestro de clientes y
deudores.
Requerido 3 Existe un maestro de clientes y el
mantenimiento del mismo 3
Desde SAP se permite mantener de forma
individualizada el maestro de los terceros 3 Maestro de clientes configurable
REQ-GP-CC-2 Atributos de
clientes
Permitir almacenar datos obligatorios y
opcionales de clientes y deudores. Requerido 3
Existen datos obligatorios y otros
opcionales. También se pueden
crear campos adicionales de
información obligatorios u
opcionales
3
Dentro de los datos maestros de terceros se
puede especificar qué información es
obligatoria y cual es opcional 3 Permite definir campos obligatorios o no
REQ-GP-CC-3 Direcciones
de clientes
Permitir que cada cliente pueda contar
con información diferenciada en
función de las direcciones o
ubicaciones de los mismos (direcciones
de entrega, facturación, cobro,..)
Opcional 3 Existe información independiente en
función de cuentas y/o sites 3 SAP permite registrar diferentes direcciones 3
Gestión de direcciones por clientes y proveedores
(direcciones, envió, facturación, etc.
REQ-GP-CC-4 Formas de
cobro
Permitir registrar en el maestro de
clientes y deudores la forma de cobro
acordada y poder obtener el formato
electrónico correspondiente para su
envío al Banco.
Requerido 3 La forma de cobro queda reflejada
en el maestro 3
SAP permite reflejar la forma de cobro para
cada uno de sus clientes/deudores 3 Funcionalidad estándar
REQ-GP-CC-5 Condiciones
de cobro
Permitir la definición de las
condiciones de cobro y su posterior
asignación a los clientes.
Requerido 3
Se crean las condiciones de cobro
que luego son asignadas al maestro
y posteriormente trasladadas por
defecto a las facturas
3
SAP permite parametrizar diferentes
condiciones de cobro y asignarlas en los datos
maestros de los terceros 3 Gestión de cobros con definición de modelos por de cobro
REQ-GP-CC-6
Cuentas
bancarias de
clientes
Permitir la creación y asignación de
cuentas bancarias de clientes de forma
centralizada en la aplicación con todos
sus datos (datos de control como el
código SWIFT, grupo bancario,
dirección, etc.).
Requerido 3
Se pueden crear los datos bancarios
de clientes a nivel de cliente, cuenta
o site. Para pagos internacionales
también se especifica el IBAN
3 SAP permite registrar las cuentas bancarias en
el maestro de los terceros 3
En el maestro de clientes se define la info del cliente y
existe un formulario para el alta de cuentas bancarias de
proveedor
REQ-GP-CC-7
Numeración
de
documentos
Disponer de numeración diferente para
cada tipo de documento (facturas, notas
de abono), por sociedad y año.
Requerido 3
Se pueden definir secuencias de
numeración diferentes por
categorías y sociedades y año
3 SAP permite que cada clase de documento
tenga un rango de números específico. 2
El reinicio de la secuencia entre dos años se hace de forma
manual
REQ-GP-CC-8 Tipos de
documentos
Se debe poder definir distintos tipos de
documentos. Requerido 3
Se pueden definir diferentes tipos
de documento 3
SAP permite definir diferentes tipos de
documentos 3 Facturas, albaranes, notas, comunicaciones, etc.
B Operaciones
REQ-GP-CC-9
Registro
manual de
facturas y nota
de abono
Permitir el registro manual de facturas
y notas de abono a un cliente Requerido 3
Se pueden registrar manualmente
facturas, abonos, abonos según
facturas… 3
SAP permite el registro manual de las
operaciones con los clientes 3 Funcionalidad estándar
73
Oracle ERP Cloud SAP S/4 HANA Cloud Microsoft Dynamics AX Cloud
Nº Req. Descripción de
requerimiento Prioridad
Grado de
Cobertura
Descripción
cobertura Grado de
Cobertura Descripción cobertura Grado de
Cobertura Descripción cobertura
REQ-GP-CC-10
Datos
automáticos
en factura
Permitir que a la hora de registrar una
factura se hereden datos del maestro de
clientes, susceptibles de ser
modificados.
Requerido 3
Al registrar las facturas se heredan
los datos del maestro, luego pueden
ser cambiados 3
Cuando se registran documentos, SAP propone
datos (condiciones de pago, modos de pago…)
heredados del dato maestro, siendo estos
susceptibles de cambio.
3
Esta es la funcionalidad de AX genérica. Recibe los
valores por defecto pero se pueden cambiar para un
registro o documento en concreto.
REQ-GP-CC-11
Registro
automático de
facturas desde
proyectos
Permitir la creación automática de
facturas desde proyectos, con la
posibilidad de facturar un mismo
proyecto a 2 clientes
Requerido 3
Los contratos se asocian a tareas de
proyectos, por lo que podríamos
facturar en un mismo proyecto a
más de un cliente
1 Esta funcionalidad se desarrollaría sobre PS. 3
Todas las imputaciones registradas en los proyectos, se
pueden facturar automáticamente, ya que son registros
pendientes de propuesta de factura. Primero se crea la
propuesta de factura automática y luego se crea el registro
de las propuestas de factura que genera la factura. A cada
proyecto se le puede asignar un contrato vigente, al cual se
le puede asignar más de una fuente de financiación. En la
fuente de financiación se puede informar más de un
cliente a facturar. La repartición se hace por % y se puede
definir por periodos de fechas.
REQ-GP-CC-12 Contabilizació
n de Facturas
Contabilización automática de la
facturación emitida Requerido 3
La contabilización de la factura
puede ser automática 3
La facturación emitida en el módulo de SD
tiene su reflejo en la contabilidad general 3 Funcionalidad estándar
REQ-GP-CC-13 Impresión de
facturas
El sistema debe permitir la impresión
de facturas de forma automática. Requerido 3
Las facturas pueden ser impresas
automáticamente e incluso ser
enviadas al correo electrónico del
cliente
3 Desde el módulo de SD se permite la
impresión del formulario factura 3
Se puede lanzar la impresión automática de facturas en
cualquier momento
REQ-GP-CC-14 Seguimiento
de cobros
El sistema debe permitir consultar el
estado de la deuda por cliente con el
detalle de las facturas vivas pendientes
de cobrar.
Requerido 3
Se puede consultar el detalle de las
facturas y documentos que
constituyen la deuda del cliente
3
SAP permite consultar el estado deuda de los
clientes y conocer cual está vencida (cuento
tiempo) y cual aún no ha vencido.
3 Se puede consultar en cualquier momento el saldo de un
cliente y con drill dow acceder al detalle
REQ-GP-CC-15 Registro de
anticipos Permitir registrar anticipos de clientes. Requerido 3 Se pueden registrar anticipos 3 SAP permite el registro de anticipos. 3 Gestión de anticipos
REQ-GP-CC-16
Registro de
cobros
manuales
Permitir registrar cobros de forma
manual y aplicarlos a facturas Requerido 3
Los cobros pueden ser registrados
manualmente contra facturas 3
SAP permite el registro y aplicación de cobros
manuales 3
Gestión de cobros, estos además pueden ser totales o
parciales
REQ-GP-CC-17
Registro de
Remesas de
cobro y
Generación
del fichero de
la Norma 19
Permitir generar remesas de cobro, y
generar el fichero de la Norma 19 con
la información de los recibos
domiciliados.
Requerido 2
Permite la generación de remesas de
cobro. La remesa de cobros
(domiciliación) podrá gestionarse de
manera estándar con el formato
CSB19 que proporciona la solución.
2
SAP permite la generación de remesas de
cobros a través del programa de cobros
automáticos y generar los formatos
electrónicos requeridos.
2 La funcionalidad estándar permite la generación de
ficheros SEPA
REQ-GP-CC-18 Registro de
ajustes
Permitir registrar ajustes en facturas y
ajustes en cobros para cancelar
importes pendientes de cobrar y
diferencias en cobros aplicados.
Opcional 3 Permite registrar ajustes en cobros 3 SAP permite el registro de ajustes en
documentos nuevos. 3 Gestión de ajustes y de reglas de tolerancias
C Reporting
REQ-GP-CP-19 Consultas on-
line
El sistema deber permitir en todo
momento realizar consultas por pantalla
de la información incluida en el módulo
Requerido 3 Existen pantallas para visualizar
toda la información necesaria 3
SAP cuenta con multitud de informes y
permite desarrollar informes a medida 3
Existe la posibilidad de personalizar la información que
los usuarios ven en pantalla por perfiles o de forma
individual. El usuario puede ser autosuficiente para
74
Oracle ERP Cloud SAP S/4 HANA Cloud Microsoft Dynamics AX Cloud
Nº Req. Descripción de
requerimiento Prioridad
Grado de
Cobertura
Descripción
cobertura Grado de
Cobertura Descripción cobertura Grado de
Cobertura Descripción cobertura
de Cuentas a Cobrar mostrar o consultar la info sobre la que tiene permisos de
acceso.
REQ-GP-CP-20
Informes de
Cuentas a
Cobrar
El sistema debe ofrecer informes que
permitan obtener información acerca de
las transacciones registradas en el
módulo de Cuentas a Cobrar
Requerido 3 Existen informes acerca de todas las
transacciones entradas 3
SAP cuenta con multitud de informes y
permite desarrollar informes a medida 3
Generación de informes a través de herramientas propias
de AX así como integración con Excel, Power BI
REQ-GP-CP-21
Construcción
de reporte por
usuarios
Se requiere que el usuario pueda
realizar consultas sin necesidad de
conocimientos técnicos. Todos los
reportes deben ser exportables
fácilmente a Excel.
Requerido 3
Se pueden generar informes
mediante la herramienta de BI
Transaccional, BI Publisher,… con
asistentes para usuarios
3 SAP permite tanto la generación de queries
como de reports painter 3
Existe la posibilidad de personalizar la información que
los usuarios ven en pantalla por perfiles o de forma
individual. El usuario puede ser autosuficiente para
mostrar o consultar la info sobre la que tiene permisos de
acceso.
D Integración
REQ-GP-CC-22
Integración
con
Contabilidad
General
Integración del módulo de Cuentas a
Cobrar con el módulo de contabilidad
general de forma que cualquier
operación registrada que requiere de
una contabilización (facturas, abonos,
cobros, ajustes, etc.) se registre
automáticamente en contabilidad
general.
Requerido 3
Cualquier operación de cuentas a
cobrar con reflejo automático genera
apuntes a contabilidad general 3
Toda operación realizada en el módulo de
cuentas a cobrar tiene su reflejo en la
contabilidad general. 3
Todos los módulos están integrados y forman parte de un
todo modular.
REQ-GP-CC-23 Integración
con Proyectos
Integración de la facturación asociada a
cada elemento del proyecto. Control de
la facturación de proyectos mediante
hitos de facturación.
Requerido 3
La integración de la facturación de
proyectos es total. La facturación se
genera desde el módulo de
proyectos
3 Los diferentes módulos de SAP están
integrados. 3
Todos los módulos están integrados y forman parte de un
todo modular.
REQ-GP-CC-24
Extracción de
información y
envío a otros
sistemas
Permitir extraer información contable
del módulo de Cuentas a Cobrar, en
ficheros, para poder remitirlos a los
sistemas externos.
Requerido 3
Con las herramientas entregadas se
permite extraer información y
volcarla a otros sistemas. También
existen procesos estándar vía fichero
o web services
3 SAP permite la integración con otros sistemas
tanto si son SAP como si no lo son. SAP PI 3
Capacidad de extracción y generación de ficheros
estándar, Excel, XML, ASCII, etc.
REQ-GP-CC-25
Envío del
fichero con la
información
de recibos
domiciliados a
sistemas
externos
Permitir enviar a sistemas externos, el
fichero de la Norma 19 con la
información de los recibos
domiciliados
Requerido 3
La normativa CSB19 está incluida
dentro de las localizaciones
españolas como formato de pago.
Con las herramientas entregadas se
permite extraer información y
volcarla a otros sistemas. También
existen procesos estándar vía fichero
o web services
3
Desde el programa de pagos automáticos de
SAP se genera de forma automática, entre
otras, la norma CSB19.
SAP permite la integración con otros sistemas
tanto si son SAP como si no lo son.
3
Genera ficheros según normativa SEPA.
Capacidad de generación y envío a sistemas externos, de
ficheros estándar, Excel, XML, ASCII, etc.
75
iv. Activos Fijos
Oracle ERP Cloud SAP S/4 HANA Cloud Microsoft Dynamics AX Cloud
Nº Req. Descripción de
requerimiento Prioridad
Grado de
Cobertura
Descripción
cobertura Grado de
Cobertura Descripción cobertura Grado de
Cobertura Descripción cobertura
A Maestros
REQ-GP-AF-1 Maestro de
activos
Permitir dar de alta activos de forma
manual o a través de una factura de
proveedor, en un maestro de activos,
mediante fichas de activos,
clasificándolos, ubicándolos y
permitiendo informar de todas sus
características tanto económicas como
técnicas.
Requerido 3 Los activos se asocian a las facturas
de los proveedores 3
Los Activos se registran en fichas
independientes 3
Maestro de activos fijos y capacidad de al recepcionar una
factura o hacer un pedido de compra ya indicar que se
trata de un activo
REQ-GP-AF-2
Creación de
activos desde
factura
Permitir el alta automática de activos
desde una factura de proveedor Requerido 3
Se puede pasar el programa de
creación masiva de activos que
creará fichas según facturas
pendientes
0
Para poder registrar una factura contra un
activo es necesario que el Dato Maestro esté
dado de alta
3 Se indica al recibir la factura y de forma automática se
genera el activo fijo
REQ-GP-AF-3 Asignación de
Matrícula
Permitir asignar un código único a cada
activo ('Matrícula'). Requerido 3
El activo se puede identificar con un
código único. También con un
número de serie o una etiqueta 3
Cada uno de los Activos Fijos contará con un
código único 3
Existe la posibilidad de asignar tanto un número de
identificación como gestionar nº de series
REQ-GP-AF-4 Atributos de
los activos
Disponer además de las características
propias de cualquier activo de otros
campos o elementos como la rúbrica y
en función de la rúbrica se asigna el
plan de amortización, periodo, etc.
Requerido 3
En función de la categoría contable
o rúbrica, se crean automáticamente
los planes de amortización
3 Cada Activo fijo cuenta con información
propia. 3
Funcionalidad de modelos de valor donde se define toda
esta información necesaria para un Activo Fijo (Fecha de
inicio de amortización, vida útil, periodos pendientes de
amortizar…)
B Operaciones
REQ-GP-AF-5
Generación
automática de
apuntes
contables
Permitir la generación automática de
apuntes contables a partir de
movimientos de activo (altas, traspasos,
bajas totales, bajas parciales,
enajenaciones, amortizaciones,…).
También se debe considerar
operaciones en que dos o más activos
se refunden en uno sólo, o a la inversa,
cuando a partir de un activo, se separa
en componentes que se quieren activar
por separado.
Requerido 3
Todas las transacciones de activos
que impliquen apuntes contables
generan automáticamente
contabilidad
3
Todo movimiento realizado en un Activo Fijo
tiene su reflejo de forma automática en la
contabilidad general 3 Gestión de activos estándar de AX
REQ-GP-AF-6 Planes de
amortización
Permitir la asignación de planes de
amortización según las
categorías/rúbricas del libro fiscal.
Requerido 3
Según las características/rúbricas se
asignan automáticamente los planes
de amortización
3 SAP permite diferentes planes de amortización 3 Se pueden gestionar distintos tipos de amortización que se
pueden asignar en la activación por categorías de activo
REQ-GP-AF-7 Planes de vida
útil
Permitir la asignación de planes de vida
útil según las categorías/rúbricas del
libro fiscal.
Requerido 3
Según las características/rúbricas se
asignan automáticamente los planes
de vida
3 SAP permite la asignación de planes de vida
según las características del activo 3
Se pueden gestionar distintos tipos de amortización que se
pueden asignar en la activación por categorías de activo
REQ-GP-AF-8 Contabilizació
n automática
de la
La amortización debe poder
contabilizarse de forma automática al
final del periodo, en base a los
parámetros definidos y una
Requerido 3 Se genera según un proceso mensual 3 SAP cuenta con un programa de ejecución de
la amortización 3 Funcionalidad estándar
76
Oracle ERP Cloud SAP S/4 HANA Cloud Microsoft Dynamics AX Cloud
Nº Req. Descripción de
requerimiento Prioridad
Grado de
Cobertura
Descripción
cobertura Grado de
Cobertura Descripción cobertura Grado de
Cobertura Descripción cobertura
amortización planificación inicial establecida.
REQ-GP-AF-9 Criterios de
amortización
Disponer de distintos métodos de
amortización (lineal, decreciente, según
un plan específico,..)
Requerido 3
Existen fórmulas de amortización
estándar, también se pueden crear
algunas específicas 3
SAP permite parametrizar diferentes métodos
de amortización 3
Dispone de los principales modelos de amortización
además de poder definir modelos particulares
REQ-GP-AF-10 Vida útil
Disponer de información sobre la vida
útil de cada activo y poder cambiar esta
en función de las necesidades de la
organización
Requerido 3 Se pueden realizar cambios en la
vida útil, método de amortización 3
En cada una de las fichas de los Activos Fijos
está reflejada la vida útil del activo 3 Configurable
REQ-GP-AF-11
Facturación de
activos en
libros de IVA
Permitir la inclusión de las facturas de
activos en los libros de IVA con una
secuencia diferenciada
Requerido 3
Se puede tener códigos de
impuestos específicos para bienes de
inversión 3
SAP permite diferencia las operaciones por
clases de documentos 3
Permite la distinción del IVA en función de categoría de
Bienes, servicios y bienes de inversión
REQ-GP-AF-12 Movimientos
de activos
Permitir mover activos de un centro a
otro. Esta asignación de nuevos activos
genera contabilidad de traspaso de un
centro a otro. Dichos traspasos
generarán apuntes analíticos en la
contabilidad.
Requerido 2 Necesita desarrollo para guardar el
histórico a la nueva cuenta. 1
Necesita desarrollo de mayor complejidad para
guardar el histórico a la nueva cuenta. 2
Necesita desarrollo para guardar el histórico a la nueva
cuenta.
REQ-GP-AF-13
Capitalización
de activos
'obra en curso'
Permitir amortizar una vez que el activo
esté finalizado y flexibilidad en la
asignación a rúbricas/categorías.
Requerido 3
Los activos marcados como de obra
en curso no se pueden amortizar
hasta que se contabilizan
3
SAP permite la generación de activos fijos en
curso y realizar su liquidación a uno o n activos
fijos finales
3 Funcionalidad estándar
REQ-GP-AF-14
Facturas de
arrendamiento
de inmuebles.
Permitir la emisión de las facturas de
rentas a cobrar de todos los inmuebles
(propiedad del banco o propiedad de
sociedades vehículo).
Requerido 2
El sistema permite el registro
manual de las facturas de
arrendamiento de inmuebles o la
integración con un sistema externo
de gestión de inmuebles que genere
los datos a facturar. En el roadmap
de la solución se contempla la
gestión de arrendamientos y leasing
de equipos en activos fijos. No
obstante, esta misma funcionalidad
podría utilizarse para gestionar los
requerimientos contables del
arrendamiento de inmuebles (no los
requerimientos operativos).
2
No está incluida la emisión de facturas desde el
módulo de Activos Fijos, siendo necesario su
creación en el módulo de Cuentas por Cobrar
3
Facturación periódica o facturación por proyecto. Por
proyecto tendría la ventaja de considerar el inmueble y los
gastos asociados
C Reporting
REQ-GP-AF-15
Informe de
variaciones en
valoraciones
de activos
Permitir obtener un informe con las
variaciones por rúbrica, para identificar
variaciones en el presupuesto.
Requerido 3 Se puede obtener un informe con
todas las variaciones por rúbrica 3
SAP permite mostrar las variaciones
registradas en los activos. 2 Se necesita un desarrollo sencillo
REQ-GP-AF-16 Consultas on-
line
El sistema deber permitir en todo
momento realizar consultas por pantalla
de la información incluida en el módulo
de Activos Fijos
Requerido 3 Existen pantallas para visualizar
toda la información necesaria 3
SAP cuenta con multitud de informes y
permite desarrollar informes a medida 3
Existe la posibilidad de personalizar la información que
los usuarios ven en pantalla por perfiles o de forma
individual. El usuario puede ser autosuficiente para
mostrar o consultar la info sobre la que tiene permisos de
acceso.
77
Oracle ERP Cloud SAP S/4 HANA Cloud Microsoft Dynamics AX Cloud
Nº Req. Descripción de
requerimiento Prioridad
Grado de
Cobertura
Descripción
cobertura Grado de
Cobertura Descripción cobertura Grado de
Cobertura Descripción cobertura
REQ-GP-AF-17 Informes de
Activos Fijos
El sistema debe ofrecer informes que
permitan obtener información acerca de
las transacciones registradas en el
módulo de Activos Fijos
Requerido 3 Existen informes acerca de todas las
transacciones entradas 3
SAP cuenta con multitud de informes y
permite desarrollar informes a medida 3
Generación de informes a través de herramientas propias
de AX así como integración con Excel, Power BI
REQ-GP-AF-18
Construcción
de reporte por
usuarios
Se requiere que el usuario pueda
realizar consultas sin necesidad de
conocimientos técnicos. Todos los
reportes deben ser exportables
fácilmente a Excel.
Requerido 3
Se pueden generar informes
mediante la herramienta de BI
Transaccional, BI Publisher,… con
asistentes para usuarios
3 SAP permite tanto la generación de queries
como de reports painter 3
Existe la posibilidad de personalizar la información que
los usuarios ven en pantalla por perfiles o de forma
individual. El usuario puede ser autosuficiente para
mostrar o consultar la info sobre la que tiene permisos de
acceso.
D Integración
REQ-GP-AF-19
Integración
con el módulo
de
Contabilidad
General
Integración de la gestión de activos con
la gestión contable de forma que los
apuntes en libro mayor sean
automáticos.
Esta integración debe ser online y sin
necesidad de procesos de integración
específicos.
Requerido 3
La integración con Contabilidad
General permite que se generen
todos los asientos de las operación
de inmovilizado que implique
contabilidad
3
Toda operación realizada en el módulo de
activos fijos tiene su reflejo en la contabilidad
general.
3 Todos los módulos están integrados y forman parte de un
todo modular.
REQ-GP-AF-20
Integración
con el módulo
de Cuentas a
Pagar
Integración de la gestión de activos con
la gestión de proveedores para las
facturas de compra de los bienes
activables.
Esta integración debe ser online y sin
necesidad de procesos de integración
específicos.
Requerido 3 La integración de Activos con
cuentas a pagar es directa 3
La integración con la gestión de proveedores es
online 3
Todos los módulos están integrados y forman parte de un
todo modular.
REQ-GP-AF-21 Integración
con Compras
El sistema debe permitir integrarse con
el módulo de compras para poder
capturar los datos relativos a los
pedidos con diferentes tipologías como
por ejemplo de 'inversión'. Debe ser
parametrizable y esta integración debe
ser online y sin necesidad de procesos
de integración específicos.
Requerido 3
La integración con compras es
directa, es con las facturas
matcheadas con compras de
Cuentas a Pagar
3 La integración del módulo de Activos Fijos
con la gestión de proveedores es online 3
Todos los módulos están integrados y forman parte de un
todo modular.
REQ-GP-AF-22 Integración
con Proyectos
Disponer de funcionalidad que permita
integrar la gestión de activos con la
gestión de proyectos, tanto desde el
punto de vista de la gestión de activos
fijos en curso como de la gestión de
proyectos como elementos comerciales
Requerido 3
La integración con proyectos es
total. Se vincula el proyecto con un
activo y al finalizar un proyecto
permite capitalizar el mismo
3 La integración del módulo de Activos Fijos
con el módulo de compras (MM) es online 3 Existe una tipología especifica de Proyectos de Inversión
REQ-GP-AF-23
Integración
con
herramientas
de gestión de
inmuebles
Disponer de funcionalidad que permita
integrarse con las herramientas de
gestión de inmuebles.
Opcional 1
Se tendría que determinar el grado
de integración con estas
aplicaciones. Se pueden utilizar
servicios web, interfaces de tablas o
extracción de información con BI
Publisher.
1 SAP cuenta la gestión de inmuebles SAP Real
Estate (RE) 1
Se tendría que determinar el grado de integración con
estas aplicaciones.
REQ-GP-AF-24 Integración
para el alta de
Permitir la creación de activos a partir
de una plantilla Excel. Opcional 3
Se permite dar de alta activo desde
hoja Excel 3
Se tendría que realizar un desarrollo sencillo
mejorando la funcionalidad 1
Se requiere un desarrollo para poder crear activos fijos
mediante plantillas
78
Oracle ERP Cloud SAP S/4 HANA Cloud Microsoft Dynamics AX Cloud
Nº Req. Descripción de
requerimiento Prioridad
Grado de
Cobertura
Descripción
cobertura Grado de
Cobertura Descripción cobertura Grado de
Cobertura Descripción cobertura
activos
REQ-GP-AF-25
Extracción de
información
contable y
envío a otros
sistemas
Generar de forma automática la
información contable del módulo de
Activos Fijos, en ficheros, para poder
remitirlos a otros sistemas (módulo de
contabilidad del host).
Requerido 3
Con las herramientas entregadas se
permite extraer información y
volcarla a otros sistemas. También
existen procesos estándar vía fichero
o web services
3 SAP permite la integración con otros sistemas
tanto si son SAP como si no lo son. SAP PI 3
Capacidad de extracción y generación de ficheros
estándar, Excel, XML, ASCII, etc.
v. Gestión de Proyectos
Oracle ERP Cloud SAP S/4 HANA Cloud Microsoft Dynamics AX Cloud
Nº Req. Descripción de
requerimiento Prioridad
Grado de
Cobertura
Descripción
cobertura Grado de
Cobertura Descripción cobertura Grado de
Cobertura Descripción cobertura
A Maestros
REQ-GP-GP-1 Organizacione
s de Proyectos
El sistema debe permitir diferenciar
diferentes entidades propietarias de los
proyectos.
Requerido 3
Se relaciona cada proyecto con la
entidad legal correspondiente,
también se puede asociar a
organizaciones, unidades de
negocio, unidades de proyecto…
3 Dentro de los datos maestros de proyectos se
puede asignar la sociedad a la que pertenece 3
Permite asignar responsables a proyectos con distintos
roles
REQ-GP-GP-2 Creación de
Proyectos
El sistema debe permitir mantener una
base de datos de proyectos o
actividades.
Requerido 3
El módulo de proyectos justamente
es para mantener una base de datos
de proyectos y su control 3
Los proyectos son almacenados en la BBDD
interna de SAP 3
Permite tener una BBDD de proyectos tanto activos como
histórico u ofertas de proyectos
REQ-GP-GP-3 Plantillas de
proyectos
Disponer de plantillas de proyectos que
permitan realizar un primer desglose de
información recurrente por tipología.
Opcional 3 Se pueden crear proyectos desde
plantillas por tipología 3
Existen plantillas de proyectos estándar para
facilitar la creación de proyectos a partir de
estas
3
Existe la posibilidad de crear distintas plantillas de
proyecto así como heredar formato y desglose de otros
proyectos anteriores
REQ-GP-GP-4 Carga de
proyectos
Incorporar herramienta de carga
configurable para la creación de árboles
de proyectos desde sistemas externos.
(PPM)
Requerido 3
Se permite la creación de estructuras
interfasadas desde Microsoft Project
o importarlas a través de tablas de
interface o desde Excel
2
Sería necesario un desarrollo para definir la
carga de proyectos desde cualquier otro
sistema 3
estándar para Microsoft Project pero para otras
herramientas habría que hacer desarrollo de integración
REQ-GP-GP-5
Desglose de
actividades/tar
eas
Los proyectos deberán permitir su
desglose en actividades a múltiples
niveles, permitiendo establecer un árbol
de subactividades.
Requerido 3
Permite crear una estructura de
actividades a los diferentes niveles
que se requiera 3
Dentro de los proyectos se puede definir una
estructura inferior (grafo) que permite obtener
un mayor nivel de detalle de cada una de las
actividades
3 Permite crear proyectos, subproyectos, y luego desgloses
en capítulos, subcapítulo, partidas, etc.
REQ-GP-GP-6
Clasificación
de actividades
a partidas y
rúbricas
Las actividades deberán poder estar
relacionadas con las partidas(desarrollo
evolutivo interno, correctivo externo,
etc…) y rúbricas
Requerido 3 Se pueden definir actividades
específicas relacionadas con partidas 3
Se puede realizar una planificación e
imputación real a nivel de actividad 3
Se puede asociar todo al nivel de desglose con el que se
haya configurado el proyecto
REQ-GP-GP-7 Maestro de
recursos
Permitir la creación y gestión de
recursos dedicados a los proyectos.
Debe permitir registrar el cálculo del
Requerido 3 El sistema permite mantener un pool
de recursos a asignar a proyectos y
la imputación de tiempos a una
3 Disponiendo del módulo de HCM para el
mantenimiento de la estructura organizativa y
el maestro de personal se puede planificar por
3 Permite asociar coste estimado o real mediante
integración con módulo de nominas
79
Oracle ERP Cloud SAP S/4 HANA Cloud Microsoft Dynamics AX Cloud
Nº Req. Descripción de
requerimiento Prioridad
Grado de
Cobertura
Descripción
cobertura Grado de
Cobertura Descripción cobertura Grado de
Cobertura Descripción cobertura
coste hora (tarifa) del empleado. tarifa categoría o empleado quien es el encargado de
cada actividad
REQ-GP-GP-8 Calendarios
Permitir la creación y gestión de
calendarios de trabajo. Permitir asociar
calendarios a los recursos.
Requerido 3
Permite mantener calendarios de
trabajo para cada recurso asignado a
tareas
3 Se cubre con el mantenimiento de calendarios
de SAP 3 múltiples calendarios por proyecto, geografía, etc.
B Operaciones
REQ-GP-GP-9 Asignación de
responsables
Lo proyectos deberán poder estar
asignados a unos responsables que
serán las personas que tengas capacidad
para gestionar los mismos: Establecer
calendarios, asignar presupuestos,
recursos, realizar previsiones, desglosar
en actividades, establecer planificación
e hitos.
Requerido 3 Los proyectos están asignados a
responsables 3
Dentro del maestro de proyectos existe el
campo estándar responsable y se pueden
parametrizar responsables adicionales
3 Diferentes roles de gestión por proyecto
REQ-GP-GP-10 Presupuestaci
ón y previsión
El sistema debe permitir asociar un
presupuesto y previsiones en los
proyectos con la finalidad de realizar el
seguimiento económico y detectar
desviaciones.
Requerido 3
El sistema permite definir
presupuestos, revisiones,
previsiones… y realizar
comparaciones con los reales para
determinar rentabilidades y
desviaciones
3 Existen transacciones estándar para la
introducción del presupuesto 3 Gestión de proyecto y presupuesto
REQ-GP-GP-11 Planificación
de proyectos
Los responsables de los proyectos
podrán definir un calendario de tareas e
hitos para el control del avance del
proyecto.
Requerido 3
Permite definir calendario de tareas
e hitos para planificar y controlar el
avance del proyecto
3 Se permite la asignación de hitos a cada una de
las actividades de los proyectos 3
Planificación por proyecto tanto de recursos, costes e
ingresos
REQ-GP-GP-12 Asignación de
Recursos
El sistema debe contar con
funcionalidad para asignar recursos
(empleados) a las actividades/tareas de
los proyectos, permitiendo tener una
visión de la cargabilidad de los
empleados.
Requerido 3
Se puede definir un pool de
empleados y tener una visión global
de carga de trabajo, asignación de
recursos a proyectos, Skills de
empleados. El responsable del pool
podrá asignar y gestionar los
recursos según peticiones de los
responsables de proyectos
3
Disponiendo del módulo de HCM para el
mantenimiento de la estructura organizativa y
el maestro de personal se puede planificar por
categoría o empleado quien es el encargado de
cada actividad
3 Asignación a proyecto
REQ-GP-GP-13 Gestión de
estados
Permitir la configuración de estados del
proyecto. Estos estados podrán a su vez
estar configurados para delimitar las
operaciones que se podrán ejecutar en
cada uno de ellos.
Requerido 3
El sistema puede tener diferentes
estados, según el estado se permiten
realizar más o menos actividades (ej.
draft, cerrado,…)
3
El sistema proporciona por defecto estados de
sistema y se permite la parametrización de
estados de usuario para cubrir las necesidades
de cada cliente
3
Los estados de los proyectos se gestionan por el concepto
"Etapa del proyecto", pudiendo asignar cinco valores
predefinidos y tres configurables. La secuencia de las
Etapas es configurable, así como las actividades de cada
una.
REQ-GP-GP-14 Mecanismos
de aprobación
Mecanismos de aprobación en
operaciones tales como cambiar de
estados, asignación de presupuesto,
imputación de horas, etc.
Requerido 3
El cambio de estado tiene definido
un workflow de aprobación,
también la aprobación de
presupuestos y forecasts. El registro
de horas también tiene definido un
workflow si la imputación de las
mismas se realiza desde time &
labor
1 Se necesitaría el desarrollo de un workflow
para cubrir los mecanismos de aprobación 3 Posibilidad de establecer workflows de aprobaciones
80
Oracle ERP Cloud SAP S/4 HANA Cloud Microsoft Dynamics AX Cloud
Nº Req. Descripción de
requerimiento Prioridad
Grado de
Cobertura
Descripción
cobertura Grado de
Cobertura Descripción cobertura Grado de
Cobertura Descripción cobertura
REQ-GP-GP-15 Imputación de
horas
Disponer de un formulario que permita
la imputación sencilla de horas a los
proyectos (incluyendo ausencias
planificadas o no planificadas), tanto
para el personal interno como el
externo.
Requerido 3 Existe un formulario simple para la
imputación de tiempos 3
Se imputaran las horas desde el módulo de
CATS de HCM. 3
posibilidad de hacerlo en el sistema o por plantillas tipo
Excel
REQ-GP-GP-16 Carga de
horas
Incorporar herramienta de carga
configurable para la carga de horas
desde sistemas externos los proyectos.
Requerido 3
Se pueden cargar horas imputadas
desde sistemas externos a través de
interfaces o Excel
1
Al provenir de un sistema externo se necesita
un desarrollo que cubra la imputación en el
sistema SAP
2 Se requiere un análisis más detallado de la herramienta de
carga
REQ-GP-GP-17 Imputación de
gastos
Disponer de un formulario para la carga
de imputación de hojas de gastos a los
proyectos, tanto para el personal
interno como el externo.
Requerido 3
Desde la aplicación de gastos se
pueden imputar y cargar notas de
gastos relacionadas con proyectos.
Existe una aplicación específica para
Smartphones
3 Se cubre con el estándar de FI-TM 3 Posibilidad de hacerlo en el sistema o por pantallas tipo
Excel
REQ-GP-GP-18 Reconocimien
to de Ingresos
Funcionalidad que permita el
reconocimiento de ingresos de los
proyectos en base al grado de avance
del mismo.
Requerido 3 Es una funcionalidad estándar 3
Existen transacciones estándar para realizar la
declaración de ingresos en base al avance del
proyecto
3 Funcionalidad estándar
REQ-GP-GP-19 Delegación en
terceros
Herramienta que permita delegar la
responsabilidad de introducir horas y
gastos a terceros.
Requerido 3
Las horas y los gastos se pueden
entrar mediante formularios
específicos o bien entrarlas vía
interface o Excel.
2 Se necesitaría un desarrollo para cubrir la
delegación de la introducción de horas 3
Posibilidad de imputación a proyecto de forma
administrativa
REQ-GP-GP-20
Cierre
periódico de
proyectos
Permitir definir un proceso de cierre
que permita un punto de control
periódico, para actualización de
planificación, forecast, recopilación de
gastos e ingresos,
Requerido 3 Funcionalidad estándar 2 Se deben realizar una serie de tareas para
realizar el cierre mensual. 3
Cierres parciales.
Por un lado se puede automatizar la creación de
propuestas de factura, sobre costes del proyecto. Por otro
lado está la planificación de recursos o de materiales. Este
punto es más complejo y se debería determinar que
conceptos de planificación se requiere controlar. (por éste
último punto, indico que se necesita un pequeño
desarrollo)
REQ-GP-GP-21 Facturación de
proveedor
Herramienta que permita la
automatización de facturas pro-formas
a partir de las horas incurridas por
proveedores externos (Asistencias
técnicas) para confrontar con el
proveedor.
Requerido 3
El sistema permite generar
autofacturas a proveedores pero en
base a información de pedido y
recepción de compras, aunque sea
relacionado con proyectos
2
Implica la generación de un pedido de compras
y un pequeño desarrollo para su
implementación
3
De forma periódica y automática, se pueden generar
Facturas proforma, que en AX se entienden por
"Propuestas de Factura".
Las propuestas de factura se pueden generar por los
diferentes conceptos: Horas, Gastos, Materiales
Facturables o Cuota)
REQ-GP-GP-22 Facturación de
clientes.
Posibilidad de generar facturas a
clientes en función de los gastos
asociados a los proyectos y
agrupándolos por rúbrica.
Requerido 3
El sistema de billing permitirá
generar facturaciones a clientes
según diferentes métodos 3
Implica la generación de un pedido de ventas y
un pequeño desarrollo para su implementación 3 Funcionalidad estándar
C Reporting
REQ-GP-GP-23
Seguimiento y
Control por
proyecto
El sistema deber permitir en todo
momento conocer el detalle de los
gastos asociados a cada uno de los
Requerido 3 El sistema permite imputar y
controlar todos los costes asignados
al proyecto (internos a externos a la
3 Existen diversos informes estándar que cubren
el requisito 3 Funcionalidad estándar
81
Oracle ERP Cloud SAP S/4 HANA Cloud Microsoft Dynamics AX Cloud
Nº Req. Descripción de
requerimiento Prioridad
Grado de
Cobertura
Descripción
cobertura Grado de
Cobertura Descripción cobertura Grado de
Cobertura Descripción cobertura
proyectos. aplicación)
REQ-GP-GP-24
Consulta de
gastos
activables
El sistema debe facilitar el listado de
gastos susceptibles de activar. Requerido 3
El sistema permite controlar los
gastos activables y capitalizar los
mismos cuando se considere
necesario
3 Existen diversos informes estándar que cubren
el requisito 3 Funcionalidad estándar
REQ-GP-GP-25
Comparativa
presupuesto-
real
Proporcionar informes para comparar
Gastos reales frente a Cantidades
presupuestadas para supervisar y
controlar el avance del presupuesto en
los proyectos.
Requerido 3
Por informes y pantallas se pueden
controlar reales y desviaciones tanto
en importes como en cantidades
3 Existen diversos informes estándar que cubren
el requisito 3 Funcionalidad estándar
REQ-GP-GP-26 Rentabilidad
de proyectos
Permitir obtener ratios de rentabilidad
por periodo de cada uno de los
proyectos.
Opcional 3
Existe ratios y cuadros de mandos
específicos para el control de
rentabilidades de proyecto 2
Existen diversos informes estándar que cubren
el requisito 3 Funcionalidad estándar
REQ-GP-GP-27 Imputación de
horas
Posibilidad de obtener informes con la
imputación de horas a los proyectos. Requerido 3
El sistema permite obtener la
información de las horas imputadas
por proyecto en un rango de fechas
determinado
3 Existen diversos informes estándar que cubren
el requisito 3
Permite la obtención de informes con la imputación de
horas a los proyectos.
REQ-GP-GP-27-1 Imputación de
horas
El sistema debería alertar de la ausencia
en la imputación de algún recurso. Requerido 3
El sistema da alertas ante la falta de
imputación de horas de algún
recurso
1 Se requiere de un desarrollo para lanzar un
alerta de la falta de imputación de horas 1
El sistema no envía alertas automáticas con las ausencias
de la imputación. Se necesita un desarrollo
REQ-GP-GP-28 Avance de
planificación
Poder extraer el avance en la ejecución
de las tareas de cada uno de los
proyectos.
Requerido 3
Existen cuadros de mando que
permiten controlar el avance de cada
proyecto. 3
Existen diversos informes estándar que cubren
el requisito 3 Existen informes para visualizar el avance en tareas.
REQ-GP-GP-28-1 Avance de
planificación
El sistema debería alertar de
incumplimientos de planificaciones de
los hitos.
Requerido 3
Existen la posibilidad de lanzar
avisos ante el incumplimiento de
planificaciones 1 Se necesita un desarrollo 1
El sistema no envía alertas automáticas por
incumplimientos en la planificación. Se necesita un
desarrollo
D Integración
REQ-GP-GP-29
Integración
con
Contabilidad
General
Los eventos relacionados con las
operaciones de proyectos se verán
reflejados en el módulo de contabilidad
general.
Requerido 3
La integración con Contabilidad
General permite que se generen
todos los asientos de los eventos de
proyectos que implique contabilidad
3 SAP es un sistema plenamente integrado 3
Todos los módulos están integrados y forman parte de un
todo modular. Podemos navegar desde la gestión a la
contabilidad y viceversa. Es Dato único
REQ-GP-GP-30
Integración
con cuentas a
pagar
Deber existir una conexión directa con
el módulo de cuentas a pagar para
poder asociar e imputar facturas a los
proyectos.
Requerido 3 Desde cuentas a pagar ya se asignan
las facturas a los proyectos 3 SAP es un sistema plenamente integrado 3
Todos los módulos están integrados y forman parte de un
todo modular. Podemos navegar desde la gestión a la
contabilidad y viceversa. Es Dato único
REQ-GP-GP-31
Integración
con cuentas a
cobrar
Debe permitir la conexión para emitir la
facturación a clientes desde los
proyectos.
Requerido 3
Desde proyectos ya se permite la
facturación de los proyectos según
diferentes métodos
3 SAP es un sistema plenamente integrado 3
Permite la emisión de facturas desde el proyecto
quedando está asociada al proyecto para el computo de
gastos ingresos así como desde el módulo de facturación
emitir una factura y de forma manual asociarla a un
proyecto y dentro de este a una partida, capitulo, etc.
82
Oracle ERP Cloud SAP S/4 HANA Cloud Microsoft Dynamics AX Cloud
Nº Req. Descripción de
requerimiento Prioridad
Grado de
Cobertura
Descripción
cobertura Grado de
Cobertura Descripción cobertura Grado de
Cobertura Descripción cobertura
REQ-GP-GP-32
Extracción e
importación
de datos
Que el ERP tenga la facilidad para la
extracción e importación de
información de forma sencilla.
Requerido 3
Con las herramientas entregadas se
permite extraer información y
volcarla a otros sistemas. También
existen procesos estándar vía fichero
o web services. También existen
procesos de importación vía
ficheros, servicios web y plantillas
Excel
3 SAP es un sistema plenamente integrado 3 Capacidad de extracción y generación de ficheros
estándar, Excel, XML, ASCII, etc.
vi. Presupuestación
Oracle ERP Cloud SAP S/4 HANA Cloud Microsoft Dynamics AX Cloud
Nº Req. Descripción de
requerimiento Prioridad
Grado de
Cobertura
Descripción
cobertura Grado de
Cobertura Descripción cobertura Grado de
Cobertura Descripción cobertura
A Maestros
REQ-GP-PR-1 Centros de
coste
El sistema debe permitir crear y
gestionar los centros de coste, para
reflejar entre otras cosas la estructura
organizativa de la compañía.
Requerido 3
En la estructura organizativa se
definen los segmentos analíticos
necesarios, entre ellos puede ser el
centro de coste
3
Existen transacciones estándar para la creación
y mantenimiento de los centros de coste en
SAP 3
AX permite la creación de una estructura organizativa de
los centros de costes, así como el uso de dimensiones
analíticas ilimitadas
REQ-GP-PR-2 Centros
presupuestario
El sistema debe permitir crear y
gestionar los centros supervisores de
presupuesto.
Requerido 3 Se pueden definir centros
presupuestarios 3 Se pueden crear centros presupuestarios 3
Existen workflows configurables para la validación y
control de los presupuestos
REQ-GP-PR-3 Plantillas de
presupuesto
El sistema debe permitir definir las
estructuras de presupuestación o
plantillas para recoger el presupuesto de
las distintas compañías y centros
presupuestarios.
Requerido 3
Se pueden definir estructuras para la
presupuestación al nivel jerárquico y
con las combinaciones de
segmentos requeridos
2 Se necesita de un desarrollo para cubrir la
necesidad de disponer de plantillas 3
Mediante el add in de Excel permite la integración desde
Excel de partidas presupuestarias
REQ-GP-PR-4
Variables de
presupuestació
n
Presupuestación por unidad operativa,
naturaleza contable (rúbrica) y partida. Requerido 3
Se pueden definir presupuestos a
este nivel 3
Se puede realizar la presupuestación por esos
conceptos a partir de transacciones estándar 3
La introducción de presupuestos se realiza a nivel
contable, con cuenta contable y dimensión
REQ-GP-PR-5
Autorizacione
s por usuario /
rol
Definir perfiles y roles en función de
los distintos objetos de coste y
dimensiones analíticas
Requerido 3
Se pueden definir seguridades a los
niveles requeridos por perfil de
usuario y roles funcionales según
perfiles
3
SAP dispone de una gestión de roles y perfiles
que cubre las necesidades de cada cliente
plenamente parametrizable 3
Permite la configuración de roles con distintos niveles de
acceso
REQ-GP-PR-6 Campos
descriptivos
El sistema debe permitir añadir campos
adicionales en la pantalla de gestión de
presupuestos
Requerido 3 Se pueden añadir campos
adicionales 2
La pantalla de introducción de presupuestos no
cubre este requisito pero se puede realizar un
pequeño desarrollo para su implementación
3 Existen campos estándar de descripción en el formulario
de introducción de partidas presupuestarias
B Operaciones
REQ-GP-PR-7 Presupuestos Creación y gestión integrada en el
Requerido 3 Funcionalidad estándar del módulo
2 El sistema SAP permite la creación y gestión
3 Funcionalidad estándar del módulo de Presupuestación
83
Oracle ERP Cloud SAP S/4 HANA Cloud Microsoft Dynamics AX Cloud
Nº Req. Descripción de
requerimiento Prioridad
Grado de
Cobertura
Descripción
cobertura Grado de
Cobertura Descripción cobertura Grado de
Cobertura Descripción cobertura
y planificación sistema, del presupuesto y de su
planificación
de Presupuestación del planificado y presupuesto de manera
estándar
REQ-GP-PR-9 Registro de
presupuesto
Permitir el registro anual del
presupuesto en base a rúbricas y
partidas. Posibilidad de diferenciar
entre partidas recurrentes y no
recurrentes, así como la posibilidad de
registrar otra información de interés.
El registro de un nuevo presupuesto
debe tener en cuenta partidas en curso,
no ejecutadas, o gastos recurrentes de
otros ejercicios.
Requerido 3
Se puede presupuestar combinando
rúbricas y partidas. También
utilizando otros segmentos de la
estructura analítica. Las partidas se
pueden clasificar como recurrentes o
no
2
Se permite la definición del presupuesto en
SAP. Se puede necesitar algún desarrollo en
función de los requisitos
2
El registro de presupuestos contables se hace para cada
combinación de cuenta contable y dimensión analítica,
pero no se diferencian las partidas recurrentes y no
recurrentes
REQ-GP-PR-10
Registro
descentralizad
o
Funcionalidad de registro
descentralizado, con una consolidación
y aprobación centralizada
Opcional 3
La funcionalidad de creación y
elaboración de presupuestos
descentralizada está incluida en la
herramienta de planificación de
Oracle
2 Se necesita un flujo de workflow para la
aprobación 2
El formulario de entrada de registros presupuestario es
único para registrarlo mediante plantilla Excel
REQ-GP-PR-11 Control
presupuestario
Permitir definir controles para que no
se puedan superar el presupuesto
asignado a cada rúbrica y partida
Requerido 3
Existen controles a nivel de cada
transacción para validar que se
cumpla el control presupuestario 1
El requisito es cubierto con la herramienta de
presupuestación estándar de SAP. Necesita
integración entre las diferentes herramientas
(Ariba, SAP S/4, etc.)
3
Incluye funcionalidad estándar de control presupuestario,
que impide superar las partidas presupuestarias
seleccionadas, permitiendo establecer distintos niveles de
exceso presupuestario para distintos niveles de usuarios
REQ-GP-PR-12 Fases del
presupuesto
Permitir almacenar en la aplicación las
diferentes fases para la preparación del
presupuesto hasta llegar a su versión
definitiva
Requerido 3
La herramienta de planificación y
presupuestación de Oracle permite
la gestión de varias versiones de
presupuestos hasta llegar a su
versión final.
2
Se pueden almacenar diferentes versiones de
presupuesto o planificado. Se puede necesitar
algún desarrollo adicional 3 Existen distintos estados para cada presupuesto
REQ-GP-PR-13
Mecanismos
de aprobación
de
presupuesto
Disponer de flujos de trabajo
configurables para soportar el proceso
de aprobación del presupuesto
Opcional 3
La funcionalidad de creación y
elaboración de presupuestos y sus
aprobaciones está incluida en la
herramienta de planificación de
Oracle
1 Se necesitaría un flujo de aprobación de
workflow 3
Existen workflows configurables para la validación y
control de los presupuestos
REQ-GP-PR-14 Versión
provisional
Posibilidad de operar con versiones
provisionales de presupuestos hasta
tener la versión definitiva que sustituirá
a todas las demás versiones anteriores
Requerido 3
La funcionalidad de creación y
elaboración de presupuestos con
versionados y aprobaciones está
incluida en la herramienta de
planificación de Oracle
3
Se permite la gestión de distintas versiones
hasta llegar a una definitiva que se podrá copiar
a partir de otra 1
AX permite crear varias versiones de presupuestos, pero
habría que hacer un desarrollo para que las aprobaciones
se vayan añadiendo a un mismo proyecto.
REQ-GP-PR-15
Seguimiento
del
presupuesto
Disponer de funcionalidad para realizar
el seguimiento periódico del
presupuesto a nivel de partida y
registrar modificaciones del mismo de
acuerdo a los datos reales.
Requerido 3
Desde el control presupuestario se
realiza un seguimiento directo del
presupuesto vs los reales,
comprometidos y obligados. Este
control puede ser solamente de
seguimiento o también de
impedimento de entrada de
transacciones
3 Está cubierto con la funcionalidad estándar de
gestión de presupuestos de SAP 3
Existe la posibilidad de introducir partidas adicionales o
revisiones presupuestarias identificando estas revisiones
REQ-GP-PR-16 Estados del
presupuesto
Permitir visualizar y almacenar los
distintos status por los que pasa la
elaboración del presupuesto, por quién
Requerido 3 La funcionalidad de creación y
elaboración de presupuestos con
versionados, estados y aprobaciones
1 Será necesario un desarrollo ya que se necesita
del mismo para la gestión de workflow 3 Los workflows relacionados en el módulo de gestión
presupuestaria, incluyen la información necesaria respecto
84
Oracle ERP Cloud SAP S/4 HANA Cloud Microsoft Dynamics AX Cloud
Nº Req. Descripción de
requerimiento Prioridad
Grado de
Cobertura
Descripción
cobertura Grado de
Cobertura Descripción cobertura Grado de
Cobertura Descripción cobertura
es aprobado, etc… (Elaboración,
Pendiente Aprobación, Denegado,
Aprobado, etc.)
está incluida en la herramienta de
planificación de Oracle
al estado de aprobación del presupuesto
REQ-GP-PR-17 Versiones de
presupuesto
Permitir la opción de crear y ver
diferentes versiones de presupuestos
para ayudar a elaborar un presupuesto
preliminar y presupuestos revisados y
aprobados de las versiones posteriores.
Requerido 3
La funcionalidad de creación y
elaboración de presupuestos con
versionados, estados y aprobaciones
está incluida en la herramienta de
planificación de Oracle
3
Se permite la gestión de distintas versiones
hasta llegar a una definitiva que se podrá copiar
a partir de otra
3 Funcionalidad estándar
REQ-GP-PR-18 Cargas de
presupuesto
Disponer de herramientas para carga de
presupuestos desde hoja de cálculo. Requerido 3
Se permiten cargar presupuestos
desde hojas de cálculo 1
Se necesitará un desarrollo para la carga desde
Excel 3
Mediante el add in de Excel permite la integración desde
Excel de partidas presupuestarias
REQ-GP-PR-19
Alarmas del
sistema sobre
el control de
disponibilidad
Permitir generar avisos en el sistema
sobre las partidas presupuestarias que
han sido superadas o están a punto de
hacerlo
Requerido 3 Existen monitores y avisos que
controlan las desviaciones 2
SAP tiene cobertura para este requisito pero se
puede necesitar algún desarrollo adicional 3
Incluye el control presupuestario, permitiendo la
configuración de un umbral de aviso para la superación de
las partidas presupuestarias definido por el usuario
REQ-GP-PR-20 Bloqueo de
partidas
Permitir la configuración para el
bloqueo de presupuesto para el
remanente de determinadas partidas
ejecutadas parcialmente.
Requerido 2
La herramienta no permite bloquear
partidas no ejecutadas de forma
automática. Se puede realizar
mediante workaround registrando
un asiento de compromiso con ese
remanente.
1
La herramienta no permite bloquear partidas
no ejecutadas de forma automática. Se necesita
un desarrollo 1
La herramienta no permite bloquear partidas no
ejecutadas de forma automática. Se necesita un desarrollo
REQ-GP-PR-21 Copia de
presupuestos
Posibilidad de copiar presupuestos
existentes para crear nuevos
presupuestos
Requerido 3
Esta gestión de copia y elaboración
se realiza en la herramienta de
planificación y presupuestación de
Oracle
3
Se permite la gestión de distintas versiones
hasta llegar a una definitiva que se podrá copiar
a partir de otra 3
Sí que permite la generación de presupuestos desde la
contabilidad real, aplicando un factor a los importes de
contabilidad real para la generación de las partidas
presupuestarias
REQ-GP-PR-22 Arrastre de
presupuesto
Herramienta para asistir a los
responsables de presupuestación a la
hora de arrastrar presupuesto entre
ejercicios.
Requerido 3
Esta gestión de copia y elaboración
se realiza en la herramienta de
planificación y presupuestación 2
Se permite arrastrar el presupuesto de un año a
otro con un pequeño desarrollo 3
Esta gestión de copia y elaboración se realiza en la
herramienta de planificación y presupuestación
C Reporting
REQ-GP-PR-23 Consultas on-
line
El sistema deber permitir en todo
momento ejecutar las consultas en
tiempo real por los criterios analíticos
definidos
Requerido 3
El seguimiento analítico siempre es
en tiempo real. Existen monitores de
control específicos
3 Existen diversos informes estándar que cubren
el requisito 3
Existen varias consultas e informes de la información
presupuestaria
REQ-GP-PR-24
Comparativa
con datos
reales
Proporcionar informes para comparar
Gastos reales frente a Cantidades
presupuestadas para supervisar y
controlar los presupuestos.
Requerido 3 Existen informes, consultas para
realizar este tipo de seguimiento 3
Existen diversos informes estándar que cubren
el requisito 3
Existen varias consultas e informes de la información
presupuestaria y su comparativa vs datos reales
REQ-GP-PR-25
Comparativa
con datos de
periodos
anteriores
Permitir comparar datos de diferentes
periodos mediante informes con fines
de elaboración de informes y control.
Requerido 3 Se pueden comparar datos de
diferentes periodos 3
Existen diversos informes estándar que cubren
el requisito 3
Existen varias consultas e informes de la información
presupuestaria y su comparativa vs datos reales
85
Oracle ERP Cloud SAP S/4 HANA Cloud Microsoft Dynamics AX Cloud
Nº Req. Descripción de
requerimiento Prioridad
Grado de
Cobertura
Descripción
cobertura Grado de
Cobertura Descripción cobertura Grado de
Cobertura Descripción cobertura
REQ-GP-PR-26
Comparativa
entre
versiones de
presupuestos
Posibilidad de obtener informes con la
versión inicial del presupuesto y
ampliaciones presupuestarias y
adjudicaciones de compra para poder
realizar tendencias de cierre
Requerido 3
Se puede comparar en consultas e
informes el presupuesto original y el
revisado
3
Existen diversos informes estándar que cubren
el requisito de comparar distintas versiones de
planificación y costes reales.
2
Si la comparativa se hace sobre las actividades que se van
creando en los presupuestos, puede ser sencillo desde un
SQL o PowerBI, pero cada modificación del presupuesto,
se tendría que hacer en nuevas actividades, para que
quedasen reflejadas las modificaciones. Esto a su vez
puede ser poco operativo para la operativa del cliente si
son muchas las modificaciones. También hay otra opción
algo más compleja técnicamente pero muy sencilla para la
operativa, que sería utilizar el log de cambios en según
qué campos de las tablas.
REQ-GP-PR-27
Análisis de
elementos de
costes
Poder ejecutar informes de cualquiera
de los elementos definidos como
objetos de coste y analizar las
imputaciones registradas en ellos.
Requerido 3
Las comparaciones siempre pueden
ser por objetos de coste
independientes o bien combinando
los diferentes segmentos analíticos
3 Existen diversos informes estándar que cubren
el requisito 3
Tanto la introducción como la consulta de los datos
presupuestarios puede realizarse para cada dimensión
analítica
REQ-GP-PR-28 Informes de
presupuestos
Informes relativos al presupuesto
definido, comprometido, obligación y
real.
Requerido 3
Se permite consultar y crear
informes de los saldos en todos estos
estados
3 Existen diversos informes estándar que cubren
el requisito 3
Existen varias consultas e informes de la información
presupuestaria y su comparativa vs datos reales
REQ-GP-PR-29
Informes de
seguimiento
por rúbrica
Posibilidad de realizar el seguimiento
de las diferentes rúbricas según su
estado: presupuesto, presupuesto
ampliado con las nuevas partidas
aprobadas, gastos contabilizados
(diferenciando si están facturados o
periodificados), gastos incurridos
pendientes de facturas, gastos
comprometidos pero no incurridos
(compras realizadas pendientes de
entrega o de recepción de los servicios
o contratos de larga duración con un
volumen de gastos ya comprometido) o
gastos solicitados y aún no cerrados por
compras.
Requerido 3
Se puede realizar un control
presupuestario por todos estos
conceptos (comprometidos,
obligados, reales).
3 Existen diversos informes estándar que cubren
el requisito 3
Permite la introducción de diferentes tipos de partidas
presupuestarias (revisiones, transferencias…) fácilmente
identificables en el sistema.
REQ-GP-PR-30
Gastos
recurrentes o
partidas
pendientes de
ejecutar
Herramienta para asistir a los
responsables de presupuestación a la
hora de configurar el nuevo
presupuesto para obtener los gastos
recurrentes del anterior presupuesto, así
como las partidas parcialmente
ejecutadas con previsión de ser
ejecutadas en sucesivos ejercicios.
Requerido 3
La herramienta de planificación y
presupuestación permite gestionar
este tipo de circunstancias
3 Existen diversos informes estándar que cubren
el requisito 3
Para una mayor operatividad y agilidad explotando esta
información para el usuario plantearíamos además el,
desarrollo de cubos SQL o Power BI para su explotación
en Excel por los usuarios
REQ-GP-PR-31
Construcción
de reporte por
usuarios
Se requiere que el usuario pueda
realizar consultas sin necesidad de
conocimientos técnicos. Todos los
reportes deben ser exportables
fácilmente a Excel.
Requerido 3
Mediante asistentes se pueden crear
consultas fácilmente gracias al BI
integrado y sus esquemas de estrella.
Todos los informes y consultas son
fácilmente exportables a Excel
1
El usuario puede realizar consultas pero no
existe una herramienta de BI integrada para la
creación de reports
3 Integración Excel nativa. Además está incluida la
herramienta de PowerBI
D Integración
REQ-GP-PR-32 Integración
con
Contabilidad
Las dimensiones analíticas definidas
para el área de Planificación y
Presupuestación deben tener
Requerido 3 La integración es total 3 SAP es un sistema plenamente integrado 3 Todos los módulos están integrados y forman parte de un
todo modular. Las dimensiones analíticas se extienden por
86
Oracle ERP Cloud SAP S/4 HANA Cloud Microsoft Dynamics AX Cloud
Nº Req. Descripción de
requerimiento Prioridad
Grado de
Cobertura
Descripción
cobertura Grado de
Cobertura Descripción cobertura Grado de
Cobertura Descripción cobertura
General y
analítica
correspondencia con las distintas
cuentas contables para garantizar el
cuadre entre la contabilidad financiera y
la analítica
toda la aplicación, permitiendo su total integración
REQ-GP-PR-33
Integración
con Gestión
de Proyectos
Las imputaciones y movimientos que
se realicen contra los proyectos deben
quedar clasificadas en base a las
características/dimensiones analíticas
de esos proyectos para su posterior
explotación de la información.
Requerido 3 La integración es total 3 SAP es un sistema plenamente integrado 3
Todos los módulos están integrados y forman parte de un
todo modular. Las dimensiones analíticas se extienden por
toda la aplicación, permitiendo su total integración
REQ-GP-PR-34
Integración
con cuentas a
pagar
Conectar los elementos analíticos en la
gestión de acreedores para que las
facturas y demás apuntes con efectos en
los ingresos y gastos queden integrada
en la gestión presupuestaria de forma
automática.
Requerido 3
La integración es total. Mediante el
motor contable se especifican reglas
automáticas de relleno de
dimensiones analíticas
3 SAP es un sistema plenamente integrado 3
Todos los módulos están integrados y forman parte de un
todo modular. Las dimensiones analíticas se extienden por
toda la aplicación, permitiendo su total integración
REQ-GP-PR-35
Integración
con cuentas a
cobrar
Conectar los elementos analíticos en la
gestión de deudores para que las
facturas y demás apuntes con efectos en
los ingresos y gastos queden integrada
en la gestión presupuestaria de forma
automática.
Requerido 3
La integración es total. Mediante el
motor contable se especifican reglas
automáticas de relleno de
dimensiones analíticas
3 SAP es un sistema plenamente integrado 3
Todos los módulos están integrados y forman parte de un
todo modular. Las dimensiones analíticas se extienden por
toda la aplicación, permitiendo su total integración
REQ-GP-PR-36
Integración
con activos
fijos
Poder asociar elementos analíticos al
maestro de activos fijos y así recoger
cualquier gasto o ingreso asociado al
inmovilizado e integrarlo en la
contabilidad analítica de forma
automática.
Requerido 3
La integración es total. Mediante el
motor contable se especifican reglas
automáticas de relleno de
dimensiones analíticas
3 SAP es un sistema plenamente integrado 3
Todos los módulos están integrados y forman parte de un
todo modular. Las dimensiones analíticas se extienden por
toda la aplicación, permitiendo su total integración
REQ-GP-PR-37
Carga de
operaciones
reales de otros
sistemas para
seguimiento
presupuestario
de las
participadas
Disponer de una herramienta para
cargar la contabilidad real desde
sistemas externos mediante hoja de
cálculo, para las empresas participadas
que no están en el alcance del ERP.
Requerido 3 Las cargas se pueden realizar
mediante hojas Excel 1
Se necesita desarrollo para la integración con
otros sistemas 3
Mediante el add in de Excel permite la integración desde
Excel de apuntes contables
87
vii. Compras
Oracle ERP Cloud SAP S/4 HANA Cloud Microsoft Dynamics AX Cloud
Nº Req. Descripción de
requerimiento Prioridad
Grado de
Cobertura
Descripción
cobertura Grado de
Cobertura Descripción cobertura Grado de
Cobertura Descripción cobertura
A Maestros
REQ-GP-CO-1
Maestro de
bienes y
servicios
Permitir la definición de distintas
naturalezas de compras (p.e. categoría /
sub-categorías), las cuales se deberán
estar asociadas a las rúbricas contables
(cuentas).
Requerido 3
Según clasificaciones de naturalezas
de compras se establecen rúbricas de
contabilización
3
SAP Permite definir la clasificación de
naturalezas de compra a través de categorías de
productos/familias y asociarlas a las cuentas
contables pertinentes a través de sus categorías
de valoración.
3 Funcionalidad estándar
REQ-GP-CO-2 Maestro de
Proveedores
Disponer de un acceso común a los
datos de los proveedores registrados en
el sistema.
Requerido 3 El maestro de proveedores se puede
acceder de forma común 3 Funcionalidad estándar 3 Funcionalidad estándar
REQ-GP-CO-3
Catálogo de
bienes y
servicios
Posibilidad de definir un catálogo de
compras a partir de la clasificación
definida, pudiendo asociarse a
proveedores y acuerdos marco vigentes
para facilitar la gestión.
Opcional 3
Se puede definir un catálogo de
compras, con capacidad de asociar
acuerdos marcos y proveedores
3
SAP proporciona diferentes fuentes de
aprovisionamiento para asociar estas
necesidades, Acuerdos marcos, libros de
pedido, Registros info…
3
Además del catálogo de productos pueden crearse
catálogos de productos genéricos que luego compras
puede decidir sobre qué modelo se compra. Ejemplo en el
catálogo hay un producto que es una Tablet y luego
compras puede decidir qué modelo se asigna
REQ-GP-CO-4 Organización
de Compras
Permitir definir la Organización de
compras, como la unidad organizativa
responsable del suministro de bienes y
servicios y de la negociación de las
condiciones de compra generales con
los proveedores.
Requerido 3
Se puede definir compras como una
unidad de organización específica
con estas funciones. Esta unidad
podrá realizar gestiones on behalf de
otras unidades
3
SAP permite definir de forma estándar una
estructura de compras, además de asociar
grupos de compras responsables a materiales o
servicios.
3 Funcionalidad estándar
B Operaciones
REQ-GP-CO-5 Control
presupuestario
El sistema deberá contar con
mecanismos de control presupuestario
en el flujo de Compras al Pago (P2P).
Este mecanismo deberá comprobar la
disponibilidad de fondos para la rúbrica
asociada a la naturaleza del gasto
(cuenta) y del centro solicitante,
rechazando su registro en caso de
insuficiencia de fondos o bloqueando el
importe de la compra hasta que se
registre el gasto real con la facturación.
Requerido 3 el control presupuestario está
incluido en todo el proceso P2P 3
Se pueden realizar controles presupuestarios
desde la cesta de la compra en Ariba contra el
ERP en tiempo real.
3
el módulo de compras consulta presupuestos y puede
admitir o rechazar una solicitud en función de parámetros
del presupuesto
REQ-GP-CO-6 Solicitudes de
compra
Disponer de un formulario para el
registro de la necesidad de adquisición
y que permita registrar múltiples
naturalezas en una misma solicitud. A
través de dicho formulario podrá
adjuntarse documentación tal como
pliegos de prescripciones técnicas o
proveedores susceptibles del
suministro.
Este documento es susceptible de la
funcionalidad del control
presupuestario y flujo de aprobación.
Requerido 3
Existe un formulario de autoservicio
que permite registrar diferentes
necesidades a la vez de artículos y/o
servicios. Las solicitudes pueden ser
contra catálogo o también en
formularios libres, se puede adjuntar
la información necesaria para
facilitar las tareas del departamento
de compras y/o colaborar mediante
la red social incorporada
3
Se utilizará el documento cesta de la compra en
Ariba para el registro de eta necesidad. Éste
permite adjuntar documentos, diferentes
posiciones asociadas a diferentes naturalezas.
Las verificaciones presupuestarias se realizarán
desde este documento.
3 Funcionalidad estándar
88
Oracle ERP Cloud SAP S/4 HANA Cloud Microsoft Dynamics AX Cloud
Nº Req. Descripción de
requerimiento Prioridad
Grado de
Cobertura
Descripción
cobertura Grado de
Cobertura Descripción cobertura Grado de
Cobertura Descripción cobertura
REQ-GP-CO-7
Mecanismo de
aprobación de
solicitud
Permitirá habilitar un flujo de
aprobación para las solicitudes de
compra. Este flujo debe permitir
adaptar la jerarquía de aprobadores en
función de las rúbricas (cuentas), centro
supervisor, centro autorizador.
Requerido 3
La aprobación de solicitudes de
compras se adapta a las necesidades
específicas a través de la
herramienta de configuración BPM
3 Se tendrá que definir el proceso de autorización
y configurar el WF en el sistema. 3 Con el Motor de Work Flows
REQ-GP-CO-8 Delegación de
aprobaciones
El sistema de permitir delegar la
aprobación a un tercero. Requerido 3
Se puede permitir la sustitución de
la aprobación a un tercero o bien
sustituir temporalmente un
aprobador por otro
3 Existe la funcionalidad de sustituciones en el
sistema. 3 de forma manual o a través de Work Flows
REQ-GP-CO-9
Comunicación
de resultados
de aprobación
Los eventos que se sucedan en el
proceso de aprobación deberán ser
comunicados a los interesados: Centro
supervisor, centro autorizador, centro
solicitante, Negociación de compras,
etc.
Requerido 3
Las notificaciones pueden ser
internas mediante avisos o también
con envío de correo electrónico 3
Cualquier persona que interviene en el proceso
de aprobación será notificada automáticamente
en el sistema. Se tendrán que configurar los
cuerpos de mensaje que contendrán estos
mails.
3 Existen varios workflows de aprobación con distintos
niveles de aprobación
REQ-GP-CO-10
Negociación
con los
Proveedores
Disponer de formularios para la gestión
del proceso de negociación con
proveedores. El sistema debe poder
registrar un proceso de negociación a
partir de la información de las
solicitudes de compra y de los
proveedores que intervendrán en dicho
proceso. Este proceso debe contar con
diferentes estados que faciliten el
seguimiento de su situación actual.
Requerido 3 El módulo de negociación permite
gestionar RFP's, RFI's, subastas 3
SAP Ariba Sourcing dispone de eventos tales
RFI, RFP, Subastas y la posibilidad de
gestionar estos eventos y tareas a través de
proyectos. Los proyectos permitirán realizar un
seguimiento exhaustivo a través de tareas y
notificaciones automáticas.
1
Para que el proceso pueda intervenir en un proceso de
negociación y solicitudes de compra, se debe usar el
Enterprise portal de AX. Necesitará de adaptaciones para
adaptar los formularios a publicar en el portal.
REQ-GP-CO-11
Planificar el
proceso de
Negociación
Funcionalidad que permita planificar el
proceso de negociación a partir de un
calendario de actividades con la
finalidad de dar seguimiento al proceso.
El sistema deberá alertarnos según se
vaya desarrollando el proceso.
Requerido 3
El proceso de negociación marca
actividades y calendarios para
generar los avisos correspondientes. 3
Esta funcionalidad es la gestión de proyectos
de Sourcing de Ariba. Los proyectos se podrán
dividir en diferentes fases, ésta incluyan tareas
y/o eventos, notificando a los responsables de
realizar cada una de ellas.
2
Asignación de actividades a proyecto e imputación de
costes a actividad. Creación de diferentes calendarios en
función de las actividades, ya que dependiendo de los
horarios el sistema puede generar ciertos avisos. Indico
cierto desarrollo ya que dentro del concepto "Proceso de
negociación" puede existir muchas casuísticas que no
contemple el sistema
REQ-GP-CO-12
Preguntas y
Requerimient
os para
Proveedores
El sistema debe permitir el registro de
preguntas y/o requerimientos de
diferentes tipologías, definir
ponderaciones a cada una de ellas.
Estas preguntas y requerimientos
podrán ser utilizados para las
Solicitudes de Información (RFI) o
Solicitudes de Cotización (RFQ).
Opcional 3
Se pueden definir la pregunta o el
requerimiento a solicitar. También
puntuaciones que permitan la
valoración
3
Con SAP Ariba Sourcing se pueden establecer
preguntas, asociarles pesos, que sean preguntas
condicionales a seguir el proceso, que tengan
impacto en si hay que realizar o no tareas en el
proceso de Sourcing.
1 Mediante las campañas o registro de actividades se podría
llegar a generar una entrada de información del proveedor
REQ-GP-CO-13
Solicitud de
Información
(RFI)
El sistema debe permitir el registro de
Solicitudes de Información (RFI) para
los proveedores a partir de la librería de
preguntas. Para facilitar la
comunicación con el proveedor el
sistema podrá remitir las preguntas
desde la aplicación o facilitar su
extracción a ficheros en formato Excel
Requerido 3
Se permite la respuesta manual en el
sistema, en portal de proveedores o
bien a través de plantillas de Excel
3
Dentro de SAP Ariba Sourcing existe el evento
RFI. Permite interactuar con el proveedor para
el intercambio de información o respuesta de
preguntas a través de un portal de proveedores
(Ariba Network) o directamente por mail con
ficheros.
1 Ídem al punto anterior, ya que en una campaña se pueden
adjuntar diferentes formularios de preguntas
89
Oracle ERP Cloud SAP S/4 HANA Cloud Microsoft Dynamics AX Cloud
Nº Req. Descripción de
requerimiento Prioridad
Grado de
Cobertura
Descripción
cobertura Grado de
Cobertura Descripción cobertura Grado de
Cobertura Descripción cobertura
para su envío por correo electrónico.
La información y documentación
requerida puede utilizarse por ejemplo
para la homologación al proveedor.
REQ-GP-CO-14
Recepción de
la Información
solicitada
El sistema disponer de mecanismos que
faciliten el registro de la información
remitida por los proveedores en
relación con la Solicitud de
Información (RFI). Por ejemplo a
través de la importación de ficheros en
formatos Excel.
Requerido 3 la integración de las respuestas a
través de portal o Excel es inmediata 3
Permite interactuar con el proveedor para el
intercambio de información o respuesta de
preguntas a través de un portal de proveedores
(Ariba Network) o directamente por mail con
ficheros.
2
La herramienta DIXF permite importar desde plantillas
Excel información en el sistema. Es necesario generar
ciertos objetos en el sistema para crear las entidades a
importar.
REQ-GP-CO-15
Análisis de la
Solicitud de
Información
El sistema debe facilitar el análisis de
las respuestas de los proveedores en
base a las ponderaciones definidas para
cada una de ellas, proponiendo un
ranking a través de sus propias
pantallas, gráficos y/o informes,
facilitando la toma de decisiones.
Requerido 3
En base a las ponderaciones
establecidas y las respuestas, el
sistema propone un ranking de
adjudicación que facilitará la
decisión final
3
Además de existir informes precargados en el
sistema para el análisis de esta información, el
sistema permite crear informes a medida con la
información requerida.
1 Mediante BI es un desarrollo más sencillo. Cubos OLAP
o PowerBI, pero hacerlo en AX es más complejo.
REQ-GP-CO-16
Solicitud de
Cotización
(RFQ)
El sistema debe permitir el registro de
Solicitudes de Cotización (RFQ) para
los proveedores a partir de la librería de
requerimientos con la información
técnica de lo que se quiere comprar.
Para facilitar la comunicación con el
proveedor el sistema podrá remitir las
preguntas desde la aplicación o facilitar
su extracción a ficheros en formato
Excel para su envío por correo
electrónico.
Requerido 3
Se pueden enviar los RFQ a los
proveedores en formato Excel para
facilitar sus respuestas y la
integración en el sistemas
3
Dentro de SAP Ariba Sourcing existe el evento
RFQ. Permite interactuar con el proveedor para
el intercambio de información o respuesta de
preguntas a través de un portal de proveedores
(Ariba Network) o directamente por mail con
ficheros. Existen bibliotecas de documentos
que se pueden organizar como se deseen, y
utilizarlas en cualquier momento.
1 Debería de evaluarse y tratar como registró en
presupuestos.
REQ-GP-CO-17
Recepción de
la Cotización
solicitada
El sistema disponer de mecanismos que
faciliten el registro de la información
técnica y económica remitida por los
proveedores en relación con la
Solicitud de Cotización (RFQ). Por
ejemplo a través de la importación de
ficheros en formatos Excel.
Requerido 3
Se pueden enviar los RFQ a los
proveedores en formato Excel para
facilitar sus respuestas y la
integración en el sistemas
3
Permite interactuar con el proveedor para el
intercambio de información o respuesta de
preguntas a través de un portal de proveedores
(Ariba Network) o directamente por mail con
ficheros.
1 Importación mediante DIXF, pero teniendo claro el punto
anterior
REQ-GP-CO-18
Análisis de la
Solicitud de
Información
El sistema debe facilitar el análisis de
las respuestas de los proveedores en
base a las ponderaciones y factores
económicos de cada una de las ofertas,
proponiendo un ranking o vista
comparativa a través de sus propias
pantallas, gráficos y/o informes,
facilitando la toma de decisiones para la
adjudicación de la compra.
Requerido 3
En base a las ponderaciones
establecidas y las respuestas, el
sistema propone un ranking de
adjudicación que facilitará la
decisión final
3
Si las preguntas y respuestas de proveedores
estaban ponderadas se podrá obtener un
análisis, además el sistema permite crear varios
supuestos de adjudicación que facilitará a la
mesa de compras tomar una decisión.
2
Nuestra recomendación sería realizarlo con Power BI con
un desarrollo sencillo (vía Cubos OLAP o PowerBI). Con
AX es más complejo.
REQ-GP-CO-19
Comunicación
con
proveedores
El sistema debe facilitar de mecanismos
de comunicación (de ser posible on-
line) con los proveedores durante todo
el proceso de negociación. Esto
permitirá agilizar la resolución de
Opcional 3
La comunicación con los
proveedores puede ser online a
través del portal, con correo
electrónico o bien a través de
conversaciones de la red social
3 Ariba habilita varias vías de comunicación con
el proveedor para el intercambio de mensajes. 2
La generación de alertas y su envío por correo electrónico
es automático y estándar. En función del tipo de
información a enviar, requiere desarrollo.
90
Oracle ERP Cloud SAP S/4 HANA Cloud Microsoft Dynamics AX Cloud
Nº Req. Descripción de
requerimiento Prioridad
Grado de
Cobertura
Descripción
cobertura Grado de
Cobertura Descripción cobertura Grado de
Cobertura Descripción cobertura
dudas, intercambio de comentarios, etc.
REQ-GP-CO-20 Elaboración
de Contratos
El sistema deberá disponer formularios
que permitan la gestión de contratos
con los proveedores. Permitiendo la
elaboración de diferentes tipologías de
contratos con diferentes estructuras,
acuerdos, políticas, hitos, etc.
Opcional 3
Existe la funcionalidad de gestión de
contratos y todo su clausurado legal
a través de plantillas y variables 3
SAP Ariba Contract Management permite la
gestión del ciclo de vida del contrato. Pudiendo
establecer diferentes tipos de proyectos de
seguimiento a través de plantillas dependiente
el tipo de contrato.
3 Contratos y plantillas de contratos
REQ-GP-CO-21 Integración
con MS Word
El sistema de elaboración de contratos
deberá estar integrado con Microsoft
Word para poder agilizar el registro y la
edición del mismo. Esto facilitará su
impresión o almacenamiento en
formato Word o PDF para su posterior
envío al proveedor.
Opcional 3
El contrato queda grabado en Msft
Word y permite la colaboración con
proveedores, compras y legal.
Quedando reflejado todos los
cambios en las versiones
3
SAP Ariba Contract Management está
integrado con Microsoft Word, pudiendo
utilizar funcionalidad de Word como por
ejemplo la comparación de versiones. Se
permite la gestión de cláusulas y su biblioteca.
2
Desde AX se puede almacenar un PDF o enviar un PDF
por correo electrónico. Si los datos del contrato están en
AX, se pueden vincular a Microsoft Word mediante la
utilidad Add-in the Microsoft.
REQ-GP-CO-22 Aprobación de
Contratos
El sistema deberá disponer de
funcionalidad que permita y agilice la
validación y aprobación del contrato
por los diferentes intervinientes,
seguridad informática, asesoría jurídica
entre otros.
Opcional 3
El contrato queda grabado en Msft
Word y permite la colaboración con
proveedores, compras y legal.
Quedando reflejado todos los
cambios en las versiones
3
Con SAP Ariba Sourcing y la gestión de
proyectos se podrá establecer una secuencia de
seguimiento de actividades, autorización,
negociaciones de clausulado con el proveedor,
etc., asociar tareas a diferentes intervinientes
(miembros de equipo en Ariba).
3
Si el origen de los datos está en AX a través de un Work
Flows se puede hacer de forma estándar. Si el origen de
los datos de aprobación fuera externo habría que
desarrollarlo
REQ-GP-CO-23
Registro del
Contrato de
Compra
El sistema deberá disponer de
formulario para el registro del Contrato
o Acuerdo Marco firmado por el
proveedor tras la adjudicación. La
finalidad de este documento es poder
agilizar las posteriores solicitudes de
compra en base a las fechas de
vigencia, naturalezas de compra,
precios / tarifas, entre otros.
Requerido 3
Se permite el registro del contrato o
acuerdo marco que servirá como
base a los pedidos derivados de
solicitudes, con las especificaciones
necesarias de precios, artículos,
fechas…
3
Una vez que se ha trabajado el contrato en
borrador, añadido o eliminado clausulas, dado
el ok del proveedor tras su negociación, el
sistema permite la generación del acuerdo final
en PDF para su firma en el sistema a través de
autorización o firma digital (integración nativa
con diversas plataformas como por ejemplo
Docusign).
3 Gestión de contratos y acuerdos comerciales en AX
REQ-GP-CO-24 Adjuntar
Documentos
Debe permitir adjuntar los documentos
firmados y cualquier tipo de
documento, con la finalidad de
disponer de ellos en todo momento
desde la propia aplicación.
Requerido 3
Los documentos pueden ser
anexados para su consulta a nivel de
transacción 3
Es posible adjuntar documentación de
cualquier tipo y crear tareas asociadas a ellas.
Se pueden asociar a un proyecto de contrato de
forma específica a una biblioteca que se genere
y se gestione como se desee.
3
AX tiene capacidad para asociar documentos externos en
cualquier parte de la aplicación (contratos, facturas,
pedidos, etc.)
REQ-GP-CO-25 Alertas sobre
Contratos
El sistema deberá disponer de
funcionalidad que alerte a través de
notificaciones en el sistema o vía mail
sobre ciertas situaciones de los
Contratos de Compra. Por ejemplo
alertas sobre el vencimiento,
cancelación, prórrogas, aprobaciones,
etc.
Requerido 3 Permite generar notificaciones o
avisos 3
En el sistema se pueden configurar este tipo de
alertas en el sistema. 2
Si, si se trata de notificar fechas. Las alertas de A+F19X
se pueden enviar por mail, pero son sobre cambios que se
hacen en el sistema. Cambios de valor en campos.
Para realizar un sistemas de alertas más complejo, en el
que se pueda avisar de situaciones futuras, se tiene que
hacer un desarrollo que permita alertar a diferentes
cuentas de correo, con una información específica y con
una periodicidad configurable
REQ-GP-CO-26 Pedido de
Compra
El sistema deberá permitir el registro de
la formalización de la compra a través
de un Pedido de Compra. Este debe
estar asociado a la solicitud de compra
y a su vez al Contrato o Acuerdo
Marco. Este documento debe contar
Requerido 3
El contrato o acuerdo marco,
solicitud y pedido están totalmente
asociados. El control presupuestario
se inicia con la solicitud
3
El pedido de compra se realizará desde la cesta
de la compra en Ariba y se permitirá comprar
contra catálogo, texto libre o un
material/servicio en concreto. Se podrá asociar
a contrato de compras estos pedidos siempre
3 Funcionalidad estándar
91
Oracle ERP Cloud SAP S/4 HANA Cloud Microsoft Dynamics AX Cloud
Nº Req. Descripción de
requerimiento Prioridad
Grado de
Cobertura
Descripción
cobertura Grado de
Cobertura Descripción cobertura Grado de
Cobertura Descripción cobertura
con diferentes estados que faciliten el
seguimiento de su situación actual.
Este documento es susceptible de la
funcionalidad del control
presupuestario y flujo de aprobación.
que existan en el sistema.
REQ-GP-CO-27
Mecanismo de
aprobación de
Pedido de
Compra
Permitirá habilitar un flujo de
aprobación para los pedidos de compra.
Este flujo debe permitir adaptar la
jerarquía de aprobadores en función de
las rúbricas (cuentas), centro
supervisor, centro autorizador.
Requerido 3
La aprobación de pedidos de
compras se adapta a las necesidades
específicas a través de la
herramienta de configuración BPM
3
En SAP Ariba el documento pedido se
generará automáticamente desde la cesta de la
compra. La solución al WF de autorización
vale para este requerimiento.
3 Funcionalidad estándar
REQ-GP-CO-28
Control
presupuestario
en Pedido de
Compra
Este mecanismo deberá comprobar la
disponibilidad de fondos para la rúbrica
asociada a la naturaleza del gasto
(cuenta) y del centro solicitante,
rechazando su registro en caso de
insuficiencia de fondos o bloqueando el
importe de la compra hasta que se
registre el gasto real con la facturación.
En este caso se deberá tener en cuenta
el importe de la solicitud de compra
asociada al periodo, dado que si el
importe del pedido de compra es igual e
inferior a la solicitud de compra puede
no ser necesaria su aprobación, sin
embargo si este importe es superior será
necesario iniciar un nuevo flujo de
aprobación.
Requerido 3
La disponibilidad de fondos tiene en
cuenta los compromisos, las
obligaciones y los reales
0 Se necesita un desarrollo para realizar esas
comprobaciones desde Ariba 3 Funcionalidad estándar
REQ-GP-CO-29
Envío de
pedidos de
compra a
proveedores
El sistema debe permitir el envío de los
pedidos de compra (PDF o formato
electrónico) a los proveedores de forma
automática tras la aprobación del
mismo, con la finalidad de agilizar su
comunicación.
Requerido 3
Los pedidos pueden ser generados
vía PDF y enviados
automáticamente al proveedores vía
correo electrónico
3
Se puede enviar PDF, formato electrónico o a
través del portal de colaboración de Ariba
network. 2
Puede realizarse el envío en formato PDF de forma
manual realizado por el usuario esto es estándar, pero
generar de forma automática y masiva en un momento
determinado esto sería un desarrollo
REQ-GP-CO-30
Alertas sobre
Pedidos de
Compra
El sistema deberá disponer de
funcionalidad que alerte a través de
notificaciones en el sistema o vía mail
sobre ciertas situaciones de los Pedidos
de Compra. Por ejemplo alertas a los
aprobadores.
Requerido 3
Las notificaciones de aprobaciones
pueden ser enviadas vía correo
electrónico 3
Cualquier persona que interviene en el proceso
de aprobación será notificada automáticamente
en el sistema. Se tendrán que configurar los
cuerpos de mensaje que contendrán estos
mails.
2 Es necesario un desarrollo
REQ-GP-CO-31 Recepciones
de compra
Permitir registrar las recepciones de
mercancía de forma que los centros
solicitantes confirmen el suministro del
bien o servicio por parte del proveedor.
Debe poder registrarse recepciones
totales o parciales. Con este evento se
confirmará el consumo del presupuesto
asignado, no obstante no pasará a ser
gasto real hasta la facturación.
Esta recepción deberá ser registrada por
los solicitantes de la compra desde los
formularios que estos dispongan.
Requerido 3
Las recepciones pueden ser totales o
parciales y pueden ser registradas
por el usuario solicitante a través de
un formulario específico
3
Se podrá realizar la confirmación desde la
misma herramienta, si el proveedor está
registrado en el portal del Ariba network se
podrá confirma, y avisar de la entrega por el
propio proveedor.
3 Funcionalidad estándar
92
Oracle ERP Cloud SAP S/4 HANA Cloud Microsoft Dynamics AX Cloud
Nº Req. Descripción de
requerimiento Prioridad
Grado de
Cobertura
Descripción
cobertura Grado de
Cobertura Descripción cobertura Grado de
Cobertura Descripción cobertura
REQ-GP-CO-32
Importación
de Pedidos y
Recepciones
El sistema permitirá registrar pedidos
de compra y recepciones de forma
masiva a través de ficheros de carga
Requerido 3 Se permiten cargas masivas de
pedidos y recepciones 3
Estos pedidos y confirmaciones se cargarían a
través de un programa desarrollado a medida
pero en SAP.
1 Es necesario un desarrollo
REQ-GP-CO-33
Contabilizacio
nes de facturas
contra pedido
/ recepción.
Permitir registrar las facturas
asociándolas contra un pedido de
compra o contra la recepción con la
finalidad de mantener la trazabilidad de
la compra y dar por contabilizado el
gasto real inicialmente comprometido.
Requerido 3
Se pueden definir los 2 ciclos:
pedido contra factura o pedido-
recepción-factura 3
Las facturas se pueden registrar directamente
por el proveedor contra el pedido a través de
Ariba Network. 3 Funcionalidad estándar
REQ-GP-CO-34 Sociedades de
grupo
Se debe soportar la operación de las
empresas relacionadas, a objeto de que
su operación cumpla con los mismos
parámetros de las sociedades del
Holding
Requerido 3 Se pueden soportar las empresas que
se requieran 3 Funcionalidad estándar 3 Se cubre mediante la configuración estándar
REQ-GP-CO-35
Trazabilidad
Solicitud-
Oferta -
Contrato-
Pedido-
Recepción -
Factura
Control de la trazabilidad de todo el
proceso. Es decir, que en cada
momento se pueda saber en qué estado
está cada expediente (solicitado,
pedido, decepcionado, facturado,
pagado).
Requerido 3
Existe una trazabilidad y consulta de
todo el ciclo de vida de un
expediente
3 Se puede seguir la trazabilidad desde informes
o desde el mismo objeto. 3 Funcionalidad estándar
REQ-GP-CO-36
Punto único
de
documentació
n de
expedientes
Sería deseable que el sistema permita
almacenar o adjuntar en un mismo
punto toda la información relacionada
con un expediente de compra.
Opcional 3
Desde una solicitud se puede
consultar toda la información
relacionada
0
El sistema cubre toda la información
relacionada por Proyectos (Sourcing, Gestión
de contratos,…) pero no agrupada por una
compra en concreto.
3
El sistema permite adjuntar documentación a las entidades
que se requiera, pudiendo configurar diferentes
localizaciones por entidad. Con esto se conseguiría tener
todos los expedientes localizados en una misma
ubicación. Permite adjuntar todo tipo de fichero
almacenando la fecha y el usuario.
REQ-GP-CO-37 Portal de
Proveedor
El sistema debe proveer de un
formulario con acceso para los
proveedores y que estos puedan dar
seguimiento a los Pedidos de Compra
que le hemos realizado. Facilitará la
interacción entre el área de Compras de
la compañía y el Socio de Partner.
Opcional 3
A través del portal de proveedores,
los mismos pueden acceder a
consultar los pedidos de compra e
interactuar en más puntos (catálogo,
datos maestros, notificaciones de
envío, situación financiera….)
3
A través del portal de proveedores Ariba
Network se puede realizar seguimientos de
pedidos, ofertas a negociaciones, facturas…)
3 Existe un portal de proveedores que permite el acceso vía
web para realizar el seguimiento
REQ-GP-CO-38 Definir
Tolerancias
El sistema debe permitir la definición
de tolerancias que sean aplicables a los
documentos de compras (Solicitud,
Pedido de Compra, Recepción) con la
finalidad de que el sistema permita
exceder el importe en un porcentaje, el
cual podrá ser modificado.
Requerido 3
Se pueden definir tolerancias de
importes y cantidades, numéricas o
porcentuales 3 Se podrán gestionar tolerancias. 3 Se pueden definir tolerancias por importe y por %
C Reporting
REQ-GP-CO-39 Consultas on-
line
El sistema deber permitir en todo
momento realizar consultas por pantalla
de la información incluida en el módulo
Requerido 3 Se pueden realizar consultas por
pantalla 3
Con Ariba existen informes precargados para
el seguimiento de compras, además de permitir
la creación de informes a medida de forma
3
Existe la posibilidad de personalizar la información que
los usuarios ven en pantalla por perfiles o de forma
individual. El usuario puede ser autosuficiente para
mostrar o consultar la info sobre la que tiene permisos de
93
Oracle ERP Cloud SAP S/4 HANA Cloud Microsoft Dynamics AX Cloud
Nº Req. Descripción de
requerimiento Prioridad
Grado de
Cobertura
Descripción
cobertura Grado de
Cobertura Descripción cobertura Grado de
Cobertura Descripción cobertura
de Compras sencilla. acceso.
REQ-GP-CO-40 Informes de
Compras
El sistema debe ofrecer informes que
permitan obtener información acerca de
las transacciones registradas en el
módulo de Compras:
- Solicitudes de Compras
- Negociación con Proveedores
- Proveedores Homologados
- Contratos
- Pedidos de Compras
- Recepciones de Compras
Requerido 3
Se entregan muchos informes acerca
de las transacciones, y se
proporcionan herramientas para
generar las consultas o informes
específicas que se requiera (OTBI,
BI Publisher)
3
Con Ariba existen informes precargados para
el seguimiento de compras, además de permitir
la creación de informes a medida de forma
sencilla.
2 El sistema permite la obtención de informes de los datos
introducidos en el sistema
REQ-GP-CO-41
Construcción
de reporte por
usuarios
Se requiere que el usuario pueda
realizar consultas sin necesidad de
conocimientos técnicos. Todos los
reportes deben ser exportables
fácilmente a Excel.
Requerido 3
Se pueden generar informes
mediante la herramienta de BI
Transaccional, BI Publisher,… con
asistentes para usuarios
3
Con Ariba existen informes precargados para
el seguimiento de compras, además de permitir
la creación de informes a medida de forma
sencilla y exportable a Excel.
3
Existe la posibilidad de personalizar la información que
los usuarios ven en pantalla por perfiles o de forma
individual. El usuario puede ser autosuficiente para
mostrar o consultar la info sobre la que tiene permisos de
acceso así como exportarla a Excel
D Integración
REQ-GP-CO-42
Integración
con Cuentas a
pagar
Integración del área de Compras con
las cuentas a pagar de forma que las
facturas y abonos recibidos puedan
asociarse directamente contra el código
de pedido al que corresponden.
Esta integración debe ser online y sin
necesidad de procesos de integración
específicos.
Requerido 3
La integración es total y directa.
Puede automatizarse el proceso de
imaging con la solución de imaging
3
Desde Ariba se enviará a SAP la información
necesaria de forma que haya traza entre los
documentos y la contabilidad.
3
AX es un ERP y en este sentido los módulos están
integrados y forman parte de un todo modular. Podemos
navegar desde la gestión a la contabilidad y viceversa. Es
Dato único
REQ-GP-CO-43
Integración
con
Contabilidad
General,
Contabilidad
Analítica y
presupuestació
n
Los eventos del proceso de compras
deben quedar reflejados en los módulos
de contabilidad general, contabilidad
analítica y presupuestación.
Requerido 3
Los procesos de compra que
generen un reflejo contable crean
asientos directos en la contabilidad y
analítica.
1
Desde Ariba se enviará a SAP la información
necesaria de forma que haya traza entre los
documentos y la contabilidad. 3
AX es un ERP y en este sentido los módulos están
integrados y forman parte de un todo modular. Podemos
navegar desde la gestión a la contabilidad y viceversa. Es
Dato único
REQ-GP-CO-44 Acceso de
solicitantes
Conectar el formulario de solicitudes de
compra para acceder desde la Intranet
Corporativa.
Requerido 3 Se puede crear un enlace al entorno
de la aplicación. 3
Es simplemente introducir un link en la intranet
corporativa que llame a la herramienta de
compras.
1
Habría que analizar las dificultades de la conexión desde
la intranet corporativa. Otra alternativa podría ser publicar
el formulario de solicitudes de compra en el Enterprise
Portal de AX, con el fin de poderse consultar vía web.
También se puede publicar únicamente a nivel interno.
94
viii. Empleados
Oracle ERP Cloud SAP S/4 HANA Cloud Microsoft Dynamics AX Cloud
Nº Req. Descripción de
requerimiento Prioridad
Grado de
Cobertura
Descripción
cobertura Grado de
Cobertura Descripción cobertura Grado de
Cobertura Descripción cobertura
A Maestros
REQ-GP-GE-1 Categorías
El sistema debe permitir la definición
de un maestro de categorías de
empleados, en los cuales se pueda
asociar la tarifa media de la categoría, y
utilizarlas para la definición de la
jerarquía de aprobaciones
Requerido 3
El sistema permite mantener las
tarifas tanto para categorías (puestos
de empleados) así como también
para personas nominadas. Las
jerarquías de empleados y puestos
pueden utilizarse para la gestión de
aprobaciones.
3
El sistema permite la definición de categorías y
a éstas se asocian los conceptos de nómina con
sus valores por categoría para su uso en
nómina (si el valor es una media por categoría
es algo que vendrá de fuera). No entiendo la
funcionalidad de jerarquía de aprobaciones; no
existe en el estándar esta parte ni puedo calibrar
el alcance.
2
Se define un coste por categoría de empleado. En la
definición de un Workflow de actividades, se puede
definir jerarquías de aprobaciones.
REQ-GP-GE-2 Calendarios
El sistema debe permitir la definición
de calendarios laborales
independientes, con la finalidad de
poder diferencias los días laborables de
cada ciudad.
Requerido 3
El sistema permite la definición de
una jerarquía organizativa así como
una jerarquía geográfica. Los
eventos de calendario pueden
vincularse a cualquier jerarquía y a
cualquier nivel de la misma. Así
pues, podrían gestionarse los
festivos de cada ciudad sin
problemas.
3
La ciudad corresponde a la Subdivisión de
personal que se asocia al empleado en el
infotipo de asignación organizativa. A las
diferentes Subdivisiones de personal se asigna
a cada una su calendario laboral, con sus días
laborables y festivos anuales.
3
Pueden existir tantos calendarios como se desee, pudiendo
asignar el calendario a Actividades, Empleados,
Proyectos, etc…
REQ-GP-GE-3 Maestro de
personas
El sistema debe permitir el registro de
empleados o personas con su
información básica, debiendo existir
diferencia entre personal interno y
externo (subcontratado), permitiendo
asociarle una categoría y calendario
laboral.
Requerido 3
El sistema permite definir y
mantener un maestro de personas
internas y externas con todos los
datos necesarios.
3
Se puede parametrizar un grupo de personal de
subcontratados, a los que no se calcule nómina,
y a este grupo se puede parametrizar toda la
gestión, categorías, horario, etc., excepto el
cálculo de la nómina (supongo que no querrán
calcular nomina)
3 Funcionalidad estándar
B Operaciones
REQ-GP-GE-4 Petición de
ausencias
El sistema debe disponer de un
formulario que permita la solicitud de
ausencias (p.e. vacaciones).
Requerido 3
El sistema dispone de una
funcionalidad específica para la
gestión de ausencias y permite el
registro de las mismas a través de un
formulario que puede variar
dependiendo del tipo de ausencia.
Las ausencias también pueden
cargarse vía hoja de cálculo.
3 Lo cubre la funcionalidad estándar del portal
del empleado y del manager 3
Por empleado se pueden planificar las ausencias de tipo
retributivas (vacaciones, periodos ausencia retribuidos) y
las ausencias no retributivas. En ambos casos, el
empleado puede hacer la solicitud por el módulo de
"Tiempo y Asistencia". En la solicitud se debe informar
de información relevante sobre la ausencia.
REQ-GP-GE-5 Aprobación de
ausencias
Disponer de mecanismos de
aprobación para las solicitudes de
ausencias. Este flujo de aprobación
debe permitir la adaptación de los
aprobadores en función del empleado.
Requerido 3
Las peticiones de ausencias
disponen de un workflow de
aprobación configurable.
3 Lo cubre la funcionalidad estándar del portal
del manager 3 Para cada empleado se define un aprobador
REQ-GP-GE-6 Imputación de
horas
Disponer de un formulario que permita
la imputación de horas a los proyectos
(incluyendo ausencias planificadas o no
planificadas), tanto para el personal
interno como el externo, y desde el que
se pueda ver el estado de aprobación
Requerido 3
La entrada de ausencias y la de
horas tanto para personal interno
como externo puede realizarse desde
el mismo formulario si así se
requiere. Ambas tipologías de
tiempo (ausencias y horas de
proyectos) se transfieren a los
3 Lo cubre el módulo de CATS 3
La imputación de horas a los proyectos se realiza desde el
diario de horas o desde las actividades planificadas del
proyecto. En el registro de ausencias se solicita el
proyecto para que así queden registrados los costes de la
ausencia.
95
Oracle ERP Cloud SAP S/4 HANA Cloud Microsoft Dynamics AX Cloud
Nº Req. Descripción de
requerimiento Prioridad
Grado de
Cobertura
Descripción
cobertura Grado de
Cobertura Descripción cobertura Grado de
Cobertura Descripción cobertura
del mismo. módulos de proyectos para que
puedan visualizarse en el calendario
del recurso y actualizar los costes
reales. Puede consultarse de manera
sencilla el estado de aprobación
tanto de los partes de tiempo como
de ausencias.
REQ-GP-GE-7
Control de
imputación de
horas
El sistema debe disponer de
mecanismos de control para imputar en
función de un calendario laboral (p.e.
impedir la imputación en días festivos).
Requerido 3
El sistema dispone de un sistema de
reglas y fórmulas rápidas con las
que se pueden configurar este tipo
de validaciones.
3 Lo cubre el módulo de CATS 3 El sistema puede no permitir imputación de costes en días
o periodos cerrados del calendario.
REQ-GP-GE-8
Control de
imputación de
horas y
ausencias
El sistema debe controlar las
imputaciones de horas en fechas con
ausencias aprobadas.
Requerido 3
Las ausencias aprobadas aparecen
automáticamente en el parte de
tiempos para ese periodo. Además
pueden crearse reglas para este tipo
de validación.
3 Lo cubre el estándar 2
En principio si la ausencia está aprobada y registrada, no
se podría hacer registros durante la ausencia. Habría que
modificar algún parámetro.
REQ-GP-GE-9 Aprobación de
horas
Mecanismo que permita la aprobación
de las horas imputadas por los
empleados y personal externo
Requerido 3
El sistema dispone de un workflow
de aprobación para los partes de
tiempo tanto de personal interno
como externo.
3 Dudas 3 El módulo de "Tiempo y asistencia" tiene un proceso de
validación y aprobación de la asistencia.
REQ-GP-GE-10
Registro de
Hojas de
Gastos
Disponer de un formulario para la carga
de las hojas de gastos, tanto para el
personal interno como el externo, desde
el que se pueda ver el estado de
aprobación del mismo.
Requerido 3
El sistema dispone de un módulo
para la gestión de gastos de viajes
que permite la imputación de los
mismos contra proyectos. Pueden
registrarse los gastos tanto desde la
aplicación como desde una
aplicación móvil. Siempre es posible
la consulta del estado de aprobación
de las hojas de gastos.
3 Existe un formulario para ello. 3 Funcionalidad estándar
REQ-GP-GE-11
Control de
imputación de
gastos
El sistema debe disponer de
mecanismos de control para evitar la
imputación de gastos en fechas que no
se hayan imputado horas.
Requerido 1
El sistema no dispone de este tipo de
validación. Sería necesario un
desarrollo. 2 Es necesario desarrollar un control. 2
Se necesita un desarrollo que variará en función del estado
de aprobación de las horas imputadas y de la diferencia de
tiempo entre que se registran las horas y los gastos.
REQ-GP-GE-12 Aprobación de
gastos
Mecanismo que permita la aprobación
de gastos imputados por los empleados
y personal externo
Requerido 3
Los gastos de viaje tienen
incorporado un proceso de
workflow para su aprobación.
3
A condición que el personal externo se integra
en la estructura organizativa, horarios,
calendarios, etc.
2 Ídem que el punto REQ-GP-GE-11
REQ-GP-GE-13 Alertas
El sistema debe disponer de
mecanismos que alerten de las
solicitudes de ausencias, imputación de
horas y gastos pendientes de aprobar.
Además el sistema deberá alertar sobre
el incumplimiento de las imputaciones
de horas con antelación al cierre
mensual.
Requerido 3
El sistema puede generar alertas o
avisos sobre los gastos, ausencias y
horas pendientes de aprobar. En la
pantalla de gestión del rendimiento
de los proyectos es posible
identificar en tiempo real las horas
no imputadas y los partes de tiempo
pendientes.
3
Las alertas de solicitudes se presentan al
manager aprobador en su portal. La alerta del
incumplimiento de horas anterior al cierre, no
entiendo el significado, quizá pueda ser un
control a definir
2 Se necesita un desarrollo sencillo si se usan las consultas
periódicas por usuario (PILAS de AX)
C Reporting
96
Oracle ERP Cloud SAP S/4 HANA Cloud Microsoft Dynamics AX Cloud
Nº Req. Descripción de
requerimiento Prioridad
Grado de
Cobertura
Descripción
cobertura Grado de
Cobertura Descripción cobertura Grado de
Cobertura Descripción cobertura
REQ-GP-GE-14 Informe de
ausencias
Informe de solicitudes de ausencias de
los empleados, con sus respectivos
estados y extraíble a Excel.
Requerido 3
Con las herramientas de Reporting
de Oracle Cloud es posible definir
de manera sencilla e intuitiva
cualquier tipo de informe como el
mencionado. La salida de los
informes puede ser fácilmente
exportada a hoja de cálculo.
3 Consulta Query, o report estándar 3 Funcionalidad estándar
REQ-GP-GE-15 Informe de
horas
Informe con el detalle de la imputación
de horas a los proyectos, con sus
respectivos estados y extraíble a Excel.
Requerido 3
Con las herramientas de Reporting
de Oracle Cloud es posible definir
de manera sencilla e intuitiva
cualquier tipo de informe como el
mencionado. La salida de los
informes puede ser fácilmente
exportada a hoja de cálculo.
3 Consulta Query, o report estándar 3 Funcionalidad estándar
REQ-GP-GE-16 Informe de
gastos
Informe con el detalle de los gastos por
empleados, con sus respectivos estados
y extraíble a Excel.
Requerido 3
Con las herramientas de Reporting
de Oracle Cloud es posible definir
de manera sencilla e intuitiva
cualquier tipo de informe como el
mencionado. La salida de los
informes puede ser fácilmente
exportada a hoja de cálculo.
3 Consulta Query, o report estándar 3 Funcionalidad estándar
D Integración
REQ-GP-GE-17 Integración
con proyectos
Asignar a los empleados en las tareas o
actividades del plan de trabajo del
proyecto.
Requerido 3
La gestión de recursos de proyectos
permite asignar recursos a los
proyectos/tareas según su
disponibilidad y habilidades.
También es posible la asignación
manual de los mismos.
3
Para poder imputar a un proyecto el empleado
debe haber sido asignado al mismo. Sino no
podrá imputar.
3 Asignación del empleado a la actividad.
REQ-GP-GE-18 Integración
con Compras
Los empleados externos
(subcontratados) están sujetos a un
contrato y su correspondiente pedido de
compra.
Se requiere que la imputación de horas
de dicho personal se transforme
automáticamente en la recepción del
servicio del pedido de compra para
poder asociarla posteriormente a la
factura.
Requerido 1
El tiempo imputado por el personal
subcontratado se transfiere
automáticamente a Project costing
para actualizar los costes del
proyecto. No obstante, la recepción
del pedido de compra de servicios
no se crea automáticamente sino que
hay que registrarla manualmente en
la versión actual del producto.
1
Se tendrá que desarrollar la funcionalidad para
que la creación del pedido contenga todos los
datos deseables. 1
Desde el proyecto se crea un pedido de compra de
servicios a subcontratas, pudiendo ser un proveedor
externo o una empresa del grupo. La compra de servicios
a una empresa del grupo genera una venta en la misma.
La imputación de horas no genera un pedido de compra,
por lo que habría que relacionar la cantidad de horas con
la creación de un pedido de compra desde el proyecto.
REQ-GP-GE-19 Integración
con Nóminas
Se deberá generar un fichero con la
información de las imputaciones de
gastos aprobadas para su posterior pago
en el sistema de nóminas.
Requerido 3
Las hojas de gastos aprobadas se
transfieren automáticamente al
módulo de cuentas a pagar para la
gestión del pago.
3 Esta integración existe, para el pago de gastos
aprobados. 3
Desde el proyecto o desde las consultas de gastos, se
puede visualizar los gastos y se pueden exportar a Excel.
97
b. Requerimientos Técnicos
Oracle ERP Cloud SAP S/4 HANA Cloud Microsoft Dynamics AX Cloud
Descripción de requerimiento Grado de
Cobertura
Descripción
cobertura Grado de
Cobertura Descripción cobertura Grado de
Cobertura Descripción cobertura
A Escalabilidad Escalabilidad para poder cubrir no sólo las primeras iteraciones de construcción, sino las expansiones sucesivas para
poder soportar los requerimientos de información de nuevas áreas. 3 Herramienta totalmente escalable. 3 Herramienta totalmente escalable. 3 Herramienta totalmente escalable.
B Movilidad
Adaptación a distintos dispositivos (móviles, tabletas, etc.) 3
Toda la funcionalidad está
disponible a través de navegador,
enfoque muy válido para Tablet, no
tanto para móviles.
1
Entre las diferentes interfaces de usuario a S/4
Hana está SAP FIORI que ofrece acceso a
ciertas funcionalidades de S/4 en entornos
móviles.
Pero en su mayoría las pantallas de S/4 no
están optimizadas para dispositivos móviles.
1
Dynamics Ax 2012 R3 tiene un Enterprise Portal que
permite trabajar en modo web con determinada
funcionalidad. Es posible, con programación, adaptar
formularios a formato Tableta y Móvil.
Disponibilidad de APPS 2
Disponibles apps específicas para
móviles y Tablet (Mobile Expense
Management).
En la parte de elaboración del
presupuesto con Oracle Planning &
Budgeting Cloud Services, existe la
aplicación de aprobación del
workflow de presupuesto, Oracle
Enterprise Performance
Management.
2 Existen varias apps disponibles. 2 Dynamics Ax 2012 R3 tiene 3 aplicaciones: Gastos,
Autorizaciones, Imputación horas a proyectos.
C Integración con operacionales y otros sistemas
Indique Herramientas de Integración adicionales a la solución con los distintos sistemas operacionales ya existentes.
Sistemas middleware. 2
Oracle Cloud cuenta con soluciones
adicionales en la Nube que permiten
la integración con otros sistemas.
Oracle Cloud Integration permite
realizar integraciones a través de
adaptadores pre construido.
Process Cloud Services permite
definir procesos BPM que incluyan
integración con otros sistemas.
Los costes de licenciamiento son
aparte.
2
SAP cuenta con herramientas adicionales para
las integraciones como:
SAP Gateway
SAP Process Orchestration
SAP HANA Cloud Integration.
Los costes de licenciamiento son aparte.
2
Microsoft AX 2012 posee una capa de middleware la cual
no requiere licenciamiento adicional.
Además permite la utilización de otras herramientas como
Microsoft Integration Services la cual es una plataforma
para construir soluciones ETL para la integración de datos
con otros sistemas. Esta sí requiere licenciamiento
adicional.
Describa las características nativas de integración del ERP con otras aplicaciones (IN-OUT). Y mencione las
herramientas recomendadas para realizar integración con sistemas legados. 2
Oracle ERP Cloud de manera nativa
cuenta con herramientas de entrada
y salida de datos.
ADF Desktop Integration, es un add
in integrada con Excel a través de
plantillas y que permiten la entrada
de datos en el ERP.
File Base Data Import (FBDI) son
ficheros en formato csv los cuales se
importan en el ERP a través de
procesos pre construidos.
ADF Services, son web services pre
construidos para la entrada de datos
en el ERP.
Para la salida de datos se utilizan las
herramientas de Reporting del ERP,
las cuales pueden generar ficheros
2
SAP S/4 Hana cuenta con APIs, Funciones,
Web Services, REST, SOAP pre construido
que permitirán la entrada de datos en el ERP. 2
Microsoft AX 2012 dispone de Web Services, APIs y
plantillas pre construidos para facilitar la entrada de datos.
98
Oracle ERP Cloud SAP S/4 HANA Cloud Microsoft Dynamics AX Cloud
Descripción de requerimiento Grado de
Cobertura
Descripción
cobertura Grado de
Cobertura Descripción cobertura Grado de
Cobertura Descripción cobertura
en diferentes formatos.
D Seguridad
Describa el acuerdo de nivel de servicio (SLA) ofrecido en la solución 3
Las instancias de Oracle Fusion se
instalan en el hardware alta-gama de
Oracle denominado Engineered
Systems (Exalogic para la lógica de
aplicación y Exadata para la base de
datos). Los Engineered Systems
ofrecen escalabilidad inmediata y
alta disponibilidad por defecto dado
que son sistemas con redundancia a
todos los niveles y con la base de
datos Oracle funcionando en RAC.
3
Dependerá del servicio contratado con el
proveedor. Se ha considerado que es igual que
las herramientas en cloud.
3 Dependerá del servicio contratado con el proveedor. Se ha
considerado que es igual que las herramientas en cloud.
¿La solución cuenta con mecanismos de recovery del sistema tras falla? Si la respuesta es afirmativa, por favor explique
éstos mecanismos. 3
Todas las instancias de Oracle
Fusion están replicadas en un centro
de respaldo localizado en otro país
en caso de desastre.
3
Dependerá del servicio contratado con el
proveedor. Se ha considerado que es igual que
las herramientas en cloud. 3
Dependerá del servicio contratado con el proveedor. Se ha
considerado que es igual que las herramientas en cloud.
País donde se alojan los datos (España, UE o resto). Criterio específico para herramientas en cloud. 2 Holanda, Inglaterra, Alemania. 2
Al ser una solución on-premise, el criterio no
aplica. Para no penalizar la solución, se aplica
la misma puntuación que para la misma
solución en cloud.
2
Al ser una solución on-premise, el criterio no aplica. Para
no penalizar la solución, se aplica la misma puntuación
que para la misma solución en cloud.
¿Es propietario de los centros de datos? 3 Si 3
Al ser una solución on-premise, el criterio no
aplica. Para no penalizar la solución, se aplica
la misma puntuación que para la misma
solución en cloud.
3
Al ser una solución on-premise, el criterio no aplica. Para
no penalizar la solución, se aplica la misma puntuación
que para la misma solución en cloud.
E Administración
Herramientas para monitorización de las plataforma 3
Cada cliente Cloud tiene acceso a su
propio portal informativo (Cloud UI
Portal), donde se le informa sobre
incidencias, posibles paradas del
sistema, y se le proporciona
información y gráficas sobre la
disponibilidad de su entorno,
accesos y demás.
3
La solución cuenta con herramientas de
monitorización desde el punto de vista técnico
de la plataforma Hana sobre la que se ha
desarrollado.
3 Si, la herramienta Ms Dynamics Lifecycle Services
(LCS) incorpora la telemetría de la solución.
El sistema requiere de un recurso exclusivo para la administración del sistema tanto en infraestructura tecnológica
como en administración de la aplicación. 3
Siendo una solución en cloud, no se
necesitan recursos exclusivos para la
administración del sistema,
simplificando su gestión y
eliminando el coste asociado.
0
Al ser una solución on-premise, requerirá un
recurso exclusivo y cualificado para la
administración del sistema. 0
Al ser una solución on-premise, requerirá un recurso
exclusivo y cualificado para la administración del sistema.
99
c. Requerimientos Operativos
Oracle ERP Cloud SAP S/4 HANA Cloud Microsoft Dynamics AX Cloud
Descripción de requerimiento Grado de
Cobertura
Descripción
cobertura Grado de
Cobertura Descripción cobertura Grado de
Cobertura Descripción cobertura
A Estrategia de evolución de la herramienta
¿Cuál es la política de actualización de versión de la solución ofertada? 3
Oracle no sigue la política de
actualización de todas las instancias
de forma simultánea si no que
planifica las actualizaciones cliente
por cliente – acordando el mejor
momento para cada uno.
2 Se liberan FPS – Featured Support Package
periódicamente. 2
El ciclo de vida de soporte técnico de Microsoft presenta
plazos de soporte técnico claro y previsible para la
solución, brindándole tranquilidad para evolucionar según
necesite. Tiene garantizado el soporte técnico de la
versión AX 2012 durante 10 años.
¿Existe flexibilidad para actualizar la versión? 3
Se ofrece al cliente una ventana
amplia de tiempo para asegurar que
estas actividades se realizan en el
momento más adecuado.
3 El cliente decide el momento de actualizarlos
en su sistema. 3
Las actualizaciones de la aplicación serán gestionadas por
el cliente
Indique cuál es el road map de las actualizaciones de la solución que usted ofrece y el road map de las futuras versiones
del ERP. 3
Hay dos tipos de actualizaciones del
producto:
- Upgrades: hay aproximadamente 2
upgrades anuales.
- Updates: son mensuales y se
realizan en entornos de test y
producción en días diferentes y se
hacen para todos los clientes a la
vez.
2
El road map abarca las tres siguientes líneas:
1. Las recientes innovaciones para nuestras
soluciones que se han lanzado en las últimas
semanas o meses y ya se pueden comprar.
2. Innovaciones previstas para nuestras
soluciones que se espera que sea lanzado en el
corto plazo o mediano plazo.
3. Orientación futura ofrece una perspectiva a
largo plazo sobre los planes de desarrollo de
alto nivel para las innovaciones para nuestras
soluciones, inspirada en sus requerimientos.
2
Soporte estándar hasta octubre de 2021 con
actualizaciones bi-anuales desde el punto de vista
funcional y de plataforma, así como actualizaciones
legislativas en función de los requerimientos
gubernamentales (oficiales).
B Capacidad de personalización/adaptación
¿La solución permite la exportación de datos a diferentes formatos? 3 Disponible en la herramienta. 3 Disponible en la herramienta. 3 Disponible en la herramienta.
¿La solución permite la importación de los datos desde diferentes formatos? 3 Disponible en la herramienta. 2 Disponible en la herramienta mediante un
pequeño desarrollo. 3 Disponible en la herramienta.
¿La solución ofrece la posibilidad de mantener conversaciones online mediante herramientas colaborativas? 3
Dispone de una herramienta
colaborativa para mantener
conversaciones entre los diferentes
usuarios, con la posibilidad de
adjuntar documentos (facturas,
cobros, etc.).
0 No disponible 0 No disponible
¿Cuál es el lenguaje de desarrollo de la herramienta? Y Con que otros lenguaje se pueden desarrollar las
personalizaciones 3
Utilización de lenguajes de
programación estándares. 2 Lenguaje de programación propio. 3 Utilización de lenguajes de programación estándares.
La solución posee facilidad para programar tareas a ejecutar de forma automática. Notificación de reportes periódicos,
concatenar tareas de cierre. 3
Sí, es posible. Los entornos de
Oracle ERP Cloud incluyen un
planificador de tareas denominado
Enterprise Scheduler.
3
La planificación de tareas como por ejemplo el
proceso de cierre mensual dispone de
utilidades que posibilitan la planificación y
ejecución automática de dichas tareas y
procesos. La solución permite en cualquier
caso el lanzamiento de procesos en fondo,
informes o tratamientos masivos.
3
En Dynamics AX tenemos disponible la funcionalidad
del procesamiento por lotes lo que permite la
programación periódica de tareas, procesos y también
informes.
100
Oracle ERP Cloud SAP S/4 HANA Cloud Microsoft Dynamics AX Cloud
Descripción de requerimiento Grado de
Cobertura
Descripción
cobertura Grado de
Cobertura Descripción cobertura Grado de
Cobertura Descripción cobertura
C Workflows
Permitir definir workflows de autorización y estrategias de aprobación para distintos procesos de la organización
como compras, creación de datos maestros y aprobación de proveedores. 3
La herramienta permite la
personalización de workflows de
aprobación. 3
La herramienta permite la personalización de
workflows de aprobación. 3
La herramienta permite la personalización de workflows
de aprobación.
D Trazabilidad
El sistema permite tener completa trazabilidad en movimientos correspondientes a transacciones de
facturas/cobros/pagos/compras/etc. trazabilidad desde el movimiento contable al documento origen y desde el saldo
hasta el movimiento contable. También el sistema permite tener trazabilidad en las correcciones/anulaciones de
movimientos contables.
Esta trazabilidad se debe permitir en forma bi-direccional
3
La herramienta está completamente
integrada. Se mantiene trazabilidad
en las distintas áreas y módulos.
2
La herramienta es multiplataforma (Ariba,
SAP S/4, BPC). Es necesario en algunos casos
cambiar de herramienta para seguir la
trazabilidad de la información no estando toda
disponible desde un único punto.
3 La herramienta está completamente integrada. Se
mantiene trazabilidad en las distintas áreas y módulos.
E Reporting
Indique si la herramienta permite que el usuario pueda realizar sus reporte de forma estándar en el ERP 3
La herramienta permite que el
usuario pueda realizar sus propios
informes.
0 No disponible 3 La herramienta permite que el usuario pueda realizar sus
propios informes.
Describa particularmente si posee alguna herramienta BI y si está incluida dentro del licenciamiento 3 Herramienta disponible y dentro del
licenciamiento. 0 No disponible 3 Herramienta disponible y dentro del licenciamiento.
F Usabilidad
La herramienta posee un “Look & Feel” atractivo y vanguardista 2 Criterio propio. 1 Criterio propio. 2 Criterio propio.
La navegación es intuitiva 2 Criterio propio. 1 Criterio propio. 2 Criterio propio.
101
2. Evaluación: Eje Económico
Oracle ERP Cloud SAP S/4 HANA Cloud Microsoft Dynamics AX Cloud
Descripción de requerimiento Grado de
Cobertura
Descripción
cobertura Grado de
Cobertura Descripción cobertura Grado de
Cobertura Descripción cobertura
A Coste agregado de la herramienta a 6 años
Indique cuál es el coste agregado de la solución a 6 años. 3 A partir del estudio realizado en la
elaboración de la lista corta. 0
A partir del estudio realizado en la elaboración
de la lista corta. 3
A partir del estudio realizado en la elaboración de la lista
corta.
3. Evaluación: Eje Referencias
Oracle ERP Cloud SAP S/4 HANA Cloud Microsoft Dynamics AX Cloud
Descripción de requerimiento Grado de
Cobertura
Descripción
cobertura Grado de
Cobertura Descripción cobertura Grado de
Cobertura Descripción cobertura
A Coste agregado de la herramienta a 6 años
¿Cuántas implantaciones de la solución ofertada tienen en el mercado Global dentro del sector bancario? 2
54 clientes (HSBC es la referencia
más grande, con 4.000 usuarios
incluyendo los módulos de
Finanzas, Compras, Proyectos y
Planificación y Presupuestación)
3
Existen más de 3.900 clientes en el sector
bancario que utilizan las soluciones de SAP
entre las que se encontraría SAP ERP en sus
diferentes versiones.
2 Tenemos más de 80 instalaciones en el Sector Bancario a
nivel mundial
¿Cuántas implantaciones de la solución ofertada tienen en el mercado Español dentro del sector bancario? 2
Teniendo en cuenta la información
recogida en la elaboración de la lista
corta de ERPs, contabilizamos un
total de 5 presencias del fabricante
en el sector bancario.
3
Teniendo en cuenta la información recogida en
la elaboración de la lista corta de ERPs,
contabilizamos un total de 9 presencias del
fabricante en el sector bancario.
2
Teniendo en cuenta la información recogida en la
elaboración de la lista corta de ERPs, contabilizamos un
total de 4 presencias del fabricante en el sector bancario.