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 a bastecimiento (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 s e 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. 2. 3. 4. 5. Seleccin y capacitacin del grupo de trabajo Desarrollo del modelo conceptual Parametrizacin, carga de datos y pruebas Capacitacin de usuarios y puesta en productivo 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 que se dedicaron respectivaSOLICITUD DE REPARACIN SOLICITUD DE REPARACIN mente al anlisis de proceCOORDINADORES DE PLANIFICACIN Y OPERACIONES TALLERES COORDINADORES DE PROGRAMACIN PLANIFICACIN Y MANTENIMIENTO OPERACIONES TALLERES sos y al anlisis de datos MANTENIMIENTO PROGRAMACIN maestros, que son bsicaNecesidad Aviso de Avera Aviso de Avera Aviso de Avera mente todos los datos que Necesidad Aviso de Avera Aviso de Avera Aviso de Avera van a poblar las tablas de la base de datos de PM, y sus Guardia/ Guardia/ MBO? MBO ? Guardia/ Guardia/ MBO? MBO ? relaciones. Requiere Plan? SI Requiere El grupo que analiz los Plan? SI S S procesos identific alrededor S S Aviso de Medida Evaluacin de 20 procesos, de los No de mantenimiento Aviso de Medida RBWS Evaluacin + G3 Planificar No No de mantenimiento OT RBWS + G3 Planificar No cuales 4 eran los principales OT (nuevamente Pareto) y Registrar Aviso de MedidaAviso Registrar de Medida fueron los que se atacaron Paro? Es G 3? No Paro? Es G 3? primero. Se realizaron No Aviso de Avera Aviso de Avera No mltiples iteraciones con Si No Si S diagramas de flujo, apelando Crear Orden de Modifica Ejecucin S Trabajo Crear Orden de PST Modifica PST Ejecucin No Emergencia Trabajo (misma PST PST en algunos casos a sesiones No (Semana G1 o G2? Emergencia Corriente) semana) (Semana (misma G1 o G2? Corriente) semana) de tormenta de ideas, Backlog de Avisos S Backlog cuando se debieron de de Paro Avisos S Ejecucin PST de Paro O.T. Ejecucin (Prxima PST replantear algunos procedi(prxima O.T. G1, G2,? G1 Semana) (Prxima semana) (prxima G1, G2,? G1 Semana) semana) mientos desde cero. Recibe comunicacin Recibe La premisa de este proyecto comunicacin G2 G2 fue la de tener cero RBWS Comunica al CM RBWS desarrollo, lo que implicaba y alComunica Jefe de Taller al CM y al Jefe de Taller que SAP se adecuara en lo Crea / Libera OT Ejecucin G1 inmediata Crea / Libera OT Ejecucin G1 inmediata posible a los procedimientos Tiene Plan Estndar? Tiene Plan ya existentes en ANCAP, y RBWS Estndar? RBWS tambin que ANCAP se S S Crea / Libera OT adecuara a SAP. Sin esta Adjunta plan G2 No Crea / Libera OT estndar Adjunta a la OT plan G2 No estndar a la OT flexibilidad no se habra Ejecucin logrado cumplir con el Reelabora PST PST Ejecucin
(misma semana) Reelabora PST (misma semana) (misma PST 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. En el ejemplo se aprecia el equipo WORTHINGTON montado en la ubicacin tcnica 2806-JA. Si en algn momento de su vida, este equipo pasara a otra ubicacin tcnica, la historia de su mantenimiento se la lleva consigo. Pero mientras se encuentre este equipo montado en esta ubicacin tcnica, cada vez que nosotros solicitemos informacin de mantenimiento de esta ubicacin nos traer la de este equipo WORTHINGTON. Las ubicaciones tcnicas se 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:

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 I ndustrial 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.

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.

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