Selección de herramienta ERP. Aplicación en el sector bancario …bibing.us.es/proyectos/abreproy/70784/fichero/29558675H+TFM+Selección... · vii Resumen El presente proyecto,

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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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)


E

54

Gráfico 2 Puntuación Eje Funcional (II)


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


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


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


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


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


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


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


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)


Gráfico 6 Puntuación General (II)


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




Grado de


cobertura Grado de



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



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




Grado de


cobertura Grado de



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


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


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




Grado de


cobertura Grado de



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




Grado de


cobertura Grado de



REQ-GP-CG-30

Integración

con Cuentas a

Pagar


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


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





3


cuentas a cobrar tiene su reflejo en la



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





3


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


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




Grado de

Cobertura

Descripción

cobertura Grado de



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




Grado de

Cobertura

Descripción

cobertura Grado de



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




Grado de

Cobertura

Descripción

cobertura Grado de



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



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






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



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






Requerido 3

Se pueden generar informes

mediante la herramienta de BI

Transaccional, BI Publisher,… con

asistentes para usuarios


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


general.

Requerido 3

Cualquier operación de cuentas a

pagar con reflejo automático genera

apuntes a contabilidad general

3


cuentas a pagar tiene su reflejo en la

contabilidad general.


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




Grado de

Cobertura

Descripción

cobertura Grado de



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


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


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


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


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





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



españolas como formato de pago 3



otras, la norma CSB34. 3 Genera ficheros según normativa SEPA

72

iii. Cuentas por Cobrar




Grado de

Cobertura

Descripción

cobertura Grado de



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




Grado de

Cobertura

Descripción

cobertura Grado de



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











74




Grado de

Cobertura

Descripción

cobertura Grado de



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




módulo de Cuentas a Cobrar


transacciones entradas 3





REQ-GP-CP-21

Construcción

de reporte por

usuarios






Requerido 3






como de reports painter 3





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


general.

Requerido 3

Cualquier operación de cuentas a

cobrar con reflejo automático genera

apuntes a contabilidad general 3


cuentas a cobrar tiene su reflejo en la



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


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


sistemas externos.

Requerido 3





o web services





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



españolas como formato de pago.





o web services

3



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




Grado de

Cobertura

Descripción

cobertura Grado de



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




Grado de

Cobertura

Descripción

cobertura Grado de



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




de Activos Fijos









acceso.

77




Grado de

Cobertura

Descripción

cobertura Grado de



REQ-GP-AF-17 Informes de

Activos Fijos




módulo de Activos Fijos


transacciones entradas 3





REQ-GP-AF-18

Construcción

de reporte por

usuarios






Requerido 3






como de reports painter 3





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


activos fijos tiene su reflejo en la contabilidad

general.


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.



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


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


todo modular.


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.


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




Grado de

Cobertura

Descripción

cobertura Grado de



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





o web services





v. Gestión de Proyectos




Grado de

Cobertura

Descripción

cobertura Grado de



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


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




Grado de

Cobertura

Descripción

cobertura Grado de



coste hora (tarifa) del empleado. tarifa categoría o empleado quien es el encargado de

cada actividad

REQ-GP-GP-8 Calendarios


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




Grado de

Cobertura

Descripción

cobertura Grado de



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


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


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


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




Grado de

Cobertura

Descripción

cobertura Grado de



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



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



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



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


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


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



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



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


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




Grado de

Cobertura

Descripción

cobertura Grado de



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





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


vi. Presupuestación




Grado de

Cobertura

Descripción

cobertura Grado de



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



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




Grado de

Cobertura

Descripción

cobertura Grado de



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


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


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


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




Grado de

Cobertura

Descripción

cobertura Grado de



es aprobado, etc… (Elaboración,

Pendiente Aprobación, Denegado,

Aprobado, etc.)

está incluida en la herramienta de


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



versionados, estados y aprobaciones

está incluida en la herramienta de


3



a partir de otra


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


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



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


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


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


el requisito 3


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


el requisito 3



85




Grado de

Cobertura

Descripción

cobertura Grado de



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


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


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


el requisito 3



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).


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


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






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




Grado de

Cobertura

Descripción

cobertura Grado de



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




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






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









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









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


Excel de apuntes contables

87

vii. Compras




Grado de

Cobertura

Descripción

cobertura Grado de



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.


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.


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.


88




Grado de

Cobertura

Descripción

cobertura Grado de



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)


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




Grado de

Cobertura

Descripción

cobertura Grado de



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



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)


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



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



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




Grado de

Cobertura

Descripción

cobertura Grado de



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


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


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


91




Grado de

Cobertura

Descripción

cobertura Grado de



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.


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


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.


92




Grado de

Cobertura

Descripción

cobertura Grado de



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




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





93




Grado de

Cobertura

Descripción

cobertura Grado de



de Compras sencilla. acceso.

REQ-GP-CO-40 Informes de

Compras




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




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






Requerido 3





3




sencilla y exportable a Excel.

3





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.



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




Grado de

Cobertura

Descripción

cobertura Grado de



A Maestros

REQ-GP-GE-1 Categorías


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


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


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)


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




Grado de

Cobertura

Descripción

cobertura Grado de



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.


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


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.


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


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




Grado de

Cobertura

Descripción

cobertura Grado de



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


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










gastos

Informe con el detalle de los gastos por

empleados, con sus respectivos estados

y extraíble a Excel.

Requerido 3









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.


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.


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


Descripción de requerimiento Grado de

Cobertura

Descripción

cobertura Grado de



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



Cobertura

Descripción

cobertura Grado de



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



Cobertura

Descripción

cobertura Grado de



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



Cobertura

Descripción

cobertura Grado de



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



Cobertura

Descripción

cobertura Grado de



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



Cobertura

Descripción

cobertura Grado de



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.

Documents

Selección de herramienta ERP. Aplicación en el sector bancario …bibing.us.es/proyectos/abreproy/70784/fichero/29558675H+TFM+Selección... · vii Resumen El presente proyecto,