Masterarbeit von Hasan Veseli Zusammenfassung innerhalb der Siemens AG Product Life-Cycle Oriented Exchange of Configuration Management Data within the Siemens AG Inhaltsverzeichnis

University of Applied Sciences Munich

Fakultät für Elektrotechnik und Informationstechnik

Masterarbeit von Hasan Veseli

Zusammenfassung

Produktlebenszyklus-orientierter Austausch von

Konfigurationsmanagement-Daten innerhalb der Siemens AG

Product Life-Cycle Oriented Exchange of Configuration Management Data

within the Siemens AG

Inhaltsverzeichnis

1 Übersicht .............................................................................................................................. 1

2 Situationsanalyse ................................................................................................................ 2

2.1 Ist-Situation .................................................................................................................. 2

2.2 Projektauftrag .............................................................................................................. 4

3 Lösungserarbeitung ............................................................................................................. 5

3.1 Variantenbildung .......................................................................................................... 5

3.2 Variantenauswahl ........................................................................................................ 6

3.3 Konzeptentwurf ............................................................................................................ 7

3.4 Test ............................................................................................................................ 10

4 Resümee ........................................................................................................................... 10

Literaturhinweise ....................................................................................................................... 11

Zusammenfassung der Masterarbeit von Hasan Veseli Seite 1

1 Übersicht

Konfigurationsmanagement ist als ein Hilfsmittel der Produktentwicklung entstanden, um

durch professionelles Management von Produktzusammensetzungen (Konfigurationen)

deren Nachvollziehbarkeit bzw. Rückverfolgbarkeit optimal zu gewährleisten. Der

ISO10007:03 [ISOCM03] Standard hebt den Prozesscharakter von Konfigurations-

management (CM) hervor und unterstreicht, dass CM nicht nur die Produktenwicklung betrifft.

In komplexen Produktumgebungen, werden Konfigurationen auch in späteren Phasen

angereichert. Bei den heute üblichen Geschäftspraktiken werden einem Hardware-Produkt

z. B. auf Basis der technischen Konfiguration (Entwicklung) noch Informationen hinzugefügt,

die darüber Aufschluss geben, zu welchen Konditionen die jeweilige Konfiguration verkauft

werden darf (Vertrieb). Später müssen zu jeder Konfiguration auch Änderungen wie z. B.

Wartungseinsätze, Modifikationen, Modernisierung, etc. dokumentiert werden (Service), die

der jeweiligen Konfiguration direkt zurechenbar sind. Die Anzahl der Beteiligten am

Konfigurationsmanagement wird immer größer.

Konfigurationsmanagement (CM) ist ein Prozess und wird mit dem Anspruch erstellt, Arbeits-

abläufe optimal zu planen. Dabei spielt die Aufbauorganisation aller Akteure eine

zweitrangige Rolle. Je mehr Akteure einen Prozess bedienen (Distribution) und je

unterschiedlicher deren technische Systeme sind (Heterogenität), desto aufwendiger

gestaltet sich die Bedienung des Prozesses.

Prozess- bzw. Datenschnittstellen sollten demnach klaren Regelungen zur Struktur,

Formaten etc. folgen. Diesen Aspekt greift z. B. der EIA-836-A Standard auf, der sich auf die

Spezifikation von Elementen des CM (wie Pläne, Berichte, Baselines etc.) auf der Daten-

schnittstelle konzentriert. Der vom EIA-836-A gewählte Ansatz besagt, dass für Sender und

Empfänger von CM-Daten die In- bzw. Outputs standardisiert vorliegen müssen.

Diese Arbeit greift die o. g. Problematiken im Rahmen eines Projekts bei der Siemens AG

auf. Aufgrund von gewachsenen Strukturen und einer Matrix-Organisation ergibt sich hier

nämlich eine Problematik, die eines firmenweiten Lösungskonzeptes bedarf.

Diese Arbeit orientiert sich an das Systems Engineering Vorgehen, nach Haberfellner et. al.

[Daen02]. Hierfür wird zuerst die Ist-Situation ermittelt. Danach werden weitere Aspekte, die

bei der Lösungserarbeitung zu berücksichtigen sind, analysiert (wie der CM Referenz-

Prozess von Siemens) und ebenso der Projekt-Auftrag selbst. Die Ziele für die Lösungssuche

werden vom Projektauftrag abgeleitet. Weiterhin wurden alternative Lösungsansätze gezeigt,


die generell auf die Abdeckung aller Punkte der Ist-Analyse abzielen. Abschließend wurden

die verschiedenen Erkenntnisse und Lösungen in Bezug auf die Ziele zusammenhängend

bewertet und diskutiert.

2 Situationsanalyse

2.1 Ist-Situation

Die Siemens AG ist ein weltweit führendes Unternehmen der Elektronik und Elektrotechnik.

Rund 430.000 Mitarbeiter entwickeln und fertigen Produkte, projektieren und erstellen

Systeme und Anlagen und bieten maßgeschneiderte Lösungen auf den Gebieten Industrie

(Sektor „Industry“) und Energie (Sektor „Energy“) sowie im Gesundheitssektor (Sektor

„Healthcare“) an. Die Die Sektoren sind unterteilt in geschäftsverantwortliche Divisionen.

Die kundennahen Aktivitäten (Sales und Service) werden in so genannte Regionen unterteilt.

Diese sind selbstständige Einheiten und geografisch organisiert, z. B. Region Deutschland.

Innerhalb einer Region werden alle dort vertretenen Siemens-Produkte betreut. Dies reicht

von einfachen Ladentischprodukten z. B. SIMATIC-Steuerung über komplexere Systeme

z. B. Computertomograf bis hin zu großen Anlagen wie z. B. Kraftwerke.

In der vorgestellten Matrix-Organisationsform (vgl. Abbildung 2 – A) liegt die Portfolio- und

Produktverantwortung prinzipiell bei den Divisionen der Sektoren. Die Kundenbetreuung

erfolgt im Allgemeinen durch die eigenverantwortlichen Regionen, bei Bedarf unterstützt

durch die produktverantwortlichen Divisionen.

Historisch gewachsene IT-Systeme und Tools bestimmen heute die IT-Landschaft in den

Divisionen und Regionen. Zwischen diesen Organisationen ist dabei, trotz zentraler

Bestrebungen Standard-Systeme und Tools einzuführen, bislang noch eine heterogene IT-

Landschaft vorzufinden. Ursächlich für die die Heterogenität sind oft unterschiedliche Einsatz-

Szenarios, Budgets, Kompatibilitäts-Anforderungen etc., die bei der Auswahl von IT und

Tools eine Rolle spielen.

Im Rahmen der World-Class-Services-Initiative bei Siemens wurde erkannt, dass

organisationsübergreifende Prozessstandardisierung ein wichtiger Verbesserungshebel ist.

Es entstand dabei das „Service Operations Reference Framework“ (SERVOR®), in dessen

Rahmen auch der Siemens-eigene CM-Prozess harmonisiert wurde (vgl. Abbildung 1).


Configuration Management Identification

Configuration Management Planning

Configuration Management Reporting

Configuration Management Change Control

Configuration Management Audit

Abbildung 1: SERVOR® for Configuration Management Reference Process (top-level)

Die im Prozess definierten Informationsflüsse (In-/Outputs) müssen von den IT-Systemen der

unterschiedlichen Organisationen abgebildet und die dabei anfallenden Daten in der

vorhandenen heterogenen IT Landschaft ausgetauscht werden können (vgl. Abbildung 2 –

B). Die Herausforderung hierbei besteht darin, den Aufwand für die erforderlichen Schnitt-

stellen zwischen den Systemen zu reduzieren1 d.h. die Schnittstellen so zu vereinheitlichen,

dass der Datenaustausch an sich mit so wenig Aufwand wie möglich aufgesetzt und

betrieben werden kann und Änderungen in einzelnen Systemen mit minimalen Einfluss auf

die Datenschnittstellen bleiben.

Define /Realize

(Make) /DeliverProducts

SellService Configuration Management

DeliverService

Pro

ces

s

PLM SCM Support CRM SCM

e.g. SAP PLM e.g. SAP MM e.g. CRM e.g. SPIRIDON

Sys

tem

Da

ta ConfigurationManagement Data

(e.g. customer & partner information, contract information, relevant

configuration data, life cycle data, history information

PLM data(e.g. equipment data, part lists,

BOMs, …)

PLM data(e.g. serial / version numbers

for HW/SW)

PLM data(e.g. service, configuration and

history data)

PLM data(e.g. customer, contract data for

products)

PLM dataManufacturing

data Sales data Service data

Matrix organization

Integration of Configuration management and business processes

RegionalBranches

Operating Business

Region 1

Region 2

…

Gro

up 1

Gro

up 2

Gro

up 3 . . .

A

B

Abbildung 2: Integration des CM in Multi Organisations-, Prozess- und System-Ebenen [SERVOR®CM]

1 Das Reduzieren von Schnittstellen ist eines der Kern-Apelle von Haberfellner et. al.: „Prinzip der minimalen

Schnittstellenbildung“ (vgl. [Daen02]).


2.2 Projektauftrag

Da die Heterogenität der heutigen IT-Landschaft nicht kurz- oder mittelfristig aufgehoben

werden kann, wurde ein erfolgversprechenderer Lösungsansatz in der Spezifikation einer

harmonisierten Schnittstelle zwischen den Systemen zum Datenaustausch gesehen.

Ziel dieses Projektes ist es; einen Vorschlag für eine Siemens-weit gültige Schnittstellen-

spezifikation für Configuration-Management-Daten mit Gültigkeit für Hardware-, Software-

und Dienstleistungsprodukte zu spezifizieren. Die Umsetzung in den Divisionen und

Regionen erfolgt dann in späteren Implementierungsprojekten zusammen mit den Geschäfts-

und IT-System-Verantwortlichen der Divisionen und Regionen.

Today

RCSystem 3RCSystem 3RCSystem 3



Gro

up

1S

yste

m 1

Gro

up

1S

yste

m 1

Gro

up

2S

yste

m 1

Gro

up

2S

yste

m 1

Future requested by Business




Gro

up

1S

yste

m 1

Gro

up

1S

yste

m 1

Gro

up

2S

yste

m 1

Gro

up

2S

yste

m 1

Future With CM Architecture

RCSystem 3

RCSystem 1

RCSystem 2

Gro

up

1S

yste

m 1

Gro

up

2S

yste

m 1

ConfigurationManagement

Data

Today Future Request Goal

Initial Situation Prerequisites

No change of existing IT implementations

No change of existing IT landscape

But benefit for potential future IT implementations and landscape

SERVOR® for Service Configuration Management Framework (Process, Metrics, Improvement Levers)

Change ConfigurationManagement Concept & Plan






Execute Configuration Audit

Perform Planned Formalized Reporting

Change ProductEnvironmentConfiguration Information

Change Competitor ProductConfigurationInformation

Develop specific Configuration Management Plan

Perform On Demand Reporting

Change General ProductConfigurationInformation

Change Individual ProductConfiguration Information

DefineConfiguration Management ConceptA&D AT CHMed PG RDSBT TS UK

A&D AT CHMed PGMed PG RDSBT TS UKSBT TSSBT TS UK

A&D AT CHMed PG RDSBT TS UK


















Perform data consistency reporting



Identify General ProductConfiguration

Identify ProductEnvironmentConfiguration

Identify Competitor Product Configuration





Identify Individual ProductConfiguration





SERVOR® for Service Configuration Management Framework (Process, Metrics, Improvement Levers)



































































































Siemens is a matrix organization with multiple IT systems with varied dependencies of information.

RegionalBranches

Operating Business

Region 1

Region 2

Gro

up 1

Gro

up 2

Gro

up 3

. . .Siemens is a matrix organization with multiple IT systems with varied dependencies of information.

RegionalBranches

Operating Business

Region 1

Region 2

Gro

up 1

Gro

up 2

Gro

up 3

. . .RegionalBranches

Operating Business

Region 1

Region 2

Gro

up 1

Gro

up 2

Gro

up 3

. . .

Need for enhanced cooperation and information exchangebetween different organizations and units in groups and / or regions


Data

Need for enhanced cooperation and information exchangebetween different organizations and units in groups and / or regions


Data


Data

Definition of a standardized corporate, open and flexible semantic data model based on the defined information objects of Configuration Management Process

Definition of a standardized corporate, open and flexible data interfacebased on approved standards (e.g. XML, SAP XI, EDIFACT, …)

Definition of basic corporate policies to support configuration management within service units.

1

2

3

Configuration management architecture to enable collaboration

between groups & regions.

Project Proposal

Project proposal has been validated with experts from• groups A&D, Med, PG, SBT, TS• regions AT, BE, CH, RD, UK

Abbildung 3: Projektauftrag

Diese Arbeit ging aus zeitlichen Gründen nur auf die Konzeptphase ein und erfüllt alle dafür

vorgesehenen und dokumentierten Anforderungen des Projektauftrags. Sie präsentiert

sowohl Lösungsideen für eine langfristige Planung als auch einen sehr konkreten Vorschlag

zur Verbesserung des aktuellen Zustandes. Dieser Konzeptvorschlag wird Verantwortlichen

aus den Divisionen und Regionen vorgestellt und diskutiert. Explizite Implementierungs-

entscheidungen bedürfen der Abstimmung mit den Geschäftsverantwortlichen der Siemens-

Service-Einheiten.


3 Lösungserarbeitung

3.1 Variantenbildung

Abbildung 4 zeigt die Ist-Situation,

bei untereinander heterogenen

Systemen. Die Datenübertragung

erfolgt hierbei nach Absprache der

jeweiligen Partner, bei dem der

Sender dem Empfänger die

relevanten Daten in einer Form

bereitstellt, die eine Weiterverarbeitung (bis zum Import) möglich macht.

Den Ansatz der Variante A (vgl.

Abbildung 5) verfolgen auch die

meisten Autoren im Bereich CM,

die ein zentrales Data-Repository

vorsehen, bei der die Beteiligten

auf Daten zugreifen und diese

regional verarbeiten, um sie zentral

zu synchronisieren. Mit diesem

zentralen Data-Repository

synchronisieren sich auch die

Partnersysteme, wodurch die

Datenübertragung als solches

wegfällt, denn benötigte Daten

werden aus dem Repository

einfach ins eigene System

geladen.

Variante B (vgl. Abbildung 5)

besagt, dass alle bisherigen

Repositories weiterhin beibehalten werden würden und ein einheitliches Datenmodell

appliziert werden müsste, ohne einen Aufbruch des Gesamtbildes vorzunehmen.

Variante A: Zentrales CM-Repository

Variante C: Verteilte, Schnittstellen-homogene Systeme

Variante B: Verteilte, homogene Systeme

Abbildung 4: Ist-Ansatz frei nach Abbildung 2 – B

Abbildung 5: Lösungsvarianten


Variante C (vgl. Abbildung 5) orientiert sich an XML-Ansätzen, bei der durch ad-hoc-

Transformation (mithilfe von Interpretern, die gemäß Regeln) (exportierte) Daten in eine neue

Struktur umgewandelt werden.

3.2 Variantenauswahl

Der Projektauftrag definiert drei Voraussetzungen für eine annehmbare Lösung (vgl.

Abbildung 3 - Prerequisites). Die ersten zwei Voraussetzungen besagen, dass die Lösung

keine Umstrukturierungen bestehender Systeme implizieren darf. Die dritte Voraussetzung

(„Benefit for potenatial future IT implementations and landscape“) soll sicherstellen, dass sich

zukünftige IT-Systeme an den geschaffenen Standard halten.

Die ausgewählte Variante (Variante C) erfüllt als einzige alle Kriterien (vgl. Tabelle 1) und ist

damit als akzeptabelster Ansatz zu sehen. Eine Gegenüberstellung der Vor- und Nachteile

der jeweiligen Varianten erübrigt sich somit.

Anforderung

Variante

No change of existing IT

impelementations

No change of existing IT

landscape

Benefit for potenatial future IT

implementations and

landscape

Variante A

(zentrales

Repository)

~

(Teilweise gegeben, da

einzelne Systeme, wegen

des Synchronisations-

bedarfs, möglicherweise

angepasst werden müssen.)

-

(Nicht gegeben, da der

Synchronisatios-Bedarf mit

dem zentralen Repository

einen Paradigmenwechsel

verursacht.)

+

(Gegeben, da schrittweise

Integration möglich;

Kompatibel zu den anderen

Varianten.)

Variante B

(verteilte,

homogene

Systeme)

-

(Nicht gegeben, da einzelne

Systeme erheblich

restrukturiert werden.)

+

(Gegeben, da nur einzelne

Systeme restrukturiert

werden.)

+

(Gegeben, da schrittweise


kompatibel zu den anderen

Varianten.)

Variante C

(verteilte,

Schnittstellen-

homogene

Systeme)

+(Gegeben, da nur die

Datentransformation an den

Schnittstellen verändert wird.)

+(Gegeben, da Daten-

modelle, Systeme etc. nicht

modifiziert werden.)

+(Gegeben, da schrittweise


kompatibel zu den anderen

Varianten.)

Tabelle 1: Varianten-Vergleich auf Projekt-Anforderungen

In Tabelle 1 wurde die Lösung mit der besten Abdeckung der Anforderungen ermittelt. Nun

wird untersucht, ob eine aktive Umsetzung der Projektziele auf bestehenden Systemen – und


nicht nur in Hinblick auf zukünftige Implementierungen – nützlich wäre, da die ausgewählte

Lösung (Variante C) mit vergleichbar minimalem Aufwand verbunden ist. Dies würde der

Lösung einen höheren Reifegrad verleihen. Hierzu werden in Tabelle 2 die nominellen

Defizite des aktuellen Ansatzes untersucht und ob die Variante C Lösungen hierfür bereithält.

Nachteile des aktuellen Ansatzes Abhilfe durch die Auswahl

(Variante C)

1. Sender müssen die Daten je nach Empfänger

unterschiedlich restrukturieren, damit dieser sie

verwenden kann.

+

(Die Restrukturierung erfolgt immer nach demselben

Schema.)

2. Empfänger erhalten schlechtestenfalls von jedem

Partner unterschiedlich aufbereitete Daten, die

wiederum importfähig gemacht werden müssen.

+

(Empfänger erhalten die Daten immer nach

demselben Schema.)

3. Datenmodelländerungen können die jeweiligen

Daten-auszüge verändern, ohne dass die

Empfänger eine Inkohärenz feststellen können.

+

(Datenmodell änderungen beeinflussen nicht das

Schnittstellenschema.)

4. Konstant hoher Aufwand, verbunden mit den

zahlreichen Ex-/Imports.

+

(Reduktion des Aufwandes durch die Applikation eines

Schnittstellen-modells.)

5. Erhöhtes Risiko der fehlerhaften Interpretation von

Daten (vor allem durch 2. und 3.).

~

(Da beide Austauschpartner das Datenmodell der

Schnittstelle kennen, ist zumindest eine nominelle

Fehlinterpretation der Daten ausgeschlossen.)

Tabelle 2: Verteilte, heterogene CM-Systeme – Nachteile

3.3 Konzeptentwurf

Da sich die Wertschöpfung der ausgewählten Lösung (Variante C) stark an den Schnittstellen

orientiert und strukturell kaum vom aktuellen Ansatz abweicht (vgl. Abbildung 4 und

Abbildung 5), ist eine Konzentration auf die Schnittstellen des aktuellen Systems notwendig.

Da CM-Datenübertragung prozessorientiert erfolgt, ist davon auszugehen, dass jeweils die

Datenflüsse zwischen den Prozessschritten schnittstellenrelevant sind.

Die EIA-836-A (wie in der Einleitung kurz erläutert) ist eine Norm, die den Austausch von CM-

Daten zwischen verschiedenen Partnern definiert und somit grundsätzlich für den gewählten

Lösungsansatz geeignet ist. Diese konzentriert sich explizit auf den Austausch von

Konfigurationsdaten, mit dem Ziel eine gemeinsame Sprache bei dem Austausch von Daten

zwischen mehreren Partnern und bei heterogenen Quellsystemen anzubieten.


Sie definiert die Struktur auf der

Datenschnittstelle von Objekten

aus der CM-Welt (Pläne,

Baselines, Produkte etc.; vgl.

Abbildung 7), ein Schnittstellen-

modell also. Die in der EIA-836-A

definierten Objekte enthalten

zahlreiche Konstrukte zur

Dokumentennachverfolgung,

eindeutiger Objekt-Identifikation,

standardisierte Code-Listen etc.

Weiterhin geht diese auf typische

Fragestellungen wie Daten-

formate (in diesem Fall XML), Übertragungsprozeduren etc. ein. Diese können als ein

Regelwerk verstanden werden, welches der dritten Anforderung (vgl. Abbildung 3 – Project

Proposal) genügt.

ProductDefiningDocument

Product

Baseline

ChangeBoardCharter

ChangeBoardMinutes

ChangeVerificationRecord

ConfigurationAuditReport

Facility

File

DocumentChangeNotice

EngineeringDrawing

GenericDocument

DeficiencyRecord

ConfigurationManagementPlan

Contract

Organization

Initiative

Person

PartModel

Patent

RequestForVariance

RequestForChange

Supplement

Specification

ProductModificationInstruction

AssociatedList

ConfigurationAuditPlan

ProductDesign ProductUnit

HardwareDesign

SoftwareItem

SoftwareUnit

Standard

HardwareUnit

SoftwareComponent

Configuration Management Plan

External Configuration Requirement Data

Configuration Management Report Data

Product Environment Configuration Data

Internal Configuration Requirement Data

Customer Data

Configuration Management Concept

Contract Data

Functional Location Data

Individual Product Configuration Data

Competitor Product Configuration Data

Change Request for General Product Configuation Data

Change Request for Product Environment Configuration Data

Configuration Item Data

Change Request for Individual Configuration Data

Change Request for Competitor Product Configuration Data

Change Request for Configuration Management Plan Data

Configuration Audit Report Data

EIA-836-A Objects Siemens CM-Process In-/Outputs (Business Object Types)

Abbildung 7: Daten- bzw. Objektstrukturen der EIA-836-A Norm und des CM-Prozesses

Partner A Partner B

EIA‐836‐ASchema

Data Export File

TransformedExport File

Import ReadyFile

1 (exporting)

2 (using)

(importing) 7

3 (producing)

4 (validating)

(using) 5

(producing) 6

2 (using)

(using) 5

SendersSchema

Transformation Scriptor

Procedure

ReceiversSchema

Transformation Scriptor

Procedure

Abbildung 6: Übertragungs-Prozedur für CM-Daten lt. Der EIA-836-A


Die 18 In-/Outputs der Prozessschritte (genannt Business Object Types) und die 31 Objekte

der EIA-836-A-Norm stellen zwei Systeme dar, die jede für sich vollständige Lösungen für

ihre Domänen bieten (vgl. Abbildung 7). Deswegen ist es notwendig, diese Systeme zu

kombinieren bzw. primär zu prüfen, ob die Norm den Anforderungen des Prozesses genügt.

Hierfür wird überprüft, ob sich die Prozessdaten mit Hilfe der Norm abbilden lassen bzw. was

auf der Schnittstellenebene ergänzt werden muss, damit dies der Fall ist (vgl. Abbildung 7).

Für insgesamt 14 Business Object Types (BOTs) wurden grundsätzlich (etwa 13) passende

Objekte in der der EIA-836-A Norm identifiziert, die jedoch keinen 1:1 Abgleich darstellen

(vgl. Abbildung 8). Im Detail (v. a. bei der Modellbildung) ergeben sich zahlreiche Varianten

bzw. Punkte, die ergänzt werden müssen. Für die restlichen BOTs wurden Ergänzungs-

möglichkeiten aufgezeigt, die sich an das übliche Vorgehen bei Siemens orientieren.

Bei der späteren, abgestimmten Lösung müssen all diese Fragen geklärt werden. Hierfür

wurde eine komprimierte Liste dieser Entscheidungspunkte geliefert, die in insgesamt 13

Kategorien aufgeteilt ist. Dies dient zudem als Basis für die Erstellung eines Regelwerks, wie

es der Projektauftrag fordert.

Configuration Management Plan Data






Product Environment Configuration DataProduct Environment Configuration Data

Configuration Item DataConfiguration Item Data



Competitor Product Configuration DataCompetitor Product Configuration Data


Individual Product Configuration DataIndividual Product Configuration Data






Major Input











Configuration handover dataConfiguration handover data






Configuration Management Concept Data







Major Output







Change Request Configuration Information

Change Request Configuration Information

Configuration Audit Report DataConfiguration Audit Report Data

Change Request Configuration Information Data

Change Request Configuration Information Data







Legend:

Data Owned by Configu-ration ManagementOther Data Owner

BOTBOT

BOTBOT

Legend:

Data Owned by Configu-ration ManagementOther Data Owner

BOTBOT

BOTBOT

▪ Configuration managementconcept reference

▪ Document meta information▪ Concept description ▪ Configuration management

plan template▪ Implementation concept

▪ Implementation plan▪ Implementation cost estimation

Configuration Management Concept

▪ Configuration management plan reference

▪ Document meta information▪ Plan description ▪ Description of general configuration

management activities▪ Responsibility charts▪ Policies and guidelines

▪ Conventions▪ Statutory and regulatory policies▪ Terminology & definitions

▪ Siemens internal requirements▪ External requirements▪ Identification concept▪ Change control concept▪ Reporting concept▪ Audit concept▪ Database consistency and

Integrity concept▪ Implementation concept

▪ Implementation plan▪ Implementation cost calculation

Configuration Management Plan

EIA-836A interface object:

ConfigurationManagementPlan

• Identification

• Revision

• CommonRevisionableDocumentProperties

(Copyright, SecurityClassification, Title, DataRights, DistributionStatement, RelatedDocument, RevisionIdentifier, ApprovalAuthorityAssignedStatus, RevisionDescription)

• ProductManaged

• Representation (electronic etc.)

• NextHigherPlanReference

Source: GEIA Standard EIA-836A, March 2007

Abbildung 8: Abgleich der In-/Output-Daten des Prozesses (BOTs) mit den Objekten der EIA-836-A Norm


3.4 Test

Auch in der Konzeptphase ist es wichtig zu testen – ganz im Sinne des Systems-Engineering.

Deshalb wird das aus dem Prozessabgleich abgeleitete Modell anhand von insgesamt 15

Use-Cases getestet, mit dem zusätzlichen Ziel weitere Erkenntnisse für Anpassungen zu

erlangen. Die Use-Cases wurden aus den Szenarien abgeleitet, die bereits dem SERVOR®

for CM Prozess als Grundlage dienten. Diese Use-Cases wurden von den Bereichen als

übliche Geschäftsszenarien im Bereich CM identifiziert.

Da es sich hierbei um einen Konzept-Vorschlag handelt, wurde auf der Modellebene getestet,

um in erster Linie zu überprüfen, ob Denkfehler gemacht wurden, bzw. Übertragungen

grundsätzlich (also auf der Modellebene) möglich sind; sowie zu ermitteln welche weitere

Lücken (Gaps) es gibt und ob sie umgegangen werden können, oder ob Modifikationen

notwendig sind.

4 Resümee

Der Lösungsvorschlag bildet ein Datenmodell für den Austausch von konfigurations-

relevanten Daten. Im Gegensatz zu einem Datenmodell für Prozessdaten, beschreibt das

Datenmodell der Schnittstelle die Datenelemente, die zwischen verschiedenen Systemen

ausgetauscht werden. Als Folge werden für Konfigurationsdaten, die als Dokument

ausgetauscht werden sollen, z. B. Pläne, Berichte etc., ein besonderer Wert auf Dokument-

management-Aspekte, z. B. Versionsmanagement, Verantwortlichkeiten etc., gelegt.

Weiterhin müssen für Produkt- und Komponenten-Konfigurationen die Strukturen des

Prozessmodells weiter detailliert und standardisiert werden und, wenn nötig, um

Verwaltungsinformationen (z. B. Datenherkunft, Eigentümer, etc.) erweitert werden.

Zu Beginn des Projektes wurde in erster Linie versucht, ein implementierbares Datenmodell

(im Sinne eines Entity-Relationship-Modells) zu entwickeln, welcher aus dem Prozessmodell

(BOTs) abgeleitet werden sollte. Die Ergebnisse ähnelten in der Aufbaustruktur den Objekten

der EIA-836-A-Norm.

Weitere Analysen führten explizit zur EIA-836 Norm, die zwar nicht 1:1 übernommen werden

konnte, jedoch für sich ein brauchbares Konzept darstellt (Erweiterbarkeit von Objekten,


Beschreibungstiefe von z. B. Orts- oder Dokumentmanagementangaben etc.), wobei dem

eine längere Entwicklungszeit vorausgegangen war2.

Durch die Analyse von diversen Beschreibungen der Norm war es zwischenzeitlich fraglich,

ob die Norm mit den Lösungsanforderungen vereinbar war. Der hohe Umfang der Norm-

Dokumentation (ca. 500 Seiten) und die daraus resultierende Komplexität erforderten viele

Sitzungen, die alle das Ziel hatten, ein gemeinsames Verständnis zu erreichen und den

Nutzwert für dieses Projekt zu ermitteln.

Gespräche mit Stakeholdern ergaben wichtige Erkenntnisse über zu erwähnende Aspekte

und der notwendigen Granularität, mit der die Darstellung bzw. Darstellungsart der

Ergebnisse als allgemein verständlich gilt. Die Aufbereitung des Vorgehens in Präsentationen

und das Feedback des Auditoriums waren hilfreich für die Chronologie dieser Arbeit.

Die Literatur fokussiert sich zu sehr auf die Probleme und Möglichkeiten von CM in der

Produktentstehungsphase und versäumt i. d. R. hilfreiche Erfahrungsberichte für die Daten-

übertragung über den gesamten Produktlebenszyklus hinweg oder speziell für den Bereich

Service Management (in Bezug auf CM) zu geben. In einer Zeit, in der sich die Kompatibilität

von Systemen wegen des hohen Kommunikationsbedarfs als zu lösendes Problem erweist,

kann man davon ausgehen, dass Siemens nicht die erste größere Organisation ist, bei der

derartige Standardisierungs-Bestrebungen unternommen werden. Gleichzeitig impliziert

diese Kritik, dass man mit besserem Beispiel vorangehen sollte.

Literaturhinweise

[Daen02] Daenzer, W. (Hrsg.), Haberfellner, R., Nagel, P., Becker, M., Büchel, A., &

von Massow, H. (2002). Systems Engineering. Zürich: Verlag Industrielle Organisation.

[EIA-836-A] Information Technology Association of America (ITAA).

(2007).Configuration Management Data Exchange and Interoperability. ITAA EIA-836-A.

[ISOCM03] International Organization for Standardization (ISO). (2003). Quality

management systems - Guidelines for configuration management. ISO 10007:03.

[SERVOR®CM] Siemens AG. (2002). SERVOR® for Configuration Management Library.

2 Der erste Draft der EIA-836-A Norm wurde schon 2001 publiziert, erst nach drei Jahren (2004) folgte eine

offizielle Publikation EIA-836 welches bis zum Jahr 2007 nochmals überarbeitet wurde. Für die weiteren

Iterationen wurden Services angekündigt.

Documents

Masterarbeit von Hasan Veseli Zusammenfassung innerhalb der Siemens AG Product Life-Cycle Oriented Exchange of Configuration Management Data within the Siemens AG Inhaltsverzeichnis