Architecture applied in Turnaround IT

1. Architecture applied in Turnaround IT Scandinavian Airlines Magnus Rosén October 2005

2. Angreppssätt avseende IT-frågor Angreppssätt Undvika att existerande IT-system förhindrar en halvering av bemanningsnivån 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) IT Ompröva ITs rolli verksamheten 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å

3. Domains: • Structu-ral changes • Day-to-day • Rationali-zations Methods and Approach Design to Cost: ”Deliver as much functionality as possible, to a capped unit cost” • Within the domains, the complexityis 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 • 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

4. Methods and Approach • 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 • 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 • RFP-Elaborate on the RFI and the suppliers responses to the RFI to produce requirements for the RFP- Evaluate and short-list the suppliers • 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 • 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. Establish domain structure based on current IT landscape • Rationalize each domain • Create a roadmap for towards target business domain structure 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 • 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 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… Included in this tender • Flexibilty /free scope of action • SAS Group Strategy • Mission & vision • HR, IT etc. • Dimensioning • Strategical alignment • Production Planning • Realization • 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. • Based on agreed strategy, decide on dimensioning of resources: • Service Level Agreements • Aircraft (types, numbers etc) • Flight-deck and Cabin crew (qualifications, numbers 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.

9. Capacity • planning • Traffic program • scheduling • Production • realization Applications in the production planning domain • Non standard, real-time • Non standard, file • Standard, real-time • Standard, file Which system, which domain PCAirflight TDB Opus & topst Which system, which domain • Aircrafts • Crew • Follow-up and prognosis

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. CPHES SATS FIDO TRAF (actual) IRIS (actual) BUS TP TRAF (budget) IRIS (budget) Production Planning Process Aircraft, Crew, Budget and Follow-Up Processes (Simplified Major Information Flow) Aircraft PCAirFlite TDB OPUS TOPST APM/FAM Rave Crew PAC CAS TAP CIS Follow Up TAP AI Budget FIA Interfaces to other Domains Sales & Distribution Domain Inventory Control & Revenue Optimization Domain Departure Control Domain

12. HL domain description – production planning Inventory Control & Revenue Optimization Domain RAVE SASVAC PAC CAS TAP-AI TAP CMS FDA PBS Sabre Slotmanager APSM IRS CIS ATM per diem STM PC AirFlite CRU80 TDB OPUS TOPST HR Domain APM-FAM TPTS TT OPUS2000 TOPST2000 Day Dynamic /TQS SAS Institute Crew Overtime DSS FLOW TASIR/SIRI Crew Services FIA FIDO TRAF CrewNet Pepsi TP IRIS Response Charts CSM Sales & Distribution Domain Ground Handling Domain Technical Maintenance Domain Flight Support Domain Inflight Services Domain FQM HERMES

13. Production Planning IS/IT Support Timeline Process Stage Strategy/ Dimensioning Planning Execution Follow Up/ Reporting Process Blocks Final Planning Execution FleetPlanning Aircraft Scheduling Aircraft Maintenance Control Maintenance Follow Up Repetitive Flightplan Capacity Adjustment Slot Management Network Optimization Charter Management Fleet Optimization Financial Analysis Crew Legality Crew Crew Pairing Crew DB Crew web interface Crew Check-In Module Crew Assignment Automated Crew Booking Crew Tracking Crew Payroll Data Crew Simulator Planning Pairing Optimization Crew Solver Crew Vacation Planning Automated Rostering Production Follow-Up/ Control Manpower Planning Crew Request Operation Control OpsControl Production Follow-Up/Control ATC FlightPlan Weather Data Communication Module Aircraft Maintenance allocation Slot Monitoring OpsSolver Interfaces to External Domains Market Intelligence ReservtionDistribution Aircraft Maintenance Crew Web Portal Human Resources Aircraft Maintenance Aircraft Maintenance Legend: Core Requirements Functional Extensions Niceties External Interfaces

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