SE Process Development in an Organisation in Change - FINSE

SE Process Development in an
Organisation in Change
Thoughts and experiences from the on-going work
at the Swedish Defence Materiel Administration!
Tomas Huldt
Syntell AB
Jan Ericsson
Swedish Defence Materiel Administration

“There is no sense in being exact about
something if you don’t even know what
you are talking about”
(John von Newman, 1950)

This is what SE is all about!
Your SE efforts improves your understanding
of reality, To-Be or As-Is!
Abstraction
Iteration
Kundförfrågan
NOTES: 1 2 3 4 5 6 7 8 9 10
Agreement
Process
A1
Iteration och
rapportering
Abstraction
Kontroll och styrning
Enterprise
Management
Process
A2
Iteration och
rapportering
RECOMMENDED
PUBLICATION A-0
System
krav/spec
Project
Management
Process
A3
Iteration och
rapportering
NODE: A0
TITLE: Performing the System Engineering System Life Cycle Processes
NUMBER:
Technical
Processes
A4
Resources and
infrastructure
Systemleverans
och förvaltning

Content
Why and how did it start
The first year
After the introduction of ISO/IEC 15288
The next step and the goal

The Start!
Why and how did it start?

The First Year!
The establishment of a common
understanding and goals!

After the introduction of
ISO/IEC 15288 as the glue
Work carried out on the ”SE” Processes
(SubSet of the Technical Processes)
Stakeholder Requirements Definition Process
Requirements Analysis Process
Architectural Design Process
Implementation Process
Integration Process

ISO/IEC 15288 - System Life Cycle Processes
Purpose and Overview:
Establishes a common framework for describing the
life cycle of systems and a complete set of well-defined
processes and associated terminology.
Enterprise
Processes
Enterprise Management
Process
Investment Management
Process
System Life Cycle
Processes Mgmt Process
Resource Management
Process
Quality Management
Process
Agreement
Processes
Acquisition Process
Supply Process
Project
Processes
Planning Process
Assessment
Process
Control Process
Decision Making
Process
Risk Management
Process
Configuration
Mgmnt Process
Information
Mgmnt Process
Technical Processes
Stakeholder Requirements
Definition Process
Requirements Analysis
Process
Architectural Design
Process
Implementation Process
Integration Process
Verification Process
Transition Process
Validation Process
Operation Process
Maintenance Process
Disposal Process

Why ISO/IEC 15288
The efforts from the first year resulted in several
very qualitative documents. However, there was
a lack of integration and commonality between
high-level company processes.
ISO/IEC 15288 offers a good foundation, at
company level:
Purpose and goal oriented
Process oriented
Areas of responsibilities
Common definitions and glossary
Relations to other standards and best practice
Reduced internal administration, upgrades or
editorial work needed.

Limitations of ISO/IEC 15288
ISO/IEC 15288 do not:
Define interfaces between processes and activities
Define the dynamic workflow, i.e. the process and
activity relations (”preceding, following, parallels,
interactions etc”)
Define a document/information structure
Eliminate redundant efforts and information
Define methods to be used and consequently does
not define how to perform tasks
Do not have a ”over-faith” to ISO/IEC 15288!
Identify strengths and weaknesses according to
your need and organisation!

Implementation strategy
The tasks to be performed!

Dynamic modelling
Top-down modelling of ISO/IEC 15288
Goal: To create an understanding of the complete
environment and dependencies. To define
interactions between processes and activities.
Output: A dynamic model of ISO/IEC 15288 down to
activity level, (15288/Processes/Activities), including
inputs, outputs and methods, (long term tools,
personnel and controls).
Method: IDEF0 (”IDEF Zero”)
Status: To be reviewed.

IDEF0 example
USED AT: AUTHOR: Tomas Huldt, Syntell AB DATE: 17 May 2001
PROJECT: Systemteknik -
systemlivscykelprocesser (ISO/IEC CD 15288
CD3)
NOTES: 1 2 3 4 5 6 7 8 9 10
REV: 26 June 2001
Systembehov och
avgränsningar
Kontroll och styrning
Intressentkravkravanalysocharkitekturutformningsprocessen
A4.1
Systemarkitektur
Realisation
och
Integration
A4.2
Verification and
certification data
WORKING
DRAFT
RECOMMENDED
PUBLICATION
Intressent- och
systemkrav
Realisering
Verification
Transition
and
Validation
NODE: A4
TITLE: Tekniska processer
NUMBER:
A4.3
READER DATE CONTEXT:
Systemleverans
Validerat system
Operation
Maintenance
and
Disposal
A4.4
A0
Systemleverans
och förvaltning
Iteration och
rapportering
Behov av iteration

Activity block diagrams
Step-by-step modelling of the implementation of
ISO/IEC 15288 activities
Goal: The definition of the activity flow including its
artefacts.
Output: Flow diagrams to the level required
(ISO/IEC 15288 activities and if needed one level
below). The diagram states the sequential flow of
tasks and other meta information:
• What to refine (input)
• What to be done (Outputs)
• How to do it (description)
• Check lists (best practice and knowledge based)
• etc
Method: Preferable FBD (Functional block diagrams).
Status: Partly implemented in the FMV intranet.

FBD example
Uppdrag att identifiera
intressentkrav
Process: Definiera intressentkrav
Identifiera
intressenter
Genomför
systemsäkerhetsanalys
Återmata
analyserade krav
till intressenter
Insamla
intressentkrav
Genomför
informationssäkerhetsanalys
Registrera &
vidmakthåll
intressentkrav
Definiera de krav som
ställs av de som ska
utnyttja det tekniska
systemet
Analysera &
specificera
intressentkriterier,
Q-krav & funktioner
Granska krav vid
viktiga hållpunkter
under hela livscykeln
Definiera
användbarhetskrav
Analysera &
prioritera krav
• Definierade intressentkrav
• Definierade användar- & driftskrav
• Underlag för förhandling & överenskommelse
• Underlag för validering av en systemtjänst eller
-produkt

Method analysis
Method selection and analysis
Goal: To validate different available methods
supporting ISO/IEC 15288 activities.
Output: A matrix that rates different methods
against ISO/IEC 15288 activities. In the focal point
between activity and method a rating number was
edited (1 to 5, 1 no and 5 high compliancy)
Method: X-axis: ISO/IEC 15288 and Y-axis Methods.
Status: Performed and reviewed.
Method selection:
• INCOSE "Systems Engineering Handbook"
• EIA-632 "Process for Engineering a system"
• IEEE Std 1220 "Standard for Application and
Management of the Systems Engineering Process"
• RUP ”Rational Unified Process”
• Mil-Std-498

Method analysis example (step 1)
Compliancy Matrix 15288 Vs Methods
Chapter in 15288
Heading
Compliency number
INCOSE 8,75
EIA-632 8,25
IEEE 1220 6,72
RUP 7,53
Mil Std 498 3,97
Ideal 11,67 "The perfect one!"
5.4 Technical Processes 18
5.4.1 Stakeholder Requirements Definition Process 18
5.4.1.3 Stakeholder Requirements Definition Activities. The project organization shall
implement the following activities in accordance with applicable organization policies
and procedures with respect to the Stakeholder Requirements Definition Process.
Activity
Page
Compliancy Weight
EIA-632 "Process for Engineering a system"
INCOSE "Systems Engineering Handbook"
IEEE Std 1220 "Standard for Application and Management of
the Systems Engineering Process"
RUP
Mil Std 498
J16
Activity: 1. Identify the individual stakeholders or stakeholder classes who have a legitimate int 1 3 4 4 2 5 1
2. Elicit Stakeholder Requirements, expressed in terms of the needs, wants, desires, e2 3 4 3 3 4 1
3. Define a representative set of activity sequences to identify all required services th 3 3 4 2 3 3 2
4. Identify the interactions between users and the system. Determine a complete and 4 3 4 4 4 3 1
5. Identify safety risk and, if warranted, specify requirements and functions to provide 5 3 2 2 3 3 1
6. Identify security risk and, if warranted, specify all applicable areas of system securi 6 3 2 2 1 3 1
7. Analyze and specify stakeholder requirements and functions that relate to critical qu7 3 5 5 1 2 1
8. Analyze and prioritize the complete set of elicited requirements to identify and reso8 3 5 5 4 4 1
9. Feed back the analyzed requirements to applicable stakeholders to ensure that the 9 3 5 2 4 4 1
10. Record the stakeholder requirements in a form suitable for requirements managem10 3 4 5 5 4 1
11. Review the Stakeholder Requirements at key decision times in the life cycle to ens11 3 4 3 1 5 1
5.4.2 Requirements Analysis Process 20 3,91 3,36 2,82 3,64 1,09
AT&T "AT&T Engineering Standard Process"
"OTIS"
LIMES
DERA "Systems Engine
Handbok

Method analysis example (step 2)
The summary matrix.

Information analysis
Information analysis and documentation
structure according to defined processes and
activities (part of the FBD analysis) :
Goal: To each activity and process define a
information and a documentation flow, i.e. what
type of data is created, where and how is it
compiled?
Output: Information and document attached to the
FBD’s and a formal document structure defined.
Method: Throughout the analysis of the FBD, IDEF0
and corresponding activity description define all
required data/documents. The Document structure
in Mil-Std-498 is the general base line for this
analysis.
Status: Under analysis.

Case development
The creation of general SE cases:
Goal: To create one or more general cases, based
upon different SE objectives, to be used for in-depth
analysis of methods and for the validation of SE
related tools.
Output: Well-defined ”paper-based” cases, including
all aspects during the:
• Stakeholder Requirements Definition Process
• Requirements Analysis Process
• Architectural Design Process
• Implementation Process
• Integration Process
Method: Based upon best practice and experience
create all required task and data to be performed by
validated method or tool.
Status: Under development.

K
r
a
f
t
k
ä
l
l
a
/
L
a
H
d
u
d
s
n
h
i
å
n
l
g
l
i
n
f
r
a
s
t
r
u
k
t
u
r
Case example
A
n
v
ä
n
d
a
r
e
Stakeholder
requirements
Functional
Operational
Operational
Operational
Level Level Level 11
1
Analysis
Level Level Level 22
2
Level Level Level 33
3
Kraftkälla/Laddn
ing
Hushåll
infrastruktur
Kravbeskrivning Intressent Funktionell
allokering
Systemet skall kunna försörja samtliga förbrukare inom
hushållet
Kunder Strömförsörjning
Systemet skall kunna försörja hushållet med el under
minst 12 timmar
Kunder Strömförsörjning
Systemet skall kunna startas automatiskt och manuellt vid Kunder
strömavbrott
Manövrering
Systemets effekt skall kunna styras både automatiskt och Kunder
manuellt
Manövrering
Systemet skall snabbt kunna laddas upp Kunder Laddning
Systemet skall kunna laddas med energi i hushållets
närhet
Kunder Energikälla
Systemet skall ha hög funktionssannolikhet Kunder Strömförsörjning
Systemet skall kunna underhållas av hushållets personer Kunder
och resurser
Övervakning
Systemet skall kunna manövreras av personer inom
hushållet
Kunder Manövrering
Systemet skall ha inbyggda förebyggande funktioner Samhälle Övervakning/
(säkringar, automatstopp etc)
styrning
Systemet skall upfylla krav på elsäkerhet och vara Energi- Gränsytor
kompatibelt med ordinarie elnät
producenter
Systemet skall kunna produceras inom ordinarie
Företags- Stödfunktion
produktionsanläggningar
ledningar
Systemet skall vara miljövänligt (utsläpp, buller etc) Samhälle Laddning/
strömförsörjning
Systemet skall enkelt kunna integreras i normalhushåll Kunder Gränsytor
1 2 3 4 5 6
Ref. 6 6.1 6.2 6.3 6.4
Strömförsörjnin
g
Go Go Go Go Go Go
Go Go Go Go Go
Ref. 6.4 6.4.1 6.4.2 6.4.3 6.4.4
Go Go Go
Övervakning
reglering
Underhåll
Viloläge
Transformering
Go Go
Start och
stopp
Kontroll,
styrning
Användar
e
+
WHATs
Prioriterade
Intressentkrav
Functional
Architecture
HOWs
Tekniska
Systemkrav
Relation intressentkrav
och tekniska systemkrav
Målvärde
Kravbeskrivning Intressent Funktionell
allokering
Systemet skall kunna försörja samtliga förbrukare inom
hushållet
Kunder Strömförsörjning
Systemet skall kunna försörja hushållet med el under
minst 12 timmar
Kunder Strömförsörjning
Systemet skall kunna startas automatiskt och manuellt vid Kunder
strömavbrott
Manövrering
Systemets effekt skall kunna styras både automatiskt och Kunder
manuellt
Manövrering
Systemet skall snabbt kunna laddas upp Kunder Laddning
Systemet skall kunna laddas med energi i hushållets
närhet
Kunder Energikälla
Systemet skall ha hög funktionssannolikhet Kunder Strömförsörjning
Systemet skall kunna underhållas av hushållets personer Kunder
och resurser
Övervakning
Systemet skall kunna manövreras av personer inom
hushållet
Kunder Manövrering
Systemet skall ha inbyggda förebyggande funktioner Samhälle Övervakning/
(säkringar, automatstopp etc)
styrning
Systemet skall upfylla krav på elsäkerhet och vara Energi- Gränsytor
kompatibelt med ordinarie elnät
producenter
Systemet skall kunna produceras inom ordinarie
Företags- Stödfunktion
produktionsanläggningar
ledningar
Systemet skall vara miljövänligt (utsläpp, buller etc) Samhälle Laddning/
strömförsörjning
Systemet skall enkelt kunna integreras i normalhushåll Kunder Gränsytor
Hushåll
säkringsfunktion
Gränsytefunktion
Säkringsfunktio
Säkringsfunktio
n
Gränsytefunktio
Gränsytefunktio
n
PIU
Laddningsfunktion hushåll
Gränsytefunktion
Överv
aknin
gs
funkti
PIU
Laddnings
Strömförsörjnings
Strömförsörjnings
Strömförsörjnings on
funktion
funktion funktion Transfor Gräns
SIU funktion
merings ytef.
WIU
funktion
Laddningsfun
ktion vind
Gränsytefunkt
ion
Laddningsfun
ktion sol
Gränsytefunkt
ion sol
Benchmarking
System
requirements
Värme
Kyl/frys samt spis
Vattenpump
Belysning
Reglerfun
ktion
Gränsytef
Övervak
Övervak unktion
ning
ning
och
och
styrfunk
styrfunk
tion
tion
Physical
Architecture

Tool analysis and selection
The validation of IT/IS environment:
Goal: Based upon defined cases, validate
and rate different tool and database
candidates.
Output: A matrix rating different IT/IS
environments solutions that facilities defined
activities.
Method: X-axis: activities and Y-axis
environment.
Status: Not started

Education analysis
Selection of required education:
Goal: To define required education level per type of
organisation function and identify preferred supplier
(ext. or int.).
Output: A selection of training modules and its
different configurations according to organisation
and function (a set of courses for PM, one for SE,
one for developers etc).
Method: The definition of modular training packages
corresponding to different organisational views (Line
org, PM org, Process/Functional org).
Status: Starts Q3 2001.

Training tracks (SE and PM)
Awareness Training
Presentation and Brochure
Target Aud: All Employees
SE Introductory Briefing (4-hour)
Target Aud: PM/SE
48-hour Training Course
“Applying SE in the specifi
domain Environment”
Target Aud: SEs
Tools-based Modules
“Understanding and
Applying SE Tools and
Techniques”
Target Aud: SEs
On-the-Job Mentoring
Application of SE
Master’s Level Training
University Courses
Target Aud: SEs
SE Training Path
On-the-Job Interaction
via Program IPTs
Non-SE Training Path
Awareness Training
Presentation and Brochure
Target Aud: All Employees
SE Introductory Briefing (4-hour)
Target Aud: PM/SE
48-hour Training Course
“Leveraging SE”
Target Aud: PM
Tools-based Modules
“Understanding SE Tools &
Utilizing the Products that
Result from Those Tools”
Target Aud: PM
On-the-Job Mentoring
Leveraging of SE
Master’s Level Training
University SE Courses
Target Aud: PM
Adapted from INEEL

Training for the Systems Engineer
Briefs
(1-2hrs)
Overviews
(1-2days)
Fundamentals
(1-2weeks)
Foundations
(as needed)
Why?
What?
How?
Enterprise
Environment
Management
Investment
Management
System Life-
Cycle Process
Management
Resource
Management
Quality
Management
Project
Planning
Project
Assessment
Project
Control
Information
Management
Acquistion
Process
•Org.
•Process
Mgmt
•Subcontr
act mgmt
Decision
Making
Risk
Management
Configuration
Management
Quality
Management
Supply
Process
•SE Planning
•Assessment
•Risk Mgmt
•Config Mgmt
•SE Planning
•Assessment
•Decision
•Risk Mgmt
•Config Mgmt
Stakeholder
Requirements
Definition
Requirements
Analysis
Architectural
Design
•Requirements Engineering
•Architectural Design
•Integration, V&V
•System operational effectiveness
•Requirements Engineering
•Architectural Design
•Integration, V&V
•System operational effectiveness
Implementation
Integration
Verification
Transition
Process
Validation
Operation
Maintenance
Disposal

The establishment
of a SE-model
Processes
• Interacting processes and
activities
• Defines ”What to be done”
USED AT: AUTHOR: Tom Strandberg
DATE: 97/06/26 x WORKING
READER DATE CONTEXT:
PROJECT: Verifiering
REV: 3
DRAFT
RECOMMENDED
NOTES: 1 2 3 4 5 6 7 8 9 10
PUBLICATION
Status (ver.objektets)
Krav
Ej godkänt krav
(för åtgärd)
ProvningTidplan
Nedbrytning
(Funktionell,
fysisk, krav,
prov)
Verifieringsresurser
(personal,
faciliteter,
utrustning,
etc)
Rutines/activities
Specar
Välj
utgångspunkt
för planering
A11
resurser
beaktas i
planering
•Free-standing modules
•Defines how, when
and who
Kopplade krav
Krav
(P/G/A)
Projektplan
Godkänna
A13
Verify-IT!
NODE: A1
TITLE: Planera (P/G/A)
(IT-stöd)
NUMBER:
Risk
Samordna
Gruppera
Optimera
A12
Provningsprogramförslag
(på remiss)
(tid, kostnad) (funktion)
Justerad tidplan
Provningsprogram
(P/G/A)
Ej godkänt
provningsprogram
P. 3
VAD VEM NÄR HUR
Asdf akjsdlöj
fölkjakfdö
ölökadsj öf
Aöälskd
fäkalös
kkadsk
äfklads
Adslök jasö öj Aslödk
jöjöadsf
Fdslökgj ijreg Asdo
fpåoasä
Asöädlkf
kälasdäk
äökflöad
sklöäg
äöagk
Lkjtreh
öijhtr
Asopd
jgpåaärsj
Löijsgfdö
m fdsg
Oöi
fdsöijfds
öijfdö
Oirej
gfdsgo k
A612 Adjust Release Schedule
Information supplied from the shop load status,
production requirements and revised order release dates
is used to forecast the expected load on the system.
This expected information along with the budgeted
capacity and stop order information is used to identify
any adjustments needed to avoid problems. The
adjustments are used to select which orders are ready
for release. The revised release schedule is sent back to
help forecast the load. Problems and the release
schedule are sent on to the next node.
USED AT:
ProvningTidplan
Krav
Nedbrytning
(Funktionell,
fysisk, krav,
prov)
Ver.objekt
(materiel, modell,
dokumentation, etc)
AUTHOR: Tom Strandberg
PROJECT: Verifiering
NOTES: 1 2 3 4 5 6 7 8 9 10
Specar
Risk
Planera
(P/G/A)
A1
P. 3
(beaktas i planeringen)
Provningsprogram
(P/G/A)
DATE:
REV:
Genomför
(P/G/A)
A2
Verifieringsresurser
97/06/26
3
P. 4
Provningsdata
USED AT: AUTHOR: Tom Strandberg
PROJECT: Verifieri ng
NOTES: 1 2 3 4 5 6 7 8 9 10
Krav
Perspektiv: Provningsansvarig
Syfte: identifiera och beskriva processen
och dess informationsbehov
DATE: 97/06/26
WORKING
READER DATE CONTEXT:
REV: 3.1
DRAFT
Top
x RECOMMENDED
PUBLICATION
Verifie ringsprogram
Speca r
Risk
Ve rifiering
A0
P. 2
Verifie ringsresurser
Ve rify-IT!
(IT-stöd )
Verifierat krav
Ej god känt krav
(för åtgärd)
NODE: A-0
TITLE: NUMBER:
Reviderat
Provningsprogram
(P/G/A)
Verify-IT!
(IT-stöd)
Analysera &
Dokumentera
(godk.
internt) A3
P. 5
Risk
(funktion,
ansvar)
För kundkrav:
Av Bofors
Godkänd
Provningsrapport
(P/G/A)
Granska &
Godkänn
(kund)
A4
NODE:
A0
TITLE:
Verifiering
NUMBER:
P. 1
x WORKING
DRAFT
RECOMMENDED
PUBLICATION
Rapport-mallar
READER DATE CONTEXT:
Justerad tidplan
Godkänd
Provningsrapport
(tillika möjligt
verifierat krav internt)
Verifierat krav
Ej godkänt krav
(för åtgärd)
P. 2
Subprocesses
(A1-levels, etc)
Asopdkj
oasädjfä
äadsöf
Lökfdsj
göjfdsöj
göjtrs
Pkfdskgä
gbfd
TITLE: How to do something
COMPANY: LSC
CREATOR : Tom Strandberg
DATE: 06-26-97 TIME : 17:41 PG 1
OF 1
PGS
MARKNAD
Data
Terminator
Process
ADMIN
KONSTR.
Data
Decision
Manual
operation
Preparation
Main process
(A0-level,
ISO/IEC15288)
USED AT: AUTHOR: Tom Strandberg
DATE: 97/06/26 x WORKING
READER DATE CONTEXT:
PROJECT: Verifiering
REV: 3
DRAFT
RECOMMENDED
NOTES: 1 2 3 4 5 6 7 8 9 10
PUBLICATION
Reviderat
Provningsprogram Rapport-mallar
(P/G/A)
Provningsdata
Beskrivande info
(ej i behov av analys)
Sammanställ
och fördela
A31
(Mät)data för
analys
Analysera
A32
Modeller
Analysrapport
Rapportera
provning
(P/G/A)
A33
Provningsrapport
Godkänn
internt
A34
NODE: A3
TITLE: Analysera & Dokumentera (godk. internt)
NUMBER:
Analysrapport
För kundkrav:
Av Bofors
Godkänd
Provningsrapport
(P/G/A)
Ej godkänd
provn.rapport
P. 5
The Summary table

Start
The implementation of a SE capability
Contract
(SOW etc)
•Customer
•Contractor
Selection of
Processes
•Customer (ext)
•Contractor (int)
•Subcontractors
•Supplier
•Company standards/Practice
•Project needs
•Standards & Best practice
•The future
Selection of
Methods
Selection and
definition of
Data Elements
Education &
hands-on training
•New DEDs
•Old DEDs
•Re-usable (legacy data)
•Formats (tools & Db)
Selection of
Tools and
Databases
Imp.

The Next Step!
Where are we going?

The implementation
To create a implementation plan, including:
Education
• Who, what and when
• Processes, activities, methods and tools
IT/IS environment (a project of its one)
• Purchase
• Development
• Implementation
Support
• The tailoring of activities, methods and outputs
according to project needs
• Recourse pool
• ”On-line” method and tool support
Configuration Management (of the above)
• What is valid
• Who has what

Long-Term Goals

The reality for many engineers
Project Management/PM
System Definition
WBS/CBS
Statement Of Work
Planning
Organisations
Etc
FRAME MAKER
Documentation/CSDB
System Definition
Information Modules
Documentation Structures
Publications
Etc
Etcetera
System Engineering/SE
System Definition
Requirement Analysis
Functional Analysis
Architecture
System Safety
Etc
MS ACCESS
MS EXCEL
ORACLE
Logistic Support/LSA
System Definition
FMEA/FMECA
RCM
MTA
LORA
Etc
MS WORD
Product Data Model/PDM
System Definition
Product Data
Manufacturing Data
Configuration Data
Etc

The ”Nirvana” for many engineers
Project Management/PM
WBS/CBS
Statement Of Work
Planning
Organisations
Etc
Top Function
F1 F2 F3
F31 F32 F33
Failure mode 1
Failure mode 2
Documentation/CSDB
Information Modules
Documentation Structures
Publications
Etc
System Engineering/SE
Requirement Analysis
Functional Analysis
Architecture
System Safety
Etc
Top Components
C1 C2 C21
C21 C22 C23
C211 C212 C213
Platform independent
And Instant Access
System Definition
Maint. 1
Maint. 2
Logistic Support/LSA
FMEA/FMECA
RCM
MTA
LORA
Etc
Product Data Model/PDM
Product Data
Manufacturing Data
Configuration Data
Etc

Long-term goals
The establishment of continues business
improvement program
Find and prioritise potentials
Create new or improved processes, activities
and methods
Select new or improve support necessary
Gradually integrate information assets to
improve quality and efficiency
”One way and one database”

Thoughts and experiences
To change a organisations way of work is an
extensive work and the success factor is to
retrieve enough and accurate knowledge about
the reality, ”As-Is” and ”To-Be”.
Define crystal clear goals and purposes
Select existing and available methods and tools
• Do not waste time and efforts upon method and
tool development.
Good ideas often fall upon lack of commitment and
resources
• Convince management and
• Motivate co-workers (handling officers)
Put the right people on the team and not the one
that has the time!