DISEO E IMPLANTACIN DE SERVICIOS TCNICOS: INNOVACIN EN LA GESTIN DEL MANTENIMIENTO

Autor: Miguel ngel Avils Sastre Ttulo: Diseo e Implantacin de Servicios Tcnicos: Innovacin en la Gestin del Mantenimiento Registro de la Propiedad Intelectual Nmero: M-006983/2012 Asiento Registral Nmero: 16/2012/10653 Titular de los derechos: Miguel ngel Avils Sastre

A mis hijos, por todo lo que aportan a mi vida.

PRLOGO

No resulta fcil hacer un prlogo para uno mismo. Hay que evitar caer en la tentacin de elogiarse, y dedicar estas lneas a vender el producto creado. No obstante, por el tema que se trata, voy a incumplir lo dicho. Voy a venderlo. Y qu mejor manera de comenzar diciendo, que los Servicios Tcnicos son una oportunidad de mejora, orientados a definir estrategias de negocio nuevas para toda Organizacin que lo implante. Sin tener conocimiento de los Servicios Tcnicos, puede resultar muy chocante y difcil de asimilar, pero gracias al enfoque que proporciona un Servicio Tcnico, en base a lo que ya se est haciendo, permite definir nuevos procedimientos con los que dirigir nuestras actividades. En este libro, los Servicios Tcnicos estn descritos desde la perspectiva del mantenimiento fundamentalmente, pues ha sido dentro de este entorno, donde han conocido su creacin y desarrollo. Por contra, es importante ser conscientes que el gran escollo a salvar para implementar cualquier Servicio Tcnico, es la falta de inters que puede suscitar gestionar el mantenimiento, usando indicadores totalmente diferentes a los actualmente establecidos (Disponibilidad tcnica, fiabilidad, tiempo de ejecucin ...) y de los que existen numerosas publicaciones en cualquier librera tcnica. En el mundo del mantenimiento es muy comn dar prioridad a una alta disponibilidad tcnica, en detrimento de la fiabilidad, tiempos de ejecucin menores a costa de incrementar las averas... o al revs, pero en definitiva, continuamente se cambia la actividad dependiendo de qu indicador est ms de moda, y muchas veces, por no definir claramente una estrategia y su periodo de validez. Los Servicios Tcnicos deben disearse sabiendo, que son una consecuencia de las actividades, pero nunca deben formar parte de ellas. Esta independencia, permite establecer tcticas comunes a los estamentos involucrados en dicho Servicio Tcnico. Falta de inters, madurez, resistencia al cambio..., pero la oportunidad que ofrece esta nueva visin del mantenimiento, a travs de la actividad que se genera por medio del equipamiento, las instalaciones, los recursos humanos que explotan dichas instalaciones y finalmente los mantenedores, merecen ser consideradas bajo la globalidad de todo el proceso establecido. Tristemente no es as. Las actividades de mantenimiento en mayor o menor medida, siguen establecidas en el mundo actual bajo los criterios del mantenedor (subcontratacin, nuevos contratos marco y modelos de contratacin...) frente a los criterios del cliente. Cmo hacer que ambos puntos de vista coincidan? Por medio de una herramienta que permita considerar todos los criterios o perspectivas, pues los Servicios Tcnicos permiten valorar las actividades usando criterios, en unos casos cientficos y en otros simplemente perceptivos. Deben, y as estn diseados, ajustarse a las necesidades que en cada momento los distintos actores implicados en el Servicio Tcnico demanden, aunque sea simplemente basndose en su experiencia. Adems, pretenden dar un paso ms respecto de la visin del mantenimiento, involucrando al cliente en la actividad. Cmo? Pues aportando su experiencia o dndoles a conocer el esfuerzo que suponen determinadas actividades, y el conocimiento de ese esfuerzo no lo medidos solo en costes, mano de obra... sino en un conjunto de mtricas que se obtienen del conjunto de actividades.

Supongo que al lector le pasar segn avance en la lectura, lo mismo que me pas a mi y a las personas que han colaborado y ayudado a materializarlos; que cuando comenzamos a definir y disear los Servicios Tcnicos, segn avanzbamos, la posibilidad de complementarlos e integrar nuevos aspectos, criterios, matices, medir todo aquello consecuencia de esta nueva visin, era una tentacin. Pero si no establecamos claramente los alcances y objetivos, sabiendo que nos dejbamos aspectos en algunos casos muy innovadores, no hubiramos sido capaces de tener un producto con gran capacidad de evolucionar. Como comprobar el lector es un mtodo, es decir, una visin, pero puede haber muchas ms. Este libro es una forma de comenzar, pero seguro que si alguien lo implementa en su organizacin o de la simple reflexin consecuencia de su lectura, lo modificar hasta seguramente slo parecerse en su finalidad, pero en nada, a la definicin y diseo. Si la organizacin se dedica a otros menesteres diferentes del mantenimiento, no hay problema. Lo importante es la filosofa. Ah es donde intervienen los Servicios Tcnicos.

NDICE GENERAL

NDICE GENERAL

SERVICIOS TCNICOS: UN NUEVO CONCEPTO? PRIMERA PARTE: ANTECEDENTES SEGUNDA PARTE: COMENZANDO TERCERA PARTE: MEJORANDO EL COMIENZO CUARTA PARTE: FASE DE CONSTRUCCIN QUINTA PARTE: HACIA EL MANTENIMIENTO SEXTA PARTE: ORGANIZANDO LAS INTERVENCIONES SPTIMA PARTE: GESTIN DE SERVICIOS EPLOGO ANEXO INDICADORES GLOSARIO DE TRMINOS BIBLIOGRAFA

5 11 31 127 173 223 283 311 337 341 351 357

SERVICIOS TCNICOS, UN NUEVO CONCEPTO?

INTRODUCCION
Cuando a finales del ao 2004, se me encomienda la tarea de desarrollar los Servicios Tcnicos, la pregunta inmediata fue:

Qu era un Servicio Tcnico?

Despus de un breve intercambio de ideas algo estaba claro, medir las actividades. El horizonte ya estaba establecido, pero quedaba la parte ms difcil; el camino a trazar sin ni tan siquiera conocer el terreno por dnde moverse. Despus de un tiempo dedicado a documentarnos, mis colaboradores y yo llegamos a la conclusin ms decepcionante posible; no exista, hasta donde ramos capaces de investigar, referente similar. Libros hablando del concepto de SERVICIO, alguno (de pasada), pero sin concretar cmo definir un servicio, disearlo, construirlo, implementarlo, medirlo, y lo ms importante, que cumpla las expectativas. Pero pasada la decepcin inicial, fuimos conscientes de que haba que partir de cero, lo que aportaba al proyecto un matiz muy interesante, creatividad. Desde mi modesto punto de vista, la motivacin consecuencia de la creacin, de hacer un producto propio y del que no existe nada similar, fue un aliciente a considerar muy importante, como as se demostr posteriormente. Es ms, cuando se trasmita este proyecto todo el mundo tena algo que decir, con lo que el enriquecimiento y la continuidad, estaban prcticamente garantizados. Por ello, este libro no es solo terico, es decir, trata de los Servicios Tcnicos desde el punto de vista conceptual, sino que tambin pretende ser una gua practica, una referencia que ayude en la medida que corresponda, a disear cualquier Servicio Tcnico, aunque el producto final no siga ni se parezca en nada, a todo lo que este libro va a mostrar. Los Servicio Tcnicos surgen en el seno del mantenimiento de instalaciones del mundo ferroviario y por tal motivo, la vinculacin casi permanente en las referencias y ejemplos, va a ser vital para el desarrollo del libro. Pero no significa que no pueda extrapolarse a otros mbitos del mantenimiento, incluso a otros sectores involucrados como una actividad ms. Ejemplo de ello puede ser la logstica o la explotacin. Ni tan siquiera el conjunto del mantenimiento desde el punto de vista de actividad, tiene que estar centralizado en un nico departamento. La consecuencia inmediata de la implantacin de un Servicio Tcnico es, la necesidad de concienciar en el cambio, ms si cabe, si los resultados son positivos y la satisfaccin alta. Para qu medir las actividades desde un nuevo punto de vista, si con el actual es satisfactorio? A lo largo del libro introduciremos argumentos que demostrarn, que medir las actividades por el servicio prestado, permitirn no solo mejorar los criterios de los mantenedores, sino adems, incorporar la satisfaccin del cliente. No es ajeno al sector del mantenimiento en estos momentos con datos del ao 2005, que los valores actuales de disponibilidad de instalaciones y flotas estn en el orden del 97%-98%, sin embargo, las encuestas de satisfaccin de cliente no 7

reflejan estas magnitudes estando muy por debajo, en el mejor de los casos 60%70%. Y la pregunta es obvia, qu est fallando? El ejemplo ms sencillo puede estar en una flota de autobuses; de qu sirve tener todos los autobuses disponibles sino hay conductores suficientes? El esfuerzo del departamento de mantenimiento no habr repercutido en el beneficio buscado, y lo ms seguro es que sea el eslabn final de las crticas, por ser uno de los departamentos ms visibles de los involucrados. Por eso, cuando nos referimos al conjunto de actividades incluye tambin, la que muchas veces genera el propio cliente. Nos cuesta cambiar? Sin duda. Las personas somos poco dadas a innovaciones drsticas de las cuales, ni sabemos, ni tenemos conocimiento. El rechazo producido es quizs el principal escollo a sortear. Hace tiempo en un artculo en prensa sobre gestin de RRHH se pona de manifiesto, que la mejor opcin para evitar la oposicin al cambio, era realizar grandes cambios, por decirlo de alguna manera, generar una bola de nieve imparable. Cuando las personas nos encontramos ante situaciones en las que el volumen de los cambios es muy alto, somos incapaces de ofrecer resistencia y los asumimos, no sin cierta resignacin. Pero tambin es cierto que la mejor manera de minimizar la resistencia al cambio, es por medio de la comunicacin. Informar en primer lugar, de qu es un Servicio Tcnico y lo que representa. Desde el punto de vista de los trabajadores se ha demostrado, qu cuanto ms conocemos menos miedo , y el miedo es una de las claves del por qu de la negativa al cambio. Un modelo , donde toda persona involucrada en la actividad conozca su participacin, convertir los contras en pros y algo muy positivo, como decan las empresas japonesas en la dcada de los aos 70: por el mismo coste, nosotros adems de manos tenemos una cabeza. Qu importante es contar con la opinin de quin ms cercano est a la actividad, incluido el cliente. Para un departamento de mantenimiento, auditar su actividad considerando las referencias definidas con el Servicio Tcnico, representa un cambio cualitativo ventajoso, porque la primera pregunta va a ser, los indicadores actuales son vlidos? S, pero tenemos que ser conscientes de que no abarcan las necesidades del cliente. Miden lo que miden; mantenimiento intrnsecamente. Son muy tiles por ejemplo en subcontratacin, cmo sino evaluar a nuestros contratistas?. Tiempos de Respuesta, Fiabilidad y un largo etc., formarn parte de las clusulas de garanta y penalizacin. Y a todo esto, dnde englobamos los costes?. El diseo de los Servicios Tcnicos no fue ajeno a los costes. Como veremos, es una de las premisas fundamentales que justifica su creacin. Pero a nadie se le escapa que el factor econmico es uno de los aspectos de gestin ms delicados, y que para poder establecer buenas polticas es premisa fundamental, tener bien correlacionados los costes de las actividades empresariales. Como se dice habitualmente, la casa hay que comenzarla por sus cimientos, y dada la envergadura que por si sola tiene el Servicio Tcnico, la repercusin y medicin de los costes se ha pospuesto para una posterior fase evolutiva. Eso s, hemos dejado indicado durante el diseo los 8

cimientos sobre los que desarrollarlo, basndonos en el conocimiento y mtodos aplicados actualmente en el mantenimiento como actividad. Espero que en un futuro prximo, consolidados los Servicios Tcnicos como herramienta para gestionar actividades, seamos capaces de asociar el factor econmico, y del conocimiento obtenido, el tema principal de un futuro libro. Hasta entonces, empezando por m, tendremos que esperar.

10

PRIMERA PARTE ANTECEDENTES

11

12

NDICE PRIMERA PARTE

1 2 3 4 UNAS PINCELADAS PARA SITUARNOS ........................................................ 15 HACIENDO HISTORIA DEL MANTENIMIENTO ............................................... 17 MEDIR ................................................................................................................ 25 EVALUANDO EL MANTENIMIENTO ................................................................ 27

13

14

1 UNAS PINCELADAS PARA SITUARNOS

En cualquier actividad generada slo es posible cuantificar el xito o fracaso de la misma, si hay referencias que permitan evaluarla. En el mundo del mantenimiento esta mxima es trascendental y se muestra, como la nica forma de valoracin para cada vez ser ms competitivos, ms eficientes, mejorar la satisfaccin del cliente... o simplemente evolucionar, independientemente de cual sea el fin ltimo. La vida en si misma consiste en un proceso continuo de medicin. Unas veces usamos referencias propias que nuestra formacin y conocimiento intrnseco pueden proporcionarnos. Otras, la medicin ha sido aprendida basada en la propia experiencia o en la de los dems. Aquella que simplemente nos han trasladado. En el mantenimiento hay de todo un poco. La historia del mantenimiento y de los mtodos productivos es muy reciente. Podramos datarlos en la primera mitad del siglo XX, donde las tristemente dos guerras mundiales, marcaron tendencias que solo con la llegada de los aos 80 y la aparicin del mantenimiento predictivo, condicionado,... aportaron un nuevo planteamiento. Pero antes en los aos 70, surgieron dos corrientes con fuerza en dos pases a la vanguardia en los mtodos de produccin, pero claramente diferenciados. - En Estados Unidos el mantenimiento basado en el Coste del Ciclo de Vida (LCC), fundado en la rentabilidad y coste del servicio obtenido. Se agrupan bajo el concepto de coste los de: adquisicin, puesta en servicio, explotacin, mantenimiento, desmontaje y retirada. - En Japn el conocido como Mantenimiento Productivo Total (TPM), basado en el mximo rendimiento de las instalaciones productivas, con el mximo aprovechamiento de los recursos humanos que intervienen en la produccin. Se persigue la motivacin de las personas implicadas agrupndolos en equipos de trabajo. En las postrimeras del siglo XX destaca con fuerza, convirtindose en un referente a nivel mundial, el mtodo conocido como Mantenimiento Basado en la Fiabilidad (RCM-Reliability Centred Maintenance). Esta metodologa es consecuencia del estudio de los tipos de fallo y la relacin existente con sus modos y/o causas de fallo. Pero en dnde aplicaremos estos mtodos? O mejor dicho, cules son las reas en donde el mantenimiento se aplica?: Industrial (fabricacin). Sistemas e infraestructuras tecnolgicas. Telecomunicaciones y CPDs (Centros de Procesos de Datos). 15

 Obra Civil. Edificios e instalaciones. Obra Civil. Infraestructuras (Carreteras, puertos...) Transportes. En unas pocas lneas hemos hablado de mantenimiento, tipos, mediciones, campos donde aplicarlo,... Desenredemos la madeja.

16

2 HACIENDO HISTORIA DEL MANTENIMIENTO

El captulo anterior ha sido catico? Confuso? Tiene su por qu. Hemos abierto un gran campo del que hablar y primordial para entender este libro. Vamos a situarnos en el tiempo. Entre todas las actividades auxiliares a la produccin y explotacin, el mantenimiento ha ido alcanzando durante el transcurso del siglo XX cada vez mayor relevancia, llegando a adquirir identidad propia consecuencia del aumento de la mecanizacin (incremento del uso de la maquinaria) en todos los ciclos productivos. Al comienzo (Revolucin Industrial), el mantenimiento, siempre que existiera la posibilidad de identificarlo como tal, careca de base tcnica, es decir, mtodos organizados y estructurados de intervencin y justificacin econmica. En el periodo de tiempo transcurrido hasta la Segunda Guerra Mundial, las mquinas se caracterizaban por ser sencillas y de propsito nico, lo que las converta en altamente fiables, fciles de reparar y no exiga ninguna cualificacin especfica para el personal que las manipulaba. El mantenimiento como faceta de prevencin de averas no exista. Las intervenciones se realizaban siempre consecuencia de una avera previa, en la mayora de los casos, averas que inutilizaban la maquinaria. En caso contrario, la mquina continuaba funcionando hasta su fallo total y era el operario de la propia mquina, quien casi siempre arreglaba el problema. Pero la llegada de la Segunda Guerra Mundial marc claramente el antes y el despus. Los operarios estaban haciendo la guerra. No haba mano de obra industrial y esto llev a la mecanizacin de las industrias, por el aumento de la necesidad de toda clase de productos. Mecanizacin y automatizacin. El resultado hacia los aos 50 fue de la existencia de todo tipo de mquinas, y lo peor, ms complejas. Desde entonces, la dependencia industrial se caracteriza por la implicacin y eficiencia de la maquinaria. Aparecen lo que podramos considerar los primeros talleres mecnicos. Ya no son los operarios, cuando los hay, quienes arreglan las mquinas. Los departamentos de produccin, ante la necesidad de continuar su ciclo productivo, requieren de personal que arregle los equipos, y muy importante, que este personal debe ser un especialista, porque la maquinaria ha adquirido tal grado de sofisticacin que un nico mantenedor, no tiene porque conocer todo el entresijo mecnico. La muestra ms evidente es, que desde que los coches son coches, varios son los especialistas que intervienen en sus reparaciones. Esto solo referente a la maquinaria. Y el resto de disciplinas? Usando una expresin muy castiza, ms de lo mismo. Cul es la consecuencia de toda esta diversificacin? La ausencia de una semntica nica y vlida para todos los campos y disciplinas. De hecho, la definicin de mantenimiento es reciente, concretamente del ao 1963: 17

Asegurar que todo elemento fsico contine desempeando las funciones deseadas
Y en 1972 la EFNMS (European Federation of National Maintenance Society) lider un proyecto de mbito europeo, para la unificacin de los trminos que forman parte del lxico del mantenimiento. Existen otros factores que marquen diferencias entre el comienzo y la actualidad? Por supuesto. La instrumentacin e incorporacin de automatismos es relativamente reciente, con el agravante de confiarle la responsabilidad a la Oficina Tcnica si existe. En la Revolucin Industrial y aos posteriores, no haba ninguna clase de automatismos. No haba mtodos industriales de proceso continuo. La maquinaria careca de sofisticacin. Era pesada y lenta. Se confiaba la continuidad, la mayor parte de las veces, al sobredimensionamiento, tanto del conjunto, como de los elementos unitariamente. Otro factor muy importante que no se debe desligar, era la mano de obra. Dos caractersticas la definan: Bajo coste y jornadas casi eternas. La competitividad era prcticamente nula. La industria se rega por la existencia generalizada de monopolios. Como colofn final (que no el ltimo de los factores), el mantenimiento se le consideraba un gasto. Nada que ver con la actualidad, donde el mantenimiento, por el hecho de tener identidad propia, ya sea en el seno de la empresa o como subcontratacin, es un factor productivo ms y por lo tanto, debe incluirse dentro de las polticas de costes de la empresa. Esta implicacin directa del mantenimiento en los costes, tanto desde el punto de vista de los presupuestos, como de los procesos productivos, oblig a considerar otros aspectos que hasta el momento, no tenan relevancia. Mantener un sistema productivo significa que se detiene. Unas veces por el propio mantenimiento y otras, condicionado por las averas. Empieza a hablarse de las ausencias de servicio como factor crtico o negativo. El mantenimiento en estos aos 50, adems de reparar eficazmente, comprende lo importante que es evitar el fallo en la medida de lo posible. Plantea la necesidad de la prevencin como mtodo de reduccin de las averas, y lo ms importante, minimizar el impacto. Aparece el Mantenimiento Preventivo y con l, la creencia de que la mejor manera de evitar el fallo es anticipndose. Esta premisa que puede parecer tan coherente, veremos ms adelante que no se cumple en un alto porcentaje de casos. Paralelamente, los departamentos dedicados a las relaciones con el personal (sera quizs precipitado denominarlos de Recursos Humanos, tal y como los conocemos en la actualidad) intentan dar respuesta a la incipiente conflictividad (trato y relacin) laboral que se empieza a plantear en los pases ms avanzados industrialmente. Los departamentos de Produccin no son ajenos a los cambios que se experimentan en el resto de estamentos, e inician una

18

transformacin eficientemente.

razonada,

porque

producir

razonadamente

es

producir

An con todos estos cambios, el elevado coste inicial de cualquier instalacin sigue siendo el factor determinante para las empresas. Es necesario sacarle el mayor rendimiento a la maquinaria, y no ajenas a las prdidas productivas (sin servicio), se disean y aplican planes de mantenimiento peridico, el cul, a intervalos regulares se realizan las intervenciones de: sustitucin, renovacin, restauracin... por medio del desmontaje completo de la mquina o instalacin, cambiando todas aquellas piezas que tuvieran merma o disminucin de sus caractersticas iniciales independientemente de su estado, incluidos otros posibles elementos o componentes adicionales necesarios para el funcionamiento, como pueden ser: aceites, grasas,... y para poder llevar a cabo semejante esfuerzo, se constituyen los primeros Departamentos de Mantenimiento identificados como tales, responsables de generar y aplicar los mantenimientos peridicos. Como estamento con identidad propia en el conjunto de la empresa se le va a exigir como al resto, que el trabajo realizado sea consecuencia de la especializacin, es decir, haya un condicionante tcnico en la elaboracin de los planes y adems, exista una poltica de costes asociada. Qu gran inconveniente se plantea? Como hemos comentado las intervenciones son acometidas transcurrido un tiempo fijo. No existen: Indicadores que determinen cundo es necesaria la intervencin preventiva. Instrumentos de medicin que puedan confirmar si la pieza (u otros elementos adicionales como aceites, grasas,...) ha sustituir, sobrepasan la tolerancia (fatiga, desgaste,...) o si podra aguantar hasta la siguiente revisin.

La infrautilizacin de dichos repuestos no genera ahorro de costes y mucho peor, no garantizan un mejor funcionamiento. Esta ltima cuestin, al carecer de capacidad de anlisis derivada de los posibles estudios a realizar en los elementos sustituidos, no es detectada por los departamentos de mantenimiento. Dos industrias van a cambiar este mtodo de proceder. Por un lado el desarrollo de la industria electrnica, consecuencia del estudio y aumento de la fiabilidad de los componentes electrnicos. Posteriormente la industria aeronutica, focalizada en el incremento de la seguridad de los vuelos minimizando las paradas. Y es precisamente la industria aeronutica la que desarrolla e implanta una metodologa (Condition Monitoring) basada en la medicin de los componentes, y aqu es donde reside la innovacin del mtodo, porque el tiempo no es el factor principal para actuar y las mediciones se realizan mientras se est prestando servicio, es decir, en funcionamiento. Si las medidas obtenidas estn dentro de unos parmetros prefijados de seguridad, consecuencia del anlisis, la investigacin y la experiencia en los materiales y repuestos, no se acta sobre ninguno de los elementos. La continuidad del servicio est garantizada. 19

Esta metodologa cuya caracterstica principal como hemos visto es que no depende del tiempo (puede que bajo algunas circunstancias sea necesario considerarlo), es la precursora del mtodo RCM (Mantenimiento Basado en la Fiabilidad) . El sinptico siguiente muestra la evolucin del mantenimiento durante el siglo XX

1930 1940 1950 1960 1970 1980

Primera Etapa Reparar en caso de avera Segunda Etapa Incremento de la Disponibilidad de la Instalacin Incremento de la vida til de la maquinaria Reduccin de costes Tercera Etapa Mayor Disponibilidad y Fiabilidad Mayor Seguridad Mejora de la Calidad de los Productos y Servicios Respecto al Medio Ambiente Durabilidad del equipamiento Mejora de la Relacin Coste-Eficacia
Evolucin del Mantenimiento

1990 2000

En los ltimos aos, qu aspectos estn siendo determinantes para el mantenimiento? En primer lugar destacaramos los costes. El mantenimiento ha pasado de ser una actividad residual con costes inapreciables, a ser una de las actividades empresariales que genera ms gasto y esta tendencia alcista todava no ha sufrido variacin, llegando en la mayora de las empresas a ser el primer o segundo gasto general, convirtindose en objetivo estratgico la contencin y/o disminucin del mismo. El impacto medio ambiental. La conciencia mundial sobre el deterioro del planeta ha llevado a las grandes corporaciones a planteamientos enfocados en la proteccin del entorno. El mantenimiento, y ms concretamente las consecuencias de dicha actividad (aceites, grasas, gases y as una larga lista), han tenido que adaptarse a dichas exigencias con un proceso de revisin profundo, incluso, de los propios procesos. Relacionado con el anterior el marco legislativo. Normalizacin en estndares mundiales, reglamentacin en materia de seguridad, ambiental, hacia las personas (productor y cliente), etc., muchas de ellas, con aplicacin directa sobre el mantenimiento.

20

La independencia de la actividad humana. Las mquinas producen solas y el operario, cuando lo hay, se convierte en un mero supervisor de dicha actividad. La consecuencia es que cualquier alteracin de la maquinaria modifica la calidad final del producto. El concepto de Servicio. El cliente exige no solo un servicio de facto , sino adems, una calidad asociada al mismo rechazando cualquier merma o disminucin. Exigencia en el producto final. Por ltimo la profesionalizacin. Durante toda la primera y segunda etapa de la evolucin del mantenimiento, era costumbre que el oficio se adquiriera empezando como aprendiz. Tal era la importancia que tena, que estaba considerado una categora laboral ms en el conjunto de la empresa. Transcurrido un tiempo, en funcin de la experiencia conseguida, dejaba de ser aprendiz para convertirse en ayudante, oficial 3, oficial 2,... A partir de los aos 80 la complejidad de la maquinaria, obliga a que el aprendiz tenga previamente adquirida una formacin mnima, que le capacite para el trabajo a desarrollar. Para el mantenimiento, desde los aos 50 y con especial trascendencia la ltima dcada del siglo XX comienzo del siglo XXI, ha sido muy importante el comportamiento1 de los equipos y como vara con el tiempo. Pues bien, la evolucin que ha ido sufriendo es verdaderamente significativa, pues se ha pasado del punto de vista tradicional, aqul que es inherente a la naturaleza humana y nos induce a pensar que cualquier elemento, segn pasa el tiempo incrementa su probabilidad de fallo y segn nos acercamos al final de su vida til esta probabilidad es mayor (exponencial), a tener cinco nuevas curvas de probabilidad de fallo diferentes.

Se denomina comportamiento, a la probabilidad de fallo del equipo.

21

Comportamiento del equipamiento

20

0 1

20

0 1

20

0 1

20

0 1

20

0 1

20

0 1

De arriba abajo, describamos cada una de las curvas mostradas: Grfica 1) Curva de la Baera - Se caracteriza por una alta mortalidad infantil inicial, a continuacin un bajo nivel de probabilidad de fallo y finalmente fallos por desgastes. Grfica 2) Se caracteriza por una alta mortalidad infantil inicial, seguida de un comportamiento aleatorio de la probabilidad de fallo. Grfica 3) Incremento constante de la probabilidad de fallo. Grfica 4) Curva de fallos aleatorios - Ausencia de relacin entre la edad del equipamiento y la probabilidad de los fallos. Grfica 5) Rpido incremento de la probabilidad de fallo, seguido de un comportamiento aleatorio. Grfica 6) Curva Tradicional - Se caracteriza por poca probabilidad de fallo al principio y finalmente fallos por desgastes. Durante este captulo hemos esbozado un breve resumen de la historia del mantenimiento. Como ha evolucionado en funcin, no solo de los requerimientos sino adems, de sus condicionantes propios en el desarrollo de su actividad y conocimiento del equipamiento. Hemos proporcionado tambin al lector la definicin de mantenimiento, para entender la actividad propiamente dicha. Implcitamente, 22

hemos presentado desde el punto de vista tcnico, dos de los tipos de mantenimiento que se realizan: Correctivo algo estropeado se arregla, Preventivo antes de que se estropee, se reemplaza. Es obvio que existen otros tipos de mantenimiento (predictivos, segn condicin...), pero no consiste en hacer un desglose pormenorizado de la actividad de mantenimiento. Simplemente queremos que el lector comprenda lo que significa el mantenimiento como actividad y que al desarrollarla, convierte en la mayora de las veces a los departamentos de mantenimiento en PROVEEDORES DE SERVICIO. No son los nicos. Sobre un equipo se desarrollan multitud de actividades pero, los Servicios Tcnicos, que en definitiva es de lo que trata este libro, surgen en el seno del mantenimiento de las instalaciones ferroviarias y adems, el porcentaje de actividad que representan del resto de actividades es mayoritario. Por tal motivo, para entender los Servicios Tcnicos es paso previo, comprender el mantenimiento en general. Qu otro aspecto es interesante conocer que facilite la comprensin de los Servicios Tcnicos? La forma de medir la actividad, es decir, los indicadores. Adentrmonos en un nuevo captulo.

23

24

3 MEDIR
Comenzamos uno de los aspectos ms difciles de tratar, por lo confuso y dispar criterio que en torno a los indicadores (resultado de la medicin) existe. Voy en la medida de lo posible a intentar ser claro y efectivo, tanto en el planteamiento, como en la exposicin. Cuento a mi favor (afortunadamente), no solo mi experiencia profesional (pero con modestia) y una amplia bibliografa existente, sino adems, formar parte de una organizacin donde el correcto diseo e implementacin de los indicadores es vital para el negocio. La primera cuestin que se nos plantea es por qu medir. Las causas qu justifican dicha necesidad pueden ser variadas y de muy distinto calado, pero bsicamente necesitamos medir para: Interpretar lo que est ocurriendo. Quizs la ms importante. En un elevado porcentaje es el nico recurso para conocer. Adoptar las medidas correctoras oportunas cuando las variables se salen de los lmites establecidos. Una vez que tenemos la informacin, si el resultado no es el esperado, analizando las causas podremos establecer las medidas necesarias. Definir la necesidad de introducir cambios o mejoras evaluando sus consecuencias. Los anlisis no son siempre concluyentes. Definiendo nuevas referencias nos ayudarn a justificar las acciones a tomar. Establecer nuevas metas que permitan orientar las mejoras establecidas. Es casi una consecuencia y forma parte de todo proceso. Toda medida tiene su tiempo de vida. La medicin siempre es una referencia. Un valor que debe proporcionarnos una informacin til como hemos visto. Partiendo de este concepto, dos son los tipos que nos podemos encontrar susceptibles de interpretacin: 1. Valor como registro de informacin . En este grupo estaran todas las mediciones para controlar y detonar la actividad, como pueden ser: las horas de funcionamiento, operaciones de venta, distancia recorrida, etc. 2. Valor como referencia. Indicar si la actividad realizada es apropiada o est dentro de las expectativas y requerimientos. En este grupo podemos encontrar multitud de tipos y es al que nos vamos a referir. Y cuando hemos dicho susceptible de interpretacin es fundamentalmente, porque puede haber registros que se consideren tambin referencias.

25

Ahora bien. En el caso de referencia, es muy difcil ponerse de acuerdo para establecer una catalogacin precisa de los diferentes tipos de indicadores que existen, pues dependiendo del mbito, alcances, aplicaciones, etc. un mismo indicador puede estar englobado en distintos grupos. Los muchos autores y libros que podemos encontrar reflejan esta diversidad, fruto de la experiencia y el desarrollo profesional de cada uno. Quizs lo nico en lo que todos podamos coincidir, es que un indicador tiene una aplicacin concreta, GESTIONAR.

Los indicadores son necesarios para mejorar. Lo que no se mide no se puede controlar y lo que no se controla, no se puede gestionar
Y qu entendemos por gestionar? Sabiendo de partida que tampoco nos vamos a poner de acuerdo todos los autores, modestamente diremos que es tomar decisiones en funcin de los resultados obtenidos . Quiero subrayar un aspecto muy importante. Los seres humanos tendemos a interpretar en lugar de entender (escuchar). Por este motivo es muy posible que, tomar decisiones alguien lo asuma como consecuencia de malos resultados. La definicin expresa simplemente tomar decisiones, pues el resultado puede ser espectacular y de su anlisis, adoptar y formalizar los aspectos que lo ha proporcionado. Obviamente medir, sin conocer el proceso completo que proporciona el valor, tiene dos consecuencias directas negativas: a. Se puede disear un indicador errneo. Ni es consecuencia, ni mide el proceso. b. An en el caso de ser correcto, peor es, que pueda ser interpretado errneamente. Es obvio que el indicador es el factor ms inmediato de la necesidad de medir, y un conjunto estable y en cantidad adecuada, ser una de las mejores armas pa ra evaluar cualquier actividad.

26

4 EVALUANDO EL MANTENIMIENTO
Durante la exposicin del segundo captulo qued manifiesta, la importancia que la actividad de mantenimiento adquira para la industria y la empresa en general, segn era necesario intervenir en la maquinaria por su complejidad, y disminuir en lo posible las faltas de produccin (las ausencias de servicio). Para el progreso del mantenimiento en las diferentes modalidades que hoy en da se conocen fueron determinantes, el estudio de los equipos y su comportamiento. Vimos que para aplicar el mantenimiento ms oportuno, lo ms lgico era partir de registros previamente establecidos y de su lectura, las decisiones a tomar. Pero lo que no planteamos en ningn momento era como auditar el mantenimiento. En el captulo anterior hemos considerado que un indicador puede ser un registro, una referencia o ambos. Pues bien, para el mantenimiento como actividad esencial del proceso y que tiene asociado grandes costes, los indicadores se convierten en el exponente determinante para gestionarlo. Proporciona un campo de estudio nico y cualquier variacin en las mediciones, afectan al resto de actividades y por supuesto, al cliente final. La quinta parte del libro est dedicada a, como los Servicios Tcnicos orientan al mantenimiento usando la priorizacin de las intervenciones, como herramienta para la planificacin y organizacin de las actividades de correctivo. No obstante, el mantenimiento de por si merece de estudio aparte. Existe todo un mundo dedicado a la definicin de los mejores indicadores y a interpretarlos para una gestin eficiente. Pero... aunque cada vez existe ms convergencia de opiniones, contribuyendo en gran medida la estandarizacin y normalizacin, segn organismos internacionales y diversos comits que trabajan para unificar criterios, queda mucho por hacer. Concretamente el Comit Europeo de Normalizacin (C.E.N.), puso en marcha diversos grupos de trabajo a nivel internacional para disear y definir en conjunto, indicadores que permitiesen medir el funcionamiento del mantenimiento. El resultado ha sido la publicacin en septiembre de 2008 de la norma prEN 15341, un estndar global que refleja una seleccin de indicadores para la medida de funcionamiento del mantenimiento, as como sus definiciones. Consecuencia del trabajo realizado hace algunos aos en el departamento de mantenimiento del que formo parte, y muy en lnea con la propuesta de los grupos de indicadores definidos en la norma, establecimos una catalogacin inicial que pretenda englobar como premisa previa, los tipos sobre los que sustentar los indicadores que se definieran, es decir, los tipos bsicos para una eficaz gestin. Adems, llamarles Indicadores de resultado tena como finalidad, proporcionarles una orientacin evidente de que su objetivo estaba enfocado al control a muy alto nivel del mantenimiento. Estos tipos son: 1. Tcnicos. Orientados al equipamiento. Su rea de Influencia est acotada prcticamente, en definir el tipo de mantenimiento a 27

realizar y la eficacia del propio equipo. Por ejemplo Disponibilidad Tcnica, Tiempo Medio Entre Fallos (MTBF), etc. 2. Mano de Obra. Tres son los grandes datos sobre los que definir los indicadores de este grupo: Los partes de trabajo, los tiempos definidos en los partes incluidas las tareas realizadas en la intervencin, y los recursos humanos usados. 3. Econmicos. Este grupo da para crear una batera casi inmanejable, y si otros departamentos intervienen, se puede complicar a extremos insospechados. No obstante la clave para qu indicadores definir, puede estar en el anterior grupo. Coste del parte de trabajo. Controlndolo, aglutinamos los costes esenciales: Mano de obra y materiales. Muy importante y con gran repercusin en algunos departamentos de mantenimiento los desplazamientos. Los otros costes que se deben controlar son los derivados del grupo de tcnicos y mandos. Generalmente no se repercuten y en algunas circunstancias, pueden suponer un porcentaje elevado de gasto en mantenimiento. 4. Cliente. Lo prioritario conocer su satisfaccin. Y digo conocer, porque medirlo y ms importante sacar consecuencias, se convierte en arte muchas veces, y no es broma. No siempre el cliente trasmite con precisin su satisfaccin y su interpretacin puede ser consecuencia de malos indicadores (encuestas, grados de satisfaccin), ausencia de educacin (es muy rentable ensear al cliente todos aquellos aspectos relevantes y muchas veces implicarle si es posible), etc. Durante mucho tiempo como Coordinador de Integracin de Servicios (una figura de enlace entre el mantenedor y su cliente) pude comprobar lo ms ingrato que puede sucederle a un departamento de mantenimiento. El esfuerzo mprobo realizado al completo por el departamento de mantenimiento, superando muchsimas veces las expectativas, no repercuta lo ms mnimo y lo peor, el deterioro de la imagen y profesionalidad que para el cliente interno pareca existir. Hemos conseguido identificar cuatro tipos que abarcan casi en su totalidad, los aspectos que nos interesa conocer de la actividad para su gestin. Pero sino generamos entre ellos los mecanismos de interconexin adecuados, por muy elaborados que estn, representen un selecto grupo escogido y proporcionen la informacin requerida necesaria, podemos encontrarnos con interpretaciones errneas fruto de no tener analizado el efecto-causa. Los indicadores no tienen por qu evolucionar positivamente o empeorar todos a la vez. La mayora de las veces, consecuencia de la estrategia definida en cada momento, unos evolucionan favorablemente mientras que otros, pueden mantenerse en los valores anteriores, sufrir variaciones negativas, positivas... Por hacer una comparacin. Supongamos un coche con velocmetro y tacmetro 2 . A la misma velocidad, el indicador del tacmetro puede hallarse en la zona roja o no. Depender de la marcha engranada.
2

Cuentarrevoluciones

28

Ambas lecturas (mediciones) estn ligadas; deben interpretarse conjuntamente por la relacin (marcha engranada) en la que nos encontremos. De la misma manera, los indicadores que se definan en la organizacin deben estar escogidos, conociendo los efectos que entre unos y otros puedan tener al sufrir variaciones. Lo mejor es aplicar diez reglas, tal y como las recoge D. Francisco Javier Gonzlez Fernndez en su libro Auditora del Mantenimiento e Indicadores de Gestin, para disear los indicadores que mejor ayuden a gestionar el mantenimiento: 1. Los resultados deben aportar informacin til al conjunto de la organizacin. Los indicadores escogidos no estn aislados. Deben dar informacin til para el conjunto de la empresa. Para ello, deben estar alineados con los objetivos estratgicos definidos. 2. Deben ser representativos y fciles de obtener . Lo difcil, es disear los indicadores ms adecuados para la gestin ms eficaz. Unos indicadores fciles de obtener, cercanos y claros, sern de gran utilidad. 3. Deben tener en cuenta al cliente interno . La actividad de mantenimiento tiene como destinatario en organizaciones extensas, a los departamentos de Operacin, Explotacin y/o Produccin. Las inquietudes de dichos departamentos, sus necesidades, sus prioridades, sern de gran ayuda para definirlos. 4. Medir tiempos de ciclos y procesos. El tiempo se ha convertido en baza clave de cualquier actividad. Tener acotados los tiempos en los que se desarrolla, permitir orientar nuestros esfuerzos eficientemente. 5. Analizar indicadores de la competencia. Nada mejor que compararnos para saber lo bien o mal que lo estamos haciendo. Y tan bueno es compararnos con el que lo hace mejor que nosotros para mejorar nosotros tambin, como compararnos con el que lo hace peor para no cometer los mismos errores. 6. Implantar una cultura de medicin. La falta de tiempo y la presin a la que estn sometidos los departamentos de mantenimiento, obliga a que se est en permanente relacin demanda-accin. Ante cualquier peticin, es bueno reflexionar por qu se produce, analizando la informacin que mejor nos puede ayudar a sintetizar las acciones ms adecuadas. Implantar la cultura de los indicadores como herramienta habitual de trabajo, facilitar el xito de las decisiones. 7. Usar nicamente los indicadores que interesen. Hay un proverbio que viene a decir: Los rboles no dejan contemplar el bosque. Algo parecido podemos sacar como conclusin. Un selecto grupo de indicadores mejor que una multitud. Pocos y eficaces.

29

8. Involucrar a los equipos en la definicin de los indicadores. Al involucrar, en cierta medida estamos responsabilizando a qui en participa como algo propio. Est consensuado. 9. Analizar la eficacia de cada indicador. Un indicador que no ayude a la toma de decisiones, solo sirve para perder el tiempo. 10. Eliminar o modificar los indicadores que lo requieran. Todo indicador tiene un tiempo de vida. Uno de los aspectos menos conocidos y tratados es el agotamiento de cualquier medicin. Finalizado el tiempo de vida til, debe eliminarse o sustituirse por otro ms acorde a las necesidades. Durante estos cuatro captulos hemos intentado ayudar al lector a situarse para lo que a continuacin se le viene encima, adentrndolo en el mantenimiento como actividad ms representativa dentro de los Servicios Tcnicos y que toda actividad, incluidos los Servicios Tcnicos como resultante del conjunto de actividades, debe tener la posibilidad de medirse con el fin de evaluarla y tomar decisiones que nos permitan continuar mejorando. Es el momento de adentrarnos en los

30

SEGUNDA PARTE COMENZANDO

31

32

NDICE SEGUNDA PARTE

1 2 DEFINICION DE SERVICIO .............................................................................. 35 POR QUE DEFINIR SERVICIOS TECNICOS? ............................................... 39 2.1 Necesidades del Cliente ................................................................................ 41 2.2 Cliente Directo................................................................................................ 43 3 4 5 POR QU UN SERVICIO TECNICO? ............................................................. 45 OBJETIVOS Y CLASIFICACION DE LOS SERVICIOS TECNICOS ................ 47 FASES ............................................................................................................... 49 5.1 Diseo ............................................................................................................. 49 5.2 Construccin .................................................................................................. 50 5.3 Piloto ............................................................................................................... 51 5.4 Modelizacin .................................................................................................. 51 5.5 Consolidacin ................................................................................................ 51 5.6 Explotacin .................................................................................................... 51 5.7 Auditoria ......................................................................................................... 52 6 7 8 POR DONDE COMENZAR? ........................................................................... 55 DISEANDO UN SERVICIO TECNICO ............................................................ 57 EQUIPAMIENTO DEL SERVICIO (EQUIPAMIENTO IMPLICADO) ................. 59 8.1 Equipos Monitorizados ................................................................................. 60 8.2 Equipos no Monitorizados ............................................................................ 60 9 LOS SERVICIOS TECNICOS EN LA ORGANIZACION ................................... 63 10.1 Por la Repercusin en el Servicio Tcnico ................................................ 69 10.2 Por el Momento de Repercusin en el Servicio Tcnico .......................... 70 10.3 Por el Modo de Afeccin al Servicio Tcnico ............................................ 71 11 FUNCIONALIDADES ......................................................................................... 73 11.1 Unos apuntes sobre el Mantenimiento Basado en la Fiabilidad .............. 74 12 INCIDENCIAS CLAVE QUE DEGRADAN EL SERVICIO TECNICO ................ 79 13 DEFINICION DE ESTADOS (SITUACION OPERATIVA) ................................. 81 13.1 Nuevos Estados para mejorar la informacin ........................................... 86 13.2 Nuevos Estados por necesidad del Servicio Tcnico .............................. 86 14 RESPONSABILIDADES .................................................................................... 89 15 INDICADORES DEL SERVICIO TCNICO ....................................................... 91 15.1 Pesos Operativos......................................................................................... 95 15.1.1 Temporales ............................................................................................. 99 33 10 INCIDENCIAS .................................................................................................... 69

15.1.2 Definitivos .............................................................................................. 100 15.2 Pesos Tcnicos .......................................................................................... 103 15.2.1 Reglas Acumulativas ............................................................................. 106 15.2.2 Reglas de Exclusin .............................................................................. 106 15.2.3 Reglas de Inclusin ............................................................................... 108 16 DISPONIBILIDAD DE SERVICIO vs. DISPONIBILIDAD TCNICA ............... 115 17 EL APOYO DE LOS FLUJOGRAMAS (DIAGRAMAS DE FLUJO) ............ 119 18 DIAGRAMA DE FLUJO DE LA FASE DE DISEO ........................................ 121 19 EL CONTROL DE LOS EQUIPOS. MONITORIZACION vs. INCIDENCIAS ......................................................................................................... 123

34

1 DEFINICION DE SERVICIO
Para comprender de qu trata este libro, es conveniente empezar por entender que se expresa con la palabra Servicio. Si nos basamos en la informacin que nos da la Real Academia Espaola, bajo este epgrafe se definen muchos significados:
Servicio . (Del lat. servitum). 1. m. Accin y efecto de servir. 2. m. Conjunto de criados o sirvientes. 3. m. servicio domstico. 4. m. Culto religioso. 5. m. Mrito que se adquiere sirviendo al Estado o a otra entidad o persona. 6. m. servicio militar. 7. m. Favor que se hace a alguien. 8. m. En la poca preconstitucional, contribucin votada por las Cortes. 9. m. orinal. 10. m. retrete ( aposento). U. t. en pl. con el mismo significado que en sing. 11. m. enema. 12. m. Cubierto que se pone a cada comensal. 13. m. Conjunto de alimentos que se ponen en la mesa. 14. m. Conjunto de vajilla y otros utensilios, para servir la comida, el caf, el t, etc. 15. m. Hablando de beneficios o prebendas eclesisticas, residencia y asistencia personal. 16. m. Organizacin y personal destinados a cuidar intereses o satisfacer necesidades del pblico o de alguna entidad oficial o privada. Servicio de correos, de incendios, de reparaciones 17. m. Contribucin que se pagaba anualmente por los ganados. 18. m. Funcin o prestacin desempeadas por estas organizaciones y su personal. 19. m. Dep. saque ( accin de sacar). 20. m. Econ. Prestacin humana que satisface alguna necesidad social y que no consiste en la produccin de bienes materiales.

La mayora, por no decir todos, lejos de lo que queremos expresar, no aportan sentido til para disponer de una definicin que permita desarrollar e identificar un Servicio, excepto, el ltimo de ellos, que nos ofrece un camino para poder definir qu debe ser un Servicio. Obviamente la primera definicin accin y efecto de servir podra introducirnos en dicho concepto, pero es ms real y ms ajustada la ltima definicin. Analicemos la primera de las dos partes que consta dicha frase: Prestacin humana que satisface alguna necesidad social 35

Cuando se quiere establecer un Servicio, lo primero, es tener claro que lo que se va a hacer es satisfacer una necesidad, necesidad, que no siempre tiene que estar demandada previamente, sino que como en muchas circunstancias pasa, se quieren complementar prestaciones previamente establecidas. Por poner un ejemplo, en el transporte de viajeros por carretera, el Servicio lo podramos definir como: Trasladar personas (sin entrar a nivel de detalle) entre dos puntos geogrficos. Pero este traslado puede realizarse mejorando el tiempo de permanencia del viajero en el vehculo, como, acondicionando el ambiente para mayor confort, ofreciendo entretenimiento para hacer ms llevadero el viaje, etc. Estas prestaciones descritas no son esenciales, pues el principal Servicio es trasladar al viajero; pero las prestaciones (Servicios) adicionales mejoran las condiciones del traslado, convirtindose en Servicios de apoyo y que en muchos casos pasan a ser prestaciones inherentes a otro Servicio, como en este caso al Transporte de viajeros. Los Servicios descritos mejoran la oferta, pero como ms adelante se ver, podemos encontrar Servicios que complementan a otros sirviendo de apoyo. Lo que si es discutible para la definicin de Servicio es el detalle de humana. La intervencin del factor humano es evidente en la mayora de los Servicios, pero no es el humano quien lo procura directamente aunque su intervencin y participacin sea determinante. La mayora de los Servicios no los prestan los humanos, son las instalaciones, equipos, sistemas... los que lo proveen. La segunda parte de la frase: no consiste en la produccin de bienes materiales Desde el ms estricto punto de vista as debera ser. Pero la definicin a la que debemos llegar no se engloba slo bajo la palabra Servicio, necesitamos un adjetivo para concretar ms el mbito sobre a qu Servicios nos estamos refiriendo. Dicha palabra es Tcnico, entendiendo por Tcnico que el Servicio que se presta no est en funcin, como la segunda parte de la frase expresa, de no producir bienes materiales. Aunque la mayora de los posibles Servicios Tcnicos no producen bien material, si nos encontrramos con el caso particular de que si se produce, en principio no se desdea, si es posible gestionarlo desde la perspectiva de los Servicios Tcnicos. Con la inclusin del adjetivo Tcnico se pretende acotar, Servicios cuyo enfoque est relacionado precisamente con la operacin y el mantenimiento, e incluso la produccin, como actividades principales del mismo. Qu definicin es la que mejor se ajusta si hablamos de Servicio Tcnico? Con la definicin que debe servirnos como base para su construccin debe ponerse de manifiesto, que tanto lo que se presta como lo que se produce (estos dos aspectos se tratarn posteriormente en detalle) son consecuencia de una actividad que satisface una necesidad, ya sea material o no. Por lo tanto, la definicin que mejor se ajusta para expresarlo es:

36

CONJUNTO DE ACTIVIDADES RELACIONADAS ENTRE S, SOPORTADAS POR EQUIPOS E INSTALACIONES, QUE SATISFACEN UNA NECESIDAD O MEJORAN LAS FUNCIONALIDADES PRESTADAS.
Para finalizar este primer captulo es conveniente tener en cuenta, que no toda la actividad generada debe ser planteada como un Servicio Tcnico. Consideraremos en el momento de disearlo aquel conjunto de actividades que por su repercusin interese, y de la informacin reportada, realizar una mejor Gestin sobre las mismas.

37

38

2 POR QUE DEFINIR SERVICIOS TECNICOS?

Cundo interesa definir un Servicio Tcnico? No existe una nica respuesta a esta pregunta. Como veremos en sucesivos captulos, segn se proporcione toda la informacin para disear y construir un Servicio Tcnico, dispondremos de elementos que nos ayudarn claramente a justificar el por qu de su existencia, pero evidentemente, desde un punto de vista centradamente tcnico. Sin contar con informacin ms all del conocimiento de las actividades que se desarrollan, los principales factores que determinan si se debe o no construir un Servicio Tcnico son: I. II. Repercusin en un tercero, generalmente el cliente directo al que se le presta dicha actividad. Informacin que permita establecer nuevos criterios de gestin para desarrollar e integrar nuevos procesos, as como definir: a. Indicadores Clave de la Actividad (del ingls KPI). b. Indicadores para la definicin y construccin de un Cuadro de Mando. c. Indicadores de Nivel de Servicio. III. IV. V. Integrar distintas actividades relacionadas. Desarrollar una Poltica de Costes de actividades relacionadas. Orientar el mantenimiento como actividad principal de cada Servicio Tcnico.

Y por qu solo estos y no otros? Porque la respuesta est principalmente en el conocimiento de nuestras actividades, analizando los aspectos que permitan justificar el diseo y construccin de un determinado Servicio Tcnico. En el mundo del mantenimiento ferroviario, donde se realizan multitud de actividades entre ellas relacionadas, definir e implementar Servicios Tcnicos proporcionarn nuevas estrategias que permiten mejorar el mantenimiento. Es ms, muchos de los Servicios Tcnicos sern no solo tiles al mantenedor y su cliente directo, sino que adems, podr ser informacin til al cliente externo. Pongamos un ejemplo: Definamos un Servicio de Transporte Vertical entendindolo como al Transporte Mecanizado de personas entre distintos puntos y niveles, dentro del mismo mbito geogrfico. Dicha actividad se presta por medio de Escaleras Mecnicas. La Disponibilidad del Servicio de Transporte Vertical se entendera, como la Disponibilidad de las Escaleras Mecnicas, pero una Escalera Mecnica puede no prestar servicio por causas propias (rotura de un peldao, pasamanos, reductor...), o por causas no propias como una falta de tensin y en esta circunstancia, no podramos ofrecer la Disponibilidad del Servicio si solo centrramos el control de nuestra actividad sobre la Escalera Mecnica. Es necesario integrar en el Servicio Tcnico, los elementos que intervienen en la alimentacin de la Escalera Mecnica y que no son propios de la misma. Pero tambin es posible que se disponga de 39

Telecontrol para operarla remotamente, y en un momento determinado no se pueda actuar por prdida de comunicacin. Todas estas actividades lgicamente, no tienen porque ser desarrolladas por el mismo departamento o contrata. Lo habitual es que dichas actividades lo realicen departamentos expertos diferenciados (Electromecnico, Baja Tensin, Comunicaciones...), que no tienen por qu tener relacin entre ellos, ni estar ubicados en el mismo lugar geogrfico, ni pertenecer a la misma empresa. Supongamos que la contrata C mantiene las Escaleras Mecnicas de un determinado centro comercial. La Disponibilidad (D) de una Escalera Mecnica, ser el resultado de dividir el Tiempo de Funcionamiento (TF) entre el Tiempo de Funcionamiento Terico (TFT), y el Tiempo de Funcionamiento (TF) se hallar restando del Tiempo de Funcionamiento Terico (TFT), el Tiempo de Parada (TP) consecuencia de los diferentes tipos de intervenciones realizadas en la Escalera Mecnica. (D)= (TFT)-(TP)/ (TFT) Si se lleva un registro, todas las paradas de la Escalera Mecnica ajenas a la misma no estarn registradas y por lo tanto, contabilizadas. Esta Disponibilidad servira por ejemplo, para establecer factores de penalizacin en subcontratacin. La Disponibilidad expresada en estos trminos es realmente una Disponibilidad Tcnica, muy directamente relacionada con el Tiempo Medio entre Fallos (MTBF). Como todava es pronto para poner ejemplos reales que reflejen, como dentro de un Servicio Tcnico se producen las relaciones entre los equipos que participan del mismo, necesitamos exponer un ejemplo de fcil comprensin, que permita diferenciar qu se entiende con Disponibilidad Tcnica y con Disponibilidad del Servicio. Analicemos el siguiente supuesto:

Equipo 1

Servidor 1

Servidor 2

Servidor 3

Servidor 4

El dibujo representa una estructura jerrquica de dependencia, donde el Equipo 1 no dar servicio si el Servidor 1 no lo est y ste a su vez, sino lo est el Servidor 2, y as sucesivamente. Adems el Equipo 1 es por decirlo de alguna manera, el equipamiento visible del Servicio. En un momento determinado T 1, el usuario en el Equipo 1 detecta que no puede trabajar y a travs de la Central de Avisos genera una Incidencia. Trascurrido 30 minutos (T 2) el tcnico de mantenimiento del Equipo 1, analiza que el problema no es de este dispositivo, cierra su aviso y abre otro sobre el Servidor 1. Aunque el usuario no haya podido trabajar, al no ser culpable el Equipo 1 del problema, a efectos de computo, la Disponibilidad del Equipo 1 es del 100%. Esta secuencia se repite, hasta que finalmente con el aviso sobre el Servidor 4, el tcnico correspondiente detecta que el problema est en este equipo. Cuando lo soluciona y el usuario puede volver a trabajar en el Equipo 1, la secuencia de tiempo trascurrida ha sido la siguiente:

40

T1

30 minutos

T2

20 minutos

T3

10 minutos

T4

50 minutos

T5

80 minutos

T6

El tiempo que el usuario ha estado sin trabajar ha sido de 190 minutos. Por contra, la Disponibilidad del Equipo 1, Servidor 1, Servidor 2 y Servidor 3 ha sido del 100%, es decir, es como si todo el tiempo hubieran estado en servicio. Si el usuario solicitara los datos de Disponibilidad de su equipo, no coincidiran con el tiempo que ha estado sin trabajar. Muy importante es por lo tanto diferenciar en todo momento, la Disponibilidad Tcnica de la Disponibilidad del Servicio proporcionado por un equipo. Habitualmente con el primero se sobreentiende el segundo, error que como vemos distorsiona la realidad. Para ilustrar hasta que extremo pueden ser diferentes los valores de ambas Disponibilidades, un caso habitual en el mundo del mantenimiento es, cuando un equipo que ha permanecido durante un tiempo sin funcionar por intervencin humana, el motivo por el cual se decidi desconectarlo no justificaba dicha accin. En el momento de procesar el parte de trabajo con las fechas de notificacin de la incidencia y resolucin, al estado asociado se le modifica de parado a en servicio de manera que, la indisponibilidad generada no se computa y la Disponibilidad Tcnica resultante es del 100%. Sin embargo, aunque est absolutamente razonado modificar la situacin del equipo y no deba considerarse dicha indisponibilidad, de cara a la Disponibilidad del Servicio podremos aseverar sin riesgo a equivocarnos que ha sido del 0%. Tambin es prctica habitual que al computar la Disponibilidad Tcnica de un equipo, solo se consideren los partes de trabajo cuya causa del fallo est asociada al conjunto tcnico del mismo. Si como en el primer caso expuesto, alguno de los partes de trabajo no computados para calcular la Disponibilidad Tcnica ha causado indisponibilidad, no la penalizar, pero la Disponibilidad del Servicio si lo debera, siendo 0% como en el caso anterior. Hay muchas otras casusticas que tienen similar comportamiento en el tratamiento del parte del trabajo. Si a esto aadimos todas aquellas paradas ajenas al mantenimiento, pero englobadas dentro del conjunto de actividades realizadas sobre el equipo, el alejamiento entre ambas Disponibilidades se acenta, justificando porque no debe ser usada la Disponibilidad Tcnica como dato ms all del estrictamente tcnico. Pocas son las organizaciones que lo comprenden y menos an las que lo aplican. En el captulo 9 se justificar con ms detalle. 2.1 Necesidades del Cliente Cules son las necesidades de los clientes? Cmo podemos identificarlas? Cuando se define un Servicio Tcnico, ya sea para posteriormente establecer Acuerdos de Nivel de Servicio, o que como simples proveedores queremos medir

41

los servicios que prestamos a los clientes, conviene tener muy presente cuales son sus necesidades. Muchos autores coinciden en establecer diferentes tipos de necesidades, que generalmente pueden o no existir simultneamente, y en algunas circunstancias muchas de ellas son implcitas a la demanda. Desde nuestro punto de vista, la relacin que mejor agrupa qu tipos de necesidades existen para los clientes, es la que engloba los siguientes seis conceptos: 1) Prestaciones. Se consideran las funciones del producto y el uso esperado en funcin de los requerimientos. 2) Seguridad. ste es de los que podemos considerar implcito, pues se da por asumido que cualquier producto realizado debe cumplir las normas de seguridad legales establecidas y propias del mismo. Tambin es cierto que todos los productos no necesitan cumplir ninguna norma especfica. 3) Disponibilidad. A cualquier producto se le va a pedir que sea: a. Fiable. El mayor tiempo funcionando con el menor nmero de problemas. b. Mantenible. En algunos productos, la posibilidad de intervenir para recuperar sus caractersticas, propiedades y/o funciones iniciales. c. Durabilidad. Tanto del conjunto como de cada uno de los elementos que lo compone. 4) Servicio. Fcil de usar y normalizado, es decir, compatibilidad con el resto de productos existentes. gran

5) Imagen. Bajo algunas circunstancias, se convierte en el principal argumento para quin lo adquiere. En estos casos, la repercusin sobre un tercero del adquiriente (su cliente) es factor prioritario y las mediciones orientadas a conocer la traslacin de la imagen, tambin. 6) Medioambientales. Dada la alta concienciacin existente por el uso de los recursos y el impacto generado en el medio ambiente, el producto debe estar alineado con estrategias proteccionistas y conservacionistas. Podemos tambin considerar a esta necesidad de las implcitas. Se podran identificar algunos tipos ms como, la legalidad (ms all de la aportada por la seguridad), el cumplimiento de las expectativas, los recursos humanos, obligaciones..., pero, o son en un orden de prioridades menores, o pueden ser integradas en algunas de las expuestas. Conociendo las necesidades, queda el aspecto final, definir al cliente.

42

2.2 Cliente Directo El cliente directo y ms correcto segn la orientacin actual de Gestin (Management), el cliente interno o externo, segn sea el caso, es aqul destinatario de nuestros trabajos y servicios. Para el mbito del mantenimiento, habitualmente el cliente interno ser el personal de Produccin y/o Explotacin, y a quien deberemos enfocar el servicio consecuencia de las actividades. Ser necesario medirlo, acordar y adecuar con el cliente los niveles proporcionados y una vez el servicio est en explotacin, quien nos ayude a mejorarlo participando en la orientacin de nuestros esfuerzos para conseguirlo. Pero tambin los Servicios Tcnicos pueden ser tiles para el cliente externo, ya que los mantenedores desde un punto de vista empresarial, son proveedores de servicio y como tales, los Servicios Tcnicos no acaban en el cliente interno. ste nos demandar el mejor servicio posible, pues su actividad est orientada hacia el cliente externo. La medicin del grado de satisfaccin de ambos y la convergencia o divergencia de ese valor, ser de gran ayuda en la mejora continua de los Servicios Tcnicos.

43

44

3 POR QU UN SERVICIO TECNICO?

Observemos la representacin que nos va a servir para ilustrar este captulo1.

Seguridad (Recargas)

Soporte Redes

Compaa Telefnica A

Compaa Telefnica B

Cajero

Red de Comunicaciones

X-25 Servidor Sucursal

Servidor Central Banco A

Frame-Relay

BBDD Banco B

Mantenimiento Electromecnico

Operadores

CPD

Consultores Informticos

Supongamos que estamos de viaje y necesitamos urgentemente dinero. Buscamos un cajero que sea de nuestra red asociada o alguna sucursal que tenga concierto con nuestra entidad bancaria. Una vez encontrado, sacamos nuestra tarjeta, la introducimos, tecleamos la clave y seleccionamos Sacar Dinero. En ese momento nos sale el mensaje de:

SU OPERACIN NO PUEDE SER ATENDIDA EN ESTE MOMENTO

Indignados por la situacin que nos produce no poder disponer de nuestro dinero , entramos en la sucursal y nos quejamos. Poco nos importa que la sucursal no sea de nuestro banco, que el cajero no pueda haber atendido nuestra solicitud porque la empresa de seguridad que repone el dinero no lo haya recargado, que la empresa de mantenimiento de los cajeros no haya solucionado la avera del contador de dinero, que la red informtica de la sucursal est cada por un problema en los equipos de red, que la base de datos del servidor de la sucursal no est activa y no conecte con la central, que la lnea de comunicaciones de la compaa telefnica que enlaza la sucursal con la central no est operativa, que los servidores centrales tengan un problema de versiones y se est realizando una actualizacin, que el enlace satlite entre la central del banco y la del nuestro no est operativa...
1

X-25 y Frame Relay son tecnologas de infraestructuras de comunicacin

45

Explicaciones puede haber muchas pero la consecuencia solo una. No hemos obtenido nuestro dinero cuando ms lo necesitbamos y para nosotros, quin es el culpable? Slo uno! La sucursal donde bamos a realizar la operacin aunque la causa del problema no sea competencia directa de la misma. Si en este caso se hubiera establecido el Servicio Tcnico, llammosle de Cajeros Automticos, una de sus funcionalidades no estara operativa, quizs la nica que disponga el cajero. Muy importante para el Servicio Tcnico, es que tenemos identificado el elemento por medio del cual, se est prestando y/o percibiendo el servicio. Este ejemplo cotidiano nos permite identificar la necesidad de implementar Servicios Tcnicos, porque en la prestacin de un determinado conjunto de actividades intervienen muchos actores, cada uno de ellos con mayor o menor responsabilidad en dicha prestacin. Si lo que se presta est diseado y construido como un Servicio Tcnico, de todos los participantes i dentificaremos un nico Responsable, con capacidad para demandar a todos aquellos que intervienen. Al integrar todas las actividades, es decir, los equipos que intervienen en un Servicio Tcnico, nos va a permitir conocer en que Estado est lo que se pre sta, es decir el Estado del Servicio. La ventaja es obvia. Identifica los aspectos ms dbiles y ms fuertes de manera que, se pueden establecer las estrategias que se consideren en cualquier momento ms oportunas para la prestacin del Servicio Tcnico, orientando el mantenimiento, los recursos materiales, las personas... en definitiva, el conjunto de las actividades y mejorando la coordinacin entre ellas. Y cmo lo hacemos? Midiendo el servicio que se presta, percibe, o ambos.

46

4 OBJETIVOS Y CLASIFICACION DE LOS SERVICIOS TECNICOS

Los tres objetivos que debe satisfacer un Servicio Tcnico y como consecuencia su implementacin son: 1. Conocer el Servicio Tcnico. Para... a. ...controlar el servicio prestado/percibido. Para ello es necesario establecer un conjunto de mtricas que permitan conocer en tiempo real el Estado, la Disponibilidad, la Evolucin en el tiempo... Muchos pueden ser los Indicadores posibles a definir para cada Servicio Tcnico, pero lo ms importante es que lo evalen realmente. Consecuentemente, todo Servicio Tcnico construido debe ser medible, permitiendo establecer la magnitud correcta de lo que se presta y/o percibe. b. ...asegurar el servicio. Establecer las acciones y parametrizaciones necesarias que permitan garantizar el Servicio Tcnico. Construir el Servicio Tcnico permite identificar los puntos dbiles del sistema, procesos, recursos... Si lo que se presta o percibe es crtico bajo determinadas circunstancias. Las acciones pueden estar enfocadas a redundar el equipamiento, priorizar actividades, analizar el mantenimiento por medio de metodologas... c. ...reducir las ausencias de servicio. Como proceder ante las Incidencias. Cuando se presta un servicio lo ms importante es, garantizar que est operativo cuando se demande. Como proceder ante una avera o degradacin, habiendo desarrollado los mtodos de actuacin adecuados consecuencia del anlisis de cada situacin, reducir el impacto de las faltas de servicio. 2. Medir el esfuerzo. Cuando una organizacin est proveyendo un servicio, requiere disponer de una estructura mnima que le permita su control. Por contra, el receptor del servicio normalmente no es consciente de ese esfuerzo. En servicios donde el receptor participa del mismo (cliente interno), generalmente solo repercute o se valora esta participacin. Independientemente de si con recursos propios o ajenos se est ofertando un servicio, vincular el esfuerzo desde el nivel ms bsico u operativo, hasta el de mayor nivel o gestin supone: Integrar las actividades, alinear los objetivos, mejorar la interlocucin, aunar esfuerzos y garantizar una mejor oferta. 3. Lo que cuesta. El receptor del servicio, independientemente de si es el cliente interno o externo, demanda continuamente la mejor oferta y 47

calidad desde su punto de vista. Pero optimizar y mejorar un determinado cumplimiento de servicio, independientemente de que la percepcin del mismo no sea satisfactoria, puede suponer unos costes excesivos no asumibles. En los casos en los que la oferta de servicio es satisfactoria, la mayora de las veces se debe a esfuerzos, tanto humanos, como econmicos considerables, que deben continuamente ser evaluados. En cualquiera de los dos casos, conocer los costes proporciona una medida determinante de valoracin del servicio. Tan crtica es, que en las circunstancias donde el servicio no sea satisfactorio, ser necesario renegociar y establecer de nuevo cual es el grado de satisfaccin, para lo que los objetivos 1. y 2. sern esenciales. El cumplimiento de los puntos a, b y c, garantiza la correcta implementacin de cualquier Servicio Tcnico, pues implcitamente, estamos priorizando nuestras actividades hacia el cliente que en definitiva, es nuestro principal auditor. Pero no todos los Servicios Tcnicos, tanto desde el punto de vista del proveedor como del cliente, tendrn igual consideracin. Dependiendo de sus caractersticas los podemos encuadrar en: 1. Servicios Bsicos: Aquellos necesarios para realizar un conjunto de actividades relacionadas y que generalmente, satisface una demanda directa. 2. Servicios de Apoyo: Aquellos que sin ser percibidos directamente por el cliente, soportan los Servicios Bsicos. 3. Servicios Terciarios: Aquellos que mejoran o complementan los Servicios Bsicos. Asociar cada Servicio Tcnico a desarrollar en cada uno de estos grupos, nos ayudar a priorizar aquellos Servicios Tcnicos que sean claves para la organizacin, independientemente de cual pueda ser la razn. Por supuesto que la clasificacin de un Servicio Tcnico estar en funcin de las actividades, un ejemplo lo tendramos en: Como Servicio Bsico, Transporte Vertical. Como Servicio de Apoyo, Suministro y Distribucin de Corriente. Como Servicio Terciario, Telemando de instalaciones. Pudiendo tener Servicios Tcnicos que cumplen dos de los tipos. Finalmente resear, que es posible construir Servicios Tcnicos con identidad propia y que a su vez, estn integrados dentro de otro complementndolo.

48

5 FASES
Cuando en una organizacin sea necesario abordar la agrupacin de las actividades para conformar un Servicio Tcnico, el xito depender de si en cada fase del proyecto, el trabajo se ha realizado correctamente de acuerdo a las directrices marcadas en cada una de ellas. Por ello es importante que identifiquemos cada fase y su significado, como introduccin previa a su desarrollo posterior. Esto nos permitir establecer los requerimientos y cuales deben ser los alcances.

En el presente libro slo se desarrollarn las fases de Diseo y Construccin, como condicin inseparable para la mejor comprensin de los Servicios Tcnicos, dejando para futuras revisiones o ampliaciones el resto. 5.1 Diseo En esta fase definiremos el Servicio Tcnico como tal. Estableceremos las Generalidades, Definicin y Alcance (captulo 7), los Equipos del Servicio Tcnico (captulo 6 y 8), las Funcionalidades (captulo 11), los Estados (captulo 13), las Incidencias Operativas (captulo 12) siempre que existan y los Indicadores (captulo 15) necesarios para controlar el servicio. Tambin se definirn los Flujogramas de Estados y de Servicio (captulo 17). Por ltimo, se realizarn las Tablas de Simulacin (anexo) y la Matriz de Estados. Cada uno de estos apartados, as como muchos conceptos que irn surgiendo como semntica propia de los Servicios Tcnicos, sern tratados con profusin en los prximos captulos. 49

En esta fase tambin se plantearn las mejoras a realizar consecuencia de los resultados de la fase de Explotacin y Auditora, como proceso de mejora continua y evolucin del Servicio Tcnico. Identificaremos inicialmente los diferentes tipos de usuarios en funcin de sus caractersticas y alcances, tanto tcnicos como de gestin. Durante las siguientes fases aparecern otros tipos de usuarios, pero de partida, los posibles tipos de usuario y sus funciones son: 1. Consulta. Usuarios cuyo perfil se reduce prcticamente a la obtencin de informacin, ya sea para su propio uso y anlisis, que como intermediario de facilitarla. 2. Operador. Sus funciones estaran relacionadas con la carga y mantenimiento de los datos, as como garantizar la consistencia de la informacin (Auditar). 3. Supervisor. Entre sus competencias estaran: a. Alta, baja y modificacin de usuarios. b. Asignacin de roles (tipos de usuario). c. Autorizacin de las altas, bajas y modificaciones de datos. d. Supervisin de las actividades anteriores. 4. Gestor. Es el principal usuario. Garantiza el funcionamiento de los Servicios Tcnicos. Las principales tareas a realizar y desarrollar son: a. Disear conceptualmente los ST. b. Modelizar. Definir los Pesos Operativos y Tcnicos, Relaciones Alarmas<->Estados y Sntomas<->Estados, Equipamiento Implicado e Indirecto... c. Analizar la informacin (Indicadores, Listados...). d. Disear nuevos Indicadores. e. Detectar necesidades. f. Auditar la aplicacin y la informacin obtenida. Como es lgico, puede haber usuarios que estn dentro de dos o ms tipos. 5.2 Construccin Definido el Servicio Tcnico es el momento de construirlo. Todo lo diseado debe ser desarrollado en alguna plataforma informtica para su automatizacin, que permita la mayor capacidad de integracin tcnica y fidelidad con lo diseado. Es una fase dura e ingrata por lo que significa hacer tangible conceptos y 50

planteamientos la mayora novedosos, consecuencia de la fase de Diseo. Es una fase de msculo. 5.3 Piloto Es necesario alimentar a la aplicacin informtica desarrollada, para saber si est bien construida conforme se estableci en la fase de Diseo. Seleccionaremos un conjunto de datos (en el siguiente apartado se menciona la informacin ms relevante) imprescindible, para establecer un Piloto de pruebas con el que garantizar los resultados. Se puede entender como un test previo, para tener una valoracin inicial sobre aspectos determinantes y que garanticen en la medida de lo posible, la prueba general de conjunto que ser necesario realizar en la fase de Consolidacin. De los resultados depender la decisin de replantearse volver a la fase de Diseo o continuar. Por ello, la ausencia de flecha de conectividad con las fases previas, pues supone un nuevo comienzo. 5.4 Modelizacin Una vez construido el Servicio Tcnico, es necesario cargar toda la informacin con el Equipamiento, Horarios, Pesos Operativos, Pesos Tcnicos, Disponibilidades Medias de Servicio por Equipo, Relaciones entre Equipos, Relaciones entre SntomasEstados, Relaciones entre AlarmasEstados... En definitiva, toda la informacin necesaria para echarlo a rodar. Cada uno de los conceptos expuestos, sern tratados ampliamente en los siguientes captulos y completados en la parte del libro dedicado a la fase de Construccin. 5.5 Consolidacin Una vez que tenemos cargados todos los datos indispensables para que el Servicio Tcnico funcione, y antes de poder decir que est en Explotacin, supervisaremos que la informacin obtenida corresponde en un grado de exactitud elevado a las expectativas generadas. Es el TEST con maysculas. Sino es as y dependiendo de cual sea la causa, ser necesario reiniciar el ciclo en la fase de Diseo, Construccin o Modelizacin, en funcin de los fallos encontrados y/o defectos producidos. Si el resultado es positivo, se realizarn las Pruebas de Usuario, enfocadas a determinar si la formacin impartida es la correcta y los entornos grficos (pantallas) de interaccin con el usuario son amigables e intuitivos. Como consecuencia, y previo a las pruebas, ser necesario haber formado a los usuarios segn su nivel correspondiente al perfil asignado. 5.6 Explotacin Esta fase es propiamente aquella en la que el Servicio Tcnico est totalmente implementado, proporcionando a la Organizacin toda la informacin para la que fue diseado. Durante esta fase, ser necesario peridicamente o bajo demanda, desarrollar y/o realizar entre otras tareas: 51

Asignar roles (perfiles de usuario) . Cualquier aplicacin como mnimo consta del administrador y de los usuarios (nivel de consulta). Supervisar las actividades. Si se cumplen los procedimientos, es decir, las actividades estn orientadas al Servicio Tcnico. Altas, Bajas y Modificacin de los datos. Extraccin de las tablas de datos, cargas masivas... Modelizar. Definir nuevos Pesos Operativos y Tcnicos, Relaciones AlarmasEstados y SntomasEstados, nuevo Equipamiento y sus Relaciones... Analizar la informacin (Indicadores, Listados...). Dijimos que uno de los objetivos de un Servicio Tcnico es controlarlo y para ello, dispondremos del conjunto de requerimientos de la fase de Diseo para evaluar el comportamiento y tomar decisiones.

5.7 Auditoria An cumpliendo las expectativas iniciales, es positivo replantearse todo el proceso y las actividades relacionadas con los Servicios Tcnicos desde el punto de vista intrnseco del aplicativo, es decir, garantizar tanto la informacin de partida como el resultado obtenido, y adems, asegurar el comportamiento (reglas, parametrizaciones...) de la herramienta. Al principio, la Auditora ser una fase que existe casi en paralelo a las fases de Modelizacin, Consolidacin y Explotacin, pero llegado al punto de equilibrio, el da a da ser la explotacin como tal del servicio. No obstante peridicamente, y principalmente cuando el escenario sobre el cual se dise el Servicio Tcnico se modifique sensiblemente, ser necesario: Supervisar las actividades. Analizar si los procedimientos establecidos son mejorables. Estudiar y planificar las actividades para incrementar la oferta de servicio. Analizar la informacin (Indicadores, Listados...) Detectar necesidades (Indicadores, Listados, Alcances...)

En esta fase, como tarea importante dentro del conjunto de auditoras a realizar, estar la del Anlisis de Costes asociado a cada Servicio Tcnico. Aunque por ahora no es posible orientar en los trminos ms adecuados sobre como realizar dicha actividad, en lneas generales si podemos adelantar que, con pequeas adecuaciones, seguirn lo ms fielmente posible las tendencias actuales que sobre esta materia existen. Solo es cuestin de integrar la informacin necesaria en el sistema. Las conclusiones extradas de las actividades desarrolladas durante esta fase, permitirn realimentar todo el sistema para evolucionarlo y mejorarlo.

52

Es posible que el lector eche en falta actividades inherentes a todo proyecto como, la formacin, la documentacin... No es que no estn contempladas en ninguna de las fases, sino que por no redundar en aquellas acciones que son indispensables en todo proyecto no se mencionan, pues no aportan informacin relevante del resto de acciones que intrnsecamente a cualquier Servicio Tcnico es obligatorio hacer. El grueso de la formacin sera impartido durante la Consolidacin, mientras que la documentacin se desarrollara en cada una de las fases, siendo en la fase de Explotacin, cuando se constatara si es suficiente con la que se ha elaborado o por contra, es necesario ampliarla. Desde el punto de vista de los Servicios Tcnicos no tienen stas, y otras posibles actividades, la importancia de ser consideradas Fases, y solo en los casos que se justifique podra ser la formacin una fase intermedia entre la Modelizacin y la Consolidacin.

53

54

6 POR DONDE COMENZAR?

En el captulo 3 el ejemplo expuesto nos permite identificar por donde comenzar. En cualquier Servicio Tcnico lo primordial es identificar el Equipo, Sistema o Instalacin por medio del cul se presta el servicio, pero adems, el cliente lo percibe. Como decamos, el cajero es el equipo por el cual identificamos tanto la prestacin como la percepcin. No importa cuantos elementos intervengan en el Servicio Tcnico. En algunas circunstancias puede suceder que el propio equipo o instalacin es el nico que interviene. Por qu es importante identificar dicho nivel? Pues porque todo lo que sea necesario disear, modelizar, parametrizar... para construir el Servicio Tcnico, se establecer y repercutir en el mbito de dichos equipos o instalaciones. Por ello, a ese equipo o instalacin lo vamos a llamar Equipo Clave y lo definimos como:

Aquel por medio del cual identificamos la prestacin o lo que es lo mismo, la percepcin del Servicio Tcnico
Evidentemente no tiene porque existir un solo tipo de equipo clave. Podemos encontrarnos con varias taxonomas, estableciendo para cada una de ellas las circunstancias apropiadas que concurran. Un ejemplo concreto podra estar en el Servicio Tcnico de Mquinas Expendedoras (bebidas, comida, regalos...) cada una de ellas no se comportar igual en el momento de tratarlas, pero identifican el Servicio Tcnico que se est ofertando. En otros casos sin embargo, teniendo perfectamente identificado el elemento por el cual se presta y/o percibe el servicio, puede interesarnos que no lo sea porque disponemos de otro que mejora el control y las prestaciones del Servicio Tcnico. Un ejemplo puede ser el Servicio Tcnico de Corriente Continua (Tensin) para una explotacin ferroviaria. El elemento plenamente identificado sera la lnea area 2 o catenaria3, pero dicho elemento, no solo por sus caractersticas de linealidad dificulta el diseo del Servicio Tcnico, sino que como equipamiento proporciona pocas posibilidades de medicin y control. En este caso conviene identificar un elemento aguas arriba que permita el mismo grado d e diseo, y adems admita parametrizaciones. Dicho elemento estara identificado en los Disyuntores4 de las Subestaciones Elctricas, por medio de los cuales se suministra la tensin a los

Lneas de contacto o de distribucin de energa de traccin para alimentar a las unidades de material mvil-trenes3 Lnea area de contacto con un cierto grado de movilidad en altura y horizontalidad, formada por una serie de hilos, cables, soportes, aisladores y dems elementos encargados del reparto de la conduccin elctrica 4 Aparatos de corte con soplado electromagntico y mando elctrico o magntico, siendo su principal caracterstica la rapidez de funcionamiento de forma que, consiga interrumpir la corriente de defecto antes de alcanzar valores peligrosos de cortocircuito

55

tramos de catenaria, y proporcionan seguridad ante problemas de suministro, fallos de tensin o de cualquier otra ndole. Identificar el equipo o instalacin clave, es el primer paso obligatorio para el diseo del Servicio Tcnico. Las pautas que debe poseer un equipo o instalacin, para cumplir la funcin de Equipo Clave son: 1. Que el Servicio Tcnico sea identificado plenamente en dicho equipamiento. 2. Que admita parametrizacin. 3. Que el conjunto de actividades desarrolladas sobre dicho equipamiento estn identificadas. Sino cumple alguno de estos tres requisitos, difcilmente podremos implementar ningn Servicio Tcnico. Por contra puede suceder, que identificado al equipo clave descubramos, que el nivel de parametrizacin es mayor del existente, que las actividades no estn plenamente identificadas o que permita desarrollar otras nuevas. Es una ventaja inversa muy til. Solo es necesario echar un vistazo al captulo 4 y recordar los objetivos de todo Servicio Tcnico.

56

7 DISEANDO UN SERVICIO TECNICO

Hemos identificado el Servicio Tcnico y sabemos qu requisitos deben cumplir los equipos clave. Los primeros pasos, aunque no deben ocupar mucho tiempo, son importantes para orientar los siguientes. Por decirlo de alguna manera, conforman las bases del resto del diseo como soportes esenciales en los que fundamentarlo, y a los que se recurrir con cierta frecuencia durante el tiempo que lleve disear, construir y poner en produccin cualquier Servicio Tcnico, ya que encierran la esencia del mismo. Enumeremos las acciones iniciales que debemos realizar para disear el Servicio Tcnico: I.) Establecer las Generalidades Un Servicio Tcnico puede estar constituido por un nico tipo de equipo clave o por varios. Incluso dentro del mismo tipo de equipo o taxonoma, podemos encontrar diferentes modelos, los cuales ofrecen en unos casos ms o menos funcionalidades, incluso distintas. Es importante analizar y especificar cada uno de dichos equipos y taxonomas, pues de dicho conocimiento, derivar el desarrollo de las funcionalidades que cada uno de ellos aporta, su importancia, e impacto en el Servicio Tcnico. II.) La Definicin del Servicio Tcnico Definir el Servicio Tcnico permite establecer el escenario del mismo, acotndolo y diferenciando otras posibles funcionalidades que no competan a la hora de construirlo, siendo susceptibles por si mismas del diseo de otro Servicio Tcnico totalmente distinto. Supongamos que definimos el Servicio Tcnico de Mquinas Expendedoras como: El conjunto de sistemas electromecnicos ubicados en lugares pblicos, para la adquisicin de productos de consumo de alimentacin humana. Con esta definicin, nuestro Servicio Tcnico est acotado al dispensado de un producto alimenticio previa introduccin de las monedas, proporcionando cambio si se requiriera. Supongamos que las mquinas estn diseadas, para proporcionar la contabilidad de las ventas centralizadas en un departamento subcontratado va red telefnica de datos, cuya informacin todos los das se trasmite. Pues tal y como se ha definido el Servicio Tcnico de Mquinas Expendedoras, esta funcionalidad no es competencia del mismo y s susceptible del diseo de otro diferente, cuyo equipo clave son los mismos equipos, pero en un escenario totalmente diferenciado. Los equipos y/o sistemas relacionados que pueden intervenir en uno y otro Servicio Tcnico tambin pueden ser distintos. 57

III.) Establecer el Alcance Definir el Alcance permite disear y construir estrategias orientadas a ofertar el mayor servicio posible, en tiempo y forma. Del ejemplo anterior tendramos como Alcance: Garantizar el correcto funcionamiento de equipos y ejecucin de las tareas necesarias, para que los usuarios obtengan los productos solicitados, proporcionando el cambio correspondiente al dinero introducido. Estos tres pasos son el germen para disear el Servicio Tcnico. Podran ser considerados como los Principios del Servicio Tcnico. Todo esfuerzo futuro, toda duda que surja, cualquier matiz que sea necesario precisar, si algo es o no parte del Servicio Tcnico, tendr respuesta en su lectura. Tanto es as, que incluso pueden llegar a sufrir alteracin como consecuencia del desarrollo e implantacin del propio Servicio Tcnico. Establecidas las Generalidades, la Definicin y el Alcance, el paso siguiente es identificar los equipos y/o sistemas que soportan el Servicio Tcnico, conjuntamente con los diferentes tipos de equipo claves.

58

8 EQUIPAMIENTO DEL SERVICIO (EQUIPAMIENTO IMPLICADO)

A la hora de disear un Servicio Tcnico, es necesario considerar todos aquellos equipos y sistemas que lo componen. En el ejemplo del captulo 3 intervienen multitud de instalaciones y equipos, algunos discretos, pero otros no. La relacin es la siguiente:

Cajero Red de Comunicaciones de la sucursal Servidor de Datos de la sucursal (Banco Z) Lnea de comunicaciones (X-25) Servidor Central (Banco Z) Lnea de comunicaciones (Frame Relay) Servidor Central (Banco Y)

Lo ideal para disear el Servicio Tcnico, es poder establecer la malla de relaciones entre los diferentes equipos y sistemas que son necesarios para prestarlo. Pero como en el propio ejemplo se aprecia, no siempre se tiene el conocimiento o las competencias para disearlo. En estos casos y dependiendo de cada Servicio Tcnico, lo principal es identificar los equipos y/o sistemas discretos necesarios. Del ejemplo, los equipos que cumplen esta circunstancia son:

Cajero Servidor de Datos de la sucursal (Banco Z) Servidor Central (Banco Z) Servidor Central (Banco Y)

Controlando el estado de cada uno de estos equipos, conocemos el Estado del Servicio en todo momento, excepto, cuando el problema est en las Comunicaciones, pudiendo darse la paradoja de que los cuatro equipos estn en perfecto funcionamiento, el Estado del Servicio estara al 100% y sin embargo, el Estado del Servicio percibido por el cliente sera del 0%. En estos casos, estableciendo mecanismos de control en cada uno de los niveles por encima del elemento clave y chequeando peridicamente su conectividad con el nivel inferior, podremos conocer en todo momento el Estado del Servicio que se est prestando. Significa que no incluiremos nunca este otro tipo de equipos? Por supuesto que no. Si en el ejemplo expuesto, la red de comunicaciones de la sucursal la forman equipos claramente identificados, sobre los cuales es posible establecer el Flujo del Servicio, los incluimos dentro del Servicio Tcnico. La dificultad surge con la redundancia de los equipos. Muchas de las infraestructuras de comunicaciones, redes informticas... poseen equipos redundados de manera que ante la cada de uno de ellos no se interrumpa la conectividad. Si como hemos comentado las competencias estn fuera del alcance por el motivo que sea, articularemos el 59

mtodo ms eficaz para controlar la conectividad. Pero si existe la posibilidad, el esfuerzo a realizar para incluirlos puede proporcionar beneficios notables. En muchos casos, por no decir la totalidad, cualquier Servicio Tcnico puede estar condicionado por las comunicaciones y si se han analizado, el estudio resultante puede ser de aplicacin en cualquier otro Servicio Tcnico que a posteriori se disee. Pero, cmo plantear la redundancia de equipamiento? La redundancia no es exclusivamente una implementacin que encontraremos en las comunicaciones. En el ejemplo expuesto, el Servidor Central no suele ser un nico equipo. Generalmente son granjas de servidores o clusters, que funcionan permanentemente durante las 24 horas, o el tiempo que deban estar en servicio. La redundancia o paralelismo se tratar en captulos posteriores durante la construccin. En la fase de Diseo no tiene mayor trascendencia. Las tres primeras conclusiones que debemos considerar son: 1) Para disear un Servicio Tcnico, hacerlo identificando en la medida de lo posible solo los elementos discretos. 2) Si fuera necesario, construir en cada nivel por encima del elemento clave, mecanismos de chequeo de la conectividad. 3) El Flujo del servicio lo conforman todos los equipos/sistemas, discretos o no del Servicio Tcnico. La construccin del Diagrama de Flujo del Servicio, ayuda tanto en el diseo como en la construccin. Pero tal y cmo estamos diseando el Servicio Tcnico, se construyan o no los mecanismos de chequeo, solo cuando alguien necesite sacar dinero y no lo obtenga, ante la queja, se generar la incidencia desencadenando las acciones necesarias para determinar dnde est el problema, porque, supongamos que el Servidor de la sucursal detecta la falta de conectividad con el cajero, sino hay nadie supervisndolo, el Estado del Servicio permanece invariable. Por esta circunstancia, existirn dos tipos de equipos a la hora de construir cualquier Servicio Tcnico. Equipos Monitorizados y No Monitorizados. 8.1 Equipos Monitorizados Se define por Equipo Monitorizado , aqul que est supervisado remotamente, proporcionando en tiempo real toda la informacin necesaria para su gestin. La monitorizacin depender de sus caractersticas. En algunos equipos/sistemas bastar con instalar software adicional o construir los programas oportunos para permitir dicha monitorizacin. En otros, su antigedad, caractersticas mecnicas, orientacin industrial,... ser necesario dotarlos de elementos externos de comunicacin y supervisin. 8.2 Equipos no Monitorizados Se define por Equipo No Monitorizado , aqul que no tiene ningn tipo de supervisin y por lo tanto, solo se conoce su Situacin Operativa posteriormente a cualquier notificacin que se produzca sobre l o sobre cualquier otro equipo 60

implicado en el Servicio Tcnico. Bajo esta premisa, es imprescindible contar con una herramienta que permita el registro de las incidencias y dems actividades realizadas sobre el equipamiento. Estas aplicaciones se conocen como GMAO5, por ejemplo, el modulo de Mantenimiento (PM) de SAP. SAP (System, Anwendungen und Produkte -Sistemas, Aplicaciones y Productos-) es un software de gestin integrada orientado al mundo empresarial, que consta de multitud de mdulos para la informatizacin de los diferentes departamentos, como pueden ser: Recursos Humanos, Financiero, Contable, Logstica... Tambin existen programas software diseados exclusivamente para el Mantenimiento y que ofrecen como ventaja competitiva, frente a paquetes integrados tipo SAP, su alto grado de especializacin, versatilidad y adaptabilidad. Algunos ejemplos seran PRISMA o MAXIMO. Un Servicio Tcnico puede estar compuesto, tanto por Equipos Monitorizados, como por equipos No Monitorizados. Slo es necesario establecer los alcances de cada uno de ellos sabiendo que, el impacto en el Estado del Servicio de unos ser en tiempo real y en otros no. Lo ideal es monitorizar todos los equipos y ms, si como en el ejemplo del cajero, es necesario integrar en los diferentes equipos relacionados con ste, controles que permitan conocer la conectividad con el equipo de nivel inferior. Supongamos en el Servicio Tcnico que estamos analizando, que los equipos no estn monitorizados. Ante la imposibilidad de reintegro, la incidencia que genera recaer inicialmente sobre el cajero y a medida que en cada uno de los diferentes equipos/niveles se vaya garantizando que no est el problema, el restablecimiento del servicio se ir demorando. Esto significa que monitorizar los equipos, no solo permite obtener ms fiabilidad respecto a la informacin necesaria para el Servicio Tcnico, sino adems, realizar una gestin de cualquier tipo de incidencia ms eficaz. Por todo lo expuesto, se denomina Equipamiento Implicado a:

Todo aquel que es necesario para la prestacin del servicio de manera que, cualquier Incidencia que surja en dicho equipamiento puede afectar al Estado del Servicio
Hemos definido el Equipamiento Implicado. Bien, pues aunque no siempre sucede, podemos encontrarnos con equipos o sistemas que an no estando implicados, si bajo determinadas condiciones pueden afectar al servicio ofertado. A este equipamiento le denominaremos Equipamiento Indirecto y se define como:

Cualquier equipo que no es necesario para la prestacin del servicio, pero que bajo determinadas
5

Gestin de Mantenimiento Asistido por Ordenador

61

circunstancias retrasan o dificultan la reposicin o puesta en marcha del servicio

Un ejemplo de este tipo de equipamiento lo tenemos en los telemandos. Supongamos un conjunto de Escaleras Mecnicas de un Centro Comercial. Cada uno de estos equipos es posible ponerlo en marcha localmente, pero por eficacia y comodidad, cada Escalera Mecnica dispone de la tecnologa necesaria para ser activada o detenida en remoto. Si en el momento de abrirse el Centro Comercial al pblico, no es posible poner en marcha las Escaleras, lo que remotamente ocupa entre 10 15 minutos, dado que hay que iniciarlas localmente, se convierten en ms de 60 minutos repercutiendo en el servicio ofertado. La Escalera parada reporta el mismo Estado del Servicio, el 0%, pero puede interesar en algunas organizaciones diferenciar, cuando un Equipamiento est parado por circunstancias ajenas al propio Servicio Tcnico porque no es el responsable, sino como en este caso, el causante de no estar operativo y como consecuencia sin servicio es el Telemando. Como se ver en el captulo de Estados, cuando se den estas circunstancias, el Estado del Equipo no ser Parada Manual sino Parado sin Telemando.

62

9 LOS SERVICIOS TECNICOS EN LA ORGANIZACION

Analicemos el siguiente esquema:

GESTION DE SERVICIOS

GESTION DE INCIDENCIAS

GESTION DE MANTENIMIENTO
La definicin de cada uno de los niveles es: Gestin de Servicios: Conjunto de acciones encaminadas a la medicin y prestacin de los Servicios Tcnicos Gestin de Incidencias: Conjunto de acciones encaminadas a la medicin y repercusin de las Incidencias. Gestin del Mantenimiento: Conjunto de acciones encaminadas al control de los equipos, las instalaciones y la operatividad de la mano de obra. Qu se identifica en cada nivel? Partiendo de una organizacin donde concurren multitud de departamentos de mantenimiento (mecnicos, elctricos, informticos...), el primer nivel (Gestin de Mantenimiento) lo conforman los sectores operativos (personal operario), aquellos que estn en contacto con los equipos en campo. La gestin del mantenimiento se realiza por medio de las Ordenes de Trabajo, Partes de Actividad, Ordenes de Ejecucin... en definitiva, Parte de Trabajo. Fundamentalmente, los dos tipos de mantenimiento que realizan son Preventivo y Correctivo. El siguiente nivel (Gestin de Incidencias) estara formado por la organizacin que centraliza la notificacin de las incidencias en el equipamiento, instalaciones o sistemas. Dentro de esta Gestin est tanto, la posibilidad de intervencin remota (si la hubiera), como la identificacin del departamento o departamentos de campo responsables de la resolucin de la incidencia. En este nivel, tanto si se dispone de control remoto (Monitorizacin de equipos), como por medio del comunicante de la incidencia, es posible realizar actividades de mantenimiento. 63

El ltimo nivel proporciona la visin conjunta del equipamiento existente, en definitiva, identifica los Servicios Tcnicos prestados por el conjunto de actividades que se desarrollan en los niveles uno y dos. Por qu los tres niveles? Varias son las razones, pero la clave reside en una sola. Cada nivel aporta un nivel de conocimiento propio, permitiendo establecer polticas diferenciadas dependiendo de las necesidades, y fundamentalmente de la estrategia que se defina, tanto para cada departamento como para la totalidad. Un ejemplo nos va a servir para ilustrarlo. Retomemos el Servicio Tcnico de Corriente Continua para explotaciones ferroviarias. Para entenderlo ms ampliamente, es necesario describir brevemente el escenario en donde este Servicio Tcnico aplica. La catenaria o lnea area, es decir, el cable de cobre que proporciona la tensin a los trenes, no es un segmento continuo. Cada cierta distancia, dependiendo de las necesidades de diseo y explotacin, existen elementos que interrumpen dicha continuidad, y que sin entrar en ms detalles, permiten aislar cada sector hacindolos independientes entre ellos. Generalmente cada sector est alimentado por una nica subestacin elctrica. El elemento entre sector y sector es una pieza conocida como Seccionador (bsicamente es un interruptor salvando las distancias de construccin entre uno y otro), que permite la interconexin de ambos sectores, creando uno solo virtual. Una vez establecido el escenario analicemos una incidencia, como repercute , y el tratamiento a dar en cada uno de los niveles expuestos. Para ello definamos el indicador Tiempo de Reposicin , como el tiempo transcurrido entre la notificacin de la Incidencia y su resolucin para cada uno de los niveles definidos, de manera que, en el nivel de Gestin de Servicios la finalizacin lo determina el restablecimiento del servicio, en el nivel de Incidencia la terminacin de todas la intervenciones asociadas a la Incidencia, y en el nivel de Mantenimiento la resolucin de cada Parte de Trabajo generado. Nos comunican la incidencia falta de tensin en uno de los sectores y marcamos este comienzo como T0 o Tiempo Inicial. Para cada nivel, este tiempo de comienzo es el mismo. Cada vez que tenemos una falta de tensin, al no poder identificar donde est el problema, generamos para el personal de campo dos Partes de Trabajo, uno para el departamento responsable de las subestaciones (Energa) y otro para el departamento responsable de la catenaria y elementos relacionados con ella (Lnea Area). Adems con esta poltica, favorecemos que en caso de que el problema no sea de la catenaria, el departamento de Lnea Area acte en el seccionador para interconectar los dos sectores, proporcionando tensin al sector donde tenemos la ausencia de alimentacin. Obtenemos cuatro T 0s iguales: T0 Servicio (Gestin de Servicios) T0 Incidencia (Gestin de Incidencias) T0 OT Subestaciones (Gestin de Mantenimiento) 64

T0 OT Lnea Area (Gestin de Mantenimiento) Transcurrido un tiempo T 1, se identifica que el problema est en la subestacin y por lo tanto, el departamento de Lnea Area acta sobre el seccionador para alimentar al tramo sin tensin. Los Tiempos de Reposicin son: Para el nivel de Servicios, T1 Para el nivel de Incidencias, la Incidencia todava no ha terminado. Para el nivel de Mantenimiento, en Lnea Area T 1, en Subestaciones est pendiente. Transcurrido un segundo Tiempo T 2, el departamento de Subestaciones soluciona la avera dando por finalizada su intervencin. Los Tiempos de Reposicin son: Para el nivel de Servicios, T1 Para el nivel de Incidencias, la Incidencia todava no ha terminado. Para el nivel de Mantenimiento, en Lnea Area T 1, en Subestaciones T1+T2 An solucionando la avera, es necesario retomar las condiciones de explotacin iniciales. Eso implica la necesidad de actuar en el seccionador y alimentar el sector afectado desde la subestacin que le corresponde, para lo cual se generan dos nuevos Partes de Trabajo, uno para cada departamento, de manera que una vez que ha intervenido Lnea Area (maniobrando en el seccionador) acte Subestaciones (el sector vuelva a ser alimentado por la subestacin correspondiente). La duracin de cada uno de estos nuevos Partes de Trabajo es: En Lnea Area T3 y en Subestaciones T3+T4 (el tiempo de intervencin del departamento de Lnea Area + el tiempo de intervencin de Subestaciones) Los Tiempos de Reposicin obtenidos para cada nivel son: Para el nivel de Servicios, T1 Para el nivel de Incidencias, T 1+T2+T3+T4 Para el nivel de mantenimiento, en Lnea Area T 1, en Subestaciones T1+T2. El caso analizado ha ilustrado perfectamente las diferencias que existen entre cada uno de los niveles y la gestin diferenciada que es obligatorio realizar en cada uno de ellos. Adems, implcitamente ha aparecido un nuevo concepto, el de Incidencia.

65

Definimos Incidencia como:

AQUEL SUCESO PRODUCIDO EN LOS EQUIPOS, SISTEMAS O INSTALACIONES MANTENIDAS, QUE REPERCUTE EN LA PRESTACION DE UNO O VARIOS SERVICIOS TECNICOS
Una visin global del esquema del principio sera:

METRICAS DE SERVICIOS (SLAs)

INDICADORES INCIDENCIAS (KPIs)

GESTION DE SERVICIOS (ST)

GESTION DE INCIDENCIAS

GESTION DE MANTENIMIENTO

INDICADORES MANTENIMIENTO

PROVEEDORES PROVEEDORES

CONTRATAS CONTRATAS

En el esquema se aprecia, la diferencia entre los diferentes Indicadores que en cada nivel se han de aplicar. Hemos visto que el Tiempo de Reposicin no cumple los mismos requisitos, ni es medible bajo los mismos criterios en cada nivel. Las organizaciones actuales tienden lgicamente por la experiencia acumulada y la cantidad de literatura existente, a focalizar todos los esfuerzos en la Gestin del Mantenimiento. En dicha gestin se considera cada vez ms la interaccin con el cliente, la actividad desarrollada... pero se pone de manifiesto la ausencia de criterio respecto del Servicio ofertado, llegando en muchas circunstancias a buscar sin xito, nuevos Indicadores que permitan con la informacin aportada, establecer polticas que aumenten la eficacia del mantenimiento realizado. Hoy en da, los
6

KPI - Indicadores Clave de la Actividad, Productividad, Rendimiento... (segn autores) SLA - Acuerdos de Nivel de Servicio

66

departamentos de Mantenimiento barajan un conjunto de Indicadores cada vez ms difciles de tratar, motivado por las exigencias de rentabilidad, eficacia, optimizacin... indicadores muchas veces contradictorios, pues aplican a estrategias diferentes en muchos casos opuestas. En el ejemplo del cajero podemos comprobar, que sino se establecen polticas comunes, se hacen converger las actividades, se planifica eficazmente cada departamento con responsabilidad para garantizar un Servicio Tcnico con Calidad, y se cumplen las premisas de diseo, la repercusin en el servicio no solo no mejorar, sino que en contra de todos los esfuerzos, empeorar. La conclusin es obvia, el diseo y construccin de los indicadores de cada nivel no se puede realizar ajena a los dems niveles. Conseguirlo solo es posible con un nico planteamiento. Antes de abordar cualquier actividad de Gestin, es necesario definir claramente la o las estrategias a cumplir.

67

68

10 INCIDENCIAS
En el captulo anterior hemos definido Incidencia, Como aquel suceso producido en los equipos, sistemas o instalaciones mantenidas, que repercute en la prestacin de uno o varios Servicios Tcnicos. El conocimiento de las Incidencias , pero fundamentalmente, cmo dependiendo de su catalogacin afectan a los Servicios Tcnicos, nos permitir una mejor comprensin de algunos aspectos a desarrollar en las fases de diseo y construccin. Las Incidencias se catalogan de tres formas: I. Por la repercusin en el Servicio Tcnico. II. Por el momento de repercusin al Servicio Tcnico. III. Por el modo de afeccin al Servicio Tcnico. 10.1 Por la Repercusin en el Servicio Tcnico Se entiende por repercusin, el nmero de Servicios Tcnicos afectados cuando se produce una o varias Incidencias. Segn esta definicin la catalogacin es la siguiente: 1. Una Incidencia afecta a uno o varios Servicios Tcnicos.

SERVICIO A INCIDENCIA 1 SERVICIO B SERVICIO C

2. Varias Incidencias afectan a un Servicio Tcnico .

INCIDENCIA 1 INCIDENCIA 2 INCIDENCIA 3 SERVICIO A

69

3. Una o varias Incidencias no afectan a ningn Servicio Tcnico.

INCIDENCIA 1

SERVICIO A

10.2 Por el Momento de Repercusin en el Servicio Tcnico Se entiende por momento, el instante en el que uno o varios Servicios Tcnicos se ven afectados cuando se produce una o varias Incidencias. Segn esta definicin la catalogacin es la siguiente:
1. Incidencias de repercusin inmediata en el Servicio Tcnico.

Incidencia 1 Incidencia 2 SERVICIO A SERVICIO B

2. Una o ms Incidencias afectan al Servicio Tcnico cuando es demandado.

Incidencia 1 Incidencia 2

Demora Tiempo

de

SERVICIO A SERVICIO B

70

10.3 Por el Modo de Afeccin al Servicio Tcnico Se entiende por modo, la manera de cmo las Incidencias afectan a uno o varios Servicios Tcnicos. Segn esta definicin la catalogacin es la siguiente:

1. Varias Incidencias afectan a uno o varios Servicios Tcnicos. La resolucin de una de ellas, restaura uno o varios de los Servicios Tcnicos afectados.

INCIDENCIA 1 INCIDENCIA 2 INCIDENCIA 3 SERVICIO A SERVICIO B

2. Varias Incidencias en serie, afectan a uno o varios Servicio Tcnicos. La resolucin de todas, restauran los Servicios Tcnicos afectados.

INCIDENCIA 1 INCIDENCIA 2 INCIDENCIA 3 SERVICIO A SERVICIO B

71

72

11 FUNCIONALIDADES
En el diseo de los Servicios Tcnicos, hemos comenzado por establecer y por este orden, las Generalidades, la Definicin, el Alcance y el Equipamiento. Llegados a este punto, es necesario definir las funcionalidades que forman parte del Servicio Tcnico, funcionalidades que son aportadas por los equipos implicados y en concreto, por el equipo clave. Por qu es necesario detallarlas? Porque como se ver ms adelante, en el diseo y construccin de cualquier Servicio Tcnico, definiremos conceptos que nos permiten conocer el grado de prestacin o percepcin del mismo, y ese grado de conocimiento ser la consecuencia directa del estudio de cada una de las funcionalidades. Cierto es que muchas de las funcionalidades no se implementarn porque no aportan nada y an as, ese detalle de conocimiento es til para controlar el servicio. Otras sin embargo, permitirn definir lo que por ahora llamaremos diferentes niveles de prestacin. Retomemos el Servicio Tcnico de Mquinas Expendedoras de ejemplo para ilustrarlo. Entre las muchas funcionalidades que pueden aportar las mquinas expendedoras, una es el cambio. Qu sucede cuando una mquina no puede proporcionar cambio porque ste se ha agotado? La mquina no deja de servir productos, pero obliga al consumidor a que el importe introducido sea exacto si desea obtener el producto, lo que significa que, prestando servicio la mquina, este servicio se ve disminuido en un porcentaje por la falta de cambio, pues una de las premisas originales del diseo del equipamiento es proporcionarlo. Esta funcionalidad que hemos incorporado al Servicio Tcnico, cuando se produce en un momento determinado, el usuario percibe que no se le est proveyendo todo el servicio, ya que sino dispone de la cantidad exacta, no puede obtener el producto deseado. Otro ejemplo dentro del mismo Servicio Tcnico son los diferentes artculos a adquirir. La falta de un determinado producto produce el mismo efecto. Nuestro equipo presta servicio, pero el consumidor debe optar por quedarse sin ese producto o escoger otro distinto. De la misma manera que con el cambio, el servicio prestado/percibido ha disminuido. La oferta no es completa. Segn hemos visto, la mquina expendedora puede no disponer de cambio, que un determinado producto est agotado, o ambos a la vez, es decir, el equipo puede ir acumulando sucesivas prdidas de funcionalidad, que provocan que el servicio no se preste en su totalidad. Estas prdidas conocidas y controladas nos permiten identificar degradaciones en el Servicio Tcnico, y que consecuentemente, debemos identificarlas y evaluarlas en el diseo, e implementarlas en la construccin. El Servicio Tcnico que construyamos puede tener asociado circunstancias como las expuestas que son necesarias identificar. Cmo establecer las funcionalidades depender del conocimiento del equipamiento que intervenga. Lo lgico es, que las funcionalidades sean conocidas porque las proporcione el fabricante de los equipos, o porque si se construyeron partiendo de unas necesidades previas establecidas, stas correspondan con las funcionalidades del equipo; incluso, puede aportar ms funcionalidades que las necesarias y no deban considerarse. Tambin encontrarnos 73

que el equipo haya sufrido diversas trasformaciones en el tiempo, no estando claras todas las prestaciones. Que equipos similares no aporten las mismas funcionalidades... Sea el caso en el que estemos, es conveniente detallar las funcionalidades de cada tipo de equipo y modelo existente. Del anlisis, muchas sern comunes y otras no, pero en cada caso realizaremos la relacin de las mismas. Sobre el ejemplo visto, podramos tener equipos que expendieran Bebidas, Bebidas y Alimentos, Alimentos, Bebidas Calientes... que den cambio o no, e incluso, admitan pago con tarjeta de dbito, dbito y crdito... Obviamente, la funcionalidad que no corresponda a un equipo en concreto no ser de aplicacin en el mismo. Detallar cada una de las funcionalidades ser tarea de quin disee el Servicio Tcnico, pero como pueden darse muchas circunstancias que impidan obtener dicha informacin, lo mejor es usar un mtodo que permita conocerlas. Una metodologa que va a ayudar objetivamente a determinar las funcionalidades, ya que parte del proceso de la misma es definirlas, es la metodologa RCM (Mantenimiento Basado en Fiabilidad) mencionada en la primera parte. Esta metodologa de aplicacin universal en el mbito del mantenimiento se define como:

Proceso que determina el mantenimiento requerido en cada equipo, sistema o instalacin, dentro de su contexto operacional, asegurando que siga realizando las funciones para las que fue diseado y construido
11.1 Unos apuntes sobre el Mantenimiento Basado en la Fiabilidad Aunque no es objeto del presente libro profundizar en la metodologa RCM, pues el volumen de ttulos capaces de proporcionar el conocimiento necesario es muy numeroso, comentaremos para todos aquellos lectores que sea su primera toma de contacto, en que consiste bsicamente. Como premisa inicial podemos decir que, RCM se centra en la relacin entre la organizacin y los elementos fsicos que la componen. Los objetivos que se persiguen con esta metodologa son, a modo de glosario: I. Conseguir los niveles de calidad del servicio de mantenimiento exigidos. II. Conseguir un mejor aprovechamiento de los recursos materiales y humanos. III. Reducir los costes de mantenimiento. IV. Optimizar la eficiencia operacional de los equipos y su fiabilidad. V. Aumentar su disponibilidad

74

Para conseguir dichos objetivos, cada equipo, sistema, instalacin, es sometida a siete preguntas bsicas sntesis del resultado del proceso de revisin que efecta RCM para determinar el mantenimiento requerido, con el fin de que contine desempeando las funciones deseadas dentro de su contexto operacional. Las preguntas que conforman dicho cuestionario son: 1. Cules son sus funciones? Los equipos tienen un propsito determinado. Esto significa que tiene una o varias funciones que cumplir, y el fallo, o ausencia de alguna de ellas, impacta en la organizacin, la calidad del producto, el servicio ofertado... 2. De qu forma puede fallar? Todo equipo puede fallar en un momento dado, pero Cundo sabemos qu falla? Se define fallo a la incapacidad para cumplir alguna de sus funciones. 3. Cul es la causa de fallo? Lo ms importante es saber la causa que provoca la prdida funcional, no los sntomas asociados. Generalmente se confunden unos con otros. A modo de ejemplo muy simple, el coche no arranca (sntoma) porque no tiene gasolina (causa). 4. Qu sucede cuando falla? No hablamos de los sntomas, sino de las consecuencias de cada prdida funcional. 5. Qu importancia tiene el fallo? Priorizamos en orden de importancia a las consecuencias, es decir, a la repercusin provocada (operacionales, seguridad, ambientales...). 6. Qu puede hacerse para prevenir el fallo? Definir la tarea de mantenimiento que mejor se adapte al fallo. Al referirnos a tareas nos estamos refiriendo, a que pudiendo ser de un tipo de mantenimiento concreto como por ejemplo preventivo, pueden existir diferencias. El mantenimiento peridico segn condicin, reacondicionamiento cclico o sustituciones cclicas, se considera mantenimiento preventivo. 7. Qu hacer sino es posible prevenir el fallo? Sino es posible prevenir el fallo es muy probable que exista un error de diseo, por lo que en principio lo ms oportuno, sera replantearse el diseo (rediseo). Lo realmente difcil, es establecer un sinptico que contenga estas preguntas para determinar el tipo de mantenimiento. Decidir si se aplican preventivos, los correctivos convenientes a realizar, o predictivos si los hubiere. Para la metodologa MBF, las consecuencias de los fallos son cuatro: 1. Consecuencia de los fallos no evidentes. Los fallos que no son evidentes no impactan directamente, exponiendo al equipo a otros fallos de consecuencias drsticas. Se les otorga por ello una prioridad muy alta. 75

2. Consecuencias en la seguridad o el medio ambiente. Un fallo tiene consecuencias en la seguridad, si puede herir o matar a alguien, o medioambientales, si agrede a la naturaleza o incumple la normativa al respecto existente. Destacar que para este mtodo, prima esta consecuencia sobre las que impactan en el funcionamiento. 3. Consecuencias operacionales. Cuando un fallo afecta en lneas generales a la produccin. 4. Consecuencias que no son operacionales . Estos fallo lo nico que hay que considerar de ellos, es el gasto de reparacin asociado. El anlisis del modo de fallo y sus consecuencias es la clave de la metodologa, ya que del mismo deriva la tarea a adoptar. Dos son las tareas que distingue: 1. Preventivas. Dentro de este grupo, las tareas a realizar pueden ser: 1.1. Cclicas segn condicin. Son consecuencia de que la mayora de los fallos advierten de cuando se van a producir, permitiendo programar en la mayora de las situaciones intervenciones para evitar la consecuencia del fallo. Se les conoce como fallos potenciales. 1.2. Reacondicionamiento cclico. Se restituyen las condiciones originales transcurrido un periodo de tiempo (varios pueden ser los factores que determinen el intervalo de tiempo). 1.3. Sustitucin cclica. Transcurrido un periodo de tiempo (varios pueden ser los factores que determinen el intervalo), se procede a sustituir un elemento determinado. 2. A falta de. La metodologa MBF se plantea, no solo si las tareas de preventivo son factibles, sino adems tiene sentido realizarlas. Como resultado, sino nos encontramos en ninguna de las tareas del primer punto, el anlisis realizado determinar la conveniencia de realizar cualquier tarea, tanto si es rentable o beneficiosa, como si afecta a la seguridad. Si la respuesta siguiera siendo negativa, lo ms conveniente es plantearse el rediseo. La nica posibilidad para aplicar las tareas preventivas o a falta de que surjan del cuestionario, es conociendo los posibles indicadores que determinen los periodos de funcionamiento. Estos indicadores pueden ser del tipo: Nmero de viajes (Ascensores de un edificio).

76

 Horas de funcionamiento. (Pantallas de informacin de un aeropuerto). Nmero de operaciones de venta. (Mquinas expendedoras de bebidas). Nmeros de pasos. (Torniquetes de acceso a locales). Distancia recorrida. (Vehculos, autobuses, trenes...) Lecturas realizadas. (Cajeros bancarios, tarjeteros) Otros... Y no todo son ndices con un cierto sentido de temporalidad, pues detrs de este primer indicador, para detonar una tarea de preventivo, podemos encontrar otras mediciones que garanticen si, an transcurrido el periodo establecido para por ejemplo realizar una sustitucin, existen mrgenes de seguridad para continuar con su uso hasta la siguiente revisin. Por ejemplo: Desgastes. Viscosidades. Temperaturas. Niveles de llenado. Otros... Aunque es posible hablar largo y tendido de la metodologa MBF, en unas breves lneas hemos pretendido condensar los principales argumentos y principios en los que se basa el Mantenimiento Basado en la Fiabilidad, como apoyo y comprensin de la razn del mantenimiento, principalmente en nuestros das. Adems, nos va a ayudar a identificar las funcionalidades del equipamiento. Ser competencia de los diseadores identificar, cules de estas funcionalidades son propias del Servicio Tcnico.

77

78

12 INCIDENCIAS CLAVE QUE DEGRADAN EL SERVICIO TECNICO

Se definen como Incidencias Clave que degradan el Servicio Tcnico:

Aquellas disfunciones producidas en los equipos o sistemas, que sin llegar a anular la oferta del servicio, se presta con las funcionalidades definidas para su explotacin mermadas, incumpliendo prerrogativas o requisitos mnimos de prestacin, en aquellos casos en los que pueda establecerse un margen de operatividad posible
A estas Incidencias Clave las llamaremos de ahora en adelante, Incidencias Operativas. Esta semntica obedece a que una o varias Incidencias, ya sean tcnicas o no, en uno o varios equipos, pueden provocar una incidencia Operativa. La Incidencia Operativa es por tanto una prdida de Funcionalidad, tal y como vimos en el captulo anterior. Por ejemplo, en el Servicio Tcnico de Mquinas Expendedoras, hemos establecido la operativa de proporcionar cambio como una funcionalidad del equipo, y por lo tanto del Servicio Tcnico. Pero que no pueda dar cambio puede originarse como consecuencia, de que en cualquiera de los depsitos para cada uno de los diferentes tipos de monedas no haya existencias. Supongamos las Incidencias que se pueden dar: Sin monedas de 5 cts. Sin monedas de 10 cts. Sin monedas de 20 cts.

Sin monedas de 50 cts. Sin monedas de 1 euro

Es evidente que no disponer de monedas de 1 euro no significa que no pueda dar cambio, pero para entender mejor el ejemplo, cuando no existan monedas en alguno de los contenedores, no es posible dar cambio. Tendramos por tanto 5 posibles Incidencias (y darse simultneamente), pero una sola Incidencia Operativa, Sin Cambio. Seguramente al analizar la mquina, independientemente de la metodologa usada, hubiramos conseguido las funcionalidades detalladas de cada una de la Incidencias Tcnicas del ejemplo, obteniendo una nica Incidencia Operativa. Lgicamente, no se traducen directamente las funcionalidades a Incidencias Operativas y como dijimos, muchas funcionalidades no sern consideradas para el Servicio Tcnico. Las funcionalidades deben estar ligadas directamente con las actividades y principalmente con el mantenimiento, de manera que, algunas veces ms que de 79

funcionalidades, estaremos hablando de funciones en el ms estricto sentido de la palabra. Una de las principales funcionalidades o funciones que debe cumplir todo equipo, es proteger al usuario y/o mantenedor de riesgos elctricos. Sin embargo, no es una funcionalidad a considerar para ser tratada como Incidencia Operativa, sino que cuando exista riesgo para la seguridad, se generar una Incidencia Tcnica parndose por completo la mquina. En una Escalera Mecnica la principal funcionalidad es: Transportar personas entre dos niveles de distinta altura, tanto en sentido ascendente como descendente, a una velocidad nominal determinada. Que la velocidad no sea la apropiada (ms despacio) podra ser considerado una Incidencia Operativa mientras siga transportando personas, pero son evidentes dos cosas: 1. La Escalera Mecnica no est preparada para velocidades distintas a la definida. Si va ms despacio se deber a un problema que irremediablemente terminar por dejarla parada. Consecuencia, anulacin del servicio completa. 2. Durante el tiempo que la Escalera Mecnica va ms despacio, es muy posible que no exista forma de conocer dicho suceso y por lo tanto, no poder determinar que est en servicio con una Incidencia Operativa activa. El cliente puede percibir que va ms despacio, pero a efectos del Servicio Tcnico, la Escalera funciona o no funciona. Muchos de estos criterios debern establecerse en la fase de Diseo, siendo conscientes de la dificultad valorativa que tiene cuantificar determinadas situaciones de cara al Servicio Tcnico, pero la razn obvia de por qu definir las Incidencias Operativas es principalmente, para cuantificar la prdida de servicio asociada. En el captulo de Indicadores se analizar cmo cuantificar las Incidencias Operativas, la variacin dependiendo de las que estn activas en un momento determinado y las reglas de clculo.

80

13 DEFINICION DE ESTADOS (SITUACION OPERATIVA)

Generalmente un estado es, una situacin concreta en la que se encuentra un equipo. La lavadora o el lavavajillas de nuestros hogares, cuando pulsamos el botn de inicio, comienza a funcionar ejecutando el programa establecido. Hasta ese momento estaba parado o desconectado, y lo mismo sucede con la mayora del equipamiento y las instalaciones. Muchas veces puede suceder que funcione pero no al completo, por tener averiada alguna de sus funciones, como podra pasarnos en nuestro coche, que el motor no tuviera ninguna avera, pero el aire acondicionado no acte, haciendo desesperante nuestro viaje, con un sol de justicia y temperatura de 40C. El coche funciona, pero en cierta medida mermado en sus capacidades. Para los Servicios Tcnicos, los Estados se definen como:

Aquellos modos o situaciones en los que un equipo puede estar, tanto cuando funciona como cuando no funciona, y que permiten complementar la informacin del Servicio Tcnico
En otras palabras,

El Estado, es la Situacin Operativa del equipo en un instante concreto

El Estado como tal se aplica en principio al equipo clave de la prestacin del Servicio Tcnico. No obstante por cuestiones de control, las mismas Situaciones Operativas que se definan se usarn tambin para registrar los Estados de los equipos relacionados, tanto los implicados como los indirectos, para conocer el impacto (afeccin) al equipo clave y por consiguiente al Servicio Tcnico. Inicialmente todo equipo tiene dos posibles Estados: En Servicio (Funcionando) Parado Dentro del Estado En Servicio, un equipo puede estar a plena capacidad (100%), o estar funcionando mermado, o lo que es lo mismo, sin alguna de sus funcionalidades. En estos casos se definen todos los posible SubEstados que causen degradacin, siempre y cuando por las caractersticas del equipo y Servicio Tcnico los hubiere. Estos SubEstados, son todas aquellas Incidencias Clave qu e Degradan el Servicio y que del anlisis se hayan determinado, pasando dichas Incidencias a considerarlas SubEstados posibles del equipo. A estos Subestados a efectos informativos se les considera tambin Estados, ya que cada vez que un equipo est en cualquiera de los posibles SubEstados de Degradacin, siempre se sobreentiende que tambin est En Servicio. 81

Dentro del Estado Parado, en principio dos pueden ser las causas: Parada por Incidencia Tcnica del Servicio Parada Manual / Fuera de Servicio Permiten diferenciar, cuando un equipo est parado por un problema tcnico de cualquier equipo implicado en el Servicio Tcnico, de cuando un equipo est parado manualmente por intervencin humana. Pero podramos precisar cada parada en otras ms concretas y usando los mismos Estados. Parada por Avera. Las paradas causadas por una incidencia tcnica propia del equipo. Parada por Incidencia Tcnica del Servicio. Cuando la causa de la parada no est en el equipo final, sino es una incidencia de algn equipo relacionado. Parada Manual. Paradas ajenas a la actividad de mantenimiento. Parada por Mantenimiento. El equipo no est averiado, pero est intervenido por mantenimiento. ... y en los casos donde aplique (Supervisin remota y Telecontrol) existir Parada sin Telemando, que aplicara a todos los equipos que estando en Parada Manual, no es posible ponerlos en funcionamiento por falta de Telemando, siendo la nica posibilidad de activarlos en local. El Servicio Prestado/Percibido ser el mismo en cualquiera de los dos Estados. Adicionalmente, en todos los Servicios Tcnicos con equipos que estn monitorizados remotamente, debe existir un Estado Desconocido, consecuencia de cuando en un equipo por la circunstancia que sea, no es posible determinar si est o no en servicio. Este Estado ser el primero a analizar en el Diagrama de Estados correspondiente. El Diagrama de Estados es necesario para conocer la evolucin de la Situacin Operativa del equipamiento clave. Dicho diagrama es un proceso de ciclo continuo para determinar el Estado a aplicar en cada momento, pero entendiendo que cuando se produce una avera, aunque se repercuta y compute en dichos equipos clave, la avera puede producirse en cualquiera de los equipos implicados, y de igual manera, reflejaremos las Incidencias Operativas como SubEstados dentro del Estado En Servicio. Significa que todos los Estados aplican a todos los equipos? La respuesta es obvia, si, y si en un Servicio Tcnico tenemos equipos, tanto monitorizados como no, el Estado Desconocido no aplicar a los no monitorizados. Es importante tener en cuenta esta circunstancia, pues evita generar Diagramas de Estados especficos por cada equipo. De la misma manera, si los diferentes tipos de equipos clave disponen de distintas funcionalidades, tendrn diferentes Incidencias Operativas.

82

Como ejemplo, el Diagrama del Servicio Tcnico de Transporte Vertical (Escaleras Mecnicas y Ascensores) es:

Equipo Clave

Se ve en remoto?

NO Desconocido

SI Parada? SI Parada por Incidencia SI Tcnica del Servicio NO Parada Manual SI Avera? NO
Equipo Telemandado?

NO

EN SERVICIO

SI
Funciona Telemando?

NO

Parada sin Telemando

Cmo se controla el cambio de Estado en un equipo? Por medio de la Matriz de Cambio de Estados en la cual se reflejarn, tanto los Estados como las Incidencias Operativas. Como ejemplo de Matriz, mantengamos el Servicio Tcnico de Transporte Vertical. En vertical tenemos el Estado Inicial, en horizontal el nuevo Estado detectado y en las celdas del interior de la Matriz, el Estado que se debe considerar. Esta circunstancia se debe a la necesidad de priorizar qu Estado debe primar sobre otro. En el ejemplo se ve que si el equipo est con una Parada por Incidencia Tcnica en el Servicio y se detecta una Parada sin Telemando, el equipo debe permanecer en Parada por Incidencia Tcnica en el Servicio , dado que refleja que existe una o varias averas en el equipamiento del Servicio Tcnico y 83

que aunque se solucionase el problema del telemando, el equipo no podra ser puesto en funcionamiento. Cada Servicio tendr tanto su Diagrama de Estados propio, como su Matriz de Cambio de Estados. Matriz de Cambio de Estados:
NUEVO ESTADO DETECTADO Parada Incidencia en el Parada sin Parada Manual Servicio Telemando Parada Incidencia en el Parada sin Parada Manual Servicio Telemando Parada Incidencia en el Parada sin Servicio Telemando Parada Parada Incidencia en el Incidencia en el Servicio Servicio Parada Incidencia en el Servicio Parada Incidencia en el Parada sin Parada Manual Servicio Telemando

Desconocido

En Servicio

Desconocido
ESTADO INICIAL

En Servicio

Parada Manual Parada Incidencia en el Servicio Parada sin Telemando

Parada Manual Parada Incidencia en el Servicio Parada sin Telemando

En Servicio

En Servicio

En Servicio

En Servicio

Desconocido

Comentar que el cuadro interseccin entre Parada sin Telemando y Parada Manual no aplica, ya que la Parada sin Telemando, es la consecuencia de tener al equipo en Parada Manual. Un Equipo Clave en Parada por Incidencia Tcnica en el Servicio, puede ser por causas propias o por causas del equipamiento implicado. Para determinar como impacta (afecta) el Equipamiento Implicado en el Equipamiento Clave, se determinar por medio de la Matriz de Equipamiento Relacionado y su Relacin de Impacto, pudiendo existir tantas Matrices como afecciones haya. En el Servicio Tcnico de Transporte Vertical tenemos: Impacto: Afecta Equipo Parado
NUEVO ESTADO EQUIPO RELACIONADO Parada Incidencia en el Servicio Parada Incidencia en el Servicio Parada Incidencia en el Servicio Parada Incidencia en el Servicio Parada Manual Parada Incidencia en el Servicio Parada sin Telemando Parada sin Telemando Parada sin Telemando Parada sin Telemando

Parada Manual

ESTADO INICIAL

Desconocido Parada Manual Parada sin Telemando En Servicio

Parada Manual

84

En el Servicio Tcnico de Mquinas Expendedoras, si fuera posible pagar con tarjeta de dbito de manera que, parte del equipamiento implicado anulara solo dicha funcionalidad, tendramos dos Impactos: Afecta Equipo Parado Afecta Pago con Tarjeta de Dbito Supongamos que no tenemos control sobre todo el equipamiento implicado, y construimos un check en un Servidor Centralizado en comunicacin con nuestras mquinas para detectar, cuando no existe la posibilidad de pagar con tarjeta de dbito. Pues imaginemos que, an estando las mquinas, las comunicaciones y el Servidor operativos, se detecta la anulacin de dicha funcionalidad. Con la Matriz slo no valdra, ya que el Estado del Servidor no cambia, sigue En Servicio. Para cuando existan estas circunstancias, a la Matriz es necesario aadirle el control por medio de la deteccin de la Incidencia Operativa. En nuestro caso, cuando el check nos alerte de la prdida de la funcionalidad. La necesidad de definirlo y construirlo as viene condicionada porque, aunque las Incidencias Operativas se consideren a nivel informativo un SubEstado, realmente el Estado del Equipamiento es siempre el mismo, En Servicio. En el equipamiento implicado y que controlamos, las afecciones a la funcionalidad por sus nuevos Estados detectados (Paradas...) se establecern como en el resto de las Matrices donde no haya Funcionalidades. Impacto: Afecta Pago con Tarjeta de Dbito
ESTADO NUEVO EQUIPO RELACIONADO En Servicio/ Incidencia Operativa

Parada Manual
ESTADO INICIAL

Parada Incidencia en el Servicio

Parada sin Telemando

Desconocido

Desconocido/ Desconocido/ Desconocido/ Desconocido/ Incidencia Operativa Incidencia Operativa Incidencia Operativa Incidencia Operativa

En Servicio

En Servicio/ En Servicio/ En Servicio/ En Servicio/ Incidencia Operativa Incidencia Operativa Incidencia Operativa Incidencia Operativa

Los Estados finalmente establecidos son:

En Servicio Desconocido Parada por Incidencia Tcnica en el Servicio Parada Manual

85

Parada sin Telemando

Y dentro del Estado En Servicio, se establecern tantos SubEstados como Incidencias Operativas se definan. Pero, Los Estados y SubEstados definidos son suficientes? La respuesta depender de cada Servicio Tcnico obviamente. Con los Estados definidos podremos controlar prcticamente todos los que se definan. De hecho, el Estado Parada sin Telemando puede ser un Estado que nunca necesitemos. Nos puede interesar de cara a proporcionar una informacin ms detallada definir nuevos Estados, incluso, existir Servicios Tcnicos que tengan definidos Estados propios. Para mejor comprensin realicemos un supuesto de cada uno de ellos: 13.1 Nuevos Estados para mejorar la informacin Hemos definido la Parada por Incidencia Tcnica en el Servicio como la prdida de funcionalidad completa de servicio, ya sea por el propio equipo clave o por el equipamiento implicado. Para algunos Servicios Tcnicos puede interesar diferenciar cuando es por causa del equipamiento implicado o por el equipo clave. Para ello basta definir el Estado Parado por Avera y con aplicacin exclusivamente al equipo clave. El Estado Parada por Incidencia Tcnica en el Servicio al equipo clave, es como consecuencia de una Incidencia en el equipamiento implicado. 13.2 Nuevos Estados por necesidad del Servicio Tcnico Cuando comentamos el Servicio Tcnico de Corriente Continua para alimentar una lnea ferroviaria, dijimos que el elemento clave son los Disyuntores (Disyuntores de Feeder). Algunas explotaciones ferroviarias como los suburbanos de las ciudades, las subestaciones elctricas se construyen bajo el siguiente diseo:

86

Lnea B Sector 3 Subestacin Elctrica Disyuntor de Reserva

Lnea A Sector 1

Disyuntor B

Disyuntor A

Suministradora Elctrica
El Disyuntor de Reserva puede ser usado para alimentar cualquiera de los dos sectores de catenaria de cualquiera de las lneas. El Estado de este Disyuntor en principio es Parada Manual, pero si lo considerramos as, de cara al Servicio Tcnico tendramos que la situacin lgica del equipamiento es que est funcionando, por decirlo en otras palabras, el servicio prestado por el equipo es del 100%. Una Parada Manual (mantenimiento programado, por seguridad...) inicialmente significa que el servicio prestado es del 0%. El Disyuntor de Reserva, tanto cuando est haciendo su funcin de reserva, como cuando est en asistencia, el servicio prestado es del 100%. Si cuando est de reserva su Estado es Parada Manual, de cara al Servicio Tcnico estamos dando una valoracin que no corresponde con la realidad. Para situaciones como sta, lo ms lgico es definir un nuevo Estado que le podramos llamar En Reserva, pero , qu sucede cuando entra a sustituir a alguno de los principales? Pues que ya no est En Reserva, ha pasado a estar En Servicio y en este Estado, no reflejamos que ya no disponemos del Disyuntor de Reserva si fuera necesario usarlo para sustituir al otro Disyuntor principal. Adems del Estado En Servicio, para estos Disyuntores debemos asociar otro Estado ms, No Disponible. Realmente y dependie ndo de como se disee el Servicio Tcnico, el Estado En Reserva no es tan significativo, ya que se puede definir que el Disyuntor de Reserva cuando est en Parada Manual no signifique que el Servicio est degradado, pero con el diseo de la subestacin mostrado, en el que prestamos servicio con dos Disyuntores principales y uno de reserva, es cierto que la tensin en la Lnea Area se mantiene cuando acta el Disyuntor de reserva (el cliente percibe que el Servicio 87

est al 100%) pero de cara al mantenedor el Servicio Tcnico no se est prestando al 100%. Con los ejemplos expuestos y los nuevos Estados definidos, dejamos al lector como ejercicio reformar las Matrices incluyndolos. En este captulo al igual que en el anterior, se vuelve a plantear la cuantificacin como sistema de valoracin del Servicio Tcnico, cuantificacin que viene determinada por los Estados y las Incidencias Operativas. La valoracin que se establezca al Estado, depender del servicio que preste. Inicialmente los valores a aplicar son: En Servicio 100% Parada (Incluye a todas) 0% Pero tenemos otros Estados que no es tan clara la valoracin, como es el caso del Estado Desconocido. Veremos ms adelante que mtodo usar para asociarle un valor determinado. Ms difcil ser valorar la prdida de servicio por una incidencia Operativa, pues no siempre son tan evidentes que factores de ponderacin pueden existir para establecer dichas prdidas.

88

14 RESPONSABILIDADES
Es evidente que establecer la responsabilidad del Servicio Tcnico, si se pretende que sea la agrupacin de las actividades no parece tarea fcil, ya que la concurrencia de actores puede ser elevada y cada uno tendr su cuota de responsabilidad, segn sea su participacin. Al construir un Servicio Tcnico, como cualquier producto realizado, parece lo ms lgico tener un nico interlocutor como cabeza visible, al cual demandar y exigir el cumplimiento de las necesidades por las cuales el Servicio Tcnico fue construido; incluso, si fue un ejercicio para dar satisfaccin a una auto demanda. Cuando hablamos de Responsabilidades, dos son los alcances que se pretenden establecer partiendo de un mismo concepto. El primero lgicamente, agrupa al conjunto de Departamentos que participan en la prestacin del Servicio . Por insignificante, baja repercusin, dedicacin, trascendental... que pueda ser la actividad, todo aqul que incida en un Servicio Tcnico debe conocer su responsabilidad, como punto de partida para establecer las mejoras que puedan ser oportunas acometer. El segundo y crucial, por el alcance y repercusin directa que significa es, la designacin del Departamento que se responsabiliza de la oferta del Servicio, convirtindose en el garante de la prestacin, cuya funcin principal es asegurar que el Servicio se preste en las mejores condiciones y ante cualquier Incidencia que anule o degrade el Servicio, ser el Responsable tanto de restablecerlo, como de hacer el seguimiento de la incidencia para su pronta resolucin. Por qu establecer esta dualidad? Sencillamente porque el Servicio Tcnico puede ser cuestin de varios resultando que, excepto el que tiene la responsabilidad del equipo clave, el resto se mantiene ajeno a la trascendencia de los problemas generados por el equipamiento e instalaciones de su competencia. Incluso es posible encontrarnos, equipamiento con responsabilidades compartidas, como pueden ser las mquinas expendedoras de comida y bebida. Sin mucho esfuerzo, es fcil encontrar cuatro agentes que intervienen en dicho servicio sobre el mismo equipo: los que la mantienen fsicamente, los que reponen comida, los que reponen bebida y los que reponen el cambio de monedas. Asignando las RESPONSABILIDADES, se establecen los mecanismos necesarios para facilitar la restitucin y resolucin del Servicio Tcnico en el menor tiempo posible, y con el menor impacto.

89

90

15 INDICADORES DEL SERVICIO TCNICO

Llegados a este punto de la lectura, es el momento de plantear qu vamos a medir de los Servicios Tcnicos, aunque todava no hayamos planteado como cuantificarlo. Desde el comienzo, continuamente hemos referenciado un concepto que le hemos denominado Estado del Servicio. Cul es su significado? Supongamos que es viernes y estando cerca de terminar la jornada laboral, queremos conocer si existe atasco en una determinada carretera, pues tenemos la intencin de salir de viaje. Cogemos el telfono y llamamos a trfico, el cul nos responde que para el destino comunicado, hay retenciones de 23 kilmetros. Ante esta situacin decidimos posponer nuestra salida hasta que el nivel de colapso disminuya. El atasco puede deberse a un accidente, la propia afluencia de vehculos, un corte en la carretera por obras... e incluso pueden ser coincidentes dos de las circunstancias (Incidencias). A nosotros, como potenciales usuarios de esa carretera no nos importa cules pueden ser las causas del atasco, solo queremos conocer:

EL ESTADO DE LA CARRETERA
y decir El Estado de la carretera, es lo mismo que decir:

EL ESTADO DEL SERVICIO PRESTADO POR LA CARRETERA

o lo que es lo mismo:

LA DISPONIBILIDAD PUNTUAL DEL SERVICIO PRESTADO POR LA CARRETERA

Conocer las causas puede ser informacin complementaria til, dependiendo de a quin se le proporcione. La informacin complementaria a suministrar con el Servicio Tcnico, seran los Estados en los equipos clave. Finalmente, las causas seran el tipo de Incidencias que existen en los equipos. Definamos el Estado del Servicio como:

EL NIVEL DE SERVICIO QUE SE EST PRESTANDO Y/O PERCIBIENDO, CONSIDERANDO TODAS AQUELLAS CIRCUNSTANCIAS QUE ANULEN O DEGRADEN EL SERVICIO, INCLUSO, AQUELLAS QUE NO PERMITEN DETERMINAR SI SE PRESTA O NO DICHO SERVICIO
Otra acepcin, mucho ms coloquial es: 91

INDICADOR EN TIEMPO REAL, QUE MUESTRA LA OFERTA DE SERVICIO EN UN MOMENTO CONCRETO

Posiblemente el principal indicador de todo Servicio Tcnico es, su Estado del Servicio. De hecho como cliente, la mayora de las veces slo interesa conocer ese dato o, como proveedores de servicio, slo nos interese proporcionarlo. Pero, el prestado o el percibido? Como hemos ido viendo en sucesivos captulos la diferencia es notoria. No es lo mismo lo que se presta que lo que se percibe. Segn sea el Estado del Servicio, podemos tener la siguiente catalogacin: 1. Que lo que se presta sea igual que lo que se percibe , existiendo tanto prestacin como percepcin. A efectos de clculo solo existir uno. 2. Que lo que se presta no sea igual que lo que se percibe , existiendo tanto prestacin como percepcin. 3. Que solo exista prestacin. 4. Que solo exista percepcin. Analicemos ejemplos de cada una de las diferentes clases: 1. Servicio de Transporte Vertical. En los aeropuertos existen multitud de Escaleras y Pasillos Mecnicos para facilitar el desplazamiento de los viajeros. Cuando la Escalera o el Pasillo est en funcionamiento, prestamos el 100% del servicio, y eso mismo es lo que percibe el usuario. Si por contra no funciona, el servicio prestado es del 0% y el usuario lo percibe igual. Para este tipo de Servicios Tcnicos hablaremos del Indicador Estado del Servicio solamente, ya que con la misma mtrica indicamos tanto la prestacin como la percepcin. 2. Servicio de Corriente Continua. Los ferrocarriles circulan gracias al suministro de corriente elctrica. Esta corriente la toman los trenes desde un elemento conocido como catenaria7 o por medio de un tercer carril (es el caso de muchos de los metros de Estados Unidos). Sea cual sea el mtodo empleado no es un elemento continuo. Est, por decirlo de alguna manera, fragmentado en sectores independientes y conectados a subestaciones elctricas diferentes. El nmero de trenes que a la vez pueden circular en un determinado sector, depender de la potencia que suministre la subestacin elctrica. Pudiera suceder que el usuario, percibiendo que hay tensin y con la potencia necesaria para el volumen de trenes que circulan en ese momento (Estado del Servicio Percibido del 100%), el Servicio Tcnico est mermado pues las condiciones de origen sobre las cuales lo prestamos no se estn produciendo, ya que tenemos
7

cable o viga que se ve sustentado por postes en las lneas ferroviarias, incluidas las urbanas y suburbanas -metros, tranvas...-

92

uno de los elementos de suministro de tensin de la subestacin (Disyuntor) averiado y estamos dando servicio con el elemento de reserva (Estado del Servicio Prestado < 100%). Para este tipo de Servicios Tcnicos, lo lgico es implementar ambos Indicadores, Estado del Servicio Prestado y Estado del Servicio Percibido. 3. Servicio de Bombeo (Pozos de Bombeo Pluvial) . En una urbanizacin se han construido varios pozos de bombeo pluvial para evacuacin del aporte de agua. Cada uno de ellos contiene 3 bombas, dos que funcionan alternativamente y una tercera de emergencia. Mientras no haya una inundacin, la percepcin es que el servicio est al 100% siempre. Cuando se inunda, la percepcin es que el servicio est al 0%. Entre estos dos valores, la prestacin puede variar dependiendo de circunstancias como puede ser, el nivel de agua en el pozo o el estado operativo de las bombas. Construir el Estado del Servicio Percibido no tiene ningn sentido, pues solo tendramos esas dos posibilidades, 0% 100%. En este tipo de Servicios Tcnicos, el Indicador que se debe implementar es el del Estado del Servicio Prestado. Implementar Servicios Tcnicos con estas caractersticas tiene como valor aadido, trasmitir al cliente el esfuerzo que supone evitar las prdidas completas, mostrando los diferentes valores que del indicador Estado del Servicio Prestado se obtienen. 4. Servicio de Radiocomunicacin. Supongamos que dotamos a una flota de vehculos de transporte de trasmisores-receptores para comunicacin va radio con su Centro de Operaciones. El equipamiento consiste en una base en cada vehculo y una base en la central. Al equipamiento de los vehculos les hemos incorporado un indicador de seal, que nos indica y registra la calidad de la misma. A nivel operativo, los equipos prestan servicio o no, pero a nivel funcional, dependiendo de cmo sea la seal, el Estado del Servicio Percibido ser mejor o peor, pudiendo anularse por completo, es decir, percepcin 0% mientras que nuestra prestacin es del 100%. Para este tipo de Servicios Tcnicos el Indicador a implementar es el del Estado del Servicio Percibido.

Ya conocemos el primer Indicador a desarrollar con cada Servicio Tcnico, pero nos surge el primer interrogante, cmo calcularlo? Esta claro que para todo Servicio Tcnico lo primero es, determinar el Estado del Servicio de los equipos clave, pero una vez que tengamos definido y construido el Indicador para cada equipo, nos surge el segundo interrogante, cul es el Estado del Servicio que prestan un determinado conjunto de equipos clave? Todo Indicador es en definitiva una frmula de la que obtenemos un valor. Para definir el Indicador Estado del Servicio vamos a apoyarnos en algunos de los conceptos que hemos ido viendo en sucesivos captulos. Uno de estos conceptos ha sido el de Prestacin de Servicio (PS). En el ms puro y estricto sent ido de la 93

prestacin, cualquier equipo, o est funcionando o no. Es como los dos posibles valores de un BIT de informtica, 1 0. Para componer la frmula haremos lo mismo, pero como el Indicador ser un valor porcentual, la Prestacin de Servicio tambin ser porcentual, es decir 0% 100%. Nuestra frmula por ahora es: Estado del Servicio= (PS)Equipo Pero como tambin hemos indicado, an funcionando, en algunos equipos esta prestacin no es completa consecuencia de las Incidencias Operativas que se definan. Al sumatorio de degradaciones lo definiremos como Factor de Degradacin por Causas Propias (FDCP) y tambin ser porcentual. Aplicando esta degradacin a la frmula tendremos: Estado del Servicio= (PS)Equipo-(FDCP)Equipo La frmula as descrita parece completa, pero hemos introducido con anterioridad algunos aspectos que no cubre ninguna de las variables propuestas Cmo valorar en un equipo monitorizado, cundo est funcionando o no? Esta situacin corresponde con el Estado Desconocido. Traducido a otras palabras, existe una situacin de incertidumbre sobre el Estado del Equipo. Cuando un equipo est en Estado Desconocido aplicaremos lo que defini mos como Factor de Incertidumbre. En esos casos la frmula es: Estado del Servicio= (FI)Equipo Y, qu es el Factor de Incertidumbre? Lo definiremos como

La probabilidad de que un equipo est prestando servicio

Esa probabilidad la determinar el siguiente indicador que definimos para el Servicio Tcnico, Disponibilidad del Servicio. La frmula obtenida, sabiendo que la Prestacin de Servicio y el Factor de Incertidumbre son excluyentes, es: Estado del Servicio= (PS)Equipo-(FDCP)Equipo+(FI)Equipo Con dicha frmula abarcamos todos los aspectos posibles de medicin del Estado del Servicio, pues cualquier hecho que se produzca como consecuencia de una anulacin o degradacin del servicio, incluso las causadas por personal o exgenas al propio Servicio Tcnico, tendrn su impacto en cualquiera de las tres variables. Pero la frmula puede ser ampliada desagregando estas variables en otras que consideren estas cuestiones, de manera que, una degradacin de servicio por causas ajenas, siempre que podamos conocerlo, imputaramos la degradacin a un nuevo factor que le bautizamos como Factor de Degradacin por Causas Ajenas (FDCA). Dentro de esta variable, adems de causas tcnicas ajenas al Equipo, se 94

podran incluir las degradaciones por causa del personal, que por norma general son del 100%. En estas circunstancias, la falta de personal se debe considerar para el equipamiento como una Incidencia Operativa. Otra forma de definir las ausencias de personal, es definiendo un nuevo Estado que las contemple, por ejemplo Parada por Falta de Personal. Implementarlo de una u otra forma depender de la informacin a proporcionar segn los requerimientos de diseo. Ya tenemos la respuesta al primer interrogante. Analicemos como resolver el segundo. Supongamos que del ejemplo del Servicio Tcnico de los cajeros
Global

ST Cajeros Pas 1

ST Cajeros Pas n

... ST Cajeros Comunidad 1 ... ST Cajeros Ciudad 1 ... ST Cajeros Ciudad n ST Cajeros Comunidad n ST Cajeros Comunidad 1 ... ST Cajeros Comunidad n

ST Cajeros Ciudad 1 ... ...

ST Cajeros Ciudad n

ST Cajeros Ciudad 1 ...

Caje ro 1 ...

Caje ro n

Caje ro 1 ...

Caje ro 1

Caje ro n ...

Caje ro 1 ...

Caje ro 1 ...

Caje ro n

queremos conocer el servicio que prestan los cajeros de una Ciudad, posteriormente los de la Comunidad y por ltimo los del Pas y el Global. Para construir el Estado del Servicio de cada Ciudad, tenemos que conocer lo que cada equipo participa . Como dijimos hace dos Captulos, necesitamos ponderar de alguna manera a cada equipo. El Estado del Servicio de una Ciudad, ser el sumatorio del Estado del Servicio (ponderado) de cada uno de los equipos en esa Ciudad, y as segn ascendamos jerrquicamente, de manera que, para conocer el Estado del Servicio de una Comunidad, ser el sumatorio del Estado del Servicio ponderado de cada una de sus ciudades. 15.1 Pesos Operativos Definimos como Peso Operativo:

95

Al porcentaje de participacin de cada uno de los elementos de Nivel de Agregacin de Servicio inferior, incluidos los Equipos Clave
El sumatorio de los porcentajes es 100%. El Estado del Servicio de un determinado nivel, ser el Sumatorio de los Estados de Servicio multiplicado por el Peso Operativo de cada uno de los componentes del Nivel inferior excepto, para el Nivel inicial, que el Estado del Servicio se calcular por medio de la frmula. Para determinar el Peso Operativo podemos tener en consideracin, todos aquellos Factores de Ponderacin que determinen la importancia de cada uno respecto del conjunto. Se define como Factores de Ponderacin a:

Los criterios por medio de los cuales se determina el Peso Operativo de cada Equipo Clave
Algunos de estos Factores son:

Usuarios Ventas Operaciones Viajes Contadores (pasos, tiempo, ciclos ...)

Y algunos ms complejos como:

Paralelismo Posicin

Para el Servicio Tcnico de Transporte Vertical, el Factor de Ponderacin en principio a usar es el nmero de usuarios. Para el Servicio Tcnico de Mquinas Expendedoras, las ventas, las operaciones, e incluso una combinacin de ambas. Para el Servicio Tcnico de Corriente Continua, usuarios, viajes... Para el Servicio Tcnico de Cajeros, operaciones. Pero estos mismos Servicios Tcnicos podemos complicarlos con factores ms complejos que los propuestos. Por ejemplo, en el Servicio Tcnico de Transporte Vertical las Escaleras Mecnicas suelen estar en paralelo. Esto significa que una Escalera est de subida y otra de bajada. Para un usuario la accin de subir requiere en principio ms esfuerzo que la de bajada. Ante una Parada de la Escalera de subida siempre queda la opcin de poner la paralela de subida, pero donde solo existe una escalera y su modo de funcionamiento es de subida, podemos variar su contribucin, en funcin de si existe paralelismo o no. En el Servicio Tcnico de Corriente Continua, la alimentacin de toda la lnea ferroviaria se establece por sectores. El perjuicio en teora causado no es igual, 96

que en un momento determinado el Sector sin alimentacin sea alguno de los de cabecera que de los intermedios (posicin). Por lo tanto, los intermedios tendrn ms importancia que los extremos. Podemos, dependiendo de nuestros Servicios Tcnicos, definir y aplicar muchos ms factores de ponderacin, pero lo recomendable, dado el grado de complejidad que adquiere el control establecido por la ponderacin de cada uno de los niveles, es comenzar aplicando un nico factor; aqul que inicialmente sea ms representativo, ms generalista, y con el tiempo, ir mejorando la ponderacin con la informacin extrada de las Auditoras. La Tabla tendra el formato siguiente:

PESO DEL PESO DEL PESO DEL NIVEL 2 NIVEL 2 % NIVEL 1 NIVEL 1 % EQUIPO EQUIPO % N1.1 N2.1 40 N1.2 N1.3 N1.1 N2.2 20 N1.2 N1.1 N1.2 N2.3 40 N1.3 60
Tabla1 En donde dependiendo del mtodo de ponderacin usado, asignaremos un porcentaje a cada equipo y nivel. Una situacin que merece especial consideracin es aquella, en la que teniendo equipos que realicen ms operaciones, pasos, ventas, etc., que otros de su mismo nivel, a la hora de considerar su ponderacin, la contribucin se distribuya uniformemente entre ellos. Para ello consideremos un nuevo Servicio Tcnico: Venta de Ttulos de Transporte. En una est acin de tren disponemos de 4 Mquinas Expendedoras de ttulos (billetes) y sabemos que las operaciones que realiza cada una al cabo del ao es: Expendedora 1 = 200.000 Expendedora 2 = 35.000 97

50 25 25 60 40 15 25

EQ1.1 EQ1.2 EQ1.3 EQ1.1 EQ1.2 EQ1.1 EQ1.1 EQ1.2 EQ1.1 EQ1.2 EQ1.1 EQ1.1 EQ1.2 EQ1.3 EQ1.1 EQ1.2 EQ1.3

35 35 30 60 40 100 75 25 50 50 100 10 25 65 40 35 25

Expendedora 3 = 10.000 Expendedora 4 = 5.000

La explicacin de la diferencias entre ellas viene condicionada por la proximidad a la entrada de la estacin. Si hiciramos el reparto proporcional al nmero de operaciones totales para conocer la ponderacin, tendramos: Expendedora 1 = 200.000/250.000 = 80% Expendedora 2 = 35.000/250.000 = 14% Expendedora 3 = 10.000/25.000 = 4% Expendedora 4 = 5.000 = 2%

Si mantuviramos dicha ponderacin estaramos cometiendo un grave error, ya que si la Expendedora 1 tuviera una Parada, es decir, no prestara servicio, no significara que el Estado del Servicio de la Estacin est al 20%. Las operaciones de la Expendedora 1 se derivaran a la Expendedora 2, en menor medida a la Expendedora 3 y por ltimo a la Expendedora 4. Realmente, el Estado del Servicio es del 75%, pues la opcin de obtener el ttulo de Transporte es por igual en cualquiera de las cuatro. La ponderacin o distribucin en este caso quedara: Expendedora 1 = 25% Expendedora 2 = 25% Expendedora 3 = 25% Expendedora 4 = 25%

Pero el lector puede hacer una apreciacin a esta propuesta. Cuando es solo una de las Expendedoras la que falla, el Estado del Servicio (ES) puede ser ms alto, digamos del 85%, pero a medida que menos mquinas estn funcionando, las prdidas no son lineales sino exponenciales, pues el perjuicio causado por 1, 2 3 equipos de una oferta de 4 no es acumulativo. Un ejemplo de ponderacin dependiendo del nmero de equipos que no estn funcionando podra ser: 1 Expendedora, ES = 85% 2 Expendedoras, ES = 50% 3 Expendedoras, ES = 10% 4 Expendedoras, ES = 0%

El inconveniente es implementar dicha propuesta. Las tablas seguiran manteniendo de cara a la asignacin de los Pesos Operativos los valores del 25%. Sera en la formulacin de las Tablas de Simulacin del Indicador (se vern ms adelante), donde se especificara para implementarlo posteriormente en la aplicacin. La formulacin no sera un sumatorio como se ha indicado continuamente, sino una ecuacin de segundo grado, o para evitar complicar la implementacin del Servicio Tcnico con clculos, estableceramos tablas de 98

conversin en donde la suma de los Pesos Operativos se convierta en valores de Estado del Servicio, por ejemplo: 1 Expendedora, PO = 75%, ES = 90% 2 Expendedoras, PO = 50%, ES = 70% 3 Expendedoras, PO = 25%, ES = 40% 4 Expendedoras, PO = 0%, ES = 0%

El control de los Pesos Operativos es una actividad fundamental dentro de cada Servicio Tcnico, pues no solo pueden cambiar los factores de ponderacin usados, sino que aquellos que han servido de base para definirlos, pueden sufrir variaciones con el tiempo, propias de los cambios tanto funcionales como operativos de cualquier instalacin. Estos cambios pueden ser de dos tipos: 15.1.1 Temporales Definimos como situaciones temporales, aquellas que se producen por un tiempo finito determinado. Si la Tabla 2 representara al Servicio Tcnico de Transporte Vertical, la sustitucin de cualquier equipo significara la baja temporal del mismo y por lo tanto, no prestara servicio. Su situacin sera de no prestacin, pero no debe ser eliminado, pues recuperar su situacin una vez finalizada la intervencin programada. La disyuntiva surge si en situaciones temporales de no prestacin, se considera que el equipo sigue participando o no del Servicio Tcnico aunque no preste actividad ninguna. Evidentemente hay dos opciones: No se le considere parte del Servicio Tcnico. El valor asignado durante ese periodo de tiempo ser del 0% y su porcentaje tendr que ser repartido entre el resto de equipos a su mismo nivel si los hubiera. Importante que si un determinado nivel se pone a 0%, los niveles inferiores afectados tambin se ponen a 0% (Ver Tabla 2).

99

PESO DEL PESO DEL PESO DEL NIVEL 2 NIVEL 2 % NIVEL 1 NIVEL 1 % EQUIPO EQUIPO % N1.1 N2.1 40 N1.2 N1.3 N1.1 N2.2 20 N1.2 N1.1 N1.2 N2.3 40 N1.3 60 0 15 25 25 25 100 50 EQ1.1 EQ1.2 EQ1.3 EQ1.1 EQ1.2 EQ1.1 EQ1.1 EQ1.2 EQ1.1 EQ1.2 EQ1.1 EQ1.1 EQ1.2 EQ1.3 EQ1.1 EQ1.2 EQ1.3 50 50 0 60 40 100 75 25 0 0 100 10 25 65 40 35 25

Tabla 2 Se le considere parte del Servicio Tcnico. El valor asignado durante ese periodo de tiempo se mantiene, permaneciendo inalterados los Pesos Operativos de los niveles inferiores. (Ver Tabla 1)

15.1.2 Definitivos Definimos como situaciones definitivas, todas las altas y bajas, tanto de equipos como de niveles o tambin, las variaciones en el clculo del factor. Partiendo de la Tabla 1, podramos tener la siguiente tabla:
PESO DEL PESO DEL PESO DEL NIVEL 2 NIVEL 2 % NIVEL 1 NIVEL 1 % EQUIPO EQUIPO % N1.1 N2.1 40 N1.2 N1.3 N2.2 20 N1.1 N1.1 N1.2 N2.3 40 N1.3 60 50 25 25 100 15 25 EQ1.1 EQ1.2 EQ1.1 EQ1.2 EQ1.3 EQ1.1 EQ1.1 EQ1.2 EQ1.1 EQ1.1 EQ1.2 EQ1.3 EQ1.1 EQ1.2 EQ1.3 50 50 35 35 30 100 75 25 100 10 25 65 40 35 25

Tabla 3 100

Importante que el sumatorio de los porcentajes sea 100. Hay una cuestin a la hora de definir los Pesos Operativos, que implica un gran impacto en muchos de los Servicios Tcnicos que se diseen. Durante la exposicin del Servicio Tcnico de Venta de Ttulos de Transporte , hemos realizado el anlisis considerando que las cuatro expendedoras participaban por igual en el tiempo. Pero supongamos que a partir de un determinado instante del da y debido a la escasa venta de Ttulos, se desconectan automticamente dos de las expendedoras, volvindose a conectar transcurridas 6 horas. En definitiva, los equipos tienen dos horarios, dos de los equipos 24 horas y los otros dos 18 horas. La situacin inicial es: Expendedora 1 = 25% Expendedora 2 = 25% Expendedora 3 = 25% Expendedora 4 = 25%

Y si la desconexin de la expendedora 3 y 4 se produce desde las 24:00 hasta las 06:00 horas, la situacin es: Expendedora 1 = 50% Expendedora 2 = 50% Expendedora 3 = 0% Expendedora 4 = 0%

Qu implica este nuevo planteamiento? Sin entrar por ahora en ms consideraciones, la duplicacin de los Pesos Operativos asignados y como se ve afectado el reparto proporcional al mismo nivel. Analicemos el Estado del Servicio desde las 00:00 horas del da 1 hasta las 24:00 horas del da 2, en total 48 horas para los siguientes supuestos: a. Parada por Incidencia Tcnica del Servicio de la Expendedora 1 desde las 20:00 horas del da 1, hasta las 12:00 horas del da 2. b. Parada por Incidencia Tcnica del Servicio de la Expendedora 3 desde las 20:00 horas del da 1, hasta las 12:00 horas del da 2. En primer lugar tendramos dos Tablas con los diferentes Pesos Operativos. Eso significa, que en la aplicacin es necesario implementar la opcin de establecer horarios para cada Equipo y el Peso Operativo en cada uno de esos horarios... Pero a lo mejor en los Niveles de Agregacin de Servicio superiores, tambin es necesario implementarlo. En la siguiente tabla podemos apreciar los equipos En Servicio y los diferentes valores del Estado del Servicio por franja horaria de cada supuesto: 101

Supuesto a Estado del Servicio En Servicio 00:00-06:00 Expendedora 1 Expendedora 2 Expendedora 1 Expendedora 2 06:00-20:00 Expendedora 3 Expendedora 4 Expendedora 2 20:00-24:00 Expendedora 3 Expendedora 4 00:00-06:00 Expendedora 2 Expendedora 2 06:00-12:00 Expendedora 3 Expendedora 4 Expendedora 1 Expendedora 2 12:00-24:00 Expendedora 3 Expendedora 4 100

Supuesto b Estado del Servicio En Servicio Expendedora 1 Expendedora 2 Expendedora 1 Expendedora 2 Expendedora 3 Expendedora 4 Expendedora 1 Expendedora 2 Expendedora 4 Expendedora 1 Expendedora 2 Expendedora 1 Expendedora 2 Expendedora 4 Expendedora 1 Expendedora 2 Expendedora 3 Expendedora 4 100

Da 1

100

100

75 50 75

75 100 75

Da 2

100

100

Durante el periodo comprendido entre las 00:00 y las 06:00 horas del da 2, la diferencia del Indicador Estado del Servicio es del 50%, consecuencia de la Incidencia que afecta a la Expendedora 1. En el resto del tiempo y consecuencia del reparto proporcional, coinciden los valores para ambos supuestos. Pero solo con haber establecido una distribucin de Pesos Operativos diferente para las cuatro, las diferencias durante los dos das seran ms significativas. Supongamos que las Expendedoras 1 y 2 estn en una entrada y las Expendedoras 3 y 4 en otra que desde las 00:00 horas hasta las 06:00 horas se cierra. El resultado de la distribucin segn la nueva disposicin geogrfica es la siguiente. De 06:00 a 24:00 horas: Expendedora 1 = 30% Expendedora 2 = 30% Expendedora 3 = 20% Expendedora 4 = 20%

De 00:00 a 06:00 horas Expendedora 1 = 50% Expendedora 2 = 50% Expendedora 3 = 0% Expendedora 4 = 0% 102

Con los dos supuestos planteados inicialmente el resultado obtenido es:

Da 1

Supuesto a Estado del Servicio En Servicio Expendedora 1 00:00-06:00 100 Expendedora 2 Expendedora 1 Expendedora 2 06:00-20:00 100 Expendedora 3 Expendedora 4 Expendedora 2 20:00-24:00 Expendedora 3 70 Expendedora 4 00:00-06:00 Expendedora 2 Expendedora 2 06:00-12:00 Expendedora 3 Expendedora 4 Expendedora 1 Expendedora 2 12:00-24:00 Expendedora 3 Expendedora 4 50 70

Da 2

100

Supuesto b Estado del Servicio En Servicio Expendedora 1 100 Expendedora 2 Expendedora 1 Expendedora 2 100 Expendedora 3 Expendedora 4 Expendedora 1 Expendedora 2 80 Expendedora 4 Expendedora 1 100 Expendedora 2 Expendedora 1 Expendedora 2 80 Expendedora 4 Expendedora 1 Expendedora 2 100 Expendedora 3 Expendedora 4

Las diferencias en el Estado del Servicio son ms significativas. La conclusin es obvia, existirn Servicios Tcnicos cuyos equipos tengan los mismos horarios de funcionamiento, pero otros no y en estos casos, ser necesario generar tantas Tablas de Pesos Operativos, como franjas horarias de funcionamiento puedan darse. Esta situacin planteada, realmente debera abordarse estableciendo Calendarios particulares para cada Equipo por cada Servicio Tcnico. La dificultad reside, no solo en la gran cantidad de distribuciones a realizar de Pesos Operativos entre los diferentes Equipos y Niveles, sino adems en su mantenimiento. Por lo tanto, es recomendable, en la medida de lo posible, establecer nicamente Horarios dejando fuera del control, aquellos Equipos que por sus circunstancias presten servicio determinados das del mes o del ao. Equipos con prestaciones parciales semanales pueden ser abordados con el planteamiento de Horarios. 15.2 Pesos Tcnicos Definimos como Peso Tcnico (PT):

Al porcentaje de prdida de servicio asociado a un equipo o instalacin

103

Cada Incidencia Operativa tendr asociada un Peso Tcnico, que permitir ir degradando el servicio por acumulacin de las mismas. Inicialmente consideraremos que el sumatorio de los Pesos Tcnicos es 100%, pues la prdida de todas las funcionalidades anula el servicio en el equipamiento. Ms adelante veremos que no siempre se cumple y en esos casos, es necesario disear reglas que permitan controlar dichas situaciones. El resultado obtenido por la acumulacin de las Incidencias Operativas, es decir, el sumatorio de los Pesos Tcnicos se aplicar en la frmula del Estado del Servicio, concretamente en el Factor de Degradacin por Causas Propias. Pongamos un ejemplo muy sencillo. En el Servicio Tcnico de las Mquinas Expendedoras todos los equipos tienen las mismas funcionalidades. Identificamos que son capaces de vender 3 tipos distintos de bebida y 2 de comida:

Bebida 1 Bebida 2 Bebida 3 Comida 1 Comida 2

Si asignamos a cada opcin de venta un porcentaje, segn se produzcan situaciones de imposibilidad de obtencin de un determinado producto el servicio se degrada, llegndose a anular cuando la mquina no pueda despachar ninguno de sus productos, independientemente de la causa. De igual forma que para el Peso Operativo determinbamos factores de clculo, para establecer los Pesos Tcnicos podemos usar los mismos factores. Supongamos en este caso que aplicamos el factor de ventas (productos vendidos), obteniendo los siguientes Pesos Tcnicos (porcentajes):

Sin Bebida 1, PT = 30% Sin Bebida 2, PT = 20% Sin Bebida 3, PT = 20% Sin Comida 1, PT = 10% Sin Comida 2, PT = 20%

El sumatorio es 100%. Realmente hemos simplificado enormemente el ejemplo y pocos pueden ser los Servicios Tcnicos que cumplan tan sencilla casustica. Usando el mismo ejemplo, veamos como se puede complicar. Adems de las funcionalidades definidas aadimos que admite monedas y billetes. En este caso las funcionalidades son:

Bebida 1 Bebida 2 Bebida 3 104

Comida 1 Comida 2 Pago con monedas Pago con billetes

Y la asignacin de los Pesos Tcnicos:

Sin Bebida 1, PT = 25% Sin Bebida 2, PT = 15% Sin Bebida 3, PT = 15% Sin Comida 1, PT = 10% Sin Comida 2, PT = 10% No Admite Monedas, PT = 15% No Admite Billetes, PT= 10%

El sumatorio es de nuevo 100%, pero Qu sucede sino es posible pagar con monedas ni billetes? Pues que aunque la mquina disponga de todos los productos, no ser posible adquirirlos. El Estado del Servicio sera del 75% (ES=100%(PS)-25%(FDCP)) aplicando la degradacin por los Pesos Tcnicos, pero la realidad es que el Estado del Servicio sera del 0%. Lo ms evidente es haber creado la siguiente relacin de Pesos Tcnicos:

Sin Bebida 1, PT = 30% Sin Bebida 2, PT = 20% Sin Bebida 3, PT = 20% Sin Comida 1, PT = 10% Sin Comida 2, PT = 20% No Admite Monedas, PT = 60% No Admite Billetes, PT= 40%

Pero puede darse la circunstancia, que acumulando un nmero determinado de Incidencias Operativas superemos el 100%, mientras el equipo sigue estando en servicio. Por ejemplo:

Sin Bebida 1, PT = 30% Sin Bebida 2, PT = 20% No Admite Monedas, PT = 60%

Su suma es 110%. Como es mayor a 100%, el Estado del Servicio nunca puede ser negativo y por lgica diramos que el Estado del Servicio es 0%, pero sin embargo, el equipo todava est operativo y presta servicio.

105

Para situaciones similares es dnde en base a las Incidencias Operativas y la relacin entre las mismas, debemos aplicar reglas de clculo. 15.2.1 Reglas Acumulativas Definimos como regla acumulativa, aquella situacin en la que la prdida de servicio de dos o ms Incidencias Operativas, es superior a la suma de las mismas. Manteniendo la asignacin de Pesos Tcnicos cuya suma es 100%

Sin Bebida 1, PT = 25% Sin Bebida 2, PT = 15% Sin Bebida 3, PT = 15% Sin Comida 1, PT = 10% Sin Comida 2, PT = 10% No Admite Monedas, PT = 15% No Admite Billetes, PT= 10%

cuando se produzca la acumulacin de las dos ltimas Incidencias Operativas, el Factor de Degradacin por Causas Propias no ser del 25%, sino del 100% y como consecuencia el Estado del Servicio del 0%, ya que no hay forma de obtener el producto deseado. Las acumulaciones no tienen porque ser siempre de anulacin completa, a la hora de construir el Gestor de Servicios, desarrollaremos reglas acumulativas que nos permitan incrementar el Factor de Degradacin por Causas Propias superior a la suma de sus Pesos Tcnicos. Por ejemplo, sino disponemos de la Comida 1 ni de la Comida 2 el Factor de Degradacin por Causas Propias es igual al 20%, pero que no venda ningn tipo de comida podemos tratarlo como una circunstancia excepcional, asignando otro Peso Tcnico, por ejemplo IO6+IO7=20%FDCP=50%. En la herramienta integraremos la posibilidad de acumular Incidencias Operativas y asignarles un Peso Tcnico predefinido diferente a su suma. Obviamente esta opcin es interesante, tanto para cuando queremos penalizar la acumulacin de Incidencias Operativas, como reducirlas. Este ltimo caso con especial mencin, para cuando no quede ms remedio que asignar Pesos Tcnicos cuya suma exceda significativamente del 100%, pero no anulen el servicio 15.2.2 Reglas de Exclusin Definimos como Exclusin, aquella situacin en la que dos o ms Incidencias Operativas no pueden darse simultneamente. Aadamos una nueva Incidencia Operativa a los ejemplos vistos consecuencia de la funcionalidad Pago con Monedas (no le asignamos Peso Tcnico ya que para la explicacin no es necesaria):

106

Precio Exacto, PT = X%

Las tres ltimas Incidencias Operativas tienen un tratamiento especial. No se pueden dar simultneamente las siguientes combinaciones:

No Admite Monedas y Precio Exacto No Admite Billetes y Precio Exacto

En el primer caso, o no admite monedas o permite monedas aunque haya que pagar con la cantidad exacta. En el segundo caso el Precio Exacto tiene implcito que No Admite Billetes. Las reglas de Exclusin tienen esta finalidad, evitar degradar el servicio en un porcentaje que no corresponde. Cuando en un Servicio Tcnico tengamos que establecer reglas de Exclusin, es muy importante determinar la prioridad de los SubEstados producidos. En el caso analizado, Precio Exacto tendr prioridad sobre No Admite Monedas y No Admite Billetes. La herramienta con la que definiremos estas prioridades es la Matriz de Estados. Sin tener en cuenta todas las Incidencias que hemos definido en los ejemplos, la Matriz de Estados correspondiente al ejemplo expuesto es:
Parada Incidencia Tcnica del Servicio Parada Incidencia Tcnica del Servicio

Parada Manual

En Servicio

No admite monedas (1)

No admite billetes (2)

Precio exacto (3)

Parada Manual

En Servicio

Parada Incidencia Parada Incidencia Tcnica del Servicio Tcnica del Servicio Parada Incidencia Tcnica del Servicio Parada Incidencia Tcnica del Servicio Parada Incidencia Tcnica del Servicio Parada Incidencia Tcnica del Servicio

En Servicio

Parada Manual Parada Incidencia Tcnica del Servicio

Parada Manual Parada Incidencia Tcnica del Servicio

Parada Manual Parada Incidencia Tcnica del Servicio

En Servicio

Parada Manual

En Servicio. No admite monedas (1) Parada Manual

En Servicio. No admite billetes (2)

Parada Manual

En Servicio. Precio exacto

Parada Manual

En Servicio. No En Servicio. No admite monedas admite billetes Parada Incidencia En Servicio. No Tcnica del admite monedas Servicio Parada Incidencia En Servicio. No Tcnica del admite billetes Servicio Parada Incidencia En Servicio. Tcnica del En Servicio. Precio exacto Servicio Precio exacto

En Servicio. Precio exacto

En Servicio. Precio exacto

En Servicio. Precio exacto

Matriz de Cambio de Estados Importante destacar que aunque las Incidencias Operativas Precio Exacto y No Admite Monedas son excluyentes, un Equipo que est En Servicio con Precio Exacto y llegue la Incidencia No Admite Monedas, significar Parada por Incidencia Tcnica del Servicio, ya que Precio Exacto segn hemos definido implicaba No Admite Billetes y por la regla de acumulacin, 107

No Admite Monedas y No Admite Billetes supone que el Factor de Degradacin por Causas Propias es del 100%, es decir, el Estado del Servicio igual al 0%. 15.2.3 Reglas de Inclusin Este tipo de reglas permite integrar en los Servicios Tcnicos Incidencias Operativas de orden genrico. Supongamos un equipo que posee tres elementos iguales redundados para realizar la misma funcin. Adems y bajo determinadas circunstancias, como pueden ser fuertes demandas, dos o ms de estos elementos son capaces de funcionar simultneamente. Un ejemplo tpico son los pozos de bombeo. Segn diseo, cada bomba est pensada para extraer un caudal de agua de aforo dos veces superior a la de diseo. Esto significa que un pozo con tres bombas tiene una capacidad de extraccin de 6 veces su diseo. A la hora de construir un Servicio Tcnico de Bombeo, lo significativo es conocer, cuando hay una bomba o dos bombas sin funcionar, pero sin identificar si es la 1, la 2 la 3, o la combinacin de stas, excepto en el caso de las tres bombas, que es obvio. Las Reglas de Inclusin permiten definir este tipo de Incidencias Operativas de carcter genrico, pues segn el ejemplo, la Incidencia Operativa Una bomba en fallo se da cuando est averiada la bomba 1, 2 3 , y la Incidencia Operativa Dos bombas en fallo se da , cuando se averan simultneamente las bombas 1 y 2, 1 y 3 2 y 3. Al Servicio Tcnico, adems de las Incidencias Operativas Una bomba en fallo y Dos bombas en fallo, daremos de alta las Incidencias Operativas Fallo en bomba 1, Fallo en bomba 2 y Fallo en bomba 3. Posteriorme nte las agruparemos como reglas de inclusin para que el Servicio Tcnico solo muestre las de Una bomba en fallo o Dos bombas en fallo. Segn lo expuesto, daramos de alta las siguientes reglas de inclusin concretas: Fallo en bomba 1 Una bomba en fallo Fallo en bomba 2 Una bomba en fallo Fallo en bomba 3 Una bomba en fallo Fallo en bomba 1 y Fallo en bomba 2 Dos bombas en fallo Fallo en bomba 1 y Fallo en bomba 3 Dos bombas en fallo Fallo en bomba 2 y Fallo en bomba 3 Dos bombas en fallo Conocidos los tipos de reglas aplicables, la ltima cuestin que queda por determinar es el mtodo usado para aplicar los Pesos Tcnicos. Lo ms lgico en principio sera, que a cada equipo se le aplicara la valoracin propia que competa. Por contra, esta asignacin complica considerablemente la construccin del Servicio Tcnico, ya que puede suceder, que cada equipo clave tenga diferencias al aplicar las reglas sobre las mismas Incidencias Operativas, con respecto de otro idntico a l. Parece ms coherente aplicar los Pesos Tcnicos por grupos de equipos homogneos. En principio, tipos distintos de equipos se implementarn 108

con asignaciones diferentes. Incluso parece lgico, que los Pesos Operativos de una mquina que solo despacha agua y refresco 1, sean diferentes de la que despacha agua, refresco 1 y refresco 2 aunque sean del mismo tipo. Por ello, lo primero es aglutinar los equipos por aquellos cuyas Incidencias Operativas son iguales. A esta primera agrupacin la denominaremos por tipo de equipo. A la hora de definir los equipos, necesitamos establecer una caracterstica que les desempareje; en definitiva, diferenciarlos por Tipo de Objeto. Si adems fuera necesario dentro de un mismo Tipo de Objeto diferenciar entre modelos, porque sea de una serie mejorada, porque no posea alguna de las Incidencias Operativas... la asignacin se realizar por Catlogo. Manteniendo ambas premisas, lo normal es que en un mismo Servicio Tcnico tengamos pocos tipos de asignaciones, de manera que, en el momento de aplicar las reglas que entre las Incidencias Operativas se estipulen, vengan relacionadas y condicionadas por esta dualidad Tipo de ObjetoCatlogo. A los ejemplos que habamos propuesto de mquinas expendedoras, aadimos otro tipo de mquina que solo despacha caf y agua. Tenemos pues dos Tipos de Objeto y dos Catlogos: 1) Tipo de Objeto que despacha agua y refrescos (de 1 a n) a) Modelo que despacha agua y refresco 1 b) Modelo que despacha agua, refresco 1 y refresco 2 2) Tipo de Objeto que despacha agua y caf El resultado son tres diferentes asignaciones de Pesos Tcnicos: PT 1) a) PT 1) b) PT 2)

No obstante, en aquellos Servicios Tcnicos donde el volumen de equipos clave sea muy bajo, la asignacin individual de los Pesos Tcnicos es la opcin idnea, pues cada uno de los Pesos Tcnicos estar en funcin de los Factores de Ponderacin particulares (ventas, operaciones ...) de cada equipo. En este captulo, ms que hablar de Indicadores, hemos hablado del Indicador con maysculas, Estado del Servicio. Pero tambin hemos comentado otro Indicador, Disponibilidad del Servicio. Prcticamente no existe uno sin el otro, pero Cul es el servicio durante un tiempo concreto? Cuando nos planteemos disear y construir un Servicio Tcnico, no slo la consideracin de conocer en un momento determinado el servicio debe ser uno de los objetivos a establecer, sino adems, la Disponibilidad del Servicio en un tiempo finito. Alrededor del Estado del Servicio se pueden desarrollar toda una serie de polticas causa accin encaminadas a, restablecer el servicio en el menor tiempo, conocer y controlar situaciones crticas, evaluar impactos en usuarios, ciclos y periodicidades, grficas de comportamiento 109

etc., pero con el Indicador del Estado del Servicio no es posible comprometer niveles de servicio, pues uno de los principales motivos por los que un Servicio Tcnico debe realizarse, es para conocer el servicio que se le proporciona a un usuario (cliente). La Disponibilidad del Servicio, es la evolucin del Estado del Servicio en el tiempo. Ahora bien, s ser el indicador seal que permita detonar las acciones correctoras para cumplir los acuerdos de nivel de servicio pactados. Analicemos la siguiente grfica evolutiva del Estado del Servicio:
100
Estado del Servicio

98 96 % 94 92 90
Estado del Servicio Media

Media

T1 95,4 95,53

T2 96,7 95,53

T3 92,3 95,53

T4 90,9 95,53

T5 98,1 95,53

T6 94,3 95,53

T7 100 95,53

T8 97,2 95,53

T9 92,4 95,53

T10 98 95,53

Tiempos

Estado del Servicio - Tabla 1 La media obtenida es de 95,53%. Este valor es la Disponibilidad del Servicio entre T1 y T10, siempre y cuando cada uno de los tiempos en los que se ha registrado el Estado del Servicio sea igual, pero, es as como vamos a registrar el Estado del Servicio? Es una opcin, pero obliga a que continuamente se sondee el Estado del Servicio de cada equipo, guardar el dato y que la periodicidad del sondeo se realice en intervalos de pocos segundos.

110

Analicemos la siguiente grfica:

100
Estado del Servicio

98 96 % 94 92 90
Estado del Servicio Media

Media

T1 92,3 92,87

T2 92,3 92,87

T3 92,3 92,87

T4 92,3 92,87

T5 92,3 92,87

T6 92,3 92,87

T7 92,3 92,87

T8 92,3 92,87

T9 92,3 92,87

T10 98 92,87

Tiempos

Estado del Servicio Tabla 2 Lo primero que se aprecia es la estabilidad de los datos registrados. Con haber registrado el valor de 92,3% y el tiempo trascurrido desde T1 a T9, ms, el valor 98% y T10, hubiera sido posible obtener la misma media. No era necesario sondear peridicamente el Estado, solo registrar las variaciones del mismo y el tiempo transcurrido. Cual de los dos planteamientos adoptar est en funcin de las herramientas informticas que se usen, pero el segundo mtodo planteado es ms eficiente, pues evita dos aspectos fundamentales en cualquier desarrollo informtico: 1) Consumos de CPU, memoria, ancho de banda de red... 2) Menor tamao de la Base de Datos pues solo se registran las variaciones. Con la media estamos obteniendo el Indicador Disponibilidad del Servicio y la principal utilidad de este Indicador como hemos comentado, es la posibilidad de establecer y acordar niveles de cumplimiento. La Disponibilidad del Servicio es lo que se define como Indicador de Cliente, vlido tanto para el cliente interno como para el cliente externo. Para la Disponibilidad del Servicio se sigue cumpliendo la frmula planteada: Disponibilidad del Servicio= (PS)Medio-(FDCP)Medio+(FI)Medio)Equipo O lo que es lo mismo: Disponibilidad del Servicio=((ESEquipo)Duracin)/Tiempo Total 111

Veamos el siguiente ejemplo de un equipo que presta Servicio desde las 6:00 hasta las 24:00 horas: El Indicador Disponibilidad del Servicio es:

% Estado Servicio 100% 90% 50% 60% 25%

Hora inicio 06:00 10:00 16:00 17:00 19:00

Hora fin 10:00 16:00 17:00 19:00 24:00

Tiempo (Hf-Hi) 4:00 = 240m 6:00 = 360m 1:00 = 600m 2:00 = 120m 5:00 = 300m

DS =

(100*240)+(90*360)+(50*60)+(60*120)+(25*300) = 68.61% 1080

Es decir, la Disponibilidad del Servicio del equipo ha sido del 68.61%. Cuando planteamos la frmula del Estado del Servicio, uno de los factores que la integran es el Factor de Incertidumbre (la probabilidad de que un equipo est prestando servicio). La probabilidad en un momento determinado depender de la Disponibilidad del Servicio. De esta manera en los equipos monitorizados, cuando no exista la posibilidad de saber si un equipo est o no prestando servicio aplicaremos el Factor de Incertidumbre, o lo que es lo mismo, la Disponibilidad de Servicio de ese equipo. Cuando se modele un Servicio Tcnico, es necesario proporcionar la Disponibilidad de Servicio que cada uno de los equipos haya tenido durante el ao anterior y cada ao transcurrido variarla. El inconveniente evidente es, que la primera vez no se tendr dicha cifra y como para el clculo del Estado del Servicio es necesario, una posibilidad si se dispone de la informacin, sera recurrir a la Disponibilidad Tcnica de cada equipo. En el peor de los casos es asumir que la Disponibilidad del Servicio inicial es del 100%, y en cuanto trascurrido un tiempo que se considere razonable obtener la Disponibilidad del Servicio de cada equipo, sustituirlo por este nuevo valor. En otras implementaciones puede que no interese aplicar un valor al Factor de Incertidumbre, solo informar de la Situacin Operativa (Desconocido). Depender de las caractersticas del Servicio Tcnico. Tanto el Estado del Servicio como la Disponibilidad del Servicio, son indicadores orientados a conocer el servicio ofertado (producido) y determinantes para mejorar la percepcin del cliente. En definitiva estamos hablando del Ciclo de la Calidad. 112

Calidad Exigida

Calidad Objetivo

cliente
Calidad Percibida Calidad Producida

proveedor

Pero no tienen porque ser los nicos. En captulos sucesivos comentaremos otros indicadores que pueden ayudar a completar e incluso sustituir a los dos planteados, pues para determinados Servicios Tcnicos, ofrecen una mejor perspectiva de lo ofertado.

113

114

16 DISPONIBILIDAD DE SERVICIO vs. DISPONIBILIDAD TCNICA

Durante el captulo anterior, hemos planteado la formulacin para determinar la Disponibilidad de Servicio, y aunque durante el libro hemos tratado tambin la Disponibilidad Tcnica y las diferencias entre ambas, justificando en todo momento la necesidad de ambos indicadores, puede que la comprensin de ambas mtricas y su relacin, no est completamente explicada.

DISPONIBILIDAD

DISPONIBILIDAD DE SERVICIO

TCNICA

Lo primero que observamos es, que la Disponibilidad de Servicio ser siempre menor o igual que la Disponibilidad Tcnica (DS<=DT). Cmo se llega a esta conclusin? La DT es (TFT-TP)/TFT Donde TFT es el Tiempo de Funcionamiento Terico y T P el Tiempo de Parada. La Disponibilidad de Servicio es (PSMedio-FDCPMedio+FIMedio)Equipo Donde PS es la Prestacin de Servicio, FDCP el Factor de Degradacin por Causas Propias y FI el Factor de Incertidumbre. Pero en aquellos equipos donde no existan degradaciones, la Disponibilidad de Servicio podra plantearse tambin como: (TFT-TPT)/TFT 115

Donde el TPT (Tiempo de Parada Total) incluira tanto las paradas por causas propias, como las ajenas. Pero que consideraramos paradas por causas ajenas? sta es la clave del asunto. Cuando se desarrolla cualquier Servicio Tcnico, uno de los hitos ms importantes en el desarrollo e implantacin, es determinar y controlar todas las circunstancias que impiden al Equipo Clave prestar su servicio. En captulos precedentes hemos tratado a los Equipos Implicados, como integrantes fundamentales en la prestacin del servicio. El establecimiento y control de las relaciones entre estos y el Equipo Clave, es crtico para el correcto funcionamiento del aplicativo a la hora de proporcionar indicadores e informacin relevante sobre el Servicio Tcnico. La monitorizacin del equipamiento se muestra como opcin altamente rentable. An as, pueden existir circunstancias que paren al equipo y no seamos capaces de controlarlas? Si el equipo est monitorizado, pudieran existir casos derivados por causas exgenas. Pero en los equipos no monitorizados esta problemtica se ve acentuada en gran medida, ya que paradas derivadas por el ser humano en las que no exista reflejo informativo de las mismas, no seramos capaces de trasladarlas al aplicativo proporcionando informacin errnea. Un caso evidente son las paradas derivadas del mantenimiento preventivo, ya que la informacin sobre los tiempos es informada a posteriori de la actuacin y como la Disponibilidad de Servicio es consecuencia del Estado de Servicio y ste, es un indicador en tiempo real, no existe en principio posibilidad de repercutir la parada, nicamente si el equipo de intervencin previa a la actuacin, llama al Centro de Atencin comunicando cuando comienzan y cuando terminan, modificando manualmente por medio de un operador la situacin del equipo en la herramienta. Para saber exactamente qu debemos considerar en el tiempo de parada, hagamos un esquema que nos permita extractar todos los casos posibles: - Causas Propias. Derivadas del programadas...) Equipo Clave (incidencias, actuaciones

Derivadas de los Equipos Implicados (incidencias, actuaciones programadas...)

- Causas Ajenas. Derivadas de la intervencin humana (paradas voluntarias...) Exgenas (inundaciones...)

Aunque en el captulo 19 trataremos las ventajas e inconvenientes de los equipos monitorizados frente a los no monitorizados, cuando el equipo est monitorizado, tanto las causas propias como las ajenas estaran en principio controladas. 116

Por contra, si el equipo no est monitorizado, para las causas propias debemos contar con un Centro de Atencin, pero adems, controlar las intervenciones que no sean incidencias y no slo las derivadas de mantenimiento. Por ejemplo las derivadas de logstica. Para controlar las ajenas es imprescindible, contar en la medida de lo posible con procedimientos que reflejen toda intervencin humana. El gran inconveniente para controlar las ajenas reside, en que la mayora de ellas son exgenas al Servicio Tcnico, siendo difcil su integracin. Las Escaleras Mecnicas tienen al alcance de cualquier usuario un botn para en caso de emergencia detener su marcha. Cmo reconocer estas paradas? Ya sea justificadamente o no, es imposible fiscalizar estas situaciones. Monitorizados o no, estamos comparando las Disponibilidades sobre un equipo que no sufre degradaciones. Si el equipo como hemos visto en captulos anteriores, tiene prdidas de funcionalidad, cmo se vera alterada la frmula, ms concretamente el Tiempo de Parada? Se me antoja casi imposible reflejar en dicha variable las degradaciones sufridas, pues el factor FDCP es un porcentaje establecido sobre el servicio prestado y no un tiempo de anulacin. La frmula de Disponibilidad de Servicio segn el Tiempo: DS=(TFT-TPT)/TFT Debe ser complementada con otra variable, tambin en funcin del tiempo, que permita realizarlo. Lo primero que tenemos que tener presente es, que si en lugar de calcular la Disponibilidad de Servicio usamos esta frmula para calcular la Disponibilidad Tcnica, el tiempo durante el cual haya una o varias prdidas de funcionalidad que afecten al Servicio Tcnico, no se consideran Tiempos de Parada, por lo que en principio la Disponibilidad Tcnica sera del 100%, ya que aunque el equipo est en Funcionamiento Disminuido, de cara al cl culo de la Disponibilidad Tcnica no afectara. ste podramos considerarlo un aspecto determinante de por qu realizar un Servicio Tcnico. Por eso continuando con nuestra frmula, la prdida de funcionalidad es necesaria expresarla como un tiempo de parada aplicndole un factor de correccin. Como realmente no es un tiempo de parada, sino de funcionamiento disminuido, as lo vamos a reflejar y el factor de correccin ser el Peso Tcnico asociado a la prdida de funcionalidad, es decir, a la Incidencia Clave. La Disponibilidad de Servicio sera (TFT-TPT-(TFD*PT))/TFT Donde TFD es el Tiempo de Funcionamiento Disminuido y PT el Peso Tcnico. Para equipamiento con grandes variaciones de prestacin de servicio, sobre todo la causada por paradas ajenas y degradaciones, la diferencia de porcentaje entre 117

ambas disponibilidades se hace notoria. Para que sea todava ms evidente, mejoremos el parmetro TPT considerando los factores del siguiente esquema. Llamamos TPCPEC al Tiempo de Parada por causas propias del Equipo Clave. Sera igual que el TP. Por lo tanto, este parmetro de la frmula se mantendr como el original de la frmula de Disponibilidad Tcnica. TPCPEI es el Tiempo de Parada por causas propias del Equipo Implicado. TPCAIH es el Tiempo de Parada ocasionada por intervencin humana. TPE es el Tiempo de Parada por causas exgenas. La frmula para la Disponibilidad de Servicio quedara: (TFT-TP-TPCPEI-TPCAIH-TPE-(TFD*PT))/TFT Pero esta frmula comparada con la del Estado de Servicio es menos precisa, si as es posible expresarlo. Para el Estado de Servicio, cuando no es posible determinar si el equipo presta o no servicio, en lugar del parmetro Prestacin de Servicio aplicamos el Factor de Incertidumbre, valor que se obtiene de la Disponibilidad Media de Servicio del equipo. Aunque es rizar el rizo, para los equipos monitorizados es completar el crculo. Es posible incluir el Factor de Incertidumbre en la formulacin? Por supuesto que s. Si hemos llegado hasta aqu... Para hacerlo, de la misma manera que con las degradaciones. Muy importante es recordar que cuando un equipo est en estado Desconocido, ya no se aplicaba la Prestacin de Servicio. Por lo tanto en la frmula, debemos descontar el tiempo de duracin de la incertidumbre. Por tal motivo tendremos TI(1-FI), donde TI es el Tiempo de incertidumbre y FI el Factor de Incertidumbre. Si lo incluimos obtenemos: (TFT-TP-TPCPEI-TPCAIH-TPE-(TFD*PT)-TI(1-FI))/TFT Sustancialmente, para determinados Servicios Tcnicos, la Disponibilidad de Servicio del equipamiento ser mucho menor que la Disponibilidad Tcnica. Este argumento justifica imperativamente la necesidad de su construccin. Comparando ambas frmulas, la de Disponibilidad Tcnica y la de Disponibilidad de Servicio en funcin del tiempo, es cuando se entiende la imagen que ilustraba el comienzo de este captulo, y adems, la importancia que tiene para muchos equipos e instalaciones, construir su Servicio Tcnico. Para evitar asociar a la Disponibilidad Tcnica como si fuera una Disponibilidad de Servicio. Pero no queremos dejar la impresin de que la nica Disponibilidad a construir debe ser la de Servicio. En absoluto. La Disponibilidad Tcnica es un indicador mundialmente reconocido, incluido dentro de la norma UNE-EN 15341 Indicadores clave de rendimiento del mantenimiento, esencial para todo departamento dedicado al mantenimiento. Sino como medir, la subcontratacin, establecer planes de renovacin, determinar la fiabilidad de los equipos,... por poner algunos ejemplos.

118

17 EL APOYO DE LOS FLUJOGRAMAS (DIAGRAMAS DE FLUJO)

Durante los captulos anteriores hemos ido incorporando flujogramas, que nos han permitido explicar grficamente los diversos conceptos que son necesarios para el diseo. Para cada Servicio Tcnico, los Flujogramas que por su alta representatividad tienen ms importancia para la fase de Construccin son: El Diagrama de Estados El Flujograma del Servicio El Flujograma de la Fase

El primero de ellos fue visto en el captulo de Definicin de Estados. Para el segundo tipo propuesto, analicemos el siguiente esquema simplificado:

Equipos del Servicio

Compaa de Suministro Elctrico

Equipamiento indirecto

Celda de Alta Tensin

SHERPA

Trafo de Potencia Rectificador

Celda de Feeder

* Disyuntor de Feeder

Equipo de Fallos a Estructura

Infraestructura Comunicaciones

Cables de Feeder (+) Hilo de Trabajo Carril Cables de Feeder (-)

Telemando de SS.EE. o Conexin Remota

119

El Flujograma expuesto pertenece al Servicio Tcnico de Corriente Continua y expresa en lneas generales, tanto el flujo de funcionamiento (flechas en color negro) como el de telecontrol (flechas en color azul). Contiene el equipamiento e instalaciones principales, y debido a la particularidad ya comentada, dispone de un equipo (Disyuntor), que por su idiosincrasia es posible focalizar en l todo el Servicio Tcnico. En el esquema aparece remarcado dentro del flujograma, en lugar de designar a un elemento tan simple como es la lnea area (Hilo de Trabajo) como equipo clave. Cuanto ms detallado sea el Flujograma (interrelaciones, secuencias, equipos, sistemas...) mejor ser el conocimiento, llegando incluso a corregir conceptos errneos del funcionamiento, tanto a nivel general dentro de la Organizacin, como a nivel particular en los Responsables del equipamiento implicado. El Diagrama de Flujo de Estados tiene una aplicacin directa. Permite la construccin de las Matrices de Cambio de Estado de Equipo y de las Matrices de Cambio de Estado de Equipamiento Relacionado. El Flujograma del Servicio Tcnico es un guin de seguimiento que evita interpretar o implementar errneamente, la informacin con la que contamos para el Diseo y Construccin.

120

18 DIAGRAMA DE FLUJO DE LA FASE DE DISEO

Antes de enfrentarnos al ltimo de los captulos de esta segunda parte, es bueno recapitular los pasos a seguir para realizar la fase de Diseo, y que mejor, que mostrarlo en un diagrama. Es ms fcil y comprensible todo aquello que adquirimos en nuestro cerebro grficamente. Seguramente lo de la memoria fotogrfica, tenga algo que ver. Y tambin porque en nuestro mundo, el uso de esquemas, imgenes y cualquier otro elemento representado, ayuda a mejorar y simplificar la comprensin. En diversos captulos de la segunda parte hemos tratado los aspectos necesarios para realizar el diseo de un Servicio Tcnico. Todo comienza con la identificacin de los Equipos Clave, para a continuacin... como lo dijimos con palabras no le demos ms vueltas. A por el esquema:

Metodologas de apoyo (MBF,...)

Diagramas de apoyo

Tablas de Simulacin

Identificacin de los Equipos Clave

Identificacin de las Funcionalidades

Situacin Operativa

Asignacin de Responsabilidades

Identificacin del Equipamiento Implicado

-Generalidades -Definicin -Alcance

Identificacin del Equipamiento Relacionado

Incidencias Operativas (Reglas de clculo)

-Definicin de Estados -Definicin de Matrices -Tipos de Impacto

-Estado del Servicio (Pesos Operativos, Pesos Tcnicos, horarios...) -Disponibilidad del Servicio

Con el esquema, establecer un diagrama de PERT ( Program Evaluation and Review Technique) o Gantt8 con las tareas que se identifiquen en cada una de las subfases establecidas, es casi inmediato. Los diagramas PERT como mtodo permiten identificar las tareas, con especial relevancia al tiempo necesario en completar cada una. La consecuencia lgica es,
8

Herramientas grficas de control y seguimiento para la gestin de los proyectos

Definicin de Indicadores
121

que el conjunto de todas las tareas determina el tiempo total dedicado al proyecto. Para conocer la duracin es necesario identificar el camino crtico , o lo que es lo mismo, el conjunto de tareas que ejecutadas en orden consecutivo y por la dependencia entre ellas, establecen la duracin. Se representa en forma de mallas, mostrando en crculos las tareas y la principal informacin contenida dentro de estos: Nombre de la tarea Duracin de la tarea Fecha de inicio Holgura de la tarea Y por medio de flechas (en el argot se las denomina arcos, cuyo sentido es de izquierda a derecha) las dependencias o relaciones entre las tareas. Los diagramas de Gantt (por su creador Henry Laurence Gantt) muestra el tiempo de dedicacin previsto para cada una de las actividades a lo largo del tiempo del proyecto. El diagrama de Gantt inicialmente no establece las posibles relaciones entre todas las actividades definidas, pero por la posicin en el tiempo que ocupa cada una de ellas, es posible establecer las dependencias. Actualmente dicho mtodo se ha mejorado sustancialmente, de forma que es posible establecer hitos, condiciones, asignacin de recursos,... La ventaja de la representacin Gantt respecto del PERT, es que permite visualizar la carga de trabajo, gracias a que la tarea se representa como una barra, cuyo tamao es su duracin real. Al representarlas de esta forma, indirectamente, queda establecida la duracin del proyecto. Existen ms mtodos, pero lo importante es el diagrama.

122

19 EL CONTROL INCIDENCIAS

DE

LOS

EQUIPOS:

MONITORIZACION

vs.

Conviene recordar que se defina por Equipo Monitorizado:

... aqul que est supervisado remotamente, proporcionando en tiempo real toda la informacin necesaria para el Servicio Tcnico
Y que se defina por Equipo No Monitorizado

... aqul que no tiene ningn tipo de supervisin y por lo tanto, solo conoceremos su Situacin Operativa posteriormente a cualquier Incidencia
Tambin decamos, que un Servicio Tcnico puede estar integrado, tanto por equipos monitorizados, como por equipos no monitorizados, y que solo era necesario establecer los alcances de cada uno de ellos, sabiendo que el impacto en el Estado del Servicio de unos ser en tiempo real y en otros no, y que lo ideal es monitorizar todos los equipos. Este captulo puede llegar a ser inacabable, pues trasladado a la problemtica propia de cada Servicio Tcnico, podremos encontrar multitud de razones a favor y en contra. La principal razn en contra de la monitorizacin es su coste, tanto de implementacin, como posteriormente de mantenimiento. A favor, los factores en los que la monitorizacin aventaja a la no monitorizacin son: 1. Fiabilidad de la informacin: Toda informacin es registrada y procesada en tiempo real. 2. No es necesario la intervencin humana para conocer la Situacin Operativa del equipamiento. El equipo traduce de su situacin y las incidencias tcnicas, el Estado y en los casos que aplique, las Incidencias Operativas activas. Incluso, podra informar de su Estado del Servicio, clculo que se evitara realizar en la aplicacin excepto cuando estuviera en Desconocido ahorrando mucho tiempo de proceso. 3. Agiliza la gestin de las Incidencias. Principalmente, sobre todos aquellos equipos en los que se detecta que no hay servicio cuando se van a usar (mala imagen). Permite la resolucin remota y en los casos donde no sea posible, contar con informacin ms precisa para la intervencin en campo. 123

4. Permite desarrollar mecanismos de control en los Equipos Clave, para detectar los casos en los que el servicio no se presta por causa del equipamiento implicado, evitando la creacin y mantenimiento de las relaciones de equipamiento, tarea muy compleja en la mayora de los Servicios Tcnicos y siempre laboriosa de mantener. Estos mecanismos implcitamente, son mtodos de auditora que ayudan como en el punto tres, a agilizar la gestin de las incidencias e identificar sobre que equipos implicados, es necesario intervenir para la resolucin. 5. Evitar las situaciones no controladas (indefinidas), producidas por sucesos no contemplados por las incidencias (mantenimientos preventivos, operaciones programadas, sustituciones, intervenciones ajenas,...). Este es uno de los principales factores y posiblemente menos considerado. No slo podemos encontrar que en el equipamiento se van a realizar intervenciones consecuencia de las averas que se produzcan, sino que muchos equipos requieren de intervenciones de mantenimiento preventivo y aunque exista un registro para realizarla, no quiere decir que pueda ser usada para valorar su situacin. Obligara a establecer un procedimiento por el cual en el momento de la intervencin, se comunicara al departamento que supervisa el Servicio Tcnico el nuevo estado y bajo demanda cambiarlo en la aplicacin, y una vez finalizada la intervencin, volver a comunicarlo para su puesta en servicio. Si esto es posible hacerlo durante las horas que se oferta el servicio, obliga a disponer de personal que pueda intervenir en la aplicacin, y en el mejor de los casos, que el propio personal que realiza la intervencin disponga de los medios (terminales lgicos, conectividad,...) para comunicar al Gestor de Servicios la nueva situacin del equipo. Cuando finalice la intervencin, volver a comunicar el estado final (En Servicio, Parada por Incidencia Tcnica en el Servicio,...). U operaciones programadas como son las recaudaciones que anulan el servicio. An sabiendo la franja horaria en la que se llevar a cabo la recaudacin, no podremos contemplar la parada del equipo. Del mismo modo, una intervencin ajena como la reposicin de cambio realizada por una empresa de seguridad, se acordar o demandar desde el departamento responsable del Servicio Tcnico, pero ese registro no es posible implementarlo para control de la situacin operativa del equipo, ms si cabe, cuando un equipo obliga a pagar con las monedas justas y es consecuencia de no disponer de cambio. Es un problema de logstica ajeno al registro de incidencias tcnicas. Con la monitorizacin, el equipo puede informar de su situacin por escasa que sea la informacin. Quizs no sea posible distinguir sino disponer de cambio es una consecuencia tcnica o logstica, pero se conoce y eso es fundamental para cumplir el primero de los argumentos, fiabilidad de la informacin.

124

6. Permite dinamizar y automatizar el clculo de los Pesos Operativos. Como hemos visto en los captulos previos, si el Servicio Tcnico lo permite, facilita y reduce el mantenimiento de los datos. Los factores expuestos son ventajas suficientes como para plantearse muy seriamente la monitorizacin de los equipos. Qu argumentos considerar para justificar una decisin a favor o en contra?: 1. Costes. Los costes pueden ser debidos a diversas circunstancias y con alcances concretos. Diferenciaremos fundamentalmente costes de implementar: a. Monitorizacin. Incluye exclusivamente la supervisin. b. La Situacin Operativa. El equipo informa del estado, ya sea consecuencia directa del Servicio Tcnico (incidencias, averas, preventivos,...), como las asociadas al mismo (recaudaciones, recargas, manipulaciones controladas,...). c. Las Incidencias Operativas. El equipo informa de las Incidencias Operativas que apliquen para control del Servicio Tcnico (degradaciones, operatividad,...). d. Deteccin de las Incidencias Tcnicas. Orientacin informativa para el personal de campo que resuelve la avera. e. Intervencin remota. Resolucin de problemas, actualizaciones de software, tareas informativas,... f. Mecanismos de Control en el equipo clave, para detectar todas aquellas situaciones que afectan a la oferta de servicio consecuencia del equipamiento implicado. g. Formacin. 2. Beneficios. Distinguir los beneficios por lo que reportan o minimizan: a. Reduccin de la informacin a cargar inicialmente (Fase de Modelizacin). b. Esfuerzo por dedicacin al mantenimiento de la informacin, principalmente las Relaciones. c. Fiabilidad de la informacin. En aquellos Servicios Tcnicos dnde la ausencia de servicio solo se detecta cuando se interacta, pero es crtico que funcione. Aplica tanto para la intervencin (priorizaciones, recursos, materiales,...) como para el control (mtricas, situaciones,...). d. Control Automtico del equipamiento del Servicio Tcnico. Reduce la intervencin humana. e. Desde el punto de vista del mantenimiento, la creacin de expertos, conocimiento que puede ser vendido a otras organizaciones. 125

3. La relacin Costes-Beneficios. Destacar como principal resultado a considerar de esta relacin, la reduccin de recursos humanos dedicados a supervisar, controlar, mantener,... los Servicios Tcnicos consecuencia de la monitorizacin. 4. Antigedad del equipamiento. Puede ser ms rentable un plan de renovacin que el gasto para monitorizarlo, incluyendo las funcionalidades necesarias para la organizacin. Incluso, posponer la construccin del Servicio Tcnico en espera de la renovacin. 5. Homogeneidad del equipamiento. Monitorizar (integrar) una diversidad considerable de equipos para ofrecer un comportamiento homogneo, puede en algunos casos, llevar a vas muertas sin ningn resultado concluyente, anulando las expectativas y provocando un alto nivel de frustracin. 6. Conocimiento. De qu sirve monitorizar, si nadie puede aprovechar el conocimiento que aporta? Es importante cuantificar en los casos que se decida monitorizar, la preparacin previa del personal y establecer la formacin a impartir. Como se apunt, se convierte en un coste ms a tener en cuenta. Se han expuesto los factores ventajosos de monitorizar y los argumentos para justificarlo, pero sino se realiza, para implementar un Servicio Tcnico ser necesario realizarlo por medio de la informacin registrada, pudiendo tener un coste directo significativamente menor, pero la dedicacin de recursos humanos se convierte en pieza fundamental en la gestin del Servicio Tcnico. Ya sea por la monitorizacin, por el registro de incidencias (control de la informacin en general) o por ambos, es en la fase de Construccin donde adquiere verdadera relevancia esquematizar y conocer los alcances de ambos mtodos (recursos, equipamiento,...) para integrarlos y que proporcionen la informacin necesaria para implementar el Servicio Tcnico.

126

TERCERA PARTE MEJORANDO EL COMIENZO

127

128

NDICE TERCERA PARTE

1 2 3 4 5 6 7 8 PUNTO Y SEGUIDO ........................................................................................ 131 HORARIO, DIARIO, CALENDARIO... QU DECISION TOMAR? ................ 133 AUTOMATIZAR EL CLCULO DEL PESO OPERATIVO? ......................... 141 FACTOR CIENTIFICO ..................................................................................... 147 TABLAS DE CONVERSION ............................................................................ 151 SERVICIOS TECNICOS SI, SERVICIOS TECNICOS NO. .............................. 155 PESOS OPERATIVOS DINAMICOS ............................................................... 161 DESGLOSANDO LA FORMULA ESTADO DEL SERVICIO ....................... 165 8.1 Prestacin de Servicio (PS). ....................................................................... 165 8.2 Factor de Degradacin por Causas Propias (FDCP) ................................ 166 8.3 Factor de Incertidumbre .............................................................................. 167 9 CUNDO UN EQUIPO EST PRESTANDO SERVICIO? ............................ 169

129

130

1 PUNTO Y SEGUIDO
Hasta ahora hemos situado al lector en primer lugar en el tiempo, introducindole como era lgico en el mantenimiento, como actividad de gran peso dentro del conjunto de acciones desarrolladas en torno a los Servicios Tcnicos. Las mtricas y su historia como referencias de gestin y control. A continuacin y sin respiro, en el conocimiento de los Servicios Tcnicos, qu son, su por qu, y qu pretenden ofrecer; y hemos aprovechado para trazar las pautas del proceso para el diseo, estableciendo los pasos mnimos necesarios para materializarlos y qu indicadores son los imprescindibles, mejor dicho, inherentes a todo Servicio Tcnico. As, la segunda parte de este libro ha estado centrada en dos aspectos absolutamente diferenciados: introducir en los Servicios Tcnicos y desarrollar los aspectos a considerar para elaborar la primera de las siete fases establecidas, como el primero de los escalones que nos garanticen el xito, sabiendo los pasos a dar. Hemos hecho valer especficamente entre otros, el recurso de los ejemplos como mtodo de ayuda para una mejor comprensin. Y adems, hemos expuesto otros aspectos que facilitan la visin y completan el conocimiento. Qu pretende mostrar esta tercera parte? Profundizar en algunos aspectos de los Servicios Tcnicos con el nico fin de mejorar nuestro diseo inicial, orientado exclusivamente a la informacin resultante final, los indicadores y no al propio concepto establecido, tanto desde el punto de vista de qu son los Servicios Tcnicos, como los principios del Diseo. Los prximos captulos presentan una importante mejora sobre las expectativas... y seguiremos contando con el valioso aporte de los ejemplos.

131

132

2 HORARIO, DIARIO, CALENDARIO... QU DECISION TOMAR?

Al final del apartado 15.1 de la parte segunda, se ha tratado brevemente uno de los aspectos ms complejos que un Servicio Tcnico puede llegar a tener. La diferente aportacin que cada equipo o instalacin tiene, dependiendo de la hora, da de la semana, mes etc. Y esta situacin puede complicarse ms si la aportacin tambin se ve afectada por cada Nivel de Agregacin. Para ilustrar mejor lo comentado, retomemos la ltima versin del ejemplo analizado del Servicio Tcnico de Mquinas Expendedoras: Distribucin de Pesos Operativos para cuatro Expendedoras. Las Expendedoras 1 y 2 estn en una entrada y las Expendedoras 3 y 4 en otra que desde las 00:00 horas hasta las 06:00 horas se cierra. La distribucin es la siguiente: De 06:00 a 24:00 horas: Expendedora 1 = 30% Expendedora 2 = 30% Expendedora 3 = 20% Expendedora 4 = 20%

De 00:00 a 06:00 horas Expendedora 1 = 50% Expendedora 2 = 50% Expendedora 3 = 0% Expendedora 4 = 0%

Con los dos supuestos planteados: a. Parada por Incidencia Tcnica del Servicio de la Expendedora 1 desde las 20:00 horas del da 1, hasta las 12:00 horas del da 2 b. Parada por Incidencia Tcnica del Servicio de la Expendedora 3 desde las 20:00 horas del da 1, hasta las 12:00 horas del da 2

133

El resultado obtenido es:

Supuesto a Estado del Servicio En Servicio 00:00-06:00 Expendedora 1 Expendedora 2 Expendedora 1 Expendedora 2 Expendedora 3 Expendedora 4 Expendedora 2 Expendedora 3 Expendedora 4 Expendedora 2 Expendedora 2 Expendedora 3 Expendedora 4 Expendedora 1 Expendedora 2 Expendedora 3 Expendedora 4 100 Supuesto b Estado del Servicio En Servicio Expendedora 1 Expendedora 2 Expendedora 1 Expendedora 2 Expendedora 3 Expendedora 4 Expendedora 1 Expendedora 2 Expendedora 4 Expendedora 1 Expendedora 2 Expendedora 1 Expendedora 2 Expendedora 4 Expendedora 1 Expendedora 2 Expendedora 3 Expendedora 4 100

Da 1

06:00-20:00

100

100

20:00-24:00 00:00-06:00 06:00-12:00 Da 2 12:00-24:00

70 50 70

80 100 80

100

100

La Disponibilidad del Servicio durante esos dos das es: - Supuesto a: (100*6+100*14+70*4+50*6+70*6+100*12)/48 = 87,5% - Supuesto b: (100*6+100*14+80*4+100*6+80*6+100*12)/48 = 95,8% Analicemos la situacin con una segunda ubicacin, que a diferencia de la primera, el horario de funcionamiento es desde las 6 a las 24 horas. Para no complicar demasiado el anlisis consideramos solo en la Ubicacin 2, dos Expendedoras con funcionamiento igual al de apertura de la ubicacin, igual Peso Operativo y una nica Incidencia el da 2 de la Expendedora 1 desde las 14:00 hasta las 20:00 horas. La tabla resultante es:
Supuesto a Estado del Servicio En Servicio Expendedora 1 06:00-24:00 100 Expendedora 2 00:60-14:00 Da 2 14:00-20:00 Expendedora 2 Expendedora 1 20:00-24:00 Expendedora 2 50 100 100

Da 1

Expendedora 1 Expendedora 2

134

La Disponibilidad del Servicio durante esos dos das es: (100*24+100*8+50*6+100*4)/48 = 81,25% Tenemos pues la evolucin del Estado del Servicio en cada una de las ubicaciones, con la Disponibilidad resultante de los dos das, pero y si quisiramos saber el Estado y Disponibilidad conjunto resultante? Pues tendremos que dar Peso Operativo a cada Ubicacin durante los dos das. Lo primero, establecer los criterios como se vio en su momento para definir los Pesos Operativos. Suponiendo que la distribucin de los Pesos Operativos en las Expendedoras se hizo en base al nmero de operaciones total por entrada con el siguiente resultado - Expendedoras 1 y 2 (Ubicacin 1) = 60.000 - Expendedoras 3 y 4 (Ubicacin 1) = 40.000 - Expendedoras 1 y 2 (Ubicacin 2) = 25.000 La distribucin de los Pesos Operativos por Ubicacin sera: De 06:00 a 24:00 horas: Ubicacin 1 = 80% Ubicacin 2 = 20% Ubicacin 1 = 100%

De 00:00 a 06:00 horas

135

Ya solo queda calcular el Estado del Servicio conjugando todos los supuestos de ambas ubicaciones.
Supuesto a Ubicacin 2 Estado del Servicio En Servicio 00:00-06:00 100 Supuesto a Ubicacin 1 Estado del Servicio En Servicio Expendedora 1 100 Expendedora 2 Expendedora 1 Expendedora 2 100 Expendedora 3 Expendedora 4 Expendedora 2 Expendedora 3 70 Expendedora 4 Expendedora 2 100 Expendedora 2 Expendedora 3 Expendedora 4 Expendedora 1 Expendedora 2 Expendedora 3 Expendedora 4 Expendedora 1 Expendedora 2 Expendedora 3 Expendedora 5 Expendedora 1 Expendedora 2 Expendedora 3 Expendedora 4 50 70 Supuesto b Ubicacin 1 Estado del Servicio En Servicio Expendedora 1 100 Expendedora 2 Expendedora 1 Expendedora 2 100 Expendedora 3 Expendedora 4 Expendedora 1 Expendedora 2 80 Expendedora 4 Expendedora 1 100 Expendedora 2 Expendedora 1 80 Expendedora 2 Expendedora 4 Expendedora 1 Expendedora 2 100 Expendedora 3 Expendedora 4 Expendedora 1 Expendedora 2 100 Expendedora 3 Expendedora 5 Expendedora 1 Expendedora 2 100 Expendedora 3 Expendedora 4

Da 1

06:00-20:00

Expendedora 1 Expendedora 2

20:00-24:00 Expendedora 1 Expendedora 2 00:00-06:00 06:00-12:00 Expendedora 1 Expendedora 2 12:00-14:00 Da 2 14:00-20:00 Expendedora 2 20:00-24:00 Expendedora 1 Expendedora 2 Expendedora 1 Expendedora 2

100

100

100

50

100

100

100

Con los datos obtenidos, el Estado del Servicio global es:

Ubicacin 2 Ubicacin 1(a) Global (U2+U1a) Ubicacin 1(b) Global (U2+U1b) Estado del Estado del Estado del Estado del Estado del Servicio Servicio Servicio Servicio Servicio 100 100 100 100 100 100 100 100 100 100 70 80 76 84 50 100 50 100 100 70 80 76 84 100 100 100 100 100 50 100 100 90 90 100 100 100 100 100

00:00-06:00 Da 1 06:00-20:00 20:00-24:00 00:00-06:00 06:00-12:00 Da 2 12:00-14:00 14:00-20:00 20:00-24:00

La Disponibilidad del Servicio Global durante los dos das es: Supuesto a:(100*6+100*14+76*4+50*6+76*6+100*2+90*6+100*4)/48=87,5% Supuesto b:(100*6+100*14+84*4+100*6+84*6+100*2+90*6+100*4)/48=95,4% 136

Estos clculos mostrados tienen dos aspectos muy significativos. El primero el mantenimiento, pues por cada nivel de agregacin de servicio que tengamos, es necesario mantener actualizada las tablas de los Pesos Operativos en cada horario, y en segundo lugar para mostrar el Estado del Servicio en un momento determinado, es necesario calcularlo para todos, ya que para cuando en un determinado nivel cambiemos de horario (distintos Pesos Operativos), es necesario tenerlo calculado previamente para mostrarlo. Si el ejemplo mostrado es ilustrativo del volumen de informacin a calcular y mantener (Equipos, Ubicacin y Global), compliqumoslo ms con los siguientes supuestos, que pueden darse conjunta o individualmente, e imaginemos lo que conlleva. a) Las Expendedoras 3 y 4 de la Ubicacin 1 estn situadas cerca de una plaza de toros de manera que, las horas previas al festejo realizan ms operaciones. b) La Ubicacin 2 est junto a un Centro Comercial con gran afluencia de personas los fines de semana. c) La Expendedora 4 se la para durante 3 horas todos los mircoles por pruebas de mejora en el software. d) Los dos ltimos das y los dos primeros de cada mes en la ubicacin 2, se pone en explotacin temporal (servicio) una Expendedora ms. e) El primer domingo de cada mes, la Ubicacin 2 abre 24 horas por exhibiciones nocturnas en el Centro Comercial. Y as podramos considerar muchos ms supuestos. Es cierto que si el clculo de los Pesos Operativos se realiza sobre la base de las operaciones anuales que realizan las Expendedoras, independientemente de que criterio adicional se haya considerado para calcular dichos pesos, estamos distribuyendo la carga a todo el ao y en condiciones normales de explotacin, las mtricas obtenidas representan estas diferencias, pero en el momento que se produce cada uno de los supuestos, el Estado del Servicio no reflejara la realidad si debe ser la percepcin del servicio ofertado. Imaginemos un caso real con multitud de supuestos como puede ser el de una explotacin ferroviaria metropolitana, con diferentes taxonomas de equipo, estaciones, lneas... Slo el mantenimiento de la informacin requiere de una dedicacin completa por parte de un equipo de personas. Qu hacer en estos casos? Est claro que no hay una respuesta nica vlida. Depender del propio diseo del Servicio Tcnico, valorar los niveles de agregacin de servicio a construir que se incluye en cada nivel y el consumo de equipamiento informtico (servidores, memoria, discos...) a adquirir. Analicemos algunos ejemplos y las medidas adoptadas, sabiendo que es sobre un volumen alto de equipos y diferentes niveles. Pero antes de exponer los casos, s hay un aspecto vlido para todos a tener en cuenta, qu se gana o qu se pierde si se incluye o excluye, y el esfuerzo que supone. Si somos capaces de cuantificar dicha relacin, tendremos una medida muy 137

interesante y acertada para justificar la decisin que se adopte. An as, la principal recomendacin a seguir es disear los Servicios Tcnicos con la mayor homogeneidad posible. I.) Un Equipo con horario diferente al resto Si el equipo es el nico en dicha ubicacin, lo ms razonable es no incluir el nivel padre en el conjunto del Servicio Tcnico. SI hay 2 ms equipos, dos son las posibles decisiones a adoptar: 1- No incluirlo dentro del nivel de agregacin de servicio correspondiente, si su horario en funcionamiento es relativamente corto respecto del resto de equipos. 2- Si su horario de funcionamiento es superior al 50%-60% respecto del total, disminuir su Peso Operativo resultante con la finalidad de compensar la ausencia del mismo fuera de su horario de funcionamiento. En esta circunstancia sabemos que en determinados horarios el Estado de Servicio nunca ser del 100%, pero la Disponibilidad del Servicio ser ms real. Si estamos en el primer supuesto, siempre podremos definir un Servicio exclusivamente para dicho equipo, que no repercutir sobre el nivel de agregacin de servicio superior. II.) Nivel de agregacin de servicio con diferente horario del resto de servicios del mismo nivel En este caso, en el que los equipos o niveles inferiores tienen diferente horario porque estn condicionados por el padre, si es necesario, definiremos un Servicio exclusivo para dicho nivel que no tendr repercusin sobre el resto del Servicio. III.) Equipos que funcionan determinado da de la semana o del mes con igual horario al resto La distorsin producida por este equipamiento es muy alta. Considerando el servicio que van a prestar dentro de la totalidad los excluimos. Como en los casos anteriores, siempre podremos definir un Servicio Tcnico exclusivamente para dichos equipos y que no repercutir sobre el Nivel de Agregacin de Servicio superior. Igual consideracin para Niveles de Agregacin de Servicio superior que se prestan determinado da de la semana o del mes. Si el volumen de equipos no fuera considerable, para el caso de equipos que funcionen determinado da de la semana, puede evaluarse la posibilidad de abordar el Servicio Tcnico incluyendo a dichos equipos o niveles. Tendramos una matriz con horarios para cada da de la semana en la que definir el Peso Operativo. Tiene una ventaja muy significativa una matriz semana/horario, permite establecer para cada da horarios de prestacin diferentes. Por ejemplo, podramos tener 138

los horarios de 6 a 12 y de 12 a 24 desde el domingo al jueves y de 0 a 6, de 6 a 12 y de 12 a 24 para el viernes y el sbado. Otro planteamiento muy interesante es, realizar actualizaciones programadas de las tablas conociendo los das de la semana o del mes que determinados equipos prestan servicio. Por ejemplo, si durante el fin de semana hay una serie de equipos adicionales en servicio, se preparan las tablas de Pesos Operativos, de manera que en un determinado momento, la aplicacin actualice el correspondiente nivel dando de alta a estos equipos y modificando los Pesos Operativos. Finalizada esta situacin, se vuelve a cargar la tabla de Pesos Operativos con vigencia durante la semana. Ambas operaciones seran desasistidas y programadas en el sistema para ejecutarse automticamente. De igual manera se hara si son equipos que funcionan durante determinados das del mes o del ao. IV.) Equipos que funcionan determinado da de la semana o del mes con diferente horario al resto Sobran las palabras. Con los medios definidos hasta ahora es prcticamente inabordable. La sensacin producida es que si nos encontramos ante un Servicio Tcnico poco homogneo en cuanto a su prestacin horaria, es difcilmente construible. La relacin directa es que cuantos ms horarios (franjas horarias) tengamos que implementar, la complejidad aumenta fundamentalmente en el momento de establecer los Pesos Operativos y mantenerlos actualizados, ms, si para cada Nivel de Agregacin de Servicio hay que definir horarios. Qu significado tiene entonces el ttulo de este captulo? Obviamente hay un ideal, el calendario. Un calendario es abordable para Servicios Tcnicos muy homogneos, con franjas horarias iguales para cada nivel, y pocas o nulas altas y bajas. El esfuerzo inicial es alto, mayor si el volumen de equipos lo es, pero garantiza un Estado del Servicio muy fiel al ofertado en todo momento. Si la variedad es tan dispar en equipos y niveles, no parece razonable construir ningn Servicio Tcnico sino existe posibilidad de automatizar de algn modo el clculo del Peso Operativo, de manera que sea la propia aplicacin, quin realice dicho proceso y dinmicamente recalcule el Peso Operativo correspondiente dependiendo de la hora, da de la semana y mes. Entre uno y otro extremo, es tarea de los diseadores encontrar el punto de equilibrio entre esfuerzo y el nivel de desglose. Lo ms razonable es a nivel de equipo un horario estable durante toda la semana, aadiendo la posibilidad si fuera necesario, de ampliar o reducir el horario uno o varios das de la semana. Este modelo requiere un gran esfuerzo inicial en el establecimiento de los Pesos Operativos y su carga en el sistema, y un nivel medio de esfuerzo de mantenimiento como consecuencia de las altas, bajas y las variaciones en los factores de ponderacin, por medio de los cuales se han establecido los Pesos Operativos.

139

140

3 AUTOMATIZAR EL CLCULO DEL PESO OPERATIVO?

En los captulos anteriores hemos ido comprobando, no slo la importancia que los Pesos Operativos tienen en el clculo de las mtricas, sino la dificultad que representa su mantenimiento. Aquellas organizaciones con escenarios cambiantes segn la hora o el da de la semana, requerir no slo de un gran esfuerzo inicial el clculo de los Pesos Operativos, sino de un esfuerzo tedioso el mantenimiento de los mismos. La pregunta es obvia, qu se puede hacer para reducir el esfuerzo? Lgicamente, opciones existirn tantas como planteamientos, ni mejor, ni peor; dependern del momento, la situacin, incluso, del propio Servicio Tcnico. Hemos visto que el clculo del Peso Operativo puede ser una tarea compleja, que incluso puede derivar en valoraciones que llevadas a la prctica, nos encontremos con situaciones como esta: Equipo 1, PO= 47,77% Equipo 2, PO=43,83% Equipo 3 PO=8,40%

La reflexin ms inmediata es, la necesidad de llegar al extremo de asignar Pesos Operativos hasta la fraccin decimal consecuencia de los clculos previos realizados. Independientemente de los factores de ponderacin implicados en la determinacin del Peso Operativo, la modelizacin por medio de una hoja de clculo englobando la informacin es cuanto menos que imprescindible. Podemos reducir el esfuerzo a nosotros mismos? Y lo ms importante, desarrollar un mtodo en la herramienta para que el clculo del Peso Operativo sea fcil, intuitivo y de aplicacin inmediata? La respuesta es s. Es posible desarrollar diversos mtodos que faciliten el clculo y el mantenimiento. En este captulo vamos a proporcionar uno de aplicacin genrica muy til cuando el volumen de informacin es elevado. No significa que los pasos previos de extraccin y recopilacin de informacin para la elaboracin del factor de ponderacin se elimine, pero s que agiliza el clculo y sobre todo su mantenimiento. Existe la creencia de que simplificar ayuda. Es verdad. El mtodo va a evitar el uso de decimales que evidentemente no aportan, en la mayora de los casos, precisin en las mtricas obtenidas (Estado del Servicio). Hemos abogado por usar como factor de ponderacin mtodos cientficos como punto de partida, pero con el tiempo, la experiencia, el conocimiento del equipamiento y en dnde prestan su servicio, aunque carentes de base cientfica, llegan a dar a los Pesos Operativos muchas veces mayor precisin que cualquier mtodo basado en la informacin inherente al equipamiento. Generalmente la combinacin de ambos es el factor ms fidedigno para determinar los Pesos Operativos. Pero, cmo ponderar la experiencia? El impacto en el cliente, imagen, repercusin... son calificativos la mayora de las veces con mayor peso especfico que cualquier otro basado en datos. Sea cul sea finalmente el nmero de factores, 141

es relativamente simple establecer una valoracin gradual entre los elementos del mismo nivel y en base a la misma, determinar el Peso Operativo. Consiste en establecer un mtodo que podamos implementar en la herramienta, que facilite cualquier tarea de mantenimiento, evitando en situaciones con un volumen de equipos elevado, que si se modifica el Peso Operativo a cualquiera, tengamos que intervenir manualmente en el cambio de los Pesos Operativos del resto. Supongamos un Servicio Tcnico con 5 equipos. Como factor de ponderacin inicial usamos el nmero de ventas que realiza cada uno. Equipo 1 = 6500 operaciones de venta. Equipo 2 = 3200 operaciones de venta. Equipo 3 = 1700 operaciones de venta. Equipo 4 = 6200 operaciones de venta. Equipo 5 = 300 operaciones de venta.

Adicionalmente sabemos que el Equipo 2 est situado en una localizacin con mucha repercusin de imagen y el Equipo 4, cuando no est en funcionamiento, el nmero de quejas es elevado. Con las ventas el reparto porcentual queda: Equipo 1 , PO=36,31% Equipo 2 , PO=17,88% Equipo 3 , PO=9,5% Equipo 4 , PO=34,64% Equipo 5 , PO=1,68%

Para aplicar los dos factores de ponderacin adicionales, incrementamos el Peso Operativo resultante del Equipo 2 y del Equipo 4 en un porcentaje que consideremos, por ejemplo: Equipo 1 , PO=36,31% Equipo 2 , PO=30% Equipo 3 , PO=9,5% Equipo 4 , PO=50% Equipo 5 , PO=1,68%

El problema es evidente, el incremento realizado a estos dos Equipos, nos obliga a reducir la diferencia de porcentaje incrementado disminuyendo los restantes, trabajo manual costoso que puede llevar a errores, y que como hemos comentado, en la herramienta deberemos variarlos a mano. En lugar de sto, segn las ventas damos un grado (valor) asociado entre 1 y 10: Equipo 1, G=4 142

Equipo 2, G=2 Equipo 3, G=1 Equipo 4, G=4 Equipo 5, G=1

Como queremos que el Equipo 2 y 4 tengan una consideracin adicional por las causas explicadas. Incrementamos sus grados en la cantidad estipulada, obteniendo: Equipo 1, G=4 Equipo 2, G=4 Equipo 3, G=1 Equipo 4, G=6 Equipo 5, G=1

La suma total de los grados es 16. Pues en base a los grados asociados y al total, volvemos a calcular sus Pesos Operativos aplicando redondeo, pues con la graduacin, lo que realmente estamos realizando, es escalar los equipos por su repercusin en la oferta de servicio en base a los factores de ponderacin: Equipo 1, PO=25% Equipo 2, PO=25% Equipo 3, PO=6% Equipo 4, PO=38% Equipo 5, PO=6%

La primera ventaja es obvia. Las cifras obtenidas son valores redondos. La segunda y ms importante es, que ante el alta o baja de un equipo, o la modificacin del porcentaje, el reclculo y modificacin del Peso Operativo se simplifica enormemente; y esto vale para los equipos y los diferentes Niveles de Agregacin de Servicio que constituyen el Servicio Tcnico. Veamos algunos ejemplos: A. Un nuevo equipo Con datos de ventas conocidas, asociamos el grado correspondiente, por ejemplo 3. El total es 19 y los Pesos Operativos obtenidos son: Equipo 1, PO=21% Equipo 2, PO=21% Equipo 3, PO=5% Equipo 4, PO=32% Equipo 5, PO=5% Equipo 6, PO=16% 143

B. Baja de equipo De los 5 equipos iniciales, se da de baja definitiva el Equipo 3 y no se le sustituye por ninguno. Los Pesos Operativos resultantes son: Equipo 1, PO=27% Equipo 2, PO=27% Equipo 4, PO=40% Equipo 5, PO=6%

C. Modificacin del factor de ponderacin o el grado El Equipo 5 por ventas pasa de 1 a 3. Los Pesos Operativos resultantes son: Equipo 1, PO=22% Equipo 2, PO=22% Equipo 3, PO=6% Equipo 4, PO=33% Equipo 5, PO=17%

Si est automatizado en la aplicacin el clculo del Peso Operativo en funcin del grado, en el momento de dar de alta un equipo y asociarle su grado, darle de baja o modificar el grado de los existentes, automticamente el resto de los Pesos Operativos de los equipos del mismo nivel se actualizan y esta funcionalidad puede implementarse para cualquiera de los Niveles de Agregacin de Servicio. La finalidad es tener una magnitud que nos indique el Estado del Servicio, no una cifra exacta del Estado del Servicio. Comparemos la misma situacin con la distribucin de Pesos Operativos: Y la distribucin: Equipo 1, PO=25% Equipo 2, PO=25% Equipo 3, PO=6% Equipo 4, PO=38% Equipo 5, PO=6% 144 Equipo 1, PO=36,31% Equipo 2, PO=30% Equipo 3, PO=9,5% Equipo 4, PO=50% Equipo 5, PO=1,68%

Y el Equipo 5 no funciona. Con la primera relacin el Estado del Servicio global es 98,32%, con la segunda 94%. Da igual el valor obtenido. Lo importante es saber que ambas cifras representan lo mismo, en este caso, que el Estado del Servicio es muy bueno. Si en el clculo del redondeo, por la circunstancia que fuere el sumatorio no es 100, implementaremos la posibilidad de modificar directamente cualquiera de los Pesos Operativos sin que esta modificacin altere la graduacin establecida. Toda la poltica de horarios tal y como la hemos visto puede aplicarse. Es ms, simplifica el mantenimiento de la misma y el equipo que no preste servicio en un determinado horario su grado es 0 no se le da de alta. Una reflexin final. Sea cual sea la forma de obtener el Peso Operativo y como se aplica para el clculo del Estado del Servicio, podemos decir que estamos hablando de Pesos Operativos Estticos, pero podemos implementar Pesos Operativos dinmicos?

145

146

4 FACTOR CIENTIFICO
En el captulo anterior hemos expuesto un mtodo de clculo ms cmodo para asignar los Pesos Operativos, pues por medio de una gradacin y en funcin del sumatorio de los grados, los repartimos proporcionalmente. Puede ser exagerado reiterar otra vez que los Servicios Tcnicos estn orientados hacia el cliente y por ello, hemos considerado como factores cientficos de clculo, operaciones en cajeros, usuarios en elementos de transporte, en definitiva, un factor de ponderacin en el cul pueda verse reflejado la repercusin al usuario, ya que la base de la ponderacin es la interaccin del usuario con el equipo, pero, es posible encontrar otros parmetros de ponderacin dnde el usuario no est reflejado, en principio? Y, es til? La respuesta est abierta a las necesidades lgicas de cada organizacin, pero puede ser muy interesante implementar en la aplicacin, diferentes Estados de Servicio en funcin de ponderaciones que nacen de diferentes criterios y adems, que los calcule automticamente verdaderamente til. Partamos del mismo ejemplo que sirvi para la exposicin en el captulo precedente. Supongamos un Servicio Tcnico con 5 equipos. Como factor de ponderacin inicial usamos el nmero de ventas que realiza cada uno. Equipo 1 = 6500 operaciones de venta. Equipo 2 = 3200 operaciones de venta. Equipo 3 = 1700 operaciones de venta. Equipo 4 = 6200 operaciones de venta. Equipo 5 = 300 operaciones de venta.

Cada operacin significa un usuario que ha hecho uso del equipo y por lo tanto, parece lgico pensar que el Equipo 1 con 6500 operaciones es el que ms repercute hacia el usuario. Bien, eso no significa que el que ms operaciones realiza sea el que mayor recaudacin hace, ir en funcin del producto obtenido. Para nuestros equipos del ejemplo, las recaudaciones han sido: Equipo 1 = 1250 euros. Equipo 2 = 450 euros. Equipo 3 = 1000 euros. Equipo 4 = 1600 euros. Equipo 5 = 750 euros.

En este caso, el equipo que ms penaliza cuando no est funcionando es el Equipo 4. 147

Mientras que con el primer factor de ponderacin, el reparto de los Pesos Operativos redondeando es: Equipo 1 , PO=36% Equipo 2 , PO=18% Equipo 3 , PO=9% Equipo 4 , PO=35% Equipo 5 , PO=2%

Con el segundo factor, el reparto de los Pesos Operativos es: Equipo 1 , PO=25% Equipo 2 , PO=9% Equipo 3 , PO=20% Equipo 4 , PO=31% Equipo 5 , PO=15%

Si los comparamos, observamos por ejemplo, que ante la parada de cualquiera de ellos, el indicador Estado del Servicio no va a ser igual, lo que puede inducir a pensar que no se est estableciendo la valoracin ms adecuada en funcin de la informacin que se desea obtener, porque, cul de los dos factores es ms preciso para generar el indicador Estado del Servicio? Un lector avezado habr apreciado, que el primer factor de ponderacin est claramente orientado al Servicio Tcnico de mquinas expendedoras (usuario final), mientras que el segundo sera ms propio de un Servicio Tcnico contable sobre el mismo tipo de equipamiento. Por consiguiente, parece que no se prestan como vlidos para la comparativa, por medio de la cual trasladar al usuario final el Estado del Servicio que se le est ofertando. Pero podramos partir de la suposicin que, ms penalizamos al usuario final, cuanto mayor es el coste del producto que desea obtener, y en este caso, el segundo factor estar ms en consonancia con la orientacin del Servicio Tcnico de mquinas expendedoras. Cuesta entenderlo, quizs, por no ser muy tangible. A ver si con el siguiente supuesto, es posible materializarlo. En un aeropuerto existen multitud de elementos mecanizados dedicados al desplazamiento de los viajeros, convirtindose en algunos aeropuertos de gran demanda en un batalln. Estamos hablando de las Escaleras Mecnicas y los Ascensores. Todos ellos permiten el desplazamiento del viajero evitando tener que subir y bajar escaleras fijas, accin que con maletas se convierte en un tormento -incluso sin ellas-, debido a las diferencias de altura a salvar. Todos los elementos del aeropuerto tienen precisamente ese aspecto en comn, la altura, ms conocido tcnicamente como cota. Supongamos que sta vara entre los 4 metros de las Escaleras Mecnicas ms cortas, a los 25 metros del Ascensor con mayor recorrido.

148

Segn el Servicio Tcnico de Transporte Vertical para el aeropuerto, el primer factor de ponderacin para determinar el Peso Operativo de cada elemento sera, el nmero de viajeros que hacen uso de cada equipo, pero esta valoracin puede proporcionar casusticas tan curiosas como que los elementos con mayor demanda, sean los de menor recorrido. Cuando estos equipos estn fuera de servicio, penalizan el indicador del Estado de Servicio ostensiblemente, pero el malestar que pueden ocasionar es nimio comparado con un equipo parado de cota muy superior, aunque el nmero de usuarios sea menor. Ponderar por la cota significa que, el indicador Estado del Servicio obtenido est reflejando el porcentaje de trayecto que el usuario puede hacer por medios mecanizados. El resto hasta el 100%, es la parte que el usuario debe hacer por sus propios medios, es decir, a pie, independientemente de que el trayecto sea de subida o bajada. Haciendo un smil (otra vez mi aficin por la montaa), dispongo de los medios para subir al Everest mecanizadamente y el porcentaje perdido, corresponder a la parte que tengo que hacer por mis propios medios, a pinrel. Aplicando la ponderacin para el clculo del Peso Operativo por la cota en lugar de por el volumen de usuarios, estamos evaluando el Servicio Tcnico no por los clientes afectados, sino por cuanto afecto al cliente en su desplazamiento. Cuanto menor sea el valor del Estado del Servicio, mayor ser el recorrido realizado a pie. Y si implementamos los dos? Pues que dependiendo del resultado, nos indican el porcentaje de usuarios afectados y que porcentaje de su trayecto no est mecanizado. Combinados, el resultado ptimo es aqul que ambos Estados de Servicio estn prximos al 100%, pues manifiestan que el nmero de clientes afectados es reducido y el trayecto a realizar por sus propios medios mnimo. Si por el contrario, ambos resultados fueran bajos, muchos usuarios estaran siendo afectados por un elevado volumen de equipos parados en las horas de ms demanda, o pocos equipos, pero de mayor cota,... depender del anlisis de los factores que han desencadenado unos valores tan bajos en ambos indicadores. Implementar uno o ms indicadores Estado del Servicio depender , no slo de la orientacin que sea necesario dar al Servicio Tcnico, sino de las herramientas de gestin tiles (SLAs, KPIs,...) para orientar las actividades. Para cada actividad, es factible haber desarrollado una prioridad de atencin particular, que no tiene porque ser la misma para todas las generadas en rededor al equipamiento. Puede incluso que con el tiempo se modifique el factor de ponderacin usado. Lo que si puede ser complicado es encontrar en los equipos e instalaciones, factores de ponderacin comunes como sucede en el ejemplo de los elementos de Transporte Vertical; pero si es muy recomendable como ejercicio inicial, disponer de varios factores de ponderacin para posteriormente, decidir cul o cules son los que mejor reflejan el servicio. No olvidemos que cualquier indicador implementado, en este caso el Estado del Servicio, tiene que ser til como herramienta de gestin. Quizs no sea tan difcil hallarlo. Y si para las mquinas expendedoras en lugar de la recaudacin, el factor de ponderacin es la diversidad de producto? Un equipo con solo dos tipos de producto, ante la ausencia de uno de ellos, reduce significativamente las posibilidades frente a otro con cinco tipos diferentes. En este 149

caso sera una ponderacin a la inversa, es decir, cuanto menos tipos de bebidas despache, el Peso Operativo aplicado ser mayor que otra mquina de bebidas que disponga de mayor variedad. Claro, lo que si es discutible es llamar Estado del Servicio, a un indicador ponderado por la cota, o no? Pues si la primera acepcin de estado segn la RAE1 es:

Situacin en que se encuentra alguien o algo, y en especial cada uno de sus sucesivos modos de ser o estar
Quizs no sea tan descabellado definir como Estado del Servicio, al indicador ponderado por la cota o cualquier otro factor.

Real Academia Espaola

150

5 TABLAS DE CONVERSION

Mientras la aguja del tacmetro no llegue a la zona roja, el rgimen de revoluciones es el correcto
En el captulo 15.1 de la segunda parte se plante, que en algunas circunstancias la percepcin del servicio no es lineal en funcin del Peso Operativo, y el Estado del Servicio de cada equipo dependa de si haba ms o menos equipos funcionando. Pueden existir diferentes criterios de dinamizacin. Uno de ellos ha sido tratado exhaustivamente y contemplado en nuestro sistema con el establecimiento de horarios, en donde los equipos pueden tener diferente Peso Operativo en funcin del rango horario de funcionamiento, demanda... Otra opcin para establecer la dinamizacin depende del volumen de equipos prestando servicio en un instante dado, o mejor dicho, lo que sucede es que el Estado de Servicio no es el sumatorio de los Pesos Operativos por el Estado de Servicio de los equipos. Como hemos comentado algunas veces, lo importante no es la cifra obtenida, sino lo que interpretamos por medio de la misma. Sera convertir el valor obtenido del Estado del Servicio en otro que fuera en funcin del volumen. El principal obstculo que nos vamos a encontrar es como decir al nivel correspondiente que criterio aplicar. La aplicacin (Gestor de Servicios) es nica para todos los Servicios Tcnicos que construyamos y por consiguiente, la formulacin implementada es comn para el clculo de las mtricas de cada uno de ellos. Para todos aquellos no familiarizados con la programacin informtica, comentar que realmente no es complejo hacerlo. Ms bien, es una cuestin de control a la hora de programarlo, establecindolo como opcin en cualquier Nivel de Agregacin, cual de los diferentes mtodos de clculo aplicar. En el captulo 15.1 de la parte segunda, expusimos el siguiente ejemplo: Expendedora 1, PO=25% Expendedora 2, PO=25% Expendedora 3, PO=25% Expendedora 4, PO=25%

Pues dependiendo de los Equipos que no estn funcionando, es decir, que no prestan servicio: 1 Expendedora, ES = 75%, lo convertimos en ES = 85% 2 Expendedoras, ES = 50% se mantiene 3 Expendedoras, ES = 25%, lo convertimos en ES = 10% 4 Expendedoras, ES = 0% se mantiene 151

Es como si los Pesos Operativos de cada equipo variaran en funcin de los equipos prestando servicio. Si las Expendedoras tuvieran funcionalidades (Pesos Tcnicos) ya no podramos realizar conversiones inmediatas, es ms, si esta situacin se da en el Servicio Tcnico de Mquinas Expendedoras, teniendo en cada ubicacin un nmero de equipos diferente, la parametrizacin y mantenimiento (situaciones de temporalidad, altas, bajas ...) dificultan tal opcin hacindolo prcticamente inviable. Por ello, es necesario establecer un nico criterio que aglutine todas las posibles casusticas de medicin que surjan. Partiendo del ejemplo de los equipos que no prestan servicio, podemos establecer el siguiente criterio de conversin: Si ES > 75%, ES = 85% Si 50% < ES <= 75%, ES = 50% Si 0% < ES <= 50%, ES = 10% SI ES = 0%, ES = 0%

Este mtodo de clculo nos permite formularlo para equipos con y sin Pesos Tcnicos, y por lo tanto, es una opcin estndar ms de nuestro sistema al igual que las matrices y otros recursos definidos. Cada Servicio Tcnico tendra asociado su propia Tabla de Conversin. Aunque en principio las Tablas de Conversin tiene sentido aplicarlas en Servicios Tcnicos con equipamiento homogneo, del anlisis y el comportamiento de los mismos podemos encontrar que, aunque exista heterogeneidad, como lo que se pretende tener es un valor que nos de la percepcin del servicio que se est ofertando, podremos aplicar dichas Tablas de Conversin. Supongamos que en un Centro Comercial tenemos diferentes Mquinas Expendedoras (alimentacin, bebidas, regalos, parking ...), aunque las funcionalidades y el fin de cada una es diferente, en lugar de mostrar el Estado del Servicio por medio de los Pesos Operativos directamente, puede interesar aplicar las Tablas de Conversin. Sinos fijamos, al aplicar las Tablas de Conversin lo que realmente estamos haciendo, es establecer un rango que nos indica como est la oferta de servicio. Analicemos el siguiente ejemplo: Si ES > 75%, ES = color verde Si 50% < ES <= 75%, ES = color naranja Si 0% < ES <= 50%, ES = color rojo SI ES = 0%, ES = color negro

Es un semforo que nos indica la situacin sin importar el valor exacto del Estado del Servicio, e igualmente vlido para calcular la Disponibilidad del Servicio. Las Tablas de Conversin no son slo un mtodo de clculo diferente de las mtricas, sino otra forma de presentarlas y que para muchos Servicios Tcnicos, 152

simplifican los mecanismos de control y supervisin. La tabla de conversin nos proporciona un nuevo indicador que dependiendo del proveedor y/o el cliente, formar parte del conjunto de mtricas definidas en el Servicio Tcnico. Al indicador proporcionado consecuencia de aplicar una Tabla de Conversin le llamaremos Nivel de Servicio Ofertado. Cuando apliquemos este indicador es mejor representarlo evitando cifra porcentual asociada. Si la escala de colores no es posible implementarla, podemos sugerir una nueva conversin. Si ES > 80%, NSO = 5 Si 60% < ES <= 80%, NSO = 4 Si 40% < ES <= 60%, NSO = 3 Si 20% < ES <= 40%, NSO = 2 Si 0% < ES <= 20%, NSO = 1 SI ES = 0%, NSO = 0

Los rangos forman parte de la negociacin a realizar con el cliente.

153

154

6 SERVICIOS TECNICOS SI, SERVICIOS TECNICOS NO.

La respuesta a si implementar o no un Servicio Tcnico, es rotundamente s. Dnde reside la dificultad? Pues la dificultad no reside tanto en el esfuerzo de lo conocido, por muy laborioso que pueda resultar, como en las caractersticas del Servicio Tcnico, y ms concretamente en el equipo clave. Los Servicios Tcnicos hasta ahora planteados como ejemplos tienen una caracterstica comn, la oferta del servicio es realizada por un equipo o instalacin, y la participacin humana es insignificante, centrada principalmente en dar continuidad al servicio (mantenimiento, reposicin, recarga...), pero no son parte implicada directamente en la oferta. Conviene recordar la definicin:

CONJUNTO DE ACTIVIDADES RELACIONADAS ENTRE S, SOPORTADAS POR EQUIPOS E INSTALACIONES, QUE SATISFACEN UNA NECESIDAD O MEJORAN LAS FUNCIONALIDADES PRESTADAS
Pero no significa que no podamos tener Servicios Tcnicos en donde el factor humano pueda ser clave en la oferta. Comparemos dos Servicios, Surtidores -Autoservicio- de Combustible (Gasolinera) vs. Lneas de Caja (Hipermercado). Caractersticas de los Surtidores: 1. Durante el horario de apertura al pblico, estn todos en funcionamiento. 2. El Peso Operativo de cada surtidor ser equitativo entre todos. 3. Existe degradacin de servicio (Pesos Tcnicos), ya que pueden despachar cuatro tipos diferentes de combustible. 4. El factor humano no est directamente implicado en la oferta de servicio. Caractersticas de las Lneas de Caja: 1. Las lneas de caja en funcionamiento dependen del personal disponible, del da de la semana y de la hora. 2. El factor humano est directamente implicado en la oferta de servicio. 3. Ante la rotura de uno de los terminales de venta, cinta,... es posible cambiar a la persona a otra y continuar prestando servicio. 4. Nunca estn todas las Lneas de Caja prestando servicio simultneamente. 5. Dificultad en establecer los Pesos Operativos. 155

6. No existen Incidencias Operativas. En el caso de los Surtidores es relativamente fcil disear el Servicio Tcnico, ya que con toda probabilidad, dispondrn de mecanismos automatizados para informar de cuando no es posible suministrar algn tipo determinado de combustible y de las incidencias que se produzcan. Puede que diferenciar, si la falta de suministro de un determinado tipo de combustible, es consecuencia de una avera o por falta de reparto sea ms o menos complejo, e incluso, no haya posibilidad de saberlo, pero detectar la imposibilidad de servir un determinado producto, seguro. Con los Surtidores nos encontramos ante un Servicio Tcnico ms, cmo los que han sido comentados como ejemplos y es posible, que hasta ms sencillo. Por contra, el Servicio Tcnico a disear con las Lneas de Caja se manifiesta como todo un reto. Para ello vamos a realizar un anlisis ms profundo, para tener argumentos que nos permitan construirlo e implementarlo con garantas de xito. Una vez analizada la informacin de las ventas realizadas, llegamos a la siguiente situacin: a. Desde el lunes al viernes entre las 10 y las 15 horas, el nmero de lneas de caja necesario es 5. b. De lunes a jueves desde las 15 hasta las 22 horas, el nmero de lneas de caja necesario es 10. c. Los viernes desde las 15 hasta las 22 horas, el nmero de lneas de caja necesario es 15. d. Los sbados desde las 10 hasta las 12 horas, el nmero de lneas de caja necesario es 10. e. Los sbados desde las 12 hasta las 15 horas, el nmero de lneas de caja necesario es 15. f. Los sbados desde las 15 hasta las 18 horas, el nmero de lneas de caja necesario es 10. g. Los sbados desde las 18 hasta las 22 horas, el nmero de lneas de caja necesario es 20. h. No se consideran los festivos.

156

Planteado en forma de tabla tenemos:

Lunes 10 11 12 13 14 15 16 17 18 19 20 21 22 5 5 5 5 5 10 10 10 10 10 10 10 10

Martes 5 5 5 5 5 10 10 10 10 10 10 10 10

Mircoles 5 5 5 5 5 10 10 10 10 10 10 10 10

Jueves 5 5 5 5 5 10 10 10 10 10 10 10 10

Viernes 5 5 5 5 5 15 15 15 15 15 15 15 15

Sbado 10 10 15 15 15 10 10 10 20 20 20 20 20

Verlo matricialmente nos permite establecer dos cuestiones importantes: Los rangos horarios a definir dependiendo del da de la semana. El nmero activo en cada horario de lneas de caja necesarias. Porque, qu es realmente lo que necesitamos tener funcionando? Comparndolo con los Surtidores o cualquier otro Servicio Tcnico, cuando se oferta un servicio siempre depende del volumen de Equipos Clave la oferta del mismo. Si en una gasolinera tuviramos 6 Surtidores y 2 de reserva, lo que sabemos es el nmero mnimo necesario a considerar para que el Estado del Servicio sea del 100%. Cmo se implementara es otra cuestin. Pero de la misma manera que en el Servicio Tcnico Corriente Continua (ver parte segunda) se planteaba la nueva Situacin Operativa En Reserva, para contemplar al Disyuntor de Reserva y como participa en el clculo del Estado del Servicio, se puede de forma similar plantear para el Servicio Tcnico de los Surtidores. El 100% del Estado del Servicio Percibido si hay 6 Surtidores simultneamente funcionando. Para el Estado del Servicio Prestado, 100% si hay 6 Surtidores funcionando (igual que para el Estado de Servicio Percibido) 100% si hay 6 Surtidores funcionando y 2 de reserva. Depender de las condiciones de diseo. En el caso de las lneas de caja este planteamiento se simplifica, pues parece lo ms lgico que el Estado del Servicio (Prestado y Percibido) dependa exclusivamente de las lneas de caja necesarias en cada horario y las que estn realmente activas, siendo ste el factor principal a tener en cuenta; que no es la caja 3, 5, 7, 12,.... y as hasta las necesarias en cada horario, sino que la suma de las activas tiene que ser las que por horario se han determinado. Lo que en principio pareca una desventaja, se convierte en una ventaja frente a un Servicio Tcnico 157

tpico como el de los Surtidores, donde el Estado del Servicio depende de un Dispensador con nombre y apellidos. Peor es el caso de un Servicio Tcnico como el Transporte Vertical, donde el servicio depende exclusivamente de un elemento sin posibilidad de sustitucin. Si son las 18:13 horas de martes y solo tenemos 8 cajas activas de las 10 necesarias, el Estado del Servicio es del 80%. Cuntos rangos horarios son necesarios? Siete: 1. De 10 a 15 LMXJV = 5 Lneas de Caja. 2. De 15 a 22 LMXJ = 10 Lneas de Caja. 3. De 15 a 22 V = 15 Lneas de Caja. 4. De 10 a 12 S = 10 Lneas de Caja. 5. De 12 a 15 S = 15 Lneas de Caja. 6. De 15 a 18 S = 10 Lneas de Caja. 7. De 18 a 22 S = 20 Lneas de Caja. Y lo que hay que controlar es el nmero de Lneas de Caja necesarios en cada momento segn se ha establecido, desarrollo realmente fcil tanto si se automatiza monitorizando los equipos, como si es por medio de un registro. Es un Servicio Tcnico sin Pesos Operativos? Pues depende de cmo se quiera plantear. Si es en base al nmero de equipos necesarios, cada uno de ellos tendr un Peso Operativo. Si es desde el punto de vista del Estado del Servicio, este es el cociente en formato porcentual entre el nmero de Lneas de Caja activas y el nmero de Lneas de Caja necesarias. Intrnsecamente siguen existiendo los Pesos Operativos. Pero no parece esto lo ms importante, porque Cuntas veces el Estado del Servicio ser menor del 100%? Dado el volumen de equipamiento y siempre y cuando no cambie la situacin operativa a mantener en cada horario, un Estado del Servicio menor del 100% estar condicionado casi exclusivamente a la falta de personal. Interesa seguir montando el Servicio Tcnico? Indudablemente; y debemos enfocarlo para medir el Estado del Servicio Percibido o, se podra plantear de otra manera, algo as como Calidad del Estado del Servicio Prestado. Hasta ahora, cuando se han planteado las mtricas de Estado del Servicio Percibido, nos hemos centrado fundamentalmente en si la oferta se mantiene desde el punto de vista operativo. Si en una lnea de transporte urbano es necesario tener a una determinada hora 6 autobuses, si se nos rompe uno y tenemos de reserva lo sacaremos, con lo cual el servicio de cara al viajero se mantiene en el 100% de la oferta inicial, pero desde el punto de vista del explotador la prestacin no es igual, porque en caso de otra avera ya no se dispone de vehculo para sustituir. La prestacin no es igual y por lo tanto menor del 100%. Pero manteniendo la oferta desde el punto de vista operativo, el servicio puede que se vea afectado por otros 158

matices no considerados, como por ejemplo, incumplimiento del intervalo. En esta situacin, el Estado del Servicio Percibido se mantiene? Si pudiramos sondear a los clientes, stos seguramente contestaran que no se est ofertando un buen servicio. Si tenemos la gasolinera y en cada Surtidor tres coches esperando, aunque el Estado del Servicio sea del 100%, seguro que el Estado del Servicio Percibido considerado ms all de la oferta, no. Es posible plantear entonces Estado del Servicio Percibido como Calidad del Estado del Servicio Prestado? Como en todo lo que venimos planteando, depende del Servicio Tcnico, la aplicacin y el alcance que se quiera establecer (Acuerdos de Nivel de Servicio, garantas, criterios de mantenimiento, inversiones...). Vimos en los captulos iniciales Servicios Tcnicos en donde solo se percibe 0% 100%. No parece lo ms lgico que la medida de Calidad venga determinada por el Estado del Servicio Percibido. Incluso puede que no sea necesario implementarla. Sin embargo, en el Servicio Tcnico que nos sirve de base de este captulo de las Lneas de Caja, no slo est justificado, sino que realmente la mtrica que nos dar valor a la implementacin, ser aquella que tenga en consideracin la Calidad. Una de las principales diferencias de este Servicio Tcnico respecto del resto reside en el factor humano, pero si lo comparamos con otros Servicios Tcnicos como el de los Surtidores, Expendedoras... poseen una cualidad idntica, el tiempo de cada operacin, siendo uno de los factores objetivos que pueden incidir en la depreciacin del servicio percibido. El tiempo que cada cajero tarda en atender a cada cliente, depender de sus conocimientos en los productos, pericia, conocimiento del terminal... y ante una situacin de colapso, dispondr de recursos que puedan minimizarlo. Medir factores propios de las personas para valorar la Calidad, se muestra a da de hoy como tarea inviable. Pero imaginemos que del estudio inicial del Servicio Tcnico, obtuvimos adems la siguiente relacin respecto de los tiempos medios de atencin por operacin: a. Rango de Tiempo desde 1 producto hasta 10, de 1 a 20 segundos. b. Rango de Tiempo desde 11 productos hasta 20, de 21 a 50 segundos. c. Rango de Tiempo desde 21 productos hasta 30, de 51 a 80 segundos. d. Rango de Tiempo desde 31 productos en adelante, 170 segundos. Y baremamos en funcin del incumplimiento, es decir, asignamos un Peso Tcnico como si de una Incidencia Operativa se tratara. a. 3%. b. 5%. c. 9%. d. 15%.

159

La Incidencia Operativa se mantiene activa hasta finalizar la siguiente operacin, que la soluciona, mantiene o aparece una nueva Incidencia Operativa, es decir, un nuevo incumplimiento diferente del anterior. Como las Incidencias Operativas terminan por solucionarse, las Incidencias Operativas de este Servicio Tcnico se solucionan si entre cliente y cliente trascurren ms de 15 segundos, que es el tiempo baremado del anlisis inicial que en situaciones de aglomeracin se tarda en atender. En tiempo real sabemos, el tiempo que dura cada operacin dependiendo del nmero de productos y el tiempo que trascurre entre clientes. Con ambos tiempos, estamos en disposicin de calcular el Estado del Servicio Percibido. Nos queda una pregunta que hacernos, es correcto plantear la Calidad del Estado del Servicio Prestado as? Como asiduos clientes del hipermercado conocemos intrnsecamente, lo que tardan en despacharnos dependiendo del volumen de productos adquiridos y como consecuencia, aunque nos desespere estar en la cola, sabemos si el tiempo dedicado a cada cliente es ms o menos el adecuado. Con la exposicin realizada y partiendo de datos ficticios hemos pretendido, no slo justificar que prcticamente siempre es posible implementar un Servicio Tcnico, sino adems, que implementar algo tan subjetivo como la Calidad es posible. Hemos asociado la Calidad del Estado del Servicio Prestado con el Estado del Servicio Percibido, pero realmente se debera de llamar:

Calidad del Servicio Ofertado

pues realmente hemos conjugado por un lado el equipamiento y por otro las personas, y por mantener los criterios de diseo planteados en los indicadores, este nuevo indicador propuesto ser distinto del Estado del Servicio Percibido. Y hemos ido en nuestra contra al montar un Servicio Tcnico de Lneas de Caja. Al comienzo de la exposicin del libro, cuando plantebamos la definicin de Servicio Tcnico, decamos como premisa que la actividad humana no se valoraba... pero en estos Servicios Tcnicos el humano es casi parte del equipo. Su operatividad es finita y limitada. Consecuencia de ello es que ya existen muchos establecimientos donde se ha eliminado la figura del cajero...

160

7 PESOS OPERATIVOS DINAMICOS

Hace tres captulos dejamos una interrogante sin contestar, y en el captulo anterior se plante una situacin nueva respecto a la valoracin del equipamiento. Esta situacin aporta una nueva estrategia a los Servicios Tcnicos, la asignacin de Pesos Operativos dinmicos a los Equipos Clave. El Servicio Tcnico inicialmente no posea Incidencias Operativas y por lo tanto ausencia de Pesos Tcnicos, pero trasladada a un Servicio Tcnico que posea degradacin es posible plantearla de la misma manera, pues dependiendo del horario cada equipo tiene un Peso Operativo determinado y la degradacin en cada equipo es un Peso Tcnico concreto invariable en el tiempo y dependiente del Catlogo (modelo). En estos Servicios Tcnicos, casi se hace imperiosa la necesidad de monitorizar el equipamiento para que sea la aplicacin la que segn los equipos necesarios, asigne los Pesos Operativos y degrade en funcin de los equipos parados (averiados) y las Incidencias Operativas activas. En el captulo de Tablas de Conversin, se habl de la dinamizacin de los Pesos Operativos. Se plante desde el punto de vista de los horarios o desde el punto de vista del volumen de equipos en funcionamiento, pero con distinto Estado del Servicio final. La autntica dinamizacin est realmente en funcin del volumen de equipos, automatizando la asignacin del Peso Operativo en funcin de los rangos horarios definidos y los equipos necesarios sin necesidad de tablas de conversin. El uso de la dinamizacin es interesante cuando tenemos un conjunto homogneo de equipos prestando servicio por igual, lo que significa que estn todos juntos y la distribucin de los Pesos Operativos entre ellos es equitativa. Por qu homogneo? Porque si los equipos poseen diferentes funcionalidades no pueden en principio tener iguales Pesos Operativos y el resto de premisas no se cumplira. En algunos Servicios Tcnicos implementar la dinamizacin reduce drsticamente las tareas de mantenimiento, si la situacin y nmero de equipos prestando servicio en cada horario es muy estable. Informticamente implementar los Pesos Operativos dinmicos no es tarea compleja. En principio, todos los equipos tienen que estar dados de alta en el sistema y participar del servicio en el nivel que les corresponda. Segn se registra su puesta en funcionamiento, en funcin de las necesidades, asignar a cada uno el Peso Operativo correspondiente variable dependiendo de la tabla horaria. Si tenemos situaciones en las que hay ms activos que necesarios (cambios de turno, redistribuciones ...) se pueden adoptar mecanismos de control como, no asignar Peso Operativo a los equipos innecesarios, nunca mostrar Estado del Servicio superior al 100%, etc. stos y otros mecanismos de control formarn parte del aplicativo. Y se puede realizar con taxonomas diferentes? Por supuesto. La taxonoma es un nivel de agregacin de servicio diferente y dependiendo del Peso Operativo y el Estado del Servicio de cada taxonoma, calculamos el Estado del Servicio del Nivel de Agregacin de Servicio superior. Cuando se plante la automatizacin del clculo del Peso Operativo, implcitamente se planteaba la dinamizacin. El reparto de los Pesos Operativos se realiza en funcin del volumen necesario para ofertar el servicio y se distribuye en funcin del 161

baremo asignado a cada uno. Para ilustrarlo usemos un ejemplo reciente. Nuestro baremo vlido para todos los horarios es: Equipo 1 = 4 Equipo 2 = 2 Equipo 3 = 1 Equipo 4 = 4 Equipo 5 = 1

Y nos encontramos en una franja horaria en la que son necesarios 3 equipos. El sistema tiene registrado que los equipos activos son el 1, 3 y 4. En este instante, cambia la franja horaria siendo necesario un equipo ms (por ejemplo por defecto el Equipo 5), pero el sistema detecta que se mantienen en 3 los equipos activos. En el horario 1 los Pesos Operativos eran: Equipo 1 = 44% Equipo 2 = 0% Equipo 3 = 12% Equipo 4 = 44% Equipo 5 = 0%

Y en el horario 2 surge la primera interrogante, qu Peso Operativo asignar a los equipos 1, 3 y 4? Pues dependiendo de si es el equipo 2 el 5, la distribucin es diferente: Equipo 1 = 36% Equipo 2 = 18% Equipo 3 = 10% Equipo 4 = 36% Equipo 5 = 0% Equipo 1 = 40% Equipo 2 = 0% Equipo 3 = 10% Equipo 4 = 40% Equipo 5 = 10%

Y no es lo mismo que el Estado del Servicio sea del 82% (E1=36%+E3=10%+E4=36%) en el primer caso, que del 90% (E1=40%+E3=10%+E4=40%) en el segundo. Estrategias a implementar puede haber varias, pero enumeremos las pautas a considerar para encontrar la ms fiel a la filosofa de los Servicios Tcnicos: 1. El Estado del Servicio no puede seguir siendo del 100% (E1=44%+E3=12%+E4=44%), porque deberamos tener 4 equipos en servicio y por lo tanto, los Pesos Operativos deben variar. Reasignacin. 2. Existen 5 equipos, hay que ofertar 4, y slo 3 estn activos. De cara al cliente la percepcin no es que hay un equipo menos prestando 162

servicio, es que debe haber un equipo ms prestando servicio y ninguno de los dos posibles est funcionando. Disponibilidad de equipamiento adicional. 3. Como proveedores, debemos ser exigentes con el nivel de servicio ofertado, penalizando al mximo las deficiencias consecuencia de situaciones en las que pudiendo dar un 100%, el Estado del Servicio es menor. Incumplimientos de Acuerdos de Nivel de Servicio Orientacin del mantenimiento. 4. La situacin del punto 3 afecta a la imagen, es decir, deteriora la Calidad del servicio. Una pobre oferta. 5. Si se activa el Equipo 2, se reestablece la oferta y por lo tanto el 100% (E1=36%+E2=18%+E3=10%+E4=36%). Repercusin inmediata. En estas circunstancias, la distribucin de los Pesos Operativos estar en funcin de los 5 Equipos: Equipo 1 = 33% Equipo 2 = 18% Equipo 3 = 8% Equipo 4 = 33% Equipo 5 = 8%

y el Estado del Servicio resultante es del 74% (E1=33%+E3=8%+E4=33%). Pero estoy seguro de que el lector se habr percatado, que esta estrategia en el Servicio Tcnico de las Lneas de Caja puede resultar falsa. Si nos encontramos en una franja horaria donde slo son necesarios 5 terminales de venta y por falta de personal hay nicamente 4 activos, parece lo ms evidente que el Estado del Servicio sea del 80%, y no del 13%, consecuencia de tener 30 lneas de caja y una distribucin equitativa entre los equipos (baremo fijo a 1). Esta situacin es consecuencia de dos pautas ms a considerar: 6. El baremo si el reparto es equitativo en el horario. Reasignacin condicionada. 7. El volumen de equipos. Disponibilidad de equipamiento adicional alto. Sea cual sea la estrategia adoptada, lo ms importante es que la aplicacin disponga de la opcin para escogerla, de manera que, cmo se calcule el Estado del Servicio y se asignen los Pesos Operativos en cada nivel, est en funcin de las pautas enumeradas anteriormente. Un Servicio Tcnico que tuviera terminales de punto de venta automticos y terminales de punto de venta atendidos (lneas de caja) necesitara implementar ambas estrategias. 163

Nos encontramos ante una situacin ideal, asignacin de Pesos Operativos dinmicos en funcin de un baremo -estrategias definidas para calcular el Estado del Servicio- Qu nos falta para que la implementacin sea completa? Recordemos la frmula para calcular el Estado de Servicio Estado del Servicio=(PS)Equipo-(FDCP)Equipo+(FI)Equipo El Factor de Incertidumbre es la situacin operativa cuando un equipo deja de monitorizarse (no se puede decir la Situacin Operativa en la que se encuentra y por lo tanto su Estado es Desconocido). En el Servicio Tcnico considerado, que un equipo no est activo puede ser consecuencia de estar apagado y no de la ausencia de monitorizacin. Para implementar un Servicio Tcnico con estas caractersticas, no queda ms remedio que implementar en los equipos, mecanismos que permitan a la aplicacin diferenciar cundo un equipo deja de estar activo por la accin de apagarlo, de cundo es consecuencia por una falta de monitorizacin. Una solucin fcil es, antes de apagarlo realizar la Parada Manual. Si posteriormente se apaga no aplicara el estado Desconocido consecuencia de la Matriz de Equipos Clave, como vimos en la segunda parte. El equipo en cuestin estara en una nueva Situacin Operativa dentro de nuestro servicio que denominaramos Apagado. An estableciendo los procedimientos operativos de uso en los equipos, podran darse situaciones de error, pero son situaciones controladas intrnsecas no slo de este Servicio Tcnico, sino de cualquiera que se implemente. En el captulo anterior se plante un nuevo indicador, Calidad del Servicio Ofertado, pues al Estado del Servicio consecuencia de esta estrategia, se le puede aadir una penalidad especial para considerar que, aunque como pasa en el ejemplo, que solo es necesario un equipo adicional segn lo determina el horario, disponemos de varios equipos que podran prestar servicio y ninguno lo est. La degradacin estara en funcin del servicio ofertado y el valor resultante se podra aplicar para obtener la Calidad del Servicio Ofertado. En estos dos captulos ha quedado de manifiesto, que el indicador propuesto para medir la calidad, puede dar mucho juego dependiendo de los factores considerados.

164

8 DESGLOSANDO LA FORMULA ESTADO DEL SERVICIO

En los captulos anteriores hemos mencionado nuevos indicadores, pero la referencia de partida ha sido en todo momento la frmula que sirve de clculo para el Estado del Servicio Estado del Servicio=(PS)Equipo-(FDCP)Equipo+(FI)Equipo y segn vamos profundizando en el conocimiento de cmo implementar un Servicio Tcnico, aparecen casusticas que dependiendo del grado de control que se quiera disponer, puede ser interesante incorporarlas como informacin complementaria de los Indicadores que se construyan, tanto en la Prestacin de Servicio, como en el Factor de Degradacin por Causas Propias. 8.1 Prestacin de Servicio (PS). La Prestacin de Servicio podan ser dos valores, 0% 100%. Cuando es 100% es consecuencia de que todos y cada uno de los equipos implicados, recursos, logstica que participan en ofertar el servicio son correctos, adecuados o simplemente funcionan. Pero cuando es 0% no siempre es por la misma razn. Varias pueden ser las causas y diferenciarlas, permite declinar las responsabilidades de la anulacin de servicio a quien corresponda. La Prestacin de Servicio puede ser descompuesta en factores como: - Tcnicas Propias (TP). Es tal y como actualmente se determina la Prestacin de Servicio. Independientemente del origen de la anulacin, se asume siempre como Tcnicas propias (averas). - Tcnicas Ajenas (TA). En aquellos Servicios Tcnicos en los que factores tcnicos exgenos al mismo inhabilitan el servicio, como por ejemplo, la electricidad. Lo ideal sera integrar a las grandes suministradoras de electricidad en el Servicio Tcnico, pero dada la dificultad que supone, es ms fcil implementar los procesos que se necesiten para que cuando el 0% sea debido a una falta de tensin, contabilizarlo dentro del apartado de Tcnicas Ajenas. - Explotacin (Ex). En aquellos Servicios Tcnicos donde hay participacin humana en la oferta, la complementa o simplemente proporciona atencin (seguridad, informacin...) y la ausencia del personal inhabilita la prestacin. El ejemplo ms claro pueden ser los ascensores (Servicio Tcnico de Transporte Vertical), ya que ante un atrapamiento y la imposibilidad de comunicar con personal en el exterior, por procedimiento de seguridad se paran. - Operativas (Op). Para situaciones excepcionales ajenas al Servicio Tcnico, como por ejemplo una inundacin, un derrumbe...

165

Si simultneamente pueden darse dos o ms factores que anulen el servicio, contablemente el resultado ser nico, es decir PS=0%, pero a efectos de control se consideran todos los que en el tiempo estn activos, pues puede darse la circunstancia que solucionndose uno de ellos, el servicio siga interrumpido por el resto. 8.2 Factor de Degradacin por Causas Propias (FDCP) Es el factor que ms se descompone. De igual manera que la Prestacin de Servicio, las degradaciones pueden ser debidas a diversas causas. Por ello, en lugar de dividir el Factor de Degradacin por Causas Propias en varios subfactores, lo lgico es que coexistan diferentes Factores de Degradacin: 1. Factor de Degradacin por Causas Tcnicas Propias (FDCTP). Tal y como se aplicaba el Factor de Degradacin por Causas Propias. 2. Factor de Degradacin por Causas Tcnicas Ajenas (FDCTA). Conceptualmente idntico al anterior, pero cuando es consecuencia de un factor exgeno. 3. Factor de Degradacin por Explotacin (FDEx). Cuando se produce una Incidencia Operativa consecuencia de la falta de personal. No es un factor comn de aplicar pues generalmente la participacin de las personas estn a nivel de anulacin completa del servicio, pero pueden existir Servicios Tcnicos que tengan esta circunstancia a considerar. 4. Factor de Degradacin Logstica Propia (FDLP). Cuando se produce una Incidencia Operativa, principalmente en aquellos Servicios Tcnicos en donde se obtiene un producto o contraprestacin, no se dispensa el producto por falta del mismo. Por ejemplo un tipo de bebida o la falta de cambio en una mquina dispensadora porque no se ha recargado de monedas. 5. Factor de Degradacin Logstica Ajena (FDLA). Es conceptualmente igual al anterior, pero la reposicin o recarga pueden realizarla contratas. Esta variable puede tener otra visin alternativa. Si independientemente de ya sea con personal propio o contrata se imputa como Factor de Degradacin Logstica Propia, cuando la Incidencia Operativa est causada en el origen, es decir, cuando el problema de no recargar o no reponer provenga directamente del fabricante, ser considerado como Factor de Degradacin Logstica Ajena. Si simultneamente pueden darse dos o ms factores que causen la misma Incidencia Operativa, contablemente el porcentaje de degradacin se restar una sola vez, pero se controlarn todos los que en el tiempo estn activos, pues puede darse la circunstancia de que solucionndose uno de ellos, el servicio siga degradado por el resto.

166

8.3 Factor de Incertidumbre El Factor de Incertidumbre solo aplica en los casos de los equipos monitorizados y aunque es cierto que la falta de supervisin de un equipo monitorizado puede deberse a situaciones similares que las comentadas para la Prestacin de Servicio y el Factor de Degradacin por Causas Propias, la propia monitorizacin cuando existe, generalmente proporciona los medios redundantes de comunicacin y cuando se produce una ausencia, conocer exactamente el por qu, requiere de controles ms complejos que los indicados en los dos factores previos. Del desglose detallado en los tres apartados previos, obtenemos que la frmula resultante sera: Estado del Servicio=(PS)Equipo-(FD)Equipo+(FI)Equipo Donde: Prestacin de Servicio(PS)=100-(TP)-(TA)-(Ex)-(Op) y Factor de Degradacin(FD)=(FDCTP)+(FDCTA)+(FDEx)+(FDLP)+(FDLA) y en condiciones normales de explotacin: Tcnicas Propias(TP)=(TA)=(Ex)=(Op)=0

167

168

9 CUNDO UN EQUIPO EST PRESTANDO SERVICIO?

Una discusin que se produce muy a menudo entre aquellas personas que participan en los Servicios Tcnicos, consiste en definir cuando un equipo presta SERVICIO. Como ha quedado de manifiesto durante el desarrollo del Servicio Tcnico, cualquier suceso que provoque una degradacin total o parcial de la prestacin, se cuantifica y repercute significando la no prestacin de una funcionalidad o anulacin completa. Pero si durante el tiempo que transcurre hasta que el equipo restituye su funcionalidad, no hay nadie que la demande, realmente deja de prestar el servicio? Qu percibe el cliente?

Ojos que no ven, corazn que no siente?

El Estado del Servicio es un indicador en tiempo real diseado para dar a conocer al posible cliente la situacin que se va a encontrar respecto de un servicio que puede demandar, pero eso no significa que lo vaya a hacer. Incluso al conocer dicho Estado en determinados Servicios Tcnicos, por sus caractersticas, permitirn al usuario decidir alternativas consecuencia de la informacin proporcionada principalmente por los Equipos Clave o elementos informativos adicionales. El ejemplo usado para ilustrar qu queramos decir con Estado del Servicio en la segunda parte, es altamente significativo de que si el valor posible que nos dan es muy alto, no se nos ocurrira hacer uso de la carretera. Pero esto sucede en algunos Servicios Tcnicos, en otros no. Examinemos algunos supuestos: Supuesto 1) Servicio Tcnico de Terminales de informacin en un aeropuerto. Los terminales se han distribuido por zonas teniendo de uno a cuatro terminales por zona de influencia. En una zona y segn el planteamiento establecido para el indicador Estado del Servicio, el porcentaje ir disminuyendo segn menos terminales estn activos, llegando a tener valores de Estado del Servicio en las zonas donde solo haya un terminal de 0% 100%, a aquellas zonas que cuentan con cuatro terminales y posibles valores resultantes de 0%, 25%, 50%, 75% 100%. Pero en aquellas zonas que tengan ms de un terminal, el usuario puede optar por ver la informacin en otro prximo con lo que su necesidad estara satisfecha. Esta mtrica es el Nivel de Oferta, indicador que mide si es posible satisfacer la demanda en un grado razonable. En este Servicio Tcnico mientras haya algn terminal operativo, el servicio en su conjunto se est prestando, el indicador Estado del Servicio tiene una clara orientacin tcnica (mientras no sea del 0% la prestacin de servicio se mantiene aunque no sea del 100%) y el indicador Nivel de Oferta notoriamente informativo y de gestin. Pero an en los casos de Niveles de Oferta nulos, no significa que alguien est demandando 169

el servicio y dado que no existe posibilidad razonable de determinar con exactitud si alguien lo demanda, es lgico asumir como prestacin, el valor que se obtenga de Nivel de Oferta. Supuesto 2) Servicio Tcnico de desplazamiento vertical y horizontal en un aeropuerto (Transporte Vertical). En los aeropuertos cuanto ms grande es su extensin, ms elementos mecnicos de desplazamiento (Ascensores y Escaleras) existen para facilitar el trnsito interno del viajero. Sin considerar la posibilidad de disponer con elementos paralelos para realizar el mismo desplazamiento, ante un fallo, el usuario no tiene ms remedio que hacerlo por sus propios medios, en definitiva andando, estando en un claro ejemplo de anulacin del servicio. El Nivel de Oferta coincide prcticamente con el Estado del Servicio en la mayora de las localizaciones y en este caso, implementando solo el Estado de Servicio, la orientacin es tanto tcnica como de gestin. Al igual que en el supuesto anterior, no hay forma razonable de cuantificar cundo y cuntos usuarios no han podido usar las Escaleras y los Ascensores y asumiremos la prestacin, el valor obtenido del Estado del Servicio. Servicio Tcnico de mquinas expendedoras de ttulos de transporte en una estacin de tren. En todas las estaciones de tren, y ms si hay posibilidad de trenes de cercanas, existen mquinas que por medio de dinero en efectivo, tarjeta de crdito..., dispensan billetes, abonos etc. Un Servicio Tcnico de este tipo, dnde para que la demanda exista es necesario interactuar con el usuario, son los nicos donde existen ciertas posibilidades de establecer diferenciaciones en cuanto a la prestacin del mismo. Desde un punto de vista muy interesado (casi egosta), hasta que no exista la peticin por parte del usuario y lgicamente, mientras no exista la completa anulacin de la mquina, el Estado del Servicio podr tener la degradacin correspondiente, pero el Nivel de Oferta es la mayor que nos permita el diseo y las consideraciones establecidas, de manera que, mientras no se est interactuando no se penaliza. Cunto tiempo se penalizara, podra estar en funcin del promedio del tipo de funcionalidad demandada, pero para la comprensin de este captulo no es relevante. Ahora bien, puede suceder que no admita el pago con tarjeta, pero s con efectivo. Mientras exista un mtodo de pago por medio del cual obtener el ttulo de transporte requerido, lo que se est demandando es posible obtenerlo y bajo este razonamiento, NO HAY PRDIDA DE SERVICIO, aunque haya una funcionalidad anulada. El 170

Supuesto 3)

indicador Nivel de Oferta para ese equipo en concreto estara al mximo si no hubiera ninguna otra circunstancia adicional que considerar. Si en lugar del mtodo de pago, es propiamente la obtencin de un determinado ttulo de transporte la cosa cambia, pues el usuario se ve obligado a optar por otro tipo de ttulo o buscar otro equipo donde obtener el que verdaderamente necesita. En este caso, s ha existido merma y por lo tanto puede ser cuantificada en los trminos establecidos en el diseo. An as, en el afn de proporcionar el mejor servicio posible, las mquinas proporcionan informacin til de su situacin operativa. Si el usuario recibe esta informacin previa a realizar la operacin, nunca existira prestacin pues directamente el usuario optara por otra solucin y por ende, nunca habra penalizacin favoreciendo claramente al indicador correspondiente. Una de las premisas ms importante a la hora de disear indicadores es que sean tiles, y el indicador as descrito poco o nada nos aportara. Es mejor optar a que, independientemente haya o no solicitud del servicio ofertado, cuantificar cualquier prdida de funcionalidad, y si es necesario ser muy precisos, cuantificarla en funcin de demanda media por franja horaria o cualquier otro factor de ponderacin. As, aunque tuviramos una situacin prolongada en el tiempo en la que no haya ningn usuario demandando el servicio, tendramos una informacin cuantificada por medio del indicador correspondiente que nos permite gestionar las ausencias parciales o totales de servicio. Este tipo de Servicios Tcnicos permiten implementar ambos indicadores (Estado del Servicio y Nivel de Oferta) y la lectura conjunta de ambos, refleja la percepcin de servicio que tiene el usuario y la prestacin que somos capaces de ofertar. Supuesto 4) Servicio de Tcnico de postes de SOS en las carreteras. En las principales vas de circulacin de vehculos a motor de los pases ms avanzados, se colocan a lo largo y en ambos sentidos postes de comunicacin de emergencia para los casos en los que sea necesario contactar con un centro de atencin (averas, accidentes...). Este Servicio Tcnico es igual que el anterior, requiere interactuar con el usuario, pero se simplifica sustancialmente ya que el servicio demandado es la comunicacin con el centro de atencin, e independientemente cual puede ser la causa que pueda provocar el fallo, ante ste, desplazarse a otro poste puede significar un tiempo crucial. Penalizar exclusivamente cuando haya demanda no parece a priori lo ms adecuado. Seamos adems de mantenedores, explotadores, o la explotacin est a cargo de otro 171

departamento o empresa, conocer la situacin operativa real (el Estado del Servicio) es vital. En este caso, hablar de Nivel de Oferta est de ms. Cualquiera que sea el caso en el que nuestro Servicio Tcnico se encuentre, lo que hemos pretendido trasladar al lector es que, cuantificar exclusivamente cuando haya la demanda, aunque pueda hacerse y parezca ser coherente, a la larga, ese indicador as construido no va a permitir hacer una gestin eficaz, pasando a formar parte de ese conjunto indeseado de informacin que muchas empresas tienen y solo sirven para tergiversar, confundir y polemizar. Sea quien sea el explotador necesita conocer la situacin del Servicio Tcnico, ya sea por medio del Estado del Servicio o conjuntamente con el Nivel de Oferta, aunque pasen los das sin ningn usuario que lo demande. Mejor, as no habr reclamaciones. Qu alivio!

172

CUARTA PARTE FASE DE CONSTRUCCION

173

174

NDICE CUARTA PARTE

1 2 3 4 SEGUNDA FASE, CONSTRUCCION .............................................................. 177 ANTES DE DESEMBALAR LOS LADRILLOS............................................ 179 UN ESQUEMA VALE MAS QUE MIL PALABRAS ......................................... 183 LOS PILARES BSICOS ................................................................................ 197 4.1 Servicio Tcnico .......................................................................................... 197 4.2 Situacin del Servicio Tcnico ................................................................... 197 4.3 Nivel de Agregacin .................................................................................... 199 4.4 Nivel de Agregacin del Servicio Tcnico ................................................. 200 4.5 Rangos Horarios .......................................................................................... 201 4.6 Situacin Operativa del equipamiento ....................................................... 202 4.7 Incidencias Operativas ................................................................................ 203 4.8 Reglas de las Incidencias Operativas ........................................................ 203 4.9 Tipos de Impacto ......................................................................................... 204 4.10 Matriz de Estados de Equipos Clave ........................................................ 204 4.11 Matrices de Estados de Equipos Implicados .......................................... 206 4.12 Tipos de Relaciones .................................................................................. 206 4.13 Relaciones Sntoma-Estado-Incidencia Operativa.................................. 207 4.14 Relaciones Alarma-Estado-Incidencia Operativa.................................... 208 4.15 Relaciones de equipos .............................................................................. 208 4.16 Pesos Operativos....................................................................................... 209 4.17 Interfaces de Carga-Descarga .................................................................. 209 5 6 7 8 FLUJO DE CONTROL ..................................................................................... 211 CAMBIO DE ESTADO BAJO DEMANDA ....................................................... 213 COMO MOSTRAR LOS DATOS DEL SERVICIO TECNICO .......................... 215 UN DIAGRAMA PARA ACABAR .................................................................... 221

175

176

1 SEGUNDA FASE, CONSTRUCCION

En las tres partes precedentes a sta que comenzamos, hemos tratado los aspectos relativos a conocer e identificar los Servicios Tcnicos, para posteriormente entrar por completo en la fase de Diseo. Captulo a captulo, intentando hacer la lectura lo ms dinmica posible, hemos desbrozado todos los matices necesarios para realizar el diseo del Servicio Tcnico recogiendo todo aquello que por las razones expuestas, nos facilitarn el desarrollo de las siguientes fases y establecern las claves sobre las que edificarlo. Es muy posible que algunas cosas queden en el tintero, pero an as, hemos andado mucho camino, imprescindible para la comprensin de esta cuarta parte que ahora comenzamos. Es el momento de hacer un poco de memoria. Las fases establecidas para implementar con xito un Servicio Tcnico son:

Pues bien, diseado el Servicio Tcnico es el momento de construirlo. Decamos para la fase de Construccin: Todo lo diseado debe ser desarrollado en alguna plataforma informtica para su automatizacin, que permita la mayor capacidad de integracin tcnica y fidelidad con lo diseado 177

Y ste es el fin, la aplicacin desde el punto de vista informtico. Es el momento de buscar a los analistas y programadores capaces de convertir las ideas en una herramienta tangible. La creacin de un equipo multidisciplinar entre los diseadores y programadores ser trascendental para la consecucin del proyecto. Trasmitir qu es lo que se quiere, la prioridad esencial. No es del todo descabellado, proponer la participacin de los analistas en la fase de diseo en segunda fila, pero con el nico propsito de trasmitir los conceptos tan exclusivos e inherentes que todo Servicio Tcnico posee. No olvidemos que, en la mayora de los casos hablamos de equipamiento industrial, es decir, tecnologa y conceptos propios del mundo mecnico, automtico, manufacturero, productivo... y por propia experiencia puedo manifestar, lo importante y determinante que es dedicar parte del tiempo de cualquier proyecto a trasmitir el conocimiento correspondiente. Hacerlo, ha sido en la mayora de los casos garantizar el xito en tiempo y forma. Esta fase no debera presentar ms complicaciones que las propias de la creacin del aplicativo, que no son pocas, pues como dijimos en su momento tiene algo de ingrata. Durante el periodo de tiempo que dure la fase de Construccin, podremos encontrar situaciones en las que como consecuencia del desarrollo de la aplicacin, se detecte la necesidad de modificar algn aspecto diseado, o plantear desde una nueva perspectiva el conceptual del Servicio Tcnico. Para estos casos, no queda ms remedio que retroceder a la fase de Diseo. En el esquema que ilustra el comienzo del captulo no se especifica ningn enlace entre las dos fases, ya que la proximidad entre ellas y condicionado por el equipo multidisciplinar, los rediseos consecuencia de la construccin deben ser lo ms operativos y de ejecucin inmediata. Esta fase es la ms pragmtica de todas. Vamos a por ella.

178

2 ANTES DE DESEMBALAR LOS LADRILLOS

Lo ms lgico sera ponernos manos a la obra y empezar con la difcil tarea que se nos viene encima. Pero un tiempo de reflexin previo va a ser vital. Los buenos programadores saben que lo ltimo a realizar es precisamente el programa. Antes, es necesario tener absolutamente controlados todos los aspectos que intervienen en la construccin del Servicio Tcnico. Realizar un Anlisis Funcional ayudar a que la aplicacin sea coherente, flexible, amoldable y muy importante, escalable. Por ello, todo lo diseado debe ser programado en alguna plataforma informtica para su automatizacin, que permita la mayor capacidad de integracin y fidelidad con lo diseado. Realmente la programacin del aplicativo, vamos a llamarle Gestor de Servicios Tcnicos, plantea dos interrogantes que necesitan respuesta y muy condicionadas por el grado de informatizacin previo: a. Construir el Servicio Tcnico desde cero. Ya sea porque no se poseen herramientas informticas adecuadas o porque no se considere oportuno, la herramienta ser una aplicacin independiente, programada, nunca mejor dicho, desde cero. Esta opcin en principio puede ser la que muestre una mayor flexibilidad y autonoma en el desarrollo del aplicativo. Por contra los grandes esfuerzos a realizar, pues poco o nada se aprovecha de lo ya existente, implicando grandes cambios a nivel general en la organizacin y el equipamiento. b. Construir el Servicio Tcnico en una o varias aplicaciones en explotacin. Si nuestra empresa u organizacin cuenta con un GMAO1, herramientas industriales de supervisin de equipos (SCADA2), etc., este tipo de herramientas, incorporan lenguajes propietarios de programacin para adaptarlos a las necesidades empresariales y adems, permiten integrar aplicativos desarrollados en lenguajes estndar de programacin (JAVA, XML,...). Esta opcin facilita la integracin con el resto del software, reduciendo esfuerzos, aprovechando las sinergias existentes, y minimizando los cambios y el impacto que puedan producir. Como inconveniente, integrar la herramienta en el conjunto de aplicaciones obliga a usar las caractersticas ya definidas, tanto en los aplicativos, como en el equipamiento, pudiendo limitar en gran medida las posibilidades constructivas del Servicio Tcnico, no tanto al principio, donde los alcances pueden ser menos ambiciosos, s, cuanto ms se le evoluciona y perfecciona. Sirva como solucin a estas dos interrogantes, la experiencia de los actuales Servicios Tcnicos implementados en Metro de Madrid, donde despus de un
1 2

Gestin de Mantenimiento Asistido por Ordenador Sistema de Captacin y Adquisicin de Datos

179

profundo anlisis sistemtico, se lleg a la conclusin de que lo mejor era implementarlos como una aplicacin independiente, pero que fuera capaz de aprovechar las herramientas software existentes, y la informacin proporcionada por stas y el equipamiento. Con la vista puesta en el pasado, siendo conscientes de las necesidades evolutivas y los retos que plantean, tanto los Servicios Tcnicos actuales, como los que en un futuro prximo estn por construir, la decisin de partida adoptada se mostr la ms satisfactoria. Pero es justo comentar que en la actualidad, Metro de Madrid est inmerso en una fase de evolucin cualitativa del aplicativo, ya que se ha optado por integrar la herramienta en una plataforma existente en el mercado propiedad de IBM, conocida como TBSM (Tivoli Integrated Portal) y que para mantener la compatibilidad con la herramienta actual, todos aquellos alcances que no es posible desarrollarlos en esta nueva plataforma, se mejoran en la actual integrndolos por medios de interfaces de programacin adecuados. Independientemente de cual de las dos opciones comentadas sea la ms conveniente, lo ms lgico es construir la aplicacin conjuntamente con el primer Servicio Tcnico que se disee. El por qu es obvio. Permite segn se desarrollen todos los aspectos definidos (Reglas, Pesos, Incidencias, Estados, Matrices...), ir comprobando si se ajustan los resultados a las expectativas de diseo, pues ser dentro del mbito del Servicio Tcnico donde se garanticen los resultados. Determinar que herramienta software en concreto usar para construir un Servicio Tcnico depender de la organizacin. Lo ms razonable es escoger aquella que mejor se ajuste, tanto con lo que se va a disear, como con el resto de software y aplicaciones en produccin. No obstante, es recomendable tener presentes algunos criterios que van a facilitar la eleccin: 1) Si se van a Monitorizar Equipos y Sistemas, la finalidad de dicha monitorizacin es el control y la supervisin (telemantenimiento). Se hace por ello imprescindible integrarlos bajo una consola nica (Consola de Gestin). Para ello, es requisito fundamental que los equipos puedan ser supervisados por medio de sistemas de comunicacin estndar, usando protocolos normalizados. As mismo, donde por antigedad u otras causas no se pueda establecer una monitorizacin directa, ser necesario adquirir sondas industriales, PLCs3 y equipos afines, que proporcionen el interfaz de conversin para su integracin. Por ltimo, en muchas circunstancias es ms recomendable la integracin por medio de sondas va software dentro del equipo, como si de un programa o aplicacin ms, se tratara. 2) Es recomendable construir la aplicacin disponiendo de tres entornos (computadoras) bien diferenciados, para minimizar el impacto de las evoluciones y mejoras que se desarrollen posteriormente: a. Desarrollo
3

Autmatas (equipos industriales)

180

b. Preproduccin c. Produccin Como mnimo es necesario contar con un entorno de DesarrolloPreproduccin y otro de Produccin. 3) Si el Servicio Tcnico a construir va a contar con equipos no monitorizados, la nica posibilidad de conocer la Situacin Operativa de un equipo y por consiguiente su Estado de Servicio, es por medio de un registro de Incidencias. Los actuales sistemas GMAO cuentan con dicha posibilidad. Evidentemente el Estado del Servicio depender de si existe Incidencia que afecte a dicho Servicio Tcnico. Esta circunstancia no solo afecta a las cifras de Disponibilidad del Servicio, que en principio siempre sern mucho mejores, consecuencia del retraso en comunicar la incidencia, que las de los equipos monitorizados, sino que si mediante el GMAO, adems de las Incidencias (Mantenimiento Correctivo) tenemos integrado el Control del Mantenimiento Preventivo, Predictivo,... las paradas consecuencia de dichas intervenciones no se contabilizan hasta pasados varios das y por lo tanto, durante el periodo de tiempo que dure la intervencin, tanto el Estado como la Disponibilidad del Servicio sern del 100%, siempre y cuando el estado del equipo antes de la intervencin fuera En Servicio. Para mitigar stas y otras posibles situaciones similares, debemos integrar en nuestra aplicacin la posibilidad de cambiar la Situacin Operativa de un equipo bajo demanda, es decir, la forma de actualizar el Estado del equipo, cuando por los medios automticos establecidos (registros de incidencias y monitorizaciones) no se obtiene dicha informacin en tiempo real o con un decalaje de tiempo razonable. El procedimiento que determine como hacerlo ser competencia de cada Organizacin. Asimismo, se puede aprovechar esta funcionalidad para no solo cambiar bajo demanda la Situacin Operativa por mantenimientos programados, sino adems, por situaciones circunstanciales como son: a. En equipos monitorizados, que las seales proporcionadas no sean correctas (malos cableados, problemas de software...) y por lo tanto no est llegando la Situacin Operativa correspondiente. b. Errores en la aplicacin, de manera que algunos equipos no tengan su Estado real. c. Problemas con el registro de las Incidencias (Eliminadas, mal comunicadas...) 4) Considerar otras fuentes de informacin adems de aquella que refleje los problemas derivados de cuestiones tcnicas (averas). Dependiendo de los requerimientos y caractersticas del Servicio Tcnico que se est diseando se pueden tener, Situaciones 181

Operativas iguales que los provocados por problemas tcnicos, pero consecuencia de contextos diferentes, como pueden ser: logsticos, explotacin, recursos humanos,... Si existen bases de datos de las cuales obtener la Situacin Operativa provocada por otros contextos diferentes al tcnico, es determinante implementar la interfaz de comunicacin entre el Gestor de Servicios y dichas bases de datos. Algunos ejemplos de incidencias no tcnicas son: - Falta de cambio en una mquina expendedora (la Incidencia Operativa sera Precio Exacto) por falta de recarga de monedas. Se deriva de un problema logstico, generalmente, realizada por empresas de seguridad. - No dispensar algn producto por estar agotado. Se deriva de un problema logstico de reposicin de existencias, generalmente, realizado por distribuidores. - Equipamiento fuera de servicio consecuencia de actuaciones ajenas al Servicio Tcnico y que repercuten directamente en la falta del mismo. Por ejemplo, una inundacin provocada por la rotura de una galera de conduccin o fuertes tormentas. - Falta de personal para atender a los clientes y que incide directamente en la explotacin del equipamiento implicado en un Servicio Tcnico. Para qu tener claro estos 4 criterios? Para facilitar la integracin y conocer las limitaciones. Nada puede ser ms frustrante y perjudicial que, despus del esfuerzo empleado en implementar un Servicio Tcnico, ste no cumpla las expectativas iniciales por no haber tenido en cuenta cuestiones, aparentemente no tan ligadas a priori con el Servicio Tcnico.

182

3 UN ESQUEMA VALE MAS QUE MIL PALABRAS

Para hacernos una idea general de cul sera el escenario del que estamos hablando, donde tenemos que relacionar los equipos, las bases de datos, centros de atencin, etc., con el esquema adjunto podemos tener una visin global bastante aproximada de los sistemas y dems componentes que se relacionan con el Gestor de Servicios Tcnicos.

Situaciones Excepcionales

Us ua ri os
Datos Consultas I nformes

Web
Registro Incidencias de Logstica

Centro de Atencin

Registro Incidencias de Explotacin

Gestor de Servicios Tcnicos

Incidencias

GMAO
Gestor de Mantenimiento

Mantenimiento (Incidencias Tcnicas)

Otros Registros
Estados Alarmas

BB.DD Equipos

Automatizacin de Incidencias

Cons ol a de Gesti on
Telecontrol Telemantenimiento (Supervisin)

Sonda s

Ascensores

Surtidores

Lneas de Caja

Expendedo ras de bebidas

183

Lo primero que podemos destacar es, que el Centro de Atencin lo representamos como un help desk de mantenimiento, y conservamos registros independientes para las incidencias derivadas de problemas logsticos, explotacin, recursos humanos,... pero en organizaciones de un considerable tamao, el Centro de Atencin puede ser mucho ms que un centro de atencin tcnica, convirtindose en un Centro Integrado de Gestin, que aglutine y coordine todas las incidencias que repercutan en los Servicios Tcnicos, derivndolas a los centros responsables de atenderlas y a sus gestores. Para mejor comprensin y diversidad informativa, en el esquema los mantendremos como centros independientes. El nexo de todo el dibujo es la base de datos de equipos. Nada podr funcionar, en el ms estricto sentido de la palabra, sin un correcto inventario de los equipos, incluso, aunque no formen parte de ningn Servicio Tcnico. Por qu es tan importante? Voy a justificarlo ayudndome de una aficin compartida por muchos. El xito de hacer cumbre en una montaa, sobre todo cuando ascenderla requiere de experiencia y adecuada preparacin fsica y mental, se basa adems en una correcta planificacin. Para ello, cuestiones como los vveres, el equipo, la vestimenta, etc., son esenciales y para ello, nada mejor que hacer un detallado inventario, pero teniendo en cuenta adems aspectos como el peso del conjunto, condiciones atmosfricas, poca del ao, altitud, etc. Por insignificante que parezca un elemento, por tericamente imprescindible que aparente ser, bajo determinadas circunstancias puede llegar a convertirse en crucial, y significar el fracaso o el triunfo. Pues sin pretender ser tremendista, y aunque las consecuencias sean de otra ndole, evidentemente, lo ms importante para una exitosa implementacin de cualquier Servicio Tcnico es, disponer del inventario del equipamiento e instalaciones. Dicho de otro modo, la base de datos de los equipos y para conseguirlo debe reunir dos cualidades: a. Lo ms consistente respecto del parque instalado. Un equipo o instalacin que desde el punto de vista informtico no existe, no admite ningn tipo de tratamiento, generando distorsiones en los resultados. b. Lo ms detallada posible. Disponer del mayor volumen posible de informacin de cada equipo, permite disponer de recursos para tratarlo informticamente. Las caractersticas tcnicas, funcionales, operativas... deben aportar el conocimiento existente. Y la primera informacin asociada a todo equipo en cualquier base de datos es su cdigo. Es la matrcula por la que lo identificamos, pero debemos evitar que sea estrictamente eso, un simple nmero que no diga nada, ni tan siquiera el tipo de vehculo. Como mnimo es recomendable que el cdigo nos de idea del tipo de equipo que es, y ya que estamos hablando de matrculas, o lo que es lo mismo, de vehculos, si el cdigo empieza por CAM tendramos camiones, si por TUR turismos, MOT motocicletas y as sucesivamente. 184

Al igual que en muchas matrculas se distingue la regin, poblacin o pas distintivo, si llegara a ser el caso, junto con el cdigo que identifica al tipo de equipo, puede ser interesante otro cdigo que identifique al responsable directo del equipo desde el punto de vista organizativo. Esta implementacin es muy til cuando tengamos equipos del mismo tipo, atendidos por diferentes departamentos de mantenimiento, incluidas contratas. Respecto de este tema muchas veces sucede que, adems de un responsable directo, hay otros departamentos con competencias que intervienen y no slo para la resolucin de problemas. Para cumplimentar estos casos no parece apropiado contemplar la identificacin en el cdigo. Lo lgico es, generar una caracterstica adicional que pueda agrupar tantos cdigos como responsables puedan actuar. Identificar a los puestos con competencias en el equipamiento obliga ineludiblemente a, en paralelo con la base de datos de equipos, crear una base de datos de departamentos. Si la diversidad dentro del tipo de equipo es elevada, puede ser conveniente optar por algn conjunto de siglas adicional a este cdigo que identifique marca o modelo. Para completar la identificacin del equipo una vez combinadas las siglas precedentes, aadiramos la numeracin secuencial. Un cdigo compuesto por los tres tipos de siglas, seguido lgicamente de la numeracin correspondiente, cumple con la mayora de las necesidades de las organizaciones para identificar adecuadamente al equipamiento. Una vez que tenemos perfectamente fichado al equipo, lo siguiente es definir sus caractersticas. Es de esos aspectos inherentes a todo objeto. Por ejemplo, cuando nos disponemos a comprar una cmara de fotos, un televisor, un ordenador,... las caractersticas nos permiten: Saber si el equipo se adapta a lo que buscamos. Que otros aspectos adicionales son interesantes adems de los buscados. Si no cumple todas nuestras exigencias, que otros aspectos aporta que pueden compensarnos su adquisicin. Comparar entre equipos. En este ejemplo, las caractersticas ayudan en el momento de la compra. En el caso del inventario, nos permitirn operar, explotarlo, mantenerlo... y porque no tambin, adquirirlo. Adems del cdigo aadimos las caractersticas, pero cuando se tienen multitud de equipos semejantes, continuamente se van a repetir. No parece lo ms conveniente reiterar esta informacin por cada equipo. Lo ms productivo es asociar caractersticas iguales en grupos de catlogos, entendiendo como catlogo a un conjunto de datos iguales, de manera que, pudiendo tener equipos de diferente tipo, marca, modelo o combinacin de stos, pueden compartir caractersticas comunes 185

englobadas dentro de un mismo epgrafe. La ventaja de proceder de esta forma reside en que cualquier modificacin de una caracterstica comn, en lugar de tener que cambiarla en cada uno de los equipos que disponen de ella, se modifica a nivel de catlogo beneficindose de la actualizacin todos los equipos. Un catlogo, reduce los costes de implementacin y de mantenimiento de datos. Adicionalmente, cada equipo dispondr de tantos catlogos como sean necesarios para informar. A modo orientativo, es interesante generar los catlogos desde el punto de vista funcional, tcnico, etc., por homogeneidad de la informacin contenida. En el caso de que con ningn catlogo se pueda dar cumplimiento a informacin relevante del equipo, asociaremos directamente las caractersticas al equipo, como por ejemplo la ubicacin, pero no nos adelantemos. La ubicacin es una caracterstica que requiere de tratamiento especfico. Hasta este momento, la base de datos de equipos es muy completa. Cada equipo, sistema, instalacin, est perfectamente identificado y como hemos dicho, muy til para quien desarrolle su actividad en funcin del mismo. Para el mantenedor datos tcnicos, para los operadores datos operativos..., pero, por qu pueden ser tiles para el mantenedor el conocimiento de los datos tcnicos? Fijmonos de nuevo en el esquema. Observamos que ya sea por medio de la Consola de Gestin, o por medio del Centro de Atencin, todas las incidencias producidas en los equipos son comunicadas. En el caso de incidencias automatizadas, el equipo monitorizado, por medio de su alarma, reporta cual es el fallo y si es necesaria la sustitucin de alguno de sus componentes, ajustarlos, etc., y se consultan las caractersticas correspondientes con la finalidad de adecuar la actuacin lo ms eficientemente posible. Pero en el caso de una incidencia comunicada telefnicamente, pocas veces se dice la causa del fallo, porque normalmente un observador no experimentado ni conocedor del equipamiento solo trasmite los sntomas que se aprecian, sntomas que pueden o no ser los asociados al problema. El ejemplo ms simple que podemos exponer, es la parada de un vehculo como consecuencia de la falta de gasolina. La falta de gasolina lo asociaramos como el fallo y la parada como el sntoma, pero que un vehculo se pare puede ser por multitud de causas (fallos), independientemente de lo complejas que sean. Facilitar informacin a quien tenga que intervenir es importante, principalmente por cuatro motivos que pueden o no darse simultneamente: 1) Conocer la operacin u operaciones a realizar para solventar el problema. 2) El tipo de herramientas segn condicionen las intervenciones a realizar. 3) Materiales y/o productos adicionales (grasas, lubricantes, etc.) necesarios en la actuacin. 4) Procedimientos asociados previos a cualquier (comunicacin a centros de seguridad o vigilancia...) intervencin

186

Esta informacin para proceder en las intervenciones slo es posible obtenerla de los sntomas y fallos de los equipos, ms concretamente de los fallos. Pues de igual modo que las caractersticas las agrupbamos en catlogos y los asignbamos a los equipos, los catlogos de sntomas y fallos estarn asociados con equipamiento homogneo. Por lo tanto, tendrn asociados tantos catlogos de sntomas y fallo como sean necesarios, y del mismo modo que para las caractersticas, aquellos sntomas y fallos exclusivos del equipo se asociarn directamente. Evidentemente, el catlogo de sntomas tiene como finalidad determinar el fallo o posibles fallos (no siempre es tan determinante poder acotar la causa del fallo), pero la utilidad real de la generacin de catlogos de sntomas, es para construir Flujos de Decisin, de manera que, usando preguntas asociadas a los sntomas, se pueda llegar a determinar, en el mejor de los casos, el fallo o por lo menos, un conjunto finito de fallos potenciales. Cuando se nos par el vehculo (sntoma), la pregunta ms inmediata a realizar es: El indicador del depsito de combustible est a cero? Si la respuesta fuera afirmativa, como fallo asociado sera la falta de combustible. En caso contrario, tendramos relacionada otra pregunta (podran ser varias), como por ejemplo: Al intentar arrancar con la llave, el motor gira? Dependiendo de la respuesta, tendramos asociados uno o varios fallos posibles, o continuaramos navegando por el Flujo de Decisin hasta finalizarlo. Un consejo muy til es, evitar la finalizacin del flujo sin asociar posibles fallos. La experiencia demuestra que si existe tal oportunidad se repite en exceso, con los inconvenientes de la falta de informacin que se deja de aportar para la resolucin de la incidencia. Hemos solucionado la identificacin de los fallos en los equipos no monitorizados, pero en los equipos monitorizados es suficiente con la llegada de la alarma? Aunque se simplifica sustancialmente el control de los problemas y por ende su solucin, como mnimo debemos asociar la presencia de cualquier alarma con el catlogo de fallos, y al igual que como en el resto de parmetros que estamos considerando propiedades del equipo, excepto aquellas alarmas exclusivas, al resto las podemos agrupar en catlogos. Las ventajas son obvias, en primer lugar es una relacin unvoca directa, ya que toda alarma tendr asociada uno o varios fallos, y en segundo lugar, no necesitamos ejecutar ningn Flujo de Decisin para determinar el problema. Recapitulemos que informacin bsica contiene la base de datos de equipos: 1 - Cdigo. 2 - Catlogo de Caractersticas. 3 - Catlogo de Sntomas. 187

4 - Catlogo de Fallos. 5 - Catlogo de Alarmas. Nos falta algo? Si, la ubicacin. Pero en principio, con la informacin considerada, es ms que suficiente para disponer del conocimiento necesario y dar cumplimiento a las actividades generadas en derredor de los equipos. Esto no significa que haya organizaciones que, por la idiosincrasia de la misma o los condicionantes propias de la explotacin, requieran de otras cuestiones ms especficas y particulares. Ha llegado el momento de tratar la UBICACIN. La ubicacin es importante para situar a cualquier equipo geogrficamente, sobre todo, si existe una gran dispersin. Cmo vamos a poder intervenir en un equipo si no sabemos dnde est? Pero an en el caso de ubicarlo, no significa garanta de encontrarlo. Es muy fcil entenderlo. Supongamos que recibimos una notificacin de una incidencia producida en un equipo que se encuentra ubicado en la planta 4, del edificio 3, del recinto empresarial de una determinada poblacin. Hay una cadena de cuatro localizaciones, cada una de ellas hurfana sin las otras. Si la ubicacin no proporcionara la secuencia completa, en el caso de una incidencia sera casi imposible realizar la intervencin. Se puede afinar la localizacin, ubicando dentro de la 4 planta la situacin exacta (equipamiento en cuartos tcnicos, falsos techos, etc.), llegando en determinadas situaciones a ser imprescindible y al mismo nivel de importancia que las cuatro precedentes. Pero no solo la ubicacin es importante para situar al equipamiento, sino porque detrs de la posible secuencia de localizacin, y como veremos en algunos ejemplos del prximo captulo, si no hay alguna causa que lo justifique, los diferentes Niveles de Agregacin de Servicio que se definan, correspondern inicialmente con los diferentes niveles de localizacin de los equipos, y que como recomendamos en la segunda parte, cinco parece ms que razonable el nmero mximo de niveles; cuatro seran por la ubicacin como tal y uno ms por la taxonoma. Conociendo el alcance y la repercusin que tiene esta caracterstica, es obligatorio realizar un estudio previo de las posibles demarcaciones geogrficas susceptibles de localizar al equipamiento, desglosadas desde la ms generalista a la ms concreta, para componer los cdigos correspondientes a dichas localizaciones. Cuanto ms particular sea una localizacin, ms diversificacin existe y los cdigos para un mismo nivel de localizacin, no tienen porque definir geogrficamente lo mismo. Dependiendo de los tipos de equipos pueden variar. Imaginemos el Servicio Tcnico de Surtidores de Combustible y el Servicio Tcnico de Maquinas Expendedoras de Bebidas. Por poner un ejemplo, en el primero los equipos estn instalados en Gasolineras a lo largo de las carreteras, sin embargo, en el segundo pueden estar en Centros Comerciales, en Estaciones de Tren,... incluso en Gasolineras. En el primero, el cdigo de la carretera, el punto kilomtrico y el nombre de la gasolinera (por aquello de que pueda haber varias juntas) localizan al equipo. En el segundo, la poblacin, calle, nombre del centro, localizacin en el centro, se hacen casi imprescindibles. Qu consecuencia inmediata se obtiene de los ejemplos? La bsqueda de la homogeneidad, aunque a veces pueda ser 188

innecesario o reiterativo. La poblacin es una ubicacin genrica para cualquier equipo y ste podra ser el nivel de ms alto rango. Para los siguientes niveles no queda ms remedio, que analizar los posibles emplazamientos. Con la ubicacin ya tenemos compuesta y generada la base de datos de equipos. Del esquema podemos fcilmente adivinar, qu sistemas necesitan estar ligados directamente para su correcto funcionamiento: - El Gestor de Servicios Tcnicos - El GMAO - La Consola de Gestin De los dos ltimos en captulos anteriores hemos comentado, que son aplicaciones software comerciales. El primero para gestionar el mantenimiento y el segundo, como integrador industrial y de telecomunicaciones de los distintos equipos e instalaciones. Tratarlos en profundidad, tanto por la diversidad y extensin de los mismos, se escapa del alcance del libro y no aaden informacin especfica para la comprensin de los Servicios Tcnicos, pero pueden aportar algo de luz, dada la vinculacin entre ellos. Actualmente los sistemas GMAO existentes en las empresas, y la tendencia lo demuestra, son paquetes software (aplicaciones informticas comerciales), los cules, por medio de sus herramientas de programacin, se adaptan a los requisitos y necesidades del mantenedor. Esto es as, consecuencia de la competitividad que promueve continuos cambios de escenario, en los que es ineludible la actualizacin constante de la aplicacin. Pero adems, estn diseadas para integrarse con la mayora de los paquetes software que existen en el mercado, ya sean del mbito de la microinformtica (Word, Excel,...), o especficos de reas, como el diseo asistido por ordenador (CAD), industriales, financieros, etc. Ambos aspectos tienen gran peso en el momento de la decisin a adoptar, pero no es suficiente si, respecto del usuario final, es decir, los responsables de mantenimiento, mandos intermedios, operarios,... no se han tenido en cuenta sus requerimientos o, si al interactuar con la aplicacin, no es intuitiva, no se disponen de los formatos establecidos o las bsquedas se convierten en un ejercicio de habilidad e intuicin. Si adems, la gestin del mantenimiento ya estaba parcial o totalmente informatizada, habr formatos, funciones, flujos de informacin y rutinas, que estaban perfectamente integradas en la actividad diaria, y que ser requisito imprescindible constituirlas en el nuevo aplicativo. El GMAO que se implemente debe facilitar la ayuda y mejorar lo ya existente. NUNCA, convertirse en una complicacin aadida burocratizando la actividad. Las caractersticas esenciales que todo GMAO debera proporcionar son: a. rdenes de Trabajo. Deber ser posible generar bajo demanda, o de manera programada, partes de trabajo (Preventivo, Correctivo...) para todos los equipos integrados en nuestra Base de Datos de equipamiento. Adems debe existir, la posibilidad de imputar los 189

costes derivados de la actividad de mantenimiento a Centros de Costes, Centros de Actividad, Maquinaria, Repuestos, etc. b. Actividades propias y contratadas. La actividad de mantenimiento puede ser realizada por medios propios, externos o mixtos. Para los casos en los que exista contratacin externa, hay un aspecto legal muy importante a considerar, la prestacin laboral. Por ello nuestra herramienta debe contar, con la posibilidad de diferenciar qu tareas son ejecutadas por personal externo o personal propio. El tratamiento interno de cada una de estas ordenes ser igual de cara a la consistencia de la informacin derivada de ellas, pero de cara al exterior, estarn delimitadas claramente las competencias en cada caso. c. Almacn. Controlar las existencias, la realizacin de inventarios,... toda actividad de mantenimiento por regla general lleva asociada, la sustitucin de componentes que debern ser adquiridos en el exterior o tenerlos previamente acopiados en almacenes. Saber si estn en stock, pueden ser adquiridos de forma inmediata, o cuando, ante la disminucin del stock, se debe lanzar una orden de compra, sern funciones que nuestro sistema debe proporcionar. El coste asociado, gestionar proveedores, reservas de material,... funciones adicionales consecuencia de la propia actividad de logstica. Y hablando de logstica, lo racional es que la logstica de mantenimiento est integrada con la logstica general de la empresa y los costes derivados, en las herramientas financieras y econmicas del departamento afn. d. Inventarios. Para poder asociar una orden de trabajo con la instalacin que necesita mantenimiento es requisito imprescindible, que dicho equipamiento exista previamente. Y aqu es aplicable todo aquello que, durante el desarrollo del presente captulo, hemos ido detallando como: requisito mnimo imprescindible, para generar la Base de Datos de equipos. Pero como inventario no estn solamente los implementados para equipos y logstica, si no que el registro de las rdenes de trabajo, personal, ubicaciones,... sern tambin inventarios en nuestro sistema. Con qu ser til contar adicionalmente a los inventarios? Funciones de gestin que permitan la mayor flexibilidad en la obtencin y anlisis de histricos. Disponer de un Gestor Documental integrado que nos permita consultar la documentacin tcnica, as como de las instrucciones, protocolos de intervencin, etc., ser de gran ayuda para el personal operario y tcnico. e. Personal. Siendo una parte ms de nuestros inventarios, lo consideraremos como un tipo peculiar de relacin, pues estar ligado por un lado al departamento de Recursos Humanos (bajas por enfermedad, permisos,...) y que ser necesario disponer para la asignacin de los operarios a las ordenes de trabajo, y por otro, a la propia actividad generada por cada uno de ellos, permitiendo 190

analizarla desde el punto de vista operativo (tiempos, operaciones realizadas,...). f. Planificacin de actividades. Automatizar, debe ser una prioridad en todo sistema. Evitar que el personal dedique tiempo a tareas que pueden ser mecanizadas en la aplicacin, una exigencia. Ya sea por la monitorizacin de los equipos o por la informacin incorporada en las ordenes de trabajo, la planificacin de tareas, fundamentalmente de preventivo, pueden ser realizadas desatendidamente, como consecuencia de la generacin de planes de mantenimiento diseados para cada equipo o tipos de equipo, en funcin de las recomendaciones del fabricante, la actividad del equipamiento, las condiciones de explotacin, etc. g. Interaccin remota. El uso de Terminales Porttiles Lgicos (TPM) a modo de PDAs (Personal Digital Assistant-Asistente Digital Personal), que faciliten el intercambio de informacin con el sistema, agilizando los procesos y las tareas. h. Certificacin. Tanto si el departamento de mantenimiento estaba previamente certificado en ISO, como si forma parte de sus planes de futuro, un GMAO, que no slo por si mismo ya disponga de su propia certificacin ISO, si no que sus mdulos estn construidos orientados en las acreditaciones oficiales ser de gran ayuda, fundamentalmente, en aquellos departamentos que valoren dicha posibilidad. Y cul es la finalidad ltima de todo GMAO? Planteado de otra manera, qu expectativas debe ofrece a aquella organizacin que lo incorpore? La respuesta estar en funcin de las caractersticas que aporte el GMAO, pero para todo departamento de mantenimiento, al esfuerzo que supone reorganizarlo para que en el momento de adquirir la herramienta no se cumpla lo de: Informatizar un departamento desorganizado, es informatizar el caos debe proporcionar resultados muy concretos y evaluables, tanto desde el punto de vista estrictamente tcnico, como desde la operatividad. Estos resultados los podemos agrupar fundamentalmente en: 1Reducir los tiempos de Respuesta. La informatizacin debe facilitar y mejorar los cauces de comunicacin de las incidencias y los sntomas asociados. De esta manera, la intervencin se agiliza y se reduce el tiempo de respuesta. Reducir los tiempos operativos. nicamente es posible realizarlo por medio de histricos, que analicen la reiteracin de los trabajos y operaciones de cada intervencin, ordenndolas. Otra causa significativa para la reduccin de los tiempos operativos es

2-

191

detectar, cmo el preventivo influye positiva o negativamente en el correctivo. 3Reducir el nmero de intervenciones por orden de trabajo. Ligado con el anterior si, en la comunicacin de la incidencia se aporta toda aquella informacin valiosa que permita al operario, no slo conocer el problema, sino disponer de las herramientas, repuestos y documentacin tcnica necesaria, para la restitucin funcional del equipo. El objetivo es una nica intervencin. Y mejor, sobre todo en las grandes corporaciones, detectar cuando la incidencia puede no ser responsabilidad del departamento de mantenimiento y s ser competencia del departamento de operacin, logstica,... Consumo de repuestos. Muchos departamentos de mantenimiento no dedican la suficiente atencin a este aspecto, lo que provoca, no slo una mala gestin en las intervenciones, si no adems, que no sea posible establecer una poltica de costes adecuada, pues los gastos en repuestos no son controlados por una falta de conocimiento del material usado en cada intervencin. Mejora de la disponibilidad (tcnica y operativa). Hasta ahora todo lo expuesto debe tener como consecuencia inmediata, una mejora sustancial en la disponibilidad tcnica y operativa del equipamiento. Reducir tiempos de toda intervencin significa incrementar la disponibilidad. Pero esta disponibilidad puede mejorarse si adems, el sistema proporciona mecanismos que permitan optimizar el mantenimiento, de manera que, puedan aglutinarse simultneamente intervenciones de correctivo, preventivo, o ambas. Mejora de la fiabilidad (averas/operaciones, averas/ciclos, averas/horas,...). Entre los muchos aspectos que debe proporcionar el mdulo de anlisis estn las curvas de regresin, de manera que permitan identificar averas repetitivas y corregir la produccin de las mismas, adecuando tanto las intervenciones de correctivo, como de preventivo, y en su defecto, la necesidad de plantear estudios de reingeniera. Disminucin de los costes. Es quizs el aspecto ms significativo por el cual se justifica la adquisicin de un GMAO, la posibilidad de efectuar los anlisis y valoraciones necesarias que permitan establecer una poltica de costes adecuada para disminuirlos, o en su defecto, cuando es necesario incrementarlos, justificarlos gracias a la aportacin de informacin que el GMAO dispone. Para conseguirlo solo es posible, si estn desglosados e identificados ordenadamente en las correspondientes cuentas. Disminucin del trabajo administrativo . A todos nos suena: el control de los trabajos en libretas..., mltiples versiones fotocopiadas de un plano..., comunicaciones escritas en papel ..., notas adjuntas...,etc., En definitiva papel que lo nico a lo que 192

4-

5-

6-

7-

8-

conduce es a generar caos y desinformacin, operatividad de los departamentos de mantenimiento.

restando

Hemos realizado un planteamiento muy generalista de lo que debe aportar un GMAO y a las respuestas que debe dar cumplimiento, con el fin de proporcionar una idea aproximada al lector de este tipo de herramientas software. Para la Consola de Gestin decir que, desde la perspectiva de herramienta integradora, tiene como propsito dos aspectos muy concretos: 1. Recoger en un repositorio nico todos los datos procedentes de campo, es decir, los estados, alarmas y dems registros generados por el equipamiento y las instalaciones, globalizando la informacin de todo el sistema, permitiendo, entre otras posibilidades, su representacin de forma grfica. 2. Gestionar remotamente principalmente para: el equipamiento e instalaciones,

i. Controlar (parmetros de funcionamiento...). Muchos equipos estn dotados de sensores y dems sistemas de medicin para realizar lecturas de temperaturas, desgastes, funcionamiento, viscosidad,... parmetros que en funcin de los mismos, desencadenan operaciones de preventivo o predictivo, segn sea el caso. Esta lectura realizada remotamente, evita los desplazamientos sistemticos con el consiguiente ahorro en horas de operario. Pero adems, en un entorno integrado con otras aplicaciones (GMAO) y por medio de niveles establecidos (Watchdog, Threshold,...4), es posible que cuando los parmetros superen por exceso o defecto dichos mrgenes de funcionamiento, desencadenar las acciones de mantenimiento asociadas. ii. Mantener (reparar, actualizar...). Actualmente es cada vez ms frecuente, que los equipos posean mecanismos automatizados, ya sean ordenadores industriales o autmatas de control. Esta innovacin permite actualizar el software de control, pero tambin intervenir remotamente para hacer principalmente mantenimientos correctivos. El ahorro en tiempos de desplazamiento, as como el incremento de la disponibilidad, son las mtricas que se ven altamente beneficiadas por ello. Incluso es posible hacer diagnsticos remotos que complementan la informacin de los partes de trabajo del personal

Watchdog de vigilancia; Threshold umbral. Se ponen en ingls por ser usados habitualmente en ese idioma.

193

operario de campo, que in situ debe intervenir en el equipamiento. iii. Supervisar (mtricas de operacin...). En el equipamiento de ltima generacin est implementado la posibilidad, de que el propio equipo informe de las mtricas ms comnmente usadas, como la disponibilidad, fiabilidad, recaudacin,... evitando que sea necesario calcular estos indicadores en sistemas asociados como son, las propias consolas de gestin o los GMAO. En determinado tipo de equipamiento son los SCADA quienes, aprovechando su labor recolectora de la informacin, proporcionan estas mtricas. Las consolas de gestin se caracterizan por su evolucionado interfaz grfico, que permite, entre otras opciones, visualizar el desglose completo de los equipos en sus distintos componentes, facilitando la comprensin del mismo y donde, en un momento determinado, puede estar localizado un fallo. Adems y muy til, para organizaciones que dispongan de un volumen elevado de equipos distribuidos con una alta dispersin geogrfica, es situarlos en un mapa. El ejemplo caracterstico son las redes de comunicaciones, que, adems del mbito geogrfico, permiten representar los enlaces y dependencias entre ellos. Al igual que pasaba con los GMAO, en el mercado podemos encontrar multitud de Consolas de Gestin de diferentes empresas, algunas muy especficas del mundo de las telecomunicaciones y sistemas informticos (Network Node Manager, Tivoli, PATROL,...), y otras ms centradas en el equipamiento industrial (ProficyPortal,,...), aunque esta tendencia, y gracias al uso ya comentado de software estndar, es posible aunar ambos mundos, coexistiendo. Incluso, existen Consolas con tal grado de parametrizacin, que no estn ligadas a ninguno de ellos, como es el caso de WEBTOP basada en entornos Web (System Monitor Configuration Console), cuyo principal atractivo es recoger de manera centralizada la informacin procedente de distintos sistemas y presentarlo de la manera ms eficiente al usuario. Se caracterizan sus implementaciones por: 1 - Gestin de autorizaciones y autentificaciones. 2 - Proporcionar un nico punto de entrada donde localizar toda la informacin. 3 - Interfaz amigable y conocida. Este tipo de implementaciones se caracterizan por modelarse en una arquitectura basada en 3 capas, apoyndose en mdulos ms especficos de herramientas de ms bajo nivel, con tres acciones claramente definidas: Recoleccin: Los elementos recolectores de la informacin relevante que circula por la red de comunicacin entre los equipos y la consola 194

son las sondas. stas captan las alarmas generadas para su posterior tratamiento. Tratamiento: El tratamiento de alarmas se realiza en la base de datos interna residente en memoria, donde se almacena toda la informacin recolectada por las sondas para su procesamiento y gestin (ordenacin, filtrado, asignacin a usuarios,). Posteriormente, se ejecutan procesos de correlacin y enriquecimiento, en los casos que sea necesario, por medio de polticas especficas para cada equipamiento. Presentacin: Para poder tratar las alarmas, stas se muestran va Web, donde los operadores adems de visualizarlas, proceden a realizar las distintas acciones asociadas (reconocimiento, escalamiento, resolucin,...), segn los procedimientos establecidos y ejecucin de las herramientas especficas de gestin del equipamiento, como por ejemplo los SCADAs.

Si la exposicin realizada de estas dos aplicaciones, no fuera suficiente para satisfacer el inters del lector, en libreras especializadas pueden encontrar multitud de tomos dedicados exclusivamente a cada uno de los conceptos, existiendo adems multitud de empresas y profesionales dedicados en exclusividad a dichos productos. La integracin del equipamiento industrial en las consolas de gestin, en los casos que exista, suele realizarse por medio de aplicaciones intermedias conocidas como SCADA (no representado en el esquema). Este tipo de software, al ser casi siempre desarrollado por los propios fabricantes y estar orientado hacia un determinado tipo de equipo, permite modelizar los datos remitidos desde el equipamiento y que tienen que ser registrados en la Consola de Gestin usando protocolos estndar de comunicaciones. Estos datos se almacenarn bajo una nica base de datos. En muchos casos adems, estos SCADAs permiten integrarse dentro de la consola como si formaran parte de la misma, facilitando el trabajo de los tcnicos, operadores y supervisores. Ya sea por medio de los SCADA o directamente conectados a la Consola de Gestin estarn los equipos. Son indiscutiblemente la base de todo Servicio Tcnico y por este motivo, es conveniente, en la medida de lo posible, disponer de la informacin necesaria para una correcta implementacin, ya sea directamente del propio equipo o por medio de sondas de control. Evidentemente, la primera pregunta que debemos hacernos antes de construir nuestro Servicio Tcnico es, si va a ser posible cumplir los requerimientos de diseo con los datos proporcionados por el equipamiento. No tiene sentido continuar si, en un porcentaje muy alto, los datos para la gestin del Servicio Tcnico no se proporcionan. Si as fuera, los planteamientos posibles son: 1. En los equipos que pueda hacerse, implementar la informacin requerida para el Servicio Tcnico. 2. En los equipos que no pueda hacerse optar por: 195

i. Incorporar sondas, tal y como muestra el esquema del comienzo, que permitan disponer de la informacin necesaria. ii. Establecer dichos requerimientos en las futuras adquisiciones de equipos, ya sea por modernizacin o ampliacin. Construir el Servicio Tcnico ser rentable, si an en el caso de tener un porcentaje muy alto de equipos monitorizados, pero no integrables con el Servicio Tcnico, la gestin de los mismos a travs del GMAO y otras Bases de Datos existentes es aceptable, proporcionando al Gestor de Servicios Tcnicos un volumen de informacin tal, que permita representar con una fidelidad admisible el Estado del Servicio. En caso contrario, se debe posponer la construccin del Servicio Tcnico. La informacin bsica para los Servicios Tcnicos que debe reportar todo equipo, dada su importancia, se ha representado en el esquema, Estados y Alarmas. Con estos dos aspectos conoceremos en todo momento, tanto el Estado del Servicio del equipo, como el Estado del Servicio del equipo asociado, en aquellos Servicios Tcnicos donde la prestacin del servicio no dependa exclusivamente del equipo clave como vimos en su momento. Ahora bien, si disponemos de Consola de Gestin, es este sistema quien trasmite el estado y las alarmas. Obvia decir la criticidad, no solo operativa de la misma desde el punto de vista tcnico, si no adems, por su vinculacin (interfaz) con el Gestor de Servicios Tcnicos. El resto de elementos que componen el esquema se refieren al interfaz del usuario, incluyendo la comunicacin de situaciones excepcionales que puedan causar la prdida de servicio en el equipamiento. Esta parte es la ms susceptible de personalizarse, dependiendo de los roles y usuarios definidos en el aplicativo, y la interrelacin con los diferentes responsables del equipamiento. En este captulo nos hemos centrado en comprender lo ms esencial para la creacin de la aplicacin, la base de datos de los equipos y como llega la informacin para evaluar la situacin del equipamiento. El Gestor de Servicios Tcnicos es la aplicacin. Es el motivo de la fase de construccin. Ha llegado el momento de edificar la herramienta.

196

4 LOS PILARES BSICOS

Para construir cualquier edificio, lo principal son unos cimientos slidos. Sean cuales sean las caractersticas y requerimientos del Servicio Tcnico, todos tienen que estar implementados bajo los mismos criterios. Esto significa que la base sobre la que sustentarlos debe ser la misma, con una excepcin, las Incidencias Operativas, que como se explic son propias de cada Servicio Tcnico. El Conjunto de datos maestros y recursos tcnicos sobre los que implementar el Servicio Tcnico le vamos a llamar:

LOS PILARES BASICOS

Durante la segunda parte se han ido mencionando cada uno de ellos. Conviene agruparlos como vertebracin de todo Servicio Tcnico. 4.1 Servicio Tcnico Este primero junto con el siguiente, son muy obvios. Para construir cualquier Servicio Tcnico, lo primero es darle de alta. Todo Servicio Tcnico debe constar como mnimo de un Nombre que lo identifique, una Clave como cdigo referencial, lo ms cmodo es un acrnimo y por ltimo una breve Descripcin, que para no complicarnos usaramos la propia definicin. Nos ser muy til un cuarto campo que llamaremos Estado que nos permitir establecer el contexto operativo. No debe confundirse en ningn momento con el Estado (Situacin Operativa) del equipamiento, al igual que para otros pilares bsicos que incluyan este campo, es esencial desde el punto de vista de la operatividad de la aplicacin, como de la implementacin de cualquier nuevo Servicio Tcnico u otro pilar bsico. Nos permitir establecer el momento de explotacin finalizada la construccin, paradas temporales por mejoras o evolutivos, o simplemente dejar de estar operativo, pero conservando toda la informacin que hasta ese momento estuviera disponible. Por ejemplo: 1. Nombre: MAQUINAS EXPENDEDORAS DE ALIMENTACION 2. Clave: STMEA 3. Descripcin: El conjunto de sistemas electromecnicos ubicados en lugares pblicos, para la adquisicin de productos de consumo de alimentacin humana. 4. Estado: DISPONIBLE 4.2 Situacin del Servicio Tcnico Este segundo pilar no solo va a tener aplicacin en el contexto operativo de cada Servicio Tcnico, si no para cada uno de los restantes pilares bsicos que necesitemos conocer su situacin, establecer, por decirlo de alguna manera, la 197

operatividad en la que se encuentra todo registro en un momento determinado. Permitir, desde el punto de vista informtico, diferentes tratamientos que vendrn condicionados por la gestin que en cada caso sea necesario aplicar y la informacin a obtener. Solo dos campos son necesarios: Clave y Descripcin; y las tres posibles situaciones: a. Disponible. La situacin normal de todo Servicio Tcnico en explotacin. b. Fuera de Servicio Temporal. Para situaciones transitorias en las que deja de estar operativo. Dependiendo del Pilar Bsico que lo incluya ser necesario aplicar, si fuera necesario, los cambios operativos, redistribuciones,... para mantener la integridad de la informacin. c. Fuera de Servicio Permanente. Por ejemplo, un Servicio Tcnico de un Nivel de Agregacin (ver siguiente Pilar) que ya no es necesario. Dependiendo del Pilar Bsico que lo incluya, ser necesario aplicar los cambios operativos, redistribuciones, ... para mantener la integridad de la informacin. Un ejemplo para el Servicio Tcnico de cajeros podra ser: ESPAA: Estado Disponible. a. MADRID: Estado Disponible. i. ii. iii. Madrid: Estado Disponible Mstoles: Fuera de Servicio Temporal (Se est definiendo) Legans: Estado Disponible

b. ANDALUCA: Estado Disponible i. ii. iii. iv. c. Cdiz: Estado Disponible Sevilla: Estado Disponible Mlaga: Fuera de Servicio Temporal (Suspendido temporalmente) Crdoba: Fuera de Servicio Permanente

EXTREMADURA: Fuera de Servicio Temporal (Se est definiendo) i. ii. Cceres: Fuera de Servicio Temporal (Se est definiendo) Badajoz: Fuera de Servicio Temporal (Se est definiendo) 198

d. CATALUA: Estado Disponible i. ii. iii. Barcelona: Estado Disponible Gerona: Estado Disponible Lrida: Fuera de Servicio Temporal (Se est definiendo)

4.3 Nivel de Agregacin Examinemos la siguiente imagen:

Como se explic, para conformar un Servicio Tcnico lo primero es identificar a los equipos claves, para a continuacin aglutinarlos por taxonoma, mbito geogrfico (o el que corresponda)... y as sucesivamente. Las sucesivas agrupaciones es lo que denominamos Nivel de Agregacin, y es necesario definirlos, para que la aplicacin pueda ir calculando los indicadores que se diseen segn sea el nivel que se consulte. Podramos decir que consiste en definir la estructura jerrquica sobre la cual se van a crear y detallar posteriormente los Niveles de Agregacin del Servicio. Evidentemente puede haber dos o ms Servicios Tcnicos que compartan iguales niveles de agregacin, como por ejemplo, el Servicio Tcnico de cajeros bancarios y el de surtidores de combustible. Tres campos son suficientes:

199

1. Clave. Un cdigo de referencia. Palabra que permita por si misma identificar el nivel de agregacin. 2. Descripcin. Un breve comentario. La propia definicin podra ser vlida. 3. Estado. El contexto operativo. Por ejemplo, para el Servicio Tcnico de la red de cajeros de un banco segn la imagen, los diferentes Niveles de Agregacin son: PAS. Sera el nivel superior o Global. COMUNIDAD. En este nivel se crearn los Niveles de Agregacin del Servicio, en todas las comunidades donde opere el banco. CIUDAD. En este nivel se crearn los Niveles de Agregacin del Servicio, en todas las ciudades de cada comunidad donde opere el banco.

El nivel ms bajo o primario no es necesario definirlo, ya que lo constituyen los equipos y/o instalaciones. Si para el Servicio Tcnico de los cajeros hubiese sido interesante diferenciar por el tipo de cajero, deberamos aadir tantos Niveles de Agregacin como taxonomas a controlar (marcas, marcas y modelos...). 4.4 Nivel de Agregacin del Servicio Tcnico Propiamente es el apartado donde se desglosa cada Servicio Tcnico. Consiste en definir la estructura en rbol con los diferentes Servicios que lo componen. Los campos que vamos a necesitar son: 1. Nombre. Es el campo identificativo del Nivel de Agregacin de Servicio. Puede ser una clave, o unas pocas palabras que lo identifique. 2. Descripcin. Un breve comentario. 3. Servicio Tcnico. A que tipo de Servicio Tcnico corresponde (apartado 4.1). 4. Nivel de Agregacin. Para implantarlo dentro de la estructura jerrquica (apartado 4.3). Partiendo del ejemplo anterior, PAIS, COMUNIDAD.... 5. Estado. El contexto operativo (apartado 4.2). 6. Desglose. Los Niveles de Agregacin de Servicio hijos que lo conforman, o planteado desde otro punto de vista, que jerrquicamente dependen de l.

200

Con los pilares vistos hasta ahora estamos en disposicin de plantear un caso concreto, que para mejor comprensin, mostramos en formato de tabla. Para abreviarlo no se incluye el campo Descripcin:
Nombre (Nivel de Agregacin de Servicio Servicio Tcnico) Tcnico Cajeros ESPAA Nivel de Agregacin Situacin Estado Disponible

CAJEROS Global

Cajeros MADRID Cajeros Madrid Cajeros Mstoles Cajeros Legans Cajeros ANDALUCIA Cajeros Cdiz Cajeros Sevilla Cajeros Malaga Cajeros Crdoba

CAJEROS Comunidad CAJEROS Ciudad CAJEROS Ciudad CAJEROS Ciudad CAJEROS Comunidad CAJEROS CAJEROS CAJEROS CAJEROS Ciudad Ciudad Ciudad Ciudad

Estado Disponible Estado Disponible Fuera de Servicio Temporal Estado Disponible Estado Disponible Estado Disponible Estado Disponible Fuera de Servicio Temporal Fuera de Servicio Permanente Fuera de Servicio Temporal Fuera de Servicio Temporal Fuera de Servicio Temporal Estado Disponible Estado Disponible Estado Disponible Fuera de Servicio Temporal

Desglose Cajeros MADRID Cajeros ANDALUCIA Cajeros EXTREMADURA Cajeros CATALUA Cajeros Madrid Cajeros Mstoles Cajeros Legans Equipos Equipos Equipos Cajeros Cdiz Cajeros Sevilla Cajeros Malaga Cajeros Crdoba Equipos Equipos Equipos Cajeros Cceres Cajeros Badajoz Equipos Equipos Cajeros Barcelona Cajeros Gerona Cajeros Lrida Equipos Equipos Equipos

Cajeros EXTREMADURA CAJEROS Comunidad Cajeros Cceres Cajeros Badajoz Cajeros CATALUA Cajeros Barcelona Cajeros Gerona Cajeros Lrida CAJEROS Ciudad CAJEROS Ciudad CAJEROS Comunidad CAJEROS Ciudad CAJEROS Ciudad CAJEROS Ciudad

4.5 Rangos Horarios En los captulos previos se ha tratado en profundidad la problemtica de los horarios y su impacto. Para este primer acercamiento a los Servicios Tcnicos, vamos a partir de la implementacin ms simple posible. Todo horario vendr condicionado lgicamente por las horas de comienzo y fin, pero tambin por el da de la semana, el da del mes y el mes. La complejidad de disear Servicios Tcnicos con horarios cuya implementacin llegue hasta el nivel de mes, no lo es tanto por el propio horario, como s lo es por la implementacin de los equipos, tal y como se apunt en su momento. Inicialmente solo es factible en Servicios Tcnicos con una estabilidad elevada (pocos cambios y pocas altas en el tiempo), pues si no es as, las tareas de implementacin, pero sobre todo las de mantenimiento, pueden resultar largas y tediosas, y casi con toda seguridad, muy susceptibles de cometer errores por parte de los responsables de dicha actividad. Las caractersticas mnimas esenciales que debe tener todo horario son: 201

a. El rango de horas vlido. b. Los das de la semana que aplica. Sabiendo que debe cumplir las dos caractersticas descritas, los siguientes campos nos ayudarn a verificarlos: 1. Clave del horario. El cdigo del horario. 2. Descripcin. Un breve comentario. 3. Hora de inicio. Para facilitar la implementacin, en formato de 24 horas. 4. Hora de fin. Igual que el campo anterior. 5. Das de la semana. La seleccin de das en los cuales el horario tiene vigencia. Una manera sencilla de tratar este campo es proporcionar los siete das de la semana y por medio de una marca (flag), indicar si aplica o no. Por ejemplo: 1. Clave: H4 2. Descripcin. Rango horario desde las 02:00 horas a las 06:00 horas. 3. Hora de inicio: 02:00 4. Hora de fin: 06:00 5. Das de la semana. SD (Sbados y Domingos) Como consideracin especial, es importante en el momento de dar de alta los equipos dentro de un mismo Servicio Tcnico, no escoger horarios que se solapen en el mismo da. La razn es obvia. Generaramos una dicotoma tcnica sobre la mtrica a mostrar, consecuencia de los diferentes Pesos Operativos en cada uno de los horarios durante el periodo de tiempo coincidente. Ejemplo: Equipo 1, Peso Operativo 34%, Rango horario de 15:00 a 22:00 horas Equipo 1, Peso Operativo 23%, Rango horario de 18:00 a 24:00 horas 4.6 Situacin Operativa del equipamiento Para poder medir el indicador Estado de Servicio, es necesario conocer la Situacin Operativa del equipo clave. Los Estados a dar de alta dependern de cada Servicio Tcnico construido. Cuanto ms queramos precisar la informacin complementaria sobre los equipos, ms Situaciones Operativas deberemos dar de alta. Recordemos algunos ejemplos expuestos en la segunda parte: En Servicio (fundamental). Parada Manual. 202

Parada por Mantenimiento. Parada por Avera. Parada por Incidencia Tcnica en el Servicio. Parada por Falta de Tensin. Desconocido (opcional). Siempre que tengamos equipos e instalaciones monitorizados.

Como aplicar cada uno de los Estados, ser el resultado de la informacin recolectada (alarmas y/o incidencias) y la aplicacin de las matrices; clculo que ser parte de la programacin de la aplicacin. 4.7 Incidencias Operativas De igual manera que es necesario conocer la Situacin Operativa, en aquellos Servicios Tcnicos con merma de la oferta de servicio, pero sin llegar a la anulacin, es necesario definir las Incidencias Operativas para, segn el Peso Tcnico que le corresponda, degradar la parte de servicio que se deja de prestar. Inicialmente sern propias de cada Servicio Tcnico, aunque puede darse la coincidencia de que una misma Incidencia Operativa pueda ser aplicada en Servicios Tcnicos diferentes. Una buena iniciativa para permitir mayor flexibilidad en la asignacin del Peso Tcnico, es definir y asociar las incidencias Operativas a los catlogos del tipo de equipo, permitiendo que, en lugar de ser un porcentaje que haya que asignar individualmente a cada equipo (la peor situacin por el esfuerzo a realizar en el mantenimiento de los datos) o aplicarla por igual a todos los equipos (situacin cmoda respecto al mantenimiento de los datos, pero que no aporta flexibilidad), se distribuyan en funcin de las caractersticas compartidas. Los campos necesarios son: 1. Clave de la Incidencia Operativa. El cdigo de la Incidencia Operativa. 2. Descripcin. El nombre propiamente de la Incidencia Operativa. 3. Estado. El contexto operativo. 4.8 Reglas de las Incidencias Operativas En la segunda parte comentamos, que en algunos Servicios Tcnicos puede darse la circunstancia de que dos o ms Incidencias Operativas anulen el servicio, sin que sea condicin obligatoria que todas las Incidencias Operativas estn activas; o que no puedan darse dos ms de ellas simultneamente. Cualquiera que sea la regla que sea necesario aplicar, segn sea la casustica analizada, ser necesario implementarla en la aplicacin. Los campos imprescindibles son: 203

1. Clave de la regla. El cdigo. 2. Descripcin. La regla propiamente. 3. Resultado. El porcentaje que se debe aplicar, en lugar del resultado proporcionado por el sumatorio del porcentaje asociado al Peso Tcnico de cada Incidencia Operativa. En caso de estar vaco, ser el sumatorio de los Pesos Tcnicos de las Incidencias Operativas activas. 4.9 Tipos de Impacto Definimos como Tipos de Impacto, un Tipo de Relacin (apartado 4.12) entre el equipamiento implicado y el equipo clave. Los Tipos de Impacto segn su alcance pueden ser de dos clases: I.) Los que anulan el servicio. II.) Los que degradan el servicio. En este caso, al tipo de impacto se le asocian las Incidencias Operativas correspondientes a la degradacin y repercutibles sobre los equipos clave, el equipamiento implicado, o ambos. Solo el Peso Tcnico asociado a la Incidencia Operativa del equipo clave, ser el valor a considerar para calcular la degradacin correspondiente. Definido el Tipo de Impacto, se genera la Matriz de Estados de Equipos Implicados (apartado 4.11), para determinar la Situacin Operativa del equipo clave en funcin de la Situacin Operativa en el equipo implicado. Dependiendo del mbito de aplicacin los Tipo de Impacto pueden ser: I.) Genricos. De aplicacin en todos los Servicios Tcnicos. Este grupo lo conformarn de manera general, los Tipos de Impacto que anulen el servicio. II.) Particulares. En el mbito de uno o varios Servicios Tcnicos. En este grupo sern mayora los Tipos de Impacto que degraden el servicio. 4.10 Matriz de Estados de Equipos Clave Las matrices se establecen para conocer la prioridad de un Estado sobre otro. Por ejemplo, si en un equipo monitorizado que est en Parada por Avera se pierde su comunicacin, no debe NUNCA pasar a Estado Desconocido, ya que antes de perder su conectividad el equipo no prestaba servicio (Estado de Servicio 0%) y no parece tico por el simple hecho de perder su conectividad, pasar a dar una cifra de Estado de Servicio diferente. Otra cuestin es como solventar si durante el periodo de tiempo que no existe comunicacin, el equipo recupera su funcionalidad y presta servicio, pero no es un detalle a establecer en este

204

apartado; formar parte de los mecanismos de control desarrollados con la construccin del aplicativo. Dijimos que un aspecto a tener muy en cuenta era la homogeneizacin de cada uno de los Servicios Tcnicos. Ya sean equipos clave o equipos implicados, para los mismos Estados iniciales, con el nuevo Estado reportado, se deben obtener los mismos Estados finales. Como consecuencia, ste es posiblemente uno de los Pilares Bsicos ms sencillos, pues tericamente existir una nica Matriz que incluir todos los Estados definidos. No obstante y como mejora funcional a la herramienta que construyamos, podemos definir una Matriz genrica como garante del comportamiento de los equipos, pero si por los condicionantes del Servicio Tcnico, el equipamiento no fluye entre los Estados del mismo modo conceptual que en los otros de Servicios Tcnicos, podemos disear la capacidad de establecer Matrices de Estados de Equipos Clave particulares y en el caso de no tener definida matriz alguna, que aplique la genrica. Un ejemplo de Matriz de Estados, con algunos de los Estados definidos en el apartado 4.6 sera:
Estado Inicial DESCONOCIDO DESCONOCIDO DESCONOCIDO DESCONOCIDO DESCONOCIDO EN SERVICIO EN SERVICIO EN SERVICIO EN SERVICIO EN SERVICIO PARADA MANUAL PARADA MANUAL PARADA MANUAL PARADA MANUAL PARADA MANUAL PARADO POR INCIDENCIA TECNICA EN EL SERVICIO PARADO POR INCIDENCIA TECNICA EN EL SERVICIO PARADO POR INCIDENCIA TECNICA EN EL SERVICIO PARADO POR INCIDENCIA TECNICA EN EL SERVICIO PARADO POR INCIDENCIA TECNICA EN EL SERVICIO Estado Nuevo DESCONOCIDO EN SERVICIO PARADA MANUAL PARADA SIN TELEMANDO PARADO POR INCIDENCIA TECNICA EN EL SERVICIO DESCONOCIDO EN SERVICIO PARADA MANUAL PARADA SIN TELEMANDO PARADO POR INCIDENCIA TECNICA EN EL SERVICIO DESCONOCIDO EN SERVICIO PARADA MANUAL PARADA SIN TELEMANDO PARADO POR INCIDENCIA TECNICA EN EL SERVICIO DESCONOCIDO EN SERVICIO Estado Final DESCONOCIDO EN SERVICIO PARADA MANUAL PARADA SIN TELEMANDO PARADO POR INCIDENCIA TECNICA EN EL SERVICIO DESCONOCIDO EN SERVICIO PARADA MANUAL PARADA SIN TELEMANDO PARADO POR INCIDENCIA TECNICA EN EL SERVICIO PARADA MANUAL EN SERVICIO PARADA MANUAL PARADA MANUAL PARADO POR INCIDENCIA TECNICA EN EL SERVICIO PARADO POR INCIDENCIA TECNICA EN EL SERVICIO

EN SERVICIO PARADO POR INCIDENCIA PARADA MANUAL TECNICA EN EL SERVICIO PARADO POR INCIDENCIA PARADA SIN TELEMANDO TECNICA EN EL SERVICIO PARADO POR INCIDENCIA PARADO POR INCIDENCIA TECNICA EN EL SERVICIO TECNICA EN EL SERVICIO

205

4.11 Matrices de Estados de Equipos Implicados Como lo ms lgico es que los equipos implicados sean diferentes en cada uno de los Servicios, y an pudiendo ser los mismos no tienen por qu afectar del mismos modo, habr tantas Matrices de Estados de Equipos Implicados, como circunstancias operativas puedan identificarse para cada Servicio Tcnico, incluidas las que son consecuencia de las Incidencias Operativas. Las Matrices de Estados de Equipos Implicados, por derivar directamente de los Tipos de Impacto, tambin pueden ser: I.) Genricas. De aplicacin en todos los Servicios Tcnicos. II.) Particulares. En el mbito de uno o varios Servicios Tcnicos. En la mayora de los casos, suelen tener asociadas una o varias Incidencias Operativas. Un ejemplo de Tipo de Impacto genrico (no tiene asociado ninguna Incidencia Operativa) Afecta Equipo Clave Parado sera:

Estado Inicial Equipo Clave DESCONOCIDO DESCONOCIDO EN SERVICIO EN SERVICIO PARADA MANUAL

Nuevo Estado Equipo Relacionado PARADA MANUAL PARADO POR INCIDENCIA TECNICA EN EL SERVICIO PARADA MANUAL PARADO POR INCIDENCIA TECNICA EN EL SERVICIO PARADO POR INCIDENCIA TECNICA EN EL SERVICIO

Estado Final Equipo Clave PARADA MANUAL PARADO POR INCIDENCIA TECNICA EN EL SERVICIO PARADA MANUAL PARADO POR INCIDENCIA TECNICA EN EL SERVICIO PARADO POR INCIDENCIA TECNICA EN EL SERVICIO

El resto de Estados, si tenemos en consideracin el orden prioritario establecido en la Matriz de Equipos Clave del apartado 4.10, no son aplicables. 4.12 Tipos de Relaciones Los Tipos de Relaciones permiten definir como es el prototipo de relacin entre el equipamiento participante de un Servicio Tcnico. Definir los Tipos de Impacto y las Matrices de Estados de Equipos Implicados no tendra sentido, si despus no estableciramos que equipamiento implicado afecta a que determinados equipos claves. Los dos tipos bsicos para todo Servicio Tcnico son: I.) Equipos. Son tipos de relaciones de Categora (apartado 4.13) genrica, sin Tipo de Impacto, en la que se agrupan equipos fundamentalmente por proximidad geogrfica. Este tipo es muy interesante darlo de alta pues reduce el mantenimiento entre las 206

relaciones equipo-equipo, fundamentalmente, en los casos en los que un conjunto determinado de equipos implicados afectan a los mismos equipos clave, independientemente del Tipo de Impacto. II.) Jerrquica. Se aplican a las relaciones con Tipo de Impacto definido para determinar la Situacin Operativa del Equipo Clave (apartado 4.11) y la o las Incidencias Operativas asociadas si las hubiera. Como su propio nombre indica, la relacin as constituida establece las dependencias subordinadas de los equipos clave frente a sus equipos relacionados. Y en los Servicios Tcnicos que sea necesario... III.) Cluster. El tercer tipo bsico que exponemos es un caso muy peculiar. Con el ejemplo que comienza el captulo 3 de la segunda parte es fcil intuir, que en muchos Servicios Tcnicos van a existir equipos replicados, generalmente de iguales caractersticas. La razn de ello es garantizar la continuidad de las funcionalidades que realice. Para esos casos donde existen dos o ms equipos realizando la misma funcin simultneamente (redundancia), este tipo de relacin es primordial, pues en lugar de establecer una relacin por cada equipo, lo que provocara disfunciones obvias de control ante la cada de uno de ellos ya que el servicio se degradara o anulara cuando sus homlogos mantienen las prestaciones, en las de tipo Cluster, solo ante el fallo definido (Parada o Incidencia Operativa) de todos los equipos que conforman la relacin Cluster, los equipos claves se veran afectados. Los casos tpicos de las relaciones Cluster suelen ser los servidores informticos de bases de datos o los equipos de comunicaciones (redes informticas). 4.13 Relaciones Sntoma-Estado-Incidencia Operativa La Situacin Operativa del Equipo Clave va a estar en funcin del: - Estado de partida - Nuevo Estado reportado - La aplicacin de la Matriz correspondiente en cada caso. Pero para conocer el Estado reportado, ya sea del equipo clave o del equipamiento implicado, solo es posible o por medio de la monitorizacin o de los registros de incidencias (tcnicas, operativas, explotacin, logsticas...), incluidas las comunicaciones directas por situaciones excepcionales. Cuando sea necesario conocer el Estado por medio de las incidencias puede suceder que: a. La incidencia informe de la Situacin Operativa. La aplicacin es directa en estos casos y no es necesaria la relacin.

207

b. Si no lo indica, es necesario relacionar en el Gestor de Servicios Tcnicos, el o los Sntomas recogidos en el parte de incidencias con el Estado. c. Si el equipo tiene degradacin de servicio, es necesario relacionar el o los Sntomas, adems de con el Estado, con las posibles Incidencias Operativas. El formato de las relaciones Sntoma-Estado-Incidencia Operativa a implementar en la herramienta ser similar al formato de las matrices. Por ejemplo: Grupo Sntomas
ALARMA-63 METTA5 SIN COMUNICACIN

Estado
EN SERVICIO

Incidencia Operativa
SIN PAGO ELECTRNICO

Esta clase de relaciones, condicionadas por participar en ellas las Incidencias Operativas, tambin estarn definidas a nivel de catlogo de equipos. 4.14 Relaciones Alarma-Estado-Incidencia Operativa Es la misma casustica que para el apartado anterior, pero donde se relaciona la alarma con el Estado y en donde aplique, la Incidencia Operativa. Las relaciones Alarma-Estado-Incidencia Operativa tambin se definen a nivel de catlogo de equipos. Por ejemplo: Alarma
131

Estado
PARADO POR INCIDENCIA TECNICA EN EL SERVICIO

Incidencia Operativa

4.15 Relaciones de equipos Segn el apartado 4.12, inicialmente solo son necesarias para construir un Servicio Tcnico, las relaciones de Equipos, Jerrquicas, y extraordinariamente las de tipo Cluster. Para entender ms estos tres Tipos y las facilidades aportadas de cara al mantenimiento de los datos, conceptualmente, las Relaciones en las que participen equipos (es posible hacerlo extensible al resto de relaciones que se diseen para cualquier Servicio Tcnico) son: 1. Equipos. Es un conjunto de equipos (Tipo genrica 4.12) Ejemplo: Relacin de equipos clave tipo A 2. Equipo a Equipo. Cuando un equipo implicado, anula el servicio en el equipo clave.

METTA-Mquina Expendedora de Ttulos de Transporte Automtica

208

Ejemplo: Equipo implicado tipo A Tipo de Impacto Equipo clave tipo B 3. Equipo a Relacin. Cuando un equipo implicado afecta, a un conjunto de equipos clave. Ejemplo: Equipo tipo A Tipo de Impacto Relacin de equipos clave tipo B 4. Relacin a Equipo. Cuando un conjunto de equipos implicados, afecta por igual a un equipo clave. Ejemplo: Relacin de equipos implicados tipo A Tipo de Impacto Equipo clave tipo B 5. Relacin a Relacin. Cuando un conjunto de equipos implicados afecta por igual a un conjunto de equipos clave. Ejemplo: Relacin de equipos implicados tipo A Tipo de Impacto Relacin equipos clave tipo B Las ventajas son significativas, ya que al hacer agrupaciones y establecer las relaciones por medio de ellas, simplifica las tareas de mantenimiento en los casos de sustitucin de equipos. 4.16 Pesos Operativos Aunque tratado casi en ltimo lugar, es el PILAR sobre el que sustentar los Servicios Tcnicos. El mtodo por medio del cual establecer la contribucin porcentual, tanto de los equipos como de los niveles definidos. En el apartado 4.4 se expuso como se crean los Niveles de Agregacin del Servicio. Por ello, segn se genera la estructura jerrquica, la aplicacin debe proporcionar el campo para asociar el Peso Operativo. Las reglas de clculo se programan en la propia aplicacin. En segundas partes (o terceras,... depender de la evolucin de la herramienta) plantearemos como hacer que la aplicacin sea lo ms parecido a un sistema experto, permitiendo que las reglas de clculo y control, se definan a nivel de interfaz de usuario y no embebidas en el cdigo. Pero como se dice comnmente, comencemos la casa por los cimientos. Si adems se han definido horarios de funcionamiento, los Pesos Operativos de cada equipo vendrn determinados por cada uno de los horarios asociados. 4.17 Interfaces de Carga-Descarga Dar de alta un Servicio Tcnico por completo puede convertirse en una tarea ardua, montona y de muy larga duracin; incluso, modificar sustancialmente la informacin. Para agilizar ambas situaciones y a la vez facilitar una herramienta de control ms operativa que la propia aplicacin en s es, permitir que las altas o modificaciones de los datos se puedan hacer de forma masiva por medio de interfaces de carga y descarga. La generacin de vistas en forma de tabla, con los registros en cada una de las lneas y los campos en las columnas es lo ms apropiado; y para ello el formato ms usado habitualmente son las hojas de 209

clculo. Los Pilares Bsicos ms susceptibles de incorporar esta opcin son: los Pesos Operativos (la distribucin de los Pesos Operativos segn el Nivel de Agregacin de Servicio consultado) y las Relaciones en general.

210

5 FLUJO DE CONTROL
Conocidos los Pilares Bsicos sobre los que vertebrar la construccin de cada Servicio Tcnico, es crucial saber como interactan entre ellos, fundamentalmente los consultivos, para determinar la Situacin Operativa, el Estado de Servicio y el resto de indicadores implementados. Las mtricas que construyamos van a depender, adems del grado de fidelidad de la informacin procedente de campo y bases de datos asociadas, del tratamiento que se le de. Es obligatorio, no solo contar con la informacin correctamente definida en la herramienta informtica, si no que el modo de aplicarla durante todo el proceso sea, adems de adecuado, preciso. Un esquema que represente el flujo de informacin y los puntos clave del proceso, ser de gran ayuda. Cuanto ms detallado, mejor. En el siguiente esquema se muestra condensado, que pilares fundamentales intervienen y la secuencia lgica de tratamiento de la informacin:
Pesos Tcnicos y Reglas Incidencias Operativas

Relaciones Sntomas I. Operativas

Relaciones Alarmas I. Operativas

Alarma o Incidencia

Servicio Tcnico
Equipos Implicados

Equipos Clave

Matriz Equipos Clave

Situacin Operativa

Nivel de Agregacin de Servicio

Estado del Servicio

Relaciones de equipos

Tipos de Impacto

Matriz Equipos Implicados

Pesos Operativos

Matriz Equipos Clave Pesos Tcnicos y Reglas

Relaciones Alarmas I. Operativas

Relaciones Sntomas I. Operativas

Rangos Horarios

Incidencias Operativas

Ante la llegada de una Incidencia o Alarma, el primer paso es discriminar si el equipo es clave o implicado. La secuencia aplicada vara aunque bsicamente sean muy semejantes los tratamientos, pues el resultado en ambos casos debe ser el mismo: determinar la Situacin Operativa y los indicadores asociados para cada nivel de agregacin afectado, segn el esquema de construccin que se haya implementado y en base a los Niveles de Agregacin de Servicio dados de alta. No obstante, para 211

conseguir que la herramienta que estamos construyendo sea lo ms estndar posible, es primordial que cada Servicio Tcnico sea lo ms homogneo respecto de otros ya implementados, y para ello, hay que exigirle que se ajuste al Diagrama de Flujo de Control. Un aspecto que puede llevar a confusin segn se observa el esquema, es la aplicacin de la Matriz de Equipos Clave al equipamiento implicado. La razn es evidente, los pasos a seguir para determinar la Situacin Operativa de cualquier equipo implicado son los mismos que para los equipos clave, y no sera lgico duplicarlo en el sistema matrices si la evolucin de la Situacin Operativa debe ser siempre idntica para todo el equipamiento, independientemente del Servicio Tcnico que sea. Por medio del Diagrama de Flujo de Control podemos visualizar como fluye la informacin para el clculo, en este caso del indicador Estado del Servicio. Lgicamente, representar con ms o menos detalle, tantos diagramas como indicadores se diseen, beneficia la construccin e implementacin y no slo para los indicadores. De cualquier informacin relevante, ver su ciclo o proceso, mejorar sin lugar a dudas los resultados y la fidelidad de los mismos.

212

6 CAMBIO DE ESTADO BAJO DEMANDA

El Cambio de Estado Bajo Demanda es una de las opciones a implementar en la aplicacin con ms alcance y utilidad del que inicialmente podamos imaginar. El por qu de implementar esta opcin, que fue comentada muy someramente en el captulo 2, es para dar respuesta a situaciones relacionadas con la actividad en los equipos e instalaciones que no se controlan en tiempo real, como son por ejemplo paradas provocadas por causas ajenas al Servicio Tcnico. En lneas generales, qu significa cambiar el estado bajo demanda? Cambio de Estado Bajo Demanda supone modificar la Situacin Operativa activa por otra de las que se hayan asociado al equipamiento, y esta operativa siempre es realizada mediante el interfaz adecuado en la aplicacin por los usuarios. Para conocer realmente no slo el alcance de semejante utilidad, sino para determinar el impacto de implementarlo, lo mejor es detallar las principales circunstancias en las cuales es necesario cambiar el Estado del equipo bajo demanda. La primera ya est comentada sobradamente. Cuando el equipamiento no est monitorizado, las paradas voluntarias para realizar intervenciones programadas (por ejemplo mantenimientos preventivos) slo pueden repercutirse en la aplicacin si mediante los procedimientos establecidos, se comunican dichas intervenciones y se acta cambiando su estado por el de Parada Manual . Como se explic en la parte segunda, este Estado se aplicaba cuando un equipo no presta servicio por un acto voluntario y no tiene asociada ninguna avera. La segunda de las opciones tambin se ha comentado en algn momento. Podemos detectar situaciones en las que por un error en la implementacin, los clculos, fallos de diseo, de integracin, etc. el Estado de un equipo no corresponde con su Situacin Operativa real. Dependiendo del tiempo requerido para subsanar el problema y el impacto que pueda suponer mantener la informacin errnea, las decisiones a adoptar pueden ser dos:
Eliminar temporalmente dicho equipo del Servicio Tcnico. Corregir su estado en la aplicacin a travs de la opcin del cambio

bajo demanda. Prcticamente con las dos opciones expuestas, hemos justificado, en lneas generales, la necesidad del Cambio de Estado Bajo Demanda. Pero conviene especificar una ms de gran impacto y alcance para comprender fundamentalmente como se puede desvirtuar la informacin, si no se dispone de la posibilidad de actuar en la Situacin Operativa. Son las conocidas como Situaciones Excepcionales. Estas situaciones son provocadas por derrumbamientos, filtraciones, intervenciones policiales, cambios puntuales de operacin o explotacin , Todos estos tipos de contexto slo es posible conocerlos si existe el mtodo apropiado de comunicacin,

213

ya que no hay incidencia registrada de ningn tipo y si la hay, generalmente no define el equipamiento afectado motivado por la situacin excepcional. Para aportar el mejor de los controles, si cuando se modifica el Estado manualmente existe un campo de observaciones, se podr incorporar una explicacin del por qu del cambio. Rizar el rizo es definirle el periodo de validez. Transcurrido ese tiempo, el equipo tendr la Situacin Operativa consecuencia de la monitorizacin o las incidencias activas. Pero la ventaja de poder actuar sobre el Estado manualmente no reside exclusivamente en el hecho de hacerlo, sino de que dicho cambio tenga un efecto permanente o temporal. Ante errores puntuales interesa corregir su Estado, pero que cualquier informacin que modifique la Situacin Operativa, se procese automticamente segn se ha ido tratando a lo largo del libro. Sin embargo, para las situaciones excepcionales, el cambio de Estado debe continuar en el tiempo mientras no haya variaciones que as lo indiquen o se vuelva a las condiciones normales de explotacin (oferta del servicio). Para poder aplicar ambos aspectos, definimos un nuevo Estado cuya caracterstica principal es que no es una Situacin Operativa como tal definida, sino un tratamiento interno del Estado en si que va a permitir bloquear o no el Estado aplicado. Se le define como Estado Automtico, de manera que una vez aplicado el nuevo Estado al equipo, a continuacin, aplicamos el Estado Automtico para que toda la informacin que sea susceptible de modificar la Situacin Operativa sea procesada. Si por contra realizamos el Cambio de Estado y no aplicamos a continuacin este nuevo estado definido, el Estado escogido se mantendr sine de hasta que no se aplique el Estado Automtico. Las razones de cuando est justificado intervenir en la aplicacin para alterar el Estado activo de un equipo estn expuestas. Llevarlo a trmino o no, ser decisin final y responsabilidad de los usuarios en funcin de los procedimientos operativos definidos.

214

7 COMO MOSTRAR LOS DATOS DEL SERVICIO TECNICO

No parece lo ms elegante decir como deben ser presentados los datos del Servicio Tcnico a los usuarios. Los diseadores en colaboracin con los usuarios tienen mucho que aportar, haciendo lo ms amigable e intuitiva la navegacin por las distintas pantallas de informacin. Pero independientemente del alcance grfico que se muestre, es posible establecer una serie de criterios a tener en cuenta como orientacin para el interfaz grfico de los diferentes usuarios. Un entorno Web parece lo ms indicado, ya que est generalizado su uso gracias a Internet, y el usuario, se sentir familiarizado con las opciones generales. Para el programador, HTML, XML, Java, son lenguajes de programacin de uso muy comn en dicho entorno. La informacin bsica que debera mostrarse para el indicador Estado del Servicio, como parte del interfaz grfico del usuario es: 1. Datos generales del nivel de agregacin del Servicio Tcnico seleccionado. 2. Las cifras correspondientes al Estado de Servicio (Prestacin de Servicio...) del nivel de agregacin, y la fecha y hora correspondiente a dicho valor. Puede ser muy til mostrar adicionalmente un histrico de los Estados del Servicio previos con su fecha y hora. 3. El nmero de equipos en cada una de las Situaciones Operativas e Incidencias Operativas cuando aplique, de los niveles de agregacin inferiores. 4. Los servicios del Nivel de Agregacin inmediatamente inferior, con su Peso Operativo asociado, Estado del Servicio y la fecha y hora correspondiente a dicho valor.

215

Ejemplo de pantallas de usuario actualmente en explotacin, donde se muestra la informacin ms relevante comentada:

Segn naveguemos por los niveles de agregacin inferiores, el formato de presentacin de los datos se mantienen. 216

Pero para tener un control visual inmediato del Estado del Servicio, mucho ms cmodo que ver una cifra, es verla dentro de un reloj a modo de termmetro o velocmetro. El Estado del Servicio es un Indicador en tiempo real y nada mejor, que mediante una rpida visualizacin tener la percepcin del mismo. Para ello es til disear una pantalla adicional, donde continuamente se est, dependiendo del Nivel de Agregacin escogido, indicando el Estado del Servicio por medio de colores, aunque adicionalmente contenga el valor correspondiente. Es lo que se conoce como MONITOR, pues refleja la situacin operativa de modo grfico. Ejemplo en explotacin:

Para cada nivel debe personalizarse el color a mostrar, pues dependiendo de las condiciones de operacin, la misma cifra en unos casos puede ser aceptable y en otras crtico. Analicemos el siguiente ejemplo: Una gasolinera con 9 surtidores y otra con 3, y supongamos las siguientes situaciones simultneas: La primera gasolinera tiene 3 surtidores estropeados. La segunda gasolinera tiene 1 surtidor estropeado.

El Estado de Servicio en ambos casos es del 66%, pero en la primera gasolinera si se estropea otro surtidor, el nuevo Estado del Servicio ser del 55%, que puede ser considerado una oferta aceptable. Sin embargo, si en la segunda gasolinera se estropea otro surtidor, la situacin se convierte en crtica, pues el Estado del Servicio es del 33% y eso significa, que solo hay un surtidor en funcionamiento. Si esa prestacin puede verse mermada con degradaciones consecuencia de la falta de

217

alguno de los diferentes tipos de combustible que es capaz de proporcionar... considerarlo crtico es benevolente. En el captulo 3 de la tercera parte dedicado a las Tablas de Conversin se planteaba una opcin de rangos a mostrar por medio de colores: Si ES > 75%, ES = color verde Si 50% < ES <= 75%, ES = color naranja Si 0% < ES <= 50%, ES = color rojo SI ES = 0%, ES = color negro

Por hacerla ms completa, podemos aadir un color adicional entre el verde y el naranja, por ejemplo el amarillo. Adems, al incorporar la personalizacin para cada rango de porcentajes, no tenemos porque definir todos los colores en cada nivel de agregacin, de manera que podemos plantear situaciones como: Si ES > 50%, ES = color verde Si 0% < ES <= 50%, ES = color rojo SI ES = 0%, ES = color negro

No estara completa la personalizacin de los rangos si adems, cuando el porcentaje obtenido sea menor de un umbral definido o se alcance un determinado color, no se disparasen automticamente alarmas de aviso por la situacin crtica alcanzada y generar un fichero de control con tales alarmas. Si adems, consecuencia del estudio y anlisis del comportamiento del equipamiento y su impacto en el servicio, podemos establecer los procedimientos para restituirlo o por lo menos, indicar los pasos a realizar para iniciar la restitucin, los incorporaremos a la aplicacin como parte de la parametrizacin. En el captulo mencionado se plante tambin la posibilidad de conversin a cifras dentro de un escala fija establecida (de 0 a 5, de 0 a 10...), como otra forma de valoracin. Para el indicador Disponibilidad del Servicio, la pantalla debe contener bsicamente: 1. Datos generales del nivel de agregacin del Servicio Tcnico seleccionado. 2. Datos de seleccin con los campos de fecha de inicio y fecha final. 3. Zona de resultados. Se muestra el dato de la Disponibilidad obtenida durante las fechas de seleccin y una grfica de la evolucin del Estado del Servicio.

218

Por supuesto que, cuanto ms sea necesario desglosar el indicador de Disponibilidad (por franjas horarias, das sueltos,...), ms opciones de seleccin sern necesarias incluir. En las pantallas que a continuacin se muestran y que forman parte de la misma herramienta en explotacin que las anteriores, es posible observar el contenido propuesto:

Pero como todo sistema no es infalible (ya nos gustara), puede suceder que durante uno o varios das, la informacin almacenada para calcular la Disponibilidad del 219

Servicio no sea correcta debido a una gran diversidad de problemas como, alarmas perdidas, cadas del sistema, problemas de rendimiento,... Cuando se nos presente una situacin as tenemos dos opciones posibles: a. Rehacer el contenido de la informacin. b. Anular das dentro del rango definido. La primera de las opciones se muestra inicialmente muy compleja y difcil de tratar. En la segunda, la prdida de informacin debe asumirse. Por experiencia puedo manifestar como mejor opcin la b, pero debe ser cada departamento u organizacin quienes decidan, en funcin de la criticidad de la informacin, la opcin a implementar que mejor se ajusta a sus necesidades.

220

8 UN DIAGRAMA PARA ACABAR

Como hicimos para la fase de Diseo, nada mejor que terminar la fase de Construccin mostrando el diagrama de la misma, identificando los principales aspectos que son necesarios considerar.

Flujo de Control

Planificacin

Definicin de Hardware y herramientas Software necesarias

Identificacin de las Bases de Datos interrelacionadas

Identificacin de los Pilares Bsicos a implementar

Identificacin del Equipo de Trabajo

-Analistas -Programadores -Consultores --...

- GMAO -Consola de Gestin -...

Obviamente, ser muy conveniente establecer la planificacin de todo el proceso de creacin de la aplicacin, pues en s misma tiene la suficiente complejidad como para elaborar un plan detallado, indicando fases, hitos y tiempos para cumplir -en plazo y forma- la construccin del Gestor de Servicios Tcnicos.

Generacin de los interfaces grficos

221

Desarrollo del aplicativo

222

QUINTA PARTE HACIA EL MANTENIMIENTO

223

224

NDICE QUINTA PARTE

1 2 EL MANTENIMIENTO ..................................................................................... 227 CMO LOS SERVICIOS TECNICOS ORIENTAN EL MANTENIMIENTO ..... 229

PRIMER PASO............................................................................................... 229 SEGUNDO PASO .......................................................................................... 233 TERCER PASO............................................................................................... 234 CUARTO PASO ............................................................................................. 237 QUINTO PASO ............................................................................................ 239
3 4 5 6 7 8 9 ORGANIZACIN DEL MANTENIMIENTO ...................................................... 245 AUTOMATIZAR LA GESTION DEL MANTENIMIENTO ................................. 251 UN PASO MS ................................................................................................ 253 OTRA FORMA DE VER LO MISMO ................................................................ 257 HACIENDO FILIGRANAS ............................................................................... 265 EL FACTOR DIFERENCIADOR ...................................................................... 269 EL FACTOR HUMANO .................................................................................... 277

10 ENTENDIENDO LAS INCIDENCIAS ............................................................... 279 11 CERRANDO EL CIRCULO .............................................................................. 281

225

226

1 EL MANTENIMIENTO
Todo lo que a estas alturas podamos decir del mantenimiento despus de todo lo ya dicho, poco puede aportar. Recurrir nicamente a la extensa bibliografa existente. En la primera parte hicimos un breve relato de la historia y evolucin del mantenimiento, para ayudar al lector en la comprensin del presente libro, situndolo dentro del contexto donde se han desarrollado los Servicios Tcnicos. Qu contiene el ttulo de este captulo? Pues que una de las principales actividades relacionadas con cualquier Servicio Tcnico, como anunciamos, es el MANTENIMIENTO. Recuperemos la definicin de Servicio Tcnico.

CONJUNTO DE ACTIVIDADES RELACIONADAS ENTRE S, SOPORTADAS POR EQUIPOS E INSTALACIONES, QUE SATISFACEN UNA NECESIDAD O MEJORAN LAS FUNCIONALIDADES PRESTADAS
Es muy posible que algn lector no coincida con adjudicarle al mantenimiento tanta importancia, pero desde el momento que estas actividades son soportadas por equipos e instalaciones, en el ms estricto de los anlisis posibles a realizar sobre cualquier Servicio Tcnico, encontraremos que, aunque la nica tarea a realizar sea la de sustitucin, la participacin del mantenedor en momentos claves para la continuidad de la oferta del servicio es esencial. Los Servicios Tcnicos, como se ha mencionado al principio del libro, surgen en el seno de un departamento dedicado al mantenimiento de instalaciones, de las cuales, un volumen importante est de cara a los clientes externos, y la mayora de ellos explotados por otros departamentos (clientes internos) dentro de la misma empresa. Conocer qu oferta de servicio se est proporcionando por medio de estas instalaciones, qu servicio est prestando el mantenedor o qu servicio est percibiendo el cliente, fueron los argumentos que justificaban la implantacin de los Servicios Tcnicos, pero muy importante tambin, que orientacin deban tener HACIA EL CLIENTE. Al medir el nivel de servicio ofertado, implcitamente se est midiendo la satisfaccin del cliente, porque correspondiendo con este nivel estar la percepcin de servicio, que podr ser aceptable, regular, malo... Es evidente que en muchos casos tendremos que educar al cliente, para que el mismo pueda asociar un determinado nivel con un grado de satisfaccin. En el mundo actual, es tendencia exigir lo inalcanzable, consecuencia generalmente de la ausencia de educacin (formacin) y una abrumable oferta de servicio que no es tal. Por poner ejemplos constatables, ya no se entiende un vehculo sin aire acondicionado y como consecuencia, el transporte pblico debe dar el grado de 227

confort que ofrece nuestro vehculo particular. Sin embargo, el esfuerzo que puede suponer al mantenedor continuar con el antiguo nivel de oferta de servicio previo, antes de incorporar los mismos sistemas de confort, no ha sido ponderado ni evaluado, producindose un conflicto de intereses. Podemos reducir a dos los principales motivos que causan esta situacin: 1. La nula enseanza. Nadie nos ha explicado como realmente evaluar lo que nos est ofreciendo. Todo lo contrario. Se ha usado el trmino hasta unos niveles que se ha desvirtuado, tanto, que incluso podra ser tratado de ignorante quien no fuera capaz de apreciarlo, de distinguirlo. Si no se nos educa, por pedir... Es importante que el cliente sepa si est recibiendo lo que demanda o se le ofrece, pues la mayora de las veces, llega a confundirse y a confundrsele. 2. La comparacin. Servicios Tcnicos semejantes, hay que situarlos en su contexto. La mayora de las veces no son comparables. Muy importante para evaluar un Servicio Tcnico es la satisfaccin de quin lo recibe. Si se nos malcra, seremos unos insatisfechos permanentes. Cuando se mide un Servicio Tcnico, el objetivo no es que el valor obtenido est siempre cercano al 100%. Hay casos excepcionales que por la idiosincrasia del Servicio Tcnico deba serlo, pero un nmero importante de ellos no. Lo importante es determinar que el valor obtenido diga si es aceptable o no, simplemente esto, y que incrementar el nivel de la oferta tiene un esfuerzo que no slo debe ser evaluado desde el mantenimiento, si no con la participacin de todos los que con su actividad contribuyen en el servicio ofertado, incluido el que lo recibe, porque hasta ahora, la repercusin del cliente durante todo el libro pareca no existir, limitando su participacin a ser el receptor del servicio. Pero, y si cundo vamos a sacar dinero, resulta que es nuestra tarjeta la causante de no poder realizar el reintegro? Por ello, la vinculacin por lo menos del cliente interno, ayudar a orientar el mantenimiento, pero a la vez, hay que mostrar el esfuerzo que supone reorientar la actividad, pues no solo se debe considerar el incremento de satisfaccin posible consecuencia del aumento y/o mejora de la oferta, sino la continuidad, es decir, la sostenibilidad de las actividades con los nuevos criterios.

228

2 CMO LOS SERVICIOS MANTENIMIENTO

TECNICOS

ORIENTAN

EL

Esta quinta parte por si sola, da para hacer no un libro, si no varios, y nada podra ser ms satisfactorio que otros autores fueran los creadores de dichos textos. De la experiencia, condicionantes propios de cada organizacin, explotacin de los equipos que participan en los Servicios Tcnicos, el mantenimiento y dems actividades, darn para pginas y pginas. Quin se atrever con un caso prctico? Con un modelo a seguir? El reto est lanzado. En estos momentos el que suscribe es ms modesto. Para esta parte del libro, solo marcar unas pocas directrices propias de la reflexin y la experiencia, aportando algunos matices muy interesantes para alinear esfuerzos, resultados,... Estoy en la obligacin moral de advertir al lector, que si puede haber sido durill a la lectura hasta este punto, de aqu en adelante voy a rematar la faena (como diran los taurinos). An as pretendo para los captulos restantes que sean lo ms sintticos posibles. nimo, que queda poco. El primer paso casi es inmediato. Una vez puesto en marcha el Servicio Tcnico y realizados los ajustes necesarios en la distribucin de los Pesos Operativos, del anlisis de las primeras cifras obtenidas del Estado del Servicio y Disponibilidad del Servicio obtendremos los equipos clave Crticos. Estos equipos y su equipamiento implicado merecen especial atencin, pues cualquier incidencia tcnica, de explotacin, de logstica, degradaciones, provocarn cadas significativas en los indicadores. En muchos Servicios Tcnicos el porcentaje de contribucin en el indicador ser tan alto, que es lgico establecer sobre ellos, y tambin sobre el equipamiento relacionado, procedimientos de atencin y resolucin especiales.

PRIMER PASO Identificar equipos clave y equipamiento implicado crtico

1 Equipo CRTICO. Se establecen procesos de atencin y resolucin especiales. Para ello, es importante analizar el impacto que producen estos equipos en el Servicio Tcnico y durante cuanto tiempo es admisible. Slo en circunstancias muy especiales, segn sea este impacto, la prioridad a establecer sobre los mismos variar. En principio, es recomendable que todos tengan la misma consideracin, y nicamente exista prioridad entre ellos, dependiendo del momento en que se produce la incidencia. 1.1 Equipo URGENTE. Es un subconjunto de equipos de atencin inmediata. La justificacin de esta premura ser variada (imagen, repercusin, localizacin, beneficios,) Sean uno, dos o varios los motivos, para estos equipos, su tiempo de atencin 229

y resolucin ser siempre un SLA. El incumplimiento en caso de que pueda producirse, deber estar cuantificado en tiempo y delimitado en las razones del mismo. Pero quizs nos hemos apresurado catalogando directamente determinados equipos. Lo ms lgico es que una vez establecidas las correcciones en los Pesos Operativos, se prioricen todos los equipos, clave e implicados, segn sea el grado de prdida de servicio. Para realizar la priorizacin tendremos en cuenta los siguientes criterios:

mbito geogrfico. Condiciones de explotacin y/o operacin. Volumen de equipos.

En la cuarta parte, en el captulo de los Pilares Bsicos, se expona la siguiente tabla de niveles de agregacin del servicio.
Nombre (Nivel de Agregacin de Servicio Servicio Tcnico) Tcnico Cajeros ESPAA

Nivel de Agregacin

Situacin Estado Disponible

CAJEROS Global

Cajeros MADRID Cajeros Madrid Cajeros Mstoles Cajeros Legans Cajeros ANDALUCIA Cajeros Cdiz Cajeros Sevilla Cajeros Malaga Cajeros Crdoba

CAJEROS Comunidad CAJEROS Ciudad CAJEROS Ciudad CAJEROS Ciudad CAJEROS Comunidad CAJEROS CAJEROS CAJEROS CAJEROS Ciudad Ciudad Ciudad Ciudad

Estado Disponible Estado Disponible Fuera de Servicio Temporal Estado Disponible Estado Disponible Estado Disponible Estado Disponible Fuera de Servicio Temporal Fuera de Servicio Permanente Fuera de Servicio Temporal Fuera de Servicio Temporal Fuera de Servicio Temporal Estado Disponible Estado Disponible Estado Disponible Fuera de Servicio Temporal

Desglose Cajeros MADRID Cajeros ANDALUCIA Cajeros EXTREMADURA Cajeros CATALUA Cajeros Madrid Cajeros Mstoles Cajeros Legans Equipos Equipos Equipos Cajeros Cdiz Cajeros Sevilla Cajeros Malaga Cajeros Crdoba Equipos Equipos Equipos Cajeros Cceres Cajeros Badajoz Equipos Equipos Cajeros Barcelona Cajeros Gerona Cajeros Lrida Equipos Equipos Equipos

Cajeros EXTREMADURA CAJEROS Comunidad Cajeros Cceres Cajeros Badajoz Cajeros CATALUA Cajeros Barcelona Cajeros Gerona Cajeros Lrida CAJEROS Ciudad CAJEROS Ciudad CAJEROS Comunidad CAJEROS Ciudad CAJEROS Ciudad CAJEROS Ciudad

Tabla de Niveles de Agregacin del Servicio Aplicando el primer criterio de mbito geogrfico, es lgico que la priorizacin se realice hasta el nivel de agregacin de ciudad. Sin embargo, la Comunidad de 230

Madrid geogrficamente consta de una sola provincia, por lo que las condiciones de explotacin y/u operacin por provincia coinciden con los de comunidad, y por ello, el mbito geogrfico para establecer la priorizacin es, particularmente para este caso, a nivel de agregacin de comunidad. Aunque en el ejemplo no est representado, supongamos adems que el volumen de cajeros en las provincias de Cceres y Badajoz es de dos respectivamente. En este caso, no parece apropiado priorizar para cada provincia dado el bajo nmero de equipos. Como ambas provincias estn adyacentes una de la otra, la priorizacin, al igual que para Madrid, se realizara a nivel de agregacin de comunidad. Realizada la priorizacin en funcin de los criterios, tendremos una relacin de equipos en funcin de los Pesos Operativos acumulados. Con los resultados y evaluando las poblaciones por rangos, convertimos dichos resultados en valores dentro de una escala, por ejemplo de 1 a 3 de 1 a 5. No es conveniente sin analizar las poblaciones priorizaciones de 1 a 10. Solo en el caso de que la priorizacin est en funcin exclusivamente del equipo, puede tener sentido hacer un escalado tan detallado. Para entenderlo supongamos el siguiente reparto: Nivel 2 Peso Operativo 25% Nivel 1 Peso Operativo 50% Equipo Peso Operativo 30% El producto de sus Pesos Operativos acumulados es 3,75% (30% x 50% x 25%). Si hiciramos un ejemplo ms extenso proporcionando valores a un conjunto elevado de equipos, observaramos el siguiente comportamiento:

Grfico de distribucin de porcentajes La grfica nos indica que la mayora de los equipos se distribuiran en un margen muy estrecho de porcentajes, y mayor sera esta acumulacin, si la resultante fuera el producto de ms de tres niveles de agregacin. Qu consecuencia se obtiene del anlisis? Pues que para determinar exactamente la asignacin de la prioridad a cada equipo, es absolutamente obligatorio, analizar la distribucin de la 231

participacin de los equipos en el Servicio Tcnico. Como recomendacin, los grficos de dispersin sern de gran utilidad para evaluar la distribucin. En funcin de la grfica mostrada, distribuyendo los equipos en tres rangos es ms que suficiente para una propuesta de distribucin por repercusin: A. Repercusin Inapreciable. La prdida de servicio causada por este equipamiento es insignificante. B. Repercusin Condicionada. Equipamiento que por si mismo no es significativa la disminucin de servicio que produce, pero que bajo determinadas circunstancias, su participacin puede llevar a incumplimientos pactados. C. Repercusin Directa. Si no presta servicio, el porcentaje disminuye ostensiblemente. Pero para decir qu tipo de repercusin tiene un determinado equipo, solo es factible cuando el equipo no est funcionando y por lo tanto, el clculo del Peso Operativo acumulado. Pero, cmo plantear la prioridad cuando es una degradacin lo que se produce? Podra suceder que un equipo con prioridad baja y que no est funcionando, impacte en el Servicio Tcnico ms que un equipo con prioridad alta, pero degradado. No parece lgico atender antes al equipo funcionando que al equipo parado; o s? Si al analizar la distribucin de los Pesos Operativos acumulados y la priorizacin, est en funcin de las poblaciones resultantes, lo ms lgico es que en un porcentaje muy alto, un equipo parado de repercusin inferior afecte menos, que un equipo degradado de nivel superior por escasa que sea la degradacin. Es posible que en lugar de tener tres niveles de repercusin (priorizacin), segn la grfica de distribucin de equipos, sean dos o cuatro, pero sean los que sean, deben ser suficientes para garantizar una atencin adecuada a los equipos, en funcin de su repercusin en el Servicio Tcnico. Puede suceder que el nico nivel de agregacin existente adems del global sea el de equipos y por lo tanto, aplicaramos directamente la priorizacin en base a sus Pesos Operativos. O al contrario, que el resultado de los Pesos Operativos acumulados sea la consecuencia de aplicar todos los niveles de agregacin de servicio, concentrndose en un rango muy pequeo de porcentajes y separado prcticamente por decimales. Llegado el caso, a cada resultado acumulado le aplicaramos el factor de correccin que se determine para poder obtener una dispersin razonable. La clave para hacer una distribucin eficaz puede ser un determinado Nivel de Agregacin de Servicio. En la Tabla expuesta ste sera, el nivel de agregacin de Comunidad. El lector seguramente se habr percatado que hemos aplicado para hallar la prioridad un nico Peso Operativo por equipo, cuando muchas veces los equipos tienen diferente Peso Operativo dependiendo de la franja horaria. Es posible incluso que los niveles de agregacin superiores tambin tengan diferentes Pesos 232

Operativos segn la franja horaria. O como se planteaba en la tercera parte, la asignacin de los Pesos Operativos sea dinmica con lo que se complica todava ms el Peso Operativo a aplicar. Cmo priorizar en estos casos? Pues de la misma manera que en el ejemplo expuesto; segn obliguen las condiciones de partida, as estableceremos el valor a aplicar. Si hay varios Pesos Operativos por franja, aplicaremos aquellos en donde todos los equipos estn prestando servicio y si adems, el nivel superior tambin tiene franjas horarias, usaremos el mismo criterio que para los equipos. Que no hay coincidencia, el mayor valor de todas las franjas horarias. Si adems de las franjas horarias, se dinamizan los Pesos Operativos, ser el valor asignado el que participe del clculo. Y si es el Servicio Tcnico de las lneas de caja? Segn se describi, se dinamizaban los Pesos Operativos por volumen de equipos, con una distribucin uniforme entre las cajas que estuvieran activas. Para este tipo de Servicios Tcnicos lo ms recomendable es, que los Pesos Operativos acumulados para obtener la prioridad comiencen en el nivel de agregacin de servicio anterior al de los equipos, nunca, desde el propio equipo. Sean cuales sean las condiciones de explotacin y/o operacin, los criterios adoptados, las formulas a aplicar y los parmetros escogidos, tienen que ser lo ms homogneos posibles. Para aquellos Servicios Tcnicos en los que se apliquen horarios, de cara al mantenimiento, adems de mostrar la prioridad como elemento informativo, ser muy til indicar las franjas horarias en las que presta servicio el equipo, como ayuda al personal encargado de gestionar el mantenimiento. Esta informacin puede ser tambin de gran utilidad, para los gestores de otras actividades con repercusin en el Servicio Tcnico.

SEGUNDO PASO Priorizar los equipos

El ejemplo de priorizacin del apartado anterior se ha realizado en funcin del Servicio Tcnico. Y el mantenedor? Aqu surge el primer punto de conflicto entre la visin del cliente y la visin del mantenedor, y decir visin es, decir intereses. Para el cliente, el principal criterio para priorizar est en funcin de la oferta de servicio perdida, con especial mencin en algunos Servicios Tcnicos a la repercusin negativa en los beneficios. Para el mantenedor, la proximidad a sus centros de atencin tcnica, talleres, almacenes de repuesto, organizacin del personal, sern los criterios para priorizar. Cul de los dos debe primar? Cul es mejor? Pues dado que este captulo trata en definitiva de Cmo los Servicios Tcnicos orientan el Mantenimiento, los criterios del mantenedor sern en principio secundarios, consultivos bajo determinadas circunstancias, pero siempre como segunda opcin. Esto no quiere decir que no se repercuta el esfuerzo. Para el mantenedor, los reajustes en su estructura y organizacin para obtener o mantener una determinada oferta de servicio deben cuantificarse, ms, si cliente y mantenedor estn dentro de la misma organizacin. El dilema entonces es, qu punto de vista adoptar? O mejor, cmo relacionar ambos puntos de vista para llegar al mejor resultado posible? 233

El anlisis de cada situacin condicionar la priorizacin. Es un hecho absoluto, porque incluso la valoracin de la prdida de beneficio relacionada con la prdida de oferta de servicio, estar condicionado por el esfuerzo, y todo esfuerzo, tiene siempre un coste asociado.

TERCER PASO Priorizados los equipos, analizar el impacto provocado en la reorganizacin del mantenimiento, para proporcionar el nivel de servicio requerido
Vamos a priorizar el equipamiento en funcin del mantenedor. Los criterios propios del mantenedor pueden reducirse a dos para realizar la priorizacin: Tiempo Medio de Desplazamiento y Tiempo Medio de Resolucin - Definimos como Tiempo Medio de Desplazamiento, al promedio de los tiempos en recorrer la distancia desde el Centro S.A.T. (Servicio de Asistencia Tcnica) al equipo y volver. - Definimos como Tiempo Medio de Resolucin, al promedio de los tiempos dedicado en solucionar la incidencia. Con el primer tiempo parametrizamos por proximidad, siendo lo ms lgico y como si de una diana se tratara, establecer tres niveles (de menor tiempo de desplazamiento al de mayor): - Prioridad Alta - Prioridad Media - Prioridad Baja

234

Proximidad Baja

Proximidad Media

Proximidad Alta

SAT

Corona de prioridad geogrfica Puede parecer paradjico que cuanto ms prximo est el equipo al Centro SAT la prioridad sea mayor, y que cuanto ms nos alejemos menor. La lgica parece indicar lo contrario, pero hay un aspecto muy manido, mal planteado la mayora de las veces y que es muy importante de cara al mantenimiento, LA EFICIENCIA. Para justificar la distribucin de prioridades expuesta, hagmoslo por medio del siguiente ejercicio: Supongamos un tiempo medio de resolucin similar en las tres zonas y los siguientes tiempos medios de desplazamiento: - Zona Verde 30 minutos. - Zona Naranja 60 minutos. - Zona Roja 90 minutos. Tal relacin significa que, sin considerar los tiempos de resolucin, en un periodo de tiempo igual, por cada equipo resuelto en la zona roja, se resolveran 2 en la naranja y 3 en la verde. Obviamente esta proporcin disminuye cuando es necesario considerar el tiempo medio de resolucin, pues las proporciones se reducen a medida que el tiempo medio de resolucin aumenta. Con un tiempo medio de resolucin de 30 minutos, la proporcin es de 1,33 en la zona naranja y 2 en la verde. Con un tiempo medio de 235

resolucin de 90 minutos, la proporcin es de 1,2 para la zona naranja y de 1,5 para la verde. No obstante, aunque las diferencias se reduzcan segn aumenta el tiempo medio de resolucin, para un departamento dedicado al mantenimiento, cuanto ms equipos resuelva por unidad de tiempo, mejores sern sus indicadores de resultado y, consecuentemente, ms eficiente su mantenimiento. Por lo tanto, la priorizacin estar en proporcin del mayor volumen de equipos atendidos por unidad de tiempo, de ah que cuanto menos tiempo de desplazamiento suponga atenderlos, mayor prioridad tienen. Incluso en el supuesto de que el tiempo medio de resolucin fuera menor, segn el tiempo medio de desplazamiento fuera mayor, para plantear la prioridad por localizacin geogrfica inversamente, solo podra ser posible, cuando la suma de los tiempos de desplazamiento y resolucin fuera menor en una determinada zona geogrfica, pudiendo darse el caso extremo de que la prioridad alta fuera la corona central, la media la corona externa y la baja la corona interna. No obstante, este planteamiento es una situacin bastante improbable a similitud de equipamiento. Una vez planteada la prioridad por localizacin geogrfica, constituimos una nueva prioridad en funcin del tiempo medio de resolucin y estableciendo tambin tres niveles en funcin del tiempo: - Resolucin Alta - Resolucin Media - Resolucin Baja Con el mismo planteamiento expuesto para la prioridad por localizacin, al mantenedor le interesa atender los equipos que le consumen menor tiempo de intervencin.

236

Con la combinacin de ambos, obtenemos la siguiente tabla de prioridades de mayor a menor:

1er Nivel de Prioridad Proximidad Alta

Proximidad Media

Proximidad Baja

2 Nivel de Prioridad Resolucin Baja Resolucin Media Resolucin Alta Resolucin Baja Resolucin Media Resolucin Alta Resolucin Baja Resolucin Media Resolucin Alta

Cdigo AB AM AA MB MM MA BB BM BA

Tabla de prioridades segn mantenimiento Las dos ltimas letras son el cdigo de prioridad asignado a cada equipo.

CUARTO PASO Estudiar otros posibles criterios para priorizar

Comparados ambos mtodos de priorizacin, parece ms completo el planteado en funcin del mantenedor, pues a diferencia del usado en funcin del servicio, establece un criterio ms razonable y lgico que ste. Priorizados los equipos y realizada la reorganizacin del centro de mantenimiento en funcin de dicha priorizacin, como proceder resulta en principio algo catico. Atendemos a un equipo con Repercusin Alta cuyo tiempo de desplazamiento es elevado en lugar de otro equipo de igual prioridad, pero mucho ms cerca solo por el hecho de haberse averiado 1 minuto antes? No parece lo ms razonable. Aprovechemos el punto de vista del mantenedor para mejorar la priorizacin en funcin del servicio. Consiste en establecer la misma corona geogrfica dependiendo del tiempo medio de desplazamiento y la repercusin en el servicio.

237

La tabla combinacin de los dos mtodos de priorizacin (proximidad y repercusin) es:

2 Nivel de Prioridad Cdigo Repercusin Alta AA Proximidad Alta Repercusin Media AM Repercusin Baja AB Repercusin Alta MA Proximidad Media Repercusin Media MM Repercusin Baja MB Repercusin Alta BA Proximidad Baja Repercusin Media BM Repercusin Baja BB
Tabla de prioridades segn servicio Con cualquiera de las dos tablas y la ordenacin resultante, se pueden planificar las intervenciones del departamento de mantenimiento, y la segunda adems, aplicable a otras actividades que puedan realizarse en torno a los equipos. Dependiendo de los recursos, agrupando las incidencias por el cdigo de prioridad sabemos como actuar. Hay un inconveniente. No es lo mismo priorizar (planificar) que organizar. En el captulo siguiente trataremos este problema. Tenemos un mtodo para priorizar en funcin del servicio, mejorado, y otro en funcin del mantenimiento, pero en ambos casos puede suceder que los equipos con menor prioridad nunca sean atendidos, ya que continuamente estaran en el final de la lista. Desde el punto de vista del cliente, aunque el equipo influya poco en la oferta del servicio, prolongados tiempos en los cules un equipo no est disponible o alguna de sus funcionalidades no est operativa, es contraproducente, principalmente por imagen (dejadez, abandono,...) y estado de nimo (enfado, crispacin,...). Para evitar estas situaciones es necesario establecer un factor de correccin, que segn trascurra el tiempo modifique la prioridad inicial del equipo. Para introducir este factor de correccin, vamos a basarlo en el mtodo planteado en funcin exclusivamente del servicio (Repercusin). Empleando los tres niveles de priorizacin expuestos es ms fcil para explicar, y tambin para entender, cmo aplicar el factor de correccin. Si el equipo es de Repercusin Baja, transcurrido un tiempo predeterminado pasara a tener Repercusin Media, y transcurrido ms tiempo, Repercusin Alta. En el caso de ser directamente un equipo de Repercusin Media, transcurrido un tiempo, que no tiene porque ser igual que el aplicado para equipos cuya Repercusin inicial es Baja, pasara a tener Repercusin Alta. Cmo atender a los equipos con Repercusin Alta? Y al resto? Dos son los planteamientos de actuacin dependiendo de: 238

1er Nivel de Prioridad

1. Si durante un periodo de tiempo, es tal el volumen continuo de incidencias o alarmas de equipos que solo se atienden aquellos con Repercusin Alta (ya sea propia o por tiempo), que imposibilitan atender equipos con distinta Repercusin, la atencin debe ser realizada por la fecha en la que se produce la incidencia o la alarma. 2. En caso contrario, la secuencia ser la siguiente: Equipos con Repercusin Alta propia Equipos con Repercusin Alta por tiempo y Repercusin Media propia Equipos con Repercusin Alta por tiempo y Repercusin Baja propia Equipos con Repercusin Media propia Equipos con Repercusin Media por tiempo y Repercusin Baja propia Equipos con Repercusin Baja propia La conclusin es inmediata. Es necesario controlar las dos prioridades, o por lo menos, diferenciar de alguna manera cuando la prioridad es propia o adquirida, teniendo en cuenta que es necesario diferenciar equipos, que a igual prioridad adquirida, provienen de distintas prioridades iniciales propias. Segn el caso expuesto codificaramos de la siguiente manera: Equipos con Repercusin Alta propia AA Equipos con Repercusin Alta por tiempo y Repercusin Media propia MA Equipos con Repercusin Alta por tiempo y Repercusin Baja propia BA Equipos con Repercusin Media propia MM Equipos con Repercusin Media por tiempo y Repercusin Baja propia BM Equipos con Repercusin Baja propia BB Tanto si el mtodo usado es en funcin del servicio combinado con el mantenimiento, como si es en funcin exclusivamente del mantenimiento, solo es necesario controlar las dos prioridades, la de partida y la adquirida. En los casos expuestos con 9 niveles de prioridad, la evolucin solo se aplicara dentro del 2 nivel de prioridad, es decir, por Repercusin o por Resolucin.

QUINTO PASO Establecer los factores de correccin necesarios, para garantizar una correcta intervencin en el equipamiento
239

Independientemente de cuantos niveles de prioridad obtengamos, por encima de ellos siempre habr dos niveles de orden superior. Son los planteados al principio del captulo. Cuando un equipo ya sea porque tiene la mxima prioridad, o porque trascurrido un tiempo la adquiere, podra suceder bajo determinadas circunstancias que no fuera atendido durante un prolongado espacio de tiempo inadecuado. Para solucionar estos casos, los equipos que superen determinado periodo de tiempo sin atencin, se les aumenta la prioridad a CRITICOS. Como vimos al comienzo del captulo, este nivel de prioridad se caracteriza, porque todo equipo que lo alcanza o se le asigna de partida, est sujeto a procesos de atencin y resolucin especiales, diferentes a los establecidos por los mtodos de priorizacin vistos. Un ejemplo puede ser, establecer tiempos de respuesta menor a un nmero de horas. Los dos mtodos planteados tienen un denominador comn, satisfacen los requerimientos de partida, ya sea en funcin del servicio o del mantenimiento. Ambos planteamientos son equilibrados, facilitando a los responsables del mantenimiento planificar las actuaciones. Es ms, son los mtodos los que planifican las actuaciones siendo posible automatizarlos. Finalmente, qu ms es necesario considerar establecido el mtodo? Pues que los Servicios Tcnicos estn soportados por equipos e instalaciones, y los mtodos expuestos se han desarrollado considerando al equipo clave. Qu prioridad aplicar al resto del equipamiento implicado? Pues que dicha prioridad se asignar, condicionada por alguno de los siguientes aspectos: 1) El equipamiento implicado hereda la prioridad del equipo clave. 2) Si en un Servicio Tcnico, un equipo implicado afecta a un conjunto de equipos clave con diferentes prioridades, habr que optar por: a. Asumir la ms alta. b. Determinarla partiendo desde el Nivel de Agregacin de Servicio superior. c. El sumatorio de un nmero determinado de prioridades de equipos clave. 3) Si un equipo participa en varios Servicios Tcnicos, ya sea como equipo clave, equipamiento implicado o ambos, la prioridad asociada podr ser: a. La de mayor valor absoluto. b. El sumatorio de un nmero determinado de prioridades. c. Si su implicacin es tal que su repercusin es muy alta, ser considerado CRITICO o URGENTE. Quizs sea conveniente recordar que durante todo el captulo, al referirnos a la prioridad de los equipos y como evoluciona segn transcurre el tiempo, el mbito 240

donde tiene aplicacin es en la gestin de las incidencias; aunque tambin puede haber otros aspectos interesantes para los que puede resultar til la prioridad, como por ejemplo: las renovaciones masivas de equipamiento. En el fondo, no deja de ser un mtodo para establecer un orden, y si priorizar es til para planificar las actividades, la renovacin, no puede ser considerada una actividad ms? Pues si el trabajo ya est hecho, una tarea menos a realizar. No obstante, ajeno a otros posibles usos, nos circunscribimos al mbito exclusivamente del mantenimiento. Durante toda la exposicin del resto de captulos de esta parte dedicada al mantenimiento, la idea que debemos tener en mente es la siguiente: El resultado final es la combinacin de tres factores, que van a determinar nuestro mtodo.

241

Y surge el primer conflicto. Los departamentos de mantenimiento actuales tienen en mente el siguiente trinomio.

Coste

Fiabilidad

Mantenimiento
Disponibilidad

El xito consiste en conjugar ambas visiones sabiendo que, no siempre una mayor Rentabilidad o Disponibilidad, redunda en una mejor oferta de servicio. Equilibrio, y para conseguirlo, el control de cada nivel de gestin tal y como se plante.

GESTION DE SERVICIOS

GESTION DE INCIDENCIAS

GESTION DE MANTENIMIENTO

242

Los indicadores establecidos en los niveles de Mantenimiento y de Incidencias, sern las palancas de mando sobre las que actuar para corregir el rumbo cuando, en la Gestin de Servicios, se incumplan los Niveles de Servicio definidos.

243

244

3 ORGANIZACIN DEL MANTENIMIENTO

En cualquier organizacin dedicada al mantenimiento, cmo reducir los tiempos dedicados al desplazamiento, se convierte en la piedra angular sobre la que organizar la actividad, ms incluso que el tiempo de resolucin. Ello es debido a que el tiempo de desplazamiento, sin considerarlo parte de los tiempos muertos, es un tiempo no productivo inherente a toda actuacin. En los mtodos planteados en el anterior captulo, el primer criterio empleado para priorizar era el tiempo medio de desplazamiento. Analizando cada una de las coronas se observa que, para la corona ms prxima al Centro S.A.T., los tiempos de desplazamiento pueden ser menores que el tiempo medio definido, pues el equipo de trabajo no regresar despus de cada actuacin, sino que se desplazar al siguiente equipo averiado siguiendo un orden de proximidad. Pero en el resto de las coronas, no slo no es tan notoria esta diferencia entre los tiempos de desplazamiento empleados y el tiempo medio de desplazamiento, si no que al realizar el desplazamiento, se pase cerca de un equipo de las coronas inmediatamente inferiores, que estuvo averiado, y se atendi segn planificbamos por cualquiera de los mtodos expuestos. Este hecho demuestra que, aunque se hayan planificado las intervenciones, no se han organizado de la manera ms ptima y el principal objetivo del mantenimiento es ser EFICIENTE. En el siguiente esquema, se representa el desplazamiento realizado desde el punto A hasta el punto B por un equipo de intervencin y como en su recorrido atraviesa las coronas inferiores, con la oportunidad que ello representa para realizar actuaciones aprovechando este desplazamiento.

Proximidad Baja

Proximidad Media

Proximidad Alta

SAT A B

Corona de prioridad geogrfica 245

Para que el mtodo propuesto de planificacin sirva tambin para organizar el mantenimiento eficientemente, dividamos las coronas en sectores.
Proximidad Baja

Proximidad Media

Proximidad Alta

SAT

Corona de prioridad geogrfica por sectores Lo primero que se observa es, que el reparto de los sectores no tiene porque ser proporcional en tamao. Dijimos en el captulo anterior, que uno de los criterios para priorizar es el volumen de equipos. En el momento de sectorizar el mbito geogrfico, lo haremos lo ms homogneo posible, depender del volumen de equipos, pero este nmero vendr determinado por alguno de los siguientes criterios o combinacin de varios:

Promedio de incidencias El nmero de equipos por sector La media de prioridad por sector El sumatorio de las prioridades

Las ventajas que representa para organizar el mantenimiento son evidentes. Lo que antes era una nica lista de intervencin, ahora existirn cinco. Como atenderlas depender, por un lado del total de equipos averiados en cada sector y sus prioridades, y por otro, de factores intrnsecos al mantenimiento (nmero de equipos de trabajo disponibles, almacenes de repuesto,...). No obstante, es posible establecer algunas directrices (ordenamiento) de carcter general para organizar las 246

intervenciones. Estas directrices no tienen en consideracin las incidencias en equipos CRITICOS Y URGENTES, por tener procedimientos de actuacin especiales: a. Sector con mayor nmero de equipos averiados con prioridad ms alta, en la Corona de Proximidad Alta. b. A igualdad, se compara el siguiente nivel de prioridad y as sucesivamente. c. Cuando el mayor nmero de equipos averiados con prioridad ms alta, est en la Corona de Proximidad Media o en la Corona de Proximidad Baja, se aplicaran Reglas de Comparacin. Estas reglas tienen como finalidad proponer un orden de actuacin. Cules van a ser las Reglas de Comparacin? Lo que sabemos en todo momento es, que en cada trapecio circular de cada sector habr para el 2 Nivel de Prioridad: N incidencias de equipos con prioridad alta. N incidencias de equipos con prioridad media. N incidencias de equipos con prioridad baja.

Partiendo de la tabla de prioridades segn mantenimiento/servicio, asignamos nmeros a las prioridades:

1er Nivel de Prioridad Proximidad Alta Proximidad Media Proximidad Baja

Valor 2 Nivel de Prioridad Valor Cdigo Repercusin Alta 1 AA 1 Repercusin Media 2 AM Repercusin Baja 3 AB Repercusin Alta 1 MA 2 Repercusin Media 2 MM Repercusin Baja 3 MB Repercusin Alta 1 BA 3 Repercusin Media 2 BM Repercusin Baja 3 BB

Tabla de prioridades y su valor correspondiente Con la cifra del 2 Nivel de Prioridad (Repercusin) obtenemos la Media de Prioridades (P) de los equipos que tienen incidencia. La conclusin es inmediata, cuanto ms baja sea la media, la mayor parte de las incidencias se ha producido en equipos de mayor prioridad.

247

Igualmente lo hacemos juntando los tres trapecios circulares del Sector, cumplindose la misma prerrogativa. La llamaremos Media de Prioridades Aglutinada y su sigla PA. Con el valor del 1er Nivel de Prioridad (Proximidad) hacemos el mismo clculo para cada sector. A la Media del Sector la llamamos S. Qu se obtiene con las tres cifras? Una orientacin muy clara y precisa de cmo organizar el mantenimiento. El captulo 2 deca: Cmo los Servicio Tcnicos orientan el Mantenimiento, y eso exactamente es lo que nos van a permitir las medias, que una vez planificadas las intervenciones se organicen para ofertar el mejor servicio. Cuanto ms bajo sea el valor de la media, ms prioritario. La primera valoracin se establecer por medio de la media de prioridades (P), que influye directamente en el Servicio Tcnico La media de prioridades aglutinada (PA) indicando el orden de los sectores. A igualdad de sectores, la media del sector (S) nos dir la prioridad entre ellos. Con las dos primeras medias ya no sera necesaria en principio la tercera media. Si por alguna razn lo fuera, generalmente algn motivo exgeno a los criterios establecidos, comparando la distribucin de las diferentes P de cada una de las coronas, sera suficiente para ordenar las intervenciones. Como ayuda para estos casos, el valor ms bajo del sumatorio de las P de cada sector.

248

Veamos un ejemplo para entender mejor lo explicado hasta ahora en este captulo: En el siguiente esquema de Coronas, tenemos una distribucin equitativa con respecto del volumen de equipos en cada una de ellas. Esta distribucin de los equipos averiados est en sectores de diferente proximidad. El resto de Coronas del mismo sector no tiene ninguna incidencia. Cul sera el orden de intervencin?
5 equipos Repercusin 1 0 equipos Repercusin 2 5 equipos Repercusin 3 PA = 2 S = 3

Proximidad Baja

Proximidad Media

Proximidad Alta

SAT

0 equipos Repercusin 1 0 equipos Repercusin 2 10 equipos Repercusin 3 PA = 3 S = 1

0 equipos Repercusin 1 10 equipos Repercusin 2 0 equipos Repercusin 3 PA = 2 S = 2

Con las directrices dadas, vemos que en la Corona de Proximidad Alta no hay equipos de Repercusin Alta (1), por lo que tenemos que aplicar las reglas de clculo en base a las medias. Segn lo visto, el primer sector sera el que tiene las siguientes medias: PA = 2 S = 2 a continuacin PA = 2 S = 3 y por ltimo PA = 3 249

S = 1 Como se puede observar, en el caso de que el equipo de mantenimiento finalizara todas las actuaciones del primer sector a atender (corona intermedia), en su desplazamiento hacia el segundo sector (corona externa), es posible que pase junto a equipos del ltimo sector (corona interna), para actuar segn la planificacin resultante. Qu decisin tomar en estos casos? Estar en funcin de las necesidades. Una vez organizadas las intervenciones, slo la perspectiva que proporciona el razonamiento humano, puede llevar al mantenimiento ese grado de eficiencia que a veces se requiere. Hemos planificado y organizado las actuaciones, Cul es el elemento diferenciador a igualdad de todas las medias? El volumen de equipos con incidencias activas por sector y trapecio circular. Lo podemos mejorar? Seguro, pero de partida, ya tenemos una base slida sobre la que sostener las intervenciones de MANTENIMIENTO.

250

4 AUTOMATIZAR LA GESTION DEL MANTENIMIENTO

Retomemos nuestra corona y su distribucin por sectores

Proximidad Baja

Proximidad Media

Proximidad Alta

SAT

Corona de prioridad geogrfica por sectores Por s misma, lo primero que se observa es lo grfica que resulta. Imaginemos una situacin real de una empresa de mantenimiento, en donde para cada trapecio circular de cada uno de los sectores se representara: 1. El total de equipos. 2. El nmero de incidencias activas. 3. La media P. 4. Los equipos con incidencias de Repercusin Alta, Media y Baja. 5. Los equipos Crticos y Urgentes. Y para cada sector: 1. El total de equipos. 2. El nmero de incidencias activas. 3. las medias PA y S. 4. Los equipos con incidencias de Repercusin Alta, Media y Baja. 251

5. Los equipos Crticos y Urgentes. Y adicionalmente, la ordenacin resultante para sectores y trapecios, en funcin de las reglas definidas en el captulo anterior. Salvando las distancias... y sin salvarlas, es un Cuadro de Mando. Gracias a la informacin descrita y representada en la Corona grfica, es posible gestionar el mantenimiento. Qu ms aadir? Si sumamos las medias PA y S, los valores estarn comprendidos entre 2 y 6. Pues de la misma manera que aplicbamos en su momento las Tablas de Conversin, podemos hacer lo mismo para cada franja. Por ejemplo: 1. Si el resultado es >= 2 y < 3, color negro 2. Si el resultado es >= 3 y < 4, color rojo 3. Si el resultado es >= 4 y < 5, color naranja 4. Si el resultado es >= 5 y =< 6, color amarillo 5. Si resultado es =0, color verde Visualmente nos ofrece la ordenacin. Con la P podemos hacer lo mismo, sabiendo que los rangos a definir estn comprendidos entre 1 y 3. Es en ambos casos el mismo principio que las Tablas de Conversin. Realmente lo que estamos haciendo es ver el Servicio Tcnico desde otra perspectiva, distinta de la ofrecida por los Niveles de Agregacin de Servicio definidos en el Gestor. Es desde la perspectiva de la priorizacin, donde conjugamos la visin del Servicio Tcnico con la del mantenedor. Con la idea de dotar de una herramienta de gestin para el mantenimiento, slo queda representar el esquema grfico y la ordenacin, o en el Gestor de Servicios Tcnicos o en el GMAO1. En cul de los dos, depender de la potencia de uno u otro sistema. Qu ventaja adicional obtenemos al informatizar? Que en tiempo real todas las cifras se actualizan segn se resuelvan o produzcan nuevas incidencias, de manera que, nos permite modificar el plan de actuacin segn las nuevas ordenaciones resultantes, indicando a los equipos de mantenimiento que cambien de sector y corona en funcin de esta nueva ordenacin. Si adems, ya sea manualmente o por algn medio de localizacin (GPS...), podemos saber dnde estn distribuidos los equipos de mantenimiento y representarlos en el esquema de coronas, sera poner la guinda a un delicioso pastel. El smmum sera, si los operarios tuvieron conectividad permanente, a travs de algn tipo de terminal porttil lgico (TPL), donde se fueran reflejando todos estos cambios.

Gestor de Mantenimiento Asistido por Ordenador

252

5 UN PASO MS
En el ejemplo expuesto hace dos captulos, no distinguamos si el equipo con determinada prioridad era propia o adquirida. El resultado es que puede haber circunstancias que si reflejara esta condicin, la organizacin de las intervenciones podra variar. Para ello consideremos de nuevo la tabla:

1er Nivel de Prioridad Proximidad Alta Proximidad Media Proximidad Baja

Valor 2 Nivel de Prioridad Valor Cdigo Repercusin Alta 1 AA 1 Repercusin Media 2 AM Repercusin Baja 3 AB Repercusin Alta 1 MA 2 Repercusin Media 2 MM Repercusin Baja 3 MB Repercusin Alta 1 BA 3 Repercusin Media 2 BM Repercusin Baja 3 BB

Tabla de prioridades y su valor correspondiente Considerando el 2 Nivel de Prioridad, las combinaciones posibles controlando la prioridad propia y la prioridad adquirida consecuencia del tiempo de demora en intervenir son:

Valor Valor 2 Nivel de Prioridad Propio 2 Nivel de Prioridad Adquirido Suma Repercusin Alta 1 Repercusin Alta 1 2 Repercusin Media 2 Repercusin Alta 1 3 Repercusin Media 2 Repercusin Media 2 4 Repercusin Baja 3 Repercusin Alta 1 4 Repercusin Baja 3 Repercusin Media 2 5 Repercusin Baja 3 Repercusin Baja 3 6
Tabla de prioridades combinadas, valor propio-valor adquirido A la tabla le hemos aadido la suma de ambas prioridades. Es en base a esta suma y a la prioridad adquirida, como vamos a organizar las actuaciones. De partida, para todos los equipos la prioridad propia y adquirida coinciden. Partiendo de los mismos conceptos y reglas, el clculo de las medias es el siguiente: a. La media S no vara respecto del planteamiento inicial. b. La media P se calcula considerando la suma de las dos prioridades. 253

c. La media PA se calcula considerando la suma de las dos prioridades. La informacin mnima para cada trapecio circular es: 1. La media P. 2. Los equipos con incidencias de Repercusin Alta, Media y Baja. 3. Los equipos Crticos y Urgentes. Y para cada sector: 1. Las medias PA y S. 2. El nmero de equipos con incidencias de Repercusin Alta, Media y Baja. 3. Los equipos Crticos y Urgentes. En el captulo 3 se expuso un ejemplo en el cul, no se diferenciaba si la prioridad era adquirida o no. Inicialmente con el nuevo planteamiento tampoco, pero lo que si se ven alteradas son las medias. Con los mismos datos del supuesto final del captulo 3, para realizar los clculos, diferenciemos cuantos equipos a igualdad de prioridad propia, tienen diferente prioridad adquirida: Trapecio circular A: 0 equipos Repercusin Alta 0 equipos Repercusin Media 5 equipos Repercusin Baja, Repercusin Alta prioridades=20 5 equipos Repercusin Baja, Repercusin Baja prioridades=30 Sector A: PA = 5 S = 1 Trapecio circular B: 0 equipos Repercusin Alta 5 equipos Repercusin Media, Repercusin Alta prioridades=15 5 equipos Repercusin Media, Repercusin Media prioridades =20 0 equipos Repercusin Baja Sector B: PA = 3,5 S = 2

254

Trapecio circular C: 5 equipos Repercusin Alta, Repercusin Alta prioridades=10 0 equipos Repercusin Media 5 equipos Repercusin Baja, Repercusin Alta prioridades=20 Sector C: PA = 3 S = 3 Las conclusiones que podemos sacar del caso expuesto son: 1 2 La gestin que proporciona el control de las dos prioridades es ms eficiente. Solo es necesario mostrar en los equipos la prioridad adquirida. No obstante, si el sistema lo permite, se puede complementar mostrando en los equipos la prioridad propia. La complejidad aportada por este mtodo es nula.

La nica circunstancia en principio paradjica es, cuando en dos trapecios circulares de diferentes sectores (el resto de los trapecios de esos sectores no tienen incidencias), existan el mismo nmero de equipos con Repercusin MediaRepercusin Media y Repercusin BajaRepercusin Alta, ya que la suma de prioridades coincide. En este caso S, P y el volumen de equipos con incidencias activas por sector y trapecio circular, sern los factores que determinarn el orden de las actuaciones.

255

256

6 OTRA FORMA DE VER LO MISMO

Segn avanzamos captulos, estos muestran cmo podemos planificar considerando diferentes estrategias de priorizacin. Otra forma de ver lo mismo es, combinar los dos niveles de prioridad para producir el mismo resultado, en lugar de considerar exclusivamente el 2 nivel de prioridad y la evolucin segn la prioridad propia-adquirida. La gran diferencia con la estrategia anterior reside en el mtodo de evolucin, es decir, el recorrido posible que puede realizar la prioridad del equipo. Con la estrategia del 2 nivel, los equipos evolucionaban dentro de su mismo nivel de prioridad, manteniendo el primer nivel de prioridad invariable. En este segundo planteamiento, los equipos evolucionan adquiriendo la suma. Partiendo de la tabla de prioridades segn servicio:

1er Nivel de Prioridad Proximidad Alta Proximidad Media Proximidad Baja

Valor 2 Nivel de Prioridad Valor Cdigo Repercusin Alta 1 AA 1 Repercusin Media 2 AM Repercusin Baja 3 AB Repercusin Alta 1 MA 2 Repercusin Media 2 MM Repercusin Baja 3 MB Repercusin Alta 1 BA 3 Repercusin Media 2 BM Repercusin Baja 3 BB

Tabla de prioridades y su valor correspondiente

257

Si la representamos ordenadamente, obtenemos:

1er Nivel de Prioridad Proximidad Alta Proximidad Alta Proximidad Media Proximidad Alta Proximidad Media Proximidad Baja Proximidad Media Proximidad Baja Proximidad Baja

Valor 2 Nivel de Prioridad Valor Suma 1 Repercusin Alta 1 2 Repercusin Media 2 3 1 Repercusin Alta 1 3 2 Repercusin Baja 3 4 1 Repercusin Media 2 4 2 Repercusin Alta 1 4 3 Repercusin Baja 3 5 2 Repercusin Media 2 5 3 Repercusin Baja 3 6 3

Tabla de prioridades ordenada Esto significa que un equipo parte con una prioridad en el momento de la incidencia y trascurrido un tiempo, su valor ir disminuyendo hasta llegar a 2, nivel inmediatamente inferior al de CRTICO. Dos, son los posibles criterios a aplicar: Criterio 1) Si por ejemplo el equipo de partida posee Proximidad MediaRepercusin Baja, su siguiente nivel de evolucin es Proximidad BajaRepercusin Alta y as sucesivamente aunque repita el valor de la suma. Criterio 2) Si por ejemplo el equipo de partida posee Proximidad BajaRepercusin Alta (Suma=4), su siguiente nivel de evolucin es el correspondiente al primer valor inmediatamente inferior, es decir 3. Ambas opciones tienen sus pros y contras , sabiendo que en ambos casos la evolucin viene determinada por el tiempo de permanencia, convirtindose en factor diferenciador clave para el cambio de prioridad. El primer criterio es en principio ms justo, pues iguala oportunidades. De alguna manera, estamos estableciendo que, Proximidad BajaRepercusin Alta (4) es un nivel de prioridad intermedio entre Proximidad MediaRepercusin Baja (5) y Proximidad MediaRepercusin Media (4). Por contra, se hace obligatorio que, aunque a efectos de clculo solo sea necesario el resultado de la suma, intrnsecamente sea necesario controlar los dos niveles de prioridad. Con el segundo criterio se simplifica el grado de control, pues solo es necesario registrar el valor final. En contra tiene ser ms injusto, dado que evoluciona saltndose posibles permanencias en prioridades intermedias.

258

Cualquiera que sea el criterio aplicado, en cada trapecio circular seguir existiendo P y a nivel de sector S y PA. La informacin mnima para cada trapecio circular es: 1. La media P. 2. Los equipos con incidencias 2, 3 y 4 para los de Proximidad Alta. 2, 3, 4 y 5 para los de Proximidad Baja. 2, 3, 4, 5 y 6 para los de Proximidad Baja. 3. Los equipos Crticos y Urgentes. Y para cada sector: 1. Las medias S y PA. 2. Los equipos con incidencias cuya suma sea 2, 3, 4, 5 y 6. 3. Los equipos Crticos y Urgentes. En el esquema siguiente se muestra un ejemplo de tres trapecios circulares cuyo resultado es la misma PA y distinta S.
5 equipos Prioridad 2 0 equipos Prioridad 3 5 equipos Prioridad 4 0 equipos Prioridad 5 5 equipos Prioridad 6 PA = 4 S = 3

Proximidad Baja

Proximidad Media

Proximidad Alta

SAT

0 equipos Prioridad 2 0 equipos Prioridad 3 15 equipos Prioridad 4 PA = 4 S = 1

0 equipos Prioridad 2 5 equipos Prioridad 3 5 equipos Prioridad 4 5 equipos Prioridad 5 PA = 4 S = 2

El orden de actuacin lo determina la media del sector y si fuera necesario, el volumen de equipos con incidencias activas por sector y trapecio circular. 259

Las conclusiones que podemos sacar del caso expuesto son: 1. Controlar las dos prioridades aumenta la eficiencia de la gestin. 2. El arco de distribucin de las prioridades es mayor, aportando una visin global del sector. El primer mtodo solo proporcionaba una visin exclusivamente del trapecio circular. 3. En el mejor de los casos, solo es necesario controlar la prioridad resultante. Depender del criterio adoptado segn vimos. 4. La complejidad aportada es nula. Con el caso expuesto en el captulo anterior y la evolucin mostrada entre las prioridades propias-adquiridas, vamos a adaptarlo al mtodo expuesto en este captulo con los dos criterios posibles. Para evitar redundar informacin que no aporta nada, slo se mantienen para el ejemplo, los datos a convertir segn la nueva forma propuesta de control. El resto de informacin permanecera invariable, siendo innecesario mostrarla: Trapecio circular A: Los 5 equipos Repercusin Baja, Repercusin Alta prioridades=20 pueden ser segn: Criterio 1 prioridades=15. Estos equipos de partida son Proximidad AltaRepercusin Baja y evolucionan dos niveles, a Proximidad AltaRepercusin Media (Suma=3). Criterio 2 prioridades=10. Estos Equipos de partida son Proximidad AltaRepercusin Baja (Suma=4) y evolucionan a prioridad 2. Los 5 equipos Repercusin Baja, Repercusin Baja prioridades=30 pueden ser segn: Criterio 1 prioridades=20. Estos equipos mantienen su prioridad inicial, Proximidad AltaRepercusin Baja (Suma=4). Criterio 2 prioridades=20. Estos equipos mantienen su prioridad inicial. Proximidad AltaRepercusin Baja (Suma=4). Sector A: La PA = 5 puede ser segn: Criterio 1 PA = 3,5 Criterio 2 PA = 3 S = 1. Igual para los tres. Trapecio circular B: Los 5 equipos Repercusin Media, Repercusin Alta prioridades=15 pueden ser segn:

260

Criterio 1 prioridades=20. Estos equipos de partida son Proximidad MediaRepercusin Media y evolucionan un nivel, a Proximidad AltaRepercusin Baja (Suma=4). Criterio 2 prioridades=15. Estos equipos de partida son Proximidad MediaRepercusin Media (Suma=4) y evolucionan a prioridad 3. Los 5 equipos Repercusin Media, Repercusin Media prioridades=20 pueden ser segn: Criterio 1 prioridades=20. Estos equipos mantienen su prioridad inicial, Proximidad MediaRepercusin Media (Suma=4). Criterio 2 prioridades=20. Estos equipos mantienen su prioridad inicial, Proximidad MediaRepercusin Media (Suma=4). Sector B: La PA = 3,5 puede ser segn: Criterio 1 PA = 4 Criterio 2 PA = 3,5 S = 2. Igual para los tres. Trapecio circular C: Los 5 equipos Repercusin Alta, Repercusin Alta prioridades =10 pueden ser segn: Criterio 1 prioridades=20. Estos equipos mantienen su prioridad inicial, Proximidad BajaRepercusin Alta (Suma=4). Criterio 2 prioridades=20. Estos equipos mantienen su prioridad inicial, Proximidad BajaRepercusin Alta (Suma=4). Los 5 equipos Repercusin Baja, Repercusin Alta prioridades=20 pueden ser segn: Criterio 1 prioridades=25. Estos equipos de partida son Proximidad BajaRepercusin Baja y evolucionan dos niveles, a Proximidad MediaRepercusin Baja (Suma=5). Criterio 2 prioridades=20. Estos equipos de partida son Proximidad BajaRepercusin Baja (Suma=6) y evolucionan a prioridad 4. Sector C: La PA = 3 puede ser segn: Criterio 1 PA = 4,5 Criterio 2 PA = 4 S = 3. Igual para los tres. Varias son las conclusiones que se obtienen de los resultados: 1. Mientras que el primer mtodo est enfocado exclusivamente en funcin del servicio y slo considera la visin del mantenimiento 261

para las igualdades, plantearlo del todo as no es del todo rentable pues, puede que se den circunstancias muy similares de Repercusin entre Proximidad Baja y Proximidad Alta de diferentes sectores, y por una pequea diferencia, el mtodo obligue a realizar las actuaciones antes en el de Proximidad Baja que en el de Proximidad Alta. En los otros dos mtodos, estando tambin en funcin del servicio, la proximidad es el principal factor diferenciador para restitucin del mismo, aportando la ventaja frente al primero, que los equipos segn pasa el tiempo adquieren prioridades de niveles de proximidad inferiores, siendo ms notoria en aquellos que la evolucin se realiza como el resultado de la suma de prioridades. 2. El primer mtodo es el mejor, si el volumen de incidencias se mantiene en unos niveles bajos, o la proporcin de equipos con Repercusin Alta adquirida o CRTICO respecto del resto es moderado. Los mtodos que contemplan ambas prioridades son adecuados para volmenes medios-altos de incidencias, o para incidencias con suma de prioridades medias-bajas. 3. Los dos ltimos mtodos rentabilizan la proximidad al S.A.T. Sea cual sea el mtodo usado, tienen los tres un defecto importante. En los esquemas que a continuacin se muestran se puede ver con claridad. Ya sea en funcin del Servicio...
5 equipos Repercusin 1 0 equipos Repercusin 2 5 equipos Repercusin 3 PA = 2 S = 3

Proximidad Baja

Proximidad Media

Proximidad Alta

SAT

1 equipos Repercusin 1 0 equipos Repercusin 2 1 equipos Repercusin 3 PA = 2 S = 1

0 equipos Repercusin 1 5 equipos Repercusin 2 0 equipos Repercusin 3 PA = 2 S = 2

262

...o del Servicio y el Mantenimiento.

5 equipos Prioridad 2 0 equipos Prioridad 3 5 equipos Prioridad 4 0 equipos Prioridad 5 5 equipos Prioridad 6 PA = 4 S = 3

Proximidad Baja

Proximidad Media

Proximidad Alta

SAT

0 equipos Prioridad 2 0 equipos Prioridad 3 1 equipo Prioridad 4 PA = 4 S = 1

0 equipos Prioridad 2 5 equipos Prioridad 3 0 equipos Prioridad 4 5 equipos Prioridad 5 PA = 4 S = 2

Muestran que a igualdad de prioridad, aplicando la S, el orden de actuacin resultante sera: 1. El trapecio circular A, sector A que contiene en el primer esquema dos equipos y en el segundo esquema un equipo. 2. El trapecio circular B, sector B que contiene en el primer esquema cinco equipos y en el segundo esquema diez equipos. 3. El trapecio circular C, sector C que contiene en el primer esquema diez equipos y en el segundo esquema quince equipos. Excepto por algn razonamiento especial, como por ejemplo planificar las intervenciones en funcin de los trapecios circulares, parece difcil justificar esta ordenacin. No parece lo ms lgico mantenerla. Significa que los mtodos propuestos son malos? En absoluto. Si la diferencia entre el nmero de incidencias de cada sector no es muy radical, cualquiera de los mtodos es vlido. Uno de los factores para sectorizar, como se apunt, era el promedio de incidencias, asumiendo que en un momento determinado puede suceder esta contradiccin en la ordenacin. An as, si fuera nuestra responsabilidad mandar al equipo de intervencin, seguramente en un 99,9% de las veces nos decantaramos por enviarles directamente al trapecio ms alejado, donde hay mayor volumen de equipos sin prestar servicio. Para mejorar los mtodos hasta ahora vistos, es 263

necesario considerar adems al FACTOR DIFERENCIADOR. Hablaremos ms delante de l, pero por ahora continuemos desarrollando nuestro mtodo.

264

7 HACIENDO FILIGRANAS
Durante esta quinta parte hemos mezclado las prioridades para generar mtodos eficaces de planificacin y organizacin de las intervenciones. Hemos conjugado la visin de servicio con la de mantenimiento. Pero al hacerlo, nunca hemos considerado el Tiempo Medio de Resolucin. Combinando los tres conceptos:

Proximidad Repercusin Resolucin

Se antoja inicialmente como la mejor propuesta de todas. Pero la primera cuestin que se plantea es: En qu orden? Pues si hemos asumido como vlido en primer lugar Proximidad y posteriormente Repercusin, como consiste en afinar ms, Resolucin ser el tercer nivel de prioridad. Evidentemente no es una cuestin de capricho, si no de proporcionar un elemento diferenciador ms a igualdad de prioridades. En este supuesto, la tabla se amplia con una tercera clasificacin, resultado de considerar el esfuerzo reparador que demanda cada uno de los equipos.

265

La Tabla resultante es:

1er Nivel de Prioridad Valor 2 Nivel de Prioridad Repercusin Alta Proximidad Alta 1 Repercusin Media Repercusin Baja Repercusin Alta Proximidad Media 2 Repercusin Media Repercusin Baja Repercusin Alta Proximidad Baja 3 Repercusin Media Repercusin Baja 3er Nivel de Prioridad Resolucin Baja Resolucin Media Resolucin Alta Resolucin Baja Resolucin Media Resolucin Alta Resolucin Baja Resolucin Media Resolucin Alta Resolucin Baja Resolucin Media Resolucin Alta Resolucin Baja Resolucin Media Resolucin Alta Resolucin Baja Resolucin Media Resolucin Alta Resolucin Baja Resolucin Media Resolucin Alta Resolucin Baja Resolucin Media Resolucin Alta Resolucin Baja Resolucin Media Resolucin Alta

Valor 1 2 3

1 2 3

1 2 3

Valor Suma Cdigo 1 3 AAB 2 4 AAM 3 5 AAA 1 4 AMB 2 5 AMM 3 6 AMA 1 5 ABB 2 6 ABM 3 7 ABA 1 4 MAB 2 5 MAM 3 6 MAA 1 5 MMB 2 6 MMM 3 7 MMA 1 6 MBB 2 7 MBM 3 8 MBA 1 5 BAB 2 6 BAM 3 7 BAA 1 6 BMB 2 7 BMM 3 8 BMA 1 7 BBB 2 8 BBM 3 9 BBA

Tabla de prioridades combinada, valor y suma Cuando solo considerbamos dos prioridades, un equipo de Proximidad MediaRepercusin Baja era la misma, que un equipo de Proximidad BajaRepercusin Alta; y esta igualdad se mantiene suponiendo que la Resolucin es igual, pero en caso de ser distintas proporciona una nueva ordenacin.

266

La tabla resultante ordenada es:

1er Nivel de Prioridad Proximidad Alta Proximidad Alta Proximidad Alta Proximidad Media Proximidad Alta Proximidad Alta Proximidad Alta Proximidad Media Proximidad Media Proximidad Baja Proximidad Alta Proximidad Alta Proximidad Media Proximidad Media Proximidad Media Proximidad Baja Proximidad Baja Proximidad Alta Proximidad Media Proximidad Media Proximidad Baja Proximidad Baja Proximidad Baja Proximidad Media Proximidad Baja Proximidad Baja Proximidad Baja 3er Nivel de Prioridad Resolucin Baja Resolucin Media Resolucin Baja Resolucin Baja Resolucin Alta Resolucin Media Resolucin Baja Resolucin Media Resolucin Baja Resolucin Baja Resolucin Alta Resolucin Media Resolucin Alta Resolucin Media Resolucin Baja Resolucin Media Resolucin Baja Resolucin Alta Resolucin Alta Resolucin Media Resolucin Alta Resolucin Media Resolucin Baja Resolucin Alta Resolucin Alta Resolucin Media Resolucin Alta

Valor 1 1 1 2 1 1 1 2 2 3 1 1 2 2 2 3 3 1 2 2 3 3 3 2 3 3 3

2 Nivel de Prioridad Valor Repercusin Alta 1 Repercusin Alta 1 Repercusin Media 2 Repercusin Alta 1 Repercusin Alta 1 Repercusin Media 2 Repercusin Baja 3 Repercusin Alta 1 Repercusin Media 2 Repercusin Alta 1 Repercusin Media 2 Repercusin Baja 3 Repercusin Alta 1 Repercusin Media 2 Repercusin Baja 3 Repercusin Alta 1 Repercusin Media 2 Repercusin Baja 3 Repercusin Media 2 Repercusin Baja 3 Repercusin Alta 1 Repercusin Media 2 Repercusin Baja 3 Repercusin Baja 3 Repercusin Media 2 Repercusin Baja 3 Repercusin Baja 3

Valor Suma 1 3 2 4 1 4 1 4 3 5 2 5 1 5 2 5 1 5 1 5 3 6 2 6 3 6 2 6 1 6 2 6 1 6 3 7 3 7 2 7 3 7 2 7 1 7 3 8 3 8 2 8 3 9

Tabla de prioridades ordenada De la misma manera que plantebamos en el captulo anterior, dos pueden ser los Criterios a adoptar: Criterio 1) Si por ejemplo el equipo de partida posee Proximidad MediaRepercusin BajaResolucin Baja, su siguiente nivel de evolucin es Proximidad MediaRepercusin Media Resolucin Media y as sucesivamente aunque repita el valor de la suma. Criterio 2) Si por ejemplo el equipo de partida posee Proximidad BajaRepercusin AltaResolucin Alta (Suma=7), su siguiente nivel de evolucin es el correspondiente al primer valor inmediatamente inferior, es decir 6.

267

Y las mismas conclusiones se establecen para este mtodo, con la salvedad, de que los tiempos de permanencia en cada nivel deben acortarse para que se permita un mejor escalamiento, con mayor relevancia an si el criterio adoptado es el primero. El rango es un 40% mayor lo que permite una mejor distribucin, y aunque podemos tener las mismas coincidencias que en los mtodos anteriores, la concurrencia de partida entre los equipos, tericamente disminuye. En cada trapecio circular seguir existiendo P y a nivel de sector S y PA. La informacin mnima para cada trapecio circular es: La media P. El total de equipos con prioridad 3, 4, 5, 6 y 7 para los de Proximidad Alta. 3, 4, 5, 6, 7 y 8 para los de Proximidad Baja. 3, 4, 5, 6, 7, 8 y 9 para los de Proximidad Baja. Los equipos Crticos y Urgentes.

Y para cada sector: Las medias S y PA. El total de equipos cuya suma de prioridades sea 3, 4, 5, 6, 7, 8 y 9. Los equipos Crticos y Urgentes.

Pero, aunque este mtodo proporcionado permite unos niveles altos de distribucin, y por lo tanto, mejora sensiblemente la planificacin, seguimos dependiendo de que la ordenacin resultante sea supervisada, para evitar situaciones como la expuesta al final del captulo anterior.

268

8 EL FACTOR DIFERENCIADOR
Es evidente, que considerando solo las medias, no es factible optimizar del todo la ordenacin de las actuaciones, ms si se tiene en cuenta, que puede suceder una situacin como la siguiente:
10 equipos Prioridad 2 1 equipo Prioridad 3 0 equipos Prioridad 4 0 equipos Prioridad 5 0 equipos Prioridad 6 PA = 2.1 S = 3

Proximidad Baja

Proximidad Media

Proximidad Alta

SAT

1 equipos Prioridad 2 0 equipos Prioridad 3 0 equipos Prioridad 4 PA = 2 S = 1

Donde se aprecia claramente que la ordenacin resultante es: Trapecio circular A, sector A que contiene un equipo. Trapecio circular C, sector C que contiene once equipos. Esta situacin es consecuencia de las medias aglutinadas. En principio, no parece oportuno mandar a los operarios al sector A, realizar una actuacin y acto seguido, se desplacen al trapecio circular C, cuando en ste existen once equipos, de los cuales, diez de ellos tienen la misma prioridad que el equipo del trapecio circular A. Con el ejemplo visto, si es frecuente que pueda ocurrir tal radicalidad de incidencias diferentes en distintos sectores y trapecios circulares, ser necesario correlacionar el nmero de equipos con incidencias, con las medias. Pero esta consideracin no va a ser nada fcil estandarizarla. -Mecachis! 269

Perdn. Estaba pensando en voz alta. La razn de la broma no es otra que hemos llegado a un punto muy delicado. Para poder relacionar las prioridades resultantes con el nmero de equipos, ser necesario desarrollar una funcin que nos permita obtener una prioridad resultante de ambos conceptos, de manera que al principio, el decremento de la prioridad sea muy significativo, atenundose a medida que el volumen de equipos aumenta. La grfica tendra la siguiente forma:

PRIORIDAD
0

11

EQUIPOS

21

La cuestin es, determinar la Funcin que rena las condiciones necesarias respecto del orden a establecer, en funcin del volumen de equipos.

270

Sin entrar en anlisis matemticos, pues estn fuera del alcance del presente libro, en la siguiente tabla:

equipos 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
...resultado de la Funcin:

prioridad P(equipos,prioridades) 60 50 40 30 3 4 5 6 9,7 9,1 8,4 7,4 3 4 5 6 6,3 5,9 5,4 4,8 3 4 5 6 4,9 4,6 4,2 3,7 3 4 5 6 4,1 3,8 3,5 3,1 3 4 5 6 3,6 3,3 3 2,6 3 4 5 6 3,2 3 2,7 2,3 3 4 5 6 2,9 2,7 2,5 2,1 3 4 5 6 2,7 2,5 2,2 1,9 3 4 5 6 2,5 2,3 2,1 1,8 3 4 5 6 2,4 2,2 1,9 1,6 3 4 5 6 2,2 2 1,8 1,5 3 4 5 6 2,1 1,9 1,7 1,4 3 4 5 6 2 1,8 1,6 1,4 3 4 5 6 1,9 1,8 1,5 1,3 3 4 5 6 1,8 1,7 1,5 1,2 3 4 5 6 1,8 1,6 1,4 1,2 3 4 5 6 1,7 1,5 1,4 1,1 3 4 5 6 1,6 1,5 1,3 1,1 3 4 5 6 1,6 1,4 1,3 1 3 4 5 6

P(prioridad,equipos)=

prioridad*10 prioridad*LN(equipos)+equipos

...se muestra la Prioridad resultante (zona verde), calculada partiendo del nmero de equipos (zona anaranjada) y de la PA (zona amarilla). Para simplificar el ejemplo expuesto, el rango de valores de la PA que se ha considerado, vara entre 3 a 6.

271

Las grficas muestran el siguiente aspecto:

PRIORIDAD

1 1 3 5 7 9 11 13 15 17 19 EQUIPOS

De la tabla observamos que, 8 equipos cuya PA -prioridad en la tabla- sea 3 (P=2,1) tiene la misma P resultante que 10 equipos con PA igual a 4, 13 equipos con PA igual a 6. La frmula propuesta, en la que PA forma parte tanto del numerador como del denominador, genera una grfica en la que la atenuacin es menor que si se usara un valor fijo en el denominador. Se busca con la Funcin expuesta, primar la organizacin por sectores con mayor volumen de equipos y mayor PA antes, que menos equipos con menor PA y con un incremento/diferencia de equipos relativamente pequeo. Veamos el comportamiento de la siguiente Funcin, en la que ya no consideramos en el denominador la prioridad y lo sustituimos por un valor fijo:

P(prioridad,equipos)=

prioridad*10 2*LN(equipos)+equipos

272

La tabla resultante considerando los mismos supuestos de partida que la anterior es:
equipos 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 prioridad P(equipos,prioridades) 3 4 5 6 30 40 50 60 3 4 5 6 8,8 11,8 14,7 17,6 3 4 5 6 5,8 7,7 9,6 11,5 3 4 5 6 4,4 5,9 7,4 8,8 3 4 5 6 3,7 4,9 6,1 7,3 3 4 5 6 3,1 4,2 5,2 6,3 3 4 5 6 2,8 3,7 4,6 5,5 3 4 5 6 2,5 3,3 4,1 4,9 3 4 5 6 2,2 3,0 3,7 4,5 3 4 5 6 2,1 2,7 3,4 4,1 3 4 5 6 1,9 2,5 3,2 3,8 3 4 5 6 1,8 2,4 2,9 3,5 3 4 5 6 1,7 2,2 2,8 3,3 3 4 5 6 1,6 2,1 2,6 3,1 3 4 5 6 1,5 2,0 2,5 2,9 3 4 5 6 1,4 1,9 2,3 2,8 3 4 5 6 1,3 1,8 2,2 2,6 3 4 5 6 1,3 1,7 2,1 2,5 3 4 5 6 1,2 1,6 2,0 2,4 3 4 5 6 1,2 1,5 1,9 2,3

y las grficas:
10 9 8 7 6 5 4 3 2 1 1 3 5 7 9 11 13 15 17 19

La primera conclusin es que la atenuacin es an mayor. Comparando el mismo resultado que para la primera frmula, 8 equipos cuya PA sea 3 (P=2,5), tiene la misma P que 11 equipos con PA igual a 4, 18 equipos con PA igual a 6. En este 273

caso, el incremento de equipos para modificar la organizacin de los sectores debe ser significativamente superior, cuanto mayor es la PA. El procedimiento que se escoja, es decir, la frmula a aplicar, vendr determinada por el criterio organizativo que mejor est alineado con el Mantenimiento, los Servicios Tcnicos o ambos. En cualquier caso es una estrategia y es nica (Seguro?). Ese es su mayor inconveniente; que adoptada la estrategia es invariable. La frmula aplicar siempre por igual, sean cuales sean las circunstancias, y puede ser favorable en la mayora de las situaciones, pero tambin contraproducente. No siempre el mantenimiento es una frmula matemtica. No obstante, es lgico pensar que en un porcentaje muy elevado dar formal cumplimiento, estableciendo la planificacin y organizacin ptimas, para una eficaz intervencin del mantenimiento y eficiente restitucin del servicio. La pregunta que surge en estos momentos es: Qu es mejor, adoptar una nica estrategia o disponer de varias? Y en el caso de varias eso significa, qu se aplicarn frmulas diferentes a cada Sector con los problemas derivados de aplicar distintos criterios comparativos para planificar? La madeja as planteada parece difcil de desenredar. Sin embargo, y como hemos ido planteando a lo largo del libro, lo ms simple es lo ms eficaz, o lo ms eficaz es lo ms simple. Que lleva a que es discutible, pero se cumple casi siempre. Este captulo comienza, planteando un ejemplo con una PA menor en un Sector con un solo equipo, que en otro Sector con once equipos. Solo con el ejemplo, ya es posible plantear tres posible estrategias: 1. Planificacin de los Sectores por la PA. Esta es la estrategia que se ha planteado desde el principio. 2. Planificacin de los Sectores por el mayor numero de equipos. 3. Planificacin de los Sectores por el menor numero de equipos. Disponemos de tres formas de acometer las intervenciones, muy radicales las dos ltimas, pero que combinadas entre ellas nos amplan el abanico de estrategias: 1. Planificacin de los Sectores por la PA, aproximndola al valor de su entero ms prximo. Es decir, si un Sector tiene de PA 2,3 su PA resultante es 2. Si su PA es 2,7 su PA resultante es 3. 2. Planificacin de los Sectores por la PA, aproximndola al valor de su entero inferior ms prximo. Es decir, si un Sector tiene de PA 2,3 su PA resultante es 2. Si su PA es 2,7 su PA resultante es 2. 3. Planificacin de los Sectores por la PA, en franjas de 0,5 en 0,5, aproximando su valor al inferior de la franja ms prximo. Es decir, si un Sector tiene de PA 2,3, su PA resultante es 2. Si su PA es 2,7 su PA resultante es 2,5.

274

4. Cualquiera de los dos ltimos planteamientos anteriores combinado con el volumen de equipos, de manera que, dos Sectores con consecutivas PA y una diferencia superior a un determinado nmero de equipos a favor del de mayor PA, conmutan su orden. 5. Otras... Podemos seguir proponiendo estrategias, pero con las mostradas son ms que suficientes para comprender las mltiples posibilidades con las que planificar las intervenciones de mantenimiento. Incluso, podemos recuperar para el conjunto de estrategias, las funciones propuestas en prrafos anteriores. Qu hacemos con todo este galimatas? Implementar en la herramienta la posibilidad de mostrar una tabla con las diferentes ordenaciones propuestas y tantos esquemas de Coronas/Sectores como estrategias activas. Lo lgico es que este nmero de estrategias sea moderado. No ms de dos o tres parece lo ms adecuado. Ms sera posiblemente complicarnos en exceso y no ser eficaces. Lo que si se debe procurar es implementar la posibilidad de modificarlas, e incluso, cambiarlas por otras. Y ahora qu?

275

276

9 EL FACTOR HUMANO
Y ahora qu? Dejbamos en el aire esta pregunta. Pues que para ser operativos con las propuestas realizadas en el captulo anterior, tenemos dos posibilidades: 1. Contar con un Sistema Experto. 2. Contar con Gestores de Mantenimiento. El primero por se muestra harto difcil. Es por medio de las personas responsables del mantenimiento, cmo a travs de las diferentes ordenaciones proporcionadas por la herramienta y su visualizacin grfica por los esquemas de Coronas/Sectores, determinar el orden definitivo, que en el mejor de los casos, podra coincidir con alguna de las ordenaciones consecuencia de una estrategia en concreto. Y debe ser as, porque todo el empeo mostrado en esta QUINTA PARTE tiene como finalidad, disear un mtodo cientfico de priorizacin que permita tener mltiples planificaciones, es decir, mltiples propuestas, y considerando los condicionantes especficos propios del Mantenimiento y de los Servicios Tcnicos, poder organizar las intervenciones de la manera ms eficaz. Las prioridades y las estrategias mostradas son consecuencia de premisas de partida estables, Tiempos de Desplazamiento, Tiempos de Resolucin, Impacto en los Servicios Tcnicos,... pero adems, existen muchos otros factores que pueden alterar los planteamientos iniciales. Son las personas el factor que proporciona el Sentido organizativo. Sin entrar en las mltiples causas que pueden alterar una determinada ordenacin, la aportacin del conocimiento de los mandos, tcnicos, operarios... se vuelve imprescindible para solventar muchas circunstancias imposibles de considerar en el momento de disear una estrategia. Muchas de estas circunstancias no tienen slo que ver con la propia actividad de mantenimiento o explotacin del equipamiento de los Servicios Tcnicos. Por poner un ejemplo, pueden existir circunstancias que en un determinado momento, recomienden actuar de inmediato sobre un equipo con bajo impacto, porque ya existan otros equipos ms prioritarios que no estn prestando servicio. Qu sera lo ideal o casi la herramienta perfecta? Pues que todas las ordenaciones resultantes de la intervencin humana fueran programadas dentro del sistema , para que cuando se dieran circunstancias similares, no fuera necesario por parte de la persona reformarlas, si no que el sistema nos las ofreciera, consecuencia de la experiencia acumulada y parametrizada en la herramienta. Toda nueva situacin se incorporara al sistema enriquecindolo. Poco a poco tendramos el primer punto de este captulo, un Sistema Experto que a medida que crece, mejora el asesoramiento a los responsables de gestionar el mantenimiento.

277

278

10 ENTENDIENDO LAS INCIDENCIAS

Todo el esfuerzo hasta ahora reflejado, sobre la importancia del mantenimiento como una de las actividades clave en los Servicios Tcnicos, quizs no se entendiera, si no diramos una vuelta de tuerca ms en comprender la naturaleza de las incidencias, como recurso esencial de informacin para los equipos no monitorizados. En la parte segunda se defini incidencia como: Aqul suceso producido en los equipos, sistemas o instalaciones mantenidas, que repercute en la prestacin de uno o varios Servicios Tcnicos Si ya estaba claro, por qu volver a hablar de las incidencias. Porque todo lo expuesto sirve para planificar y organizar el mantenimiento, en funcin de las incidencias que repercuten en el Servicio Tcnico. Pero existen muchas otras incidencias que se producen sobre los equipos que no repercuten. La gestin de este tipo de incidencias debe tratarse con los criterios propios del anlisis de las mismas. Es prctica comn en las organizaciones dedicadas al mantenimiento, considerar toda notificacin producida sobre un equipo o instalacin como incidencia de correctivo. La definicin ms comn de mantenimiento correctivo es: El que se lleva a cabo con el fin de corregir (reparar) una falla en el equipo o instalacin, restaurando sus condiciones de origen Por principio, incidencia de correctivo debera solo considerarse la que provoca parada o disminucin de funcionalidades, pero es siempre cierto este planteamiento? Con algunos ejemplos vamos a dar luz en tanta sombra. Ejemplo 1) En una mquina expendedora de comida se raja el cristal frontal, pero la mquina sigue dispensndola. Un cristal rajado supone un peligro evidente para un usuario. Si al comunicar la incidencia la mquina sigue suministrando los productos, no se considerar incidencia. Por contra, si por seguridad, ante el peligro que supone el cristal rajado la expendedora se apaga, si ser considerada incidencia. Ejemplo 2) En una escalera mecnica se detecta un ruido. La escalera contina funcionando. No obstante, la aparicin de un ruido generalmente es sntoma de que algo se ha estropeado, y si no se acta y repara el posible fallo, la escalera terminar 279

por pararse. De cara al servicio no es una incidencia, pero debemos darle una consideracin extraordinaria por la probabilidad manifiesta de que con el tiempo si afecte. Ejemplo 3) En un surtidor de gasolina, la luz que ilumina el cartel publicitario de la compaa por las noches no funciona. Esta situacin puede prolongarse todo el tiempo que sea, que el servicio no se ve nunca afectado. La notificacin asociada nunca ser considerada incidencia. Estos tres ejemplos bastan para determinar, que todas las posibles notificaciones que se realicen de un equipo deben ser tipificadas, para distinguir cuando hay que considerarlas incidencias o no. La gestin que se realice depender del tratamiento en cada caso. En lneas generales: 1) Si la incidencia provoca que el equipo tenga una Situacin Operativa diferente de En Servicio, o se mantiene en dicho Estado pero con degradacin (Incidencia Operativa), ser considerada como incidencia tcnica. 2) Si la incidencia por si sola no es motivo de alteracin de la Situacin Operativa, o de la aparicin de una Incidencia Operativa, pero por la circunstancia que sea se comunica con la alteracin o la degradacin, se considerar como incidencia tcnica. 3) Si la incidencia con el tiempo puede alterar la Situacin Operativa o provocar una Incidencia Operativa, no tendr la consideracin de incidencia tcnica, pero formar parte de ellas a modo de subconjunto. Su tratamiento puede contemplarse, desde el punto de vista de asignar a los equipos prioridades especiales muy bajas, hasta realizar una gestin paralela a las incidencias tcnicas, con los mismos esquemas, grficos y prioridades que se han establecido, para la planificacin y organizacin del mantenimiento. 4) Si la incidencia no puede alterar la Situacin Operativa o provocar una Incidencia Operativa, no tendr la consideracin de incidencia tcnica. Su tratamiento es ajeno al mantenimiento correctivo. Podrn ser planificadas junto con mantenimientos preventivos, predictivos, actuaciones peridicas... La importancia por diferenciar las incidencias definidas como tcnicas, de aqullas que no lo son reside, no slo en el perjuicio producido a los Servicios Tcnicos ante una falta de orientacin del mantenimiento y como consecuencia mala oferta de servicio, si no que todo indicador cuyo objetivo sea medir el mantenimiento (Tiempos de Respuesta, Tiempos de Resolucin...), se ver distorsionado y con toda seguridad perjudicado. Las conclusiones que deriven del anlisis de estos indicadores tendrn ese mismo grado de error, o incluso, superior.

280

11 CERRANDO EL CIRCULO
Ya lo decamos en el captulo dos, que esta parte dara para hacer no un libro si no varios, y que de la experiencia de cada organizacin y de la propia explotacin de los equipos, dentro del marco de los Servicios Tcnicos, el conjunto de actividades para pginas y pginas. ... y dejamos una frase sin acabar. Al final, lo que empezaban como unas directrices, ha terminado convirtindose en un mtodo de Gestin de Mantenimiento, es decir, en una metodologa. Hemos combinado las exigencias del Servicio con los requerimientos del Mantenimiento, pero continuamente hemos mencionado que pueden existir muchas y diversas actividades en torno al equipamiento. Esto significa que en un momento determinado puede interesar, que en lugar de contar con un Centro de Gestin de Mantenimiento, haya la necesidad de aglutinar la supervisin y control de las actividades en un Centro de Gestin Integrado, y la priorizacin de los equipos se realice, conjugando aquellos aspectos propios de cada una de ellas. Estoy convencido de que para cada captulo de esta quinta parte es posible escribir mucho ms, aportando multitud de consideraciones que afinen y pulan los patrones a seguir establecidos. Cualquier actividad, no deja de ser un proceso de cambio continuo, mejorando todo aquello que signifique un paso ms hacia la excelencia. Y para ser excelentes es muy importante, contar con armas que nos ayuden a desarrollar y mejorar nuestras competencias, sabiendo que nuestros esfuerzos, deben estar encaminados a proporcionar el mejor Servicio. Para conseguirlo, contamos con una herramienta que nos permite medir la oferta de servicio y adems, converger la visin del cliente y del proveedor:

281

282

SEXTA PARTE ORGANIZANDO LAS INTERVENCIONES

283

284

NDICE SEXTA PARTE

1 2 3 4 5 6 COMENZAMOS OTRA VEZ ............................................................................ 287 ORIENTANDO EL MANTENIMIENTO (Y NO ES REPETICION) .................... 289 QU HACEMOS? .......................................................................................... 295 COMPLICANDO LAS COSAS ........................................................................ 301 MECANISMO DE CONTROL .......................................................................... 307 RESUMEN ....................................................................................................... 309

285

286

1 COMENZAMOS OTRA VEZ

Tengo que reconocer que, cuando acab la parte dedicada a los Servicios Tcnicos y el Mantenimiento, una sensacin de alivio y gratitud fueron la consecuencia de un intenso trabajo, no sin cierta dificultad. El gran reto que actualmente tienen los departamentos de mantenimiento, pero tambin cualquier departamento cuyo finalidad est tan directamente relacionado con la prestacin de un servicio, es tener un sistema que les permita automatizar en la medida de lo posible su actividad. Pero como no hay mejor crtico que uno mismo, el gran problema que plantea la metodologa de PRIORIDADES, es la necesidad de implementarla en un sistema informtico; y claro, eso representa como poco incremento de costes, pues aunque se disponga de una herramienta como la comentada de SAP R/31 y su mdulo de mantenimiento, no significa que se pueda implementar directamente. Es ms, el planteamiento formulado necesita de un desarrollo a medida, cuyos aspectos ms destacables a realizar y/o implementar son: 1 - Anlisis de los Tiempos Medios de desplazamiento. 2 - Anlisis de los Tiempos Medios de intervencin. 3 - Ordenacin del equipamiento en funcin de su participacin en el Servicio Tcnico. 4 - Reorganizacin de los SAT existentes con lo que ello implica (locales, almacenes de repuesto, generacin de los equipos de intervencin,...). 5 - Implementacin en el inventario de equipos de las prioridades de partida, como un atributo o caracterstica ms. 6 - Implementacin en los mecanismos de Gestin de Incidencias del control de las prioridades. 7 - Mecanismos informticos que controlen la evolucin de estas prioridades, en funcin del mtodo adoptado y los criterios de tiempo. 8 - Desarrollo del interfaz grfico de coronas y sectores, para facilitar a los gestores de la actividad las planificaciones, en funcin de los recursos y volumen de incidencias. Me dejo algo? Seguro, pero a grosso modo las cuestiones ms significativas estn contempladas. La idea es clara, pero si no contamos con una partida presupuestaria poco podemos hacer. Al final, todo se traduce en dinero y muchas de las buenas ideas mueren, por no disponer de recursos econmicos. Si adems queremos proporcionar estos mtodos de organizacin, a todos los agentes cuya actividad repercuta en el Servicio Tcnico, el esfuerzo de alinearlos es
1

SAP (System, Anwendungen und Produkte -Sistemas, Aplicaciones y Productos-) Software de gestin integrada orientado al mundo empresarial. Se ha tratado en la parte segunda.

287

un coste adicional que es indispensable considerar. No olvidemos, que construir un Servicio Tcnico tena entre otros por objetivo, identificar a todos los responsables. Cmo podemos entonces plantear una metodologa, aprovechando los recursos que disponemos? Evidente. Con los mecanismos implementados en el Gestor de Servicios. No ser tan directo como el planteado segn las prioridades combinadas, pero es perfectamente vlido para organizar y planificar las intervenciones. Quedmonos por ahora con la idea de Mecanismo de Control. Cul era otro de los objetivos de disear un Servicio Tcnico? Como desarrollaremos ms en profundidad en la parte dedicada a la Gestin de Servicios, medirlo para establecer acuerdos con nuestros clientes, con nuestros usuarios. Pero tambin, desde una visin ms introvertida , controlar la actividad que desarrollamos, valorar los recursos y medios que disponemos, auditar los procesos, garantizar las metodologas aplicadas, validar los indicadores tcnicos establecidos, al final, qu servicio somos capaces de ofertar. Con las condiciones de partida, si queremos orientar el mantenimiento para ofertar un buen nivel de servicio, algn recurso o instrumento tendremos que ofrecer al mantenedor y por supuesto tambin, al resto de agentes implicados. La hemos desarrollado a lo largo del libro:

EL GESTOR DE SERVICIOS
Como tal, es una herramienta para gestionar. En este caso, si el factor humano ya era importante como hemos destacado anteriormente, ahora va a ser vital. Pero adems, alguna tcnica o mtodo que conjuntamente con el Gestor de Servicios, permita a cualquier departamento que participe en el servicio organizar sus intervenciones. A fin de cuentas, aunque seamos los ms capacitados para realizar nuestro trabajo, est demostrado que ordenar sobre una propuesta, en lugar de hacerla partiendo de cero, siempre es ms eficiente... y cmoda. pero no adelantemos acontecimientos.

288

2 ORIENTANDO EL MANTENIMIENTO (Y NO ES REPETICION)

El primer paso casi es inmediato. Una vez puesto en marcha el Servicio Tcnico y realizados los ajustes necesarios en la distribucin de los Pesos Operativos, del anlisis de las primeras cifras obtenidas del Estado del Servicio y Disponibilidad del Servicio obtendremos los equipos clave Crticos. Estos equipos y su equipamiento implicado merecen especial atencin, pues cualquier incidencia tcnica, de explotacin, de logstica, degradaciones, p rovocarn cadas significativas en los indicadores. En muchos Servicios Tcnicos, el porcentaje de contribucin en el indicador ser tan alto, que es lgico establecer sobre ellos y tambin sobre el equipamiento relacionado, procedimientos de atencin y resolucin especiales. As empezbamos el captulo COMO LOS SERVICIOS TCNICOS ORIENTAN EL MANTENIMIENTO, pero ahora no estamos en disposici n de hacerlo aunque sea evidente. La lgica nos dice que, aunque sea manualmente, generarnos una tabla reflejando los equipos con mayor Peso Operativo y a su vez, el de los Niveles de Agregacin de Servicio sucesivos que ms inciden negativamente en el servicio, nos podra ayudar a planificar las intervenciones. Pero vamos a demostrar que quizs no sea lo ms adecuado. Con la anterior propuesta por medio de las prioridades, conjuntamos cientfica y razonadamente un mtodo que organiza las intervenciones, y solo el toque experto final del gestor, era necesario para corregir posibles situaciones extremas atpicas. Nos atrevamos a plantearlo como un Cuadro de Mando que permite tomar decisiones tremendamente eficaces, y que adems, permite conjugar con la integracin oportuna, a todos los agentes que participen de la oferta de servicio, pues tienen un nexo comn, el indicador Estado del Servicio. Tanto este indicador, como la Disponibilidad del Servicio, tienen una orientacin final clara: establecer Acuerdos de Nivel de Servicio (SLAs). Se pacten o no estos acuerdos, las condiciones de explotacin e intervencin determinarn para cada Nivel de Agregacin de Servicio, incluso a nivel del equipamiento, los valores habituales de ambos indicadores. Aunque no existieran acuerdos de nivel de servicio, conocer el Nivel de Servicio es esencial. Entonces, qu es lo primero que debemos hacer? Determinar estos umbrales, que vendrn condicionados por la capacidad productiva en su conjunto de, mantenedores, operadores, explotadores, la propia demanda, e insisto, sean o no considerados, Acuerdos de Nivel de Servicio. Para establecer una nueva forma de orientar el mantenimiento, no queda ms remedio que retomar las Tablas de Conversin, por medio de las cuales, establecamos el indicador Nivel de Servicio Ofertado.

Mientras la aguja del tacmetro no llegue a la zona roja, el rgimen de revoluciones es el correcto
289

As vamos a hacer para planificar el mantenimiento. Manejar una lista segn impacto en el servicio, puede degenerar en una atencin desmedida sobre aquellos que ocupan los primeros puestos dentro del ranking y un olvido rayando la discriminacin a los ltimos de la fila. Es ms, si l os departamentos de mantenimiento, como sera lo lgico, tienen establecidos indicadores para incentivar y motivar a sus trabajadores, con la finalidad de mejorar los tiempos de respuesta, los tiempos de intervencin,... si dejamos que la lista marque el orden y ritmo de las intervenciones, estamos generando conflictos de toda ndole, desde los sociales hasta los laborales. Por eso es muy importante establecer y determinar los umbrales, pero... y aqu empiezan los problemas. No es fcil definir los lmites, o mejor dicho, los rangos entre los cuales podemos considerar que nuestro Estado del Servicio es aceptable, es asumible o es inadecuado. La eleccin de estos adjetivos no est hecha al azar. Cada uno de ellos engloba otras consideraciones. Un valor aceptable ser aquel comprendido entre la plenitud de oferta, generalmente el 100% y el valor porcentual que delimite, cuando la prdida de servicio genera malestar en el usuario, el cliente, el explotador,... Muy importante es encontrar el equilibrio entre, dnde somos capaces de llegar con los medios que contamos y cundo se est generando incomodidad. Este ejercicio es crucial para saber llegar a pactar, si finalmente se establecen, Acuerdos de Nivel de Servicio. O no establecindolos, conocer la capacidad productiva de los intervinientes. Con estas premisas dejamos la puerta abierta para desarrollar un trabajo exhaustivo y determinante, pues mientras la situacin de incomodidad y el grado de sta es fcil tenerla clara, el de satisfaccin no es igual, y puede que tengamos que educar a nuestro cliente, plantearnos inversiones y la rentabilidad de la mismas, reorganizaciones departamentales, reestructurar la logstica,.... todo esto tambin formaba parte del por qu implementar Servicios Tcnicos. Superado el umbral y dentro de lo razonable, podemos encontrarnos con situaciones que no prestando el servicio aceptablemente, las condiciones del momento, la duracin, la demanda,.... y siendo conscientes que entramos en un rango de valores donde la incomodidad es sentida o interpretada de muchas formas diferentes, es posible asumirla. Claramente es una situacin a corregir sin que se dilate en el tiempo, pero que nos permite jugar con una cier ta flexibilidad de actuacin en funcin del Estado del Servicio propio y del resto de Niveles de Agregacin del Servicio. Aunque por lgica, daremos prioridad comparativa a los Estados de Servicio de igual nivel de agregacin. Cuando el Estado de Servicio ya no es asumible, debemos considerarlo inadecuado, Quizs el adjetivo a aplicar aqu sea lo menos complicado, en comparacin con los problemas asociados a este nivel de prestacin. Lo cierto es, que en teora significa un perjuicio sustancial, y digo en teora, porque como hemos visto a lo largo del libro, podemos haber desarrollado Servicios Tcnicos que mostrando un valor bajsimo, incluso casi nulo del Estado del Servicio, por las circunstancias de la demanda y conociendo la variacin de la misma en el tiempo, no implique perjuicio real. Pero 290

siempre ser una circunstancia temporal y que puede ser til entre otras cosas, por ejemplo, para planificar intervenciones programadas. Hemos realizado lo ms significativo, y a la vez ms sencillo, para tener el mtodo que nos ayude a orientar cualquier actividad. Cuando diseamos el indicador Nivel de Oferta, nos apoyamos en una escala de 0 a 5, que nos aportaban en principio una variedad de niveles lo suficientemente flexible, como para establecer el rango de los mismos en funcin del servicio ofertado en cada momento. Estos valores deben ayudar a precisar los tres niveles que hemos establecido, y aportar un poco ms de informacin, de manera que permita, a quien est gestionando, tomar decisiones lo ms eficientes posibles. Sin entrar en mayores consideraciones y sin profundizar en los razonamientos posibles, por la experiencia, se me antojan dos formas de asociar el rango de valores a los tres niveles. Asociacin 1) Para el nivel aceptable, el valor asociado ser siempre 5. Para el nivel asumible, asociaremos los valores 4, 3 y 2. El truco es establecer dentro del rango asumible subumbrales, de manera que el valor numrico nos indique el margen de criticidad en el que nos hayamos dentro del nivel. Para el nivel inadecuado el valor asociado es 1. El valor 0 se asocia a cuando no haya oferta del servicio, es decir, cuando el Estado del Servicio es 0%. Asociacin 2) Para el nivel aceptable, asociaremos los valores 5 y 4. Con esta forma conseguimos tener un valor que nos indica cuando podemos estar en situacin prxima a cambiar de nivel. Para el nivel asumible, asociaremos los valores 3 y 2. Conceptualmente igual que en el caso anterior. Para el nivel inadecuado el valor asociado es 1. El valor 0 se asocia a cuando no haya oferta del servicio, es decir, cuando el Estado del Servicio es 0%. Es evidente que de inmediato se nos ocurren un par ms de asociaciones. No significa que sean mejores o peores. Las expuestas son las que mejor se ajustan a los Servicios Tcnicos que ms en profundidad conozco, pero incluso para un mismo Servicio Tcnico nos puede suceder que, para una explotacin la asociacin 1 sea ms adecuada y sin embargo, en otra la asociacin 2 sea ms ptima.

291

Tambin propusimos colores: - Verde - Naranja - Rojo - Negro Las dos asociaciones mostradas podemos hacerlas en funcin de los colores, mucho ms grfica y vistosa, y algo muy importante la mayora de las veces, intuitivo. Si con cuatro colores no son suficientes, podemos aadir por ejemplo el amarillo, entre el verde y el naranja. - Verde - Amarillo - Naranja - Rojo - Negro Las asociaciones quedaran: Asociacin 1) Para el nivel aceptable, el color asociado ser siempre verde. Para el nivel asumible, asociaremos los colores amarillo y naranja. Para este caso, el naranja debe asociarse a una franja de rango muy pequeo en el umbral de inadecuado. Para el nivel inadecuado el color asociado es rojo. El color negro se asocia a cuando no haya oferta del servicio, es decir, cuando el Estado del Servicio es 0%. Asociacin 2) Para el nivel aceptable, asociaremos los colores verde y amarillo. Para este caso, el amarillo debe asociarse a una franja de rango muy pequeo en el umbral de asumible. Para el nivel asumible, asociaremos el color naranja. Para el nivel inadecuado el color asociado es rojo. El color negro se asocia a cuando no haya oferta del servicio, es decir, cuando el Estado del Servicio es 0%. Considero que puestos a escoger, es preferible usar las asociaciones por colores, ya que por el orden establecido, son un formato mundialmente asimilado y entendible, 292

y lo ms importante, interpretado de igual forma. Los nmeros llevan a confusin, pues en funcin de la escala, la interpretacin y el resultado varan. De hecho en este libro, hemos asociado para el Estado del Servicio el valor 5 como muy bueno, y para las prioridades 5, era tener una prioridad baja. Interpretacin que tiene que estar trasferida a quien deba trabajar con los valores. Con los colores no sucede lo mismo afortunadamente. La experiencia me ha demostrado que las cifras, aunque como en este caso, sean consecuencia de una asociacin, siempre se interpretan negativamente cuando no es la mejor de todos los posibles valores. Quin de pequeo cuando le daban un notable no buscaba rpidamente la cifra real que proporcionaba esa nota? Sin embargo, un notable era lo mismo para todos.

293

294

3 QU HACEMOS?
Y ahora qu hacemos? En el anterior mtodo, las coronas...
5 equipos Prioridad 2 0 equipos Prioridad 3 5 equipos Prioridad 4 0 equipos Prioridad 5 5 equipos Prioridad 6 PA = 4 S = 3

Proximidad Baja

Proximidad Media

Proximidad Alta

SAT

0 equipos Prioridad 2 0 equipos Prioridad 3 15 equipos Prioridad 4 PA = 4 S = 1

0 equipos Prioridad 2 5 equipos Prioridad 3 5 equipos Prioridad 4 5 equipos Prioridad 5 PA = 4 S = 2

...nos aportaban una ayuda inestimable, pues permitan agrupar a los equipos en funcin de la prioridad. Este hecho tan simple, simplifica (valga la redundancia) considerablemente los esfuerzos de planificacin. Sin embargo, ahora solo disponemos grficamente del Estado del Servicio (aceptable, asumible, inadecuado) y del resto de consideraciones e indicadores implementados, como soporte y ayuda en la gestin del mantenedor, o quien corresponda. Es obvio que no tiene ningn sentido, que continuamente alguien est comprobando cuando un Nivel de Agregacin de Servicio deja de ser aceptable. Lo ms coherente es establecer mecanismos en el Gestor de Servicios para que, cuando el Estado del Servicio de cualquier nivel deje de ser aceptable, se notifique esa variacin con la nueva situacin. Para hacerlo, tendremos que plantearlo desde la Gestin de Alarmas, mtodo integrado dentro del conjunto de polticas de gestin de la Gestin de Servicios Tcnicos, de la que hablaremos ms adelante. Cul es la idea fundamental de la Gestin de Alarmas? Proporcionar a quien lo necesite, mecanismos de control automatizados en funcin de los umbrales 295

establecidos, para detectar situaciones a corregir consecuencia de las variaciones del Estado de Servicio, o de cualquier otro indicador que hayamos definido e implementado en la herramienta, y est relacionado con el servicio ofertado. Obviamente nos centraremos en el indicador Nivel de Oferta, y la informacin que por medio de l seamos capaces de obtener, para definir la Gestin de Alarmas. Los mecanismos que vamos a usar como recursos de diseo para hacerlo, los hemos expuesto en el captulo anterior: Niveles de Servicio (Aceptable, asumible, inadecuado). Colores (verde, amarillo, naranja, rojo, negro).

Estn seleccionados en base a mi experiencia, pero no son dogma. El estudio previo de por ejemplo, el grado de precisin, el nivel de respuesta, etc., sern los aspectos que determinarn si son convenientes otras opciones a escoger. En primer lugar, el gestor al frente del departamento de mantenimiento, el gerente responsable de la explotacin del equipamiento, el encargado de la logstica, no tienen porque ser expertos en el Gestor de Servicios Tcnicos. Puede que nos interese inducir su forma de proceder, pero no convertirlos en una autoridad. Independientemente del grado de compromiso que se derive de la relacin con el Servicio Tcnico, nos conviene dar un paso ms. Si analizamos los resultados es fcil intuir, que en un mismo Nivel de Agregacin de Servicio, podemos encontrarnos que dos o ms de ellos coinciden en el mismo Nivel de Oferta, y cul prima?

296

Un ejemplo nos ayudar a ilustrarlo. Retomamos el Servicio Tcnico de cajeros:

Nombre (Nivel de Agregacin de Servicio Servicio Tcnico) Tcnico Cajeros ESPAA

Nivel de Agregacin

Situacin Estado Disponible

CAJEROS Global

Cajeros MADRID Cajeros Madrid Cajeros Mstoles Cajeros Legans Cajeros ANDALUCIA Cajeros Cdiz Cajeros Sevilla Cajeros Malaga Cajeros Crdoba

CAJEROS Comunidad CAJEROS Ciudad CAJEROS Ciudad CAJEROS Ciudad CAJEROS Comunidad CAJEROS CAJEROS CAJEROS CAJEROS Ciudad Ciudad Ciudad Ciudad

Estado Disponible Estado Disponible Fuera de Servicio Temporal Estado Disponible Estado Disponible Estado Disponible Estado Disponible Estado Disponible Estado Disponible Fuera de Servicio Temporal Fuera de Servicio Temporal Fuera de Servicio Temporal Estado Disponible Estado Disponible Estado Disponible Fuera de Servicio Temporal

Cajeros EXTREMADURA CAJEROS Comunidad Cajeros Cceres Cajeros Badajoz Cajeros CATALUA Cajeros Barcelona Cajeros Gerona Cajeros Lrida CAJEROS Ciudad CAJEROS Ciudad CAJEROS Comunidad CAJEROS Ciudad CAJEROS Ciudad CAJEROS Ciudad

Desglose Cajeros MADRID Cajeros ANDALUCIA Cajeros EXTREMADURA Cajeros CATALUA Cajeros Madrid Cajeros Mstoles Cajeros Legans Equipos Equipos Equipos Cajeros Cdiz Cajeros Sevilla Cajeros Malaga Cajeros Crdoba Equipos Equipos Equipos Equipos Cajeros Cceres Cajeros Badajoz Equipos Equipos Cajeros Barcelona Cajeros Gerona Cajeros Lrida Equipos Equipos Equipos

Tabla de Niveles de Agregacin del Servicio Y nos centraremos en el Nivel de Agregacin de Servicio de la Comunidad de Andaluca. Supongamos que el reparto de los Pesos Operativos es el siguiente: Cajeros CDIZ 35% Cajeros SEVILLA 20% Cajeros MLAGA 15% Cajeros CRDOBA 30%

297

Y los umbrales para cada uno de ellos basndonos en el modelo de Asociacin 1:

Nivel de Agregacin de Servicio Tcnico Aceptable Cajeros CDIZ Cajeros SEVILLA Cajeros MLAGA Cajeros CRDOBA > =90% > =80% > =80% > =90%

Asumible Inadecuado <40% <90% y >60% <=60% y >=40% <70% <80% y >75% <=75% y >=70% <70% <80% y >75% <=75% y >=70% <50% <90% y >70% <=70% y >=50%

Tabla de Umbrales El color negro solo se asociar cuando el Estado del Servicio sea 0%. Planteemos tres situaciones y cual sera el enfoque en cada uno de los casos: Situacin 1) Cada uno de los Niveles de Agregacin de Servicio tiene un color distinto.

Cajeros CDIZ Cajeros SEVILLA Cajeros MLAGA Cajeros CRDOBA

En este caso, al no haber coincidencia de colores, el orden establecido sera: 1. MLAGA 2. SEVILLA 3. CRDOBA 4. CDIZ Situacin 2) Dos Niveles de Agregacin de Servicio en naranja, otro en amarillo y otro en verde.

Cajeros CDIZ Cajeros SEVILLA Cajeros MLAGA Cajeros CRDOBA

En este caso sin embargo, dos tienen igual color. El Peso Operativo de cada uno de ellos influir para determinar la ordenacin resultante: 1. CDIZ 2. MLAGA 3. CRDOBA 4. SEVILLA

298

Situacin 3) Dos Niveles de Agregacin de Servicio en amarillo, otro en rojo y otro en naranja.

Cajeros CDIZ Cajeros SEVILLA Cajeros MLAGA Cajeros CRDOBA

Al igual que en la Situacin 2, hay dos con igual color. De la misma manera, el Peso Operativo ser determinante en la ordenacin: 1. SEVILLA 2. CADIZ 3. CRDOBA 4. MLAGA Se entiende que si est en verde, y no hay ningn cajero averiado, no formar parte de la ordenacin. Considerando solamente los Niveles de Servicio, los Colores y el Peso Operativo de cada Nivel de Agregacin de Servicio, es posible sugerir un orden de intervencin, que adolecer de defectos, pero que nos proporciona un punto de partida para gestionar las intervenciones, y que por supuesto, no se circunscriben exclusivamente a correctivos, es decir incidencias. Conocer las causas que provocan cada uno de los Niveles de Servicio y su Color asociado, mejorar todava ms las decisiones a tomar para planificar las intervenciones. La Gestin de Alarmas consiste bsicamente, en mostrar el orden de los Niveles de Agregacin, generando las notificaciones que se consideren necesarias, cada vez que se produzca un cambio de ordenacin respecto de la situacin actual. En principio slo cuando sea a peor, es decir, cuando aparezca en la ordenacin un determinado Nivel de Agregacin de Servicio, o adquiera mayor gravedad alguno de los existentes. Lo ms importante es el mtodo que apliquemos cuando se produzcan estas situaciones. Eso implica, tener establecido el tratamiento que emplearemos sobre la o las causas que lo producen y que en un porcentaje muy alto, ser consecuencia de las incidencias que sobre el equipamiento implicado en el Servicio Tcnico aparezcan. No obstante, la Gestin de Alarmas se aplicar consecuencia de: Superar los umbrales de servicio. Condiciones de explotacin excepcionales.

El tratamiento a realizar sobre las incidencias lo llamaremos Gestin de Incidencias. Es obligatorio aplicar la poltica de Gestin de Incidencias siempre que se produzca una incidencia? Obviamente no, slo cuando conlleve un Nivel de Servicio asumible, inadecuado o nulo. Mientras tanto, el modo de proceder lo 299

determinarn en gran medida, los mtodos de resolucin competencia de cada departamento implicado. Pero como la Gestin de Incidencias, al igual que otras Gestiones, ser tratada bajo la Gestin de Servicios no nos adelantemos, aunque es fcil intuir la ntima relacin que va haber entre la Gestin de Alarmas y la Gestin de Incidencias. An as, es suficiente? La respuesta es no, rotundamente, pero depender de cada organizacin y el contexto en el que nos encontremos, como ya hemos apuntado, los factores que determinarn qu otros aspectos debemos tener en cuenta y desarrollar, para mejorar este segundo mtodo propuesto. De partida nos conformamos.

300

4 COMPLICANDO LAS COSAS

En el captulo anterior hemos planteado la Gestin de Alarmas, considerando solo un Nivel de Agregacin de Servicio, pero esa circunstancia pocas veces la vamos a encontrar en la realidad. El mismo ejemplo que usbamos, posee tres Niveles de Agregacin de Servicio sin contar el de los equipos. Realmente dos, ya que el global, en este caso el referente al pas (Espaa), es nico. Qu sucedera si fuera necesario considerar los dos Niveles de Agregacin de Servicio? Nada mejor que un ejemplo, para que nos muestre grficamente la visin ms adecuada y como enfocarlo. Supongamos la siguiente situacin de un hipottico Servicio Tcnico y su nivel por colores manteniendo el criterio de Asociacin 1:
Nivel de Agregacin de Servicio 1 NAS 1.1 NAS 1.2 NAS 1.3 Nivel de Agregacin de Servicio 2 NAS2.1.1 NAS2.1.2 NAS2.1.3 NAS2.1.4 NAS2.2.1 NAS2.2.2 NAS2.2.3 NAS2.2.4 NAS2.2.5 NAS2.3.1 NAS2.3.2 NAS2.3.3

Tabla de Umbrales Por sorprendente que parezca puede suceder, que an teniendo Niveles de Agregacin jerrquicamente inferiores en situacin comprometida (por ejemplo NAS2.2.1 y NAS2.2.2) el padre no se vea afectado. Depender de cmo el nivel inferior influya en el nivel jerrquico superior, segn sea su Peso Operativo y los umbrales establecidos en este ltimo. Nos suena aquello de multiplicar por todos los Pesos Operativos de los diferentes niveles (captulo 2 de la quinta parte)? Personalmente no creo que debamos aplicar el mismo criterio. Estamos tratando de establecer un nuevo mtodo. Para este Servicio Tcnico lo primero que debemos plantearnos es, si uno de los dos Niveles de Agregacin de Servicio es prioritario. Una causa que lo justifica es haber establecido sobre uno de esos Niveles de Agregacin de Servicio, acuerdos de nivel de servicio (SLAs). De haberlos, no hay disyuntiva posible. Sobre el ejemplo, si los SLAs estn fijados sobre el NAS 1, los NAS dependientes de ste, tendrn prioridad sobre los dems, y dentro de ellos, segn color y Pesos Operativos como hemos visto en el captulo anterior. Si el reparto de Pesos Operativos fuera:
Nivel de Agregacin de Servicio 1 Nivel de Agregacin de Servicio 2

60% 15% 20% 40% 25% 10% 10%

25% 40% 25% 15% 30%

15% 50% 20%

Tabla de Distribucin de Pesos Operativos La Gestin de Alarmas implementada nos proporcionara la siguiente ordenacin: 301

- NAS1.1 NAS2.1.3 NAS2.1.4 NAS2.1.2 NAS2.1.1 - NAS1.3 NAS2.3.2 - NAS1.2 NAS2.2.1 NAS2.2.2 NAS2.2.4 NAS2.2.5 Pero no significa que hasta que no hayamos solucionado el NAS2.2.5, nuestro orden de intervencin sea el mostrado. Nos falta conocer un hecho esencial sobre el Nivel de Agregacin de Servicio 1, cundo incumplimos en cada uno de ellos? Por no complicarlo en exceso, establezcamos que slo incumplimos cuando se encuentren en color naranja, rojo o negro. Segn este criterio puede suceder que, recuperado NAS2.1.3 a verde, su padre (NAS 1.1) cambie de color. Si se mantuviera dentro de alguno de los colores del incumplimiento, el siguiente en atender sera NAS2.1.4 dado que ninguno de los restantes le superara en urgencia, pero en caso contrario, ninguno de los tres niveles restantes estara afectando al incumpliendo del SLA fijado, y podramos replanificar las intervenciones como considerramos ms oportunas. An as es bueno seguir contando con la Gestin de Alarmas, pues nos ofrece una ordenacin segn criticidad, lo que significa que, ante cualquier nueva incidencia, cuales de ellos son ms susceptibles de volver a incumplir el SLA establecido. La Gestin de Alarmas por lo tanto, no solo nos indica como proceder cuando hay incumplimientos, si no tambin cuando no los hay, situacin que muchas veces resulta ms compleja, que cuando estamos en niveles de criticidad. Cuando algo va muy mal todos tenemos claro que hacer, pero cuando ( y permtaseme la expresin) estamos en una especie de limbo, todo se complica. Siguiendo con el ejemplo, una vez atendido NAS2.1.3, la situacin resultante es la siguiente:
Nivel de Agregacin de Servicio 1 NAS 1.1 NAS 1.2 NAS 1.3 Nivel de Agregacin de Servicio 2 NAS2.1.1 NAS2.1.2 NAS2.1.3 NAS2.1.4 NAS2.2.1 NAS2.2.2 NAS2.2.3 NAS2.2.4 NAS2.2.5 NAS2.3.1 NAS2.3.2 NAS2.3.3

La ordenacin vara significativamente. Obtendramos: 302

- NAS1.3 NAS2.3.2 - NAS1.1 NAS2.1.4 NAS2.1.2 NAS2.1.1 - NAS1.2 NAS2.2.1 NAS2.2.2 NAS2.2.4 NAS2.2.5 Y la pregunta es de cajn , NAS1.1 antes que NAS1.2 qu tiene un Nivel de Agregacin de Servicio hijo en rojo? El dilema est planteado. A la Gestin de Alarmas le aadimos criterios que mejoran y dirigen, dependiendo del contexto, la forma de proceder. Segn sea el Servicio Tcnico y los implicados, puede ser ms adecuado mantener la ordenacin propuesta o, se altera dependiendo del color de los hijos. El vnculo asociativo entre ambos niveles es necesario, para implementar la Gestin de Alarmas que mejor se ajuste al Servicio Tcnico. Y si en lugar de haber establecido los SLAs sobre el Nivel de Agregacin de Servicio 1, se hubieran establecido sobre el 2? Usando el mismo ejemplo y con la misma premisa de incumplimiento (naranja, rojo o negro), la ordenacin da un vuelco significativo.
Nivel de Agregacin de Servicio 1 NAS 1.1 NAS 1.2 NAS 1.3 Nivel de Agregacin de Servicio 2 NAS2.1.1 NAS2.1.2 NAS2.1.3 NAS2.1.4 NAS2.2.1 NAS2.2.2 NAS2.2.3 NAS2.2.4 NAS2.2.5 NAS2.3.1 NAS2.3.2 NAS2.3.3

Nivel de Agregacin de Servicio 1 Nivel de Agregacin de Servicio 2

60% 15% 20% 40% 25% 10% 10%

25% 40% 25% 15% 30%

15% 50% 20%

Ordenacin Actual NAS2.2.1 NAS2.3.2 NAS2.1.3 NAS2.1.4 NAS2.1.2 NAS2.1.1

Ordenacin Anterior NAS2.1.3 NAS2.1.4 NAS2.1.2 NAS2.1.1 NAS2.3.2 NAS2.2.1 303

NAS2.2.2 NAS2.2.4 NAS2.2.5

NAS2.2.2 NAS2.2.4 NAS2.2.5

Pero los criterios que estamos usando son suficientes, o necesitamos elementos de valoracin adicionales. Pues (la respuesta de siempre) depende. Siete NAS incumplen el SLA establecido, da igual que por mucho o por poco. S parece lgico complementar con informacin, no para establecer una nueva ordenacin, sino para tener criterios sobre los que decidir. El Peso Operativo del padre se antoja como posible, pero quizs el ms evidente sea, cuantos equipos son los que estn provocando el incumplimiento. En funcin del nmero de equipos y que clusulas existan cuando haya incumplimientos, puede ser ms eficaz atender el Nivel de Agregacin de Servicio donde haya menos equipos influyendo, o al contrario. Y aqu entraran en valoracin, no slo los mismos aspectos que en la quinta parte establecimos para fundar las prioridades (Tiempo de Respuesta, Tiempo de Resolucin), sino adems, las necesidades y exigencias propias de cada departamento implicado en el Servicio Tcnico. Una clusula tpica es la de tiempo durante el cual puede darse un incumplimiento 2. En este caso no hay duda, aquel que incumpli primero... siempre que todos tengan la misma duracin, porque si no, la ordenacin estara en funcin de aqul que le quede menor tiempo de margen para incumplir. Y ya para finalizar (y volvernos locos), qu pasara si existieran SLAs en ambos Niveles de Agregacin de Servicio? Pues que tendramos una casustica similar a la de tener los SLAs sobre los Niveles de Agregacin de Servicio de nivel 1, pero que a la hora de la ordenacin puede dar un vuelco sustancial dependiendo de: - Si el incumplimiento se mantiene sobre el mismo criterio de colores no se vera alterado. - Por el contrario variar, dependiendo de que colores para cada Nivel de Agregacin de Servicio del 2 supone incumplimiento. No obstante no habra inicialmente mucha diferencia, si se establecieran exclusivamente los acuerdos de nivel de servicio sobre el Nivel de Agregacin de Servicio de nivel 1. Solo en el caso de ser distintos tiene lgica marcar SLAs en ambos niveles, si no, con fijarlos en el nivel jerrquico superior sera suficiente. A donde queremos llegar es, que la Gestin de Alarmas que implementemos, no tiene que ser siempre la misma sin tener en cuenta el contexto. Deber adaptarse como estamos constatando, a todos los requerimientos existentes sin dejar de cumplir la funcin de ayudar en la toma de decisiones. Pero siempre contemos con la aportacin de la Gestin de Alarmas. Un Servicio Tcnico no se entiende sin esta herramienta.
2

Impacto: Periodo de tiempo durante el cual un SLA no se cumple como consecuencia de cualquier tipo de incidencia

304

Y esto solo considerando un criterio, el que habamos establecido como mtodo de Asociacin 1 apoyado en una escala de cinco colores. Si reducimos los colores o partimos de otro tipo de asociacin diferente el resultado vara. Por ello, no debemos elegir un mtodo y darlo por bueno. Segn sean los medios con que contamos y la magnitud del Servicio Tcnico, hacer el ejercicio previo con ejemplos y situaciones ficticias, nos permitir determinar aqul que mejor cumpla su funcin. Y si usamos dos mtodos simultneamente? Y si cundo tenemos la ordenacin, es posible simular cambios situacin/resolucin para planificar las actuaciones del equipo de intervencin? de

305

306

5 MECANISMO DE CONTROL
Pues esa es la idea que nos quedbamos en el primer captulo y debemos trabajar en ella. La Gestin de Alarmas es un Mecanismo de Control para establecer una propuesta de intervencin, en funcin de una criticidad impuesta directamente por la oferta de servicio, o mejor dicho, por la falta de sta. Y adems con doble sentido, pues tambin este control debe ser fsico, es decir, que notifique cuando estamos fuera de lo que definamos como nivel aceptable y posibles cambios de ste, siempre para peor. Lo ms destacable de este mtodo es, su absoluta compatibilidad con el anteriormente propuesto. Pueden plantearse como una evolucin lgica, que segn van consolidndose y diseando nuevos Servicios Tcnicos, la aplicacin incorpora funcionalidades que favorecen, o mejor dicho, confluyen en una autntica Gestin de Servicios. Quizs es lo ms lgico; desarrollar la Gestin de Alarmas en primer lugar y posteriormente la Gestin de Prioridades.

307

308

6 RESUMEN
A modo de resumen, con la finalidad de organizar un poco todas las ideas que se han expuesto, para establecer un mtodo que nos permita planificar nuestras intervenciones, detallemos los aspectos que en la medida de lo posible puedan ser implementados. En primer lugar implementar el indicador Nivel de Oferta, estableciendo la ordenacin de colores que mejor se ajuste al Servicio Tcnico construido. En segundo lugar la Gestin de Alarmas. Nos proporciona una ordenacin en funcin del Nivel de Oferta existente. Cuando existan en un mismo Nivel de Agregacin, varios Niveles de Agregacin de Servicio, determinar aquellos que ms impactan en funcin de sus Pesos Operativos. Si en alguno de estos Niveles de Agregacin, se han establecido Acuerdos de Nivel de Servicio, aplicar la ordenacin en funcin de este Nivel de Agregacin. Si se han establecido los acuerdos en diferentes Niveles de Agregacin, priorizar por aqul de mayor nivel jerrquico. Considerar el volumen de equipos de cada Nivel de Agregacin de Servicio, a la hora de planificar las intervenciones, sobre todo, si existen SLAs definidos. En el caso de existir los SLAs, evaluar el Impacto en cada Nivel de Agregacin de Servicio, incluso si se han definido a nivel del equipamiento. Por ltimo, una herramienta que ayuda en esta toma de decisiones, es la posibilidad de simular los cambios de situacin de los Niveles de Agregacin de Servicio afectados en la lista generada por la Gestin de Alarmas, para conocer la evolucin de la misma segn vara la situacin de cada uno de estos Niveles.

309

310

SPTIMA PARTE GESTION DE SERVICIOS

311

312

NDICE SEPTIMA PARTE

1 2 3 4 5 6 DE LLENO AL OCANO ................................................................................. 315 ALGUNAS CONSIDERACIONES DE PARTIDA............................................. 317 INTERVENIR, ES MANTENER Y MUCHO MS... .......................................... 323 GESTIN DE INCIDENCIAS ........................................................................... 327 NIVELES DE SERVICIO .................................................................................. 331 CUNTOS MBITOS DE GESTIN NECESITAMOS? ............................... 335

313

314

1 DE LLENO AL OCANO
Despus de la lectura de las partes dedicadas a orientar el mantenimiento, una duda, o ms bien pregunta surge, y queda flotando pendiente de respuesta. Para el mantenedor le hemos proporcionado medios -metodologa incluida- que le aporta ordenadamente informacin para organizar las intervenciones. Tambin apuntbamos que estos mismos criterios son vlidos, para otros agentes que su actividad pueda verse reflejada en el servicio. El gran dilema a resolver es, como integrar a todos estos participantes, alinendolos de una manera eficaz y que garantice en todo momento la mejor oferta. Solo hay una respuesta que cubra prcticamente el cien por cien de la misma:

POR MEDIO DE LA GESTIN DE SERVICIOS

Para aquel lector que est familiarizado con los procesos de ITIL 1 (Information Technology Infrastructure Library) muy posiblemente no le sonar a desconocido este acuo. Pero para los profanos en las Tecnologas de la Informacin (TI), a buen seguro que lo que puedan imaginar no ser ni por aproximacin, parecido a la realidad que aportan estos procedimientos as definidos en el marco de la Gestin de Servicios. Existen grandes similitudes entre la Gestin de Servicios para TI y la Gestin de Servicios desde la perspectiva de Servicios Tcnicos. Pero tambin hay grandes diferencias, no solo de concepto, sino de implantacin. No en vano, el diseo para definir un servicio en TI y el diseo para definir Servicios Tcnicos, parten de criterios muy diferentes; pero tambin muchos objetivos y alcances, de uno y otro, lo son. Honestamente pienso, que los Servicios Tcnicos son un poco ms ambiciosos en sus pretensiones, simplemente porque parten de premisas de definicin ms exigentes y complejas, permitiendo plantear Acuerdos de Nivel de Servicio ms ajustados. En definitiva de eso se trata; de tener una herramienta que nos permita con el usuario o cliente, establecer un marco de acuerdos para que todo servicio prestado est dentro de unos valores de calidad aceptables. Como ejemplo sirva, que con el Servicio Tcnico se pretende alinear a todos los proveedores del mismo, porque se entiende de partida que puede existir ms de uno, y como decamos en captulos precedentes, el interlocutor responsable- puede ser nico, pero la responsabilidad es de todos. Incluso hemos llegado a comentar que, dependiendo del Servicio Tcnico, el usuario puede tener su cuota de culpa, de compromiso en el mismo. No obstante y para evitar comparaciones (que siempre son odiosas), nos centraremos en la Gestin de Servicios Tcnicos. An as, como profesional que en su momento fui de las Tecnologas de la Informacin, considero que la Gestin de
1

ITIL es un conjunto de procedimientos de gestin ideados para ayudar a las organizaciones a lograr calidad y eficiencia en las operaciones de TI y el servicio que proporcionan.

315

Servicios TI es una gran herramienta, y da respuesta a las necesidades que el mundo de las comunicaciones y la informtica tienen; herramienta que adems sigue los estndares de calidad de la ISO 9000. Los Servicios Tcnicos nacen y se desarrollan dentro del mundo industrial. Su Gestin tambin. Significa esto que difiere de la Gestin de Servicios de TI? Pues la respuesta nos la da el propio mbito competencial de cada uno. A un alto nivel, gestionar es eso, establecer los mtodos para conseguir un logro. Pero a ms bajo nivel, como conseguirlos estar en funcin del entorno en el que nos movamos. Lo que no me cabe ninguna duda, es que ambos buscan la satisfaccin del cliente, ofreciendo un producto de calidad y con calidad, y que la nica forma de medirlo es, o conociendo el servicio proporcionado, o cundo dejamos de prestarlo. Basndome en este razonamiento, equipos de comunicaciones, servidores,... pueden ser considerados equipamiento industrial y consecuentemente, desarrollar el Servicio Tcnico correspondiente. Recprocamente, un equipo industrial y cada vez ms, dado el avance tecnolgico de los mismos- puede verse desde el prisma de Servicio TI y aplicar todas las premisas que tal metodologa proporciona. Es en el resultado, o mejor dicho los resultados, donde reside la diferencia. La visin de servicio no es la misma dependiendo del mtodo aplicado. En esta ltima parte del libro no me gustara extenderme ms all de lo necesario, justificando la importancia de la Gestin de Servicios como complemento esencial de los Servicios Tcnicos. La Gestin de Servicios es el conjunto de modos de gestin que, integrados, permiten establecer un marco de entendimiento comn para todos los departamentos responsables en la prestacin del servicio. Destacaremos los ms significativos para la actividad de mantenimiento, pero sin que signifique que no puedan establecerse ms modos de gestin que los planteados. Por poner un ejemplo, la Gestin Econmica (lase Costes) no la trataremos. Sin embargo todos somos conscientes de que, hagamos lo que hagamos, tenemos que traducirlo a dinero.

316

2 ALGUNAS CONSIDERACIONES DE PARTIDA

Cuando estamos planteando la Gestin de Servicios me gustara centrarla en el contexto apropiado. Todos estaremos de acuerdo que solo por medio de una gestin eficaz, nuestro trabajo, actividades... hasta los momentos de ocio sern, productivos, eficientes y divertidos. Nuestro da a da, es una gestin inconsciente fruto de la experiencia y conocimiento, cuyo resultado autoevaluamos, ms o menos conscientemente, para mejorar. Pero cuando planteo Gestin de Servicios me refiero a establecer un conjunto de normas, cuya necesidad sea consecuencia de una situacin determinada. Me refiero al hecho de procedimentar y mecanizar los procesos implicados para hacer la gestin del servicio. Mi duda, LA DUDA sera:

Es necesario establecer todo en funcin de la Gestin de Servicios?

En los Servicios Tcnicos vs. Mantenimiento hemos mostrado como, condicionados por las necesidades del servicio, gestionbamos el mantenimiento. Visto desde la generalidad, una gestin correcta del mantenimiento redunda en el beneficio del servicio, en definitiva, hacemos gestin de los servicios. Pero, dnde los procesos, los procedimientos, la operativa,... del mantenimiento y del resto de actividades, deben estar integrados en la Gestin de Servicios? La experiencia me ha demostrado que un equilibrio entre normalizar y flexibilizar, proporciona la mejor respuesta a cualquier demanda. Por ello, lo ms importante para cada Servicio Tcnico, es determinar cundo es necesario dar una respuesta coordinada, en funcin del alcance y/o repercusin. Porque para hacer Gestin de Servicios, no va a estar todo en funcin de los indicadores que hayamos establecido para cada Servicio Tcnico. Las bajas, altas, modificaciones de equipos, en los equipos sus sntomas, mejoras tecnolgicas, etc., ser necesario regular como proporcionar esta informacin y cuando coordinar estos cambios, para en definitiva, garantizar la consistencia y fiabilidad informativa obtenida de cada Servicio Tcnico. Esta circunstancia entraa una dificultad muy importante en estos momentos. No va a ser posible llegar al detalle, porque cada Servicio Tcnico posee sus propios condicionantes. Sin embargo, s podemos proporcionar todos los aspectos necesarios que deben considerarse, para en el momento de establecer y definir la Gestin de Servicios, se aborden con garantas y no dejemos flecos ni detalles sin tratar... y con toda seguridad nos quedarn muchas parcelas por cubrir, pero gracias a la Mejora Continua daremos respuesta a los vacos que hayan podido quedar.

317

Para entenderlo mejor, imaginemos la notificacin de un evento sobre un equipo que participa en un Servicio Tcnico en explotacin. Las tres primeras consideraciones a tener en cuenta son: 1 - El evento notificado Causa una prdida de servicio en el equipo y niveles de agregacin superiores que incumpla algn acuerdo establecido? Nuestro cliente, o nuestros niveles de exigencia y/o cumplimiento se ven afectados? 2 - En caso afirmativo, Quin deber reestablecer el nivel perdido? 3 - En caso negativo, se aplicarn los procesos propios de cada departamento. Como dijimos en su momento, un Servicio Tcnico puede estar participado por diversos equipos, mantenidos por departamentos independientes que ni se conocen, explotados por terceros.... Sobre el mismo equipo, en funcin del tipo de incidencia, quin la resuelve es competencia de uno u otro departamento. Saber quin es el responsable y quines tienen responsabilidad, ayudar a establecer el nivel competencial de cada departamento. Dependiendo de si la respuesta es positiva o negativa, la resolucin del evento se hara, o desde el prisma de la Gestin de Servicios, o segn los procesos y mtodos implementados en cada departamento. Partiendo de las dos primeras consideraciones, ya no hablaramos de eventos, sino de incidencias y como consecuencia de Gestin de incidencias, pero, es adecuado? Es coherente tal planteamiento? Para hacer Gestin de Servicios debemos conocer las parcelas sobre las que vamos a soportar dicha gestin. Las incidencias y su resolucin, lo que hemos denominado Gestin de incidencias, es un mbito de competencia de lo que es la:

GESTIN DE LAS INTERVENCIONES

Sobre cualquier sistema, el perfil de las posibles acciones a realizar sobre ellos, vendr determinado por todas aquellas funcionalidades primarias y secundarias que identifiquemos. Eso significa que podr haber operativas tan diversas como: Sustitucin de elementos por desgaste. Sustitucin de elementos por rotura. Acondicionamientos operativos. Actualizaciones de software. Mejoras estructurales. 318

Intervenciones de logstica. Reposiciones de producto. .

Independientemente que desde la perspectiva de un departamento de mantenimiento aquellas de su competencia las cataloguen como preventivos, correctivos para el departamento de informtica es competencia de la administracin de sistemas, para el departamento de seguridad recaudacin y reposicin de moneda y billete, etc., lo que si es comn en todas, siempre que perjudiquemos tendremos que tener claramente definido s los procesos correspondientes. Hacer una gestin eficiente de la intervencin, para anular o minimizar el perjuicio. Y por qu he usado el verbo perjudicar? Hay algn dao cuando el servicio no es demandado? A priori parece que no. Ser el propio Servicio Tcnico y sus condiciones de diseo, el que determine si lo hay o no. Por ello, contextualizar TODA intervencin bajo la perspectiva de la Gestin de las Intervenciones, personalmente, considero que no es un acierto. No es productivo limitar y acotar la actividad de cada uno de los posibles agentes con responsabilidad en el Servicio Tcnico. La funcin del Servicio Tcnico es integrar las actividades, no condicionarlas. Cundo debemos integrar las actividades? Cundo hay que regirse por la Gestin de las Intervenciones? Es de Perogrullo si se me permite la expresin. Cuando cualquiera de los indicadores que construyamos en torno al servicio se vea afectado, de manera que, el valor que proporcione est fuera del rango aceptable. Cuando desarrollamos la metodologa que conjugaba la perspectiva del Servicio Tcnico y la visin del mantenedor nos hemos anticipado, porque eso es en definitiva hacer Gestin de las Intervenciones. Disponer de mtodos de organizacin y planificacin. Sabemos que en todo Servicio Tcnico, en funcin de sus caractersticas, tendremos que desarrollar un conjunto de procesos para dar cobertura y cumplir con la Gestin de las Intervenciones. Podremos tener: Gestin de intervenciones programadas. Gestin de actualizaciones. Gestin de intervenciones peridicas. . Gestin de Incidencias.

Hbilmente he ubicado la Gestin de Incidencias la ltima porque, independientemente del tipo, clase, perfil, finalidad. de los equipos, las incidencias, por su propia idiosincrasia, poseen caractersticas comunes. Mejor, pueden ser analizadas bajo los mismos criterios.

319

Para sustentar esta afirmacin necesito recurrir a captulos ya tratados. Decamos que una Incidencia es: Aqul suceso producido en los equipos, sistemas o instalaciones, que repercute en la prestacin de uno o varios Servicios Tcnicos Y esta definicin es vlida para el mantenedor, el distribuidor, la empresa de seguridad, el operador, Como ejemplo, para el mantenedor la incidencia se asocia siempre con el mantenimiento correctivo: El que se lleva a cabo con el fin de corregir (reparar) una falla en el equipo o instalacin, restaurando sus condiciones de origen Tambin dijimos, que es muy importante diferenciar lo que era incidencia tcnica de lo que no. Recordmoslo: 1) Si la incidencia provoca que el equipo tenga una Situacin Operativa diferente de En Servicio o funciona mermadamente (Incidencia Operativa), ser considerada como incidencia tcnica. 2) Si la incidencia por si sola no es motivo de alteracin de la Situacin Operativa o provocar una Incidencia Operativa, pero por la circunstancia que sea se comunica con la alteracin o la degradacin, ser considerada como incidencia tcnica. 3) Si la incidencia con el tiempo puede alterar la Situacin Operativa o provocar una Incidencia Operativa, no tendr la consideracin de incidencia tcnica, pero formar parte del conjunto de incidencias tcnicas. 4) Si la incidencia no puede alterar la Situacin Operativa o provocar una Incidencia Operativa, no tendr la consideracin de incidencia tcnica. La Gestin de las Intervenciones es posible que sea uno de los aspectos ms desarrollados y conocidos. Es raro encontrar departamentos que no tengan, aunque sea de modo verbal, procedimentadas las actividades. Y no solo departamentos, incluso un simple taller mecnico posee los libros gua de cada vehculo. Es cierto tambin que no siempre este conocimiento est actualizado, distribuido por la organizacin, pueden surgir informaciones contradictorias.... pero la realidad es que hasta cuando compramos lo ms simple nos incluye un manual de uso, en el que se incluye un pequeo apartado con los problemas ms comunes y como intervenir. Si esto lo trasladamos a equipos e instalaciones, muchas veces nos encontramos con exceso de informacin.

320

Todos los aspectos (y otros no detallados en la Gestin de las Intervenciones), desde la perspectiva de la Gestin de Servicios, tienen su implicacin y relevancia por el posible impacto en los indicadores, y que mtodos de actuacin ms eficaces establecer para minimizar las degradaciones y/o anulaciones en la oferta de servicio. Cualquier actividad programada, peridica, de actualizacin.... tiene un denominador comn: es conocida. Esta concurrencia permite desarrollar estrategias orientadas a perturbar lo mnimo posible el servicio prestado. Pero no pasa lo mismo con la mayora de las incidencias tcnicas. Ante la notificacin de un problema, que incide en los Niveles de Servicio negativamente, en funcin de los acuerdos establecidos, as deberan ser las acciones previstas.

321

322

3 INTERVENIR, ES MANTENER Y MUCHO MS...

Nos habamos quedado en el captulo anterior en un momento clave de la Gestin de las Intervenciones. Durante el presente libro, hemos hablado en diversos captulos de las incidencias. A estas alturas todos hemos establecido, inconsciente o conscientemente, una fuerte vinculacin entre los servicios y las incidencias, ya que stas ltimas son las causantes de que un servicio se vea mermado descontroladamente, es decir, no podemos predecir a priori desde el punto de vista tcnico, cuando un imprevisto, en el ms amplio concepto de la palabra, va a incidir en nuestro servicio y en qu proporcin. Vamos a explicarnos con un poco ms de detalle y como casi todo el mundo tiene coche, mejor ejemplo imposible. Muchos de los vehculos que circulan por el mundo disponen de cadena de distribucin. Sin entrar en detalles de qu es y para qu sirve, supongamos que el fabricante de una determinada marca nos recomienda que para el modelo de nuestra propiedad, hay que sustituir dicho elemento cada noventa mil kilmetros. El por qu de realizar esta intervencin transcurrido ese kilometraje, se supone que est basado en las pruebas de duracin del material y conjunto de piezas que lo conforman, manteniendo lgicamente mrgenes de seguridad a la baja, es decir, si hemos circulado digamos con naturalidad, seguramente podramos arriesgarnos a realizar la sustitucin con algunos kilmetros ms. Pero el motivo de hacerlo, segn indicacin del fabricante, es para garantizar que dicha pieza no se va a romper, provocndonos una avera mayor y muy costosa. Desde este punto de vista, la intervencin que realizamos se puede considerar peridica, ya que est en funcin de un indicador controlable como son los kilmetros. Si en lugar de ser un vehculo, fuera un autobs que presta servicio en una lnea de transporte de pasajeros, para evitar mermar la oferta de servicio, la intervencin deberamos programarla en un momento que no estuviera circulando. Si el autobs circulara las veinticuatro horas del da, deberamos hacerlo en hora valle, donde es posible que no sea necesario mantener toda la flota circulando y, en caso contrario, o tenemos autobs de repuesto, o no nos quedara ms remedio que asumir la merma de servicio. Por lo menos buscaramos hora y da de la semana donde el impacto de la intervencin fuera menor. Por cierto, quedmonos con la palabra IMPACTO, porque ms adelante va a ser un vocablo determinante en nuestra Gestin de Incidencias. Para un mantenedor, pero tambin para un departamento de logstica, explotacin.... disponer de indicadores que: adviertan de cuando puede producirse un fallo, se est agotando un producto.... en definitiva, adelantarse a que se produzca un suceso concreto, permite que nos anticipemos planificando la intervencin correspondiente. Pero volviendo al ejemplo del coche, otras veces no nos queda ms remedio que, en el mejor de los casos, llevar nuestro coche al taller, y no hace falta que sea una avera tremenda. El simple hecho de que no llevemos espejos retrovisores no impide que circulemos; pero, adems de la posible multa si nos detiene la autoridad, estamos poniendo en riesgo nuestra integridad, la de nuestros acompaantes y la del resto de vehculos, consecuencia de no disponer de la informacin visual necesaria que nos permita circular con seguridad. 323

Admitiendo que es difcil que en el mismo instante nos quedemos sin ninguno de los espejos retrovisores, nos encontramos ante una incidencia de carcter tcnico. Debemos con la mayor brevedad posible restituir los retrovisores. Restituir. Esto suena a correctivo y este tipo de intervencin es IMPOSIBLE de prevenir. Todava recuerdo a mi hijo pequeo con seis aos diciendo: - Pap! Yo desmonto el GPS ... desde el asiento de atrs y sin tiempo de reaccin, fue el fin del soporte del GPS y del espejo retrovisor interior. Partiendo de esta simptica ancdota (del espejo retrovisor hubo repuesto, del soporte del GPS no, pero lo hizo con su mejor voluntad y eso siempre se perdona), una intervencin de correctivo la causa un suceso imprevisto. Conozco quin se ha quedado sin gasolina, y sin embargo el chivato de la reserva no se haba encendido. Con este ejemplo pretendo trasladar al lector que, incluso disponiendo de artilugios comnmente indicadores-, no solo nos encontraremos con incidencias en elementos que no podemos controlar, sino tambin en los que controlan por nosotros. La causa es evidente, deberamos vigilar a quin vigila realizando intervenciones de preventivo, pero el coste de realizar este mantenimiento es muchsimo mayor -por regla general-, que la probabilidad de fallo de este tipo de elementos. Todo este prembulo me permite encauzar la Gestin de las Incidencias, como la gestin de mayor notoriedad dentro de la Gestin de Intervenciones. Es, bajo desde mi experiencia profesional, el aspecto menos desarrollado en los departamentos de mantenimiento, aunque no la equiparemos a nivel de gestin. El cmo proceder ante imprevistos adolece generalmente del mismo defecto, no se liga el imprevisto al impacto. Pero esto no es una relacin unvoca exclusivamente. La mayora de las veces, la conjuncin de varios imprevistos generan un mayor impacto que cada uno de ellos individualmente. ste es el mayor problema de cualquier departamento, independientemente de la ndole de las intervenciones. Disponer de una herramienta que le vincule los impactos a las incidencias facilitara las planificaciones, pero sobre todo minimizara, no solo las mermas en los indicadores, sino en muchos servicios los perjuicios ocasionados. Que decir si son diferentes los departamentos que en un mismo equipo o instalacin pueden intervenir. La visin de los Servicios Tcnicos es proporcionar esta vinculacin. Al disponer de una herramienta que en tiempo real permite disponer de este conocimiento, implcitamente permite desarrollar metodolgicamente una Gestin de Incidencias eficaz e integrada, si por la idiosincrasia as fuera. El primer paso es definir (ahora s) una palabra que ha aparecido reiteradamente, impacto. El periodo de tiempo durante el cual un (Acuerdo de) Nivel de Servicio no se cumple, como consecuencia de cualquier tipo de incidencia. Establecer los Impactos (en los acuerdos), permite conocer el grado de repercusin criticidad- de las incidencias 324

Al cuantificar y detallar los impactos, podremos establecer prioridades en funcin de cada uno, y en funcin de cada prioridad, disponer de un elemento de anlisis para planificar las intervenciones ms eficaces, considerando adems, los recursos humanos y materiales necesarios y disponibles. Desde el punto de vista del mantenimiento, todo el prrafo anterior significa implantar la Gestin del Mantenimiento, y que en las dos partes anteriores es bsicamente lo que hemos hecho. Lo contrario, ser desde el punto de vista semntico mantener, pero el caos la condicin que dominar nuestro esfuerzo. La primera conclusin es obvia, no seremos competitivos. Organizar el mantenimiento es implantar la Gestin del Mantenimiento en el ms amplio sentido de la palabra mantenimiento2. Coordinar las diferentes tipologas de intervencin posibles se realizar por medio de la Gestin de las Intervenciones, y dentro de sta por la dificultad que entraa, la Gestin de Incidencias tendr una importancia mayor respecto del resto de posibles intervenciones. Por simplificar, podemos establecer la siguiente sinopsis: Gestin de las Intervenciones: - Gestin Programada, en sus diferentes y variadas versiones. - Gestin de Incidencias. En el segunda parte usamos un diagrama que tiene mucha relacin con la sinopsis planteada:

GESTION DE SERVICIOS

GESTION DE LAS INTERVENCIONES

GESTIN DE INCIDENCIAS GESTIN PROGRAMADA

GESTION DE MANTENIMIENTO
2

Mantenimiento -Segn la Real Academia de la Lengua en su segunda acepcin- Conjunto de operaciones y cuidados necesarios para que instalaciones, edificios, industrias, etc., puedan seguir funcionando adecuadamente.

325

pero sustituyendo en el cuadro central la Gestin de Incidencias por la sinopsis planteada. Es mucho ms completa y aclara posibles dudas que en su momento pudieran plantearse. No obstante, centrmonos en la Gestin de Incidencias por su complejidad. El esfuerzo de procedimentar las intervenciones programadas tiene ms de mtodo que de creatividad.

326

4 GESTIN DE INCIDENCIAS
Como ya hemos recordado unos prrafos antes sabemos que es una incidencia. Consecuentemente, la Gestin de Incidencias es: El conjunto de procesos cuya finalidad es el control y seguimiento de las incidencias, y en los casos que aplique, restaurar con la mayor brevedad posible el nivel de servicio, minimizando la repercusin en el cliente En la definicin puede chocar que, adems controlar la incidencia, exista cierta responsabilidad con respecto de los niveles de servicio. Lo cierto es que al definir los impactos, establecemos la vinculacin entre las incidencias y el servicio a travs de los niveles de servicio. Sin embargo debe quedar claro que no es responsabilidad intrnseca de la Gestin de Incidencias velar por el cumplimiento de los mismos, pero s supervisarlos, y en cierto modo garantizarlos. La entidad que debe velar por su salvaguarda es lgicamente la Gestin de Niveles de Servicio. Ms adelante abordaremos esta nueva identidad. En toda incidencia es fcil identificar las siguientes etapas por las que evoluciona. Quiero aclarar antes de detallarlas, que cada organizacin puede establecer otras distintas o equipararlas parcialmente. Con un pequeo estudio llegaramos a la conclusin de que las similitudes seran ms que las diferencias y estaramos hablando seguramente de matices; a veces nada ms que de semntica. Pero el debate siempre es productivo. En mi organizacin, con aos y aos de experiencia en el mantenimiento, creemos que para organizaciones complejas como la nuestra, nos permite hacer un seguimiento exhaustivo y completo. Adems, la literatura que se pueda consultar va orientada en la misma lnea. La vida de una incidencia posee el siguiente ciclo:
Comienzo- Momento en el que se produce la incidencia. Deteccin- Ser conscientes de la existencia de la incidencia. Diagnstico- Determinar las causas de la incidencia. Tcnicas,

Operativas...
Adjudicacin- Departamentos implicados en la resolucin. En Proceso- Tiempo durante el cual los departamentos implicados

resuelven la incidencia.
Restauracin- Recuperacin de la situacin inicial de servicio. Pendiente de Cierre- Comprobar que se restablecen los valores de

servicio pactados/ofertados.
Cierre- Cuando el cliente nos da la conformidad.

327

En la etapa de Restauracin, definirla como: La Recuperacin de la situacin inicial de servicio, incluir la palabra servicio no es trivial. El vocablo que realmente se usa es funcionamiento, pero al sustituirlo por servicio , se pretende vincular al departamento correspondiente y a su personal, que su labor no solo sirve para que lo intervenido vuelva a andar, sino que adems de funcionar, est prestando un servicio. El grado de implicacin suele ser mayor pues al final de la cadena est el cliente; alguien como nosotros. De las etapas planteadas, las crticas son las dos primeras y merecen ser analizadas con ms detalle. No son precisamente las que las organizaciones tienen mejor controladas. La primera reflexin en formato pregunta: La incidencia comienza en el mismo momento que el problema? Segunda reflexin: Siempre somos conscientes de cuando un equipo tiene un problema? Es invierno. 7am. Hace fro. Abrimos la puerta del coche, nos sentamos, buscamos torpemente el cinturn de seguridad, introducimos la llave, giramos y ..... no arranca. La batera est KO. La incidencia comienza a las 7 de la maana, pero nos hemos quedado sin carga en la batera mientras dormamos. Ni la incidencia ha comenzado cuando surgi el problema, ni hemos sido conscientes. Regresamos de las vacaciones y al entrar en la cocina, est todo el suelo mojado y la comida del frigorfico, incluido el congelador, podrida. En qu da de los 15 que estuvimos de vacaciones se rompi el compresor? Ni la incidencia ha comenzado cuando surgi el problema, ni hemos sido conscientes. Con estos dos ejemplos cotidianos documento la realidad de la problemtica asociada con las incidencias. Por ser un suceso imprevisto, dependemos de la intervencin de alguien -generalmente el cliente- para ser conscientes de la incidencia, momento en el cual da comienzo. Ambas etapas se dan a la vez en el tiempo. Generalmente es as y podramos haberlas expresado como una sola etapa, pero gracias al desarrollo tecnolgico fundamentalmente, podemos desglosarlas en dos tal y como est expuesto. Todas aquellas personas que dotan a su vivienda de alarmas conectadas con empresas de seguridad, de alguna manera estn mecanizando el conocimiento de la incidencia. Si se produce una intrusin, automticamente se dispara la alarma y se registra un aviso en dicha empresa. Claramente el comienzo de la incidencia coincide con el momento de la existencia del problema. Se cumple la etapa primera, Comienzo. La Deteccin ya es menos evidente, porque sino hay nadie que se entere de la intrusin.... La Deteccin existe desde el instante que se reconoce el problema. Este momento debera ser muy importante en toda organizacin, pues las dos siguientes etapas (Diagnstico y Adjudicacin) estn en funcin del mismo, sobre todo a la hora de exigir responsabilidades.

328

Por qu este ejemplo? Porque gracias a la tecnologa, muchas instalaciones pueden informar de sus problemas, pero algo mejor todava, pueden anticiparse al problema, y este hecho se convierte, no en un proceso de la Gestin Programada, pero casi. Aprovecharemos los procedimientos establecidos en la Gestin Programada para integrarlos con las variantes lgicas -pues no dejan de ser incidencias-, para anticiparnos al problema. Lo trataremos como una incidencia ms, pero con la ventaja de la anticipacin; qu repuesto hay que llevar, materiales, herramientas, personal necesario..... Pero los equipos no suelen ser entidades unitarias. Al revs, suelen formar parte de algo de lo que trata este libro, servicio. Las agrupaciones que hemos integrado en el momento de disear el Servicio Tcnico, nos permite, aprovechar la informacin automatizada de cada equipo, para realizar un tratamiento optimizado facilitando las intervenciones. Esta primera capa de adquisicin de la Gestin de Incidencias la denominaremos Gestin de Alarmas, y la definimos como: El conjunto de mecanismos de control incluidos en la Gestin de Incidencias que se activan, o cuando un Nivel de Servicio se incumple, o como medida de anticipacin ante un posible incumplimiento Este conjunto lo conformarn mecanismos de supervisin, seguimiento y control, tanto en los equipos, como en los indicadores de cada uno de los servicios implementados, para conocer cuando caen por debajo de un determinado nivel de prestacin. Como se puede apreciar, la Gestin de Alarmas es relativamente sencilla de llevar a cabo, pero de una importancia vital, pues ser el primer cortafuego ante situaciones adversas. De su correcta implementacin, basada principalmente en: La potencia informativa de los equipos La integracin de las aplicaciones industriales Un centro de supervisin y control

...conseguiremos minimizar los perjuicios ocasionados por la perdida de servicio en las instalaciones. La Gestin de Alarmas no debe quedar exclusivamente en el mbito de conocer o prever la incidencias de los equipos, situacin que nos facilitarn las herramientas industriales afines al equipamiento, sino que aprovechando la propia herramienta de Servicios Tcnicos, implementar mecanismos de alertas con dos alcances significativos: 1. Explotacin habitual del Servicio Tcnico. 2. Explotacin condicionada. Pueden existir circunstancias puntuales que condicionen la prestacin de un servicio. Un 329

partido de ftbol o la celebracin de una feria, ante el incremento de afluencia de gente, la exigencia de los niveles de servicio pueden ser mayores que en condiciones normales. Para estos casos nos ayudar muchsimo contar con un herramienta que nos avise de las anomalas en la explotacin. La idea de disponer de un centro de supervisin y control implica que, la Gestin de Incidencias, adems del seguimiento de las incidencias, debe abarcar dos aspectos esenciales: 1. Supervisar y Garantizar los Niveles de Servicio . 2. La funcin del Help Desk como centro de atencin. La primera ya ha sido comentada al principio y con la Gestin de Alarmas se hace ms evidente todava. La segunda tiene un alcance prctico, donde muchos de los aspectos hasta ahora tratados haban quedado desubicados. Definir la funcin del Help Desk como centro de atencin supone: 1. Centralizacin y registro de las incidencias . Lgicamente, desde que hemos comenzado hablando de la Gestin de Servicios, hemos visto que las incidencias sobre los equipos causaban la mayora de las veces prdidas de servicio. Una adecuada Gestin de Incidencias debe contar con una aplicacin que permita el registro y seguimiento de cualquier incidencia. Adems, para poder a posteriori evaluar el tratamiento efectuado, la aplicacin debe disponer de un mdulo de mtricas que proporcione informacin relevante sobre las acciones realizadas. 2. Resolucin de las incidencias. Ya sea desde la aplicacin de registro o desde las herramientas industriales, toda posible intervencin realizada desde el Help Desk cuenta con una ventaja, la pronta atencin, y por experiencia puedo decir, que en un porcentaje aproximado del 70%, la mayora de las veces son intervenciones de muy bajo nivel y fcil resolucin, lo que implica que no tenga que ser personal cualificado quin las realice. 3. Primer nivel de atencin e informacin al cliente . Por ser el departamento que centraliza los eventos y gestiona la informacin, nadie mejor para ser tambin un Centro de Informacin, con una doble orientacin, al cliente y al proveedor. Puede ser el Help Desk el propio departamento de Mantenimiento? Por supuesto que s. Qu lo impedira? El tamao de la organizacin, fundamentalmente por el volumen de equipos, instalaciones y la diversidad de intervenciones. En el momento de abordar la Gestin de las Intervenciones sabremos como enfocar los distintos aspectos de gestin interrelacionados. Lo que s sabemos, es que tendremos que abordarla, y casi seguro la Gestin de Mantenimiento. 330

5 NIVELES DE SERVICIO
Durante los captulos anteriores hemos introducido otro concepto: Niveles de Servicio. Cuando definimos la Gestin de Incidencias, un aspecto de la misma era supervisar y garantizar los niveles de servicio, pero nunca su responsabilidad. Quien debe velar por el cumplimiento de los mismos es la Gestin de Niveles de Servicio. Qu sera un Nivel de Servicio? Como en principio no existe ningn acuerdo o compromiso con un tercero, sera: La declaracin de intenciones realizada por el proveedor del servici o El cliente es pasivo aunque sea el destinatario final. Si el cliente interviene estaramos hablando de Acuerdos de Nivel de Servicio: Declaracin de intenciones entre el proveedor del servicio y el cliente Estemos discutiendo de niveles, o niveles por acuerdos, solo existe una manera de enfocarlos, por medio de la Gestin de Niveles de Servicio3.

Acuerdos de Nivel de Servicio

Gestin de Niveles de Servicio

GESTIN DE SERVICIOS (Clientes)

Gestin de Incidencias

GESTIN DE SERVICIOS (Help Desk)

Gestin de Alarmas

GESTIN DE SERVICIOS (Diseo e implantacin) INFRAESTRUCTURA (mantenimiento)

Servicio TV

Servicio ME

Equipamiento

Servicio TV- Servicio Transporte Vertical; Servicio ME- Servicio Mquinas Expendedoras

331

La imagen aporta fundamentalmente la visin estratgica donde ubicar, desde el punto de vista organizativo, la Gestin de Niveles de Servicio. Es el ms alto nivel de gestin. Se ha simplificado la representacin grfica, abordando nicamente para la Gestin de Servicios el nivel aplicativo, es decir, estaramos hablado del modelo conceptual de los Servicios Tcnicos, el departamento de Help Desk como la entidad clave en la Gestin de Incidencias, y el nivel de relacin con los clientes. La Gestin de Niveles de Servicio es: El proceso responsable de garantizar que se satisfagan los Acuerdos de Nivel de Servicio y dems niveles de servicio. Evala el impacto de los cambios, tanto cuando se proponen, como despus de ser implementados. Supervisa la afeccin en la disponibilidad del servicio, demandando la resolucin de las incidencias dentro de los periodos acordados Como se aprecia en la definicin, adems de las competencias sobre el cumplimiento de los niveles de servicio, supervisa y controla un aspecto que no se haba contemplado hasta el momento; cmo los cambios afectan a los servicios. Hasta ahora, solo plantebamos la afeccin del servicio a posteriori. Se produce un evento y se trata. Sin embargo en la Gestin de las Intervenciones aglutinbamos otras gestiones a realizar como la Gestin Programada. Somos conscientes de la necesidad de realizar una intervencin conocida y por medio de la Gestin de Niveles, evaluar el impacto de la misma en el servicio y acomodarla al momento de menor afeccin. Pero con cambios hacemos referencia a, nuevas funcionalidades de los equipos, distintas formas de operacin, diferente mantenibilidad.... sustituir, modificar o mejorar implica variacin en el comportamiento y no siempre a mejor. Evaluar cmo los cambios pueden afectar y cmo afectan una vez constituidos, es tarea clave en la Gestin de Servicios. Esta actividad no debera tomarse a la ligera, y sin embargo, sucede todo lo contrario. La mayora de las organizaciones, no estn sensibilizadas con la importancia de abordar los procesos de cambio de forma controlada para minimizar los daos. Toda operacin que signifique prdida total o parcial de servicio debe ser evaluada, pero adems, cmo los cambios realizados pueden afectar a la oferta de servicio. Conviene diferenciar que las tareas propias de mantenimiento no estn sujetas a este proceso. Si as fuera, la Gestin de Servicios estara enfocada bajo otra perspectiva. Los cambios deben entenderse como acciones con un antes y un despus. Por ejemplo: la sustitucin de la flota de vehculos, y un vehculo nuevo significa, pasar por un periodo de garanta para reparar averas, defectos y/o deficiencias. Saber la probabilidad de fallo y tiempos de parada de este periodo, ayudar a planificar el cambio. En todo cambio debe existir como mnimo:

Registro del cambio Valoracin de las ventajas y riesgos 332

Coordinacin para la implantacin Seguimiento Cierre de la peticin

Este proceso de control del cambio, puede estar integrado en la Gestin de Niveles, o establecer una Gestin de Cambios con identidad propia. Personalmente soy partidario de esta ltima opcin, ya que podremos y debemos- implantar un arma muy valiosa para todo cambio, conocida como Mesa de Cambios4. Esta herramienta no es ms ni menos que un grupo de expertos relacionados con la figura del cambio, para debatir sobre los aspectos del mismo. Al proceder de este modo garantizamos que, aunque exista el responsable de autorizar el cambio, ste vendr determinado por el consenso de todos aquellos que tienen algo que aportar al proceso. Dependiendo de la naturaleza del cambio, as estar constituida la Mesa de Cambios. Independientemente de cmo enfoquemos los procesos de cambio, desde un punto de vista ejecutivo, la Gestin de Niveles de Servicio... ... lo forman los procesos de planificacin, diseo, negociacin, monitorizacin e informe de cada (Acuerdo de) Nivel de Servicio, para mantener y mejorar gradualmente la calidad en el servicio, principalmente por su repercusin en los costes Cumplir los niveles de servicio no es tarea exclusiva de la Gestin de Niveles de Servicio. Es obligacin -como hemos reiterado continuamente- de todo aqul que participe en el servicio garantizarlos. Para cumplir los niveles de servicio, es necesario realizar una Gestin de Servicios eficiente. Cmo lograrlo? Implantando la Cultura de Servicio como filosofa empresarial: La satisfaccin del cliente ser la prioridad principal para todos los componentes de la organizacin -haya o no acuerdos establecidos-, de manera que, toda actividad realizada para proveerlo debe contribuir, parcial o totalmente, a los objetivos propios del cliente, o en su defecto, a lo esperado del servicio (Ciclo de la Calidad)5 La Cultura de Servicio solo es posible entenderla como un COMPROMISO. Todo proveedor de servicios debe asumir como mnimo que: 1. Organizar los recursos para garantizar la prestacin del servicio. 2. Desarrollar e implantar los procedimientos y procesos necesarios, que mejoren y garanticen el cumplimiento de los Niveles de Servicio. Gestin de Niveles.
4 5

Tambin se le conoce como Comit de Cambios Ver esquema del Ciclo de la Calidad en el captulo 15 de la segunda parte

333

3. Establecer por medio de la Gestin de Incidencias, los procedimientos adecuados para la resolucin de aquellas circunstancias que mermen la oferta del servicio y puedan ser causa de incumplimiento. Al final vemos que toda actividad podemos resumirla en un nico aspecto. Si procedemos velando por el servicio estamos satisfaciendo al cliente, nuestro cliente Hay algo ms importante?

334

6 CUNTOS MBITOS DE GESTIN NECESITAMOS?

Las cosas bien hechas bien parecen. La respuesta satisface la pregunta de este captulo. Por lgica se deberan abordar tantos niveles de gestin como fueran necesarios... y nos hemos quedado tan anchos Cuntos son necesarios? Si usamos como referencia la Gestin de Servicios para TI, veremos que nos aparecen entidades como: Gestin de la Capacidad Gestin de la Configuracin Gestin de Release (Lanzamientos / Versiones) Gestin de la Disponibilidad Gestin de Problemas

Y dado que estamos implantando la Gestin de Servicios en entornos industriales, los tres primeros estn enfocados a aspectos ntimamente relacionados con el mundo de la informtica y las comunicaciones. El siguiente se enmarca dentro de la Gestin de Niveles de Servicio. Sobre la Gestin de Problemas, para qu estructurarla si tenemos una entidad con peso suficiente como la Gestin de Intervenciones y la Gestin de Cambios... No obstante, hay otras gestiones que s debemos considerar aunque no estn aglutinadas bajo la Gestin de Servicios. Sirva de ejemplo: La Gestin Financiera-Econmica La Gestin de la Seguridad La Gestin de Proyectos

Cada una de las gestiones expuestas posee suficiente entidad, como para tener su propio desarrollo y afortunadamente, se dispone de suficientes publicaciones en las libreras especializadas que nos van a permitir abordarlas con garanta de xito. Lo que no vamos a encontrar es el aspecto de ligar cada una de las gestiones con la Gestin de Servicios. La clave est en plantear la Gestin de Servicios como una actividad ms dentro de la empresa, actividad compleja y que se desgrana en muchsimas subactividades, pero que debemos considerarla un todo. De esta manera tendremos el interfaz adecuado para establecer los niveles de relacin pertinentes, que aporten la informacin complementaria a cada uno de ellos. Mi consejo es que de abordarlo, no partamos con un planteamiento predefinido. Analicemos el contexto y las oportunidades que se nos ofrecen dependiendo de nuestro modelo y necesidades de la empresa. As nacieron los Servicios Tcnicos, representando un salto cualitativo en la gestin del mantenimiento y la atencin al cliente.

335

Lo ms importante es implementar la Gestin de Servicios. Su explotacin nos va a plantear muchas interrogantes. Segn la acomodemos, la empresa nos demandar ligarla con el resto de actividades.

336

EPILOGO

337

338

EPILOGO
Empezamos hablando de la historia del mantenimiento, continuamos hablando de cmo gestionar el mantenimiento, en medio los Servicios Tcnicos y como es lgico, acabamos gestionndolos. Soy consciente de que quedan muchos interrogantes por contestar, mucho por desentramar y mucho por hacer. Esto es solo el comienzo. El propio lector puede extraer todo aquello que le ayude a mejorar y enriquecer su trabajo. El mundo del mantenimiento es apasionante y sin embargo, cunto ha evolucionado realmente? Que ha cambiado durante el transcurso de los ltimos 40 aos nadie lo duda, pero, en la misma medida que la sociedad? La demanda de servicio actual no tiene parangn. Existen asociaciones cuyo empeo es modernizar el enfoque del mantenedor y su actividad, alejndola del clsico operario sin formacin, ofreciendo la visin de un tcnico cualificado. Sirva referenciar a la AEM1 las actividades que desarrolla, el grado de especializacin y conocimiento de sus profesionales, y las empresas colaboradoras. Espero que la lectura del libro haya sido tan fascinante para el lector, como para mi escribirlo. Realmente han sido unos aos intensos, con algunos periodos de reflexin, de los que me siento muy satisfecho. El libro naci como un reto personal, sin mayores pretensiones. Algo as como el que se plantea correr una maratn, establece un mtodo de preparacin y da a da lo pone en prctica.

Asociacin Espaola de Mantenimiento

339

340

ANEXO INDICADORES

341

342

ANEXO INDICADORES
En la exposicin de los Servicios Tcnicos hemos definido los dos Indicadores principales y es obvio que podemos disear cuantos necesitemos. Pero antes de inundar nuestro sistema con decenas de indicadores, es conveniente reflexionar sobre la necesidad y objetivo de cada indicador, detallando sus alcances. Aunque podemos encontrar sobradamente libros dedicados en exclusividad al concepto de indicador, incluso normas como la UNE 66175, que dentro de los sistemas de gestin de la calidad nos proporcionan una gua para la implantacin de sistemas de indicadores, en este anexo, slo vamos a dar al lector unas cuantas interrogantes e indicaciones que permitan una reflexin, sobre la importancia de definir correctamente todo indicador.

Para qu son necesarios los Indicadores?

- Para interpretar lo que est ocurriendo. - Para adoptar las medidas correctoras oportunas, cuando las variables se salen de los lmites establecidos. - Para definir la necesidad de introducir cambios o mejoras, evaluando sus consecuencias. - Para establecer nuevas metas que permitan orientar las mejoras establecidas, dependiendo de las necesidades del cliente.

Qu necesitamos saber para definir los Indicadores?

- Qu objetivos existen? - Qu procesos estn definidos? - Quines son los responsables? - Qu debemos medir? - Dnde es conveniente medir? - Cundo hay que medir y con qu frecuencia?
343

- Quin debe medir? - Cmo se van a difundir los resultados? - Quin audita el sistema de obtencin de resultados y con qu periodicidad?
Las respuestas a estas preguntas son muy importantes, porque proporcionan los criterios (atributos) mnimos esenciales para disear cualquier indicador: 1) Nombre. El nombre del Indicador debe informar (ser auto explicativo). 2) Medible. No solo a la hora de plantear su formulacin, sino a la hora de obtener los datos para su clculo. 3) Meta (Alcanzable). Una meta inalcanzable lo primero que generar es desmotivacin. 4) Propsito. Debe ser claro. En nuestro caso como primer requisito, mejorar el servicio. 5) Objetivo. Para qu se define el Indicador; no slo el propsito, sino contribuir a objetivos estratgicos definidos en las corporaciones. 6) Responsables. Debe estar claramente definido y existir desde quien lo calcula hasta quien lo gestiona. 7) Caducidad. La validez del Indicador en el tiempo depender del Propsito y Objetivo a cumplir. 8) Frecuencia. Cada cunto tiempo debe calcularse o proporcionarse. 9) Formato. Como se va a mostrar el resultado obtenido. 10) Comparacin. Hay referencias en otras organizaciones del mismo Indicador? Tcnicas de Benchmarking1 Es factible definir algunos atributos adicionales como: clasificacin, representacin grfica, distribucin, dependencias,... Contar con el mayor nmero de Atributos con identidad para definir el Indicador mejorar, no slo su comprensin, sino tambin su implementacin.

Actualmente en el contexto empresarial se interpreta como: Un proceso continuo para medir productos y servicios de una empresa entre posibles compaas competencia lderes o en su defecto, que puedan servir de referencia, pues aunque no operen dentro del mismo mbito geogrfico, si que tienen la misma finalidad. Las empresas de transporte de viajeros o mercancas son un claro ejemplo.

344

Una herramienta que puede ayudar, tanto a desarrollar el indicador, como si ya est construido y en explotacin, y que adems justifica la validez del mismo, son las encuestas. De hecho toda organizacin debera peridicamente realizar encuestas que le permitan valorar la eficacia de sus Indicadores, independientemente del tipo y finalidad que cumplen. La encuesta no debe ser compleja y lo ms importante, que est sometida a un proceso de mejora continua...

A CT U A R P LA N IF ICA R

EV A LU A R

H A CER

...para dotar al evaluador de criterios que permitan medir la validez del Indicador. El resultado de la encuesta formar parte de la mejora continua del indicador, o del Sistema de Indicadores. Analicemos las preguntas de la siguiente encuesta:

1.-Cumple el objetivo para el que fue propuesto?

2.-Es fcil de obtener? 3.-Ha finalizado su periodo de validez? 4.-En caso afirmativo Es necesario prorrogarlo? En caso afirmativo justificarlo: 5.-Ayuda a la toma de decisiones? Detallar las decisiones adoptadas: 5.-Es entendible al usuario? 6.-Est sujeto a interpretaciones? En caso afirmativo justificarlo:

SI SI SI SI SI SI SI

NO NO NO NO NO NO NO

345

7.-Hay circunstancias aleatorias que desvirtan el indicador? En caso afirmativo detallarlas:

SI

NO NO

8.-El resultado obtenido est dentro de las SI expectativas iniciales? En caso negativo justificarlo:

Con muy pocas preguntas podemos obtener una gran cantidad de informacin. Nos permitirn evaluar la necesidad de disear o de continuidad de cualquier Indicador justificndolo. Las encuestas deben tener preguntas sencillas, orientadas a dar respuesta a los Atributos que han argumentado la necesidad de implementar el indicador. No obstante, como premisa fundamental vlida para toda organizacin:

Si un indicador no sirve para tomar decisiones debe ser eliminado

El alcance de las decisiones que se tomen, ser objeto de estudio por parte de quienes tengan responsabilidad y competencia sobre el indicador. Es importante clasificar al indicador. Por clasificacin entendemos, satisfacer diversos criterios segn el punto de vista. Estos criterios bsicamente sern los mismos que los Atributos usados en la definicin del indicador, principalmente: 1) Que mide (Objetivo): Econmico, Tcnico, Calidad, Satisfaccin,... 2) Decisiones: Estratgicas, Operativas,... 3) Propsito: Controlar, Mejorar, Gestionar, Organizar,... Pero tambin podemos clasificarlos dependiendo de si son o forman parte de: I.) KPI (Indicador Clave de la Actividad2). Los indicadores as catalogados, deben ayudar a definir y medir el progreso hacia las metas definidas, reflejando los factores crticos para el xito. Por tal motivo, lo primero es establecer las metas que vendrn determinadas por la estrategia adoptada. Estrategias como: la satisfaccin del cliente, el avance tecnolgico, la reduccin de costes,... determinarn cules de los Indicadores deben ser KPIs. Es incompatible la satisfaccin del usuario con el avance tecnolgico, pues en toda innovacin, mejora, sustitucin,... durante un tiempo, consecuencia de la mortalidad infantil y estabilizacin del sistema, el servicio ofertado empeora por la indisponibilidad de estos equipos. Un buen Sistema de Indicadores, y principalmente KPIs, vendr determinado por la estrategia corporativa y/o departamental. Pueden existir otras consideraciones para tratarlos desde la perspectiva de un KPI como, costes econmicos o carga de trabajo. Una vez definidos y dada la importancia de estos indicadores, deben ser
2

La traduccin e interpretacin vara segn el autor.

346

conocidos por todo el personal implicado para convertirse en punto de referencia clave del desempeo de su trabajo. II.) SLA (Acuerdo de Nivel de Servicio) . Formarn el conjunto de indicadores pactados, tanto con nuestro cliente, como aquellos que se puedan dar en otros mbitos de la empresa. Deben aportar valor significativo al cliente interno y externo. Para saber cules son los ms apropiados, es necesario conocer los aspectos ms crticos para nuestro cliente. Por esta circunstancia, deben acordarse conociendo dichas necesidades. III.) Sistemas de Indicadores. Varios son los sistemas reconocidos mundialmente para el diseo del Sistema de Indicadores en una organizacin, pero se basan principalmente en(3): i. CMI (Cuadro de Mando Integral, Kaplan y Norton). Sistema de gestin integrado de objetivos e indicadores. ii. Policy Deployment (Kanri). Sistema de gestin basado en el ciclo de mejora de la calidad. No todos los indicadores deben llegar al grado de exigencia que se est mostrando. Muchos de los indicadores cotidianos cumplen una funcin menos elevada , pero trascendental en la mayora de las organizaciones; fundamentales para la toma de decisiones, el control de las actividades y garantizar la correcta aplicacin de los procesos. Formarn un subconjunto reducido de uso particular en aquellas personas con responsabilidad directa sobre los equipos, repuestos y mano de obra. En el mundo del mantenimiento su enfoque es principalmente Tcnico (MTBF, Tiempo de Resolucin, Averas Pendientes,...) y de Costes (Mano de obra, Repuestos,...) Todo Indicador debera tener una ficha que describa los principales aspectos del mismo. Si la organizacin tiene pensado certificarse o est certificada segn las normas ISO, no slo el formato, sino adems si el contenido es relevante de cara a dicha certificacin. Dentro de este cumplimiento y aunando los atributos de definicin, a modo de ejemplo y como mnimo deberan contemplar los siguientes alcances: 1. Objeto. Se definen los objetivos del por qu del Indicador (p.e. es un KPI para control de...). Se describe su tipo (catalogacin si existe en la organizacin). 2. Alcance. Se define el mbito de aplicacin (equipos, sistemas, Servicios,...). 3. Referencias. Documentos que se mencionen en cualquiera de los apartados particulares de la empresa o general como, normativas, reglamentacin,...

Aconsejamos al lector la consulta de ambos sistemas, tanto en sus autores, como en los muchos libros que analizan ambos mtodos.

347

4. Responsabilidades. Se detallan cada uno de los participantes (para el clculo, introduccin de los datos, definicin, gestin,...) y las competencias. 5. Generalidades. Aspectos generales. Por ejemplo, si el indicador son siglas el significado de las mismas,... 6. Desarrollo. 6.1. Definicin del Indicador. Se define el principal objetivo del Indicador. Por ejemplo, del indicador Estado del Servicio Prestado sera: conocer en un momento puntual el Servicio ofertado al cliente ... 6.2. Mtodo utilizado para el clculo. Se define de dnde se obtienen los datos, la frmula, el significado de cada uno de los factores de la frmula,... 6.3. Periodicidad en la toma de datos. Cada cuanto tiempo se obtiene el indicador y a quin se le proporciona. 6.4. Tiempo de vida. Caducidad del indicador. 7. Codificacin. Un cdigo que permita tener registrados todos los indicadores en una Base de Datos controlada. 8. Registros. Se especifica el responsable, el documento (informes peridicos, propuestas de mejora,...) a realizar y el periodo de archivo de dicho documento. 9. Anexos. Toda aquella informacin til que aplica al indicador, incluidos los documentos mencionados en la Referencia. 10. Formatos. Los formatos que como consecuencia del indicador sea necesario crear (difusin, informes,...) Esta breve recomendacin sobre indicadores y su implantacin no estara completa, si no hiciramos mencin a la necesidad de elaborar un diagrama que represente el Proceso, es decir, las tareas a realizar en torno al indicador. El diagrama ms bsico debe contener: a) Las Actividades b) Los Implicados c) La Documentacin producida

348

Un ejemplo prctico sera:

ACTIVIDADES Informacin: - Departamentos - Cliente IMPLICADOS REGISTROS

Ratios

Indicadores de aos anteriores

Propuesta de Indicador -Tipo -Frmula -Unidad Organizativa Implicada

RESPONSABLES

Definicin y aprobacin del indicador mbito de aplicacin Metas y Objetivos Aprobacin por parte de la Unidad Organizativa implicada

RESPONSABLES CLIENTE

Indicador aprobado? Si

No

Elaboracin del documento de descripcin del indicador y codificacin del mismo

RESPONSABLES

Documento del indicador

Difusin del indicador

RESPONSABLES

Anlisis y seguimiento del indicador

RESPONSABLES

Informes

Aprueba test?? No Anlisis

Si Registro RESPONSABLES

RESPONSABLES

Se puede realizar mejora?

No

Descarte

RESPONSABLES

Si Proponer mejora RESPONSABLES

Realizar la mejora

RESPONSABLES

Informe de mejoras

No

Es necesario redefinir el indicador? Si

RESPONSABLES CLIENTE

El diagrama mostrado no es ms que un ejemplo a seguir. Ser responsabilidad de cada organizacin desarrollar el proceso asociado a cada indicador, pues no todos los indicadores deben ajustarse a un proceso genrico. Depender de los objetivos y propsitos del mismo. 349

350

SERVICIOS TECNICOS GLOSARIO DE TERMINOS

351

352

GLOSARIO
Servicio Tcnico: Conjunto de actividades relacionadas entre si, soportadas por equipos e instalaciones, que satisfacen una necesidad o mejoran las funcionalidades prestadas. Cliente: El destinatario de nuestros trabajos y servicios. Equipo Monitorizado: Equipo supervisado remotamente, proporcionando en tiempo real toda la informacin necesaria para el Servicio Tcnico. Equipo no monitorizado: Equipo que no tiene ningn tipo de supervisin y por lo tanto, solo se conoce su Situacin Operativa posteriormente a cualquier Incidencia que se produzca sobre l. Equipo Clave: Equipo por medio del cual identificamos la prestacin o lo que es lo mismo la percepcin del Servicio Tcnico. Equipo Implicado: Todo aquel que es necesario para la prestacin del servicio, de manera que cualquier Incidencia que surja en dicho equipamiento, puede afectar al Estado del Servicio. Equipo Indirecto: Cualquier equipo que no es necesario para la prestacin del servicio, pero que bajo determinadas circunstancias retrasan o dificultan la reposicin o puesta en marcha. Peso Operativo: Porcentaje de participacin de cada uno de los elementos de Nivel de Agregacin de Servicio inferior. Factor de Ponderacin: Los diferentes aspectos de referencia que sirven para establecer los Pesos Operativos. Peso Tcnico: Porcentaje asignado a cada Incidencia Operativa. Regla acumulativa: Aquella situacin en la que la prdida de servicio de dos o ms Incidencias Operativas, es superior a la suma de las mismas. Regla de Exclusin: Aquella situacin en la que dos o ms Incidencias Operativas, no pueden darse simultneamente. Incidencia Clave: ver Incidencia Operativa. Incidencia Operativa: Aquellas disfunciones producidas en los equipos o sistemas, que sin llegar a anular la oferta del servicio, se presta con las funcionalidades definidas para su explotacin mermadas, incumpliendo prerrogativas o requisitos mnimos de prestacin, en aquellos casos en los que pueda establecerse un margen de operatividad posible. Estado del Servicio: El nivel de servicio que se est prestando y/o percibiendo, considerando todas aquellas circunstancias que lo anulen o degraden el servicio, incluso, aquellas que no permiten determinar si se presta o no dicho servicio. 353

Disponibilidad del Servicio: El Estado del Servicio durante un periodo de tiempo. Nivel de Servicio Ofertado: El indicador proporcionado consecuencia de aplicar una Tabla de Conversin. Tabla de Conversin: Sistema por medio del cual, convertimos el Estado del Servicio en una escala, representada por colores, nmeros... Calidad de Servicio Ofertado: Calidad del Estado del Servicio Prestado. Horario: Franja de tiempo en la que los equipos prestan servicio. Prestacin de Servicio: Valor porcentual (0% 100%) consecuencia de si el equipo funciona o no. Factor de Degradacin por Causas Propias: El sumatorio de las degradaciones de un equipo expresado en valor porcentual. Factor de Incertidumbre: La probabilidad de que un equipo est prestando servicio. Situacin Operativa: Aquellos modos en los que un equipo puede estar, tanto cuando funciona como cuando no funciona y que permiten complementar la informacin del Servicio Tcnico. Los posible Estados en los que un equipo puede estar. Estado: Una Situacin Operativa concreta. Nivel de Agregacin: La estructura jerrquica, sobre la cual se van a crear y detallar posteriormente, los Niveles de Agregacin del Servicio. Nivel de Agregacin de Servicio: Los niveles (Servicios) en los que se desglosa cada Servicio Tcnico. Incidencia Tcnica: Aquel suceso producido en los equipos, sistemas o instalaciones mantenidas, que repercute en la prestacin del servicio. Matriz de Cambio de Estados: Tabla por medio de la cual se controla la situacin operativa del equipo clave. Matriz de Equipamiento Relacionado: Tabla por medio de la cual, dependiendo de la situacin del equipo relacionado, se controla la situacin operativa del equipo clave. Impacto: Asociacin realizada en las matrices de equipamiento relacionado, para controlar las situaciones en las que los equipos implicados provocan una incidencia operativa en el equipo clave. RCM: Mantenimiento Basado en la Fiabilidad. Proceso que determina el mantenimiento requerido en cada equipo, sistema o instalacin dentro de su contexto operacional y asegurando que siga realizando las funciones para las que fue diseado y construido. 354

Flujograma (Diagrama de Flujo): Representacin esquemtica de un proceso y las relaciones entre sus componentes. Taxonoma: Ver Tipo de Objeto. Tipo de Objeto: Las diferentes clasificaciones de los equipos, que poseen caractersticas similares. Por ejemplo, los surtidores de gasolina. Para un Servicio Tcnico, los diferentes tipos de equipo que conforman Catlogo: Sistema de clasificacin que diferencia dentro de un mismo Tipo de Objeto, marcas y/o modelos existentes. Agrupacin de caractersticas. Conjunto de datos iguales. Grado: Forma de valoracin de los equipos que permite automatizar el clculo de los Pesos Operativos. Equipo CRTICO: Aqul equipo clave sobre el que se establecen procesos de atencin y resolucin especiales. Equipo URGENTE: Es un subconjunto de los equipos crticos. Tiempo Medio de Desplazamiento: Al promedio de los tiempos en recorrer la distancia desde el Centro S.A.T. (Servicio de Asistencia Tcnica) al equipo y volver. Tiempo Medio de Resolucin: Al promedio de los tiempos dedicados en solucionar las incidencias. GMAO: Gestin de Mantenimiento Asistido por Ordenador. Consola de Gestin: Sistema que recoge en un repositorio nico, la informacin generada en el equipamiento y desde el cual es posible supervisar y controlar.

355

356

BIBLIOGRAFIA

357

358

BIBLIOGRAFIA
AUDITORA DEL MANTENIMIENTO E INDICADORES DE GESTIN, D. Francisco Javier Gonzlez Fernndez. Fundacin Confemetal Editorial. TEORA Y PRCTICA DEL MANTENIMIENTO INDUSTRIAL AVANZADO 2 EDICIN, D. Francisco Javier Gonzlez Fernndez. Fundacin Confemetal Editorial. GESTION DEL MANTENIMIENTO, D. Jos Mara de Bona. Fundacin Confemetal Editorial. SISTEMA DE INDICADORES PARA LA MEJORA Y EL CONTROL INTEGRADO DE LA CALIDAD DE LOS PROCESOS, D. Jos Antonio Heredia lvaro. Universitat Jaume I. TECNICAS DE MANTENIMIENTO AVANZADO, Javier Borda. Deusto. GESTION POR PROCESOS, D. Jos A. Prez Fernndez de Velasco. ESIC. COMO HACER EL MANUAL DE CALIDAD SEGN LA NUEVA ISO 9001:2000, D. Fermn Gmez Fraile, D. Miguel Tejero Monzn y D. Jos F. Vilar Barrio. Fundacin Confemetal Editorial. CUADRO DE MANDO INTEGRAL, d. Robert S. Kaplan y D. David P. Norton. Gestin 2000. GESTIN ECONOMICA DEL MANTENIMIENTO (Cuadernos de Mantenimiento), D. Francisco J. Gonzlez Fernndez. Asociacin Espaola de Mantenimiento (AEM). CURSO ACUERDOS DE NIVEL DE SERVICIO, D. Eduardo Nez Lobato. IIR. CURSO ACUERDOS DE NIVEL DE SERVICIO, D. Francisco Garca Ahumada. IIR. EL MANTENIMIENTO EN ESPAA, Asociacin Espaola de Mantenimiento (AEM). MANTENIMIENTO BASADO EN LA FIABILIDAD (MBF), Soluciona Consultora.

359