Get documents about "Architecture and Turnaround IT
Shared by: HC120727132834
-
Stats
- views:
- 0
- posted:
- 7/27/2012
- language:
- pages:
- 15
Document Sample
Architecture applied in Turnaround IT
Scandinavian Airlines
Magnus Rosén
October 2005
Angreppssätt avseende IT-frågor
Angreppssätt
Undvika att
existerande IT-
system förhindrar en
1. Säkerställa att IT halvering av
inte blir ett hinder bemanningsnivån
för ny organisation
Behov av justeringar
av IT-system för att
IT säkra driften i ny
organisation (t.ex. tre Ompröva ITs roll
lokala baser)
i verksamheten
2. Reducera
kostnader och bidra
till att ”stänga Strukturella
gapet” förändringar
• Migrera till
moderna, enklare
system
• Stäng ned system
som inte behövs
givet en lägre
ambitionsnivå
1
Methods and Approach
Design to Cost: ”Deliver as much functionality as possible, to a capped unit cost”
• Within the domains, the complexity is carved-out and managed
through consolidation, or complete technology transformation, such
Domains: as replacing the systems with a standard package
Structu- • Interfaces to external systems are carefully described, and
ral changes encapsulted
• Driven as separate projects; New Production Planning System,
Future Distribution IT Platform, and JAR-OPS1
• Rethinking existing practices; look for simplifications, avoid cost
Day-to-day redundancies, etc
Rationali- • Proven to be effective; much has already been achieved in e.g. IT
zations Cost Restructuring
• Executed throughout the whole IS/IT function
2
Methods and Approach
1. 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
3
Buy vs. build – Key differences
Buy an application package Build in-house
• External “best practice”, well-documented • System is developed to fit existing processes
business processes that may be poorly described/understood, but
familiar to everyone and sometimed
• Gap analysis (what really would pay off to incrementally improved
change)
• Functional specification (what would we like to
• Low degree of granularity in functionality have)
decisions (package level)
• High degree of granularity in descriptions of
• Large training and change management effort functionality for requirements specifications
• Potentially new skills needed • Minimized change effort
– Vendor selection and RFP process
– Customizations • Done it a hundred times
– Business cases
– New technologies
• Risks of poor commitment in the business
community • Relatively high project risks in development
• Best for “core” platforms, e.g., ERP
• Best when building limited functionality on top
of existing systems
4
Potential approach for domain-based IT architecture
rationalization
Create a roadmap for
Establish domain
Rationalize each towards target
structure based on
domain business domain
current IT landscape
structure
• Limit complexity by • Apply value levers for each • Create an application
introducing a domain domain roadmap for each domain
structure (separable – Remove of applications by – Phasing out applications
entities with clear simplifying business – Introducing common
interfaces processes solutions
• Use current technical – Replace legacy systems – Other major system
landscape as the starting with more cost-efficient changes
point (instead of clean packaged applications • Create a domain roadmap
sheet) to limit – Off-shore business to migrate gradually the
interdependencies in next process or its IT support current domain structure
phases – Reduce infrastructure cost towards a target business-
by service scope driven domain structure that
reduction follows closely the target
• Create a target picture for domain structure
each domain • Adjust IT management roles
and responsibilities to reflect
domain structure (domain
owners and budgets)
5
”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
6
Production Planning is a critical part of the core
business process of Scandinavian Airlines…
Included in this tender
• SAS Group
Flexibilty Strategy Strategical Dimensioning Production
/free scope • Mission & Realization
alignment Planning
of action vision
• HR, IT etc.
Object Establish Scandinavian Airlines Based on agreed Optimize the use of Effectuate the
strategic alignment based on strategy, decide on available production Traffic Program
market, competition, unit cost dimensioning of resources by means of given the
(productivity) etc resources: adjusting the schedule to following
• Market, customer segment, • Service Level changes in commercial and objectives:
product Agreements technical/operational •Safety
• A/C-types • Aircraft (types, demand. •Regularity/Punct
• Partner/alliances numbers etc) uality
• Crew productivity • Flight-deck and •Profitability.
• Unit cost Cabin crew
• Etc. (qualifications,
numbers etc).
7
Applications in the production planning domainNon standard, real-time
Non standard, file
Which system,
which domain Standard, real-time
Standard, file
Capacity Traffic program Production
planning scheduling realization
Aircrafts
Which system,
PCAirflight TDB Opus & topst
which domain
Crew
Follow-up and prognosis
8
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
9
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
CPHES
SATS
TRAF IRIS
Budget BUS FIDO
(actual) (actual)
TRAF IRIS
TP
(budget) (budget)
FIA
Interfaces to
other Domains Sales & Inventory Control & Departure
Distribution Revenue Optimization Control
Domain Domain Domain
10
HL domain description – production planning
Inventory Control &
Revenue Optimization RAVE
Domain SASVAC
PAC CAS TAP-AI TAP CMS FDA
PBS
Sabre
APSM
Slotmanager IRS CIS ATM
per diem
STM
PC AirFlite
CRU80
TDB OPUS TOPST
HR
APM-FAM
Domain
TT TPTS
Day Dynamic
SAS Institute OPUS2000 TOPST2000
/TQS Crew
DSS FLOW Overtime
TASIR/SIRI
Crew Services
FIA FIDO TRAF Pepsi CrewNet
Response
TP IRIS Charts
CSM
Ground Technical Flight Inflight
Sales & Distribution FQM
Handling Maintenance Support Services
Domain
Domain Domain Domain Domain
HERMES
11
Timeline
Process Strategy/ Planning Execution Follow Up/
Process Stage Dimensioning Reporting
Blocks Final Planning Execution
Fleet Aircraft Maintenance Control Maintenance Follow Up
Aircraft Planning Scheduling
Repetitive Flightplan Capacity Adjustment
Slot Management
Network Optimization
Charter Management
Fleet Optimization
Financial Analysis
Crew Legality
Crew Pairing Crew DB Crew web interface Crew Check-In
Crew Module
Crew Assignment Automated Crew Crew Tracking
Booking 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 Production Follow-
OpsControl ATC FlightPlan Up/Control
Weather Data
Communication
Module
Aircraft Slot Monitoring
Maintenance
allocation OpsSolver
Interfaces to Market Intelligence ReservtionDistribution Aircraft Crew Web Portal Human Resources
Maintenance
External Aircraft Aircraft
Maintenance Maintenance
Domains
Legend: Core Requirements Functional Extensions
12 Niceties External Interfaces
Target Architecture
13
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
14
