Sappress Sap for Dfps

Bonn � Boston

Bernhard Escherich, Heinrich Pfriemer, Wolfgang Ullwer

SAP for DFPS – Implementierung und Customizing

®

1430.book Seite 3 Donnerstag, 10. Juni 2010 3:02 15

Auf einen Blick

TEIL I Einführung und Grundlagen ...................................... 31

1 Einführung in DFPS – Anwendungen in der Praxis ................ 33

2 Fallstudie – Tsunami-Hilfsoperation ...................................... 53

3 Stammdaten und Organisationsstruktur als Grundlage der Implementierung ........................................... 65

TEIL II Prozesse, Funktionen, Customizing .......................... 135

4 Operational Planning ............................................................ 137

5 Implementierung der Prozessgruppe »Qualification Management« ................................................ 177

6 Logistik ................................................................................ 207

7 Materialwirtschaft ................................................................ 245

8 Instandhaltung ..................................................................... 283

9 Unterstützung des Flugbetriebs ............................................ 317

10 DFPS und Rechnungswesen .................................................. 345

11 Berichtswesen/Reporting ..................................................... 371

TEIL III Erfahrungen aus Implementierungsprojekten .......... 415

12 IT-Architektur als Herausforderung für Armeen und Sicherheitsorganisationen .............................................. 417

13 Rollen im DFPS-Projekt ........................................................ 439

14 Projekt- und Risikomanagement ........................................... 453

15 DFPS und die Prozesse des Personalwesens .......................... 481

16 Sicherheit und Berechtigungen ............................................ 507

17 Mobile Anwendungen .......................................................... 533

TEIL IV Innovative Anwendungsfelder von DFPS .................. 557

18 Katastrophenschutz .............................................................. 559

19 Performance-Based Logistics – DFPS in der Rüstungs- und Raumfahrtindustrie ....................................................... 581

20 SOA und Network Centric Warfare mit DFPS ....................... 599

21 Polizei und Nachrichtendienste ............................................ 623

22 Ausblick ............................................................................... 639


7

Inhalt

Vorwort .................................................................................................... 17Preface ..................................................................................................... 19Einleitung ................................................................................................. 23

TEIL I Einführung und GrundlagenEine Lösung wird durch nichts anschaulicher als durch Praxisbeispiele. Lernen Sie deshalb in diesem Kapitel die DFPS-Konzepte kennen, und lernen Sie anhand von Anwendungsbeispielen, wie Sie selbst DFPS für Ihre Bedürfnisse nutzen können. 33

1 Einführung in DFPS – Anwendungen in der Praxis ............. 33

1.1 Grundanforderungen an DFPS ............................................... 331.1.1 Rahmenbedingungen ................................................. 341.1.2 Besonderheiten von militärischen und

Sicherheitsorganisationen .......................................... 371.1.3 Vor dem DFPS-Einsatz – Informationssysteme in

Armeen und Sicherheitsorganisationen........................ 391.2 DFPS – Funktionalitäten und Integration in Armeen

und Sicherheitsorganisationen .............................................. 461.3 Beispielhafte Praxisberichte ................................................... 47

1.3.1 Beispiel 1 – Bundeswehr ............................................. 471.3.2 Beispiel 2 – Die Streitkräfte Singapurs ......................... 501.3.3 Beispiel 3 – Koordinierter Sanitätsdienst in

der Schweiz (KSD) ...................................................... 511.4 Fazit ...................................................................................... 52

Eine gewaltige Naturkatastrophe in einem Land am Rande des Pazifiks bildet den fiktiven Hintergrund für unsere Fallstudie. Wir zeigen, wie SAP for Defense & Security die Einsatzkräfte bei der Bewältigung dieses Szenarios unterstützt. 53

2 Fallstudie – Tsunami-Hilfsoperation ................................... 53

2.1 Ausgangslage ......................................................................... 532.2 Tsunami ................................................................................. 572.3 Rettungsoperationen mit DFPS-Unterstützung ....................... 602.4 Fazit ...................................................................................... 64

3 Stammdaten und Organisationsstruktur als Grundlage der Implementierung ......................................... 65

3.1 Organisatorische Flexibilität ................................................... 663.1.1 Das Skelett einer Organisation .................................... 663.1.2 Organisatorische Flexibilität im Detail ......................... 67

3.2 Integration ............................................................................ 79


Inhalt

8

3.3 Gesamtstammdatenmodell von DFPS ................................... 833.3.1 Das Strukturelement – technischer Fokus .................... 853.3.2 Planstelle ................................................................... 973.3.3 Person ........................................................................ 1003.3.4 Stelle .......................................................................... 1053.3.5 Zusammenfassung ....................................................... 1063.3.6 Material- und Infrastrukturstammdaten ...................... 106

3.4 Strukturen der Branchenlösung DFPS ..................................... 1163.4.1 Strukturen des Organisationsmanagements ................. 1163.4.2 Neue Auswertewege .................................................. 117

3.5 Statusnetz und Aktivierung von Strukturen ............................ 1243.5.1 Aktivierung ohne Organisationsmaßnahme ................. 1263.5.2 Statusänderung mit Organisationsmaßnahmen ............ 1313.5.3 Zusammenfassung ....................................................... 132

3.6 Fazit ...................................................................................... 133

TEIL II Prozesse, Funktionen, CustomizingOperational Planning oder Einsatzplanung stellt die Kür der Herausforderungen an IT-Systeme dar. Diese Prozessgruppe werden wir Ihnen in diesem Kapitel mit all ihren Funktionalitäten anhand eines beispielhaften Verlaufs näherbringen. 137

4 Operational Planning .......................................................... 137

4.1 Voraussetzungen ................................................................... 1374.2 Lebenszyklusmodell ............................................................... 1394.3 Phase 1 – Rahmenbedingungen ............................................. 1414.4 Phase 2 – Planung ................................................................. 145

4.4.1 Die Herausforderungen der Planung ........................... 1454.4.2 Fallbeispiel – die Planungsphase des Einsatzes ............ 147

4.5 Phase 3 – Genehmigung und Erstausstattung ......................... 1694.5.1 Genehmigungsschritte durchführen ............................ 1704.5.2 Personalplanung ......................................................... 1714.5.3 Einsatz aktivieren ........................................................ 1714.5.4 Erstausstattung ........................................................... 171

4.6 Phasen 4 und 5 – Hin- und Rückverlegung sowie Durchführung des Einsatzes ................................................... 172

4.7 Fazit ...................................................................................... 174

5 Implementierung der Prozessgruppe »Qualification Management« ............................................. 177

5.1 Grundlagen und Zielsetzung .................................................. 1775.2 Integrierte und einheitliche Verwaltung der

Qualifikationsstammdaten ..................................................... 180


Inhalt

9

5.2.1 Zentraler Qualifikationskatalog ................................... 1805.2.2 Qualifikationsgruppe .................................................. 1825.2.3 Qualifikation ............................................................... 1845.2.4 Qualifikationsblock ..................................................... 185

5.3 Das personelle Soll – Abbildung der Anforderungen und Fähigkeiten ..................................................................... 1875.3.1 Zuordnung über das Personalmanagement –

Transaktion PPPM ...................................................... 1885.3.2 Zuordnung über Organisationsgrundlagen

Personelle Anteile – Transaktion /isdfps/TOEP1........... 1895.3.3 Voraussetzungen für die Zuordnung von

Qualifikationen und Qualifikationsblöcken ................. 1905.4 Das personelle Ist – Abbildung der Fähigkeiten einer

Person ................................................................................... 1925.4.1 Zuordnung über die Pflege der Personal-

stammdaten – Transaktion PA30 ................................ 1925.4.2 Zuordnung über den Strukturarbeitsplatz –

Transaktion /isdfps/TOEP1 .......................................... 1935.5 Unterstützung der Personalauswahl – das Beispiel

»Einsatzplanung« ................................................................... 1945.6 Zielvereinbarungen und Beurteilungen .................................. 1975.7 Ableitung von Qualifikationen – Infotyp

»Trainingsprogramm« (806) aus der Instandhaltung ............... 1995.7.1 Voraussetzungen für die Ableitung von

Qualifikationen aus dem Flugbetrieb .......................... 2005.7.2 Beispielhafter Prozessablauf ........................................ 202

5.8 Operative Gewichtung – Bewertung der Verknüpfung zwischen Qualifikationen und Planstellen/Stellen .................. 204

5.9 Fazit ...................................................................................... 206

Innerhalb der Branchenlösung SAP for Defense & Security nehmen die Funktionen für »Defense Logistics« eine zentrale Rolle ein. Im Verbund mit der organisatorischen Flexibilität sind sie die tragende Säule des Softwarepakets. 207

6 Logistik ................................................................................ 207

6.1 Unternehmensstruktur ........................................................... 2076.2 Integration des Strukturelements in die Logistik .................... 209

6.2.1 Materielles Soll ........................................................... 2136.2.2 Materielles Ist – Bestandselemente ............................. 222

6.3 Soll-Ist-Vergleich ................................................................... 2246.3.1 Soll-Ist-Vergleich in der Struktur-Workbench ............. 2246.3.2 Zusätzliche Funktionen zum Soll-Ist-Vergleich ............. 225

6.4 Materielle Planung ................................................................ 2276.5 NSN und IUID ....................................................................... 235


Inhalt

10

6.6 Herstellerteilenummern ......................................................... 2396.7 Austauschbarkeit ................................................................... 2426.8 Fazit ...................................................................................... 244

»From Factory to Foxhole« – das ist die erklärte Zielrichtung militärischer Bewirtschaftungsprozesse. Lesen Sie im Folgenden, wie SAP for Defense & Security die spezifischen Anforderungen an die Materialwirtschaft erfüllt. 245

7 Materialwirtschaft .............................................................. 245

7.1 Erst- und Folgeversorgung mit Vorratspaketen ....................... 2457.1.1 Vorratspakete anlegen und pflegen ............................. 2467.1.2 Integration der Strukturelemente in die logistische

Unternehmensstruktur ................................................ 2487.1.3 Prozesse der Erst- und Folgeversorgung ...................... 251

7.2 Prioritäten ............................................................................. 2537.2.1 Prioritäten für Materialbedarfe .................................... 2537.2.2 Organisatorische Priorität ........................................... 2547.2.3 Bedarfspriorität ........................................................... 2567.2.4 Lieferpriorität .............................................................. 260

7.3 Zustandsverwaltung ............................................................... 2677.3.1 Zustandscode .............................................................. 2677.3.2 Prozessuale Abwicklung der Zustandsverwaltung ........ 270

7.4 Hinweiscode und Statuscode ................................................. 2717.5 Rücklieferung ........................................................................ 2737.6 Leihe .................................................................................... 2767.7 Verlegeplanung ..................................................................... 278

7.7.1 Einsätze ...................................................................... 2787.7.2 Verlegungen ............................................................... 2797.7.3 Verlegeschritte ............................................................ 2797.7.4 Verlegeschritt-Typen ................................................... 279

7.8 Fazit ...................................................................................... 281

Angesichts wachsenden Kostendrucks in Sicherheits- und Verteidigungsorganisationen kommt der wirtschaftlichen Gestaltung von Instandhaltungsaktivitäten größere Bedeutung zu. DFPS unterstützt Sie dabei mit speziell für Ihre Branche entwickelten Funktionen. 283

8 Instandhaltung .................................................................... 283

8.1 Besonderheiten militärischer Instandhaltung .......................... 2848.2 Instandhaltungsbezogene Unternehmensstruktur ................... 2868.3 Stammdaten .......................................................................... 287

8.3.1 Stammdaten Technischer Objekte ............................... 2888.3.2 Technische Plätze ....................................................... 2898.3.3 Technische Referenzplätze und Referenzmesspunkte ... 2978.3.4 Equipment .................................................................. 2998.3.5 Stücklisten .................................................................. 3018.3.6 Organisationsbezogene Stammdaten .......................... 3028.3.7 Instandhaltungsbeziehungen ....................................... 303


Inhalt

11

8.4 DFPS-spezifische Prozesserweiterungen in der Instandhaltung ...................................................................... 3088.4.1 Schadensbedingte Instandhaltung ............................... 3088.4.2 Takeover/Handover .................................................... 313

8.5 Verteilte Instandhaltung ........................................................ 3158.6 Mobile Instandhaltungsprozesse ............................................ 3158.7 Fazit ...................................................................................... 316

Mit SAP for Defense & Security (DFPS) stehen für die Unterstützung des Flugbetriebs spezielle Funktionen, erweiterte Stammdaten und flexible Benutzeroberflächen zur Verfügung, die auf die Anforderungen fliegender Verbände abgestimmt sind. 317

9 Unterstützung des Flugbetriebs ......................................... 317

9.1 Äußere Gegebenheiten .......................................................... 3179.2 Stammdaten für die Unterstützung des Flugbetriebs .............. 321

9.2.1 Objekt »Master-Equipment« ....................................... 3279.2.2 Objekt »Site-Equipment« ............................................ 3299.2.3 Objekt »Mission« ........................................................ 329

9.3 Prozesse des Flugbetriebs ...................................................... 3319.3.1 Anlegen von Flugaufträgen ......................................... 3319.3.2 Zuordnung der Luftfahrzeuge zum Flugauftrag............. 3359.3.3 Kontrolliertes Abfliegen .............................................. 3369.3.4 Monitoring der Flotte – Statusboard ........................... 3379.3.5 Statusverwaltung – technischer Status und

Einsatzstatus ............................................................... 3399.3.6 Rüstprozess und Flugvorbereitungen inklusive

Rückmeldung .............................................................. 3419.3.7 Den Flug verfolgen und Folgemaßnahmen

anstoßen ..................................................................... 3439.4 Fazit ...................................................................................... 344

Mit einer guten Verwaltung der finanziellen Ressourcen durch ein zuverlässiges Rechnungswesen ist die Basis für die Transparenz der Geldflüsse gelegt. Gerade in Zeiten der Transformation von Streitkräften und des Rückgangs von Steuereinnahmen ist es wichtig, zu wissen, wie viel etwas kostet. 345

10 DFPS und Rechnungswesen ................................................ 345

10.1 Das Rechnungswesen im Bereich der Einsatzorganisationen ... 34510.2 Integration von DFPS und Rechnungswesen .......................... 347

10.2.1 Grundlagen ................................................................. 34710.2.2 Controlling .................................................................. 34810.2.3 Projektsystem ............................................................. 35910.2.4 Haushaltsmanagement ................................................ 36210.2.5 SAP Real Estate Management .................................... 364

10.3 Rechnungswesenspezifische Statuswechselprüfungen und Folgeaktionen ........................................................................ 36610.3.1 Statuswechsel: Geplant – Beantragt ............................ 36610.3.2 Statuswechsel: Beantragt – Genehmigt ....................... 367


Inhalt

12

10.3.3 Statuswechsel: Genehmigt – Aktiv .............................. 36710.4 Löschen und Abgrenzen von Strukturen und die

Auswirkungen auf das Rechnungswesen ................................ 36810.5 Technische Objekte und Rechnungswesen ............................. 36910.6 Fazit ...................................................................................... 370

Für die Modernisierung der Streitkräfte und der Sicherheitsorganisationen ist der Themenbereich »Analyse und Berichtswesen« entscheidend. In diesem Kapitel lernen Sie die notwendigen Werkzeuge und Konzepte kennen, um diesen Bereich effizient zu implementieren. 371

11 Berichtswesen/Reporting ................................................... 371

11.1 Fragestellungen und Konzepte als Grundlagen für das Berichtswesen ....................................................................... 372

11.2 Erprobung der Reportingmöglichkeiten ................................. 37811.2.1 SAP BusinessObjects Explorer ..................................... 37911.2.2 Suchfunktion im SAP BusinessObjects Explorer............ 383

11.3 Besonderheiten bei Projekten im Katastrophenschutz ............ 38411.4 Möglichkeiten und Funktionalitäten für das Berichtswesen –

DFPS und SAP-Standardfunktionalitäten ................................ 38611.4.1 Operatives Berichtswesen ........................................... 38711.4.2 DFPS und SAP NetWeaver BW ................................... 397

11.5 Technologische Grundlagen .................................................. 41211.6 Fazit ...................................................................................... 413

TEIL III Erfahrungen aus Implementierungsprojekten

12 IT-Architektur als Herausforderung für Armeen und Sicherheitsorganisationen ........................................... 417

12.1 Anforderungen und Rahmenbedingungen .............................. 41812.1.1 Einsätze und Autarkiefähigkeit .................................... 41812.1.2 Interoperabilität .......................................................... 41912.1.3 Aufwuchsfähigkeit ...................................................... 42012.1.4 Heterogene Systemlandschaft ..................................... 42112.1.5 Extrem hohe Sicherheitsanforderungen ....................... 422

12.2 Referenzarchitektur ............................................................... 42212.2.1 Zentrale Systemebene am Heimatstandort .................. 42412.2.2 Dezentrale Systeme .................................................... 42612.2.3 Beispiel 1 – Systemlandschaft für eine

Luftlandeeinheit .......................................................... 42712.3 Vorgehensmodell .................................................................. 428

12.3.1 Phase 1 – Implementierungsstudie .............................. 42912.3.2 Phase 2 – Analyse ....................................................... 43012.3.3 Phase 3 – Design ........................................................ 430


Inhalt

13

12.3.4 Phase 4 – Verfeinerung ............................................... 43112.3.5 Phase 5 – Ständige Verbesserung ................................ 43112.3.6 Hilfsmittel und Vorlagen ............................................. 432

12.4 Typische Architekturmuster ................................................... 43412.4.1 Beispiel 2 – Verteilte Einheiten im Einsatzraum

mit einem Unterstellungsverhältnis ............................. 43412.4.2 Beispiel 3 – Versorgungsbeziehung zwischen

Einheiten im Einsatzraum mit Bezug zur Heimatbasis ................................................................ 436

12.5 Risiken und Probleme ............................................................ 43712.6 Fazit ...................................................................................... 438

Die richtige Auswahl von qualifizierten Projektmitgliedern ist entscheidend für den Erfolg Ihres DFPS-Projekts. In diesem Kapitel erfahren Sie, welche Experten Sie für Ihr Projekt benötigen, worin deren Aufgaben bestehen und welche Erfahrungen und Kenntnisse sie mitbringen müssen. 439

13 Rollen im DFPS-Projekt ...................................................... 439

13.1 Grundsätzliche Anforderungen .............................................. 43913.2 Die Rollen im Einzelnen ......................................................... 443

13.2.1 Programmmanager ..................................................... 44413.2.2 Projektleiter/Teilprojektleiter ...................................... 44413.2.3 Architekt ..................................................................... 44513.2.4 DFPS-Berater ............................................................. 44713.2.5 Basisberater ................................................................ 44813.2.6 Sicherheitsexperten .................................................... 44913.2.7 Change-Management-Berater ..................................... 44913.2.8 Schulungsplan für Berater ........................................... 450

13.3 Checkliste für ein DFPS-Projektteam ...................................... 45113.4 Fazit ...................................................................................... 451

Das Projekt- und Risikomanagement für ein DFPS-Projekt stellt besondere Anforderungen an Sie. In diesem Kapitel erfahren Sie, welche Ansätze und Methoden sich bewährt haben und welche Risiken bestehen. 453

14 Projekt- und Risikomanagement ........................................ 453

14.1 Grundsätzliche Überlegungen ................................................ 45314.1.1 Komplexität von DFPS-Projekten ................................ 45414.1.2 Komplexität reduzieren und kontrollieren ................... 456

14.2 Mögliches Projektvorgehen ................................................... 45814.2.1 Der Schritt vorab – Bereitschaftsstand für

das Projekt? ................................................................ 45814.2.2 Grundsätzliches Projektvorgehen ................................ 460

14.3 Projektrisiken ........................................................................ 47114.3.1 Grundsätzliche Überlegungen und Vorgehen .............. 47114.3.2 Allgemeine Projektrisiken .......................................... 47214.3.3 Fachliche Projektrisiken .............................................. 477

14.4 Zusammenfassung ................................................................. 480


Inhalt

14

In diesem Kapitel werden wir detailliert auf die Interaktion zwischen HCM und DFPS eingehen und erläutern, welchen zusätzlichen Mehrwert der Einsatz der Branchenlösung DFPS bietet. 481

15 DFPS und die Prozesse des Personalwesens ...................... 481

15.1 Welchen Mehrwert liefert die Branchenlösung DFPS? ............ 48215.2 HCM und DFPS – prozessuale und

technische Unterschiede ........................................................ 49115.3 DFPS-HCM-Implementierungen – bisherige Erfahrungen ....... 50115.4 Fazit ...................................................................................... 506

In diesem Kapitel erfahren Sie, wie Sie mit einem angepassten Sicherheitskonzept Projektrisiken begegnen können. Dabei gehen wir von einem übergreifenden Konzept aus und bauen hierauf die Darstellung der technischen Details auf. 507

16 Sicherheit und Berechtigungen .......................................... 507

16.1 Vorüberlegungen und Vorgehensweise .................................. 50716.2 Sicherheitskonzept in einem DFPS-Projekt – Modelle ............ 50916.3 Sensible Einheiten und Nachrichtendienste –

Besonderheiten ..................................................................... 51216.4 Trennung in rote und schwarze Netze .................................... 51516.5 Besonderheiten bei Projekten im Katastrophenschutz ............ 51816.6 Lösungsbestandteile der SAP-Plattform für die Umsetzung

des Sicherheitskonzepts ......................................................... 51916.7 DFPS-spezifische Erweiterungen ........................................... 525

16.7.1 Funktionalitäten des Rollenmanagers ......................... 52616.7.2 User- und Berechtigungsmanagement für mobile

Systeme ..................................................................... 52816.7.3 Erweiterung ZBV zur Unterstützung

Autarkiefähigkeit ........................................................ 53016.8 Sicherheit im DFPS-Projekt – die zehn wichtigsten Punkte .... 53116.9 Fazit ...................................................................................... 532

Die sogenannte »letzte taktische Meile« scheint für viele IT-Systeme von Einsatzorganisationen noch immer ein unüberbrückbares Hindernis zu sein. Im vorliegenden Kapitel wird Ihnen der SAP-Vorschlag zur Überbrückung dieses Hindernisses aufgezeigt. 533

17 Mobile Anwendungen ......................................................... 533

17.1 Notwendigkeit von mobilen Anwendungen ........................... 53317.2 Mobile Anwendungen – technische und prozessuale Sicht ..... 536

17.2.1 Welche Technik erlaubt die Flexibilität? ...................... 53717.2.2 Mobile Prozesse ......................................................... 542

17.3 Beispielszenario – Ausfall eines Fahrzeugs im Hilfs- oder Auslandseinsatz ..................................................................... 549

17.4 Fazit ...................................................................................... 554


Inhalt

15

TEIL IV Innovative Anwendungsfelder von DFPSIn diesem Kapitel wollen wir das Thema DFPS im Katastrophenschutz vertiefen und Ihnen zeigen, wie Sie zur Abbildung der spezifischen Prozesse DFPS optimal einsetzen können. 559

18 Katastrophenschutz ............................................................ 559

18.1 Grundlagen ........................................................................... 55918.2 Prozessbereiche und funktionale Blöcke im Katastrophen-

schutz mit DFPS .................................................................... 56118.3 Daten aus den SAP-Verwaltungssystemen nutzen .................. 56618.4 SAP-Lösungen und Leitstellensysteme ................................... 570

18.4.1 Beispiel 1 – Bewältigung von Großschadenslagen –Leitstelle mit verbundenem DFPS-System .................. 572

18.4.2 Beispiel 2 – Mehrere DFPS-Leitstellen fungieren als verbundene Plattform ............................................ 574

18.4.3 Beispiel 3 – Bewältigung von Großschadenslagen – Leitstelle auf SAP-Basis mit angeschlossenen DFPS-System .............................................................. 575

18.5 Stabsarbeit – SAP Interactive Forms by Adobe und DFPS ....... 57518.6 Zusammenfassung ................................................................. 579

19 Performance-Based Logistics – DFPS in der Rüstungs- und Raumfahrtindustrie ................................... 581

19.1 PBL-Konzept ......................................................................... 58219.2 PBL-Prozesse ......................................................................... 58619.3 DFPS-Unterstützung für PBL .................................................. 58719.4 Reporting .............................................................................. 59319.5 Fazit ...................................................................................... 598

Als weiteres innovatives Anwendungsfeld von DFPS erläutern wir im Folgenden die Serviceorientierte Architektur und damit zusammenhängend Network Centric Warfare. 599

20 SOA und Network Centric Warfare mit DFPS .................... 599

20.1 Was ist Network Centric Warfare? ......................................... 59920.1.1 Begriffsbestimmung .................................................... 59920.1.2 DFPS und NCW – Operationalisierung des

Backoffice ................................................................... 60220.2 Serviceorientierte Architektur ................................................ 604

20.2.1 Theoretische Grundlagen ............................................ 60420.2.2 SOA für Einsatzorganisationen .................................... 60820.2.3 SOA am Beispiel des

Szenarios »Logistic Assessment« .................................. 61320.3 Fazit ...................................................................................... 622


Inhalt

16

In diesem Kapitel lernen Sie die Einsatzmöglichkeiten von DFPS bei Polizeibehörden und Nachrichtendiensten kennen und erhalten Leitlinien, wie Sie in diesem besonderen Umfeld Lösungen schnell und effizient implementieren können. 623

21 Polizei und Nachrichtendienste .......................................... 623

21.1 Grundlagen ........................................................................... 62321.2 Szenarien und Prozesse bei Polizeibehörden und

Nachrichtendiensten mit DFPS-Systemen .............................. 62521.2.1 Beispiel 1 – Olympische Spiele im Beispielland A......... 62721.2.2 Beispiel 2 – Durchführung eines Auslandseinsatzes ...... 62921.2.3 Beispiel 3 – Durchführung einer europaweit k

oordinierten Durchsuchung ........................................ 63121.3 Wichtige Hinweise – Projekte für Polizeibehörden und

Nachrichtendienste ............................................................... 63621.4 Fazit ...................................................................................... 638

Wie entwickelt sich die Branchenlösung SAP for Defense & Security? Zum Abschluss des Buches wagen wir einen Blick in die Zukunft. 639

22 Ausblick ............................................................................... 639

645

Anhang ...................................................................................... 645

A Abkürzungen ................................................................................... 647B Literatur ........................................................................................... 651C Die Autoren .................................................................................... 653

Index....................................................................................................... 655


23

Einleitung

Die Branchenlösung SAP for Defense & Security (DFPS) gehört seit Jahren zuden am schnellsten wachsenden Branchenlösungen von SAP. Armeen undSicherheitsbehörden erhalten mit DFPS eine ganzheitliche Lösung zur Abbil-dung ihrer gesamten Prozesse.

Das vorliegende Buch basiert auf mehr als 20 Jahren Erfahrung, die die Auto-ren insgesamt bei der Entwicklung, Implementierung, aber auch Schulungder Lösung sammeln konnten.

Darstellungsziel

Dieses Buch vermittelt Ihnen alle erforderlichen Grundlagen und Kennt-nisse, um eine DFPS-Implementierung erfolgreich bestreiten zu können. Wirstellen darüber hinaus unsere eigenen Implementierungserfahrungen zurVerfügung, damit Sie überprüfen können, ob in Ihrem Projekt Optimie-rungspotenziale vorhanden sind. Zudem finden Sie in diesem Buch vieleweiterführende Informationen, in welchen Bereichen DFPS-Lösungen imp-lementiert werden können, sodass Sie als Berater neue Geschäftsfelder ent-decken können.

An wen richtet sich dieses Buch

Wir wenden uns mit unserem Buch an Projektmitarbeiter in DFPS-Projekten(Projektleiter, Architekten, funktionale Experten, Basismitarbeiter) sowie anexterne Berater in diesen Projekten. Dabei haben wir die Kapitel so verfasst,dass sie von den Grundlagen ausgehend in die Tiefe gehen, sodass Sie auchals Entscheider einen Gewinn von der Lektüre des Buches haben.

Zum Verständnis sind keine tiefen SAP-Kenntnisse über allgemeine Grundla-gen für die Benutzung der Software hinaus (wie etwa die Anmeldung am Sys-tem) vonnöten.

Unsere Beschreibungen basieren auf dem Stand ERP 6.0 mit dem Erweite-rungspaket 4 (EHP 4). Wo dies möglich ist, geben wir Ihnen Ausblicke aufWeiterentwicklungen.


Einleitung

24

Aufbau und Inhalt

Damit Sie einen Wegweiser durch das umfangreiche vorliegende Werkerhalten, möchten wir Ihnen im Folgenden den Aufbau des Buches und denInhalt der einzelnen Kapitel näher vorstellen.

Wir haben das Buch in vier Teile untergliedert, die der Maßgabe folgen, vonden Grundlagen in die Tiefe zu führen. Die Teile I–III empfehlen wir Ihnenunbedingt als unverzichtbare Grundlage für alle Lesergruppen.

Wenn Sie bereits über DFPS-Kenntnisse verfügen, legen wir Ihnen Teil IIIbesonders ans Herz, da wir hier die Implementierungserfahrungen starkgebündelt haben. Erfahrene DFPS-Experten werden insbesondere Teil IV,die Darstellung neuer DFPS-Anwendungsfelder, mit Interesse lesen.

Teil I – Einführung und Grundlagen

Im ersten Teil dieses Buches zeigen wir Ihnen im Einzelnen die für das Ver-ständnis von DFPS erforderlichen Grundlagen auf.

� Kapitel 1, »Einführung in DFPS – Anwendungen in der Praxis«Anhand verschiedener Beispiele wird grundlegend erläutert, welcheFunktionalitäten die Lösung SAP for Defense & Security beinhaltet undwie sie sowohl von Verteidigungsorganisationen als auch von anderenSicherheitsbehörden (z.B. Feuerwehren) eingesetzt wird. Entsprechendberücksichtigen die ausgewählten Beispiele sowohl Streitkräfte (ausDeutschland, Singapur oder der Schweiz) als auch andere Organisationender öffentlichen Sicherheit (der Koordinierte Sanitätsdienst in derSchweiz). Die Darstellung liefert Ihnen damit einen Überblick darüber,welche Anforderungen und Geschäftsprozesse Sie mit der Lösung DFPSabdecken können.

� Kapitel 2, »Fallstudie – Tsunami-Hilfsoperation«In diesem Kapitel werden die inhaltlichen Grundlagen und Anforderungenfür eine Tsunami-Hilfsoperation dargestellt. Diese Fallstudie, die auch fürLeser außerhalb des militärischen Bereichs von Interesse sein wird, dientals Grundlage für die Darstellung der Prozesse in den folgenden Kapiteln.

� Kapitel 3, »Stammdaten und Organisationsstruktur als Grundlage derImplementierung«Aufgrund der umfassenden Integration der Lösung kommt der Implemen-tierung der Organisationsstruktur und des Stammdatenmodells eine zen-trale Bedeutung zu. Für Sie als Leser ist dieses Kapitel entscheidend, da esklar den Unterschied zu einer »normalen« ERP-Implementierung heraus-arbeitet. Zudem wird in diesem Kapitel deutlich werden, dass auch in den


Einleitung

25

Fällen, in denen bei Streitkräften oder Sicherheitsorganisationen zunächstnur ERP (ohne DFPS) implementiert wird, DFPS dennoch bereits bei derDatenmodellierung berücksichtigt werden muss.

Das Kapitel behandelt zudem die konkrete Darstellung der systemtechni-schen Abbildung des Datenmodells.

Teil II – Prozesse, Funktionen, Customizing

In diesem Teil des Buches schildern wir Ihnen die Grundlagen für eineImplementierung von DFPS.

� Kapitel 4, »Operational Planning« In diesem Kapitel werden zunächst die Prozesse dargestellt, die ein Planerbei Streitkräften oder Sicherheitsorganisationen ausführt, wenn es um dieVorbereitung eines Einsatzes geht. Auf Basis der in Kapitel 3 gelegtenGrundlagen wird dann gezeigt, wie dies systemtechnisch in SAP ERP abge-bildet werden kann.

� Kapitel 5, »Implementierung der Prozessgruppe ›Qualification Management‹«Bei den Ressourcen kommt dem Personal und der Notwendigkeit, hier dierichtigen Qualifikationen verfügbar zu haben, besondere Bedeutung zu.Aus diesem Grund gehen wir bei der Darstellung der Prozesse und deranschließenden Beschreibung der systemtechnischen Abbildung intensivauf den Zusammenhang zwischen DFPS und SAP ERP HCM ein.

� Kapitel 6, »Logistik« Logistischen Prozessen kommt gerade bei Einheiten im Einsatz eine spezi-elle Bedeutung zu. Die besonderen Prozesse einer solchen Logistik wer-den dargestellt, auch hier wieder vornehmlich unter Berücksichtigung derIntegration mit den anderen SAP-Komponenten. Daran schließt sicherneut die Darstellung der systemtechnischen Abbildung an.

� Kapitel 7, »Materialwirtschaft« Die Anforderungen an die Prozesse der Materialwirtschaft werdenzunächst wieder mit Rückbezug auf die Tsunami-Fallstudie erläutert.Daran schließt sich die Darstellung der systemtechnischen Abbildung an.

� Kapitel 8, »Instandhaltung«Auf Basis der umfassenden Integration können sehr komplexe Instandhal-tungsprozesse abgebildet werden. Diese Prozesse werden zunächst darge-stellt und dann in ihrer Abbildung im System detailliert beschrieben.


Einleitung

26

� Kapitel 9, »Unterstützung des Flugbetriebs«Für den Bereich des Flugbetriebs als der »Königsdisziplin« der Instandhal-tung wird die Darstellung des vorangegangenen Kapitels fortgeführt undvertieft.

� Kapitel 10, »DFPS und Rechnungswesen«Die vielfältige Vernetzung von DFPS mit dem Rechnungswesen ist zentra-ler Bestandteil der Prozessbeschreibung. Auf dieser Basis wird dann diesystemtechnische Einrichtung dargestellt.

� Kapitel 11, »Berichtswesen/Reporting« Das Berichtswesen fasst die Daten aus den einzelnen Bereichen zusam-men. Prozesse wie die Bestimmung des Bereitschaftsgrads (OperationalReadiness) werden hier dargestellt. Anschließend erhalten Sie die erfor-derlichen Informationen, um ein Berichtswesen im System einzurichten.

Teil III – Erfahrungen aus Implementierungsprojekten

Die vielfältigen Integrationsaspekte und die Größe der Projekte machen einDFPS-Projekt zu einem herausfordernden Vorhaben. In diesem Teil möchtenwir Ihnen eine Zusammenfassung unserer vielfältigen Implementierungser-fahrungen geben. Dabei geht es sowohl darum, herauszuarbeiten, was getanwerden soll (Do’s), aber auch, was unbedingt unterlassen werden soll(Dont’s). Sie erhalten damit das notwendige Wissen, um Ihr DFPS-Projekt zuplanen, die notwendigen Mitarbeiter auszuwählen und zentrale inhaltlicheFestlegungen zu treffen.

� Kapitel 12, »IT-Architektur als Herausforderung für Armeen undSicherheitsorganisationen« Die umfassende Integration der DFPS-Lösung mit verschiedenen Systemenstellt hohe Anforderungen an die Lösungsarchitektur. Das Kapitel enthälthier eine Checkliste von Do’s and Dont’s für eine gute Lösungsarchitektur.Auf dieser Liste bauen die nachfolgenden Kapitel mit den SchwerpunktenSicherheit, dezentrale Systeme und mobile Anwendungen auf.

� Kapitel 13, »Rollen im DFPS-Projekt«Dieses Kapitel bietet Ihnen eine Übersicht darüber, welche Rollen undFähigkeiten Sie im Projekt besonders betonen sollten. Die Größe der Vor-haben stellt besondere Anforderungen an die Projektteams, die hier imEinzelnen dargestellt werden.

� Kapitel 14, »Projekt- und Risikomanagement« Die umfassende Erfahrung der Autoren ermöglicht es, die spezifischenAnforderungen an ein Projekt- und Risikomanagement für ein DFPS-Pro-


Einleitung

27

jekt detailliert darzustellen. Zudem werden die häufigsten Projektrisikenaufgezeigt.

� Kapitel 15, »DFPS und die Prozesse des Personalwesens« Dieses Kapitel greift ein häufiges Projektrisiko auf: die Interaktion vonSAP for Defense & Security mit dem Personalwesen. Spezifika dieser Inter-aktion werden anhand des Einsatzplanungsprozesses aus Kapitel 4beschrieben. Es werden die damit verbundenen Herausforderungen undLösungsmöglichkeiten umfassend dargestellt.

� Kapitel 16, »Sicherheit und Berechtigungen« Die Fragen nach der Sicherheit des Systems stehen im Mittelpunkt vielerArchitekturdiskussionen in Projekten. Dieses Kapitel knüpft daran an,indem es aufzeigt, welche Sicherheitskonzepte sich besonders bewährthaben und wie spezifische Berechtigungsfunktionen in SAP for Defense &Security optimal genutzt werden können.

� Kapitel 17, »Mobile Anwendungen«Mit der Frage der Sicherheit ist die Frage nach dezentralen und mobilenSystemen verknüpft. Deshalb werden in diesem Kapitel insbesondere dieVerteilungsmechanismen und die Offlinefähigkeiten dargestellt, die fürDFPS entwickelt wurden.

Teil IV – Innovative Anwendungsfelder von DFPS

Dieser Teil gibt Ihnen einen Überblick über neue DFPS-Anwendungsfelder,die sich in den letzten Monaten in den Projekten entwickeln bzw. von Vor-denkern in den Streitkräften entwickelt wurden und derzeit erprobt werden.Dabei wird wiederum auf Basis bereits vorhandener Projekterfahrungen auf-gezeigt, wie diese neuartigen Anforderungen mit den DFPS-Funktionalitätenumgesetzt werden können.

� Kapitel 18, »Katastrophenschutz«Die gesteigerten Anforderungen im Katastrophenschutz erfordern eineModernisierung der IT-Systeme. In diesem Kapitel zeigen wir Ihnen auf,welche besonderen Aspekte Sie bei Implementierungen in diesem Bereichbeachten müssen. Dabei erfahren Sie auch, wie Sie die Implementierungschlank halten können, da die Budgetmittel hier oftmals sehr beschränktsind.

� Kapitel 19, »Performance-Based Logistics – DFPS in der Rüstungs- undRaumfahrtindustrie« Rüstungshersteller gehen zunehmend dazu über, Armeen Fähigkeiten zuverkaufen (z.B. Flugstunden). In diesem Kapitel wird dargestellt, wie dieHersteller mit ihren Systemen in DFPS integriert werden können.


Einleitung

28

� Kapitel 20, »SOA und Network Centric Warfare mit DFPS« Die Notwendigkeit, Ad-hoc-Informationen auszutauschen und umfas-sende Lagebilder zu erarbeiten, hat SOA und Network Centric Warfare zueinem wichtigen Thema für DFPS werden lassen. Dieses Kapitel enthältnicht nur die erforderlichen Implementierungsinformationen dazu, son-dern auch Erfahrungsberichte aus zentralen Projekten der NATO wie derCWID (Coalition Warrior Interoperability Demonstration).

� Kapitel 21, »Polizei und Nachrichtendienste«Polizeibehörden und Nachrichtendienste haben besondere Anforderun-gen an eine Softwareunterstützung, vor allem im Bereich des Geheim-schutzes. Hier geben wir Ihnen die erforderlichen Grundlagen an dieHand, um auch in diesem Bereich Projekte erfolgreich zu implementieren.

� Kapitel 22, »Ausblick«Falls Sie DFPS bereits im Einsatz haben, stellen Sie sich sicherlich dieFrage, wie sich die Lösung DFPS in Zukunft weiterentwickeln wird. DieseInformationen erhalten Sie in einem abschließenden Ausblick. Dabei istnicht allein aufzuzeigen, welche Einzelfunktionalitäten in Zukunft entwi-ckelt werden, sondern vielmehr den konzeptionellen Rahmen seitens SAPin den Mittelpunkt zu rücken, auf dessen Grundlage sich DFPS in Zukunftweiterentwickeln wird.

Im Anhang des Buches finden Sie häufig verwendete Abkürzungen und hilf-reiche Literaturtipps.

Hinweise zur Lektüre

In diesem Buch finden Sie viele grau hinterlegte Informationskästen, dieZusatzinformationen bieten. Neben diesen Kästen finden Sie verschiedeneSymbole, die Ihnen die Orientierung erleichtern sollen. Dies sind im Einzel-nen folgende:

� Mit diesem Symbol haben wir Tipps gekennzeichnet, die Ihnen spezielleEmpfehlungen zur Arbeitserleichterung geben, oder Hinweise, die Infor-mationen zu weiterführenden Themen enthalten.

� Das Symbol Achtung macht Sie auf Themen oder Bereiche aufmerksam,bei denen Sie besonders achtsam sein sollten.

� Beispiele haben wir mit diesem Symbol kenntlich gemacht; es weist aufSzenarien aus der Praxis und auf die Erläuterungen hin, wie die Funktio-nen im Einzelnen eingesetzt werden.


Einleitung

29

� Kapitel 2 beschäftigt sich mit einer Fallstudie über einen Tsunami-Hilfs-einsatz. Mit diesem Symbol sind Inhalte gekennzeichnet, die diese Fallstu-die in den übrigen Kapiteln des Buches wieder aufgreifen.

Wir hoffen, dass Ihnen dieses Buch bei allen Ihren Aufgaben hilft, die mitDFPS zusammenhängen, und freuen uns auf Ihr Feedback. Zunächst wün-schen wir Ihnen jedoch viel Vergnügen bei der Lektüre.

Danksagung

Die vorliegende Darstellung der vielfältigen Lösung DFPS wäre ohne dieUnterstützung vieler Experten nicht möglich gewesen. Hierbei gilt unserbesonderer Dank den Kollegen der SAP AG im Solution Management und inder Entwicklung sowie den Beratungskollegen im globalen Defense & Secu-rity Hub, die gemeinsam mit uns Projekte auf der ganzen Welt implementie-ren.

Persönlich möchten wir unseren Dank richten an:

Nicole Borsdorf, Markus Holger Erb, Dirk Fischer, Kai Finck, Fred Grunow,Sebastian Hodapp, Volker Lehnert, Hans Peukert, Stephan Rupf, GuidoSchlief, Dirk Schmidt, Timo Schuette, Sylvia Strangfeld, Marc von der Lin-den, Ralf Wagner, Josef Wittmann, Nora Fischer, Florian Tischhäuser, MarcKeller, Fabian Kunz, Marcus Ophees, Al Johnson, Michaela Goldmann-Friedsam, Yvonne Missbach, José Sanchez, Peter Trentz, Sanda Prigara,Lana Molotova, Sawwas Athanasiadis, Armel Akle, Martin Janssen, BobCowley.

Uns ist bewusst, dass wir mit diesem Projekt unseren Familien in den letztenMonaten einiges zugemutet haben. Wir danken unseren Lebenspartnerin-nen, Frauen und Kindern dafür, dass sie uns zu diesem Vorhaben ermutigtund uns stets den Rücken frei gehalten haben.

Zuletzt möchten wir unseren Lektoren bei SAP PRESS Patricia Kremer undFrank Paschen für ihre engagierte Betreuung und die gute Zusammenarbeitdanken.

Bernhard Escherich, Heinrich Pfriemer und Wolfgang Ullwer


53

Eine gewaltige Naturkatastrophe in einem Land am Rande des Pazi-fiks bildet den fiktiven Hintergrund für unsere Fallstudie. Wir zei-gen, wie SAP for Defense & Security die Einsatzkräfte bei der Bewäl-tigung dieses Szenarios unterstützt.

2 Fallstudie – Tsunami-Hilfsoperation

Im vorliegenden Kapitel werden die Grundlagen für die Fallstudie gelegt, dieuns im weiteren Verlauf dieses Buches begleiten soll. Wir nehmen dabei an,dass sich in dem fiktiven Land Lhamosa eine Naturkatastrophe ereignet. DieEinsatzkräfte dieses Landes setzen ihr gesamtes Wissen und Können, ihremateriellen und immateriellen Ressourcen dazu ein, Menschenleben zu ret-ten, die Erstversorgung der Opfer zu gewährleisten und Schäden zu beseiti-gen. Dabei stehen ihnen internationale Hilfsorganisationen zur Seite. MitSAP for Defense & Security steht den Einsatzkräften eine Software zur Verfü-gung, die einerseits für organisatorische Flexibilität sorgt, indem sie rascheAnpassungen der Organisationsstrukturen an die jeweiligen einsatzspezifi-schen Anforderungen ermöglicht, und die andererseits die logistischen Pro-zesse bei der Durchführung des Einsatzes durchgängig unterstützt.

2.1 Ausgangslage

Zum Einstieg in die Fallstudie machen wir Sie mit den Gegebenheiten vorOrt vertraut. Darüber hinaus geben wir einen kleinen Einblick in den gegen-wärtigen Stand der Technik bei der Errichtung von Vorwarnsystemen.

Alltag in Ghuanawesi – die Ausgangslage

Zu Beginn des Szenarios, an einem gewöhnlichen Samstag, befinden sich Polizeiund Sicherheitsorgane des fiktiven Landes Lhamosa im Bereitschaftszustand, siewerden von den Ereignissen ebenso überrascht wie die internationale Öffentlich-keit. Wir gehen in unserer Fallstudie davon aus, dass in der RegionalhauptstadtGhuanawesi zu diesem Zeitpunkt eine kleine Polizeiwache mit zwei Personenbesetzt ist.


Fallstudie – Tsunami-Hilfsoperation2

54

So weit die Ausgangslage für unsere Fallstudie. Wenn wir die beschriebeneSituation in einem SAP-System widerspiegeln wollen, müssen wir Datensätzefür die Polizeiwache, die Personen, den Pickup sowie für die Wasserkanisteranlegen und die Daten zueinander in Beziehung setzen. Wir nennen die rela-tiv beständigen Datensätze die Stammdaten der Objekte. Da für die Beschrei-bung einer Person andere Eigenschaften von Bedeutung sind als zur Abbil-dung eines Fahrzeugs, stellt die Software dafür unterschiedliche Datenobjektemit unterschiedlichen Attributen bereit. Die einfachste Form der branchenspe-zifischen Softwareunterstützung besteht darin, spezielle Felder für diejenigenAttribute bereitzustellen, die nicht im SAP-Standard enthalten sind, um so z.B.den militärischen Rang einer Person oder den Organisationsbereich einer Ein-heit darstellen zu können. Noch höher entwickelte Branchenlösungen haltenfür spezielle Anforderungen sogar eigene Stammdatenobjekte bereit – in DFPSfinden Sie beispielsweise Einsatzkontingente. Darüber hinaus unterstützenBranchenlösungen neben den Standardabläufen auch branchenspezifischeProzesse, wie beispielsweise die Planung und Einrichtung einer Polizeistation.Das Funktionsangebot wird komplettiert durch speziell zugeschnitteneReports und eigens erstellten BI Content (d.h. Inhalte in Business-Intelligence-Systemen, die branchenspezifische Informationsbedarfe befriedigen).

DFPS ist zur Modellierung der Ausgangslage unserer Fallstudie u.a. deshalbso gut geeignet, weil hier nicht nur das Vorhandensein von Personen oderAusrüstung eine Entsprechung im System findet, sondern auch der bereitsbeschriebene Mangel an personellen und technischen Ressourcen abgebildetwerden kann – und weil es seine Abstellung prozessual unterstützt. Selbstdie unscharfe Vorgabe, dass eine Polizeiwache über zwei »geländegängigeFahrzeuge« verfügen soll, kann in dieser Form in DFPS hinterlegt und füreinen Lagebericht oder im Rahmen von Folgeprozessen mit dem einen tat-sächlich vorhandenen Toyota in Beziehung gebracht werden.

Im Land Lhamosa herrscht ein grundlegender Mangel an personellen und techni-schen Ressourcen, der in vielen öffentlichen Gebäuden augenfällig ist. Eine regio-nale Polizeiwache sollte den Papieren nach mit zwei geländegängigen Fahrzeugenausgerüstet sein und, im Falle von Stationen an der Küste, ein Boot mit Außen-bordmotor zur Verfügung haben.

Die Realität stellt sich anders dar. Vom Fenster der Polizeiwache in Ghuanawesiaus kann man den kleinen Fischereihafen sehen, doch keines der dort vor Ankerliegenden Boote gehört der Polizei. Auf der Ladefläche des vor der Tür geparktenToyota Pick-ups stehen zwei große Wasserkanister, die gelegentlich zur Versor-gung der in den abgelegeneren Gebieten lebenden Einwohnern eingesetzt wer-den, denn die kommunale Trinkwasserversorgung arbeitet nur unzuverlässig. Diesebeiden Kanister werden bald von großem Nutzen sein.


Ausgangslage 2.1

55

So weit der Beginn unseres Szenarios. Wir werden im Laufe dieses Bucheserfahren, wie sich die Ereignisse weiter entwickeln. Fürs Erste haben wirgesehen, dass es in Ghuanawesi eine Polizeiwache mit zwei Beamten gibt,die über einen Pick-up, zwei Kanister und kein Boot verfügen.

SAP for Defense & Security bietet uns die Möglichkeit, diese Polizeiwache imSystem abzubilden, in den Gesamtzusammenhang der Organisation einzu-ordnen, sie wiederzufinden und die unterschiedlichsten Prozesse organisati-onsbezogen zu unterstützen. Selbst der Außenbordmotor könnte mitSystemunterstützung repariert und betankt werden, wenn das Boot denn zurVerfügung stünde. Sogar dieser drastische Unterschied zwischen Soll und Istin der Anzahl verfügbarer Boote kann softwaregestützt ermittelt und gegebe-nenfalls durch die Einleitung eines Nachschubvorgangs beseitigt werden.

Abbildung 2.1 zeigt einen Ausschnitt aus der Organisationsstruktur der Poli-zei von Lhamosa. Diese Struktur können Sie auch in DFPS abbilden. Sie fin-den die Polizeiwache von Ghuanawesi im sogenannten Navigationsbereich inder linken oberen Ecke der Struktur-Workbench. Unten links finden Sie diezugeordnete Ausrüstung, das »materielle Soll«. Rechts, im Detailbereich,erkennen Sie eine ganze Reihe Registerkarten mit fachlich gegliederten

Dunkle Vorzeichen – moderne Vorwarnsysteme

Doch noch ist in Ghuanawesi alles ruhig. Auslöser des Tsunamis ist ein Seebebenweit draußen im pazifischen Ozean, das sich an Land kaum bemerkbar macht. Vonden vergleichsweise geringen Erdstößen fühlen sich die Bewohner und Touristennicht im Mindesten alarmiert – wenn sie es denn überhaupt bemerken. ErsteAnzeichen für die sich anbahnende Katastrophe werden jedoch im pazifischenOzean registriert.

Seit der Implementierung eines Tsunami-Warnsystems ist es möglich, über diegezielte Beobachtung physikalischer Parameter (wie z.B. den Wasserdruck) kriti-sche Situationen vorherzusehen; zumindest hat sich dadurch die Vorwarnzeitdeutlich verlängert. Die Verantwortlichen werden im Idealfall mehrere Stundenvor dem Auftreffen der Flutwelle alarmiert und können entsprechende Vorkehrun-gen treffen. Selbstverständlich steht diese Vorwarnzeit in Abhängigkeit von derEntfernung des Epizentrums zu den jeweiligen Küstengebieten. Es existiert dazuheute im Internet umfangreiches Kartenmaterial, z.B. auf den Seiten des amerika-nischen National Geophysical Data Centre (NGDC) oder des Pacific Marine Environ-mental Laboratory (PMEL). Interaktive Seekarten ermöglichen den Benutzern, inSimulationsrechnungen die relative Lage eines Seebebens einzugeben. Die ermit-telten Laufzeiten bis zum Auftreffen auf die Küste werden mittels konzentrischerKreise in der Karte dargestellt.

Wir gehen in unserer Fallstudie davon aus, dass das Epizentrum ca. 1.000 Seemei-len vor der Küste von Lhamosa liegt.



56

Informationen, in unserem Beispiel die Grunddaten. Dem Bearbeiter erlau-ben diese Informationen, auf sein jeweiliges Sachgebiet passend zugeschnit-tene Entscheidungsgrundlagen bezüglich der Organisationsstruktur durcheinfache Navigation vorzufinden.

Abbildung 2.1 Fallstudie – Polizeistruktur im fiktiven Land Lhamosa

Eine ähnlich aufgebaute, wenn auch im Detail weitaus komplexere Strukturexistiert auch im SAP-System der internationalen Hilfsorganisationen sowiein den SAP-Systemen der Streitkräfte befreundeter Staaten. DFPS bietet dieMöglichkeit, dank sogenannter Verwendungstypen Organisationsstrukturen(OrgStrukturen) für unterschiedliche Zwecke im SAP-System zu hinterlegen,also sowohl eine Organisationsstruktur für die Aufbauorganisation als auchfür den Verteidigungsfall oder, wie in unserem Fall erforderlich, eine spezi-fische Struktur für einen Einsatz zu definieren.

Abbildung 2.2 zeigt die Aufzeichnung einer Tsunami-Warnstation vom 29.September 2009 durch eine Boje im Pazifik, 610 Seemeilen nordöstlich vonSaipan. Man erkennt deutlich die kurzfristigen Pegelschwankungen, die sichhier im Bereich einiger Zentimeter bewegen. Auslöser dafür war ein Bebender Stärke 8,1 in Höhe der Samoa Islands, das zu einer mehr als drei Meterhohen Flutwelle in Pago Pago auf Amerikanisch-Samoa führte, die in ihremganzen Ausmaß 180 Menschenleben forderte.

Der Tsunami wird ausgelöst – die Welle entsteht

Fischer, die sich zum Zeitpunkt des Bebens auf See befinden, bemerken die Wellemeist gar nicht. Ihr Boot bewegt sich kaum. Im offenen Ozean ist eine Tsunami-Welle nur wenige Zentimeter hoch, und sie bewegt sich mit unvorstellbaren 800Kilometern pro Stunde – was der Geschwindigkeit eines Passagierflugzeugs ent-spricht – auf die Küste zu. Die Energie der Welle reicht von der Meeresoberflächebis zum Meeresboden. Dass auf hoher See davon kaum etwas zu spüren ist, liegtu.a. daran, dass die Welle so lang ist, dass zwischen den einzelnen Wellenkämmen100 bis 300 Kilometer liegen können.


Tsunami 2.2

57

Abbildung 2.2 Aufzeichnung des Wasserstands im Pazifik am 29.09.2009

2.2 Tsunami

Erst wenn sich die Welle der Küstenlinie nähert, verliert sie ihre scheinbareNormalität, und die Energie wird auf weit kleinerem Raum konzentriert. Hier-bei türmen sich riesige Wellen auf, die alles vernichten können, was auf ihremWeg liegt. Das japanische Wort Tsunami bedeutet lange Hafenwelle oderWelle im Hafen und wird seit einer wissenschaftlichen Konferenz im Jahre1963 weltweit für diese Form der Riesenwellen verwendet [SCINEXX2009].

In ihren SAP-Systemen können die Hilfsorganisationen Standorte (wie z.B.die Bucht von Ghuanawesi) mit Adressdaten versehen – dies ist Standard inSAP ERP. Branchenspezifisch für DFPS ist die Möglichkeit, zu Strukturele-menten (in unserem Fall zur Polizeiwache von Ghuanawesi) sogenannte Geo-lokationen anzulegen, mit deren Hilfe die Strukturelemente im geografischenKoordinatensystem verortet werden können. Zusätzlich dazu ergeben sichreichhaltige Möglichkeiten aus der Kopplung des SAP-Systems mit einemGeoinformationssystem (GIS).

Noch bevor die Welle auf den Strand trifft und der Tsunami die Stadt Ghua-nawesi verwüstet, haben Sensoren auf der ganzen Welt das Beben registriertund Bojen, wie die bereits erwähnte Messstation im Pazifik, die Schwankun-gen des Wasserspiegels über Satellitenverbindungen an die Beobachtungs-stationen übermittelt. Mithilfe von Simulationstools und spezieller Seekar-ten können die Laufzeiten der Tsunami-Wellen ermittelt werden.

Sie erkennen im unteren Bereich von Abbildung 2.3 den nördlichen RandAustraliens, oben rechts ist die eingangs erwähnte Messstation nordöstlichvon Saipan verzeichnet.



58

Abbildung 2.3 Karte des betroffenen Gebiets

In unserer Fallstudie können wir davon ausgehen, dass aufgrund der Lagedes Epizentrums die gefährdeten Gebiete identifiziert und Flutwarnungenausgegeben werden. In unserem Beispiel beträgt die Entfernung 1.000 See-meilen, d.h., etwa zwei bis drei Stunden nach dem Beben wird mit dem Auf-treffen der Flutwelle zu rechnen sein. Dementsprechend sind auch die Ein-satzkräfte der Nachbarstaaten in Alarmbereitschaft versetzt worden.

Flutwarnung für die pazifischen Küstengebiete

Dank der beschriebenen Vorwarnsysteme erfahren die staatlichen Stellen imInnenministerium von Lhamosa sehr frühzeitig von der drohenden Katastrophe.Umgehend wird für den gesamten Küstenbereich Alarm ausgelöst. In der Polizei-wache von Ghuanawesi schrillt das Telefon. Mitarbeiter des Technischen Hilfs-werks aus Deutschland, die sich im Auftrag der Bundesregierung in der ProvinzGhuanawesi aufhalten, sind per SMS informiert worden. Jetzt ist rasches Handelngefragt. Als Erstes müssen die Anwohner entlang der Küste gewarnt werden. Diebeiden Polizisten springen in den Toyota. Die Leute vom THW versuchen, Kontaktmit der Einsatzzentrale zu bekommen. Doch auch sie müssen zunächst einmalselbst aus der Gefahrenzone gelangen.


Tsunami 2.2

59

Leider reichen die Vorwarnzeiten bedingt durch die kurze zeitliche Distanznicht aus, um sämtliche Bewohner der am stärksten betroffenen Gebieterechtzeitig zu evakuieren. Daher kommt es zunächst darauf an, diePolizeikräfte und Katastrophenschützer vor Ort möglichst rasch zu informie-ren, jede Minute zählt. Von besonderer Bedeutung ist demnach das rei-bungslose Ineinandergreifen der Informationskette. Als große Herausforde-rung erweist sich in unserem Fall die rasche Information der Bevölkerung. Esgilt, Paniksituationen zu vermeiden, aber dennoch in aller Deutlichkeit aufdie Gefahrenlage hinzuweisen.

Bessere Schulbildung, die sich durchaus auch des traditionellen Volksglau-bens, wie z.B. der Erzählung vom Smong, bedienen sollte, kann in einem sol-chen Fall lebensrettend sein. Dieser Mythos beschreibt die Gefahren einerÜberflutung sehr plastisch und macht, da er schon Kindern in der Schule ver-mittelt wird, nachhaltig auf Anzeichen einer drohenden Überschwemmungaufmerksam: Der plötzlich fallende Wasserspiegel ist für derart informierteBevölkerungskreise ein tief verwurzeltes Alarmsignal. Selbst Kinder verste-hen es, die Anzeichen der Natur zu deuten: Wenn das Wasser verschwindet,bleibt nur noch wenig Zeit.

Erste Hilfe – die Welle kommt

Mit ohrenbetäubendem Lärm und atemraubender Gewalt kehrt das Wasserzurück. Eine gigantische Flutwelle bricht über Ghuanawesi herein, reißt alles mit,was sich ihr in den Weg stellt. Boote werden weit ins Landesinnere getragen,Autos fortgespült und Bäume ausgerissen. Die Besatzung der Polizeiwache hat sichin einen auf einer Anhöhe befindlichen dreistöckigen Hotelneubau geflüchtet.Gemeinsam mit dem Personal versucht sie, Hotelgäste aus den überfluteten unte-ren Stockwerken zu retten.

Was der Welle nicht schon beim ersten Überrollen zum Opfer gefallen ist, wirddurch den gewaltigen Sog zerstört, mit dem sich das Wasser zurück ins Meerbewegt, eine Lawine aus Schlamm, Geröll und aufgrund der mitgerissenen Gegen-stände, Splitter und Scherben voller Gefahren. Viele Menschen haben Schnittver-letzungen davongetragen. Immer wieder versuchen die beiden Polizisten, mit ihrenFunkgeräten Meldung von der Katastrophe zu machen und Hilfe anzufordern.

Leider kommt keine Verbindung zustande, sodass sie ganz auf sich selbst angewie-sen sind, um die Aktivitäten vor Ort aus dem Hotel, in das sie sich gerettet haben,heraus zu koordinieren. Durch gezielte Ansprache ist es ihnen rasch gelungen,unter den Touristen Helfer zu rekrutieren: Gemeinsam mit einer Krankenschwesteraus Dresden und einem am Knie verletzten australischen Medizinstudenten küm-mern sich die Polizisten um die Verletzten. Die Besitzerin des Hotels bemüht sichunterdessen, die mit ihr befreundeten Personen vom Technischen Hilfswerk perMobiltelefon zu erreichen.



60

2.3 Rettungsoperationen mit DFPS-Unterstützung

Währenddessen laufen in den Einsatzzentralen rund um den Globus die Pla-nungen an. Die Armee von Singapur, das Technische Hilfswerk in Deutsch-land sowie die Metropolitan Fire Brigade (MFB) in Melbourne greifen dabeiauf vordefinierte Einsatzstrukturen zurück. In der Hauptstadt von Lhamosawerden die personellen und materiellen Ressourcen für den Einsatz mitDFPS identifiziert und zugeordnet.

An die Rolle des Einsatzleiters werden besondere Anforderungen gestellt,die als Qualifikationsblöcke im System hinterlegt sind. Bei der Suche nachgeeigneten Personen spielen in unserem Fall Sprachkenntnisse eine beson-dere Rolle. Diese Anforderung engt den verfügbaren Personenkreis weiterein, doch rasch wird ein Kandidat identifiziert.

Da sich die Größe der Naturkatastrophe, insbesondere die Ausdehnung derbetroffenen von der Versorgung abgeschnittenen Gebiete, und die Anzahlder Opfer derzeit noch nicht abschätzen lassen, wird die Größe des Einsatzeszunächst auf Basis der verfügbaren Ressourcen bestimmt; die Transportkapa-zität erweist sich dabei als limitierender Faktor.

Der designierte Einsatzleiter weist an, dass alle verfügbaren Trucks und Pick-ups für einen Straßentransport bereitzustellen sind. In DFPS sind Trucks undPick-ups jeweils als Materialplanungsobjekte den Transportzügen der Ein-satzkräfte zugeordnet. Das bedeutet, dass es für die Planung zunächst keineRolle spielt, ob es sich bei einem mittelschweren Truck um einen Fünftonneraus skandinavischer, koreanischer oder deutscher Produktion handelt; ent-scheidend für die generische Planung ist in diesem Fall die Transportkapazi-tät. Als weitere Materialplanungsobjekte sind den Transportzügen Funkge-räte sowie Lademittel zugeordnet.

Diesem sogenannten materiellen Soll steht ein Ist gegenüber, das nun nichtmehr generisch ist, sondern aus konkreten individuellen Trucks, Funkgerä-ten und Gabelstaplern besteht. Bald schon stellt sich als Ergebnis des Soll-Ist-

Blitz-Recruiting – der Einsatzleiter ist gefunden

Grau ist alle Theorie. Zwar bestünde durchaus die Möglichkeit, durch eine System-abfrage die Anforderungen an einen Einsatzleiter mit den vorhandenen Qualifika-tionen der infrage kommenden Kandidaten abzugleichen. Doch die Zeit drängt,und so spielen am Ende persönliche Beziehungen die größere Rolle. FehlendeSprachkenntnisse müssen in Kauf genommen werden, wenn der Posten nicht län-ger unbesetzt bleiben soll.


Rettungsoperationen mit DFPS-Unterstützung 2.3

61

Vergleichs für die Strukturelemente der Transportzüge heraus, dass zwischender im Soll vorgegebenen Anzahl und dem tatsächlichen Ist-Bestand eindeutliches Delta klafft. Diese Diskrepanz droht den Erfolg des gesamten Ein-satzes infrage zu stellen, denn mit lediglich 50 Prozent der geplanten mittel-schweren Trucks kann ein Transportzug nicht als einsatzbereit gelten.

Um diese beträchtliche Lücke zu schließen, wird rasch der Prozess der materi-ellen Planung mittels der Struktur-Workbench initiiert. Dabei wird der Stan-dardversorger der Transportzüge ermittelt, der ebenfalls durch ein Strukturele-ment im SAP-System repräsentiert ist. Die Strukturelemente der Transportzügeund die Strukturelemente ihrer Standardversorger sind miteinander durcheine Versorgungsbeziehung verbunden. Dabei kann es durchaus unterschiedli-che Versorgungsbeziehungen geben, je nachdem, ob es sich um die normaleAufbauorganisation handelt oder, wie in unserem Fall, um einen Einsatz.

Bei der Entwicklung von DFPS fanden die logistischen Strukturen in Vertei-digungsorganisationen Berücksichtigung. Somit sind wir in der Lage, zwi-schen verbrauchenden Truppenteilen (VTT), Versorgern, Depots und derIndustrie zu unterscheiden.

Das DFPS-System kann die zeitliche Befristung dieser Leihe berücksichtigenund darüber hinaus automatisch eine Rücklieferungs-Banf erzeugen, umbereits von Beginn an die später erforderliche Rücklieferung vorzubereiten.Den besonderen Anforderungen an rasche Bearbeitungsgänge im EinsatzRechnung tragend, kann die Banf ohne komplizierte Freigabestrategie ineine Bestellung umgewandelt werden. Diese wird, wie es auch der SAP-Stan-dard vorsieht, über die Stationen Auslieferung, Warenausgang beim Versor-ger und Wareneingang beim Empfänger, d.h. jeweils bei unseren Transport-zügen, prozessiert. Der Soll-Ist-Vergleich ist nunmehr ausgeglichen, dieEinsatzbereitschaft der Transportzüge gewährleistet.

Die erforderlichen Hilfsgüter sind im System im Gegensatz zu Funkgeräten,Trucks und Lademitteln nicht als Materialplanungsobjekte hinterlegt. Statt-

Logistische Strukturen

Die Transportzüge in Ghuanawesi profitieren von dem Umstand, dass ihre Versor-gungsbeziehungen direkt auf das zentrale Materialdepot von Lhamosa verweisen.Unser Versorger ist demnach das Depot.

Glücklicherweise hat unser Versorger einen ausreichenden Bestand an mittel-schweren Trucks, sodass direkt von der Struktur-Workbench aus eine Bestellanfor-derung (Banf) erzeugt werden kann. Die fehlenden Trucks werden somit beimDepot angefordert – allerdings nur temporär, es handelt sich um eine Leihe.



62

dessen erleichtert DFPS die Planung bezüglich der Verbrauchsmaterialien mit-hilfe sogenannter Vorratspakete. Für unseren Einsatz sind hier gefüllte Frisch-wasserkanister, Decken, Sanitätsmaterial und haltbare Verpflegung jeweils alseigene Pakete angelegt und unseren Strukturelementen zugeordnet.

Diese Information muss der Einsatzleitung schnellstmöglich zur Verfügunggestellt werden, denn aufgrund der Nichtverfügbarkeit von Transportwegensind sämtliche weiteren Hilfslieferungen ebenfalls blockiert. Nachdem derLandweg offenbar verschlossen ist, muss dringend eine Alternativrouteerschlossen werden. Der Einsatzleiter weist daraufhin an, Transporte mitdem Boot der Polizeiwache zu unterstützen. Wie wir uns erinnern, existiertdieses Boot leider nur als Soll-Vorgabe, oder technisch ausgedrückt: Der Ist-Bestand an Booten ist gleich null.

Lokale Sicherheitsmaßnahmen erschweren die Hilfe auf dem Landweg

Um die Sicherheit im Katastrophengebiet zu gewährleisten, werden strikte Zugangs-beschränkungen erlassen, deren Einhaltung durch lokale Polizeiorganisationengewissenhaft überwacht wird. Leider fällt unser Transportzug dieser Gründlichkeitbeinahe zum Opfer, ein Teil der Vorräte wird konfisziert. Glücklicherweise kommtdann doch dank des mitgeführten Funkgeräts eine Verbindung zum Einsatzleiterzustande, und schon nach drei Stunden wird dem Transport die Weiterfahrt gestattet.

Allerdings wird nach dreißig weiteren Kilometern der Zugang in den Distrikt Ghu-anawesi erneut verwehrt, was wiederum zu zeitraubenden Diskussionen führt.Diesmal hat die Strenge der Beamten an der Straßensperre tatsächlich einen nach-vollziehbaren Grund: Gut zweihundert Meter weiter hat die Flutwelle die Straßebuchstäblich fortgerissen, und dies sind nur die Vorboten der unheilvollen Zerstö-rung. Den Berichten vermehrt anzutreffender Passanten zufolge, die auf der Fluchtvor dem Wasser zwar ihr Leben retten konnten, nun aber auf der Suche nach Was-ser, Verpflegung oder Hilfe bei der Bergung ihrer Angehörigen dem Konvoi entge-gengehen, sind sämtliche Straßenverbindungen für Fahrzeuge unpassierbar.

Lufttransporte – Beginn der internationalen Zusammenarbeit

Die Pannen in der jüngsten Vergangenheit haben das ohnehin angekratzte Imagedes Einsatzleiters weiter beschädigt. Zudem besteht keine Chance, die Hilfsbedürf-tigen auf dem Landweg zu erreichen.

Inzwischen hat sich die Erkenntnis in der Einsatzzentrale von Lhamosa durchge-setzt, dass es zu Lufttransporten keine Alternative gibt. Ebenfalls ohne Alternativeist die Überlegung, sich noch einmal mit der Personalie des Einsatzleiters zubeschäftigen. Vielleicht lohnt es sich doch, einen Abgleich der im System hinter-legten Qualifikationen mit den Anforderungen an die Rolle durchzuführen und aufausreichende Englischkenntnisse zu achten?


Rettungsoperationen mit DFPS-Unterstützung 2.3

63

DFPS unterstützt die Einsatzleitung nun bei der Formulierung von Einsatz-zielen, bei der Zuweisung von Aufgaben an Organisationseinheiten durchTask Catalogues, anhand derer die am besten geeigneten Einheiten ausge-wählt werden können. Darüber hinaus erleichtert die Verwendung vongenerischen Katalogisierungen wie dem Reportable Item Code (RIC) interna-tionalen Organisationen die Kommunikation von Angebot und Bedarfen anTransportkapazität über Länder- und Systemgrenzen hinweg. Damit lassensich Trucks, Kanister, Container etc. durch einen hierarchischen Code dar-stellen. Aber nicht nur dies – es könnte auch die Versorgung auf dem Land-weg wieder aufgenommen werden, wenn es gelänge, Maultiere in ausrei-chender Anzahl zu bekommen, denn auch für diese gibt es einen RIC.

Vorbereitung, Durchführung und Nachbereitung der Hilfsflüge werdenebenfalls durch DFPS unterstützt. Die Luftfahrzeuge werden als technischeObjektstruktur in SAP abgebildet. Für jeden Flug wird ein entsprechenderAuftrag angelegt, alle zusammen werden automatisch aktualisiert in einerFlugübersicht dargestellt. Die benötigte Konfiguration der angefordertenLuftfahrzeuge kann dort eingetragen und mit der Konfiguration verfügbarerHubschrauber verglichen werden, die in einem ebenfalls automatisch aktua-lisierten Statusboard aufgelistet werden können. Anhand vielfältiger Krite-rien wird ein passendes Fluggerät ausgewählt und dem Flug zugeordnet.Spezielle Statusinformationen helfen bei der Überwachung der Flugvorbe-reitung und der Gewährleistung der Flugsicherheit, auch und gerade in Ein-satzszenarien. Sämtliche vorbereitenden und abschließenden Maßnahmenkönnen vorgeplant und dokumentiert werden.

Darüber hinaus helfen Qualifikationen, Trainingsprogramme und Kataloge,die geeignete Besatzung für einen geplanten Hilfsflug auszuwählen. SämtlicheAktivitäten und die Betriebswerte werden auch im Einsatzfall dokumentiert,

Für den nächsten Tag hat sich der Gouverneur von Lhamosa zu einem Informa-tionsbesuch angekündigt.

Plötzlich geht alles sehr schnell: Ein neuer Einsatzleiter ist gefunden. Damit wächstauch die Bereitschaft, mit den internationalen Einsatzkräften zusammenzuarbei-ten. Der neue Einsatzleiter spricht mit dem Vertreter des Technischen Hilfswerksdie Neuplanung des Einsatzes durch. Verheerende Bilder vom Zentrum der Katas-trophe legen eine Neupriorisierung der Einsatzziele nahe. Medizinische Soforthilfe,die Suche nach Überlebenden und die Verhinderung der Ausbreitung von Seuchendurch zügige Bergung der Opfer werden demnach vorrangig betrieben, gleichzeitigbittet nun der Gouverneur die internationale Gemeinschaft um Hilfe. Insbesonderezusätzliche Kapazitäten an Transporthubschraubern sowie Helikoptern mit SAR-Ausstattung (Search, Aid & Rescue) werden dringend benötigt.



64

um die Logbücher stets aktuell zu halten. Saubere Aufzeichnungen könnenspäter dazu genutzt werden, bei der Abrechnung der Einsatzkosten zwischenden beteiligten Nationen zu einem belastbaren Ergebnis zu kommen.

2.4 Fazit

Nach der Lektüre dieses Kapitels sind Sie mit der Ausgangslage für unsereFallstudie vertraut. Sie kennen den Zusammenhang zwischen geografischenGegebenheiten und einsatzrelevanten Bedingungen, z.B. die Abhängigkeitder Vorwarnzeit von der Laufzeit der Flutwelle oder die Auswirkungen blo-ckierter Transportwege auf die Planung von Hilfslieferungen. Vorbereitendauf die Folgekapitel haben Sie darüber hinaus erfahren, wie Sie die DFPS-Software bei der Abbildung der Einsatzkräfte und bei der Abwicklung logis-tischer Prozesse unterstützen kann.


Gesamtstammdatenmodell von DFPS 3.3

83

3.3 Gesamtstammdatenmodell von DFPS

Wie Sie den vorausgegangenen Abschnitten bereits entnehmen konnten,stellt das Strukturelement die wesentliche Drehscheibe der gesamten Bran-chenlösung dar. Abbildung 3.8 soll Ihnen dies exemplarisch verdeutlichen.

Abbildung 3.8 Gesamtstammdatenmodell DFPS (Quelle: SAP)

Was Sie sehen, entspricht der Strukturelementspinne (siehe Abbildung 3.7)in einer detaillierteren Betrachtungsweise. Sie finden das Strukturelement(SE) als Viereck in der Mitte der Grafik, das mithilfe von Verknüpfungen dieverschiedenen Komponenten der Branchenlösung miteinander verbindet.

Allein daraus lässt sich die starke Integration mit Komponenten von SAP ERPerkennen. Grundsätzlich können wir – wie auch bereits durchgeführt – mit-hilfe der SAP-Terminologie zwischen der Integration in SAP ERP und derIntegration mit anderen Komponenten und Lösungen unterscheiden.

Symbole im Gesamtstammdatenmodell

Diese verschiedenen Komponenten werden anhand der Formen unterschieden. Sostehen Quadrate für das Personalwesen, Dreiecke für die Materialwirtschaft, Acht-ecke für das Rechnungswesen, Kreise für Projektstrukturen und Haushaltsmanage-ment, Fünfecke für die Instandhaltung und Drachen für die Infrastruktur (sieheAbbildung 3.8).

LogistikPersonalwesenRechnungswesen

Technischer Platz

LA

Dokumente

VPA

MPO

MC

Master Equipment

M

-

P

S = PlanstelleP = PersonQ = QualifikationQB = QualifikationsblockC = StelleGP = GeschäftspartnerLA = Logistischer ArbeitsplatzAO = Architekturobjekt

C

Projekte

S SE

SE

Lagerort

Q

QB

VPAMCMPO M

= ===

Vorratspaket ContainerMaterial MaterialplanungsobjektMaterial

PSP-Elemente

Instandhaltung

GPFinanzstelle

AO

Infrastruktur Kosten-stelle

ProfitCenter


Stammdaten und Organisationsstruktur3

84

In Abbildung 3.8 handelt es sich um den ersten Aspekt. So stellt das Struk-turelement die Integration der Personalwirtschaft, der Logistik und desRechnungswesens auf Basis von SAP NetWeaver sicher. Darüber hinaus lässtes sich sowohl in C2-Systemen (Command and Control-Systemen) als auch inmobilen Anwendungen einsetzen. Mehr Informationen dazu erhalten Sie inKapitel 17, »Mobile Anwendungen«.

� Personalwesen (Quadrate)Das Quadrat (SE) entspricht einem Strukturelement, das in diesem Fall miteinem weiteren Strukturelement zu einer Struktur nach oben verknüpftist. Die weiteren Vierecke entsprechen den bekannten Stammdaten desPersonalwesens. Darunter finden Sie u.a. die Planstellen (S) und die Stel-len (C), die die Planstellen beschreiben. Personen (P) besetzen Planstellenund erfüllen diese Qualifikationen (Q). Einzig und allein die Qualifikati-onsblöcke (QB), die die Anforderungen an den Halter von Planstellenbeschreiben, stellen ein DFPS-Spezifikum dar. Darüber hinaus könnenPersonen (P) auch mit Geschäftspartnern (GP), die der Einfachheit halberebenso als Viereck dargestellt werden, verknüpft werden. Diese Verknüp-fung wird vor allem für den Infrastrukturprozess der Belegplanung undder Ableitung von Qualifikationen aus der Instandhaltung benötigt.

� Materialwirtschaft (Dreiecke)Unter dem Bereich der Dreiecke befinden sich die materiellen Anteile:Materialcontainer (MC) und Materialplanungsobjekte (MPO). Vorratspa-kete (VPA) drücken das materielle Soll eines Strukturelements aus, demdas tatsächliche Material (M) gegenübersteht. Dieses Material wird,sobald es vorhanden ist, in dem dem Strukturelement zugeordnetenLagerort angezeigt.

� Instandhaltung (Fünfecke)Die Fünfecke beschreiben die Instandhaltungsanteile, die hier aus demtechnischen Platz und den zugeordneten Master-Equipments bestehen,Letztere wurden eigens für DFPS entwickelt. Die Instandhaltungsanteilewerden über den logistischen Arbeitsplatz mit den personellen Anteilen(konkret dem HR-Arbeitsplatz) verknüpft. Dies ist in Abbildung 3.8 mitder Verknüpfung LA und S skizziert.

� Rechnungswesen (Achtecke)Die integrativen Aspekte des Rechnungswesens bestehen aus den Achte-cken Kostenstelle und Profit-Center und der daraus abgeleiteten Finanz-stelle des Haushaltsmanagements der Infrastruktur (Drachen) und der Pro-jektstruktur (Kreise).



85

Umgangssprachlich werden allerdings sehr oft nur die Kostenstelle unddas Profit-Center (die Achtecke in Abbildung 3.8) als Rechnungswesenbezeichnet. Diese beiden bilden die Basis für die weitere Integration mitdem Haushaltsmanagement (hier die Finanzstelle, als Sechseck dargestellt)und stellen weiterführende Rechnungswesenprozesse sicher.

� Infrastruktur (Drache) Die Einbindung des Immobilienmanagements erfolgt mit der Verknüp-fung des Architekturobjekts mit dem Strukturelement. Dies ist erst mitdem Erweiterungspaket 3 (EHP3) möglich.

� Projektstrukturen und Haushaltsmanagement (Kreise)Eine nicht zu unterschätzende Bedeutung hat das Projektsystem, das überdas Objekt »Projektstrukturplan« an das Strukturelement geknüpft wer-den kann.

Zusammenfassend lässt sich bezüglich des Gesamtstammdatenmodells Fol-gendes noch einmal bestätigen:

� DFPS verfügt über zwei Integrationsaspekte: die Integration ins ERP-Sys-tem und die Integration mit anderen Komponenten und Systemen.

� DFPS stellt mithilfe des Strukturelements die Verknüpfung des Personal-wesens, der Logistik und des Rechnungswesens sicher.

Im Folgenden werden wir die hier dargestellten Stammdaten anhand ihrerDFPS-Besonderheiten detailliert betrachten.

3.3.1 Das Strukturelement – technischer Fokus

Der Nukleus unserer Lösung ist Ihnen ja schon eindrücklich vorgeführt wor-den, nun soll seine technische Sicht näher betrachtet werden.

Die aus dem Organisationsmanagement der Personalwirtschaft bekannteOrganisationseinheit wurde zum sogenannten Strukturelement erweitert.Das Ziel dieser Erweiterung ist eine integrierte Abbildung organisatorischerStrukturen zur Planung und Steuerung administrativer, personalwirtschaft-licher und logistischer Prozesse.

Technisch betrachtet, wird diese Erweiterung des Objekts »Organisations-einheit« mithilfe einer einzigen Tabelle – der Tabelle /ISDFPS/FORCE –umgesetzt.



86

Tabelle /ISDFPS/FORCE

Die Tabelle /ISDFPS/FORCE besteht aus zwei Abschnitten, der Objektidenti-fizierung sowie den Objektzuordnungen und Eigenschaften.

In Tabelle 3.2 erfolgt die Zuordnung von der Objekt-ID einer Organisations-einheit zu der FORCE-ID eines Strukturelements (Objektidentifizierung).

So wird nicht nur die Zuordnung zwischen Organisationseinheit und Struk-turelement in der Tabelle /ISDFPS/FORCE festgehalten, sondern ebenso dieVerschränkung mit der Logistik (siehe Tabelle 3.3).

Feld Bedeutung Verwendung

FORCE_ID interner Schlüssel des Struktur-elements

Identifizierung des Strukturelements

FORCE_CNT interner Versionszähler

PLVAR Planvariante Zuordnung des Struktur-elements zu einer Organi-sationseinheit

OTYPE Objekttyp

OBJID Objekt-ID

Tabelle 3.2 Tabelle /ISDFPS/FORCE – Objektidentifizierung

Feld Bedeutung Reiter

WERKS_S Werk (Bestand) Bestand/Vorrat

BERID_S Dispositionsbereich (Bestand)

ACNTABLE_S nachweispflichtig (Bestand)

LGORTACNT Lagerort (Bestand)

WERKS_P Werk (Vorrat)

BERID_P Dispositionsbereich (Vorrat)

ACNTABLE_P vorratsführend (Vorrat)

WERKS_RE Werk (Infrastruktur)

BERID_RE Dispositionsbereich (Infrastruktur)

ACNTABLE_RE nachweispflichtig (Infrastruktur)

LGORT_RE Lagerort (Infrastruktur)

PSPNR PSP-Element PSP-Element

Tabelle 3.3 Tabelle /ISDFPS/FORCE – Zuordnungen und Eigenschaften



87

Sie sehen in der rechten Spalte in Tabelle 3.3, auf welchen Reitern innerhalbder Struktur-Workbench die Daten angezeigt werden.

Wie Sie anhand von Tabelle 3.3 erkennen können, ist die Tabelle/ISDFPS/FORCE die Basis für jegliche Integration mit der Logistik. AlleStrukturelemente verfügen über einen Tabelleneintrag in dieser Tabelle,Organisationseinheiten ohne einen entsprechenden Eintrag werden in derStruktur-Workbench nicht angezeigt. Verfügen Sie in Ihren Systemen übereine existierende Aufbaustruktur, lässt sich diese mithilfe des Reports/ISDFPS/CREATE_FORCE_FROM_ORGU in die Tabelle /ISDFPS/FORCEübernehmen.

Jetzt wissen Sie, worin der Unterschied zwischen einer Organisationseinheitund dem Strukturelement liegt, betrachten wir nun also das Strukturelementetwas näher.

Das Strukturelement im Detail

Zunächst möchten wir Ihnen die Details näherbringen, die das Strukturele-ment benötigt, um zu existieren. Wie jedes Objekt des Organisationsma-nagements, muss auch das Strukturelement über eine einzigartige Objekt-ID(Identifikationsnummer), einen Namen (technisch: Lang- und Kurzbezeich-nung), einen Start- und Endezeitraum und über einen Planungsstatus verfü-gen. Mit diesen Attributen wird allerdings nur das Strukturelement an sichbeschrieben, damit es aber seinen Zweck erfüllen kann, benötigt es Ver-knüpfungen mit anderen Objekten.

READINESS_MAT Materialbereitschaftsgrad Bereitschaft

READINESS_PERS Personalbereitschaftsgrad

READINESS_TRAI Ausbildungsbereitschaftsgrad

EKORG Einkaufsorganisation Logistikdaten

EKGRP Einkäufergruppe

LOGLEV logistische Ebene

PRIO organisatorische Priorität

MATSTAT Status der Erstversorgung Vorratspakete

Feld Bedeutung Reiter

Tabelle 3.3 Tabelle /ISDFPS/FORCE – Zuordnungen und Eigenschaften (Forts.)



88

Alle diese Informationen werden im Objektkopf der Struktur-Workbenchangezeigt (z.B. die vierte Panzerkompanie, siehe Abbildung 3.9).

Abbildung 3.9 Objektkopf – vierte Panzerkompanie

Da man bereits bei diesen sehr grundlegenden Einstellungen auf der Hut vorFehlern sein muss, möchten wir Ihnen diese nun näher erläutern.

� Objekt-Identifikationsnummer (Objekt-ID) eines StrukturelementsDie Objekt-ID der Organisationseinheit wird verwendet, um ein Struktur-element eindeutig zu beschreiben. (Die in der Tabelle /ISDFPS/FORCEexistente Force-ID ist zwar auch einzigartig, aber kommt aufgrund ihrerLänge nicht zur Anwendung.) Auch wenn sprechende Objekt-IDs wie Hfür Heer, M für Marine und L für Luftwaffe möglicherweise als praktika-bel erscheinen, empfehlen wir Ihnen, auf die SAP-interne Nummernver-gabe zurückzugreifen.

� Lang- und KurzbezeichnungDie Eingabe der Lang- und Kurzbezeichnung erfolgt direkt beim Anlegendes Strukturelements. Beide Felder werden in weiterer Folge über denReiter Benennung angezeigt und lassen sich auch über diesen abändern.Die Speicherung dieser Information erfolgt im Infotyp 1000.

Eine häufige Frage, gerade im Bereich der Abbildung von multinationalenStäben, ist die nach der Mehrsprachigkeit. Diese Möglichkeit ist ebenfallsauf dem Reiter Benennung über das Icon Übersetzung pflegen gegeben(siehe Abbildung 3.10).

Nummernkreise nicht zu eng fassen

Insbesondere gilt es, darauf zu achten, dass die etwaigen Nummernkreise (derIdentifizierungsnummern) nicht zu eng gefasst werden, um das problemlose Pla-nen und Arbeiten über Jahre hinweg zu gewährleisten.

Bitte beachten Sie, dass allein bei der Kopie einer einzigen Kompanie bereits meh-rere Hundert neuer HR-Objekte erzeugt werden und somit auch das Nummernin-tervall entsprechend nach oben gesetzt wird.



89

Abbildung 3.10 Icon »Übersetzung pflegen«

� Start- und EndezeitraumDer Startzeitraum des Strukturelements beginnt in der Regel mit dem Tagseines Anlegens. Verwenden Sie jedoch die Komponente Case Manage-ment und darin die Organisationsmaßnahmen, gibt das Datum des Wirk-samwerdens der Maßnahme den Startzeitraum vor. Bei der Übernahmevon historischen Daten wird natürlich der tatsächliche Start- und Ende-zeitpunkt übernommen.

� PlanungsstatusDer/die Planungsstatus des Strukturelements folgt bzw. folgen dem Sta-tusnetz von Organisationsmanagementobjekten. Ein Strukturelementbefindet sich nach dem Anlegen im Status Geplant und wird im Rahmendes Genehmigungsprozesses in Beantragt, Genehmigt bzw. Aktiv

gewandelt.

Suchmöglichkeiten bedenken

Bei geplanter Verwendung der Suchfunktionalität sollte man sich bereits beimAnlegen der Stammdaten darüber Gedanken machen, ob eine einfache Verwen-dung der Lang- oder Kurzbezeichnung ausreicht.

Sucht man beispielsweise nach der Einsatzbereitschaft von Strukturelementen undhat man diese zuvor z.B. auch auf Zugsebene angelegt, erhält man bei einfacherVerwendung wahrscheinlich zwanzig verschiedene Einträge I. Zug als Ergebnis.

Zielführender wäre es, bereits bei Lang- oder Kurzbezeichnungen die Einheiteneinzigartig zu kennzeichnen, wie z.B. I.Zug/1.Kp/3 Bn – oder kürzer I./1./3.

Endezeitpunkt

Generell empfehlen wir Ihnen in diesem Zusammenhang, den Endezeitpunkt desStrukturelements gegen unendlich (»High Date«) laufen zu lassen, also den31.12.9999 als vorgeschlagenen Endezeitpunkt nicht abzuändern.



90

Diese Aktivierung kann sowohl manuell über die Strukturarbeitsoberflä-che als auch über die Organisationsmaßnahmen durchgeführt werden.Dabei werden Statuschecks und Folgeaktionen durchgeführt (sieheAbschnitt 3.4, »Strukturen der Branchenlösung DFPS«).

� VerknüpfungenVerknüpfungen stellen nicht nur die Verbindung zu vorgesetzten undnachgeordneten Strukturelementen dar, sondern werden auch gemein-sam zu sogenannten Verwendungstypen (Grundstruktur, Einsatzstruktur,Übung etc.) zusammengefasst, um dann damit Strukturen abzubilden(siehe Abschnitt ,3.4 »Strukturen der Branchenlösung DFPS«).

Beschreibende Infotypen des Strukturelements

Alle weiteren benötigten Attribute/Aufgaben des Strukturelements werdenauf Reitern des Detailbereichs abgebildet. Generell wurde bereits bei derEntwicklung versucht, auf bereits in SAP ERP HCM vorhandene Infotypenzurückzugreifen und z.B. die folgenden Infotypen des Organisationsmanage-ments zu nutzen:

� Infotyp 1000 – Objekt

� Infotyp 1001 – Verknüpfungen

� Infotyp 1002 – Verbale Beschreibung

� Infotyp 1008 – Kontierungsmerkmale

� Infotyp 1018 – Kostenverteilung

� Infotyp 1019 – Kontingentplanung

Diese Standard-Infotypen reichen jedoch nicht aus, um z.B. das Strukturele-ment restlos zu beschreiben, daher wurden branchenspezifische Infotypen(im Namensraum von 1950 bis 1990) geschaffen, die vor allem militärspezi-fische Attribute abdecken. Die folgende Aufzählung zeigt diese branchenspe-zifischen Infotypen im Überblick:

� Infotyp 1950 – Eigenschaften

� Infotyp 1951 – Klassifizierung

� Infotyp 1952 – Stationierung

� Infotyp 1953 – Leistungsangebot

� Infotyp 1954 – Leistungsbezug

� Infotyp 1955 – Unterstellungsbeziehungen

� Infotyp 1956 – Einsatz/Übung



91

� Infotyp 1980 – Verlegung

� Infotyp 1981 – Verlegung Material

� Infotyp 1982 – Verlegung Personal

� Infotyp 1984 – Logisches System

� Infotyp 1985 – Einsatz-/Übungsverknüpfungen

� Infotyp 1986 – Strukturinformation

� Infotyp 1988 – Operative Gewichtung

Wir möchten Ihnen nun im weiteren Verlauf die wichtigsten Infotypenexemplarisch vorstellen.

Infotyp 1950 – Eigenschaften

Dieser Infotyp wird bereits beim Anlegen eines regulären Strukturelementsausgefüllt, daher ist er bei jedem Strukturelement vorhanden, außer bei Ein-sätzen und Übungen.

Der Infotyp 1950 definiert die grundlegenden organisatorischen Eigenschaf-ten eines Strukturelements. Dazu gehören z.B. die folgenden:

� Das Land, zu dem das Strukturelement gehörtDie Angabe des Landes hat neben dieser rein informativen Betrachtungund einem eventuellen Nutzen in multinationalen Stäben und Einheitenauch eine Auswirkung auf das dahinter liegende Controlling.

� OrganisationsbereichDer Organisationsbereich spiegelt in den meisten Fällen die Teilstreit-kräfte wider, allerdings können auch Bereiche wie Militärmedizin undSeelsorge als eigener Organisationsbereich angesehen werden.

Auswirkungen auf Rechnungswesen und Logistik

Das Customizing dieses Infotyps im IMG stellt die Basis für einige Prozesse desRechnungswesens (z.B. der automatischen Generierung der CO-Stammdaten) undder Logistik dar.

Organisationsbereich – Steuerungselement für die Stammdatenorganisation

Gerade der Organisationsbereich ist ein wesentliches Steuerungselement für dasweitere Anlegen von Stammdaten. So können damit Waffengattungen, die auto-matische Kostenstellengenerierung sowie im Bereich des MPO die Anzahl derplanbaren Objekte auseinandergesteuert werden.



92

� OrganisationsbereichstypDer Organisationsbereichstyp ist eine Gruppierung der Organisationsbe-reiche; die Standardauslieferung Militär- (M), Zivil- (Z), Hilfsorganisation(A – für Aid Organization) und Polizeiorganisation (P) liefern eine bloßeVorlage für Organisationsbereichstypen und können natürlich nachBedarf abgeändert oder ergänzt werden.

Dabei gilt es, zu beachten, dass pro Organisationsbereichstyp eine Strukturdurch Strukturebenen festgelegt wird.

� StrukturebeneDie Strukturebene entspricht der militärischen Größenordnung – ausge-hend vom Organisationsbereichstyp werden Strukturebenen definiert. Soverfügt M über eine andere Struktur als C (Armee, Korps, Division, Bri-gade, Regiment etc.). Dahinter lässt sich zusätzlich der Symbol Modifier –d.h. die dem NATO-Standard 2525B entsprechende Größenordnung –festmachen.

� GliederungsformDie Gliederungsform spezifiziert die Strukturebene. Die Strukturebene»Kompanie« weist z.B. folgende Gliederungsformen auf: Kompanie, Batte-rie, Staffel.

� Truppengattung, -zusatz und -artDiese drei Eigenschaften beschreiben die jeweilige Waffengattung ihresStrukturelements. Angenommen, Sie wählen die Waffengattung Infante-rie, dann könnten Sie im Zusatz zwischen leichter, motorisierter, mecha-nisierter Infanterie sowie zwischen Gebirgs- und Fallschirmjägern unter-scheiden. Die Art würde in diesem Fall »Kampftruppe« sein. Generell giltauch hier, dass das ausgelieferte Customizing eine bloße Vorlage darstelltund natürlich bei Bedarf an Ihre Vorgaben angepasst werden kann.

� DienststelleDie Checkbox Dienststelle hat rein informativen Charakter und dient derKennzeichnung, dass es sich bei Ihrem Strukturelement um eine Dienst-stelle handelt.

Strukturebene

Bei der Auseinandersteuerung von Gliederungsformen bleibt das taktische Zeichender Strukturebene erhalten. Diese Information ist bei der Verwendung geografi-scher Informationssysteme (GIS) entscheidend, denn mit ihrer Hilfe kann diejeweilige militärische Einheit im Kartenwerk dargestellt werden.



93

� SymbolcodeDieser 15-stellige Symbolcode entspricht dem NATO-Standard MIL-STD-2525B – Common Warfighting Symbology und wird aus der Waffengattungund Größenordnung zusammengestellt. Dies ermöglicht die Abbildungauf geografischen Informationssystemen (GIS).

� Unit Identifier CodeDies ist ein auf NATO STANG 5500 basierender Code, der Einheiten ein-deutig beschreibt. Er besteht aus dem Länderschlüssel wie DE, dem Orga-nisationsbereich wie 1 für Armee und einem sechsstelligen Code.

� ReferenzstrukturelementDieses Feld erlaubt das Speichern der Objekt-Identifikationsnummer(Objekt-ID) eines Referenzstrukturelements.

Infotyp 1956 – Einsatz/Übung

Dieser Infotyp wird verwendet, um Strukturelemente vom Subtyp »Einsatzund Übung« zu beschreiben. Diese stellen immer das oberste Strukturele-ment einer Einsatz- oder Übungsstruktur dar, und somit wird der Infotyp1956 bereits beim Anlegen eines neuen Einsatzes oder einer Übung befüllt.Mehr über dessen direkte Verwendung erfahren sie in Kapitel 4, »Operatio-nal Planning«.

Im Folgenden beschreiben wir Ihnen die wichtigsten Felder des Infotyps1956:

� ObjektzeitraumDieses Feld stellt die technische Lebenslinie des Strukturelements dar undhängt nicht mit dem Einsatzzeitraum zusammen.

Taktisches Zeichen zuordnen

Auch bei der Truppengattung lässt sich über den Symbolcode des NATO-Standards2525B das entsprechende taktische Zeichen zuordnen. Es empfiehlt sich, diesgleich beim erstmaligen Anlegen im IMG durchzuführen. Dann können Sie sich miteinem entsprechend gekoppelten geografischen Informationssystem (GIS) dasStrukturelement auf der Landkarte darstellen lassen.

Strukturelement mit Infotyp 1956

Ein mit dem Infotyp 1956 versehenes Strukturelement sollte nur als »Klammer« fürdie Rahmenbedingungen der darunter liegenden Struktur wahrgenommen wer-den. Vermeiden Sie Zuordnungen von Personal und Material, diese sind zwar tech-nisch möglich, erfüllen allerdings realen keinen Zweck, da es sich ausschließlich umein »Sammel-Strukturelement« handelt.



94

� Operativer ZeitraumDieser Zeitraum definiert den tatsächlichen Start- und Endezeitpunkt desEinsatzes und auch die Vorschlagswerte für die Kontingente.

� KontingenteKontingente definieren die Zeiträume der Rotationen/Ablösungen sowohlvon Personal als auch von Material.

� IntensitätDieses Feld beschreibt die Intensität von Einsätzen oder Übungen; es hatmeist einen indirekten Einfluss auf die Lohn- und Gehaltsabrechnung vonSoldaten.

Infotypen 1953 und 1954 – Leistungsangebot und Leistungsbezug

Diese beiden Infotypen gilt es, gemeinsam zu betrachten, da sie in einemAnbieter-Verbraucher-Verhältnis stehen. Unterstützungsbeziehungen desNachschubs und der Instandhaltung, die minutengenau als Verknüpfungenabgebildet werden, um das Weiterleiten von Anforderungen und Aufträgensicherzustellen, benötigen sehr viele Tabelleneinträge. Daher entschied mansich, für Unterstützungsbeziehungen mit eher informativem Charakter zweiInfotypen zu verwenden.

Diese Infotypen 1953 und 1954 dienen in erster Linie dem Abbilden vonServiceverhältnissen, bei denen es ausreicht, tagesgenau zu agieren. In denmeisten Fällen werden sowohl Wirtschaftsservices (Welche Einheit bezahltdie Rekruten?) als auch medizinische Services (Welches Militärspital ist fürwelche Einheiten zuständig?) abgebildet.

Infotyp 1953 bietet den im IMG vordefinierten Service an (siehe Abbildung3.11), und Infotyp 1954 stellt den Bezug eines Services dar. In diesem Fallsehen Sie eine Sanitätskompanie einer Brigade, die die geplante Zuordnungder medizinischen Grundversorgung »Role 2« hat. Das heißt, sie stellt bereitshochwertige medizinische Versorgung sicher.

Als hervorhebenswerte Funktionalitäten lassen sich folgende nennen:

� Eigennutzung – alle angebotenen Services können auch vom eigenen SEkonsumiert werden.

� Where-used-Button (Verwendungsnachweis-Button) – er ermöglicht denraschen Überblick über die Bezieher des jeweiligen Services.

Endezeitpunkt des Objektzeitraums

Verwenden Sie auch hier den 31.12.9999 als Endezeitpunkt für Ihr Strukturele-ment und nicht das voraussichtliche Ende Ihres Einsatzes.



95

� Möglichkeit zur Massenänderung – diese besteht im Popup-Screen desVerwendungsnachweises, dadurch können Sie z.B. auf einmal den medi-zinischen Versorger mehrerer Einheiten wechseln.

Abbildung 3.11 Infotyp 1953 – hier als medizinische Grundversorgung

Infotyp 1952 – Stationierung

Dieser Infotyp speichert alle Adress- und weiteren Standortinformationen,die für Folgeprozesse der Logistik, z.B. für die Mobilmachung, benötigt wer-den.

Abbildung 3.12 Infotyp 1952 – Stationierung und seine Subtypen

Folgeaktionen definieren

Etwaige Folgeaktionen, die durch die Aktivierung der Serviceverknüpfungengestartet werden sollen, lassen sich im IMG durch ein Business Add-In Folgeak-tivitäten und Filter für Infotypen 1953/1954 definieren.



96

Dabei stehen, wie in Abbildung 3.12 zu erkennen, folgende Subtypen zurVerfügung:

� Post- und Lieferanschrift

� MOB-Adresse Personal und Material

� Nächster Bahnhof, Flughafen oder Seehafen

� Geolokation (gemäß WGS84)

Es lassen sich über die rein informatorische Beziehung automatisch Adress-informationen von der Wirtschaftseinheit auf die Strukturelemente verer-ben. Des Weiteren lassen sich Adressen auch innerhalb der Struktur über dieButtons und finden und vererben.

Massenänderungen von Adressen an ganzen Strukturen sind mit der Trans-aktion Stationierung bearbeiten (/isdfps/CDD_DEPLYMNT) möglich.

Infotyp 1988 – Operative Gewichtung

Dieser Infotyp entspringt einer Anforderung der Defense Interest Group(DEIG). Um die Einsatzbereitschaft oder Readiness der eigenen Kräfte ein-schätzen zu können, ist es notwendig, diese zuvor zu gewichten. Über vor-definierte Gewichtungen von Struktur, personellem und materiellem Sollwird die Kalkulation der Einsatzbereitschaft durch den Vergleich mit dem Istund dem Personal und Material ermöglicht.

Die Definition dieser Gewichtungen erfolgt nach grundlegenden Einstel-lungen im IMG über den Infotyp 1988. Damit lassen sich standardmäßig dieGewichtung der Verknüpfungen zwischen SE – SE; SE – S; SE – MPO; S – QB,Q und S – MPO abbilden.

Vor dem Anlegen dieser Gewichtungen (siehe Abbildung 3.13), müssen Siebereits Klarheit über folgende Fragen haben:

� Welchen Wert hat z.B. die Planstelle Bataillonskommandeur für ein Batail-lon?

� Wie wichtig ist ein Nachtsichtfernglas für die Planstelle?

� Wie entscheidend sind die vorhandenen Qualifikationen?

� Kurz und gut, Sie müssen zuvor wissen, wie Sie Ihre TOE gewichten wol-len, um danach auch tatsächlich eine realistische Gewichtung zu erlangen.Das Anlegen dieser Gewichtungsstrukturen über den Infotyp 1988 stelltjedoch nicht den Hauptteil dieser Kalkulation der operativen Gewichtungdar, denn dieser findet mithilfe von BW statt.



97

� Sie haben nun einen Überblick über die gebräuchlichsten Infotypen desStrukturelements erhalten. All diese sind in der standardmäßigen Auslie-ferung enthalten. Natürlich können Sie auch kundenspezifische Infotypenzur zusätzlichen Beschreibung des Strukturelements in die Struktur-Work-bench mit aufnehmen. Die DFPS-spezifischen Infotypen wurden imNamensraum von 1950 bis 1990 entwickelt.

Abbildung 3.13 Infotyp 1988 – Anlegen einer neuen Gewichtung

Zusammenfassung – Strukturelement aus technischer Sicht

Das Strukturelement stellt eine DFPS-spezifische Erweiterung des Objekt-typs »Organisationseinheit« dar. Diese Erweiterung erfolgt mithilfe derTabelle /ISDFPS/FORCE, die vor allem die Integration mit der Logistikermöglicht. Neben den Kernattributen eines Objekts verfügt das Strukturele-ment bereits standardmäßig über beschreibende Infotypen.

3.3.2 Planstelle

Für den Aufbau eines Organisationsplans ist die Planstelle von entscheiden-der Bedeutung. Sie repräsentiert das personelle Soll eines Strukturelements.Im Gegensatz zum vorher sehr ausführlich behandelten Strukturelement gibtes für die Planstelle keine DFPS-spezifischen Tabellen, wie die zuvorbeschriebene Tabelle /ISDFPS/FORCE.

Die Planstelle entspricht der Planstelle S aus dem Organisationsmanagement,wird allerdings über die Struktur-Workbench angelegt.


IT-Architektur12

422

� Gibt es klare und vollständige Dokumentationen für die Systeme, ausdenen insbesondere ersichtlich ist, welche besonderen Anforderungender jeweilige Organisationsbereich stellt?

� Gibt es Architekturstandards für die einzelnen Systeme?

� Gibt es klar definierte Governance-Modelle für die Systeme und notwen-dige Veränderungen?

� Gibt es übergreifende Datenmodelle für mehrere Systeme?

� Existieren Schnittstellenvereinbarungen zwischen den einzelnen Syste-men für den Datenaustausch?

12.1.5 Extrem hohe Sicherheitsanforderungen

Der gesamte Bereich, der von der Lösung DFPS unterstützt wird, unterliegtextrem hohen Sicherheitsanforderungen. Gehört in SAP-Projekten in derIndustrie das Thema Berechtigungskonzept zu den unterstützenden Funk-tionen im Projekt, so verstehen viele Sicherheitsorganisationen und Armeendiesen Bereich als Kernprozess. Bei dieser Ausgangsposition ergeben sichwichtige Fragen für Ihr Projekt, die Sie klären sollten, um eine effizienteArbeit an der Architektur sicherzustellen:

� Welche Vorgaben existieren für den Geheimschutz der Daten?

� Welche Vorgaben sind zu beachten (z.B. Datenschutzgesetze)?

� Gibt es eine klare Festlegung in der Organisation, welche Personenkreiseauf welche Daten zugreifen können?

� Gibt es Einheiten in Ihrer Organisation, deren Daten über den normalenGeheimschutz hinaus einem besonderen Schutz unterliegen müssen (z.B.Spezialkräfte)?

� Gibt es Personen in Ihrer Organisation, deren Daten nicht im Systemzugänglich sein dürfen?

� Welche Netzstruktur gibt es?

� Welche Vorgaben gibt es für die Weiterverwendung der Daten (z.B. Dru-cken nur in gesicherten Druckerräumen)?

12.2 Referenzarchitektur

Der grundlegende Unterschied zwischen einer DFPS-Architektur und sonstigenSAP-Architekturen besteht darin, dass es nicht allein darum geht, vordefinierte


Referenzarchitektur 12.2

423

Standorte mit dem System zu versorgen. Vielmehr muss eine verteilte System-landschaft geschaffen werden, die ein Einsatzszenario unterstützt und den aut-arken Betrieb der dezentralen Komponenten sicherstellt. Um Ihnen einen siche-ren Ausgangspunkt für Ihr Projekt zu geben, werden wir Ihnen zunächst dieReferenzarchitektur mit ihren verschiedenen Bestandteilen vorstellen.

Diese Referenzarchitektur besteht aus zwei Stufen: den Zentralsystemen amHeimatstandort (siehe Abschnitt 12.2.1, »Zentrale Systemebene am Heimat-standort«) und den dezentralen Systemen mit den mobilen Anwendungen(siehe Abschnitt 12.2.2, »Dezentrale Systeme«).

Die verschiedenen Ebenen werden durch speziell für DFPS entwickelteSchnittstellenkomponenten verbunden, die auf den Komponenten Applica-tion Link Enabling (ALE) und Product Data Replication (PDR) aufsetzen. Kurzgesagt, stellen diese Erweiterungen sicher, dass die Autarkiefähigkeit derdezentralen Systeme optimal unterstützt werden kann, indem zusammenge-hörige Stamm-, Bewegungs- und Benutzerdaten zwischen den beteiligtenSystemen verteilt werden. Auf diese Komponenten werden wir im Verlaufdes Kapitels noch genauer eingehen, ihre Erwähnung ist jedoch schon jetztwichtig, um den Zusammenhang zwischen den verschiedenen Systemebe-nen verstehen zu können.

Abbildung 12.1 zeigt den schematischen Aufbau der Referenzarchitektur.

Abbildung 12.1 Referenzarchitektur DFPS im Überblick

SAPMobileInfra-

structure

MIClient

MIClient

ZentralsystemHeimat-

basis

DezentraleSystemeSAP ERP



LogisticsExecution

SystemMI

Client

ALE


IT-Architektur12

424

Die Referenzarchitektur wird dabei im Kern vom ERP-System mit der DFPS-Lösung gebildet. In den vorangegangenen Kapiteln wurde Ihnen sicherlichschon die Bedeutung der Logistik für die Einsatzunterstützung klar. Aus die-sem Grund ist das Logistics Execution System (LES) Bestandteil der System-architektur. LES besteht aus verschiedenen Komponenten, z.B. WarehouseManagement (WM Mit LES können die Prozesse in den Bereichen Beschaf-fung, Lagerung, Distribution, Transport, Verkauf und Service flexibel ver-knüpft werden.

Um die mobilen Szenarien abbilden zu können, die in Kapitel 17, »MobileAnwendungen«, genauer dargestellt werden, sind die Komponenten MobileInfrastructure und Mobile Client notwendig. Diese ermöglichen mobile Sze-narien, sodass etwa erste Einheiten, die nach Lhamosa verlegt werden, arbei-ten können, ohne dass eine permanente Netzverbindung bereits vorhandenist.

Dabei bilden die zentrale und die dezentrale Ebene den prinzipiellen Aufbauder Architektur ab. Innerhalb einer Ebene kann es durchaus noch die Vertei-lung von Funktionalitäten auf verschiedene Systeme – z.B. aus Sicherheits-gründen – geben. Aus Gründen der Übersichtlichkeit werden wir diese The-men jedoch erst nach dem Überblick betrachten.

12.2.1 Zentrale Systemebene am Heimatstandort

Die zentralen Systeme in der Heimatbasis verfügen über die komplettenFunktionalitäten, um den Grundbetrieb mit den dazu notwendigen Prozes-sen in Ihrer Organisation zu unterstützen. Darüber hinaus kommt dieserEbene jedoch eine zentrale Bedeutung für die gesamte Landschaft zu: Sowerden hier auch die Systeme für Übungen und Einsätze zentral aufgebaut.Darüber hinaus wird von hier auch die Administration der gesamten System-landschaft über die Ebenen hinweg sichergestellt.

Für den Grundbetrieb der betriebswirtschaftlichen Prozesse umfasst dieseEbene damit mindestens ein ERP-System als Produktivsystem sowie SAPNetWeaver als Technologieplattform mit den verschiedenen Komponenten.

Dezentrale Systeme – räumliche Trennung nicht zwingend erforderlich

Hervorzuheben ist dabei jedoch, dass sich die Unterscheidung zwischen den ver-schiedenen Ebenen nicht zwangsläufig auf den physischen Standort der Systemebezieht. So können etwa dezentrale Systeme durchaus im gleichen Rechenzentrumstehen wie die Systeme der zentralen Ebene.



425

Welche Elemente der Technologieplattform verwendet werden (Portal, Busi-ness Intelligence/BW, Master Data Management etc.), ist abhängig von denkonkreten Einsatzszenarien. Darüber hinaus kann zur zentralen Ebene derReferenzarchitektur auch SAP Supply Chain Management mit der Kompo-nente SAP Advanced Planning & Optimization (APO) gehören.

In den meisten Fällen wird darüber hinaus ein System mit der ZentralenBenutzerverwaltung (ZBV) für die Systemlandschaft aufgebaut. In Zukunftwird hier sicherlich anstelle der ZBV vermehrt SAP NetWeaver IdentityManagement zum Einsatz kommen.

Um die Funktionen für den Aufbau der dezentralen Systeme sicherzustellenund die Systemlandschaft insgesamt zu administrieren, werden Sie darüberhinaus weitere Systeme einsetzen:

� Template-System für den Aufbau der dezentralen SystemeIn der Praxis hat es sich bewährt, für den Aufbau der dezentralen Systemeeine Kopie des produktiven ERP-Systems mit den notwendigen Datenbereitzustellen. Die dezentralen Systeme werden durch eine Kopie ausdiesem System heraus erzeugt. Die hierfür notwendigen Ressourcen wer-den durch die Vorteile, insbesondere die Betriebssicherheit, aufgewogen.

� Template-System für Middleware-SystemeWie im Fall des produktiven ERP-Systems werden auch für die Middle-ware-Komponenten entsprechende Systeme als Vorlagen für die Erzeu-gung der dezentralen Systeme bereitgestellt.

� Solution ManagerDer Solution Manager im zentralen Systembereich ist das System, das allenotwendigen Funktionalitäten für alle Systeme der drei Ebenen enthält,um diese aufzubauen, zu verwalten, aber auch (z.B. nach der Rückführungeines Einsatzverbandes) wieder abzubauen.

ERP und DFPS – Das Herzstück Ihres IT-Systems

Lassen Sie sich nicht von der Vielzahl der Komponenten verwirren. Das SAP ERP-System mit der Branchenlösung SAP for Defense & Security (DFPS) ist das absolutzentrale Element Ihrer Landschaft. Dieses System muss das führende System IhrerLandschaft sein, wenn Sie nicht zahlreiche Probleme erzeugen möchten. Dies giltinsbesondere für die Verbindung mit bereits existierenden HR-Systemen – einBereich, auf den wir in Kapitel 15, »DFPS und die Prozesse des Personalwesens«,noch ausführlich eingehen werden. Gehen Sie bei all Ihren Architekturüberlegun-gen immer von diesem ERP-System aus, sodass Sie es als stabile Grundlage für Ihregesamte Systemlandschaft verwenden können.


IT-Architektur12

426

12.2.2 Dezentrale Systeme

Der Aufbau mehrerer Systemebenen ist in vielen SAP-Landschaften eineOption, die nicht zwingend genutzt werden muss. In DFPS-Landschaften istdies jedoch die Regel und versetzt Sie eben in die Lage, eine verteilte System-landschaft aufzubauen, die den besonderen Anforderungen hinsichtlich derAutarkie genügt.

Die zweite Ebene der DFPS-Landschaft wird von den dezentralen Systemengebildet. Diese Systeme unterstützen die Prozesse, die bei einem Offlinebe-trieb ohne Verbindung mit dem Zentralsystem von Bedeutung sind.

Ziel dieser Systeme ist es, die Autarkiefähigkeit des jeweiligen Verbandesauch unter den besonderen Einsatzbedingungen (insbesondere ohne aktiveNetzverbindung) sicherzustellen.

Ebenso wie die zentrale Systemebene besteht auch die Ebene der dezentra-len Systeme aus mehreren Systemen:

� Dezentrale ProduktivsystemeDie dezentralen Produktivsysteme werden von den Einheiten zumeistdirekt in das Einsatzgebiet mitgeführt. Sie enthalten nur den Ausschnittder Daten, der für das jeweilige Einsatzgeschehen notwendig ist.

� Dezentrale Middleware-Systeme Auf dieser Ebene wird ein Middleware-System mit einem Installations-Toolkit-Server installiert, sodass auch die mobilen Anwendungen aufmobilen Endgeräten betrieben werden können.

� Mobile EndgeräteMobile Endgeräte kommen etwa in vorgeschobenen Kommandopostenzum Einsatz. Sie enthalten nicht vollständige Datensätze, sondern nur dieAusschnitte, die für die Prozesse, die dort ausgeführt werden müssen, vonBedeutung sind. Dabei ist nicht nur ein Offlinebetrieb möglich. Vielmehrkönnen die Endgeräte auch direkt mit dem produktiven ERP-System derdezentralen Ebene interagieren.

Beispiele für dezentrale Systeme

Organisatorisch betrachtet, sind dies etwa im militärischen Bereich Systeme aufBrigadeebene, auf Schiffen, auf vorgeschobenen Flugplätzen etc. Im Bereich desKatastrophenschutzes sind dies Systeme aus dem Bereich der Einsatzabschnitte,z.B. einem Flüchtlingslager bei einem humanitären Einsatz im Ausland. Denken Siehierbei etwa wieder an unsere Fallstudie mit der Hilfsoperation nach dem Tsunamiin Lhamosa.



427

� Externe Systeme (GIS, C2)Für den Bereich der Einsätze ist die Verbindung mit Führungssystemen(Command and Control, C2 – etwa bei multinationalen Verbänden) vonbesonderer Wichtigkeit. Dies ermöglicht DFPS dadurch, dass die entspre-chenden Standards für den Datenaustausch (z.B. Allied Data PublicationNo. 3, ADatP-3) unterstützt werden. Darüber hinaus bietet DFPS auch dieMöglichkeit, geographische Informationssysteme (GIS) anzuschließen.

� SpiegelsystemeBei der Darstellung der Anforderungen an die Systemarchitektur habenwir bereits deutlich gemacht, dass für die Verbände im Einsatz Betriebssi-cherheit, kombiniert mit einem geringen Aufwand für die Administration,von höchster Bedeutung ist. Aus diesem Grund werden für die dezentra-len Systeme Spiegelsysteme aufgebaut. Diese dienen dazu, Transporte ein-spielen zu können, um sie testen und jegliche Störungen in den dezentra-len produktiven Systemen ausschließen zu können. Aus diesem Grund istes wichtig, dass für jeden Softwarestand der Systeme ein eigenes Spiegel-system vorgehalten wird.

12.2.3 Beispiel 1 – Systemlandschaft für eine Luftlandeeinheit

Lassen Sie uns das Verfahren für den Aufbau einer Systemlandschaft füreinen Einsatz am Beispiel einer Luftlandeeinheit illustrieren, die etwa zurSicherung einer Hilfsoperation wie der in Lhamosa in ein Einsatzgebiet ver-legt wird.

Aus dem Zentralsystem heraus wird ein Template-System aufgebaut.Ebenso wird ein Template-System für die Middleware aufgebaut. Ausdiesem System heraus werden sowohl das dezentrale Produktivsystemals auch das dezentrale Middleware-System mit den für den Einsatz not-wendigen Daten erzeugt. Da es sich um eine Luftlandeeinheit handelt,wird ein mobiler Kommandoposten zusätzlich noch über mobile Anwen-dungen angebunden. Auch bei einem länger andauernden Einsatz garan-tieren die Spiegelsysteme in der Heimat, dass die im Einsatzraum ver-wendeten Systeme der Luftlandeeinheit störungsfrei verwendet werdenkönnen, da hier alle Änderungen an der Systemkonfiguration getestetwerden können.

Abbildung 12.2 illustriert noch einmal diesen Aufbau. Aus Gründen derÜbersichtlichkeit sind die externen Systeme, die auf der dezentralen Ebeneintegriert werden (GIS, C2), nicht eingezeichnet:


655

Index

A

ABC-Stoffe (Anschlag) 629abgeleitete Rolle 526Abrechnung der Einsätze 563Abweichung 343Abweichungsursache 344ADatP 427, 517ADatP-3 420, 614, 615Adobe-Formular 384, 569Agilität 36, 417Air Task Order 333, 647Aktivierung

mit Organisationsmaßnahme 131ohne Organisationsmaßnahme 126

Alarm- und Ausrückeordnung 571Alarmplan 566ALE-Verteilung von Organisationsdaten

569alternative Kennzeichnung 295ALV 392Analyse 430Analyse und Berichtswesen 371Anforderung

Armee 34IT 38Sicherheitsorganisationen 36

Application Link Enabling (ALE) 423Architektur 417, 418, 436, 461

Anforderung 417Muster 434Referenzarchitektur 422, 423Risiken und Probleme 437Standards 422

Architektur-Board 431Armee

Anforderung 34Besonderheit 37Prozessmodell 41

ASD Spec 1000 D/2000 M 294ASD Spec 2000 M 292ATA-100 294Aufbauorganisation 56, 118

Allgemeine Aufbauorganisation (AAO) 38, 626

Besondere Aufbauorganisation (BAO) 38, 561, 626

Aufgabenkatalog 493Aufwuchsfähigkeit 420Auslandseinsatz Polizei 629Auslieferung 267Ausstattungspaket 112, 221Austauschbarkeit 242Auswertewege 117Autarkie der Systeme 629Autarkiefähigkeit 418, 426, 487, 530

B

Backoffice 602Balanced Scorecard (BSC) 373, 375

Dimensionen BSC 376Bedarfsdringlichkeit 253Bedarfsdringlichkeitsgruppe 253, 258Bedarfspriorität 253, 254, 259Benutzerverwaltung 520Berechtigung 507Berechtigungskonzept 511Berechtigungsmanagement

mobile Systeme 528Berechtigungsverwaltung 520Bereitschaftsgrad 590

Analysieren 595Bereitschaftsstand 594, 596Berichtsaufbereitung 374Besetzungsvorschlag 155, 497, 499Best Practices 195Bestandselement 209, 211, 222Bestandslagerort 329Bestandssituation 250Bestellanforderung

Anlegen 234, 271Umsetzen 263

Betriebsteile 220Betriebswerte 344BEx Query Designer 409BI Content DFPS 401Bottleneck-Qualifikation 182, 198Bottleneck-Ressource 195Bundesamt für Sicherheit in der Informa-

tionstechnik (BSI) 509


656

Index

Bundeswehr 47, 377Hauptprozesse 48Prozessmodell 40Reporting 49

Bundeswehr Balanced Scorecard 49Business Process Owner 501BusinessObjects-Plattform 385Business-Rollen 521Business-Silo 485, 608Business-Szenario 610

C

C2IS 614, 616C2-Systeme 427, 488Capabilities 496Case Management 169Charge 268, 270Checkbox »Abneigungen« 197Coalition Warrior Interoperability

Demonstration (CWID) 431, 614Cockpit 597Composite Application 608Controller 377Core2Defense 467

D

Data Enrichment 538Data Provisioning 614Daten-Cube 399Datenherkunft verändern 297Datenmodell 45Datenqualität 457, 463Defense & Security Hub 513Defense User Interest Group (DEIG) 47Demonstration 629Design 430dezentrales Qualifikationsmanagement

195dezentrales System 315, 423, 426, 537,

539, 540DFPS 65

Einsatz 39Funktionalitäten 46Grundanforderung 33Struktur 78, 90, 116

DFPS-ImplementierungAnsatz 463bestehende Erweitern 466Krisenmanagementlösung einer Region

468Prozessmodul 454vollständige (Streitkräfte eines Landes)

464Dienstvorschrift 509Digitalfunk 572Disponenten-Workbench 234, 261DOE 528DV 100 576

E

EA-DIMP 240Earned Value Reports 594, 596Eigenschaft

Adaptieren 162Einbauort 295, 299Einsatz

Abrechnung 564Aktivieren 171Beenden 173Nachbereitung 564

Einsatz- und Blaulichtorganisationen 65Bedingung 46Bereitschaft 489Durchführung 564Gerät 328Intensität 151Kontingent 54

Einsatzlebenszyklus 139Phase 1 141Phase 2 146Phase 3 170Phasen 4 und 5 172

Einsatzleitrechner 573Einsatzleitsoftware 44Einsatzleitsystem 573Einsatzorganisation 137, 177, 481, 482Einsatzplan 633Einsatzplanung 194, 495, 498, 564Einsatzstruktur 121, 561, 633Einsatzstrukturelement 278

Anlegen 150


657

Index

Einsatzstrukturplanung 153Einsatztaktik Polizei 626Einsatztyp 151, 634, 635, 636Einsparung 593Einzeländerung 131Einzelverbrauchsgüter (EVG) 209, 245Emergency Data Exchange Language

(EDXL) 420Enterprise Service Interface 612Enterprise Services 611, 612, 613Epizentrum 55Equipment 299

Einbauort 299Nummerierung 301

Erstausstattung 171erste logistische Ebene 535, 538Erstversorger Material 252Erstversorgung 251Ertragsperspektive 596erweiterte Historie 301Erweiterungspaket 613ESR 613ES-Workplace 589, 609EU-Mechanismen 561Eventualfallplanung 144

F

Fachinformationssystem 40, 487, 616Katastrophenschutz 44

Factory-to-Foxhole-Prozess 536Fähigkeit 483

Suchen 154fähigkeitsorientierte Planung 142Fall-ID 635Fallstudie 53, 306

Ausgangslage 53Planungsphase 147

First Mission 138Flexibilität 287Flug 63, 331Flugauftrag 331, 335Flugbetrieb 317Fluggeräteinstandsetzung 586Flugplan 343Flugsicherheit 239Flugstatus 343, 586

Flugstunde 594garantierte Verfügbarkeit 584

Flugübersicht 63, 336Folgeaktion 170Folgeversorgung 252Force Multiplier 38, 39Force Provider 483Formulare offline 579Fremdsystem 462Friedensstruktur 118Frost & Sullivan 582Führungsinformationssystem 39, 487,

616funktionale Blöcke (Katastrophen-

schutz) 561funktionaler Ansatz 465Fußball-Europameisterschaft 2008 52

G

garantierte Verfügbarkeit 584Gegenstromprinzip 378Geheimhaltungsbedarf 512, 637Geheimhaltungsvorschrift 636Geheimschutz 634Geiselnahme 629Genehmigungsprozess 497Geoinformationssystem (GIS) 427, 570,

633Geolokationen 57geplante Kosten 594Geschäftsmodell

neues 585Geschäftsprozesse 605GIS 57Golden Hour 51Governance-Modell 422Governmental Organization 347GRC 524grenzüberschreitende Kriminalität 631Großschadensereignis 44Großschadenslagen 572Grundprozesse von Sicherheitsorganisati-

onen 560Grundschulung DFPS 442Gültigkeit 195Gültigkeitszeitraum 185


658

Index

H

Halbwertszeit 185, 195Halter 276Halterwechsel 276Haushaltsmanagement 396Herstellerteiledatum 240Herstellerteilenummer 239, 240, 242heterogene Systemlandschaft 421Hinverlegung 172Hinweiscode 271, 272Hochwasser 379, 563Hochwasserlage 573horizontale Integration 329

I

ICM 623, 633, 638ICM-System 632iCOD 616Identity Center 522Identity Store 522IH-Planungswerk 302Implementierungsstudie 429Individualausbildung 408, 433Individualmaßnahme 131InfoProvider 411Information und Einsatz im Sanitäts-

dienst (IES) 51informationsgetriebene Bereiche 623Informationsüberlegenheit 601Infotyp

0024 1920806 2011055 1871950 5041953/1954 5051956 5031988 205783 500806 200, 203

Infrastruktur 77Infrastrukturplanungsobjekt 115Instandhaltung 543, 552

Dimensionen 284militärische 284

Instandhaltungsauftrag 253Instandhaltungsbeziehung 303, 310

spezialisierte 307

Instandhaltungsbezogene Unterneh-mensstruktur 286

Instandhaltungsstrategie 582Instandhaltungstiefe 285Instandsetzungsbeziehungen 304Instandsetzungskosten 594Integration 168, 462

ICM und DFPS 633Organisation und Logistik 212

integriertes Produkt- und Prozess-Engi-neering (iPPE) 107, 214

Interaction Center 566interaktive Formulare 631Intervallbeleg 327iPPE-Objekt 494IS-A&D � EA-DIMPIst-Bestand 62Ist-Rüstcode 336itelligence AG 51Item Unique Identification 238

K

Katalog 492, 494, 503Katastrophenschutz 559

Charakteristika 625Kalender 566Krisenstab 518Ressourcenmanagement 560

Kennzahlen 49Kommunikation

unterschiedliche Schutzstufen 515Kommunikation im Stab 564Kontingent 278

Definieren 152Kontingentgröße 158Kontingentplanung 152, 157, 159, 161,

483, 503kontrolliertes Abfliegen 336, 337Koordinierter Sanitätsdienst in der

Schweiz 51, 561, 628Kopierfunktion 496

Planstellen 161Kopiermöglichkeit 165Kosten

geplante 594ungeplante 594

Kosteneinsparung 37Kostenstellenstruktur 593


659

Index

Krisenmanagement 565Krisenstab 45

Katastrophenschutz 518Kursangebot DFPS 440

L

Lagefeststellung 564Lager 37Lagerort 255, 270Laufbahnplanung 196Lebenszyklusmodell 139Leih-Banf 276Leihe 276Leitstelle 44, 563, 566, 572Leitstelle auf Basis von SAP ICM 571Leitstellenarbeit 565Leitverband 252, 484Lessons Learned 177letzte taktische Meile 534Lhamosa 372, 373, 418, 420, 516, 519,

629, 631Lieferantencharge 268Lieferpriorität 260Liegeplatz 342Logistic Assessment 604, 613, 618Logistics Execution System (LES) 424logistische Ebene 275logistische Unternehmensstruktur 248Luftfahrtgesellschaft 584Luftfahrtindustrie 598Luftfahrzeug 584

M

mangelhafte IT-Unterstützung 563Master Parts List 244, 343Master-Equipment 327, 329, 338Material

Planen 164Materialbewirtschaftung 544Materialcontainer 110, 219Materiallage 223Materialnummer 236Materialplanungsobjekt 60, 106, 213,

214Modelle 215

MaterialstammMaterialstamm anlegen 250

Materialstammsatz 214Materialverantwortlicher 217materielle Planung 227, 257

Ablaufsübersicht 230materielles Ist 222materielles Soll 60, 245Maximalprinizp 345mehrere DFPS-Leitstellen 574Meldebestand 247Mengenverbrauchsgüter (MVG) 209,

245Microsoft Office-Produkte 563Middleware 537, 539, 540Military Data Exchange 603Milizarmee 286MilStd 2525B 488Minimalprinzip 346Mission 329mobile Anwendung 533, 536Mobile Client 424, 538

Benutzer anlegen 529Mobile Defense & Security (MDS) 315,

534Mobile Infrastructure 424mobile Instandhaltung 315mobile Systemlandschaft 528mobiles Reporting 548mobiles System

Berechtigungsmanagement 528Model Identification Code 292Model Identifier � Model Identification

Code 338Modell 217MPO-Organisationseinheit 218MPO-Workbench 107, 214MPO-Zuordnung 218MRO 313MRO-Services 584

N

Nachbereitung des Einsatzes 564Nachrichtendienst 623

Lösung 632Musterprozesse 637Prozesse 625


660

Index

NATO 420, 431, 603NATO Architecture Framework (NAF)

428NATO Stock Number 236NATO-Standard 45Network Centric Warfare 599Netze 515

Trennung (rot und schwarz) 515Netzwerk 514netzwerkzentrierte Kriegsführung 419,

599netzwerkzentriertes Unternehmen 601neue Geschäftsmodelle 585Nichtverbrauchsgüter 209niedrigere Schutzstufe 517Nutzer 276

O

oberster Technischer Platz 322OF-Transaktionen 68Olympische Spiele 624, 627On-going Mission 138Operational Planning 137, 488, 491Operationalisierung

Backoffice 602Operationsplaner Polizei 634operative Gewichtung 204operativer Beginn 151operatives Berichtswesen 387operatives Ende 151Organisation und Personal 546organisationsbezogene Stammdaten 302Organisationsebenenfeld 527Organisationsmaßnahme 131, 149, 157,

185, 193, 498, 504Statuswechsel 150

Organisationsplan 482, 486, 495Organisationsstruktur 38, 55organisatorische Flexibilität 46, 53, 65,

250, 305, 308, 461organisatorische Priorität 253, 254, 255organisierte Kriminalität 631Outsourcing 285

P

parallele Struktur 118PBL 286, 581, 582PBL-Anbieter 588, 591PBL-Architekturvarianten 588PBL-Prozess 586

Flugzeuginstandhaltung 587PBL-Systemunterstützung 588PBL-Szenario 585, 589PBL-Unterstützung

Bereiche 590Pegelstand 382Performance-Based Logistics � PBLPerson 100Personal

Planen 156Personalmaßnahme 499, 500Personalplanung 171Personalwesenprozess 192personelles Ist 187personelles Soll 187, 192Persönliche und funktionelle Ausrüs-

tung 100phasenorientiertes Vorgehen 456Planstelle 97Planstellenkontingent 159Planung

Eventualfallplanung 145fähigkeitsorientierte 142Herausforderung 145

politische Einflüsse 455Polizei 560, 566, 623

Auslandseinsatz 629Charakteristika 625Einsatztaktik 626Operationsplaner 634Prozesse 625

PolizeiorganisationAuslandseinsatz 624Plattform 632

Power by the hour 584Praxisbericht 47Pressluftatmer 585priorisierte Disposition 262Priorität 253Privatindustrie 48Process Maturity 501


661

Index

Process Performance Indicators 346Product Data Replication (PDR) 423Programmmanagement 589Programmmanager 597Projekt

1. Phase 463Bereitschaftsstand 458Bestandteil 461grundsätzliches Vorgehen 460Komplexität 454Phasen 456Rahmenbedingung 459Zielvorgaben 460

Projekt- und Risikomanagement 453Projektmanagement 456, 457, 461Projektrisiken 471, 472

fachliche 477Top 9 472

ProjektrollenArchitekt 445Basisberater 448Change-Management-Berater 449DFPS-Berater 447Programmmanager 444Projektleiter/Teilprojektleiter 444Sicherheitsexperte 449Stellenanzeige 446, 448

ProjektteamAnforderung 439Checkliste 451Rollen 439Rollenverteilung 443Schlüsselrollen 442

Projektvorgehen 458, 464Core2Defense 467Krisenmanagement 470

Provisioning Framework 522Provisions 246Prozessbereich 40Prozesse

Nachrichtendienst 637Polizei 625Sicherheitsorganisationen 559, 624

ProzessmodellArmee 41Bundeswehr 40Sicherheitsorganisationen 43

prozessuale Festlegung 462

Q

Qualification Management 177Qualifikation 180, 184Qualifikationsblock 180, 185, 192, 491,

501Qualifikationsgruppe 182, 183

Anlegen 183Qualifikationskatalog 180, 185, 194Qualifikationsmanagement 178, 488

dezentrales 195Qualifikationsstammdaten

Verwalten 180

R

Rahmenbedingung 34Raumfahrtindustrie 581, 598Rechnungswesen 168, 345Referenzarchitektur 422, 423Referenzmesspunkt 297, 326

Anlegen 297Referenzplatz 325Referenzrolle 526Regelbetrieb 561Reorder Point 247Reportable Item Code 63, 111Reporting 593, 596

Mittlere Führungsebene 373mobiles 548Operative Ebene 373

Reporting Materialwirtschaft 389Reporting Politische Ebene/Obere Füh-

rungsebene 372Reportingpyramide 372, 385Rolle 511Rollen- und Berechtigungskonzept 511Rollenmanager 526rotes Netz 508, 515Routinebetrieb 44Rückführungscode 275Rückgabedatum 276Rücklieferung 61, 273Rücklieferungs-Bestellanforderung 276,

649Rückverlegung 172Rüstungs- und Raumfahrtindustrie 581Rüstzustand 332


662

Index

S

Sandbox-System 503Sanitätsdienst Schweiz � Koordinierter

SanitätsdienstSAP BusinessObjects Access Control 522SAP BusinessObjects Explorer 379, 381SAP BusinessObjects governance, risk,

and compliance (GRC) 520SAP BusinessObjects Strategy Manage-

ment 376SAP BusinessObjects-Portfolio 596SAP Developer Network (SDN) 589, 613SAP Enterprise Architecture Framework

428SAP for Aerospace & Defense 82SAP Interactive Forms by Adobe 569,

575, 630SAP Investigative Case Management (SAP

ICM) 565, 570SAP NetWeaver BW 397, 400, 594SAP NetWeaver Identity Management

425, 520, 521, 523SAP-Lösungsbestandteile (Polizei) 632Schadensart 306schadensbedingte Instandhaltung 308Schadensbehebung 538, 550Schichtenmodell – S4-Krisenstab im

Katastrophenschutz 518Schnittstelle 630Schulungskatalog 441Schulungsplan 450Schutzaufgaben 547, 550Schutzstufe

niedrige 517schwarze Netze 515Schweiz 572Serialisierungsinformation 292Serialnummernprofil 238Service Operations 612Servicebetrieb 582serviceorientierte Architektur 599, 604,

613Services 612Sicherheit 507

dezentrales System 514DFPS-Checkliste 531

Sicherheitsanforderung 422

Sicherheitsgateway 517Sicherheitskonzept 507, 509, 511Sicherheitsorganisation

Anforderung 36Besonderheiten 37Prozesse 42, 624Prozessmodell 43

Sicherheitsstufe 515Sicherheitsüberprüfung 637Singapur Armed Forces 51Site-Equipment 329Skala 184

Vererben 184Smong 59SOA-Definition 605Sofortlage 626Softwarearchitektur 533Soll-Ist-Vergleich 215, 224, 227

Struktur-Workbench 224Soll-Rüstcode 336Solution Map 609Spezialeinheit 626Spezialkräfte 512, 513, 514Spiegelsystem 427staatliche Einsatzorganisaton 347Stab 147

Kommunikation 564Stabsarbeit 565, 579Stabslösung 576Stammdaten 54, 287, 492, 494

organisationsbezogene 302Standard-Anwendungs-Software-Pro-

dukt-Familien (SASPF) 48Standardversorger 231Standortwerk 302Statusboard 63, 318, 337Statuscode 271Statusnetz 125Statusprüfung 170Stelle 105, 198Strategie-Dashboard 596, 597Streitkräfte Singapurs 50Streitkraft-zentrierter Ansatz 465Struktur 118

parallele 118technischer Hintergrund 148

Struktur � DFPS-StrukturStrukturebene 143


663

Index

Strukturelement 75, 85, 209, 303Berechtigungen 526Integration in die Logistik 209

Strukturelement »Logistic Unit« 160Strukturelemente integrieren 209Strukturkennzeichen 295, 323Strukturlücke 343Struktur-Workbench 71, 487Stücklisten 301Suche 231Sustainability 267, 273Synchronisation 538, 542, 552System

dezentrales 423, 426, 537, 539, 540rotes 508Spiegelsystem 427Template-System 425zentrales 423, 539

Systemarchitektur 535Spezialkräfte 513

Systemebenezentrale 423, 424

Systemlandschaftheterogene 421Luftlandeeinheit 428mobile 528

SzenarioPolizei 625

T

Tabelle /ISDFPS/FORCE 496Tabelleneintrag /ISDFPS/FORCE 505Table of Organization and Equipment 68Tail Number 324, 341Tail Number � taktisches KennzeichenTakeover/Handover 313taktisches Kennzeichen 324TDv/B007 294Technische Objekte 288

organisatorische Flexibilität 290Stammdaten 288

Technische Referenzplätze 297Technischer Platz 289, 296

Kennzeichnung 295Nummerierung 291Serialisierungsinformation 292

Technischer Referenzplatz 291Technologieebenen SAP BusinessOb-

jects 412Teilekennzeichen 240Teilflugstrecke 333Teilstreitkraft 433, 455Telekommunikationsüberwachung (TKÜ)

633Template-System 425, 539The Open Group Architecture Frame-

work (TOGAF) 428THW 383Time Change Item 335, 649Train as you fight-Grundsatz 486Trainingsdaten 200Trainingsprogramm 199Transaktion 67

/isdfps/MAT_COMP 226/isdfps/TOEM 1 392/isdfps/TOEM 2 392/ISDFPS/TOEP1 188/isdfps/TOEP1 193PPPM 188

Transport- und Logistikbranche 584TREX 383truppendienstliche Unterstellung 120trusted RFC-Verbindung 634Tsunami 57

Einsatzplaner 510Fallstudie 394, 562Hilfsoperation 388

turn-over-time 285Twitter 601

U

Übungsstruktur 122Umlagerungsbestellung 228Unfallmeldebericht 550ungeplante Kosten 594Unique Item Identifier 238Unternehmensstruktur 207Unterstützungsbeziehungen 209User Interface 615


664

Index

V

Value Chain 609Verbrauchsgüter 593Vereinte Nationen 629Verfeinerung 431Verfügbarkeit (Luftfahrzeuge)

Berichte 594Verknüpfung

Planstellen 157Speichern 182

Verlegeplanung 278Verlegung 279Vermisstenauskunft 565Verschlüsselung 509Versorger 61Versorgungsartikelkonzept 236, 243Versorgungsbeziehung 61, 231Versorgungsnummer 236Verteidigungsstruktur 119verteilte Instandhaltung 315Verwendungstyp 56, 74Vierfachvordruck 576Vierfachvordruck als interaktives Formu-

lar 577Virtual Directory Servers 522Virtual Private Networks (VPN) 516Vorgehensmodell

Architektur 428, 429Vorratselement 209, 211, 246Vorratslagerort 246, 249Vorratspaket 62, 114, 245

W

Waffensysteme 583Wandel des Einsatzspektrums 35Warengruppe 216Wax Boards 320Webservices 412Webservices IdM 523

Weiterleitungsfunktion 307Weltwirtschaftsforum Davos 52Weltwirtschaftsgipfel 624Werk 255Workbench

Qualifikationen pflegen 190Workflow 306, 578Workitem 155WSDL 612

X

Xcelsius 385, 413XML 517

Y

Yowie 601

Z

ZBV-AnbindungÄndern 530

ZBV-VerbindungÄndern 531

Zeitlage 626, 627zentrale Benutzerverwaltung (ZBV) 425,

524, 539zentrale Systemebene 423, 424zentraler Personalwesenprozess 192zentraler Qualifikationskatalog 180, 185zentrales System 423, 539Zielvereinbarung 197Zulu-Zeit 334Zuordnungszeitraum 194Zustandscode 267, 275Zustandsverwaltung 269Zwischenstopp 334


Documents

Sappress Sap for Dfps