Implantación SAP-PM en ANCAP URUMAN 2005

Montevideo, Uruguay

Implantación del Módulo de

Mantenimiento de Planta SAP-PM

en ANCAP

Ricardo Cosentino

En este trabajo se describe el proyecto de implementación del módulo de

mantenimiento del sistema integrado de gestión SAP en ANCAP. Este proyecto se
inscribe dentro del plan de mejora de gestión para incrementar el margen de
refinación iniciado en el año 2000. El alcance del mismo cubre todo el ciclo de la
gestión del mantenimiento en las instalaciones del área Energía. Se enumeran las
distintas etapas del proyecto, con sus puntos más destacados y los recursos
utilizados.

Ricardo Cosentino Pág. 1

Implantación SAP-PM en ANCAP URUMAN 2005
Montevideo, Uruguay

Introducción
El mantenimiento dentro del área Energía de ANCAP cuenta con siete unidades
ejecutoras: los seis talleres del Departamento de Mantenimiento, que se dedican al
mantenimiento de la Refinería La Teja, y el Departamento de Zonas Exteriores, que
se dedica al mantenimiento del resto de las instalaciones (Terminal del Este,
plantas de distribución y estaciones de servicio propias). Ver organigrama parcial en
el Anexo 1.
Previo a la reingeniería, se procesaban diversas solicitudes de mantenimiento que
eran priorizadas, planificadas y programadas en cada una de las distintas unidades
ejecutoras. Esta descentralización implicaba que no había un criterio común y
carente de subjetividad para todos los talleres, generándose por lo tanto grandes
desequilibrios en el cumplimiento de las solicitudes de trabajo. Ver en el Anexo 1
las relaciones entre solicitantes y ejecutores indicado en líneas de trazos.
Se contaba con un sistema informático para la gestión del mantenimiento de rutina
(SIMAN) desarrollado por una firma argentina de software y adaptado a las
necesidades de ANCAP. Este sistema se comunicaba mediante interfases con el
sistema de materiales de SAP R/3 y con el sistema general de abastecimiento
(SAGA, desarrollado internamente en ANCAP). Estas sincronizaciones se
realizaban mensualmente a los efectos de asociar los materiales consumidos por
las órdenes de trabajo, y a su vez traspasar los costos de mano de obra y
materiales al SAGA.
Las solicitudes de mantenimiento de rutina se dividía en dos clases, de acuerdo con
las horas hombre estimadas para la solución del problema. De esta forma, los
trabajos livianos, de hasta 8 HH se denominaban “services”, no se priorizaban
según la matriz de riesgo (se explica a continuación), y se gestionaban en un
módulo aparte del SIMAN más ágil, registrando menos información que las
órdenes.
También se diferencia la gestión del mantenimiento de rutina de la gestión que se
realiza durante las paradas de planta. Estas paradas son actualmente cada cuatro
años y debido al costo por lucro cesante de las unidades detenidas, se trabaja con
una intensidad tal que prácticamente se cuadruplica la ejecución con respecto al
mantenimiento de rutina. Para este pico de trabajo se recurre a contratos puntuales
de terceros, y las tareas del camino crítico se ejecutan en régimen de 24x7.
Para dar una idea de la carga de trabajo, se registraban anualmente unas 3.000
órdenes de trabajo de rutina y unos 5.000 services, mientras que durante la parada
de planta, que duran alrededor de 45 días, se registraban casi 7.000 tareas.

RAM
En el año 2000 se comenzó a ejecutar un proyecto de mejora del margen de
refinación con el apoyo de la consultora KBC Advanced Technologies, que
abarcaba varias áreas de la División Industrialización Combustibles y Lubricantes.

Ricardo Cosentino Pág. 2

Implantación SAP-PM en ANCAP URUMAN 2005
Montevideo, Uruguay

En particular el subproyecto RAM (Reliability, Availability and Maintenance) se

centró en el análisis de la gestión de Mantenimiento.
Los principales pilares sobre los que se basó la reingeniería encarada dentro del
RAM son:
a) el establecimiento de una matriz para la selección de trabajos en base al
riesgo;
b) la centralización de la planificación y programación del mantenimiento;
c) el aumento de la comunicación estableciendo un área de coordinación de
mantenimiento dependiente de la Gerencia de Refinería y Terminales
(Operaciones);
d) la creación de un grupo de confiabilidad;
e) la creación de un grupo dedicado exclusivamente a la planificación y
programación de las paradas de unidades.

La primera medida que recomendó KBC fue la de implantar una matriz que fijara el
criterio para priorizar los trabajos que se solicitaban a mantenimiento. Se denominó
internamente la “matriz de riesgo”, que para evaluar la prioridad tiene en cuenta las
consecuencias potenciales de no realizar el trabajo, y la probabilidad de que ello
ocurra dentro de un plazo determinado. Por lo tanto al priorizar los trabajos con la
matriz se está utilizando una herramienta objetiva que no depende del solicitante ni
del ejecutor. De la aplicación de este sistema, luego de cuatro años de instalada la
matriz, se puede observar un abatimiento asintótico sensible del costo de
mantenimiento, que junto con la aplicación de las otras recomendaciones de la
consultora mejoraron la disponibilidad mecánica de la planta.
Este sistema se aplicaba a las órdenes de trabajo y no a los services por la poca
envergadura de cada una de estas intervenciones. Al comenzar a analizarse los
trabajos con el filtro que suponía la matriz, se empezaron a observar desviaciones
de órdenes hacia los services (algunos solicitantes “ingeniosos” fraccionaban el
trabajo en varios services, burlando de esta manera el sistema de priorización).
Esto generó una sobrecarga de las cuadrillas destinadas a la ejecución de services,
las que se debían reforzar en detrimento del cumplimiento de las órdenes
“legalmente” priorizadas.
Junto con la implementación de la matriz de riesgo, se formó el grupo que se
dedicaría a la planificación y programación centralizada de las órdenes de trabajo
(denominado internamente PyP). Este grupo estaba integrado por seis supervisores
seleccionados de los talleres (dependientes de Técnica) y se capacitaron junto con
los cuatro coordinadores de mantenimiento (dependientes de Operaciones,
denominado internamente CM) durante dos meses. El entrenamiento del grupo en
su conjunto sentó las bases para un trabajo en equipo realmente admirable que
continúa hasta el día de hoy. Aquí comenzó uno de los cambios culturales más
profundos.
La manera de operar era, sintéticamente, la siguiente: se generaba una solicitud de
trabajo por parte de los coordinadores, quienes establecían la prioridad del mismo
de acuerdo con la matriz de riesgo. Las solicitudes procesadas por los CM se
pasaban diariamente a PyP en breves reuniones de coordinación. Los
planificadores tomaban estas solicitudes y creaban las órdenes de trabajo

Ricardo Cosentino Pág. 3

Implantación SAP-PM en ANCAP URUMAN 2005
Montevideo, Uruguay

elaborando un plan, consistente en una secuencia de tareas a ejecutar por las

diversas especialidades de mantenimiento, y se confeccionaba la lista materiales.
PyP se encargaba de las compras de los materiales que no figuraban en almacén.
Este hecho también mejoraba la relación con Compras, quién ahora tenía un único
interlocutor (anteriormente debía tratar con cada Jefe de Taller).
La planificación de los trabajos y su posterior programación se realizaban en MS
Excel, sobre el servidor que corría el SIMAN. Esta tarea resultaba sumamente
tediosa y requería múltiples iteraciones de los planificadores para reflejar las
actualizaciones que cada uno realizaba en planes que involucraban varios talleres.
Semanalmente se realizaban reuniones de coordinación de CM con PyP y con
Mantenimiento, donde se procedía a la programación de los trabajos para la
semana siguiente. De esta manera cada taller conocía de antemano que trabajos
realizaría, con la seguridad de contar con todos los materiales. Aquí estamos frente
a otro cambio cultural, el ejecutor se enfoca y se concentra en su función, y no en
planificar, programar, comprar, coordinar, etc. Ver el organigrama reducido del
Anexo 2, y observar la comunicación entre las áreas nuevas: CM y PyP, y la
presencia de la Matriz de Riesgo.
En la refinería hay miles de equipos instalados, y como en todos los órdenes de la
vida, se cumple el principio de Pareto, por lo tanto, existe un grupo reducido de
equipos que son los que se llevan gran parte del costo de mantenimiento. Estos
equipos son los denominados “malos actores” (bad actors) y en ellos se concentró
inicialmente el flamante grupo de mejora de la confiabilidad.
Para la planificación y programación de la parada de planta se utilizó por
recomendación de la consultora un software específico (Primavera Project Planner,
P3 Ver. 3.1) que es el estándar en la industria. Este software domina el nicho de la
gestión de proyectos de paradas de unidades en industrias intensivas en activos,
como ser las petroquímicas, plantas de generación, etc. Durante el mes anterior a
la primera parada de planta gestionada con P3 y el mes y medio propio de la
ejecución se contrató un experto argentino en la operación del software.
El programa permitió tener un control de la parada como nunca antes se había
logrado, permitiendo la anticipación de múltiples conflictos de recursos e
interferencias. Se estima que debido a esta mejora en la coordinación se consiguió
devolver la planta a Operaciones dos días antes de lo que era tradicional. Con esto
se logró el repago con muy amplio margen de la inversión en el software y el grupo
que se dedicó a la planificación de la parada.
Para llevar el control de la gestión se estableció un conjunto de indicadores claves
de medición de desempeño (KPIs). Tal como lo habían advertido los consultores,
pronto se vio que era muy dificultoso llevar estos indicadores con el sistema
existente de gestión, por lo que se comenzaron a estudiar las alternativas de
sistemas informáticos de gestión de mantenimiento (CMMS) existentes en el
mercado. Luego de varias instancias de evaluación de los principales actores de
clase mundial en este ramo de la industria, se seleccionó el módulo de
mantenimiento de plantas (PM) de SAP, sistema integrado del cual ANCAP ya tenía
implementados los módulos de costos, de activo fijo y de materiales.

Ricardo Cosentino Pág. 4

Implantación SAP-PM en ANCAP URUMAN 2005
Montevideo, Uruguay

Proyecto SAP-PM
El módulo PM tal como se necesitaba para consolidar la implantación del modelo de
gestión iniciado con KBC, interactuaba fuertemente con los módulos ya existentes
de materiales (MM), costos (CO), activo fijo (AA), pero se necesitaba aún ampliar la
implementación del módulo MM incorporando la gestión de abastecimiento. Luego a
nivel corporativo se incluyó también el módulo de finanzas (FI) y la solución de
presupuesto (IS-PS-FM) para la administración pública.
El objetivo de este proyecto era contribuir a la mejora del margen de refinación
dando soporte a la gestión y control del mantenimiento mediante el uso de un
sistema informático integrado de clase mundial. Se buscaba mejorar la gestión de
los activos y mejorar el control contable, sus precios de compra y depreciaciones.
Se debía avanzar hacia el mantenimiento preventivo, reduciendo el dominante
mantenimiento correctivo, para lo cual el sistema debía permitir la planificación y
programación de estas tareas sobre base horaria, calendario o a condición.
Se deseaba centralizar las referencias documentarias, tanto de los activos como de
los procedimientos.
El sistema integrado, maneja de manera transparente para el usuario la
sincronización en línea con los datos de costos, pudiendo actualizarlos en tiempo
real.
De la misma manera, la integración con materiales, tanto para la gestión del stock
como del abastecimiento, resulta de una importancia fundamental en el ahorro de
tiempo de planificación y ejecución.
Finalmente, para poder tener el control de la gestión, se deseaba una herramienta
que pudiera proveer un fácil acceso a los indicadores claves de rendimiento
previamente definidos.

Fases del proyecto

El proyecto se dividió en cinco fases bien diferenciadas:

1. Selección y capacitación del grupo de trabajo

2. Desarrollo del modelo conceptual
3. Parametrización, carga de datos y pruebas
4. Capacitación de usuarios y puesta en productivo
5. Mejora continua

Fase I
En esta primera etapa se integró el grupo que iba a trabajar en la implementación
del módulo de mantenimiento con 5 usuarios referentes y 8 usuarios funcionales.
El grupo de usuarios referentes estaba integrado por 2 Gerentes y 3 Jefes de
Departamento, que tenían dedicación part-time para la toma de decisiones
estratégicas.

Ricardo Cosentino Pág. 5

Implantación SAP-PM en ANCAP URUMAN 2005
Montevideo, Uruguay

El grupo de usuarios funcionales estaba integrado por 1 jefe de turno de

operaciones, 5 ingenieros de mantenimiento, 1 supervisor y 1 ayudante técnico. El
equipo se completa con los programadores y analistas de procesos y de seguridad.
Este grupo tenía dedicación full-time.
La capacitación abarcó a los módulos de PM y MM dada la gran interrelación que
surgía entre ambos en esta implementación, y se dictaron los cursos a 16 personas
durante 3 semanas.

Fase II
Esta fase duró 16 semanas e involucró en promedio a 10 personas full-time, es
decir que se debieron incorporar 2 personas más al grupo con dedicación total.
Se formaron 2 subgrupos
SOLICITUD DE REPARACIÓN que se dedicaron respectiva-
SOLICITUD DE REPARACIÓN
OPERACIONES
COORDINADORES DE PLANIFICACIÓN Y
TALLERES
mente al análisis de proce-
COORDINADORES DE PROGRAMACIÓN
MANTENIMIENTO PLANIFICACIÓN Y
OPERACIONES
MANTENIMIENTO PROGRAMACIÓN
TALLERES sos y al análisis de datos
maestros, que son básica-
Necesidad Aviso de Avería Aviso de Avería Aviso de Avería
Necesidad Aviso de Avería Aviso de Avería Aviso de Avería mente todos los datos que
van a poblar las tablas de la
Guardia/ Guardia/ base de datos de PM, y sus
MBO?
Guardia/ MBO?
Guardia/
MBO? MBO?
Requiere
relaciones.
Sí
SI
SI
Plan?
Requiere
Plan?
El grupo que analizó los
Sí
Sí procesos identificó alrededor
Sí
Aviso de Medida
No de mantenimiento
Aviso de Medida
Evaluación
RBWS + G3
Evaluación Planificar
de 20 procesos, de los
No
No de mantenimiento RBWS + G3 OT
Planificar
OT
No cuales 4 eran los principales
Registrar Aviso
de Medida Aviso
(nuevamente Pareto) y
Registrar
de Medida
Paro? Es G° 3?
fueron los que se atacaron
No

Aviso de Avería
No
Paro? Es G° 3? primero. Se realizaron
Aviso de Avería No
No
Si múltiples iteraciones con
Si
Sí
Sí
Crear Orden de Modifica Ejecución diagramas de flujo, apelando
Trabajo
Crear Orden de No PST
Modifica PST
Ejecución
Emergencia
G°1Emergencia
o G°2?
Trabajo No (Semana PST
Corriente)
(Semana
(misma
PST
semana)
(misma
en algunos casos a sesiones
G°1 o G°2?
Backlog
Corriente) semana) de tormenta de ideas,
de Avisos
Sí
Sí
Backlog
dede
Paro
Avisos
PST
Ejecución cuando se debieron
de Paro O.T.
G°1, G°2,? G°1
(Próxima
PST
Semana)
(Próxima
Ejecución
(próxima
O.T. replantear algunos procedi-
semana)
(próxima
G°1, G°2,? G°1
Recibe
Semana)
semana) mientos desde cero.
G°2
comunicación
Recibe
comunicación La premisa de este proyecto
G°2
RBWS
fue la de tener cero
Comunica al CM
y al Comunica
Jefe de Taller
al CM
RBWS desarrollo, lo que implicaba
y al Jefe de Taller
Crea / Libera OT Ejecución que SAP se adecuaría en lo
G°1
Crea / Libera OT inmediata
Ejecución
G°1
Tiene Plan
inmediata posible a los procedimientos
RBWS
Estándar?
Tiene Plan
Estándar?
ya existentes en ANCAP, y
RBWS
Sí también que ANCAP se
Sí
Crea / Libera OT
G°2
Crea / Libera OT
Adjunta plan
No
adecuaría a SAP. Sin esta
estándar a la plan
Adjunta OT
G°2
estándar a la OT
No
flexibilidad no se habría
Reelabora PST
Ejecución
PST
Ejecución
logrado cumplir con el
(misma semana)
Reelabora PST (misma
PST
(misma semana) semana)
(misma
semana)

Ricardo Cosentino Pág. 6

Implantación SAP-PM en ANCAP URUMAN 2005
Montevideo, Uruguay

cronograma. Las vertientes por lo tanto eran 3: lo existente en ANCAP, lo

recomendado por KBC y aún no implantado, y lo propio de SAP.

En este punto debemos retomar uno de los temas pendientes más importantes, ya
mencionado, que había quedado sin implementar en el sistema computarizado
anterior: el by-pass de los services a la priorización con la matriz de riesgo.
El tema de la inclusión de los services en la matriz fue uno de los que llevó más
tiempo en analizar y en lograr una solución que fuera operativamente aceptable,
debido al volumen y dinamismo exigido por los mismos.
Aquí se muestra esquemáticamente uno de los diagramas de flujo utilizados en esta
etapa.
Se definían los grandes bloques de procesos y se asignaban responsabilidades.
Luego cada uno de los bloques de proceso era vuelto a analizar hasta llegar a
componentes manejables.
En esta etapa se debía pensar solo en los procesos, y no en el sistema. Luego
cuando llegara el momento de entrar en la fase III se vería cómo se implementa,
pero esto no debía ser un condicionante ahora.
De todos modos, se disponía de un sistema de pruebas, denominado “sandbox”,
para testeo sin límites de la parametrización y los datos.
Se definieron los procesos de los avisos y órdenes de mantenimiento para
solicitudes de mantenimiento correctivo, preventivo, planificación de requerimientos
de materiales (MRP), costeo de órdenes y perfiles de seguridad por grupos de
usuarios.
El grupo que se dedicó al análisis de los datos maestros debió resolver la estructura
organizativa a utilizar para definir la jerarquía de las ubicaciones técnicas y los
equipos, la vinculación con los activos fijos ya existentes, definir los catálogos de
mantenimiento a utilizar en las órdenes que resultan fundamentales al momento de
analizar, y la estructura organizativa para los recursos humanos, agrupados por
puestos de trabajo y sus respectivas capacidades.
Antes de continuar aclararemos la terminología utilizada por SAP. Cuando se
realiza una solicitud de intervención a mantenimiento, se crea un documento en
SAP denominado “Aviso de mantenimiento”. El aviso luego dará origen a una
orden, y se precisa de ambos para gestionar con eficiencia los activos. El aviso se
vincula con el historial del equipo y los catálogos de mantenimiento, y la orden se
vincula con el módulo de costos y el de recursos humanos. Todo aviso se debe
referir a una ubicación técnica (en realidad en inglés es “functional location”, término
que identifica mejor el uso de este campo).
Una ubicación técnica describe en el sistema una función a ser desempeñada.
Luego se precisa un equipo, que físicamente es quién cumple esta función. SAP
entonces define una vinculación entre equipo y ubicación técnica, denominada
“montaje”. De esta manera el sistema maneja la relación entre historiales que se
deben ir con los equipos aunque cambien de ubicación técnica, y la relación entre la
estructura funcional y la de costos.
Ejemplo: en la figura de la página siguiente se puede apreciar la definición de 2
ubicaciones técnicas para 2 bombas, la 2806-J y su alterna la 2806-JA. Se dispone
de 2 equipos para desempeñar esta función de la bomba 2806, una es marca

Ricardo Cosentino Pág. 7

Implantación SAP-PM en ANCAP URUMAN 2005
Montevideo, Uruguay

SULZER y la otra WORTHINGTON. TI-28007

En el ejemplo se aprecia el equipo

WORTHINGTON montado en la
ubicación técnica 2806-JA.
Si en algún momento de su vida, PI-28006

este equipo pasara a otra ubicación I-3

técnica, la historia de su
mantenimiento se la lleva consigo. V-1

Pero mientras se encuentre este 2806-J

equipo montado en esta ubicación

técnica, cada vez que nosotros PI-28008
100001 - SULZER

solicitemos información de I-4

mantenimiento de esta ubicación V-6

nos traerá la de este equipo V-2

WORTHINGTON. 2806-JA
100002 - WORTHINGTON

Las ubicaciones técnicas se UBICACIÓN TÉCNICA EQUIPO

organizan jerárquicamente en
árboles, de manera similar a los directorios de DOS y Windows. El nombre de la
ubicación técnica contiene hasta 40 caracteres, y se define una máscara que
identifica los niveles y subniveles dentro de este árbol. A su vez, se pueden definir
dependencias lógicas y volver a comenzar una nueva máscara en una rama
cualquiera, que con un nombre nuevo generará su propio árbol. El criterio que
adoptamos para las ubicaciones técnicas de las plantas, fue para las ramas básicas
una estructura organizativa que copia el organigrama, y dentro de la Gerencia de
Refinería y Terminales se definió un árbol independiente, con relación funcional
lógica al anterior, cuyos niveles se organizan por unidad productiva, por circuito
(identificado en función de las pantallas del sistema de control distribuido de la
planta) y finalmente las ubicaciones técnicas propias de los equipos. Luego se vio la
necesidad de definir una estructura de tercer nivel en la que se ubicó toda la
instrumentación.
Para la planificación y programación de las órdenes de trabajo es necesario definir
una estructura organizativa para recursos humanos, donde se especifiquen las
jerarquías de los puestos de trabajo y sus capacidades.
La definición de SAP de “Puesto de trabajo” se corresponde con lo que sería un
oficio, que jerárquicamente depende de un “Puesto de trabajo responsable” que
puede agrupar varios oficios de la misma familia, como se muestra en el diagrama
siguiente:

Departamento
Departamento
Mantenimiento
Mantenimiento

Electricidad e
Mecánica Electricidad e Metalurgia Servicios I Servicios II Servicios III
Mecánica Instrumentos Metalurgia Servicios I Servicios II Servicios III
Instrumentos

Mecánico Electricista Cañista

Mecánico Electricista Cañista

Tornero Instrumentista Calderero

Tornero Instrumentista Calderero

Precisión Teléfonos Soldador

Precisión Teléfonos Soldador

Ricardo Cosentino Pág. 8

Implantación SAP-PM en ANCAP URUMAN 2005
Montevideo, Uruguay

Veamos por ejemplo la familia de oficios de Mecánica: tiene el puesto de trabajo

responsable “mecánica”, con los puestos de trabajo “mecánico”, “precisión” y
“tornero”. Son oficios que dependen de la misma jefatura, son especialidades del
mismo taller.
El entregable en esta fase fue un documento denominado “Business blueprint” en el
que se documentaba ordenadamente cada uno de los pasos que se exigirían luego
para la parametrización del sistema. En esta fase se siguió una metodología
denominada ASAP (Accelerated SAP) que guiaba de manera sistemática hacia
donde se debían dirigir los esfuerzos en cada momento.

Fase III
Una vez definidos los procesos y las estructuras de los datos maestros, en esta
tercera etapa se procedió a la parametrización propiamente dicha del sistema y la
carga de datos.
Es interesante el procedimiento que tiene desarrollado SAP para asegurar la
minimización de errores de parametrización: toda la parametrización se realiza en
un mandante independiente, el 200 de la máquina de desarrollo. En este mandante
no hay datos, únicamente se parametriza. Luego la parametrización se debe
“transportar” entre mandantes, tarea que está a cargo de los administradores del
sistema. Los mandantes 100 de producción y 100 de aseguramiento de calidad no
son parametrizables, únicamente contienen datos y reciben la parametrización
transportada desde el 200 de desarrollo. Existe un mandante para pruebas en la
máquina de desarrollo que es el 300, al cual los mismos parametrizadores
transportan sus órdenes.
Para definir los “caminos” que deben recorrer los avisos y las órdenes de trabajo,
SAP permite personalizar lo que se llama “status de usuario”. Básicamente
consisten en la traducción de los diagramas de flujo, en algo así como una
secuencia de banderas (flags) que tienen 2 estados lógicos: encendido o apagado.
Hay 2 clases de indicadores de status de usuario: los numerados y los no
numerados. Los numerados son excluyentes entre sí, es decir que cuando uno se
enciende apaga al que estaba antes encendido. Entre ellos se pueden definir las
secuencias, y los permisos para el activado y desactivado. Los no numerados
pueden coexistir en cualquier estado. En realidad son complementarios de los
numerados.
También una orden va cambiando sus status de sistema a medida que avanza en el
flujo del proceso. Estos status son indicadores automáticos y no se pueden poner y
sacar manualmente. Son de solo lectura.
De la combinación de estos status de usuario y de los status de sistema, se
establece la ubicación de la orden dentro del proceso, y esto es lo que se utiliza al
momento de definir los backlogs (listas de espera).
La orden de mantenimiento es la que recibe los costos operativos de materiales y
de mano de obra (a través de la tarifa definida para cada puesto de trabajo). Las
órdenes pueden liquidar a centros de costos, a activos fijos o a cuentas de mayor.

Ricardo Cosentino Pág. 9

Implantación SAP-PM en ANCAP URUMAN 2005
Montevideo, Uruguay

La interrelación con el módulo de materiales tiene varios puntos de contacto, tanto

en el retiro de materiales almacenados, como en los requerimientos de
abastecimiento, donde se distinguen 2 modalidades: las solicitudes de pedidos de
compra, y las reservas de materiales para el MRP (planificación de los
requerimientos de materiales), quién después se encargará de procesar las
órdenes provisionales generadas, consolidándolas en nuevas solicitudes de pedido.
De la misma manera, hubo muchos procesos que vinculan PM con costos, y aquí
se debe destacar que este proyecto enseñó a trabajar en forma realmente integrada
dentro de la compañía, con horizontes de colaboración mucho más amplios. Ha
sido una oportunidad en la que el trabajo en equipo es un imperativo, si no habría
sido imposible lograr el éxito de la implantación en tiempo y forma de un sistema
tan completo y tan complejo.
Se parametrizó por lo tanto los procesos de reservas de materiales (manuales y
desde las órdenes de trabajo), el MRP para la generación de las órdenes
provisionales, las solicitudes de compra de materiales y servicios desde las órdenes
de mantenimiento y los consumos de materiales desde los almacenes.
Se parametrizaron las funciones de las hojas de ruta, que son las generadoras de
los planes de mantenimiento preventivo y predictivo, para su planificación y
posterior lanzamiento y programación.
Se parametrizaron las estructuras básicas para la gestión de documentos
asociados a las órdenes y a las ubicaciones técnicas y equipos. Esta
documentación estaba ya mayormente radicada en un servidor dedicado a la
Gerencia Técnica, y esta parametrización permitió vincularlos y visualizarlos desde
la misma orden de mantenimiento de SAP. Debemos recalcar nuevamente la
agilidad que brinda para acceder a la información esta integración transparente
para el usuario de toda la documentación asociada a un determinado trabajo: mano
de obra, materiales, costos, planos, procedimientos e historiales.
Se definieron y diseñaron para los programadores en esta etapa también algunos
formularios que se debían trabajar en papel.
Finalmente se definieron los perfiles de seguridad por grupos de usuarios, tarea que
resultó intrínsecamente iterativa entre el grupo parametizador de mantenimiento y el
grupo de seguridad. Era una tarea ardua en la que se trabajaba codo con codo, en
permanente comunicación y coordinación.
Para la carga de datos había dos procedimientos básicos: la entrada manual de
datos y la carga por lotes (batch input). Se utilizaba uno u otro en función de la
cantidad de datos a ingresar.
Una vez parametrizadas las tablas se ingresaron 22.507 ubicaciones técnicas y
12.766 equipos. Durante esta fase y por el gran volumen de información manejada
se requirió el apoyo de personal de alto nivel de la Gerencia de Refinería y
Terminales.
A medida que se avanzaba en la parametrización y en la carga de datos, se podían
hacer pruebas cada vez más completas. Las pruebas eran fundamentalmente
internas, pero también hubo varias instancias formales de integración, además de
las informales que se llevaban a cabo casi a diario.
Durante las 16 semanas que duró esta fase, trabajaron en el módulo de
mantenimiento un promedio de 14 personas, mientras que en el global del proyecto

Ricardo Cosentino Pág. 10

Implantación SAP-PM en ANCAP URUMAN 2005
Montevideo, Uruguay

SAP, que abarcaba además los módulos de abastecimiento, costos, activo fijo,
finanzas y presupuesto, con el soporte de la División Sistemas de Información, eran
casi 40 personas.
El entregable en esta etapa no era físico, sino que lo constituía el sistema en sí
mismo, instalado, parametrizado, cargado y probado, listo para lanzarse a la
operación.

Fase IV
Una vez culminada la parametrización se desarrollaron los manuales para los
usuarios y se diseñaron los cursos de capacitación para usuarios. Se dictaron
cursos de mantenimiento durante 4 semanas a un total de 140 funcionarios.
Las habilidades que debían tener los asistentes una vez culminados los cursos
eran: a) poder ingresar un aviso de mantenimiento (antes las solicitudes eran
telefónicas, recibidas centralizadamente en Programación); b) capacidad de realizar
consultas acerca del estado de la solicitud; y c) capacidad de extraer listados y
reportes de los puntos de interés para su área.
La puesta en productivo se realizó en la semana 39 de haber comenzado el
proyecto, y la transición entre en sistema viejo y el nuevo se hizo durante el fin de
semana previo, en jornadas que resultaron muy exigentes. Pero para lograr el
cambio no se podía estar con medias tintas, y se optó por una transición rápida y
contundente, imponiendo de inmediato la dinámica del nuevo sistema.
De acuerdo con experiencias anteriores, se estableció una potente mesa de ayuda,
a la que se podía acceder por vía telefónica o por correo electrónico, además del
apoyo en campo de uno de los ingenieros y un supervisor con dedicación completa
al proyecto.

Fase V
Una vez en productivo, surgieron varios detalles para mejorar. Todo proyecto debe
tener comienzo y fin. Si esto no se tiene en cuenta, siempre se van a encontrar
mejoras que no van a permitir terminarlo nunca. Lo mejor es enemigo de lo bueno.
Aquí se respetó la línea impartida por el Gerente del proyecto de cumplir
absolutamente los plazos y los presupuestos, lo que hizo de este proyecto un éxito
a remarcar.
Para esta fase de mejora continua se creó un grupo denominado “Centro de
competencia” integrado para mantenimiento por una programadora, un analista
(ambos full-time), y dos usuarios clave parametrizadores del módulo.
Se trabaja en permanente contacto y la frecuencia de las reuniones ha disminuido
con el correr del tiempo a medida que el módulo se ha estabilizado.

Ricardo Cosentino Pág. 11

Implantación SAP-PM en ANCAP URUMAN 2005
Montevideo, Uruguay

Conclusiones
El tiempo total de implementación fue de 39 semanas, algo más de 9 meses,
acorde con las estadísticas de SAP para un proyecto de esta envergadura, que se
centran entre 7 y 9 meses.
El grupo destinado para el proyecto osciló entre una base de 10 y un pico de 14
integrantes en distintas fases, y en total se utilizaron 19.000 horas hombre.
Ahora contamos con un apoyo informático de primer nivel para la gestión tal como
lo recomendó la consultora KBC.
Nos permite mantener actualizados en línea los datos de mantenimiento de los
activos de la empresa, y tomar decisiones con muchos más elementos que antes.
Se ha mejorado el sistema de reuniones que antes se operaba sobre papel y luego
se pasaba a los sistemas actualizados manualmente (Excel), mientras que ahora se
hacen directamente sobre el sistema y los cambios que se realizan sobre una orden
y afectan a terceros puestos de trabajo, ya se ve inmediatamente el resultado, sin
lugar a errores.
Esto permite tener un panorama mucho más claro del trabajo a realizar para la
programación de los talleres ejecutores. A su vez la integración transparente con el
módulo de materiales permite visualizar la existencia en stock o las compras
también en tiempo real. Se ha mejorado sensiblemente la calidad de la información,
la comunicación en la empresa, lo que aumenta el rendimiento de los recursos que
a su vez se traduce en una baja de los costos, como se refleja en los indicadores de
la encuesta de desempeño de refinerías Solomon y Associates de la que ANCAP
participa desde 1996.

Autor
Ricardo Cosentino; MBA, IEEM; Ingeniero Industrial opción Mecánica, Universidad
de la República; se desempeñó como Jefe del Taller Metalúrgico de la Refinería La
Teja durante 12 años, interinamente como Jefe de Mantenimiento, y actualmente
como Jefe de Programación y Control; Profesor del Taller de Ayudantía Técnica de
la carrera de Ingeniería Industrial de la Universidad de Montevideo; desarrolló
también actividad profesional independiente.

ANCAP, Refinería La Teja.

Calle Humboldt 3900, La Teja
Montevideo 11900
Tel. 3094501 int. 3715
E-Mail: rcosentino@ancap.com.uy

Ricardo Cosentino Pág. 12

Implantación SAP-PM en ANCAP URUMAN 2005
Montevideo, Uruguay

Anexo 1: Organigrama parcial de la División Industrialización Combustibles y

Lubricantes, y modo de relacionamiento entre las áreas solicitantes y ejecutoras
antes de la reingeniería.

Gerencia División
Industrialización
Combustibles y
Lubricantes

Departamento
Departamento Gerencia Refinería
Gerencia Técnica Planificación y
Lubricantes y Terminales
Control

Programación y
Mantenimiento Ingeniería y Obras Zonas Exteriores Inspección Técnica
Control

Mecánica Operaciones I

Metalurgia Operaciones II

Electricidad e
Operaciones III
Instrumentos

Servicios I Ingenieros

Servicios II Jefes de Turno

Servicios III Jefes de Turno

Jefes de Turno

Ricardo Cosentino Pág. 13

Implantación SAP-PM en ANCAP URUMAN 2005
Montevideo, Uruguay

Anexo 2: Organigrama parcial de la División Industrialización Combustibles y

Lubricantes, y modo de relacionamiento entre las áreas solicitantes y
ejecutoras luego de la reingeniería.

Gerencia División
Industrialización
Combustibles y
Lubricantes

Departamento
Departamento Gerencia Refinería
Gerencia Técnica Planificación y
Lubricantes y Terminales
Control

Programación y Coordinación de
Mantenimiento Ingeniería y Obras Zonas Exteriores Inspección Técnica
Control Mantenimiento

Mecánica Operaciones I

Metalurgia Operaciones II

Electricidad e
Operaciones III
Instrumentos

Servicios I Operaciones IV

Servicios II Ingenieros

Servicios III Jefes de Turno

Ricardo Cosentino Pág. 14

Implantación SAP-PM en ANCAP URUMAN 2005
Montevideo, Uruguay

Anexo 3: Ejemplo de aviso de avería de mantenimiento. Se visualiza la pantalla de

la cabecera del aviso con una ventana emergente del catálogo de
síntomas de averías. Esta clase de avisos genera órdenes de
mantenimiento correctivo.

Ricardo Cosentino Pág. 15

Implantación SAP-PM en ANCAP URUMAN 2005
Montevideo, Uruguay

Anexo 4: Ejemplo de orden de mantenimiento correctivo.

a) Visualización de la cabecera de la orden:

Ricardo Cosentino Pág. 16

Implantación SAP-PM en ANCAP URUMAN 2005
Montevideo, Uruguay

Anexo 4 (cont.)

b) Visualización de las operaciones (tareas) de la orden:

Ricardo Cosentino Pág. 17

Implantación SAP-PM en ANCAP URUMAN 2005
Montevideo, Uruguay

Anexo 4 (cont.)

c) Visualización de los materiales requeridos para la orden:

Ricardo Cosentino Pág. 18