PROCESOS OPERATIVOS

Macroproceso de otorgamiento de pensiones

Orientación y Pago de
Verificación de Precalificación Calificación de
Recepción de pensiones y
Aportes de Solicitudes Solicitudes
Trámites bonos

Pago de
Línea de Flujo pensiones y
bonos

Administración de Aportes Inspección y Fiscalización Atención al Asegurado

CONCEPTO DEFINICIÓN

ACP Archivo Control de Planillas

AFP Administradores de Fondo de Pensiones

AP Archivo de Planillas

BDAI Base de Datos de Alertas de Irregularidad

BDEI Base de Datos de Empleadores Irregulares

BPM Business Process Management

BPMN Business Process Model and Notation

CCR Control de Calidad de Recepción

CIAD Centro de Información y Atención para la Desafiliación

CS Contratista del Servicio

DIN Dirección de Inversiones

DPR Dirección de Producción

DSO Dirección de Servicios Operativos

EPC Event-driven Process Chain

FONAHPU Fondo Nacional de Ahorro Público

FRIDI Formato de Registro de Información de Documentos Idóneos

FRIPS Formato de Registro de Información de Pruebas Supletorias

FTT Formato de Trámite Terminado

CONCEPTO DEFINICIÓN

Fuente que administra la información de los aportes de cada asegurado. Contiene

HOST
información de 1992 a 1999.

LDI Libre Desafiliación Integrado

MAF Modulo de Afiliación Facultativa. Sustituye al Modulo de Inscripción Facultativa

MAI Modulo de Archivo Integrado

MCCIA Modulo de Consulta de Cuenta Individual de Aportes

MIF Modulo de Inscripción Facultativa

MOF Manual de Organización y Funciones

MRT Módulo de Registro de Tiempos

NMR Nuevo Módulo de Recepción

NSAB Nuevo Sistema de Archivo de Bonos de Reconocimiento

NSBR Nuevo Sistema de Bonos de Reconocimiento

NSGA Nuevo Sistema de Gestión de Archivos

NSGP Nuevo Sistema de Generación de Plantillas

NSP Nuevo Sistema de Pensiones

NSTD Nuevo Sistema de Trámite Documentario

OAJ Oficina de Asesoría Jurídica

ONP Oficina Normalización Previsional

Orcinea Sistema de Cuenta Individual

OyR Orientación y Recepción

PDT Programa de Declaración Telemática

PECAS Nuevo sistema de precalificación que se encuentra en estado de prueba

Plantillas de
Accidentes de Trabajo y Enfermedades Profesionales
18846

PLAP Plataforma de Atención al Público

PSV Proveedor Servicio de Verificación

RCPJ Registro de Control de Procesos Judiciales

Reflection Sistema de SUNAT que contiene información desde 1999 en adelante

RENIEC Registro Nacional de Identificación y Estado Civil

RESIT Reporte Situacional

CONCEPTO DEFINICIÓN

RIA Registro Individual de Asegurados

ROF Reglamento de Organización y Funciones

SAA Sistema de Administración de Accesos

SAC Sistema de Archivo Central

SACP Sistema de de Archivo Central de Planillas

SAE Sistema de Administración de Empleadores

SBC Sistema de Bono Complementario

SBS Superintendencia de Banca, Seguros y AFP

SCIEA Sistema de Cuenta Individual de Empleadores y Asegurados

SCLIR Sistema de Consulta Libapo, IMT, Resoluciones

SCP Sistema de Control de Plantillas

SCTR Seguro Complementario de Trabajo de Riesgo

SEC Sistema de Emisión de Certificados

SGC Sistema de Gestión de Colas

SGCP Sistema de Gestión y Control de Plantillas

SISREC Sistema de Recaudación

SNP Sistema Nacional de Pensiones

SOA Arquitectura Orientada a Servicios

SPP Sistema Privado de Pensiones

STD Sistema de Trámite Documentario

SUNARP Superintendencia Nacional de los Registros Públicos

SUNAT Superintendencia Nacional de Administración Tributaria

T-Registro Sistema de Registro de Derechohabiente de pensionistas de SUNAT

TUPA Texto único de Procedimiento Administrativo

VISDOC Visualizador de documentos plantillas micrograbadas

BPM, GESTIÓN, INFORMÁTICA, PROCESO, SAP

As-is; To-Be; Gap

Este artículo corresponde en parte a discusiones técnicas con
mis colegas de Embotelladora Andina y refleja mi opinión
respecto a los modelos As-Is y To-Be más el análisis de GAP.

Primero es necesario tener en consideración que estas

discusiones se originan por causa del transcurso del tiempo, al
igual que uno los sistemas envejecen y requieren ser
actualizados funcionalmente. Luego la pregunta es ¿Cómo
actualizo funcionalmente mis sistemas? Asunto que intentaré
responder a continuación[1].

La necesidad de la actualización funcional se presenta cuando

se está trabajando varios años con un mismo sistema, que se
ha actualizado técnicamente, se han instalado las nuevas
versiones del software. Pero, no se usan extensivamente las
nuevas funciones que incluye este nuevo software y, por otra
parte el portafolio de proyectos se comienza a llenar de
muchas iniciativas de “mejoramientos”. La conclusión es: los
sistemas requieren un mejoramiento de mayor alcance o
profundidad.

El plantearse este mejoramiento o puesta al día tiene varias

implicancias:

 Los sistemas en uso se implementaron con una tecnología

distinta a la hoy en boga, entiéndase BPM. Es decir se
diseñaron a partir del concepto funcional: Área Organizativa /
Módulo de Software.
 No existe mucha seguridad que la documentación del
sistema refleje la realidad actual.
 La actualización, con toda seguridad, ocupará la disciplina
BPM y el concepto Proceso de Negocios.
 Lo más probable es que la organización no esté dispuesta a
ejecutar un proyecto con una estrategia Big Band,
básicamente por una cuestión de costos. Esto obliga a una
estrategia de implementación que denomino “Cambiar la
 Rueda en Marcha”[2], es decir implementar los nuevos
procesos de negocios mientras los sistema originales –
antiguos- siguen funcionando y, todo esto en un
mismo landscape.
 Dado que los sistemas antiguos tienen un diseño funcional,
se mapean directamente uno es a uno con las área
organizacionales. Cuestión que no ocurre con los procesos
de negocios, que generan una estructura organizacional
matricial, y esto provoca, sin lugar a dudas, un conflicto de
poderes –político- no menor.
 Si la empresa tiene filiales, plantas u operaciones en distintos
lugares o países lo más típico es que teniendo el mismo
software, se tienen implementaciones distintas de acuerdo
con los criterios de los gerentes.

Estrategia Cambio de Rueda en Marcha

Esta estrategia es válida para una empresa que opera un ERP

con sistemas adicionales como CRM, SCM y sistemas legados,
todos estos sistemas con algún grado importante de
interconexiones. Es decir es para una empresa de tamaño
grande con una infraestructura informática compleja que
justifica una estrategia como la que describiré a continuación.

Características

Esta estrategia corresponde a las de tipo Evolutivo por

Proceso[1], cuyas características principales son:

Fortalezas

 Permite un enfoque en profundidad y sistemático.

 Cambio Organizacional suave.

Debilidades

 Realización lenta de los beneficios.

 Se generan cambios en los procesos debido al paso del
tiempo.
Básicamente esta estrategia se aplica a un proceso de
negocios End-To-End, por ejemplo: Order-to-Cash, Procure-to-
Pay, etc.

Pre-Requisitos

Para que esta estrategia efectivamente pueda aplicarse

exitosamente es necesario contar con:

 Una directriz del Directorio y la Gerencia General que señale

que la empresa re-implementará sus sistemas informáticos
utilizando la disciplina BPM.
 Un Mapa de los Procesos de Negocios oficial.
 Un área Informática con personal capacitado en BPM y que
conozca los procesos de negocios de su empresa en
profundidad (detalles operativos).
 Una estructura metodológica que incluya: la Enterprise
Architecture, La estrategia BPM (la que presento en este
artículo), Gestión de Portafolio y Metodología para la
Implementación de Procesos de Negocios.
 Un plan de Gestión de Cambio.

A mi juicio, lo que importa es contar con estos elementos

independientemente del área organizativa que los provee.

Modelo

Este modelo se aplica a un proceso de negocios End-To-End y

su estructura general es:

Estrategia Cambio Rueda en Marcha

Etapa AS-IS

Este es uno de los aspectos que siempre está en discusión[2],

ya que existen opiniones a favor y en contra respecto a si es
necesario generar los modelos As-is, mi opinión es que es
indispensable generar estos modelos debido a que:

 Ayuda a generar un alineamiento y entendimiento entre las

distintas áreas y locaciones de la empresa en cuanto a cómo
efectivamente se ejecuta el proceso de negocios. A menudo
en las organizaciones grandes muchos ejecutivos y usuarios
claves no tienen la visión completa de cada uno de los pasos
y detalles de la operación del proceso de negocios. La
documentación del As-Is ayuda a generar claridad respecto a
cómo se ejecutan las cosas y cuáles son los des
alineamientos.
 Ayuda a introducir los conceptos de BPM a los ejecutivos y a
los usuarios claves, en particular en el uso de los diagramas
de procesos de negocios (VAC, EPC, etc.)
 Permite establecer los puntos críticos y de mejoramiento del
proceso.
 Afiata el equipo de trabajo del proyecto: Consultores,
Usuarios Claves y Ejecutivos Claves.

Para el levantamiento del proceso As-Is es importante

considerar:

 Que a fin de generar la documentación del As-Is en un

tiempo razonable es necesario tener un método
preestablecido de trabajo y un estándar para modelar.
 Se necesita de herramienta de software para modelar, ojalá
una que maneje objetos como ARIS.
 Es indispensable, una vez generado el modelo As-Is, los
gerentes involucrados en el proceso validen formalmente el
modelo. Esta acción tiene más de una complicación debido a
que a menudo el modelo levantado no corresponde a la
imagen que tienen del mismo los ejecutivos.
 Por último, si su empresa necesita cumplir con alguna
regulación (SoX, Basilea II) o alguna certificación el disponer
 de la documentación de los procesos de negocios
actualizados es una obligación.
 La responsabilidad de generar y mantener actualizados los
modelos As-Is de los procesos de negocios debe estar
formalmente asignada a alguna unidad de la organización.

To-Be

La generación de los modelos To-Be es indispensable para

establecer que se quiere de la nueva implementación, y ayuda
a:

 Definir el nuevo modelo del proceso de negocios

independientemente del software a utilizar. Esto permite
pensar sin restricciones dadas por el software, por la
costumbre, por el personal, etc. cuestión que posibilita
descubrir oportunidades de mejoramiento.
 Al tener los modelos To-Be y los As-Is es factible realizar un
análisis de GAP, que es fundamental para esta estrategia.
 El desarrollo del modelo To-Be permite establecer
Indicadores de Performance –KPI que apoyaran el
mejoramiento del negocio y el accountability.
 Posibilita realizar un efectivo alineamiento de los procesos de
negocios con la estrategia corporativa.

Para la generación del modelo To-Be se pueden trabajar con

los siguientes enfoques:

 Utilizar Mejores Prácticas, que son modelos provistos, en

general, por los fabricantes del software o por alguna otra
organización. La ventaja de su uso es tiempo, costo y que
son modelos probados en la práctica[3]
 Variantes LLL (Legal, Language, Localization),
modificaciones a una Mejor Práctica originadas por un
imperativo legal, una necesidad impuesta por el idioma o por
elementos físicos –no de idiosincrasia- de una locación, por
ejemplo la disponibilidad de un determinado elemento.
 Prácticas Propias, son modelos generados por la propia
organización y que se justifican, dado su alto costo de
generación, cuando el proceso o parte de el –subproceso- no
 está presente en una Mejor Práctica y/o cuando su
implementación genera una ventaja competitiva muy
significativa.

Análisis de GAP

En simple es establecer cuáles son los cambios necesarios de

realizar al proceso actual para actualizarlo al Nuevo modelo.

En esta estrategia es necesario volver a tener en cuenta que el

“Cambio de Rueda es en Mrcha”, esto significa que los ajustes,
modificaciones y adiciones se hacen en el landscape que está
operando. Hecho que significa establecer con mucha precisión
cuales serán los cambios a realizar, cómo y dónde se harán y,
muy principalmente, cuál será el impacto que tendrán

Resumiendo el Análisis de GAP, debe establecer las brechas

en:

 Procesos y Subprocesos
 Parametrizaciones
 Desarrollos propios (existente y nuevos)
 Datos
 Roles
 Responsabilidades
 Documentación
 Performance
 Gobernabilidad

Cada uno de los tópicos anteriores debe ser documentado y en

conjunto constituirán en Business Blue Print que define el GAP
a implementar.

Referencias

[1] SAP Roadmap for BPM