ADQUISICION DE APLICACIÓN TECNOLOGICA PARA EL ...

1

ADQUISICION DE APLICACIÓN TECNOLOGICA PARA EL FORTALECIMIENTO DE LA ADMINISTRACIÓN Y CONTROL DE LOS BIENES DE USO,BIENES DE CONSUMO,CUENTAS POR PAGAR Y CUENTAS POR COBRAR DE LAS INSTITUCIONES DEL ESTADO DOMINICANO COMO PARTE DEL SISTEMA INTEGRADO DE ADMINISTRACIÓN FINANCIERA DEL ESTADO(SIAFE) Y

CONSULTORÍA DE SERVICIOS PROFESIONALES

LicitaciónPúblicaNacional PAFI-CCC-LPN-2018-0003

Santo Domingo, Republica Dominicana, 13 de Septiembre de 2018

2

Santo Domingo, 13 de Septiembre de 2018

ATENCIÓN: COMITÉ DE COMPRAS Y CONTRATACIONES

REFERENCIA: PAFI-CCC-LPN-2018-0003

DIRECCION: Avenida Mexico No. 45, Gazcue

TELEFONOS: 809-687-5131 ext.2436

Estimados representantes del Ministerio de Hacienda de la Republica Dominicana.

GBM Dominicana, agradece la oportunidad de presentar nuestra propuesta de valor para la implantación de

la soluciones SAP basado en los requerimientos presentados en el Pliego de Condiciones Especificas de fecha

Julio 2018. Reiterando nuestro compromiso de socios estratégicos de negocio en Infraestructura y servicios

profesionales en este proceso de trasformación de negocio y crecimiento.

Esta propuesta incluye:

▪ Enfoque de implementación de la solución basados exclusivamente en las necesidades de su Empresa;

siguiendo para ello, los pasos de nuestra metodología de servicio comenzando por la evaluación de

procesos existentes, utilización de las mejores prácticas de negocios contenidas en SAP para su Industria,

integración natural con los procesos contables, el desarrollo de pruebas unitarias e integrales, conversión

de datos y el adiestramiento a usuarios claves, a través de nuestra división de consultoría GBM

CONSULTING.

▪ Adicionalmente GBM presenta una solución que contempla las capacidades requeridas para el sistema

SAP como servicio, que acompañada de los servicios gestionados de GBM permitirá al Ministerio de

Hacienda de la Republica Dominicana la tercerización de su infraestructura.

▪ GBM complementa esta oferta poniendo a disposición nuestro centro de competencias operado por

nuestra división de Consultoría GBM CONSULTING.

Esta propuesta se caracteriza por ser una ventaja competitiva, gracias a cuatro factores primordiales:

1. El Software SAP que lleva 40 años en el mercado de ERP, demostrado por gracias a los modelos de

referencias que SAP ha desarrollado a lo largo de sus años de experiencia, convierten a este software

la solución más idónea y con la mejor funcionalidad integrada del mercado. permitiendo a más de

248,500 clientes alrededor del mundo operar de manera rentable, adaptarse continuamente y crecer

de forma sostenible.

3

2. Servicios de Consultoría por GBM Dominicana, que cuenta con más de 18 de años de experiencia en

SAP y una amplia practica de industria enfocada en los negocios del sector público, asegurando una

implementación con muy bajo nivel de riesgo y dentro de las metas corporativas de tiempo, calidad y

costos trazados por Ministerio de Hacienda de la Republica Dominicana.

3. GBM como socio tecnológico que cuenta con una historia conjunta ininterrumpida con IBM de servicio

y asesoramiento en infraestructura más de 60 años apoyando el crecimiento de las diferentes

organizaciones en República Dominicana. Actualmente, GBM cuenta con más de 1000 empleados y

tiene presencia en Costa Rica, Panamá, Nicaragua, Honduras, El Salvador, Guatemala, República

Dominicana y Miami. Algunas de las marcas más importantes que representa son: IBM, SAP, Lenovo,

Cognos y Cisco Systems entre muchas otras. Hoy GBM cuenta con más de 2200 clientes en toda la

región que avalan el compromiso de brindar soluciones de calidad mundial para un negocio cada vez

más demandante.

4. GBM Smart Capacity tiene más de cinco años de estar brindando directamente servicios de Data

Center en la región, en sus distintas modalidades (renta de espacio, virtualización) y meses continuos

de cumplimiento al 100% en sus acuerdos de niveles de servicio.

Confiamos en que esta propuesta cumpla con sus expectativas y estamos a su disposición para responder

cualquier consulta que pueda surgir sobre la misma.

Sin nada más a que hacer referencia, quedamos de ustedes.

Atentamente,

Gustavo Pascal

Gerente General

GBM Republica Dominicana

4

TABLA DE CONTENIDO

TABLA DE CONTENIDO ................................................................................................ 4

1. INFORMACION DEL PROVEEDOR DE SERVICIOS ..................................................... 14

1.1 Información de Contacto ..........................................................................................14

1.2 INFORMACION SOBRE LA EMPRESA .........................................................................14

1.3 GBM CONSULTING ....................................................................................................16

2. INFORMACION DE SAP .......................................................................................... 25 2.1 Historia de SAP .........................................................................................................25

2.2 SAP Hoy .....................................................................................................................26

2.3 Descripción general de soluciones SAP ....................................................................31

2.4 Aplicaciones SAP – SAP Business Suite .....................................................................36

2.5 SAP S/4HANA ............................................................................................................38

2.6 Analíticas ...................................................................................................................39

3. REQUERIMIENTOS FUNCIONALES .......................................................................... 41

3.1 Objetivo del Proyecto ...............................................................................................41

3.2 Alcance Organizacional del Proyecto .......................................................................41

3.2.1 A nivel institucional: .................................................................................................41

3.2.2 Alcance geografico (Pais y sus distintas dependencias geográficas) .......................42

3.3 Alcance Funcional del Proyecto ................................................................................42

3.3.1 Instituciones del Estado Dominicano .......................................................................42

3.3.1.1 Mandante ........................................................................................................43

3.3.1.2 Sociedad (Cada Institución) .............................................................................43

3.3.1.3 Plan de Cuentas ...............................................................................................44

3.3.1.4 Crecimiento de instituciones a través de parámetros ...................................44

3.3.1.4.1 Definicion de una institución...........................................................................44

3.3.1.4.2 Homlogación de instituciones con estructuras existentes .............................45

3.3.1.5 Consolidacion de información de las instituciones .........................................46

3.3.2 Cierre de una institución ..........................................................................................47

3.3.2.1.1 Cierre de dia ....................................................................................................48

3.3.2.1.2 Cierre de Mes ..................................................................................................48

3.3.2.1.3 Abrir y cerrar períodos contables ....................................................................48

3.3.2.1.4 Crear informes externos. .................................................................................48

3.3.2.2 Cierre de Ejercicio ............................................................................................49

5

3.3.2.2.1 Ejercicio ...........................................................................................................50

3.3.2.2.2 Periodos especiales .........................................................................................50

3.3.2.2.3 Determinacion de períodos al momento de la contabilización. .....................50

3.3.2.2.4 Apertura y cierre de periodos contables .........................................................51

3.3.2.2.5 Variantes de períodos contables .....................................................................51

3.3.2.2.6 Clase de cuenta ...............................................................................................51

3.3.3 Catalogo de bienes ampliados ..................................................................................52

3.3.3.1 Bienes de Uso ..................................................................................................52

3.3.4 Contabilidad automática ..........................................................................................54

3.3.4.1 Codigo de transacción .....................................................................................54

3.3.4.2 Parametrización Contable y Generacion Automatica .....................................54

3.3.4.2.1 Bienes de Consumo .........................................................................................54

3.3.4.2.2 Bienes de Uso ..................................................................................................55

3.3.4.3 Proyección de la Contabilidad Automatica .....................................................56

3.3.4.4 Destino contable .............................................................................................57

3.3.4.5 Reporte de Balance por institución y consolidado..........................................57

3.3.5 Trazabilidad de Datos ...............................................................................................58

3.3.5.1 Log de resultados de trazabilidad ...................................................................59

3.3.6 Migración de Datos ...................................................................................................60

3.3.7 Interfaces para consolidar otros sistemas ................................................................61

3.3.8 Cumplimiento Regulatorio .......................................................................................62

3.3.8.1 Comprobantes fiscales ....................................................................................63

3.3.8.1.1 Reporte 606 .....................................................................................................65

3.3.8.1.2 Reporte 607 .....................................................................................................66

3.3.8.1.3 Reporte 608 .....................................................................................................66

3.3.8.1.4 Reporte 609 .....................................................................................................66

3.3.9 Documentos e Imagines ...........................................................................................66

3.3.10 Calendario del Sistema ...........................................................................................69

3.3.10.1.1 Calendario Intervalo de cuentas (Operaciones-Transacciones) ..................70

3.3.10.1.2 Calendario de Operaciones-Transacciones por usuario ..............................70

3.3.10.2 Calendario Festivos .........................................................................................70

3.3.11 Accesos ...................................................................................................................71

3.3.11.1 Administración de usuario y rol de Application Server ABAP .........................72

3.3.11.2 Concepto de Autorización ABAP .....................................................................72

3.3.11.3 Configuración de administración de usuario y rol ..........................................73

3.3.12 Consultas y Reportes ..............................................................................................74

3.3.13 Analiticas .................................................................................................................75

3.3.13.1 S / 4HANA Embedded Analytics y vistas de CDS .............................................76

3.3.14 Flujos de Procesos ..................................................................................................78

3.3.14.1 SAP Business Workflow para S/4HANA ...........................................................78

3.3.14.2 El objetivo ........................................................................................................79

3.3.14.3 Soporte para el propietario del proceso de flujo de trabajo ..........................80

6

3.3.14.4 Notificaciones del Flujo de Trabajo .................................................................81

3.3.14.5 Worflow Analytics ...........................................................................................82

3.3.15 Almacenes ...............................................................................................................82

3.3.16 Historial de Transacciones ......................................................................................84

3.3.16.1 Cabecera de Documento .................................................................................84

3.3.17 Multi Monedas........................................................................................................85

3.3.17.1 Monedas Paralelas ..........................................................................................86

3.3.18 Anulación y reverso de transacciones ....................................................................86

3.3.19 Bienes de Consumo (Inventario) ............................................................................87

3.3.19.1 Registro de Bienes de Consumo (Datos Maestros) .........................................89

3.3.19.1.1 Codigo de barra del fabricante (Codigo EAN) ..............................................91

3.3.19.2 Transacciones ..................................................................................................92

3.3.19.2.1 Movimiento de bienes .................................................................................92

3.3.19.2.2 Entrada de almacén – Recepción Total .......................................................93

3.3.19.2.3 Entrada de almacén – Recepción Parcial .....................................................94

3.3.19.2.4 Entrada de almacén – Recepción Productos Faltantes ...............................94

3.3.19.2.5 Entrada de almacén – Contabilización Automatica .....................................95

3.3.19.2.6 Salida de almacen por requisición ...............................................................96

3.3.19.2.6.1 Solicitudes manuales................................................................................96

3.3.19.2.6.2 Solicitudes automaticas ...........................................................................97

3.3.19.2.6.3 Entregas de mercancía .............................................................................97

3.3.19.2.6.4 Contabilizacion automática......................................................................97

3.3.19.2.7 Salida de almacen por deterioro de mercancía ...........................................99

3.3.19.2.7.1 Solictudes de Salida de almacen por deterioro de mercancía ................99

3.3.19.2.7.2 Disminucion de inventario .......................................................................99

3.3.19.2.8 Salida de almacen por prestamos entre instituciones ............................. 100

3.3.19.2.9 Salida de almacen por prestamos entre secciones institucionales .......... 101

3.3.19.2.10 Salida de almacen por Devolución en Compras ....................................... 102

3.3.19.2.10.1 Contabilizacion de Salida de almacen por Devolución en Compras ..... 104

3.3.19.2.11 Cambio de tipo de inventario ................................................................... 104

3.3.19.2.12 Traslado entre instituciones ..................................................................... 105

3.3.19.2.13 Traslados entre secciones instituciones ................................................... 106

3.3.19.2.14 Conversión de Inventario.......................................................................... 107

3.3.19.2.15 Generacion de ordenes de compras planificadas .................................... 108

3.3.19.3 Bienes de Consumo – Reportes .................................................................... 109

3.3.19.4 Bienes de Consumo - Interfaces ................................................................... 110

3.3.19.5 Bienes de consumo – Otros puntos de atención ......................................... 111

3.3.20 Cuentas por Pagar (Gestión de Acreedores) ....................................................... 111

3.3.20.1 Datos Basicos ................................................................................................ 112

3.3.20.2 Tipos de Cuentas por Pagar .......................................................................... 113

3.3.20.3 Transacciones en Cuentas por Pagar ........................................................... 114

3.3.20.3.1 Nota de Debito .......................................................................................... 114

7

3.3.20.3.2 Nota de Credito ........................................................................................ 115

3.3.20.3.3 Devolución de Fondos .............................................................................. 115

3.3.20.3.4 Baja en cuentas ......................................................................................... 116

3.3.20.3.5 Pago con captación directa ....................................................................... 116

3.3.20.3.6 Registro de Cuentas por Cobrar ............................................................... 117

3.3.20.4 Cuentas por Pagar – Reportes ...................................................................... 117

3.3.20.5 Cuentas por Pagar – Interfaces .................................................................... 118

3.3.21 Cuentas por Cobrar .............................................................................................. 119

3.3.21.1 Datos Basicos – Cuentas por Cobrar ............................................................ 121

3.3.21.1.1 Motivos de Cuentas por Cobrar ................................................................ 121

3.3.21.1.2 Fecha de Imputación-Fecha de Registro-Valor por Cobrar ...................... 122

3.3.21.1.3 Descuentos ............................................................................................... 123

3.3.21.1.4 Mora ......................................................................................................... 124

3.3.21.1.5 Intereses Indenizatorios ........................................................................... 125

3.3.21.1.6 Fecha compromiso de cobro .................................................................... 125

3.3.21.1.7 Motivos de Cobro ..................................................................................... 126

3.3.21.1.8 Condiciones de Cobro ............................................................................... 126

3.3.21.1.9 Clasificación del Tiempo ........................................................................... 127

3.3.21.1.10 Gestión y documentación de cobros ........................................................ 128

3.3.21.2 Transacciones ............................................................................................... 128

3.3.21.2.1 Nota de Debito .......................................................................................... 128

3.3.21.2.1.1 Motivos ................................................................................................. 129

3.3.21.2.2 Nota de Credito ........................................................................................ 129

3.3.21.2.3 Registro de Ingreso ................................................................................... 130

3.3.21.2.4 Cambio de Tipo de Cuenta por Cobrar ..................................................... 132

3.3.21.2.5 Baja en Cuentas ........................................................................................ 132

3.3.21.2.6 Registro de Deterioro ............................................................................... 133

3.3.21.2.7 Pago con captación directa ....................................................................... 134

3.3.21.3 Cuentas por Cobrar – Reportes y Consultas ................................................. 134

3.3.21.4 Cuentas por Cobrar – Interfaces .................................................................. 135

3.3.22 Gestión de Bienes Muebles-Inmuebles (Activos Fijos) ........................................ 136

3.3.22.1 Estructuracion de los Bienes de Uso (Activos Fijos) ..................................... 137

3.3.22.2 Creación Automatica de un bien .................................................................. 139

3.3.22.2.1 Creacion automatica mediante integración ............................................. 139

3.3.22.3 Datos maestros generales de los bienes ...................................................... 140

3.3.22.4 Clasificacion de los bienes ............................................................................ 143

3.3.22.5 Identificacion única del bien ........................................................................ 145

3.3.22.6 Etiqueta del bien (Codigo de Barra) ............................................................. 146

3.3.22.7 Datos de los bienes – (Control de estructuración de pantallas) .................. 147

3.3.22.8 Recepcion en Almacén/Aceptacion del bien ................................................ 152

3.3.22.8.1 Solicitud de Compras ................................................................................ 152

3.3.22.8.2 Recepción en Almacen.............................................................................. 152

8

3.3.22.9 Registro de deterioro ................................................................................... 153

3.3.22.10 Registro de Revaluacion ........................................................................... 153

3.3.22.11 Registro de Capitalización o Modificaciones ............................................ 153

3.3.22.12 Registro de Recuperación ......................................................................... 154

3.3.22.13 Calculo de Depreciación y Amortización .................................................. 154

3.3.22.14 Afectacion en uso (prestamos) internos y Traslados internos ................. 159

3.3.22.18 Solicitud de Inspección ............................................................................. 163

3.3.22.19 Solicitud de asignación de bienes disponibles.......................................... 164

3.3.22.20 Solicitud de cambio de parámetros .......................................................... 164

3.3.22.21 Reparaciones y Registro de Mantenimiento Preventivo y Correctivo ..... 164

3.3.22.21.1 Mantenimiento Preventivo ...................................................................... 165

3.3.22.21.1.1 Hoja de Ruta para Equipo ..................................................................... 166

3.3.22.21.1.2 Hoja de Ruta para Ubicación Tecnica ................................................... 166

3.3.22.21.2 Ordenes de Mantenimiento ..................................................................... 167

3.3.22.21.2.1 Clases de Ordenes de Mantenimiento ................................................. 167

3.3.22.22 Arrendamiento y Alquileres (Administración de Bienes Inmuebles) ....... 170

3.3.22.22.1 Arrendamiento ......................................................................................... 171

3.3.22.22.2 Contabilidad de los Arrendamientos ........................................................ 171

3.3.22.22.3 Revisiones de Contratos de Arrendamiento ............................................ 172

3.3.22.23 Solicitud de actualización de avaluo ......................................................... 172

3.3.22.23.1 Registro de Inspecciones e Irregularidades – (Avisos de Inspeccion) ...... 173

3.3.22.24 Registro de Datos de Subasta ................................................................... 174

3.3.22.25 Registro de venta de Inmueble ................................................................. 175

3.3.22.26 Objetos de autorización (Seguridad) ........................................................ 176

4. REQUERIMIENTOS NO FUNCIONALES LOTE # 1 .................................................... 181

4.1 Objetivos específicos ............................................................................................. 181

4.1.1 Inteligencia de Negocios ........................................................................................ 181

4.1.2 Flujos de Procesos ................................................................................................. 182

4.1.2.1 SAP Business Workflow para S/4HANA ........................................................ 182

4.1.2.2 El objetivo ..................................................................................................... 183

4.1.2.3 Soporte para el propietario del proceso de flujo de trabajo ....................... 184

4.1.2.4 Notificaciones del Flujo de Trabajo .............................................................. 185

4.1.2.5 Worflow Analytics ........................................................................................ 185

4.1.3 Portal de Autoservicio ........................................................................................... 186

4.1.3.1 Principales características ............................................................................ 186

4.1.3.2 SAP Enterprise Portal en SAP NetWeaver 7.5 Integración SAP Fiori ........... 187

4.1.3.3 SAP Fiori Launchpad on Portal ..................................................................... 187

4.1.4 Documentos e Imagines ........................................................................................ 188

4.1.5 Geolocalización ...................................................................................................... 190

4.1.6 Dispositivos inteligentes ........................................................................................ 190

9

4.1.7 Herramienta de migración de datos ...................................................................... 191

4.1.8 Plan de Proyecto .................................................................................................... 198

5. Arquitectura del Sistema .................................................................................... 199

5.1 Esquema de integración basados en estandares abiertos .................................... 199

5.2 Arquitectura basada en componentes .................................................................. 201

5.3 Codigo fuente ........................................................................................................ 201

5.4 Modulos integrados ............................................................................................... 201

5.5 Soluciones WEB ..................................................................................................... 202

5.6 Multicapas ............................................................................................................. 202

5.7 Asincrona ............................................................................................................... 204

5.8 Multithread ............................................................................................................ 204

5.9 Arquitectura de la solución ................................................................................... 205

5.9.1 Sistema Operativo ................................................................................................. 205

5.9.1.1 SUSE® Linux Enterprise Server ..................................................................... 206

5.9.1.1.1 Componentes del Software .......................................................................... 207

5.9.1.1.2 SUSE Linux Enterprise High Availability Extension ....................................... 207

5.9.1.1.3 Configuración simplificada de replicación del sistema SAP HANA .............. 208

5.9.2 Base de Datos ........................................................................................................ 208

5.9.2.1 Interfaces estándar de la Base de Datos ...................................................... 208

5.9.2.2 Aprovisionamiento de datos ........................................................................ 208

5.9.2.3 Recuperación de datos ................................................................................. 208

5.9.2.4 Landscape del Sistema Técnico para S/4HANA ............................................ 209

5.9.2.5 La base de datos del sistema ........................................................................ 209

5.9.2.6 Arquitectura del servidor ............................................................................. 209

5.9.2.7 Conexiones desde clientes de bases de datos y clientes web a SAP HANA . 210

5.10 Servidor de Aplicación ........................................................................................... 213

5.11 Lenguaje de programación .................................................................................... 214

5.11.1 ABAP and SAP NetWeaver ................................................................................... 214

5.11.2 Alcance y Áreas de Aplicación de ABAP............................................................... 215

5.12 Realizacion de Cambios ......................................................................................... 216

5.13 Arquitectura de la solución ................................................................................... 218

5.14 Soporte de la solución ........................................................................................... 218

5.14.1 Alcance del soporte SAP Enterprise .................................................................... 218

5.14.2 Soporte paquetes de mejora y otras actualizaciones de software de SAP ......... 219

5.14.3 Acuerdo global de nivel de manejo y servicio de incidentes (SLA) ..................... 220

5.14.3.1 Acuerdo de nivel de servicio (SLA´s) para tiempos de respuesta iniciales .. 221

5.14.3.2 Acuerdo de nivel de servicio para el tiempo de respuesta de la acción ...... 221

5.14.3.3 Cadena de Valor GBM a traves de su servicio de Enterprise Support ......... 222

5.14.3.4 Early Watch Alert .......................................................................................... 223

5.14.3.4.1 Objetivos de EWA ..................................................................................... 223

10

5.14.3.4.2 Monitorización de EWA ............................................................................ 224

5.14.3.5 CQC - SAP Business Process Performance Optimization .............................. 224

5.14.3.6 Flujograma de proceso ................................................................................. 225

5.14.3.6.1 Flujograma de proceso – 1 er Nivel – Coord Ministerio de Hacienda ...... 225

5.14.3.6.2 Flujograma de proceso – 1 er Nivel – GBM Enterprise Support ............... 226

5.14.3.6.3 Flujograma de proceso – 2 do Nivel ......................................................... 227

5.14.3.6.4 Flujograma de proceso – 3 er Nivel - SAP ................................................. 228

5.14.3.6.5 Flujograma de proceso – “Very High” - SAP ............................................. 229

5.14.3.7 Servicios de Solución de Misión Critica ........................................................ 229

5.14.3.8 Prestación del Servicio ................................................................................. 229

5.14.3.9 Requisitos ..................................................................................................... 230

5.14.3.10 Portal de Soporte ...................................................................................... 231

5.14.3.11 Equipo contacto Enterprise Supporte GBM ............................................. 232

5.15 Formatos de licencias requeridas y capacidad de en premisas y en la nube. ...... 232

5.16 Parametrizacion Flexible ....................................................................................... 233

5.16.1 Autorización para realizar proyectos de personalización ................................... 235

5.16.2 Guía de Parametrización (IMG) ........................................................................... 236

5.16.3 SAP Parametrizacion ............................................................................................ 237

5.17 Multiples ambientes .............................................................................................. 238

5.17.1 Ambientes ............................................................................................................ 238

5.17.1.1 Landscape del sistema .................................................................................. 238

5.17.1.2 Landscape de tres ambientes ....................................................................... 238

5.17.1.3 Alta disponibilidad para SAP HANA .............................................................. 239

5.17.2 Sincronización ...................................................................................................... 241

5.18 Software ................................................................................................................. 243

5.18.1 Bitacoras de Auditoria ......................................................................................... 243

5.18.1.1 Audit Information System ............................................................................ 243

5.18.1.2 Auditoría del servidor de aplicaciones SAP NetWeaver para ABAP ............ 243

5.18.1.3 Realizando auditorías ................................................................................... 244

5.18.1.4 Visualización de resultados de auditoría ...................................................... 245

5.19 Herramienta de desarrollo y/o configuración ....................................................... 245

5.20 Integracion de aplicaciones ................................................................................... 246

5.20.1 Single stack and Dual stack .................................................................................. 247

5.21 Alta Disponibilidad ................................................................................................. 250

5.21.1.1 ¿Qué es la alta disponibilidad? ..................................................................... 250

5.21.1.2 Recuperación: indicadores clave de rendimiento ........................................ 250

5.21.1.3 Eliminación de puntos únicos de falla .......................................................... 251

5.21.1.4 Soporte de alta disponibilidad de SAP HANA ............................................... 252

5.21.1.5 Copias de seguridad (Backups) ..................................................................... 253

5.21.1.6 Replicación de almacenamiento .................................................................. 254

5.21.1.7 Replicación del sistema ................................................................................ 255

5.21.1.8 Servicio de reinicio automático .................................................................... 260

11

5.21.1.9 Host Auto-Failover ........................................................................................ 260

5.22 Escalibilidad ........................................................................................................... 262

5.22.1 Comprender las cargas de trabajo ....................................................................... 262

5.22.2 Escalar los datos................................................................................................... 263

5.22.3 Escalar el rendimiento ......................................................................................... 265

5.22.4 Escalar la aplicación ............................................................................................. 268

5.22.5 Escalar el hardware .............................................................................................. 268

5.22.6 Prueba de referencia de escalabilidad ................................................................ 269

5.23 Seguridad ............................................................................................................... 270

5.23.1 Seguridad en la funcionalidad ............................................................................. 270

5.23.1.1 Administración de usuario y rol de Application Server ABAP ...................... 271

5.23.1.2 Concepto de Autorización ABAP .................................................................. 272

5.23.1.3 Configuración de administración de usuario y rol ....................................... 273

5.23.2 Encripcion de datos ............................................................................................. 274

5.23.2.1 SSL y SNC ...................................................................................................... 274

5.23.2.1.1 Protección provista ................................................................................... 275

5.23.2.1.2 Productos de seguridad externa para SNC ............................................... 275

5.24 Controles de Acceso .............................................................................................. 275

5.24.1 Parámetros de perfil para inicio de sesión y contraseña .................................... 275

5.24.2 Inicio de sesión del sistema ................................................................................. 276

5.24.3 Integracion entre Active Directory y SAP ............................................................ 277

5.24.4 SAP Single Sign-On ............................................................................................... 278

6. OTRAS CONSIDERACIONES DE IMPLEMENTACION Y TIEMPO ............................... 281

6.1 Metodología de Implementación SAP ACTIVATE .................................................. 281

6.2 Aceptación de Entregables .................................................................................... 299

6.3 Estándares y Procedimientos de Gestión de Proyecto ......................................... 301

6.3.1 Plan de Comunicación del Proyecto ...................................................................... 301

6.3.2 Planificación de Reuniones .................................................................................... 301

6.3.3 Agenda de Reuniones y Minutas ........................................................................... 302

6.3.4 Reporte de estatus ................................................................................................ 302

6.3.4.1 Informe de avance semanal del equipo de proyecto ................................... 302

6.3.4.2 Actualización del Plan de trabajo ................................................................. 303

6.3.4.3 Reporte Mensual del Estatus del Proyecto ................................................. 303

6.3.5 Mecanismos de Comunicación a personas fuera del equipo del proyecto .......... 303

6.3.5.1 Comunicaciones claves durante el proyecto................................................ 303

6.3.6 Documentación del Proyecto ................................................................................ 303

6.3.7 Mecanismos de Control de Temas Críticos (Issues) .............................................. 304

6.3.8 Mecanismos de Cambio de Alcance ...................................................................... 304

6.4 Equipo de Proyecto – Ministerio de Hacienda de Republica Dominicana ............ 305

6.5 GBM ....................................................................................................................... 306

12

6.6 Estrategia de Adiestramiento. ............................................................................... 314

6.7 Plan de Cutover (Interfaces para carga de datos iníciales e Histórica) ................. 317

7. CONDICIONES GENERALES DE LA OFERTA ............................................................ 324

13

Este documento ha sido preparado para uso exclusivo del Ministerio de Hacienda de la Republica

Dominicana, siendo permitida su revisión al personal autorizado por la compañía.

Se prohíbe la copia o distribución total o parcial de su contenido sin la expresa autorización de GBM

CONSULTING

Si como resultado de someter este documento, se produce una contratación de GBM CONSULTING,

cualquier duplicación o divulgación del presente quedará regida por los acuerdos de confidencialidad

establecidos por ambas partes. En el caso de no aceptarse nuestra propuesta, este documento y cualquier

copia de él, deberá ser devuelto a GBM CONSULTING.

Control del Documento

Fecha

Autor Versión Referencia de Cambio

03-09-2018 Abraham R. Zuloaga F. 1.0 Preparación

07-09-2018 Abraham R. Zuloaga F. 2.0 Preliminar

11-09-2018 Victor Delgado 3.0 Ajustes - Preliminar

11-09-2018 Abraham R. Zuloaga F. 4.0 Ajustes - Prliminar

11-09-2018 Abraham R. Zuloaga F. 5.0 Ajustada

14

1. INFORMACION DEL PROVEEDOR DE SERVICIOS

1.1 Información de Contacto

Victor Delgado

Territory Manager

GBM Consulting

Tel: 809 5665161 ext. 8543|Cel: 809.961.4896

Email: [email protected]

Rodolfo Guerrero

Ejecutivo de Cuentas

GBM Dominicana

Tel : 809.566.5161 ext.8156|Cel: 809.747.3638

Fax : 809.566.3501 Email:


Gustavo Pascal

General Manager

GBM Dominicana

Tel : 809.566.5161 ext.8000


1.2 INFORMACION SOBRE LA EMPRESA

GBM es una compañía integradora de soluciones, experta en tecnologías de información. Provee todos los

componentes para una infraestructura tecnológica empresarial con equipos (hardware), programas

(software) y servicios especializados. El objetivo de GBM es convertirse en un aliado estratégico de sus

clientes, con el fin de asesorar e implementar soluciones que permitan la creación y evolución de procesos

más automatizados y de esta forma, volverlos más competitivos.

GBM es una empresa regional de capital centroamericano, con presencia local en 7 países y cuya casa matriz

se ubica en Costa Rica. Además de oficinas locales en Guatemala, Honduras, El Salvador, Nicaragua, Costa

Rica, Panamá y República Dominicana, se atienden los mercados de Haití y Belice. También cuenta con

oficinas en Miami, FL, EEUU, como punto de distribución de productos.

mailto:[email protected]


15

GBM es distribuidor exclusivo de IBM en esta región y representa además, de forma oficial y con pleno apoyo,

marcas líderes de la industria como Cisco Systems, Diebold, ZyXEL, Lexmark, así como alianzas con compañías

como SAP, Microsoft y Klein. (GBM Business Partners)

El dinámico proceso de cambio que experimenta la industria informática, en el que dramáticos avances

técnicos se producen cada día, exige que las empresas proveedoras desarrollen un catálogo extenso de

productos, con plataformas alternativas que incluyan una variedad de tecnologías complementarias y los

servicios de implantación y soporte correspondientes. Sólo así estará en condiciones de responder al

conjunto de necesidades del cliente, de configurar e integrar todos los sistemas que en definitiva

representarán una verdadera solución para el usuario.

En cuanto a los servicios, estamos inmersos en un programa de mejoramiento continuo que define muy bien

lo que es la esencia de la calidad y lo que necesitamos hacer para ser competitivos a lo largo del tiempo.

Nuestra experiencia de más de 60 años, nos lleva a integrar nuevas tendencias, metodologías e

implementaciones que den valor agregado. Por esta razón hemos buscado una compañía que nos

complemente: que nos permita la sinergia. A partir del intercambio de conocimiento y experiencia

maximizamos el negocio de quien más nos interesa: nuestros clientes.

GBM ofrece tecnología de la base al tope, en todas las capas de productos: Hardware, Software y aplicativos.

Con GBM Consulting ahora ofrecemos soluciones SAP de principio a fin; desde la asesoría en procesos para

la adopción de un ERP de SAP, su licenciamiento, la puesta en marcha y mantenimiento.

De la base al tope y de principio a fin, maximizamos el potencial de nuestros clientes.

Recientemente hemos agregado a nuestra oferta (por adquisición) la prestación de servicios de asesoría e

implementación de herramientas SAP, por medio de GBM CONSULTING. Nuestro objetivo es seguir

evolucionando como su mejor aliado integrador de tecnología de nuestra región.

http://www.gbm.net/quienes/partners.html

16

¿Porqué GBM?

Al presentarles la siguiente solución, le estamos ofreciendo, no sólo los servicios que entendemos cumplirán

con los requerimientos que demanda el MHRD en estos momentos, sino una solución que incluye múltiples

ventajas para la institución, como son:

1. Confiabilidad y Estabilidad: GBM Dominicana (parte del consorcio GBM Corporación, www.gbm.net )

es una empresa sólida y exitosa, fue creada hacia fines de 1991 como resultado de un proyecto conducido

por IBM Latinoamérica para buscar una nueva forma operativa más directa que respondiera a un mercado

en rápida transformación. Durante más de 45 años, GBM (antes IBM) ha operado aportando soluciones

profesionales a cientos de organizaciones nacionales e internacionales. Muchos de nuestros clientes han

nacido y crecido con nosotros y a la fecha es nuestro mayor testimonio. IBM mantiene una participación

activa como accionista y miembro activo del consejo de directores de GBM Corporación.

2. Servicio y Soporte de Calidad Superior: GBM está basada en la asociación de un número de líderes de

negocios con un equipo gerencial de vasta experiencia en la industria, y cuenta con un cuerpo de

profesionales que acumulan una capacidad técnica y años de experiencia sin paralelo en el territorio. Esta

combinación le permite operar como una empresa auténticamente local, a la vez que capitaliza la sinergia

resultante de su cubrimiento regional (GBM es el único proveedor de tecnología, de Dominicnana, que

cuenta con presencia regional), para brindarle a nuestros clientes el mejor servicio y soporte de la región.

3. Respaldo Internacional: Además de otras representaciones importantes, GBM Dominicana, empresa

asociada a IBM, es el único Distribuidor Autorizado IBM para Dominicnana, lo cual nos permite contar con el

respaldo de los diferentes centros de soporte internacional de IBM, así como acceso a los laboratorios de

investigación y desarrollo para mantener actualizados sus sistemas, y solucionar problemas complejos.

También contamos con el respaldo de los especialistas de GBM en Centroamérica.

4. Escalabilidad: Desde su creación y siguiendo la experiencia IBM, el nivel de escalabilidad de nuestros

productos y servicios brinda gran capacidad de crecimiento y expansión, lo que le permite aumentar, en

caso de ser necesario, la cantidad procesamiento de información con solo hacer expansiones de los recursos,

evitándose costosos reemplazos de los mismos.

5. Experiencia: GBM tiene una reconocida experiencia en el mercado en proyectos de integración

tecnológica, habiéndose destacado en proyectos complejos y de gran envergadura. Esto le garantiza a el

MHRD contar con un asociado de la más alta calidad y tradición de éxitos.

1.3 GBM CONSULTING

GBM CONSULTING es la división de consultoría de GBM. Somos proveedores élite de soluciones de sistemas

de negocios que agrega valor a la gestión de las organizaciones con base en la plataforma SAP.

http://www.gbm.net/

17

GBM CONSULTING ha desarrollado metodologías altamente competitivas, diseñadas para reducir el costo

total de la propiedad del sistema y, al mismo tiempo, obtener el desempeño confiable que requieren las

organizaciones. Su práctica de servicio al cliente guía a través del proceso de implementación de SAP y

cualquier otro requerimiento, garantizando un trato personalizado.

GBM CONSULTING le ayuda a diseñar su estrategia de TI y a desarrollar soluciones de ERP (Enterprise

Resourse Planning) integradas con beneficios claros y mensurables para su negocio.

En GBM, estamos convencidos de que la lealtad del cliente es el resultado de nuestro compromiso y es la

razón de nuestro éxito. Por esto mismo buscamos satisfacer el 100 % de sus requerimientos, ofreciéndoles

modelos de negocio que incorporen no sólo las tendencias del mercado y herramientas disponibles, sino

también que estén de acuerdo con la realidad y estrategia de cada compañía.

Es el respeto por nuestros clientes lo que nos obliga a desarrollar el conocimiento de industria, de sus actores,

de las tendencias y los diferentes procesos operativos que han demostrado resultados positivos. Ha sido ese

conocimiento de sus necesidades y la habilidad de escuchar lo que nos ha incentivado a diseñar metodologías

y soluciones a la medida acordes a nuestras realidades regionales y culturales.

Nacimos y crecimos utilizando SAP como herramienta de soporte operativo, y desde la aparición de

NetWeaver, hemos adquirido el liderazgo regional como Partner SAP en integración de plataformas

tecnológicas, de gente y procesos. Somos reconocidos por las habilidades de nuestra gente, por el alto nivel

de nuestros entregables de proyecto, por lo innovador de nuestros productos pre-empaquetados, por el

compromiso durante el soporte post-productivo, y por la importancia que prestamos al manejo del cambio

organizacional asociado a proyectos de tecnología. En resumen, somos reconocidos regionalmente por el

avance que nuestros clientes experimentan luego de culminar sus proyectos.

¿Porqué seleccionar a GBM Consulting?

GBM Consulting tiene experiencia que cuenta:

▪ Nuestro equipo esta constituido de consultores que tienen experiencia específica en la industria y en las

soluciones ofrecidas.

▪ Nuestros consultores tienen en promedio 8 años de experiencia en la industria de software.

▪ 80 por ciento de nuestra plantilla de consultores tiene más de 5 años de experiencia en la

implementacion y optmizacion de los procesos empresariales en el sistema SAP.

▪ Hemos exitosamente completado mas de 300 implementaciones SAP a nivel nacional e internacional.

▪ Mas del 50% de nuestras implementaciones son del sector de Productos de Consumo, manufactura y

distribucion.

GBM es un socio de negocios reconocido regionalmente por SAP:

▪ Somos Socio de negocios “GOLD PARTNER” de SAP.

18

▪ Hemos recibido el SAP Partner Award of Excellence muchos años. En el 2004 fuimos elegidos como el

socio más importante e influyente de la región, no solo por el nivel de facturación logrado, sino por la

alta satisfacción de nuestros clientes (SAP Commitment Award of Excellence 2004).

▪ Somos socios de negocio reconocidos por SAP en Venezuela (1998), Caribe (2000), Estados Unidos (2003)

y en Centro América a partir de 2008.

▪ Hemos desarrollado micro-verticales junto con SAP, para complementar funcionalidad requerida por

clientes en diversos sectores.

GBM opera regionalmente:

▪ Nuestra práctica regional cuenta con más de 140 empleados.

▪ Nuestra práctica de consultoría cuenta con mas de 240 consultores SAP.

▪ Somos Socios de Negocio reconocidos en Estados Unidos, Venezuela, Caribe y C.A., y colaboramos con

otros Socios de Negocio SAP en otras regiones como expertos de industria para sector financiero.

Referencias GBM

Empresa País Sector Tipo de Proyecto

Aerocav Venezuela Transporte

Financials · Material Management · Plant Maintenance · Sales &

Distribution · Special developments

Project Duration: 4 months (Up-grade to 4.7)

Contacto: Derling Bejarano

Gerente Senior de Sistemas

Teléfono: 212- 620-0731

[email protected]

ALNOVA Venezuela Distribución

Reimplementación de Finanzas, Costos, Ventas, Inventario

compras distribución y planificación de producción

Duración: 8 meses

FI CO CO-PC MM SD PP

Contacto: Marlennis Navarro

Gerente de Tecnología

Teléfono: 212- 365-1042

[email protected]

Almacenes

SEMA

República

Dominicana Detallista

Finanzas: Contabilidad General, Cuentas por Pagar, Cuentas por

Cobrar, Tesorería · Contraloría · Gestión de Materiales · Recursos

Humanos, IS Retail

Duración del Proyecto: 6 Meses


19


Banks Brewery Caribe Inglés Manufactura

Finanzas y control de costos, · Ventas y distribución Gestión de

materiales, Gestión de compras e inventarios · Planificación de

la producción Recursos humanos y nómina

FI CO MM PP HR

Barbados

Bottling

Company

Caribe Inglés Manufactura

Financials & Cost Controlling · Sales & Distribution · Material

management · Production planning · Human Resource & payroll

Duración del Proyecto 5 meses

Candyven Venezuela Distribución

Finanzas: Contabilidad General, Cuentas por Cobrar, Cuentas por

Pagar, Tesorería Contraloría, Gestión de Costos, Activo Fijo ·

Gestión de Materiales · Gestión de compras e inventarios ·

Ventas y distribución · Automatización de Fuerza de Ventas con

Portal · Nomina ·

Duración del proyecto : 6 meses

FI CO MM SD Portals HR

Cementos

Andinos Venezuela Manufactura


Pagar, Tesorería Contraloría y Gestión de Costos de Productos ·

Presupuesto ·Gestión de materiales · Gestión de compras e

inventarios · Ventas y distribución · Planificación de Producción ·

Mantenimiento de Planta · Duración del proyecto : 6 mesesFI

BCS CO CO-PC MM SD PP PM QM

Contacto: Henry Morales


Teléfono: 212- 400-1335

[email protected]/[email protected]

Cesar Castillo Puerto Rico Distribución FI, CO, MM, SD, Charge Backs, Duración del proyecto: 12 meses

COBECA Venezuela Distribución



Gestión de Materiales · Gestión de compras e inventarios ·

Ventas y distribución - Charge Backs,

Duración del proyecto: 12 meses + de 30 Sociedades financieras

FI CO MM SD CB

20


Demerara

Destilleries

Limited DDL

Caribe Inglés Manufactura

Finanzas y control de costos (FICO) · Gestión de la cadena de

suministros · Ventas y distribución (SD) · Gestión de materiales

(MM)· Planificación de la producción (PP) · Control de Calidad

(QM)

GENICA:

General de

Alimentos NISA

Venezuela Manufactura

Finanzas: Cuentas del mayor; Cuentas por Cobrar, Cuentas por

Pagar, Tesorería Contraloría · Contraloría Costeo de productos ·

Manejo de materiales · Planificación de la producción · Ventas y

distribución · Manejo de la calidad Mantenimiento de planta

Duración del proyecto: 6 meses

FI CO CO-PC MM SD PP QM PM

Contacto: Dennis Parente


Teléfono: 212 276-6111 -

[email protected]

Grace Kenedy Caribe Inglés Distribución


Pagar, Tesorería, Costos, Manejo de Materiales, Ventas y

Distribución

Duración del Proyecto: 7 meses

FI CO MM SD

Contacto: Broderik Bowes

Gerente: Coordinador de Sistemas

Teléfono: 876- 932-3583 -

[email protected]

Grupo Diesco República

Dominicana Manufactura


Pagar, Tesorería Contraloría · Costeo de productos · Manejo de

materiales · Ventas y distribución - Planificación de la producción.

Manejo de la calidad Recursos Humanos


FI CO CO-PC MM SD PP QM HR

Grupo Ramos República

Dominicana Detallista

Finanzas: Contabilidad General, Cuentas por Pagar, Cuentas por

Cobrar, Tesorería · Contraloría · Gestión de Materiales · Recursos

Humanos, IS Retail

Duración del Proyecto: Upgrade 4 Meses


21


Knorr

Dominicana

República



Pagar, Tesorería Contraloría y Gestión de Costos de Productos,

Gestión de materiales · Gestión de compras e inventarios · Ventas

y distribución, Planificación de Producción, Gestión de Calidad

FI, CO, MM, SD, PP, QM Duración del Proyecto: 5 meses

Multiquímica

Dominicana

República



Pagar, Tesorería Contraloría · Gestión de Materiales ·

Planificación y control de producción · Ventas y distribución

Duración del proyecto: Cinco meses

Pine Hill Dairies Caribe Inglés Manufactura

Financials & Cost Controlling · Sales & Distribution · Material

management · Production planning · Human Resource & payroll

Duración Proyecto: 5 meses

QUIMBIOTEC Venezuela Manufactura



Presupuesto ·Gestión de Materiales · Gestión de compras e

inventarios · Ventas y Distribución - Gestión de Calidad


FI CO MM SD QM

Contacto: Carolina Capraro

Coordinador Plataforma SAP

Teléfono: 212 - 700-0486

[email protected]

Grupo Shalom

(Almacenes El

Titán)

Panamá Retail

SAP ERP ECC 6.0 + SAP Best Practice Retail y Distribución. SAP

POS DM: Merchandise Lifecycle : Manejo de

Artículos,determinación de Precios Retail, Operación de Surtido,

Manejo de Promociones, liquidaciones, modificaciones de

precios manuales. Supply Chain Management :

Aprovisionamiento Orientado a Demanda, Aprovisionamiento

orientado a Presupuesto, verifiación de facturas, manejo de

centro de distribución, manejo de bodegas (WMS), distribución

de mercancias. Store & Multi Channel : conectividad de Tiendas,

control de inventario en tiendas, • SAP POS Connectivity: ERP

Outbound, • SAP POS Features and ERP Inbound , Enterprise

Management & Support : • Libro Mayor• Cuentas X Cobrar•


22


Cuentas X Pagar• Cierre Contable• Manejo de Caja• Activos

Fijos• Centros de Costos• Centros de Beneficios, • Radio

Frecuencia• Cross-Docking• Planificación y Re-

Aprovisionamiento• Configuraciones básicas o Datos Maestros

Centrales o Estructura organizacional

o Organización en Retail• Datos Maestros o Datos maestros de

artículoso Determinación de precios de Retail o Gestión de

Surtido o Datos maestros básicos en Retail

o Datos maestros de perecederos en Retail o Datos maestros de

mercancías duraderas en Retail


Contacto: Rafael Sabas


Teléfono: 507 - 233-0459

[email protected]

Industrias

Lacteas S.A. Panamá Manufactura

SAP ERP ECC 6.0 + Mejoras a FI y SD (Ventas).


Contacto: Siomar Quiros


Teléfono: 507 – 304-4700

[email protected]

Félix B Maduro Panamá Retail

Fashion




















23






mercancías duraderas en Retail, Implementación de BI


Contacto: Orlando Macias

Gerente de Operaciones

Teléfono: 507 -3005400

[email protected]

Superior S.A. Panamá Retail -

Distribución






















mercancías duraderas en Retail, Implementación de BI - Slow

Seller, MAP BI y BO


Contacto: Paul Levy

Presidente

Teléfono: 507 - 2638985

[email protected]



24


Lady Lee Honduras Retail

Distribución

SAP ERP ECC 6.0 FI CO MM SD Retail y POS-DM RE PS BI + BPC


Contacto: Daniel Rivera

Director Corporativo de Tecnología.

Teléfono: 504 - 2580-6037

[email protected]

Útiles de

Honduras Honduras

Retail

Distribución

SAP ERP ECC 6.0 FI CO MM SD Retail y POS DM. Incluye Interfase

con su POS RMS. Desarrollo especial para ellos de toma de

pedidos en handhelds


Contacto: Luis Romeo Rendon

Sub Gerente General (Hijo del Dueño).

Teléfono: 504 - 2551-2434

[email protected]

La Mundial Honduras Distribución y

Retail

LAT llega en el 2011 a solventar sus problemas de configuración

e implementar nuevos módulos FI-AA LE-TRA PP en adición a la

reconfiguración de FI MM SD donde tenían la mayor cantidad de

problemas


Contacto: Josue Maldonado

Gerente de Sistemas.

Teléfono: 504 - 2556-6000

[email protected]




25

2. INFORMACION DE SAP

2.1 Historia de SAP

Durante 42 años, SAP ha ayudado a las empresas a operar mejor mediante soluciones de software de primera línea que resuelven complejos problemas y ayudan a inventar, comercializar e imponer los productos y servicios de la economía global. La historia de SAP es una de crecimiento constante desde una operación pequeña de cinco personas con sede en el sudoeste de la región alemana de Rhine-Neckar hasta convertirse en uno de los proveedores de software independiente más grandes del mundo, así como también en empleador de más de 68 835 personas en más de 130 países.

SAP se fundó en 1972 y hoy es una de las empresas proveedoras de software independiente más grandes del mundo y, según su capitalización de mercado, una de las tres mayores empresas independientes del mundo del software. Fue fundada como "SAP Systemanalyse und Programmentwicklung” (Systems Analysis and Program Development) en Manheim, Alemania, en 1972. En ese mismo año, también se lanzó el sistema SAP R (que luego pasó a llamarse R/1), En 1977, SAP se mudó a Walldorf y obtuvo sus dos primeros clientes internacionales en Austria. SAP R/2 se lanzó en 1979. Los primeros años de la década de 1980 fueron testigos del crecimiento de la base de clientes de la empresa hasta alcanzar las 250 compañías europeas.

A partir de una trayectoria de innovación y una visión probada a lo largo de todos los cambios tecnológicos y económicos, hoy más que nunca, SAP está impulsada por el espíritu pionero que inspiró a sus fundadores a transformar continuamente el sector de la tecnología.

Los 42 años de trayectoria de éxito de SAP están definidos por algunos temas clave:

• La creencia de que el procesamiento de datos "en tiempo real" puede ayudar a acercar a las personas a las capacidades de Business Intelligence

• La dedicación a la innovación y un espíritu emprendedor que le permite extender todos los límites que sea técnicamente posible

• Y el compromiso desde el comienzo con la colaboración y la creación de soluciones en conjunto con nuestros clientes

Puede emplear los enlaces que se encuentran a continuación si desea información sobre la interesante evolución y los hitos clave de SAP:

• 1972 – 1981: los primeros años. Los primeros años son una crónica de los hechos más importantes de los comienzos de la empresa y el desarrollo posterior, desde su fundación, sus primeros módulos de software y el sistema SAP R/2, hasta los ingresos del primer año de la empresa, los primeros clientes fuera de Alemania y su primera aparición en una feria del sector. Estos años iniciales de SAP pueden describirse mejor como el desarrollo del sueño del procesamiento "en tiempo real", un software que procesa datos cuando los clientes lo solicitan, en vez de analizarlos por lotes durante la noche.

26

• 1982 – 1991: La era SAP R/2: esta etapa abarca varios eventos memorables para la empresa, por ejemplo, expandirse a cuatro servidores con 64 MB de memoria, llegar a 100 empleados y firmar un contrato con el cliente número 1000, alcanzar la marca de ingresos de 100 millones DM y expandirnos a nivel internacional. Se desarrolla la aplicación de software de mainframe empaquetada SAP R/2, que procesa datos en tiempo real e integra todas las funciones de negocio de una empresa.

• 1992 – 2001: La era SAP R/3: el ascenso de SAP durante la era SAP R/3 es meteórico, la empresa alcanza 6000 millones EUR en ingresos y más de 24 000 empleados. De esta forma, marca un nuevo estándar de calidad en las ferias del sector y conferencias para clientes, se hace pública y desarrolla nuevas tecnologías y plataformas. Una versión del servidor del cliente de un software de aplicación estándar ahora permite que los negocios funcionen más eficientemente en todo el mundo e incorpora los procesos en tiempo real al escritorio.

• 2002 – Presente: Datos en tiempo real donde y cuando los necesite: SAP celebra sus 30 y 40 años de trayectoria junto con los increíbles resultados que ha alcanzado en ese tiempo. La informática en la nube, las soluciones móviles y el procesamiento in-memory abren nuevos horizontes para el acceso a los datos en tiempo real, desde prácticamente cualquier lugar, y llevan las capacidades "en tiempo real" a la web y más allá.

2.2 SAP Hoy

Como líder de mercado en software de aplicaciones empresariales, SAP tiene más de 263 000 clientes en más de 188 países que utilizan aplicaciones SAP, desde soluciones específicas que satisfacen las necesidades de pequeñas y medianas empresas (80% de nuestros clientes son pequeñas y medianas empresas) hasta soluciones en suite para organizaciones globales (86% de las empresas incluidas en la lista de Global Fortune 500 utilizan software SAP).

SAP es ideal para todas las empresas, personas y tipo de datos. Nuestro compromiso es resolver los problemas de negocio que antes eran imposibles de solucionar, y ayudar a las empresas a triunfar en la economía de la inteligencia.

En la actualidad, millones de personas en todo el mundo usan soluciones SAP. El ecosistema único de SAP comprende más de 1500 inicios de HANA, más de 2000 partners de tecnología y software, más de 3000 partners de servicios, más de 4000 revendedores de soluciones, más de 2 millones de miembros de la red SAP Community Network (SCN) y 16 redes de valor Industry Value Networks. Más de 68 835 miembros del equipo SAP, entre ellos más de 14 600 empleados de consultoría y educación, y más de 11 250 empleados de soporte y servicios, contribuyen a fortalecer la posición de SAP como líder de mercado en aplicaciones empresariales.

27

SAP ayuda a que el mundo funcione mejor

6000 millones SAP suministra analíticas que monitorean más de 6000 millones de acciones por día en EE. UU. para identificar fraudes y proteger a los inversores.

Más de 38 millones Las soluciones en nube de SAP proporcionan la libertad para que 38 millones de personas trabajen desde prácticamente cualquier lugar.

1800 millones La plataforma de SAP para tecnología móvil envía 1800 millones de mensajes de texto por día en todo el mundo.

Imagine un mundo que funciona mejor

SAP ayuda a las empresas de diferentes tamaños y sectores a funcionar mejor. Los servicios y las aplicaciones SAP ayudan a las organizaciones de todo el mundo a operar con rentabilidad, a adaptarse continuamente y a crecer de manera sustentable. Desde el sector administrativo hasta el directorio, desde el almacén hasta el salón de ventas, desde la computadora de escritorio hasta el dispositivo móvil; SAP habilita a las personas y las organizaciones para trabajar juntas de forma más eficiente y a usar los conocimientos de negocio con más eficacia. Ayudamos a nuestros clientes a cumplir sus metas ampliando la disponibilidad del software en las instalaciones on-premise, las implementaciones on-demand y los dispositivos móviles.

A nivel global, nuestras soluciones están ayudando a los clientes a optimizar sus recursos y proteger el medio ambiente. Ayudan a las agencias gubernamentales de distintos países a alcanzar más logros para sus ciudadanos. Nuestras innovaciones contribuyen a que, en todo el mundo, las personas tengan acceso a agua potable, alimentos nutritivos, oportunidades educativas y atención médica.

A nivel empresarial, nuestras soluciones ayudan a las organizaciones a mantenerse al día con los cambios e innovar para alcanzar un crecimiento. Nuestras soluciones móviles y centradas en las personas ayudan a los negocios a acercarse aun más a sus clientes. Nuestras soluciones analíticas, aceleradas con el procesamiento in-memory, asisten al personal para que tome decisiones mejor informadas, incluso mucho más rápido, a pesar del volumen, la velocidad y los diversos tipos de "datos masivos" (big data). Nuestras accesibles soluciones empaquetadas dan a los empresarios el poder de crecer.

A nivel personal, nuestras soluciones facilitan que las personas se conecten con las empresas, de modo que tengan mayor peso a la hora de decidir cómo, cuándo y dónde se ofrecerán productos y servicios. Las soluciones SAP influyen en cientos de millones de personas cada día mediante sus interfaces centradas en el usuario y sus aplicaciones móviles. Para 2015, esperamos que esa cantidad llegue a 1000 millones.

28

El ecosistema único de SAP abarca más de 263 000 clientes en 188 países y 37 idiomas. Y con 3.000 partners de servicios, 77 centros de capacitación, 7 centros de soporte global, 14 centros de desarrollo personalizado y soporte brindado realmente durante las 24 horas, los 7 días de la semana, SAP marca una diferencia efectiva en lo que hace a ayudar a nuestros clientes a optimizar el trabajo de su empresa y de TI, e impulsar el éxito en las áreas de negocios y de tecnología.

La empresa, que cuenta con filiales en más de 50 países, cotiza en varias bolsas de valores, incluida la NYSE, con el código "SAP".

La cartera de productos, soluciones, servicios y soporte SAP está pensada en función del cliente. Nuestras soluciones ayudan a los clientes a abordar los problemas y las tendencias más importantes de este tiempo: las presiones del crecimiento poblacional y la rápida urbanización, el poder de una conexión interpersonal sin precedentes, la ubicuidad de la tecnología móvil y la demanda creciente de recursos naturales. Con nuestro software, las empresas de todos los tamaños pueden conectarse mejor con clientes y proveedores, y medir, monitorear y administrar sus operaciones sustentables. Nuestras soluciones también satisfacen las expectativas que tienen nuestros clientes sobre ciclos de innovación más cortos, un costo total de propiedad atractivo, una experiencia de usuario superior y una opción para el consumo, sea on-premise o en la nube.

La cartera de SAP incluye aplicaciones y soluciones analíticas para clientes de cualquier tamaño y sector, de cualquier lugar del mundo. SAP HANA es la plataforma para todas nuestras soluciones. Es una plataforma de datos in-memory que se puede implementar como una aplicación on-premise o en la nube. También ofrece una oportunidad única para las innovaciones de negocio, ya que simplifica los entornos de TI, reduce el costo total de propiedad y mejora el desempeño. Por lo tanto, todos los productos SAP se pueden ejecutar en la plataforma SAP HANA. Es más, nuestro software está desarrollado con un enfoque de "primero movilidad" en base a las aplicaciones SAP Fiori, que brindan una experiencia simple y fácil de usar para las funciones del software SAP más usadas y que funcionan sin dificultades en todos los dispositivos.

La mayoría de nuestras soluciones se pueden entregar on-premise y mediante la nube bajo la modalidad de software como servicio (SaaS). SAP suministra una gran cantidad de soluciones en la nube y así abarca líneas de negocio, tales como recursos humanos, finanzas, ventas y aprovisionamiento.

Figura 1. SAP es la empresa en nube, potenciada por HANA

29

Estrategia: simplificar todo con la nube de SAP con tecnología SAP HANA

Las empresas de todo el mundo están comenzando una nueva era de innovación del modelo de negocios, que se hace posible gracias a la convergencia de tecnologías móviles, en la nube, in-memory y redes sociales.

Sin embargo, suelen tener que lidiar con la complejidad de TI que se viene acumulando desde hace décadas. Esta complejidad es el resultado de diversos factores, tales como el aumento del hardware y las aplicaciones a medida. Asimismo, las inversiones en innovaciones suelen tardar en implementarse y aportar valor para el negocio. Dada la complejidad del modelo actual de consumo, los clientes no pueden responder con la rapidez que se necesita a las cambiantes condiciones del mercado. Pensamos que la clave es la simpleza. Al resolver el problema de la complejidad del negocio, podemos ayudar a revelar el potencial de innovación de nuestros clientes. Nos comprometemos a liderar esta simplificación.

En el sector tecnológico actual, los mayores ganadores crecieron porque ofrecieron simplicidad y facilidad de consumo en un modelo de nube, que se tradujo en la adopción masiva por parte de los usuarios y el éxito de mercado.

En 2014, SAP se concentrará en ayudar a sus clientes a "simplificar todo, de manera que puedan hacer lo que quieran".

Figura 2. Pensamos que la clave es la simplicidad.

Dado que simplifica en forma simultánea en tres ejes (la pila tecnológica, el consumo de software y la experiencia del usuario final), SAP puede ayudar a sus clientes a reducir considerablemente sus gastos en hardware y servicios, dirigir los ahorros a la innovación y transformación de la empresa, y facultar a sus empleados para que impulsen la transformación futura de sus negocios.

30

Gracias a la plataforma SAP HANA tenemos la oportunidad de simplificar nuestra cartera de productos y entorno de TI en beneficio de nuestros clientes. SAP HANA puede simplificar drásticamente las aplicaciones empresariales ya que reduce toda la pila de TI. La plataforma SAP HANA Cloud Platform nos da la capacidad de llevar nuestras aplicaciones centrales on-premise a la nube y podemos ofrecerles a nuestros clientes una variedad de implementaciones en la nube.

Con SAP Cloud potenciado por SAP HANA, orientaremos la simplificación a tres áreas: la simplificación del modelo de consumo, de nuestra cartera y de la experiencia de usuario.

• Simplificar el consumo de software al trasladar toda nuestra cartera a la nube: estamos sumergidos en la transición de nuestro modelo de consumo a SAP Cloud potenciado por SAP HANA, desde donde podemos proporcionar soluciones integrales y lograr mejores resultados para los clientes. Ofreceremos toda nuestra cartera de soluciones (aplicaciones, analíticas y plataforma) por medio de SAP Cloud potenciado por SAP HANA. Trasladaremos nuestro software central SAP Business Suite a la nube como un servicio gestionado, suministrado tanto por SAP como por nuestros partners. También aceleraremos nuestras inversiones en soluciones en nube pública para líneas de negocio en SuccessFactors, Ariba y nuestra cartera en nube, todos los cuales se ejecutan en SAP HANA. Les brindaremos a nuestros clientes una verdadera nube integrada. Y, como estamos comprometidos a brindar flexibilidad y opciones, también seguiremos ofreciendo un modelo de implementación on-premise.

• Simplificar nuestros productos con SAP HANA como plataforma común: estandarizaremos todos los productos SAP (incluidos SuccessFactors y Ariba) en la plataforma común SAP HANA, y proporcionaremos integración en toda nuestra cartera. Esto brindará una experiencia simplificada del conjunto de soluciones a nuestros clientes y partners. Nuestros partners y ecosistema podrán ampliar nuestras soluciones o desarrollar aplicaciones integrales basadas en la plataforma.

• Simplificar la experiencia de usuario: simplificaremos la experiencia de usuario (UX) proporcionando un enfoque de "primero, la tecnología móvil" en base a las aplicaciones SAP Fiori, que brindan una experiencia simple y fácil de usar para las funciones del software SAP más usadas y que funcionan sin dificultades en todos los dispositivos. Construiremos aplicaciones que se identifiquen con el usuario y mejoren considerablemente la experiencia de los clientes y los empleados de nuestros clientes

Además de simplificar nuestro modelo de negocio, nos centraremos en proporcionar soluciones integrales específicas para cada sector que permitan obtener valor y lograr resultados. Seguiremos desarrollando un ecosistema abierto y nuestra red de partners para proporcionarles SAP Cloud potenciado por SAP HANA en su infraestructura de nube. El ecosistema tendrá un rol fundamental en el desarrollo de soluciones nuevas en la plataforma SAP HANA y en la obtención de valor para nuestros clientes.

Nos enfocamos en la simplificación para poder innovar mejor y crecer.

31

Hoy SAP solo recibe un pequeño porcentaje de la inversión total que hace cada cliente en tecnología de la

información. Al invertir en innovaciones y llevar a nuestros clientes a un modelo de negocio en la nube,

contribuiremos a que disminuyan su costo total de propiedad (TCO) en tecnología. Esto les permite reinvertir

lo que se ahorran en TCO en innovaciones y SAP puede obtener un margen mayor del gasto en TI que realizan

los clientes.

Además, SAP fomentará la innovación y el crecimiento en las siguientes dimensiones:

• Impulsar la agenda de Big Data entre nuestros clientes con la plataforma SAP HANA y las soluciones

analíticas predictivas in-memory en tiempo real.

• Establecer SAP HANA como una plataforma de negocio empresarial estándar y ganar dinero por medio

de partners y el ecosistema.

• Enfocarnos en los clientes de nuestro cliente llegando de empresa a empresa y al consumidor (B2B2C)

mediante nuestra cartera de soluciones omnicanal y CRM.

• Impulsar un crecimiento acelerado en sectores elegidos, tales como la banca, los seguros, la venta

minorista, la administración pública y el área de la salud.

• Los mercados emergentes continuarán siendo impulsores de crecimiento, y se espera un crecimiento de

los ingresos, en el orden de los dos dígitos altos, por software y nube hasta el 2017. Además de las

inversiones realizadas en China, Rusia y el Medio Oriente, estamos aumentando las inversiones en África.

Seguiremos comprometidos con el éxito de nuestros clientes y orientaremos nuestras operaciones en pos de

crear mayor valor para nuestros clientes. Nos esforzamos por proporcionarles una ventaja competitiva

importante y ayudarlos a lograr un crecimiento financiero, ecológico y social más sustentable.

2.3 Descripción general de soluciones SAP

Las soluciones SAP ayudan a las organizaciones a operar como nunca antes. Nuestros servicios y soluciones

ayudan a 263 000 empresas de 188 países a anticipar mejor las exigencias del mercado, a responder con

flexibilidad y a innovar rápidamente. Las soluciones SAP brindan a personas de todo el mundo la libertad de

trabajar en tiempo real desde cualquier lugar y en cualquier momento, de modo que las empresas pueden

direccionar la innovación en sus sectores y liderar el mercado. Ya sea una implementación on-premise, en la

nube o en un dispositivo móvil, las soluciones SAP funcionan como si fueran una sola: como "soluciones

encadenadas" que organizan la información y los procesos de negocio y cumplen con las necesidades de los

negocios y las redes empresariales de todos los tamaños.

32

Nuestra estrategia de productos emplea tecnologías in-memory, de nube y móviles que se apoya en nuestra

plataforma existente de aplicaciones, lo que ayuda a minimizar las interrupciones para nuestros clientes. No

solo buscamos proteger las inversiones en tecnología de nuestros clientes, sino también aumentar las

ventajas para su negocio. De esta manera, los clientes pueden adoptar las innovaciones a su propio paso, sin

interrupciones y de acuerdo con las necesidades específicas de su sector.

SAP ofrece productos innovadores en cinco categorías de mercado: aplicaciones; analíticas; tecnología móvil;

base de datos y tecnología; y la nube. Todas potenciadas por la plataforma SAP HANA. Nuestra estrategia

consiste en productos simples, mejores resultados de negocio y valor de negocio sustentable. Estas

innovaciones se combinan con soluciones que resuelven problemas específicos de 12 líneas de negocio en

25 sectores. Algunas de nuestras soluciones vienen preempaquetadas para una implementación rápida sin

interrupciones. Así, ayudan a miles de pequeñas y medianas empresas y brindan una buena experiencia de

consumo para los clientes de nuestros clientes. Además, ayudan a las organizaciones a enfrentar los desafíos

de sustentabilidad.

Figura 3. Cartera de productos de SAP

SAP ofrece productos innovadores en cinco categorías de mercado: aplicaciones; analíticas; tecnología móvil;

base de datos y tecnología; y la nube. Todas potenciadas por la plataforma SAP HANA.

Soluciones para líneas de negocio

Todas ellas son pertinentes para todos los sectores, y brindan funcionalidades con las mejores prácticas para

áreas clave dentro de una organización. En consecuencia, los profesionales tienen la posibilidad de

destacarse en sus respectivas disciplinas. Nuestra cartera de soluciones actualmente abarca 12 líneas de

negocio:

• Gestión de activos: ayudan a las organizaciones a administrar de manera eficiente y sustentable el

ciclo de vida completo de los activos, además de mejorar su uso y reducir los costos.

• Estrategia corporativa y sustentabilidad: permiten tener transparencia, cumplimiento regulatorio

eficiente, menores riesgos, menor uso energético, productos más seguros y un mayor valor para la

marca.

33

• Finanzas: ayudan a garantizar el cumplimiento regulatorio y una buena gestión del riesgo, además

de superar los objetivos financieros y brindar servicios superiores a menor costo.

• Recursos humanos: ofrecen visibilidad completa y analítica del desempeño de la fuerza laboral a nivel

mundial y local, así como aptitudes, brechas y procesos; y todo dentro de una única plataforma

global.

• Tecnología de la información: permiten que el departamento de TI se convierta en un socio

estratégico de negocio al maximizar su capacidad de respuesta y su contribución en el logro de los

objetivos de negocio, controlar y optimizar los costos de tecnología, y evaluar y controlar sus riesgos.

• Fabricación: con ellas, las organizaciones pueden adaptarse a condiciones cambiantes, ejecutar

procesos de producción eficientes y sustentables, y elaborar productos de alta calidad en

cumplimiento de las normativas.

• Marketing: ayudan a las organizaciones para que la experiencia de sus clientes sea uniforme en todos

los puntos de contacto y así puedan satisfacer sus exigencias cada vez más preparados.

• Compras: permiten que los clientes gestionen el proceso completo desde el análisis y el

abastecimiento hasta la compra en todas las categorías de gasto para generar ahorros sustentables

en los resultados finales.

• I&D e ingeniería: reducen el tiempo de capitalización, aumentan la contribución a los ingresos a

través de productos nuevos y mejorados, y reducen los costos de I&D, por incumplimiento y por falta

de calidad.

• Ventas: ayudan a las organizaciones a tener un crecimiento rentable de los ingresos mediante la

ejecución centrada en las ventas.

• Servicio: con ellas, las organizaciones pueden superar las expectativas de los clientes e impulsar los

ingresos en sus interacciones y operaciones.

• Gestión de la cadena de suministro: hacen que las organizaciones mejoren la precisión de las

previsiones y la demanda mundial, además de entregar la orden perfecta y controlar los costos de la

cadena de suministro en toda una red sólida y con capacidad de respuesta.

En GBM suministramos estas soluciones on-premise o en la nube como ofertas de software como servicio

(SaaS).

http://www.sapcorporateprofile.com/solutions/line-of-business/service

34

Soluciones por sectores de industria

El objetivo principal de la estrategia de las soluciones por sector de SAP es ayudar a satisfacer las necesidades de nuestros clientes de 25 sectores específicos. Dado que nuestros clientes aprovechan las comparaciones, los procesos y las mejores prácticas preconfigurados, pueden activar funcionalidades adicionales específicas de cada sector en su software SAP. Pueden brindar a sus usuarios de negocio las capacidades específicas que necesitan, mientras que se benefician con una base tecnológica sólida y rentable para fomentar el crecimiento. Con las soluciones específicas para su sector, los clientes de SAP pueden hacer lo siguiente:

• Confiar en software diseñado para brindarles flexibilidad, que ayuda a empresas de cualquier tamaño.

• Aprovechar los procesos de negocio integrales que abarcan áreas funcionales.

• Disfrutar de tecnologías innovadoras, comol las analíticas de negocio, la informática in-memory, la tecnología móvil y la nube.

• Equilibrar las necesidades de TI y de negocios teniendo en cuenta las necesidades inmediatas y futuras

• Ampliar su negocio con confianza aprovechando la experiencia de SAP en 25 sectores

• La exitosa estrategia por sectores de SAP aprovecha las fortalezas clave de la empresa en cuatros áreas:

• Claridad de la visión y amplio roadmap de sectores: SAP ha reforzado significativamente su visión de los sectores y los ha vuelto un elemento integral para el diseño y la entrega de sus soluciones. Ponemos atención a las necesidades de los sectores y empleamos los conocimientos aprendidos para crear soluciones innovadoras que abran la puerta a nuevas oportunidades y beneficios.

• Soluciones para 25 sectores en una única plataforma: las soluciones SAP brindan funcionalidades para múltiples sectores en una única plataforma y adaptan los procesos de negocio a 25 sectores. Mediante una solución SAP, las empresas pueden extender fácilmente sus negocios fuera de los límites del sector sin tener que reconceptualizar sus sistemas centrales.

• Funcionalidades para múltiples sectores: SAP tiene todas las herramientas para ofrecer funcionalidades que traspasen los límites de cada sector. Los negocios que abarcan diferentes mercados y sectores pueden confiar en la diversidad de una cartera versátil de SAP para gestionar mejor sus operaciones.

• Ecosistema integral dentro de un marco unificado: la experiencia de SAP en los diversos sectores se extiende en todo nuestro amplio y sumamente calificado ecosistema de partners, y todo esto se concentrar en una única plataforma tecnológica integrada: SAP NetWeaver. Con el software SAP, la especialización por sectores está al alcance de cualquier empresa.

SAP respalda a empresas de 25 sectores mediante carteras de soluciones que suman procesos de mejores prácticas del sector. Estas carteras son el resultado de décadas de innovación fiable con líderes del sector, quienes compartieron sus mejores prácticas con el fin de ayudar a los clientes, proveedores y partners de sus redes de negocios a optimizar el desempeño del trabajo conjunto. También ofrecemos valor de TI mediante la coordinación de soluciones on-premise, en la nube y en cualquier dispositivo, lo que le brinda

35

flexibilidad, seguridad y escalabilidad en una única plataforma tecnológica. Los beneficios de esta organización son los siguientes:

• Soluciones que son más fáciles de usar gracias a los pasos simples de implementación

• Retorno sobre la inversión en poco tiempo mediante soluciones de implementación rápida

• Operaciones seguras y fiables adaptadas a cada negocio individual

Nuestras carteras de soluciones están diseñadas para satisfacer las necesidades de los principales sectores que detallamos a continuación. También incluyen aplicaciones para numerosos subsectores y segmentos del sector. Las soluciones por sector de SAP ayudan a organizaciones de 25 sectores a operar mejor.

Sector Cartera del sector

Consumidor • SAP for Consumer Products

• SAP for Life Sciences

• SAP for Retail

• SAP for Wholesale Distribution

Fabricación discreta • SAP for Aerospace & Defense

• SAP for Automotive

• SAP for High Tech

• SAP for Industrial Machinery & Components

Energía y recursos naturales • SAP for Chemicals

• SAP for Mill Products

• SAP for Mining

• SAP for Oil & Gas

• SAP for Utilities

• Servicios financieros SAP for Banking

• SAP for Insurance

Servicios públicos • SAP for Defense & Security

• SAP for Healthcare

• SAP for Higher Education & Research

• SAP for Public Sector

Servicios • SAP for Engineering, Construction & Operations

• SAP for Media

• SAP for Professional Services

• SAP for Sports & Entertainment

• SAP for Telecommunications

• SAP for Transportation & Logistics

36

2.4 Aplicaciones SAP – SAP Business Suite

El software de SAP Business Suite ayuda a las empresas a ejecutar y optimizar sus estrategias de negocio y de TI con una cartera integrada de aplicaciones de negocio. Las empresas pueden gestionar los procesos esenciales específicos del sector con soluciones modulares diseñadas para trabajar con otro software SAP y de otros proveedores. Los clientes pueden implementar las aplicaciones SAP Business Suite de manera modular para abordar necesidades de negocio específicas dentro de sus propios cronogramas, apuntando a los procesos de negocio que tengan el mayor impacto potencial. El software brinda una mejor comprensión y visión de toda la empresa al tiempo que mejora la eficacia operativa y aumenta la flexibilidad necesaria para afrontar los cambios en el negocio.

Las empresas pueden mejorar progresivamente las aplicaciones SAP Business Suite mediante paquetes de mejoras que reciben a través de nuestras ofertas de asistencia y que reducen la necesidad de realizar actualizaciones costosas y que llevan mucho tiempo. Las soluciones aumentan la visibilidad entre departamentos y silos de negocio, y así mejoran la capacidad para tomar decisiones de negocio más claras.

El software SAP Business Suite incluye las siguientes aplicaciones:

• SAP Customer Relationship Management (SAP CRM) ayuda a las organizaciones a gestionar y supervisar los procesos de ventas, servicio y marketing. Esta aplicación también da soporte a actividades clave del back-office, como la gestión de reposición, la planificación de la demanda, la facturación y la ejecución de pedidos. Con funcionalidades de business intelligence y analíticas incorporadas, soporte para el personal móvil y funcionalidades multicanal sustanciales, SAP CRM ayuda a las empresas a desarrollar un conocimiento de los clientes, a predecir cambios y realizar correcciones de curso en tiempo real.

• SAP Enterprise Resource Planning (SAP ERP): esta aplicación acompaña a los procesos de negocio de principio a fin, que incluyen finanzas, gestión del capital humano, gestión de activos, ventas, compras y otras actividades esenciales. SAP ERP se adapta a los procesos específicos de cada sector con funcionalidades que se pueden activar selectivamente, lo que mantiene estable el centro de la aplicación y ayuda a lograr un desempeño máximo.

• SAP Product Lifecycle Management (SAP PLM) ayuda a las empresas a gestionar, hacer el seguimiento y controlar la información relacionada con los productos a lo largo de todo el ciclo de vida de los productos y activos en toda la cadena de suministro. SAP PLM está diseñada para facilitar la creatividad y liberar el proceso de innovación de productos de las limitaciones organizativas.

• SAP Supplier Relationship Management (SAP SRM): esta aplicación de gestión de relaciones con los proveedores permite realizar actividades de compras clave, que incluyen el abastecimiento en función de la demanda, la gestión de contratos centralizada, las compras operativas y la interacción con proveedores a través de canales múltiples. SAP SRM ayuda a acelerar y a optimizar la totalidad del ciclo de compras hasta el pago al permitir procesos integrados e imponer el cumplimiento de contratos, lo cual puede generar ahorros concretos.

• SAP Supply Chain Management (SAP SCM) ayuda a las empresas a adaptar sus procesos de cadena de suministro al entorno competitivo en constante cambio. Esta aplicación transforma las cadenas de suministro tradicionales (que tienen procesos lineales y secuenciales) en redes de suministro abiertas, configurables y ágiles. Como resultado, las empresas pueden mejorar su respuesta a la dinámica de la oferta y la demanda en un entorno distribuido a nivel mundial.

37

SAP Business Suite powered by SAP HANA

Las aplicaciones de SAP Business Suite funcionan en el entorno de la plataforma de próxima generación SAP HANA. Este software integra transacciones y análisis dentro de una única plataforma in-memory. Puede dirigir su negocio en tiempo real para crear nuevas ventajas para su negocio con innovaciones de negocio más inteligentes, procesos más rápidos e interacciones más simples. 2

Combinación de SAP Business Suite con SAP HANA

SAP Business Suite es una completa familia de aplicaciones diseñadas para funcionar juntas y ayudarle a ejecutar su negocio con eficiencia y eficacia. Incluye software totalmente integrado para dar soporte a sus operaciones centrales de negocio con aplicaciones, procesos y tecnología líderes del mercado.

SAP siempre se ha esforzado por agregar valor al software de SAP Business Suite. Es por eso que SAP Business Suite ahora funciona en entorno SAP HANA, la plataforma de próxima generación. ¿El resultado? Puede aprovechar el software para replantear sus procesos según lo necesite, incorporar inteligencia a sus transacciones o simplemente inventar modelos de negocio que antes no eran posibles. El software también facilita la planificación, ejecución y generación de informes y análisis en tiempo real para todos sus procesos de negocio de extremo a extremo. Y los usuarios pueden obtener vistas unificadas de 360 grados de la información en tiempo real (al alcance de la mano y en múltiples dispositivos) en todas las aplicaciones de SAP Business Suite y en muchas más. Puede consultar la información sobre fuentes tales como sensores de máquinas y redes sociales.

Figura 4. Plataforma abierta para innovar sin interrupciones

La plataforma SAP HANA sienta las bases para que usted aumente significativamente el rendimiento de sus aplicaciones SAP Business Suite y siga innovando sin interrupciones con una plataforma abierta.

38

2.5 SAP S/4HANA

Con SAP S/4HANA (SAP Business Suite 4 SAP HANA), SAP proporciona un nuevo producto y una próxima generación de aplicaciones de negocios: software empresarial simple para grandes volúmenes de datos y diseñado para ayudarlo a ejecutar de manera simple al Ministerio de Hacienda de la Republica

Dominicana (MHRD) en su economía digital.

La familia SAP S/4HANA está completamente desarrollada en la plataforma “in memory” de SAP HANA. Usando el potencial avanzado de SAP HANA, SAP S/4HANA está diseñado para su negocio digital y brinda una visión instantánea al usar un única fuente de verdad, procesos en tiempo real, planificación dinámica y análisis. Con la experiencia del usuario SAP Fiori y modelo de datos menos complejo, está diseñado para ejecutarse de manera simple, y en paralelo reduce la huella de datos de su empresa. SAP S/4HANA también ya está conectado a redes empresariales y colaboración interna de la institución a raves de las redes (por ejemplo, SAP Jam Collaboration) y preparado para Internet de cosas. Con todos estos aspectos, SAP protege sus inversiones facilitando las aplicaciones comerciales de próxima generación.

S/4HANA es el paquete empresarial SAP de próxima generación (abreviatura de SAP Business Suite 4 SAP HANA), similar a la transición entre R/2 y R/3. Se basa en SAP HANA, con principios de diseño e interfaces de usuario modernos. También ofrece enormes simplificaciones e innovaciones. Con las enormes mejoras tecnológicas proporcionadas por HANA, el paquete de negocios ahora puede combinar muchas herramientas y tablas que debían mantenerse por separado en el pasado. Por ejemplo, en el pasado, la integración entre diferentes sistemas (por ejemplo, ERP, CRM, SCM) tenía que hacerse replicando datos entre varios sistemas. Ahora, ahora todos pueden ejecutarse rápida y fácilmente en la misma base de datos. Esto puede ayudar a mejorar drásticamente la huella de datos de una organización.

SAP S / 4HANA se compone de:

● SAP Enterprise Management S / 4HANA

La gestión empresarial de SAP S/4HANA está diseñada para intituciones de todos los sectores que necesitan una gestión profunda y un amplio nivel de funcionalidad combinado con un alto grado de flexibilidad en la personalización.

● Productos SAP S/4HANA (Line of Business), los productos SAP S/4HANA LoB mejoran las funciones centrales de SAP S/4HANA Enterprise Management para proporcionar beneficio comercial adicional para su línea de negocio (LoB).

● Productos SAP S / 4HANA LoB para industrias específicas, Los productos SAP S / 4HANA LoB para industrias específicas mejoran las funciones principales de SAP S / 4HANA Enterprise.

39

2.6 Analíticas

La cartera de soluciones analíticas de SAP incluye aplicaciones analíticas diseñadas para ayudar a los usuarios de negocio a alcanzar sus metas estratégicas, proporcionar resultados predecibles y tomar decisiones fundamentadas. Las aplicaciones de Business Intelligence y de gestión de la información empresarial permiten a las empresas brindar información confiable a todos los miembros de una red de negocio, de forma que puedan responder con mayor rapidez y tomar mejores decisiones. Esta cartera de soluciones también incluye soluciones de gestión del rendimiento empresarial y para el control corporativo, los riesgos y el cumplimiento regulatorio, que ayudan a los clientes a mejorar su rentabilidad, gestionar el riesgo y el cumplimiento y optimizar los sistemas y procesos.

Estas propuestas, que reflejan el compromiso de SAP con la apertura y la interoperabilidad en entornos de software heterogéneos, están diseñadas para integrarse con orígenes de datos y sistemas de otros proveedores al igual que con aplicaciones SAP Business Suite y otras soluciones analíticas de SAP.

Nuestra cartera de soluciones analíticas incluye:

o Funcionalidades de Business Intelligence (BI), que les permite a los usuarios interactuar con la información de negocio y obtener respuestas a preguntas ad hoc sin conocimientos avanzados de los orígenes de datos subyacentes. Disponible tanto en las opciones de implementación on-demand como local, el software permite a los usuarios acceder a información en todas las fuentes y formatos y luego proporcionarla como información provechosa y utilizable. Las herramientas de BI también ayudan a los clientes a descubrir tendencias y patrones, resolver problemas de negocio, prever los cambios y alcanzar los objetivos de la empresa. Nuestras soluciones de BI incluyen la plataforma SAP BusinessObjects BI, SAP Crystal Reports, SAP BusinessObjects Dashboards y SAP Lumira.

o La gestión del rendimiento empresarial (EPM) ayuda a las empresas a mejorar el control de su desempeño, la agilidad de la organización y la toma de decisiones. Las soluciones admiten procesos en múltiples líneas de negocio, entre ellos finanzas, cadena de suministro y compras. La cartera EPM incluye

40

aplicaciones para la gestión de estrategias; la elaboración de planificaciones, presupuestos y proyecciones; la consolidación financiera; la administración de rentabilidad y costos, y la gestión del rendimiento de la cadena de suministros y gastos. Entre las soluciones de EPM de SAP se encuentran las aplicaciones SAP Business Planning and Consolidation, SAP Profitability and Cost Management, SAP Financial Consolidation y SAP Disclosure Management.

o El control corporativo, los riesgos y el cumplimiento regulatorio (GRC) otorgan a las empresas una estrategia proactiva y en tiempo real para gestionar estos tres aspectos en entornos heterogéneos. Asimismo, las aplicaciones analíticas específicas de la industria abordan desafíos en sectores y líneas de negocio específicos. Creadas junto con los clientes y diseñadas para funcionar prácticamente en cualquier entorno, las aplicaciones brindan el conocimiento y el soporte para las mejores prácticas que necesitan las empresas para comprender mejor los riesgos, develar oportunidades y tomar las decisiones correctas a fin de optimizar sus negocios. Las aplicaciones, que pueden implementarse rápidamente, están diseñadas para funcionar prácticamente en cualquier sistema de TI y generar valor en seguida para los clientes. Las soluciones SAP para GRC incluyen las aplicaciones SAP Risk Management, SAP Access Control y SAP Global Trade Services, como también la aplicación analítica SAP Sustainability Performance Management.

o Las analíticas predictivas proporcionan funcionalidades predictivas avanzadas a un amplio espectro de

usuarios, más allá de los científicos, a los usuarios de líneas de negocios y analistas en el lugar de trabajo,

que los ayudan a descubrir nuevas oportunidades de negocio, predecir tendencias y responder

proactivamente ante los cambios. Esto es posible gracias a que se automatiza la elaboración de modelos

clave y las tareas analíticas, y a que se logra una implementación y adopción más rápidas de herramientas

analíticas predictivas.

41

3. REQUERIMIENTOS FUNCIONALES

3.1 Objetivo del Proyecto El Ministerio de Hacienda de la Republica Dominicana requiere una solución tecnológica que permita la Administración de los Bienes de uso (muebles, inmuebles, intangibles), Bienes de consumo (Inventario), Cuentas por Pagar y Cuentas por Cobrar de las instituciones del Estado Dominicano en todo el sector público como parte del Sistema Integrado de Administración Financiera del Estado (SIAFE) y consultoría de servicios profesionales, considerando todos los aspectos requeridos en el pliego que se describe como “ADQUISICION DE APLICACIÓN TECNOLOGICA PARA EL FORTALECIMIENTO DE LA ADMINISTRACIÓN Y CONTROL DE LOS BIENES DE USO, BIENES DE CONSUMO, CUENTAS POR PAGAR Y CUENTAS POR COBRAR DE LAS INSTITUCIONES DEL ESTADO DOMINICANO COMO PARTE DEL SISTEMA INTEGRADO DE ADMINISTRACIÓN FINANCIERA DEL ESTADO (SIAFE) Y CONSULTORÍA DE SERVICIOS PROFESIONALES”, (Referencia: PAFI-CCC-LPN-2018-0003) de Julio del 2018. GBM basada en la experiencia de varios años y en número significativo de implantaciones a nivel Latinoamericano sugerimos un plan de trabajo que aportará un valor operativo de gran importancia, reduciendo el tiempo de implantación y los costos generales involucrados para la inclusión de los componentes que le permitan el fortalecimiento en la administración de y control de bienes de uso, bienes de consumo, cuentas por pagar y cuentas por cobrar de las instituciones del estado Dominicano. Para la implementación de SAP S/4HANA dentro de el Ministerio de Hacienda de la Republica Dominicana, se ha definido el alcance de los macroprocesos como a continuación se detallan, tomando como referencia las necesidades de procesos de negocios e información.

3.2 Alcance Organizacional del Proyecto

3.2.1 A nivel institucional:

• Lote Nro 1: Tres (3) instituciones.

42

3.2.2 Alcance geografico (Pais y sus distintas dependencias geográficas)

• Republica Dominicana.

Lote Numero 1 – Tres (3) Instituciones

Fase l: Preparación (2) Dos Semanas

Fase ll: Exploración (8) Ocho Semanas

Fase lll: Realización (24) Veinticuatro Semanas

Fase lV: Implementar (10) Diez Semanas

Fase V: Produccion (4) Cuatro Semanas

Fase Vl: Soporte Post – Productivo (6) Seis Semanas

3.3 Alcance Funcional del Proyecto

Como parte de la funcionalidad para la implementación una solución tecnológica que permita la Administración de los Bienes de uso (muebles, inmuebles, intangibles), Bienes de consumo (Inventario), Cuentas por Pagar y Cuentas por Cobrar en el Ministerio de Hacienda de la Republica Dominicana, se han contemplado los siguientes módulos, tomando como referencia las necesidades de la Licitación Pública (Referencia: PAFI-CCC-LPN-2018-0003) de Julio del 2018, emitida por el Ministerio de Hacienda de la Republica Dominicana.

3.3.1 Instituciones del Estado Dominicano

Bansadonos en lo indicado en la PARTE A – REQUERIMIENTOS FUNCIONALES LOTE 1, Numeral 1.1

Instituciones del Estado Dominicano y los Sub-Numerales 1.1.1 Configuracion de las instituciones del estado

dominicano al 1.2.23 Historial de transacciones de instituciones de la Licitación Pública (Referencia: PAFI-CCC-

LPN-2018-0003) de Julio del 2018, procedemos a describir la solución que ofrece SAP que cubre los escenarios

requeridos por el Ministerio de Hacienda de la Republica Dominicana:

Para SAP es fundamental definir las estructuras básicas donde se establecerán las funciones institucionales,

son elementos de la estructura lógica del Sistema SAP, importantes para la Gestión financiera.

43

Se usan las unidades organizativas para estructurar funciones institucionales y para elaborar los informes.

Las unidades organizativas de Gestión financiera se utilizan con fines de gestión de informes externos, es

decir, satisfacen las necesidades a las que su empresa está sujeta por parte de grupos externos, por ejemplo,

normativas legales. Por ejemplo, los balances se crean en función de las unidades organizativas de Gestión

financiera.

3.3.1.1 Mandante

Unidad autocontenida dentro del Sistema SAP desde un punto de vista técnico, organizativo y comercial. Los mandantes tienen sus propios registros maestros y su propio conjunto de tablas. La definición de la unidad organizativa mandante es obligatoria.

El mandante es el nivel jerárquico más alto en el Sistema SAP. Las especificaciones que se realicen o los datos que se introduzcan en este nivel son válidos para todas las sociedades y para todas las otras estructuras organizativas. Por lo tanto, sólo necesita especificar estos valores o introducir estos datos una vez. De este modo se asegura de que los datos son coherentes.

Los usuarios deben introducir una clave de mandante cuando entran en el Sistema SAP. La clave define el mandante en el cual se desea trabajar. Se graban todas las entradas que hace por mandante. Se realiza también el análisis y el tratamiento electrónico de datos por mandante.

Para la configuración del Ministerio de Hacienda se configura el mandante en donde residirán y consolidaran la información Financiera y Logistica de todas las instituciones.

3.3.1.2 Sociedad (Cada Institución)

La unidad organizativa de contabilidad externa más pequeña para la que se puede crear un conjunto de

cuentas completo, autocontenido. Esto incluye la entrada de cualquier operación sujeta a contabilización y

la creación de todas las partidas para cierres individuales legales, tales como el balance y la cuenta de

pérdidas y ganancias.

La sociedad es la unidad organizativa de contabilidad externa centralizada dentro del Sistema SAP. Se debe

definir por lo menos una sociedad antes de implementar el componente Gestión financiera. Las operaciones

relevantes para Gestión financiera se introducen, se graban y se evalúan a nivel de sociedad.

Se crea normalmente una sociedad GL legalmente independiente en el Sistema SAP con una sociedad. Sin

embargo, puede definir también una sociedad según otros criterios. Una sociedad podría ser también un

centro de producción comercial separado, pero no independiente. Esto es necesario, por ejemplo, si el centro

de producción está situado en un país diferente y, por lo tanto, las evaluaciones tienen que realizarse en la

moneda nacional apropiada y de acuerdo con otras especificaciones legales y de impuestos.

La definición de la unidad organizativa de la Sociedad es obligatoria.

44

3.3.1.3 Plan de Cuentas

Se trata de una lista de todas las cuentas de mayor utilizadas por una o varias instituciones. Para cada cuenta

de mayor, el plan de cuentas contiene el número de cuenta, el nombre de la cuenta y la información que

controla cómo funciona una cuenta y cómo se crea una cuenta de mayor en una institución.

Se debe asignar un plan de cuentas a cada institución. Este plan de cuentas es el plan de cuentas operativo y

se usa para las contabilizaciones diarias en esta institución.

Al utilizar instituciones múltiples dispone de las siguientes opciones:

Puede usar el mismo plan de cuentas para todas las instituciones: Si todas las sociedades tienen las mismas

necesidades para la estructura del plan de cuentas, asigne todas las sociedades al mismo plan de cuentas.

Este podría ser el caso si todas las sociedades están en el mismo país de retención.

Además del plan de cuentas operativo, puede utilizar dos planes de cuentas adicionales: Si cada institución

requiere planes de cuentas diferentes, puede asignar hasta dos planes de cuentas además del plan de

cuentas operativo. Este podría ser el caso si las instituciones se encuentran en varios países de retención.

Los planes de cuentas pueden tener tres funciones diferentes en el sistema:

• Plan de cuentas operativo: El plan de cuentas operativo contiene las cuentas de mayor utilizadas para

contabilizar en la sociedad durante las actividades diarias. Gestión financiera y Controlling utilizan

este plan de cuentas. Se debe asignar un plan de cuentas operativo a una sociedad.

• Plan de cuentas de grupo: El plan de cuentas del grupo comprende las cuentas de mayor que utiliza

el grupo de instituciones completo. Esto permite que la sociedad GL proporcione informes para el

grupo de empresas completo. La asignación de un plan de cuentas de grupo de instituciones a una

sociedad es opcional.

• Plan de cuentas específico por país: El plan de cuentas específico por país contiene las cuentas de

mayor necesarias para satisfacer los requisitos legales del país de retención. Esto le permite

proporcionar certificaciones que cumplan los requisitos legales del país de retención. La asignación

de un plan de cuentas específico por país a una institución es opcional.

3.3.1.4 Crecimiento de instituciones a través de parámetros

3.3.1.4.1 Definicion de una institución

A través de SAP se pueden crear tantas instituciones como se consideren. Para SAP una institución es una

unidad organizativa en Contabilidad que representa una organización de acuerdo con los requisitos de la

legislación legal de un país en particular.

45

Una sociedad (institución) almacena datos básicos para cada institución en la definición de la sociedad. Solo

especifica funciones particulares cuando personaliza en Contabilidad financiera.

En el sistema SAP, las funciones de consolidación en la contabilidad financiera se basan en distintas

instituciones. Cuando se crea una entidad, debe tener en cuenta los siguientes puntos relacionados con la

contabilidad

• Las entidades deben estar catalogadas en una lista de ID de la entidad que sea coherente en todo

el grupo. Ejemplo un órgano rector generalmente proporciona esta lista de ID de instituciones.

3.3.1.4.2 Homlogación de instituciones con estructuras existentes

En SAP a través del proceso de copiado de sociedades (entidades) permite la homologación de las distintas

instituciones.

A través de la herramienta se permite copiar las características de una sociedad para que sean homologados

en otra. Esto tiene la ventaja de que también copia los parámetros específicos del código de la institución

existente. Si es necesario, puede cambiar ciertos datos en la aplicación correspondiente. Esto es mucho

menos lento que crear un nuevo código de institución.

Si no se desea copiar un código de institución existente, se puede crear un nuevo código de institución y

realizar todos los ajustes que se consideren. Se pueden definir los códigos de la institución especificando la

siguiente información:

Clave de código de la isntitución: Se puede seleccionar una clave alfanumérica de cuatro caracteres como

clave de código de la institución. Esta clave identifica el código de la institucion y debe ingresarse al

publicar transacciones o crear datos maestros específicos del código de la institución, por ejemplo.

46

Nombre del código de la institución

Datos de geográficos: Los datos de geograficos son necesarios para la correspondencia y se imprimen en

informes, como el retorno anticipado de impuestos sobre ventas / compras.

Moneda del país: Las cuentas deben ser administradas en la moneda nacional. Esta moneda también se

conoce como la moneda local o la moneda del código de la entidad. Las cantidades que se contabilizan en

moneda extranjera se convierten a la moneda local.

Clave de país: La clave del país especifica qué país se debe ver como el país de origen; todos los demás países

se interpretan como "en el extranjero". Esto es importante para las transacciones comerciales y de pago

porque se usan formularios diferentes para las transacciones de pagos en el extranjero. Esta configuración

también le permite usar diferentes formatos de dirección para correspondencia extranjera.

Idioma: EL sistema idioma para determinar el texto automáticamente en el idioma del país correspondiente.

Esto es necesario al crear comprobaciones, por ejemplo.

3.3.1.5 Consolidacion de información de las instituciones

La consolidación es el proceso de combinar datos de cierre individual de las entidades relevantes para

preparar el estado consolidado para un grupo de instituciones. Estos estados consolidados muestran la

posición financiera de acuerdo con la estructura del sector publico.

Dentro de la consolidación, las sociedades GL (instituciones) se combinan en subgrupos. La creación de

subgrupos tiene como objetivo lo siguiente:

• Poder agrupar las instituciones de acuerdo con criterios específicos; por ejemplo, según la línea

institucional, la estructura de la región (Europa, Asia, mundo, etc.) a las que pertenecen. Si se crean

informes en subgrupos, se cumplirán gran parte de los requisitos de información. Esto permite

asignar una entidad a varios subgrupos. En estos casos, la creación de un subgrupo es totalmente

flexible.

• Si se utilizan subgrupos, se pueden representar los niveles jerárquicos individuales que comprenden

una sociedad GL de varios niveles.

En una consolidación simultánea, se tienen en cuenta en una operación todas las instituciones (sociedades

GL) que van a incluirse en un grupo, ejemplo “Organo Rector”. Esto significa, por ejemplo, que la

consolidación de deudas, la consolidación de gastos e ingresos internos y la eliminación del resultado interno

de cada sociedad GL se reconcilian recíprocamente con cada sociedad GL en la consolidación con respecto a

las relaciones de interlocutores.

47

3.3.2 Cierre de una institución

Las tareas de cierre se repiten periódicamente y se pueden subdividir como se indica a continuación en la

Gestión financiera:

• Cierre del día

• Cierre del mes

• Cierre del ejercicio

Se puede utilizar el componente de tareas de cierre como ayuda para la preparación y la realización de las

actividades necesarias para el cierre. Con este propósito, el sistema proporciona varios informes estándar

que se pueden utilizar para crear evaluaciones y análisis directamente desde la lista de saldo contabilizada.

El sistema soporta las tareas de cierre siguientes:

• Periodificación de cuentas de gastos e ingresos

• Creación de los balances contables

• Documentación de los datos contables

Para efectuar tareas de cierre en la contabilida, antes debe realizarlas en los auxiliares que se utilicen Éstas

incluyen, por ejemplo:

• Deudores y acreedores

• Gestión de materiales

48

• Activos fijos

3.3.2.1.1 Cierre de dia

El cierre del día incluye todas las actividades necesarias al final del día para verificar si las operaciones

empresariales contabilizadas se han procesado correctamente. No se requiere ninguna contabilización

adicional para el cierre del día.

Para controlar la actualización de los datos en la base de datos, debe crear una lista de todas las

actualizaciones canceladas cada día.

3.3.2.1.2 Cierre de Mes

El cierre del mes comprende todas las actividades relacionadas con el cierre de un período contable.

Se puede llevar a cabo las siguientes actividades como parte de cierre del mes:

3.3.2.1.3 Abrir y cerrar períodos contables

Se puede llevar a cabo un cierre uno o varios períodos contables del pasado para la contabilización, y que

permite que se realice la contabilización para uno o varios períodos de contabilización actuales o futuros.

3.3.2.1.4 Crear informes externos.

Puede utilizar programas de informe para crear, por ejemplo, los informes siguientes:

• Balances contables

• Declaración de IVA

• Documentación de los datos de contabilización

Esto incluye los informes siguientes:

• Registro de la propiedad

• Historial de cuenta

• Control de cuentas

• Listas de saldos

• Lista de partidas abiertas

49

3.3.2.2 Cierre de Ejercicio

El cierre del ejercicio se divide en dos fases:

• Al inicio del nuevo ejercicio, se abren nuevos períodos de contabilización y se arrastran los saldos del ejercicio anterior.

• Entonces, se debe preparar y crear los balances contables, documentar las operaciones de la institución utilizando el historial de cuenta, y archivar aquellos documentos que ya no se necesiten online.

La primera contabilización del nuevo ejercicio abre automáticamente ese ejercicio. De todas formas, se debe haber abierto en primer lugar el período contable relevante.

El Sistema SAP ofrece un conjunto de informes con los que se puede arrastrar saldos al nuevo ejercicio. Durante este proceso las cuentas PyG se arrastran a una o más cuentas de arrastre de resultados. Los saldos de la cuenta de balance se arrastran, sencillamente, hasta el nuevo ejercicio. No es necesario crear balances especiales.

Cualquier contabilización que se efectúe en el ejercicio anterior ajustará automáticamente el saldo de arrastre relevante. No es necesario cerrar el ejercicio anterior ni efectuar las contabilizaciones de cierre antes de abrir el nuevo ejercicio.

De igual manera que con el cierre del mes, se podrán crear todos los informes externos necesarios, así como documentar los datos contables y llevar a cabo las evaluaciones internas.

50

3.3.2.2.1 Ejercicio

Normalmente, un período de doce meses para los cuales una institución (sociedad contable) crea

regularmente saldos y verifica inventarios.

El ejercicio puede coincidir exactamente con el año natural, pero esto no es obligatorio.

• Un ejercicio se divide en períodos contables. Cada período contable se define por una fecha de inicio

y una fecha de finalización. Antes de poder contabilizar documentos, hay que definir en el sistema

los períodos contables; éstos, a su vez, definen el ejercicio.

• Además de los períodos contables, también se pueden definir períodos especiales para el cierre del

ejercicio.

• En la Contabilidad principal, un ejercicio puede tener un máximo de doce períodos contables y cuatro

períodos especiales.

Para asignar actividades de la empresa a períodos de tiempo distintos, debe definir un ejercicio con períodos

contables. La definición del ejercicio es obligatoria.

Se debe definir un ejercicio como variantes de ejercicio que después asigna a su entidad. Una variante de

ejercicio pueden utilizarla varias entidades.

Para definir variantes de ejercicio dispone de las opciones siguientes:

• El ejercicio es equivalente al año natural.

• El ejercicio se diferencia del año natural (ejercicio desplazado). Los períodos contables también

pueden ser diferentes a los meses naturales

3.3.2.2.2 Periodos especiales

Períodos contables especiales que subdividen el último período contable normal para tareas de cierre,

independientemente de cómo se haya definido el ejercicio, también pueden utilizarse períodos especiales.

Los períodos especiales subdividen el período de cierre del ejercicio. Por lo tanto, dividen solamente el último

período contable en varios períodos de cierre. Esto permite crear varios balances suplementarios, o eventos

financieros de cierre de final de ejercicio como las auditorias financieras.

3.3.2.2.3 Determinacion de períodos al momento de la contabilización.

Al registrar un documento, introduzca también la fecha de contabilización. Al contabilizar el documento, el sistema utiliza la fecha de contabilización indicada para determinar automáticamente el período contable. El período contable consiste en un mes y un ejercicio.

51

Ambos se visualizan en el resumen de documento. El período contable determinado se introduce en el documento y las cifras de movimientos de este período se actualizan.

Si se desea visualizar el saldo de una cuenta, las cifras de movimientos se visualizarán individualmente según los períodos contables. Este proceso se ilustra a continuación:

3.3.2.2.4 Apertura y cierre de periodos contables

En SAP se debe definir los períodos contables en la variante de ejercicio. Se puede abrir y cerrar estos

períodos contables para contabilizar. Pueden abrirse tantos períodos como sean necesarios para contabilizar

simultáneamente.

Normalmente, sólo se abre el período contable corriente para la contabilización. El resto se cierran. Al final

de este período contable, se cierra el periodo y se abre el período contable siguiente.

Tiene las opciones siguientes para abrir y cerrar períodos de contabilización.

3.3.2.2.5 Variantes de períodos contables

Se puede especificar las instituciones que se abren para contabilizar en una variante de período contable. La

variante de período contable son multisociedades y deben asignarse a las sociedades. A continuación, los

períodos contables se abren y se cierran simultáneamente para todas las sociedades mediante las variantes

de períodos contables.

Se recomienda trabajar con variantes de períodos contables a los usuarios que tengan a su cargo un gran

número de sociedades. Ya que el período contable sólo se debe abrir y cerrar una vez para la variante, el

trabajo se reduce considerablemente.

3.3.2.2.6 Clase de cuenta

La apertura y el cierre de los períodos contables se puede diferenciar por clase de cuenta. Esto significa que

para un período contable en un momento de cierre, se puede especificar que se pueden permitir las

contabilizaciones en Cuentas por Cobrar, pero no en Cuentas por Pagar.

52

3.3.3 Catalogo de bienes ampliados Bansadonos en lo indicado en la PARTE A – REQUERIMIENTOS FUNCIONALES LOTE 1, Numeral 1.3 “Catálogo

de bienes ampliados” y los Sub-Numerales 1.3.1 al 1.3.2 de la Licitación Pública (Referencia: PAFI-CCC-LPN-

2018-0003) de Julio del 2018, procedemos a describir la solución que ofrece SAP que cubre los escenarios


SAP S/4HANA tiene la capacidad de parametrizar catálogos de bienes de uso y bienes de consumo de

acuerdo al requerimiento:

3.3.3.1 Bienes de Uso

Esta parte del registro maestro contiene información concreta sobre el bien (activo fijo). Existen los

siguientes grupos de campos:

o Información general (descripción, cantidad, etc.)

o Imputación

o Información de contabilización (por ejemplo, fecha de capitalización)

o Asignaciones temporales (por ejemplo, centro de coste)

o Información de mantenimiento

o Entradas para impuesto sobre el patrimonio (neto)

o Información de terrenos

o Condiciones de leasing

o Medidas de fomento a la inversión

o Información sobre el origen del activo fijo

o Datos de inventario

o Datos del seguro

o Campos de usuario/criterios de clasificación

Además, se pueden crear textos explicativos para grupos de campos individuales que pertenezcan a la parte

de datos generales del registro maestro de activo fijo. Puede simplificarse la creación de textos explicativos

utilizando máscaras de edición de texto explicativo libremente definibles por el Ministerio de Hacienda.

53

• Datos para calcular valores de bienes:

Pueden especificarse los parámetros de amortización en el registro maestro de activo fijo para cada una de

las áreas de valoración en el plan de valoración. Para que se puedan realizar estas especificaciones, el registro

maestro contiene un resumen de las áreas de valoración. Además, existe una visualización detallada

disponible para cada área de valoración. Si existen áreas de valoración que no son necesarias para un activo

fijo específico, es posible desactivarlas a nivel de activo fijo.

El siguiente gráfico muestra las condiciones de amortización más importantes dentro de un área de

valoración:

El sistema SAP permite realizar la búsqueda de un bien bajo múltiples características entre las que figuran:

• Clase de bien

• Denominación

• Centro de Coste

• Numero de Inventario

• Determinación de cuenta

Para facilitar su búsqueda a cada activo fijo se le asigna un número.

El número de activo fijo identifica únicamente a un activo fijo. Siempre consta del número principal del activo

fijo y su subnúmero. En el sistema existen dos formas de efectuar la asignación de números:

• Asignación de números externa

• Asignación de números interna

54

En el caso de la asignación de números externa, el usuario asigna directamente el número de activo fijo. El

sistema visualiza solamente el intervalo de números definido y emite un mensaje de error si el número ya

está asignado. En el caso de la asignación de números interna, el sistema asigna automáticamente números

consecutivos.

3.3.4 Contabilidad automática Bansadonos en lo indicado en la PARTE A – REQUERIMIENTOS FUNCIONALES LOTE 1, Numeral 1.1

Instituciones del Estado Dominicano y los Sub-Numerales 1.4 “Contabilidad Automatica” de la Licitación

Pública (Referencia: PAFI-CCC-LPN-2018-0003) de Julio del 2018, procedemos a describir la solución que

ofrece SAP que cubre los escenarios requeridos por el Ministerio de Hacienda de la Republica Dominicana:

Al ser SAP una solución totalmente integrada permite las contabilizaciones automaticas entre sus diferentes

componentes de solución.

3.3.4.1 Codigo de transacción

Al ser SAP una solución transaccional y analítica los codigos de las transacciones forman parte de su

estructura de funcionamiento. Cada componente de SAP posee la nomenclatura que sirve para identificar

cada una de las acciones que se ejecutan dentro del sistema. Estas transacciones son univocas y están

orieintadas a realizar una funcionalidad, siempre y cuando el usuario poseea las repectivas autorizaciones

para ejecutarlas.

Las transacciones son programas que se encargan de cumplir unas tareas en particular dentro del sistema

SAP, estas tareas se ejecutan mediante una sucesión de pantallas en las que debemos realizar una serie de

acciones para trasladar y traducir al sistema una tarea o proceso empresarial. Para ejecutar estos procesos

empresariales las transacciones envían ejecuciones de programas escritos en codificación ABAP.

Las transacciones estándar, independientemente del módulo al que pertenezcan, generalmente siguen la

misma nomenclatura y la primera letra de la transacción coincide con el módulo al que pertenecen. Por

ejemplo las transacciones del módulo de gestión de materiales MM empiezan con M, las del módulo de

finanzas FI empiezan con F, etc.

Las dos primeras letras indican la transacción y los dos números siguientes el tipo de acción. Los números

son “01” para crear, “02” para modificar y “03” para visualizar.

3.3.4.2 Parametrización Contable y Generacion Automatica

3.3.4.2.1 Bienes de Consumo

55

SAP en el componente de Gestion de Bienes de Consumo (MM) en la parametrizacion a la contabilización automática permite la configuración de las cuentas contables aplicadas en forma automática en los procesos de gestión de bienes de consumo que tiene impacto en la contabilidad mediante la generación de documentos contables.

Los procesos a los que se hace referencia son, fundamentalmente, los Movimientos de bienes y la Verificación de facturas de proveedores. En ambos casos, ambas etapas del Proceso de Compras, ya sea por la valorización del stock o la generación de una deuda con un proveedor, dan origen a documentos contables que recibe finanzas y que lo informan de esos movimientos del módulo gestión de bienes de consumo.

Las contabilizaciones automaticas vienen dadas por las determinación de cuentas, que no es mas que identificar que cuentas del catalogo de cuentas deben ser afectadas una vez se selecciona el tipo de movimiento que se realiza en el modulo de Bienes de Consumo (Materiales).

3.3.4.2.2 Bienes de Uso

En el caso del modulo de Bienes de Uso al igual que el modulo de Bienes de Consumo, los tipos de

movimientos que se realizan en el modulo, son de tipo automatico y afectan la contabilidad de manera

automática e inmediata.

Mediante el componente Bienes de uso, se pueden actualizar automáticamente todas las operaciones

relevantes para el libro mayor. Éstas comprenden todas las operaciones contables que se contabilizan en los

bienes de uso (activos fijos) y todas las modificaciones realizadas en los valores efectivos que el sistema

calcula automáticamente (especialmente, la amortización). Esta actualización se produce inmediatamente y

en modo interactivo para un área de valoración, o bien como parte de las operaciones periódicas del resto

de las áreas de valoración.

56

Al contabilizar con imputación a un bien de uso (activo fijo), el sistema determina la cuenta de mayor que

deberá contabilizarse a partir de cuatro elementos: el plan de cuentas válido en la sociedad, el área de

valoración que se debe contabilizar, la clave de asignación de cuentas y la clase de movimiento.

Basado en el requeriemiento del Ministerio de Hacienda de Republica Dominicana estos moviemientos

deberán integrase con el SIGEF por cada movimiento automatico y contable que se genere.

3.3.4.3 Proyección de la Contabilidad Automatica

Para SAP el tema de proyectar lo que se debe reflejar en el contabilidad es una actividad rutinaria, ejemplo

de ello es la ejecución de la amortización o depreciación de los bienes de uso. SAP otorga a los usuarios la

posibilidad de efectuar una ejecución de la amortización de manera proyectada de manera que el usuario

puede validar los impactos contables.

La simulación es la modificación experimental de los parámetros de amortización para todos bienes de uso

(activos fijos) o para un bien de uso determinado. Cuando se simula el desarrollo del valor de los bienes, se

pueden variar todos los términos de amortización importantes (clave de amortización, vida útil, series de

índices).

Existen varias aproximaciones que puede utilizar:

• La simulación de valores para un solo activo fijo mediante la modificación de los parámetros de

amortización, utilizando la transacción de visualización del valor del activo fijo. Hay dos parámetros

principales que pueden ser modificados:

o Términos de amortización (clave de amortización, vida útil, etc.)

o Movimientos

57

• Simulación de la amortización para futuros ejercicios para grupos de bienes de uso con la ayuda de

un report especial de simulación y una variante de simulación.

• Simulación de la amortización acumulada del pasado, utilizando una nueva área de valoración.

Nota: Las simulaciones o proyecciones no generan asientos contables.

3.3.4.4 Destino contable

En SAP el destino contable de las transacciones viene dada por la parametrizaciones que se lleven a cabo

en las determinaciones de cuentas de cada componente de la solución y que se debe parametrizar de

acuerdo con el plan de cuenta de la institución.

3.3.4.5 Reporte de Balance por institución y consolidado

En SAP se pueden diseñar los reportes de Balance por institución y consolidado en base a la disposición

jerárquica de cuentas de mayor.

• Es posible disponer las cuentas de acuerdo con las normativas legales utilizadas para crear los

balances.

• Otra alternativa puede consistir en disponer las cuentas de acuerdo con las necesidades del

usuario.

Es necesaria una estructura de balance/PyG para las funciones siguientes:

• Para crear e imprimir balances contables.

• Para ejecutar varios informes, como por ejemplo una lista estructurada de saldos.

• Como base para la planificación en la Contabilidad principal.

Se pueden definir diversas estructuras de balance/PyG. Esto puede ser necesario si se desea crear los

balances contables utilizando formatos diferentes.

El sistema estándar se suministra con estructuras de balance/PyG predefinidas. Podrá copiarlos o

modificarlos para sus propias estructuras.

En una estructura de balance/PyG existen ciertas posiciones que poseen un valor especial en el programa

de cálculo de resultados y en el sistema de información del libro mayor.

Si se está creando una estructura nueva, el sistema creará automáticamente una posición aparte para las

siguientes posiciones especiales de la estructura:

58

• Activo

• Pasivo

• Resultado neto: Beneficio, El saldo calculado para el resultado del balance se visualizará aquí si éste

es positivo.

• Resultado neto: Pérdida El saldo calculado para el resultado del balance se visualizará aquí si éste

es negativo.

• Resultado de la cuenta de pérdidas y ganancias:En este punto el sistema visualiza el saldo de todas

las cuentas que se pueden asignar a una posición, pero que no se encuentren en el activo ni el

pasivo.

• No asignado: El sistema visualizará todas las cuentas que no pueden asignarse a una posición

determinada.

El programa que crea los balances calcula el resultado neto del balance y el de la cuenta de pérdidas y

ganancias. Este programa también muestra una lista, en la posición "No asignado", de las cuentas que no se

pueden asignar a una posición en la estructura de balance/PyG.

Las pérdidas o ganancias del balance se establecen desde las cuentas de activo y pasivo, así como las cuentas

que son "no asignadas". El saldo de todas las cuentas corresponde al resultado de la cuenta de pérdidas y

ganancias.

El programa que crea el balance contable no realiza ninguna contabilización. Se limita a calcular las pérdidas

o ganancias del balance y de la cuenta de pérdidas y ganancias y a visualizarlas en los balances.

3.3.5 Trazabilidad de Datos


“Trazabilidad de Datos” y los Sub-Numerales 1.5.1 y 1.5.3 de la Licitación Pública (Referencia: PAFI-CCC-LPN-



SAP a través de la herramienta (AIS) del sistema de información de auditoría (AIS) es una herramienta de

auditoría que puede usar para analizar en detalle los aspectos de seguridad del servidor de aplicaciones

SAP NetWeaver (SAP NetWeaver AS) para el sistema ABAP.

AIS presenta su información en la estructura de información de auditoría (similar a la Guía de

implementación) para que pueda determinar fácilmente qué actividades necesita realizar y cuáles ha

realizado.

Las siguientes funciones están disponibles:

59

• Procedimientos de auditoría y documentación

• Evaluaciones de auditoría

• Descargas de datos de auditoría

AIS está diseñado para auditorías comerciales y auditorías de sistemas. La estructura de información de

auditoría está diseñada teniendo en cuenta estos tipos de auditorías y brindamos vistas predefinidas basadas

en estos tipos de auditoría. Puede modificar estas vistas o desarrollar las que el Ministerio de Hacienda

requiera propias.

SAP también ofrece el lugar de trabajo del sistema de información de auditoría (transacción SAIS), que

proporciona funciones de auditoría básicas en SAP NetWeaver Application Server para ABAP en una

disposición de estructura de menú más cómoda.

3.3.5.1 Log de resultados de trazabilidad

SAP NetWeaver Application Server (SAP NetWeaver AS) ABAP registra todos los errores del sistema,

advertencias, bloqueos de usuario debido a intentos fallidos de inicio de sesión de usuarios conocidos, y

procesa mensajes en el registro del sistema.

El registro del sistema es un marco para recopilar y registrar mensajes de las aplicaciones. El registro del

sistema es un buffer en anillo. Cuando el archivo de registro alcanza su tamaño máximo, el sistema

sobrescribe los datos más antiguos.

Se visualiza el registro del sistema (transacción SM21) para acceder a la pantalla de salida del registro del

sistema. Con esta transacción, puede leer cualquiera de los mensajes que están contenidos en los registros

del sistema. Puede modificar la vista según sea necesario.

Las aplicaciones priorizan sus mensajes de acuerdo con los siguientes niveles de gravedad:

• Muy alta prioridad

• Alta prioridad

• Advertencia

• Información

Puede configurar Visualizar el registro del sistema (transacción SM21) para mostrar solo los mensajes de

prioridad muy alta o todos los mensajes.

Puede cambiar los mensajes en Editar registro del sistema y Mensajes de registro de auditoría de seguridad

(transacción SE92).

60

3.3.6 Migración de Datos

Bansadonos en lo indicado en la PARTE A – REQUERIMIENTOS FUNCIONALES LOTE 1, Numeral 1.6 “Migración

de Datos” y los Sub-Numerales 1.6.1 y 1.6.2 de la Licitación Pública (Referencia: PAFI-CCC-LPN-2018-0003)

de Julio del 2018, procedemos a describir la solución que ofrece SAP que cubre los escenarios requeridos por

el Ministerio de Hacienda de la Republica Dominicana:

Junto con las innovaciones relacionadas con modelos de datos, interfaces de usuario, etc. en S / 4HANA, SAP

ha revisado la forma en que cargamos datos en SAP. La razón para crear una herramienta de migración

moderna y fácil de usar es simplificar y cumplir los siguientes desafíos y requisitos.

• Migrar datos de sistemas SAP / que no son de SAP a S/4HANA

• Proporcionar una solución de migración de datos sin necesidad de programación.

• Incorpora objetos personalizados de una manera fácil.

• Mapeo de datos entre el sistema de origen y el de destino.

• LSMW.

• Cabina de migración (MC).

• Migración Object Modeler (MOM).

• Rapid Data Migration (RDM) con servicios de datos.

El Migration Cockpit presenta un único punto de entrada donde, a través de procedimientos guiados, se

puede realizar la selección de datos, la transformación de datos y la monitorización. Proporcionó registros y

documentación para ayudar al usuario durante el proceso.

61

3.3.7 Interfaces para consolidar otros sistemas

Bansadonos en lo indicado en la PARTE A – REQUERIMIENTOS FUNCIONALES LOTE 1, Numeral 1.7 “Interfaces

para consolidar con otros sistemas” y los respectivos 1.7.1 y 1.7.3 de la Licitación Pública (Referencia: PAFI-

CCC-LPN-2018-0003) de Julio del 2018, procedemos a describir la solución que ofrece SAP que cubre los

escenarios requeridos por el Ministerio de Hacienda de la Republica Dominicana:

SAP NetWeaver Process Integration (SAP PI) es una de aplicacion empresariales (EAI) de software, un componente de la NetWeaver grupo de productos utilizados para facilitar el intercambio de información entre programas y sistemas internos de la institución y los de las partes externas. Antes de la versión actual, SAP PI se llamaba SAP Exchange Infrastructure (SAP XI) . Al igual que otros componentes de NetWeaver, SAP PI es compatible con productos de software de otras compañías. SAP llama a PI un intermediario de integración porque media entre entidades con requisitos variables en términos de conectividad, formato y protocolos. Según SAP, PI reduce el TCO al proporcionar un repositorio común para las interfaces. El componente central de SAP PI es SAP Integration Server , que facilita la interacción entre diversos sistemas operativos y aplicaciones en sistemas informáticos en red internos y externos. PI se basa en SAP Web Application Server . ¿Por qué necesitamos SAP PI? Aparte de Legacy Systems, en un gran establecimiento comercial, SAP no consiste en un solo sistema sino en varios sistemas integrados, es decir, CRM, SRM y FINANZAS-PRESUPUESTO, etc. Para manejar estas complejidades, SAP introdujo una plataforma de integración de procesos. Proporcionar un único punto de integración para todos los sistemas sin tocar la compleja red existente de sistemas heredados. Se trata de un middleware potente de SAP para proporcionar una integración perfecta de extremo a extremo entre aplicaciones SAP y no SAP dentro y fuera de los límites corporativos. SAP PI admite intercambios B2B y A2A, admite el intercambio de mensajes síncrono y asíncrono e incluye un motor integrado para diseñar y ejecutar procesos de integración.

62

El PI de SAP consta de una estructura de centro y enlace; los enalces se conectan con sistemas externos mientras que el centro intercambia mensajes entre ellos. El sistema fuente se conoce como el sistema emisor y el sistema objetivo se conoce como el sistema receptor. El PI no es un componente único, sino más bien una colección de componentes que funcionan juntos de forma flexible para implementar escenarios de integración. La arquitectura incluye componentes que se utilizarán en el momento del diseño, en el momento de la configuración y en el tiempo de ejecución. Podemos dividir el SAP PI en varias áreas:

• Servidor de integración

• Creador de Integración

• Paisaje del sistema

• Configuración y Monitoreo

Integration Server es el motor de procesamiento central de SAP PI. Todos los mensajes se procesan aquí de forma consistente. Consiste en tres motores separados

• Motor de integración

• Motor de adaptador

• Business Process Engine

Se puede considerar que el motor de integración es el concentrador y el motor. Integration Builder es un marco cliente-servidor para acceder y editar objetos de integración y consta de dos herramientas relacionadas:

• Enterprise Service Repository: para diseñar y desarrollar objetos para ser utilizados en escenarios

• Directorio de integración: para configurar los objetos de ESR para desarrollar escenarios Dos juntos, se crean procesos de integración que comúnmente se denominan escenarios. El System Landscape es un repositorio central de información sobre software y sistemas en el centro de datos y simplifica la administración del paisaje de su sistema. En Configuración y Monitoreo, podemos monitorear los mensajes y adaptadores.

3.3.8 Cumplimiento Regulatorio Bansadonos en lo indicado en la PARTE A – REQUERIMIENTOS FUNCIONALES LOTE 1, Numeral 1.8

“Cumplimiento Regularatorio” y sus respectivos 1.8.1 y 1.8.3 de la Licitación Pública (Referencia: PAFI-CCC-


requeridos por el Ministerio de Hacienda de la Republica Dominicana.

Impuesto

63

A nivel de impuesto existe el ITBIS (Impuesto a las Transferencias de Bienes Industrializados y Servicios) Es

un impuesto general al consumo tipo valor agregado que se aplica a la transferencia e importación de bienes

industrializados, así como a la prestación de servicios. En otros países este impuesto es llamado Impuesto al

Valor Agregado (IVA).

Tasa del Impuesto

En cumplimiento con lo establecido en los párrafos I y II del art. 23 de la Ley 253-12, la tasa del ITBIS a aplicar

a las transferencias de bienes gravadas y/o prestación de servicios a partir del 2016 será del 18%. A partir del

2016 se establece una tasa reducida del 16% del Impuesto a las Transferencias de Bienes Industrializados y

Servicios (ITBIS) para los bienes derivados de lácteos, de grasas animales o vegetales comestibles, derivados

de azúcares y de cacao y chocolate según se citan en el cuadro del párrafo II del art. 23.

Codigo Tipo de Rentencion

01 Alquileres 02 Honorarios por Servicios 03 Otras Rentas 04 Otras Rentas (Rentas Presuntas) 05 Intereses Pagados a Personas Juridica Residentes

06 Intereses Pagados a Personas Fisica Residentes 07 Retencion para Proveedores del Estado 08 Juegos telefonicos

3.3.8.1 Comprobantes fiscales

La nueva Norma General 07-18 tiene por objeto sustituir la Norma General No.06- 14 sobre remisión de

información, de fecha 25 de septiembre de 2014, incorporando cambios en cuanto a las informaciones

requeridas a través de los distintos formatos de envío que soportan las declaraciones juradas de los

contribuyentes.

Establecer un mecanismo de control de emisión de documentos por parte del contribuyente (facturas con

valor de crédito fiscal, facturas a consumidores finales, notas de débito y crédito) que permita la verificación

de los registros de sus ingresos por ventas y el control de los créditos por adelantos de ITBIS en compras

locales y servicios reportados, así como de los gastos deducibles para fines del Impuesto Sobre la Renta (ISR).

NCF Número de comprobantes fiscales

Ley 254-06: Documentos que acredita la entrega en uso, o la prestación de servicios, debiendo estos cumplir

siempre con los requisitos mínimos establecidos por el reglamento para la regulación de la impresión,

emisión y entrega de comprobantes fiscales

64

Estos reglamentos solo aplican para las empresas que se rigen bajo las regulaciones fiscales de la República

Dominicana y aplican para los clientes y proveedores exceptuando los proveedores gubernamentales.

La nueva composición de los números de comprobantes fiscales es de 11 caracteres que están estructurados

de las siguientes maneras:

Los tipos de comporbantes fiscales establecidos por la DGII son:

• Facturas Validas para crédito fiscal y/o que sustentan costos y gastos (01); son los comprobantes

fiscales que registran las transacciones comerciales de compra y venta de bienes y/o servicios, y

permiten alcontribuyente, deducir gastos y costos del ISR o crédito del ITBIS.

• Factura de Consumo (02) son los comprobantes fiscales que acreditan las transferencias de bienes,

la entrega en uso o la prestación de servicios a consumidores finales.

65

• Notas de Debito (03); son los documentos fiscales que emiten los vendedores de bienes y/o

prestadores deservicios para recuperar costos y gastos, tales como intereses por mora, fletes u otros,

incurridos por el vendedor con posterioridad a la emisión de comprobantes fiscales. Solo podrán ser

emitidas al mismo adquiriente o usuario.

• Notas de Crédito (04); son documentos que emiten los vendedores de bienes y/o prestadores de

servicios por modificaciones posteriores en las condiciones de ventas originalmente pactadas, es

decir, para anular operaciones, efectuar devoluciones, conceder descuentos y bonificaciones,

subsanar errores o casos similares.

• Comprobantes fiscales especiales; son documentos que podrán ser utilizados como

comprobantes fiscales, a los fines de evitar perturbaciones en el desarrollo de las actividades

económicas en aquellos sectores, actividades empresariales o profesionales autorizados por la DGII.

Los tipos de comprobantes especiales son:

Las regulaciones correspondientes a los comprobantes fiscales (NCF) abarcan tanto las operaciones de

Ventas y de compras de bienes y servicios.

3.3.8.1.1 Reporte 606

66

Reporte 606: Formato utilizado para reportar las compras de bienes y/o servicios que incluyen el número de

comprobante fiscal o el número de factura en su operación. Este reporte se debe enviar en cada periodo

fiscal del ejercicio.

• Remisión de Costos y Gastos (Formato 606). Las informaciones relativas a los costos y gastos para

fines del ISR, los adelantos utilizados como créditos para fines de ITBIS, las retenciones del ITBIS y del

ISR, realizadas a terceros, las percepciones cuando corresponda y el ITBIS llevado al costo, deberán

remitirse de conformidad al formato establecido en el Anexo A de la presente Norma General.

3.3.8.1.2 Reporte 607

Reporte 607: Formato utilizado para reportar las ventas de bienes y/o servicios que incluyen el número de

comprobante fiscal. Este reporte debe ser enviado en cada periodo fiscal del ejercicio. El formato de este

archivo se especifica en la norma 01-07.

• Remisión de ventas y operaciones (Formato 607). De conformidad a lo establecido en el formatodel

Anexo B de la presente Norma General, se deberán remitir las informaciones de ventas y operaciones

efectuadas y las retenciones del ITBIS y del ISR realizadas por terceros, sustentadas en facturas de

crédito y comprobantes especiales. También deberán remitirse las operaciones sustentadas en

facturas de consumo solo cuando tengan un valor igual o superior a los cincuenta mil pesos

dominicanos (RD$50,000.00), indicando el documento de identidad de la persona que adquiere el

bien o servicio.

3.3.8.1.3 Reporte 608

Reporte 608: para reportas los Números de Comprobantes Fiscales (NCF) anulados. El formato de este

archivo se especifica en la norma 01-07.

Comprobantes anulados (Formato 608). Los sujetos obligados deberán remitir un reporteconteniendo

los números de comprobantes fiscales que fueron anulados durante el período, especificando las razones de

la anulación de estos, de conformidad a lo establecido en el formato del Anexo C de la presente Norma

General.

3.3.8.1.4 Reporte 609

Reporte 609: Cuando se efectúen pagos al exterior por concepto de prestación de servicios, los sujetos

obligados deberán remitir mensualmente un reporte con el detalle de las transacciones de conformidad a lo

establecido en el formato del Anexo D de la presente Norma General.

3.3.9 Documentos e Imagines

67


Instituciones del Estado Dominicano y los Sub-Numerales 1.9.1 al 1.9.2 “Documentos e Imagenes” de la

Licitación Pública (Referencia: PAFI-CCC-LPN-2018-0003) de Julio del 2018, procedemos a describir la solución

que ofrece SAP que cubre los escenarios requeridos por el Ministerio de Hacienda de la Republica Dominicana:

A través de la herramienta SAP Extended Enterprise Content Management de OpenText, se puede manejar

el contenido de procesos completamente digitalizados e información en tiempo real. La aplicación SAP

Extended Enterprise Content Management (SAP Extended ECM) de OpenText cubre todo, desde la gestión

de documentos y registros hasta la recuperación de información y la colaboración mediante la conexión de

correos electrónicos, documentos y otro contenido a los procesos centrales.

Colaboración centrada en el proceso

Permite integrar con Microsoft Office 365 para admitir la coedición en línea, la integración del equipo de

Microsoft y más opciones de colaboración.

Aprovecha las características del espacio de trabajo empresarial para fortalecer la colaboración interna,

garantizar la divulgación precisa de la información y reutilizar el contenido corporativo tradicional.

Gestión de documentos

• Vincule cualquier parte del contenido electrónico a los procesos de negocio para que sea más fácil

encontrar y compartir contenido.

• Garantiza la precisión y vigencia de la información mediante el control de la versión del documento,

el control de acceso y las capacidades de seguimiento de auditoría.

• Ayudar a los usuarios a encontrar lo que necesitan, cuando lo necesitan

Captura de documento

• Administre los requisitos de escaneo con etiquetado de metadatos automatizado y escaneo de

imágenes mejorado.

• Admite los sistemas institucionales clave y todos los principales hardware de escaneo para convertir

los documentos en papel en activos comerciales digitales.

Gestión de registros

• Proporcionar un programa de administración de registros certificado que abarca múltiples sistemas

SAP y no SAP.

• Administra los registros electrónicos y físicos a lo largo de sus ciclos de vida

68

• Crea planes de clasificación, períodos de retención y políticas de disposición, y coloca los artículos

programados para destrucción en espera.

Acceso al contenido

• Recupera documentos relacionados con la empresa desde cualquier ubicación para garantizar un

flujo de información coherente y procesos globales eficientes.

• Integra contenido de múltiples sistemas SAP y no SAP para crear vistas virtuales orientadas a

procesos directamente en su sistema SAP

• Identifica instancias duplicadas de contenido dentro del sistema de archivos para eliminar copias

redundantes.

OpenText ™ Suite para SAP permite a las organizaciones combinar sus datos estructurados y no estructurados

para proporcionar una experiencia de usuario significativa, ya sea para apoyar procesos empresariales clave,

como proveedores o fuerza de trabajo, o proporcionar una plataforma para combinar los dos mundos de

contenido en una organización. Todos los elementos de su información empresarial (contenido estructurado

de SAP y datos no estructurados) están disponibles en el contexto de sus procesos comerciales, en cualquier

momento, en cualquier dispositivo.

Crea una mejor forma de trabajar, apoyando un mejor compromiso, productividad, control, innovación e

información. Cada producto está listo para conectarse a la arquitectura de la institución y a los procesos para

69

respaldar su implementación de SAP o sus necesidades. Las soluciones de OpenText son compatibles con

SAP Fiori / SAP Hybris y OpenText Smart UI, lo que garantiza la facilidad de uso y adopción para todos los

usuarios.

3.3.10 Calendario del Sistema


“Calendario del Sistema” de la Licitación Pública (Referencia: PAFI-CCC-LPN-2018-0003) de Julio del 2018,

procedemos a describir la solución que ofrece SAP que cubre los escenarios requeridos por el Ministerio de

Hacienda de la Republica Dominicana:

SAP indica qué datos de calendario de vacaciones y de fábrica puede llamar desde el sistema, en sus

desarrollos.

Visión de conjunto: Los calendarios específicos de ubicación se pueden definir en el sistema SAP. Pueden

contener festividades regionales y reglas de fábrica específicas de la ubicación.

Hay módulos de funciones con los que puede usar estos datos para las funciones. Las vacaciones se pueden

definir y recopilar en calendarios regionales de vacaciones. Un calendario de vacaciones se identifica en el

sistema mediante una ID de calendario de dos caracteres.

Un calendario de vacaciones se asigna a cada calendario de fábrica. También puede contener:

• Días laborables

• Reglas especiale

Los días especificados como días hábiles se numeran desde 0 (a menos que se especifique lo contrario). Estos

números son la fecha de fábrica. Puede acceder a la fecha del calendario directamente con la fecha de fábrica,

por ejemplo, para calcular las fechas de entrega.

El calendario de fábrica se identifica en el sistema mediante una ID de calendario de dos caracteres.

70

3.3.10.1.1 Calendario Intervalo de cuentas (Operaciones-Transacciones)

La apertura y el cierre de los períodos contables puede determinarse por intervalos de cuentas. Esto significa que sólo se abre un período contable para contabilizar en una cuenta específica que a su vez dada la integración esta se refiere a un modulo especifico, ejemplo al modulo de Bienes de Uso o Bienes de Consumo.

Los intervalos de cuentas se refieren siempre a cuentas de mayor. Si desea abrir cuentas auxiliares, introduzca la cuenta asociada correspondiente y la clase de cuenta.

Por ejemplo, durante las operaciones de cierre se pueden utilizar las cuentas asociadas para cerrar las

Cuentas por Cobrar y Cuentas por Pagar antes que las cuentas de mayor. Esto permite prevenir posteriores

contabilizaciones de dichas cuentas después de haber confirmado los saldos con los deudores y los

acreedores. La confirmación de saldos es una de las condiciones previas para continuar las operaciones de

cierre.

3.3.10.1.2 Calendario de Operaciones-Transacciones por usuario

En SAP se puede abrir y cerrar períodos contables sólo para usuarios específicos. Para ello, se debe

introducir un grupo de autorización en el nivel de la cabecera de documento.

3.3.10.2 Calendario Festivos

El calendario de festivos se utiliza en numerosas aplicaciones SAP y desempeña un papel importante en el

módulo SAP HCM.

En cualquier momento se puede visualizar o realizar cualquier modificación necesaria en el calendario de

festivos. El calendario de festivos en sap se basa en el año real y permite la aplicación de los modelos de

horario de trabajo a un período de tiempo específico.

71

En SAP, es esencial utilizar el calendario de festivos para registrar las presencias y absentismos de empleados,

el horario de trabajo: el programa de cálculo de nómina se puede ejecutar correctamente si se tienen en

cuenta el horario de trabajo en el cual está incluido el calendario de festivos.

El calendario de festivos en sap se crea según los días festivos nacionales y regionales válidos para las

subdivisiones y áreas de personal. También pueden registrarse en el calendario los días libres específicos de

la institucion.

3.3.11 Accesos

Bansadonos en lo indicado en la PARTE A – REQUERIMIENTOS FUNCIONALES LOTE 1, Numeral 1.11 “Accesos”

de la Licitación Pública (Referencia: PAFI-CCC-LPN-2018-0003) de Julio del 2018, procedemos a describir la

solución que ofrece SAP que cubre los escenarios requeridos por el Ministerio de Hacienda de la Republica

Dominicana:

Administración de usuarios y autenticación

El componente central SAP ERP utiliza los mecanismos de administración y autenticación del usuario

proporcionados con la plataforma SAP NetWeaver, en particular, el servidor de aplicaciones SAP NetWeaver.

Por lo tanto, las recomendaciones y pautas de seguridad para la administración de usuarios y la

autenticación, tal como se describe en SAP NetWeaver Application Server para la Guía de seguridad de ABAP,

también se aplican al componente central SAP ERP.

Además de estas pautas, incluimos información sobre la administración de usuarios y la autenticación que

se aplica específicamente al componente central de SAP ERP en los siguientes temas:

Administración de usuarios Este tema enumera las herramientas que se usarán para la administración de

usuarios, los tipos de usuarios requeridos y los usuarios estándar que se entregan con el componente central

SAP ERP.

Sincronización de datos de usuario Los componentes del componente central de SAP ERP pueden usar datos

de usuario junto con otros componentes. Este tema describe cómo se sincronizan los datos del usuario con

estas otras fuentes.

Integración en entornos de inicio de sesión único Este tema describe cómo el componente central de SAP

ERP admite mecanismos de inicio de sesión único.

Administración de Usuario: La administración de usuarios de SAP ERP Central Component utiliza los

mecanismos proporcionados por SAP NetWeaver Application Server para ABAP, como herramientas, tipos

de usuario y el concepto de contraseña. Para obtener una descripción general de cómo estos mecanismos se

aplican al componente central de SAP ERP, consulte las secciones a continuación. Además, brindamos una

lista de los usuarios estándar necesarios para operar los subcomponentes de SAP ERP Componente central.

72

3.3.11.1 Administración de usuario y rol de Application Server ABAP

Propósito: Utiliza las funciones de administración de usuario y rol de Application Server ABAP (AS ABAP) para

administrar usuarios, roles y autorizaciones en sistemas ABAP. Al asignar roles y autorizaciones, limita el

ámbito de acción de los usuarios individuales en el sistema.

Estructura: La documentación para el usuario y la administración de roles de Application Server ABAP (AS

ABAP) consta de las siguientes partes:

Concepto de autorización AS ABAP: Esta sección presenta los componentes de autorización con los que

funcionan la función y la administración del usuario.

Configuración de administración de usuario y rol: Esta sección describe la configuración de todos los

elementos de la función y la administración del usuario.

Administrar roles y usuarios: Esta sección describe todas las tareas de administración y los procedimientos

exactos de la administración de usuarios y autorizaciones.

3.3.11.2 Concepto de Autorización ABAP

El concepto de autorización de ABAP protege las transacciones, los programas y los servicios en los sistemas

SAP contra el acceso no autorizado. Sobre la base del concepto de autorización, el administrador asigna

autorizaciones a los usuarios que determinan qué acciones puede ejecutar un usuario en el sistema SAP,

después de que él o ella haya iniciado sesión en el sistema y se haya autenticado.

Para acceder a objetos comerciales o ejecutar transacciones SAP, un usuario requiere las autorizaciones

correspondientes, ya que los objetos comerciales o las transacciones están protegidos por objetos de

autorización. Las autorizaciones representan instancias de objetos de autorización genéricos y se definen

según la actividad y las responsabilidades del empleado. Las autorizaciones se combinan en un perfil de

autorización asociado a un rol. Los administradores de usuario luego asignan las funciones correspondientes

utilizando el registro maestro de usuario, de modo que el usuario puede usar las transacciones apropiadas

para sus tareas.

La siguiente figura muestra los componentes de autorización y sus relaciones.

73

3.3.11.3 Configuración de administración de usuario y rol

Al considerar la administración del usuario y la función en un sistema, hay una serie de tareas asociadas con

la configuración del sistema, tanto durante la instalación inicial como durante el ciclo de vida del sistema.

• Primer procedimiento de instalación: Antes de utilizar SAP NetWeaver Application Server (SAP

NetWeaver AS) ABAP de forma productiva, debe cumplir los requisitos previos para la administración

de usuarios.

• Configuración de usuarios y administradores de autorización: Dividir las tareas de administración de

usuarios entre varios administradores para garantizar la separación de tareas al asignar

autorizaciones.

• Configurar la herramienta de administración de roles: Configurar la herramienta de administración

de roles y decida cómo manejar las comprobaciones de autorización.

• Seguridad de inicio de sesión y contraseña en SAP NetWeaver AS para ABAP: Configurar las reglas de

contraseña, los parámetros del perfil de inicio de sesión y contraseña, la política de seguridad y los

modificadores de personalización para las contraseñas generadas.

74

• Reglas para nombres de usuario: Establezca las reglas que eliminen los resultados indeseables del

uso irrestricto de los caracteres Unicode para los ID de usuario.

• Protección de usuarios especiales: Proteja a los usuarios predeterminados del mal uso.

• Seguridad en grupos de sistemas: La configuración de autorizaciones requiere que considere el grupo

de sistemas: desarrollo, prueba y producción.

• Administración de roles: La administración de roles abarca las funciones disponibles para la

administración de roles y autorizaciones y la asignación indirecta de roles utilizando la estructura

organizacional.

• Administración central de usuarios (CUA): Al utilizar Administración central de usuarios, puede

mantener los registros maestros de usuario centralmente en un sistema. Los cambios en la

información se distribuyen automáticamente a los sistemas secundarios. Esto significa que tiene una

visión general en el sistema central de todos los datos del usuario en todo el panorama del sistema.

• Gestión de usuarios de DBMS: La administración de usuarios del sistema de administración de bases

de datos (DBMS) permite que SAP NetWeaver AS para ABAP administre usuarios y sus privilegios en

el DBMS.

• Repositorio central para datos de personalización: El objetivo de un repositorio central para datos

de personalización es proporcionar almacenamiento para datos específicos del usuario y roles

específicos sin tener que crear tablas de bases de datos adicionales. Esta información debe tenerse

en cuenta siempre que se cambien usuarios o roles.

• Directorio de Servicios: Con los servicios de directorio, varias aplicaciones en el entorno de TI pueden

acceder a información común en una ubicación central.

• Comprobación de cambios en las autorizaciones después de las actualizaciones: Habilite la

administración de roles con el generador de perfiles y realice un postprocesamiento general al

realizar la actualización.

• Personalizar autorizaciones basadas en escenarios: Habilite escenarios alternativos de autorización

entregados para las aplicaciones.

3.3.12 Consultas y Reportes

Bansadonos en lo indicado en la PARTE A – REQUERIMIENTOS FUNCIONALES LOTE 1, Numeral 1.12 “Consultas

y Reportes” de la Licitación Pública (Referencia: PAFI-CCC-LPN-2018-0003) de Julio del 2018, procedemos a

describir la solución que ofrece SAP que cubre los escenarios requeridos por el Ministerio de Hacienda de la

Republica Dominicana:

75

En SAP se pueden realizar las consultas en línea que se deseen y por la solución que se desee. Los campos de

selección que provee la solución facilitan al usuario efectuar las consultas que desee.

SAP provee de “Bliblotecas” de informes por cada área del componente de manera que facilita la búsqueda

de la información dependiendo del área que gestiona el usuario.

Todos los informes están contenidos en bibliotecas. Una biblioteca es una colección de características, ratios

base y ratios que se han seleccionado de todas las entradas de una tabla de Report Writer.

Una característica (denominada campo o dimensión en releases anteriores) es un campo no numérico. Una

cuenta, un centro de coste y una división son ejemplos de características.

Un ratio base (ratio en releases anteriores) es un campo de valor numérico. Ejemplos de ratios base:

moneda local, costes totales y volumen de actividad.

Un ratio consta de un ratio base y de una o varias características. Utilizando columnas predefinidas es

posible definir columnas estándar que puedan utilizarse a continuación reiteradamente en los informes.

Ejemplos de ratios: costes reales en el año en curso, costes plan en el año cerrado.

Los informes contenidos en la biblioteca sólo pueden utilizar las características, los ratios base y los ratios

que se han definido para esta biblioteca en concreto.

3.3.13 Analiticas


“Analiticas” y Numeral 1.14 “Reportes Dinámicos” de la Licitación Pública (Referencia: PAFI-CCC-LPN-2018-

0003) de Julio del 2018, procedemos a describir la solución que ofrece SAP que cubre los escenarios requeridos

por el Ministerio de Hacienda de la Republica Dominicana:

76

¿Qué es S / 4HANA Embedded Analytics?

Es la recopilación de todas las características analíticas integradas en SAP S / 4HANA Suite que permite a los

usuarios comerciales o usuarios finales realizar análisis en tiempo real o informes operativos sobre los datos

transaccionales en vivo. Viene con un conjunto de representaciones predefinidas y preempaquetadas de

datos operativos. Estas representaciones llamadas VDM (Modelos de Datos Virtuales) permiten a los usuarios

comerciales obtener buenos conocimientos de los datos.

Hay un nuevo conjunto de herramientas que se introdujo en SAP S/4HANA 1709. En 1709, SAP introdujo los

siguientes 5 mosaicos, que básicamente se incluyen en "DISEÑO DE INFORMES".

3.3.13.1 S / 4HANA Embedded Analytics y vistas de CDS

77

SAP S/4HANA embedded analytics es una colección de funciones de análisis y un conjunto de

representaciones de datos de autoservicio entregados de contenido SAP (es decir, modelos de datos

virtuales) para obtener información en tiempo real de los datos sin ningún conocimiento detallado de la

estructura de datos subyacente. El análisis integrado de S/4HANA puede integrarse directamente en

procesos comerciales transaccionales y puede ser consumido por aplicaciones de análisis independientes.

El objetivo es mejorar tanto la eficiencia como la efectividad del proceso comercial a través de la integración,

el análisis y la visualización de análisis y KPI, dentro del rango de la ejecución del proceso comercial.

Consiste en modelos de datos virtuales basados en vistas de CDS que cubren informes operacionales basados

en roles para líneas de negocios y viene con herramientas para usuarios comerciales, usuarios avanzados y

desarrolladores para analizar datos y administrar el ciclo de vida de los informes y KPI.

Modelo de datos virtual basado en vista CDS (VDM):

El Core Data Services (CDS) ofrece lenguajes y servicios específicos del dominio para definir y consumir

modelos de datos semánticamente ricos. SAP proporciona un conjunto de vistas de CDS para que sirvan

como la representación funcional de sus datos operativos (tablas transaccionales y de datos maestros de

SAP S / 4HANA).

Estos modelos de datos virtuales (VDM) son la base del sistema SAP S / 4 HANA y se utilizan tanto en los

procesos de negocio como en los análisis para acceder a los datos de las tablas físicas subyacentes. Es una

representación estructurada de vistas de CDS y sigue reglas de modelado coherentes.

Proporciona acceso directo a datos comerciales de SAP utilizando solicitudes estándar de SQL o OData. Estos

modelos de datos virtuales también se pueden usar para extraer datos del sistema SAP S / 4HANA a SAP BW.

S/4HANA Embedded Analytics

El análisis integrado de SAP S/4HANA es la recopilación de todas las características de análisis en S/4HANA

que permiten informes operativos sobre datos transaccionales en vivo, logrado mediante el uso de vistas de

CDS entregadas previamente por SAP.

El consumo de estas vistas de CDS se controla usando "anotaciones". Las anotaciones enriquecen los modelos

de datos de CDS con metadatos adicionales. Comienzan con @. Hay dos tipos de anotaciones. El primer tipo

de anotaciones proporciona metadatos que se aplican a toda la entidad de vista de CDS (por ejemplo,

especificar la configuración del búfer de tabla de una vista). Tales anotaciones se enumeran antes de la

declaración DEFINE VIEW. El segundo tipo de anotaciones se usa para influir en un solo elemento de la lista

de selección (por ejemplo, especificar un campo como Unidad de medida con @ Semantics.unitOfMeasure).

Las anotaciones de este tipo se especifican directamente antes del campo específico.

78

Las vistas de CDS se pueden usar en programas ABAP, así como para el procesamiento analítico, hay

anotaciones específicas que permiten esto. SAP ofrece más de 8,900 vistas de CDS como parte de S / 4HANA

sin costo adicional

Los componentes arquitectónicos clave del análisis integrado SAP S / 4HANA incluyen:

• Base de datos SAP HANA

• Modelo de datos virtual

• Motor analítico (SAP BW incorporado)

• Servicio OData

¿Qué es 1709 S / 4HANA (On-Premise):

Tras el éxito del producto SAP S/4HANA 1610, SAP lanzó 'SAP S / 4HANA 1709' a partir del 15 de septiembre

de 2017. El lanzamiento de SAP S 4HANA 1709 ahora está disponible en general. Esta versión se ejecuta en

SAP HANA 2, la segunda generación de la plataforma de base de datos en memoria de SAP, que admite

escalado horizontal y uso activo-activo para un mayor rendimiento. Esto permite a los clientes beneficiarse

de las últimas innovaciones en el sistema de base de datos.

3.3.14 Flujos de Procesos

Bansadonos en lo indicado en la PARTE A – REQUERIMIENTOS FUNCIONALES LOTE 1, Numeral 1.15 “Flujos

de Procesos” de la Licitación Pública (Referencia: PAFI-CCC-LPN-2018-0003) de Julio del 2018, procedemos a



3.3.14.1 SAP Business Workflow para S/4HANA

Fiori ha transformado radicalmente la Business Suite. Se ha confirmado que SAP puede simplificar

enormemente la interacción del usuario para un usuario de negocios y, al hacerlo, allana el camino para

facultar al usuario de negocios para lograr mucho más sin la necesidad de capacitación o documentación

adicional.

Para hacerlo, se debe replantear por completo "lo que se puede lograr", "cómo se puede lograr" y "qué

sacrificar" para que algo sea tan fácilmente consumible.

79

Al comienzo de esta revolución, el desarrollo del flujo de trabajo invirtió mucho tiempo en lluvia de ideas,

sesiones de pensamiento de diseño y un sinfín de introspección para llegar a un plan que respalde a la Suite

con sus nuevos y radicales requisitos.

3.3.14.2 El objetivo

SAP Business Workflow como plataforma para procesos de negocio tiene una base muy sólida y amplia. A

lo largo de los años, se ha ampliado para satisfacer las crecientes demandas de rendimiento de Suite, así

como sus ya impresionantes capacidades, mejoradas aún más por los proyectos de Customer Connection

donde los clientes y los consultores colaborativamente hicieron sugerencias de mejora que SAP codificó y

transfirió a versiones anteriores.

Por la naturaleza misma de las solicitudes de Customer Connection, ha confirmado que funcionalmente SAP

Business Workflow es increíblemente sólido. Pero la flexibilidad y la usabilidad podrían mejorarse. Por lo

tanto, para cumplir con los requisitos de S/4HANA, un enfoque que reutiliza las capacidades y el código

existentes pero que ofrece el uso de diferentes interfaces de usuario y la ampliación de la flexibilidad fueron

dos caminos que necesitaron un enfoque de desarrollo.

Soporte para el flujo de trabajo Usuario final

El usuario final del flujo de trabajo es el usuario que recibe las tareas del flujo de trabajo, realiza las

aprobaciones o completa los formularios. Entonces, el mejor lugar para mejorar su experiencia de usuario

80

es la bandeja de entrada. Hay otros blogs sobre My Inbox y cómo se simplifican radicalmente los negocios

diarios de los usuarios, por lo que no es necesario insistir en eso.

Vale la pena indicar:

• La interacción del usuario es simple e intuitiva

• My Bandeja de entrada se puede utilizar de fábrica (sin codificación) con casi todos los

flujos de trabajo existentes, un solo My Inbox entrega las tareas en un solo lugar,

independientemente del sistema de origen, las funciones para habilitar el uso diario

(sustitución, gestión de archivos adjuntos, gestión de fechas límite ...) se proporcionan de

fábrica.

3.3.14.3 Soporte para el propietario del proceso de flujo de trabajo

Las aprobaciones y las tareas de flujo de trabajo satisfacen un objetivo: el objetivo del proceso. Es el

propietario del proceso quien conoce este objetivo y tiene un gran interés en lograr este objetivo. El flujo de

trabajo es simplemente una herramienta para lograr este objetivo de manera constante, rápida y con bajos

costos. El nuevo requisito de S/4 HANA es proporcionar una experiencia de usuario al propietario del proceso,

para que ellos mismos puedan configurar el flujo de trabajo sin tener que descargarlo al departamento de

TI, que proporciona experiencia pero a costa del presupuesto y el tiempo. Empoderar al propietario del

proceso elimina estos costos, pero solo se puede lograr si la interacción del usuario es lo suficientemente

simple. Obviamente, hay algunos procesos que serán demasiado complicados para que el propietario del

proceso se automatice a sí mismo, pero hay muchos que sí pueden hacerlo.

S/4 Suite está habilitando esto, un escenario a la vez, y la aplicación Fiori Manage Workflows es lo que el

propietario del proceso usa para lograr esto. También le da al propietario del proceso la flexibilidad de

cambiar el proceso más a menudo de lo que se podría haber logrado al entregarlo al departamento de TI.

Por lo tanto, el propietario del proceso ahora es lo suficientemente ágil como para adoptar un proceso según

los requisitos locales o estacionales.

81

En la captura de pantalla anterior, puede ver que el usuario que creó este flujo de trabajo de aprobación en

tres pasos no necesitó un editor gráfico, o BPMN, sino que simplemente utilizó un asistente para definir el

proceso.

3.3.14.4 Notificaciones del Flujo de Trabajo

Una nueva forma de notificar a los usuarios acerca de las nuevas tareas son las Notificaciones automáticas

de flujo de trabajo. Estos se envían desde el centro de notificaciones Fiori 2.0. Sin ir a la aplicación My Box

de entrada, el usuario ve nuevas tareas rápidamente. Estas tareas incluso pueden manejarse directamente

sin tener que abrirlas. Es una solución poderosa que se puede configurar para cada flujo de trabajo. Por lo

tanto, puede optar por activ arlos para todos los procesos de flujo de trabajo o solo para los de tiempo crítico.

82

3.3.14.5 Worflow Analytics

También en el campo del análisis, se está haciendo el progreso necesario. De acuerdo con el concepto de

Fiori, las herramientas estan disponibles para monitorear los procedimientos de flujo de trabajo. Permitir a

los usuarios rastrear rápidamente problemas aquí y tomar medidas relevantes.

3.3.15 Almacenes


“Almacenes” de la Licitación Pública (Referencia: PAFI-CCC-LPN-2018-0003) de Julio del 2018, procedemos a



Almacén, número de almacén y tipo de almacén

Una unidad de organización que permita la diferenciación de stocks de material en un centro. Todos los datos

referentes a un almacén concreto se guardan a nivel de almacén. Esto afecta especialmente a los stocks de

almacén.

• Número de almacén: Clave alfanumérica que define un sistema de almacenamiento consistente en

varias unidades organizativas y técnicas (áreas de almacenamiento). Todos los datos de bienes

específicos de gestión de almacenes y relacionados con un número de almacén concreto se guardan

83

a nivel del número de almacén. Esto incluye, por ejemplo, los datos sobre paletización, entrada de

bienes y salida de bienes.

• Tipo de almacén: Un área de almacenamiento física o lógica que puede definirse para un almacén en

el sistema de gestión de almacenes (WM). Consta de una o más ubicaciones. Los tipos de almacén

difieren en función de los criterios técnicos e institucionales. Los siguientes ejemplos son típicos de

los tipos de almacén que se pueden definir utilizando el sistema WM.

o Área de entrada de mercancías.

o Área de salida de mercancías.

o Área de entrega.

o Almacén de estanterías.

Todos los datos del bien específicos de gestión de almacenes y en relación con un tipo de almacén concreto

se guardan en el nivel del tipo de almacén. Esto incluye, por ejemplo, las ubicaciones fijas así como las

cantidades máximas y mínimas de las ubicaciones.

Se pueden asignar diferentes almacenes a un centro. De todas formas, sólo se puede asignar un almacén por centro a un número de almacén. Los almacenes asignados a diferentes centros pueden gestionarse bajo el mismo número de almacén. En este caso también puede asignarse únicamente un almacén por centro a un número de almacén. Un número de almacén puede existir para varios almacenes físicos, los cuales son representados como tipos de almacén en el sistema de WM. Un tipo de almacén agrupa varias ubicaciones.

Una ubicación es la unidad física más pequeña que el sistema puede tratar.

En la siguiente representación gráfica aparece un ejemplo de estructura empresarial con almacenes, números de almacén y tipos de almacenamiento:

84

3.3.16 Historial de Transacciones

Bansadonos en lo indicado en la PARTE A – REQUERIMIENTOS FUNCIONALES LOTE 1, Numeral 1.19 “Historial

de Transacciones” de la Licitación Pública (Referencia: PAFI-CCC-LPN-2018-0003) de Julio del 2018,



A través de SAP S/4HANA se puede realizar las consultas de las transacciones efectuadas en cada una de las

soluciones, las consultas se realizan en línea y permiten a través del efecto “Drill Down” determinar con

precisión la trazabilidad de cada operación, una vez se determina la operación el usuario puede identificar

a través de los documentos que se generan tanto en la contabilidad como en el modulo original que esta

efectuando la operación.

Drilldown Reporting es un sistema de información orientado al diálogo que es capaz de analizar un conjunto

de datos de acuerdo con todas las características incluidas en la descripción de datos.

Puede usar los siguientes informes, entre otros:

• Informes para el análisis de estados financieros: Los análisis de estados financieros se basan en

versiones de estados financieros jerárquicos que se almacenan en la Gestión financiera. Puede

realizar análisis de varianza sobre la base de los datos reales y del plan (comparaciones anuales,

semestrales, trimestrales y mensuales).

• Informes de figuras clave: Los elementos del estado financiero de la versión del estado financiero

que se requieren para calcular cifras clave específicas se incluyen en los informes de cifras clave. Por

ejemplo, puede seguir los saldos de las cuentas individuales, determinar el índice de liquidez o

determinar las cifras clave de la versión de los estados financieros, como el índice de capital.

Puede crear sus informes utilizando la moneda local (moneda del código de la empresa) u otra moneda

paralela (como grupo, disco duro, índice o moneda de la empresa). Utiliza las cifras de transacción de cuenta

de mayor y las versiones de estados financieros como su base de datos.

3.3.16.1 Cabecera de Documento

En SAP todo documento que se origina posee los datos de identificación necesarios para poder conservar

en sistema la trazabilidad e historial requerido. Un ejemplo es cuando se registra una factura de proveedor

(Cuando se registra una factura recibida de acreedor, deben introducirse los siguientes datos de cabecera

de documento:

• Fecha de documento

85

• Fecha de contabilización

• Importe bruto de la facturaCuentas por Pagar) en dicha cabecera se deben cumplir los siguientes

requisitos.

Un ejemplo adjunto en la búsqueda de información de registros

3.3.17 Multi Monedas

Para cada importe monetario que se introduce en el Sistema SAP, se debe especificar una moneda. Las

monedas se expresan según las normas ISO, por ejemplo, DOP para el Peso Dominicano.

En Gestión financiera, es preciso especificar para cada una de las sociedades la moneda en la que deben

gestionarse los libros. Esta moneda es la moneda nacional de la sociedad, o sea, la moneda local (o moneda

de la sociedad). A partir de una vista de sociedad, todas las otras monedas son monedas extranjeras.

Puede gestionar libros en dos monedas paralelas además de la moneda local, por ejemplo, la moneda del

grupo o una moneda fuerte. Para más información, véase monedas paralelas.

Para que el sistema convierta importes en varias monedas, debe definir tipos de cambio. Para cada par de

moneda, se pueden definir tipos de cambio diferentes y a continuación distinguirlos utilizando tipos de

cotización.

Moneda local: Moneda del código de una compañía (moneda del país) en la que se administran los libros

contables locales.

86

Moneda extranjera: Una moneda que difiere de la moneda del código de institución (moneda del país).

3.3.17.1 Monedas Paralelas

En Gestión financiera, se pueden definir hasta dos monedas paralelas además de la moneda local. Por este

motivo, los libros están gestionados en estas monedas paralelas además de la moneda local.

Se pueden utilizar varios tipos de moneda diferentes como monedas paralelas. La moneda para un tipo de

moneda se define al definir las unidades organizativas.

Moneda del grupo: La moneda del grupo se define al definir el mandante. La moneda del grupo se utiliza en

los estados financieros consolidados.

Antes de que el proceso de consolidación pueda completarse, todos los valores en los estados financieros

individuales deben traducirse de la moneda local o de la transacción a la moneda del grupo.

Moneda de sociedad: La moneda de sociedad asignada a la sociedad.

Moneda fuerte: La moneda fuerte se define al definir el país al que se asigna la sociedad. Segunda moneda

específica del país utilizada en países con altas tasas de inflación. En los países de Caribe y Latinoamerica es

comúnmente la moneda dólar (USD).

Moneda-índice: La moneda-índice se define al definir el país al que se asigna la sociedad. Moneda teórica

específica del país utilizada en algunos países de alta inflación como moneda de comparación a efectos de

la presentación de informes legales.

Gestionar los libros en monedas paralelas tiene los efectos siguientes:

• Durante la contabilización, se ahorran también los importes en las monedas paralelas. Los importes

se convierten automáticamente, pero los puede introducir también manualmente.

• Se actualizan también las cifras de movimiento de cuentas de mayor en las monedas paralelas.

• Las diferencias de cambio resultan también en las monedas paralelas.

• Puede realizar también una valoración de moneda extranjera en las monedas paralelas

3.3.18 Anulación y reverso de transacciones


“Anulación y reverso de Transacciones” y sus respectivos Sub-Numerales 1.20.1 al 1.20.4 de la Licitación

Pública (Referencia: PAFI-CCC-LPN-2018-0003) de Julio del 2018, procedemos a describir la solución que

ofrece SAP que cubre los escenarios requeridos por el Ministerio de Hacienda de la Republica Dominicana:

87

En SAP Si ha ingresado un documento incorrecto, puede revertirlo, anulando así los elementos abiertos.

• Un documento solo se puede revertir si:

• No contiene elementos borrados

• Contiene solo artículos de clientes, proveedores y cuentas de mayor

• Fue publicado con la contabilidad financiera

• Todos los valores ingresados (el centro de costos y el código fiscal) siguen siendo válidos.

Hay dos formas de actualizar las cifras de transacción al revertir un documento:

• El documento y el documento inverso incrementan las cifras de débito y crédito de la transacción en la misma cantidad.

• Después de que se anula un documento, se muestra el saldo de la cuenta afectada como si el documento nunca se hubiera publicado. Importante, afecta el saldo, sin embargo el sistema muestra la trazabilidad del documento original y el documento anulado, con fechas de registro y responsable.

En general, publica el documento de anulación en el mismo período de contabilización que el documento original correspondiente. Si el período de publicación del documento de origen ya se ha cerrado, debe ingresar una fecha que corresponde a un período de publicación abierto.

3.3.19 Bienes de Consumo (Inventario)

Bansadonos en lo indicado en la PARTE A – REQUERIMIENTOS FUNCIONALES LOTE 1, Numeral 2 Bienes de

consumo (Inventario) de la Licitación Pública (Referencia: PAFI-CCC-LPN-2018-0003) de Julio del 2018

donde indica:

“Este módulo tiene por objetivo el control de todos los bienes de consumo adquiridos en cada institución del

Estado Dominicano a fin de facilitar el registro, mantenimiento y salida de almacén, así como la

administración centralizada por parte de los órganos rectores con todos los aspectos descritos en el presente

pliego”.

Se procede a describir la solución contenida en SAP para cumplir con los requerimientos funcionales

establecidos.

El bien se obtiene a partir de fuentes externas o internas según las necesidades determinadas por la

planificación de necesidades del bien de consumo (material). La entrega se introduce en la Gestión de stocks

como una entrada de mercancías. El bien se almacena (y se gestiona según la Gestión de stocks) hasta que

se entrega o se utiliza para fines internos (por ejemplo, para consumo).

88

Durante todas las operaciones, la Gestión de inventarios accede a los datos maestros (tales como los datos

maestros del bien) y a los datos de operaciones (tales como los documentos de compra) que comparten

todos los componentes de Logística.

Este componente trata las siguientes tareas:

▪ Gestión de inventarios por cantidad y valor. ▪ Planificación, entrada y documentación de todos los movimientos de mercancías ▪ Realización del Inventario.

Todas las transacciones que provocan una modificación en el inventario se introducen en tiempo real, igual

que las actualizaciones del inventario que se derivan de estas modificaciones. Puede obtener una visión

general del estado actual del stock de cualquier material en cualquier momento. Ello hace referencia, por

ejemplo, a stocks que:

▪ Se encuentran en el almacén. ▪ Ya se han pedido pero todavía no se han recibido. ▪ Se encuentran en el almacén, pero están reservados para la fabricación o para un

departamento o institución.

Si para un bien se precisa una subdivisión adicional por lotes, es posible dividir por lotes. Estos lotes se

gestionan individualmente en el inventario.

89

3.3.19.1 Registro de Bienes de Consumo (Datos Maestros)


consumo (Inventario) y los Sub-Numerales 2.1 Registro Bienes de Consumo y sus correspondientes numerales

comprendidos entre el 2.1.1 al 2.1.14 de la Licitación Pública (Referencia: PAFI-CCC-LPN-2018-0003) de Julio

del 2018.

Se procede a describir la solución contenida en SAP S/4HANA para cumplir con los requerimientos

funcionales establecidos.

Maestro de Bienes (Maestro de Materiales)

El maestro de materiales contiene información sobre todos los materiales que una institución almacena o

consume. Es la fuente principal de datos específicos de los bienes de consumo o almacen para la institución.

Esta información se almacena en registros maestros de materiales individuales.

Todos los componentes de Logística SAP utilizan el maestro de materiales. La integración de todos los datos

de material en un objeto de base de datos individual elimina el almacenamiento de datos redundantes. En

Logística SAP, los datos contenidos en el maestro de materiales son necesarios, por ejemplo, para las

siguientes funciones:

• En Compras, para la gestión de pedidos.

• En Gestión de inventarios, para la contabilización de movimientos de mercancías y el inventario.

• En Verificación de facturas, para la contabilización de facturas.

• En Planificación de la producción, para la planificación de necesidades, programación y la

planificación de trabajo.

Toda la información que una intitución necesita para gestionar un material se almacena en un registro de

datos del maestro de materiales, clasificado según diferentes criterios.

El usuario puede introducir y modificar casi todos los datos del registro maestro de materiales por sí mismo.

Sin embargo, hay informaciones que sólo el sistema puede actualizar. Por ejemplo, el sistema actualiza los

datos de gestión cuando se procesa un registro maestro de materiales y los balances de stock cuando se

contabilizan entradas o salidas de mercancías.

Los datos en un registro maestro de materiales se pueden dividir en dos clases:

• Datos de naturaleza puramente descriptiva: Éstos son los datos que contienen información como,

por ejemplo, la denominación, el tamaño y la dimensión.

90

• Datos que el sistema utiliza para ejecutar una función de control: La característica de planificación

de necesidades y el control de precio son ejemplos de este tipo de datos.

Como los diferentes departamentos de una institucion trabajan con el mismo bien de consumo (material),

pero cada departamento utiliza información diferente sobre ese bien, los datos de un registro maestro del

bien de consumo (material) están subdivididos en función del área de especialización.

Maestro de Bienes (Maestro de Materiales)

Los materiales que tienen los mismos atributos básicos se agrupan y se asignan a un tipo de material. De este

modo se pueden gestionar diversos materiales de manera uniforme según las necesidades de la institución.

Al crear un registro maestro de bienes, se debe asignar el bien (material) a un tipo de bien. El tipo de bien

determina atributos del bien concretos y tiene funciones de control importantes. Es, por ejemplo, un factor

que determina la secuencia de pantallas y la selección de campos en un registro maestro de bienes de

consumos (materiales).

91

Al crear un registro maestro de bienes, el tipo de bien seleccionado determina:

• Si el tipo de bien está pensado para un propósito específico, por ejemplo, como material configurable

o material de proceso.

• Si se puede asignar el número de bien interna o externamente.

• El rango de números de donde procede el número de bien.

• Las pantallas que se visualizan y la secuencia de visualización.

• Los datos de departamento que se pueden introducir.

• Qué clase de aprovisionamiento tiene el bien, es decir, si un bien es de fabricación propia o de

aprovisionamiento externo, o las dos cosas.

Junto con el centro, el tipo de bien determina la gestión de inventarios obligatoria del bien, es decir:

• Si las modificaciones de cantidad se actualizan en el registro maestro de bienes.

• Si las evaluaciones del valor también se actualizan en las cuentas de stock de gestión financiera.

• Además, las cuentas afectadas por un bien que entra o sale del almacén dependen del tipo de bien.

3.3.19.1.1 Codigo de barra del fabricante (Codigo EAN)

Al introducir una entrada de mercancías para un bien, también puede introducirse un código EAN/UPC

(número de artículo europeo/código de producto universal).

En el registro maestro de bienes, puede definirse uno o varios códigos EAN/UPC para cada unidad de medida.

Los números pueden asignarse de forma interna y externa.

Al introducir una entrada de bienes para un pedido, pueden especificarse los dos códigos EAN/UPC

siguientes:

EAN para UMP (unidad de medida de pedido): Durante la entrada de bienes para un pedido, el sistema

propone el código EAN/UPC para la unidad de medida de pedido. Si se introduce un código EAN/UPC distinto,

el sistema verifica si ese número ya existe para la unidad de medida en el registro maestro de bienes. Si no

existe, el sistema reacciona de la siguiente forma:

o Si los números se asignan de forma externa, se crea el nuevo código EAN/UPC (si es válido).

o Si los números se asignan de forma interna, el sistema emite un mensaje de error.

92

Control EAN: Para cualquier verificación, puede introducir otro código EAN/UPC para otra unidad de medida

(sugerencia: unidad de medida de almacén) además del código EAN/ UPC para la unidad de medida de

pedido. Si el código EAN/UPC todavía no existe, el sistema lo crea en el registro maestro de bienes siempre

que los números se asignen de forma externa.

Puede actualizarse el código EAN/UPC en la pantalla detallada de una posición o en la lista de selección de

posiciones (formato con EAN).

3.3.19.2 Transacciones


consumo (Inventario) y los Sub-Numerales 2.2 Transacciones y sus correspondientes numerales comprendidos

entre el 2.2.1 al 2.2.15 de la Licitación Pública (Referencia: PAFI-CCC-LPN-2018-0003) de Julio del 2018.

3.3.19.2.1 Movimiento de bienes

Operaciones que tienen como consecuencia una modificación en el inventario de los bienes de consumos.

Entrada de bienes

Una entrada de bienes, es un movimiento de bienes con el que se contabiliza la entrada de una bien desde un proveedor o desde fabricación. Una entrada de bienes comporta un aumento del inventario en almacén.

Salida de bienes

Una salida de bienes, es un movimiento de bienes con el que se contabiliza una toma o una salida de bienes, un consumo de bienes o un envío de bienes a un departamento u otra institución. Una salida de bienes comporta una reducción del inventario en almacén.

Traslado

Un traslado consiste en retirar un bien de un almacén y trasladarlo a otro almacén. Los traslados pueden producirse en un mismo centro o entre dos centros.

Traspaso

Un traspaso es un concepto general que hace referencia a los traslados y las modificaciones del tipo o la categoría de inventario de un bien. El hecho de que la contabilización se produzca o no junto con un movimiento físico es irrelevante. Ejemplos de traspasos:

o Traspasos de bien a bien

93

o Liberación del inventario en control de calidad

o Traslado de material de consignación al inventario propio de la institución.

3.3.19.2.2 Entrada de almacén – Recepción Total


consumo (Inventario) y los Sub-Numerales 2.2. Transacciones y el Sub-numeral 2.2.2.1 Recepción Total de la

Licitación Pública (Referencia: PAFI-CCC-LPN-2018-0003) de Julio del 2018, procedemos a describir la

solución que ofrece SAP que cubre los escenarios requeridos por el Ministerio de Hacienda de la


Las entregas de los proveedores son probablemente el resultado de pedidos iniciados por el departamento de compras.

Un pedido de compras no sólo es el documento con el que el departamento de compras solicita mercancías

al proveedor, sino que además constituye una importante herramienta de planificación y seguimiento para

los departamentos siguientes: Compras, Planificación de necesidades de material, Gestión de stocks y

Verificación de facturas (Cuentas a pagar).

Referencia a un pedido

Si se entrega un material para un pedido, es importante para todos los departamentos implicados que la entrada en el sistema de la entrada de mercancías haga referencia a dicho pedido, por los siguientes motivos:

• El departamento responsable de la entrada de mercancías puede verificar si la entrega corresponde realmente a la orden.

• El sistema puede proponer datos del pedido durante el registro de la entrada mercancías (por ejemplo, el material pedido, la cantidad, etc.) Esto simplifica la entrada de datos y su verificación (excesos de suministro y suministros incompletos).

• Se marca la entrega en el historial de pedido Esto permite que el departamento de compras supervise el historial de pedido e inicie procedimientos de recordatorio en caso de una entrega retrasada.

• La factura de acreedor se verifica según la cantidad pedida y la cantidad entregada.

• La entrada de mercancías se valora en función del precio del pedido o de la factura.

Almacén

Si el bien de consumo está destinado al almacén, el peticionario puede definir dicho almacén. El sistema propondrá el almacén de forma automática durante el registro de la entrada de los bienes, y el usuario puede aceptarlo o modificarlo. Si no se indica ningún almacén en el pedido, deberá especificarse uno al registrar la entrada de los bienes de consumo.

94

Las entradas de bienes de consumo para el almacén pueden contabilizarse en tres tipos de inventarios distintos:

• En el stock de libre utilización

• En el stock en control de calidad

• En el stock bloqueado

En el pedido es posible definir si el bien de consumo debe o no contabilizarse en el inventario en control de calidad. Sin embargo, en el momento de la recepcion de los bienes debe indicarse en qué tipo de inventarios se contabiliza el bien.

Se anexa un ejemplo de flujo de procesos de Gestion de Depositos por Entradas de Bienes, basados en las buenas practicas contenidas en SAP.

3.3.19.2.3 Entrada de almacén – Recepción Parcial


consumo (Inventario) y los Sub-Numerales 2.2. Transacciones y el Sub-numeral 2.2.2.2 Recepción Parcial de

la Licitación Pública (Referencia: PAFI-CCC-LPN-2018-0003) de Julio del 2018, procedemos a describir la


Dominicana:

Durante el registro de una entrada de bienes para un pedido de compras, el sistema propone la cantidad

abierta de pedido de la posición como cantidad recibida. Si la cantidad entregada es distinta a la cantidad

abierta de pedido, puede modificarse la cantidad propuesta.

Siempre que se introduce una posición de entrada de biens, el sistema compara la cantidad entregada con

la cantidad abierta del pedido de compras. Por lo tanto, el Sistema SAP puede determinar y notificar entrada

parciales inmediatamente.

3.3.19.2.4 Entrada de almacén – Recepción Productos Faltantes


consumo (Inventario) y los Sub-Numerales 2.2. Transacciones y el Sub-numeral 2.2.2.3 Recepción Productos

Faltantes de la Licitación Pública (Referencia: PAFI-CCC-LPN-2018-0003) de Julio del 2018, procedemos a



En el Sistema SAP estándar, se permiten la recepción de bienes faltantes o incompletos. El sistema interpreta

la cantidad ingresada como una entrega parcial y la acepta como tal. El sistema emite un mensaje de

advertencia en el que se indica que se ha producido un suministro incompleto.

95

La cantidad abierta de pedido es la cantidad que todavía debe entregarse para una posición de pedido. Se

calcula como la diferencia entre la cantidad pedida y la cantidad entregada hasta la fecha. Si ya se ha

entregado toda la cantidad de pedido o más, la cantidad abierta de pedido será igual a cero.

La cantidad abierta de pedido se ajusta de forma automática siempre que se reciben los bienes para una

posición de pedido o cuando se modifica la posición de pedido.

También es posible introducir en la posición de pedido un porcentaje de tolerancia para faltas en el suministro.

Cuando se recibe una cantidad de bienes de consumo que se encuentra dentro de los márgenes de tolerancia

para faltas en el suministro, la cantidad se interpreta como una entrega parcial y se acepta como tal. El

sistema no emite un mensaje de advertencia. Si la cantidad de entrada de mercancías es inferior a la

tolerancia para faltas en el suministro, el sistema emite un mensaje de advertencia.

Indicador de entrega final

El indicador de entrega final especifica si una posición de pedido de compras se considera cerrada. Esto

significa que ya no se esperan más entradas de bienes para dicha posición. Si se ha fijado el indicador de

entrega final, la cantidad abierta de pedido pasa a ser cero, aun cuando no se haya suministrado todos los

bienes.

Es posible definir que el indicador de "entrega final" se fije automáticamente en el pedido de compras, si:

• Se ha entregado la cantidad total.

• El suministro incompleto o el exceso de suministro se hallan dentro de las tolerancias.

Si un suministro incompleto está fuera de los márgenes de tolerancia, este indicador puede fijarse de forma

manual para la posición de pedido, durante la entrada referente a la entrada de biens, a fin de indicar que la

entrega para la posición de pedido debe considerarse completa.

Si se introduce una devolución o anulación para una posición cuyo indicador de entrega final ya se ha fijado,

de modo que la cantidad de entrega se sitúe por debajo del límite de tolerancia para faltas en el suministro,

el indicador de entrega final se anulará de forma automática. En este caso, el sistema emite un mensaje de

advertencia que informa de la anulación del indicador de entrega final. Si no se espera una nueva entrega,

se puede anular manualmente el indicador de entrega final. Después de hacerlo, el sistema ya no modificará

el indicador de entrega final automáticamente.

3.3.19.2.5 Entrada de almacén – Contabilización Automatica

Al contabilizar una entrada de mercancías, el sistema crea automáticamente un documento de bien (material) que se utiliza como comprobante del movimiento de mercancías.

96

En paralelo al documento del bien (material), el sistema crea un documento contable. El documento contable

contiene los apuntes contables (de las cuentas correspondientes) necesarios para el movimiento.Desde la

pantalla que visualiza el documento de material, es posible visualizar el documento contable.

Al registrar la entrada de los bienes, se puede imprimir el vale de acompañamiento de bienes (por ejemplo,

vale de entrada de bienes o vale de identificación de palet) al mismo tiempo.

Envío de un correo electrónico a Compras

Si en el pedido se ha fijado el indicador Mensaje EM, el encargado de compras recibe automáticamente un

mensaje que le informa de la entrega.

Actualización de stocks

Los inventarios que se actualizarán en el registro maestro de bienes dependerán del lugar de destino de los

bienes.

• Entrada de bienes en almacén: Si los bienes se destinan al almacén, el sistema aumenta el stock valorado

total y el tipo de stocks (por ejemplo, el stock de libre utilización) en la cantidad entregada. El valor de

inventarios se actualiza al mismo tiempo.

• Entrada de mercancías en consumo: Si las mercancías se destinan al consumo, sólo las estadísticas de

consumo se actualizan en el registro maestro de bienes. (Numeral 2.2.4 Documento de Gasto).

3.3.19.2.6 Salida de almacen por requisición

3.3.19.2.6.1 Solicitudes manuales

Bansadonos en lo indicado en la PARTE A – REQUERIMIENTOS FUNCIONALES LOTE 1, Numeral 2 Bienes de consumo (Inventario) y los Sub-Numerales 2.2. Transacciones y los Sub-numerales 2.2.3.1 al 2.2.3.4 Salida de almacen por requisición, de acuerdo a la licitación (Referencia: PAFI-CCC-LPN-2018-0003) de Julio del 2018, procedemos a describir la solución que ofrece SAP que cubre los escenarios requeridos por el Ministerio de Hacienda de la Republica Dominicana:

El sistema SAP permite a través de sus procesos estándar efectuar las solicitudes manuales de bienes de consumo. El sistema ofrece diferentes campos de imputación en la parte superior de la que le permite seleccionar e indicar el motivo de la salida del bien.

Existe la posibilidad de introducir datos de imputación adicionales en otros campos, o bien, estos datos adicionales se copian automáticamente desde el objeto de imputación. Mediante una imputación automática, el sistema determina la cuenta de mayor en la que se contabiliza el movimiento de mercancías. No es necesario introducir una cuenta de mayor a menos que se desee contabilizar el movimiento de mercancías en una cuenta diferente.

97

Con las solicitudes alguna persona del departamento que hace la solicitud registra una solicitud de pedido manualmente. La persona que crea la solicitud de pedido determina qué y cuánto debe pedirse, y la fecha de entrega.

3.3.19.2.6.2 Solicitudes automaticas

Son salidas de bienes planificadas, con esta clase de toma de bien, el sistema crea automáticamente una

reserva para los componentes planificados. Al introducir la salida del bien, puede indicar la referencia de la

orden o de la reserva. El sistema determina todos los componentes que se van a retirar.

3.3.19.2.6.3 Entregas de mercancía

Una vez cumplido el ciclo de autorización el administrador puede proceder a la entrega de los bienes. En

SAP se efectúa una orden al almacén para disponer de los bienes listos para la entrega en una fecha y con

un propósito determinado. Esto simplifica y acelera el proceso de salida de bienes.

Varios departamentos pueden solicitar una reserva de salida de bienes para varios objetos de imputación

(como centros de coste, órdenes, activos fijos, etc.).

3.3.19.2.6.4 Contabilizacion automática

Una salida de mercancías tiene los siguientes resultados en el sistema:

98

• Creación del documento de movimiento en la Gestion de Bienes (Materiales)

• Creación del documento contable

• Creación de un vale de acompañamiento de mercancías

• Actualización de inventario

• Actualización de cuentas de mayor

• Actualización de consumo

• Actualización de reserva

• Actualización en otras aplicaciones

• Creación de una necesidad de transporte al conectarse el sistema de Gestión de almacenes (de requerirse)

Creación de un documento de material

Al contabilizar una salida de mercancías, el sistema crea automáticamente un documento de material que

se utiliza como comprobante del movimiento de mercancías.

Creación de un documento contable

En paralelo al documento de material, el sistema crea un documento contable. El documento contable contiene los apuntes contables (de las cuentas correspondientes) necesarios para el movimiento.

Desde la pantalla que visualiza el documento de material, es posible visualizar el documento contable.

Creación de un vale de acompañamiento de mercancías

Al introducir la salida de bienes, puede imprimir, al mismo tiempo, el vale de salida de bienes.

Actualización de inventarios

Los siguientes inventarios quedan reducidos de acuerdo con la cantidad de salida:

• Inventario valorado total

• Inventario de libre utilización

• Inventario, si la salida de mercancías se introduce con referencia a una reserva o a una orden.

Desde el punto de vista de la planificación de necesidades, el inventario disponible permanece inalterado cuando se contabiliza una salida de bienes planificada, porque la cantidad tomada estaba reservada y, por lo tanto, no estaba disponible. Al contabilizar una salida de bienes sin referencia a una reserva o a un pedido,

99

el inventario disponible queda reducido consecuentemente, desde el punto de vista de la planificación de necesidades.

Actualización de cuentas de mayor

Al contabilizar la salida de mercancías, el sistema genera automáticamente los apuntes contables en las cuentas de la contabilidad.

Actualización de consumo

Además de provocar la actualización de los inventarios en el registro maestro de bienes, una contabilización de salida de bienes genera una actualización de las estadísticas de consumo si el bien está planificado con la Planificación de necesidades de bien.

La Planificación de necesidades del bien utiliza las estadísticas de consumo de un bien para elaborar pronósticos. Para ello, distingue entre tomas planificadas y tomas no planificadas.

Si la toma está planificada, se actualiza el consumo total. Si la toma no está planificada, se actualizan el consumo total y el consumo no planificado.

3.3.19.2.7 Salida de almacen por deterioro de mercancía


consumo (Inventario) y los Sub-Numerales 2.2. Transacciones y los Sub-numerales 2.2.4 al 2.2.4.4 Salida de

almacen por deterioro, de acuerdo a la licitación (Referencia: PAFI-CCC-LPN-2018-0003) de Julio del 2018,



3.3.19.2.7.1 Solictudes de Salida de almacen por deterioro de mercancía

Se puede efectuar una salidad de almacen de un bien si ya no se puede utilizar más, por ejemplo, porque:

• La calidad ha disminuido debido a que el bien ha permanecido en el almacén durante mucho tiempo.

• El bien ha caducado.

• El bien ha sido destruido (por ejemplo, un container de vasos de cristal cae de la carretilla elevadora

durante el transporte). Esto se debe introducir como un desguace.

En el Sistema SAP, una sallida de almacen por deterioro se contabiliza igual que una salida de bienes.

3.3.19.2.7.2 Disminucion de inventario

Se puede desicorporar bienes por deterioro a los tipos de inventarios señalados a continuación:

100

• Inventario de libre utilización

• Inventario en control de calidad

• Inventario bloqueado (reserva)

Un desguace tiene los siguientes resultados en el sistema:

• Queda reducido el inventario correspondiente. (Automatico)

• El valor del bien desincorporado se contabiliza desde la cuenta de existencias en la cuenta de

deterioro. (Automatico)

• Los costes del material desincorporado se asignan al centro de coste y cuenta

especificado.(Automatico)

• El valor utilizado es el valor del registro maestro de biens en el momento de la contabilización.

Consideraciones de los motivos de deterioro:

Descripcion de los motivos

a. Vencimiento, Averia, perdida, obsolescencia, robo o sustraccion

b. Siniestro: Ciclon, incendio, terremoto, inundaciones, destruccion

3.3.19.2.8 Salida de almacen por prestamos entre instituciones



almacen por prestamos entre instituciones, de acuerdo a la licitación (Referencia: PAFI-CCC-LPN-2018-0003)

de Julio del 2018, procedemos a describir la solución que ofrece SAP que cubre los escenarios requeridos por

el Ministerio de Hacienda de la Republica Dominicana:

En SAP si los centros están asignados a diferentes ámbitos de valoración que pertenecen a instituciones

diferentes, también puede producirse entre dos instituciones.

A diferencia del traslado de almacén a almacén, un traslado de centro a centro afecta de la siguiente forma

tanto a Finanzas como a la Planificación de necesidades:

Finanzas

101

Afecta a Finanzas siempre que ambos centros estén asignados a diferentes ámbitos de valoración. Esto

significa que un traslado no sólo comporta una actualización de cantidades, sino también una actualización

de valores (valor de inventarios, cuentas de mayor). De este modo, se crea un documento contable paralelo

al documento del modulo de material (bienes) para el traslado.

Planificación de necesidades

La planificación de necesidades se ve afectada porque toma en consideración una modificación del

inventario de centro.

Un traslado de sociedad a sociedad se contabiliza del mismo modo que un traslado de centro logistico a

Centro Logistico.

Este traslado puede introducirse mediante el procedimiento en una o en dos etapas.

Durante el traslado, se crean dos documentos contables además del documento de material:

• Un documento contable para la salida de almacén de la institucion de procedencia

• Un documento contable para el almacenamiento en la institucion de destino

• La contabilización de inventarios se compensa con una cuenta de compensación entre instituciones.

En este escenario se debe tomar en cuenta en centro de costos de la Seccion a la cual se esta efectuando el

préstamo. La determinación de cuentas al momento de efectuar el traslado deberá indicar si se desea llevar

como una cuenta por cobrar institucional o una cuenta de orden.

3.3.19.2.9 Salida de almacen por prestamos entre secciones institucionales



almacen por prestamos entre secciones institucionales, de acuerdo a la licitación (Referencia: PAFI-CCC-LPN-







Finanzas

102












Centro Logistico.






3.3.19.2.10 Salida de almacen por Devolución en Compras



almacen por prestamos entre secciones institucionales, de acuerdo a la licitación (Referencia: PAFI-CCC-LPN-



En SAP se puede registrar la devolución si, por alguna razón, se desean devolver bienes suministrados por

el proveedor (por ejemplo, debido a mala calidad o porque están dañadas), se puede utilizar esta función

para devolver los bienes, incluso si se ha contabilizado ya la entrada de los bienes.

Si el proveedor envía una entrega sustitutiva después de que se le hayan devuelto los bienes, se puede

hacer referencia a la devolución cuando se contabilice la entrada de bienes.

Al contabilizar una devolución, se pueden utilizar los documentos de entrega y notas de entrega detalladas.

Se puede contabilizar una devolución desde los tipos de inventarios siguientes:

103

• Stock de libre utilización

• Stock en control de calidad

• Stock bloqueado

• Stock bloqueado en la entrada de mercancías

Condiciones previas

Al introducir la devolución, debe hacer referencia al pedido o al documento de material para que el sistema pueda:

• Sugerir datos (por ejemplo, el almacén) para simplificar la entrada de datos.

• Verificar que la cantidad devuelta no exceda la cantidad entregada.

• Reducir la cantidad entregada hasta la fecha.

• Anular otras actualizaciones producidas (por ejemplo, para una entrada de bienes en consumo) cuando se introdujo la entrada de bienes.

Para poder introducir una devolución con referencia a un pedido, antes es preciso determinar si los bienes se han contabilizado en el inventario o en gasto, o si se han contabilizado en el inventario bloqueado en la entrada de bienes. Si se han contabilizado las bienes en un tipo de inventario particular en la entrada de bienes (por ejemplo, el inventarios en control de calidad), se deben devolver desde el mismo tipo de inventario.

104

3.3.19.2.10.1 Contabilizacion de Salida de almacen por Devolución en Compras

Creación del documento en el modulo de gestión de bienes de consumo (material):El sistema crea un documento de bien (material) para la devolución. Puede imprimir este documento como un vale de devolución de bienes. Puesto que se valora la devolución, el sistema crea también un documento contable.

La cuenta de existencias y la cuenta de mayor se actualizan:En el caso de una devolución, el sistema anula todas las actualizaciones de inventarios y de cuentas de mayor producidas durante la contabilización de la entrada de bienes.

Consideraciones de los motivos de devoluciones de bienes:

Descripcion de los motivos

a. No reúnen las características especificas en la orden de compra

b. Defectos y averias.

3.3.19.2.11 Cambio de tipo de inventario


consumo (Inventario) y los Sub-Numerales 2.2. Transacciones y los Sub-numerales 2.2.8 al 2.2.8. Cambio de

Inventario, de acuerdo a la licitación (Referencia: PAFI-CCC-LPN-2018-0003) de Julio del 2018, procedemos a



En SAP si un bien sufre modificaciones a lo largo del tiempo, de tal modo que deja de corresponder a las

características definidas en el registro maestro de bienes de consumo para coincidir con las características

de un número de bien distinto, debe realizar un traspaso de bien a bien.

Un traspaso de un bien a bien tiene como resultado una cantidad trasladada que se gestiona en un número

de bien diferente. Para el bien receptor ya debe existir un registro maestro de bienes (material).

Ambos bienes deben gestionarse en la misma unidad de medida de almacén si se desea realizar un traspaso de bien a bien.

105

Un traspaso de este tipo siempre se realiza en una etapa y sin planificación previa. La contabilización sólo puede realizarse del inventario de libre utilización del bien de salida al inventario de libre utilización del bien receptor.

3.3.19.2.12 Traslado entre instituciones


consumo (Inventario) y los Sub-Numerales 2.2. Transacciones y los Sub-numerales 2.2.9 al 2.2.9.5 Traslado

entre instituciones, de acuerdo a la licitación (Referencia: PAFI-CCC-LPN-2018-0003) de Julio del 2018,







Finanzas









Centro Logistico.


106





En este escenario se debe tomar en cuenta es la Cataegoria de Valoracion del bien en el Centro Logistico al

se esta efectuando el traslado. Es un moviento entre inventarios de bienes.

3.3.19.2.13 Traslados entre secciones instituciones


consumo (Inventario) y los Sub-Numerales 2.2. Transacciones y los Sub-numerales 2.2.10 al 2.2.10.5 Traslado

entre secciones instituciones, de acuerdo a la licitación (Referencia: PAFI-CCC-LPN-2018-0003) de Julio del

2018, procedemos a describir la solución que ofrece SAP que cubre los escenarios requeridos por el Ministerio

de Hacienda de la Republica Dominicana:





Finanzas











107


Centro Logistico.






3.3.19.2.14 Conversión de Inventario


consumo (Inventario) y los Sub-Numerales 2.2. Transacciones y los Sub-numerales 2.2.12 al 2.2.12.5

Conversión de Inventario, de acuerdo a la licitación (Referencia: PAFI-CCC-LPN-2018-0003) de Julio del 2018,



En SAP permite distinguir entre las siguientes unidades de medida de un bien:

Unidad de medida base: Esta es la unidad de medida en la que se gestionan los inventarios de un bien. El sistema convierte todas las cantidades introducidas en otras unidades a la unidad de medida base.

Unidades de medida alternativas: Cada departamento puede tener unidades de medida propias. Por ejemplo, Gestión de compras puede utilizar una unidad distinta a la de Gestión de almacenes. Todas las unidades de medida aparte de la unidad de medida base se denominan unidades de medida alternativas. El Sistema SAP admite las siguientes unidades de medida alternativas:

• Unidad de medida de pedido: Permite que un bien se pida en una unidad diferente de la unidad de medida base. La unidad de medida de pedido se propone automáticamente en las funciones de compras, donde puede ser modificada.

• Unidad de medida de salida: Unidad de medida en la que el bien sale del almacén. El sistema permite que se registren consumos, traslados, traspasos e inventarios en una unidad diferente de la unidad de medida base y de la unidad de medida de almacén.

108

3.3.19.2.15 Generacion de ordenes de compras planificadas


consumo (Inventario) y los Sub-Numerales 2.2. Transacciones y los Sub-numerales 2.2.12 al 2.2.15 Generación

de ordenes de compras planificadas, de acuerdo a la licitación (Referencia: PAFI-CCC-LPN-2018-0003) de Julio

del 2018, procedemos a describir la solución que ofrece SAP que cubre los escenarios requeridos por el

Ministerio de Hacienda de la Republica Dominicana:

Planificacion de necesidades (MRP)

109

La función principal de la planificación de necesidades de bienes es garantizar la disponibilidad de bienes de

consumo, es decir, se utiliza para el aprovisionamiento de cantidades necesarias en el momento oportuno a

efectos internos. Este proceso implica la supervisión de inventarios y, especialmente, la creación automática

de propuestas de aprovisionamiento para el departamento de compras.

El componente de MRP ofrece asistencia a los planificadores de necesidades en su área de responsabilidad.

El planificador de necesidades se encarga de todas las actividades relacionadas con especificar la clase, la

cantidad y el tiempo de las necesidades y, además, debe calcular para cuándo y para qué cantidad debe

crearse una propuesta de pedido para cubrir estas necesidades. El planificador de necesidades necesita toda

la información sobre inventarios, reservas de inventarios e inventarios sobre pedido para calcular las

cantidades y, además, necesita toda la información sobre los ciclos de aprovisionamiento para calcular las

fechas. El planificador especifica una planificación de necesidades y un procedimiento de cálculo del tamaño

de lote por bien adecuados para determinar las propuestas de aprovisionamiento. Bienes de Consumo –

Reportes.

3.3.19.3 Bienes de Consumo – Reportes


consumo (Inventario) y los Sub-Numerales 2.2.16 Reportes y Consultas de la Licitación Pública (Referencia:

PAFI-CCC-LPN-2018-0003) de Julio del 2018, los reportes que se identifican en el alcance son los

siguientes:

Nota: Los reportes que se indican se basan en los reportes dispuestos por SAP S/4HANA de manera

estándar, no están considerados reportes a la “medida”.

Nro Descripción Reporte o Consulta Observación

1 Productos disponibles, físicos y reservados Funcionalidad nativa (estándar) de la solución

2 Valor de inventario Funcionalidad nativa (estándar) de la solución

3 Productos por vencer Funcionalidad nativa (estándar) de la solución

4 Consumo por departamento Funcionalidad nativa (estándar) de la solución

5 Productos en préstamos por tipos Funcionalidad nativa (estándar) de la solución

6 Productos con traslados por tipos Funcionalidad nativa (estándar) de la solución

7 Devoluciones Funcionalidad nativa (estándar) de la solución

8 Motivo/sub-motivo de requisición Funcionalidad nativa (estándar) de la solución

110

3.3.19.4 Bienes de Consumo - Interfaces

Nro Descripción Interfaz Obervación

1 Interfaz con Portal de Compras y Contrataciones Subsanacion a la funcionalidad (Desarrollo)

2 Interfaz de Compras SIGEF Subsanacion a la funcionalidad (Desarrollo)

3 Interfaz con Contabilidad SIGEF Subsanacion a la funcionalidad (Desarrollo)

9 Productos por proveedor Funcionalidad nativa (estándar) de la solución

10 Salida por deterioro Funcionalidad nativa (estándar) de la solución

11 Consumos por institución y producto Funcionalidad nativa (estándar) de la solución

12 Existencia de cada producto valorado Funcionalidad nativa (estándar) de la solución

13 Devoluciones realizadas a proveedores Funcionalidad nativa (estándar) de la solución

14 Reintegros de artículos, traslados y artículos dados de baja Funcionalidad nativa (estándar) de la solución

15 Kárdex valorado por artículo Funcionalidad nativa (estándar) de la solución

16 Movimiento detallado por referencia mensual y acumulada.

Funcionalidad nativa (estándar) de la solución

17 Hoja de vida por articulo Funcionalidad nativa (estándar) de la solución

18 Código de barras: impresión y consulta Funcionalidad nativa (estándar) de la solución

19 Agotamiento por mala planeación Funcionalidad nativa (estándar) de la solución

20 Inventario en almacén Funcionalidad nativa (estándar) de la solución

21 Artículos recibidos en almacén Funcionalidad nativa (estándar) de la solución

22 Salidas de almacén Funcionalidad nativa (estándar) de la solución

23 Reporte de bienes de consumo para la comisión de ética Funcionalidad nativa (estándar) de la solución

111

3.3.19.5 Bienes de consumo – Otros puntos de atención

Nro Numeral en licitación Descripcion Obeservacion

1 2.2.5.3 Solicitud Se requiere que exista un flujo de

procesos para manejar niveles de

autorización de solicitudes

Evaluar la Estrategia de Liberación

del modulo de Gestion de Bienes de

Consumo (Materiales)



















3.3.20 Cuentas por Pagar (Gestión de Acreedores)

El componente de aplicación Contabilidad de acreedores registra y gestiona los datos de contabilidad de todos los acreedores. También es parte integrante del sistema de compras: Las entregas y las facturas se gestionan dependiendo de los acreedores. El sistema activa automáticamente las contabilizaciones en respuesta a las operaciones. Asimismo, el sistema proporciona los importes de las facturas al componente de aplicación Caja para optimizar la planificación de liquidez.

A los acreedores se les paga con el programa de pagos. Este programa soporta todas las vías de pago estándar (como cheques y transferencias) tanto de forma impresa como de forma electrónica (intercambio de soporte de datos en disco y archivo de datos).

Las contabilizaciones efectuadas en la Contabilidad de acreedores se registran simultáneamente en el libro mayor, donde las distintas cuentas de mayor se actualizan según el movimiento realizado (acreedores, anticipos, etc.). El sistema contiene la previsión de vencimientos y otros informes estándar que puede utilizar como ayuda en la supervisión de partidas abiertas. En la Contabilidad de acreedores existen listas de saldos, diarios, historiales de cuenta y otras evaluaciones internas para documentar las operaciones.

Entre algunas de sus funcionalidades, el módulo Cuentas por Pagar posee el programa de pagos, el cual es capaz de procesar tanto los pagos recibidos como los efectuados. El programa de pagos trata los pagos al extranjero y los pagos locales de acreedores y deudores creaando documentos de pago y proporcionando datos a los programas de impresión o transmisión de medios de pago. Estos programas de medios de pago imprimen una lista de pagos y formas de pago (por ejemplo, cheques) o bien crean soportes de datos en formato texto o los requeridos por la institución financiera.

112

El sistema estándar contiene formularios y programas de medio de pago para las vías de pago más comunes. También puede crear pagos en disco. Tenga en cuenta que los formularios de pago y los formatos de fichero varían de un país a otro y a veces incluso de un banco a otro, por ello se pueden diseñar nuevas formas de pago y modificar las existentes con la ayuda de las herramientas que ofrece SAPscript Estas herramientas se describen en la documentación Base.

En la Contabilidad de Acreedores todas las operaciones se contabilizan en cuentas y se gestionan mediante dichas cuentas. Deberá crearse un registro maestro para cada cuenta requerida. El registro maestro controla la forma en que el sistema graba y procesa las operaciones contables y contiene especificaciones propias de los acreedores, por ejemplo:

• Valores propuestos cuando se contabilizan posiciones en la cuenta. Por ejemplo, las condiciones de pago especificadas en el registro maestro se visualizan como valores propuestos en la entrada del documento.

• Valores para procesar operaciones contables. Por ejemplo, los datos bancarios y las vías de pago (cheque o transferencia bancaria, por ejemplo) son necesarios para realizar pagos automáticos.

• Valores para trabajar con registros maestros. Mediante la definición de grupos de autorización, se puede impedir a ciertos usuarios el acceso a una cuenta.

Además, la visualización de partidas individuales y la gestión de partidas abiertas se definen automáticamente para cada cuenta de acreedor. Al contabilizar operaciones contables en cuentas, el sistema actualiza automáticamente el saldo de cuenta e indica las partidas del documento que se han contabilizado en la cuenta. Por consiguiente, es posible ver el estado de cuentas y las partidas individuales de cada cuenta de acreedor.

Una de las maneras de integración identificada es la adquisición de Material de Consumo, si bien se requerirá interfaces, SAP provee flujos de procesos basados en la mejores practicas.

3.3.20.1 Datos Basicos

Bansadonos en lo indicado en la PARTE A – REQUERIMIENTOS FUNCIONALES LOTE 1, Numeral 3 Cuentas por

Pagar y los Sub-Numerales 3.1 Creación, de acuerdo a la licitación (Referencia: PAFI-CCC-LPN-2018-0003) de

Julio del 2018, procedemos a describir la solución que ofrece SAP que cubre los escenarios requeridos por el

Ministerio de Hacienda de la Republica Dominicana:

Los datos de los registros maestros de un Acreedor controlan cómo se contabilizan y procesan los datos variables de un acreedor. Los registros maestros de acreedor también contienen todos los datos necesarios para establecer relaciones empresariales con los acreedores.

El registro maestro no sólo se utiliza en las Finanzas, sino también en la Gestión de materiales. Si se almacenan los datos maestros de acreedor de forma centralizada y se comparten en toda la empresa, sólo deberán introducirse una vez. Actualizando los datos maestros de forma centralizada, se pueden evitar inconsistencias. Si uno de los acreedores cambia de dirección, deberá introducirse este cambio sólo una vez; así, los departamentos de contabilidad y compras tendrán siempre información actualizada.

113

Un registro maestro de acreedor contiene:

• La denominación del acreedor, la dirección, el idioma y los números de teléfono

• Los números de identificación fiscal

• Datos bancarios

• Los datos de control de cuenta, como el número de cuenta asociada de mayor de la cuenta de acreedor

• Las vías de pago y las condiciones de pago que se han establecido con el acreedor

• Datos de compras

3.3.20.2 Tipos de Cuentas por Pagar

A través de SAP la clasificación en Grupo de Cuentas en las Cuentas por Pagar soportan los motivos de las

Cuentas por Pagar requerida por el Ministerio de Hacienda de Republica Dominicana.

Los grupos de cuentas determinan:

• La clase de asignación de números

• Un rango de números para la asignación de números de cuentas

• Los campos que se visualizan y si la entrada de éstos es opcional u obligatoria (status del campo) al registrar o modificar los datos maestros de acreedor.

Para crear un registro maestro, se deberá especificar un grupo de cuentas. El grupo de cuentas no se puede modificar después de crear el registro maestro. No obstante, el responsable del sistema puede modificar dichas especificaciones del grupo de cuentas.

Contratos de servicios

Contribuciones y remuneraciones

Obras en proceso

Materiales y suministros

Propiedad planta y equipo

Pago en consignación

Numeración de los registros maestros

Cada registro maestro tiene un número unívoco. Este número se necesita para visualizar o modificar el registro maestro, así como para efectuar contabilizaciones en la cuenta de acreedor.

114

El número del registro maestro de acreedor se puede asignar interna o externamente. El sistema asigna los números internos, mientras que los números externos se registran manualmente al crear el registro maestro de acreedor. Los números externos pueden ser alfanuméricos.

El grupo de cuentas determina si los números de cuenta son internos o externos y el intervalo de números válido para un registro maestro de acreedor.

El sistema garantiza que los números asignados siempre sean unívocos. En la asignación interna, el sistema selecciona el siguiente número del intervalo. En la asignación externa, el sistema impide la entrada de un mismo número dos veces.

Formato de pantalla de los registros maestros de acreedor

Según la clase de datos de los acreedores que se guarde, se podrán adaptar las pantallas para introducir y actualizar los registros maestros de acreedor, y así satisfacer las necesidades de la institucion.

Hay cuatro tipos de status de campo:

• El campo está listo para la entrada (campo opcional)

• El campo deberá completarse (campo obligatorio)

• El campo únicamente se visualiza (campo de visualización)

• El campo está oculto

El grupo de cuentas determina el status de los campos de un registro maestro de acreedor. Al crear un registro maestro, se deberá especificar un grupo de cuentas. Cuando se introduce un registro maestro de acreedor, se debe efectuar una entrada en algunos campos.

Formato de pantalla de los registros maestros de acreedor

El componente de aplicación Acreedores suministra con pantallas predefinidas en las que se pueden introducir los datos maestros. El formato de estas pantallas se puede modificar mediante la definición del status de los campos del grupo de cuentas. Es posible:

• Ocultar un campo.

• Convertirlo en una entrada obligatoria (campo obligatorio).

• Convertirlo en una entrada opcional (campo opcional).

• Fijarlo únicamente para visualización.

3.3.20.3 Transacciones en Cuentas por Pagar

3.3.20.3.1 Nota de Debito

115


Pagar y los Sub-Numerales 3.2 Transacciones, Sub-Numeral 3.2.2 Nota de Debito de acuerdo a la licitación

(Referencia: PAFI-CCC-LPN-2018-0003) de Julio del 2018, procedemos a describir la solución que ofrece SAP

que cubre los escenarios requeridos por el Ministerio de Hacienda de la Republica Dominicana:

Registro Preliminar

Se pueden registrar de forma preliminar Notas de Debito antes de contabilizarlos. Esto es útil, por ejemplo, si los datos que se desea introducir son incompletos o si las funciones de registro y contabilización preliminar las llevan a cabo responsables diferentes (principio de verificación por dos o más personas).

Status de workflow

Una vez registrados de forma preliminar las Notas de Debito, aparecerá una ficha adicional de Workflow. En esta ficha se visualiza el status de tratamiento:

• Documento completado

• Liberado

• Liberación requerida

Luz de status

Después de seleccionar Intro, el sistema muestra el saldo de la factura/el abono registrados de forma preliminar en forma de una luz de status:

3.3.20.3.2 Nota de Credito

Se puede utilizar esta función para introducir facturas y abonos emitidos o recibidos. La transacción de

entrada de la Nota de Credito es una operación de pantalla individual. Esto significa que se pueden introducir,

apartar, registrar de forma preliminar y contabilizar documentos en una pantalla con una cantidad mínima

de entradas.

Los datos de contabilidad de acreedores se contabilizan en Acreedores. Desde allí, los datos se clasifican por

el acreedor y se ponen a la disposición de otras áreas, tales como el sistema de compras. Al contabilizar datos

en Acreedores, el sistema crea un documento y transfiere los datos introducidos al libro mayor.

3.3.20.3.3 Devolución de Fondos

SAP pemite la devolución de fondos, dicha devolución se puede compensar en base a las partidas abiertas

que poseea, sin embargo se puede permitir dicha devolución si:

• No comprende ninguna partida compensada.

116

• Sólo contiene partidas de deudor, de acreedor y de cuenta de mayor.

• Se contabilizó con la Gestión financiera.

Las contabilizaciones de anulación y de corrección se pueden marcar también como contabilizaciones

negativas. Las contabilizaciones negativas se utilizan para reducir las cifras de movimientos de cuentas de

acreedor.

3.3.20.3.4 Baja en cuentas

Existen dos maneras de contabilizar cifras de movimientos al anular un documento:

• El documento y el documento de baja en cuenta aumentan las cifras del Debe y del Haber del

movimiento en cuenta en el mismo importe.

• Después de de dar de baja el documento, se mostrará el saldo de la cuenta correspondiente como si

no se hubiera contabilizado nunca el documento.

3.3.20.3.5 Pago con captación directa

SAP a través del programa de pagos permite la gestión tanto de los pagos efectuados como de los recibidos.

Su flexibilidad permite definir las características de pago que varían de un país a otro, por ejemplo, las

especificaciones sobre la vía de pago, la forma de pago o el soporte de datos.

El sistema estándar contiene las vías de pago ordinarias y los correspondientes formularios, que se han

definido de manera diferenciada para cada institución.

Las vías de pago estándar son el cheque, la transferencia y el efecto.

Otras características especiales incluyen:

• La compensación de partidas abiertas entre deudores y acreedores

• Los pagos internos, es decir, que una sociedad realiza un pago centralizado por otras

• El pago o la compensación de cualquier tipo de partida abierta, por ejemplo, el traslado de anticipos

• La restricción del acceso al programa de pagos asignando autorizaciones

Órdenes de pago

Las órdenes de pago se crean cuando se debe realizar un pago pero el pago no se contabilizará hasta que el

banco con el cual el Ministerio de Hacienda le envíe el extracto de cuenta.

117

Para el período comprendido entre la ejecución de pagos y el momento en el que se procesa su extracto de

cuenta, las partidas individuales abonadas deben marcarse de un modo que no den lugar a que se vuelvan

a pagar en otra ejecución de pagos.

El programa de pagos crea por lo tanto órdenes de pago. Se asigna un número unívoco a cada orden de pago

dentro del mandante. Una orden de pago está formada por datos de cabecera y datos de partida individual.

Los datos de cabecera incluyen la institución pagadora, el importe de pago, la vía de pago y la cuenta del

banco propio. Un registro individual se almacena en los datos de la partida individual para cada partida

individual pagada. Además de la clave de partida individual (número de documento, institución, ejercicio y

partida individual) este registro contiene el importe bruto, la deducción del importe del descuento y el

importe de la retención de impuestos.

El número de orden de pago se registra en la forma de pago o en el soporte de datos. Este número aparece

donde aparecería normalmente el número de documento de pago si el programa de pagos hubiera acabado

de crear la contabilización del pago.

Este número aparece impreso en el extracto de cuenta de su banco propio y le permite ubicar las posiciones

pagadas, de una forma fácil y rápida, en la orden de pago. Las posiciones se anulan cuando se contabiliza el

extracto de cuenta.

3.3.20.3.6 Registro de Cuentas por Cobrar

En SAP si se selecciona un acreedor que también es un deudor al tratar una operación de compensación

como, por ejemplo, una entrada/salida de pagos o una actualización de cuentas, el sistema también

marcará automáticamente las partidas abiertas de acreedor, a condición de que:

• El número de acreedor se haya introducido en el registro maestro de deudor

• El indicador Compensación con acreedor se haya configurado

• La misma norma se aplica si se selecciona un acreedor que sea también deudor durante una operación de compensación.

3.3.20.4 Cuentas por Pagar – Reportes


Pagar y los Sub-Numerales 3.3 Reportes y Consultas de la Licitación Pública (Referencia: PAFI-CCC-LPN-

2018-0003) de Julio del 2018, los reportes que se identifican en el alcance son los siguientes:

Nota:

1) .Los reportes que se indican se basan en los reportes dispuestos por SAP S/4HANA de

manera estándar, no están considerados reportes a la “medida”.

118

2) La ampliación a la funcionalidad siginifica que “Cumple” con los requisitos con apliaciones al

sistema.

3.3.20.5 Cuentas por Pagar – Interfaces


1 Interfaz con Contabilidad SIGEF Ampliación a la funcionalidad (Desarrollo)

2 Interfaz cin ERP Instituciones Ampliación a la funcionalidad (Desarrollo)


1 Cuentas por Pagar Por Institución, Cuenta contable,

Sector, tipo, beneficiario, etc.


2 Vencimientos e Histórico De las Cuentas Por Pagar en

base a fecha de compromiso


3 Pagos realizados a Proveedores Funcionalidad nativa (estándar) de la solución

4 Retenciones y Acumulaciones y sus beneficiarios por

estatus


5 Administración y detalle de los Fondos de Terceros Funcionalidad nativa (estándar) de la solución

6 Obtención de Estados de Cuentas de Proveedores Funcionalidad nativa (estándar) de la solución

7 Información sobre descuentos en compras Funcionalidad nativa (estándar) de la solución

8 Deuda de cada institución con proveedores de bienes

y servicios


9 Cuentas por pagar y su vencimiento para Contraloría

mensual.


10 Cuenta por pagar de la institución para el portal de

transparencia

Ampliación a la funcionalidad (Desarrollo)

11 Certificación de impuestos por retención. Ampliación a la funcionalidad (Desarrollo)

12 Reporte regulatorio 606 y 607 Ampliación a la funcionalidad (Desarrollo)

119

3 Interfaz con sistema de Tesoreria Nacional Ampliación a la funcionalidad (Desarrollo)

4 Interfaz con sistema de Presupuesto Ampliación a la funcionalidad (Desarrollo)

5 Interfaz con sistema de Nomina Ampliación a la funcionalidad (Desarrollo)

3.3.21 Cuentas por Cobrar


Cobrar y los Sub-Numerales 4.1. al 4.3 Creacion de acuerdo a la licitación (Referencia: PAFI-CCC-LPN-2018-


por el Ministerio de Hacienda de la Republica Dominicana:

El componente de aplicación Cuentas por Cobrar registra y gestiona los datos de contabilidad de todos los deudores. Y es donde se manejaría en unión con el área de Ventas los límites de crédito.

Todas las contabilizaciones efectuadas en la Contabilidad de deudores se registran directamente en el libro mayor. Las diferentes cuentas de mayor se actualizarán dependiendo de la operación efectuada (por ejemplo, créditos, anticipos, efectos, etc.). El sistema contiene un abanico de herramientas que pueden ser utilizadas para supervisar partidas abiertas, por ejemplo, análisis de cuentas, informes de aviso, listas de vencimientos y un programa de reclamaciones flexible.

La correspondencia vinculada a estas herramientas se puede diseñar individualmente para adecuarse a las necesidades del usuario. Esto también se puede aplicar a las notificaciones de pago, confirmaciones de saldo, extractos de cuenta y cálculos de intereses. La entrada de pagos se puede asignar a créditos vencidos utilizando las funciones de pantalla de fácil manejo. El programa de pagos puede efectuar automáticamente débitos bancarios y anticipos.

Un conjunto de herramientas se encuentra disponible para documentar las operaciones realizadas en la

Contabilidad de deudores, incluidos listas de saldos, diarios, historiales de cuenta y otros informes estándar.

Al preparar los balances, se revalúan las partidas en moneda extranjera, se enumeran los deudores que

también son acreedores y se clasifican los saldos de cuentas por tiempo restante hasta vencimiento.

En Cuentas por Cobrar no es únicamente una de los auxiliares de finanzas que constituye la base de la

contabilidad en regla. También proporciona los datos necesarios para una gestión de créditos eficaz, así como

la información importante para la optimización de la planificación de liquidez, (a través de su enlace con el

componente Caja).

A través de Cuentas por Cobrar es posible almacenar los datos maestros de deudor de forma centralizada,

se permite un acceso total dentro de la empresa y se evita la necesidad de introducir la misma información

por duplicado. La actualización de los datos maestros de forma centralizada evita inconsistencias. Si, por

ejemplo, un deudor cambia de dirección, sólo deberá introducirse esta modificación una vez; de este modo,

los departamentos de contabilidad y ventas siempre tendrán información actualizada.

120

El registro maestro controla la forma en que el sistema graba y procesa las operaciones contables y contiene

especificaciones propias de los deudores, por ejemplo:

• Valores propuestos cuando se contabilizan posiciones en la cuenta. Por ejemplo, las

condiciones de pago especificadas en el registro maestro se visualizan como valores

propuestos en la entrada del documento.

• Valores para tratar operaciones como datos de control de cuentas, tales como el número de

la cuenta asociada a la cuenta de mayor. Por ejemplo, el procedimiento de reclamación, la

fecha de la última reclamación y la dirección son necesarios para el proceso de reclamación

automática.

• Valores para trabajar con registros maestros, mediante la definición de grupos de

autorización, se puede impedir a ciertos usuarios el acceso a una cuenta.

• Valores para comunicarse con el deudor. Por ejemplo, la dirección y los números de teléfono.

121

3.3.21.1 Datos Basicos – Cuentas por Cobrar

En el Sistema SAP, todas las operaciones se contabilizan y gestionan en cuentas. Deberá crearse un registro

maestro para cada cuenta requerida. Dicho registro incluirá información de control sobre el modo con que

el sistema registra y procesa las operaciones. También incluye toda la información relativa al deudor con el

que se necesita establecer una relación empresarial.

Al almacenar los datos maestros de deudor de forma centralizada, se permite un acceso total dentro de la

institución y se evita la necesidad de introducir la misma información por duplicado. La actualización de los

datos maestros de forma centralizada evita inconsistencias. Si, por ejemplo, un deudor cambia de dirección,

sólo deberá introducirse esta modificación una vez; de este modo, los departamentos de contabilidad y

ventas siempre tendrán información actualizada.

Características

Se utilizan las especificaciones indicadas en los registros maestros:

Como valores propuestos cuando se contabilizan posiciones en la cuenta: Por ejemplo, las condiciones de

pago especificadas en el registro maestro se visualizan como valores propuestos en la entrada del

documento.

Para tratar operaciones: Datos de control de cuentas, tales como el número de la cuenta asociada a la cuenta

de mayor. Por ejemplo, el procedimiento de reclamación, la fecha de la última reclamación y la dirección son

necesarios para el proceso de reclamación automática.

Para trabajar con registros maestros: Mediante la definición de grupos de autorización, se puede impedir a

ciertos usuarios el acceso a una cuenta.

Para comunicarse con el deudor: Por ejemplo, la dirección y los números de teléfono y fax.

3.3.21.1.1 Motivos de Cuentas por Cobrar

En SAP en la solución de Cuentas por Cobrar permite la clasificación por el grupo de cuentas asegura que se visualizan únicamente las pantallas y los campos relevantes y listos para la entrada de cada una de las funciones de interlocutor diferentes del deudor. Por ejemplo, los campos de datos bancarios, comunicación y dirección se omiten para el grupo de cuentas.

Características

El grupo de cuentas controla:

• La clase de asignación de números utilizada para el número de cuenta.

122

• Un intervalo de números desde el que se ha seleccionado el número de cuenta. El sistema utiliza el

número de cuenta para identificar al deudor.

• Los campos que se visualizan al introducir o modificar los datos maestros de deudor y si es necesario

efectuar una entrada en estos campos (status del campo).

Numeración de registros maestros

Cada registro maestro tiene un número unívoco. Este número se necesita para llamar el registro maestro o para efectuar contabilizaciones en la cuenta de deudor.

El grupo de cuentas determina la clase de la asignación de números utilizada y el rango de números válido para un registro maestro de deudor.

El número del registro maestro de deudor se asigna de modo interno o externo. El sistema asigna los números de manera interna, mientras que los números externos se introducen manualmente al crear el registro maestro de deudor. Los números externos pueden ser alfanuméricos.

El sistema garantiza que los números asignados siempre sean unívocos. En la asignación interna, el sistema selecciona el siguiente número del intervalo. En la asignación externa, el sistema impide la entrada de un mismo número dos veces.

En el caso del Ministerio de Hacienda de Republica Dominicana los grupos de cuenta que permitan una administración de acuerdo a los siguientes motivos:

Valores/significado

a. Impuestos, tasas y contribuciones

b. Ventas de bienes y servicios

c. Avances a terceros

d. Anticipos en compra

e. Préstamos 3

f. Avales ejecutados

Nota: Los motivos de cuentas por cobrar, se generan a través de las “Integraciones especificas con otros sistemas”, y las las soluciones de Bienes de Uso, Bienes de Consumo consideradas en el presente alcance.

3.3.21.1.2 Fecha de Imputación-Fecha de Registro-Valor por Cobrar


Cobrar y los Sub-Numerales 4.3.4. al 4.3.6 Fecha de imputación, Fecha de registro, Valor por cobrar de

acuerdo a la licitación (Referencia: PAFI-CCC-LPN-2018-0003) de Julio del 2018, procedemos a describir la

123


Dominicana:

El componente de aplicación Cuentas por Cobrar se suministra con pantallas prefijadas en las que se pueden

introducir los datos maestros. Puede configurar estas pantallas especificando qué campos deberían aparecer

en las pantallas y cómo se deben procesar dichos campos. Para ello, especifique el status de los campos.

En el caso del Ministerio de Hacienda de Republica Dominicana parte de los campos a considerar:

• Fecha de imputación

• Fecha de registro

• Valor por Cobrar

En el sistema SAP se pueden manejar a través de los Estatus Campos los requisitos desde el punto de vista

de campos requeridos, que a su vez se pueden configurar de la siguiente manera:

• Campo oculto (no visible)

• Campo obligatorio (el campo contiene un signo de interrogación y se tiene que realizar una entrada)

• Campo de entrada opcional (puede realizar una entrada)

• Campo de visualización (no se puede modificar)

3.3.21.1.3 Descuentos

Si se ha actualizado una clave para las condiciones de pago en el registro maestro de deudor, el sistema

propondrá automáticamente esta clave cada vez que se introduzca una posición para ese deudor. La clave

de las condiciones de pago puede determinar lo siguiente:

• El porcentaje de descuento pronto pago válido para un pago individual con un máximo de 3 condiciones de pago (primer plazo de descuento, segundo plazo de descuento y vencimiento neto), así como una fecha base para el pago.

• Las condiciones de pago en el caso de pagos a plazos.

124

3.3.21.1.4 Mora

En SAP Se puede calcular el interés de las cuentas de deudor

El cálculo de intereses se controla con parametrizaciones realizadas en el indicador de intereses. Se asigna un indicador de intereses a los registros maestros de las cuentas de deudor y acreedor para las que se va a calcular el interés. Cuando esté realizando una ejecución de cálculo de intereses, realizará especificaciones adicionales que también afectarán a la ejecución y que, en ocasiones, tendrán prioridad ante las parametrizaciones del indicador de intereses.

El cálculo de intereses se realiza utilizando el tipo de interés Debe definido para el indicador de intereses. Los tipos de interés Haber se utilizan cuando se calcula el interés en partidas pagadas antes de su vencimiento.

Como es el proceso de calculo de intereses

En primer lugar, el programa identifica las posiciones para las que se debe calcular el interés, con arreglo a las reglas definidas en el indicador de intereses y todas las especificaciones adicionales que se indican al ejecutar el programa. Las reglas introducidas determinan las posiciones y la operación para las que se puede calcular el interés, tales como:

• Únicamente partidas abiertas o compensadas

• Todas las operaciones de compensación o sólo aquellas con un pago (excluyendo, por tanto, abonos y pagos a cuenta).

• Partidas del Haber y del Debe o sólo partidas del Debe. Si se debe calcular el interés para partidas del Haber (por ejemplo, abonos y pagos a cuenta), el cálculo se realiza de la misma manera que para las partidas del Debe.

125

3.3.21.1.5 Intereses Indenizatorios

A continuación el programa establece los días para los que se deben calcular los intereses, teniendo en cuenta el tipo de calendario.

Existen básicamente dos factores incluidos en el cálculo de intereses: el límite superior e inferior del intervalo de liquidación especificado para la ejecución de cálculo de intereses y el período de tiempo entre el vencimiento neto y la fecha del documento de pago (o la fecha de compensación para abonos determinada por posición). El programa selecciona las partidas en las que el período entre vencimiento neto y fecha de compensación recae dentro de los límites inferior y superior del intervalo de liquidación. Si se suprime el límite inferior del intervalo de liquidación, el sistema utiliza el valor del campo Última fecha clave en el registro maestro como límite inferior.

Se puede especificar si debe calcularse el interés partiendo de la fecha del último cálculo de intereses. Es decir, sólo se incluirán en la nueva ejecución aquellas posiciones que todavía estén abiertas partiendo de la fecha de la última ejecución. Las partidas compensadas sólo se incluyen si la fecha de compensación es posterior a la fecha del último cálculo de intereses.

Los días de tolerancia pueden especificarse en el indicador de intereses. Éstos se añaden al vencimiento neto, pero solamente son relevantes para seleccionar las posiciones que se deben incluir en la ejecución del cálculo de intereses. El interés se calcula siempre partiendo del vencimiento neto sin tener en cuenta los días de tolerancia. También se puede definir los días de transferencia para las posiciones compensadas. Ésta es una manera de tener en cuenta la demora ocasional del traslado de pagos o que las cuentas relevantes no se compensan puntualmente. Los días de traslado se restan de la fecha del documento de pago o de la fecha de compensación.

3.3.21.1.6 Fecha compromiso de cobro

En SAP se puede obtener la visualización de días de demora muestra el número de días en que vencen las partidas abiertas. Se pueden visualizar:

• Todas las partidas abiertas

• Fechas compromisos de cobros

• Sólo las partidas vencidas

• Sólo las partidas que todavía no han vencido

Para esta visualización, se puede utilizar el vencimiento neto o la fecha límite en que el deudor puede recibir o podría haber recibido un descuento por pronto pago. Si algunas partidas no han vencido todavía, el sistema muestra el número de días en que vencen, mediante la visualización de números negativos.

Visualización de partidas vencidas

En la pantalla inicial Análisis de cuentas Deudor: Acceso, se puede visualizar tanto las partidas vencidas como las que todavía no han vencido y ver los días demoras de partidas vencidas.

126

Junto al número de partidas, también puede verse el total de todos los importes vencidos dentro de este intervalo de días de demora.

3.3.21.1.7 Motivos de Cobro

En el sistema SAP se especificar una cuenta asociada en el registro maestro para que todas las

contabilizaciones hechas en un libro auxiliar se contabilicen también en el libro mayor. Cuando se

contabilizan partidas en un libro auxiliar, el Sistema R/3, a su vez, contabiliza automáticamente los mismos

datos en el libro mayor. Cada libro auxiliar tiene una o más cuentas asociadas en el libro mayor. Estas cuentas

asociadas aseguran que el saldo de las cuentas de mayor siempre sea cero. Esto significa que se podrán

preparar balances en cualquier momento y sin transferir las sumas de los libros auxiliares al libro mayor.

Puede utilizar las cuentas asociadas para establecer parametrizaciones:

• La cuenta asociada se puede utilizar a fin de configurar las pantallas para contabilizar partidas en las cuentas de deudor o de acreedor. Mediante la cuenta asociada se puede, por ejemplo, suprimir los campos de entrada de seguros de cambio si no se realizan esta clase de movimientos.

• Puede utilizar también la cuenta asociada para especificar las monedas que se pueden utilizar al contabilizar en las cuentas de deudor o acreedor correspondientes.

En el caso del Ministerio de Hacienda de Republica Dominicana se necesita identificar los motivos de cobros.

Campo Valores/significado

Motivos de cobro • Arrendamientos

• Alquileres

• Cobro a empleados

• Venta de bienes y servicios

3.3.21.1.8 Condiciones de Cobro

Si se ha actualizado una clave para las condiciones de cobro en el registro maestro de deudor, el sistema propondrá automáticamente esta clave cada vez que se introduzca una posición para ese deudor. La clave de las condiciones de pago puede determinar lo siguiente:

• El porcentaje de descuento pronto pago válido para un pago individual con un máximo de 3 condiciones de pago (primer plazo de descuento, segundo plazo de descuento y vencimiento neto), así como una fecha base para el pago.

• Las condiciones de pago en el caso de pagos a plazos.

127

En el caso del Ministerio de Hacienda de la Republica Dominicana, se deben considerar las siguientes condiciones:


Condiciones de cobro Total

Parcial (1 a N):

• Numero de pago

• Monto de pago

• Fecha de compromiso de pago

3.3.21.1.9 Clasificación del Tiempo

El sistema puede distribuir automáticamente el importe total de compensación entre las partidas abiertas

según la antigüedad. De esta manera, se incluyen las partidas abiertas marcadas según la secuencia del

número de días de demora.

Se visualiza la pantalla para el tratamiento de partidas abiertas y se activan las partidas abiertas necesarias.

El sistema distribuye el importe de compensación de la siguiente manera:

Cuando las posiciones tienen el mismo número de días de demora, las partidas del Haber tienen prioridad

sobre las partidas del Debe.

Siempre se incluyen los pagos a cuenta de operaciones de pago anteriores.

Las posiciones se activan automáticamente hasta que se haya alcanzado el importe exacto de compensación

o la desviación entre el total de posiciones y el importe de compensación no exceda de las tolerancias de las

deducciones no autorizadas.

Si no se cumplen estas condiciones, el sistema continúa activando posiciones hasta que se alcanza el importe

máximo posible sin exceder del importe de compensación. La desviación restante se contabiliza a cuenta en

la cuenta que se está compensando. Si se están compensando varias cuentas juntas, la contabilización a

cuenta se efectúa en la cuenta que contiene la última posición activada.

Para el Ministerio de Hacienda de la Republica Dominicana se debe considerar la siguiente clasificación:

128


Clasificación por tiempo Flotante: Corto plazo

Consolidada: Mediano plazo, Largo plazo

Clasificación por residencia: Interna, Externa

3.3.21.1.10 Gestión y documentación de cobros

En el sistema SAP se puede utilizar la herramienta de “Avisos” estos contiene los detalles de la entrada de

cobros realizados que se deben compensar la partida abierta relevante. Las cabeceras de los avisos incluyen

el importe del pago, la fecha de pago e información adicional sobre el pago. Las partidas de aviso contienen

información sobre las posiciones pagadas; el importe y el origen de las diferencias. También contienen

información utilizada con fines de identificación, como el número de documento, número de referencia,

número del documento de facturación, número de referencia de deudor, etcétera.

Los avisos se pueden crear de distintas formas en el Sistema SAP.

3.3.21.2 Transacciones


Cobrar y su respectivo Sub-Numeral 4.4 Transacciones, de la Licitación Pública (Referencia: PAFI-CCC-LPN-



3.3.21.2.1 Nota de Debito

Se puede utilizar esta función para introducir Notas de Debito, la transacción Enjoy de entrada

adicionalmente permite el registro de Nota de Debito/Debe es una operación de pantalla individual.

Mediante esta función estándar de contabilidad, se pueden introducir operaciones en el auxiliar de Cuentas

por Cobrar y en el Libro mayor. Al hacerlo, se crean documentos y se graban los datos en la base de datos.

Los datos de contabilidad de deudores se contabilizan en Deudores. Desde allí, los datos se clasifican por

deudor y se ponen a disposición de otros componentes, por ejemplo, Comercial. Al contabilizar datos en

Deudores, el sistema crea un documento y transfiere los datos introducidos al libro mayor.

129

El componente Deudores no es solamente una base de procedimientos contables correctos. A causa de la

integración cercana con Comercial, proporciona datos para una gestión de créditos eficaz. El enlace a

Gestión de caja proporciona también información para optimizar la planificación de liquidez.

3.3.21.2.1.1 Motivos

Para el Ministerio de Hacienda de la Republica Dominicana, se deben considerar los siguientes motivos

para la generación de Notas de Debitos.

Motivos

Diferencia en lo contratado

Actualizacion de avaluó

Entre otros

3.3.21.2.2 Nota de Credito

Se puede utilizar esta función para introducir Notas de Credito, la transacción Enjoy de entrada

adicionalmente permite el registro de Abono por Nota de Credito en una operación de pantalla individual.

Mediante esta función estándar de contabilidad, se pueden introducir operaciones en el auxiliar de Cuentas

por Cobrar y en el Libro mayor. Al hacerlo, se crean documentos y se graban los datos en la base de datos.

Los datos de contabilidad de deudores se contabilizan en Deudores. Desde allí, los datos se clasifican por

deudor y se ponen a disposición de otros componentes, por ejemplo, Comercial. Al contabilizar datos en

Deudores, el sistema crea un documento y transfiere los datos introducidos al libro mayor.

El componente Deudores no es solamente una base de procedimientos contables correctos. A causa de la

integración cercana con Comercial, proporciona datos para una gestión de créditos eficaz. El enlace a

Gestión de caja proporciona también información para optimizar la planificación de liquidez.

Para el Ministerio de Hacienda de la Republica Dominicana, se deben considerar los siguientes motivos

para la generación de Notas de Creditos.

130

Motivos

Diferencia en lo contratado

Descuentos

Actualizacion de Avaluo

Entre otros

3.3.21.2.3 Registro de Ingreso

Los datos de contabilidad de deudores se contabilizan en Deudores. Desde allí, los datos se clasifican por deudor y se ponen a disposición de otros componentes, por ejemplo, Comercial. Al contabilizar datos en Deudores, el sistema crea un documento y transfiere los datos introducidos al libro mayor. A continuación se actualizan las cuentas de mayor según la operación de que se trate (crédito, anticipo, efecto, etcétera).

En SAP se registran los ingresos a una vez se hayan introducido los datos de la cabecera del documento y de las posiciones de deudor, se introducirán las partidas individuales de las cuentas de mayor.

En entradas de operaciones de Deudores se puede seleccionar la clave de contabilización que permite seleccionar el motivo de abono

Clave numérica de dos caracteres que controla la entrada de las partidas individuales. La clave de contabilización determina:

• Clase de cuenta

• Contabilización en el Debe/Haber

• Disposición de las pantallas de entrada

Al registrar una contabilización, se introduce la clave de contabilización para cada posición. Esta clave determinará la forma de contabilizar dicha posición. Las claves de contabilización se definen a nivel de mandante y por tanto son válidas para todas las sociedades. La clave de contabilización determina:

• Los datos que se pueden registrar en la partida individual.

• El procesamiento de los datos que se contabilizan.

• La actualización de los datos introducidos que efectúa el sistema.

131

Pagos

El programa de pagos permite la gestión tanto de los pagos efectuados como de los recibidos. Su flexibilidad permite definir las características de pago que existen en Republica Dominicana, por ejemplo, las especificaciones sobre la vía de pago, la forma de pago o el soporte de datos.

El sistema estándar contiene las vías de pago ordinarias y los correspondientes formularios, que se han definido de manera diferenciada para cada país.

En el caso del Ministerio de Hacienda de Republica Dominicana están indicados los siguientes:


Forma de cobro a. Transferencia

b. Cheque certificado

c. Cheque de administración

d. Tarjeta de crédito/debito

e. Nota de crédito

f. Depósito

g. Efectivo

Las vías de pago estándar son el cheque, la transferencia y el efecto

Otras características especiales incluyen:

• La compensación de partidas abiertas entre deudores y acreedores

• Los pagos internos, es decir, que una intitucion realiza un pago centralizado por otras

132

• El pago o la compensación de cualquier tipo de partida abierta, por ejemplo, el traslado de anticipos

• La restricción del acceso al programa de pagos asignando autorizaciones

3.3.21.2.4 Cambio de Tipo de Cuenta por Cobrar


Cobrar y su respectivo Sub-Numeral 4.4.5 Cambio de tipo de Cuenta por Cobrar, y sus respectivos Sub-

numerales 4.4.5.1 al 4.4.5.2 de la Licitación Pública (Referencia: PAFI-CCC-LPN-2018-0003) de Julio del 2018,



SAP permite el cambio de tipo de Cuenta por Cobrar a través de el registro de partidas individuales, esto a

través de los documentos para la Administracion de Cuentas por Cobrar el cual a través de de las posiciones

de deudor, se introducirán las partidas individuales de las cuentas en el deudor original hacia los conceptos

que motivan el cambio.

3.3.21.2.5 Baja en Cuentas


Cobrar y su respectivo Sub-Numeral 4.4 Transacciones, asi como los sub-numerales 4.4.6 al 4.4.6.3 Baja en

Cuentas, de la Licitación Pública (Referencia: PAFI-CCC-LPN-2018-0003) de Julio del 2018, procedemos a



SAP permite la baja de cuentas por cobrar a través de el registro de partidas individuales, esto a través de

los documentos para la Administracion de Cuentas por Cobrar el cual a través de de las posiciones de deudor,

se introducirán las partidas individuales de las cuentas en el deudor original hacia los conceptos que motivan

el cambio.

En este caso para el Ministerio de Hacienda de la Republica Dominicana.

Conceptos

Incobrabilidad

Por prescripción

Por sentencia judicial

133

Por disposición normativa, que actualmente no

existe y se contempla para un futuro.

Fallecimiento

Entre otros

3.3.21.2.6 Registro de Deterioro

En SAP a través de la función Gestión de créditos permite manejar los créditos pendientes o incobrables

pueden perjudicar enormemente los ingresos de la institución . La gestión de créditos permite reducir el

riesgo de crédito especificando un límite de crédito específico para sus deudores. De esta forma se puede

estimar la salud financiera de un cliente o grupo de clientes, identificar señales de aviso con prontitud y

desarrollar la búsqueda de decisiones en cuanto a deudas. Esto resulta muy útil si los deudores se encuentran

en industrias o empresas financieramente inestables o si realiza operaciones comerciales con países que son

políticamente inestables o utilizan una política de tipo de cambio restrictiva.

Si utiliza el componente de contabilidad de deudores, la gestión de créditos permite que emita un límite de

crédito para cada deudor. Cada vez que contabiliza una factura, el sistema verifica entonces si el importe de

la misma excede el límite de crédito. Las funciones de información tales como la hoja maestra de clientes o

la lista Early warning le ayudan a supervisar la situación crediticia de un cliente.

Dependiendo de las necesidades de la gestión de créditos, se pueden especificar verificaciones de crédito

automáticas basadas en un conjunto de criterios. También se puede especificar en qué puntos críticos del

ciclo comercial se efectuarán estas verificaciones (por ejemplo, entrada de pedidos, entrega o salida de

bienes).

• Durante el tratamiento de pedidos, el gestor de créditos recibe automáticamente la información sobre

el estado de crédito crítico de un deudor.

• Las situaciones crediticias críticas también se pueden comunicar automáticamente al personal de

gestión de créditos mediante el correo electrónico interno.

• Los gestores de crédito tienen la capacidad de revisar la situación crediticia de un cliente de manera

rápida y precisa y, de acuerdo con su política de créditos, decidir si se amplía o no el crédito.

Para el Ministerio de Hacienda de la Republica Dominicana los conceptos sobre los cuales se genera un

deterioro son los siguientes:

134

Conceptos

Incobrabilidad

Por prescripción

Por sentencia judicial

Por disposición normativa, que actualmente no

existe y se contempla para un futuro.

Fallecimiento

Entre otros

3.3.21.2.7 Pago con captación directa


Cobrar y su respectivo Sub-Numeral 4.4 Transacciones, asi como los sub-numerales 4.4.9 al 4.4.9.2 Pago con

Captación directa, de la Licitación Pública (Referencia: PAFI-CCC-LPN-2018-0003) de Julio del 2018,



En SAP puede utilizar el programa de pagos para procesar operaciones de pagos con deudores y acreedores.

El programa de pagos permite la gestión tanto de los pagos efectuados como de los recibidos. Su flexibilidad permite definir las características de pago que varían de un país a otro, por ejemplo, las especificaciones sobre la vía de pago, la forma de pago o el soporte de datos.

El sistema estándar contiene las vías de pago ordinarias y los correspondientes formularios, que se han definido de manera diferenciada para cada país.

3.3.21.3 Cuentas por Cobrar – Reportes y Consultas


PagarCobrar y los Sub-Numerales 4.5 Reportes y Consultas de la Licitación Pública (Referencia: PAFI-CCC-

LPN-2018-0003) de Julio del 2018, los reportes que se identifican en el alcance son los siguientes:

Nota:

1) Los reportes que se indican se basan en los reportes dispuestos por SAP S/4HANA de manera

estándar, no están considerados reportes a la “medida”.

135

2) La ampliación a la funcionalidad siginifica que “Cumple” con los requisitos con apliaciones al

sistema.

3.3.21.4 Cuentas por Cobrar – Interfaces


1 Interfaz con el sistema de la DGA Ampliación a la funcionalidad (Desarrollo)

2 Interfaz con el sistema de la DGII Ampliación a la funcionalidad (Desarrollo)

3 Interfaz con Contabilidad SIGEF Ampliación a la funcionalidad (Desarrollo)

4 Interfaz con sistema de Tesoreria Ampliación a la funcionalidad (Desarrollo)

5 Interfaz con sistema de Caja de Instituciones Ampliación a la funcionalidad (Desarrollo)

6 Interfaz con sistema de Bancos Comerciales Ampliación a la funcionalidad (Desarrollo)

7 Interfaz con sistema SIRIT Ampliación a la funcionalidad (Desarrollo)


1 Cuentas por cobrar por Institución


2 Cuentas por cobrar actualizadas por concepto


3 Vencimientos e Histórico de las Cuentas Por cobrar


4 Cobros realizados


5 Administración y detalle de los Fondos de Terceros


6 Obtención de Estados de Cuentas por cliente Funcionalidad nativa (estándar) de la solución

7 Información sobre descuentos en ventas Funcionalidad nativa (estándar) de la solución

8 Cuentas por cobrar y su vencimiento Funcionalidad nativa (estándar) de la solución

9 Cuenta por cobrar de la institución para el portal de

transparencia mensual

Ampliación a la funcionalidad (Desarrollo)

136

3.3.22 Gestión de Bienes Muebles-Inmuebles (Activos Fijos)


Uso (muebles, inmuebles e intangibles) y sus respectivos Sub-Numerales de la Licitación Pública (Referencia:

PAFI-CCC-LPN-2018-0003) de Julio del 2018, procedemos a describir la solución que ofrece SAP que cubre los

escenarios requeridos por el Ministerio de Hacienda de la Republica Dominicana:

El componente de Administración de Bienes de Uso (Contabilidad de activos fijos) se utiliza para gestionar y

supervisar activos fijos con el Sistema de SAP. En la Gestión financiera del Sistema SAP, sirve de libro auxiliar

del libro mayor , suministrando información detallada sobre los movimientos relacionados con activos fijos.

Como resultado de la integración en el Sistema SAP, la Contabilidad de activos fijos transfiere directamente

datos a otros componentes del Sistema y desde otros componentes del mismo. Por ejemplo, es posible

contabilizar directamente desde el componente Gestión de Bienes de Consumo a Bienes. Cuando un bien se

adquiere, se puede contabilizar directamente la recepción de facturas, la entrada de mercancías o la toma

del almacén, al modelo de bienes (Activos Fijos). Al mismo tiempo, se puede transferir la amortización y el

interés directamente a los componentes de Contabilidad y Presupuesto.

El componente de Contabilidad de Bienes consta de las partes siguientes:

• Contabilidad de bienes tradicional

• Procesamiento de bienes arrendados

• Preparativos para la consolidación

• Sistema de información

La contabilidad de bienes tradicional abarca toda la vida de los bienes, desde la orden de compra o el alta

inicial (posiblemente gestionada como un bien en curso) hasta su baja. En gran medida, el sistema calcula

137

automáticamente los valores de amortización, interés, seguro y otros propósitos entre estos dos puntos en

el tiempo y pone esta información a su disposición de distintas maneras mediante el Sistema de información.

Existe un informe para previsiones de la amortización y simulación del desarrollo de los valores de balance.

El sistema también ofrece funciones especiales para bienes arrendados y bienes en curso o construccion. El

sistema permite gestionar valores en monedas paralelas mediante diferentes tipos de valoración. Estas

características simplifican el proceso de preparación de la consolidación de grupos de organizaciones

multinacionales.

Efectivamente la demanda acerca de la gestión de datos maestro para la contabilidad de bienes se satisfacen

con el componen de bienes mediante el:

o Registros maestros de bienes que están estructurados según los requisitos funcionales y de objetivos.

o Actualización de datos maestros que está organizada según dicha estructura y que permite una

adaptación personal.

3.3.22.1 Estructuracion de los Bienes de Uso (Activos Fijos)

Se pueden estructurar activos fijos en diferentes niveles en el sistema:

• Nivel de balance

• Nivel de clasificación

• Nivel de activos fijos

138

Para el Ministerio de Hacienda de Republica Dominicana la información de los estados financieros esta clasificado los bienes de la siguiente manera:

• Tierras y terrenos

• Edificios

• Equipos de transporte, tracción y elevación

• Maquinarias y equipos especializados

• Equipo e instrumental médico, científico y de laboratorio

• Equipos y mobiliario de oficina y alojamiento

• Equipos y mobiliario educacional, deportivo y recreativo

• Equipos de defensa, seguridad y orden público

• Semovientes

Nivel de balance

Para una estructuración acorde a los criterios de balance, el componente de Gestión financiera del Sistema SAP ofrece una jerarquía de tres niveles:

• Versión de balance

• Posición de balance

• Cuenta de mayor

Nivel de clasificación

En este nivel, se pueden estructurar los bienes de uso mediante clases de bienes (Activos Fijos) en el componente de Administracion de Bienes de Uso (Activos Fijos). Puede utilizar las clases de bienes para estructurar bienes en función de las condiciones legales o las necesidades contables. Cada bien pertenece a una clase de bien (activos fijos). Utilice la determinación de cuentas en la bienes para asignar cada bien a una posición del balance Otras propiedades, planta y equipo.

Nivel de Bienes de Uso (Activos Fijos)

En el nivel de bienes, se ha creado una jerarquía de cuatro niveles en el componente Administracion de Bienes de Uso (véase Funciones básicas de la actualización de activos fijos):

El complejo de bienes permite agrupar bienes (activos fijos) con el propósito de aplicar criterios uniformes de evaluación y amortización. Los complejos de bienes se asignan a clases de bienes (activos), igual que otros bienes (activos fijos).

139

El número principal del bien (activo fijo) representa un bien que será evaluado independientemente. Se considera el bien como una unidad individual para la evaluación. Éste contiene información para la valoración del bien (activo fijo), así como información organizativa.

Debajo del número principal del bien (activo fijo), el bien puede volver a dividirse en sus componentes por medio de los subnúmeros de bienes (activo fijo). Se pueden utilizar subnúmeros para amortizar altas posteriores a un activo fijo independientemente del activo fijo original.

El nivel inferior consta de los datos variables por cada área de valoración (como altas o bajas) que pertenezcan al registro maestro del bien de uso (activo fijo) (partidas individuales).

3.3.22.2 Creación Automatica de un bien

Bansadonos en lo indicado en la PARTE A – REQUERIMIENTOS FUNCIONALES LOTE 1, Numeral 5 Bienes de Uso (muebles, inmuebles e intangibles) y el respectivo Sub-numeral 5.2 “Creacion de forma automática” de la Licitación Pública (Referencia: PAFI-CCC-LPN-2018-0003) de Julio del 2018, procedemos a describir la solución que ofrece SAP que cubre los escenarios requeridos por el Ministerio de Hacienda de la Republica Dominicana:

El sistema SAP posee una interfaz de programación estandarizada que facilita el acceso externo a los procesos y datos del negocio en el Sistema SAP. Es decir son mecanismos realizar las transacciones estándar del sistema a través de una interfaz, en este caso el Portal de Compras y Contrataciones SIGEF.

Los BAPI (Business Application Programming Interface) ofrecen una vista orientada a objetos de los componentes empresariales en el Sistema SAP. Se implementan y almacenan como módulos de funciones habilitados para RFC en el generador de funciones de ABAP Workbench.

Tecnicamente los BAPI´s están identificados en una biblioteca técnica, en caso de los bienes de uso existen entre otros los siguientes:

• BAPI_FIXEDASSET_GETLIST (información sobre los bienes (activos fijos seleccionados)

• BAPI_FIXEDASSET_GETDETAIL (visualizar información detallada sobre un bien (activo fijo)

• BAPI_FIXEDASSET_CREATE (crear un bien)

• BAPI_FIXEDASSET_CHANGE (modificar un bien existente).

La Contabilidad de bienes (activos fijos) es un libro auxiliar de la contabilidad (Libro mayor), utilizado para la gestión y para la documentación detallada de las operaciones financieras relacionadas con los bienes de uso.

El componente de Administración de Bienes de uso (activos fijos) permite registrar la amortización y las modificaciones efectuadas en los valores efectivos en la Contabilidad de activos fijos y actualizarlos en el Libro mayor en el Sistema SAP.

3.3.22.2.1 Creacion automatica mediante integración

140

3.3.22.3 Datos maestros generales de los bienes

Esta parte del registro maestro contiene información concreta sobre el bien (activo fijo). Existen los

siguientes grupos de campos:

o Información general (descripción, cantidad, etc.)

o Imputación

o Información de contabilización (por ejemplo, fecha de capitalización)

o Asignaciones temporales (por ejemplo, centro de coste)

o Información de mantenimiento

o Entradas para impuesto sobre el patrimonio (neto)

o Información de terrenos

o Condiciones de leasing

o Medidas de fomento a la inversión

o Información sobre el origen del activo fijo

141

o Datos de inventario

o Datos del seguro

o Campos de usuario/criterios de clasificación

Además, se pueden crear textos explicativos para grupos de campos individuales que pertenezcan a la parte

de datos generales del registro maestro de activo fijo. Puede simplificarse la creación de textos explicativos

utilizando máscaras de edición de texto explicativo libremente definibles por el Ministerio de Hacienda.

• Datos para calcular valores de bienes:

Pueden especificarse los parámetros de amortización en el registro maestro de activo fijo para cada una de

las áreas de valoración en el plan de valoración. Para que se puedan realizar estas especificaciones, el registro

maestro contiene un resumen de las áreas de valoración. Además, existe una visualización detallada

disponible para cada área de valoración. Si existen áreas de valoración que no son necesarias para un activo

fijo específico, es posible desactivarlas a nivel de activo fijo.

El siguiente gráfico muestra las condiciones de amortización más importantes dentro de un área de

valoración:

El sistema SAP permite realizar la búsqueda de un bien bajo múltiples características entre las que figuran:

• Clase de bien

• Denominación

• Centro de Coste

• Numero de Inventario

• Determinación de cuenta

142

Para facilitar su búsqueda a cada activo fijo se le asigna un número.

El número de activo fijo identifica únicamente a un activo fijo. Siempre consta del número principal del activo

fijo y su subnúmero. En el sistema existen dos formas de efectuar la asignación de números:

• Asignación de números externa

• Asignación de números interna

En el caso de la asignación de números externa, el usuario asigna directamente el número de activo fijo. El

sistema visualiza solamente el intervalo de números definido y emite un mensaje de error si el número ya

está asignado. En el caso de la asignación de números interna, el sistema asigna automáticamente números

consecutivos.

Se puede contemplar realizar búsquedas para características específicas de características del MHRD.

Valoracion de Bienes

Efectivamente El componente "Función básica para la valoración de activos fijos" se utiliza para determinar

los valores de todos los activos fijos en un momento concreto, en base a las exigencias de las autoridades

gubernamentales o en base a sus propias reglas para satisfacer sus propias necesidades.

El sistema permite no solo la selección por método de calendarios de depreciación, sino además permite

selección por método de depreciación. Se puede establecer la fecha inicial y final de la amortización para los

movimientos de activos fijos, podrá fijar un control de períodos adecuado para la clave interna de cálculo en

las cuatro categorías de movimientos:

• Altas

• Altas posteriores/postcapitalización

• Traspasos

• Bajas

De este modo, se puede fijar, por ejemplo, la fecha de inicio de la amortización para todas las altas de un

mismo ejercicio al principio del mismo. También se puede fijar la fecha de inicio de la amortización para las

bajas al primer o al último día de cada período. Al utilizar la fecha de referencia de un movimiento (alta o

baja), el sistema determina la fecha de inicio o la fecha de finalización del cálculo de amortizaciones mediante

el control de períodos.

143

3.3.22.4 Clasificacion de los bienes

Los bienes de uso como conjunto están compuestos por una serie de diferentes tipos de bienes de uso. El

balance representa esta variedad mediante las posiciones de balance:

A. Muebles

B. Edificios

C. Terrenos

D. Intangibles

Generalmente, es deseable preparar una clasificación más detallada de los bienes de uso, según los tipos de

bienes de uso fijos definidos por el Ministerio de Hacienda de Republica Dominicana.

Cada tipo de bienes de uso está representado por una o más clases de bienes de uso definidos. Las clases de

bienes de uso contienen algunos indicadores de control. La clase de bienes de uso puede servir como una

especie de registro maestro tipo para los bienes de uso de esa clase. Generalmente, todas las clases de bienes

de uso utilizarán los mismos elementos siguientes:

o Determinación de Cuenta: Mediante el componente Administracion de Bienes, se pueden actualizar

automáticamente todas las operaciones relevantes para el libro mayor. Éstas comprenden todas las

operaciones contables que se contabilizan en los bienes de uso y todas las modificaciones realizadas

en los valores efectivos que el sistema calcula automáticamente (especialmente, la amortización).

Esta actualización se produce inmediatamente y en modo interactivo para un área de valoración, o

bien como parte de las operaciones periódicas del resto de las áreas de valoración.

144

o Control de Estructuración de Pantalla: El registro maestro de bien de uso (Activo Fijo) en el

componente de Administracion de Bienes de Uso (Activos Fijos) tiene un gran número de campos a

fin de satisfacer las necesidades de sus muchas funciones. No obstante, a fin de conseguir que la

actualización de datos sea lo más simple y eficiente posible, las siguientes funciones del Customizing

permiten diseñar el registro maestro de activo fijo que mejor se ajuste a sus necesidades.

o Especificaciones de características de campo (entrada obligatoria, entrada opcional,

supresión) y el nivel de actualización (clase de bienes de uso fijos/número

principal/subnúmero de activo fijo) para campos de datos maestros.

o Especificación de la disposición de las etiquetas en el registro maestro

Con lo antes mencionado las clases de bienes de uso constituyen el medio más importante para estructurar

bienes de uso fijos en SAP. Puede definir un número ilimitado de clases de bienes de uso en el sistema. Las

clases de bienes de uso se pueden utilizar para estructurar sus bienes de uso en función de las necesidades

del Miisterio de Hacienda de Repubica Dominicana. Las clases de bienes de uso son válidas para todas las

instituciones. Por lo tanto, el catálogo de clases de bienes de uso es relevante en todas las instituciones. Esta

afirmación resulta igualmente válida cuando las instituciones que tienen diferentes planes de valoración y,

por tanto, diferentes áreas de valoración.

Al tener una clasificación por clase de bien y dependiendo de las funciones que deban tener, se deben

tener en cuenta los siguientes criterios al crear la clase de bienes de uso:

• La clase de bienes de uso proporciona los valores propuestos para todos los registros maestros de

activo fijo de la clase. De este modo, la clase de bienes de uso funciona como un registro maestro

145

tipo y permite crear nuevos registros maestros de bienes de uso de una manera sencilla y sin

errores.

• La estructuración de las pantallas, la disposición de las fichas y las características de los campos

(obligatorio/opcional/suprimido) del registro maestro del bien y se pueden especificar para la clase

de bienes.

• La asignación de los números de bienes de uso puede controlarse mediante la clase de bienes de

uso.

• La clase de bienes de uso constituye un criterio de selección en todos los reports estándar de la

Contabilidad de bienes de uso. Además, es posible clasificar y totalizar según características

específicas de la clase.

Adicionalmente a todo esto permite poder controlar el tipo de depreciación o amortización, así como el

método de valoración que aplica.

El registro maestro del bien en el componente de Administracion de Bienes de Uso (Activos Fijos) tiene un

gran número de campos a fin de satisfacer las necesidades de sus muchas funciones. No obstante, a fin de

conseguir que la actualización de datos sea lo más simple y eficiente posible, las siguientes funciones de la

parametrizacion permiten diseñar el registro maestro de activo fijo que mejor se ajuste a sus necesidades.

Especificaciones de características de campo (entrada obligatoria, entrada opcional, supresión) y el nivel de

actualización (clase de bienes de uso fijos/número principal/sub número de bien) para campos de datos

maestros.

3.3.22.5 Identificacion única del bien

146


Uso (muebles, inmuebles e intangibles) y su respectivo Sub-Numerales 5.4 “Identificación única del bien” de

la Licitación Pública (Referencia: PAFI-CCC-LPN-2018-0003) de Julio del 2018, procedemos a colocar en base

a nuestro entendimiento las consideraciones de los requerimientos que desdes el punto de vista de campos

se deben considerar, como ejemplo se tomo “Bienes Inmuebles - Terrenos”.

El concepto "bien patrimonial" se utiliza tanto para bienes económicos simples como para aquellos bienes

económicos complejos a gran escala que consisten en varios activos fijos parciales. La estructura de datos

del sistema, con un número principal de bien de uso (activo fijo). El número principal del bien (activo fijo)

representa el bien en su conjunto. Las partes de los bienes pueden representarse mediante distintos

subnúmeros, en el caso de que se requiera.

Cada registro maestro se crea automáticamente con un subnúmero como mínimo, incluso si no existen sub-

bienes u activos fijos. El sistema marca el primer registro maestro como un registro maestro de número

principal del bien . Al utilizar la asignación de números interna, este número principal tiene como subnúmero

"0000". Se pueden crear subnúmeros adicionales para este registro maestro de número principal. El sistema

gestiona los valores para todos los subnúmeros de cada área de valoración individual por segmentos del año.

Los distintos movimientos se contabilizan directamente en los subnúmeros de activos fijos como partidas

individuales.

Bien de Uso Principal principal con subnúmeros

3.3.22.6 Etiqueta del bien (Codigo de Barra)

Bansadonos en lo indicado en la PARTE A – REQUERIMIENTOS FUNCIONALES LOTE 1, Numeral 5 Bienes de Uso (muebles, inmuebles e intangibles) y sus respectivos Sub-Numerales 5.5 “Etiqueta del Bien” y los sub-numerales 5.5.1 al 5.5.7 de la Licitación Pública (Referencia: PAFI-CCC-LPN-2018-0003) de Julio del 2018, procedemos a describir la solución que ofrece SAP que cubre los escenarios requeridos por el Ministerio de Hacienda de la Republica Dominicana.

Un inventario es la actualización de las cantidades y los importes relacionados con el patrimonio de bienes

de uso. El componente de Administración de Bienes de Uso suministra las siguientes funciones para apoyar

al inventario.

147

• Lista de inventario

El sistema suministra un listado de inventario para ayudar con el inventario. Encontrará este listado en el

sistema de información estándar de la Contabilidad de bienes de uso. Se debe adaptar la estructura y la

clasificación del listado para cumplir sus necesidades específicas.

• Códigos de Barra

Existe un informe adicional que permite imprimir información seleccionada procedente del registro maestro

de activo fijo conjuntamente con un código de barras. Se imprime en un formulario de SAPscript que el

usuario puede definir libremente. Se puede utilizar la impresión para etiquetar los bienes de uso para su

identificación individual. El código de barras es unívoco para cada bien, puesto que representa (en la versión

estándar del sistema) el número y el sub número del bien.

SAP suministra el formulario estándar FIAA_0003. Puede utilizar este formulario, pero también puede utilizar

una copia del mismo como base para definir su propio formulario (véase la guía de implementación). Sistema

de información ® Definir/asignar formularios). El formulario estándar contiene los siguientes elementos de

texto:

o Denominación del bien de uso

o Centro de coste del bien

o Número de inventario

o Número de bien y sub número

o Código de barras

Conjuntamente con esta información del registro maestro podrá utilizar todos los campos en la tabla ANLAV

en el formulario. También puede hacer que cualquier campo de la tabla ANLAV aparezca como código de

barras.

3.3.22.7 Datos de los bienes – (Control de estructuración de pantallas)


Uso (muebles, inmuebles e intangibles) y sus respectivos Sub-Numerales 5.6 al 5.11.14 “Datos de los Bienes”

de la Licitación Pública (Referencia: PAFI-CCC-LPN-2018-0003) de Julio del 2018, procedemos a colocar en

base a nuestro entendimiento las consideraciones de los requerimientos que desdes el punto de vista de

campos se deben considerar, como ejemplo se tomo “Bienes Inmuebles - Terrenos”.

Los atributos de campo se especifican en el registro maestro del bien y el nivel de actualización de los campos,

utilizando el control de estructuración de pantallas. Pueden definirse tantos tipos de controles de

estructuración de pantallas como sean necesarios e introducirse en las clases de bienes de uso (Datos

maestros del Customizing). El control de estructuración de pantallas existe para:

• Datos maestros generales

148

• Condiciones de amortización del registro maestro (área de valoración).

En cada control de estructuración de pantallas pueden hacerse especificaciones para los grupos de campo

individuales. Los campos de actualización correspondientes se asignan a cada grupo de campos.

152

3.3.22.8 Recepcion en Almacén/Aceptacion del bien

Bansadonos en lo indicado en la PARTE A – REQUERIMIENTOS FUNCIONALES LOTE 1, Numeral 5 Bienes de Uso (muebles, inmuebles e intangibles) y sus respectivos Sub-Numerales 5.11.1 “Recepcion del Bien” de la Licitación Pública (Referencia: PAFI-CCC-LPN-2018-0003) de Julio del 2018, procedemos describir el manejo a través de SAP.

El componente Administración de Bienes (activos fijos) está integrado de numerosas maneras con otros

componentes del Sistema SAP. La integración de Administración de Bienes (activos fijos) con el componente

(Gestión financiera, incluyendo la contabilidad de acreedores y de deudores) permite realizar:

• La contabilización integrada de altas y bajas de activos fijos con la contabilidad de acreedores y

contabilidad de deudores.

• La imputación de anticipos para bienes de uso (activos fijos) en el momento de contabilizar

anticipos en el componente de la Gestión financiera (FI)

• La contabilización de amortización de lo bienes de uso (contabilidad de activos fijos) en la cuenta

de mayor adecuada

Además, la integración con algunos componentes permite realizar imputaciones en bienes de uso (activos

fijos) a partir de movimientos relacionados con los bienes de uso. Estos componentes son:

• Gestion de bienes de consumo (MM - Gestión de materiales)

• Mantenimiento (PM – Mantenimiento de planta)

3.3.22.8.1 Solicitud de Compras Si se realizan contabilizaciones en un bien (activo fijo) cuando se introduce una solicitud de pedido o un

contrato marco, el sistema comprueba, con relación a la fecha de entrega prevista, si existe realmente el

bien y si se pueden realizar contabilizaciones en él. Las mismas comprobaciones se llevan a cabo si contabiliza

en un bien cuando introduce un pedido de compras. Además, el sistema garantiza que no sobrepasará el

límite superior para bienes económicos de poco valor.

3.3.22.8.2 Recepción en Almacen Puede contabilizar la entrada de bienes de un pedido de compras. Una vez valorada la entrada del bien, el

sistema activa el valor facturado de los bienes (basado en el pedido) en el bien.

Normalmente, en derecho mercantil la fecha de puesta en servicio determina la fecha de inicio de

capitalización de un bien (activo fijo). La puesta en servicio tiene lugar, para la mayoría de activos fijos,

directamente después de la recepción en almacen.

153

3.3.22.9 Registro de deterioro


Uso (muebles, inmuebles e intangibles) y sus respectivos Sub-Numerales 5.11.2 “Registro de Deterioro” de la

Licitación Pública (Referencia: PAFI-CCC-LPN-2018-0003) de Julio del 2018, procedemos describir el manejo a

través de SAP.

El registro por deterioro de un bien de uso es la posible eliminación de un bie o parte de un bien (activo fijo)

procedente del patrimonio de bienes. Esta eliminación de un bien (o de parte de un bien) se contabiliza desde

un punto de vista contable como una baja del bien.

Un registro por deterioro (baja sin ingresos) es una eliminación de un bien del patrimonio de bienes sin

ingreso alguno. Se utiliza esta opción de contabilización, el crea la contabilización Pérdidas por baja del bien

sin ingresos por el importe del valor neto contable que se da de baja.

3.3.22.10 Registro de Revaluacion


Uso (muebles, inmuebles e intangibles) y sus respectivos Sub-Numerales 5.11.4 “Registro de revaluación” de



Dominicana.

Este componente sirve para llevar a cabo medidas de revalorización para el balance. Esta revalorización

posibilita el cumplimiento en algunos países de los requisitos fiscales para una revalorización de los bienes.

El sistema permite definir medidas de revalorización en la Administracion de Bienes de Uso y utilizar la

contabilización colectiva para contabilizarlos.

Puede gestionar los valores de revalorización en todas las áreas de valoración. Sin embargo, de acuerdo con

las normas legales de muchos países, debe poder identificar estas evoluciones del valor por separado. En

este caso, debe usar un área de valoración separada para cada revalorización.

3.3.22.11 Registro de Capitalización o Modificaciones


Uso (muebles, inmuebles e intangibles) y sus respectivos Sub-Numerales 5.11.5 “Registro de capitalizaciones

o modificaciones” de la Licitación Pública (Referencia: PAFI-CCC-LPN-2018-0003) de Julio del 2018,

154


Hacienda de la Republica Dominicana.

En este contexto, la postcapitalización representa correcciones subsiguientes para los costes de adquisición

y producción de un bien de uso. Un ejemplo de las circunstancias en las que este tipo de corrección es

necesario sería si se olvidó de añadir los gastos y costes relacionados con la adquisición o montaje de un bien

de uso en un ejercicio ya cerrado.

El sistema contabiliza los importes brutos de las postcapitalizaciones, dando como resultado importes de

amortización históricos. El sistema calcula de nuevo la amortización de los ejercicios cerrados, basados en la

fecha de capitalización introducida en el registro maestro del bien.

Posteriormente, el sistema contabiliza los registros como un alta a la cuenta de balance del bien y la

amortización acumulada procedente de ejercicios pasados, a la cuenta de amortización acumulada. El

sistema también contabiliza ingresos extraordinarios en el importe de la diferencia existente entre los CAP y

la amortización acumulada.

3.3.22.12 Registro de Recuperación


Uso (muebles, inmuebles e intangibles) y sus respectivos Sub-Numerales 5.11.7 “Registro de capitalizaciones

o modificaciones” y sus respectivos Su-numerales 5.11.7.1 al 5.11.7.4 de la Licitación Pública (Referencia:

PAFI-CCC-LPN-2018-0003) de Julio del 2018, procedemos a describir la solución que ofrece SAP que cubre los

escenarios requeridos por el Ministerio de Hacienda de la Republica Dominicana.

A veces es necesario contabilizar los ingresos o los costes para una baja de bien de uso (activo) ya

contabilizada. Por ejemplo, puede ser necesario contabilizar una prestación del seguro como ingreso

posterior a un bien, aunque el bien ya haya sido reportado como desactivado (robado).

En el componente activos fijos existen dos movimientos que hacen posible crear partidas individuales para

costes o ingresos contabilizados después de la baja. Puede hacer un report sobre esas partidas individuales

de activo fijo en la lista estándar de bajas.

3.3.22.13 Calculo de Depreciación y Amortización


Uso (muebles, inmuebles e intangibles) y sus respectivos Sub-Numerales 5.11.8 Calculo de Depreciación y

155

Amortización de la Licitación Pública (Referencia: PAFI-CCC-LPN-2018-0003) de Julio del 2018, procedemos

describir el manejo a través de SAP.

“De acuerdo con las NICSP el método de depreciación refleja el patrón al cual se espera sean consumidos los

bienes de uso. Los métodos de cálculo de la depreciación que se utilizan en el sector público dominicano

son:

1. Lineal

2. Decreciente

3. Unidades de producción

El componente Amortización del modulo de activo fijo permite la gestión de las siguientes clases de

amortización en el sistema:

• Clases de amortización calculada automáticamente (puede planificarse también manualmente):

o Amortización normal

o Amortización especial

• Clases de amortización que normalmente se planifican manualmente:

o Amortización no planificada

o Traslado de reservas/reducción de CAP

Las claves de amortización controlan el cálculo automático de la amortización en el sistema. Estas claves

pueden modificarse. De esta forma, podrá definir sus propios métodos de cálculo de valores efectivos.

El sistema trata el cálculo de intereses para intereses del área analítica en la contabilidad de costes como una

clase de amortización y está por lo tanto controlado también por claves de amortización y métodos de

cálculo, de manera similar al cálculo de la amortización.

Las clases de amortización (Depreciacion)

Se soportan las siguientes clases de amortización o valoración:


La amortización normal es la deducción planificada por uso durante la utilización normal de un bien. (Lineal,

Decreciente, Unidades de Produccion).


La amortización especial representa la deducción por uso de un bien desde un punto de vista

puramente fiscal. Esta forma de amortización permite una amortización porcentual,

156

probablemente estancada, dentro del período permitido por las autoridades fiscales, sin

tener en cuenta el uso real del bien.

o Amortización no planificada

La amortización normal refleja la deducción por uso durante la utilización normal del bien.

Las influencias poco habituales, como por ejemplo daños que provoquen una reducción

permanente del valor del activo fijo, quedan contempladas en la amortización no planificada.

o Traslado de reservas/Reducción de CAP

Métodos de valoración

En SAP se definir sus propios métodos de cálculo para la valoración de bienes de uso (Amortizaciones ®

Métodos de valoración ® Clave de amortización ® Métodos de cálculo). Estos métodos de cálculo no están

codificados de forma fija en el sistema. Están basados en una serie de claves de cálculo de definición flexible.

Definiendo sus propios métodos de cálculo y parámetros de control, puede representar sus propios métodos

de amortización específicos.

El sistema contiene métodos y parámetros de cálculo predefinidos para los métodos de amortización más

utilizados.

El cálculo de amortizaciones se basa en los parámetros de control que se explican a continuación, así como

en la vida útil prevista del bien introducida en el registro maestro del bien de uso:

o La clave de amortización contiene todos los datos de control para el cálculo de la

amortización anual prevista. Puede introducir una clave de amortización en cada área de

valoración del registro maestro del bien.

o La parte más importante de la clave de amortización es el método de cálculo de las diferentes

clases de amortización calculada automáticamente (amortización normal y especial e

interés). El método de cálculo es especialmente importante para definir el método de cálculo

por amortización.

o Las funciones especiales le permiten cumplir con un valor de detención (valor residual).

Claves de amortización

La clave de amortización contiene las parametrizaciones de valor necesarias para establecer los importes de

amortización. Representa una combinación de reglas de cálculo que se utilizan para las clases de

amortización calculadas automáticamente.



o Intereses del área analítica

157

Componentes y parámetros de control de la clave de amortización

Las claves de amortización se definen en el nivel del plan de valoración. Por tanto, están disponibles en todas

las sociedades. Mediante las claves de amortización definidas en un plan de valoración, podrá configurar el

plan de valoración de acuerdo con las reglas de valoración especiales de un espacio económico (país, región

geográfica, etc.) con condiciones de amortización uniformes.

En el Sistema SAP los planes de valoración estándar contienen claves de amortización predefinidas para

cumplir las necesidades de amortización específicas de cada país en este caso para Republica Dominicana.

Puede dividir la duración de la amortización en varias fases en la clave de amortización. Si introduce un

método de cambio para una de estas fases, el sistema pasará a la fase siguiente en el momento en que se

produzca el evento especificado en el método de cambio. A continuación, el sistema utiliza el cálculo de la

clase de amortización especificado para dicha fase siguiente.

Métodos de Calculo

El sistema utiliza métodos de cálculo para el cálculo de la amortización y de los intereses del área analítica.

Asigne métodos de cálculo a las claves de amortización. Los métodos de cálculo proporcionan los parámetros

para el programa de cálculo de amortizaciones.

El cálculo de la amortización se controla mediante los métodos de cálculo, los parámetros de control

introducidos en las claves de amortización y las claves del valor de detención.

Los distintos métodos de cálculo, a excepción del método básico de cálculo de la amortización, dependen del

plan de valoración. Esto significa que puede representar sus necesidades de amortización específicas de país

por medio de métodos de cálculo específicos del plan de valoración. El sistema le ayuda a seleccionar los

métodos correctos ofreciendo únicamente los métodos que se aplican a su plan de valoración en cuestión.

158

Puede introducir también los valores propuestos para las áreas de valoración e instituciones.

El gráfico siguiente proporciona un resumen de las funciones de control de métodos de cálculo.

Los métodos de cálculo estándar son parte integral del sistema y no pueden modificarse. Si necesita modificar

un método de cálculo por motivos legales o empresariales, copie el método de cálculo y realice las

modificaciones en la copia. La clave del método de cálculo que cree deberá empezar por X, Y o Z.

Todos los cambios realizados en otros métodos de cálculo durante el período de la amortización se definen

en la clave de amortización.

159

Métodos de Amortización

Las claves de amortización, con sus métodos de cálculo y sus parámetros, le permiten representar los

métodos de amortización más variados en el sistema. A continuación se describen las cuestiones más

importantes sobre estos métodos de amortización, y cómo se gestionan en el sistema.

3.3.22.14 Afectacion en uso (prestamos) internos y Traslados internos


Uso (muebles, inmuebles e intangibles) y sus respectivos Sub-Numerales 5.11.9 “Afectación en uso

(préstamos) internos” y los sub-numerales 5.11.9.1 al 5.11.9.4 asi como el numeral 5.11.11 “Traslados

internos” y los sub-numerales 5.11.11.1 al 5.11.11.6 de la Licitación Pública (Referencia: PAFI-CCC-LPN-2018-


por el Ministerio de Hacienda de la Republica Dominicana.

Un bien de uso (Activo Fijo) se puede asignar a varias unidades organizativas mediante la introducción de

entradas en el registro maestro de bienes de uso . Estas asignaciones son de especial relevancia para otras

aplicaciones del Sistema SAP. Sin embargo, también existen funciones y requisitos para la Administracion

de bienes de uso que hacen necesario o deseable realizar asignaciones organizativas.

Para la contabilidad interna, generalmente es necesario asignar costes de bienes de uso a centros de coste

(Ubicación Fisica). Por tanto, puede asignar cada activo de la Administracion de bienes de uso a un único

centro de coste. Esta asignación se hace en el registro maestro de activo. En el nivel del centro de coste, se

puede:

o Contabilizar todas las amortizaciones e intereses para el activo.

o Planificar todas las amortizaciones e intereses futuros.

o Contabilizar estadísticamente los beneficios o pérdidas de la venta de bienes de uso.

El flujo de información se diseñaría a través de un flujo de trabajo digital que permita las autorizaciones de

recepción y salida de los bienes.

3.3.22.15 Afectación de uso (prestamos) interinstitucional


Uso (muebles, inmuebles e intangibles) y sus respectivos Sub-Numerales 5.11.10 “Afectación de uso

(prestamos) interinstitucional” y sus respectivos Su-numerales 5.11.10.1 al 5.11.10.4 de la Licitación Pública

(Referencia: PAFI-CCC-LPN-2018-0003) de Julio del 2018, procedemos a describir la solución que ofrece SAP

que cubre los escenarios requeridos por el Ministerio de Hacienda de la Republica Dominicana.

160

Esta operación sirve para traspasar un bien de uso entre dos instituciones. Las operaciones de baja y alta se

contabilizan en un único paso. Según la estructura organizativa de la institucion, esta operación combinada

se podrá contabilizar mediante las clases de operaciones del traspaso de bienes o mediante las clases de

operaciones relativas a bajas y altas.

Para contabilizar automáticamente la transferencia de bienes y crear el bien de alta, deberán haberse

definido determinadas parametrizaciones del sistema en el Customizing de la Contabilidad de activos fijos.

El traspaso de baja se contabiliza desde la perspectiva de la institución emisora. De forma automática, el

sistema contabiliza el alta por traspaso en la institución receptora. Si se precisa un nuevo registro maestro

de bienes en la institución receptora, se debe introducer la información necesaria en una ventana de diálogo.

Traspaso en masivo

El sistema gestiona la contabilización en la sociedad emisora al igual que una baja de activo fijo no integrada contabilizada en una cuenta de compensación. Por este motivo, el sistema no crea ninguna contabilización impositiva durante la transferencia de bienes (activos fijos).

3.3.22.16 Descargos

La descarga de un bien (activo fijo) es la eliminación de un activo fijo o parte de un activo fijo procedente del patrimonio de bienes. Esta eliminación de un bien (o de parte de un activo fijo) se contabiliza desde un punto de vista contable como una baja de bien (active fijo). Dependiendo de las consideraciones institucionales o de la operación institucional que conducen a la baja, puede distinguir entre las siguientes clases de baja:

• Un bien vendido da como resultado ingresos realizados. La venta se contabiliza con un deudor.

• Es necesario desguazar el activo fijo sin ningún ingreso realizado.

• Un activo fijo se vende a una institución.

En el caso del Ministerio de Hacienda de Republica Dominicana se deben considerer los siguientes motivos de descargas:

Motivos de descargos

161

• Obsolescencia técnica

• Mantenimiento o reparación onerosa

• Siniestro (Ciclón, Incendio, Terremoto, Inundaciones)

• Destrucción

• Deterioro

• Pérdida

• Robo

• Desapoderamiento

Cada motivo de descargos debe considerar una determinacion de cuenta que permita configurar los movimientos contables que se requieran de acuerdo a los requisitos del Ministerio de Hacienda de Republica Dominicana. En este caso se debe aplicar el “Descargo Automatico”, el cual consiste en descargar el bien de la institucion y darle de alta en “Inventario de Bienes del Estado Dominicano no Asignados”.

Se debe considerar las siguientes clasificaciones de descargos indicadas el el numeral 5.11.13.3.3

Tipos de descargos Acciones a realizar

Para inventario • Alta en el inventario de bienes del Estado Dominicano no

asignado.

Sin traslado • Se requiere la asignación de un tiempo por tipo de bien para

poder hacer el traslado

• Tomar en cuenta que se puede hacer la subasta sin trasladar

el bien y la persona que lo compra debe hacer el traslado.

• Alta en el inventario del Estado Dominicano.

Con traslado • Alta en el inventario del Estado Dominicano.

Descargo por deterioro • El objetivo es desapoderamiento o para incineración.

• Se requiere que esta opción realice las mismas transacciones

del descargo por inventario, es decir, dar de baja en el

inventario de la institución y alta en el inventario del Estado

Dominicano con su correspondiente contabilidad.

• En adición, se requiere que se realice de forma automática la

transacción de deterioro.

162

3.3.22.17 Inventario de bienes del Estado Dominicano no asignados

Bansadonos en lo indicado en la PARTE A – REQUERIMIENTOS FUNCIONALES LOTE 1, Numeral 5 Bienes de Uso (muebles, inmuebles e intangibles) y sus respectivos Sub-Numerales 5.11.14 “Inventario de bienes del Estado Dominicano” y sus respectivos Su-numerales 5.11.14.1 al 5.11.14.2 de la Licitación Pública (Referencia: PAFI-CCC-LPN-2018-0003) de Julio del 2018, procedemos a describir la solución que ofrece SAP que cubre los escenarios requeridos por el Ministerio de Hacienda de la Republica Dominicana.

Un inventario es la actualización de las cantidades y los importes relacionados con el patrimonio de bienes de uso, en especial aquellos bienes que son descargados (dados de baja) y se procedera a dar de baja de la institución y darle de alta en inventario de Bienes del Estado Dominicano administrado por DGBN.

Un inventario es la actualización de las cantidades y los importes relacionados con el patrimonio de bienes.

El componente de Administracion de Bienes de Uso suministra las siguientes funciones para apoyar al

inventario.

Lista de inventario

El sistema suministra un listado de inventario para ayudar con el inventario de bienes (en este caso en el

inventario de bienes del estado dominicano). Este listado se puede encontrar en el sistema de información

estándar de la Administracion de Bienes de Uso (Contabilidad de activos fijos).

Código de barras

Existe un reporte adicional que permite imprimir información seleccionada procedente del registro maestro del bien conjuntamente con un código de barras. Se imprime en un formulario que el usuario puede definir libremente. Se puede utilizar la impresión para etiquetar los bienes para su identificación individual. El código de barras es unívoco para cada bien, puesto que representa (en la versión estándar del sistema) el número y el subnúmero del bien.

Considerar que una vez se complete el descargo y se encuentra en “Inventario” se debe considerar que el bien puede tener las siguientes consideraciones:

Una Reasignación a otra institución

Envío a reparación

163

Envío a subasta

• Por lote o unidad

• Cuando se envía a subasta, se clasifican los bienes

como sigue:

a. Mobiliario

b. Equipos

c. Vehículos reparables d. Piezas y partes

3.3.22.18 Solicitud de Inspección


Uso (muebles, inmuebles e intangibles) y sus respectivos Sub-Numerales 5.11.15 “Solicitud de Inspección” de



Dominicana.

En SAP con la ayuda de Las hojas de ruta para la inspección de bienes con fines de planificar actividades para

llevar a cabo inventarios de bienes, evaluar el estado de los mismos, determinar su mantenimiento, a través

de esta funcionalidad describen una secuencia de operaciones de inspecciones individuales que se han de

realizar repetidamente dentro de una institución. Se usan las hojas de ruta para estandarizar estas secuencias

de trabajo de repetición y planificarlas con mayor eficacia.

Entre las actividades para un objeto técnico, se incluyen por ejemplo

• Inspecciones

• Inventarios

• Mantenimiento

• Reparaciones

Las hojas de ruta ayudan a reducir el esfuerzo de inspecciones cuando las secuencias de trabajo

estandarizadas se modifican, por ejemplo, como consecuencia de una nueva normativa legal. Debe llevar a

cabo las modificaciones en un lugar específico de la hoja de ruta para las inspecciones correspondientes.

164

Con las hojas de ruta para inspeccion, puede reducir el tiempo necesario para crear órdenes de

mantenimiento y posiciones de mantenimiento (en caso de requerirse) y seguir haciendo referencia a las

operaciones y secuencias ya introducidas en la hoja de ruta para la inspección de inventario.

Además, puede incluir características de inspección del módulo Gestión de calidad (no en este alcance para

el MHRD) en hojas de ruta para mantenimiento y, si fuera necesario, incluir las hojas de ruta en la función de

gestión de instrumentos de inspección. Este proceso es aconsejable, por ejemplo, si se desean mantener

datos individuales para cada pieza de los instrumentos de inspección o si, por el contrario, desea obtener un

registro del historial de resultados.

3.3.22.19 Solicitud de asignación de bienes disponibles


Uso (muebles, inmuebles e intangibles) y sus respectivos Sub-Numerales 5.11.16 “Solicitud de asignación de

bienes disponibles” de la Licitación Pública (Referencia: PAFI-CCC-LPN-2018-0003) de Julio del 2018,


Hacienda de la Republica Dominicana.

Este requerimiento se desarrollara a través del Portal en donde se generara una orden de asignación del

bien (Traspaso del bien) previo a las autorizaciones y disponibilidad.

3.3.22.20 Solicitud de cambio de parámetros


Uso (muebles, inmuebles e intangibles) y sus respectivos Sub-Numerales 5.11.17 “Solicitud de cambios de

parametros” de la Licitación Pública (Referencia: PAFI-CCC-LPN-2018-0003) de Julio del 2018, procedemos a


Republica Dominicana.

Este requerimiento se desarrollara a través del sistema de Flujos de Procesos.

3.3.22.21 Registro de Reparaciones y Registro de Mantenimiento Preventivo y Correctivo


Uso (muebles, inmuebles e intangibles) y sus respectivos Sub-Numerales 5.11.3 Registro de Reparaciones y

5.11.18 “Registro de mantenimiento preventivo y correctivo” de la Licitación Pública (Referencia: PAFI-CCC-


requeridos por el Ministerio de Hacienda de la Republica Dominicana.

165

En SAP las reparaciones de los bienes se planifican y controlan a través de la solución de Mantenimiento de

Planta. Este componente contiene las funciones:.

El modulo de mantenimiento comprende las siguientes actividades:

• Inspección: Todas las medidas que establecen la condición real de un sistema técnico.

• Mantenimiento preventivo:Todas las medidas que mantienen la condición ideal de un sistema

técnico.

• Reparar:Todas las medidas que restablecen la condición ideal de un sistema técnico.

3.3.22.21.1 Mantenimiento Preventivo

El mantenimiento preventivo considera dentro de sus caracteristicas el manejo de:

• Equipo y / o ubicaciones funcionales

• Órdenes de mantenimiento

• Almacenar las actividades que se realizarán, en forma de listas de tareas de mantenimiento.

• Definir el alcance del mantenimiento preventivo y el trabajo de inspección y cuándo debe realizarse

en piezas de equipos y ubicaciones funcionales.

• Definir la frecuencia de tareas recurrentes de mantenimiento y servicio, ya sea:

o Basado en tiempo o basado en contador

o Basado en tiempo y basado en contador

• Definir la asignación basada en costos de las actividades de mantenimiento preventivo e inspección

desde el comienzo.

Mantenimiento planificado

El término "Mantenimiento planificado" incluye todo el trabajo de mantenimiento que puede planear para

el alcance de trabajo y las fechas tope, o sea, la inspección, el mantenimiento y reparaciones planificadas.

En el componente de aplicación Mantenimiento de Planta, se pueden definir también los intervalos en los

cuales se deberían ejecutar los pasos del trabajo individuales en la hoja de ruta para mantenimiento

planificado. Se asignan estas hojas de ruta a un plan de mantenimiento en planificación de mantenimiento.

166

De este modo, se garantiza que sólo las operaciones en la orden de mantenimiento que se han asignado al

paquete de mantenimiento que vence se puedan copiar al planificar el trabajo. El sistema crea órdenes de

mantenimiento cuando un plan de mantenimiento vence.

Mantenimiento actual

El trabajo de mantenimiento no incluido en el mantenimiento planificado se clasifica en el mantenimiento

actual.

Las hojas de ruta para el mantenimiento actual sirven de base para una orden de mantenimiento y se pueden

utilizar tomando como base los resultados de la inspección actual.

También se pueden utilizar hojas de ruta para mantenimiento como modelo y ayuda para obtener datos al

procesar órdenes de mantenimiento, asignando una hoja de ruta a una orden. Esto reduce

considerablemente la cantidad de preparación de trabajo necesario para las actividades de mantenimiento.

Si, por ejemplo, crea una orden de mantenimiento para una medida cuyas operaciones se han descrito ya en

detalle en una hoja de ruta para mantenimiento, introduzca únicamente esta hoja de ruta y las fechas topes

de realización en la orden. El sistema copiará las operaciones individuales de la hoja de ruta para

mantenimiento.

3.3.22.21.1.1 Hoja de Ruta para Equipo

Las hojas de ruta para equipo tienen un enlace específico con un equipo. Mediante las hojas de ruta para

equipos, podrá definir y gestionar de forma centralizada las medidas de mantenimiento de sus equipos. Las

hojas de ruta para equipo podrán ayudarle también a preparar planes y órdenes de mantenimiento.

Dentro de un grupo de hojas de ruta, cada hoja de ruta para equipo se identifica por un contador de grupos

de hojas de ruta. Esto le permite, por ejemplo, combinar en un grupo varias hojas de ruta para equipo. Dentro

del grupo de hojas de ruta, el sistema asigna un número secuencial (el contador de grupos de hojas de ruta)

a cada hoja de ruta individual para equipo.

3.3.22.21.1.2 Hoja de Ruta para Ubicación Tecnica

Una hoja de ruta para ubicación técnica se asigna a una ubicación técnica específica. Mediante una hoja de

ruta de ubicación técnica, podrá definir y gestionar de forma centralizada las medidas de mantenimiento de

su ubicación técnica. Las hojas de ruta para ubicación técnica podrán ayudarle también a preparar planes y

órdenes de mantenimiento para ubicaciones técnicas.

167

Dentro de un grupo de hojas de ruta, cada hoja de ruta para ubicación técnica se identifica por un contador

de grupos de hojas de ruta. Esto le permite, por ejemplo, combinar varias hojas de ruta para ubicación técnica

en un grupo. Dentro del grupo de hojas de ruta, el sistema asigna un número secuencial (el contador de

grupos de hojas de ruta) a cada hoja de ruta para ubicación técnica individual.

3.3.22.21.2 Ordenes de Mantenimiento

Las órdenes constituyen una parte importante de la planificación detallada de medidas y de su

documentación correspondiente en Mantenimiento.

Integracion

Gestion de Bienes de Consumo:

• Representación de todos los procesos necesarios para la gestión de piezas o materiales.

• Gestión de piezas de reserva que deben renovarse.

• Aprovisionamiento externo de materiales y servicios.

Finanzas

• Gestión de datos de deudor y acreedor.

• Gestion presupuestaria

o Control de fondos.

o Cierre de la liquidación de servicios, operaciones y material que puede dar lugar a un

comprometido sin imputación especial.

Gestion de Bienes de Uso (Activos Fijos)

• Liquidación directa de actividades que deben capitalizarse en el sistema afectado.

• Visualización de la conexión entre vistas institucionales y vistas específicas de mantenimiento de su

sistema.

3.3.22.21.2.1 Clases de Ordenes de Mantenimiento

La clase de orden es una característica de clasificación de órdenes. Consta de la información de control

importante para gestionar órdenes.

168

Las clases de orden se utilizan principalmente para agrupar órdenes según los componentes de aplicación.

Las estructuras más detalladas también tienen en cuenta las opciones de realización y gestión posterior de

órdenes individuales.

Por ejemplo, en el sistema estándar están disponibles las clases de orden siguientes:

• PM01 para órdenes de mantenimiento (PM)

• PM04 para órdenes de renovación (PM)

• PM06 para órdenes de inversión (PM)

• SM01 para órdenes de servicio (CS)

La orden se puede utilizar para concretar el trabajo que se debe realizar. Esto es importante para minimizar

el tiempo improductivo, sobre todo de los objetos centralizados.

Según la clase de la orden y el trabajo planificado, puede ejecutar la planificación en grados de detalle

diferentes:

Órdenes - entrada rápida: Puede introducir los datos necesarios en la pantalla de cabecera de la orden y no

tiene que llamar otra pantalla de operación.

Órdenes - sin planificación detallada: Puede introducir cualquier número de operaciones en el formulario

de lista en la pantalla de resumen de la operación.

Órdenes con la planificación detallada: Puede llamar pantallas de datos detallados para cada operación,

para introducir los datos siguientes:

• Datos de trabajo interno (por ejemplo, los datos de salario)

• Datos de trabajo externo (por ejemplo, el precio, el grupo de compras)

• Datos de la operación.

La gestión de órdenes proporciona un gran número de funciones, aunque no todas ellas se deben utilizar

durante la gestión. Cada institución puede determinar flujos de procesos propios en función de sus

necesidades.

Planificación con referencia a:

• La operación

• Los puestos de trabajo y el número de personas implicadas

• El material y, si fuera necesario, se utilizarán listas de materiales

169

• Uno o varios objetos

• Las fechas y los tiempos de ejecución

• Las hojas de ruta

• Los costes y la liquidación (norma de liquidación)

• Las relaciones

• Las asignaciones de órdenes

• El factor de ejecución

• Los datos de usuario

• El presupuesto

• Los medios auxiliares de fabricación (MAFs)

• Los permisos

• Las capacidades

• Las subcontrataciones

Control

• Verificación de la disponibilidad de materiales y medios auxiliares de fabricación

• Liberación de la implementación

• Impresión de documentos de trabajo

Implementación

• Período de utilización del material

Cierre

• Notificación de cierre

• Cierre técnico

• Liquidación de costes

170

3.3.22.22 Arrendamiento y Alquileres (Administración de Bienes Inmuebles)


Uso (muebles, inmuebles e intangibles) y sus respectivos Sub-Numerales 5.11.19 “Arrendamientos y

Alquileres” de la Licitación Pública (Referencia: PAFI-CCC-LPN-2018-0003) de Julio del 2018, procedemos a



Este componente organiza las necesidades de la Administración de bienes inmuebles en un resumen

general de las operaciones relevantes:

Administración de bienes inmuebles

Creación y gestión de todos los objetos necesarios para la administración de bienes inmuebles (unidad

económica, terreno, edificio, unidad de alquiler, salas).

Contrato de alquiler

Procesos en curso que van desde la creación del contrato de alquiler, pasando por la revisión del alquiler, la

contabilidad de alquileres o la liquidación del alquiler, hasta la rescisión del contrato y la recepción

definitiva de la unidad de alquiler.

Administración externa

Complemento de la administración externa de bienes inmuebles mediante la liquidación de honorarios o

los costes e ingresos del propietario.

Toma en arrendamiento

Vista de crédito del proceso de arrendamiento para el controlling de los flujos financieros para el

arrendador y la entrada de gastos.

Integración de procesos importantes en la gestión de los bienes inmuebles:

• Contabilizaciones en la Administracion de Bienes de uso.

• Controlling de bienes inmuebles (planificación de costes/facturación de actividades

multisociedades/liquidación de costes/facturación de los centros de beneficio)

• Planificación y controlling de nuevas construcciones, medidas de mantenimiento y remodelación

• Tratamiento de pedidos y gestión de comprometidos en las operaciones y el mantenimiento de

bienes inmuebles.

171

3.3.22.22.1 Arrendamiento

Este componente incorpora todas las funciones necesarias para el proceso de arrendamiento:

• Administración de contratos de alquiler (tratamiento de solicitudes, ofertas, contratos de alquiler y rescisiones)

• Contabilidad de alquileres (tratamiento de posición del Debe, periodificaciones, contabilizaciones y cobros de alquileres)

• Liquidación de gastos adicionales

• Revisión del alquiler

• Liquidación de alquileres basados en el volumen de negocios.

3.3.22.22.2 Contabilidad de los Arrendamientos

La contabilidad de alquileres representa una contabilidad integrada de cuentas por pagar/cuentas por cobrar

en forma de contabilidad de partidas abiertas. Gestiona todas las contabilizaciones y operaciones al contado

con las partes contratantes. Las contabilizaciones se gestionan en el nivel más bajo para cada unidad de

alquiler y contrato de alquiler.

• La contabilidad de alquileres se divide en las funciones siguientes:

o Posición del Debe: La posición del Debe en el contrato de alquiler contabiliza o anula créditos

adicionales del arrendatario en cada contrato de alquiler. La posición del Debe en las

unidades de alquiler no alquiladas tiene en cuenta los costes analíticos de superficies no

alquiladas.

o Periodificación: Aquí se pueden separar las asignaciones periódicas de gastos e ingresos

relativos a pagos adelantados o atrasados para alquileres pendientes en la cuenta de

pérdidas y ganancias.

o Pagos: Los pagos comprenden funciones para las entradas de pago manuales y automáticas

(FI: programa de pagos/carga de extracto de cuentas/seguimiento de contabilizaciones para

rechazos de entradas de pago automáticas). En este caso, las partidas abiertas del cliente se

compensan o los pagos adelantados se contabilizan como pagos a cuenta no cualificados.

o Reclamación: Con el programa de reclamaciones se tiene acceso a todas las funciones de la

gestión de impagados. El programa de reclamaciones es idéntico a la gestión de impagados

de la contabilidad de deudores en la Gestión financiera.

172

3.3.22.22.3 Revisiones de Contratos de Arrendamiento

Este componente soporta métodos automáticos para la revisión de alquileres, es decir, la modificación en

masa de importes de condiciones individuales en una base legal o contractual.

Este componente soporta los siguientes métodos de revisión:

• Vivienda de referencia

• Lista indicativa de alquileres

• Comparación de procedimientos: Lista indicativa de alquileres versus vivienda de referencia

• Peritaje

• Medidas/reformas de construcción

• Revisión del alquiler regulado por índices

• Revisión libre (de vivienda/industrial/párking)

• Condiciones definidas por el usuario

• Cálculo de la rentabilidad

• Revisión debida a la modificación de superficie

• Transferencia del importe de la unidad de alquiler al contrato de alquiler o viceversa

• Integración de métodos de revisión específicos del Ministerio de Hacienda.

Requisitos legales

Los plazos y restricciones requeridos por ley para las revisiones del alquiler pueden definirse en la

parametrizacion de Bienes inmuebles y el sistema las tendrá en cuenta.

3.3.22.23 Solicitud de actualización de avaluo


Uso (muebles, inmuebles e intangibles) y sus respectivos Sub-Numerales 5.11.21 “Solicitud de actualización

de avaluo” de la Licitación Pública (Referencia: PAFI-CCC-LPN-2018-0003) de Julio del 2018, procedemos a



173

3.3.22.23.1 Registro de Inspecciones e Irregularidades – (Avisos de Inspeccion)

Este componente de aplicación se utiliza en la gestión de inspección para registrar el manejo de bienes,

evaluar su situación y proceder a su registro:

• Describir la condición en un bien (objeto)

• Efectuar una solicitud en el departamento de mantenimiento para poder ejecutar una medida

necesaria, en caso de sere necesaria.

• Documentar el resultado de la inspección.

En el caso del Ministerio de Hacienda de la Republica Dominicana los resultados deberán clasificarse de

acuerdo a los siguientes valores:

• Inspección satisfactoria

• Activo o bien – No localizado

• Activo o bien – No registrado en el sistema

• Instrucción de Descargos

• Instrucción para reparación

• Instrucción para mantenimiento

• Instrucción para reclasificar, cuando las características del activo no coincidan físicamente

con lo indicado en el sistema.

• Irregularidades por duplicidad en el serial

• Irregularidades por etiqueta o código que no corresponde

• Irregularidades por etiqueta no legible

• Uso inadecuado del bien

Adicional registrar el estado de conservación del bien:

• Normal

• Regular

• Deficiente

174

• Ruinoso

• Abandono

Un aviso de actividad describe una actividad de inspección (servicio) realizada previamente o una que no es

el resultado de una inspeccion. Proporciona sencillamente la documentación técnica de las actividades que

se realizaron así como el período de tiempo que abarcó y los resultados que se consiguieron. En

consecuencia, los avisos de inspección (actividad) se utilizan para disponer de la notificación técnica de las

de actividades de la inspeccion.

Por ejemplo, un aviso de actividad típico es el diagnóstico de inspección, ya que describe los resultados de

una inspección realizada para comprobar el estado real del bien. En la mayoría de casos, la inspección se

basa en una orden de inspección.

Otro aviso de actividad característico es el diagnóstico de mantenimiento. El diagnóstico de mantenimiento

documenta los valores técnicos del bien, determinados durante y/o después del trabajo de mantenimiento

planificado. Estos trabajos de mantenimiento se realizan para mantener el estado ideal del objeto y siempre

provienen de los planes de mantenimiento preventivo.

Al crear un aviso de actividad, ya se ha ejecutado una actividad. Se desea documentar esta actividad con un

aviso de actividad. Para realizar este paso, introduzca la información siguiente donde sea procedente:

• La actividad que se ha ejecutado

• Dónde se ha ejecutado la actividad

• Las consecuencias que puede tener (o haber tenido)

• Cuál era el alcance de la actividad

El aviso de actividad es distinto al aviso de avería o un aviso de cliente, ya que no es necesario describir las

averías o problemas, sino sólo las actividades que se hayan ejecutado.

3.3.22.24 Registro de Datos de Subasta


Uso (muebles, inmuebles e intangibles) y sus respectivos Sub-Numerales 5.11.24 “Registro de Datos de

Subasta” de la Licitación Pública (Referencia: PAFI-CCC-LPN-2018-0003) de Julio del 2018, procedemos a



Este requerimiento representa la creación de una ampliación que permita el control de la subasta de

bienes en base a lo planteado por el Ministerio de Hacienda de Republica Dominicana.

175

3.3.22.25 Registro de venta de Inmueble


Uso (muebles, inmuebles e intangibles) y sus respectivos Sub-Numerales 5.11.26 “Registro de Venta de

Inmueble” de la Licitación Pública (Referencia: PAFI-CCC-LPN-2018-0003) de Julio del 2018, procedemos a



SAP considera dentro de sus funciones la venta de un bien. Dependiendo de las consideraciones

institucionales o de la operación empresarial que conducen a la baja, puede distinguir entre las siguientes

clases de desincorporación del bien que generen ingresos por ventas:

• Un activo fijo vendido da como resultado ingresos realizados. La venta se contabiliza con un deudor.

• Un activo fijo vendido da como resultado ingresos realizados. La venta se contabiliza contra una

cuenta de compensación, es decir se puede compensar con saldos en caso de que sea un proveedor.

El sistema permite contabilizar la entrada en Cuentas por Cobrar (deudores), la contabilización de ingresos y

la baja del bien en un solo paso. En este movimiento de contabilización, primero debe contabilizar los

ingresos , y posteriormente contabilizar la baja del bien. Un indicador en el movimiento de contabilización

especifica que el sistema contabiliza la baja de un activo fijo después de la contabilización de ingresos.

176

3.3.22.26 Objetos de autorización (Seguridad)

El sistema SAP tiene una serie de procesos que controlan el funcionamiento de los bienes de uso fijos

iniciando desde la Solicitud de Pedido del Activo que se va adquirir en la que se involucra la creación de un

dato maestro del activo, lo que permite controlar, revisar y aprobar el proceso de adquisición del mismo.

Previo a este control que se realiza desde SAP, el comprador debe tener determinado si el bien adquirir

pertenece al rubro de activo fijo o un material.

El control de autorización del Sistema SAP se basa en objetos de autorización definidos por el sistema. Si se

utilizan estos objetos, el usuario puede definir autorizaciones. Estas autorizaciones pueden agruparse en

perfiles y asignarse a usuarios individuales.

Los objetos de autorización se representan en el sistema con campos especiales (por ejemplo, sociedad). Una

autorización se define especificando las entradas que se permiten para los campos particulares en el objeto

de autorización.

Los siguientes objetos de autorización se han definido para la Contabilidad de bienes de uso:

Funciones Objeto de autorización

Bienes de uso fijos en general Vista de activo fijo

Contabilización de activo fijo Sociedad/Clase de activo fijo

Contabilización de activo fijo Clase de activo fijo/Clase de movimiento

Actualización de clases de activo fijo Clases de activo fijo

Contabilidad de bienes de uso fijos Autorización para operaciones periódicas

Actualización de registros maestros de bienes de uso fijos

Sociedad/Clase de activo fijo


Sociedad/División


Sociedad/Centro de coste


Sociedad/Centro

Actualización de complejos de bienes de uso fijos Complejo de bienes de uso fijos

Customizing del activo fijo Plan de valoración

177

3.3.22.27 Proceso de Cierre en Bienes

Cierre de Administracion de Bienes Mensual

El componente para la Administracion de Bienes de Uso provee de herramientas que facilitan el cierre de los

auxiliares de bien de uso y afectar de manera automatica la contabilidad de mayor.

Definir de manera detallada aquellos procesos que se pueden llevar a cabo durante el cierre del periodo o

ejercicio en la Administracion de bienes de uso, utilizando operaciones periodicas.

Todo movimiento de un bien de uso en el componente de la Administración de Bien de Uso en el Sistema

SAP provoca una modificación inmediata en la amortización prevista. Sin embargo, no se produce una

actualización inmediata de la amortización y de las cuentas de amortización acumulada para el balance y las

cuentas de pérdidas y ganancias. La amortización planificada se contabiliza en el libro mayor en el momento

de efectuar la ejecución periódica de contabilización de amortizaciones. Esta ejecución de contabilización

contabiliza la amortización planificada para cada nivel de imputación para cada bien de uso individual en

forma de cantidad global.

El cálculo y la programación de la amortización, del interés y de la revalorización son controlados, de forma

automática, por las claves del sistema, pero también se pueden controlar de forma manual, por medio de

una operación de contabilización especial. En ambos casos, la amortización planificada de la Administración

de Bien de Uso debe contabilizarse periódicamente en el bien de uso correspondiente y en las cuentas de

gastos del libro mayor. Además de las diferentes clases de amortización, interés y revalorización, esta

ejecución de contabilización también contabiliza la asignación y la liquidación de provisiones especiales.

Cuando el sistema contabiliza la amortización, crea documentos colectivos. No crea documentos separados

para cada bien de uso.

178

Valoración paralela (De requerir distintas areas de valoracion)

Junto con la contabilización de la amortización (utilizando la ejecución de contabilización de amortizaciones),

la operación periódica más importante que se lleva a cabo es la contabilización de modificaciones en los

valores del balance de bien de uso. Estos cambios consisten en todas las contabilizaciones que afectan a los

valores del bien de uso, incluyendo altas, bajas, etc.

Cierre de Administracion de Bienes Anual

El cierre del ejercicio es un balance anual, una cuenta anual de pérdidas y ganancias y un apéndice con

información adicional (report anual) que debe ser creado para cumplir con los requisitos legales propios de

cada país. Antes de poder cerrar un ejercicio en la Gestión financiera desde la perspectiva contable, deben

realizarse medidas preparatorias en la Administración de Bienes de Uso.

Se utiliza el programa de cierre de ejercicio para cerrar el ejercicio para una o más instituciónes desde la

perspectiva financiera. Una vez cerrado el ejercicio ya no se pueden contabilizar o modificar valores en la

Administracion de Bien de Uso (por ejemplo, un nuevo cálculo de la amortización). El ejercicio cerrado es

siempre el año siguiente al último ejercicio. No se puede cerrar el ejercicio en curso.

3.3.22.28 Administracion de Bienes – Reportes a considerar

Nota: Los siguientes reportes se basan en los reportes que genera el sistema SAP S/4HANA de manera de

estándar.


1 Bienes muebles por motivos de descargos


2 Muebles prestados o afectación en uso


3 Muebles e inmuebles por motivos de alta


4 Bienes reasignados


5 Bienes subastados


6 Bienes por distrito catastral


7 Bienes por número de título/matricula


8 Bienes por responsable


9 Bienes por custodia


10 Terrenos desocupados por zona Funcionalidad nativa (estándar) de la solución

179

3.3.22.29 Administracion de Bienes – Interfaces


1 Interfaz con Portal de Compras y Contrataciones Ampliaciòn a la funcionalidad (Desarrollo)

2 Interfaz de Compras SIGEF Ampliaciòn a la funcionalidad (Desarrollo)

3 Interfaz con sistema de Jurisdicción inmobiliaria Ampliaciòn a la funcionalidad (Desarrollo)

4 Interfaz con sistema de Catastro Nacional Ampliaciòn a la funcionalidad (Desarrollo)

5 Interfaces con sistema de la DGII Ampliaciòn a la funcionalidad (Desarrollo)

6 Interfaz con Contabilidad SIGEF Ampliaciòn a la funcionalidad (Desarrollo)

7 Interfaz con ERP sistema de cobros de DGBN Ampliaciòn a la funcionalidad (Desarrollo)

8 Interfaz con sistema SIRIT Ampliaciòn a la funcionalidad (Desarrollo)

3.3.22.30 Administracion de Bienes – Otras consideraciones

Sección Numero Ítem Motivo

1 Bienes Muebles/Inmuebles

5.11.9. Prestamos Internos Flujo de proceso


5.11.10.3 Prestamos Interinstitucional

Debe existir un flujo de proceso para manejar niveles de autorización por órgano rector, DGBN.


5.11.11.4 Traslados Internos Se requiere que exista un flujo de procesos para manejar niveles de autorización de solicitudes


5.11.12.4 Traslados interinstitucionales

Se requiere que exista un flujo de procesos para manejar niveles de autorización de solicitudes.

5 Bienes Muebles/inmuebles

5.11.13.2.1 Descargos – Solicitud Se requiere que, mediante funcionalidad, las instituciones del Estado Dominicano soliciten

11 Proyectos por estatus


12 Reporte de inventario de software crítico/activos fijos administrados por las TIC’s para la OPTIC.


13 Proyectos en proceso (deslinde, saneamiento)


14 Descargos realizados por modalidad


180

vía flujo de proceso el descargo de un (1) o un grupo de bienes


5.11.13.2.3 Avisos Se requiere que el sistema le presente al usuario, los requisitos que se necesitan para hacer el descargo a modo informativo. Por ejemplo: El traslado de los equipos, debe cubrirlo la institución que solicita el descargo.


5.11.13.2.4 Autorización DGBN recibe la solicitud y autoriza el proceso de descargo para proceder con la coordinación correspondiente y agendar

8 Inventario de Bienes

5.11.15 Solicitud de Inspección Se requiere crear flujo de proceso para que las instituciones del Estado Dominicano puedan solicitar a DGBN la inspección de sus bienes, por motivos distintos a la revisión periódica establecida vía el portal de transacciones.

9 Inventario de Bienes

5.11.17 Solicitud de Cambios de Parámetros

Se requiere que las instituciones del Estado Dominicano realicen solicitudes vía flujo de procesos para adicionar y modificar parámetros del módulo, con el objetivo de que puedan ser aprobados y administrados por los entes reguladores, DGBN o DIGECOG, según corresponda.

10 Arrendamiento y Alquileres

5.11.19.2 Arrendamiento y Alquileres de Bienes Inmuebles

Se requiere flujo de proceso para que las instituciones del Estado Dominicano soliciten a DGBN la autorización para alquilar o arrendar un bien bajo su dominio o propiedad, previamente registrado en el sistema.

11 Registro de Irregularidades de Bienes

5.11.21.1 Registro de Irregularidades de Bienes

Se requiere crear flujo de proceso para que DGBN le solicite a Catastro Nacional para que revisen el valor del inmueble.

181

4. REQUERIMIENTOS NO FUNCIONALES LOTE # 1

4.1 Objetivos específicos

4.1.1 Inteligencia de Negocios

Bansadonos en lo indicado en la PARTE A – REQUERIMIENTOS FUNCIONALES LOTE 1, Numeral 6

Requerimientos No Funcionales Lote 1 y su respectivo Sub-Numerale 6.4 “Inteligencia de Negocio” de la

Licitación Pública (Referencia: PAFI-CCC-LPN-2018-0003) de Julio del 2018, procedemos a describir la solución

que ofrece SAP que cubre los escenarios requeridos por el Ministerio de Hacienda de la Republica Dominicana.

S/4HANA Embedded Analytics permite al usuario realizar informes en tiempo real directamente sobre los

datos operativos sin la necesidad de cambiar entre dos sistemas diferentes para requisitos analíticos y

transaccionales, como SAP ERP y SAP BW, por ejemplo. S/4HANA proporciona una variedad de contenido

analítico listo para usar predefinido, por ejemplo: cabinas de negocios inteligentes, informes

multidimensionales, aplicaciones FIORI, así como un sistema embebido BW, que básicamente combina las

funcionalidades OLTP y OLAP en un único sistema y elimina la necesidad de un sistema de almacenamiento

de datos adicional, así como del proceso ETL que consume mucho tiempo. Se puede acceder al contenido

analítico de S/4 a través de. FIORI Launchpad o SAP Portal.

182

Embedded Analytics es la integración de contenido analítico y capacidades dentro del sistema operativo para,

por ejemplo, ERP System. Con la ayuda de un Modelo de Datos Virtual basado en los Servicios de Datos

Básicos (CDS) de ABAP para calcular las cifras clave y el procesamiento de los datos que garantizan un alto

rendimiento en una experiencia de usuario basada en FIORI para el usuario final. Además, las Vistas S / 4

ABAP CDS se pueden exponer a herramientas externas frontales para informes como SAP Lumira y Analysis

for Office.

Modelado y administración simplificados

Acelere las solicitudes de cambio y reduzca el tiempo de implementación, al tiempo que reduce el gasto de

desarrollo con funciones simplificadas de modelado y administración.

Experiencia de usuario mejorada

Aumente la productividad del usuario y reduzca los análisis ocultos, a la vez que aumenta la adopción del

usuario gracias a una experiencia de usuario intuitiva y una interfaz moderna.

Procesamiento de datos en tiempo real de gran volumen

Reduzca el tiempo de espera para el manejo de datos y habilite la automatización inteligente, con

procesamiento de datos de gran volumen en tiempo real.

4.1.2 Flujos de Procesos

Bansadonos en lo indicado en la PARTE A – REQUERIMIENTOS FUNCIONALES LOTE 1, Numeral 1.15 “Flujos

de Procesos” de la Licitación Pública (Referencia: PAFI-CCC-LPN-2018-0003) de Julio del 2018, procedemos a



4.1.2.1 SAP Business Workflow para S/4HANA

Fiori ha transformado radicalmente la Business Suite. Se ha confirmado que SAP puede simplificar

enormemente la interacción del usuario para un usuario de negocios y, al hacerlo, allana el camino para

facultar al usuario de negocios para lograr mucho más sin la necesidad de capacitación o documentación

adicional.

Para hacerlo, se debe replantear por completo "lo que se puede lograr", "cómo se puede lograr" y "qué

sacrificar" para que algo sea tan fácilmente consumible.

Al comienzo de esta revolución, el desarrollo del flujo de trabajo invirtió mucho tiempo en lluvia de ideas,

sesiones de pensamiento de diseño y un sinfín de introspección para llegar a un plan que respalde a la Suite

con sus nuevos y radicales requisitos.

183

4.1.2.2 El objetivo

SAP Business Workflow como plataforma para procesos de negocio tiene una base muy sólida y amplia. A

lo largo de los años, se ha ampliado para satisfacer las crecientes demandas de rendimiento de Suite, así

como sus ya impresionantes capacidades, mejoradas aún más por los proyectos de Customer Connection

donde los clientes y los consultores colaborativamente hicieron sugerencias de mejora que SAP codificó y

transfirió a versiones anteriores.

Por la naturaleza misma de las solicitudes de Customer Connection, ha confirmado que funcionalmente SAP

Business Workflow es increíblemente sólido. Pero la flexibilidad y la usabilidad podrían mejorarse. Por lo

tanto, para cumplir con los requisitos de S/4HANA, un enfoque que reutiliza las capacidades y el código

existentes pero que ofrece el uso de diferentes interfaces de usuario y la ampliación de la flexibilidad fueron

dos caminos que necesitaron un enfoque de desarrollo.

Soporte para el flujo de trabajo Usuario final

El usuario final del flujo de trabajo es el usuario que recibe las tareas del flujo de trabajo, realiza las

aprobaciones o completa los formularios. Entonces, el mejor lugar para mejorar su experiencia de usuario

es la bandeja de entrada. Hay otros blogs sobre My Inbox y cómo se simplifican radicalmente los negocios

diarios de los usuarios, por lo que no es necesario insistir en eso.

184

Vale la pena indicar:

• La interacción del usuario es simple e intuitiva

• My Bandeja de entrada se puede utilizar de fábrica (sin codificación) con casi todos los flujos

de trabajo existentes, un solo My Inbox entrega las tareas en un solo lugar,

independientemente del sistema de origen, las funciones para habilitar el uso diario

(sustitución, gestión de archivos adjuntos, gestión de fechas límite ...) se proporcionan de

fábrica.

4.1.2.3 Soporte para el propietario del proceso de flujo de trabajo

Las aprobaciones y las tareas de flujo de trabajo satisfacen un objetivo: el objetivo del proceso. Es el

propietario del proceso quien conoce este objetivo y tiene un gran interés en lograr este objetivo. El flujo de

trabajo es simplemente una herramienta para lograr este objetivo de manera constante, rápida y con bajos

costos. El nuevo requisito de S/4 HANA es proporcionar una experiencia de usuario al propietario del proceso,

para que ellos mismos puedan configurar el flujo de trabajo sin tener que descargarlo al departamento de

TI, que proporciona experiencia pero a costa del presupuesto y el tiempo. Empoderar al propietario del

proceso elimina estos costos, pero solo se puede lograr si la interacción del usuario es lo suficientemente

simple. Obviamente, hay algunos procesos que serán demasiado complicados para que el propietario del

proceso se automatice a sí mismo, pero hay muchos que sí pueden hacerlo.

S/4 Suite está habilitando esto, un escenario a la vez, y la aplicación Fiori Manage Workflows es lo que el

propietario del proceso usa para lograr esto. También le da al propietario del proceso la flexibilidad de

cambiar el proceso más a menudo de lo que se podría haber logrado al entregarlo al departamento de TI.

Por lo tanto, el propietario del proceso ahora es lo suficientemente ágil como para adoptar un proceso según

los requisitos locales o estacionales.

185

En la captura de pantalla anterior, puede ver que el usuario que creó este flujo de trabajo de aprobación en

tres pasos no necesitó un editor gráfico, o BPMN, sino que simplemente utilizó un asistente para definir el

proceso.

4.1.2.4 Notificaciones del Flujo de Trabajo

Una nueva forma de notificar a los usuarios acerca de las nuevas tareas son las Notificaciones automáticas

de flujo de trabajo. Estos se envían desde el centro de notificaciones Fiori 2.0. Sin ir a la aplicación My Box

de entrada, el usuario ve nuevas tareas rápidamente. Estas tareas incluso pueden manejarse directamente

sin tener que abrirlas. Es una solución poderosa que se puede configurar para cada flujo de trabajo. Por lo

tanto, puede optar por activ arlos para todos los procesos de flujo de trabajo o solo para los de tiempo crítico.

4.1.2.5 Worflow Analytics

También en el campo del análisis, se está haciendo el progreso necesario. De acuerdo con el concepto de

Fiori, las herramientas estan disponibles para monitorear los procedimientos de flujo de trabajo. Permitir a

los usuarios rastrear rápidamente problemas aquí y tomar medidas relevantes.

186

4.1.3 Portal de Autoservicio

SAP Enterprise Portal es el componente front-end web para SAP NetWeaver: la plataforma integral de

integración y aplicaciones que facilita la alineación de personas, información y procesos comerciales a través

de límites organizativos y técnicos. La solución del portal en las instalaciones ofrece un único punto de acceso

a fuentes de información SAP y no SAP, aplicaciones empresariales, repositorios de información, bases de

datos y servicios dentro y fuera de su organización. Puede acceder al portal desde los escritorios y desde

dispositivos móviles, como teléfonos inteligentes o tabletas. SAP Enterprise Portal le permite crear atractivos

portales corporativos que aprovechan la experiencia de la plataforma de lanzamiento SAP Fiori. La tecnología

y la arquitectura del portal garantizan que esté diseñado para la empresa, proporcionando un entorno seguro

y escalable.

4.1.3.1 Principales características

Acceso basado en roles: SAP Enterprise Portal proporciona acceso central, basado en roles y fácil a procesos de negocios e información a través de varios canales de consumo (escritorio / móvil).

Personalización: los usuarios clave y los usuarios finales pueden personalizar fácilmente la apariencia de su experiencia en el portal (por ejemplo, diseño de página, tema, favoritos).

Contenido predefinido El cliente de la interfaz de usuario proporciona acceso a contenido predefinido (paquetes empresariales) y listas de elementos de trabajo provenientes de Universal Work List, Power List (POWL) entregado por SAP Business Suite.

Usos de la aplicación: Utilizando servicios del cliente como navegación, favoritos o búsqueda, los usuarios pueden lanzar fácilmente aplicaciones web integradas (tecnologías de interfaz de usuario SAP o no SAP) como Web Dynpro para ABAP, Web Dynpro para Java, Web UI Framework, HTML5 (SAPUI5) y SAP GUI.

187

4.1.3.2 SAP Enterprise Portal en SAP NetWeaver 7.5 Integración SAP Fiori

El launchpad de SAP Fiori que se ejecuta en SAP Enterprise Portal es un hito clave en la alineación de los

Clientes de UI de SAP (Launchpad de Fiori, Portal, NetWeaver Business Client) con el diseño Fiori UX. Se

entrega como una nueva página de marco de portal multicanal siguiendo las pautas de diseño de Fiori,

mientras aprovecha los procesos tecnológicos y de administración subyacentes del portal.

• Mejor experiencia de usuario para el acceso de escritorio y móvil a través del diseño SAP Fiori2.0 con

el launchpad SAP Fiori. Diseño de elección: SAP Fiori, AJAX o página de framework personalizado.

• SAP S/4HANA integración utilizando catálogos remotos

• Integración de los reportes de SAP BusinessObjects.

• Integración de contenido de SAP Enterprise Portal en SAP Cloud Platform Portal

• Acceso a documentos intuitivo con SAP Document Centre

• Mejoras y simplificación de paisaje

4.1.3.3 SAP Fiori Launchpad on Portal

¿Qué es el launchpad de SAP Fiori?

El launchpad de SAP Fiori es un punto de agregación personalizado basado en roles para aplicaciones de

negocios y análisis. Se ejecuta en múltiples dispositivos, utilizando el paradigma de diseño receptivo, y se

puede implementar en múltiples plataformas. Está diseñado según la experiencia de usuario simple e

intuitiva de SAP Fiori, al tiempo que admite tecnologías de interfaz de usuario establecidas.

El launchpad de SAP Fiori que se ejecuta en SAP Enterprise Portal es un hito clave en la alineación de los

Clientes de (User Interface) de SAP (Launchpad de Fiori, Portal, NWBC) con el diseño Fiori UX (User

Xperience). Se entrega como una nueva página de portal de portal multicanal siguiendo las pautas de diseño

de Fiori mientras aprovecha los procesos de administración y tecnología subyacentes del portal. La nueva

plataforma de lanzamiento de Fiori en SAP Enterprise Portal es el enfoque recomendado para consumir SAP

Portal en dispositivos móviles.

Con el launchpad de SAP Fiori en Portal, los usuarios del portal pueden controlar qué aplicaciones aparecen

en su launchpad en los dispositivos móviles y en el escritorio.

188

Experiencia de usuario de SAP Fiori (2.0) para acceder fácilmente desde el escritorio y dispositivos móviles a

través de la página de Fiori

• Opción para que los usuarios finales construyan sus propias páginas de inicio específicas del

dispositivo

• AppFinde explorar y agregar contenido a la página de inicio

• Los administradores pueden configurar contenido para diferentes dispositivos

• API y complementos que le permiten ampliar y personalizar los escenarios de integración del

launchpad SAP Fiori

• Integración de aplicaciones SAP Fiori únicas en la navegación del portal

• Integración del launchpad SAP Fiori completo.

Experiencias de usuario del portal Dos sabores listos para usar: una plataforma

• Página de SAP Fiori Framework: en los escenarios del portal de la aplicación-Dispositivos cruzados

(diseño receptivo) -Optimizado para SAP Fiori.

• Ajax Framework: concéntrese en escenarios de intranet, externos y de administración: Solo para

uso de escritorio.

4.1.4 Documentos e Imagines

OpenText Extended ECM for SAP® Solutions es una solución integral para la integración de ECM con los

procesos comerciales administrados en SAP. El contenido no estructurado se puede administrar a lo largo de

su ciclo de vida y se puede conectar estrechamente a los objetos comerciales de SAP. El acceso coherente a

este contenido se da dentro y fuera de las aplicaciones de SAP. Esta sesión de CW365 ofrecerá una

descripción general de las propuestas de valor clave y destacará las nuevas capacidades agregadas por la

versión 10, como la integración de SAP CRM y la integración de SAP NetWeaver Portal.

189

SAP HANA proporciona una herramienta para su transformación digital que le permite a través de su

experiencia, compromiso de la fuerza de trabajo, proveedor colaboración y gestión de activos. La estructura

es compatible con esta información empresarial soluciones de gestión como SAP extendido Enterprise

Content Management (SAP Extended ECM) por OpenText. Estamodelo de negocio transformado lo ayuda a

cumplir los principales desafíos comerciales de hoy en día mediante la participación de clientes multimedia

con contenido multimedia, administrando un historial de empleados, controlando los costos de suministro,

y digitalizando la información de los activos para facilitar entrega a través de dispositivos moviles.

Colaboración centrada en el proceso

• Permite integrar con Microsoft Office 365 para admitir la coedición en línea, la integración del equipo de Microsoft y más opciones de colaboración.

• Se aprovechan las características del espacio de trabajo empresarial para fortalecer la colaboración interna, garantizar la divulgación precisa de la información y reutilizar el contenido corporativo tradicional.

Gestión de documentos

• Permite vincular cualquier parte del contenido electrónico a los procesos de negocio para que sea más fácil encontrar y compartir contenido.

• Garantiza la precisión y vigencia de la información mediante el control de la versión del documento, el control de acceso y las capacidades de seguimiento de auditoría.

190

• Ayuda a los usuarios a encontrar lo que necesitan, cuando lo necesitan.

Captura de documento

• Administa los requisitos de escaneo con etiquetado de metadatos automatizado y escaneo de imágenes mejorado.

• Admite los sistemas empresariales clave y todos los principales hardware de escaneo para convertir los documentos en papel en activos comerciales digitales.

4.1.5 Geolocalización

SAP Geographical Enablement Framework para SAP S/4HANA y entrega objetos comerciales enriquecidos

geoespacialmente (como equipos, ubicación funcional, notificación y orden de trabajo) para Gestión de

activos. Permite el acceso a los datos geográficos de los objetos seleccionados desde las pantallas Web

Dynpro asociadas a través de un explorador de geometría y un editor de geometría, así como a través de

sistemas GIS externos utilizando herramientas GIS estándar.

4.1.6 Dispositivos inteligentes

SAP Fiori surgió como una idea innovadora y revolucionaria en su campo, creando una colección de

distintas aplicaciones que buscan revolucionar las experiencias que vive un usuario en cuanto a las

soluciones de trabajo de SAP.

Su aparición marcó un punto de inflexión en el aprovechamiento de soluciones tecnológicamente

innovadoras, ofreciendo mayor interactividad y variedad de recursos, cosa que antes no sucedía con tanta

flexibilidad en el entorno SAP. El conjunto de aplicaciones SAP de Fiori está diseñado bajo esquemas de

función específicas, pero siguiendo un patrón común: la interactividad.

Para Fiori es de vital importancia que sus aplicaciones ofrezcan el máximo volumen de interactividad. Es

por ello que las aplicaciones fueron diseñadas siguiendo modelos similares a las apps utilizadas tanto en

tablets como en smartphones.

191

De esta manera los usuarios pueden interactuar con ellas de una manera más simple y eficaz, gracias a la

interactividad de su diseño. Las funciones pueden ser simples o complejas, pero todas están diseñadas bajo

este esquema tipo app. Por ejemplo, usar una herramienta para aprobar compras ahora es más simple

debido a que hay una app de Fiori diseñada específicamente para esto.

Las soluciones SAP de Fiori fueron creadas no solo bajo los conceptos de la simplicidad, interactividad y la

eficacia, sino también bajo un esquema de portabilidad muy amplio. El motivo de ello es que gracias a la

tecnología desarrollada por esta compañía, este software funciona como si fuera una aplicación sin

necesidad de serlo. La instalación se suprime al lograr que las aplicaciones del entorno SAP de Fiori

funcionen directamente en el navegador de Internet de preferencia de cada profesional. Es posible sacar

provecho de este sistema tanto desde el ordenador como desde el teléfono móvil, lo que hace que su

acceso sea fácil y rápido, evitando las limitaciones que trae consigo una instalación que se realice

localmente en un almacenamiento de memoria.

4.1.7 Herramienta de migración de datos

192

Cuando una organización se plantea la migración de un sistema antiguo a uno nuevo, como un ERP; siempre existe una etapa del proyecto que suele menospreciarse. Esa fase es la de la mover los datos hacia el nuevo sistema: la migración de datos en sí.

SAP S/4HANA es un sistema altamente integrado. Por tanto, la identificación de los datos a convertir y la

secuencia en la que se ejecuten los procesos de conversión dependerán de las interrelaciones entre las

aplicaciones y las transacciones del Sistema SAP.

En un sistema SAP intervienen tres clases de datos: maestros, transaccional e Histórico.

• Datos maestros. Los datos maestros de la aplicación tienden a ser más estáticos una vez se han definido.

La mayoría de datos maestros se pueden extraer de los sistemas legacy existentes. Ejemplo de estos

datos son los proveedores, clientes, planes de cuentas, activos, inventarios, maestros de materiales,

registros de información sobre proveedores, etc.

• Datos transaccionales. Los datos transaccionales son datos actuales y pendientes por ser procesados

que deben capturarse en el sistema legacy y definirse en las aplicaciones de SAP S/4 HANA para la

conclusión del proceso empresarial. Ejemplo de estos datos son las cuentas x cobrar, cuentas x pagar,

pedidos de compra, ventas pendientes, pedidos atrasados, etc.

• Datos históricos. Los datos históricos deben trasladarse desde el sistema legacy al Sistema SAP ERP para

funciones de referencia. Ejemplo de estos datos son los pedidos de cliente cerrados, informaciones por

totales del libro mayor, etc. Es recomendable que los datos históricos sean transferidos al Data

Warehouse de SAP y no al ambiente transaccional. La carga de históricos no se ha considerado como

parte del alcance del proyecto.

Cada tipo de dato deberá ser analizado independientemente con el objeto de definir el procedimiento

apropiado para la conversión de datos. Al momento de tomar la decisión del proceso de automatización de

Go LivesinInterrumpirelnegocio§ Datamaestraconbajacalidadpuedeafectarelsoportealasáreasclavesdelnegocio

DatamaestranodeberetrasarelGoLive§ Elnogestionarelprogresodelproyectodedatamaestra

puedecausarsorpresasalfinaldelproyecto.

Sinsorpresas§ Ladeteccióndesorpresasdeformatempranasepuedenmanejar–

sorpresasdetectadasdeformatardíapuedenserungranproblemayafectarelproyecto

Adopcióndelusuario§ Faltadecalidadenladatapuedehacerquelosusuariosrechacenel

sistema§ ElROIdelproyectopuedeestarenriesgosielíndicedeadopciónseretrasa

193

carga es importante tener en cuenta la cantidad y la calidad de los datos. "Cantidad" se refiere a los datos

que se deben procesar (para un volumen alto se aconseja automatización). "Calidad" se refiere a la integridad

de los datos del sistema legacy. Debido a la integración del Sistema SAP ERP, las modificaciones directas a

las tablas de bases de datos no se permitirán, para problemas referentes a la integridad de los datos. Toda migración implica integración y calidad. Los fallos más frecuentes que suelen producirse en una migración de datos tiene que ver con estas cualidades y repercuten en cuestiones como:

• Errores de perfilado de datos, que causan problemas en la calidad y provocan retrasos en el plazo de entrega del proyecto de migración.

• Especificaciones inexactas o incompletas originadas por la falta de profundidad en el mapeo, ausencia de validaciones o lejanía respecto a las reglas de negocio.

• Subestimación de la criticidad de un proyecto de este tipo, que deriva en una inadecuada asignación de recursos, falta de planificación o carencia de las herramientas y perfiles necesarios para llevar a cabo la migración de datos con éxito.

Optimizar es la opción más indicada y debe tenerse en cuenta desde el principio, desde el momento en que se plantea la necesidad de llevar a cabo una migración de datos. Cuando la planificación tiene este alcance es fácil prever:

• La necesidad de conectar con el sistema antiguo y llevar a cabo procesos de migración reutilizables y automáticos que permitan, por ejemplo, utilizar el proceso de migración en más de una ocasión. Los escenarios más comunes son los entornos de desarrollo, test y producción.

• Que a lo largo del proyecto de migración habrá momentos en que los dos sistemas tendrán que coexistir o relevarse. En ambas opciones el uso de la tecnología es básico para alcanzar objetivos.

• El time to market y los costes estimados, para lo que hay que descubrir, conocer y comprender todos los datos intervinientes en el proceso, evitando así las situaciones inesperadas que pudieran afectarles.

En cualquier caso, el mayor esfuerzo ha de concentrarse siempre en los procesos de extracción, transformación y carga, que constituyen el núcleo de toda migración de datos y pueden resumirse así:

Enfoque

Tradicional:

SAPERPSAP&LEGACY

SYSTEM(S) ?

Extract &

provision data

Es crucial identificar el

enfoque de migración de

data maestra junto con una

solución integrada para

asegurar el éxito de su

proyecto

Atención: La

migración de

data no es fácil

n Losproyectosdemigracióndedatosamenudoexcedenlostiempos

n yelpresupueston Lasorganizacionespuedenminimizarlasinterrupciones

yretrasosaplicandounconjuntodemejoresprácticas

n Lafaltadeunenfoquedeuntrack deProyectoparalamigracióndedatos

n Calidaddelosdatos

n PreparaciónparaunaGoLive rápido,fiableyriguroso

Por que?

Transformation Upload

Eldesafíodelamigracióndedatos

194

• Extracción: desde la fuente de origen hasta el área intermedia, creada a la imagen de aquella.

• Calidad: que es el momento de aplicar los procesos que, después de varias iteraciones, permitirán estar en disposición de garantizar la integridad y confiabilidad de los datos, tras haber eliminado errores e inconsistencias.

• Transformación: cuando los datos han sido enriquecidos, homogeneizados y se encuentran limpios, están ya preparados para comenzar a aplicar sobre ellos los procesos evolutivos que, en base a las funciones que representarán y a las reglas de negocio, los dejarán en condiciones de ser cargados.

• Carga: desde ese área donde los datos han sido preparados se procederá a su carga al sistema de destino en el modo y formato adecuados.

Deben existir roles asignados y responsabilidades claras, para quienes apoyen los procesos de extracción y carga de datos, esto con el fin de lograr la validación previa en un repositorio temporal y la carga y validación en el sistema destino. Este esquema de gobierno le podrá ser útil para la puesta en producción y posterior operación del sistema. Nosotros en GBM recomendamos que el Ministerio de Hacienda de la Republica Dominicana asigne a una persona la gobernabilidad del proyecto de datos para este proyecto. Normalmente quienes conocen los datos existentes en un sistema de información son los usuarios funcionales, por eso es necesario establecer un equipo de trabajo con ellos junto al responsable de datos del proyecto , apoyado por el consultor de Datos maestros de GBM para que realice las labores de extracción, transformación y carga (ETL). Criterios como: integridad, precisión, consistencia, unicidad y oportunidad, son claves para la aprobación de los datos a ser cargados en el sistema destino. Para lograr esto se deben definir herramientas de control de cada uno de estos elementos de calidad en los diferentes momentos de extracción y carga de los datos. SAP Best Practices para migración de datos Arquitectura para extraer, transformar, validar y cargar basado en SAP Business Object Data Services

195

Data Services

Transformation

Legacy

Data Source

Load

Staging Area &

DQ Metrics DB

Data Services

Conversion ETL

BAPI

Batch File

IDOC

Load

Load

Load

Legacy

Data Source

SAP

Systems

LSMW

or DS

LSMW

Cleanse & Consolidate

Validate Load ReconcileExtractData Analysis

Extract

LSMW

or DS

Extract Configuration & Post Load ReconciliationData Services

Profiling

Extract

1. Extracción de Data: El uso de SAP BusinessObjects Data Integrator permite conectar al sistema legacy para extraer la data (maestra y transaccional)

2. Data mapping: La funcionalidad de mapeo de data y re-cestructuracion soporta todos los objetos requeridos para configurar SAP Business All-in-One como el sistema destino.

3. Data validation: Tiene contenido pre-definido con lógica de negocio y validaciones para mejorar la calidad de la data e identificar errores de forma temprana en el proceso.

4. Data load: Contiene programas para activar los IDOC’s para el proceso de migración de data.

5. Reconciliación de data: Información para poder validar la carga de la data

Extract Data1 Map data2 validate data3 load data 4 reconciledata 5

196

Extracción y perfilamiento de datos: Es imprescindible tener el conocimiento, no sólo de los datos que recogeremos de la base de datos antigua en nuestro proyecto de migración, sino también de cómo se comportan. El perfilamiento de datos forma parte de un proceso fundamental que se realiza previamente al diseño de las reglas de calidad, conocido como Data Discovery, en el que, por otra parte, se incluye también la identificación de ineficiencias y redundancias. ¿En que consiste el perfilado de los datos? Por perfilado de datos se entiende el análisis de los datos de los sistemas para entender su contenido, estructura, calidad y dependencias. Este paso es vital ya que a la hora de plantear un análisis de los datos de origen nos encontramos en muchas ocasiones que realmente no sabemos que hemos de preguntar, ni donde pueden residir algunos problemas. De esta forma el perfilado nos dará un análisis exacto de la estructura y el modelo de datos a tratar. SAP Data Services es la herramienta de perfilado nos dará “hechos sobre los que construir nuestro diseño”. Limpieza de datos: Una vez identificados los registros y los modelos de datos a través del perfilado, deberemos realizar el tratamiento de excepciones y de errores.

SAPBestPractices- DataMigrationparaSAPElenfoquedeMigración

Legacy Data Environment

Data Stagingand TestEnvironment

XML

Applications

Databases

Flat Files/Excel

Loading

Extract & Profile

Staging Area

SAP

Target Environment

Data Services Platform

Cleanse

Name Parsing

Address Parsing & Correction

Material/Product Parsing

Matching

SAP Configuration Extraction

Reconciliation

Transparency, Communication and

Governance,

Files

IDocs

Pre-Built load routines for SAP

Objects

Validate & Load

Transform

Business Validation Rules

Automatic SAP Config

Validation

TransformData into SAP

structure

197

Este punto consiste en analizar los informas del perfilado de datos y detectar todos aquellos formatos, registros nulos, contenidos o errores de integridad referencial que han aparecido y definir, junto con los responsables de los datos, como tratar cada una de las casuísticas que van apareciendo, por ejemplo:

• ¿Qué hacer con aquellos clientes que tienen el código de cliente con un formato incorrecto?,

• ¿Qué hacer con los registros nulos?,

• ¿Qué hacer con los formatos, estandarizarlos? Una vez tenemos claro que haremos con cada uno de los errores que sabemos que existen en los datos el siguiente paso es establecer la estrategia para corregir, estandarizar, eliminar o tratar todos esos errores y excepciones. El data cleansing, data scrubbing o limpieza de datos, es el acto de descubrimiento, corrección o eliminación de datos erróneos de una base de datos. El proceso de data cleansing permite identificar datos incompletos, incorrectos, inexactos, no pertinentes, etc. y luego substituir, modificar o eliminar estos datos sucios ("data duty"). Las inconsistencias descubiertas, modificadas o eliminadas pueden haber sido causado por: las definiciones de diccionario de datos diferentes de entidades similares, errores de entrada del usuario y corrupción en la transmisión o el almacenaje. La Limpieza de datos se diferencia de la validación de datos ("data validation"), en que la validación de datos cumple la función de rechazar los registros erróneos durante la entrada al sistema. El proceso de data cleansing incluye la validación y además la corrección de datos, para alcanzar datos de calidad ("Data quality"). La calidad de datos debe cumplir con los siguientes requisitos:

• Exactitud: Los datos deben cumplir los requisitos de integridad, consistencia y densidad. • Integridad: Los datos deben cumplir los requisitos de Entereza y validez.

✓ Entereza: Alcanzado por la corrección de datos que contienen anomalías. ✓ Validez: Alcanzado por la cantidad de datos que satisfacen las restricciones de integridad.

• Consistencia: Alcanzado por la corrección de contradicciones y anomalías sintácticas. • Uniformidad: Relacionado con irregularidades. • Densidad: Conocer el cociente de valores omitidos sobre el número de valores totales. • Unicidad: Relacionado con datos duplicados

Transformación de datos y carga: La fase de transformación aplica una serie de reglas de negocio o funciones sobre los datos extraídos utilizando para convertirlos en datos que serán cargados. Algunas fuentes de datos requerirán alguna pequeña manipulación de los datos mediante reglas (que pueden ser automatizadas). Algunas de las siguientes opciones se analizan:

• Seleccionar sólo ciertas columnas para su carga (por ejemplo, que las columnas con valores nulos no se carguen).

• Traducir códigos (por ejemplo, si la fuente almacena una "H" para Hombre y "M" para Mujer pero el destino tiene que guardar "1" para Hombre y "2" para Mujer).

https://es.wikipedia.org/wiki/Reglas_de_negocio

198

• Codificar valores libres (por ejemplo, convertir "Hombre" en "H" o "Sr" en "1"). • Obtener nuevos valores calculados (por ejemplo, total_venta = cantidad * precio, o Beneficio = PVP

- Coste). • Unir datos de múltiples fuentes (por ejemplo, búsquedas, combinaciones, etc.). • Calcular totales de múltiples filas de datos (por ejemplo, ventas totales de cada región). • Generación de campos clave en el destino. • Transponer o pivotar (girando múltiples columnas en filas o viceversa). • Dividir una columna en varias (por ejemplo, columna "Nombre: García López, Miguel Ángel"; pasar a

dos columnas "Nombre: Miguel Ángel", "Apellido1: García" y "Apellido2: López"). • La aplicación de cualquier forma, simple o compleja, de validación de datos, y la consiguiente

aplicación de la acción que en cada caso se requiera: ✓ Datos OK: Entregar datos a la siguiente etapa (Carga). ✓ Datos erróneos: Ejecutar políticas de tratamiento de excepciones (por ejemplo, rechazar el

registro completo, dar al campo erróneo un valor nulo un valor centinela). La fase de carga es el momento en el cual los datos de la fase anterior (transformación) son cargados en el sistema de destino SAP.

4.1.8 Plan de Proyecto

El plan de proyecto detallado se entregara en anexo adjunto.

https://es.wikipedia.org/wiki/Pruebas_de_validaci%C3%B3n

https://es.wikipedia.org/wiki/Manejo_de_excepciones

199

5. Arquitectura del Sistema

5.1 Esquema de integración basados en estandares abiertos

SAP Cloud Platform Integration es un sistema de integración abierto, flexible y bajo demanda que se ejecuta

como un servicio central en SAP Cloud Platform. Intercambie datos fácilmente y en tiempo real con la

integración de SAP Cloud Platform. Integre procesos y datos entre aplicaciones en la nube, aplicaciones de

terceros y soluciones locales.

Diversos escenarios

Integra procesos y datos en escenarios de aplicación a aplicación (A2A) y de empresa a empresa (B2B).

Múltiples puntos finales: Integra diversas aplicaciones y orígenes de datos de SAP y de otros, en las

instalaciones y en la nube.

Contenido preempaquetado: Aprovecha el contenido de integración preempaquetado para impulsar

proyectos de integración y escenarios rápidamente productivos.

Personaliza los escenarios de integración de SAP: Crea su propia extensión de los escenarios de integración

pre-entregados de SAP para incluir sus requisitos personalizados.

Adaptador SDK: Utilice nuestro SDK de adaptador para construir sus propios adaptadores personalizados

para necesidades de conectividad adicionales.

APIs Publicas: Personalice el acceso a la integración de SAP Cloud Platform con nuestras API públicas de

OData.

Seguro y confiable: Utilice nuestras capacidades básicas de integración y seguridad para el procesamiento

seguro e confiable y la integración de datos.

Sincrónico y asincrónico: Organice procesos comerciales e integre datos en escenarios en tiempo real y en e

scenarios asíncronos.

200

Integrar cada faceta de los procesos del MHRD nunca ha sido tan simple. Integre procesos y datos entre

aplicaciones en la nube, aplicaciones de terceros y soluciones locales con este sistema de integración abierto,

flexible y bajo demanda que se ejecuta como un servicio central en SAP Cloud Platform, e intercambie datos

fácilmente en tiempo real. Acceda a un catálogo profundo de flujos de integración e integre ambos procesos

y datos a través de una tecnología unificada diseñada para la nube. Descanse tranquilo sabiendo que la

integración es segura, confiable y administrada por SAP en los centros de datos de todo el mundo.

Ejemplo:

201

5.2 Arquitectura basada en componentes

La solución esta basada en el servidor de aplicaciones SAP Netweaver que esta basado en Arquitectura

Orientada a Servicios (SOA)

SAP contiene implícitamente la arquitectura SOA: la disciplina de la arquitectura de software se centra en la idea de reducir la complejidad mediante la abstracción y la separación de preocupaciones. Algunos ejemplos de arquitectura de Software incluyen el modelo de Servidor de Cliente, el modelo de computación distribuida. Servidor cliente: es una arquitectura de red que separa un cliente (a menudo una aplicación que utiliza una interfaz gráfica de usuario) de un servidor. Cada instancia del software del cliente puede enviar solicitudes a un servidor. Los tipos específicos de servidores incluyen servidores de aplicaciones, servidores de archivos, servidores de terminales y servidores de correo. Si bien su propósito varía un poco, la arquitectura básica sigue siendo la misma. Arquitectura de tres niveles:Three-tier es una arquitectura cliente-servidor en la que la interfaz de usuario, la lógica del proceso funcional ("reglas comerciales"), el almacenamiento de datos y el acceso a datos se desarrollan y mantienen como módulos independientes, la mayoría de las veces en plataformas separadas. La arquitectura de 3 niveles tiene los siguientes 3 niveles.

1. Nivel de presentación 2. Nivel de aplicación / Nivel lógico / Nivel de lógica de negocios 3. Nivel Nivel de acoplamiento suelto:Este término implica que los componentes de software que interactúan minimizan su conocimiento incorporado entre sí: descubren la información que necesitan en el momento en que la necesitan.

5.3 Codigo fuente

GBM garantiza el accedo al código fuente de la solución.

5.4 Modulos integrados

SAP Business Suite es un conjunto de programas que permiten a las empresas ejecutar y optimizar distintos

aspectos como los sistemas de ventas, finanzas, operaciones bancarias, compras, fabricación, inventarios y

relaciones con los clientes. Ofrece la posibilidad de realizar procesos específicos de la empresa o crear

módulos independientes para funcionar con otro software de SAP o de otros proveedores. SAP está basado

en una plataforma de tecnología integrada llamada NetWeaver. La suite puede soportar sistemas operativos,

bases de datos, aplicaciones y componentes de hardware de casi cualquier proveedor.

202

5.5 Soluciones WEB

La interfaz de usuario FIORI esta basada en estándares web HTML5 y puede ser accedida mediante PC,

Laptops o Dispositivos Móviles.

Con Fiori el Ministerio de Hacienda de la Republica Dominicana puede conectarse a las soluciones además

de crear y extender aplicaciones SAP Fiori / UI

Se puede aprovechar las plantillas de códigos listos para usar:basado en las mejores prácticas de SAP

• Extender las aplicaciones SAP Fiori existentes a través de puntos de extensión predefinidos

• Adaptar la interfaz de usuario de los elementos de SAP Fiori y aplicaciones

• Usa editores de texto y herramientas gráficas

• Implementar fácilmente en varias plataformas SAP.

5.6 Multicapas

SAP la arquitectura esta diseñada en un modelo de capas que incluye Capa de Base de Datos, Capa de

Aplicación y Capa de Presentación.

Con las capas dinámicas de SAP HANA, sus datos de acceso frecuente permanecen in-memory, mientras que

los datos de acceso poco frecuente son movidos al disco. Esto le permite gestionar de manera rentable

grandes volúmenes de datos sin estar limitado por el tamaño de la memoria. Sus aplicaciones pueden

acceder a todos los datos independientemente de dónde estén almacenados y puede modificar sus

preferencias de almacenamiento en cualquier momento para satisfacer las expectativas de los usuarios.

Elementos de la arquitectura de SAP

El sistema SAP está basado en una arquitectura cliente-servidor, lo que significa que hay una distribución de

las tareas que debe realizar el sistema.

Esta arquitectura que se encuentra dividida en niveles o 3 capas, cada una de estas capas o niveles tienes

unas características determinadas y se encarga de proporcionar ciertos servicios que veremos a

continuación.

Cada una de estas capas proporciona servicios a la capa inmediatamente superior (cliente) y solicita servicios

a la capa inferior (servidor).

203

Nivel de presentación o capa de presentación. Esta capa proporciona los servicios de presentación para la

implementación de SAP GUI, hace de interfaz entre el usuario y el sistema. La capa de presentación envía

información del usuario al sistema y muestra al usuario la respuesta del sistema, es el punto de conexión con

el usuario a través de un gadget tecnológico.

En esta primera capa o nivel los sistemas y componentes que tienen como misión garantizar la interacción

con el usuario final, por este motivo son procesos que tienen una interfaz gráfica visual, donde todo debe

quedar muy claro para facilitar los procesos.

A continuación vemos las características de esta capa:

Permite el agregado de nuevos equipos en cualquiera de sus 3 niveles para acomodarse a los requerimientos

dinámicos del sistema. El software normalmente continúa en vigencia más tiempo que el hardware que lo

soporta, por este motivo el software SAP dispone de una portabilidad a través de distintos tipos de hardware

y sistemas operativos todos los datos del sistema están almacenados en tablas que son accesibles sin

necesidad de instrucciones complejas de recuperación de datos.

Parametrizable: SAP es un software estándar que dispone de herramientas específicas para la adaptación del

software a las necesidades de la empresa, es decir es un software que puede parametrizarse según las

necesidades del cliente.

A este primer nivel también se le llama nivel cliente ya que se crea un vínculo directo con el cliente.

Primer Nivel de aplicación o capa de aplicación. En esta capa es donde más se interactúa como desarrollador

porque es la capa donde está el código ABAP y funciona como controladora entre la capa de presentación y

la capa de base de datos.

Es donde se realiza la gestión de las aplicaciones, siendo sistemas completos que se han configurado de una

manera específica para rendir a un alto nivel. Se caracteriza por tener un alto volumen de memoria RAM, por

lo tanto dispone de mayor potencia. Esta potencia que dispone está destinada en su mayor parte a que se

ocupe de la gestión y el funcionamiento de las distintas aplicaciones que funcionan dentro del entorno SAP.

Esta capa también se encarga de gestionar el reparto de trabajo y tareas para que un proyecto pueda llevarse

a cabo de manera eficiente. Reparte las tareas y los encargos de forma adecuada a fin de que el sistema

funcione correctamente.

Debemos tener en cuenta también que el sistema al estar formado por 3 niveles o capas, siempre debe de

haber uno que haga que punto de unión y conexión entre los 3. En este caso es el nivel de aplicación el que

se encarga de la interacción.

En resumen el nivel de aplicación es donde se encuentran los componentes técnicos enfocados a la memoria

y al rendimiento del sistema, además sirve de comunicación entre los otros 2 niveles.

204

Segundo Nivel de base de datos o capa base de datos: En este último nivel llamado base de datos es el que

se encuentra vinculado con los discos duros. Proporciona servicios de base de datos para el almacenamiento

y recuperación de los datos. En este nivel se encuentran componentes de gran tamaño y velocidad que deben

actuar con gran precisión para obtener un rendimiento óptimo del sistema. Es donde se encuentra

almacenados todos los datos que sirven de apoyo a todos los procesos de los que depende SAP. Es donde

encontramos todos los datos del servidor, incluso los programas ABAP.

Comunicación entre los elementos

A continuación describiremos brevemente la interacción entre el usuario final y el sistema, relacionándolo

con los componentes que intervienen en cada caso.

El usuario final interactúa en la Capa de Presentación a través de un terminal que tiene instalado SAP GUI o

FIORI. Esta capa captura todos los datos introducidos por el usuario (input) en los campos de texto o las teclas

pulsadas y los trasladados a la Capa de Aplicación para poder ser procesados.

En la Capa de Aplicación se reciben los datos y se ejecutan los módulos y sentencias de código ABAP que

están definidas.

En el caso que necesitemos buscar, insertar o modificar datos en las tablas de la base de datos se ejecuta la

comunicación con la Capa base de datos y obtenemos el output otra vez en la capa de presentación.

Esta combinación de los 3 niveles o capas explicados y su comunicación es lo que hace que SAP disponga de

una arquitectura equilibrada, ajustada y con un rendimiento óptimo.

5.7 Asincrona La comunicación entre la capa de aplicaciones y la capa de presentación es asíncrona.

5.8 Multithread SAP es una solución que maneja el Multithread. Es posible que haya estado en una situación en la que debe procesar múltiples objetos. Cuando esto sucede esto secuencialmente, tomará un tiempo antes de que termine el procesamiento. Una solución podría ser programar su programa en segundo plano, y simplemente dejarlo funcionar allí. Pero, ¿qué pasa si no tiene el lujo de programar su informe en segundo plano, o qué pasa si la cantidad total de objetos es tan grande que le llevaría un día procesarlos a todos, con el riesgo de sobrepasar su período de tiempo nocturno e impactar el trabajo diario. Multi Threading

205

Se puede lanzar múltiples bloques de procesamiento al mismo tiempo. Cada bloque podría procesar un solo objeto y cuando termine, libere la ranura para poder lanzar el siguiente bloque. Eso podría significar que podría tener varios objetos actualizados al mismo tiempo. Es iamginarse 10 objetos procesados a la vez en lugar de solo un objeto secuencialmente. Podría reducir su tiempo de ejecución a solo el 10% del informe original. En realidad no es tan difícil. Si crea un módulo de función habilitado remotamente, que contiene la lógica de procesamiento para un objeto, con los parámetros necesarios, puede simplemente iniciarlos en una nueva tarea. Eso crea un nuevo proceso (puede supervisarlo en la transacción SAP SM50) que terminará tan pronto como se procese su objeto. Definición: Multithreading significa iniciar múltiples hilos de ejecución en un solo programa Java. Ventajas de Multithreading

• Velocidad: Los subprocesos aumentan el rendimiento al permitir que su código se ejecute en todos los procesadores disponibles en una máquina multiprocesador.

• Capacidad de respuesta: En una máquina de un solo procesador, las tareas que requieren largos tiempos de espera (por ejemplo, acceso a la red, lectura de disco, cálculo de punto flotante) se pueden colocar en una secuencia separada. Por lo tanto, el procesador no necesita esperar y el tiempo de respuesta de la aplicación aumenta.

5.9 Arquitectura de la solución

5.9.1 Sistema Operativo

Según la Nota de SAP "2235581 - Sistemas operativos compatibles", las siguientes dos distribuciones de Linux

se pueden utilizar con la plataforma SAP HANA.

• SUSE Linux Enterprise Server para aplicaciones SAP (SLES para SAP)

• Red Hat Enterprise Linux para SAP HANA (RHEL para SAP HANA)

Estrategia de revisión de HANA

SAP envía correcciones y actualizaciones periódicas. Las correcciones se envían en forma de revisiones y

paquetes de soporte de los componentes del producto. Las nuevas capacidades de HANA se presentan dos

veces al año en forma de SAP HANA Support Package Stacks (SPS).

206

El Datacenter Service Point (DSP) se basa en la disponibilidad de una determinada revisión de SAP HANA, que

se había estado ejecutando internamente en SAP para aplicaciones empresariales de producción durante al

menos dos semanas antes de su lanzamiento oficial.

Sistema Operativo S/4HANA

5.9.1.1 SUSE® Linux Enterprise Server

SUSE® Linux Enterprise Server para aplicaciones SAP es un paquete de software y servicios que abordan las

necesidades específicas de los usuarios de SAP. Es el único sistema operativo que está optimizado para todas

las soluciones de software de SAP.

Los casos de uso de destino incluyen:

• Migraciones de Unix a Linux

• Dispositivos SAP

• Implementaciones en la nube de SAP

SUSE Linux Enterprise Server para aplicaciones SAP consta de componentes de software que se describen en

las siguientes secciones. La figura de SUSE Linux Enterprise Servidor para aplicaciones SAP muestra una

descripción general de los componentes y servicios de software también disponible con otros productos de

SUSE (verde) y que están disponibles exclusivamente con SUSE Linux Enterprise Server para aplicaciones SAP

(azul).

207

5.9.1.1.1 Componentes del Software

La versión actual se basa en SUSE Linux Enterprise Server 15. SUSE Linux Enterprise Server es la plataforma

más interoperable para la informática de misión crítica, tanto física como virtual.

5.9.1.1.2 SUSE Linux Enterprise High Availability Extension

Este componente consiste en:

• Agrupación flexible y orientada a las políticas

• Sistema de archivos con reconocimiento de clúster y gestión de volumen

• Replicación continua de datos

• Configuración e instalación

• Herramientas de gestión y administración.

• Gestión de recursos, también para SAP.

• Consciente de la virtualización.

SUSE Linux Enterprise High Availability Extension proporciona dos agentes de recursos específicamente

para trabajando con aplicaciones SAP:

• SAPInstance que permite iniciar y detener instancias de productos SAP.

208

• SAPDatabase que permite iniciar y detener todas las bases de datos admitidas por las aplicaciones

SAP (SAP HANA, SAP MaxDB, SAP ASE, Oracle, Sybase, IBM DB2). Configuración simplificada de

replicación del sistema SAP HANA

5.9.1.1.3 Configuración simplificada de replicación del sistema SAP HANA

SUSE Linux Enterprise Server para aplicaciones SAP admite SAP HANA System Replication usando

componentes de SUSE Linux Enterprise High Availability Extension y dos recursos adicionales agentes (RA).

Además, SUSE Linux Enterprise Server para aplicaciones SAP se envía con YaST asistente que simplifica la

configuración del clúster.

5.9.2 Base de Datos

En el núcleo de SAP HANA se encuentra la base de datos SAP HANA de alto rendimiento y en memoria.

SAP HANA es una plataforma en memoria que combina una base de datos compatible con ACID con

procesamiento de datos avanzado, servicios de aplicaciones y servicios flexibles de integración de datos. La

base de datos SAP HANA puede actuar como una base de datos relacional estándar basada en SQL. En esta

función, puede servir como proveedor de datos para aplicaciones transaccionales clásicas (OLTP) y / o como

fuente de datos para solicitudes analíticas (OLAP). Se accede a la funcionalidad de la base de datos a través

de una interfaz SQL.

5.9.2.1 Interfaces estándar de la Base de Datos

SAP HANA proporciona interfaces de bases de datos estándar como JDBC y ODBC y admite SQL estándar con extensiones específicas de SAP HANA.

5.9.2.2 Aprovisionamiento de datos

Varios mecanismos de aprovisionamiento de datos están disponibles para obtener datos de diferentes

fuentes en SAP HANA. Por ejemplo, en un mercado de datos o escenario de análisis, los datos se replican en

SAP HANA desde los sistemas de origen usando una de las tecnologías de replicación admitidas). Para las

aplicaciones que usan SAP HANA como su base de datos principal (como SAP S / 4HANA), los datos se crean

directamente en SAP HANA.

5.9.2.3 Recuperación de datos

Aunque la base de datos de SAP HANA contiene la mayor parte de sus datos en la memoria para obtener el

máximo rendimiento, aún utiliza el almacenamiento persistente para permitir el reinicio y la recuperación

del sistema. Hay una demora mínima y ninguna pérdida de datos en caso de falla. Por ejemplo, después de

209

un corte de energía, la base de datos puede reiniciarse como cualquier base de datos basada en disco y

retornar a su estado más reciente consistente. Además, SAP HANA proporciona funciones para copia de

seguridad y recuperación, así como también alta disponibilidad (recuperación ante desastres y recuperación

de fallas).

5.9.2.4 Landscape del Sistema Técnico para S/4HANA

Un sistema SAP HANA comprende múltiples bases de datos aisladas y puede consistir en un host o un clúster

de varios hosts (sistema de escalamiento horizontal).

Un sistema SAP HANA, identificado por un único ID de sistema (SID), contiene una o más bases de datos de

tenants y una base de datos del sistema. Las bases de datos se identifican mediante un SID y un nombre de

base de datos. Desde la perspectiva de la administración, existe una distinción entre las tareas realizadas a

nivel del sistema y las realizadas a nivel de la base de datos. Los clientes de la base de datos, como la cabina

de mando SAP HANA, se conectan a bases de datos específicas.

Todas las bases de datos de un sistema comparten la misma instalación del software del sistema de base de

datos, los mismos recursos informáticos y la misma administración del sistema. Sin embargo, cada base de

datos es autónoma y está completamente aislada con su propio conjunto de usuarios de base de datos,

catálogo de bases de datos, persistencia, etc.

5.9.2.5 La base de datos del sistema

La base de datos del sistema, que se crea durante la instalación, se usa para la administración central del

sistema, por ejemplo, la creación de bases de datos de tenants y la configuración global del sistema. La base

de datos del sistema almacena la información general del paisaje del sistema, incluido el conocimiento de las

bases de datos de tenants que existen en el sistema. Sin embargo, no posee información de topología

relacionada con la base de datos, es decir, información sobre la ubicación de tablas y particiones de tabla en

bases de datos. La información de topología relacionada con la base de datos se almacena en el catálogo de

base de datos de tenants relevantes.

5.9.2.6 Arquitectura del servidor

A continuación, se muestra un ejemplo de la arquitectura básica de un sistema SAP HANA de un solo servidor

con tres bases de datos de tenants. Para obtener más información sobre la arquitectura del sistema.

210

5.9.2.7 Conexiones desde clientes de bases de datos y clientes web a SAP HANA

Varios tipos de conexiones entre SAP HANA y clientes externos son posibles.

Las conexiones entre SAP HANA y los componentes y aplicaciones externos se pueden clasificar de la

siguiente manera:

• Conexiones utilizadas con fines administrativos

• Conexiones utilizadas para el aprovisionamiento de datos

• Conexiones de clientes de bases de datos que acceden a la interfaz SQL / MDX de la base de datos

de SAP HANA

• Conexiones de clientes HTTP/S

• Conexiones salientes.

Se puede ver un ejemplo de cómo se ven estas conexiones en el siguiente diagrama. Las conexiones de red

se representan con flechas discontinuas. La dirección de cada flecha indica qué componente es el iniciador

(inicio de la flecha) y qué componente es el oyente (punto final de la flecha). El acceso administrativo hacia

211

y desde SAP HANA está representado por las flechas verdes discontinuas. Los números de puerto se muestran

con un fondo negro. El "xx" en los números de puerto representa el número de instancia de SAP HANA.

El diagrama muestra todos los canales de red utilizados por el software SAP HANA. A modo de ilustración, el

diagrama muestra una instalación de un solo host con dos bases de datos de tenants. Sin embargo, las

conexiones mostradas se aplican igualmente a un escenario distribuido.

Las siguientes tablas explican el diagrama y las diferentes categorías descritas anteriormente con más detalle.

Acceso de cliente de base de datos a través de ODBC / JDBC (SQLDBC)

Cliente Información adicional TCP Port

Servidores de aplicaciones que usan SAP HANA como base de datos

Ejemplos: SAP 4/HANA y SAP Business Warehouse uno o más componentes de SAP Business Suite

Debe habilitar el acceso SQL / MDX para todos los clientes de la base de datos.

Los nombres de host externos e internos se asignan a los fines del acceso de cliente de base de datos. Puede cambiar la asignación predeterminada.

Sistema de base de datos del sistema: 3xx13

Base de datos del primer tenant si se crea automáticamente durante la instalación: 3xx15

Bases de datos de tenants: 3xx41-3xx98

Clientes de usuarios finales que acceden a la base de datos de SAP HANA directamente

212

Ejemplo: Microsoft Excel SAP HANA Cockpit y SAP HANA Studio Esta conexión se usa con fines administrativos (por ejemplo, para acceder a datos de usuario, datos de configuración o archivos de rastreo).

Los números de puerto de las bases de datos de tenants se asignan automáticamente a partir del rango de números de puerto disponibles según la disponibilidad en el momento en que se crea la base de datos. Los administradores también pueden especificar explícitamente qué números de puerto usar cuando crean la base de datos del tenant. Para obtener más información, consulte la sección sobre asignación de puertos en bases de datos de los tenants.

Acceso vía HTTP/S

Cliente Información adicional TCP Port

Interfaz de usuario de aplicaciones avanzadas XS (navegador, dispositivo móvil, etc.)

• Acceso desde aplicaciones basadas en SAP HANA Extended Application Services, Advanced Model (SAP HANA XS advanced).

• Acceso desde el cliente de la aplicación al Web Dispatcher gestionado por xscontroller (enrutador de la plataforma) para fines de autenticación de usuarios.

• Acceso al Despachador Web

gestionado por xscontroller para fines de acceso a datos.

Sistema de base de datos del sistema: 3xx33

Servicio de autenticación y cuenta de usuario XS (navegador, dispositivo móvil, etc.)

• Cliente de línea de comando XSA

• Biblioteca de cliente (Java)

• Una o más aplicaciones de modelo avanzado de SAP HANA XS utilizadas,

213

por ejemplo, con fines administrativos o de supervisión

5.10 Servidor de Aplicación

SAP NetWeaver es una plataforma de tecnología integrada para todas las aplicaciones SAP en el plano técnico. Es conocida como una aplicación orientada a servicios y a la integración. Provee al usuario de un vínculo entre lenguajes y aplicaciones. Está construido usando estándares abiertos de la industria por lo que es sencillo negociar transacciones de información con desarrollos de Microsoft .NET, Sun Java EE, e IBM WebSphere.

Fue lanzado como un movimiento estratégico de SAP que plantea a las empresas ejecutar todas sus aplicaciones empresariales en una única plataforma integrada con la más firme infraestuctura. Esta solución incorpora una gran flexibilidad, una mejor integración con las aplicaciones y construcción en estándares para asegurar la futura interoperación.

SAP NetWeaver 7.5 es la versión de seguimiento compatible de SAP NetWeaver 7.4 y la base in situ para SAP Business Suite (a partir del Paquete de mejora 8 para SAP ERP) y para la edición local de SAP S / 4HANA. SAP NetWeaver 7.5 incluye mejoras para la integración con SAP HANA Cloud Platform y amplía la compatibilidad con entornos locales o bajo demanda.

SAP NetWeaver 7.5 admite Java 8 para permitir a los clientes de SAP que ejecutan concentradores basados en Java, como SAP Enterprise Portal, SAP Process Orchestration y SAP Business Process Management, mantener la velocidad de la innovación y beneficiarse de las nuevas funciones de Java.

214

SAP NetWeaver 7.5 contiene innovaciones en ABAP, Java y los entornos en la nube, que junto con las mejoras y optimizaciones en los concentradores SAP NetWeaver, SAP Fiori y la administración del ciclo de vida brindarán ventajas significativas para los clientes de SAP.

SAP NetWeaver 7.5 admite nuevas y evolucionadas tendencias tecnológicas como Internet de las cosas (IoT), móvil, nube, big data y análisis, y responde plenamente a las crecientes necesidades y expectativas de los clientes, siendo la base para el desarrollo fácil y rápido de aplicaciones empresariales simples con experiencia de usuario de clase.

5.11 Lenguaje de programación

ABAP, nombre derivado de las siglas de “Advanced Business Application programming”, es el lenguaje de

programación creado por SAP para poder desarrollar aplicaciones en el sistema SAP.

ABAP es un lenguaje de programación de cuarta generación, es decir, es una herramienta creada por SAP

que permite escribir programas de manera más simple y en menor tiempo que otros lenguajes ya que es en

sí un lenguaje de más alto nivel que se aleja del concepto de procedimiento y hace fácil el acceso a las bases

de datos.

Todo el sistema SAP está programado en ABAP y todos los módulos del ERP hacen uso de este lenguaje.

También se da la posibilidad a los programadores de poder extender o agregar nuevas funcionalidades al

sistema SAP estándar programándolas en ABAP. Esto es muy importante ya que por ejemplo si para un

proceso de una empresa el sistema SAP estándar no abarca todas las características, se pueden agregar

funcionalidades que las incluyan programándolas en ABAP.

A su vez se pueden crear programas en ABAP que funcionen dentro de SAP y que sean para procesos no

tenidos en cuenta dentro del ERP pero que a su vez tomen datos fácilmente de las tablas estándar sin tener

que buscar otras soluciones fuera de SAP.

• Utiliza sentencias de Open SQL para conectarse con prácticamente cualquier base de datos.

• Cuenta con miles de funciones para el manejo de archivos, bases de datos, fechas, etc.

• Permite conexiones RFC (Remote Function Calls) para conectar a los sistemas SAP con cualquier otro

sistema o lenguaje de programación.

5.11.1 ABAP and SAP NetWeaver

En SAP NetWeaver, ABAP es la interfaz de programación de Application Server ABAP (AS ABAP). Requisito

previo para el uso del lenguaje de programación ABAP es la instalación de un Servidor de aplicaciones ABAP.

La mayoría de los componentes de un AS ABAP pueden organizarse de acuerdo con sus tareas en las capas

de una arquitectura cliente-servidor de tres niveles con capas de presentación, aplicación y base de datos.

215

▪ La capa de presentación se distribuye a las estaciones de trabajo de usuarios individuales y

representa la interfaz de usuario de un AS ABAP (SAP GUI o navegador web).

▪ La capa de aplicación se realiza por uno o más servidores de aplicaciones. La capa de aplicación

contiene el entorno de tiempo de ejecución ABAP en el que se ejecutan los programas ABAP.

▪ La capa de la base de datos consiste en un sistema de base de datos en el que se almacena el conjunto

de datos central de un AS ABAP.

Estas tres capas están acompañadas de los siguientes componentes de comunicación:

▪ Internet Communication Manager (ICM).

▪ Internet Communication Manager es un proceso de AS ABAP que permite a AS ABAP comunicarse

directamente con Internet utilizando HTTP / HTTPS / SMTP. ICM se utiliza para conectar

componentes de presentación basados en web, como Web Dynpro ABAP y BSP. ICM también permite

que un AS ABAP se use tanto como cliente como servidor para servicios web. Para acceder a ICM

desde programas ABAP, se utilizan las clases e interfaces de Internet Communication Framework

(ICF).

▪ Interfase RFC. Esta es la interfaz funcional clásica de AS ABAP. Una Llamada de Función Remota es

una llamada de una función en un sistema diferente al que está ejecutando el programa de llamada.

Las llamadas son posibles entre diferentes AS ABAP o entre un AS ABAP y un sistema externo. En AS

ABAP, las funciones se realizan en módulos de función. En sistemas externos, se llaman funciones

especialmente programadas cuya interfaz simula un módulo de funciones.

La función principal de los programas ABAP en la capa de aplicación es el procesamiento y el formateo de los

datos de la capa de la base de datos y su transferencia y recepción de la entrada desde la capa de

presentación o los componentes de comunicación.

5.11.2 Alcance y Áreas de Aplicación de ABAP

216

ABAP es un lenguaje 4GL desarrollado específicamente para el procesamiento masivo de datos en

aplicaciones comerciales. Ofrece las siguientes ventajas en comparación con los lenguajes elementales

donde estas funciones se almacenan en bibliotecas:

▪ Acceso a la base de datos integrado en el lenguaje como Open SQL.

▪ Optimización del rendimiento del acceso a bases de datos integrado en el entorno de tiempo de

ejecución ABAP mediante el uso del almacenamiento en búfer de SAP.

▪ Tablas internas para almacenamiento dinámico y procesamiento de datos de tablas masivas en la

memoria de trabajo.

▪ El concepto de procesamiento de transacciones en línea (OLTP) integrado en el entorno de tiempo

de ejecución ABAP, permitiendo que múltiples usuarios accedan a la base de datos central al mismo

tiempo utilizando SAP LUW.

▪ El lenguaje tiene una interfaz integrada para otros entornos de programación mediante Remote

Function Call.

▪ El lenguaje tiene una interfaz integrada para XML.

La integración de estas funciones en el lenguaje es de particular beneficio para la habilitación de controles

estáticos y el rendimiento de los programas. A cambio, esto significa que ABAP también contiene

considerablemente más elementos de lenguaje que un lenguaje de programación elemental.

5.12 Realizacion de Cambios

El Sistema de cambio y transporte (CTS) es una herramienta que le ayuda a organizar proyectos de desarrollo

en ABAP Workbench y personalización, y luego a transportar los cambios entre los sistemas SAP en el entorno

de su sistema. Además de los objetos ABAP, también puede transportar objetos no ABAP y aplicaciones que

no son de SAP en el entorno de su sistema.

Esta documentación le brinda una descripción general de cómo puede usar CTS para organizar sus cambios,

así como información básica sobre cómo configurar su sistema y el panorama del cliente, y cómo elegir una

estrategia de transporte. Lea y siga esta documentación cuando planifique su proyecto de desarrollo.

El organizador de transporte proporciona funciones para organizar proyectos de desarrollo de software. Está

diseñado para admitir proyectos de todos los tamaños, ya sea que se lleven a cabo de forma centralizada o

en un entorno distribuido.

Esta sección incluye los siguientes temas:

▪ Requisito previo para trabajar con Organizador de Transportes

▪ Edición de objetos en Customizing y Repository

▪ Trabajando con el Organizador de Transporte

▪ Flujo de trabajo de transporte (desarrollo)

Requisito previo para trabajar con Organizador de Transportes

217

Esta sección está destinada al administrador del sistema que configura el Sistema de cambio y transporte

(CTS). Para configurar el CTS, necesita la autorización de administración S_CTS_ADMIN.

Edición de objetos en Customizing y Repository

Transport Organizer registra los cambios realizados en los objetos tanto en Customizing como en Repository.

Trabajando con el Organizador de Transporte

Esta sección proporciona una descripción detallada de los pasos involucrados cuando trabaja en desarrollo y

personalización de proyectos con Organizador de Transporte. Esto incluye lo siguiente:

▪ Grabación de cambios en las solicitudes de cambio.

▪ Trabajando con solicitudes de cambio desde su creación hasta su lanzamiento.

▪ Verificando si los transportes de solicitudes de transporte publicadas fueron exitosos.

Flujo de trabajo de transporte (desarrollo)

El flujo de trabajo de transporte proporciona un marco para transportar mejoras o nuevos desarrollos de

funciones empresariales existentes en un entorno de sistema. Proporciona una conexión directa entre el

desarrollo y la administración del transporte. El flujo de trabajo de transporte gestiona el proceso de

transporte, determina automáticamente el usuario para cada paso individual y luego muestra una interfaz

que pueden usar para realizar la tarea directamente.

Es un método eficiente de transportar un número seleccionado de solicitudes a un grupo de objetivos de

transporte, y utiliza pasos de aprobación claramente definidos para garantizar la calidad de sus sistemas de

destino. Las solicitudes pueden ser solicitudes de cambio transportables, solicitudes de personalización,

transportes de reubicación o transporte de copias. Los objetivos de transporte no necesitan ubicarse en

rutas de transporte definidas.

Es importante que importe las solicitudes en el orden correcto, para que el trabajo de desarrollo esté

actualizado en el sistema de destino.

▪ Workbench: Estás ordenes contienen objetos de repositorio o bien customizing independiente de

mandante. El Workbench (repositorio ABAP) es independiente de mandante, por ese motivo se

asocia este tipo de órdenes a la programación.

▪ Customizing: Contienen objetos dependientes de mandante. El customizing es dependiente de

mandante (no todo, pero la inmensa mayoría, por lo que por ese motivo son asociadas al customizing

en general.

218

5.13 Arquitectura de la solución

5.14 Soporte de la solución

SAP Enterprise Support

SAP Enterprise Support le brinda la asistencia proactiva que necesita para tener éxito. Al abordar los

complejos desafíos comerciales actuales con planes de participación claros que incluyen objetivos

establecidos conjuntamente, SAP Enterprise Support ayuda a asegurar las inversiones existentes, optimizar

las operaciones y aprovechar las últimas innovaciones de SAP. Más que ayudar a resolver problemas,

actuamos como un socio comercial que trabaja de manera proactiva con usted para ayudarlo a alcanzar sus

objetivos comerciales.

5.14.1 Alcance del soporte SAP Enterprise

SAP Enterprise Support actualmente incluye:

219

Mejora continua e innovación

Nuevas versiones de software de Enterprise Support Solutions licenciadas, así como herramientas y

procedimientos para actualizaciones.

Soluciones de Soporte Empresarial significará todo el software licenciado por el Ministerio de Hacienda bajo

el acuerdo de licencia de software de SAP respectivo y cubierto por el acuerdo de SAP Enterprise Support.

Paquetes de soporte: paquetes de corrección para reducir el esfuerzo de implementar correcciones

individuales. Los paquetes de soporte también pueden contener correcciones para adaptar la funcionalidad

existente a los requisitos legales y reglamentarios modificados.

• Actualizaciones de tecnología para soportar sistemas operativos y bases de datos de terceros.

• Código fuente ABAP disponible para aplicaciones de software de SAP y módulos de funciones

adicionales publicados y compatibles.

• La administración de cambios de software, como las configuraciones de configuración modificadas o

las actualizaciones de Enterprise Support Solutions, es compatible, por ejemplo, con contenido,

herramientas y material de información.

SAP proporciona al Ministerio de Hacienda servicios de soporte remoto de hasta cinco días por año

calendario desde arquitectos de soluciones de SAP:

• Ayudar al Ministerio de Hacienda a evaluar las capacidades de innovación del último paquete de mejora

de SAP y cómo se puede implementar para los requisitos del proceso comercial del Cliente.

• Brindar orientación al Ministerio de Hacienda en forma de sesiones de transferencia de conocimiento,

ponderadas un día, para aplicaciones / software SAP definido o componentes Backbone de Soporte

Global. Actualmente, el contenido y los horarios de las sesiones se especifican en Enterprise Support.

La metodología de programación, disponibilidad y entrega está a discreción de SAP.

• SAP le brinda al Ministerio de Hacienda acceso a autoservicios guiados como parte de SAP Solution

Manager Enterprise Edition, lo que ayuda al Cliente a optimizar la administración de soluciones técnicas

de las Soluciones Enterprise Support seleccionadas.

5.14.2 Soporte avanzado para paquetes de mejora y otras actualizaciones de software de SAP SAP ofrece comprobaciones remotas especiales entregadas por expertos en soluciones de SAP para analizar modificaciones planificadas o existentes e identificar posibles conflictos entre el código personalizado del cliente y los paquetes de mejoras y otros Enterprise.

220

Actualizaciones de soluciones de soporte. Cada chequeo se realiza para una modificación específica en uno de los pasos principales del proceso comercial del Ministerio de Hacienda. El Ministerio de Hacienda tiene derecho a recibir dos servicios de una de las siguientes categorías por año calendario según la solución de software de SAP.

• SAP Software Solution se refiere a un grupo de uno o varios sistemas de producción que ejecutan Soluciones para clientes y se centra en un aspecto funcional específico del negocio del Cliente. Los detalles y ejemplos se pueden encontrar en el sitio web de soporte al cliente de SAP (como se especifica en la nota SAP 1324027 o en cualquier nota SAP futura que reemplace la nota SAP 1324027).

• Solución del cliente significará Enterprise Support Solutions y cualquier otro software licenciado por el cliente de terceros.

Justificación de modificación: en función de la provisión del cliente de la documentación necesaria de SAP sobre el alcance y el diseño de una modificación personalizada planificada o existente en SAP Solution Manager Enterprise Edition, SAP identifica la funcionalidad estándar de Enterprise Support Solutions que puede cumplir los requisitos del cliente ( para más información, consulte la hoja de información "Verificación de justificación de modificación" y la documentación de la solución para desarrollo personalizado). Mantenimiento del código personalizado: Basado en la provisión del cliente de documentación requerida por SAP sobre el alcance y diseño de una modificación personalizada planificada o existente en SAP Solution Manager Enterprise Edition, SAP identifica qué salidas de usuario y servicios pueden estar disponibles para separar el código personalizado de SAP código (para obtener detalles, consulte la hoja de información "Comprobación de mantenimiento de código personalizado" y la documentación de la solución para desarrollo personalizado).

5.14.3 Acuerdo global de nivel de manejo y servicio de incidentes (SLA) Cuando el Ministerio de Hacienda informa mal funcionamiento, SAP apoya al Ministerio de Hacienda brindándole información sobre cómo remediarlo, evitar o eludir errores. El canal principal para dicho soporte será la infraestructura de soporte provista por SAP. El Ministerio de Hacienda puede enviar un incidente en cualquier momento. Todas las personas involucradas en el proceso de resolución de incidentes pueden acceder el estado del incidente en cualquier momento. Para obtener más detalles sobre la definición de prioridades de incidente, consulte la Nota de SAP 67739. En casos excepcionales, el Ministerio de Hacienda también puede ponerse en contacto con SAP por teléfono. Los detalles de contacto se proporcionan en SAP Note 560499. Para dicho contacto (y según se indique de otro modo) SAP requiere que el Ministerio de Hacienda proporcione acceso remoto como especificado en el acuerdo de SAP Enterprise Support correspondiente.

221

Los siguientes acuerdos de nivel de servicio ("SLA" o "SLA") se aplicarán a todos los incidentes del cliente que SAP acepta como Prioridad 1 o 2 y cumple con los requisitos previos especificados aquí. Dichos SLA comenzarán en el primer trimestre natural completo después de la fecha de vigencia del acuerdo de SAP Enterprise Support.

5.14.3.1 Acuerdo de nivel de servicio (SLA´s) para tiempos de respuesta iniciales Incidentes de prioridad 1 ("Muy alto") SAP responderá a los incidentes de Prioridad 1 dentro de una (1) hora de la recepción de SAP (veinticuatro horas por día, siete días a la semana) de dichos incidentes de Prioridad 1. Se asigna un incidente Prioridad 1 si el problema es muy serio las consecuencias para las transacciones comerciales normales y el trabajo urgente y crítico para la empresa no se pueden realizar. Esto es generalmente causado por las siguientes circunstancias:

• Interrupción completa del sistema

• Mal funcionamiento de SAP central funciones en el sistema de producción, o Top-Issues,

• Cada circunstancia, una solución alternativa no está disponible. Incidentes de Prioridad 2 ("Alto") SAP responderá a los incidentes de Prioridad 2 dentro de las cuatro (4) horas posteriores a la recepción de SAP durante el horario de la oficina local de SAP.tales incidentes de Prioridad 2. Se asigna un incidente Prioridad 2 si las transacciones comerciales normales en una producción sistema se ven seriamente afectados y las tareas necesarias no se pueden realizar. Esto es causado por incorrecta o funciones inoperables en el sistema SAP que se requieren para realizar tales transacciones y / o tareas.

5.14.3.2 Acuerdo de nivel de servicio para el tiempo de respuesta de la acción correctiva para los

incidentes de prioridad 1 SAP proporcionará una solución, solución o plan de acción para la resolución ("Acción correctiva") de la Prioridad del Ministerio de Hacienda

• 1 incidente dentro de las cuatro (4) horas posteriores a la recepción de SAP (veinticuatro horas al día, siete días a la semana) de dicha Prioridad

• 1 incidente ("SLA para acción correctiva"). En caso de que se presente un plan de acción al Cliente como una Acción correctiva, dicho plan de acción deberá incluir: o Estado del proceso de resolución; o Próximos pasos planificados, incluida la identificación de los recursos de SAP responsables; o acciones requeridas del cliente para apoyar el proceso de resolución; o En la medida de lo posible, fechas planificadas para las acciones de SAP; y o Fecha y hora para la próxima actualización de estado de SAP.

222

Las actualizaciones de estado posteriores incluirán un resumen de las acciones emprendidas hasta el momento; los próximos pasos planificados; y fecha y hora para la próxima actualización de estado El SLA para acción correctiva solo se refiere a la parte del tiempo de procesamiento cuando se procesa el incidente en SAP ("Tiempo de procesamiento"). El tiempo de procesamiento no incluye el momento en que el incidente está en estado "Cliente Acción "o" Solución propuesta SAP ", mientras que:

• El estado Acción del Cliente significa que el incidente fue entregado al Cliente; y

• El estado de la Solución propuesta de SAP significa que SAP ha proporcionado una Acción correctiva como se describe aquí.

El SLA para la Acción Correctiva se considerará cumplido si dentro de las cuatro (4) horas posteriores al procesamiento: SAP propone un solución, una solución o un plan de acción; o si el Ministerio de Hacienda acepta reducir el nivel de prioridad del incidente.

5.14.3.3 Cadena de Valor GBM a traves de su servicio de Enterprise Support

GBM cuenta con una unidad de soporte y conocimiento SAP. A través de nuestros servicios de atención

inteligente, se pueden canalizar los requerimientos de soporte y controlar la prestación del servicio para

conocer así la cantidad de solicitudes realizadas mensualmente, tiempo de atención de cada

requerimiento, promedio mensual del tiempo de atención y tipo de requerimiento.

SAP Enterprise Support – VAR es el proceso proactivo diseñado para ayudarle a sacar el máximo provecho

de la integración entre las Soluciones de SAP, minimizando riesgos, acelerando la innovación, que conducen

a una mejor gestión de sus requerimientos.

223

SAP Enterprise Support – VAR ayudará a identificar los riesgos antes de que se conviertan en problemas,

proporcionando 24x7x365 apoyo de expertos, y la obediencia a acuerdos de servicio claros, aumentando

significativamente la disponibilidad de aplicaciones que soportan los procesos de negocio.

• Implementar Mejor: conducción implementaciones eficientes que satisfagan sus necesidades de

negocio.

• Opere mejor: Proteger su negocio para lograr la excelencia operativa.

• Innovar Mejor: Promover el crecimiento de su negocio, con la constante evolución de su negocio y

los procesos de TI.

Algunos de nuestros principales entregables:

• Informe de la salud del del sistema: Early Watch Alert (al menos 4 revisiones con el MHRD por año)

• El informe del EWA alerta roja y la mitigación en colaboración con el MHRD.

• Servicios más remotos para la integridad y mejora del sistema en colaboración con SAP:

✓ SAP Early Watch Alert ✓ SAP Business Process Performance Optimization ✓ SAP Data Volume Management ✓ SAP Technical Performance Optimization ✓ SAP Upgrade Assessment

5.14.3.4 Early Watch Alert

El Early Watch Alert (EWA) es la herramienta de SAP que permite al Ministerio de Hacienda de la Republica

Dominicana mantenerse al tanto del estado de sus sistemas y tomar decisiones ante los problemas críticos

que se detecten, garantizando así el buen funcionamiento de sus sistemas SAP.

Tambien es capaz de dar prestación de servicios de soporte de SAP como SAP Early Check Watch, la optimización de instrucciones SQL y evaluación de la gestión de soluciones. Se trata de una funcionalidad estratégica que lleva a la reducción del coste total de propiedad y mejor rendimiento del sistema.

5.14.3.4.1 Objetivos de EWA

▪ Prevención de los cuellos de botella. ▪ Facilitar la temprana identificación de problemas potenciales. ▪ Generación de informes periódicos. ▪ Provisión de un seguimiento regular y automático de los resultados de los componentes de

SAP. ▪ Prestación de un seguimiento regular y automático de los componentes críticos de

administración del sistema SAP.

224

5.14.3.4.2 Monitorización de EWA

▪ Estado de los componentes generales ▪ La configuración del sistema ▪ Recursos de hardware ▪ Gestion de base de datos ▪ Mensajes de errores críticos ▪ Mejora del rendimiento ▪ Promedios del tiempo de respuesta ▪ Carga de trabajo actual

5.14.3.5 CQC - SAP Business Process Performance Optimization

Con esta herramienta se busca la optimización del rendimiento de los procesos de negocio dentro de los

controles de calidad continua. Eso Analiza los pasos críticos del proceso y recomienda cómo optimizarlos

técnicamente.

El servicio de análisis de calidad continua de SAP Business Process Performance Optimization analiza y optimiza el rendimiento de los procesos de negocio. SAP Business Process Performance Optimization es aplicable en la fase de operación de una solución, y también en la fase de prueba de un proyecto de implementación.

Con el servicio SAP Business Process Performance Optimization, utiliza la experiencia de SAP para ahorrar tiempo, reducir costos y mantener la solución SAP funcionando de manera óptima.

El servicio SAP Business Process Performance Optimization ofrece las siguientes ventajas para la institución:

• Tiempo de respuesta y rendimiento optimizados: SAP Business Process Performance Optimization acelera los pasos del proceso empresarial.

• Productividad incrementada: SAP Business Process Performance Optimization aumenta el rendimiento de pasos de proceso ineficientes y Aprovecha la productividad de sus usuarios.

• Uso óptimo de los recursos de hardware: Las transacciones de rendimiento óptimo generan menos carga en el sistema. Los recursos de hardware existentes son capaces para procesar volúmenes de datos más altos. Las inversiones previstas podrían ser postergadas.

• Aumento de la satisfacción del usuario final: SAP Business Process Performance Optimization aumenta la satisfacción del usuario final, ya que su personal gasta menos tiempo en las actividades sin valor añadido.

225

5.14.3.6 Flujograma de proceso

5.14.3.6.1 Flujograma de proceso – 1 er Nivel – Coordinador Ministerio de Hacienda

226

5.14.3.6.2 Flujograma de proceso – 1 er Nivel – GBM Enterprise Support

227

5.14.3.6.3 Flujograma de proceso – 2 do Nivel

228

5.14.3.6.4 Flujograma de proceso – 3 er Nivel - SAP

229

5.14.3.6.5 Flujograma de proceso – “Very High” - SAP

5.14.3.7 Servicios de Solución de Misión Critica

GBM procede a describir el flujo detallado para el tratamiento de los puntos: Que se considera como punto asunto crítico:

▪ Caída de producción, parálisis del entorno productivo

▪ Procesos de bloqueo a procesos que afectan financieramente a la compañia

▪ Show stoppers para salidas en vivo

5.14.3.8 Prestación del Servicio

▪ Personal exclusivo, dedicado y experimentado

▪ Asistencia directa de expertos en cada proceso

230

▪ Teléfonos:

• Costa Rica (506) 2284-3999

• Guatemala (502) 2424-2222

• El Salvador (503) 2505-9600

• Honduras - Tegucigalpa (504) 2232-2319/09

• Honduras - San Pedro Sula (504) 2556-5531 / 2556-5532, 34, 35

• Miami, FL (USA) (1) 305 597-3998

• Nicaragua (505) 2255-6630

• Panamá (507) 300-4800

• República Dominicana (809) 566-5161

• Venezuela Teléfono: (212) 750-5700

Para todos los numeros previos al extension Nro. 1782 cae al Customer Interaction Center de Soporte GBM.

• Gerente de Soporte Wendy Villalba [email protected]

5.14.3.9 Requisitos

• Proporcionar conectividad remota (SAP Router)

• SAP Solution Manager 7.1 en las ultimas versiones de patches, support package stack y

patch levels del aplicativo

• Habilitar EWA para los sistemas productivos y la respectiva transmisión de datos a SAP.

SAP Note 207223

• Establecer conectividad entre SAP Solution Manager del cliente, socio y SAP

• Habilitar las mejoras a través del SAP Solution Manager Enterprise Edition 7.1

• Revelar inmediatamente a SAP sobre modificaciones, manteniendo registros adecuados y

actuales, para proporcionar servicios de apoyo y proporcionar dichos registros a SAP de

ser necesario.

231

• Para servicios de procesos de misión crítica, proporcionar detalle descrito en inglés o

portugués, y un canal de conexión remota para acceder a SAP cuando sea necesario.

5.14.3.10 Portal de Soporte

GBM ofrece el siguiente Portal de Soporte http://solmanitilgbm.gbm.net para colocar a cabo las

actualizaciones, documentaciones y casos del Enterprise Support

http://solmanitilgbm.gbm.net/

232

5.14.3.11 Equipo contacto Enterprise Supporte GBM

5.15 Formatos de licencias requeridas y capacidad de operación en premisas y en la nube.

Nombre

Consultor

Numero Telefono Titulo Academico Ciudad - Pais

Wendy

Villalba

SAP_Enterprise_Sup

[email protected]

Soporte Online

http://gcgsapes.gb

mcloud.com:8101/s

upport

+504-(504) 2556-

5531

Soporte GBM Ext:

3911

Grado de Administración en

Informatica con amplia experiencia

en la implementación de sistemas

de información, reingeniería de

procesos y configuración de SAP.

Experimentado en la interacción con

equipos funcionales y técnicos para

diseñar e implementar soluciones

que logren los objetivos

corporativos y aseguren la máxima

satisfacción del cliente.

Experimentado en la interacción con

equipos funcionales y técnicos para

diseñar e implementar soluciones

que logren los objetivos

corporativos y aseguren la máxima

satisfacción del cliente

Consultor SAP Logistics Materials

Management: 2 proyectos de ciclo

de vida completo

Consultor de ventas y distribución

de SAP: 2 proyectos completos de

ciclo de vida

Soporte y mejora de SAP: más de 80

clientes

SAP: SD, MM, CRM and integration

with other modules | ASAP -

ACTIVATE

Miami, USA

233

El licenciamiento ofrecido considera la posibilidad de implemenarlo en premisas o en la nube privada del

proveedor que ofrezca hospedaje.

5.16 Parametrizacion Flexible Se entiende por parametrización a todas aquellas actividades que se efectúan en SAP, tendientes a su configuración específica y con el objetivo de adaptar su funcionamiento a las peculiaridades de los procesos de negocios de cada institución. SAP considera una parametrización flexible en todos los niveles de la arquitectura. SAP a través de la trasnaccion SPRO (SAP Project Reference Object) o (Objetos de Referencia del Proyecto SAP.) Cuando hablamos de parametrización o Customizing o también configuración nos estamos refiriendo a configurar el sistema SAP de acuerdo a las necesidades del Ministerio de Hacienda de la Republica Dominicana. La parametrización del sistema SAP se realiza durante el proyecto de implantación del sistema SAP. Esta tarea es realizada por los Consultores Funcionales y Tecnicos. Cuando ejecutamos la transacción estándar SPRO vamos a visualizar el IMG, que es la Guia de Implementación del sistema. Esta es la herramienta que adapta el sistema SAP a las necesidades de la empresa. A continuación una muestra de los diferenciadores y las consideraciones de SAP para las parametrizaciones. Acceso de un Usuario Funcional: Los usuarios del caso Ministerio de Hacienda, de las funcionalidades consiederadas en el presente alcance, tales como: Bienes de Uso, Bienes de Consumo, Cuentas por Pagar, Cuentas por Cobrar, tendrán acceso a un menú FIORI.

234

Menu para llevar las parametrizaciones:

235

5.16.1 Autorización para realizar proyectos de personalización El objeto de autorización S_PROJECT le permite procesar proyectos personalizados, p. cambiar, mostrar o eliminar proyectos, mantener la información de estado y la documentación del proyecto y analizar proyectos. El objeto de autorización S_PROJECTS le permite realizar actividades en la administración de proyectos de Customizing con efecto de proyecto cruzado, por ejemplo, crear y cambiar plantillas de proyectos y crear proyectos. Puede asignar autorizaciones para las actividades de IMG de cada proyecto de Customizing, o cada vista de proyecto. Se debe crear un rol para cada proyecto de personalización (vista) y asigne el proyecto o vista de personalización a este rol. Las autorizaciones para realizar todas las actividades en el proyecto o vista de personalización se generan en la generación de perfil. Se puede restringir el acceso de un usuario a las filas de una tabla por unidades organizativas empresariales. Un uso posible sería que un usuario solo puede mostrar y cambiar los contenidos de un área de trabajo particular, por ejemplo, un país o planta, en una tabla de parametrización.

236

5.16.2 Guía de Parametrización (IMG) La Guía de implementación (IMG) es la herramienta que ajusta el sistema SAP a los requisitos de una institución. Utiliza la guía de implementación para estructurar y organizar la implementación del Sistema SAP en una o varias instituciones. La guía de implementación es una estructura jerárquica de las áreas de aplicación en la jerarquía de componentes. Contiene todos los pasos de trabajo requeridos para la implementación con documentación. Hay tres variantes de guía de implementación:

• SAP IMG de referencia

• Project IMGs

• Vista del proyecto IMG El SAP Reference IMG: SAP ofrece una Guía de implementación, la SAP Reference IMG, que contiene los pasos de trabajo para todas las aplicaciones como actividades de IMG en el sistema SAP. Proyecto IMG: Para reducir la complejidad del proceso de configuración en SAP Reference IMG, generalmente crea proyectos de implementación separados. En los proyectos de implementación, usted elige solo aquellas funciones que necesita para los procesos en su proyecto. Generas IMG de proyectos por separado para cada proyecto de implementación y para las actualizaciones de la versión. Vista del proyecto IMGs: Puede generar vistas para estructurar las actividades de su proyecto seleccionando atributos según criterios específicos. Por ejemplo, la vista de actividades obligatorias contiene solo aquellas actividades que se requieren. La guía de parametrización se usa para:

• Configurar las funciones de SAP en su empresa de una manera rápida, segura y rentable.

• Adaptar las funciones estándar para cumplir con los requisitos de su empresa.

• Administrar, editar y analizar proyectos de implementación o actualización.

• Documentar y monitorear las fases de implementación con una herramienta de gestión de proyectos.

237

Un equipo del proyecto de implementación es guiado a través de todas las configuraciones de personalización requeridas y recibe la documentación de configuración del sistema necesaria para todos los pasos requeridos.

5.16.3 SAP Parametrizacion

Los clientes en SAP son parte de la estructura técnica definitoria del Sistema SAP. Cada cliente contiene sus propios registros maestros y un conjunto de tablas. La parametrizacion es específica del cliente, dependiendo de qué datos de negocio están configurados. La parametrizacion entre clientes es válido para todos los clientes en un Sistema SAP. Cuando instala el sistema SAP, los siguientes clientes están disponibles:

• Cliente 000 como cliente de referencia de SAP

• Cliente 001 como cliente de preparación de producción

• Cliente de referencia de SAP (000)

• Cliente de referencia de SAP (000) Todas las tablas de SAP están en el cliente de referencia de SAP. Las entradas de muestra, que puede cambiar, existen para las tablas en las que almacena su estructura organizativa. El código de empresa 0001 en el cliente 000 contiene la parametrizacion completa. La parametrización específico del país (requisitos legales y comerciales) de todos los países estándar se entrega en plantillas de código de empresa XX01 (XX = indicador de país). SAP actualiza la configuración en cada nueva versión. Como resultado, el cliente 000 siempre tiene el estado actual. Para una actualización de lanzamiento, SAP actualiza automáticamente:

• Contenidos de tabla y estructuras de tabla

• Programas

• Pantallas

• Formularios

• Ayuda en línea

238

Los cambios en los campos o tablas que pueda requerir el Ministerio de Hacienda pueden ejecutarse a través de las tareas de customizing (parametrizaciones) o a través del uso del lenguaje técnico ABAP ya descrito, el caso del uso ABAP es cuando el cambio requerido no es contenido en el estándar de SAP. Un ejemplo de ello son los campos y requerimientos que pueda tener el formulario 606, 607 y 608 muy propio de Republica Dominicana.

5.17 Multiples ambientes

5.17.1 Ambientes

5.17.1.1 Landscape del sistema

El denonimado landscape del sistema contiene todos los sistemas SAP que ha instalado. Puede consistir en

varios grupos de sistemas, cuyos sistemas SAP están vinculados por rutas de transporte.

Después de decidir qué ambientes se necesita, se debe decidir cómo distribuirlos entre los diferentes

sistemas SAP. Puede configurar múltiples clientes independientemente el uno del otro en un único sistema

SAP. Sin embargo, cuando configura los datos, debe recordar que las configuraciones de personalización

entre clientes y los objetos de repositorio son idénticas para todos los clientes en un único sistema SAP. Los

cambios realizados en un cliente se aplican inmediatamente a todos los clientes del sistema.

5.17.1.2 Landscape de tres ambientes

Recomendamos un panorama de tres ambientes en el que cada uno de los clientes centrales tenga su

propio sistema SAP.

Esto consiste en un ambiente de Desarrollo (DEV), un sistema de garantía de Calidad (QAS) y un sistema de

producción (PRD). El sistema de desarrollo contiene el cliente de personalización CUST, el sistema de garantía

de calidad contiene el cliente de garantía de calidad QTST y el sistema de producción contiene el cliente de

producción (PROD).

• Todos los cambios de parametrización (personalización) de datos y objetos de repositorio en el

ambiente de Customizing (Personalización) ubicado en el ambiente (DEV).

• Cuando libera las solicitudes de cambio correspondientes, se transportan al cliente de control de

calidad (QAS). Esto significa que los cambios en los datos de clientes relacionados solo aparecen en

el cliente de control de calidad después del transporte.

239

• En el cliente de control de calidad (QAS), puede probar si los transportes están completos, o si falta

algún cambio vinculado y todavía están en solicitudes de cambio no publicadas. Si la prueba es

exitosa, las solicitudes de cambio se transportan al ambiente de producción (PRD). El ambiente de

producción está completamente separado de los demás clientes en lo que respecta a los datos de

clientes relacionados.

Si necesita otros clientes con funciones adicionales, puede configurarlos en uno de los tres sistemas.

Configure el cliente de prueba de desarrollo (TEST) y el prototipo de cliente (SAND) en el sistema de

desarrollo. Configure el cliente de capacitación (TRNG) en el sistema de garantía de calidad.

5.17.1.3 Alta disponibilidad para SAP HANA

La alta disponibilidad es el nombre dado a un conjunto de técnicas, prácticas de ingeniería y principios de diseño que respaldan el objetivo de la continuidad del negocio y también aseguran que los datos y servicios estén disponibles para los usuarios autorizados cuando sea necesario. SAP HANA está completamente diseñado para alta disponibilidad. Admite medidas de recuperación que van desde fallas y errores de software hasta desastres que desmantelan un centro de datos completo. Se logra una alta disponibilidad al eliminar los puntos únicos de falla (tolerancia a fallas) y al proporcionar la capacidad

240

de reanudar rápidamente las operaciones después de una interrupción del sistema con una pérdida comercial mínima (capacidad de recuperación de fallas). La recuperación de fallas es el proceso de recuperación y reanudación de operaciones después de una interrupción debido a una falla. La recuperación de desastres es el proceso de recuperación de operaciones después de una interrupción debido a un centro de datos prolongado o una falla del sitio. Prepararse para un desastre puede requerir una copia de seguridad de los datos a distancias más largas y, por lo tanto, puede ser más complejo y costoso. La clave para lograr una alta disponibilidad es la redundancia, incluida la redundancia del hardware, la redundancia de la red y la redundancia del centro de datos. SAP HANA proporciona varios niveles de defensa contra interrupciones relacionadas con fallas:

• Redundancia de hardware: Los proveedores de dispositivos SAP HANA ofrecen múltiples capas de hardware redundante, software y componentes de red, como fuentes de alimentación y ventiladores redundantes, memorias correctoras de errores de nivel empresarial, conmutadores y enrutadores de red totalmente redundantes y fuente de alimentación ininterrumpida (UPS). Los sistemas de almacenamiento en disco usan baterías para garantizar la escritura, incluso en presencia de fallas de energía, y utilizan la creación de bandas y la duplicación para proporcionar redundancia para la recuperación automática de las fallas del disco. En general, todas estas soluciones de redundancia son transparentes para el funcionamiento de SAP HANA, pero forman parte de la defensa contra la interrupción del sistema debido a fallas de un solo componente.

• Software: SAP HANA se basa en SUSE Linux Enterprise 11 para SAP e incluye preconfiguraciones de seguridad (por ejemplo, servicios mínimos de red). Además, el software del sistema SAP HANA también incluye una función de vigilancia, que reinicia automáticamente los servicios configurados (servidor de índices, servidor de nombres, etc.), en caso de interrupción detectada (cancelada o bloqueada).

• Persistencia: SAP HANA conserva registros de transacciones, puntos de guardado e instantáneas para permitir el reinicio y la recuperación del sistema de las fallas del host, con un mínimo retraso y sin pérdida de datos.

• Modo de espera y conmutación por error: los hosts de reserva dedicados y separados se utilizan para conmutación por error, en caso de falla de los hosts activos primarios. Esto mejora la disponibilidad al reducir significativamente el tiempo de recuperación de una interrupción.

241

5.17.2 Sincronización

Transporte de Capas y Rutas de Transporte

Todos los proyectos de desarrollo desarrollados en el mismo Sistema SAP y transportados en las mismas

rutas de transporte se agrupan para formar una capa de transporte.

Antes de comenzar el primer proyecto de desarrollo, crea una capa de transporte en el editor de rutas de

transporte de TMS. Esta capa de transporte se asigna al sistema de desarrollo como su capa de transporte

estándar. Los objetos entregados por SAP pertenecen a la capa de transporte "SAP".

En general, solo se necesitan otras capas de transporte cuando se incluyen nuevos sistemas de desarrollo

en el grupo del sistema.

Después de configurar la capa de transporte, configura las rutas de transporte. Hay dos tipos de rutas de

transporte. Primero configura las rutas de consolidación y luego configura las rutas de entrega:

Rutas de consolidación

Para que sus cambios sean transportables, se configura una ruta de consolidación para cada capa de

transporte. Especifique su sistema de desarrollo como el punto de partida (origen) de estas rutas de

consolidación. Especifique el sistema de garantía de calidad como objetivo de transporte (en un entorno de

dos sistemas, especifique el sistema de producción como objetivo de transporte).

242

Cualquier objeto modificado que tenga una ruta de consolidación configurada para su capa de transporte

se incluye en las solicitudes de cambio transportables. Una vez que se ha liberado la solicitud, los objetos se

pueden importar al sistema de consolidación.

Si realiza cambios en los objetos que no tienen una ruta de consolidación definida para su capa de

transporte, los cambios se realizan automáticamente en las solicitudes de cambio locales (o en las

solicitudes de personalización sin un destino de transporte). No puede transportarlos a otros Sistemas SAP.

Puede configurar una ruta de consolidación solo para cada sistema SAP y capa de transporte.

Rutas de entrega Después de haber importado su trabajo de desarrollo en el sistema de garantía de calidad, entonces desea transportarlo a su sistema de producción. Incluso puede querer transportarlo a varios Sistemas SAP (por ejemplo, sistemas de capacitación adicionales). Para hacer esto, debe configurar las rutas de entrega. Las rutas de entrega tienen un sistema de origen y un sistema de destino. Cuando se configura una ruta de entrega, se asegura de que todas las solicitudes de cambio que se importan al sistema de origen de la ruta se marquen automáticamente para importarlas al sistema de destino de la ruta. Se puede configurar varias rutas de entrega con el mismo sistema de origen y diferentes sistemas de destino (reenvío paralelo). También puede configurar las rutas de entrega en secuencia (reenvío multinivel). El control de transporte de CTS se asegura de que todas las solicitudes del sistema de desarrollo se marquen para su importación a todos los demás sistemas SAP en el mismo orden en el que se exportaron. Esto es importante, ya que las diferentes solicitudes pueden contener el mismo objeto Repositorio o la misma configuración de Personalización en diferentes niveles de desarrollo, y debe evitar sobrescribir una versión más reciente con una versión anterior.

243

5.18 Software

5.18.1 Bitacoras de Auditoria

SAP S/4HANA a través de la herramienta Audit Information System incluye una serie de reportes de

auditoria completamente configurable.

5.18.1.1 Audit Information System

La auditoría de información rmación sistema (AIS) es una auditoría herramienta que se puede utilizar para

analizar los aspectos de seguridad de SAP NetWeaver Application Server (SAP NetWeaver AS) para ABAP.

AIS presenta su información confirmación de la auditoría de información estructura mación (similar a la guía

de implementación) de manera que se puede determinar fácilmente qué actividades es necesario realizar y

que se ha logrado.

Funciones Principales

• Procedimientos de auditoría y documentación

• Evaluaciones de auditoria

• Descargas de datos de auditoría

AIS está diseñado para negocios de auditoría s y sistema s de auditorías. La auditoría de información

estructura mación está diseñado con este tipo de auditoría s en mente y que entregan vistas predefinidas en

base a estos auditoría tipos ing. Puede modificar estas vistas o desarrollar las suyas propias.

5.18.1.2 Auditoría del servidor de aplicaciones SAP NetWeaver para ABAP

Para prepararse y realizar una auditoría de SAP NetWeaver Application Server ( SAP NetWeaver AS) ABAP,

los auditores y administradores utilizan el Sistema de información de auditoría (Workplace) del sistema de

trabajo (transacción SAIS ) y sus transacciones relacionadas.

SAP NetWeaver AS para ABAP ofrece una función de auditoría básica con el Sistema de información de

auditoría.

244

¿Qué es una estructura de auditoría?

Una estructura de auditoría es una colección de transacciones y documentos que un auditor requiere para

realizar una auditoría. La estructura de auditoría es técnicamente un menú de área de SAP NetWeaver

Application Server ( SAP NetWeaver AS) ABAP.

Un desarrollador de un sistema puede crear una estructura de auditoría para el auditor. Las empresas de

auditoría externa o los socios de SAP pueden proporcionar sus propias estructuras de auditoría para importar

a su sistema. SAP también proporciona un conjunto de estructuras de auditoría para su uso.

La trasanccion en SAP es la SE43 para ver, modificar, extender y transportar estos objetos del banco de

trabajo.

5.18.1.3 Realizando auditorías

En encargado de las auditorias, como auditor, usa una estructura de auditoría para auditar un sistema

ABAP de SAP NetWeaver Application Server ( SAP NetWeaver AS).

Requisitos previos

Ha iniciado sesión con un usuario al que se le ha asignado un rol con las autorizaciones requeridas para el

menú de auditoría, incluido el número de cheque.

Procedimiento

• Se debe iniciar el Sistema de información de auditoría (transacción SAIS ).

• Se ingresa una estructura

• Se ingresa un número de chequeo.

• Si el número de chequeo no existe en el sistema cuando ejecuta la transacción, la aplicación le

solicita que confirme la creación de una nueva auditoría para esta estructura.

• Se elige Ejecutar objeto (Ejecutar).

• Se abre el cockpit de auditoría para su estructura de auditoría.

• Se debe realizar los pasos de auditoría como se describe en la estructura de auditoría.

245

• Los documentos en la estructura de auditoría explican los antecedentes que necesita para realizar

sus comprobaciones. Las transacciones en la estructura le dan acceso a las aplicaciones que

necesita para realizar sus comprobaciones.

• Se ingresa y guarda las entradas de protocolo.

5.18.1.4 Visualización de resultados de auditoría

En SAP se muestran los resultados de la auditoría para verificar el estado de las auditorías actuales en el sistema o para prepararse para publicar sus hallazgos y archivarlos. Requisitos previos Al usuario se le han asignado las autorizaciones necesarias para mostrar los resultados de la auditoría que desea mostrar. Procedimiento

• Se inicia el sistema de información de auditoría: análisis de registro (transacción SAIS_LOG ).

• Se ingresa los datos de selección para encontrar resultados de auditoría.

• Se determina si solo desea mostrar los resultados anteriores junto con los resultados finales.

• Por defecto, la transacción muestra solo los resultados finales de cada chequeo. Para mostrar también los resultados intermedios, se desactiva la casilla Determinar solo el estado del último chequeo en cada caso . Para los hallazgos finales, deje esta opción seleccionada.

5.19 Herramienta de desarrollo y/o configuración

SAP Best Practices a través de la herramienta Rapid Deployment Solutions estandariza el proyecto de

implementación y entre en funcionamiento a tiempo y dentro del presupuesto con SAP Best Practices

(también conocido como SAP Rapid Deployment Solutions, SAP RDS). Estos paquetes de soluciones de

software cubren todo el portafolio de SAP y ofrecen las mejores prácticas para una amplia gama de procesos

y temas. No importa cuál sea el tamaño de su institución, SAP Best Practices puede ayudar a lograr un tiempo

récord en cuanto a valor en el lugar, en la nube o en un entorno híbrido.

SAP Rapid Deployment Solutions (RDS) son aplicaciones preconfiguradas que permiten a las intituciones implementar software en semanas o meses. Las aplicaciones están diseñadas para abordar un área de funcionalidad de las aplicaciones empresariales más grandes de SAP y abordar una función o necesidad específica.

246

Los mecanismos de cambios en la configuración están detallados en el numeral 5.15 Parametrización Flexible.

5.20 Integracion de aplicaciones SAP NetWeaver Process Integration (SAP PI) es una de aplicacion empresariales (EAI) de software, un componente de la NetWeaver grupo de productos utilizados para facilitar el intercambio de información entre programas y sistemas internos de la institución y los de las partes externas. Antes de la versión actual, SAP PI se llamaba SAP Exchange Infrastructure (SAP XI) . Al igual que otros componentes de NetWeaver, SAP PI es compatible con productos de software de otras compañías. SAP llama a PI un intermediario de integración porque media entre entidades con requisitos variables en términos de conectividad, formato y protocolos. Según SAP, PI reduce el TCO al proporcionar un repositorio común para las interfaces. El componente central de SAP PI es SAP Integration Server , que facilita la interacción entre diversos sistemas operativos y aplicaciones en sistemas informáticos en red internos y externos. PI se basa en SAP Web Application Server . ¿Por qué necesitamos SAP PI? Aparte de Legacy Systems, en un gran establecimiento comercial, SAP no consiste en un solo sistema sino en varios sistemas integrados, es decir, CRM, SRM y FINANZAS-PRESUPUESTO, etc. Para manejar estas complejidades, SAP introdujo una plataforma de integración de procesos. Proporcionar un único punto de integración para todos los sistemas sin tocar la compleja red existente de sistemas heredados. Se trata de un middleware potente de SAP para proporcionar una integración perfecta de extremo a extremo entre aplicaciones SAP y no SAP dentro y fuera de los límites corporativos. SAP PI admite intercambios B2B y A2A, admite el intercambio de mensajes síncrono y asíncrono e incluye un motor integrado para diseñar y ejecutar procesos de integración.

247

El PI de SAP consta de una estructura de centro y enlace; los enalces se conectan con sistemas externos mientras que el centro intercambia mensajes entre ellos. El sistema fuente se conoce como el sistema emisor y el sistema objetivo se conoce como el sistema receptor. El PI no es un componente único, sino más bien una colección de componentes que funcionan juntos de forma flexible para implementar escenarios de integración. La arquitectura incluye componentes que se utilizarán en el momento del diseño, en el momento de la configuración y en el tiempo de ejecución. Podemos dividir el SAP PI en varias áreas:

• Servidor de integración

• Creador de Integración

• Paisaje del sistema

• Configuración y Monitoreo

Integration Server es el motor de procesamiento central de SAP PI. Todos los mensajes se procesan aquí de forma consistente. Consiste en tres motores separados

• Motor de integración

• Motor de adaptador

• Business Process Engine

Se puede considerar que el motor de integración es el concentrador y el motor. Integration Builder es un marco cliente-servidor para acceder y editar objetos de integración y consta de dos herramientas relacionadas:

• Enterprise Service Repository: para diseñar y desarrollar objetos para ser utilizados en escenarios

• Directorio de integración: para configurar los objetos de ESR para desarrollar escenarios Dos juntos, se crean procesos de integración que comúnmente se denominan escenarios. El System Landscape es un repositorio central de información sobre software y sistemas en el centro de datos y simplifica la administración del paisaje de su sistema. En Configuración y Monitoreo, podemos monitorear los mensajes y adaptadores.

5.20.1 Single stack and Dual stack Cuando PI se lanzó por primera vez, no todos los componentes se construyeron en la misma plataforma. Integration Engine y Business Process Engine se construyeron en ABAP, mientras que Adapter Engine, Integration Builder, SL, CM y Mapping Runtime se construyeron en Java. Por lo tanto, PI necesita el entorno Java y ABAP para ejecutarse y se conoce como Dual Stack.

248

Pero en la versión posterior, todos los componentes están construidos en Java. Algunos de los componentes de Dual stack se dispensan o modifican para funcionar en la pila de Java. Por lo tanto, PI necesita solo el entorno Java para ejecutarse y se conoce como Single stack.

Integration Engine: Es responsable de los servicios centrales de Integration Server, es decir, los pasos de la tubería: enrutamiento y mapeo. Si la estructura del mensaje de origen es diferente de la estructura de mensaje de destino, el motor de integración llama a Mapping Runtime, donde la estructura de origen se convierte a la estructura de destino. Mapping Runtime se basa en la pila de Java. El motor de integración también puede utilizar un programa ABAP para la conversión, que se basa en la pila ABAP. Un mensaje puede ser de dos tipos

• Sincrónico: tiene tanto la parte de solicitud-respuesta

• Asincrónico: solo tiene la solicitud o la parte de respuesta. En PI, el mensaje se representa mediante una interfaz.

Interfaz -> estructura del mensaje en formato XML + dirección En base a los criterios anteriores, existen tres tipos de interfaces

• Interfaz de salida: conéctese al sistema emisor

• Interfaz de entrada: conéctese al sistema receptor

• Interfaz abstracta: conéctese al BPE Cuando configuramos la lógica de integración (escenario) en el PI de SAP de acuerdo con nuestros requisitos comerciales, es el motor de integración el que ejecuta esa configuración de forma escalonada. Pipeline es el término utilizado para referirse a todos los pasos que se realizan durante el procesamiento de un mensaje XML.

249

Los pasos son los siguientes:

• Identificación del receptor: Determina el sistema que participa en el intercambio del mensaje.

• Determinación de la interfaz: Determina qué interfaz recibirá el mensaje.

• División de mensajes: Si se encuentra más de un receptor, PI crea una instancia de un nuevo mensaje para cada receptor.

• Asignación de mensajes: Asignación para transformar el mensaje de origen a formato de mensaje de destino.

• Enrutamiento técnico: Enlaza un destino y protocolo específico al mensaje.

• Adaptador de llamada: Envia el mensaje transformado al adaptador o a un proxy. Adapter Engine Debe haber notado anteriormente que el motor de integración maneja los mensajes solo en el protocolo XML-SOAP. Pero, ¿qué sucede si tenemos un remitente y un sistema de negocios de recepción donde los datos no están en el mismo formato? Utilizamos los diversos adaptadores en el Adapter Engine para convertir mensajes basados en XML y HTTP al protocolo específico y al formato requerido por estos sistemas, y viceversa.

Como se puede observar anteriormente, SAP PI es una estructura de hub y spoke donde Adapter Engine se puede considerar como spoke. Usamos el Adapter Engine para conectar el Integration Engine (Hub) a los sistemas externos. El Adapter Framework es la base del Adapter Engine. Adapter Framework se basa en el motor SAP J2EE Engine (como parte del SAP Web Application Server) y la J2EE Connector Architecture (JCA). Adapter Framework proporciona interfaces para la configuración, administración y supervisión de adaptadores.

250

5.21 Alta Disponibilidad

5.21.1.1 ¿Qué es la alta disponibilidad?

La disponibilidad: Es la medida de la continuidad operacional de un sistema, se expresa como un porcentaje

de tiempo, inversamente proporcional al tiempo de inactividad. Por ejemplo, si un sistema determinado está

diseñado para estar disponible durante el 99.9% del tiempo (a veces llamado "tres nueves"), su tiempo de

inactividad por año debe ser menor al 0.1%, o 9 horas.

El tiempo de inactividad: Es la consecuencia de interrupciones, que pueden ser intencionales (por ejemplo,

para actualizaciones del sistema) o causadas por fallas no planificadas. Una falla puede deberse a un mal

funcionamiento del equipo, fallas de software o de red, o debido a un desastre mayor como un incendio, una

pérdida de energía regional o un accidente de construcción, que puede desmantelar todo el centro de datos.

La alta disponibilidad: Es un conjunto de técnicas, prácticas de ingeniería y principios de diseño para Business

Continuity. Esto se logra eliminando puntos únicos de falla (tolerancia a fallas) y brindando la capacidad de

reanudar rápidamente las operaciones después de una interrupción del sistema con una pérdida comercial

mínima (resiliencia de fallas).

Fault Recovery: Es el proceso de recuperación y reanudación de operaciones después de una interrupción

debido a una falla. La recuperación de desastres es el proceso de recuperación de operaciones después de

una interrupción debido a un centro de datos prolongado o una falla del sitio. Prepararse para un desastre

puede requerir una copia de seguridad de los datos a distancias más largas y, por lo tanto, puede ser más

complejo y costoso.

5.21.1.2 Recuperación: indicadores clave de rendimiento

Los clientes suelen utilizar dos medidas clave para especificar los parámetros de recuperación de un

sistema después de una interrupción: el Objetivo del período de recuperación (RPO) y el Objetivo del

tiempo de recuperación (RTO). El RPO y el RTO de un sistema se ilustran a continuación:

251

• El RPO es el período de tiempo máximo permisible durante el cual los datos operativos pueden perderse sin posibilidad de recuperación (tiempo transcurrido entre la última copia de seguridad y el bloqueo).

• El RTO es el tiempo máximo permitido para recuperar el sistema, de modo que sus operaciones puedan reanudarse.

5.21.1.3 Eliminación de puntos únicos de falla

La clave para lograr la tolerancia a fallas es eliminar los puntos únicos de falla mediante la introducción de

redundancia. Los proveedores de dispositivos SAP HANA ofrecen varios niveles de redundancia para evitar

interrupciones debido a fallas en los componentes, que se analizan brevemente aquí. En términos generales,

estas técnicas son "transparentes" para la operación de SAP HANA, pero forman una línea de defensa crucial

contra una interrupción del sistema evitable y, por lo tanto, contribuyen en gran medida a la continuidad del

negocio.

Redundancia de hardware

Los proveedores de hardware de dispositivos SAP HANA diseñan múltiples capas de componentes y

subsistemas de hardware redundantes. Estos incluyen unidades de fuente de alimentación (PSU)

redundantes y intercambiables en caliente, ventiladores, tarjetas de interfaz de red y memorias protegidas

de corrección de errores de nivel empresarial. Estos subsistemas están diseñados de tal manera que el

componente redundante puede mantener la operación del sistema si el otro componente falla2.

Particularmente crítico es el sistema de almacenamiento. Los sistemas de almacenamiento de nivel

empresarial combinan múltiples unidades físicas en unidades lógicas, con técnicas estándar incorporadas

(RAID) para redundancia y recuperación de errores. Estos incluyen la creación de reflejos, la escritura de los

mismos datos en dos unidades diferentes en paralelo, y la paridad, bits adicionales escritos para permitir la

detección y corrección automática de errores.

Redundancia de red

Se requieren redes redundantes, equipos de red y conectividad de red para evitar que las fallas de red afecten

la disponibilidad del sistema. Esto generalmente se logra implementando una topología de switch

completamente redundante, utilizando Spanning Tree Protocol para evitar bucles. Los enrutadores pueden

configurarse con el Hot Standby Router Protocol (HSRP) para la recuperación automática de fallas. BGP se

usa comúnmente para administrar conexiones WAN duales.

252

Redundancia del centro de datos

Los centros de datos que alojan las soluciones SAP HANA están equipados con fuentes de alimentación

ininterrumpida (UPS) y generadores de energía de respaldo, sistemas de enfriamiento redundantes y

proveedores de conectividad de red y electricidad de múltiples fuentes, logrando la disponibilidad

operacional en presencia de fallas individuales y reduciendo significativamente la probabilidad de una

interrupción de impacto empresarial.

Algunas empresas operan centros de datos completamente duplicados, proporcionando un alto nivel de

tolerancia a los desastres.

5.21.1.4 Soporte de alta disponibilidad de SAP HANA

Como base de datos en memoria, SAP HANA no solo debe preocuparse de mantener la confiabilidad de sus

datos en caso de fallas, sino también de reanudar las operaciones con la mayor parte de esos datos cargados

en la memoria lo más rápido posible.

La siguiente figura muestra las fases de Alta disponibilidad. La primera fase es la preparación, preparándose

para la falla inevitable. Durante este tiempo, los datos se respaldan y los sistemas en espera están listos para

tomar el control. Se debe detectar un error, ya sea de forma automática o administrativa (para evitar falsos

positivos), y se pone en marcha un proceso de recuperación. Finalmente, la falla debe ser reparada, y el

sistema puede necesitar ser revertido a la configuración original (fallido), para estar listo nuevamente para

la siguiente falla.

Diferentes valores de RPO / RTO pueden asociarse con diferentes tipos de fallas. Se espera que los sistemas

críticos de negocios operen con un RPO de pérdida de datos cero en el caso de fallas locales, y con frecuencia

incluso en el caso de un desastre. Pero los desafíos de la recuperación de desastres son diferentes de las

fallas recuperables localmente; para lograr cero RPO y bajo RTO, los datos se deben replicar de forma

síncrona en distancias más largas, lo que afecta el rendimiento normal del sistema y puede requerir

soluciones de espera y conmutación por error más costosas.

253

Todo esto conduce a decisiones de compensación en torno a los atributos de la funcionalidad de

recuperación de fallas, el costo y la complejidad. Por consiguiente, SAP ofrece opciones de diseño

complementarias, que incluyen tres niveles de soporte de Recuperación ante desastres y dos funciones de

soporte automático de Recuperación de fallas, que se resumen en la siguiente tabla y se discuten más

detalladamente en las secciones a continuación.

5.21.1.5 Copias de seguridad (Backups)

SAP HANA utiliza tecnología en memoria, pero por supuesto, persiste completamente cualquier transacción

que cambie los datos, como inserciones de fila, eliminaciones y actualizaciones, para que pueda reanudarse

desde un corte de energía sin pérdida de datos. SAP HANA conserva dos tipos de datos para el

almacenamiento: registros de rehacer transacciones y cambios de datos en forma de puntos de rescate.

Un registro de rehacer transacción se usa para registrar un cambio. Para que una transacción sea duradera,

no es necesario que persista la información completa cuando se compromete la transacción; en cambio, es

suficiente para persistir el registro de rehacer. Al producirse una interrupción, el estado coherente más

reciente de la base de datos se puede restaurar reproduciendo los cambios registrados en el registro,

rehaciendo las transacciones completadas y retrotrayendo las incompletas.

Un punto de rescate es un punto en el tiempo periódico, cuando todos los datos modificados se escriben en

el almacenamiento, en forma de páginas. Uno de los objetivos de realizar puntos de rescate es acelerar el

reinicio: al iniciar el sistema, no es necesario procesar los registros desde el principio, sino solo desde la

última posición del punto de rescate. Los puntos de guardado se coordinan en todos los procesos (llamados

servicios SAP HANA) y las instancias de la base de datos para garantizar la coherencia de las transacciones.

De forma predeterminada, los puntos de guardado se realizan cada cinco minutos, pero esto se puede

configurar.

Los puntos de guardado normalmente sobrescriben los puntos de guardado más antiguos, pero es posible

congelar un punto de guardado para uso futuro; esto se llama una instantánea. Las instantáneas se pueden

replicar en forma de copias de seguridad de datos completas, que se pueden usar para restaurar una base

de datos a un punto específico en el tiempo. Esto puede ser útil en caso de corrupción de datos, por ejemplo.

Además de las copias de seguridad e instantáneas de datos, las copias de seguridad de registros periódicos

más pequeñas aseguran la capacidad de recuperarse de fallas de almacenamiento fatales con una pérdida

mínima de datos.

254

La figura anterior muestra los puntos de guardado, guardados en el almacenamiento local y las copias de

seguridad adicionales guardadas en el almacenamiento de la copia de seguridad. La recuperación local del

bloqueo usa el último punto de guardado y luego reproduce los últimos registros para recuperar la base de

datos sin pérdida de datos. Si el almacenamiento local fue dañado por el bloqueo, aún es posible recuperar

la base de datos de la copia de seguridad de datos (o la última instantánea) y registrar copias de seguridad,

posiblemente con alguna pérdida de datos.

El envío regular de copias de seguridad a una ubicación remota a través de una red o por medio de correos

puede ser una forma sencilla y relativamente económica de prepararse para un desastre. Dependiendo de la

frecuencia y el método de envío, este enfoque puede tener un RPO de horas o días.

5.21.1.6 Replicación de almacenamiento

Una desventaja de las copias de seguridad es la posible pérdida de datos desde el momento de la última

copia de seguridad hasta el momento de la falla. Una solución preferida, por lo tanto, es proporcionar una

replicación continua de todos los datos persistentes. Varios socios de hardware de SAP HANA ofrecen una

solución de replicación de nivel de almacenamiento, que ofrece una copia de seguridad de los volúmenes o

el sistema de archivos a un sistema de almacenamiento en red remoto.

255

En algunas de estas soluciones específicas de proveedores, que están certificadas por SAP, la transacción SAP

HANA solo finaliza cuando el registro de transacciones localmente persistente se ha replicado de forma

remota. Esto se llama replicación de almacenamiento síncrono. La replicación de almacenamiento síncrono

solo se puede utilizar cuando la distancia entre el sitio primario y de respaldo es de hasta 100 kilómetros

(uno o pocos saltos, con no más de ~ 5 μsec de latencia por kilómetro), lo que permite latencias de ida y

vuelta de milisegundos.

Debido a su naturaleza continua, la replicación de almacenamiento (a veces también llamada duplicación de

almacenamiento remoto) ofrece un RPO más atractivo que las copias de seguridad, pero esta solución

requiere una conexión confiable, de ancho de banda alto y baja latencia entre el sitio primario y secundario.

En el caso de una falla desastrosa que justifique una conmutación por error completa del sistema, un

administrador conecta un sistema en espera al almacenamiento replicado y luego reinicia el sistema SAP

HANA. El administrador debe tener cuidado de que el sistema primario fallido ya no pueda escribir en el

almacenamiento replicado (una acción llamada vallado), o existe el riesgo de corrupción de datos, con dos

sistemas escribiendo en el mismo almacenamiento.

5.21.1.7 Replicación del sistema

System Replication es una solución de HA alternativa para SAP HANA que proporciona un RTO

extremadamente corto y es compatible con todas las soluciones de socios de hardware de SAP HANA. La

replicación del sistema emplea un enfoque "N + N", con un sistema SAP HANA en espera secundario con el

mismo número de nodos activos que el sistema primario activo. Cada servicio e instancia del sistema SAP

HANA primario se comunica en pares con una contraparte en el sistema secundario.

256

El sistema secundario se puede ubicar cerca del sistema principal para que sirva como una solución rápida

de conmutación por error para el tiempo de inactividad planificado, o para manejar la corrupción del

almacenamiento u otras fallas locales. Alternativamente, o adicionalmente (de varios niveles o en cascada),

se puede instalar un sistema secundario en un sitio remoto para recuperación de desastres. Al igual que la

Replicación de almacenamiento, esta opción de Recuperación de desastres requiere un enlace confiable

entre los sitios primario y secundario.

Las instancias en el sistema secundario operan en modo de replicación en vivo. En este modo, todos los

servicios secundarios del sistema se comunican constantemente con sus contrapartes principales, replican y

persisten datos y registros, y normalmente cargan datos en la memoria. El registro y los datos se pueden

comprimir antes del envío. El sistema secundario no acepta solicitudes o consultas.

En una configuración alternativa, llamada replicación del sistema sin precarga de datos, el sistema secundario

no carga previamente los datos y, por lo tanto, consume muy poca memoria. Esto permite que los hosts del

sistema secundario sirvan para propósitos dobles, por ejemplo para desarrollo o prueba / QA con

almacenamiento separado. Antes de la adquisición, estas actividades deben ser desactivadas. El intercambio

es un RTO más largo en caso de conmutación por error.

Así es como funciona la replicación del sistema. Cuando el sistema secundario se activa en el modo de

replicación en vivo, cada componente del servicio establece una conexión con su contraparte principal del

sistema y solicita una instantánea de los datos. A partir de ese momento, todos los cambios registrados en

el sistema primario se replican. Siempre que los registros se conservan en el sistema primario, también se

envían al sistema secundario. Una transacción en el sistema primario no se compromete hasta que se

repliquen los registros de rehacer, como lo determina una opción de replicación de logs:

• Sincrónico: el sistema primario espera al comprometer la transacción hasta que recibe una respuesta

de que el registro persiste en el sistema secundario. Este modo garantiza la consistencia inmediata

entre ambos sistemas, a un costo de retrasar la transacción en el momento de la transmisión de

datos y persistir en el sistema secundario.

257

La pregunta de qué hacer si la replicación falla (por ejemplo, debido a un error de red) se rige por la opción

de configuración de sincronización completa. Se puede configurar para que comprometa la transacción, o

para que falle la confirmación en el sistema primario, hasta que se restaure la replicación.

• Sincronización en memoria: el sistema primario confirma la transacción después de que recibe una

respuesta de que el registro fue recibido por el sistema secundario, pero antes de que persistiera. El

retraso de la transacción en el sistema primario es más corto, porque solo incluye el tiempo de

transmisión de datos.

• Asincrónico (desde SPS6): el sistema primario confirma la transacción después de enviar el registro

sin esperar una respuesta. Esto elimina la latencia de sincronización, con el riesgo de pérdida de

datos menos teórica durante la falla. Este modo es más útil cuando el sitio secundario está a cientos

de kilómetros del sitio principal o cuando la reducción en la latencia es crítica.

Si se pierde la conexión al sistema secundario o falla el sistema secundario, el sistema primario (después de

un tiempo de espera breve y configurable) reanudará las operaciones sin protección de respaldo.

La gestión de los registros recibidos en el sitio secundario se realiza de dos maneras posibles, dependiendo

del modo de operación de replicación del sistema configurado:

• Envío de datos delta (desde SPS5): en este modo de operación, el sistema secundario persiste, pero

no reproduce inmediatamente los registros recibidos. Para evitar una creciente lista de registros, las

instantáneas de datos incrementales se transmiten de forma asincrónica de vez en cuando desde el

sistema primario al secundario. Si el sistema secundario tiene que hacerse cargo, solo debe

reproducirse la parte del registro que representa los cambios que se realizaron después de la

instantánea de datos más reciente. Además de las instantáneas, el sistema primario también

transfiere información de estado con respecto a qué columnas de la tabla de columnas están

actualmente cargadas en la memoria. El sistema secundario carga estas columnas en consecuencia.

▪ Logreplay (desde SPS11): con este modo de operación configurado, las entradas de registro recibidas

se reproducen inmediatamente en el sistema secundario. El tiempo de toma de control se reduce

porque ya no es necesario volver a reproducir el registro. Además, hay mucho menos tráfico de red

entre el sitio primario y el secundario, porque la entrega de datos delta no es necesaria.

En el caso de una falla que justifique una conmutación por error completa del sistema, un administrador

indica al sistema secundario que cambie del modo de replicación activo a la operación completa. El sistema

secundario, que cargó previamente la misma columna de datos que el sistema primario, se convierte en el

sistema primario al reproducir los últimos registros de transacciones y luego comienza a aceptar consultas.

Cuando el sistema original puede restaurarse en el servicio, puede configurarse como el nuevo sistema

secundario o revertirse a la configuración original "hacia atrás".

258

SPS09 presenta una forma de enganchar eventos y acciones dentro de SAP HANA scale-out (como Host Auto-

Failover) y la replicación del sistema. Un administrador puede agregar acciones requeridas a un script Python,

que se ejecutará antes o después de los eventos (como inicio, cierre, failover, toma de control, ...).

Estos ganchos llamados "Proveedor de HA / DR" se pueden usar para abordar problemas que requieren

atención de integración, como la forma de manejar las conexiones de cliente de base de datos configuradas

para llegar al sistema primario, y deben "omitir" el sistema secundario después. de una conmutación por

error. Por ejemplo, se podría escribir un enlace para reasignar direcciones IP virtuales después de una

adquisición en la replicación del sistema SAP HANA.

La redirección de IP es el método de elección para la compatibilidad de reconexión de cliente de extremo a

extremo, ya que maneja la recuperación uniforme y simple de extremo a extremo de clientes SQL y HTTP,

con tiempos de recuperación muy cortos y sin tiempo de inactividad. Configuración especial en el lado del

cliente. El principio de redirección de IP (también conocido como VIP6) es definir un nombre de host "lógico"

adicional (hana1, en la siguiente imagen) con su dirección IP lógica separada (10.68.104.51), y luego asignarlo

inicialmente a la dirección MAC desde el host original en el sistema primario (cuando está vinculado a una

de las interfaces de host). Como parte del procedimiento de conmutación por error, se ejecuta una secuencia

de comandos que reasigna la dirección IP lógica sin cambios al host de conmutación por error

correspondiente en el sistema secundario. Esto debe hacerse en pares, para cada host en el sistema primario.

La reasignación afecta el cambio de L2, como se puede ver en el paso 4 del siguiente diagrama:

259

La redirección de IP se puede implementar utilizando varias técnicas, por ejemplo, con el uso de comandos

de Linux que afectan a las tablas ARP de red, configurando los switches de red L2 directamente o mediante

el uso de software de administración de clústeres. Después de la configuración de redireccionamiento de IP,

las memorias caché ARP deben eliminarse, para proporcionar una experiencia de recuperación casi

instantánea a los clientes.

La redirección de IP requiere que tanto el host primario como el de conmutación por error estén en la misma

red L2. Esto depende del diseño de la red del cliente, pero las redes están cada vez más diseñadas con L2 a

través de L3 (como Ethernet sobre MPLS), lo que hace que esta opción sea una solución viable en muchos

casos. Si el sistema en espera está en una red L3 completamente separada, entonces la redirección de DNS

es la solución alternativa preferida.

DNS es un enlace desde un nombre de dominio lógico a una dirección IP. Los clientes se ponen en contacto

con un servidor DNS para obtener la dirección IP del host HANA (paso 1 a continuación) a la que desean

llegar. Muchos productos DNS admiten la configuración de conmutación por error al usar campos de

respuesta TTL cortos (unos minutos o menos), y se pueden configurar con la funcionalidad de vigilancia y

conmutación automática activada.

Como parte del procedimiento de conmutación por error, se ejecuta una secuencia de comandos que cambia

la asignación del nombre DNS a IP del host principal al host correspondiente en el sistema secundario (por

pares para todos los hosts del sistema). A partir de ese momento, los clientes son redirigidos a los hosts de

failover, como en el paso 2 del siguiente diagrama:

260

La redirección de DNS e IP comparte la ventaja de que no hay configuraciones o requisitos específicos del

cliente. Además, admite configuraciones DR donde los sistemas primarios y en espera pueden estar en dos

dominios de red completamente diferentes (separados por enrutadores). Una desventaja de esta solución

es que la modificación de las asignaciones de DNS requiere una solución de propiedad del proveedor.

Además, debido al almacenamiento en caché del DNS en nodos (clientes y equipos de red intermedios),

puede llevar un tiempo (hasta horas) hasta que se propaguen los cambios del DNS, causando que los clientes

experimenten un tiempo de inactividad a pesar de la recuperación del sistema.

5.21.1.8 Servicio de reinicio automático

En caso de una falla del software (o una intervención intencional de un administrador), que inhabilita uno de

los servicios SAP HANA configurados (Index Server, Name Server, etc.), el servicio se reiniciará mediante el

reinicio automático del servicio SAP HANA. función de vigilancia, que detecta automáticamente la falla y

reinicia el proceso de servicio detenido. Al reiniciar, el servicio carga datos en la memoria y reanuda su

función. Si bien todos los datos permanecen seguros (RPO = 0), la recuperación del servicio lleva tiempo.

5.21.1.9 Host Auto-Failover

Es una solución de recuperación de fallas "N + m" (m suele ser 1) local que se puede usar como una medida

complementaria o alternativa a la solución de replicación del sistema descrita anteriormente. Uno (o más)

hosts en espera se agregan a un sistema SAP HANA y se configuran para que funcionen en el modo en espera.

Siempre que estén en modo de espera, las bases de datos de estos hosts no contienen ningún dato y no

aceptan solicitudes ni consultas.

261

Cuando un host activo (trabajador) falla, un host en espera toma su lugar automáticamente. Como el host

en espera puede hacerse cargo de la operación desde cualquiera de los hosts principales, necesita acceso a

todos los volúmenes de la base de datos. Esto puede lograrse mediante un servidor de almacenamiento en

red compartido, utilizando un sistema de archivos distribuido, o con soluciones específicas de proveedores

que utilizan una interfaz programática de SAP HANA (la denominada API de conector de almacenamiento)

para separar dinámicamente y conectar (montar) el almacenamiento en red (por ejemplo, utilizando

almacenamiento en bloque a través de Fibre Channel) tras la conmutación por error.

Un tema que requiere cierta atención es cómo recuperar las conexiones de los clientes de SAP HANA que se

configuraron para llegar al host original, y deben ser "desviadas" al host en espera después de la conmutación

por error automática del host.

Un enfoque es un enfoque basado en la red (IP o DNS), exactamente como se discutió anteriormente.

Alternativamente, los clientes de la base de datos SQL / MDX pueden configurarse con la información de

conexión de múltiples hosts, incluyendo opcionalmente el host en espera (se proporciona una lista de

múltiples hosts en la cadena de conexión). El código de conexión del cliente (ODBC / JDBC) utiliza un enfoque

"round-robin" para volver a conectarse y garantiza que estos clientes puedan llegar a la base de datos de SAP

HANA, incluso después de la conmutación por error. Para admitir clientes HTTP (web), que utilizan los

servicios de la aplicación SAP HANA XS7, se recomienda instalar un equilibrador de carga HTTP (HLB) externo,

protegido contra fallas, como el despachador web de SAP o un producto similar de otro proveedor. Los HLB

están configurados para supervisar los servidores web en todos los hosts en los sitios primario y secundario.

262

HLB (que sirve como un proxy web inverso) redirecciona los clientes HTTP al servidor correcto, luego de la

falla de la instancia HANA. Los clientes HTTP están configurados para usar la dirección IP del propio HLB

(obtenido a través de DNS) y no tienen conocimiento de ninguna actividad de failover de HANA.

Un escenario peligroso que puede ocurrir con Host Auto-Failover se conoce como cerebro dividido. Una

división de cerebro podría ocurrir accidentalmente si, por ejemplo, el host2 realmente no fallara, sino que

perdiera todas sus conexiones de red (haciendo que el host en espera decidiera tomar el control). En este

caso, ambos sistemas que no se comunican asumen el rol de host2 y ambos pueden escribir en el mismo

almacenamiento, lo que causa daños en los datos. Se debe implementar la prevención de dicha corrupción

de datos debido a situaciones de cerebro dividido (cercado). La API de almacenamiento mencionada

anteriormente admite vallas.

Una vez reparado, el host fallido se puede volver a unir al sistema como el nuevo host en espera, para

restablecer la capacidad de recuperación de fallas.

5.22 Escalibilidad

5.22.1 Comprender las cargas de trabajo

SAP HANA se utiliza en una variedad de escenarios como Data Marts, como una base de datos para SAP

Business Warehouse o SAP Business Suite, y como el almacén de datos general para nuevas e innovadoras

aplicaciones en tiempo real. Cada caso de uso y carga de trabajo es diferente, y los requisitos de escalabilidad

también son diferentes.

263

En términos generales, los requisitos de escalabilidad se dividen en dos categorías principales:

• Volumen de datos: dado que SAP HANA System Architecture tiene un componente de memoria

importante y limitado, es sumamente importante poder estimar y comprender la huella en la

memoria y el consumo de memoria de la aplicación a lo largo del tiempo.

• Rendimiento: la escala de rendimiento está determinada por varios parámetros: un número cada vez

mayor de conexiones, usuarios y volúmenes de consultas, una complejidad de consultas cada vez

mayor y, por supuesto, el impacto de los crecientes tamaños de datos.

El rendimiento se mide fundamentalmente por dos indicadores principales: tiempo de respuesta y

rendimiento.

El tiempo de respuesta es el tiempo que experimenta el cliente de la base de datos, desde enviar una solicitud

hasta recibir una respuesta. El tiempo de respuesta es una función de la complejidad de la consulta, el

tamaño de datos y la paralelización de SAP HANA, pero también está influenciado por la carga general del

sistema.

El rendimiento es el número de consultas "promedio" manejadas por unidad de tiempo, por ejemplo,

consultas por hora. Para predecir o calcular el rendimiento del sistema, es necesario especificar y medir el

costo y la tasa de las consultas más dominantes.

Las consideraciones de escalabilidad más detalladas se discuten a continuación.

5.22.2 Escalar los datos

La memoria se utiliza principalmente para dos propósitos: las tablas de la base de datos y como

almacenamiento temporal para los cálculos realizados por consultas. Cuantos más datos, y / o consultas

ejecutadas simultáneamente, más memoria se requiere.

La cantidad de RAM requerida para usar SAP HANA será, por lo tanto, una de las primeras consideraciones

de escalabilidad. Esto es crítico debido a las siguientes razones:

• La memoria es un elemento del costo de adquisición de SAP HANA y afecta a las licencias en tiempo

de ejecución.

• SAP HANA proporciona compresión y reducción de datos avanzadas, lo que hace que sea más difícil

calcular de antemano la huella de memoria física requerida para un conjunto de datos determinado.

264

• La cantidad de memoria utilizada se ve muy afectada por el tipo y la cantidad de consultas

simultáneas.

• Los volúmenes de los conjuntos de datos tienden a crecer con el tiempo, por lo que la planificación

de la memoria es crucial.

La siguiente figura ilustra el uso de la memoria en un sistema SAP HANA a lo largo del tiempo. La línea roja

superior representa la cantidad real de RAM física en el sistema (un servidor o agregado en varios servidores).

El límite de asignación, establecido de forma predeterminada en el 90% de la RAM, corresponde a la licencia

de tiempo de ejecución de SAP HANA. SAP HANA utiliza un grupo dinámico para "reservar" memoria antes

de su uso, hasta este límite. SAP recomienda reservar aproximadamente el 50% del grupo de memoria

utilizado para los cálculos temporales relacionados con la consulta, pero este valor se ve realmente afectado

por la carga de trabajo de la aplicación.

SAP HANA tiene varios mecanismos para tratar situaciones con poca memoria. Por ejemplo, "descargará"

tablas menos usadas o columnas de tabla para liberar memoria, sabiendo que estas columnas siempre se

pueden volver a cargar más tarde desde la copia persistente y los registros. Esto es fácil de hacer debido a su

organización de datos en columnas.

SAP ha publicado varias "guías de dimensionamiento" para ayudarlo a estimar los requisitos de memoria de

una aplicación y su conjunto de datos; vea la sección de referencia de este documento.

Una técnica para hacer frente a la expansión planificada de los datos es comprar más memoria RAM física de

la que se requiere inicialmente, establecer el límite de asignación según las necesidades y aumentarlo con el

tiempo para adaptarlo a los datos crecientes.

265

Una vez que se han alcanzado los límites físicos de un solo servidor, es posible escalar en varias máquinas

para crear un sistema SAP HANA distribuido. Una técnica es distribuir diferentes esquemas y tablas a

diferentes servidores (datos completos y separación de usuarios), pero eso no siempre es posible, por

ejemplo, cuando una sola tabla de hechos es más grande que el tamaño de RAM del servidor.

La estrategia más importante para escalar datos es la partición de datos. El particionamiento admite la

creación de tablas muy grandes (miles de millones de filas) dividiéndolas en trozos más pequeños que pueden

colocarse en máquinas diferentes, como se ilustra a continuación.

El particionamiento es transparente para la mayoría de las consultas SQL y otras manipulaciones de datos.

Casos de uso típicos para la partición:

Superar la limitación no particionada de 2 mil millones de filas por tabla

1. Equilibrio de carga: mediante el uso de particiones, una consulta en una tabla no es procesada por

un único servidor, sino por todos los servidores que alojan particiones que son relevantes para el

procesamiento.

2. Paralelización: las operaciones se paralelizan utilizando varios subprocesos de ejecución por tabla.

3. Poda de partición: SAP HANA analiza las consultas para encontrar una coincidencia con la

especificación de partición. Si se encuentra, solo las máquinas coincidentes deben ser consultadas;

esto reduce la carga general del sistema y mejora el tiempo de respuesta.

4. Manejo explícito de particiones: las aplicaciones pueden controlar activamente las particiones, por

ejemplo, agregando particiones que deberían contener los datos para un mes próximo.

5.22.3 Escalar el rendimiento

Avanzar a lo largo de la escala de rendimiento es un tema más complejo. Como se discutió, el rendimiento

de SAP HANA se deriva de su enfoque eficiente y paralelizado. En términos generales, cuantos más núcleos

de computación tenga el servidor SAP HANA, mejor será el rendimiento general del sistema.

Esta es una vista simplificada, por supuesto, y el rendimiento de escalamiento requiere una comprensión

más detallada de la carga de trabajo y las expectativas de rendimiento.

266

Cuando hablamos de una consulta única, hablamos del tiempo de ejecución de la consulta. La concurrencia

de una consulta es la número promedio de núcleos utilizados para ejecutarlo. Esto se muestra en la siguiente

figura:

El costo computacional de la consulta es, por lo tanto, el "área" de la consulta (concurrencia multiplicada por

el tiempo de ejecución, en unidades de core-ticks). Considere, por ejemplo, una consulta SQL Q1 que realiza

una transacción relativamente simple que no necesita ser paralelizada, por lo que solo utiliza un núcleo para

su duración. La ejecución, dos o veinte, o incluso doscientas de dichas consultas simultáneamente permite a

la base de datos programar cada consulta en un núcleo de cómputo separado. Cada una de las consultas

concurrentes parecerá ejecutarse casi tan rápido como una sola instancia de la consulta en sí misma.

Considere, en el otro extremo, una consulta Q2 que ejecuta una compleja agregación analítica en una enorme

tabla estructurada en OLAP. La implementación más eficiente de esta consulta utilizará todos los recursos

disponibles en la máquina durante toda la consulta, lo que resultará en un resultado de rendimiento

impresionante. ¿Qué ocurre si dos o más consultas similares se ejecutan simultáneamente? Ahora, los

recursos de la máquina deben ser compartidos, y cada una de las consultas simultáneas parecerá ejecutarse

durante mucho más tiempo.

Esta situación se ilustra a continuación en una máquina de 64 núcleos. La imagen de la izquierda muestra

cómo 3 instancias concurrentes de Q1 toman el mismo tiempo que una instancia independiente. La imagen

de la derecha muestra cómo 3 instancias concurrentes de Q2 toman tres veces más tiempo que una sola

instancia de esta consulta.

267

La razón es que tres instancias de Q1 toman solo 3 x t1 core-ticks, mientras que tres instancias de Q2 toman

192 x t2 core-ticks, y así se ejecutan tres veces más que una sola consulta. Los usuarios experimentan un

tiempo de respuesta más largo.

Por supuesto, la mayoría de las consultas reales se encuentran entre estos ejemplos ficticios. El uso de

simulaciones y estimaciones de cargas de trabajo de consultas típicas de clientes puede determinar la carga

esperada que una instalación típica de SAP HANA puede administrar cómodamente.

En el nivel de carga de trabajo, se puede establecer una predicción aproximada de la escalabilidad midiendo

la utilización promedio de la CPU mientras se está ejecutando la carga de trabajo. Por ejemplo, una utilización

promedio de CPU del 45% puede indicar que el sistema puede cargarse 2 veces antes de mostrar una

reducción considerable en el tiempo de respuesta de consulta individual.

Existen varias herramientas para medir y analizar el rendimiento de producción y el rendimiento, la mayoría

de los cuales se puede acceder a través de SAP HANA Studio. Entre estas herramientas se encuentran diversas

perspectivas administrativas, que proporcionan una vista de alto nivel del rendimiento del sistema, listas de

sentencias SQL principales ordenadas por rendimiento y frecuencia, gráficos de rendimiento a lo largo del

tiempo y más.

Al acercarse a los detalles, una gran cantidad de tablas del sistema y vistas de monitoreo brindan información

estadística sobre cientos de parámetros de rendimiento a los que también se puede acceder mediante

programación. Otras herramientas proporcionan información más detallada sobre el comportamiento de

consultas individuales, como la herramienta de visualización del plan de ejecución, que se muestra a

continuación.

268

5.22.4 Escalar la aplicación

Los desarrolladores de aplicaciones tienen muchas formas de mejorar la interacción con SAP HANA y lograr

un rendimiento óptimo. El código de la aplicación existente puede escalarse aún más al empujar

juiciosamente las operaciones en la capa de datos de SAP HANA, utilizando SQLScript y otras construcciones

de código incrustado. Dado que esto dará como resultado un mayor uso de operadores internos, aprovecha

óptimamente los recursos de hardware y software de un sistema SAP HANA.

Modelar los datos en la forma de un esquema de estrella OLAP clásico puede resultar en mejoras

impresionantes de rendimiento, debido a las capacidades paralelas muy altas del optimizador SAP HANA

OLAP.

El particionamiento, mencionado anteriormente como una solución para escalar los requisitos de memoria

de SAP HANA, también admite sesiones cada vez más concurrentes y consultas analíticas cada vez más

complejas, al distribuir los cálculos en varios servidores. Se debe tener especial cuidado al distribuir los datos,

de modo que la mayoría de las consultas coincidan con las reglas de poda de las particiones. Esto logra dos

objetivos: dirigir diferentes usuarios a diferentes servidores (equilibrio de carga) y evitar la sobrecarga de la

red relacionada con la frecuente unión de datos entre los servidores.

Otras técnicas para aumentar aún más el rendimiento de consultas son el uso de columnas calculadas para

representar condiciones de filtro comunes, el uso de particiones incluso en un solo servidor para explotar la

poda, el despliegue de equilibradores de carga con instancias de bases de datos replicadas, agregaciones

parciales y más.

5.22.5 Escalar el hardware

SAP HANA se ofrece de dos formas: en forma de dispositivos, entregados en diferentes configuraciones y

"tamaños" por socios de hardware calificados, o como parte de un servicio basado en la nube. Esto crea

diferentes opciones de diseño del sistema, con respecto a las variaciones de escalamiento horizontal y

vertical.

Para maximizar el rendimiento y el rendimiento, SAP recomienda que amplíe lo más posible (adquiera la

configuración con la mayor especificación de memoria y procesador para la carga de trabajo de la aplicación)

antes de ampliar (para implementaciones con requisitos de volumen de datos aún mayores).

Tenga en cuenta que algunos de los proveedores de hardware recomiendan diferentes bloques de

construcción para sus implementaciones de una sola máquina y de escala horizontal (servidores en rack y

blades), por lo que la planificación de una estrategia de escalabilidad horizontal debe tener esto en cuenta.

269

5.22.6 Prueba de referencia de escalabilidad

Se desarrolló una prueba comparativa para demostrar la escalabilidad y el rendimiento analítico de SAP

HANA para la inteligencia empresarial en tiempo real en una base de datos representativa, utilizando 16

servidores. Los 16 servidores estaban equipados con 0.5TB de memoria y 80 núcleos lógicos.

Se generó un conjunto de datos de ventas y distribución de 100 TB1 en un formato que se extraería de un

sistema SAP ERP (por ejemplo, registros de datos con múltiples campos) para su análisis en un almacén

comercial.

Los datos constan de una tabla de hechos de cien mil millones de registros y varias tablas de dimensiones

más pequeñas, que representan los datos de ventas y distribución de 5 años. Los datos se dividen en hash

por igual en 16 servidores utilizando la identificación del cliente. Dentro de un servidor, los datos se dividen

en intervalos de un mes. Esto da como resultado 60 particiones por servidor y aproximadamente 104

millones de registros por partición.

Los datos se cargaron en paralelo utilizando el comando IMPORT de SAP HANA. La carga se paraleliza

automáticamente en todos los nodos. La tasa de carga se midió en 16 millones de registros por minuto,

suficiente para cargar 100 millones de registros (lo que representa una actividad de un día hábil) en solo seis

minutos.

La compresión de datos ocurre durante el proceso de carga de datos. SAP HANA demostró una tasa de

compresión mayor a 20X2; el conjunto de datos de 100TB se redujo a una base de datos HANA de 3.78 TB,

consumiendo solo 236 GB de RAM en cada nodo. La gran tabla de hechos representa el 85% del conjunto de

datos y se comprimió para ocupar menos de la mitad de la memoria RAM disponible por nodo.

270

El conjunto de consultas representa una carga de trabajo mixta utilizando los datos en forma nativa

representativa (es decir, no indexada, ajustada o desregulada de otro modo para evitar uniones, como sería

habitual en una base de datos convencional). Las consultas cubren una gama de actividades realistas de BI

que incluyen informes generales, consultas iterativas (drill downs), clasificación y análisis año tras año.

La metodología de prueba incluyó el tiempo de ejecución de la línea de base y el rendimiento de múltiples

flujos.

Las consultas iterativas demuestran la excelente capacidad de SAP HANA para agregar datos. Por ejemplo, la

consulta de más larga ejecución se ejecutó en poco más de un segundo, pero tomó solo 2,8 veces más para

analizar 12 veces más datos que su equivalente mensual. Las consultas analíticas realizaron eficientemente

uniones sofisticadas (hecho-a-hecho, consultas secundarias, CSQ, unión de todo) y análisis en un intervalo

de tiempo móvil (año tras año). Las consultas con rangos de fechas de uno a seis meses se ejecutaron en dos

segundos o menos; la consulta más compleja, que analizó todo el rango de fechas de 5 años, se ejecutó en

menos de cuatro segundos. Todos los tiempos de consulta analítica se encuentran dentro de los marcos de

tiempo para soportar el análisis iterativo de la velocidad de pensamiento.

Veinticinco secuencias de consulta simultáneas (que representan aproximadamente 2600 usuarios activos

"típicos") se ejecutaron en aproximadamente 3 veces el tiempo de una sola secuencia de consulta, lo que

demuestra una buena escalabilidad de rendimiento.

5.23 Seguridad

5.23.1 Seguridad en la funcionalidad

Con el uso cada vez mayor de sistemas distribuidos e Internet para gestionar datos comerciales, las

demandas de seguridad también van en aumento. Al usar un sistema distribuido, debe asegurarse de que

sus datos y procesos respalden las necesidades de su negocio sin permitir el acceso no autorizado a

información crítica. Los errores del usuario, la negligencia o el intento de manipulación de su sistema no

deberían ocasionar pérdida de información o tiempo de procesamiento.

Administración de usuarios y autenticación

271

El componente central SAP ERP utiliza los mecanismos de administración y autenticación del usuario

proporcionados con la plataforma SAP NetWeaver, en particular, el servidor de aplicaciones SAP NetWeaver.

Por lo tanto, las recomendaciones y pautas de seguridad para la administración de usuarios y la

autenticación, tal como se describe en SAP NetWeaver Application Server para la Guía de seguridad de ABAP,

también se aplican al componente central SAP ERP.

Además de estas pautas, incluimos información sobre la administración de usuarios y la autenticación que

se aplica específicamente al componente central de SAP ERP en los siguientes temas:

Administración de usuarios Este tema enumera las herramientas que se usarán para la administración de

usuarios, los tipos de usuarios requeridos y los usuarios estándar que se entregan con el componente central

SAP ERP.

Sincronización de datos de usuario Los componentes del componente central de SAP ERP pueden usar datos

de usuario junto con otros componentes. Este tema describe cómo se sincronizan los datos del usuario con

estas otras fuentes.

Integración en entornos de inicio de sesión único Este tema describe cómo el componente central de SAP

ERP admite mecanismos de inicio de sesión único.

Administración de Usuario: La administración de usuarios de SAP ERP Central Component utiliza los

mecanismos proporcionados por SAP NetWeaver Application Server para ABAP, como herramientas, tipos

de usuario y el concepto de contraseña. Para obtener una descripción general de cómo estos mecanismos se

aplican al componente central de SAP ERP, consulte las secciones a continuación. Además, brindamos una

lista de los usuarios estándar necesarios para operar los subcomponentes de SAP ERP Componente central.

5.23.1.1 Administración de usuario y rol de Application Server ABAP

Propósito: Utiliza las funciones de administración de usuario y rol de Application Server ABAP (AS ABAP) para

administrar usuarios, roles y autorizaciones en sistemas ABAP. Al asignar roles y autorizaciones, limita el

ámbito de acción de los usuarios individuales en el sistema.

Estructura: La documentación para el usuario y la administración de roles de Application Server ABAP (AS

ABAP) consta de las siguientes partes:

Concepto de autorización AS ABAP: Esta sección presenta los componentes de autorización con los que

funcionan la función y la administración del usuario.

272

Configuración de administración de usuario y rol: Esta sección describe la configuración de todos los

elementos de la función y la administración del usuario.

Administrar roles y usuarios: Esta sección describe todas las tareas de administración y los procedimientos

exactos de la administración de usuarios y autorizaciones.

5.23.1.2 Concepto de Autorización ABAP

El concepto de autorización de ABAP protege las transacciones, los programas y los servicios en los sistemas

SAP contra el acceso no autorizado. Sobre la base del concepto de autorización, el administrador asigna

autorizaciones a los usuarios que determinan qué acciones puede ejecutar un usuario en el sistema SAP,

después de que él o ella haya iniciado sesión en el sistema y se haya autenticado.

Para acceder a objetos comerciales o ejecutar transacciones SAP, un usuario requiere las autorizaciones

correspondientes, ya que los objetos comerciales o las transacciones están protegidos por objetos de

autorización. Las autorizaciones representan instancias de objetos de autorización genéricos y se definen

según la actividad y las responsabilidades del empleado. Las autorizaciones se combinan en un perfil de

autorización asociado a un rol. Los administradores de usuario luego asignan las funciones correspondientes

utilizando el registro maestro de usuario, de modo que el usuario puede usar las transacciones apropiadas

para sus tareas.

La siguiente figura muestra los componentes de autorización y sus relaciones.

273

5.23.1.3 Configuración de administración de usuario y rol

Al considerar la administración del usuario y la función en un sistema, hay una serie de tareas asociadas con

la configuración del sistema, tanto durante la instalación inicial como durante el ciclo de vida del sistema.

• Primer procedimiento de instalación: Antes de utilizar SAP NetWeaver Application Server (SAP

NetWeaver AS) ABAP de forma productiva, debe cumplir los requisitos previos para la administración

de usuarios.

• Configuración de usuarios y administradores de autorización: Dividir las tareas de administración de

usuarios entre varios administradores para garantizar la separación de tareas al asignar

autorizaciones.

• Configurar la herramienta de administración de roles: Configurar la herramienta de administración

de roles y decida cómo manejar las comprobaciones de autorización.

• Seguridad de inicio de sesión y contraseña en SAP NetWeaver AS para ABAP: Configurar las reglas de

contraseña, los parámetros del perfil de inicio de sesión y contraseña, la política de seguridad y los

modificadores de personalización para las contraseñas generadas.

• Reglas para nombres de usuario: Establezca las reglas que eliminen los resultados indeseables del

uso irrestricto de los caracteres Unicode para los ID de usuario.

• Protección de usuarios especiales: Proteja a los usuarios predeterminados del mal uso.

• Seguridad en grupos de sistemas: La configuración de autorizaciones requiere que considere el grupo

de sistemas: desarrollo, prueba y producción.

• Administración de roles: La administración de roles abarca las funciones disponibles para la

administración de roles y autorizaciones y la asignación indirecta de roles utilizando la estructura

organizacional.

• Administración central de usuarios (CUA): Al utilizar Administración central de usuarios, puede

mantener los registros maestros de usuario centralmente en un sistema. Los cambios en la

información se distribuyen automáticamente a los sistemas secundarios. Esto significa que tiene una

visión general en el sistema central de todos los datos del usuario en todo el panorama del sistema.

• Gestión de usuarios de DBMS: La administración de usuarios del sistema de administración de bases

de datos (DBMS) permite que SAP NetWeaver AS para ABAP administre usuarios y sus privilegios en

el DBMS.

274

• Repositorio central para datos de personalización: El objetivo de un repositorio central para datos

de personalización es proporcionar almacenamiento para datos específicos del usuario y roles

específicos sin tener que crear tablas de bases de datos adicionales. Esta información debe tenerse

en cuenta siempre que se cambien usuarios o roles.

• Directorio de Servicios: Con los servicios de directorio, varias aplicaciones en el entorno de TI pueden

acceder a información común en una ubicación central.

• Comprobación de cambios en las autorizaciones después de las actualizaciones: Habilite la

administración de roles con el generador de perfiles y realice un postprocesamiento general al

realizar la actualización.

• Personalizar autorizaciones basadas en escenarios: Habilite escenarios alternativos de autorización

entregados para las aplicaciones.

5.23.2 Encripcion de datos

Las soluciones SAP manejan conexiones encriptadas SSL para protocolos HTTP y conexiones SNC para

protocolos RFC y DIAG.

5.23.2.1 SSL y SNC

Seguridad de la capa de transporte para la comunicación con o entre sistemas SAP utilizando el protocolo

estándar de Internet Secure Sockets Layer (SSL) o la interfaz SAP para Secure Network Communications

(SNC), dependiendo de los protocolos subyacentes utilizados

Protocolo Método de seguridad utilizado Comentario

Internet protocols

(For example, HTTP, P4, LDAP)

SSL SSL es un protocolo cuasi

estándar desarrollado por

Netscape. Se usa con un

protocolo de aplicación, por

ejemplo, HTTP.

SAP protocols: dialog and RFC SNC SNC es una interfaz de SAP que

puede usar para proteger las

conexiones entre los

componentes del sistema SAP.

275

5.23.2.1.1 Protección provista

Tanto SSL como SNC proporcionan la siguiente protección:

• Autenticación: Los socios de comunicación pueden ser autenticados. Con SSL, puede configurar las

conexiones para que solo se autentique el componente del servidor para la conexión o para que

ambos socios estén autenticados. Con SNC, ambos socios siempre se autentican

• Integridad de datos: Los datos que se transfieren entre el cliente y el servidor están protegidos para

detectar cualquier manipulación de los datos.

• Privacidad de datos: Los datos que se transfieren entre el cliente y el servidor también están

encriptados, lo que brinda protección de privacidad. Un espía no puede acceder a los datos.

5.23.2.1.2 Productos de seguridad externa para SNC

SNC es una capa de software en la arquitectura del sistema SAP que proporciona una interfaz para un

producto de seguridad externo. La interfaz utilizada para la integración es GSS-API V2 (Generic Security

Services Application Programming Interface Version 2).

Tenemos un producto de seguridad predeterminado disponible, la Biblioteca de criptografía SAP. Sin

embargo, debido a las regulaciones de exportación, no entregamos esta biblioteca con el sistema SAP. Está

disponible para descarga para clientes autorizados en SAP Service Marketplace en

http://service.sap.com/download.

Esta biblioteca también solo está disponible para su uso entre los componentes del servidor. Para usar SNC

con los componentes del cliente, por ejemplo, la GUI de SAP para Windows, debe comprar un producto de

seguridad que haya sido certificado por el Programa de Socios de Software de SAP. Para obtener más

información, consulte http://www.sap.com/softwarepartner (interfaz de SNC).

5.24 Controles de Acceso

Las soluciones SAP permiten configurar reglas de autenticación tales como longitud mínima de contraseñas,

complejidad requerida, tiempo de vencimiento, tiempo máximo de inactividad, entre otros.

5.24.1 Parámetros de perfil para inicio de sesión y contraseña ( Parámetros de inicio de sesión )

Los parámetros de perfil s para establecer las reglas de contraseña e inicio de sesión .

276

Estos parámetros de perfil se definen los requisitos mínimos para las contraseñas. No puede establecer

límites superiores para las reglas de contraseña, excepto las contraseñas generadas. Por ejemplo, los usuarios

pueden usar cualquier número de caracteres especiales en sus contraseñas, siempre que sigan las otras

reglas de contraseña.

Los parámetros de perfil s reemplazados por políticas de seguridad se muestran en la última tabla. Puede

continuar utilizando estos parámetros en lugar de las políticas de seguridad. Sin embargo, en este caso, no

puede controlar el comportamiento del sistema según el usuario.

5.24.2 Inicio de sesión del sistema

Al crear aplicaciones web utilizando Web Dynpro para ABAP o Business Server Pages ( BSP ), se puede definir

pantallas de inicio de sesión para que los usuarios finales inicien sesión en su sistema. En aras de la

simplicidad, se puede utilizar una pantalla de inicio de sesión que es similar a la pantalla de inicio de sesión

clásica, donde debe ingresar el cliente, nombre de usuario, contraseña e idioma. Sin mucha programación,

puede definir qué campos deberían estar disponibles, qué ayuda adicional debería ofrecerse y cómo debería

diseñarse la pantalla de inicio de sesión para sus aplicaciones web.

Activar y configurar el inicio de sesión del sistema en Internet Communication Framework ( ICF ) utilizando

los nodos de servicio respectivos para la aplicación.

Además de estas configuraciones, también se puede realizar cambios específicos del usuario utilizando una

clase desarrollada por separado.

277

Si se producen problemas durante el proceso de inicio de sesión, el sistema genera varios mensajes de error

o advertencias según la causa. Además de los errores que se refieren al estado de los datos del usuario y los

errores de entrada durante el inicio de sesión, los problemas en la configuración del servidor o del cliente

también pueden significar que el inicio de sesión no se puede realizar correctamente. Puede encontrar estos

mensajes de error y sus textos largos sobre cómo resolver los errores en el sistema en la clase de mensaje

ICF_SYSTEM_LOGIN.

Caracteristicas

• Las siguientes funciones son compatibles con la aplicación de inicio de sesión:

• Cambio de inicio de sesión y contraseña

• Configuración del diseño y el proceso utilizando el servicio ICF

• Registro del alternar a HTTPS para transferir los datos del usuario de forma segura

• Varios diseños implementados y categorías seleccionables de hojas de estilo

• Soporte de SSO2

• Cambio de contraseñas para la autenticación básica

• Personalización para el proceso y el proceso de inicio de sesión

• Soporte de accesibilidad

• Visualización del mensaje del sistema

• Verificar sesiones de usuario existentes durante el inicio de sesión

• Inicio de sesión con certificados X.509

5.24.3 Integracion entre Active Directory y SAP

Active Directory (AD) permite a las organizaciones administrar y compartir de forma centralizada información

sobre los recursos de red y los usuarios. Active Directory también actúa como punto de integración para unir

sistemas y aplicaciones, como SAP y AD.

La integración de SAP con Active Directory permite a los clientes aprovechar los beneficios clave de

administración de identidades discutidos en la sección anterior.

278

• Tareas de gestión simplificadas

• Fortalecimiento de la seguridad de la red

• Costos de administración reducidos

El sistema SAP puede usar la función de "publicación de servicio" de Active Directory para detectar sistemas

SAP y sus servicios, como servidores de aplicaciones, servidores de mensajes, base de datos, servicio de

puerta de enlace y instancias de SAP Internet Transaction Server (ITS).

Esto permite ver y acceder a la información de toda la empresa sobre los sistemas instalados desde una

ubicación central sin tener que configurar manualmente los archivos en cada servidor o estación de trabajo

individual. El complemento SAP Microsoft Management Console (MMC) es el primer componente que usa

información proporcionada por Active Directory. Además de proporcionar una vista central de todos los

sistemas SAP en su entorno, el complemento MMC proporciona interfaces para supervisar, detener e iniciar

los sistemas SAP.

SAPGUI para Windows también usa Active Directory para obtener una lista de sistemas SAP. Esto elimina la

necesidad de administradores y usuarios finales de administrar manualmente los archivos específicos de SAP

como SAPLogon.ini en cada estación de trabajo individual.

Al utilizar la función de directiva de grupo de Active Directory, los administradores pueden actualizar e

implementar SAPGUI y otras aplicaciones de SAP en los escritorios de los usuarios automáticamente. Para

las organizaciones que desean utilizar el inicio de sesión único con SAPGUI, SAP proporciona un paquete MSI

especial. Este paquete se puede implementar automáticamente a todos los usuarios relevantes mediante el

uso de la Política de grupo.

La Administración de usuarios de SAP Central (servidor de aplicaciones web) admite la sincronización con

Active Directory, lo que permite la administración sencilla de las identidades en su organización.

5.24.4 SAP Single Sign-On

La aplicación SAP® Single Sign-On le ofrece una herramienta para acceder a todas las computadoras con una

contraseña. Protegeusuarios y empresas de muchos ciberseguridad con el uso de virus inteligentes, de dos

factores y con certificación basada en el riesgo, firmas digitales y encriptación de canales de comunicación.

Esoagrega funcionalidad vital de seguridad a su SAP y paisajes de software no SAP y ha hecho SAP Single Sign-

On una mejor práctica de seguridad solución a través de industrias y regiones.

Inicio de sesión de usuario único para un acceso seguro a todos software que necesita usuario para todo el

día en todas las empresas, dominios y dispositivos:

279

• Adaptación dinámica de los requisitos de autenticación en el riesgo, incluido el soporte para las

funciones de autenticación

• Funciones criptográficas certificadas por computadora estándar de seguridad FIPS 140-2, incluida la

integración con módulos de seguridad de hardware

• Soporte de firma digital.

SAP Single Sign On es un producto de seguridad de SAP que permite a los usuarios tener acceso seguro a

aplicaciones SAP y no SAP con una sola contraseña. Su objetivo es mejorar la seguridad y la eficiencia de la

empresa al proporcionar acceso a las aplicaciones en todos los sistemas.

SAP Single Sign On proporciona beneficios en seguridad, reducción de costos y eficiencia de TI, según SAP.

Fortalece la seguridad de la empresa mediante el uso de tecnologías avanzadas de autenticación y cifrado, y

porque todas las contraseñas se guardan en un depósito central y protegido. Los costos se pueden reducir al

limitar la cantidad de llamadas relacionadas con la contraseña que deben atender los escritorios, y al

minimizar la autenticación manual y el restablecimiento de contraseñas. La eficiencia de TI se puede mejorar

porque no hay necesidad de aprovisionar, proteger o restablecer contraseñas o administrar políticas de

contraseñas en diferentes sistemas.

SAP Single Sign On funciona tanto para aplicaciones SAP como para aplicaciones que no son de SAP, según el

proveedor

Las características específicas de seguridad de inicio de sesión único de SAP incluyen:

• Integración con implementaciones de infraestructura de clave pública (PKI) existentes, lo que

permite el uso de una PKI individual si ya hay una en la empresa;

• Gestión automatizada del ciclo de vida de los certificados para SAP NetWeaver Application Server

para ABAP, que puede reducir los esfuerzos manuales de renovación de certificados, evitar el tiempo

de inactividad y limitar el error humano en la renovación de certificados;

• Secure Login Server que permite varias formas de aprovisionar certificados X.509 para dispositivos

móviles;

• Un modo de solo cifrado que habilita el cifrado de red para el protocolo SNC que se comunica con

otros sistemas SAP incluso cuando los tokens de seguridad específicos del usuario no están

disponibles o no están configurados;

• Un cliente web de inicio de sesión seguro que permite que los procesos comerciales se ejecuten en

una sesión del navegador, ya sea en las instalaciones o en la nube; y

280

• Compatibilidad con Perfect Forward Secrecy para comunicaciones de SNC, que reduce el riesgo de

claves comprometidas que permiten a los atacantes desencriptar datos de sesión grabados

previamente.

• SAP Single Sign On está disponible con licencia y se puede descargar desde el Portal de soporte SAP.

281

6. OTRAS CONSIDERACIONES DE IMPLEMENTACION Y TIEMPO

6.1 Metodología de Implementación SAP ACTIVATE

SAP Activate es el marco de adopción de la innovación que acelera las implementaciones SAP S/4HANA a lo largo del ciclo de vida del cliente. Ofrece listo para ejecutar procesos de negocio y tecnología, guías de configuración y la metodología de próxima generación.

Se alcanzara una implementación rápida y de coste

eficiente adoptando una solución SAP innovadora

con UNA metodología simple, modular y ágil.

• Conducir una entrega de valor al cliente y de reducir el TCO

• Amplia cobertura de soluciones SAP a partir de S4HANA.

• Soporte completo para la implementación inicial y la innovación empresarial en curso.

• Modular, flexible y ágil para escalar en futuros enfoques de negocio.

• Permite la co-innovacion con los partners de negocio.

• Sucesora de la metodología ASAP

La metodología de SAP ACTIVATE para on-premise está diseñada para apoyar a los equipos de proyecto en la nueva implementación de soluciones SAP. Se puede utilizar independiente o como parte de un compromiso Premium. La metodología se estructura en las fases del proyecto, conteniendo cada uno una lista de entregables y tareas de apoyo. A lo largo del proyecto los diferentes niveles de usuarios encontrarán aceleradores como plantillas y ejemplos para apoyar su proyecto de implementación (por ejemplo Guía de Trabajo de Análisis de la adecuación / o ALM - Procesos Solution Manager). La metodología de SAP ACTIVATE ofrece los siguientes beneficios:

• Permite consistencia, reduce la complejidad y aumenta la calidad mediante la creación y prestación de servicios en una plataforma común.

• Es escalable - el apoyo a todos los tipos de servicios de entrega de los despliegues RDS / A2O a grandes soluciones de prototipos.

• Es preceptivo e integral - que ofrece procedimientos de trabajo guiados para los equipos de proyecto, entregables para los gerentes de proyectos y aceleradores para todos los usuarios.

282

• Se ofrece innovación a través del enfoque en la implementación de Agile, visualización de Aplicación y uso de los enfoques de implementación basados en la nube. Al mismo tiempo que se está aprovechando las mejores prácticas para los entregables de proyectos como Puntos de Control de Calidad de Proyectos.

Utilización de BEST PRACTICE en SAP ACTIVATE

SAP ACTIVATE comienza con un paquete de SAP Best Practices para cualquier aplicación y utiliza la misma

metodología para cualquier modo de implementación - nube, híbrido, on-premise o móvil. SAP Best

Practices cubre los fundamentos de la integración y la migración de SAP S/4Hana e incluye su propia solución

de referencia en la nube. SAP Best Practices le permite tomar ventaja de todo el poder y potencial disponible

con SAP S/4Hana pero adaptado a sus circunstancias y necesidades de negocio.

SAP Best Practices cubre una amplia gama de industrias, líneas de negocio, y la funcionalidad.

ON-PREMISE EDITION para <CLIENTE> con SAP BEST PRACTICES FOR SAP S/4HANA

Esta edición del paquete SAP Best Practices para SAP S/4HANA ayuda a tomar el control de su infraestructura

y el mantenimiento planificado para su instalación on-premise de SAP S/4HANA.

Puede adoptar innovaciones y realizar cambios en su sistema a su propio ritmo y en una forma que se adapte

a las necesidades de su organización. Este enfoque se adapta a los requerimientos altamente

individualizados para los procesos en el núcleo de su negocio. Además de añadir la lógica de negocio,

también se pueden realizar cambios en los procesos subyacentes.

283

La metodología SAP ACTIVATE es un marco modular y ágil para la implementación o migración a SAP

S/4HANA. Se construye sobre sus predecesor: la metodología ASAP.

Debido a que la metodología es compatible con el uso de complementos y extensiones desarrolladas por los

socios de SAP, se obtiene una experiencia coherente, integrada incluso si está personalizando SAP S/4HANA

para los procesos de negocio específicos.

Con la metodología, se puede tomar un enfoque de gestión de proyectos disciplinado para sus proyectos de

implementación, migración y cambio. La metodología se alinea con las mejores prácticas recomendados por

el Project Management Institute (PMI), lo que ayuda a minimizar el riesgo, optimizar y acelerar su proyecto

de implementación y reducir el costo total de implementación.

Una estructura de división del trabajo estandarizado ayuda a los administradores de proyectos definir y

gestionar el trabajo del proyecto y se centran en las prestaciones y resultados

La metodología es compatible con las cuatro fases de su implementación: preparación, exploración,

realización, y desplegar (deploy), como se muestra en la siguiente figura. La entrega de valor y puntos de

control de calidad ayudan a asegurar que la solución, tal como se aplica, proporciona el valor que Ud. espera.

He aquí un resumen de las principales actividades del equipo de proyecto realiza en cada fase de la

metodología: He aquí un resumen de las principales actividades del equipo de proyecto que realiza en cada

fase de la metodología:

284

FASE 1: PREPARE – PREPARACIÓN

Esta fase proporciona la planificación inicial y la preparación para el proyecto, incluyendo la organización del proyecto y el gobierno, así como el calendario, gestión y presupuesto. Aunque cada proyecto tiene sus propios objetivos, alcance y prioridades únicos, los entregables descritos anteriormente ayudan a completar los pasos de iniciación y planificación de una manera eficiente y efectiva.

Como parte de la fase de preparación, el equipo del proyecto será preparado para su entrenamiento y el equipo de infraestructura para soportar el proyecto será constituido

Con base en el alcance del proyecto, el equipo de implementación configurara la solución estándar de SAP para satisfacer las necesidades de los clientes. En los proyectos S/4HANA se aprovecha los servicios de pre-ensamblados o se pueden activar las Buenas Prácticas, RDS u otro paquete (s) que cubra el alcance del proyecto

Entregables Claves:

• Organización del proyecto y de Gobierno

El propósito de esta entregable es asegurar que en un marco de gestión eficiente está ubicado la ejecución del proyecto exitoso. El director de proyecto junto con PMO define la organización del proyecto, estructura de gobierno, incluidas las funciones y responsabilidades. El gobierno está totalmente alineado con el enfoque de la entrega de proyectos ágiles.

Aceleradores:

✓ Agile Implementation Methodology Overview ✓ Kickoff Meeting Template ✓ Project Organization Roles and Responsibilities ✓ Project Quality Gate ✓ Opportunity to Delivery Handover Checklist (SAP Internal) ✓ Project Status Report

• Calendario de Proyecto, Presupuesto y Planes de Gestión Definir el plan de trabajo a seguir, los recursos y compromisos de tiempo asociados necesarios para el proyecto y sus fases. Incluir los procesos que intervienen en la estimación, presupuesto y control de los

285

costes asociados. La información debe ser compilado utilizando un marco común para coordinar todos los esfuerzos de planificación (tiempo, costo, calidad, riesgo, grupos de interés, etc.)

Aceleradores: ✓ Kickoff Meeting Template ✓ Project Management Plan ✓ Agile Release Planning

• Normas y Políticas de proyectos El propósito de este entregable es proporcionar medios consistentes de ejecución y que regula el trabajo del proyecto de una manera eficiente y eficaz. El objetivo clave de normas del proyecto es identificar, definir, aprobar y comunicar las normas relacionadas con la ejecución del proyecto. Donde y cuando sea aplicable, los procesos y procedimientos actuales de los clientes, relacionadas con las normas del proyecto deben tenerse en cuenta a la hora de definir los estándares más adecuados para el proyecto.

Aceleradores: ✓ ALM - Solution Manager Processes

Agile Projects only: ✓ Agile Sprint Burndown & Task Board Sample ✓ Agile Definition of Ready and Done

• Definir OCM Roadmap y la Estrategia de Formación El propósito de esta entrega es identificar las principales stakeholders. Definición del enfoque de la gestión del cambio, road map y el enfoque de la clave de usuario y la formación de los usuarios finales.

Aceleradores:

✓ OCM Overview Guide ✓ OCM Roadmap Presentation Sample

Formación equipo de proyecto

El propósito de esta entrega es llevar a cabo la formación del equipo de proyecto sobre el enfoque de implementación de SAP Active incluyendo temas como el Fit / Gap Analysis, Agile Project Delivery y testing, el uso de mejores prácticas de SAP, y otros. Durante esta entrega el equipo también aprenderá sobre las normas y políticas del proyecto.

Aceleradores:

✓ Agile Implementation Methodology Overview ✓ SAP Activate Training (ACT100 course)

286

• Equipo Proyecto de Infraestructura El propósito de este entregable es establecer las herramientas básicas y procesos necesarios para soportar el proyecto. Una de las herramientas más importantes del proyecto es la Solution Manager de SAP, la pieza central de las herramientas de gestión del ciclo de vida de aplicaciones de SAP.

Aceleradores:

✓ SAP Solution Manager ✓ SAP Support Portal ✓ Project Logistic and Infrastructure Template

• Alcance de Solución y Determinación del valor El propósito de este entregable es definir el alcance de la solución, el diseño de soluciones de alto nivel puede ser incluido en esta entregable también. Validar las prioridades del negocio, Value Driver y beneficios esperados. Comparar valor a los escenarios y procesos de negocio. Incluir el alcance de las interfaces y las extensiones aquí también - todos los objetos RICEFW se pueden agrupar bajo este entregable.

Aceleradores:

✓ Project Scope Statement Template ✓ Design Thinking Sessions: Requirements Analysis and Process Design

• Requisitos de la infraestructura técnica y dimensionamiento El propósito de esta entregable es determinar la arquitectura técnica y los principios guiados para el aspecto de la integración, por ejemplo, a través de todas las interfaces PI. Acordar sobre la DB, sistema operativo, configuración de seguridad, la tecnología de interfaz de usuario y el dimensionamiento de la infraestructura del sistema. Aceleradores:

✓ System Landscape ✓ Design Thinking for IT Architecture Design ✓ Technical Requirements and Infrastructure Template ✓ Sizing SAP Solutions

• Estrategia y enfoque inicial de migración de datos. El propósito de esta entregable es evaluar el estado actual ("limpieza") de datos transaccionales y maestro de datos. Determinar los elementos de datos, estrategia de migración, archivado. Determinar la fuente y la arquitectura objetivo.

Aceleradores:

287

✓ Data Migration Strategy and Approach ✓ Data Audit Results Template

• Ambiente Sandbox El propósito de este entregable es configurar el sistema sandbox con todas las capacidades que son entregados por cualquier Best practice, empresa modelo o paquete (s) RDS. Una vez que el sandbox está configurado, el equipo del proyecto preparara los talleres de GAP analysis. Esto normalmente incluye las adaptaciones de la estructura organizacional, los cambios en los datos maestros y la configuración potencial de la funcionalidad adicional que es fundamental para ser incluidos en el análisis de ajuste / brecha.

Aceleradores: ✓ Implement SAP S/4HANA on-premise with SAP Best Practices ✓ Cloud Appliance Library ✓ Pre-Assembly Request

FASE 2: EXPLORE – EXPLORACION

El propósito de esta fase es realizar un análisis de gap/fit para validar la funcionalidad de la solución incluida en el alcance del proyecto y para confirmar que los requisitos de negocio pueden ser satisfechas. Brechas identificadas y los valores de configuración se agregan al backlog para su uso en la siguiente fase.

Por lo general, el equipo del proyecto lleva a cabo los talleres de análisis de gap/fit consistentes en la validación de la solución (WSA) y el diseño delta (WSB) Actividades para capturar los requisitos, las brechas y la solución de Delta. Con esto, el equipo del proyecto puede entender mejor cómo la compañía tiene la intención de ejercer su actividad dentro del sistema de software de SAP.

Las necesidades del cliente se abordaran mediante las mejores prácticas o Empresa Modelo

Trabajar con el sistema sandbox ya sea sobre la base del aparato CAL o como la solución pre-ensamblada (construido en la fase de preparación), el equipo lleva a cabo los talleres de análisis de gap/fit (que consta de validación de la solución Taller (WSA) y Delta Taller de Diseño ( WSB). En caso de brechas o requisitos delta se identifiquen, el equipo de los captura en el backlog. Estas brechas deben ser priorizadas a los efectos de la liberación y de velocidad antes de que se complete la fase de requisitos.

288

Actividades Exploración: • Preparar talleres de validación, configuración y solución. • Redefinir los requisitos de negocio • Identificar los datos maestros y los requisitos de organización • Confirmar los procesos de negocio • Definir el diseño de soluciones funcionales, incluyendo un análisis de las brechas en los talleres de diseño

de soluciones • Asociar requisitos de negocio a la jerarquía de procesos y los componentes de la solución • Obtener los sign-off de negocio sobre los requisitos y documentación de diseño delta • Recopilar información del usuario final, el análisis de las necesidades de aprendizaje y el desarrollo de una

estrategia de despliegue de aprendizaje • Establecer gestión de proyectos, seguimiento y presentación de informes para la entrega de valor

Entregables Claves:

• La Ejecución de la Gestión de Proyecto, Control de Gestión y Resultados

El propósito de este entregable es cubrir todas las actividades de gestión de proyectos, especialmente el manejo de cambios, riesgos, problemas y calidad. Así como informar del progreso del proyecto.

Aceleradores:

✓ Agile Scrum Meeting Guidelines

© 2014 SAP SE or an SAP affiliate company. All rights reserved. 14

Validate Solution instead of Blueprinting

1. Reference Value

� Provide process, value and strategic context

� Set boundaries

� Tie to Business Case, Value Drivers

2. Validation of SAP Solution

� Show and tell SAP standard key design elements

3. Identify Deltas & Gaps

� Identify delta scope and requirements

� Document gaps

5. Delta Design

� Update Business Models and Process Design

� Solution Design and Visualization / UX

6. Verify & Accept

� Verify process & solution design

� Design Acceptance

4. Delta Scope Prioritization

Workshop A

Solution Validation

Workshop B

Delta Design7. Release &

Sprint Planning

289

✓ Project Management Plan

✓ Change Request Log Template

✓ Project Quality Gate Template

• Análisis del Impacto de cambio y Plan de Comunicación

El propósito de este entregable es analizar el impacto de los cambios provocados por la aplicación y preparar el plan para la comunicación y la gestión de estos cambios.

Aceleradores:

✓ Change Impact Analysis

✓ OCM Plan Guide

✓ OCM Roadmap

• Construir la línea de base

El propósito de esta entregable es afinar el sistema sandbox para los talleres de análisis de ajuste/GAP. El equipo del proyecto, junto con los principales usuarios de negocio determinará qué historias de usuario será implementado en el sistema antes de los talleres de ajuste / gap y que serán visualizados. El proceso de decisión se basa en las necesidades del cliente, la comprensión de la solución, y la complejidad de la configuración y la disponibilidad de herramientas de visualización adecuados. El resultado de este producto clave es un sistema de trabajo con la funcionalidad que se utilizará para los talleres de análisis de FIT/GAP.

Aceleradores:

✓ Implement S/4HANA on-premise with SAP Best Practices

✓ Scenario Design Document

✓ Backlog Document Template

• Los talleres de validación incluyendo Gap Validación

El propósito de este entregable, también identificado como el Taller A (WSA), es validar los escenarios predefinidos, procesos y mejoras; identificar las posibles diferencias entre los requisitos del producto y del cliente. El entregable sólo captura los requisitos de las brechas. De ello se sigue un enfoque iterativo. Documentación y modelos existentes pueden ser alterados, los cambios tienen que ser marcados y documentados en SAP Solution Manager.

Aceleradores:

✓ Fit/Gap Analysis Workshops How-To Document

✓ Backlog Document Template

290

• Priorización backlog

El propósito de este entregable es dar prioridad a los elementos que están dentro del alcance de la implementación actual y calificar para el diseño delta.

Aceleradores:

✓ Backlog Template DocumentDiseño de las Brechas y Deltas

El propósito de este entregable es diseñar, identificado como taller (WSB), en detalle, la solución TO-BE para esos escenarios de negocios / procesos en los que la solución estándar SAP no puede cumplir cualquiera de las necesidades del cliente (BPA) o nuevos modelos de negocio (Referencias de clientes)

Aceleradores:

✓ Fit/Gap Analysis Workshop Guide

✓ Delta Design Templates

✓ RICEFW Templates

• El legado de migración de datos Diseño y Plan

El propósito de este entregable es el desarrollo de los diseños, planes y procedimientos para apoyar la migración de datos heredados durante la aplicación de la solución SAP, incluyendo los requisitos de calidad y seguridad.

Aceleradores:

✓ Data Definition Object Template

✓ Data Definition Job Aid

✓ Rapid Data Migration to SAP S/4HANA

• Diseño de Tecnología y Configuración del Ambiente de Desarrollo

El propósito de este entregable es la instalación de un entorno viable, configurado correctamente que esté disponible para su uso por el equipo del proyecto para comenzar la fase de realización. Configuración de la infraestructura para ejecutar la fase Realización.

Aceleradores:

✓ SAP Solution Manager

✓ Technical Requirements Specification

✓ System Landscape Strategies

✓ PE: Innovation Control Center

291

• Estrategia y Plan de prueba

El propósito de este entregable es la creación del marco de pruebas relacionadas con el proyecto, incluyendo las directrices y metodología para la aceptación del usuario. Consolidar Metodología Agile para la validación de los Sprint durante la fase de realización.

Aceleradores:

✓ Testing Strategy and Approach Guide

✓ SAP Solution Manager

• Liberación y Plan de Sprint

El propósito de esta entrega es definir cómo el equipo prepara la priorización del backlog, define el plan de liberación (al menos 2 versiones de valor por año) y planea los primeros sprints.

Aceleradores:

✓ Agile Release Planning

✓ Project Quality Gate

Procedimiento:

292

FASE 3: REALIZE – REALIZACIÓN

El propósito de esta fase es el uso de una serie de iteraciones para construir de forma incremental y probar un entorno empresarial y el sistema integrado que se basa en los escenarios de negocios y requisitos del proceso identificados en la fase anterior. Durante esta fase se carga los datos, la activación de la adopción se produce, y se han previsto operaciones. Actividades Realización: • Establecer la infraestructura de soluciones • Implementar la solución en el entorno de desarrollo utilizando construcción incremental en iteraciones

time-boxed. • Llevar a cabo las pruebas en general de extremo a extremo de la solución en el entorno de QA calidad. • Configuración del entorno de producción • Preparación para la migración de datos y archivo de datos • Conducir Pruebas de rendimiento • Conducir Equipo de proyecto y formación de clave de usuario • Finalizar los materiales de formación de usuarios finales y documentación • Seguimiento e informar sobre la entrega de valor Durante esta fase, además se cumplen las siguientes actividades:

✓ Lograr la gestión del cambio organizacional y formación ✓ Los requisitos del proceso de negocio, diseño, configuración y pruebas, siguiendo el enfoque ágil

(Sprints): o plan de configuración y desarrollo o Construcción iterativa o Pruebas de las transacciones y funciones o Las pruebas de soporte a los procesos de negocio y escenarios

293

o Las pruebas de integración (resultados de pruebas aprobado de integración final y las pruebas de aceptación del usuario).

o Establecer roles y autorizaciones de los usuarios de toda la empresa. o Desarrollo (especificaciones técnicas para RICEFW objetos de desarrollo, el desarrollo

RICEFW y desarrollo de contenidos y la integración) o Migración de datos o La gestión de contenidos y la interfaz de usuario o Definir la estrategia de corte y entrega de la solución

Entregables Claves:

• La ejecución de gestión del proyecto, Control de gestión y resultados El propósito de este entregable es cubrir todas las actividades de gestión de proyectos, especialmente el manejo de cambios, riesgos, problemas y calidad. Así como informar del progreso del proyecto.

Aceleradores: ✓ Agile Scrum Meeting Guidelines ✓ Change Request Log Template ✓ Project Quality Gate Template

• La alineación de la organización y habilitación de usuario Los propósitos de este entregable son:

• Asegurar el proceso de transición hacia la nueva forma de trabajar. Esto incluye la alineación de los roles y responsabilidades y actividades para asegurar que todos los empleados están completamente alineados con los objetivos del proyecto y de la organización.

• Asegurar la disponibilidad de material de formación del usuario final, entorno de formación, infraestructura logística y de instructores calificados.

294

Aceleradores: ✓ OCM Role Mapping Template ✓ Change Impact Analysis Guide

• Configuración de la tecnología de QAS y PRD, pasando de Seguridad y Autorizaciones El propósito de esta entrega es instalar entornos técnicos viables, configurados correctamente para realizar control de calidad de pruebas (QAS) y para apoyar las operaciones productivas de la solución entregada (PRD).

Aceleradores: ✓ Environment Specifications Sample ✓ PE: Innovation Control Center ✓ PE: Operations Control Center

• Ejecución de Sprint El propósito de este entregable es asegurar que la configuración asociada con las brechas de solución sea implementada, probada y documentada. Este proceso va a seguir el enfoque ágil de la construcción de la solución en incrementos con puntos de inspección frecuentes que aumentan la visibilidad de los avances de construcción, y ayudan a conseguir la aceptación de las soluciones anteriormente.

Aceleradores: ✓ Agile Sprint Elements ✓ Agile SCRUM Meeting Guidelines

• Solución integrada y pruebas de aceptación de usuario Ejecutar la estrategia de evaluación en las siguientes áreas:

✓ Pruebas de Integración, para asegurar el correcto funcionamiento. Se prueba la integración de las soluciones de SAP con aplicaciones que no son SAP y las interfaces y se puede ejecutar de forma iterativa.

✓ Prueba de rendimiento, para asegurar que las solicitudes cumplen los objetivos de rendimiento establecidos durante el proyecto.

✓ Prueba de aceptación del usuario (UAT). Este es el último ciclo de pruebas de una implementación de soluciones de SAP y es una parte esencial de lograr la aceptación de los usuarios finales del sistema de software.

Aceleradores:

✓ Testing Strategy and Approach Guide ✓ Performance Tests Template ✓ Testing Strategy Guide ✓ ICC and IV Framework in SAP Activate

295

• Migración de datos de legado El propósito de este entregable de migración de datos legados es desarrollar, implementar y probar los programas de migración de datos y los procesos definidos en la fase de solución de validación. En caso de que se acaben las herramientas para la migración automática o el volumen de datos no justifica el desarrollo de cualquier herramienta, el Equipo de Servicio y Mantenimiento desarrollará el enfoque de llevar manualmente los datos heredados en la base de datos de SAP.

Aceleradores: ✓ Data Migration Tests Results ✓ Rapid Data Migration to SAP S/4HANA

• Las auditorías de valor El propósito de la auditoría de valor durante la fase de realización es supervisar y controlar la aplicación de cambios en los procesos clave y facilitadores de valor, así como asegurar el diseño y la implementación del Value Dashboard con fines de seguimiento de KPI.

Aceleradores: ✓ Value Audit Guide

• Cutover y Plan de Transición El propósito de este entregable es definir y documentar la estrategia, el alcance y líneas de tiempo para pasar de la solución As-Is a la solución To-Be y el período de atención de soporte inmediatamente después de la entrada en vivo.

Aceleradores:

296

✓ Cutover Strategy ✓ Cutover Planning Templates

FASE 4: DEPLOY – DESPLIEGUE

El propósito de la fase de despliegue es finalizar la preparación de la solución y sus herramientas de soporte

y procesos para la salida en vivo. Esto incluye, pero no solo se limita a: las pruebas del sistema, formación

del usuario final, la gestión del sistema, y las actividades de cutover (incluyendo la migración de datos y

soporte inicial posterior al cutover).

Al iniciar fase de despliegue, el equipo del proyecto ya ha confirmado (a través de las pruebas de integración

en la fase Realización) que todos los sistemas están funcionando correctamente y no hay problemas de

integración que quedan por resolver. De esta manera el equipo se prepara para la transición a las

operaciones productivas de negocios en el nuevo entorno, se conecta la nueva solución y lleva a cabo la

adopción solución y post actividades de apoyo a la entrada en productivo.

Actividades Deploy: • Finalizar la solución, sus herramientas y procesos para la entrada de producción:

- Resolver todos los issues cruciales abiertas - Conducir pruebas de sistema - Comprobar que la gestión del sistema está en su lugar - Llevar a cabo actividades cutover, incluyendo la migración de datos

• Ejecutar los planes de transición y cutover incluyendo planes de gestión del cambio organizacional (OCM) • Completar toda la formación del usuario final • Identificar y documentar todos los problemas encontrados en la transición a la nueva solución • Monitorear los resultados de los procesos de negocio y el entorno de producción • Seguimiento e informar sobre la entrega de valor

Entregables Claves:

• La ejecución de la tarde, Control de gestión y resultados El propósito de este entregable es cubrir todas las actividades de gestión de proyectos, especialmente el manejo de cambios, riesgos, problemas y calidad. Así como informar del progreso del proyecto.

Aceleradores: ✓ Agile Scrum Meeting Guidelines ✓ Change Request Log Template ✓ Project Quality Gate Template

✓ Comunicar el estado y el progreso de los participantes del proyecto: para asegurarse de que

cada contrato se cierra mediante la verificación de que todo el trabajo especificado en el acuerdo contractual se completó, y que todos los entregables definidos fueron aceptados.

297

• Comprobación de disponibilidad Organizativa y de Soporte Productivo El propósito de este entregable es tomar el pulso de la organización, antes de la entrada en productivo, para determinar el nivel general de comodidad con los próximos cambios. Si el nivel de confort no está presente, es fundamental determinar dónde debe centrarse el trabajo OCM adicional. Además, la verificación de disponibilidad de soporte productivo es asegurar que los recursos y los procesos están en su lugar para apoyar la solución después del cutover.

Aceleradores: ✓ OCM Road Show Concept

• Entregable de Pre-productivo para la capacitación de usuario final El propósito de este entregable es proporcionar una lista que resume los servicios de formación del usuario final y garantizar la preparación para la adopción de la solución. En la lista de verificación, los elementos que rigen la prestación de formación, las comunicaciones y la planificación futura aclaran la situación de todos los aspectos de la iniciativa de capacitación.

Aceleradores: ✓ Training Schedule and Logistics Sample

Procedimiento: • Pruebas Técnicas y de Sistema El propósito de la de planificación de la prueba técnica y sistema es comprobar todo el sistema, que sea consistente entre bases de datos, servidores de aplicaciones, interfaces, impresoras, etc. Las pruebas técnicas y de sistema están diseñados para asegurar que los componentes técnicos como infraestructura tecnología, impresoras, dispositivos auxiliares, etc. funcionan con el softwate antes de cutover al sistema de producción.

Aceleradores: ✓ Testing Strategy and Approach Guide ✓ ICC and IV Framework in SAP Activate

• Cutover a Producción El propósito de este entregable es llevar a cabo cutover a producción de software y salir en vivo. En este punto, la organización, los negocios, y los aspectos funcionales y técnicos del sistema del proyecto están listos para ser utilizados en la producción. Aceleradores:

✓ Cutover Plan Documents ✓ Data Migration Strategy

298

• Soporte Productivo después de Go Live El propósito de este entregable es la confirmación de que los recursos y los procesos están en su lugar para apoyar la solución en curso y para completar los pasos necesarios para cerrar el proyecto y terminar la documentación. Aceleradores:

✓ Open Issues List Templates FASE 5: RUN – PUESTA EN MARCHA

La fase de puesta en marcha mantiene el sistema disponible en los altos niveles requeridos para apoyar las operaciones de negocio. Durante la implementación del sistema, el equipo del proyecto pone en marcha un conjunto inicial de operaciones en funcionamiento de SAP. Ahora en la fase Run, el sistema en vivo se evalúa para identificar oportunidades para optimizar aún más el sistema mediante la aplicación de operaciones adicionales.

Actividades Run: • Ejecutar la solución SAP implementada • Evaluar las operaciones estándar para optimizar el funcionamiento de la solución • Establecer las normas para el uso de herramientas • Transición del sistema optimizado para la producción • Continuar con el seguimiento y presentación de informes de valor Entregables Claves:

• Gestión del Ciclo de Vida El propósito de este entregable es proporcionar procesos, herramientas, mejores prácticas y servicios para gestionar las soluciones de SAP y no SAP en todo el ciclo de vida de la aplicación completa a lo largo de la Biblioteca de Infraestructura de TI (ITIL).

Aceleradores: ✓ ALM - Solution Manager

• Gestión del valor El propósito de este entregable es establecer los mecanismos sostenibles para el seguimiento y controla los predefinidos KPI y PPI de la solución durante la fase de Run.

299

6.2 Aceptación de Entregables Criterios de aceptación generales:

• El entregable cumple con las descripciones definidas en la Metodología de Implantación

• El entregable se ha ejecutado de acuerdo a los lineamientos en la metodología Adicionalmente proponemos las siguientes reglas generales para la gestión de entregables:

▪ GBM presentará un (1) borrador impreso del Material Entregable al Gerente del Proyecto de MHRD. Es responsabilidad del Gerente del Proyecto de MHRD realizar y distribuir copias adicionales a otras personas que así lo requieran.

▪ Dentro de los cinco (5) días hábiles a partir de la recepción, el Gerente del Proyecto de MHRDaceptará el Material Entregable o proveerá al Gerente del Proyecto GBM CONSULTING una lista por escrito de las observaciones solicitadas.

▪ Si GBM no recibe respuesta del Gerente del Proyecto de MHRD dentro de los cinco (5) días

hábiles, se considerará que el Material Entregable ha sido aceptado.

▪ El Gerente del Proyecto GBM considerará la oportuna solicitud de revisiones de MHRD, si las hubiere, dentro del contexto de las obligaciones de GBM según lo establecido en los criterios de aceptación anteriormente señalados.

▪ GBM en el caso de recibir la notificación de que el entregable no cumplió con los criterios de

aceptación establecidos en la propuesta; se harán las correcciones necesarias y volverá a enviar el entregable durante los 5 días hábiles siguientes, en cuya oportunidad dicho material se considerará aceptado.

▪ La aprobación de entregables sólo podrá tener dos ciclos de revisión y en el segundo ciclo tendrá

como alcance únicamente la revisión de las observaciones definidas en el primer ciclo.

▪ Las observaciones de MHRD a las que GBM no esté de acuerdo serán manejadas de acuerdo con lo descrito en la Sección de la Metodología de Administración de Proyecto.

▪ Cualquier conflicto que surja de este Procedimiento de Aceptación de Materiales Entregables

será tratado según lo especificado en el Procedimiento de Escalamiento. A continuación presentamos algunas precisiones y premisas generales referentes a la Administración de Entregables

300

Act Num

Rol Responsable Descripción de la Actividad Observaciones

1 PM Define y comunica estándares y lineamientos de cada entregable en relación con el contenido, template/layout y responsables de elaboración por cada entregable dependiendo del dominio y confirmará los atributos de calidad. El contenido en todo caso se apegará a lo indicado en la sección de Metodología de esta propuesta

La descripción del entregable cumplirá con lo definido en la Sección de Metodología de Implementación

2 Gerente del proyecto de MHRD y GBM

Define cronograma de entrega de cada entregable atendiendo los tiempos y milestones del plan de trabajo del proyecto

Este cronograma estará revisado y aprobado por la Gerencia de proyecto

3 PM Comunicará a los miembros del equipo los estándares de cada entregable así como el cronograma de entregas

La comunicación de los estándares u lineamientos será por grupo de trabajo dependiendo del dominio

4 Miembros del equipo de trabajo

(MHRD y GBM CONSULTING)

Elaboran los entregables de acuerdo a lineamientos y cronograma de entregas y envían al respectivo líder de equipo para su revisión

Los líderes de equipo de trabajo serán el líder de Procesos, Líder de Transformación Tecnológica, Líder de Administración del Cambio (Ver Secciones 5 y 6 Equipo de Proyecto)

5 Líder de Equipo de Trabajo

Valida que el entregable cumpla con el contenido técnico y en su caso regresa a la PMO

El Líder podrá revisar y en su caso ajustar el entregable con los responsables

6 PM Registra y valida que el entregable cumpla con los estándares y lineamientos definidos para cada entregable (Características y atributos de calidad)

7 PM Registra y valida que el entregable cumpla con los estándares y lineamientos definidos para cada caso (Características

Esta será una actividad reiterativa donde la revisión y ajustes tendrán

301

y atributos de calidad) y en su caso entregará a la PMO

lugar dependiendo de las desviaciones encontradas

8 PMO Natura

(Control de Calidad)

Revisa entregable y envía a aprobador respectivo

El Aprobador de cada entregable será definido en la etapa de Blue Print

9 Aprobador Revisa y aprueba el entregable y regresa a la PMO del proyecto

10 PMO y PM GBM CONSULTING

Registra el entregable y lo archiva para control

El PMO entrega acta de aprobación de entregable a PM de GBM CONSULTING

La herramienta de documentación será definida durante la fase de Preparación

6.3 Estándares y Procedimientos de Gestión de Proyecto

Esta sección propone establecer los estándares básicos y procedimientos del proyecto. Estos estándares

proporcionan información fundamental para ser referenciada a través de la implementación, para que todos

los miembros del proyecto puedan realizar sus tareas de manera efectiva.

6.3.1 Plan de Comunicación del Proyecto

En esta sección se describen los mecanismos y procedimientos para compartir información durante el

proyecto. Se incluyen en esta categoría:

• Planificación de Reuniones

• Agendas y Minutas

• Reportes de Estatus

• Procesos de Comunicación para personas fuera del equipo de proyecto

6.3.2 Planificación de Reuniones

Todos los miembros del equipo de proyecto deberán comprometerse a realizar las labores de proyecto

enmarcadas en las siguientes actividades:

• Asistir reuniones de estatus de proyecto

• Asumir las decisiones que sean tomadas

• Reportar el progreso de las acciones

302

Las invitaciones a reuniones deben realizarse por escrito y contener la siguiente información:

• Fecha, Hora y Lugar

• Lista de Participantes (o personas a quienes adicionalmente se desee informar)

• Temas de Discusión (Con responsables y tiempos estimados de duración)

• Duración de la reunión

6.3.3 Agenda de Reuniones y Minutas

Para reuniones de Comité Guía, se recomienda seguir los siguientes lineamientos con respecto al manejo de

la agenda y el seguimiento a través de las minutas:

• Aprobar la minuta previa a la Reunión (Convocatoria)

• Actualizar cualquier issue pendiente desde la última reunión

• Discutir el estatus del proyecto

• Discutir los resultados preliminares de cualquier tarea

• Presentar los issues abiertos

• Asignar los Issues abiertos a los miembros del equipo de proyecto

• Aprobar los resultados expuestos de la reunión en la minuta.

• Los Gerentes del proyecto deberán realizar la planificación de la agenda

• Para cualquier otro tipo de reunión, tales como workshops, cada consultor es responsable por la

agenda y planificación logística de la reunión.

6.3.4 Reporte de estatus

6.3.4.1 Informe de avance semanal del equipo de proyecto

Cada consultor debe completar y enviar la información del avance del proyecto de acuerdo las tareas que se

estén ejecutando y la fase del mismo. Se debe identificar inicio y fin de las actividades, porcentaje de avance,

etc.

Los posibles estatus de una actividad serán:

• Iniciada: 10%

• En progreso: 0-80%

• Por aprobar: 80%

• Finalizada: 100%

303

6.3.4.2 Actualización del Plan de trabajo

La información requerida para realizar la actualización del plan de trabajo será suministrada por los

miembros del equipo de proyecto. Esta actividad es ejecutada por los Gerentes del Proyecto.

6.3.4.3 Reporte Mensual del Estatus del Proyecto

El Reporte de Estatus del Proyecto representa el progreso, la distribución y el control del equipo de proyecto

cada mes o al finalizar cada fase del mismo.

Contiene reportes resumen, consolidados del plan de trabajo acerca del alcance y objetivos del proyecto,

cambios de alcance identificados y próximos pasos. Este informe o reporte ayuda a la Gerencia del Proyecto

a identificar las deficiencias, administrar recursos y mantener el proyecto al día.

6.3.5 Mecanismos de Comunicación a personas fuera del equipo del proyecto

6.3.5.1 Comunicaciones claves durante el proyecto

A. Comunicación de Kickoff del Proyecto

B. Pruebas del Sistema y Comunicación de Entrenamiento a Usuarios Finales

C. Comunicación de la Implementación del Sistema

D. Comunicación de Post-Implementación

6.3.6 Documentación del Proyecto

La documentación se constituye en el pilar fundamental del soporte del proyecto. En ella se reflejan todos

los hechos, decisiones, justificaciones y acuerdos que finalmente sustentan el producto final.

En esta sección, se establecen los estándares que deben seguir los documentos generados durante el

proyecto.

Los siguientes tipos de documentos son definidos:

• Procesos de Negocios

• Documentación de Usuario Final

• Configuración y Parametrizaciones SAP

• Documentos Generales de Proyecto

La Documentación del Proyecto será almacenada en la red con el siguiente. Todos los miembros del equipo

tendrán acceso de lectura/escritura a esta carpeta.

304

6.3.7 Mecanismos de Control de Temas Críticos (Issues)

Se considera un tema crítico o issue todo aquel pendiente de definición que pueda representar un conflicto,

problema o diferencia no conciliada que afecte en forma directa o indirecta el normal desenvolvimiento del

proyecto.

La administración de estos issues se hará de forma centralizada y utilizando para ello un repositorio común.

Los issues serán calificados de acuerdo con su criticidad teniendo como referencia el impacto que tengan

sobre el proyecto y deberán ser discutidos en las siguientes instancias:

1. Entre el equipo de funcional, durante las actividades diarias

2. Entre el Equipo del Proyecto, en la reunión de avance semanal

3. Entre el Comité Guía, en las reuniones a fin de cada fase.

Si algún issue es considerado de alto riesgo para el avance del proyecto, los Gerentes del Proyecto deberán

promover su solución en cualquier instancia que sea necesaria en el menor tiempo posible.

La solución de un ISSUE en condiciones normales debe tomar no más de 3 días hábiles y su documentación

y aprobación final será responsabilidad los usuarios y/o consultores.

6.3.8 Mecanismos de Cambio de Alcance

El control de los cambios al alcance es una de las tareas más críticas del proyecto y que mayor impacto tiene

en el éxito del mismo.

La falta de enfoque en los objetivos puede provocar la expansión del alcance del proyecto, por ello es

sumamente importante definir el mecanismo a seguir ante un eventual cambio de orden o alcance del

proyecto sin que este contradiga las indicaciones que para tal fin aparecen en el contrato de prestación de

servicios de Consultoría.

A continuación se detalla el procedimiento para cambio del Alcance que se utilizará en cualquier fase del

proyecto de implementación SAP S/4HANA en MHRD.

Paso 1 - Identificación de la necesidad del cambio (miembro del equipo).

Paso 2 - Documentación de la Solicitud del Cambio de Alcance (miembro del equipo, Gerente de Proyecto de

MHRD y Gerente de Proyecto GBM).

Información contenida en la documentación de Solicitud de Cambio de Alcance:

Descripción del cambio propuesto.

▪ Razón para el cambio

▪ Prioridad: Hay tres niveles de prioridad

o Alta. El solicitante considera que el proyecto no debe seguir adelante sin el cambio.

o Media. El solicitante considera que se perdería un beneficio importante sin la

implementación del cambio.

305

o Baja. El solicitante cree que los beneficios del cambio son superiores al costo pero que el

proyecto puede seguir de momento sin su implementación.

▪ Consecuencias de no hacer el cambio

▪ Impacto en el alcance

▪ Impacto en productos entregables

▪ Impacto en el esfuerzo de trabajo

▪ Impacto en el calendario

▪ Otros impactos

Paso 3 - Firma del documento por parte del responsable del departamento o área que inicia la solicitud de

cambio.

Paso 4 – Los Gerentes de Proyecto de MHRD y GBM estudian la solicitud de cambio, al hacerlo generarán la

primera sesión de tratamiento del tema junto con el / los miembros del equipo que realizaron las tareas de

análisis de requerimientos y el usuario solicitante.

Paso 5- Los Gerentes de Proyecto de MHRD y GBM analizarán la solicitud y, en caso de estar bajo su dominio,

tomarán la decisión que el asunto amerite. Si el tema objeto de la solicitud requiere una decisión de índole

político, organizacional modular o de alto impacto se elevará la misma al Comité Guía, quien tomará la

decisión final, según procedimiento de decisiones.

Paso 6- Notificación al solicitante, por parte del Gerente del Proyecto MHRD, de la resolución tomada

respecto de la solicitud de cambio.

6.4 Equipo de Proyecto – Ministerio de Hacienda de Republica Dominicana

Se entiende que este equipo debe ser igual para cada institución que se seleccione en el Lote N1

Gerente de Proyecto MHRD

Usuario Clave

Cuentas por Pagar

Usuario Clave

SIGEF

Usuario Cuentas por Cobrar

Usuario Clave

DGII

Usuario Clave

Activos Fijos

Usuario Clave

DGBN

Usuario Clave

Compras

Usuario Clave

SIGEF Compras

Usuario Clave Portales

Usuario Clave

SIRIT

Usuario Clave Progamacion

Usuario Clave

Inventario

Datos Maestros

MHRD

306

6.5 GBM

Para que un proyecto sea exitoso depende, al menos, de métodos y herramientas empleadas por la gente

que está involucrada. Los roles del equipo de trabajo necesitan ser claramente definidos y comunicados

desde el principio, por todos los miembros, para trabajar juntos como un equipo. El factor clave es la

importancia de identificar la persona adecuada para cada rol del equipo de trabajo.

Las acciones efectivas requieren de tres (3) elementos de importancia:

▪ La gente correcta involucrada.

▪ La información con la cual cuentan los miembros del equipo sea la correcta.

▪ Los mecanismos de toma de decisiones y resoluciones sean puestos en su lugar.

Diversas situaciones que hacen fuerte a los miembros de un equipo

▪ 100% de compromiso.

▪ Un conocimiento experto en la función de negocios. Los mejores resultados son conseguidos usando

personas que sean reconocidas como expertos en sus propias funciones de negocios.

▪ Autorización para la toma de decisiones.

▪ Soporte de la dirección estratégica de la empresa.

▪ Abiertos a nuevas ideas y conceptos.

▪ Habilidad de comprender ideas abstractas, a entender las transacciones internas de la compañía y la

reproducción de procesos en el nuevo sistema; es necesario ser capaz de pensar en términos

abstractos.

Gerente de Proyecto GBM

Consultor

Finanzas

Consultor

Finanzas

Consultor

Procura e Inventario

Consultor

Mantenimiento

Consultor

Real Estate

Lider Tecnico

Consultor Interfaces Consultor Portal Cosnultor Data Service Cosnultor Archiving

Consultor Tecnico

InterfacesConsultor Tecnico

BASIS

307

▪ Orientación de resultados. Adecuar oportunamente la información concerniente al nuevo sistema,

este efecto puede con frecuencia fomentar aceptación.

▪ Miembro del equipo. Dar soporte en situaciones difíciles.

▪ Enérgico.

▪ Buena voluntad de cooperar. Cooperación con los colegas del equipo y con los empleados en los

departamentos, si es necesario, todas las veces.

▪ Aceptación y tolerancia de otros. Aceptación de las diferencias de otros miembros del equipo.

▪ El proyecto deberá estar integrado por personal de MHRD y GBM CONSULTING, con los cometidos

que se indican a continuación:

Gerencia del proyecto: proponemos una coordinación en conjunto con las siguientes responsabilidades:

MHRD:

▪ Ser el interlocutor entre las empresas.

▪ Dar la orientación general del proyecto.

▪ Nombrar a las personas de su organización y facilitar su integración en el proyecto.

▪ Supervisar el cumplimiento de los hitos.

▪ Facilitar el acceso a la información.

▪ Dotar al proyecto de los medios necesarios.

▪ Tramitar la documentación resultante del proyecto.

GBM:

▪ Ser el interlocutor de GBM para el proyecto.

▪ Facilitar la información referente a los módulos de SAP.

▪ Estar informado de las necesidades futuras de los módulos.

▪ Aportar soluciones alternativas que faciliten la implantación sin menoscabo de la información requerida

por las distintas direcciones de la empresa.

Las condiciones esperadas del personal de MHRD que participará en el proceso de implementación de SAP

son las siguientes:

• Poseer experiencia en el manejo de los sistemas actuales de la gestión de Finanzas, Compras,

Tesorería, etc.

• Ser abiertos a los cambios y con habilidades analíticas y de sustentación de decisiones.

• Tener habilidad para tomar decisiones bajo presión.

• Contar con un equilibrio entre las habilidades de conductor, facilitador y ejecutor.

• Haber participado en otras implementaciones de sistemas (opcional).

• Tener buena expresión oral y escrita, con experiencia en conducción de presentaciones y en

entrenamiento de personal (recomendable).

• Dominar las herramientas Office de Microsoft (Word, Excel y Powerpoint).

308

Organización del Proyecto

En esta sección se describirá la organización propuesta para el desarrollo del proyecto, que estará compuesta

por una serie de figuras y unidades que participan en el mismo cuyas actividades y responsabilidades se

presentan a continuación.

Se plantea una estructura flexible y ligera, capaz de adaptarse a la evolución del proyecto, optimizando para

cada etapa los recursos asignados. Cada equipo deberá contar con un líder MHRD y uno GBM CONSULTING,

más otros miembros según sea necesario. La organización propuesta permitirá obtener:

• La clarificación de las responsabilidades y una eficaz distribución de las mismas.

• Un permanente flujo de información entre el proyecto y MHRD.

• La rápida transferencia de nuestra metodología de trabajo y conocimientos al personal de la empresa.

• La reducción de la duración y costos del proyecto.

• La pronta obtención de resultados prácticos y útiles.

• Un conocimiento detallado de los diferentes aspectos intrínsecos a cada uno de los procesos de las

diferentes unidades de negocio.

• Una alta motivación e interés por participar en el cambio de parte del personal que compondrá los

equipos de trabajo o colaborará con ellos.

Para asegurar la correcta implementación y prueba del sistema, así como el correcto soporte a los usuarios

en la nueva versión, es necesario establecer un equipo de proyecto que trabaje en conjunto con los

consultores de GBM. Los roles específicos incluyen:

Rol del Patrocinador del Proyecto: es un contacto final a largo plazo de las metas y visiones para la

corporación. Tiene que ser capaz de poner prioridades, aprobar el alcance y ayudar con la promoción del

proyecto a través de la organización.

El Patrocinador del Proyecto tiene la última decisión de realizar el cumplimiento de las responsabilidades

primarias del perfil de los miembros del Comité de Dirección. Donde existan conflictos en la terminación de

esas responsabilidades, el patrocinador tiene la autorización de negociar y dar una solución. El Patrocinador

del Proyecto tiene autoridad del presupuesto final. Tiene que ser un miembro del Comité de Dirección y debe

participar en la reunión semanal del proyecto.

Algunas de las habilidades requeridas para cumplir con el rol del Patrocinador son las siguientes:

• Presencia del nivel ejecutivo dentro de la corporación.

• Visión de las metas de la organización.

• Ser capaz de tomar decisiones críticas bajo momentos de presión.

• Fuerte habilidad de liderazgo y efectiva habilidad de negociación.

• Habilidad de tener buena comunicación incluyendo habilidad de comprender.

• Previa experiencia con sistemas de implantación.

309

Rol del Gerente del Proyecto: es el encargado de revisar la dirección de todo el proyecto. El Gerente de

Proyecto es el principal enlace con los miembros del Comité de Dirección y el Patrocinador del Proyecto.

Las responsabilidades del Gerente de Proyecto son: definición de la estrategia de implantación y plan del

proyecto de mantenimiento, la definición y la dirección de los recursos del proyecto, comunicación del status

del proyecto tanto para los miembros del Comité de Dirección como para los Patrocinadores Ejecutivos y

también para el Equipo de Trabajo. El Gerente de Proyecto debe ser capaz de anticipar la desviación del

proyecto y ser responsable de tomar acciones correctivas inmediatamente. El Gerente de Proyecto tiene que

ser capaz de participar en la identificación y diferenciación de los principales procesos de negocios.

El Gerente de Proyecto debe de ser calificado para servir efectivamente como miembro del Comité de

Dirección y ser totalmente apoyado por esa parte.

Algunas de las habilidades requeridas para cumplir con el rol del Gerente del Proyecto son las siguientes:

• Conocimiento del proceso de negocio. Idealmente esta persona no debe ser nueva en la organización.

• Trabajar efectivamente con todos los niveles de la dirección y guiar personalmente al equipo de trabajo.

• Habilidad de mantener una gran visión de las metas del proyecto y revisar, en detalle, las diferentes

tareas. Esto incluye el control del alcance.

• Tiempo de la dirección y la habilidad de realizar múltiples tareas.

• Habilidad en comunicación tanto hablada como escrita.

• Habilidad de negociación.

• Tomar decisiones rápidamente.

• Fuerte habilidad de organización.

El rol principal del gerente es:

• Tomar control sobre la calidad y oportunidad en la entrega de los Entregables por cada fase, así como

dar seguimiento en el día a día a los miembros del equipo.

• Ser responsable por mantener el plan de proyecto, asegurando una comunicación eficiente de los temas

encontrados y canalizando la solución oportuna de los mismos.

• Entregará una supervisión general a la implementación mientras que tendrá un rol activo en la

integración de los miembros del equipo.

• Administra toda la planeación, documentación y ejecución del arranque en producción.

Rol del Líder del Equipo Funcional (LEF): tiene la facultad de manejar las entregas del área funcional del

proyecto y la dirección diaria del mismo. El Líder del Equipo debe ser capaz de trabajar con el Gerente del

Proyecto para desarrollar el alcance del programa de los recursos y manejar casos particulares del proyecto.

Ellos son responsables de identificar el impacto y los requerimientos para los procesos de negocio y verificar

que los objetivos del negocio sean encontrados por el equipo del proyecto.

310

El Líder del Equipo Funcional es responsable de dirigir el esfuerzo para proporcionar el análisis y participar

en la identificación y diferenciación de los principales procesos de negocio. Las responsabilidades primarias

son trabajar con los miembros del Equipo Funcional y con el grupo de los usuarios finales para: desarrollar el

diseño funcional; realizar/revisar el diseño funcional; probar y documentar el diseño funcional. Además ellos

tienen que trabajar conjuntamente con el equipo técnico en el diseño y desarrollo de reportes, formas,

interfaces y conversiones. Dependiendo del tamaño del equipo del cliente y del proyecto, tal vez ellos serán

llamados para ejecutar con detalle el diseño y configuración del producto SAP S/4HANA.

El Líder del Equipo Funcional también es responsable de la dirección y ejecución de la prueba e integración

del sistema. Esto incluye: trabajar con el equipo del proyecto en la identificación de los escenarios críticos;

identificar los datos que van a ser probados; dirección de los resultados esperados vs. resultados actuales.

Ellos deben de ser capaces de conducir el taller y las presentaciones para validar el diseño del negocio con el

grupo de usuarios en conjunción con los miembros del equipo del proyecto.

Algunas de las habilidades requeridas para cumplir con el rol de Líder del Equipo Funcional son las siguientes:

• Conocimiento especializado de los procesos de negocio de la compañía en áreas funcionales asignadas.

Esta persona no debe ser nueva en la organización del cliente.

• Debe tener la autorización de tomar decisiones.

• Habilidad de trabajar en diversos equipos, guiar y motivar a los miembros del equipo.

• Tiene que ser capaz de trabajar tanto en la dirección como en el sistema.

• Habilidad de mantener una gran visión de las metas del proyecto y realizar en detalle las diferentes

tareas.

• Habilidad de realizar diversas tareas y tiempos de trabajo en la dirección.

• Habilidad en la aplicación de software incluyendo, pero no limitando, la presentación, hoja de cálculo y

procesador de palabras.

Rol de los Miembros del Equipo Funcional (MEF): son responsables de la ejecución del diseño y configuración

de los procesos de negocio del producto SAP S/4HANA. Esto incluye estar trabajando con el Líder del Equipo

Funcional en el análisis y dirigir el esfuerzo para participar en la identificación y diferenciación de los

principales procesos de negocio, desarrollo de los ejercicios de trabajo, diseño y configuración del sistema

SAP S/4HANA para apoyo de la organización. Deben también ayudar en el diseño de reportes, formas,

interfaces y conversiones.

Ellos son responsables de la ejecución del sistema de prueba de los usuarios y la prueba de integración. Esto

incluye el desarrollo de pruebas, hacer cambios en la configuración basado en resultados y la resolución de

errores. Ellos también deben de ser capaces de conducir el taller y las presentaciones para validar el diseño

del negocio con el grupo de usuarios finales.

También deben de ser responsables de trabajar con el equipo de documentación de los usuarios finales en

la identificación de los procesos de negocio y tareas del sistema a documentar, así como proveer

entrenamiento al usuario final y desarrollo del equipo. No es recomendable que el individuo sea responsable

de las tareas actuales de la documentación de procedimientos y tareas del sistema.

311

Algunas de las habilidades requeridas para cumplir con el rol de Miembro del Equipo Funcional son las

siguientes:

• Personal de Sistemas de Información con fuertes conocimientos de la aplicación de negocios con una

capacidad técnica.

• Autorizado para tomar decisiones funcionales y cambios operacionales.

• Buen conocimiento de los procesos de negocio de la compañía con una fuerte habilidad analítica.

• Excelente presentación y habilidad en comunicación tanto hablada como escrita.

• Habilidad de tomar decisiones bajo presión.

• Balanceada mezcla de habilidades: conductor y visionario.

• Previa experiencia en conducción de presentaciones y entrenamiento.



Rol del Líder del Equipo Técnico (LET): tiene la facultad de manejar las entregas del área técnica del proyecto

y la dirección diaria del mismo. El Líder del Equipo debe ser capaz de trabajar con el Gerente del Proyecto

para desarrollar el alcance del programa de los recursos y manejar casos particulares del proyecto. El Líder

del Equipo Técnico es responsable de dirigir el esfuerzo de los Desarrolladores ABAP. Las responsabilidades

primarias son trabajar con los miembros del Equipo Técnico, con los miembros del Equipo Funcional y con el

grupo de los usuarios finales para: crear los desarrollos, reportes, programas de carga y conversiones

requeridos para el proyecto, así como exigir de los miembros del Equipo Funcional la correcta definición y

prueba de éstos.

Algunas de las habilidades requeridas para cumplir con el rol de Líder del Equipo Técnico son las siguientes:

• Conocimiento especializado de la plataforma de sistemas actualmente instalada en la compañía.

• Debe tener la autorización de tomar decisiones.

• Habilidad de trabajar en diversos equipos, guiar y motivar a los miembros del equipo.

• Tiene que ser capaz de trabajar tanto en la dirección como en el sistema.

• Habilidad de mantener una gran visión de las metas del proyecto y realizar en detalle las diferentes

tareas.

• Habilidad de realizar diversas tareas y tiempos de trabajo en la dirección.



Rol de los Miembros del Equipo Técnico (MET): es responsable del data mapping, diseño, desarrollo, prueba

de conversión de programas, programas de interfaces y reportes de ABAP.

El Desarrollador ABAP ayudará al Líder Técnico del Proyecto en la dirección y documentación de los

desarrollos del proyecto. Esto también incluye la definición de estándares, diseño y dirección del Workbench

Organizer.

312

El Desarrollador ABAP también puede ser llamado para complementar las habilidades del Líder Técnico en el

desarrollo de herramientas del área si el Líder Técnico tiene un sistema de apoyo más poderoso.

Algunas de las habilidades requeridas para cumplir con el rol de Desarrollador ABAP son las siguientes:

• Fuerte comunicación tanto oral como escrita.

• Fuerte habilidad analítica.

• Habilidad de trabajar en diversos equipos.

• Previa experiencia como desarrollador ABAP o Lenguaje orientado a objetos.

• Conocimiento detallado del cliente considerando los sistemas legales y/o de interfaces.

• Conocimiento del cliente en los procesos de negocio.

Rol del Administrador del Sistema SAP: es responsable de la configuración, monitoreo, afinación y resolución

del ambiente de la base de SAP. Este Administrador también es responsable de la revisión diaria de las tareas

en el ambiente técnico. Éstas incluyen, entre otras: el manejo y la ejecución de Sistema de Transporte de SAP

y CCMS. La responsabilidad incluye el manejo y la ejecución de instalaciones. En pequeñas implantaciones,

el Administrador del Sistema SAP también es responsable de operar el sistema de administración del usuario

y la administración de seguridad de SAP.

Algunas de las habilidades requeridas para cumplir con el rol de Administrador del Sistema SAP son las

siguientes:

• De 3 a 5 años de experiencia en administración de empresas con aplicaciones cliente-servidor.

• De 3 a 5 años de experiencia en dirección de sistemas de operación.

• Habilidad de trabajar con diversos equipos.

• Fuerte habilidad en comunicación tanto oral como escrita.

• Fuerte habilidad analítica.

• Previa experiencia como administrador del Sistema SAP (opcional).

• Conocimiento de los procesos de negocio del cliente.

Rol del Equipo de la Gerencia del Cambio: el rol que desempeña un miembro del Equipo de la Gerencia del

Cambio es determinar cómo y dónde la implantación del sistema SAP S/4HANA afectará a la organización e

identificará cuales trabajos importarán con el cambio.

El miembro del Equipo de la Gerencia del Cambio es responsable tanto de la comunicación interna como

externa respecto al proyecto y al nuevo sistema. Internamente, ellos informan a los varios grupos de la

organización acerca del cambio. Externamente, ellos comunican con a vendedores y clientes acerca del

cambio.

A continuación se resumen las habilidades requeridas para cumplir con el rol del Equipo de la Gerencia del

Cambio, por lo que lo siguiente es obligatorio:

• Trabajar efectivamente con todos los miembros de la organización, desde los miembros ejecutivos hasta

los usuarios finales.

313

• Fuerte habilidad de comunicación.

• Buen conocimiento de la estructura organizacional y de los procesos de negocio.

• Establecer relaciones de trabajo con múltiples unidades de negocio de la organización.

GBM – Gerente de Proyecto: El rol principal del gerente del proyecto es apoyar al gerente del proyecto de

MHRD y gerenciar los recursos de consultoría involucrados en el proyecto.

• Definición del alcance, desarrollo y mantenimiento del plan proyecto y de entrenamiento, etc. Su

asignación de ninguna forma exime a MHRD de la necesidad de dedicar un recurso el 50% del tiempo de

implementación a la gerencia del proyecto.

• Provee las bases y las direcciones para los planes detallados del Proyecto.

• Transfiere los conocimientos acerca de la implantación de SAP S/4HANA.

• Informa al Gerente del Proyecto de MHRD, sobre el status del Proyecto:

▪ Dirección y Metas.

▪ Organización y entrenamiento del equipo del Proyecto

▪ Integración y Configuración de SAP ERP.

▪ Provee de recursos calificados para cumplir con los requerimientos del Proyecto.

▪ Reporta el progreso del Proyecto en forma escrita al Comité Ejecutivo del Proyecto.

GBM– Consultores de proyecto: La responsabilidad principal del equipo de consultores es entregar la mejor

solución en SAP que refleje y cumpla con las expectativas del proyecto, basándose en el Alcance del proyecto

definido por el gerente de proyecto. Adicionalmente, dentro de sus actividades se tienen:

• Transferencia de conocimientos en las áreas de aplicación de SAP S/4HANA.

• Recomendación de diseño de soluciones y alternativas.

• Diseño de la solución en base a los requerimientos del negocio.

• Liderar las actividades de documentación, mapeo y configuración.

• Facilitar que el avance del Proyecto vaya de acuerdo a los planes.

• Recomendar a MHRD, los esquemas de seguridad y las autorizaciones de SAP S/4HANA.

• Asistir a MHRD, en el desarrollo y documentación del plan y de los procedimientos de arranque en

producción.

GBM – Consultores Técnicos: Consultor BASIS de GBM: El consultor de BASIS será responsable de proveer

asesoría y soporte a MHRD en los siguientes servicios:

• Servicios de Configuración de BASIS SAP S/4HANA:

• Definición del Landscape (Estrategia de Mandantes).

• Instalación de SAP Solution Manager

• Instalación de SAP SAP S/4HANA

• Configuración de la funcionalidad de Corrección y Transporte.

• Definir Estrategia del sistema de Seguridad de SAP SAP S/4HANA.

• Administración de SAPGUI de SAP S/4HANA.

314

6.6 Estrategia de Adiestramiento.

GBM será responsable del entrenamiento de los usuarios miembros del equipo de proyecto a través de su

participación en el mismo y en sesiones de entrenamiento sobre la configuración básica establecida.

Para el entrenamiento del equipo de proyecto de MHRD, se prevé la realización de talleres presénciales sobre

la solución que entregue la formación necesaria al equipo de proyecto de MHRD para el desarrollo del

mismo.

El equipo de proyecto será entrenado bajo la filosofía de “train-the-trainer”, con la finalidad tener un efecto

de cascada para la preparación y capacitación de los usuarios finales en la etapa de soporte de la solución.

Con nuestra estrategia comprobada diseñamos la transferencia de conocimiento que se adapta a las

necesidades de nuestros clientes. Las actividades de adiestramiento están completamente integradas con

otras actividades en el proceso de implementación. Nuestros planes de adiestramiento dividen a los recursos

de MHRD en 2 grupos distintos: Miembros del equipo de proyecto y usuarios finales. La estrategia seguida

para cada grupo es diferente pero el resultado es el mismo: usuarios que entienden como la solución los

ayudará a ellos y a otros a llevar a cabo sus actividades del día a día. Del mismo modo el equipo de proyecto

se enfoca en utilizar las herramientas de SAP y la configuración; el adiestramiento de usuarios finales se

orienta a los procesos de negocio y los cambios que resultan por la implementación del nuevo sistema.

Adiestramiento de Equipo de Proyecto (Usuarios Clave)

Es recomendable que los usuarios clave reciban entrenamiento directo de SAP S/4HANA. Sin embargo como

parte de la metodología se realizaran entrenamiento a los usuarios claves de SAP S/4HANA para proveer a

su equipo de las competencias necesarias que aseguren una implementación exitosa. Las audiencias incluyen

a ejecutivos nivel senior, dueños de procesos, equipos de configuración y súper usuarios así como cualquier

otro miembro de cualquier equipo de implementación.

Los talleres que se han planeado dictar durante el transcurso del proyecto al equipo de MHRD.

Actividad Duración

estimada

Introducción de SAP S/4HANA 1 día

Taller de Finanzas 5 días

Taller de Compras 3 días

Taller de Bodegas 3 días

El equipo de MHRD asume el entrenamiento de usuarios finales, como lo define la metodología ACTIVATE.

Los consultores de GBM soportarán al equipo de MHRD durante las sesiones de entrenamiento para asegurar

que las mismas sean completadas exitosamente, en la forma de elaborar el material didáctico y en la

generación de ejemplos.

315

Adiestramiento Usuarios Finales

El entrenamiento de usuarios finales ocurre durante todo el ciclo de vida del proyecto:

• Cada vez que un usuario es involucrado en una discusión o un taller de proceso.

• Cuando el usuario acceda a información que describa el proyecto.

• Cuando el usuario ejecuta sus ejercicios en el salón de clases, en el “sandbox”.

• Durante la ejecución de sus pruebas integrales

Un programa de entrenamiento efectivo debe sacar provecho de cada uno de los puntos de contactos con

los usuarios para fortalecer el manejo del cambio de la organización, los siguientes puntos de contacto son

críticos:

Metodología de Entrenamiento de Usuarios Finales

Para entrenar a los usuarios finales, el equipo de proyecto entrenará a los usuarios finales utilizando el

método entrenar al entrenador (train-the-trainer). Este método ayudará a brindar aceptación por parte de

la comunidad de usuarios finales y al mismo tiempo construir el conocimiento para auto-soportarse. El costo

del adiestramiento para usuarios finales no está incluido en esta propuesta.

Los usuarios claves de MHRD serán responsables del entrenamiento de la comunidad de usuarios finales,

con la asistencia del equipo de consultores de GBM CONSULTING. Nuestros asesores orientarán al equipo de

MHRD en la presentación general del material didáctico y la preparación de la documentación del material

de adiestramiento.

GRAPHIC [GA-Gwinnett] 1/03

Project Communications

Kickoff Workshops Sandbox Roadshows

Walkthroughs Testing Help Desk and FAQs

Classroom Training

GRAPHIC [GA-Gwinnett] 1/03

Project Communications

Kickoff Workshops Sandbox Roadshows

Walkthroughs Testing Help Desk and FAQs

Classroom Training

316

El entrenamiento es una responsabilidad compartida que requiere de tiempo y atención, el equipo de

proyecto no podrá desarrollar el material de entrenamiento sin orientación clara por parte de los consultores

de GBM.

El entrenamiento de usuarios finales tiene el siguiente comportamiento durante el proyecto:

• Análisis, durante la fase de Business Blueprint se identificaran y clasificaran los usuarios por roles. El

mapa de usuarios será la base para la programación del entrenamiento y para la definición de los

requerimientos de entrenamiento.

• Diseño. Al inicio de la fase de realización se definirá la curricula de entrenamiento, los track de

entrenamiento y se generara el prototipo del contenido de los cursos. Esta información será generada

por los consultores de GBM.

• Desarrollo. Los business process procedures (BPP) forman la base para el entrenamiento detallada. Los

usuarios claves basados en esta información podrán ajustar las presentaciones y los ejercicios de los

entrenamiento

• Ejecución. Durante la preparación final, se ejecutara el entrenamiento de los usuarios finales donde los

instructores recibirán evaluaciones de los participantes para poder medir la efectividad de los

entrenamientos.

Curricula de Entrenamiento

El entrenamiento de los usuarios finales consta de tres niveles: visión general, entrenamiento sobre

conceptos generales de la funcionalidad y entrenamiento sobre las operaciones y transacciones. Los usuarios

tomaran los cursos de nivel 1 como la introducción a SAP. Los usuarios que necesitan información de un

modulo en especifico recibirán una visión general del modulo y de los conceptos de negocio, estos

entrenamientos tienen como objetivos proporcionar un marco conceptual y estructural del modulo o

función. Los cursos de nivel 1 y 2 serán pre-requisitos para completar los cursos de nivel 3, los cuales

proveerán a los usuarios finales información detallada de los procedimientos de trabajo, transacciones y

reportes requeridos para ejecutar las tareas diarias de trabajo.

Para definir la cantidad específica de cursos necesarios para el entrenamiento de los usuarios finales se

requerirá realizar una evaluación para recopilar la información como la población de usuarios, competencias

actuales y las requeridas para poder ejercer sus funciones en SAP S/4HANA. Aunque podemos asumir que

los usuarios no tendrán experiencia en SAP S/4HANA, se requiere medir su conocimiento y destrezas en áreas

generales como los conocimientos para operar un PC y Dispositivos Moviles.

Nuestra evaluación es una encuesta que tiene como objetivos principales: 1) determinar los roles en la

organización y las transacciones que serán ejecutas 2) determinar las competencias técnicas de los usuarios.

Una vez realizada la evaluación, trabajaremos junto con MHRD para determinar la combinación apropiada

de curricula para poder satisfacer las necesidades de los usuarios.

317

Hasta no completar la evaluación, es imposible poder proveer una curricula que satisfaga el alcance de

funcionalidades a ser implementadas. Anexamos un ejemplo de una curricula de entrenamiento de usuarios

finales que pudiera servir como base para el alcance definido en el RFP. Los consultores de GBM CONSULTING

finalizaran la curricula de entrenamiento durante la fase de Business Blueprint, basado en las funcionalidades

a ser implementadas y de los resultados de la evaluación.

Curso Curso Descripcion Nivel

Duracion

(Hrs)

100 Fundamentos Básicos

SAP

Visión General de SAP 1 2

200 Compras Visión General de compras, revisar la

estructura organización, integración y

conceptos básicos del modulo

2 4

210 Ordenes de Compras Revisión del proceso de ordenes de

compras

3 16

6.7 Plan de Cutover (Interfaces para carga de datos iníciales e Histórica)

El propósito del plan de Cutover es planificar la duración, los recursos y requerimientos de procesamiento

de data para migrar el sistema SAP S/4HANA a un entorno de producción. El proceso de Cutover supone la

ejecución paso a paso de unas tareas planificadas. El Cutover transformará el entorno de desarrollo

inspeccionado durante la fase de Preparación final en el entorno productivo.

El plan de cutover tendrá como resultado los siguientes entregables:

• Plan de fechas para la conversión de datos.

• Procedimiento de reconciliación de datos convertidos.

• Lista de verificación (cheklist) del proceso de cutover.

• Plan de fechas para las tareas del proceso de cutover

• Lista de contactos del proceso de cutover

A continuación se describe la propuesta del plan de cutover

El proceso de cutover es de por sí transitorio y requiere una planificación y una duración adecuadas. Los tres

componentes principales son:

1. Conversión de datos

• Preparación

• Programación

• Dependencias

2. Flujo de información

• Toma de decisión

318

• Papeles y responsabilidades

3. Plan de comunicación

• Decisión final para entrada en productivo (Go/No Go)

Esfuerzo para conversión de data

La planificación y preparación para el proceso de conversión de datos comienza durante la fase de

preparación de proyectos. El plan de cutover deberá refinarse durante el proceso de implementación

mientras el equipo de implementación de SAP aprueba de modo definitivo las escenarios de proceso

empresarial. Esto incluye los campos de datos maestros a ser completados y que se definidos durante la fase

de Realización (Fase 3). Esta mejora aclarará específicamente la información a convertir. Adicionalmente el

plan deberá ser refinado también en base al volumen y la integridad de la data del sistema legacy.

Preparación

SAP S/4HANA es un sistema altamente integrado. Por tanto, la identificación de los datos a convertir y la

secuencia en la que se ejecuten los procesos de conversión dependerán de las interrelaciones entre las

aplicaciones y las transacciones del Sistema SAP S/4HANA.

En un sistema SAP S/4HANA intervienen tres clases de datos: maestros, transaccional e Histórico.

• Datos maestros. Los datos maestros de la aplicación tienden a ser más estáticos una vez se han definido.

La mayoría de datos maestros se pueden extraer de los sistemas legacy existentes. Ejemplo de estos

datos son los proveedores, clientes, planes de cuentas, bienes de uso, inventarios, maestros de

materiales, registros de información sobre proveedores, etc.

• Datos transaccionales. Los datos transaccionales son datos actuales y pendientes por ser procesados

que deben capturarse en el sistema legacy y definirse en las aplicaciones de SAP S/4HANA para la

conclusión del proceso empresarial. Ejemplo de estos datos son las cuentas x cobrar, cuentas x pagar,

pedidos de compra, ventas pendientes, pedidos atrasados, etc.

• Datos históricos. Los datos históricos deben trasladarse desde el sistema legacy al Sistema SAP S/4HANA

para funciones de referencia.

Cada tipo de dato deberá ser analizado independientemente con el objeto de definir el procedimiento

apropiado para la conversión de datos. Por ejemplo, los datos maestros deberán introducirse manualmente,

según el volumen de datos. Los datos transaccionales pueden necesitar un proceso automatizado para la

conversión de datos, como por ejemplo el proceso de direct input. Al momento de tomar la decisión del

proceso de automatización de carga es importante tener en cuenta la cantidad y la calidad de los datos.

"Cantidad" se refiere a los datos que se deben procesar (para un volumen alto se aconseja automatización).

"Calidad" se refiere a la integridad de los datos del sistema legacy. Si los datos del sistema legacy no son

correctos o no se pueden mapear al Sistema SAP S/4HANA, la automatización del proceso de conversión

quizás no sea viable. Quizás sea necesario depurar los datos (por ejemplo, eliminando los registros duplicados

319

o en desuso) antes del proceso de conversión. Si es así, deberá definirse una tarea de depuración en el plan

de trabajo y un repositorio de información intermedio para poder depurar la data.

Debido a la integración del Sistema SAP S/4HANA, las modificaciones directas a las tablas de bases de datos

no se permitirán, para problemas referentes a la integridad de los datos.

Programación

Una vez se han identificado los datos a convertir y los métodos de conversión, el siguiente paso es determinar

la duración y la secuencia de los programas de conversión, para lo cual las siguientes interrogantes deberán

abordarse

• ¿A qué hora pueden terminarse todas las operaciones de sistemas existentes?

• ¿Cuándo se pueden desactivar los sistemas legacy para comenzar la conversión de datos y cuándo

debe estar operativo el nuevo sistema, teniendo en cuenta los husos horarios en los que opera la

empresa?

• ¿Cuánto durarán los procesos de conversión de datos, verificación de datos y reconciliación?

• ¿Cuándo deberán realizarse copias de seguridad de datos y cuánto tiempo se necesitará para el

restablecimiento de la base de datos?

• ¿Cuántos datos se convertirán? El volumen de los datos es fundamental para determinar el tiempo

de proceso del programa de conversión o los recursos necesarios para introducir datos

manualmente.

• ¿Qué hardware se está utilizando? Determine cómo afectará el hardware a la velocidad de los

procesos de conversión automatizados y al proceso de transacción para procedimientos manuales.

• ¿A qué hora deberá estar operativo el nuevo sistema?

• Calcule el tiempo necesario para la conclusión de todos los procesos de conversión de datos. Una

vez se hayan definido los tiempos para el proceso, se recomienda que se asignen 24 horas más al

plan como medida de precaución.

• El equipo de planificación de cutover debe identificar asimismo alternativas para resolver problemas

que puedan ocurrir durante las fases de planificación o ejecución. Por ejemplo, durante la fase de

planificación se puede identificar que no hay tiempo suficiente para el fin de semana previsto para

ejecutar todas las conversiones y los procesos de reconciliación. En ese caso, podrá:

• Elegir otro fin de semana (quizás uno festivo) en el que haya más tiempo disponible para que los

procesos de cutover se finalicen sin afectar las operaciones empresariales

• Seleccionar procesos empresariales que puedan cerrar antes (por ejemplo, el jueves por la tarde)

para proporcionar una ventana adicional al proceso de cutover.

• Determinar si el primer día todos los procesos de cutover son cruciales para las operaciones (por

ejemplo, la información histórica puede convertirse el fin de semana siguiente, tras la puesta en

marcha del nuevo sistema).

• Si, durante la fase de ejecución, el plazo de tiempo del fin de semana previsto para la conversión

resultara insuficiente, podrá:

• Restablecer el funcionamiento de los sistemas legacy y ejecutar de nuevo el proceso de transposición

durante otro fin de semana.

• Seleccionar procesos empresariales que puedan iniciarse más tarde (el lunes por la tarde, por

ejemplo), para proporcionar una ventana operativa más amplia al proceso de transposición.

320

• Determinar si el primer día todos los procesos de cutover son cruciales para las operaciones (por

ejemplo, la información histórica puede convertirse el fin de semana siguiente, tras la puesta en

marcha del nuevo sistema).

Las dependencias de los datos y la duración de los programas de conversión para el fin de semana de cutover

deberán publicarse en la sala de proyectos del equipo encargado de cutover. Esta sala proporcionará el punto

central para las comunicaciones. Este modelo enfatizara a los miembros del equipo de proyecto los procesos

de cutover, la secuencia y las dependencias. Para poder completar la programación se deberán realizar

simulacros de las conversiones para obtener la duración de cada programa. Adicionalmente el programa de

cutover deberá contener la siguiente información:

• La secuencia necesaria para la ejecución del proceso y el programa

• Los tiempos necesarios para completar los programas

• Las dependencias que deban completarse antes de poner en marcha el siguiente programa o proceso

• Los puntos de inspección por parte del equipo de control de calidad

Por ejemplo:

La ejecución del programa de conversión de datos maestros del cliente requiere tres horas. El programa no

puede ejecutarse hasta que todos los datos de configuración se hayan transportado desde el entorno de

prueba del sistema y se haya procedido a su verificación. Éste es uno de los primeros procesos a completar

durante el fin de semana de cutover. Así, el programa de conversión de datos maestros del cliente dará

comienzo a las 17:00 horas y se esperará que haya finalizado a las 20:00 horas del primer día del fin de

semana de cutover. En este documento se destacará la dependencia de los datos de configuración, así como

los procesos posteriores que se deban terminar para confirmar que los programas se ejecutan de forma

adecuada. Esto podrá incluir actualizaciones manuales de los datos maestros del cliente, la verificación de

los datos y algo de tiempo para contingencias adicionales con vistas a completar el proceso.

Adicionalmente, deberá planificarse la conclusión de los procedimientos de reconciliación de datos.

Programación de puesta en productivo del sistema

La programación exacta para la puesta en productivo del sistema requiere planificación. Para lo cual se debe

considerar lo siguiente:

• El tiempo necesario para que se ejecuten los procesos de cutover

• Consideraciones acerca de los husos horarios

• Planes de contingencia

• El tiempo necesario para que todas las operaciones empresariales se procesen para el día "final" en el

sistema existente

Antes de reemplazar el sistema existente, deberá determinarse el tipo de acceso que tendrán los usuarios.

Generalmente, los usuarios no tendrán acceso a los sistemas existentes antiguos. Sin embargo, será posible

321

que algunos usuarios y gestores determinados tengan acceso únicamente a su visualización. Quizás sea

necesario depurar información del sistema existente antiguo tras la activación del nuevo sistema. Como

consecuencia, algunos responsables podrán tener acceso a la actualización.

Flujo de información

Toma de Decisiones

La definición de los equipos y responsabilidad es crucial para el éxito de la estrategia de cutover. Todos los

integrantes del equipo deberán estar al corriente de todos los pasos a seguir para asegurar la ejecución

precisa del plan. Además, los integrantes del equipo deberán comprender a la perfección sus funciones y

responsabilidades para asegurar una transición satisfactoria. El equipo del proyecto debe estar compuesto

por personal con dominio técnico y funcional tanto del sistema existente como de SAP S/4HANA para

eliminar problemas de traducción de datos.

Roles y responsabilidades

En el proceso de cutover intervienen dos categorías de personal. El equipo de proceso de cutover

proporciona el dominio y el soporte para ejecutar las actividades diarias propias del proceso. En él se incluyen

los usuarios claves y lideres funcionales. La segunda categoría de personal aprueba las tareas concluidas con

éxito o confirma los planes de contingencia para la toma de decisión sobre la entrada en productivo (Go/No

Go). Los miembros del comité directivo y/o los responsables del proceso empresarial desempeñan este

papel.

Equipo del proceso de cutover

El equipo del proceso de cutover incluye:

• Usuarios Claves

• Lideres funcionales

• Consultores funcionales

• Gerentes de Proyecto

Aprobadores

Los aprobadores incluyen:

• Dueños de proceso

• Comité directivo

Plan de comunicación

El gerente de proyecto deberá organizar el flujo de información. La lista de verificación (check list) de cutover

facilitará esta organización. La lista de verificación (check list) proporcionará una medición del progreso del

proceso de cutover. La lista de verificación podrá indicar elementos como:

• Las tareas que deben completarse

• Los responsables de tareas por departamentos

322

Contactos con el equipo de soporte

El tiempo tiene una importancia crucial en el proceso de cutover. Cada una de las personas que intervienen

en este proceso deberá permanecer continuamente al alcance. Por este motivo, deberá desarrollarse un plan

de fechas de personal de soporte de primer nivel. Además, ninguna tarea deberá ser responsabilidad única

de un solo integrante del equipo. Esta "base de conocimiento dual" asegurará que se comparta la

información en la empresa. Asimismo, proporcionará un plan de prevención, si inesperadamente los recursos

no se encuentran disponibles.

Además, deberá recopilarse un documento que incluya a todo el personal, sus número de teléfono y

celulares, etc.

Comunicación de la decisión final sobre la disponibilidad

Para facilitar la comunicación del status de cutover a los integrantes del equipo deberá ponerse a disposición

de las partes interesadas un mensaje telefónico grabado en el que se puedan escuchar todas las

actualizaciones del proceso de transposición. El jefe del equipo de transposición deberá actualizar el mensaje

cada cuatro horas.

El siguiente diagrama genérico muestra los pasos incluidos en la estrategia de cutover. Hace hincapié en la

importancia de la planificación, la programación temporal y la secuencia de eventos.

Eje

cució

n d

e C

ut

Over

Entrenamientos a

Usuarios Finales

Activid. Previas

a la conversión

Actividades

Técnicas

Preparación de la

Conversión

Ejecución de la

Carga de DM

Cierre legacy

Cie

rre

Co

nta

ble

Sa

lid

a

Pro

du

cti

vo

31

-05

-10

07

-06

-10

14

-06

-10

21

-06

-10

28

-06

-10

24

-05

-10

05

-07

-10

Carga de Partidas

Abiertas

Carga de Saldos

12

-07

-10

Prep. Partidas

Abiertas y Saldos

Su

sp

en

sió

n d

e

op

era

cio

ne

s e

n

leg

ac

y

323

Razones para considerar el tema de datos como crítico en el proyecto.

• De acuerdo al Data Warehousing Institute (TDWI) de EEUU, 83% de las organizaciones sufren grandes

problemas causados por baja calidad de sus datos maestros, con los siguientes 3 problemas más grandes:

o Reportes imprecisos (81%);

o Indeficiniones sobre cuales datos son correctos y en cuales sistemas (78%)

o Decisiones malas basadas en definiciones incorrectas (54%).

• Expertos en calidad de datos dicen que un 2% de todos los datos de una empresa quedan obsoletos

después de 2 meses de haber sido capturados;

• Innovative Research – un 35% de toda la información en los sistemas de una empresa son imprecisos y

hasta un 30% están duplicados;

• De acuerdo al Standish Group, cerca de 88% de los proyectos más grandes de IT no cierran en tiempo

y/o dentro del supuesto financiero por problemas relacionados a integración y calidad de los datos;

324

7. CONDICIONES GENERALES DE LA OFERTA

7.1 Premisas Generales

La principal ventaja que va a tener MHRD va a tener la mejor aplicación para controlar centralizadamente e

integradamente todas las operaciones administrativas, operativas y logísticas de la Corporación en la

aplicación empresarial líder mundial con las mejores prácticas de negocios.

El principal factor de riesgo es la complejidad detrás del proyecto. Aunque inicialmente se pretende migrar

los procesos e información que se ha relevado de los procesos actuales de la corporación con la mejora

natural que se obtiene al implementar una solución de clase mundial con las mejores prácticas del negocio

incluidas en la aplicación, estos procesos pueden variar ligeramente, originando cambios en los procesos y

procedimientos y en el personal que actualmente los ejecuta. Es importante indicar que al separar el

proyecto en fases, limitamos riesgos de integración y compatibilidad entre módulos; además al separar la

fase de diseño y realización, limitamos la responsabilidad de cambios al alcance solicitados luego del cierre

de fase de revisión del proyecto.

Nuestros mitigadores de riesgo son:

• Mantener el plan de proyecto y fechas límite.

• MHRD se adapta a las mejores Prácticas de Negocios inmersas en SAP

• Evitar rotación del personal (tanto de MHRD como de GBM) durante el proyecto.

• Ser estricto con las pruebas de integración y replicar situaciones cotidianas durante las mismas.

325

• Mantener los requerimientos de interfaces tan simples como sea posible.

• Seguir las mejores prácticas de negocio de SAP.

• Mantener el alcance del proyecto. Todos los participantes deben conocer y entender el alcance del

proyecto, la metodología ACTIVATE y el alcance de nuestros servicios.

• Iniciar una estrategia de comunicación fuera del proyecto para los usuarios finales.

• Poner especial énfasis en las sesiones de entrenamiento; evaluar a los participantes en los cursos

realizados, así como el contenido presentado durante las sesiones. Se estima que una hora de

entrenamiento ahorra 5 horas de soporte de IT.

• Desarrollar un equipo de soporte centralizado para el soporte post-productivo.

Nuestra estrategia está soportada por los siguientes factores críticos de éxito:

• Patrocinio de los Directores. El proyecto debe tener soporte completo de los directores de MHRD.

• Definir claramente los lineamientos de negocio. Debe estar claro lo que MHRD desea lograr en los años

por venir. Es posible que cambios en algunos procesos puedan afectar múltiples áreas, por lo que una

clara visión de las implicaciones de esos cambios, y como pueden afectar positivamente debe ser

inculcada a todos los miembros del proyecto.

• Destinar al proyecto usuarios con poder de decisión, y amplio conocimiento del negocio. Necesitamos

los mejores recursos que MHRD nos pueda dar. Como regla general, cada usuario de MHRD tendrá una

contraparte en GBM, para asegurar la mayor transmisión de conocimientos; este usuario se comportará

como “consultor interno” luego del cierre del proyecto.

• Rápida toma de decisiones durante el proyecto. Es un proyecto muy corto y ambicioso, por lo cual

requerimos precisión en las decisiones. De nuestra experiencia, reuniones semanales ayudan a resolver

problemas de comunicación y cohesión entre las áreas.

• Utilizar la experiencia de mejores prácticas de negocio de SAP. Se recomienda referir siempre al modelo

de negocio subyacente al proceso SAP antes de solicitar cambios al proceso.

• Evitar modificaciones al código fuente de SAP. Esto facilita el mantenimiento en versiones futuras.

• Iniciar los procesos de limpieza de data temprano. Este aspecto es fundamental para lograr cumplir con

las fechas límite.

• Tener una estrategia de manejo de cambio. La comunicación y relaciones proactivas en el proyecto y el

resto de la organización.

Además de los factores críticos de éxito, es necesario que MHRD preste especial atención a los siguientes

puntos:

• El entrenamiento a usuario final debe ser realizado por el equipo de MHRD. Es 100% responsabilidad

de MHRD cubrir estos entrenamientos de forma que se puedan evitar errores y corrección de data

al momento de ir en productivo.

• GBM CONSULTING será responsable de la migración de data. Sin embargo, es responsabilidad de

MHRD validar la consistencia de data y aprobar la migración.

• Toda la migración de data debe ser entregada a final de la fase de Realización en los formatos

entregados por GBM. Cualquier retraso o incongruencia en data tendrá impacto directo en los

tiempos de proyecto y puede implicar extensiones en el proyecto a ser cargadas por separado.

326

• Los siguientes aspectos reflejan los supuestos administrativos que hemos tomado para poner el

equipo en las instalaciones de MHRD. Hemos asumido que MHRD entregará el personal de IT para

mantener la base de datos, servidores y red.

• MHRD dará acceso a los consultores de GBM para realizar las actividades del proyecto, incluido

acceso fuera de horario de oficina, fines de semana y festivos.

• GBM firmará acuerdos de confidencialidad con MHRD.

• MHRD facilitará un espacio para acomodar al equipo de proyecto con acceso a teléfonos, impresoras,

copiadoras y líneas análogas.

• El proyecto tendrá acceso a un salón de conferencias y entrenamiento. Estos salones deberán tener

proyectores, recursos de red, y equipos didácticos como tableros y marcadores.

• MHRD asume horas de trabajo mínimo de 8 horas por 5 días a la semana.

• MHRD soportará las actividades de soporte final, tales como instalación de SAP GUI.

• MHRD es responsable de la estrategia de recuperación de desastres.

Los siguientes son supuestos que incluyen los roles y responsabilidades durante el proyecto, que han sido

planteadas en la propuesta. Se incluyen acá a manera de resumen:

• MHRD es responsable por gestionar el manejo del cambio en la organización, como están definidos por

la metodología ASAP.

• MHRD es responsable de validar la precisión de la data migrada.

• Los reportes estándares serán utilizados; hemos asignado un recurso ABAP/4 para programar

modificaciones (UserExits) y reportes. Si algún requerimiento excede el tiempo de ABAP/4 dispuesto,

deberá ser incluido al cierre de la fase de Blueprint.

• Se utilizará una estrategia train-the-trainer para entrenamiento a usuario final. El entrenamiento a

usuario final es responsabilidad de MHRD.

• GBM proveerá entrenamiento al equipo funcional del proyecto en modalidad de “Workshops”. Los

mismos cubrirán únicamente el alcance funcional y módulos a implementarse en este proyecto en

particular. Estos “Workshops” forman parte integral de la propuesta económica presentada.

• MHRD entregará la estructura de soporte (mesa de ayuda) para soporte primer nivel a usuario final.

• MHRD y GBM son responsables de probar las interfases.

Proponemos un equipo de consultores de alto desempeño que han participado en varios proyectos de gran

envergadura, capaces de adaptar la realidad del MHRD al sistema SAP y que conociendo las mejoras practicas

empleadas en otras organizaciones, pueden ofrecer alternativas que mejoren los procesos de negocios

actuales del MHRD.

Una vez cumplida nuestra fase de implementación, MHRD disfrutará de un equipo interno entrenado,

autonomía en el manejo del sistema a nivel de usuario final, minimización del rechazo al cambio a una

plataforma tecnológica nueva, procesos de negocio propios definidos en SAP.

ADQUISICION DE APLICACIÓN TECNOLOGICA PARA EL ...

Documents

Transcript of ADQUISICION DE APLICACIÓN TECNOLOGICA PARA EL ...