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

11

SEGUNDA PARTE: COMENZANDO

31

TERCERA PARTE: MEJORANDO EL COMIENZO

127

CUARTA PARTE: FASE DE CONSTRUCCIN

173

QUINTA PARTE: HACIA EL MANTENIMIENTO

223

SEXTA PARTE: ORGANIZANDO LAS INTERVENCIONES

283

SPTIMA PARTE: GESTIN DE SERVICIOS

311

EPLOGO

337

ANEXO INDICADORES

341

GLOSARIO DE TRMINOS

351

BIBLIOGRAFA

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

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

1990
2000

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

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 para
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 quien
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

DEFINICION DE SERVICIO .............................................................................. 35

POR QUE DEFINIR SERVICIOS TECNICOS? ............................................... 39

2.1 Necesidades del Cliente ................................................................................ 41
2.2 Cliente Directo................................................................................................ 43

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

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

LOS SERVICIOS TECNICOS EN LA ORGANIZACION ................................... 63

10 INCIDENCIAS .................................................................................................... 69
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

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.

Repercusin en un tercero, generalmente el cliente directo al que

se le presta dicha actividad.

II.

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.

Integrar distintas actividades relacionadas.

IV.

Desarrollar una Poltica de Costes de actividades relacionadas.

V.

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.

Soporte
Redes

Seguridad
(Recargas)

Cajero

Red de
Comunicaciones

Mantenimiento
Electromecnico

Compaa
Telefnica A

X-25
Servidor
Sucursal

Operadores

Compaa
Telefnica B

Servidor
Central
Banco A

Frame-Relay

CPD

BBDD
Banco B

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 identificaremos 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 presta, 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 de 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:

INDICADORES INCIDENCIAS (KPIs)

METRICAS DE SERVICIOS (SLAs)

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

SERVICIO A

INCIDENCIA 3

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

SERVICIO A
SERVICIO B

INCIDENCIA 3

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

SERVICIO A
SERVICIO B

INCIDENCIA 3

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 que
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?

NO

EN SERVICIO

SI
Parada por
Incidencia SI
Tcnica del
Servicio
NO
Parada
Manual

Avera?
NO
Equipo
Telemandado?

SI
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:

Desconocido

ESTADO INICIAL

Desconocido

Parada Manual
Parada
Incidencia en el
Servicio

Parada Manual
Parada
Incidencia en el
Servicio

Parada sin
Telemando

Parada sin
Telemando

En Servicio

Desconocido

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

En Servicio

En Servicio

En Servicio

En Servicio

En Servicio

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

ESTADO INICIAL

NUEVO ESTADO EQUIPO RELACIONADO

Parada Manual

Parada Incidencia
en el Servicio

Parada sin
Telemando

Parada Manual

Parada Incidencia en
el Servicio

Parada sin
Telemando

Parada Manual

Parada Incidencia en
el Servicio

Parada sin
Telemando

Parada sin
Telemando

Parada Incidencia en
el Servicio

Desconocido

En Servicio

Parada Manual

Parada Incidencia en
el Servicio

Parada sin
Telemando

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

ESTADO INICIAL

Parada Manual

Parada Incidencia
en el Servicio

Parada sin
Telemando

En Servicio/
Incidencia
Operativa

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

Lnea A
Sector 1
Subestacin Elctrica
Disyuntor de Reserva

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 dependiendo 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 sentido 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 definimos 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 n

ST Cajeros Pas 1

...
ST Cajeros
Comunidad n

ST Cajeros
Comunidad 1

ST Cajeros
Comunidad 1

ST Cajeros
Comunidad n

...

...

ST Cajeros
Ciudad n

ST Cajeros
Ciudad 1

ST Cajeros
Ciudad 1

...

Cajero 1

Cajero n
...

ST Cajeros
Ciudad n
...

Cajero 1

Cajero 1
...

Cajero n
...

ST Cajeros
Ciudad 1

...

...

Cajero 1

Cajero 1
...

Cajero 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 %

N2.1

N2.2

N2.3

N1.1

50

N1.2

25

N1.3

25

N1.1

60

N1.2

40

N1.1

15

N1.2

25

N1.3

60

40

20

40

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

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 estacin 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

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 %

N2.1

N2.2

N2.3

N1.1

50

N1.2

25

N1.3

25

N1.1

100

N1.2

N1.1

15

N1.2

25

N1.3

60

40

20

40

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 %

N2.1

N2.2

N2.3

40

20

N1.1

50

N1.2

25

N1.3

25

N1.1

100

N1.1

15

N1.2

25

N1.3

60

40

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
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

Da 1

00:00-06:00 Expendedora 2

Da 2

Expendedora 2
06:00-12:00 Expendedora 3
Expendedora 4
Expendedora 1
Expendedora 2
12:00-24:00 Expendedora 3
Expendedora 4

100

100

75
50
75

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

100

75
100
75

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

Da 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

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 Manual

Parada Manual

Parada
Incidencia
Tcnica del
Servicio
Parada
Incidencia
Tcnica del
Servicio

Parada Incidencia Parada Incidencia

Tcnica del Servicio 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

En Servicio

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

No admite
monedas (1)

No admite
billetes (2)

Precio exacto
(3)

Parada Manual
Parada
Incidencia
Tcnica del
Servicio

Parada Manual
Parada
Incidencia
Tcnica del
Servicio

Parada Manual
Parada
Incidencia
Tcnica del
Servicio

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. Posteriormente 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 causaaccin 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
Media

98
96
%
94
92
90

T1

T2

T3

T4

T5

T6

T7

T8

T9

Estado del Servicio

95,4

96,7

92,3

90,9

98,1

94,3

100

97,2

92,4

98

Media

95,53

95,53

95,53

95,53

95,53

95,53

95,53

95,53

95,53

95,53

T10

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
Media

98
96
%
94
92
90

T1

T2

T3

T4

T5

T6

T7

T8

T9

Estado del Servicio

92,3

92,3

92,3

92,3

92,3

92,3

92,3

92,3

92,3

98

Media

92,87

92,87

92,87

92,87

92,87

92,87

92,87

92,87

92,87

92,87

T10

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:

DS =

% Estado
Servicio

Hora inicio

Hora fin

Tiempo
(Hf-Hi)

100%

06:00

10:00

4:00 = 240m

90%

10:00

16:00

6:00 = 360m

50%

16:00

17:00

1:00 = 600m

60%

17:00

19:00

2:00 = 120m

25%

19:00

24:00

5:00 = 300m

(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

proveedor

cliente
Calidad
Percibida

Calidad
Producida

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...)

Derivadas de los Equipos Implicados (incidencias, actuaciones

programadas...)

Equipo

Clave

(incidencias,

actuaciones

- 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 clculo 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

Cables de Feeder (+)

Hilo de Trabajo

Infraestructura
Comunicaciones

Telemando de
SS.EE.
o
Conexin
Remota

Carril
Cables de Feeder (-)

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:

-Generalidades
-Definicin
-Alcance

Identificacin del
Equipamiento
Relacionado

Incidencias
Operativas
(Reglas de
clculo)

Diagramas de
apoyo

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

Definicin de
Indicadores

Tablas de
Simulacin

Asignacin de
Responsabilidades

Situacin Operativa

Identificacin de las
Funcionalidades

Identificacin del
Equipamiento
Implicado

Identificacin de los
Equipos Clave

Metodologas de
apoyo (MBF,...)

-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

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

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

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

Da 1

06:00-20:00

20:00-24:00
00:00-06:00
06:00-12:00
Da 2
12:00-24: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

100

70
50
70

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

100

80
100
80

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:

Da 1

Supuesto a
Estado del
Servicio
En Servicio
Expendedora 1
06:00-24:00
100
Expendedora 2
00:60-14:00

Expendedora 1
Expendedora 2

100

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

50
100

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%

De 00:00 a 06:00 horas

Ubicacin 1 = 100%

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

Da 1

06:00-20:00

Expendedora 1
Expendedora 2

20:00-24:00 Expendedora 1
Expendedora 2

100

100

00:00-06:00

Expendedora 2

06:00-12:00 Expendedora 1
Expendedora 2

100

12:00-14:00

100

Da 2

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 1
Expendedora 2

50

14:00-20:00
Expendedora 2
20:00-24:00 Expendedora 1
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

100

100

100

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

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

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

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

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:

Equipo 1, PO=36,31%

Equipo 2, PO=30%

Equipo 3, PO=9,5%

Equipo 4, PO=50%

Equipo 5, PO=1,68%

Y la distribucin:

Equipo 1, PO=25%

Equipo 2, PO=25%

Equipo 3, PO=6%

Equipo 4, PO=38%

Equipo 5, PO=6%
144

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.

Supuesto 3)

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

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

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

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
Informes

Web

Centro de
Atencin

Registro
Incidencias de
Logstica

Gestor de
Servicios
Tcnicos

Registro
Incidencias de
Explotacin

Otros
Registros
Estados
Alarmas

GMAO

Incidencias

Gestor de
Mantenimiento

BB.DD
Equipos

Mantenimiento
(Incidencias
Tcnicas)

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:
1-

Reducir 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.

2-

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

191

detectar, cmo el preventivo influye positiva o negativamente en el

correctivo.
3-

Reducir 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,...

4-

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.

5-

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.

6-

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.

7-

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.

8-

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

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

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.

Madrid: Estado Disponible

ii.

Mstoles: Fuera de Servicio Temporal (Se est

definiendo)

iii.

Legans: Estado Disponible

b. ANDALUCA: Estado Disponible

c.

i.

Cdiz: Estado Disponible

ii.

Sevilla: Estado Disponible

iii.

Mlaga: Fuera de Servicio Temporal (Suspendido

temporalmente)

iv.

Crdoba: Fuera de Servicio Permanente

EXTREMADURA: Fuera de Servicio Temporal (Se est

definiendo)
i.

Cceres: Fuera de Servicio Temporal (Se est definiendo)

ii.

Badajoz: Fuera de Servicio Temporal (Se est definiendo)

198

d. CATALUA: Estado Disponible

i.

Barcelona: Estado Disponible

ii.

Gerona: Estado Disponible

iii.

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

Nivel de
Agregacin Situacin

Cajeros ESPAA

CAJEROS Global

Estado Disponible

Cajeros MADRID

CAJEROS Comunidad

Estado Disponible

Cajeros Madrid
Cajeros Mstoles
Cajeros Legans

CAJEROS Ciudad
CAJEROS Ciudad
CAJEROS Ciudad

Estado Disponible
Fuera de Servicio Temporal
Estado Disponible

Cajeros ANDALUCIA

CAJEROS Comunidad

Estado Disponible

Cajeros Cdiz
Cajeros Sevilla
Cajeros Malaga
Cajeros Crdoba

CAJEROS
CAJEROS
CAJEROS
CAJEROS

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

Ciudad
Ciudad
Ciudad
Ciudad

Cajeros EXTREMADURA CAJEROS Comunidad

Fuera de Servicio Temporal

Cajeros Cceres
Cajeros Badajoz

CAJEROS Ciudad
CAJEROS Ciudad

Fuera de Servicio Temporal

Fuera de Servicio Temporal

Cajeros CATALUA

CAJEROS Comunidad

Estado Disponible

Cajeros Barcelona
Cajeros Gerona
Cajeros Lrida

CAJEROS Ciudad
CAJEROS Ciudad
CAJEROS Ciudad

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

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

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

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

Estado

Incidencia Operativa

ALARMA-63 METTA5 SIN COMUNICACIN

EN SERVICIO

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

Estado

131

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

Alarma
o
Incidencia

Servicio
Tcnico

Equipos
Clave

Relaciones
Alarmas
I. Operativas

Matriz
Equipos
Clave

Situacin
Operativa

Nivel de
Agregacin
de Servicio

Estado del
Servicio

Equipos
Implicados

Relaciones
de equipos

Matriz
Equipos
Clave
Pesos Tcnicos
y Reglas

Matriz
Equipos
Implicados

Tipos de
Impacto

Relaciones
Alarmas
I. Operativas

Relaciones
Sntomas
I. Operativas

Pesos
Operativos

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.

-Analistas
-Programadores
-Consultores
--...

Generacin de los
interfaces grficos

Desarrollo del
aplicativo

Planificacin

Definicin de Hardware
y herramientas
Software necesarias

Identificacin de los
Pilares Bsicos a
implementar

Identificacin del
Equipo de Trabajo

Identificacin de las
Bases de Datos
interrelacionadas

Flujo de Control

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

221

222

QUINTA PARTE
HACIA EL MANTENIMIENTO

223

224

NDICE QUINTA PARTE

1

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

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 durilla 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

Nivel de
Agregacin

Situacin

Cajeros ESPAA

CAJEROS Global

Estado Disponible

Cajeros MADRID

CAJEROS Comunidad

Estado Disponible

Cajeros Madrid
Cajeros Mstoles
Cajeros Legans

CAJEROS Ciudad
CAJEROS Ciudad
CAJEROS Ciudad

Estado Disponible
Fuera de Servicio Temporal
Estado Disponible

Cajeros ANDALUCIA

CAJEROS Comunidad

Estado Disponible

Cajeros Cdiz
Cajeros Sevilla
Cajeros Malaga
Cajeros Crdoba

CAJEROS
CAJEROS
CAJEROS
CAJEROS

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

Ciudad
Ciudad
Ciudad
Ciudad

Cajeros EXTREMADURA CAJEROS Comunidad

Fuera de Servicio Temporal

Cajeros Cceres
Cajeros Badajoz

CAJEROS Ciudad
CAJEROS Ciudad

Fuera de Servicio Temporal

Fuera de Servicio Temporal

Cajeros CATALUA

CAJEROS Comunidad

Estado Disponible

Cajeros Barcelona
Cajeros Gerona
Cajeros Lrida

CAJEROS Ciudad
CAJEROS Ciudad
CAJEROS Ciudad

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

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:

1er Nivel de
Prioridad

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

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

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

Proximidad
Alta

Proximidad
Media

Proximidad
Baja

2 Nivel de
Prioridad

Valor

Repercusin
Alta

Repercusin
Media

Repercusin
Baja

Repercusin
Alta

Repercusin
Media

Repercusin
Baja

Repercusin
Alta

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 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

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

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 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

PRIORIDAD

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:

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

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

...resultado de la Funcin:

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

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

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

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, 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.
As empezbamos el captulo COMO LOS SERVICIOS TCNICOS ORIENTAN EL
MANTENIMIENTO, pero ahora no estamos en disposicin 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 los
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 cierta 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

Nivel de
Agregacin

Situacin

Cajeros ESPAA

CAJEROS Global

Estado Disponible

Cajeros MADRID

CAJEROS Comunidad

Estado Disponible

Cajeros Madrid
Cajeros Mstoles
Cajeros Legans

CAJEROS Ciudad
CAJEROS Ciudad
CAJEROS Ciudad

Estado Disponible
Fuera de Servicio Temporal
Estado Disponible

Cajeros ANDALUCIA

CAJEROS Comunidad

Estado Disponible

Cajeros Cdiz
Cajeros Sevilla
Cajeros Malaga
Cajeros Crdoba

CAJEROS
CAJEROS
CAJEROS
CAJEROS

Estado Disponible
Estado Disponible
Estado Disponible
Estado Disponible

Ciudad
Ciudad
Ciudad
Ciudad

Cajeros EXTREMADURA CAJEROS Comunidad

Fuera de Servicio Temporal

Cajeros Cceres
Cajeros Badajoz

CAJEROS Ciudad
CAJEROS Ciudad

Fuera de Servicio Temporal

Fuera de Servicio Temporal

Cajeros CATALUA

CAJEROS Comunidad

Estado Disponible

Cajeros Barcelona
Cajeros Gerona
Cajeros Lrida

CAJEROS Ciudad
CAJEROS Ciudad
CAJEROS Ciudad

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
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%

25%
40%

25%

10%

10%

40%

15%
25%

15%

30%

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%

25%
40%

25%

10%

10%

40%

15%
25%

15%

30%

Ordenacin Actual

Ordenacin Anterior

NAS2.2.1

NAS2.1.3

NAS2.3.2

NAS2.1.4

NAS2.1.3

NAS2.1.2

NAS2.1.4

NAS2.1.1

NAS2.1.2

NAS2.3.2

NAS2.1.1

NAS2.2.1

50%

20%

303

NAS2.2.2

NAS2.2.2

NAS2.2.4

NAS2.2.4

NAS2.2.5

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

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 definidos 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 servicio
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 SERVICIOS
(Diseo e implantacin)

Gestin de Alarmas

Servicio TV

Servicio ME

INFRAESTRUCTURA
(mantenimiento)

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?

SI

NO

2.-Es fcil de obtener?

SI

NO

3.-Ha finalizado su periodo de validez?

SI

NO

4.-En caso afirmativo Es necesario prorrogarlo?

En caso afirmativo justificarlo:

SI

NO

5.-Ayuda a la toma de decisiones?

Detallar las decisiones adoptadas:

SI

NO

5.-Es entendible al usuario?

SI

NO

6.-Est sujeto a interpretaciones?

En caso afirmativo justificarlo:

SI

NO

345

7.-Hay circunstancias aleatorias que desvirtan

el indicador? En caso afirmativo detallarlas:

SI

NO

8.-El resultado obtenido est dentro de las

SI
expectativas iniciales? En caso negativo justificarlo:

NO

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

Indicadores de aos
anteriores

Ratios

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

Indicador
aprobado?

REGISTROS

RESPONSABLES
CLIENTE

No

Si

Elaboracin del documento

de descripcin del indicador
y codificacin del mismo

RESPONSABLES

Difusin del indicador

RESPONSABLES

Anlisis y seguimiento
del indicador

Aprueba test??
No

RESPONSABLES

Informes

Si
RESPONSABLES

Registro

Anlisis

Se puede
realizar mejora?

Documento del
indicador

RESPONSABLES

No

Descarte

RESPONSABLES

Si
Proponer mejora

Realizar la mejora

No

Es necesario
redefinir el
indicador?

RESPONSABLES

RESPONSABLES

Informe de
mejoras

RESPONSABLES
CLIENTE

Si

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