Académique Documents
Professionnel Documents
Culture Documents
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
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
Ricardo Cosentino
Pg. 3
Ricardo Cosentino
Pg. 4
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.
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
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
Ricardo Cosentino
Pg. 7
Ricardo Cosentino
Pg. 8
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
Ricardo Cosentino
Pg. 10
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
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
Ricardo Cosentino
Pg. 13
Ricardo Cosentino
Pg. 14
Ricardo Cosentino
Pg. 15
Ricardo Cosentino
Pg. 16
Ricardo Cosentino
Pg. 17
Ricardo Cosentino
Pg. 18