DOCUMENTO DE ESPECIFICACIÓN FUNCIONAL

15159 implementar la conformidad de RO (Prov

significativo) e integrar la Solicitudes Pedidos a
Contratos

Versión V.1

Área Responsable:
División de Tecnología de la Información
Objetivo: Subgerencia Integración TI - Negocio
Proporcionar información Gestión de la Demanda
detallada de los requerimientos
funcionales y no funcionales del Fecha de creación:
sistema, describiendo sus 22/01/2024
características, comportamiento y
reglas de negocio, los cuales han Fecha de actualización:
sido revisados y validados por 23/01/2024
todos los interesados.
Este documento se crea en base
a los requisitos de alto nivel
identificados en la Iniciativa de
Este documento es propiedad del Banco Interamericano de Finanzas, con carácter reservado para uso exclusivo dentro del Banco, no
Negocio solicitada a Tecnología
pudiéndose usar o proporcionar a terceros, constituyendo falta grave el uso no autorizado o la entrega a terceros de esta información,
de la Información. además de la responsabilidad penal subyacente.

Alcance:
Aplica a iniciativas y proyectos
que requieren desarrollo de
software.
ACEPTACIÓN

A través del presente dejo constancia de haber revisado, leído y aprobado el contenido de
la información mostrada en este documento, asimismo asumo la responsabilidad,
normativas y regulaciones inherentes al área que represento.

NOMBRE ÁREA ROL

Samir Berrospi Logística Usuario Líder

Milagros Gonzales Control de Gasto Usuario Impactado

Pedro Javier Aplicaciones TI Usuario impactado

Dayant Solari Diseño de Proceso Usuario Impactado

DOCUMENTO DE ESPECIFICACIÓN FUNCIONAL 2/29

 HISTORIAL DE VERSIONES

FECHA ELABORADO NOMBRE DEL

VERSIÓN REVISADO POR DESCRIPCIÓN
VERSIÓN POR ARCHIVO
1.0 22/01/2024 Jorge Flores Myriam Elaboración de documento de especificación 15159 implementar la
Rodríguez funcional conformidad de RO
(Prov significativo) e
integrar la Solicitudes
Pedidos a Contratos

GLOSARIO DE TERMINOS

TÉRMINO DEFINICIÓN

IBS Sistema Core Bancario

RO Reporte de Operaciones
C.A.V
CC Control de Gastos
C.A.R
BTU

ACEPTACIÓN...................................................................................................................................
HISTORIAL DE VERSIONES............................................................................................................
GLOSARIO DE TERMINOS..............................................................................................................
1. OBJETIVOS Y BENEFICIOS.............................................................................................
1.1 OBJETIVOS........................................................................................................................
1.2 BENEFICIO.........................................................................................................................
2. INTRODUCCIÓN...............................................................................................................
2.1 RESUMEN EJECUTIVO........................................................................................................
2.1 PEDIDO REGULATORIO.......................................................................................................
2.2 SUPUESTOS.......................................................................................................................
2.3 FUERA DE ALCANCE...........................................................................................................
2.4 RESTRICCIONES.................................................................................................................
3. IMPACTO...........................................................................................................................
3.1 PRODUCTO........................................................................................................................
3.2 CANALES...........................................................................................................................
3.3 ÁREAS DE NEGOCIO...........................................................................................................
3.4 APLICACIONES...................................................................................................................
3.5 CADENA DE VALOR.............................................................................................................
DOCUMENTO DE ESPECIFICACIÓN FUNCIONAL 3/29
4. PROCESO AS IS...............................................................................................................
4.1 PROCESO ADECUAR LA WEB DE PEDIDOS: CAMBIOS AL FLUJO E2E....................................................................
5. PROCESO TO BE............................................................................................................
5.1 PROCESO ADECUAR LA WEB DE PEDIDOS: CAMBIOS AL FLUJO E2E..................................................................
6. ESPECIFICACIÓN DE REQUERIMIENTOS FUNCIONALES.........................................
6.1 REQ 001: ADECUAR LA WEB DE PEDIDOS: CAMBIOS AL FLUJO E2E CAMBIOS PARA
COMPRAS MENOR A2 MIL DÓLARES....................................................................................................
6.2 REQ 002: CREAR NUEVO FLUJO PARA COMPRAS CON CONTRATO MARCO Y FLUJO DE
BODY SHOPPING. 20
7. IMPACTO EN APLICACIONES IMPORTANTES.............................................................
7.1 IMPACTO EN LA POSICIÓN DEL CLIENTE - IBS....................................................................
7.2 IMPACTO EN GESTIÓN BANCARIA......................................................................................
7.3 IMPACTO EN MONITOR......................................................................................................
7.4 IMPACTO EN LA CONTABILIDAD.........................................................................................
7.5 IMPACTO EN EL MÓDULO IBS PRÉSTAMOS / CRONOGRAMAS.............................................
7.6 IMPACTO EN REPORTES REGULATORIOS...........................................................................
7.7 IMPACTO EN OTROS REPORTES EXISTENTES......................................................................
8. ESPECIFICACIÓN DE REQUERIMIENTOS NO FUNCIONALES...................................
8.1 IMPACTO EN SISTEMAS EXTERNOS....................................................................................
8.2 DISPONIBILIDAD...............................................................................................................
8.3 VOLUMETRÍA Y PROYECCIÓN............................................................................................
8.4 IMPACTO EN EL CIERRE....................................................................................................
8.5 LOG DE AUDITORÍA..........................................................................................................
8.6 GESTIÓN DE ACCESOS Y PERFILES...................................................................................
8.7 <REQUERIMIENTO NO FUNCIONAL “N”>.............................................................................
9. ANÁLISIS DE DATOS......................................................................................................

DOCUMENTO DE ESPECIFICACIÓN FUNCIONAL 4/29

 1. Objetivos y Beneficios

1.1 Objetivos
 Reducción de tiempos de atención en los requerimientos de compra y
eficiencia en tiempos
1.2 Beneficio
 Mejoras de tiempos de atención en los requerimientos de compra de las áreas
del Banco
 Mejoras en el proceso de conformes: implementación de checklist de
conformes operativos (prevención de fraudes, SI, RO, Arquitectura)
 Mejoras en la política de compras: Actualización de procesos, roles y
responsabilidades.

2. Introducción

2.1 Resumen Ejecutivo

Actualmente existen reprocesos de procedimientos para distintas casuísticas, también existen
reprocesos por errores en la información ingresada, duplicidad operativa. Existen diferentes flujos
de compras no declarados en directivas, procesos de compras nuevas muy prolongadas y
procesos con demasiadas aprobaciones transformando a un proceso lento e ineficiente para la
compra.
Las herramientas que se implementan hoy en día tienen muchos errores de los cuales no valida los
datos ingresados, no brindan trazabilidad, y mucha falta de control.
Lo que se requiere es mejorar los procesos de atención de compras para incrementar la agilidad
manteniendo los controles correspondientes y optimizando los recursos del área generando mayor
valor para la organización

2.1 Pedido Regulatorio

¿Iniciativa regulatoria? Si No x Tipo de observación: R.S. / Oficio SBS

Observación SBS
Fecha límite
SUNAT
implementación:
BCR
Contingencia en caso de no llegar a la fecha
perentoria: Auditoría interna
Auditoría externa
Regulación ASA
Otro:

2.2 Supuestos
- Los prototipos propuestos son referenciales y deberán ser validados en la etapa de
diseño.
- Las modificaciones solo se realizarían bajo las condiciones expresadas en el presente
documento.
DOCUMENTO DE ESPECIFICACIÓN FUNCIONAL 5/29
 2.3 Fuera de Alcance
- Está fuera de alcance cualquier cambio de funcionalidad o de contenido no
especificado en este documento.
2.4 Restricciones
- “No hay impacto en esta sección.”

3. Impacto

3.1 Producto
 ERP

3.2 Canales


3.3 Áreas de Negocio

 Administración
 Compras
 Arquitectura tecnología
 Arquitectura de soluciones
 Gestión de Portafolio y Performance TI
 Gestión Financiera TI
 Control de Gastos

3.4 Aplicaciones
 Web Spring – Cliente Servidor

3.5 Cadena de valor



DOCUMENTO DE ESPECIFICACIÓN FUNCIONAL 6/29

 4. Proceso AS IS
4.1 Proceso Adecuar la Web de pedidos: Cambios al Flujo E2E

DOCUMENTO DE ESPECIFICACIÓN FUNCIONAL 7/29

A continuación el detalle del proceso actual por pantallas:

1. Ingresa a la web Sprint en la opción “Registrar Solicitud”

2. Se muestra la pantalla de registrar la solicitud

3. Se ingresa el detalle

DOCUMENTO DE ESPECIFICACIÓN FUNCIONAL 8/29

 4. Se ingresa un nuevo detalle

5. Se adjunta documentos

6. Se registra el comité

DOCUMENTO DE ESPECIFICACIÓN FUNCIONAL 9/29

 7. En caso si es una solicitud de TI se deberá registrar la información de TI

8. Se visualiza el seguimiento de la solicitud con los estados correspondientes

9. La solicitud a revisión por el supervisor para ello ingresa la opción “Revisar

Supervisor”

DOCUMENTO DE ESPECIFICACIÓN FUNCIONAL 10/29

 10. Se muestra la solicitud a revisión

11. Posteriormente deberá ser revisado por el gestor de presupuesto, en la opción

“Revisar Gestor Presupuesto”

12. Muestra la solicitud con su estado

DOCUMENTO DE ESPECIFICACIÓN FUNCIONAL 11/29

 13. Ingresa al ver el detalle de la solicitud

14. Se ingresa para ver el comité de recursos

DOCUMENTO DE ESPECIFICACIÓN FUNCIONAL 12/29

4.2 Proceso de compras con contrato marco y flujo de body shopping.

DOCUMENTO DE ESPECIFICACIÓN FUNCIONAL 13/29

 5. Proceso TO BE
5.1 Proceso Adecuar la Web de pedidos: Cambios al Flujo E2E

DOCUMENTO DE ESPECIFICACIÓN FUNCIONAL 14/29

4.2 Proceso de compras con contrato marco y flujo de body shopping.

DOCUMENTO DE ESPECIFICACIÓN FUNCIONAL 15/29

 6. Especificación de Requerimientos Funcionales

Lista de Requerimientos Funcionales y/o Historias de Usuario

Cód. Nombre Requerimiento Funcional y/o Historia de Aplicación /
Proceso
Req. / HU Usuario Módulo
REQ 001 Mejorar el Adecuar la Web de pedidos para compras menor a 2 mil Web Spring
proceso dólares
REQ 002 Crear el Crear nuevo flujo para compras con contrato marco y flujo Web Spring
proceso de body shopping.
REQ 003 Mejorar el Automatizar la Generación de OC/OS en estado “En Web Spring
proceso Preparación”

REQ 004 Mejorar el Mejorar la web de pedidos de compra (Invitar / Cotizar Web Spring
proceso Proveedor Cuadro Comparativo)

REQ 005 Mejorar el Migrar las Solicitudes de Pedidos a Contratos Web Spring
proceso

6.1 REQ 001: Adecuar la Web de pedidos para compras menor a 2 mil dólares

Descripción:

Eliminar los siguientes puntos del proceso E2E para compras menores a 2 mil dólares

 Revisión de Tecnología (Pantallas 11, 12 y 13 del proceso As Is)

 Primera revisión de Control de gasto (para los casos no presupuestado)
 Aprobación de equipo de transformación (Pantalla 14 del proceso As Is)

Importante:
 Para las compras que tuvieron estas 3 aprobaciones, se mostraran hasta el pase a
producción de esta mejora, es decir se visualizara y guardara el histórico de estas
aprobaciones.
En el proceso se seguimientos, se estarían retirando esos hitos

Así mismo se deberá realizar las siguientes mejoras:

 Aprobar el presupuesto solo si aumenta el monto con respecto a lo presupuestado es

decir luego del cuadro comparativo.

 Parametrizar el monto para el comité de adquisiciones, se detalla en la siguiente

pantalla:

DOCUMENTO DE ESPECIFICACIÓN FUNCIONAL 17/29

 Todos los procesos de devolución (compra) deberán considerar un despegable con
los motivos, para poder catalogar las observaciones, este despegable deberá ser
administrable, es decir que se pueda incluir los motivos de rechazo en el misceláneo,
dicho despegable tendrá el motivo con todas las opciones administrables:
Cuando el gestor de presupuesto rechaza en la siguiente pantalla:

Aparecerá la pantalla de devolución con la opción del motivo como se muestra

siguiente pantalla :
(adjuntar pantalla de devolución incluyendo el motivo)

Cuando señalan proceso de devolución, se refieren a rechazar la aprobación del

presupuesto, tenemos pantalla de este proceso

 Tener una trazabilidad en el seguimiento de la orden, deberá incluir el flujo de orden

de compra/servicio: Se aclara que la trazabilidad incluye solo las ordenes, no se
deberán considerar NI’s.
En caso la orden sea anulada o cerrada se deberá colocar un campo más en el
seguimiento, denominado Anulado. En caso solo es anulación se deberá incluir los
detalles declarados en la cotización. Y así mismo se deberán tener los estados y la
estructura como se muestran:

DOCUMENTO DE ESPECIFICACIÓN FUNCIONAL 18/29

 Si la orden en un futuro es anulada o cerrada también debe aparecer una nueva casilla
con este nuevo estado, deben figurar todos los estados (incluyendo el estado
Completado si al momento de la visualización del seguimiento se detecta que haya
sido completada la orden y solo si ha sido completada en su totalidad)

Se detalle en el siguiente flujo:

 Mostrar el presupuesto disponible y aviso personalizable, el texto del aviso será un

parámetro del sistema: Dicho texto deberá aparecer en la misma pantalla en el ingreso
de la solicitud (No es un pop up) como se muestra en la siguiente pantalla:

DOCUMENTO DE ESPECIFICACIÓN FUNCIONAL 19/29

.
 Cambios para compras menores a 2 mil dólares
 Monto parametrizable en el mantenimiento del sistema.
 Eliminar la revisión del supervisor (Se mantendrá en el histórico)
 Si en caso la compra no tenga presupuesto pasa por el gestor, se precisa que
aplica para los proyectos sin presupuesto.

Importante:

 Los cambios al flujo no involucran cambios en el registro de la solicitud

de pedido de compras, es decir no se está considerando quitar datos
del registro ni la modificación en la lógica de llenada entre los datos
 No se han considerado cambios en las consultas o exportación de
información, por lo que si un dato es necesario quitar del registro o
producto del cambio de la lógica se descontinúa, este seguirá
apareciendo en las consultar o exportaciones en blanco.

 Automatización de la Generación de OC/OS en estado “En Preparación” compras <2k

Cuando la solicitud de compra esté aprobada y el usuario haya definido la

lógica de actualización de datos asociados a la orden. Se definirá con los
valores por defecto que se complementan en los datos de la pantalla, el
sistema hará el data entry de forma automática registro en algún hito del flujo
de pedidos. Esto es solo para las solicitudes de compra menores a 2 mil

DOCUMENTO DE ESPECIFICACIÓN FUNCIONAL 20/29

 dólares (El importe es un parámetro del sistema reutilizado del cambio del flujo
para compras menores a 2k dólares).

6.2 REQ 002: Crear nuevo flujo para compras con contrato marco y flujo de body
shopping.
Descripción:
Se quiere crear un nuevo flujo para la solicitud de contratos en estado temporal
para que el usuario creador complete los datos de la solicitud de contrato e inicie
su proceso dentro del flujo.

El flujo por seguir para el proceso body shopping sería el siguiente:

El objetivo es hacer un flujo nuevo para integrar con el sistema web spring y
contratos

Detalle:
Para la creación se tomará en consideración 3 módulos:

1. Registro de solicitudes
2. Aprobación de solicitudes
3. Adecuaciones del módulo de contratos
Por lo cual se tendrá el siguiente detalle de cada campo:
1. Registro de solicitudes
 Selección del proveedor.
DOCUMENTO DE ESPECIFICACIÓN FUNCIONAL 21/29
  Selección del contrato marco (control de vigencia).
 Registro del detalle de la solicitud asociada al detalle de commodities
registrado por el usuario en el contrato marco seleccionado, indicando CC,
proyecto y cantidad, como referencia se utilizará el registro del detalle de
solicitudes de pedidos web.
 Cualquier usuario habilitado en Web Spring puede registrar solicitudes
siempre que tenga la opción asignada.
 Edición de solicitudes observadas para su reenvío.
 Todas las solicitudes serán visibles por cualquier usuario, pero solo podrá
editar las que haya tramitado el usuario directamente como solicitante, el
resto solo podrán ser consultadas
 Incluir el seguimiento visual de los estados por los que pasó la solicitud: La
pantalla de registro es nueva ya que no tiene los mismos datos que lo de
pedidos. Los estados para esta vista serán 3, la pantalla de seguimiento es
una vista aparte, el flujo de aprobaciones será la misma que se tendrá en la
web de pedidos
 Envío de correo electrónico para el trámite de aprobación de la solicitud.

2. Aprobación de solicitudes
 Existirá un hito de aprobación a definir en la etapa de análisis (control de
Gastos), siempre debe ser un hito existente en la web de pedidos sin
escalamientos o autonomías.
 Opción de observar o rechazar solicitudes
 Envió de correo electrónico con la observación o rechazo

3. Adecuaciones del módulo de contratos

 Calificación de Contrato Marco
 Incluir el precio unitario a nivel de commodity para la valoración de las
solicitudes.

El nuevo módulo Bodyshopping deberá considerar las siguientes opciones que se

tienen en las solicitudes dentro de la web Spring

 Datos generales
 Detalle
 Adjuntos
 Seguimiento

De los cuales las opciones datos generales, detalle y seguimiento tendrá algunas
mejoras en sus formularios que serán la siguiente:

 El usuario solicitante ingresa los datos generales como: Descripción de

pedido, selección del contrato y valida la vigencia
 El sistema deberá mostrar los contratos, proveedores y vigencia

DOCUMENTO DE ESPECIFICACIÓN FUNCIONAL 22/29

  El usuario solicitante completa el detalle como: Selecciona y añade
item/Comodify (1 a 1), Especifica centro de costo y proyecto por cada item
y detalla cantidades
 El sistema deberá mostrar los ítems/comodify asociados al contrato
seleccionado
 El usuario puede observar el seguimiento incluye estaciones, estado,
nombres de responsables
 El sistema deberá mostrar la trazabilidad

Para el ingreso del nuevo módulo se deberá seguir los siguientes pasos:

1. Ingresa a la web Sprint en la opción “Registrar Solicitud” en el módulo

de contrato Marco

2. Se muestra la pantalla de registrar solicitud

DOCUMENTO DE ESPECIFICACIÓN FUNCIONAL 23/29

 Se deberá tener las siguientes consideraciones de cada campo
mostrado:
Campos de formulario Tipo de campo Detalle
Nombre de la solicitud Texto
Descripción de solicitud Texto
Fecha requerida Valor actual sistema
Bien o Servicio Selección Bien/Servicio
Fecha Entrega Fecha y Hora Solo para Bien
Fecha Inicio Fecha y Hora Solo para Servicio
Fecha Fin Fecha y Hora Solo para Servicio
Tipo de Entrega Selección 1.Almacen / 2. Servicio
Lugar de Entrega Texto Solo para entrega directa
Proveedor(contrato) Buscador Permite buscar con palabras clave debe
permitir seleccionar a un proveedor
N° de contrato Selección Muestra los contratos del proveedor
seleccionado, deberá permitir seleccionar un
contrato
Fecha de vencimiento Valor Fecha Muestra la fecha del contrato seleccionado.
Nota: Si el contrato seleccionado ya se
venció, deberá mostrar debajo del campo
fecha de vencimiento: “Este contrato ya
venció, seleccionar una vigente”. En su
defecto, sírvase a coordinar un nuevo
contrato o renovación de contrato”, Si el
contrato seleccionado ya venció deberá
mostrar los campos siguientes

3. El usuario ingresa el detalle

DOCUMENTO DE ESPECIFICACIÓN FUNCIONAL 24/29

 4. El usuario ingresa un nuevo detalle

Se deberá tener las siguientes consideraciones de cada campo

mostrado:
Campos de formulario Tipo de campo Detalle
Item/Servicio Buscador Permite buscar los ítems / servicios solo
declarados en el contrato seleccionado
Cuenta Contable Buscador El usuario podrá colocar (Lupa)
Proyecto Buscador El usuario podrá colocar (Lupa)
Centro de costo Buscador El usuario podrá colocar (Lupa)
Cantidad Numérico Permite ingresar cantidad
Moneda Numérico Muestra la moneda de la tarifa según contrato
Precio Unitario (Inc.IGV) Numérico Muestra el valor de la tarifa según contrato
(nuevo campo en módulo de contratos)
(Spring cliente)
Descripción Texto Texto (Opcional)
Comentario Texto Texto (Opcional)
Agregar Botón

5. Se adjunta documentos

DOCUMENTO DE ESPECIFICACIÓN FUNCIONAL 25/29

 6. Se visualiza el seguimiento de la solicitud con los estados
correspondientes

Los estados son:

 Preparado
 Pendiente
 Aceptado
 Verificado
 Completado
 Anulado

Módulo de contratos

En el módulo de contratos se requiere:

 Agregar un campo más que muestre el precio unitario del total de cada
item/comodity.
 Cambiar el nombre actual del campo “Precio Unitario” por “Precio PPTO”,
 Especificar si es un contrato macro, para ello se deberá agregar una columna más
para especificar si es o no un contrato macro. Como se muestra en la siguiente
imagen:

DOCUMENTO DE ESPECIFICACIÓN FUNCIONAL 26/29

 7. Impacto en aplicaciones importantes

7.1 Impacto en la Posición del Cliente - IBS

No hay impacto en esta sección.

7.2 Impacto en Gestión Bancaria

No hay impacto en esta sección.

7.3 Impacto en Monitor

No hay impacto en esta sección.

7.4 Impacto en la Contabilidad

No hay impacto en esta sección.

7.5 Impacto en el Módulo IBS Préstamos / Cronogramas

No hay impacto en esta sección.

7.6 Impacto en Reportes Regulatorios

No hay impacto en esta sección

7.7 Impacto en otros reportes existentes

No hay impacto en esta sección

8. Especificación de Requerimientos No Funcionales

8.1 Impacto en Sistemas Externos

No hay impacto en esta sección

8.2 Disponibilidad
Indicar la disponibilidad que va a tener la nueva capacidad funcional, marcar con “x” la que corresponde:

DOCUMENTO DE ESPECIFICACIÓN FUNCIONAL 27/29

 24x7 (L-D) 5x8 (L-V) 6x8 (L-S) Otro:

No hay impacto en esta sección

8.3 Volumetría y Proyección

Aplica para nuevas aplicaciones o nuevas capacidades

<Estimación en la implementación>
 Cantidad de usuarios que van a usar la aplicación:
<Puede expresarse en día, mes.>
 Cantidad de transacciones que va a realizar la aplicación:
<Puede expresarse en día, mes, y debe ser sobre las transacciones de la nueva
capacidad funcional, mas no lo existente.>
 Horas pico:
<Rango de horas con más alta transacción.>
 Fecha de alta transacción:
<últimos días del mes, quincenas, demanda por campañas.>

<Proyección a 3 años, estimación a alto nivel, es decir una aproximación>

 Cantidad de usuarios que van a usar la aplicación:
<Puede expresarse por día, mes.>
 Cantidad de transacciones que va a realizar la aplicación:
<Puede expresarse en día, mes, y debe ser sobre las transacciones de la nueva
capacidad funcional, mas no lo existente.>
 Horas pico:
<Rango de horas con más alta transacción.>
 Fecha de alta transacción:
<últimos días del mes, quincenas, demanda por campañas.>

No hay impacto en esta sección

8.4 Impacto en el cierre

diario mensual anual Otro:

8.5 Log de Auditoría

No hay impacto en esta sección

8.6 Gestión de Accesos y Perfiles

No hay impacto en esta sección.

DOCUMENTO DE ESPECIFICACIÓN FUNCIONAL 28/29
 8.7 <Requerimiento No Funcional “n”>

No hay impacto en esta sección.

9. Análisis de Datos

No hay impacto en esta sección

Proceso: <<Nombre del proceso que se ve afectado con la implementación>>

Datos de Entrada
Campo Valor Validaciones Transformación

Datos de Salida
Campo Valor Validaciones Transformación

DOCUMENTO DE ESPECIFICACIÓN FUNCIONAL 29/29