Architecture applied in Turnaround IT

Scandinavian Airlines

Magnus RosénOctober 2005

2

Angreppssätt avseende IT-frågor

1. Säkerställa att IT inte blir ett hinder för ny organisation

Behov av justeringar av IT-system för att säkra driften i ny organisation (t.ex. tre lokala baser)

Undvika att existerande IT-system förhindrar en halvering av bemanningsnivån

2. Reducera kostnader och bidra till att ”stänga gapet”

Strukturella förändringar• Migrera till

moderna, enklare system

• Stäng ned system som inte behövs givet en lägre ambitionsnivå

IT

Angreppssätt

Ompröva ITs rolli verksamheten

3

Methods and Approach

• Within the domains, the complexity is carved-out and managed through consolidation, or complete technology transformation, such as replacing the systems with a standard package

• Interfaces to external systems are carefully described, and encapsulted

• Driven as separate projects; New Production Planning System,Future Distribution IT Platform, and JAR-OPS1

Domains:Structu-ral changes

Day-to-dayRationali-zations

• Rethinking existing practices; look for simplifications, avoid cost redundancies, etc

• Proven to be effective; much has already been achieved in e.g. IT Cost Restructuring

• Executed throughout the whole IS/IT function

Design to Cost: ”Deliver as much functionality as possible, to a capped unit cost”

4

Methods and Approach1. Define the boundaries of the domain

- Delineate the boundaries of the domain to include a complete business function or process (e.g. Production Planning)- Today’s IS/IT support within the domain may have tight and complex systems interfaces; however, the domain should have few, well-defined, and non-real time interfaces to systems outside the domain- Specify the total IT cost of today’s IS/IT support for the domain

2. Solution Screening- Define SAS’ core requirements; eliminate optional and nice-to-have requirements- Identify suppliers of standardized systems to deliver full functional coverage of functionalities within the domain- Revise the scope of the domain, to fit the scale of the standard packages- Obtain price indications from suppliers, and compare with today’s IS/IT costs- Complete an RFI; evaluate the replies; vendor shortlisting

3. RFP- Elaborate on the RFI and the suppliers responses to the RFI to produce requirements for the RFP- Evaluate and short-list the suppliers

4. In-depth vendor analysis and Business Case analysis- Through a high degree of business end-user involvement, complete benchmark tests and functional tests of the final 2-3 eligible suppliers- Analyze the consequences for the business of systems replacements, and specify in which areas the business needs to accommodate its practices to fit the standard functionalities of the systems; outline a plan for migration and systems cut-over - Produce a Business Case

5. Sign agreement and initiate the supplier’s implementation activities

5

Buy vs. build – Key differences

Buy an application package Build in-house

• External “best practice”, well-documented business processes

• Gap analysis (what really would pay off to change)

• Low degree of granularity in functionality decisions (package level)

• Large training and change management effort

• Potentially new skills needed– Vendor selection and RFP process– Customizations– Business cases– New technologies

• Risks of poor commitment in the business community

• Best for “core” platforms, e.g., ERP

• System is developed to fit existing processes that may be poorly described/understood, but familiar to everyone and sometimed incrementally improved

• Functional specification (what would we like to have)

• High degree of granularity in descriptions of functionality for requirements specifications

• Minimized change effort

• Done it a hundred times

• Relatively high project risks in development

• Best when building limited functionality on top of existing systems

6

Potential approach for domain-based IT architecture rationalization

• Limit complexity by introducing a domain structure (separable entities with clear interfaces

• Use current technical landscape as the starting point (instead of clean sheet) to limit interdependencies in next phases

Establish domain structure based on current IT landscape

Rationalize each domain

• Apply value levers for each domain– Remove of applications

by simplifying business processes

– Replace legacy systems with more cost-efficient packaged applications

– Off-shore business process or its IT support

– Reduce infrastructure cost by service scope reduction

• Create a target picture for each domain

Create a roadmap for towards target business domain structure

• Create an application roadmap for each domain– Phasing out applications– Introducing common

solutions– Other major system

changes• Create a domain roadmap

to migrate gradually the current domain structure towards a target business-driven domain structure that follows closely the target domain structure

• Adjust IT management roles and responsibilities to reflect domain structure (domain owners and budgets)

7

”Carving out” of Production Planning Systems

• As of August 2003, Scandinavian Airlines is organized in three separate operational bases

• Each base is an autonomous entity and the complete Production Planning Process should be able to be performed at each base, both commercially and operationally

• Slot management is to be coordinated centrally as well as locally

• Access to data, both of operational and historic data, should be integrated across all functions within Production Planning

8

Production Planning is a critical part of the core business process of Scandinavian Airlines…

Flexibilty /free scope

of action

Strategical alignment

RealizationDimensioning Production

Planning

Object Establish Scandinavian Airlines strategic alignment based on market, competition, unit cost (productivity) etc• Market, customer segment,

product• A/C-types• Partner/alliances• Crew productivity• Unit cost• Etc.

Optimize the use of available production resources by means of adjusting the schedule to changes in commercial and technical/operational demand.

Effectuate the Traffic Program given the following objectives:•Safety•Regularity/Punctuality•Profitability.

Based on agreed strategy, decide on dimensioning of resources:• Service Level

Agreements• Aircraft (types,

numbers etc)• Flight-deck and

Cabin crew (qualifications, numbers etc).

• SAS Group Strategy

• Mission & vision

• HR, IT etc.

Included in this tender

9

Applications in the production planning domain

Aircrafts

Crew

Capacityplanning

Traffic programscheduling

Productionrealization

Follow-up and prognosis

PCAirflight TDB Opus & topstWhich system, which domain

Which system, which domain

Non standard, real-timeNon standard, file

Standard, real-timeStandard, file

10

Data flow analysis – Scope and activities

Describe the information exchange for each system to system dependency:

• Identity: name, sender, destination(s)• Type: direct real-time, messaging, batch (file transfer), database view/read/update,

(SITA) telex, web services, etc

• Protocols/technical platform: TCP/IP, HTTP(s), IIOP, FTP, MQ, ICM, “Distributören”, SITA/MESCO, etc

• Message standard/format: IATA, XML, EDI, etc

• Periodicity: scheduling, monthly, weekly, daily, recurrance

• Error handling: resend, sessions, ack/nack, once-only-delivery, guaranteed delivery

Activities:• Meetings with system responsible resources

11

TDB OPUS TOPSTPCAirFlite

APM/FAM Rave

CISPAC TAPCAS

TAP AI

Departure ControlDomain

Sales &Distribution

Domain

Inventory Control & Revenue Optimization

Domain

FIA

TRAF(actual)

FIDOIRIS

(actual)

CPHES

IRIS(budget)

TRAF(budget)

TP

BUS

SATS

Interfaces to other Domains

Crew

Budget

Aircraft

Production Planning Process

Aircraft, Crew, Budget and Follow-Up Processes (Simplified Major Information Flow)

Follow Up

12

PC AirFlitePC AirFlite

TDBTDB

TTTT

OPUSOPUS

CIS CIS

CRU80CRU80

IRISIRIS

PACPAC TAP-AITAP-AICASCAS

FIDOFIDO TRAFTRAF

TOPST2000TOPST2000

TOPSTTOPST

OPUS2000OPUS2000

FDAFDA

FIAFIA

APM-FAMAPM-FAM

TPTP

STMSTM

PepsiPepsi

APSMAPSM

CrewNetCrewNet

RAVERAVE

IRSIRS

HERMESHERMES

SASVACSASVAC

TASIR/SIRITASIR/SIRI

Day Dynamic/TQS

Day Dynamic/TQS Crew

Overtime

Crew ServicesCrew Services

CSMCSM

ATM per diem

ResponseCharts

ResponseCharts

TPTSTPTS

FLOWFLOWSAS InstituteSAS Institute

PBSPBS

FQMFQM

DSSDSS

SabreSlotmanager

SabreSlotmanager

Inventory Control & Revenue Optimization

Domain

Sales & Distribution Domain

GroundHandlingDomain

HRDomain

Technical Maintenance

Domain

CMS CMS TAPTAP

Flight Support Domain

InflightServicesDomain

HL domain description – production planning

13

Production Planning IS/IT Support

Aircraft

Crew

OpsControl

Interfaces to External Domains

Strategy/Dimensioning

Execution Follow Up/Reporting

Planning

ExecutionFinal Planning

Timeline

ProcessStageProcess

BlocksFleet

Planning

Operation Control

Crew Legality

Crew Assignment

Crew Pairing

Crew Tracking

Repetitive Flightplan

Slot ManagementNetwork Optimization

Fleet OptimizationCharter

ManagementFinancial Analysis

Pairing OptimizationCrew Simulator Planning

Manpower Planning

Crew web interface

Crew Request

Automated Rostering

Crew Vacation Planning

Aircraft Maintenance

allocation OpsSolver

Weather Data

Communication Module

Production Follow-Up/Control

Crew Payroll Data

Automated Crew Booking

Crew Check-In Module

Crew Solver

Production Follow-Up/ Control

Aircraft Maintenance

Crew Web Portal Human ResourcesMarket Intelligence

Crew DB

Core Requirements Functional Extensions External InterfacesLegend:

Capacity Adjustment

Maintenance Control Maintenance Follow Up

Aircraft Maintenance

Aircraft Maintenance

ATC FlightPlan

ReservtionDistribution

Niceties

AircraftScheduling

Slot Monitoring

14

Target Architecture

15

Sammanfattning

• Resultat: Reviderad systemarkitektur, under implementation 2005 2007 – inte fullständigt integrerad

• Betydande kostnadsbesparingar (ca 50 %)

• Arkitektens roll:– Analys och modellering– Diskussion med verksamhetsrepresentanter om krav, utformning av målsystem, etc.– Medverka i utformning av RFI och RFP– Utvärdera och prioritera alternativa lösningar tillsammans med verksamheten– Tests och benchmarks– Business case-analys samt rekommendation, tillsammans med verksamheten