ingenieria logistica benjamin s. banchard

ING

EN

IER

A L

OG

STI

CA.

Benja

min

S.

Bla

nchard

INGENIERA LOGSTICApor

Ben jamin S . B lancha r d

P u b l i c a c i o n e s d e I n g e n i e r a d e S i s t e m a s

Ingeniera de Sistemas

c/ Edison, 428006 MadridTelfono (34-1) 411 50 11Fax (34-1) 411 47 03E-mail: [email protected] P.V.P.: 1.000 Ptas.

(IVA incluido)

Otros ttulos publicados:

1. Ingeniera de Sistemas. Benjamin S. Blanchard.2. La Teora General de Sistemas. ngel A. Sarabia.3. Dinmica de Sistemas. Javier Aracil.4. Dinmica de Sistemas Aplicada. Ronald R. Drew.5. Ingeniera de Sistemas Aplicada. Isdefe.6. CALS (Adquisicin y apoyo continuado durante el ciclo de

vida). Rowland G. Freeman III.

7

ILUSTRACIN DE PORTADATorre astronmica del ao 1090 d. C. en Honan (China)

COMIT DE REDACCIN

Presidente Sr. D. Martn Alear Ginard Teniente General (R) del Ejrcito de Tierra

Vocales Sr. D. Eduardo Avanzini Blanco General de Brigada Ingeniero del Ejrcito del Aire

Sr. D. Carlos Casajs Daz Vicealmirante Ingeniero de la Armada

Sr. D. Luis Garca Pascual Vice-Rector de Investigacin y Postgrado de la UPCO

Sr. D. Javier Marn San Andrs Director General de Navegacin Area

Sr. D. Ricardo Torrn Durn General de Brigada Ingeniero del Ejrcito de Tierra

Sr D. Alberto Sols Rodrguez-Candela Ingeniero de Sistemas. Isdefe

Sra. Da. M Fernanda Ruiz de Azcrate Varela Imagen Corporativa. Isdefe

Benjamin S. Blanchard

Benjamin S. Blanchard esel Director del Programade Ingeniera de Sistemasde Virginia PolytechnicInstitute & State University.Es consultor, investigador

y profesor de cursos de ingeniera desistemas, fiabilidad y mantenibilidad, apoyologstico y coste del ciclo de vida. Antes deincorporarse a la comunidad acadmica en1970 pas 17 aos en la industria comoingeniero de diseo, ingeniero de campo yresponsable de ingeniera (Boeing AirplaneCo., Sanders Associates, Bendix Corp. yGeneral Dynamics Corp.). Ha escrito cuatrolibros y es co-autor de otros cuatro, y hapublicado numerosos artculos sobreingeniera de sistemas y disciplinasasociadas. Ha impartido conferencias enAsia, Europa, Australia y Amrica. Esmiembro de la Society of LogisticsEngineers, de la que ha sido Presidente, yde otras organizaciones profesionales comoel National Council on Systems Engineering.Es autor de la primera monografa de estaserie de Ingeniera de Sistemas.

INGENIERA LOGSTICA2

No est permitida la reproduccin total oparcial de este libro, ni su tratamientoinformtico, ni la transmisin de ningunaforma o por cualquier medio, ya seaelectrnico, por fotocopia, por registro o porotros mtodos, sin el previo consentimientopor escrito de los titulares del Copyright.

Primera Edicin: Octubre - 19951.250 ejemplares

Isdefec/ Edison, 428006 Madrid.

Diseo:HB&h Direccin de arte y produccin

Traduccin:Alison Canosa Uldall

Infografa de portada:Salvador Vivas

Fotomecnica:Microprint, S.A.

Impresin:Grficas Monterreina, S.A. (Madrid)

ISBN: 84-89338-06-XDepsito legal: M- -1995Printed in Spain - Impreso en Espaa.

INGENIERA LOGSTICA4

5

PRLOGOHistricamente, el concepto de "logstica" proviene de diferentes

fuentes. En el sector defensa la logstica se refiere a un enfoque de ciclode vida y al diseo y desarrollo de sistemas de forma que puedan serapoyados eficaz y eficientemente durante su periodo previsto deutilizacin. El nfasis est en los "sistemas" y en el diseo y desarrollode una infraestructura que apoyar adecuadamente a los sistemasoperativo. En el sector comercial la logstica se trata desde unaperspectiva empresarial y se orienta al transporte y distribucin de"productos consumibles" (en comparacin con los sistemas). Incluyeactividades tales como la adquisicin y flujo de materiales y componentesno reparables, transporte y manejo, distribucin, almacenaje y venta deproductos.

Cuando se da un enfoque global integrado a la logstica, lasactividades asociadas al flujo material de productos consumibles en elsector comercial tambin son de aplicacin al tratar con sistemas delsector defensa. El desarrollo de sistemas incluye la consideracin derequisitos de flujos de materiales de artculos dentro del contexto delos objetivos del sistema en cuestin. Este autor ve la "logstica" comouna amalgama de esas dos facetas de actividad.

El objetivo de esta monografa es tratar la logstica desde unenfoque integrado de ciclo de vida, con nfasis en las actividades deingeniera asociadas a la planificacin inicial, la definicin de requisitos,

Sr. D. Javier Marn San Andrs Director General de Navegacin Area

INGENIERA LOGSTICA6

el diseo y desarrollo, la prueba y evaluacin, la produccin, y la entregade sistemas para su operacin. Estas actividades, que tratan de laadquisicin de sistemas, se presentan en trminos del proceso deingeniera de sistemas descrito en la primera monografa de esta serie.Debe revisarse la bibliografa adicional referente a muchas de esasactividades empresariales, de adquisicin y de gestin que estnincluidas en el aspecto global del apoyo logstico integrado pero quecaen fuera del empuje principal de la ingeniera de sistemas.

Finalmente quiero expresar mi sincero aprecio a Alberto Sols, ala direccin de Isdefe y al Comit de Redaccin, por su apoyo y estmulopara contribuir a la divulgacin de la "logstica" a travs de estamonografa.

Benjamin S. Blanchard

7

NDICE GENERAL

1. INTRODUCCIN 9

1.1. Entorno actual 111.2. Algunos trminos y definiciones 161.3. Los elementos de la logstica 24

2. PLANIFICACIN DE LA LOGSTICA 29

3. LA LOGSTICA EN EL CICLO DE VIDA DEL SISTEMA 37

3.1. Requisitos de apoyo logstico 393.1.1. Definicin de los requisitos operativos del sistema 413.1.2. Desarrollo del concepto de mantenimiento y apoyo 453.1.3. Desarrollo y asignacin de prioridades de medidas

de prestaciones tcnicas 533.1.4. Anlisis funcional del sistema y asignacin de requisitos 553.1.5. Especificacin de requisitos de apoyo logstico 60

3.2. Anlisis de apoyo logstico 613.2.1. El proceso de anlisis de apoyo logstico 623.2.2. Herramientas seleccionadas y tcnicas empleadas

en el proceso de anlisis de apoyo logstico 643.2.3. Registro de anlisis de apoyo logstico 823.2.4. Adquisicin y apoyo continuado durante el ciclo de vida 88

3.3. Diseo para soportabilidad 893.4. Prueba y evaluacin del sistema 943.5. Obtencin y adquisicin de elementos de apoyo logstico 963.6. Apoyo temporal del contratista 983.7. Servicio al cliente y apoyo durante el ciclo de vida 1003.8. Retirada del sistema y desecho o reciclaje del material 101

4. GESTIN LOGSTICA 107

4.1. Requisitos del programa de logstica 1084.2. Organizacin para la logstica 1094.3. Contratacin para la logstica 1144.4. Gestin y control del programa 115

REFERENCIAS 119

BIBLIOGRAFA 125

GLOSARIO 129

INGENIERA LOGSTICA8

9

Introduccin1

INGENIERA LOGSTICA10

Esta es una monografa sobre ingeniera logstica, es decir,describe actividades de ingeniera asociadas con la distribucin, elmantenimiento y apoyo continuado de los sistemas descritos en laprimera monografa de esta serie, Ingeniera de Sistemas [1].

Histricamente, el concepto de logstica tiene su origen envarias fuentes. En el sector de defensa, la logstica est relacionadacon un enfoque de ciclo de vida para el diseo y desarrollo de unsistema, de manera que ste pueda recibir apoyo rpido y econmicoa lo largo de su ciclo de vida programado. Se ha desarrollado elconcepto de apoyo logstico integrado (Integrated Logistics Support,ILS), en el que se incluyen actividades de planificacin, diseo,suministro y produccin, mantenimiento y apoyo, retirada progresiva yreciclaje de materiales, y las funciones de gestin asociadas con cadaactividad. El nfasis se centra en los sistemas y en el desarrollo deuna infraestructura que les proporcione el apoyo suficiente a lossistemas operativos. La citada infraestructura tendr en cuenta losniveles de mantenimiento y las funciones a desempear en cada nivel,necesidades de personal y formacin, apoyo de suministros (repuestos/recambios y requisitos adicionales de inventario), equipos de prueba yapoyo, instalaciones, requisitos de transporte y manipulacin, recursosinformticos y datos de mantenimiento [2].

En el sector comercial, la logstica se aborda ms bien desdeuna perspectiva de negocios, estando orientada hacia el transportey distribucin de productos consumibles, a diferencia de los sistemas.

11

Introduccin

Incluye actividades como la obtencin y flujo de materiales noreparables, transporte y manipulacin, distribucin, almacenamiento yventas de productos. Uno de sus objetivos consiste en desarrollar ygestionar el flujo entero de materiales, desde el suministro inicial(identificacin de materias primas), por medio de la produccin, elalmacenamiento y la distribucin final de productos destinados alconsumo. Las consideraciones de ciclo de vida y las actividadesrelacionadas con el mantenimiento y apoyo de producto no suelenincluirse [3].

Cuando la logstica se plantea con una perspectiva generalintegrada, las actividades asociadas con el flujo de material deproductos consumibles en el sector comercial tambin pueden aplicarsea los sistemas del sector de defensa. El diseo, desarrollo, produccin,distribucin y apoyo continuado de sistemas requiere que se tenganen cuenta los requisitos de flujo de materiales para artculosconsumibles, as como las prcticas comerciales necesarias paraapoyar estos artculos en el contexto de los objetivos del sistema encuestin. Desde el punto de vista del autor, la logstica constituye unaamalgama de las dos facetas mencionadas, en un nivel integrado deapoyo mutuo.

El objetivo de esta monografa es describir la logstica desde unenfoque integrado de ciclo de vida, subrayando las actividades deingeniera asociadas con la planificacin inicial, la definicin derequisitos, diseo y desarrollo, prueba y valoracin, produccin ydistribucin de sistemas.

1.1. Entorno actual

La complejidad de los sistemas de hoy est creciendo debido ala incorporacin de nuevas tecnologas en un entorno que cambiaconstantemente; el ciclo de vida de muchos sistemas actualmente enuso se est prolongando debido a la limitacin de recursos y a la


incapacidad de obtener sustitutos adecuados; gran nmero de estossistemas no satisfacen las expectativas del usuario en trminos de sufuncionamiento y apoyo; parece que la base industrial se estdebilitando (es decir, el nmero de suministradores de equipos,software, etc, est disminuyendo); y la competencia a nivel internacionalest creciendo. Estos y otros factores relacionados provocanimportantes retos en el entorno actual.

Cuando abordamos la situacin actual desde una perspectivaeconmica, encontramos con frecuencia que existe una falta devisibilidad total del coste, lo cual se ve en el efecto iceberg ilustradoen la Figura 1. Para muchos sistemas, los costes de diseo y desarrolloson relativamente conocidos; sin embargo, los costes asociados conla operacin y apoyo del sistema estn en cierto modo ocultos.Esencialmente, la comunidad del diseo ha sabido tratar con gran xitolos aspectos de coste a corto plazo, pero no se ha ocupadosuficientemente de los efectos a largo plazo. Al mismo tiempo, la

13

Introduccin

experiencia indica que gran parte del coste del ciclo de vida de undeterminado sistema se atribuye a las actividades operativas y de apoyoen las fases de utilizacin de un programa (por ejemplo, hasta un 75%del coste total puede atribuirse al mantenimiento del sistema y a lasactividades de apoyo) [4].

Adicionalmente, cuando se analizan las relaciones causa-efecto,nos encontramos con que una proporcin importante del coste del ciclode vida de un determinado sistema se debe a decisiones tomadasdurante las fases de planificacin preliminar y diseo conceptual. Lasdecisiones relativas a los requisitos operativos (por ejemplo, el nmeroy ubicacin de los emplazamientos previstos), polticas demantenimiento y apoyo (dos escalones frente a tres niveles demantenimiento), asignaciones de actividades manuales y/oautomatizadas, esquemas de empaquetado de equipo y software,tcnicas de diagnstico, seleccin de materiales, conceptos del nivelde reparacin, etc., tienen una repercusin importante en el coste totaldel ciclo de vida. Refirindonos a la Figura 1, gran parte de los costesocultos de utilizacin se deben a las actividades de mantenimiento yapoyo, y los requisitos de estas actividades se generan bsicamentecomo resultado del diseo inicial y de las decisiones iniciales de gestin.De este modo, mientras se intentan reducir los costes iniciales de unproyecto, muchas de las decisiones tomadas en esta fase puedenresultar catastrficas a largo plazo. En otras palabras, la oportunidadde reducir los costes totales es mayor durante las primeras fases deldesarrollo del sistema. La Figura 2 ilustra las relaciones entre los costesa lo largo del ciclo de vida.

La situacin se ve agravada en muchos casos por la falta de unmtodo disciplinado en la adquisicin de nuevos sistemas y/omodificacin o rediseo de la ingeniera de los sistemas existentes.Los ingenieros de diseo, en general, no tratan todos los elementosde un sistema como una entidad nica (lo cual significa incluir lainfraestructura de apoyo, esencial para asegurar que el sistema cumplala misin prevista). Adems, existe una tendencia a disear-ahora-


arreglar-despus utilizando el mtodo abajo-arriba; es decir, sedisean los elementos principales del sistema ahora, y luego seincorporarn los cambios y se considerarn los aspectos de apoyo.

A lo largo de los aos, la logstica ha sido considerada comoposterior al diseo, y las actividades relacionadas con ella no hangozado de gran popularidad, sino que se han implementado en lasfases de utilizacin y la importancia que se les ha concedido por partede la direccin no ha tenido el nivel adecuado. La experiencia hademostrado que los mtodos de gestin prevalentes en muchos casoshan sido perjudiciales. La Figura 3 muestra los efectos aproximadosde una planificacin preliminar del ciclo de vida, a diferencia de losprogramas que contemplan los aspectos de soportabilidad en una faseposterior. Por tanto, es preciso que las prioridades futuras para el diseoy desarrollo del sistema sean: (1) mejorar los mtodos de definicinlos requisitos de sistemas, de acuerdo con las verdaderas necesidadesdel usuario, al principio de la fase del diseo conceptual, y considerar

15

Introduccin

las prestaciones, la efectividad y todas las caractersticas esencialesde los sistemas de manera integrada (incluyendo los requisitoslogsticos especficos); (2) considerar el sistema en su totalidad, susprincipales componentes orientados a la misin y sus elementos deapoyo desde una perspectiva de ciclo de vida; (3) organizar e integrarlas actividades necesarias relacionadas con la logstica en la tareaprincipal del diseo del sistema, simultneamente y de maneraoportuna; y (4) establecer un mtodo disciplinado que incluya lasprevisiones necesarias para la revisin, evaluacin y realimentacincon el fin de asegurar que la logstica (y el diseo en cuanto asoportabilidad) reciba un tratamiento adecuado en el proceso globalde adquisicin del sistema.

Resumiendo, estas reas prioritarias son inherentes al procesode ingeniera de sistemas descrito en la primera monografa de estaserie. El concepto de apoyo logstico integrado pone en prctica unenfoque integrado de ciclo de vida al apoyo de sistemas, dando


nfasis a las primeras fases en la adquisicin de sistemas. Dentro delmarco completo de apoyo logstico integrado, se encuentran aquellasactividades relacionadas con la ingeniera que desempean un papelesencial en las fases iniciales del diseo y desarrollo de sistemas, yaque proporcionan al usuario sistemas que pueden recibir un apoyorpido y econmico durante toda su vida til prevista; es decir, el diseode un sistema para que ste pueda ser mantenido. La ingenieralogstica, segn la definimos en esta monografa, incluye estas primerasactividades de diseo, como uno de los muchos aspectos de ingenierade sistemas. Es esencial que estos requisitos sean satisfechos en laprctica, si queremos desarrollar y producir sistemas rentables en elfuturo.

1.2. Algunos trminos y definiciones

Antes de profundizar en cuestiones concretas relacionadas conla ingeniera logstica, conviene definir algunos conceptos clave:

A) Ingeniera de sistemas . En trminos generales, laingeniera de sistemas es la aplicacin efectiva de mtodos cientficosy de ingeniera con el fin de transformar una necesidad operativa enuna configuracin definida de un sistema mediante un proceso iterativoarriba-abajo de definicin de requisitos, anlisis y asignacin funcional,sntesis, optimizacin del diseo, prueba y evaluacin. Est orientadaal proceso e incluye las previsiones esenciales de realimentacin ycontrol [5].

La ingeniera de sistemas puede definirse tambin como laaplicacin de mtodos cientficos y de ingeniera para: (a) transformaruna necesidad operativa en la descripcin de los parmetros deprestaciones de un sistema y en su configuracin, mediante la utilizacinde un proceso iterativo de definicin, sntesis, anlisis, diseo, pruebay evaluacin; (b) integrar los parmetros tcnicos relacionados yasegurar la compatibilidad de todas las interrelaciones fsicas,

17

Introduccin

funcionales y del sistema completo; y (c) integrar los aspectos defiabilidad, mantenibilidad, seguridad, supervivencia, de personal y otrossimilares en el proceso global de ingeniera para conseguir los objetivostcnicos, de coste y de calendario fijados [6].

La soportabilidad es una de las principales caractersticas deldiseo que ha de integrarse a travs del proceso de ingeniera desistemas; las actividades relacionadas con la ingeniera logstica debenintegrarse adecuadamente con otras disciplinas relacionadas con eldiseo.

B) Apoyo logstico integrado (Integrated Logistic Support, ILS).En el sector de defensa, el ILS se define como un mtodo disciplinado,unificado e iterativo relativo a las actividades de gestin y tcnicasnecesarias para: (a) desarrollar los requisitos de apoyo relacionadosde manera consistente con los objetivos de apresto, los de diseo ylas relaciones de stos entre s; (b) integrar de forma efectiva lasconsideraciones de apoyo en el diseo del sistema y equipo; (c)identificar el mtodo ms rentable de apoyar el sistema en el campo; y(d) asegurar el desarrollo y la adquisicin de los elementos necesariospara la estructura de apoyo.

El ILS abarca el ciclo de vida entero del sistema e incluyeactividades de planificacin, diseo y desarrollo, suministro yproduccin/construccin, transporte y distribucin, utilizacin y apoyodel sistema, desecho y reciclaje y las funciones de gestin asociadascon cada rea. Los elementos concretos del ILS estn identificadosen la Figura 4. Mientras que los conceptos y actividades relativos alILS se derivan principalmente del sector de defensa, sus principiospueden aplicarse y adaptarse a las necesidades concretas de cualquiertipo de sistema, includos los sistemas de transportes, decomunicaciones, una fbrica comercial, un sistema de distribucin deinformacin, etc.

C) Ingeniera logstica . La ingeniera logstica incluye las fun-

19

ciones bsicas relacionadas con el diseo, implementadas de acuer-do con los objetivos del ILS. Esta puede incluir [2]: (a) la definicininicial de los requisitos de apoyo del sistema (forma parte de la tareade definicin de requisitos dentro del campo de la ingeniera de siste-mas); (b) el desarrollo de criterios de entrada para el diseo no slode los elementos del sistema relativos a la misin, sino tambin de lainfraestructura de apoyo (entrada de datos para las especificacionesde diseo y suministro); (c) la evaluacin sobre la marcha de configu-raciones alternativas de diseo, mediante la elaboracin de estudiosinterrelacionados, la optimizacin y la revisin formal del diseo (estoes, las tareas cotidianas de integracin del diseo relativas a lasoportabilidad del sistema); (d) la determinacin de los requisitos derecursos para el apoyo, a partir de una configuracin determinada deldiseo (cantidad de recursos humanos, niveles de especializacin,recambios y repuestos, equipos de prueba y apoyo, instalaciones, trans-porte, datos y recursos informticos); y (e) la evaluacin sobre la mar-cha de la infraestructura global de apoyo con el fin de asegurar unamejora continua del proceso, por medio de procedimientos iterativosde medicin, evaluacin y recomendaciones (obtencin de datos, eva-luacin y capacidad de mejorar el proceso).

La realizacin de estas funciones y de otras relacionadasconstituye bsicamente el alcance de la ingeniera logstica. Existen,por supuesto, muchas tareas adicionales relacionadas con elaprovisionamiento y obtencin de recambios y repuestos, la obtencinde equipos de prueba y apoyo, la preparacin de manuales tcnicos,la gestin continuada de las instalaciones y el almacenamiento de lasnecesidades de inventario, etc., que estn incluidas dentro del marcoglobal de ILS, aunque no profundizaremos en ellas en el presenteestudio.

D) Anlisis de apoyo logstico (Logistic Support Analysis,LSA). En el sector defensa, el LSA se define como la aplicacin selectivade mtodos cientficos y de ingeniera desarrollados durante la fasede adquisicin, como parte del proceso de ingeniera de sistemas, cuyos

Introduccin


objetivos son: (a) facilitar la influencia de las consideraciones de apoyoen el diseo; (b) definir aquellos requisitos de apoyo relacionadosntimamente con el diseo y entre s; (c) adquirir el apoyo necesario; y(d) proporcionar el apoyo necesario durante la fase operativa delsistema a un coste mnimo.

El LSA es inherente a las distintas funciones de la ingenieralogstica, y les proporciona apoyo. En opinin del autor, el LSA se definecomo un proceso analtico continuo (incorporado como parte del trabajoglobal de anlisis en la ingeniera de sistemas), que utiliza variasherramientas informticas para apoyar el diseo y desarrollo de laingeniera. Se destaca la integracin de las herramientas y tcnicasque, a su vez, complementan las actividades de ingeniera logstica.

E) Registro de anlisis de apoyo logstico (Logistic SupportAnalysis Record, LSAR). El LSAR se refiere a los datos (y a la base dedatos) que recogen los resultados del LSA. Este incluye el mtodoanaltico que conduce a la determinacin y definicin de los requisitosde apoyo del sistema, siendo el LSAR el registro que recoge losresultados. Desgraciadamente, en muchas ocasiones se presta mayoratencin a los datos y al formato adecuados que al proceso inicialque debe seguirse para el desarrollo de dichos datos [2].

F) Adquisicin y apoyo continuo durante el ciclo de vida(Continuous Acquisition and Life-Cycle Support, CALS). De acuerdocon la sexta monografa de esta serie, CALS se refiere a la aplicacinde tecnologa informtica al conjunto global de las actividades logsticas.En los ltimos aos, se ha empezado a conceder importancia aldesarrollo y procesado de datos, principalmente en formato digital,con el objetivo de reducir el tiempo de preparacin y procesado,eliminando redundancias, acortando el proceso de adquisicin delsistema y reduciendo los costes globales del programa. Existenaplicaciones especficas para la automatizacin de publicacionestcnicas, la preparacin de datos digitales para el aprovisionamientode recambios/repuestos, y para el desarrollo de datos de diseo quedefinen productos en formato digital [8].

21

G) Fiabilidad . La fiabilidad se refiere a las caractersticas in-herentes al diseo del sistema relativas a la capacidad de dicho siste-ma para desempear una funcin o misin designada. Especficamente,la fiabilidad puede definirse como la probabilidad de que un sistema oproducto funcione de forma satisfactoria durante un perodo de tiempodeterminado, en unas condiciones operativas especficas [9]. La fiabi-lidad abarca aquellas actividades, realizadas como parte del procesode ingeniera de sistemas, que estn orientadas a la tarea de asegurarque el producto final sea fiable y satisfaga las necesidades del usua-rio. Dichas actividades pueden incluir la realizacin de modelos defiabilidad, la asignacin de requisitos, las predicciones de fiabilidad (R,MTBF, l), anlisis (FTA, FMECA, RCM, etc.), la revisin del diseo,las pruebas de fiabilidad, y la obtencin y el anlisis de datos de fallos[4].

La fiabilidad, que influye de manera significativa en la frecuenciadel mantenimiento y en los recursos necesarios para el apoyo del sis-tema, es uno de los principales factores de entrada en el diseo parasoportabilidad. Las funciones de fiabilidad deben ser parte integrantede las actividades de ingeniera logstica. La fiabilidad recibe untratamiento ms detallado en la octava monografa de esta serie [10].

H) Mantenibilidad . La mantenibilidad se refiere a lascaractersticas inherentes al diseo relativas a la facilidad, precisin,seguridad y economa en la realizacin de actividades demantenimiento. En el sentido ms amplio, la mantenibilidad puedemedirse en trminos de una combinacin de tiempos de mantenimiento(Mct, Mpt, M, ADL, LDT, MDT), horas de trabajo de personal (MLH/OH), factores de frecuencia de mantenimiento (MTBM, MTBR), costede mantenimiento, y factores relacionados de apoyo logstico. En cuantoal tiempo se refiere, puede definirse como la probabilidad de que unelemento pueda conservarse en una condicin especfica o volver atener esta condicin gracias al mantenimiento realizado por personalespecializado, utilizando unos procedimientos y recursos correctos yal nivel adecuado [11].

Introduccin


La ingeniera de mantenibilidad incluye aquellas actividades dediseo, realizadas como parte del proceso de ingeniera del sistema,con el fin de asegurar que el producto final es mantenible y satisfacelas necesidades del consumidor. Dichas actividades pueden incluir larealizacin de modelos y anlisis de mantenibilidad, asignacin derequisitos, prediccin de mantenibilidad, anlisis de ingeniera demantenimiento (FMECA, RCM, anlisis de tareas, anlisis de nivel dereparacin), revisin de diseo, demostracin de mantenibilidad yobtencin de datos de mantenimiento [4].

La mantenibilidad, que se basa en la fiabilidad e influye demanera significativa en la frecuencia y en los recursos necesariospara la realizacin de las tareas de mantenimiento, es uno de losprincipales factores de entrada en el diseo para la soportabilidaddel sistema. Las funciones de ingeniera de mantenimiento han deser una parte integrante de las actividades de ingeniera logstica.En la prctica, gran nmero de las actividades especificadas parael anlisis de apoyo logstico se realizan mediante programasformales de fiabilidad y mantenibilidad. Por tanto, podemos concluirque existe cierto grado de dependencia entre ambas reas. Paraun tratamiento ms detal lado de la mantenibi l idad y delmantenimiento, vanse las monografas novena y dcima de estaserie [12,22].

I) Ingeniera de factores humanos . Ocurre con frecuenciaque en el diseo y desarrollo de un sistema se concede bastanteimportancia tanto al hardware como al software, y escasa o nula alfactor humano.

Para que el sistema sea completo deben considerarse el serhumano y las interfaces existentes entre ste y los dems elementosdel sistema (por ejemplo, equipos, software, instalaciones, datos, etc).Adems de las funciones operativas, existen una serie de tareas demantenimiento y apoyo que sern realizadas por personas. El factor

23

humano, tambin denominado ergonoma o ingeniera humana,se refiere al diseo de un sistema o producto cuya operacin ymantenimiento resulte fcil, eficiente y segura.

El diseo para el hombre considera una combinacin defactores antropomtricos (caractersticas fsicas del ser humano),factores sensoriales (odo, emplazamiento, sensacin), factoresfisiolgicos (efectos externos del entorno en el rendimiento del hombre)y factores psicolgicos (emociones, actitud, motivacin). La presentemonografa considera de particular inters incluir el hombre comoelemento de la infraestructura de mantenimento y apoyo [13]. Laingeniera de factores humanos incluye aquellas actividadesrelacionadas con el diseo, realizadas como parte del proceso deingeniera de sistemas, con el fin de asegurar el ptimo funcionamientode las interfaces finales entre el hombre y el resto de los elementos delsistema en trminos de operacin y apoyo del sistema. Las actividadesmencionadas pueden incluir el anlisis de factores humanos y laasignacin de requisitos, el anlisis detallado de tareas, el desarrollode diagramas de secuencias operativas y de mantenimento, el anlisisde errores, el desarrollo de necesidades de formacin, la revisin deldiseo, y la prueba y evaluacin del personal. Las actividades descritasdeben ser integradas, de forma adecuada, con las actividades deingeniera logstica; en particular, en cuanto a la definicin de losrequisitos de personal (nmero y nivel de especializacin) y para lacapacitacin de personal (tipo de capacitacin, ayudas/equipos decapacitacin, instalaciones y datos). La decimotercera monografa deesta serie desarrolla la cuestin del factor humano con mayorprofundidad [14].

J) Ingeniera de software . El software, gracias las tendenciasactuales y al constante desarrollo de la tecnologa informtica, se estconvirtiendo (si es que no lo es ya) en un elemento de peso en laconfiguracin de muchos sistemas. La experiencia reciente indica quelas consideraciones de software son inherentes al diseo y al desarrollode ms del cincuenta por ciento (50%) de los sistemas actuales. Elsoftware puede dividirse en tres reas [15]:

Introduccin


a) software que constituye un componente relacionado con lamisin del sistema y que es necesario para el funcionamientodel mismo. Desde el punto de vista logstico, es necesariomantener este software durante el ciclo de vida programado.

b) software necesario para realizar funciones de mantenimientodel sistema (por ejemplo, mtodos de diagnstico,programas de seguimiento de condiciones). Una de lasfunciones de la ingeniera logstica consiste en el desarrolloinicial y posterior mantenimiento de este software.

c) software necesario para apoyar las actividades relacionadascon el programa (por ejemplo, el relativo a los distintosmodelos informticos utilizados en los anlisis de diseo, elrelativo a la preparacin y procesado de distintas categorasde datos de diseo, de acuerdo con los requisitos CALS).

Adems, estas actividades relativas al apoyo del sistema debenintegrarse en las actividades de ingeniera logstica. La monografadecimoprimera de esta serie [16] se ocupa con detalle de la ingenierade software.

1.3. Los elementos de la logstica

Los principales elementos logsticos estn definidos en los puntos2 a 9 de la Figura 4. Estos elementos han de ser asignados yproyectados en el contexto de una infraestructura como la de laFigura 5. Respecto a esta Figura, debemos definir en primer lugar losrequisitos operativos del sistema (es decir, la distribucin o el desplieguede los elementos del sistema, perfiles de utilizacin, prestaciones yfactores de efectividad, etc.) Dados los requisitos operativos, esnecesario desarrollar el concepto de mantenimiento. ste constituyeuna serie inicial de ilustraciones y manifestaciones sobre cmo debe

25

ser diseado el sistema para que sea sostenible. El concepto demantenimiento, desarrollado como parte del proceso de diseoconceptual, incluye la identificacin de los niveles de mantenimiento(dos, tres o ms niveles en los que debe realizarse el mantenimiento),la asignacin de las responsabilidades del mantenimiento (porejemplo, usuario, suministrador, u otra parte o combinaciones de losmismos), los factores de efectividad (mtricas) asociados con losdiversos elementos de apoyo, criterios de diseo relativos a lainfraestructura de apoyo, etc. Analizaremos estas reas de actividaden la Seccin 3.1.

El concepto de mantenimiento del sistema proporciona una lneade referencia para la definicin de los requisitos logsticos, es decir, eldiseo de los principales componentes relacionados con la misin desoportabilidad, y el diseo de la infraestructura de apoyo. Esta lnea seampla a travs del anlisis funcional (esto es, la identificacin de lasfunciones de mantenimiento), la asignacin de requisitos, realizacindel anlisis de apoyo logstico, etc.

Introduccin

27

Introduccin

En cualquier caso, los dos principales elementos del sistema yla infraestructura de apoyo deben contemplarse de forma integrada entodos sus aspectos, ya que el diseo de los elementos principales delsistema tendr un impacto considerable sobre las estructuras de apoyo,y los elementos logsticos tendrn el efecto de realimentar los elementosprincipales. La Figura 6 muestra estas interrelaciones. Adems, la redentera (ver Figura 5) debe considerarse como un todo, ya que laefectividad del apoyo proporcionado al nivel de mantenimientoorganizativo depende de los recursos proporcionados al nivelintermedio, el cual, a su vez, depende de los recursos proporcionadosal nivel de fabricante. Existe una tendencia generalizada a tratarsolamente estos aspectos a nivel organizativo, sin considerar el impactoque puedan tener en los otros niveles, lo cual puede resultar bastantecostoso. Por tanto, no slo es necesario definir los requisitos logsticosespecficos sino tambin examinar las interfaces entre los principalesequipos/software y los elementos de apoyo en el marco de lainfraestructura global de apoyo ilustrada en la Figura 5.

29

2Planificacin

de la logstica


La planificacin de la logstica comienza con la concepcin delprograma, al identificar por primera vez una necesidad del consumidor.Teniendo en cuenta la definicin de la necesidad, de acuerdo con laFigura 7, es preciso: (a) identificar varias maneras de enfocar el diseoa nivel de sistema que nos permitan satisfacer los requisitos; (b)evaluar los candidatos ms probables en trminos de prestaciones,efectividad, coste de ciclo de vida y criterios relacionados; y (c)recomendar el procedimiento preferido. Puede que existan muchas

31

Planificacin de la logstica

alternativas; sin embargo, el nmero de posibilidades debe serreducido a unas pocas opciones viables, de acuerdo con los recursosdisponibles (humanos, materiales y financieros).

Es durante la realizacin de los estudios iniciales de viabilidaden la fase de diseo conceptual cuando los requisitos de apoyologstico se definen inicialmente. A medida que el ingenieroresponsable del diseo vaya identificando soluciones tcnicasalternativas al problema en mano, las tecnologas contempladas hande evaluarse no slo en base a las caractersticas de sus prestaciones,sino tambin en trminos de fiabilidad, mantenibilidad, factoreshumanos, soportabilidad, capacidad de produccin, coste del ciclode vida, etc. La realizacin de este tipo de evaluacin requiere unadefinicin inicial de la infraestructura de apoyo; es decir, el entornodel usuario final en el que el sistema va a ser utilizado y mantenido.Esto, a su vez constituye el primer paso en el desarrollo de losrequisitos operativos del sistema y el concepto de mantenimento.

La Figura 8 describe el ciclo de vida del sistema e identifica lasfases bsicas del programa, las actividades realizadas durante cadafase, principales hitos y funciones logsticas primarias. Esta figura esuna extensin de la Figura 7 de la primera monografa de esta serie,que refleja el ciclo de vida y las principales actividades de ingenierade sistemas. Las actividades logsticas se dividen en: planificacin,requisitos, diseo, adquisicin, apoyo continuado y evaluacin. Estasactividades se definen con mayor detalle en la Figura 9. Lasactividades de ingeniera logstica incluyen bsicamente la definicinde requisitos, el diseo en cuanto a soportabilidad, la adquisicin enlo que se refiere al anlisis de apoyo logstico y asesoramiento.

Respecto a la Figura 8, los hitos claves incluyen el desarrollodel sistema de especializacin tipo A, el Plan de Gestin deIngeniera del Sistema (System Engineering Management Plan,SEMP) y el Plan de Apoyo Logstico Integrado (Integrated LogisticSupport Plan, ILSP). La especificacin del sistema incluye todos los


requisitos tcnicos para el diseo del sistema (es decir, el conceptode mantenimiento, criterios de diseo para los elementos orientadosa la misin del sistema y pautas de diseo para la infraestructura deapoyo).

El SEMP abarca todas las actividades de gestin de ingenierade sistemas, fomenta la integracin de todas las actividadesrelacionadas con el diseo (para inducir soportabilidad e ingenieralogstica) identifica las principales interfaces con otros planes clavede programas de mayor nivel (para incluir el ILSP, plan de gestin deconfiguracin, plan de gestin de datos, plan de fabricacin, etc.) yproporciona la integracin de los planes individuales de diseoorientado a la disciplina (plan de programa de fiabilidad, plan deprograma de mantenibilidad, plan de programa de factores humanos,plan de programa de seguridad, plan de ingeniera de software, etc).

El ILSP, que abarca todas las actividades de ingeniera logsticay de gestin, debe desarrollarse inicialmente durante la fase de diseoconceptual, y debe ser actualizado cuando sea necesario, en las fasessubsiguientes, a medida que el sistema se define mejor. En lasprimeras etapas, el contenido del ILSP debe centrarse en los requisitoslogsticos y funciones de ingeniera logstica. La Figura 10 muestraun mtodo que conduce al desarrollo del ILSP durante el diseoconceptual [17].

A medida que vaya evolucionando el programa, el ILSP debeser actualizado y hecho a medida para que refleje la configuracindel sistema en desarrollo, y para proporcionar informacin adecuadasobre la planificacin y gestin, que no slo incluya la adquisicin derequisitos de apoyo logstico, sino que tambin proyecte estosrequisitos en el marco de la infraestructura general de apoyo. La Figura11 muestra un ejemplo del posible contenido de un ILSP tpico.Conviene sealar que la documentacin especfica de planificacinpuede variar en cuanto a terminologa de programa a programa, segnse refiere a un plan elaborado por un cliente o a un plan elaborado

Fig

ura

8,9

en s

olap

a

33


35


por un contratista. Sin embargo, para simplificar, el ILSP al que serefiere la presente monografa ser el plan general de logstica. Esteservir de base, y hablaremos de varios elementos de este plan a lolargo de esta monografa.

37

3La logstica

en el ciclo de vidadel sistema


Los objetivos bsicos de esta monografa son dos: (a) disearlos principales elementos relacionados con la misin, de manera quepuedan recibir apoyo efectivo y eficaz a lo largo de su ciclo de vidaproyectado; y (b) disear la infraestructura de apoyo del sistema paraque facilite la consecucin del primer objetivo. La Figura 4 identificalos elementos bsicos de apoyo y la Figura 5 proyecta estos elementosen el entorno de una infraestructura parcial.

Las actividades logsticas propuestas, resumidas en la Figura 8y tratadas en detalle en la Figura 9, constituyen las tareas principalesaplicables al alcance de estos objetivos para cualquier tipo de sistema.No obstante, la aplicacin especfica de estas tareas debe ser elaboradaa medida para el sistema en desarrollo y para el proceso deadquisicin implementado para ese sistema. La experiencia demuestraque, en muchos casos, las funciones logsticas han desembocado enla creacin de mucha actividad demasiado tarde en el proceso deadquisicin, la elaboracin de mucha documentacin con poca utilidadprctica y los resultados han sido caros. Se cree que esto se debe, engran parte, a una falta de comprensin de las tareas en curso entrminos de su intencin y produccin deseada; y, en segundo lugar, aque estas tareas no han sido adaptadas al nivel de definicin delsistema, a medida que el proceso de desarrollo evoluciona desde unanecesidad del usuario identificada a una configuracin definida. Unbuen ejemplo de esto es la aplicacin del LSA y el intento de producirmucha documentacin (por ejemplo, LSAR) sin tener en cuenta elPROCESO que ha de aplicarse al desarrollo de los datos de entrada

39

La logstica en el ciclo de vida del sistema

requeridos para el LSAR. Por lo tanto, es esencial conocer el procesode ingeniera de sistemas y saber como encaja la ingeniera logsticadentro de este proceso.

En la Figura 9, las funciones clave de la ingeniera logsticaincluyen la definicin de los requisitos de la logstica (es decir, anlisisde requisitos, estudio de viabilidad, requisitos operativos del sistema,el concepto de mantenimiento, anlisis y asignacin de funciones, y laespecificacin del sistema tipo A), realizacin del anlisis de apoyologstico, participacin e integracin del diseo y pruebas y valoracin.Estas actividades sern examinadas en esta seccin, utilizando laFigura 12 como referencia.

3.1. Requisitos de apoyo logstico

Los requisitos se derivan de una necesidad identificada delusuario. Es preciso realizar un anlisis de necesidades en elmomento de iniciar el programa si queremos establecer una base slidapara la definicin de requisitos de soportabilidad. Las expectativas delos clientes en trminos de disponibilidad, reparabilidad y utilidad delsistema, los niveles previstos de mantenimiento, el servicio al cliente,el coste del ciclo de vida, etc., deben identificarse desde el principio.Es en este momento, al principio del diseo conceptual, cuando hayque comenzar a identificar las funciones logsticas apropiadas quedeben realizarse. Esta informacin, complementada por la definicinde los requisitos operativos del sistema y el concepto de mantenimiento,nos llevan al desarrollo y jerarquizacin de las esenciales medidasde prestaciones tcnicas (technical performance measures, TPM).Estas TPM constituyen la base para la definicin de los criteriosadecuados de diseo de soportabilidad. As, mientras el proceso globalde definicin de requisitos se compone de diferentes actividades, lascomunicaciones con el usuario en una fase inicial son de mximaimportancia. Puede que esto parezca obvio; sin embargo, el usuariono ha participado siempre desde el principio y la falta de buenas


comunicaciones ha resultado con frecuencia en el desarrollo de unproducto que no responde a sus necesidades, en particular con respectoa la soportabilidad del sistema durante, en el ciclo de vida (ver Figura3). Se puede facilitar la promocin de las comunicaciones necesariascon el usuario mediante la aplicacin de tcnicas como desplieguede funcin de calidad (Quality Function Deployment, QFD) oequivalente.

Una vez que hayamos definido una necesidad, es necesario:(a) identificar varios mtodos posibles de diseo de nivel de sistemaque puedan desarrollarse para cumplir los requisitos; (b) evaluar lasalternativas ms probables en trminos de sus prestaciones,efectividad, soportabilidad y criterios econmicos; y (c) recomendar laforma preferida de actuar. Puede que existan muchas alternativas; sinembargo, hemos de reducir el nmero de posibilidades a unas pocasopciones viables, de acuerdo con los recursos disponibles.

Al considerar las distintas opciones de diseo, debemosinvestigar aplicaciones tecnolgicas alternativas como parte del anlisisde viabilidad (ver Figura 9). Por ejemplo, en el diseo de un sistema decomunicaciones, se debe utilizar tecnologa de fibra ptica o tecnologaconvencional de cable? En el diseo de un avin, en qu medidapueden emplearse materiales compuestos? Al disear un automvildeben emplearse circuitos electrnicos de gran rapidez en funcionesde control o debemos inclinarnos por un enfoque electromecnicoconvencional? En el diseo de un proceso en qu medida debemosincorporar recursos informticas integrados, o la inteligencia artificial?Para la realizacin de determinadas funciones debemos contemplarun mtodo automtico o debemos utilizar recursos humanos?

Es durante esta etapa inicial del ciclo de vida (es decir, en eldiseo conceptual) cuando se toman las decisiones importantesrespecto a la adopcin de una aplicacin tecnolgica especfica, y esen este perodo cuando los resultados de dichas decisiones puedentener el mximo impacto en el coste final del ciclo de vida de un sistema

41


(como demuestra la Figura 2). Las aplicaciones tecnolgicas se evalany en algunos casos, cuando no se dispone de datos suficientes, seinician investigaciones con el fin de desarrollar nuevos mtodos/tcnicaspara aplicaciones especficas.

Los resultados de un anlisis de viabilidad tendrn un impactoconsiderable no slo en las caractersticas operativas del sistema, sinoen la manufacturabilidad, soportabilidad, disponibilidad y otrascaractersticas adicionales. La eleccin (y aplicacin) de determinadatecnologa conlleva una implicacin de fiabilidad y mantenibilidad, puedeafectar a los requisitos de fabricacin, puede influir de forma significativaen los requisitos de los equipos de prueba y piezas de repuesto, einfluir con toda probabilidad en el coste del ciclo de vida. Dado quelas decisiones relativas a la seleccin de una tecnologa determinada,un proceso, etc., tienen consecuencias para el ciclo de vida, esimprescindible la aplicacin de mtodos de clculo del coste del ciclode vida en el proceso de evaluacin. En cualquier caso, es fundamentalla inclusin de consideraciones logsticas en esta fase del proceso deadquisicin.

3.1.1. Definicin de los requisitos operativos del sistema

Como muestra la Figura 12, una de las primeras tareas a realizaren el proceso de desarrollo de sistemas es la definicin de los requisitosoperativos. Estos requisitos incluyen las siguientes consideraciones:

A) Distribucin o despliegue operativo . Se define como elnmero de emplazamientos donde se utilizar el sistema, los plazos yla distribucin geogrfica, y el tipo y cantidad de componentes delsistema en cada emplazamiento. Esta es la respuesta a la preguntadnde ha de utilizarse el sistema?

Desde el punto de vista logstico necesitamos saber dnde esprobable que se utilice el sistema para identificar el nmero, ubicacin


y capacidad de las instalaciones de mantenimiento y apoyo; es decir,la infraestructura de apoyo. El diseo del sistema, el equipo deempaquetado, el software, los dispositivos para diagnstico yaccesibilidad, etc., pueden ser de una forma determinada si el sistemava a ser utilizado en un nico emplazamiento. Por el contrario, si sepreveen muchos emplazamientos, la configuracin resultante del diseopuede ser distinta. Por otra parte, el nmero y ubicacin de losemplazamientos potenciales condiciona el establecimiento de losrequisitos ambientales del diseo. Aunque estas consideraciones sehan tenido en cuenta en el pasado, el mtodo de trabajo empleadosola ser disear el producto primero y preocuparse posteriormente dednde poda utilizarse. Esto puede costar caro, si las modificacionespara adecuar el producto a las necesidades del consumidor se hacena lo largo de la vida til.

B) Perfil o escenario de la misin . Se define como laidentificacin de la misin principal del sistema y sus misionesalternativas o secundarias. Qu funcin ha de desempear el sistemapara satisfacer una necesidad del consumidor y cmo ha de utilizarse?Esto puede definirse por medio de una serie de perfiles operativos,ciclos de tareas, secuencias activas y pasivas, etc., que reflejen losaspectos dinmicos necesarios para llevar a cabo una misin.

Desde el punto de vista logstico, necesitamos saber exacta-mente cmo va a utilizarse el sistema y las probables solicitacionesque va a experimentar (tanto internas como externas) para que resulteadecuado en trminos de fiabilidad y mantenibilidad. A pesar de queel sistema probablemente sea utilizado de forma distinta por cada ope-rador, debemos realizar unos supuestos subyacentes al establecer unperfil del peor de los casos. En muchas ocasiones, la Especificacindel Sistema Tipo A es muy general y no abarca las cuestiones di-nmicas; se inicia el diseo; se desarrolla y se prueba un prototipo; yel producto resultante no satisface las expectativas del usuario en cuan-to a efectividad y coste del ciclo de vida. En otras palabras, se hansupuesto desde el principio unos perfiles operativos equivocados.

Fig

ura

12 e

n so

lapa

43


C) Requisitos de prestaciones y efectividad . Definicinde las caractersticas principales de las prestaciones o funcionesdel sistema. Esto se refiere a parmetros como autonoma, precisin,rapidez, capacidad, procesamiento, potencia, tamao, peso yfactores tcnicos relacionados que son esenciales para elcumplimiento de la misin propuesta del sistema en los distintosemplazamientos. Adems, es necesario definir las caractersticasapropiadas de efectividad que puedan estar relacionadas con losfactores de prestaciones, y aplicadas al perfil de misin aplicable oescenario operativo. Tales caracterst icas pueden incluirdisponibilidad (A), fiabilidad (R, MTBF, l) mantenibilidad (MTBM,Mct, MDT, MMH/OH), seguridad de misin (D), utilizacin deinstalaciones (%), efectividad organizativa, niveles deespecializacin de personal, coste, etc, segn sean aplicables. Elobjetivo es poder aplicar la mtrica correcta a un determinado perfiloperativo. Cul es la relacin entre un alto grado de fiabilidad ylos distintos parmetros de prestaciones necesarios para cumplirun requisito especfico de la misin? Desde el punto de vistalogstico, las diferentes medidas de efectividad condicionan no slola frecuencia de mantenimiento, sino los recursos logsticos queprobablemente sean precisos para realizarlo (por ejemplo: piezasde recambio y repuesto, equipos de prueba, personal demantenimiento, instalaciones, transporte, datos y recursosinformticos). Estos factores, a su vez, ayudan a determinar losniveles de mantenimiento, rutinas de diagnstico y empaquetadode equipos y software, y caractersticas relacionadas del diseo.

D) Ciclo de vida operativo (horizonte) . Es la duracin estimadadel perodo de utilizacin operativa del sistema (y de sus elementos).Durante cunto tiempo seguir utilizando el usuario el sistema? Cules el perfil total del inventario necesario para el sistema y suscomponentes? Mientras que las condiciones pueden cambiar (debido aun cambio de las amenazas, obsolescencia inminente, el deseo detecnologa nueva, etc.), es necesario establecer una lnea de referenciadesde el principio.


Desde el punto de vista logstico, la especificacin de un ciclode vida designado es fundamental no slo respecto al diseo de losprincipales elementos relacionados con la misin del sistema parasoportabilidad, sino para el diseo de la infraestructura de apoyo paraun perodo especfico. Estos requisitos individuales de diseo puedenvariar de forma significativa si se trata de un ciclo de vida previsto de 1ao, de 10 aos o de 20 aos. En el pasado, se utilizaba con frecuenciael mtodo de disear un producto sin tener en cuenta desde el principiosu ciclo de vida, y luego exigir que fuera soportable durante un perodolargo de tiempo. Este mtodo suele resultar en la realizacin de unaserie de modificaciones a lo largo del ciclo de vida del producto, lo quecon frecuencia resulta en costes significativos.

E) Entorno . Definicin del entorno en el que el sistema ha deoperar de forma efectiva (por ejemplo, temperatura, choques yvibraciones, ruido, humedad, condiciones rticas o tropicales, terrenollano o montaoso, condiciones aerotransportadas, terrestres ymarinos). Los factores ambientales pueden desarrollarse mediante ladefinicin de un conjunto de perfiles de misin o emplazamientosoperativos. Adems, tambin debemos considerar el entorno al que elsistema (y sus componentes) est expuesto durante el transporte,manipulacin y almacenamiento. Es posible que los componentes delsistema estn expuestos a un entorno ms riguroso durante eltransporte que durante su funcionamiento.

Desde el punto de vista logstico, los requisitos ambientales delfuncionamiento del sistema pueden tener un impacto en varias reas.En primer lugar, aunque el sistema debe estar diseado para operaren entorno especfico, puede ocurrir en ocasiones que los efectos exter-nos del medio ambiente influyan en la frecuencia del mantenimiento yla necesidad de gastar recursos logsticos. En segundo lugar, en zo-nas donde el medio ambiente externo es especialmente duro, puederesultar necesario disear un nuevo elemento logstico (por ejemplo,el diseo de un contenedor especial para el transporte). En tercer lu-gar, el medio ambiente en el que va a operar el sistema condiciona

45


(hasta cierto punto) el entorno en el que va a realizarse el mantenimien-to, en particular aquellas funciones llevadas a cabo en primer escaln.

El establecimiento de los requisitos operativos constituye la basedel diseo del sistema. Necesitamos, claramente, contestar lassiguientes preguntas antes de proseguir:

a.- Cules sern las funciones del sistema?b.- Cundo tendr que desarrollar la funcin prevista y durante

cunto tiempo?c.- Dnde se utilizar el sistema?d.- Cmo alcanzar el sistema sus objetivos?

La respuesta a estas preguntas debe establecer una lnea dereferencia. Aunque las condiciones puedan cambiar, es necesarioestablecer unos supuestos iniciales. Puede parecer a veces que noexiste suficiente informacin para responder a algunas de estaspreguntas prioritarias, y por consiguiente los requisitos operativos noestarn muy bien definidos. Al mismo tiempo, los ingenierosresponsables del diseo estn diseando el producto sin que todossigan las mismas especificaciones. Es importante entonces abordarcada una de las reas, establecer unos criterios para el diseo(documentando todos los supuestos), y poner en marcha un mtodopara la gestin efectiva de la configuracin a partir de ese momento.

Una vez establecidos unos buenos criterios para los requisitosoperativos, el siguiente paso consiste en desarrollar el concepto demantenimiento del sistema. Como demuestra la Figura 12, el conceptode mantenimiento representa una actividad clave en la definicin delas actividades logsticas.

3.1.2. Desarrollo del concepto de mantenimiento y apoyo

El concepto de mantenimiento se desarrolla a partir de ladefinicin de los requisitos operativos del sistema descritos en la


Seccin 3.1.3, e incluye las actividades reflejadas en la Figura 5.Constituye una serie de ilustraciones y aseveraciones sobre cmo debeser diseado el sistema para soportabilidad, mientras que el plan demantenimiento define los sucesivos requisitos basados en losresultados del anlisis de apoyo logstico o estudios similares [2]. Elconcepto de mantenimiento, que se plasma finalmente en un plandetallado de mantenimiento, cubre bsicamente los niveles demantenimiento, polticas de reparacin, responsabilidades, criteriospara el diseo relativos a los elementos logsticos, factores deefectividad aplicados a la infraestructura global de apoyo, y factoresambientales.

A) Niveles de mantenimiento . Se refieren a la divisin defunciones y tareas para cada rea de mantenimiento. La Figura 13muestra el flujo de de actividades y materiales, donde las actividadesde mantenimiento estn representadas por el flujo desde elemplazamiento de utilizacin por el usuario hasta el ltimo escaln demantenimiento y el aprovisionamiento de recursos de apoyo logstico(por ejemplo, piezas de repuesto) est representado por el flujo desdeel proveedor hasta el emplazamiento operativo.

Segn las caractersticas y complejidad del sistema, la fiabilidadde sus componentes, la importancia crtica de artculos para el xitode la misin, etc., pueden existir 2, 3 y hasta 4 niveles de mantenimiento;sin embargo, para simplificar, podemos clasificar el mantenimientocomo organizativo (primer escaln), intermedio (segundo escaln)y suministrador/almacn (tercer escaln). La Figura 14 destaca lasdiferencias esenciales entre estos niveles. Se recomienda consultaralgunas de las referencias que figuran en la Bibliografa.

Una forma habitual de enfocar la definicin del concepto demantenimiento es aceptar que la estructura existente es la msadecuada para un nuevo sistema (ya sean 2, 3 4 los niveles demantenimiento). A pesar de que este enfoque pueda parecer el mseconmico, es posible que nuestras prcticas adquiridas con los

47


49


sistemas existentes no sean las ms viables para el nuevo requisito.Por otra parte, los niveles pueden cambiar a medida que el sistema vaevolucionando a lo largo de su ciclo de vida. Por tanto, es precisoreevaluar el concepto para cada nuevo requisito.

B) Polticas de reparacin . Se refiere al alcance de lasreparaciones del sistema y sus elementos. Dentro de las limitacionesdescritas en las Figuras 13 y 14, pueden existir un nmero de polticasposibles que especifiquen el grado en que deben realizarse lasreparaciones del sistema. Una poltica puede establecer que un artculodebe ser diseado con el fin de ser no reparable, parcialmente reparableo totalmente reparable. Las opciones se evalan segn el mtododescrito en la Figura 15, y se deciden las polticas recomendadas. Sedesarrollan los criterios de diseo, y avanza el diseo del sistema dentrode las pautas marcadas por la poltica de reparaciones elegida.

En la Figura 16 se da un ejemplo de una poltica de reparacionespara el sistema XYZ, desarrollada como parte del concepto demantenimiento.

El desarrollo del concepto de mantenimiento depende de laidentificacin de los niveles de mantenimiento supuestos, y de lasfunciones primarias a desarrollar en cada nivel. El objetivo, en estafase, es definir una base para establecer criterios de diseo en cuantoa soportabilidad y para disear la infraestuctura de apoyo. Los nivelesde reparacin asumidos influirn en los esquemas de empaquetadode equipos y software, el grado de diagnstico requerido (sobre todopara componentes electrnicos), la accesibilidad y las provisiones parael etiquetado que deben incorporarse en el caso de artculos reparables,etc. Aunque las condiciones pueden cambiar a medida que se desarrollala definicin del sistema, hay que establecer una base para el diseoconceptual. Este objetivo puede ser facilitado mediante la realizacinde los anlisis de coste del ciclo de vida (Life-Cycle Cost, LCC) y denivel de reparacin (Level of Repair, LOR). En el pasado, estasherramientas se han empleado a lo largo del ciclo de vida (sobre todo


Fig

ura

,16

en s

olap

a

51


el anlisis LOR) y los resultados han sido obtenidos despus del mismo.Aunque este enfoque puede responder a los requisitos de la definicinde recursos de apoyo logstico basados en una configuracin slidade diseo, no responde al diseo del sistema en cuanto a soportabilidad.

C) Responsabilidades organizativas . La realizacin delmantenimiento puede ser responsabilidad del usuario, del fabricante(o proveedor), de terceros o de una combinacin de ellos! Adems, laresponsabilidad puede cambiar de mano, a medida que se avanza enla fase de utilizacin. Por ejemplo, puede establecerse una capacidadinterina de apoyo del contratista donde el apoyo al sistema correspondeal fabricante en una fase inicial de su funcionamiento, pasandoposteriormente a ser responsabilidad del usuario. Por otra parte, undeterminado artculo puede considerarse no reparable siempre queexistan fuentes adecuadas de suministro de piezas de recambio yrepuesto. Con la transferencia de responsabilidades relativas al apoyo,un artculo clasificado inicialmente como no reparable puede llegar aser reparable, segn la capacidad de la nueva organizacin.

Las decisiones relativas a las responsabilidades organizativaspueden tener un impacto en el diseo del sistema desde el punto de vistade diagnstico y empaquetado del equipo y software, adems decondicionar las polticas de reparacin, clusulas de garanta del contratoy similares. El anlisis del nivel de reparacin ayuda a describir las polticasde reparacin, aunque las decisiones dependen en gran parte de criterioseconmicos. Al mismo tiempo, existen otros factores que influirn en lasdecisones sobre si un producto es reparable o no (por ejemplo, factorestcnicos de seguridad, organizativos y polticos y ambientales; la Seccin3.2 contiene informacin adicional sobre los anlisis de nivel de reparacin).

D) Elementos de apoyo logstico . Se refiere a los criterios dediseo relativo a los elementos logsticos identificados en la Figura 4.Estos elementos incluyen el aprovisionamiento (repuestos y recambios),y pueden incluir factores de probabilidad respecto a disponibilidad derecambios, niveles de inventario, cantidades econmicas de pedidos,


frecuencia de ciclos de aprovisionamiento, etc. Pueden desarrollarselos criterios apropiados para equipos de autodiagnstico incorporadosy/o externos y equipos de prueba; por ejemplo disponibilidad, MTBF,MTBM, MDT, frecuencia de calibracin y tiempo de funcionamientopara los equipos de prueba. Puede resultar conveniente incluir tambinlos niveles de personal de mantenimiento, el nivel de especializacin,los requisitos de formacin, y los factores de efectividad.

De todos modos, el concepto de mantenimiento proporcionaalgunos criterios iniciales y lneas de referencia para el diseo de lacapacidad global de apoyo reflejado en la Figura 5. Tanto los parmetrosrelacionados con las prestaciones como los factores de efectividad hande ser contemplados. Aunque el trabajo de especificacin de requisitosde los principales elementos del sistema relacionados con la misin seaexcelente, en muchas ocasiones no se tiene en cuenta la infraestructurade apoyo. Dado un requisito de disponibilidad de qu sirve especificarun tiempo medio de reparacin de treinta minutos para elementosprincipales o software si se tarda entre seis meses y un ao en conseguirun repuesto? Bsicamente, la estructura de apoyo puede tender a reducirla capacidad total del sistema, a no ser que se preste atencin a sudiseo y efectividad total.

E) Entorno . Definicin del entorno en lo referente almantenimiento y apoyo. Este incluye la temperatura, vibraciones y choques,humedad, ruido, entornos rticos o tropicales, terrenos llanos omontaosos, entornos martimos o terrestres, etc., aplicado a las tareasde mantenimiento y funciones relacionadas con el transporte, manejo yalmacenamiento.

Resumiendo, el concepto de mantenimiento constituye la basepara el establecimiento de los requisitos de soportabilidad en el diseodel sistema. La identificacin inicial de las funciones de mantenimiento,la asignacin preliminar de funciones a los distintos niveles demantenimiento, y los estudios de procedimientos se realizan con laayuda de los anlisis de nivel de reparacin y mtodos relacionados.Se establece una lnea de referencia que nos conduce al anlisis deapoyo logstico (ver Figura 12) y la preparacin del plan definitivo de

53


mantenimiento durante la fase del diseo y desarrollo detallados.

3.1.3. Desarrollo y asignacin de prioridades de medidas deprestaciones tcnicas

Tomando como base los requisitos operativos y el concepto demantenimiento, se identifican factores cuantitativos especficos o lasmtricas asociadas con el sistema que se est desarrollando. Estasmtricas, que se suelen denominar medidas de prestaciones tcnicas(technical performance measures, TPM) o parmetros dependientesdel diseo, deben fijarse inicialmente como parte del proceso dedefinicin de requisitos durante el diseo conceptual e incluirse en laespecificacin del sistema Tipo A siendo verificados ms tarde atravs de la evaluacin y revisin continua del sistema.

Las TPM deben identificarse de forma jerrquica, empezando anivel de sistema, descendiendo hasta el subsistema, nivel deconfiguracin de artculo, equipos y software, para cada elementologstico. Debe existir la posibilidad de detectar los requisitos mediblesde arriba-abajo, y el cumplimiento de estos requisitos ha de verificarsems tarde de abajo-arriba mediante el proceso de prueba y evaluacin.

La Figura 17 identifica unas TPM tpicas que, si se especificaran,tendran un impacto considerable en la logstica. Estas TPM se handividido en dos categoras: (a) factores probablemente aplicables alsistema total y que influirn principalmente sobre los elementos delsistema relacionados con su misin; y (b) factores que puedenrelacionarse directamente con los elementos logsticos identificadosen la Figura 4. Los factores de ambas categoras estn ntimamenteinterrelacionados, segn refleja la Figura 6. Aquellos parmetros quese aplican a los elementos principales del sistema influyenenormemente sobre el diseo de la infraestructura de apoyo logstico,y los que se aplican en el rea de logstica condicionarn la capacidaddel sistema para llevar a cabo su misin con xito.

55


La aplicacin de las TPM debe adaptarse al sistema en cuestiny depender, por supuesto, de los requisitos del usuario y de lasfunciones que el sistema ha de desempear. Es posible que todos losfactores identificados en la Figura 17 sean aplicables. Adems, esprobable que las prioridades que indican los respectivos niveles deimportancia varen en cada situacin. De cualquier forma, las mtricascorrectas han de ser especificadas y ordenadas por importancia parael sistema en cuestin, y deben estar relacionadas con los escenariosde la misin. Por otra parte, las TPM orientadas a los elementoslogsticos deben identificarse en el marco de la infraestructura globalde apoyo reflejada en la Figura 5; es decir cules de las TPM sonaplicables a nivel organizativo, a nivel intermedio y a nivel suministrador/almacn de mantenimiento?

Histricamente, la aplicacin de las TPM se ha realizado a nivelde sistema, con nfasis en la especificacin de factores de prestacionesde los elementos principales del sistema. En muchos casos, se hanespecificado tambin los factores de efectividad, fiabilidad ymantenibilidad y coste. Sin embargo, se ha dedicado muy poca (si esque alguna) atencin a la infraestructura de apoyo y a la evaluacin desu efectividad y eficacia. Pero si el objetivo futuro consiste en disearel sistema para soportabilidad, los elementos de la infraestructura deapoyo logstico deben tener el mismo grado de importancia que loselementos principales del sistema.

3.1.4. Anlisis funcional del sistema y asignacin de requisitos

Como muestra la Figura 12, el siguiente paso en el proceso deingeniera de sistemas es el desglose, o descomposicin, de requisitosespecificados a nivel de sistema, subsistema, y tan abajo en laestructura jerrquica como sea necesario para identificar los recursosespecficos y los diferentes componentes del sistema. El objetivoconsiste en definir el sistema en trminos funcionales, describiendo


los qu? y no los cmo?; es decir, hay que definir lo que debehacerse y no cmo debe hacerse. Las funciones pueden incluirfunciones de diseo, produccin, utilizacin, mantenimiento y apoyo,etc. Las funciones de alto nivel se descomponen en las de segundonivel, las funciones operativas conducen a las de mantenimiento y seemplea la numeracin de bloques para proporcionar capacidad deseguimiento de los requisitos, tanto descendente como ascendente.La Figura 18 muestra un diagrama funcional simplificado de bloquescon cierta medida de descomposicin.

Dada una descripcin de alto nivel del sistema en trminosfuncionales, el paso siguiente es combinar o agrupar las funcionessimilares en subdivisiones lgicas, identificando los principalessubsistemas y los componentes de los niveles inferiores de la totalidaddel sistema; es decir, desarrollar un esquema de empaquetado funcionalpara el sistema. Esto resulta en la identificacin inicial de equipos,software, recursos humanos, instalaciones, datos o sus combinaciones.Esto, a su vez, conduce al proceso de asignacin de requisitos, o ladistribucin de TPM desde el nivel de sistema hacia abajo, hasta llegaral nivel necesario. La Figura 19 refleja los resultados de la asignacinpara un sistema tpico orientado al hardware.

Las funciones operativas conducen a funciones de mantenimiento(ver Figuras 19 y 20). Se procede a la evaluacin de cada bloque entrminos de entradas, salidas, controles y/o limitaciones y mecanismosfacilitadores (ver Figura 20). Cabe subrayar que las expresiones de cadabloque estn orientadas a acciones y que los mecanismos conducen,bsicamente, a la identificacin de los recursos especficos necesariospara desarrollar la funcin; por ejemplo, de un equipo, elemento desoftware, una herramienta de prueba, una instalacin, recursos humanos,una pieza de recambio, etc. Estos requisitos de recursos son verificadosms adelante a travs del anlisis de apoyo logstico.

Desde un punto de vista logstico, el anlisis funcionalproporciona una base comn para identificar todos los recursos de

57


59

mantenimiento y apoyo; es decir, los requisitos especficos para cadauno de los elementos reflejados en la Figura 4. Por otra parte, se utilizacomo entrada principal en la elaboracin y desarrollo de varios anlisis,tanto dentro del anlisis de apoyo logstico como en los anlisisrelacionados. Por ejemplo, un anlisis funcional es necesario para larealizacin de:

a) Modelos de fiabilidad y diagramas de bloques; esto es,anlisis de fiabilidad.

b) Anlisis de modos de fallos, sus efectos y su criticidad(Failure Modes, Effects, and Criticality Analysis, FMECA).

c) Mantenimiento centrado en la fiabilidad (Reliability-CenteredMaintenance, RCM).

d) Anlisis de nivel de reparacin (Level of Repair Analysis,LORA).

e) Anlisis de riesgos/seguridad del sistema.f) Anlisis de mantenibilidad y anlisis de tareas de

mantenimiento.g) Anlisis de tareas de operador (Operator Task Analysis,

OTA), y diagramas de secuencias operativas (OperatingSequence Diagrams, OSD).

h) Anlisis de apoyo logstico (Logistic Support Analysis, LSA).i) Anlisis de coste del ciclo de vida (Life-Cycle Cost Analysis,

LCCA).

En el desarrollo del anlisis de apoyo logstico, debe seguirseuna sola lnea de referencia para la descomposicin de las funciones demantenimiento (identificadas inicialmente como parte del concepto demantenimiento) en subfunciones y tareas detalladas. A partir de aqu,se procede al anlisis de tareas de mantenimiento (Maintenance TaskAnalysis, MTA) as como a la identificacin de los recursos especficosnecesarios para la realizacin de cada tarea; por ejemplo, recambios,equipos de prueba y apoyo, personal, instalaciones, software demantenimiento, y datos. Se consideran tanto los requisitos programadoscomo los no programados. El LSA se trata en detalle en la Seccin 3.2.



En el pasado, el anlisis no se ha realizado siempre en elmomento adecuado, si es que se llegaba a realizar; es ms, lasfunciones de mantenimiento que han de desarrollarse en todos losniveles de la infraestructura (ver la Figura 5) normalmente no seconsideraban. Como consecuencia, las diferentes disciplinas de diseoasignadas a un programa determinado han tenido que generar suspropios anlisis para cumplir con los requisitos del mismo. En muchoscasos, estos anlisis se realizaban de forma independiente, y muchasdecisiones de diseo se tomaban sin poder beneficiarse de un criteriocomn. Por supuesto, esto resultaba en discrepancias de diseo ycostosas modificaciones en momentos posteriores del ciclo de vidadel sistema. Por consiguiente, el anlisis funcional y el proceso deasignacin proporcionan una base excelente, y todas las actividadespertinentes de diseo deben seguir la misma fuente de datos parasatisfacer los objetivos, tanto de la ingeniera de sistemas, descritosen la primera monografa de esta serie [1] como de la ingenieralogstica, descritos en esta publicacin.

3.1.5. Especificacin de requisitos de apoyo logstico

El documento ms importante, desde la perspectiva del diseo,es la especificacin del sistema tipo A que describe la configuracinfuncional bsica del sistema y los resultados del proceso de anlisis derequisitos (ver Hito 1, Figura 8). Este documento de nivel superiorconstituye la base del desarrollo de la totalidad de los requisitos tcnicosy conduce a los requisitos de diseo de subsistemas y otros componentesdel sistema; por ejemplo, especificaciones de desarrollo, producto,proceso, y materiales o componentes. La Figura 17 de la monografaIngeniera de Sistemas [1] presenta un ejemplo de lo que puedeincluirse en la especificacin de un sistema. Ntese que los requisitoslogsticos se introducen a travs del concepto de mantenimiento y delos diagramas de flujo funcional en las Secciones 3.1.3 y 3.1.4; sedescriben en cuanto a soportabilidad en la Seccin 3.2.7, y se definenms detalladamente en la Seccin 3.5. Estos requisitos tcnicos deben

61


ser complementados por los requisitos logsticos de programaespecificados en el Plan de Apoyo Logstico Integrado (IntegratedLogistics Support Plan, ILSP), mostrados en la Figura 11.

En muchos proyectos, la especificacin del sistema se elaboraen trminos algo imprecisos y no expresa los requisitos de una formamuy definitiva. Los requisitos logsticos se especifican, con frecuencia,en trminos tan generales como el sistema ser diseado parasoportabilidad o el sistema ser diseado para ser compatible con lainfraestructura existente o el sistema ser diseado para unmantenimiento econmico y efectivo. A veces, la falta de definicininicial es intencionada, ya que permite al grupo de diseo la mximaflexibilidad durante el mximo de tiempo. Al mismo tiempo, se preparany negocian contractualmente especificaciones de ms bajo nivel y eldiseo detallado de los subsistemas y componentes progresa sin elbeneficio de una base slida sobre la que construir. Simultneamente,el grupo logstico se esfuerza por seguir las distintas iteraciones de diseode los elementos principales del sistema. De esta forma, cuandofinalmente se integran los distintos componentes del sistema, de abajoa arriba, existen desigualdades, incompatibilidades, desperdicio dedocumentacin ya introducida, etc. Este proceso posterior de cambios ymodificaciones para que las cosas funcionen suele ser bastante costoso,como se demuestra en la Figura 3. Por consiguiente, es esencial elaborare implementar desde el principio una buena especificacin completa.Adems, los requisitos logsticos deben definirse de manera satisfactoriae incluirse dentro de esta especificacin.

3.2. Anlisis de apoyo logstico

Segn lo expuesto en la Seccin 1.2, el LSA constituye unproceso analtico, realizado dentro del marco global de anlisis en laingeniera de sistemas. Uno de sus objetivos es aplicar las herramientas,las tcnicas y los mtodos apropiados durante todo el proceso deadquisicin del sistema para: (a) influir en el diseo del sistema paralograr su soportabilidad; y (b) determinar los requisitos de recursos de


apoyo logstico del sistema a lo largo de su ciclo de vida proyectado.Se concede particular importancia al anlisis inicial y al diseo delsistema, como demuestra la Figura 20 [27, 18].

En los primeros momentos de las fases de diseo conceptual ypreliminar del sistema el nfasis es de arriba-abajo, con el objetivo deinfluir directamente en el diseo para soportabilidad; esto es, un enfoque'a priori' a travs del establecimiento de requisitos de soportabilidad.Despus, dada una configuracin de diseo seleccionada, el nfasisest en la identificacin de recursos de mantenimiento y apoyo, ascomo en el diseo de la infraestructura de apoyo del sistema.

3.2.1. El proceso de anlisis de apoyo logstico

El proceso ilustrado en la Figura 21 es inherente al LSA. A medidaque se progresa en el diseo conceptual y preliminar, el desarrolloinicial de requisitos de soportabilidad y criterios de diseo, la selecciny aplicacin de tecnologas, la evaluacin de configuracionesalternativas de diseo, etc., se hacen necesarios una serie de pasos,segn se muestra en la Figura 21. Dependiendo del problema, puedenemplearse diferentes herramientas y tcnicas, como se indica en elBloque 4. Adems, pueden utilizarse varias combinaciones de modelosinformticos para facilitar el esfuerzo analtico general. El objetivo esseleccionar los modelos apropiados, integrados mediante estacionesde trabajo para el diseo, y adaptar estas herramientas al problemaconcreto. La Figura 22 muestra el mtodo deseado as como lasinterrelaciones que pueden existir, donde los resultados de un anlisisinfluirn sobre otro. Se trata de seleccionar y emplear las herramientasadecuadas que nos permitan apoyar el proceso global de diseo delsistema de forma oportuna y efectiva.

El proceso LSA es iterativo y dispone de los elementosapropiados de realimentacin para cumplir los objetivos antesmencionados. Los resultados incluyen no solamente los pasosnecesarios para influir en el diseo en relacin con la soportabilidaddel sistema, sino tambin para proporcionar una base de datos queresulte en el registro de anlisis de apoyo logstico (Logistics Support


Fig

ura

23 e

n so

lapa

65


Analysis Record, LSAR). La Figura 23 indica algunos datos que puedenincluirse en el LSAR para un sistema a gran escala.

3.2.2. Herramientas seleccionadas y tcnicas empleadas en elproceso de anlisis de apoyo logstico

El cumplimiento de los objetivos del LSA depende, en granmedida, de la disponibilidad de las diferentes herramientas y modelosy de su grado de integracin durante el proceso de diseo. En la Figura22 se identifican algunas de estas herramientas y se muestran lasprincipales interfaces en trminos del flujo de datos. Con referencia ala Figura 24, algunas de estas herramientas han sido seleccionadaspara ser tratadas con ms detalle, con el fin de dar nfasis a laimportancia de su aplicacin en el proceso del LSA.

A) Anlisis del coste de ciclo de vida . Se ha subrayadorepetidamente la importancia de emplear mtodos de clculo del costede ciclo de vida, desde las fases iniciales de los procesos de diseodel sistema y de toma de decisiones. Teniendo en cuenta que cadamtodo individual debe ser adaptado a la necesidad especfica, laFigura 25 muestra los pasos generales a seguir en la realizacin de unanlisis del coste de ciclo de vida.

Respecto a la Figura 25, en primer lugar, hemos de definir elproblema. A la hora de evaluar las alternativas, cada uno de los mtodosviables contemplados debe ser proyectado en el contexto del ciclode vida previsto, identificando las actividades a tener en cuenta a lolargo del ciclo de vida; es decir, el paso 3. La Figura 26 muestra unadefinicin simplificada de los requisitos operativos, el concepto demantenimiento y el plan de ciclo de vida; esto, a su vez, nos proporcionala base para el desarrollo de una estructura de desglose de costes(Cost Breakdown Structure, CBS) como la mostrada la Figura 27. LaCBS representa una estructura funcional que puede emplearse enla asignacin inicial de costes (en una situacin de diseo-al-coste)

67



Fig

ura

27 e

n so

lapa

69


y en el clculo posterior de costes (en un anlisis del coste de ciclo devida). La CBS debe: (a) considerar TODOS los costes; (b) tratar loscostes desde una perspectiva funcional; y (c) desglosar los costes hastael nivel necesario para permitir la visibilidad necesaria para la evaluacinde un elemento del sistema o un proceso. Las referencias [2, 20]abarcan con la profundidad necesaria los mtodos de anlisis de costesdel ciclo de vida.

En cuanto a los pasos 6-8 de la Figura 25, en ellos se calculanlos costes de cada una de las configuraciones alternativas del diseoy se desarrollan perfiles individuales del coste de ciclo de vida, cuyosresultados se recogen en la Figura 28. La Figura 29 muestra el momentoen que la configuracin A asume una posicin de preferencia; esdecir, seis aos y medio despus de su ciclo de vida proyectado dedoce aos.

Uno de lo objetivos del anlisis de coste del ciclo de vida esmostrar con claridad las consecuencias que tendrn las decisiones dediseo y gestin en el coste total del sistema e identificar los riesgosasociados con estas decisiones lo ms pronto posible en el procesode adquisicin del sistema los riesgos asociados con estas decisiones(ver Figura 2). Uno de los objetivos del diseo para soportabilidadconsiste en minimizar los costes asociados con el mantenimiento yapoyo, es decir, los costes menos visibles en la base del iceberg dela Figura 1. En cualquier caso, el LCCA es una herramienta/un modeloimprescindible, no solamente en el proceso de ingeniera de sistemas,sino tambin en la elaboracin del LSA .

B) Asignaciones y predicciones de fiabilidad ymantenibilidad . Refirindonos a la Seccin 1.2, en las primeras fasesdel diseo del sistema se especifican los requisitos de fiabilidad ymantenibilidad a nivel del sistema y, posteriormente, se asignan a lossubsistemas y tan abajo como sea necesario.

Los valores adecuados de tiempo medio entre acciones de

71


mantenimiento (MTBF, MTBM, R, l, Mct, Mpt, M, MLH/OH, etc.),proporcionan una base para la determinacin de factores defrecuencia de mantenimiento anticipado, y recursos de apoyo logsticocomo parte del LSA. Adems, la elaboracin de los anlisis de costedel ciclo de vida depende en gran parte de estos factores. A medidaque el sistema evoluciona, se desarrollan modelos de fiabilidad ymantenibilidad, y se realizan previsiones a partir de una evaluacinde la configuracin del diseo tal y como se concibe en ese momento.Estas previsiones se realizan de forma peridica y los resultados seutilizan en el LSA. La cuestin de fiabilidad y mantenibilidad se estudiams detalladamente en las monografas octava, novena y dcima deesta serie [10, 12, 28].

C) Anlisis de modos de fallos, sus efectos y su criticidad .(Failure Modes, Effects and Criticality Analysis, FMECA). El FMECAse emplea a lo largo del proceso de diseo para ayudar a determinarlos posibles modos de fallos que el sistema puede experimentar durantesu utilizacin, sus frecuencias previstas, las causas, las consecuencias


o los efectos de los fallos en otros elementos del sistema y su criticidaden trminos de un efecto posible sobre la capacidad del sistema pararealizar su misin.

La Figura 30 muestra la manera general de enfocar el FMECA.La Figura 31 ilustra las relaciones entre un FMECA de procesos yun FMECA de productos. En el ejemplo, una junta de automvil esfabricada mediante un proceso y se plantea la cuestin qu ocurresi falla el proceso de estampado?, qu impacto tendr en los otrosprocesos como el del acabado y en el coche en general? La Figura32 muestra una aplicacin de un diagrama Ishikawa que facilita laidentificacin de las principales relaciones de causa y efecto.

El FMECA es una de las herramientas ms tiles en el diseo,ya que tiene varios usos. Se emplea conjuntamente con el anlisis delrbol de fallos (Failure Tree Analysis, FTA) en la elaboracin de losanlisis de fiabilidad [10]. Es necesario para los anlisis demantenimiento con el fin de facilitar las tareas de identificacin de lasreas crticas, en las que se han de realizar trabajos de mantenimientopara evitar grandes catstrofes; as mismo, sirve como datos de entradatanto para el anlisis de tareas de mantenimiento (MTA) como para elanlisis del mantenimiento centrado en la fiabilidad (RCM) [11, 12].Puede emplearse conjuntamente en el desarrollo de un anlisis deriesgos (Hazard Analysis, HA) y en la determinacin de los requisitosde seguridad del sistema, tanto desde una perspectiva operativa comode mantenimiento [13]. Cada una de las aplicaciones conduce aldesarrollo del LSA.

D) Anlisis de rboles de fallos (Failure Tree Analysis, FTA).El FTA es un mtodo deductivo que incluye la enumeracin grfica y elanlisis de diferentes modos en los que puede presentarse un fallo delsistema, as como de su probabilidad de ocurrencia. La Figura 33 ilustraun FTA tpico, referente a un sistema de ascensor de un edificio. Debeespecificarse un evento de alto nivel (por ejemplo, "dao a pasajeros").Adems, ese evento debe poder ser claramente observable, definibley mensurable en forma no ambigua. A partir de este evento se desarrolla

75



Fig

ura

33 e

n so

lapa

una jerarqua causal de arriba-abajo con sus probabilidades asociadas.Debe desarrollarse un FTA por separado para cada modo crtico defallo o evento de alto nivel no deseado [11].

La Figura 34 muestra una comparacin simplificada entre elFMECA y el FTA. El FMECA es ms completo, est orientado al diseoilustrando relaciones "causa-efecto", y es preferido cuando se trata deconocer ms sobre el comportamiento de un sistema y suscomponentes y de los riesgos asociados a no cumplir requisitosespecificados. Mientras que el FMECA es ms completo en trminosde evaluacin de diseo, los requisitos de entrada de datos puedenser ms amplios. Por otro lado, el FTA utiliza mtodos booleanos alanalizar diferentes caminos de fallos, y resulta preferido para grandessistemas, con elevada presencia de software, donde hay muchasinterfaces. En cualquier caso, el FMECA y el FTA puedencomplementarse mutuamente.

E) Anlisis de Tareas de Mantenimiento . Suele realizarsedurante las fases del diseo preliminar y de detalle, cuando se hasupuesto una configuracin determinada y se quiere evaluarla entrminos de: (a) sus caractersticas inherentes de soportabilidad; y (b)los recursos de apoyo logstico necesarios para el mantenimientocontinuado y apoyo de dicha configuracin a largo plazo, es decir,recambios y repuestos, equipos de prueba, cantidades de personal yespecializacin, instalaciones, etc.

Para ilustrar este punto, el organigrama de la Figura 35 describeuna capacidad de fabricacin que se ha supuesto como la configuracindel sistema que estamos evaluando. Mediante la realizacin de unanlisis del coste del ciclo de vida, se ha determinado que la funcinde prueba de fabricacin, representada por el bloque 13, es uncontribuidor de alto coste. Esto se debe principalmente almantenimiento correctivo que se requiere con frecuencia para manteneroperativa la capacidad final de prueba. Se trata de determinar algunasde las causas de este elevado coste, y el anlisiss de tareas de

77

mantenimiento se elabora para identificar las reas de preocupacin.La Figura 36 muestra un organigrama simplificado (derivado del anlisisfuncional descrito en la Seccin 3.1.4) que identifica las tareas demantenimiento realizadas con mayor frecuencia. Estas tareas seidentifican a continuacin en la Figura 37 (partes 1 y 2), donde seespecifican los recursos de apoyo logstico previstos. Revisando lapresentacin de datos en la Figura 37, podemos identificar una seriede reas que admiten modificaciones del diseo para mejorar susoportabilidad. Por ejemplo, se podra redisear la configuracin paraeliminar la necesidad de personal supervisor muy especializado yeliminar la necesidad de utilizar una instalacin limpia para la reparacinde montaje A7.

El MTA suele realizarse durante las fases de diseo preliminary de detalle como actividad de mantenimiento, y como parteinherente del LSA [2, 11, 1