A service systems engineering framework with application to pbl rev.5

A Service Systems Engineering Framework with Application to

Performance Based Logistics

IEEE ISSE 2015 – Rome, October 30 Special Session – Research at INCOSE Italy

The transition to “Service Economy”

2 A Service Systems Engineering Framework with Application to Performance Based Logistics – M. Filippi, A. D’Ambrogio, M. Lisi

Some references about Services… Some structured concepts about Service Engineering can be found in ISO

15288. Service Engineering was developed starting from the needs of IT world with

references such as: • ISO 20000 (standard) • ITIL (framework)

The evolution of the frameworks relevant to Service Systems Engineering has its fulfillment in the CMMI for Services.

For specific applications (Support Services for Defence Systems) the main reference documents are: • DoDI 5000.01 (USA DoD) • DoDI 5000.02 (USA DoD)

3

A service can be defined as an intangible and non-storable end product obtained by the transformation of base (primary) goods and services with the final scope to provide added value.

Primary goods and services may be structured, organized and re-engineered to define, design, deliver, measure and correct value-added services.

A Service Systems Engineering Framework with Application to Performance Based Logistics – M. Filippi, A. D’Ambrogio, M. Lisi

4

SEH: “Systems Engineering integrates all the disciplines and specialty groups into a team effort forming a structured development process that proceeds from concept to production to operation. Systems Engineering considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs”.

SEBoK: “Systems Engineering (SE) is an interdisciplinary approach and means to enable the realization of successful systems. It focuses on holistically and concurrently understanding stakeholder needs; exploring opportunities; documenting requirements; and synthesizing, verifying, validating, and evolving solutions while considering the complete problem, from system concept exploration through system disposal”.

ISO 15288 derives from MIL-STD-499A (today it’s managed by ISO/IEC JTC1/SC7). “The processes in this International Standard form a comprehensive set from which an organization can construct System life cycle models appropriate to its products and Services. An organization, depending on its purpose, can select and apply an appropriate subset to fulfil that purpose”. “A System may be considered as a product or as the Services it provides”.

ISO 15288 System Engineering: Systems Lifecylce Processes

SE Handbook e SEBoK Systems Engineering HDBK e Body of Knowledge


DODI 5000.01 Defence Acquisition System (DAS)

The Defence Acquisition System (DAS) is used by USA DoD to procure Weapon and Intelligence Systems.

The DAS focuses mainly on two directives: DOD 5000.01 – Defence Acquisition System; DOD 5000.02 – Operation of the Defence Acquisition System.

In the Defence Markets, the acquisition of defence and weapon systems is facing, in the last decades, a continuous budget contraction for both the acquisition and the support of the delivered systems.

The main scope of support services, as an instance of Service Systems Engineering (SSE), is to define, deliver and asses the proper blend of services to ensure optimal system performance at an affordable life cycle cost.

5

The primary objective of Defense acquisition is to acquire quality products that satisfy user needs with measurable improvements to mission capability and operational support, in a timely manner, and at a fair and reasonable price [DoDI 5000.01].


DODI 5000.01 Defence Acquisition System (DAS) DEFINITIONS in DoDI 5000.01 – DAS

[Performance-Based Logistics]: PMs shall develop and implement performance-based logistics strategies that optimize total system availability while minimizing cost and logistics footprint. Trade-off decisions involving cost, useful service, and effectiveness shall consider corrosion prevention and mitigation. Sustainment strategies shall include the best use of public and private sector capabilities through government/industry partnering initiatives, in accordance with statutory requirements.

[Systems Engineering]: Acquisition programs shall be managed through the application of a systems engineering approach that optimizes total system performance and minimizes total ownership costs. A modular, open-systems approach shall be employed, where feasible.

[Total Systems Approach]: The PM shall be the single point of accountability for accomplishing program objectives for total life-cycle systems management, including sustainment. The PM shall apply human systems integration to optimize total system performance (hardware, software, and human), operational effectiveness, and suitability, survivability, safety, and affordability. PMs shall consider supportability, life cycle costs, performance, and schedule comparable in making program decisions. Planning for Operation and Support and the estimation of total ownership costs shall begin as early as possible. Supportability, a key component of performance, shall be considered throughout the system life cycle.


Types of Services

7

System as a Service (i.e. “cloud” services) Service through the System (i.e.

commodities) Support Services:

PBL – Performance Based Logistics CBL – Capability Based Logistics

We consider only Engineered Systems for the delivery of Services (through the Systems or for the Systems).

PBL-type Support Services need the existence of a Primary System (for which Operation shall be ensured) and a Support Systems (to deliver the Support Services).

The scope of the PBL-type Support Services is to meet maximum Operational Availability (AO) of the Primary System with a minimum Life-Cycle-Cost (LCC).

FOCUS


SUPPORTSYSTEM

PRIMARYSYSTEM

(SoI)

OPERATIVE SYSTEM

LCC – Main Elements

8

Attributes of cost elements Type of product (Service or

Sistem); Nature (RE, NRE); Underpinning contract type for

Services (i.e. Flat Rate, On-Demand).

Abbr. Description of Cost Phase Type of Product Type o Cost PBL TL

AC Acquisition Cost ACQ System + Service NRE+ RE In ACQ Cost In ACQ Cost

SOC System Operating Cost O&M Service RE CBC CBC

DC Disribution Cost ACQ + O&M Service NRE+ RE On-Demand

MC Maintenance Cost ACQ + O&M Service NRE+ RE On-Demand

CRC Computer Resource Cost ACQ + O&M Service NRE+ RE On-Demand (PA)

SSC Supply Support Cost ACQ + O&M Service NRE+ RE On-Demand (PA)

T&SEC Test & Support Equipment Cost ACQ + O&M Service NRE+ RE On-Demand (PA)

TC Training Cost ACQ + O&M Service NRE+ RE On-Demand

TDC Tecnical Data Cost ACQ + O&M Service NRE+ RE On-Demand (PA)

R&DRC Retiring&Disposal/Recycling Costs ACQ + DISPOSAL System + Service NRE+ RE Flat Rate + Opportunity On-Demand

PBL Performance Based LogisticsTL Traditional Logistics

NRE Non Recurring EffortRE Recurring Effort

O&M Operation & MaintenancePA Partially Applicable

CBC Case By Case

Flat Rate

Legenda

Main LCC elements (all Life Cycle phases)


SE footprint on O&M phases SE has very limited footprint on operation and maintenance (O&M) phases, in

which the system shall provide its functions as expected by end users and customers for long time-periods @ an affordable cost.

ILS is the discipline meant to design, develop and maintain Systems “up & running” with minimum effort

The main “drivers” for O&M costs are R&MT requirements, too often considered as logistic/support requirements (TPMs) instead of Measures of Performance (MOPs).

In order to meet maximum System Performance (i.e. Operational Availability) at the minimum LCC, a proper PBL approach (as per DoDI 5000.01) shall be defined and implemented.

PBL shall define and allocate the resources (skills, tools, materials) in order to maximise the Ao


Details on the AO model

TOTALtime

UPtimeDOWNtimeUPtime

UPtimeA =+

= Basic Definition

MTTRSMTBCFMTBCFAi +

=

MMTBMMTBMAa +

=

MDTMTBMMTBMAo +

=

Inherent Availability (Corrective Maintenance)

Achieved Availability (Preventive & Corrective Maintenance)

Operational Availability (Preventive & Corrective Maintenance + Logistic Delays)

oai AAA >>

DTMMDT +=MTBPMTBCF

MTBM 111

+=

MTBPMTBCF

MTBPMTTP

MTBCFMTTRS

M 11+

+=

MODEL


A model for Operational Availability

11

Availability

Inherent Availability takes into account only corrective maintenance downtimes (Ai);

Achieved Availability (Aa) adds scheduled maintenance downtimes to Ai;

Both Ai and Aa consider the logistic resources (skills, materials, tools) IMMEDIATELY available (0 delay)

Operational Availability (AO) takes into account the delays introduced by the Support Environment;

All the Availability figures shall be calculated at System Level and have the meaning of a PROBABILITY.

AO depends both by the System and the Support System!!!

AO encompasses any design and support aspects and provides a unique indicator of the capability of a system to deliver its functions/mission when required, at any random time: AO = SYSTEM-SERVICE combined MOE


Sample model for the Delay Time – DT (Two Echelons Support Chain)

DT

D’ D’’

HL1/2 failures HL3/4 failures

PS

Site MaintainerIntervention

SP Maintainer Intervention

SiteMSDT

SiteMTIT

SiteMSDT

SPMaint. Interv. Delay Time

1-PS

Site MaintainerIntervention


StockOut

DelayTime

SiteMTIT

SPMaint. Interv. Delay Time

StockOut

DelayTime


SPDelay Time

StockOut

DelayTime

Max

Max

Spare on site Spare not on site

12

Most of the DT parameters depend on: Who does what (Maintenance

Concept) Where activities are performed How much resources are

available Where resources are located How resilient is the Support

Chain


Costs associated to the resources MATERIALS

Preparation • Repairable items stock

Definition • Not Repairable items stock

Definition • Limited Life Items defintion • Consumables Definition • Not-MSI definition

Maintenance • Repairs • Procurement • Components Replenishment

Long Term Support

• Last buy/Bridge Buy

• Redesign

• Upgrade

SKILLS

Preparation • Contractor Training • TNA/GAP Analysis • End User Training

Maintenance • Contractor Know-how • End User Refresh Training • Personnel turn-over

management • Interventions on Systems

Long Term Support

• Loss of skills management

• Professional skill management

TOOLS & EXTERNAL SERVICES

Preparation • ERP/PDM/ICT (Business) • CTTE/STTE (System) • CRM/LRAP (Services)

Maintenance • Licences • Calibrations (CTTE/STTE) • Facilities • Subcontracts

Long Term Support

• Updating (ALL)

• Upgrading (LRAP)

• Migrations (ALL)

Preparation and Long Term Support costs are mainly NRE, Maintenance costs are mainly RE


…mainly ACQ phase… …mainly O&M phases…

Verification of the AO/DT Model

The AO and DT models can be VERIFIED with analytical methods before field-validation can occur: R&MT data are often predicted, sometimes verified with in-house

tests (i.e. Accelerated Life Testing, Shake and Bake, Burn-in, failures inductions) but the test environment cannot be comparable to real conditions;

Logistic Support Delays (DTs) require the definition of the Support Chain (echelons, distribution, allocated resources and their physical location etc.);

The SIMULATED use of resources can be activated by random generation of failures (the “demand” for support) varying the scenarios and the available resources and recording the DTs and costs.

The obtained values for DT and AO can be analysed vs costs to fine tune the resources allocation and the model itself.


Continuous Validation of AO/DT Model (1 of 2) Support Services in the O&M phases are continuous (even if the System is not!)

CMMI SVC details, for a defined Service (Lev. 3), the essential processes to be implemented (from Lev. 2):

15

Strategic Service Management (STSM) Capacity & Availability Management (CAM) Incident Resolution & Prevention (IRP) Service System Transition (SST) Service Continuity (SCON) Service System Development (SSD)

Service Portfolio

Resources Availability

Management and Incident Prevention

Service Deployment

«Disaster» recovery

Analysis, Design, Development, Integration, V&V of Service(s) and

Service System(s)


Continuous Validation of AO/DT Model (2 of 2) In order to continuously validate the AO/DT model, many lower level

indicators are defined (KPIs) and shall be assessed The values of the KPIs, the penalties, the methods to measure them, the

tool, processes and procedure are included in a comprehensive document generally referred as Service Plan (SP) that: Defines the System of Interest (SoI) for which Support Services are

delivered Defines the engagement rules & procedures between the Service

Provider and the Customer/End User (i.e. LOV Charts) Details the mutual responsibilities (i.e. RACI Matrices) Defines the tools to track all the Service Request and measure the KPIs

(i.e. LRAP tools, CRMs, HelpDesk etc.) Includes a comprehensive the Service Level Agreement (SLA)

In synthesis, the SP is for the Support Services similar to the SEMP for System Engineering…


Service Plan «essentials»…

ID

Activ

ity

Site

N

SPA

Sele

x ES

[D

R.0

1]

Cre

ate

SR

R

I

I

[DR

.02]

A

naly

sis

I I

R

[DR

.03]

U

pdat

e D

ocum

enta

tion

- I

R/A

[DR

.04]

D

eliv

er D

ocum

enta

tion

to H

Ns

I R

I

[DR

.05]

C

lose

WO

I

I R

[DR

.06]

C

lose

SR

R

I

I

Sam

ple

of S

R d

escr

ibed

th

rou

gh

LOV

Ch

art

& R

AC

I M

atri

x.

En

gage

men

t (S

ervi

ce R

equ

est)

th

rou

gh L

RA

P to

ol


DTs AO «SoI» status

Service Provider/End User/Customer Interactions

Thank YOU

QUESTIONS ?


A service systems engineering framework with application to pbl rev.5

Technology

Transcript of A service systems engineering framework with application to pbl rev.5