Implantacin SAP-PM en ANCAP URUMAN 2005

Montevideo, Uruguay

Implantacin del Mdulo de

Mantenimiento de Planta SAP-PM

en ANCAP

Ricardo Cosentino

En este trabajo se describe el proyecto de implementacin del mdulo de

mantenimiento del sistema integrado de gestin SAP en ANCAP. Este proyecto se
inscribe dentro del plan de mejora de gestin para incrementar el margen de
refinacin iniciado en el ao 2000. El alcance del mismo cubre todo el ciclo de la
gestin del mantenimiento en las instalaciones del rea Energa. Se enumeran las
distintas etapas del proyecto, con sus puntos ms destacados y los recursos
utilizados.

Ricardo Cosentino Pg. 1

Implantacin SAP-PM en ANCAP URUMAN 2005
Montevideo, Uruguay

Introduccin
El mantenimiento dentro del rea Energa de ANCAP cuenta con siete unidades
ejecutoras: los seis talleres del Departamento de Mantenimiento, que se dedican al
mantenimiento de la Refinera La Teja, y el Departamento de Zonas Exteriores, que
se dedica al mantenimiento del resto de las instalaciones (Terminal del Este,
plantas de distribucin y estaciones de servicio propias). Ver organigrama parcial en
el Anexo 1.
Previo a la reingeniera, se procesaban diversas solicitudes de mantenimiento que
eran priorizadas, planificadas y programadas en cada una de las distintas unidades
ejecutoras. Esta descentralizacin implicaba que no haba un criterio comn y
carente de subjetividad para todos los talleres, generndose 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 lneas de trazos.
Se contaba con un sistema informtico para la gestin 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 divida en dos clases, de acuerdo con
las horas hombre estimadas para la solucin del problema. De esta forma, los
trabajos livianos, de hasta 8 HH se denominaban services, no se priorizaban
segn la matriz de riesgo (se explica a continuacin), y se gestionaban en un
mdulo aparte del SIMAN ms gil, registrando menos informacin que las
rdenes.
Tambin se diferencia la gestin del mantenimiento de rutina de la gestin que se
realiza durante las paradas de planta. Estas paradas son actualmente cada cuatro
aos y debido al costo por lucro cesante de las unidades detenidas, se trabaja con
una intensidad tal que prcticamente se cuadruplica la ejecucin con respecto al
mantenimiento de rutina. Para este pico de trabajo se recurre a contratos puntuales
de terceros, y las tareas del camino crtico se ejecutan en rgimen 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 das, se registraban casi 7.000 tareas.

RAM
En el ao 2000 se comenz a ejecutar un proyecto de mejora del margen de
refinacin con el apoyo de la consultora KBC Advanced Technologies, que
abarcaba varias reas de la Divisin Industrializacin Combustibles y Lubricantes.

Ricardo Cosentino Pg. 2

Implantacin SAP-PM en ANCAP URUMAN 2005
Montevideo, Uruguay

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

centr en el anlisis de la gestin de Mantenimiento.
Los principales pilares sobre los que se bas la reingeniera encarada dentro del
RAM son:
a) el establecimiento de una matriz para la seleccin de trabajos en base al
riesgo;
b) la centralizacin de la planificacin y programacin del mantenimiento;
c) el aumento de la comunicacin estableciendo un rea de coordinacin de
mantenimiento dependiente de la Gerencia de Refinera y Terminales
(Operaciones);
d) la creacin de un grupo de confiabilidad;
e) la creacin de un grupo dedicado exclusivamente a la planificacin y
programacin 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 aplicacin de este sistema, luego de cuatro aos de instalada la
matriz, se puede observar un abatimiento asinttico sensible del costo de
mantenimiento, que junto con la aplicacin de las otras recomendaciones de la
consultora mejoraron la disponibilidad mecnica 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 supona 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 priorizacin).
Esto gener una sobrecarga de las cuadrillas destinadas a la ejecucin de services,
las que se deban reforzar en detrimento del cumplimiento de las rdenes
legalmente priorizadas.
Junto con la implementacin de la matriz de riesgo, se form el grupo que se
dedicara a la planificacin y programacin centralizada de las rdenes de trabajo
(denominado internamente PyP). Este grupo estaba integrado por seis supervisores
seleccionados de los talleres (dependientes de Tcnica) 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
contina hasta el da de hoy. Aqu comenz uno de los cambios culturales ms
profundos.
La manera de operar era, sintticamente, la siguiente: se generaba una solicitud de
trabajo por parte de los coordinadores, quienes establecan 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 coordinacin. Los
planificadores tomaban estas solicitudes y creaban las rdenes de trabajo

Ricardo Cosentino Pg. 3

Implantacin 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 almacn.
Este hecho tambin mejoraba la relacin con Compras, quin ahora tena un nico
interlocutor (anteriormente deba tratar con cada Jefe de Taller).
La planificacin de los trabajos y su posterior programacin se realizaban en MS
Excel, sobre el servidor que corra el SIMAN. Esta tarea resultaba sumamente
tediosa y requera mltiples iteraciones de los planificadores para reflejar las
actualizaciones que cada uno realizaba en planes que involucraban varios talleres.
Semanalmente se realizaban reuniones de coordinacin de CM con PyP y con
Mantenimiento, donde se proceda a la programacin de los trabajos para la
semana siguiente. De esta manera cada taller conoca de antemano que trabajos
realizara, 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 funcin, y no en
planificar, programar, comprar, coordinar, etc. Ver el organigrama reducido del
Anexo 2, y observar la comunicacin entre las reas nuevas: CM y PyP, y la
presencia de la Matriz de Riesgo.
En la refinera 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 planificacin y programacin de la parada de planta se utiliz por
recomendacin de la consultora un software especfico (Primavera Project Planner,
P3 Ver. 3.1) que es el estndar en la industria. Este software domina el nicho de la
gestin de proyectos de paradas de unidades en industrias intensivas en activos,
como ser las petroqumicas, plantas de generacin, etc. Durante el mes anterior a
la primera parada de planta gestionada con P3 y el mes y medio propio de la
ejecucin se contrat un experto argentino en la operacin del software.
El programa permiti tener un control de la parada como nunca antes se haba
logrado, permitiendo la anticipacin de mltiples conflictos de recursos e
interferencias. Se estima que debido a esta mejora en la coordinacin se consigui
devolver la planta a Operaciones dos das antes de lo que era tradicional. Con esto
se logr el repago con muy amplio margen de la inversin en el software y el grupo
que se dedic a la planificacin de la parada.
Para llevar el control de la gestin se estableci un conjunto de indicadores claves
de medicin de desempeo (KPIs). Tal como lo haban advertido los consultores,
pronto se vio que era muy dificultoso llevar estos indicadores con el sistema
existente de gestin, por lo que se comenzaron a estudiar las alternativas de
sistemas informticos de gestin de mantenimiento (CMMS) existentes en el
mercado. Luego de varias instancias de evaluacin de los principales actores de
clase mundial en este ramo de la industria, se seleccion el mdulo de
mantenimiento de plantas (PM) de SAP, sistema integrado del cual ANCAP ya tena
implementados los mdulos de costos, de activo fijo y de materiales.

Ricardo Cosentino Pg. 4

Implantacin SAP-PM en ANCAP URUMAN 2005
Montevideo, Uruguay

Proyecto SAP-PM
El mdulo PM tal como se necesitaba para consolidar la implantacin del modelo de
gestin iniciado con KBC, interactuaba fuertemente con los mdulos ya existentes
de materiales (MM), costos (CO), activo fijo (AA), pero se necesitaba an ampliar la
implementacin del mdulo MM incorporando la gestin de abastecimiento. Luego a
nivel corporativo se incluy tambin el mdulo de finanzas (FI) y la solucin de
presupuesto (IS-PS-FM) para la administracin pblica.
El objetivo de este proyecto era contribuir a la mejora del margen de refinacin
dando soporte a la gestin y control del mantenimiento mediante el uso de un
sistema informtico integrado de clase mundial. Se buscaba mejorar la gestin de
los activos y mejorar el control contable, sus precios de compra y depreciaciones.
Se deba avanzar hacia el mantenimiento preventivo, reduciendo el dominante
mantenimiento correctivo, para lo cual el sistema deba permitir la planificacin y
programacin de estas tareas sobre base horaria, calendario o a condicin.
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
sincronizacin en lnea con los datos de costos, pudiendo actualizarlos en tiempo
real.
De la misma manera, la integracin con materiales, tanto para la gestin del stock
como del abastecimiento, resulta de una importancia fundamental en el ahorro de
tiempo de planificacin y ejecucin.
Finalmente, para poder tener el control de la gestin, se deseaba una herramienta
que pudiera proveer un fcil acceso a los indicadores claves de rendimiento
previamente definidos.

Fases del proyecto

El proyecto se dividi en cinco fases bien diferenciadas:

1. Seleccin y capacitacin del grupo de trabajo

2. Desarrollo del modelo conceptual
3. Parametrizacin, carga de datos y pruebas
4. Capacitacin 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 implementacin
del mdulo 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 tenan dedicacin part-time para la toma de decisiones
estratgicas.

Ricardo Cosentino Pg. 5

Implantacin 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 tcnico. El
equipo se completa con los programadores y analistas de procesos y de seguridad.
Este grupo tena dedicacin full-time.
La capacitacin abarc a los mdulos de PM y MM dada la gran interrelacin que
surga entre ambos en esta implementacin, 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 ms al grupo con dedicacin total.
Se formaron 2 subgrupos
SOLICITUD DE REPARACIN que se dedicaron respectiva-
SOLICITUD DE REPARACIN
OPERACIONES
COORDINADORES DE PLANIFICACIN Y
TALLERES
mente al anlisis de proce-
COORDINADORES DE PROGRAMACIN
MANTENIMIENTO PLANIFICACIN Y
OPERACIONES
MANTENIMIENTO PROGRAMACIN
TALLERES sos y al anlisis de datos
maestros, que son bsica-
Necesidad Aviso de Avera Aviso de Avera Aviso de Avera
Necesidad Aviso de Avera Aviso de Avera Aviso de Avera 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
Evaluacin
RBWS + G3
Evaluacin 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 Avera
No
Paro? Es G 3? primero. Se realizaron
Aviso de Avera No
No
Si mltiples iteraciones con
Si
S
S
Crear Orden de Modifica Ejecucin diagramas de flujo, apelando
Trabajo
Crear Orden de No PST
Modifica PST
Ejecucin
Emergencia
G1Emergencia
o G2?
Trabajo No (Semana PST
Corriente)
(Semana
(misma
PST
semana)
(misma
en algunos casos a sesiones
G1 o G2?
Backlog
Corriente) semana) de tormenta de ideas,
de Avisos
S
S
Backlog
dede
Paro
Avisos
PST
Ejecucin cuando se debieron
de Paro O.T.
G1, G2,? G1
(Prxima
PST
Semana)
(Prxima
Ejecucin
(prxima
O.T. replantear algunos procedi-
semana)
(prxima
G1, G2,? G1
Recibe
Semana)
semana) mientos desde cero.
G2
comunicacin
Recibe
comunicacin La premisa de este proyecto
G2
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 Ejecucin que SAP se adecuara en lo
G1
Crea / Libera OT inmediata
Ejecucin
G1
Tiene Plan
inmediata posible a los procedimientos
RBWS
Estndar?
Tiene Plan
Estndar?
ya existentes en ANCAP, y
RBWS
S tambin que ANCAP se
S
Crea / Libera OT
G2
Crea / Libera OT
Adjunta plan
No
adecuara a SAP. Sin esta
estndar a la plan
Adjunta OT
G2
estndar a la OT
No
flexibilidad no se habra
Reelabora PST
Ejecucin
PST
Ejecucin
logrado cumplir con el
(misma semana)
Reelabora PST (misma
PST
(misma semana) semana)
(misma
semana)

Ricardo Cosentino Pg. 6

Implantacin 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 an no implantado, y lo propio de SAP.

En este punto debemos retomar uno de los temas pendientes ms importantes, ya

mencionado, que haba quedado sin implementar en el sistema computarizado
anterior: el by-pass de los services a la priorizacin con la matriz de riesgo.
El tema de la inclusin de los services en la matriz fue uno de los que llev ms
tiempo en analizar y en lograr una solucin que fuera operativamente aceptable,
debido al volumen y dinamismo exigido por los mismos.
Aqu se muestra esquemticamente uno de los diagramas de flujo utilizados en esta
etapa.
Se definan 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 deba pensar solo en los procesos, y no en el sistema. Luego
cuando llegara el momento de entrar en la fase III se vera cmo se implementa,
pero esto no deba ser un condicionante ahora.
De todos modos, se dispona de un sistema de pruebas, denominado sandbox,
para testeo sin lmites de la parametrizacin y los datos.
Se definieron los procesos de los avisos y rdenes de mantenimiento para
solicitudes de mantenimiento correctivo, preventivo, planificacin de requerimientos
de materiales (MRP), costeo de rdenes y perfiles de seguridad por grupos de
usuarios.
El grupo que se dedic al anlisis de los datos maestros debi resolver la estructura
organizativa a utilizar para definir la jerarqua de las ubicaciones tcnicas y los
equipos, la vinculacin con los activos fijos ya existentes, definir los catlogos 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 terminologa utilizada por SAP. Cuando se
realiza una solicitud de intervencin 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 catlogos de mantenimiento, y la orden se
vincula con el mdulo de costos y el de recursos humanos. Todo aviso se debe
referir a una ubicacin tcnica (en realidad en ingls es functional location, trmino
que identifica mejor el uso de este campo).
Una ubicacin tcnica describe en el sistema una funcin a ser desempeada.
Luego se precisa un equipo, que fsicamente es quin cumple esta funcin. SAP
entonces define una vinculacin entre equipo y ubicacin tcnica, denominada
montaje. De esta manera el sistema maneja la relacin entre historiales que se
deben ir con los equipos aunque cambien de ubicacin tcnica, y la relacin entre la
estructura funcional y la de costos.
Ejemplo: en la figura de la pgina siguiente se puede apreciar la definicin de 2
ubicaciones tcnicas para 2 bombas, la 2806-J y su alterna la 2806-JA. Se dispone
de 2 equipos para desempear esta funcin de la bomba 2806, una es marca

Ricardo Cosentino Pg. 7

Implantacin 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
ubicacin tcnica 2806-JA.
Si en algn momento de su vida, PI-28006

este equipo pasara a otra ubicacin I-3

tcnica, la historia de su
mantenimiento se la lleva consigo. V-1

Pero mientras se encuentre este 2806-J

equipo montado en esta ubicacin

tcnica, cada vez que nosotros PI-28008
100001 - SULZER

solicitemos informacin de I-4

mantenimiento de esta ubicacin V-6

nos traer la de este equipo V-2

WORTHINGTON. 2806-JA
100002 - WORTHINGTON

Las ubicaciones tcnicas se UBICACIN TCNICA EQUIPO

organizan jerrquicamente en
rboles, de manera similar a los directorios de DOS y Windows. El nombre de la
ubicacin tcnica contiene hasta 40 caracteres, y se define una mscara que
identifica los niveles y subniveles dentro de este rbol. A su vez, se pueden definir
dependencias lgicas y volver a comenzar una nueva mscara en una rama
cualquiera, que con un nombre nuevo generar su propio rbol. El criterio que
adoptamos para las ubicaciones tcnicas de las plantas, fue para las ramas bsicas
una estructura organizativa que copia el organigrama, y dentro de la Gerencia de
Refinera y Terminales se defini un rbol independiente, con relacin funcional
lgica al anterior, cuyos niveles se organizan por unidad productiva, por circuito
(identificado en funcin de las pantallas del sistema de control distribuido de la
planta) y finalmente las ubicaciones tcnicas propias de los equipos. Luego se vio la
necesidad de definir una estructura de tercer nivel en la que se ubic toda la
instrumentacin.
Para la planificacin y programacin de las rdenes de trabajo es necesario definir
una estructura organizativa para recursos humanos, donde se especifiquen las
jerarquas de los puestos de trabajo y sus capacidades.
La definicin de SAP de Puesto de trabajo se corresponde con lo que sera un
oficio, que jerrquicamente 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
Mecnica Electricidad e Metalurgia Servicios I Servicios II Servicios III
Mecnica Instrumentos Metalurgia Servicios I Servicios II Servicios III
Instrumentos

Mecnico Electricista Caista

Mecnico Electricista Caista

Tornero Instrumentista Calderero

Tornero Instrumentista Calderero

Precisin Telfonos Soldador

Precisin Telfonos Soldador

Ricardo Cosentino Pg. 8

Implantacin SAP-PM en ANCAP URUMAN 2005
Montevideo, Uruguay

Veamos por ejemplo la familia de oficios de Mecnica: tiene el puesto de trabajo

responsable mecnica, con los puestos de trabajo mecnico, precisin 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 exigiran luego
para la parametrizacin del sistema. En esta fase se sigui una metodologa
denominada ASAP (Accelerated SAP) que guiaba de manera sistemtica hacia
donde se deban 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 parametrizacin propiamente dicha del sistema y la
carga de datos.
Es interesante el procedimiento que tiene desarrollado SAP para asegurar la
minimizacin de errores de parametrizacin: toda la parametrizacin se realiza en
un mandante independiente, el 200 de la mquina de desarrollo. En este mandante
no hay datos, nicamente se parametriza. Luego la parametrizacin se debe
transportar entre mandantes, tarea que est a cargo de los administradores del
sistema. Los mandantes 100 de produccin y 100 de aseguramiento de calidad no
son parametrizables, nicamente contienen datos y reciben la parametrizacin
transportada desde el 200 de desarrollo. Existe un mandante para pruebas en la
mquina 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. Bsicamente
consisten en la traduccin de los diagramas de flujo, en algo as como una
secuencia de banderas (flags) que tienen 2 estados lgicos: 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.
Tambin una orden va cambiando sus status de sistema a medida que avanza en el
flujo del proceso. Estos status son indicadores automticos y no se pueden poner y
sacar manualmente. Son de solo lectura.
De la combinacin de estos status de usuario y de los status de sistema, se
establece la ubicacin 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 travs 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 Pg. 9

Implantacin SAP-PM en ANCAP URUMAN 2005
Montevideo, Uruguay

La interrelacin con el mdulo 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 (planificacin de los
requerimientos de materiales), quin despus se encargar de procesar las
rdenes provisionales generadas, consolidndolas 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 compaa, con horizontes de colaboracin mucho ms amplios. Ha
sido una oportunidad en la que el trabajo en equipo es un imperativo, si no habra
sido imposible lograr el xito de la implantacin 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 generacin 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 planificacin y
posterior lanzamiento y programacin.
Se parametrizaron las estructuras bsicas para la gestin de documentos
asociados a las rdenes y a las ubicaciones tcnicas y equipos. Esta
documentacin estaba ya mayormente radicada en un servidor dedicado a la
Gerencia Tcnica, y esta parametrizacin permiti vincularlos y visualizarlos desde
la misma orden de mantenimiento de SAP. Debemos recalcar nuevamente la
agilidad que brinda para acceder a la informacin esta integracin transparente
para el usuario de toda la documentacin asociada a un determinado trabajo: mano
de obra, materiales, costos, planos, procedimientos e historiales.
Se definieron y disearon para los programadores en esta etapa tambin algunos
formularios que se deban trabajar en papel.
Finalmente se definieron los perfiles de seguridad por grupos de usuarios, tarea que
result intrnsecamente 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 comunicacin y coordinacin.
Para la carga de datos haba dos procedimientos bsicos: la entrada manual de
datos y la carga por lotes (batch input). Se utilizaba uno u otro en funcin de la
cantidad de datos a ingresar.
Una vez parametrizadas las tablas se ingresaron 22.507 ubicaciones tcnicas y
12.766 equipos. Durante esta fase y por el gran volumen de informacin manejada
se requiri el apoyo de personal de alto nivel de la Gerencia de Refinera y
Terminales.
A medida que se avanzaba en la parametrizacin y en la carga de datos, se podan
hacer pruebas cada vez ms completas. Las pruebas eran fundamentalmente
internas, pero tambin hubo varias instancias formales de integracin, adems de
las informales que se llevaban a cabo casi a diario.
Durante las 16 semanas que dur esta fase, trabajaron en el mdulo de
mantenimiento un promedio de 14 personas, mientras que en el global del proyecto

Ricardo Cosentino Pg. 10

Implantacin SAP-PM en ANCAP URUMAN 2005
Montevideo, Uruguay

SAP, que abarcaba adems los mdulos de abastecimiento, costos, activo fijo,
finanzas y presupuesto, con el soporte de la Divisin Sistemas de Informacin, eran
casi 40 personas.
El entregable en esta etapa no era fsico, sino que lo constitua el sistema en s
mismo, instalado, parametrizado, cargado y probado, listo para lanzarse a la
operacin.

Fase IV
Una vez culminada la parametrizacin se desarrollaron los manuales para los
usuarios y se disearon los cursos de capacitacin para usuarios. Se dictaron
cursos de mantenimiento durante 4 semanas a un total de 140 funcionarios.
Las habilidades que deban tener los asistentes una vez culminados los cursos
eran: a) poder ingresar un aviso de mantenimiento (antes las solicitudes eran
telefnicas, recibidas centralizadamente en Programacin); b) capacidad de realizar
consultas acerca del estado de la solicitud; y c) capacidad de extraer listados y
reportes de los puntos de inters para su rea.
La puesta en productivo se realiz en la semana 39 de haber comenzado el
proyecto, y la transicin 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 poda estar con medias tintas, y se opt por una transicin rpida y
contundente, imponiendo de inmediato la dinmica del nuevo sistema.
De acuerdo con experiencias anteriores, se estableci una potente mesa de ayuda,
a la que se poda acceder por va telefnica o por correo electrnico, adems del
apoyo en campo de uno de los ingenieros y un supervisor con dedicacin 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 lnea 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 mdulo.
Se trabaja en permanente contacto y la frecuencia de las reuniones ha disminuido
con el correr del tiempo a medida que el mdulo se ha estabilizado.

Ricardo Cosentino Pg. 11

Implantacin SAP-PM en ANCAP URUMAN 2005
Montevideo, Uruguay

Conclusiones
El tiempo total de implementacin fue de 39 semanas, algo ms de 9 meses,
acorde con las estadsticas 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 informtico de primer nivel para la gestin tal como
lo recomend la consultora KBC.
Nos permite mantener actualizados en lnea los datos de mantenimiento de los
activos de la empresa, y tomar decisiones con muchos ms 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 ms claro del trabajo a realizar para la
programacin de los talleres ejecutores. A su vez la integracin transparente con el
mdulo de materiales permite visualizar la existencia en stock o las compras
tambin en tiempo real. Se ha mejorado sensiblemente la calidad de la informacin,
la comunicacin 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 desempeo de refineras Solomon y Associates de la que ANCAP
participa desde 1996.

Autor
Ricardo Cosentino; MBA, IEEM; Ingeniero Industrial opcin Mecnica, Universidad
de la Repblica; se desempe como Jefe del Taller Metalrgico de la Refinera La
Teja durante 12 aos, interinamente como Jefe de Mantenimiento, y actualmente
como Jefe de Programacin y Control; Profesor del Taller de Ayudanta Tcnica de
la carrera de Ingeniera Industrial de la Universidad de Montevideo; desarroll
tambin actividad profesional independiente.

ANCAP, Refinera La Teja.

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

Ricardo Cosentino Pg. 12

Implantacin SAP-PM en ANCAP URUMAN 2005
Montevideo, Uruguay

Anexo 1: Organigrama parcial de la Divisin Industrializacin Combustibles y

Lubricantes, y modo de relacionamiento entre las reas solicitantes y ejecutoras
antes de la reingeniera.

Gerencia Divisin
Industrializacin
Combustibles y
Lubricantes

Departamento
Departamento Gerencia Refinera
Gerencia Tcnica Planificacin y
Lubricantes y Terminales
Control

Programacin y
Mantenimiento Ingeniera y Obras Zonas Exteriores Inspeccin Tcnica
Control

Mecnica 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 Pg. 13

Implantacin SAP-PM en ANCAP URUMAN 2005
Montevideo, Uruguay

Anexo 2: Organigrama parcial de la Divisin Industrializacin Combustibles y

Lubricantes, y modo de relacionamiento entre las reas solicitantes y
ejecutoras luego de la reingeniera.

Gerencia Divisin
Industrializacin
Combustibles y
Lubricantes

Departamento
Departamento Gerencia Refinera
Gerencia Tcnica Planificacin y
Lubricantes y Terminales
Control

Programacin y Coordinacin de
Mantenimiento Ingeniera y Obras Zonas Exteriores Inspeccin Tcnica
Control Mantenimiento

Mecnica Operaciones I

Metalurgia Operaciones II

Electricidad e
Operaciones III
Instrumentos

Servicios I Operaciones IV

Servicios II Ingenieros

Servicios III Jefes de Turno

Ricardo Cosentino Pg. 14

Implantacin SAP-PM en ANCAP URUMAN 2005
Montevideo, Uruguay

Anexo 3: Ejemplo de aviso de avera de mantenimiento. Se visualiza la pantalla de

la cabecera del aviso con una ventana emergente del catlogo de
sntomas de averas. Esta clase de avisos genera rdenes de
mantenimiento correctivo.

Ricardo Cosentino Pg. 15

Implantacin SAP-PM en ANCAP URUMAN 2005
Montevideo, Uruguay

Anexo 4: Ejemplo de orden de mantenimiento correctivo.

a) Visualizacin de la cabecera de la orden:

Ricardo Cosentino Pg. 16

Implantacin SAP-PM en ANCAP URUMAN 2005
Montevideo, Uruguay

Anexo 4 (cont.)

b) Visualizacin de las operaciones (tareas) de la orden:

Ricardo Cosentino Pg. 17

Implantacin SAP-PM en ANCAP URUMAN 2005
Montevideo, Uruguay

Anexo 4 (cont.)

c) Visualizacin de los materiales requeridos para la orden:

Ricardo Cosentino Pg. 18