You are on page 1of 62

Bernhard Escherich, Heinrich Pfriemer, Wolfgang Ullwer

SAP for DFPS Implementierung und Customizing

Bonn Boston

Auf einen Blick


TEIL I 1 2 3 Einfhrung und Grundlagen ...................................... 31

Einfhrung in DFPS Anwendungen in der Praxis ................ 33 Fallstudie Tsunami-Hilfsoperation ...................................... 53 Stammdaten und Organisationsstruktur als Grundlage der Implementierung ........................................... 65 Prozesse, Funktionen, Customizing .......................... 135

TEIL II 4 5 6 7 8 9

Operational Planning ............................................................ 137 Implementierung der Prozessgruppe Qualification Management ................................................ 177 Logistik ................................................................................ 207 Materialwirtschaft ................................................................ 245 Instandhaltung ..................................................................... 283 Untersttzung des Flugbetriebs ............................................ 317

10 DFPS und Rechnungswesen .................................................. 345 11 Berichtswesen/Reporting ..................................................... 371 TEIL III Erfahrungen aus Implementierungsprojekten .......... 415

12 IT-Architektur als Herausforderung fr 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 Rstungsund Raumfahrtindustrie ....................................................... 581 20 SOA und Network Centric Warfare mit DFPS ....................... 599 21 Polizei und Nachrichtendienste ............................................ 623 22 Ausblick ............................................................................... 639

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

TEIL I Einfhrung und Grundlagen


Eine Lsung 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 fr Ihre Bedrfnisse nutzen knnen. 33

Einfhrung in DFPS Anwendungen in der Praxis ............. 33


1.1 Grundanforderungen an DFPS ............................................... 1.1.1 Rahmenbedingungen ................................................. 1.1.2 Besonderheiten von militrischen und Sicherheitsorganisationen .......................................... 1.1.3 Vor dem DFPS-Einsatz Informationssysteme in Armeen und Sicherheitsorganisationen ........................ DFPS Funktionalitten und Integration in Armeen und Sicherheitsorganisationen .............................................. Beispielhafte Praxisberichte ................................................... 1.3.1 Beispiel 1 Bundeswehr ............................................. 1.3.2 Beispiel 2 Die Streitkrfte Singapurs ......................... 1.3.3 Beispiel 3 Koordinierter Sanittsdienst in der Schweiz (KSD) ...................................................... Fazit ...................................................................................... 33 34 37 39 46 47 47 50 51 52

1.2 1.3

1.4

Eine gewaltige Naturkatastrophe in einem Land am Rande des Pazifiks bildet den fiktiven Hintergrund fr unsere Fallstudie. Wir zeigen, wie SAP for Defense & Security die Einsatzkrfte bei der Bewltigung dieses Szenarios untersttzt. 53

Fallstudie Tsunami-Hilfsoperation ................................... 53


2.1 2.2 2.3 2.4 Ausgangslage ......................................................................... Tsunami ................................................................................. Rettungsoperationen mit DFPS-Untersttzung ....................... Fazit ...................................................................................... 53 57 60 64

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


3.1 Organisatorische Flexibilitt ................................................... 3.1.1 Das Skelett einer Organisation .................................... 3.1.2 Organisatorische Flexibilitt im Detail ......................... Integration ............................................................................ 66 66 67 79

3.2

Inhalt

3.3

3.4

3.5

3.6

Gesamtstammdatenmodell von DFPS ................................... 3.3.1 Das Strukturelement technischer Fokus .................... 3.3.2 Planstelle ................................................................... 3.3.3 Person ........................................................................ 3.3.4 Stelle .......................................................................... 3.3.5 Zusammenfassung ....................................................... 3.3.6 Material- und Infrastrukturstammdaten ...................... Strukturen der Branchenlsung DFPS ..................................... 3.4.1 Strukturen des Organisationsmanagements ................. 3.4.2 Neue Auswertewege .................................................. Statusnetz und Aktivierung von Strukturen ............................ 3.5.1 Aktivierung ohne Organisationsmanahme ................. 3.5.2 Statusnderung mit Organisationsmanahmen ............ 3.5.3 Zusammenfassung ....................................................... Fazit ......................................................................................

83 85 97 100 105 106 106 116 116 117 124 126 131 132 133

TEIL II Prozesse, Funktionen, Customizing


Operational Planning oder Einsatzplanung stellt die Kr der Herausforderungen an IT-Systeme dar. Diese Prozessgruppe werden wir Ihnen in diesem Kapitel mit all ihren Funktionalitten anhand eines beispielhaften Verlaufs nherbringen. 137

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


4.1 4.2 4.3 4.4 Voraussetzungen ................................................................... Lebenszyklusmodell ............................................................... Phase 1 Rahmenbedingungen ............................................. Phase 2 Planung ................................................................. 4.4.1 Die Herausforderungen der Planung ........................... 4.4.2 Fallbeispiel die Planungsphase des Einsatzes ............ Phase 3 Genehmigung und Erstausstattung ......................... 4.5.1 Genehmigungsschritte durchfhren ............................ 4.5.2 Personalplanung ......................................................... 4.5.3 Einsatz aktivieren ........................................................ 4.5.4 Erstausstattung ........................................................... Phasen 4 und 5 Hin- und Rckverlegung sowie Durchfhrung des Einsatzes ................................................... Fazit ...................................................................................... 137 139 141 145 145 147 169 170 171 171 171 172 174

4.5

4.6 4.7

Implementierung der Prozessgruppe Qualification Management ............................................. 177


5.1 5.2 Grundlagen und Zielsetzung .................................................. 177 Integrierte und einheitliche Verwaltung der Qualifikationsstammdaten ..................................................... 180

Inhalt

5.3

5.4

5.5 5.6 5.7

5.8 5.9

5.2.1 Zentraler Qualifikationskatalog ................................... 5.2.2 Qualifikationsgruppe .................................................. 5.2.3 Qualifikation ............................................................... 5.2.4 Qualifikationsblock ..................................................... Das personelle Soll Abbildung der Anforderungen und Fhigkeiten ..................................................................... 5.3.1 Zuordnung ber das Personalmanagement Transaktion PPPM ...................................................... 5.3.2 Zuordnung ber Organisationsgrundlagen Personelle Anteile Transaktion /isdfps/TOEP1 ........... 5.3.3 Voraussetzungen fr die Zuordnung von Qualifikationen und Qualifikationsblcken ................. Das personelle Ist Abbildung der Fhigkeiten einer Person ................................................................................... 5.4.1 Zuordnung ber die Pflege der Personalstammdaten Transaktion PA30 ................................ 5.4.2 Zuordnung ber den Strukturarbeitsplatz Transaktion /isdfps/TOEP1 .......................................... Untersttzung der Personalauswahl das Beispiel Einsatzplanung ................................................................... Zielvereinbarungen und Beurteilungen .................................. Ableitung von Qualifikationen Infotyp Trainingsprogramm (806) aus der Instandhaltung ............... 5.7.1 Voraussetzungen fr die Ableitung von Qualifikationen aus dem Flugbetrieb .......................... 5.7.2 Beispielhafter Prozessablauf ........................................ Operative Gewichtung Bewertung der Verknpfung zwischen Qualifikationen und Planstellen/Stellen .................. Fazit ......................................................................................

180 182 184 185 187 188 189 190 192 192 193 194 197 199 200 202 204 206

Innerhalb der Branchenlsung SAP for Defense & Security nehmen die Funktionen fr Defense Logistics eine zentrale Rolle ein. Im Verbund mit der organisatorischen Flexibilitt sind sie die tragende Sule des Softwarepakets. 207

Logistik ................................................................................ 207


6.1 6.2 Unternehmensstruktur ........................................................... Integration des Strukturelements in die Logistik .................... 6.2.1 Materielles Soll ........................................................... 6.2.2 Materielles Ist Bestandselemente ............................. Soll-Ist-Vergleich ................................................................... 6.3.1 Soll-Ist-Vergleich in der Struktur-Workbench ............. 6.3.2 Zustzliche Funktionen zum Soll-Ist-Vergleich ............. Materielle Planung ................................................................ NSN und IUID ....................................................................... 207 209 213 222 224 224 225 227 235

6.3

6.4 6.5

Inhalt

6.6 6.7 6.8

Herstellerteilenummern ......................................................... 239 Austauschbarkeit ................................................................... 242 Fazit ...................................................................................... 244

From Factory to Foxhole das ist die erklrte Zielrichtung militrischer Bewirtschaftungsprozesse. Lesen Sie im Folgenden, wie SAP for Defense & Security die spezifischen Anforderungen an die Materialwirtschaft erfllt. 245

Materialwirtschaft .............................................................. 245


7.1 Erst- und Folgeversorgung mit Vorratspaketen ....................... 7.1.1 Vorratspakete anlegen und pflegen ............................. 7.1.2 Integration der Strukturelemente in die logistische Unternehmensstruktur ................................................ 7.1.3 Prozesse der Erst- und Folgeversorgung ...................... Prioritten ............................................................................. 7.2.1 Prioritten fr Materialbedarfe .................................... 7.2.2 Organisatorische Prioritt ........................................... 7.2.3 Bedarfsprioritt ........................................................... 7.2.4 Lieferprioritt .............................................................. Zustandsverwaltung ............................................................... 7.3.1 Zustandscode .............................................................. 7.3.2 Prozessuale Abwicklung der Zustandsverwaltung ........ Hinweiscode und Statuscode ................................................. Rcklieferung ........................................................................ Leihe .................................................................................... Verlegeplanung ..................................................................... 7.7.1 Einstze ...................................................................... 7.7.2 Verlegungen ............................................................... 7.7.3 Verlegeschritte ............................................................ 7.7.4 Verlegeschritt-Typen ................................................... Fazit ...................................................................................... 245 246 248 251 253 253 254 256 260 267 267 270 271 273 276 278 278 279 279 279 281

7.2

7.3

7.4 7.5 7.6 7.7

7.8

Angesichts wachsenden Kostendrucks in Sicherheits- und Verteidigungsorganisationen kommt der wirtschaftlichen Gestaltung von Instandhaltungsaktivitten grere Bedeutung zu. DFPS untersttzt Sie dabei mit speziell fr Ihre Branche entwickelten Funktionen. 283

Instandhaltung .................................................................... 283


8.1 8.2 8.3 Besonderheiten militrischer Instandhaltung .......................... Instandhaltungsbezogene Unternehmensstruktur ................... Stammdaten .......................................................................... 8.3.1 Stammdaten Technischer Objekte ............................... 8.3.2 Technische Pltze ....................................................... 8.3.3 Technische Referenzpltze und Referenzmesspunkte ... 8.3.4 Equipment .................................................................. 8.3.5 Stcklisten .................................................................. 8.3.6 Organisationsbezogene Stammdaten .......................... 8.3.7 Instandhaltungsbeziehungen ....................................... 284 286 287 288 289 297 299 301 302 303

10

Inhalt

8.4

8.5 8.6 8.7

DFPS-spezifische Prozesserweiterungen in der Instandhaltung ...................................................................... 8.4.1 Schadensbedingte Instandhaltung ............................... 8.4.2 Takeover/Handover .................................................... Verteilte Instandhaltung ........................................................ Mobile Instandhaltungsprozesse ............................................ Fazit ......................................................................................

308 308 313 315 315 316

Mit SAP for Defense & Security (DFPS) stehen fr die Untersttzung des Flugbetriebs spezielle Funktionen, erweiterte Stammdaten und flexible Benutzeroberflchen zur Verfgung, die auf die Anforderungen fliegender Verbnde abgestimmt sind. 317

Untersttzung des Flugbetriebs ......................................... 317


9.1 9.2 uere Gegebenheiten .......................................................... Stammdaten fr die Untersttzung des Flugbetriebs .............. 9.2.1 Objekt Master-Equipment ....................................... 9.2.2 Objekt Site-Equipment ............................................ 9.2.3 Objekt Mission ........................................................ Prozesse des Flugbetriebs ...................................................... 9.3.1 Anlegen von Flugauftrgen ......................................... 9.3.2 Zuordnung der Luftfahrzeuge zum Flugauftrag............. 9.3.3 Kontrolliertes Abfliegen .............................................. 9.3.4 Monitoring der Flotte Statusboard ........................... 9.3.5 Statusverwaltung technischer Status und Einsatzstatus ............................................................... 9.3.6 Rstprozess und Flugvorbereitungen inklusive Rckmeldung .............................................................. 9.3.7 Den Flug verfolgen und Folgemanahmen anstoen ..................................................................... Fazit ...................................................................................... 317 321 327 329 329 331 331 335 336 337 339 341 343 344

9.3

9.4

Mit einer guten Verwaltung der finanziellen Ressourcen durch ein zuverlssiges Rechnungswesen ist die Basis fr die Transparenz der Geldflsse gelegt. Gerade in Zeiten der Transformation von Streitkrften und des Rckgangs von Steuereinnahmen ist es wichtig, zu wissen, wie viel etwas kostet. 345

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


10.1 10.2 Das Rechnungswesen im Bereich der Einsatzorganisationen ... Integration von DFPS und Rechnungswesen .......................... 10.2.1 Grundlagen ................................................................. 10.2.2 Controlling .................................................................. 10.2.3 Projektsystem ............................................................. 10.2.4 Haushaltsmanagement ................................................ 10.2.5 SAP Real Estate Management .................................... Rechnungswesenspezifische Statuswechselprfungen und Folgeaktionen ........................................................................ 10.3.1 Statuswechsel: Geplant Beantragt ............................ 10.3.2 Statuswechsel: Beantragt Genehmigt ....................... 345 347 347 348 359 362 364 366 366 367

10.3

11

Inhalt

10.4 10.5 10.6

10.3.3 Statuswechsel: Genehmigt Aktiv .............................. Lschen und Abgrenzen von Strukturen und die Auswirkungen auf das Rechnungswesen ................................ Technische Objekte und Rechnungswesen ............................. Fazit ......................................................................................

367 368 369 370

Fr die Modernisierung der Streitkrfte 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 11.2 Fragestellungen und Konzepte als Grundlagen fr das Berichtswesen ....................................................................... Erprobung der Reportingmglichkeiten ................................. 11.2.1 SAP BusinessObjects Explorer ..................................... 11.2.2 Suchfunktion im SAP BusinessObjects Explorer............ Besonderheiten bei Projekten im Katastrophenschutz ............ Mglichkeiten und Funktionalitten fr das Berichtswesen DFPS und SAP-Standardfunktionalitten ................................ 11.4.1 Operatives Berichtswesen ........................................... 11.4.2 DFPS und SAP NetWeaver BW ................................... Technologische Grundlagen .................................................. Fazit ...................................................................................... 372 378 379 383 384 386 387 397 412 413

11.3 11.4

11.5 11.6

TEIL III Erfahrungen aus Implementierungsprojekten 12 IT-Architektur als Herausforderung fr Armeen und Sicherheitsorganisationen ........................................... 417
12.1 Anforderungen und Rahmenbedingungen .............................. 12.1.1 Einstze und Autarkiefhigkeit .................................... 12.1.2 Interoperabilitt .......................................................... 12.1.3 Aufwuchsfhigkeit ...................................................... 12.1.4 Heterogene Systemlandschaft ..................................... 12.1.5 Extrem hohe Sicherheitsanforderungen ....................... Referenzarchitektur ............................................................... 12.2.1 Zentrale Systemebene am Heimatstandort .................. 12.2.2 Dezentrale Systeme .................................................... 12.2.3 Beispiel 1 Systemlandschaft fr eine Luftlandeeinheit .......................................................... Vorgehensmodell .................................................................. 12.3.1 Phase 1 Implementierungsstudie .............................. 12.3.2 Phase 2 Analyse ....................................................... 12.3.3 Phase 3 Design ........................................................ 418 418 419 420 421 422 422 424 426 427 428 429 430 430

12.2

12.3

12

Inhalt

12.4

12.5 12.6

12.3.4 Phase 4 Verfeinerung ............................................... 12.3.5 Phase 5 Stndige Verbesserung ................................ 12.3.6 Hilfsmittel und Vorlagen ............................................. Typische Architekturmuster ................................................... 12.4.1 Beispiel 2 Verteilte Einheiten im Einsatzraum mit einem Unterstellungsverhltnis ............................. 12.4.2 Beispiel 3 Versorgungsbeziehung zwischen Einheiten im Einsatzraum mit Bezug zur Heimatbasis ................................................................ Risiken und Probleme ............................................................ Fazit ......................................................................................

431 431 432 434 434

436 437 438

Die richtige Auswahl von qualifizierten Projektmitgliedern ist entscheidend fr den Erfolg Ihres DFPS-Projekts. In diesem Kapitel erfahren Sie, welche Experten Sie fr Ihr Projekt bentigen, worin deren Aufgaben bestehen und welche Erfahrungen und Kenntnisse sie mitbringen mssen. 439

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


13.1 13.2 Grundstzliche Anforderungen .............................................. Die Rollen im Einzelnen ......................................................... 13.2.1 Programmmanager ..................................................... 13.2.2 Projektleiter/Teilprojektleiter ...................................... 13.2.3 Architekt ..................................................................... 13.2.4 DFPS-Berater ............................................................. 13.2.5 Basisberater ................................................................ 13.2.6 Sicherheitsexperten .................................................... 13.2.7 Change-Management-Berater ..................................... 13.2.8 Schulungsplan fr Berater ........................................... Checkliste fr ein DFPS-Projektteam ...................................... Fazit ...................................................................................... 439 443 444 444 445 447 448 449 449 450 451 451

13.3 13.4

Das Projekt- und Risikomanagement fr ein DFPS-Projekt stellt besondere Anforderungen an Sie. In diesem Kapitel erfahren Sie, welche Anstze und Methoden sich bewhrt haben und welche Risiken bestehen. 453

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


14.1 Grundstzliche berlegungen ................................................ 14.1.1 Komplexitt von DFPS-Projekten ................................ 14.1.2 Komplexitt reduzieren und kontrollieren ................... Mgliches Projektvorgehen ................................................... 14.2.1 Der Schritt vorab Bereitschaftsstand fr das Projekt? ................................................................ 14.2.2 Grundstzliches Projektvorgehen ................................ Projektrisiken ........................................................................ 14.3.1 Grundstzliche berlegungen und Vorgehen .............. 14.3.2 Allgemeine Projektrisiken .......................................... 14.3.3 Fachliche Projektrisiken .............................................. Zusammenfassung ................................................................. 453 454 456 458 458 460 471 471 472 477 480

14.2

14.3

14.4

13

Inhalt

In diesem Kapitel werden wir detailliert auf die Interaktion zwischen HCM und DFPS eingehen und erlutern, welchen zustzlichen Mehrwert der Einsatz der Branchenlsung DFPS bietet. 481

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


15.1 15.2 15.3 15.4 Welchen Mehrwert liefert die Branchenlsung DFPS? ............ HCM und DFPS prozessuale und technische Unterschiede ........................................................ DFPS-HCM-Implementierungen bisherige Erfahrungen ....... Fazit ...................................................................................... 482 491 501 506

In diesem Kapitel erfahren Sie, wie Sie mit einem angepassten Sicherheitskonzept Projektrisiken begegnen knnen. 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 16.2 16.3 16.4 16.5 16.6 16.7 Vorberlegungen und Vorgehensweise .................................. Sicherheitskonzept in einem DFPS-Projekt Modelle ............ Sensible Einheiten und Nachrichtendienste Besonderheiten ..................................................................... Trennung in rote und schwarze Netze .................................... Besonderheiten bei Projekten im Katastrophenschutz ............ Lsungsbestandteile der SAP-Plattform fr die Umsetzung des Sicherheitskonzepts ......................................................... DFPS-spezifische Erweiterungen ........................................... 16.7.1 Funktionalitten des Rollenmanagers ......................... 16.7.2 User- und Berechtigungsmanagement fr mobile Systeme ..................................................................... 16.7.3 Erweiterung ZBV zur Untersttzung Autarkiefhigkeit ........................................................ Sicherheit im DFPS-Projekt die zehn wichtigsten Punkte .... Fazit ...................................................................................... 507 509 512 515 518 519 525 526 528 530 531 532

16.8 16.9

Die sogenannte letzte taktische Meile scheint fr viele IT-Systeme von Einsatzorganisationen noch immer ein unberbrckbares Hindernis zu sein. Im vorliegenden Kapitel wird Ihnen der SAP-Vorschlag zur berbrckung dieses Hindernisses aufgezeigt. 533

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


17.1 17.2 Notwendigkeit von mobilen Anwendungen ........................... Mobile Anwendungen technische und prozessuale Sicht ..... 17.2.1 Welche Technik erlaubt die Flexibilitt? ...................... 17.2.2 Mobile Prozesse ......................................................... Beispielszenario Ausfall eines Fahrzeugs im Hilfs- oder Auslandseinsatz ..................................................................... Fazit ...................................................................................... 533 536 537 542 549 554

17.3 17.4

14

Inhalt

TEIL IV Innovative Anwendungsfelder von DFPS


In diesem Kapitel wollen wir das Thema DFPS im Katastrophenschutz vertiefen und Ihnen zeigen, wie Sie zur Abbildung der spezifischen Prozesse DFPS optimal einsetzen knnen. 559

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


18.1 18.2 18.3 18.4 Grundlagen ........................................................................... Prozessbereiche und funktionale Blcke im Katastrophenschutz mit DFPS .................................................................... Daten aus den SAP-Verwaltungssystemen nutzen .................. SAP-Lsungen und Leitstellensysteme ................................... 18.4.1 Beispiel 1 Bewltigung von Groschadenslagen Leitstelle mit verbundenem DFPS-System .................. 18.4.2 Beispiel 2 Mehrere DFPS-Leitstellen fungieren als verbundene Plattform ............................................ 18.4.3 Beispiel 3 Bewltigung von Groschadenslagen Leitstelle auf SAP-Basis mit angeschlossenen DFPS-System .............................................................. Stabsarbeit SAP Interactive Forms by Adobe und DFPS ....... Zusammenfassung ................................................................. 559 561 566 570 572 574

18.5 18.6

575 575 579

19 Performance-Based Logistics DFPS in der Rstungs- und Raumfahrtindustrie ................................... 581


19.1 19.2 19.3 19.4 19.5 PBL-Konzept ......................................................................... PBL-Prozesse ......................................................................... DFPS-Untersttzung fr PBL .................................................. Reporting .............................................................................. Fazit ...................................................................................... 582 586 587 593 598

Als weiteres innovatives Anwendungsfeld von DFPS erlutern wir im Folgenden die Serviceorientierte Architektur und damit zusammenhngend Network Centric Warfare. 599

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


20.1 Was ist Network Centric Warfare? ......................................... 20.1.1 Begriffsbestimmung .................................................... 20.1.2 DFPS und NCW Operationalisierung des Backoffice ................................................................... Serviceorientierte Architektur ................................................ 20.2.1 Theoretische Grundlagen ............................................ 20.2.2 SOA fr Einsatzorganisationen .................................... 20.2.3 SOA am Beispiel des Szenarios Logistic Assessment .................................. Fazit ...................................................................................... 599 599 602 604 604 608 613 622

20.2

20.3

15

Inhalt

In diesem Kapitel lernen Sie die Einsatzmglichkeiten von DFPS bei Polizeibehrden und Nachrichtendiensten kennen und erhalten Leitlinien, wie Sie in diesem besonderen Umfeld Lsungen schnell und effizient implementieren knnen. 623

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


21.1 21.2 Grundlagen ........................................................................... Szenarien und Prozesse bei Polizeibehrden und Nachrichtendiensten mit DFPS-Systemen .............................. 21.2.1 Beispiel 1 Olympische Spiele im Beispielland A......... 21.2.2 Beispiel 2 Durchfhrung eines Auslandseinsatzes ...... 21.2.3 Beispiel 3 Durchfhrung einer europaweit k oordinierten Durchsuchung ........................................ Wichtige Hinweise Projekte fr Polizeibehrden und Nachrichtendienste ............................................................... Fazit ...................................................................................... 623 625 627 629 631 636 638

21.3 21.4

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

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


645

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


A B C Abkrzungen ................................................................................... 647 Literatur ........................................................................................... 651 Die Autoren .................................................................................... 653

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

16

Einleitung

Die Branchenlsung SAP for Defense & Security (DFPS) gehrt seit Jahren zu den am schnellsten wachsenden Branchenlsungen von SAP. Armeen und Sicherheitsbehrden erhalten mit DFPS eine ganzheitliche Lsung zur Abbildung ihrer gesamten Prozesse. Das vorliegende Buch basiert auf mehr als 20 Jahren Erfahrung, die die Autoren insgesamt bei der Entwicklung, Implementierung, aber auch Schulung der Lsung sammeln konnten.

Darstellungsziel Dieses Buch vermittelt Ihnen alle erforderlichen Grundlagen und Kenntnisse, um eine DFPS-Implementierung erfolgreich bestreiten zu knnen. Wir stellen darber hinaus unsere eigenen Implementierungserfahrungen zur Verfgung, damit Sie berprfen knnen, ob in Ihrem Projekt Optimierungspotenziale vorhanden sind. Zudem finden Sie in diesem Buch viele weiterfhrende Informationen, in welchen Bereichen DFPS-Lsungen implementiert werden knnen, sodass Sie als Berater neue Geschftsfelder entdecken knnen.

An wen richtet sich dieses Buch Wir wenden uns mit unserem Buch an Projektmitarbeiter in DFPS-Projekten (Projektleiter, Architekten, funktionale Experten, Basismitarbeiter) sowie an externe Berater in diesen Projekten. Dabei haben wir die Kapitel so verfasst, dass sie von den Grundlagen ausgehend in die Tiefe gehen, sodass Sie auch als Entscheider einen Gewinn von der Lektre des Buches haben. Zum Verstndnis sind keine tiefen SAP-Kenntnisse ber allgemeine Grundlagen fr die Benutzung der Software hinaus (wie etwa die Anmeldung am System) vonnten. Unsere Beschreibungen basieren auf dem Stand ERP 6.0 mit dem Erweiterungspaket 4 (EHP 4). Wo dies mglich ist, geben wir Ihnen Ausblicke auf Weiterentwicklungen.

23

Einleitung

Aufbau und Inhalt Damit Sie einen Wegweiser durch das umfangreiche vorliegende Werk erhalten, mchten wir Ihnen im Folgenden den Aufbau des Buches und den Inhalt der einzelnen Kapitel nher vorstellen. Wir haben das Buch in vier Teile untergliedert, die der Magabe folgen, von den Grundlagen in die Tiefe zu fhren. Die Teile IIII empfehlen wir Ihnen unbedingt als unverzichtbare Grundlage fr alle Lesergruppen. Wenn Sie bereits ber DFPS-Kenntnisse verfgen, legen wir Ihnen Teil III besonders ans Herz, da wir hier die Implementierungserfahrungen stark gebndelt haben. Erfahrene DFPS-Experten werden insbesondere Teil IV, die Darstellung neuer DFPS-Anwendungsfelder, mit Interesse lesen.
Teil I Einfhrung und Grundlagen

Im ersten Teil dieses Buches zeigen wir Ihnen im Einzelnen die fr das Verstndnis von DFPS erforderlichen Grundlagen auf.
Kapitel 1, Einfhrung in DFPS Anwendungen in der Praxis Anhand verschiedener Beispiele wird grundlegend erlutert, welche Funktionalitten die Lsung SAP for Defense & Security beinhaltet und wie sie sowohl von Verteidigungsorganisationen als auch von anderen Sicherheitsbehrden (z.B. Feuerwehren) eingesetzt wird. Entsprechend bercksichtigen die ausgewhlten Beispiele sowohl Streitkrfte (aus Deutschland, Singapur oder der Schweiz) als auch andere Organisationen der ffentlichen Sicherheit (der Koordinierte Sanittsdienst in der Schweiz). Die Darstellung liefert Ihnen damit einen berblick darber, welche Anforderungen und Geschftsprozesse Sie mit der Lsung DFPS abdecken knnen. Kapitel 2, Fallstudie Tsunami-Hilfsoperation In diesem Kapitel werden die inhaltlichen Grundlagen und Anforderungen fr eine Tsunami-Hilfsoperation dargestellt. Diese Fallstudie, die auch fr Leser auerhalb des militrischen Bereichs von Interesse sein wird, dient als Grundlage fr die Darstellung der Prozesse in den folgenden Kapiteln.

Kapitel 3, Stammdaten und Organisationsstruktur als Grundlage der Implementierung Aufgrund der umfassenden Integration der Lsung kommt der Implementierung der Organisationsstruktur und des Stammdatenmodells eine zentrale Bedeutung zu. Fr Sie als Leser ist dieses Kapitel entscheidend, da es klar den Unterschied zu einer normalen ERP-Implementierung herausarbeitet. Zudem wird in diesem Kapitel deutlich werden, dass auch in den

24

Einleitung

Fllen, in denen bei Streitkrften oder Sicherheitsorganisationen zunchst nur ERP (ohne DFPS) implementiert wird, DFPS dennoch bereits bei der Datenmodellierung bercksichtigt werden muss. Das Kapitel behandelt zudem die konkrete Darstellung der systemtechnischen Abbildung des Datenmodells.
Teil II Prozesse, Funktionen, Customizing

In diesem Teil des Buches schildern wir Ihnen die Grundlagen fr eine Implementierung von DFPS.
Kapitel 4, Operational Planning In diesem Kapitel werden zunchst die Prozesse dargestellt, die ein Planer bei Streitkrften oder Sicherheitsorganisationen ausfhrt, wenn es um die Vorbereitung eines Einsatzes geht. Auf Basis der in Kapitel 3 gelegten Grundlagen wird dann gezeigt, wie dies systemtechnisch in SAP ERP abgebildet werden kann. Kapitel 5, Implementierung der Prozessgruppe Qualification Management Bei den Ressourcen kommt dem Personal und der Notwendigkeit, hier die richtigen Qualifikationen verfgbar zu haben, besondere Bedeutung zu. Aus diesem Grund gehen wir bei der Darstellung der Prozesse und der anschlieenden Beschreibung der systemtechnischen Abbildung intensiv auf den Zusammenhang zwischen DFPS und SAP ERP HCM ein. Kapitel 6, Logistik Logistischen Prozessen kommt gerade bei Einheiten im Einsatz eine spezielle Bedeutung zu. Die besonderen Prozesse einer solchen Logistik werden dargestellt, auch hier wieder vornehmlich unter Bercksichtigung der Integration mit den anderen SAP-Komponenten. Daran schliet sich erneut die Darstellung der systemtechnischen Abbildung an. Kapitel 7, Materialwirtschaft Die Anforderungen an die Prozesse der Materialwirtschaft werden zunchst wieder mit Rckbezug auf die Tsunami-Fallstudie erlutert. Daran schliet sich die Darstellung der systemtechnischen Abbildung an. Kapitel 8, Instandhaltung Auf Basis der umfassenden Integration knnen sehr komplexe Instandhaltungsprozesse abgebildet werden. Diese Prozesse werden zunchst dargestellt und dann in ihrer Abbildung im System detailliert beschrieben.

25

Einleitung

Kapitel 9, Untersttzung des Flugbetriebs Fr den Bereich des Flugbetriebs als der Knigsdisziplin der Instandhaltung wird die Darstellung des vorangegangenen Kapitels fortgefhrt und vertieft. Kapitel 10, DFPS und Rechnungswesen Die vielfltige Vernetzung von DFPS mit dem Rechnungswesen ist zentraler Bestandteil der Prozessbeschreibung. Auf dieser Basis wird dann die systemtechnische Einrichtung dargestellt. Kapitel 11, Berichtswesen/Reporting Das Berichtswesen fasst die Daten aus den einzelnen Bereichen zusammen. Prozesse wie die Bestimmung des Bereitschaftsgrads (Operational Readiness) werden hier dargestellt. Anschlieend erhalten Sie die erforderlichen Informationen, um ein Berichtswesen im System einzurichten.
Teil III Erfahrungen aus Implementierungsprojekten

Die vielfltigen Integrationsaspekte und die Gre der Projekte machen ein DFPS-Projekt zu einem herausfordernden Vorhaben. In diesem Teil mchten wir Ihnen eine Zusammenfassung unserer vielfltigen Implementierungserfahrungen geben. Dabei geht es sowohl darum, herauszuarbeiten, was getan werden soll (Dos), aber auch, was unbedingt unterlassen werden soll (Donts). Sie erhalten damit das notwendige Wissen, um Ihr DFPS-Projekt zu planen, die notwendigen Mitarbeiter auszuwhlen und zentrale inhaltliche Festlegungen zu treffen.
Kapitel 12, IT-Architektur als Herausforderung fr Armeen und Sicherheitsorganisationen Die umfassende Integration der DFPS-Lsung mit verschiedenen Systemen stellt hohe Anforderungen an die Lsungsarchitektur. Das Kapitel enthlt hier eine Checkliste von Dos and Donts fr eine gute Lsungsarchitektur. Auf dieser Liste bauen die nachfolgenden Kapitel mit den Schwerpunkten Sicherheit, dezentrale Systeme und mobile Anwendungen auf. Kapitel 13, Rollen im DFPS-Projekt Dieses Kapitel bietet Ihnen eine bersicht darber, welche Rollen und Fhigkeiten Sie im Projekt besonders betonen sollten. Die Gre der Vorhaben stellt besondere Anforderungen an die Projektteams, die hier im Einzelnen dargestellt werden. Kapitel 14, Projekt- und Risikomanagement Die umfassende Erfahrung der Autoren ermglicht es, die spezifischen Anforderungen an ein Projekt- und Risikomanagement fr ein DFPS-Pro-

26

Einleitung

jekt detailliert darzustellen. Zudem werden die hufigsten Projektrisiken aufgezeigt.


Kapitel 15, DFPS und die Prozesse des Personalwesens Dieses Kapitel greift ein hufiges Projektrisiko auf: die Interaktion von SAP for Defense & Security mit dem Personalwesen. Spezifika dieser Interaktion werden anhand des Einsatzplanungsprozesses aus Kapitel 4 beschrieben. Es werden die damit verbundenen Herausforderungen und Lsungsmglichkeiten umfassend dargestellt. Kapitel 16, Sicherheit und Berechtigungen Die Fragen nach der Sicherheit des Systems stehen im Mittelpunkt vieler Architekturdiskussionen in Projekten. Dieses Kapitel knpft daran an, indem es aufzeigt, welche Sicherheitskonzepte sich besonders bewhrt haben und wie spezifische Berechtigungsfunktionen in SAP for Defense & Security optimal genutzt werden knnen. Kapitel 17, Mobile Anwendungen Mit der Frage der Sicherheit ist die Frage nach dezentralen und mobilen Systemen verknpft. Deshalb werden in diesem Kapitel insbesondere die Verteilungsmechanismen und die Offlinefhigkeiten dargestellt, die fr DFPS 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 Vordenkern in den Streitkrften entwickelt wurden und derzeit erprobt werden. Dabei wird wiederum auf Basis bereits vorhandener Projekterfahrungen aufgezeigt, wie diese neuartigen Anforderungen mit den DFPS-Funktionalitten umgesetzt werden knnen.
Kapitel 18, Katastrophenschutz Die gesteigerten Anforderungen im Katastrophenschutz erfordern eine Modernisierung der IT-Systeme. In diesem Kapitel zeigen wir Ihnen auf, welche besonderen Aspekte Sie bei Implementierungen in diesem Bereich beachten mssen. Dabei erfahren Sie auch, wie Sie die Implementierung schlank halten knnen, da die Budgetmittel hier oftmals sehr beschrnkt sind. Kapitel 19, Performance-Based Logistics DFPS in der Rstungs- und Raumfahrtindustrie Rstungshersteller gehen zunehmend dazu ber, Armeen Fhigkeiten zu verkaufen (z.B. Flugstunden). In diesem Kapitel wird dargestellt, wie die Hersteller mit ihren Systemen in DFPS integriert werden knnen.

27

Einleitung

Kapitel 20, SOA und Network Centric Warfare mit DFPS Die Notwendigkeit, Ad-hoc-Informationen auszutauschen und umfassende Lagebilder zu erarbeiten, hat SOA und Network Centric Warfare zu einem wichtigen Thema fr DFPS werden lassen. Dieses Kapitel enthlt nicht nur die erforderlichen Implementierungsinformationen dazu, sondern auch Erfahrungsberichte aus zentralen Projekten der NATO wie der CWID (Coalition Warrior Interoperability Demonstration). Kapitel 21, Polizei und Nachrichtendienste Polizeibehrden und Nachrichtendienste haben besondere Anforderungen an eine Softwareuntersttzung, vor allem im Bereich des Geheimschutzes. Hier geben wir Ihnen die erforderlichen Grundlagen an die Hand, um auch in diesem Bereich Projekte erfolgreich zu implementieren. Kapitel 22, Ausblick Falls Sie DFPS bereits im Einsatz haben, stellen Sie sich sicherlich die Frage, wie sich die Lsung DFPS in Zukunft weiterentwickeln wird. Diese Informationen erhalten Sie in einem abschlieenden Ausblick. Dabei ist nicht allein aufzuzeigen, welche Einzelfunktionalitten in Zukunft entwickelt werden, sondern vielmehr den konzeptionellen Rahmen seitens SAP in den Mittelpunkt zu rcken, auf dessen Grundlage sich DFPS in Zukunft weiterentwickeln wird.

Im Anhang des Buches finden Sie hufig verwendete Abkrzungen und hilfreiche Literaturtipps.

Hinweise zur Lektre In diesem Buch finden Sie viele grau hinterlegte Informationsksten, die Zusatzinformationen bieten. Neben diesen Ksten finden Sie verschiedene Symbole, die Ihnen die Orientierung erleichtern sollen. Dies sind im Einzelnen folgende: Mit diesem Symbol haben wir Tipps gekennzeichnet, die Ihnen spezielle Empfehlungen zur Arbeitserleichterung geben, oder Hinweise, die Informationen zu weiterfhrenden 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 auf Szenarien aus der Praxis und auf die Erluterungen hin, wie die Funktionen im Einzelnen eingesetzt werden.

28

Einleitung

Kapitel 2 beschftigt sich mit einer Fallstudie ber einen Tsunami-Hilfseinsatz. Mit diesem Symbol sind Inhalte gekennzeichnet, die diese Fallstudie in den brigen Kapiteln des Buches wieder aufgreifen. Wir hoffen, dass Ihnen dieses Buch bei allen Ihren Aufgaben hilft, die mit DFPS zusammenhngen, und freuen uns auf Ihr Feedback. Zunchst wnschen wir Ihnen jedoch viel Vergngen bei der Lektre.

Danksagung Die vorliegende Darstellung der vielfltigen Lsung DFPS wre ohne die Untersttzung vieler Experten nicht mglich gewesen. Hierbei gilt unser besonderer Dank den Kollegen der SAP AG im Solution Management und in der Entwicklung sowie den Beratungskollegen im globalen Defense & Security Hub, die gemeinsam mit uns Projekte auf der ganzen Welt implementieren. Persnlich mchten wir unseren Dank richten an: Nicole Borsdorf, Markus Holger Erb, Dirk Fischer, Kai Finck, Fred Grunow, Sebastian Hodapp, Volker Lehnert, Hans Peukert, Stephan Rupf, Guido Schlief, Dirk Schmidt, Timo Schuette, Sylvia Strangfeld, Marc von der Linden, Ralf Wagner, Josef Wittmann, Nora Fischer, Florian Tischhuser, Marc Keller, Fabian Kunz, Marcus Ophees, Al Johnson, Michaela GoldmannFriedsam, Yvonne Missbach, Jos Sanchez, Peter Trentz, Sanda Prigara, Lana Molotova, Sawwas Athanasiadis, Armel Akle, Martin Janssen, Bob Cowley. Uns ist bewusst, dass wir mit diesem Projekt unseren Familien in den letzten Monaten einiges zugemutet haben. Wir danken unseren Lebenspartnerinnen, Frauen und Kindern dafr, dass sie uns zu diesem Vorhaben ermutigt und uns stets den Rcken frei gehalten haben. Zuletzt mchten wir unseren Lektoren bei SAP PRESS Patricia Kremer und Frank Paschen fr ihre engagierte Betreuung und die gute Zusammenarbeit danken.

Bernhard Escherich, Heinrich Pfriemer und Wolfgang Ullwer

29

Eine gewaltige Naturkatastrophe in einem Land am Rande des Pazifiks bildet den fiktiven Hintergrund fr unsere Fallstudie. Wir zeigen, wie SAP for Defense & Security die Einsatzkrfte bei der Bewltigung dieses Szenarios untersttzt.

Fallstudie Tsunami-Hilfsoperation

Im vorliegenden Kapitel werden die Grundlagen fr die Fallstudie gelegt, die uns im weiteren Verlauf dieses Buches begleiten soll. Wir nehmen dabei an, dass sich in dem fiktiven Land Lhamosa eine Naturkatastrophe ereignet. Die Einsatzkrfte dieses Landes setzen ihr gesamtes Wissen und Knnen, ihre materiellen und immateriellen Ressourcen dazu ein, Menschenleben zu retten, die Erstversorgung der Opfer zu gewhrleisten und Schden zu beseitigen. Dabei stehen ihnen internationale Hilfsorganisationen zur Seite. Mit SAP for Defense & Security steht den Einsatzkrften eine Software zur Verfgung, die einerseits fr organisatorische Flexibilitt sorgt, indem sie rasche Anpassungen der Organisationsstrukturen an die jeweiligen einsatzspezifischen Anforderungen ermglicht, und die andererseits die logistischen Prozesse bei der Durchfhrung des Einsatzes durchgngig untersttzt.

2.1

Ausgangslage

Zum Einstieg in die Fallstudie machen wir Sie mit den Gegebenheiten vor Ort vertraut. Darber hinaus geben wir einen kleinen Einblick in den gegenwrtigen Stand der Technik bei der Errichtung von Vorwarnsystemen.
Alltag in Ghuanawesi die Ausgangslage Zu Beginn des Szenarios, an einem gewhnlichen Samstag, befinden sich Polizei und Sicherheitsorgane des fiktiven Landes Lhamosa im Bereitschaftszustand, sie werden von den Ereignissen ebenso berrascht wie die internationale ffentlichkeit. Wir gehen in unserer Fallstudie davon aus, dass in der Regionalhauptstadt Ghuanawesi zu diesem Zeitpunkt eine kleine Polizeiwache mit zwei Personen besetzt ist.

53

Fallstudie Tsunami-Hilfsoperation

Im Land Lhamosa herrscht ein grundlegender Mangel an personellen und technischen Ressourcen, der in vielen ffentlichen Gebuden augenfllig ist. Eine regionale Polizeiwache sollte den Papieren nach mit zwei gelndegngigen Fahrzeugen ausgerstet sein und, im Falle von Stationen an der Kste, ein Boot mit Auenbordmotor zur Verfgung haben. Die Realitt stellt sich anders dar. Vom Fenster der Polizeiwache in Ghuanawesi aus kann man den kleinen Fischereihafen sehen, doch keines der dort vor Anker liegenden Boote gehrt der Polizei. Auf der Ladeflche des vor der Tr geparkten Toyota Pick-ups stehen zwei groe Wasserkanister, die gelegentlich zur Versorgung der in den abgelegeneren Gebieten lebenden Einwohnern eingesetzt werden, denn die kommunale Trinkwasserversorgung arbeitet nur unzuverlssig. Diese beiden Kanister werden bald von groem Nutzen sein.

So weit die Ausgangslage fr unsere Fallstudie. Wenn wir die beschriebene Situation in einem SAP-System widerspiegeln wollen, mssen wir Datenstze fr die Polizeiwache, die Personen, den Pickup sowie fr die Wasserkanister anlegen und die Daten zueinander in Beziehung setzen. Wir nennen die relativ bestndigen Datenstze die Stammdaten der Objekte. Da fr die Beschreibung einer Person andere Eigenschaften von Bedeutung sind als zur Abbildung eines Fahrzeugs, stellt die Software dafr unterschiedliche Datenobjekte mit unterschiedlichen Attributen bereit. Die einfachste Form der branchenspezifischen Softwareuntersttzung besteht darin, spezielle Felder fr diejenigen Attribute bereitzustellen, die nicht im SAP-Standard enthalten sind, um so z.B. den militrischen Rang einer Person oder den Organisationsbereich einer Einheit darstellen zu knnen. Noch hher entwickelte Branchenlsungen halten fr spezielle Anforderungen sogar eigene Stammdatenobjekte bereit in DFPS finden Sie beispielsweise Einsatzkontingente. Darber hinaus untersttzen Branchenlsungen neben den Standardablufen auch branchenspezifische Prozesse, wie beispielsweise die Planung und Einrichtung einer Polizeistation. Das Funktionsangebot wird komplettiert durch speziell zugeschnittene Reports und eigens erstellten BI Content (d.h. Inhalte in Business-IntelligenceSystemen, die branchenspezifische Informationsbedarfe befriedigen). DFPS ist zur Modellierung der Ausgangslage unserer Fallstudie u.a. deshalb so gut geeignet, weil hier nicht nur das Vorhandensein von Personen oder Ausrstung eine Entsprechung im System findet, sondern auch der bereits beschriebene Mangel an personellen und technischen Ressourcen abgebildet werden kann und weil es seine Abstellung prozessual untersttzt. Selbst die unscharfe Vorgabe, dass eine Polizeiwache ber zwei gelndegngige Fahrzeuge verfgen soll, kann in dieser Form in DFPS hinterlegt und fr einen Lagebericht oder im Rahmen von Folgeprozessen mit dem einen tatschlich vorhandenen Toyota in Beziehung gebracht werden.

54

Ausgangslage

2.1

Dunkle Vorzeichen moderne Vorwarnsysteme Doch noch ist in Ghuanawesi alles ruhig. Auslser des Tsunamis ist ein Seebeben weit drauen im pazifischen Ozean, das sich an Land kaum bemerkbar macht. Von den vergleichsweise geringen Erdsten fhlen sich die Bewohner und Touristen nicht im Mindesten alarmiert wenn sie es denn berhaupt bemerken. Erste Anzeichen fr die sich anbahnende Katastrophe werden jedoch im pazifischen Ozean registriert. Seit der Implementierung eines Tsunami-Warnsystems ist es mglich, ber die gezielte Beobachtung physikalischer Parameter (wie z.B. den Wasserdruck) kritische Situationen vorherzusehen; zumindest hat sich dadurch die Vorwarnzeit deutlich verlngert. Die Verantwortlichen werden im Idealfall mehrere Stunden vor dem Auftreffen der Flutwelle alarmiert und knnen entsprechende Vorkehrungen treffen. Selbstverstndlich steht diese Vorwarnzeit in Abhngigkeit von der Entfernung des Epizentrums zu den jeweiligen Kstengebieten. Es existiert dazu heute im Internet umfangreiches Kartenmaterial, z.B. auf den Seiten des amerikanischen National Geophysical Data Centre (NGDC) oder des Pacific Marine Environmental Laboratory (PMEL). Interaktive Seekarten ermglichen den Benutzern, in Simulationsrechnungen die relative Lage eines Seebebens einzugeben. Die ermittelten Laufzeiten bis zum Auftreffen auf die Kste werden mittels konzentrischer Kreise in der Karte dargestellt. Wir gehen in unserer Fallstudie davon aus, dass das Epizentrum ca. 1.000 Seemeilen vor der Kste von Lhamosa liegt.

So weit der Beginn unseres Szenarios. Wir werden im Laufe dieses Buches erfahren, wie sich die Ereignisse weiter entwickeln. Frs Erste haben wir gesehen, dass es in Ghuanawesi eine Polizeiwache mit zwei Beamten gibt, die ber einen Pick-up, zwei Kanister und kein Boot verfgen. SAP for Defense & Security bietet uns die Mglichkeit, diese Polizeiwache im System abzubilden, in den Gesamtzusammenhang der Organisation einzuordnen, sie wiederzufinden und die unterschiedlichsten Prozesse organisationsbezogen zu untersttzen. Selbst der Auenbordmotor knnte mit Systemuntersttzung repariert und betankt werden, wenn das Boot denn zur Verfgung stnde. Sogar dieser drastische Unterschied zwischen Soll und Ist in der Anzahl verfgbarer Boote kann softwaregesttzt ermittelt und gegebenenfalls durch die Einleitung eines Nachschubvorgangs beseitigt werden. Abbildung 2.1 zeigt einen Ausschnitt aus der Organisationsstruktur der Polizei von Lhamosa. Diese Struktur knnen Sie auch in DFPS abbilden. Sie finden die Polizeiwache von Ghuanawesi im sogenannten Navigationsbereich in der linken oberen Ecke der Struktur-Workbench. Unten links finden Sie die zugeordnete Ausrstung, das materielle Soll. Rechts, im Detailbereich, erkennen Sie eine ganze Reihe Registerkarten mit fachlich gegliederten

55

Fallstudie Tsunami-Hilfsoperation

Informationen, in unserem Beispiel die Grunddaten. Dem Bearbeiter erlauben diese Informationen, auf sein jeweiliges Sachgebiet passend zugeschnittene Entscheidungsgrundlagen bezglich der Organisationsstruktur durch einfache Navigation vorzufinden.

Abbildung 2.1 Fallstudie Polizeistruktur im fiktiven Land Lhamosa

Eine hnlich aufgebaute, wenn auch im Detail weitaus komplexere Struktur existiert auch im SAP-System der internationalen Hilfsorganisationen sowie in den SAP-Systemen der Streitkrfte befreundeter Staaten. DFPS bietet die Mglichkeit, dank sogenannter Verwendungstypen Organisationsstrukturen (OrgStrukturen) fr unterschiedliche Zwecke im SAP-System zu hinterlegen, also sowohl eine Organisationsstruktur fr die Aufbauorganisation als auch fr den Verteidigungsfall oder, wie in unserem Fall erforderlich, eine spezifische Struktur fr einen Einsatz zu definieren.
Der Tsunami wird ausgelst die Welle entsteht Fischer, die sich zum Zeitpunkt des Bebens auf See befinden, bemerken die Welle meist gar nicht. Ihr Boot bewegt sich kaum. Im offenen Ozean ist eine TsunamiWelle nur wenige Zentimeter hoch, und sie bewegt sich mit unvorstellbaren 800 Kilometern pro Stunde was der Geschwindigkeit eines Passagierflugzeugs entspricht auf die Kste zu. Die Energie der Welle reicht von der Meeresoberflche bis zum Meeresboden. Dass auf hoher See davon kaum etwas zu spren ist, liegt u.a. daran, dass die Welle so lang ist, dass zwischen den einzelnen Wellenkmmen 100 bis 300 Kilometer liegen knnen.

Abbildung 2.2 zeigt die Aufzeichnung einer Tsunami-Warnstation vom 29. September 2009 durch eine Boje im Pazifik, 610 Seemeilen nordstlich von Saipan. Man erkennt deutlich die kurzfristigen Pegelschwankungen, die sich hier im Bereich einiger Zentimeter bewegen. Auslser dafr war ein Beben der Strke 8,1 in Hhe der Samoa Islands, das zu einer mehr als drei Meter hohen Flutwelle in Pago Pago auf Amerikanisch-Samoa fhrte, die in ihrem ganzen Ausma 180 Menschenleben forderte.

56

Tsunami

2.2

Abbildung 2.2 Aufzeichnung des Wasserstands im Pazifik am 29.09.2009

2.2

Tsunami

Erst wenn sich die Welle der Kstenlinie nhert, verliert sie ihre scheinbare Normalitt, und die Energie wird auf weit kleinerem Raum konzentriert. Hierbei trmen sich riesige Wellen auf, die alles vernichten knnen, was auf ihrem Weg liegt. Das japanische Wort Tsunami bedeutet lange Hafenwelle oder Welle im Hafen und wird seit einer wissenschaftlichen Konferenz im Jahre 1963 weltweit fr diese Form der Riesenwellen verwendet [SCINEXX2009]. In ihren SAP-Systemen knnen die Hilfsorganisationen Standorte (wie z.B. die Bucht von Ghuanawesi) mit Adressdaten versehen dies ist Standard in SAP ERP. Branchenspezifisch fr DFPS ist die Mglichkeit, zu Strukturelementen (in unserem Fall zur Polizeiwache von Ghuanawesi) sogenannte Geolokationen anzulegen, mit deren Hilfe die Strukturelemente im geografischen Koordinatensystem verortet werden knnen. Zustzlich dazu ergeben sich reichhaltige Mglichkeiten aus der Kopplung des SAP-Systems mit einem Geoinformationssystem (GIS). Noch bevor die Welle auf den Strand trifft und der Tsunami die Stadt Ghuanawesi verwstet, haben Sensoren auf der ganzen Welt das Beben registriert und Bojen, wie die bereits erwhnte Messstation im Pazifik, die Schwankungen des Wasserspiegels ber Satellitenverbindungen an die Beobachtungsstationen bermittelt. Mithilfe von Simulationstools und spezieller Seekarten knnen die Laufzeiten der Tsunami-Wellen ermittelt werden. Sie erkennen im unteren Bereich von Abbildung 2.3 den nrdlichen Rand Australiens, oben rechts ist die eingangs erwhnte Messstation nordstlich von Saipan verzeichnet.

57

Fallstudie Tsunami-Hilfsoperation

Abbildung 2.3 Karte des betroffenen Gebiets

In unserer Fallstudie knnen wir davon ausgehen, dass aufgrund der Lage des Epizentrums die gefhrdeten Gebiete identifiziert und Flutwarnungen ausgegeben werden. In unserem Beispiel betrgt die Entfernung 1.000 Seemeilen, d.h., etwa zwei bis drei Stunden nach dem Beben wird mit dem Auftreffen der Flutwelle zu rechnen sein. Dementsprechend sind auch die Einsatzkrfte der Nachbarstaaten in Alarmbereitschaft versetzt worden.
Flutwarnung fr die pazifischen Kstengebiete Dank der beschriebenen Vorwarnsysteme erfahren die staatlichen Stellen im Innenministerium von Lhamosa sehr frhzeitig von der drohenden Katastrophe. Umgehend wird fr den gesamten Kstenbereich Alarm ausgelst. In der Polizeiwache von Ghuanawesi schrillt das Telefon. Mitarbeiter des Technischen Hilfswerks aus Deutschland, die sich im Auftrag der Bundesregierung in der Provinz Ghuanawesi aufhalten, sind per SMS informiert worden. Jetzt ist rasches Handeln gefragt. Als Erstes mssen die Anwohner entlang der Kste gewarnt werden. Die beiden Polizisten springen in den Toyota. Die Leute vom THW versuchen, Kontakt mit der Einsatzzentrale zu bekommen. Doch auch sie mssen zunchst einmal selbst aus der Gefahrenzone gelangen.

58

Tsunami

2.2

Leider reichen die Vorwarnzeiten bedingt durch die kurze zeitliche Distanz nicht aus, um smtliche Bewohner der am strksten betroffenen Gebiete rechtzeitig zu evakuieren. Daher kommt es zunchst darauf an, die Polizeikrfte und Katastrophenschtzer vor Ort mglichst rasch zu informieren, jede Minute zhlt. Von besonderer Bedeutung ist demnach das reibungslose Ineinandergreifen der Informationskette. Als groe Herausforderung erweist sich in unserem Fall die rasche Information der Bevlkerung. Es gilt, Paniksituationen zu vermeiden, aber dennoch in aller Deutlichkeit auf die Gefahrenlage hinzuweisen. Bessere Schulbildung, die sich durchaus auch des traditionellen Volksglaubens, wie z.B. der Erzhlung vom Smong, bedienen sollte, kann in einem solchen Fall lebensrettend sein. Dieser Mythos beschreibt die Gefahren einer berflutung sehr plastisch und macht, da er schon Kindern in der Schule vermittelt wird, nachhaltig auf Anzeichen einer drohenden berschwemmung aufmerksam: Der pltzlich fallende Wasserspiegel ist fr derart informierte Bevlkerungskreise ein tief verwurzeltes Alarmsignal. Selbst Kinder verstehen es, die Anzeichen der Natur zu deuten: Wenn das Wasser verschwindet, bleibt nur noch wenig Zeit.
Erste Hilfe die Welle kommt Mit ohrenbetubendem Lrm und atemraubender Gewalt kehrt das Wasser zurck. Eine gigantische Flutwelle bricht ber Ghuanawesi herein, reit alles mit, was sich ihr in den Weg stellt. Boote werden weit ins Landesinnere getragen, Autos fortgesplt und Bume ausgerissen. Die Besatzung der Polizeiwache hat sich in einen auf einer Anhhe befindlichen dreistckigen Hotelneubau geflchtet. Gemeinsam mit dem Personal versucht sie, Hotelgste aus den berfluteten unteren Stockwerken zu retten. Was der Welle nicht schon beim ersten berrollen zum Opfer gefallen ist, wird durch den gewaltigen Sog zerstrt, mit dem sich das Wasser zurck ins Meer bewegt, eine Lawine aus Schlamm, Gerll und aufgrund der mitgerissenen Gegenstnde, Splitter und Scherben voller Gefahren. Viele Menschen haben Schnittverletzungen davongetragen. Immer wieder versuchen die beiden Polizisten, mit ihren Funkgerten Meldung von der Katastrophe zu machen und Hilfe anzufordern. Leider kommt keine Verbindung zustande, sodass sie ganz auf sich selbst angewiesen sind, um die Aktivitten 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 Krankenschwester aus Dresden und einem am Knie verletzten australischen Medizinstudenten kmmern sich die Polizisten um die Verletzten. Die Besitzerin des Hotels bemht sich unterdessen, die mit ihr befreundeten Personen vom Technischen Hilfswerk per Mobiltelefon zu erreichen.

59

Fallstudie Tsunami-Hilfsoperation

2.3

Rettungsoperationen mit DFPS-Untersttzung

Whrenddessen laufen in den Einsatzzentralen rund um den Globus die Planungen an. Die Armee von Singapur, das Technische Hilfswerk in Deutschland sowie die Metropolitan Fire Brigade (MFB) in Melbourne greifen dabei auf vordefinierte Einsatzstrukturen zurck. In der Hauptstadt von Lhamosa werden die personellen und materiellen Ressourcen fr den Einsatz mit DFPS identifiziert und zugeordnet. An die Rolle des Einsatzleiters werden besondere Anforderungen gestellt, die als Qualifikationsblcke im System hinterlegt sind. Bei der Suche nach geeigneten Personen spielen in unserem Fall Sprachkenntnisse eine besondere Rolle. Diese Anforderung engt den verfgbaren Personenkreis weiter ein, doch rasch wird ein Kandidat identifiziert.
Blitz-Recruiting der Einsatzleiter ist gefunden Grau ist alle Theorie. Zwar bestnde durchaus die Mglichkeit, durch eine Systemabfrage die Anforderungen an einen Einsatzleiter mit den vorhandenen Qualifikationen der infrage kommenden Kandidaten abzugleichen. Doch die Zeit drngt, und so spielen am Ende persnliche Beziehungen die grere Rolle. Fehlende Sprachkenntnisse mssen in Kauf genommen werden, wenn der Posten nicht lnger unbesetzt bleiben soll.

Da sich die Gre der Naturkatastrophe, insbesondere die Ausdehnung der betroffenen von der Versorgung abgeschnittenen Gebiete, und die Anzahl der Opfer derzeit noch nicht abschtzen lassen, wird die Gre des Einsatzes zunchst auf Basis der verfgbaren Ressourcen bestimmt; die Transportkapazitt erweist sich dabei als limitierender Faktor. Der designierte Einsatzleiter weist an, dass alle verfgbaren Trucks und Pickups fr einen Straentransport bereitzustellen sind. In DFPS sind Trucks und Pick-ups jeweils als Materialplanungsobjekte den Transportzgen der Einsatzkrfte zugeordnet. Das bedeutet, dass es fr die Planung zunchst keine Rolle spielt, ob es sich bei einem mittelschweren Truck um einen Fnftonner aus skandinavischer, koreanischer oder deutscher Produktion handelt; entscheidend fr die generische Planung ist in diesem Fall die Transportkapazitt. Als weitere Materialplanungsobjekte sind den Transportzgen Funkgerte sowie Lademittel zugeordnet. Diesem sogenannten materiellen Soll steht ein Ist gegenber, das nun nicht mehr generisch ist, sondern aus konkreten individuellen Trucks, Funkgerten und Gabelstaplern besteht. Bald schon stellt sich als Ergebnis des Soll-Ist-

60

Rettungsoperationen mit DFPS-Untersttzung

2.3

Vergleichs fr die Strukturelemente der Transportzge heraus, dass zwischen der im Soll vorgegebenen Anzahl und dem tatschlichen Ist-Bestand ein deutliches Delta klafft. Diese Diskrepanz droht den Erfolg des gesamten Einsatzes infrage zu stellen, denn mit lediglich 50 Prozent der geplanten mittelschweren Trucks kann ein Transportzug nicht als einsatzbereit gelten. Um diese betrchtliche Lcke zu schlieen, wird rasch der Prozess der materiellen Planung mittels der Struktur-Workbench initiiert. Dabei wird der Standardversorger der Transportzge ermittelt, der ebenfalls durch ein Strukturelement im SAP-System reprsentiert ist. Die Strukturelemente der Transportzge und die Strukturelemente ihrer Standardversorger sind miteinander durch eine Versorgungsbeziehung verbunden. Dabei kann es durchaus unterschiedliche Versorgungsbeziehungen geben, je nachdem, ob es sich um die normale Aufbauorganisation handelt oder, wie in unserem Fall, um einen Einsatz. Bei der Entwicklung von DFPS fanden die logistischen Strukturen in Verteidigungsorganisationen Bercksichtigung. Somit sind wir in der Lage, zwischen verbrauchenden Truppenteilen (VTT), Versorgern, Depots und der Industrie zu unterscheiden.
Logistische Strukturen Die Transportzge in Ghuanawesi profitieren von dem Umstand, dass ihre Versorgungsbeziehungen direkt auf das zentrale Materialdepot von Lhamosa verweisen. Unser Versorger ist demnach das Depot. Glcklicherweise hat unser Versorger einen ausreichenden Bestand an mittelschweren Trucks, sodass direkt von der Struktur-Workbench aus eine Bestellanforderung (Banf) erzeugt werden kann. Die fehlenden Trucks werden somit beim Depot angefordert allerdings nur temporr, es handelt sich um eine Leihe.

Das DFPS-System kann die zeitliche Befristung dieser Leihe bercksichtigen und darber hinaus automatisch eine Rcklieferungs-Banf erzeugen, um bereits von Beginn an die spter erforderliche Rcklieferung vorzubereiten. Den besonderen Anforderungen an rasche Bearbeitungsgnge im Einsatz Rechnung tragend, kann die Banf ohne komplizierte Freigabestrategie in eine Bestellung umgewandelt werden. Diese wird, wie es auch der SAP-Standard vorsieht, ber die Stationen Auslieferung, Warenausgang beim Versorger und Wareneingang beim Empfnger, d.h. jeweils bei unseren Transportzgen, prozessiert. Der Soll-Ist-Vergleich ist nunmehr ausgeglichen, die Einsatzbereitschaft der Transportzge gewhrleistet. Die erforderlichen Hilfsgter sind im System im Gegensatz zu Funkgerten, Trucks und Lademitteln nicht als Materialplanungsobjekte hinterlegt. Statt-

61

Fallstudie Tsunami-Hilfsoperation

dessen erleichtert DFPS die Planung bezglich der Verbrauchsmaterialien mithilfe sogenannter Vorratspakete. Fr unseren Einsatz sind hier gefllte Frischwasserkanister, Decken, Sanittsmaterial und haltbare Verpflegung jeweils als eigene Pakete angelegt und unseren Strukturelementen zugeordnet.
Lokale Sicherheitsmanahmen erschweren die Hilfe auf dem Landweg Um die Sicherheit im Katastrophengebiet zu gewhrleisten, werden strikte Zugangsbeschrnkungen erlassen, deren Einhaltung durch lokale Polizeiorganisationen gewissenhaft berwacht wird. Leider fllt unser Transportzug dieser Grndlichkeit beinahe zum Opfer, ein Teil der Vorrte wird konfisziert. Glcklicherweise kommt dann doch dank des mitgefhrten Funkgerts eine Verbindung zum Einsatzleiter zustande, und schon nach drei Stunden wird dem Transport die Weiterfahrt gestattet. Allerdings wird nach dreiig weiteren Kilometern der Zugang in den Distrikt Ghuanawesi erneut verwehrt, was wiederum zu zeitraubenden Diskussionen fhrt. Diesmal hat die Strenge der Beamten an der Straensperre tatschlich einen nachvollziehbaren Grund: Gut zweihundert Meter weiter hat die Flutwelle die Strae buchstblich fortgerissen, und dies sind nur die Vorboten der unheilvollen Zerstrung. Den Berichten vermehrt anzutreffender Passanten zufolge, die auf der Flucht vor dem Wasser zwar ihr Leben retten konnten, nun aber auf der Suche nach Wasser, Verpflegung oder Hilfe bei der Bergung ihrer Angehrigen dem Konvoi entgegengehen, sind smtliche Straenverbindungen fr Fahrzeuge unpassierbar.

Diese Information muss der Einsatzleitung schnellstmglich zur Verfgung gestellt werden, denn aufgrund der Nichtverfgbarkeit von Transportwegen sind smtliche weiteren Hilfslieferungen ebenfalls blockiert. Nachdem der Landweg offenbar verschlossen ist, muss dringend eine Alternativroute erschlossen werden. Der Einsatzleiter weist daraufhin an, Transporte mit dem Boot der Polizeiwache zu untersttzen. Wie wir uns erinnern, existiert dieses Boot leider nur als Soll-Vorgabe, oder technisch ausgedrckt: Der IstBestand an Booten ist gleich null.
Lufttransporte Beginn der internationalen Zusammenarbeit Die Pannen in der jngsten Vergangenheit haben das ohnehin angekratzte Image des Einsatzleiters weiter beschdigt. Zudem besteht keine Chance, die Hilfsbedrftigen auf dem Landweg zu erreichen. Inzwischen hat sich die Erkenntnis in der Einsatzzentrale von Lhamosa durchgesetzt, dass es zu Lufttransporten keine Alternative gibt. Ebenfalls ohne Alternative ist die berlegung, sich noch einmal mit der Personalie des Einsatzleiters zu beschftigen. Vielleicht lohnt es sich doch, einen Abgleich der im System hinterlegten Qualifikationen mit den Anforderungen an die Rolle durchzufhren und auf ausreichende Englischkenntnisse zu achten?

62

Rettungsoperationen mit DFPS-Untersttzung

2.3

Fr den nchsten Tag hat sich der Gouverneur von Lhamosa zu einem Informationsbesuch angekndigt. Pltzlich geht alles sehr schnell: Ein neuer Einsatzleiter ist gefunden. Damit wchst auch die Bereitschaft, mit den internationalen Einsatzkrften zusammenzuarbeiten. Der neue Einsatzleiter spricht mit dem Vertreter des Technischen Hilfswerks die Neuplanung des Einsatzes durch. Verheerende Bilder vom Zentrum der Katastrophe legen eine Neupriorisierung der Einsatzziele nahe. Medizinische Soforthilfe, die Suche nach berlebenden und die Verhinderung der Ausbreitung von Seuchen durch zgige Bergung der Opfer werden demnach vorrangig betrieben, gleichzeitig bittet nun der Gouverneur die internationale Gemeinschaft um Hilfe. Insbesondere zustzliche Kapazitten an Transporthubschraubern sowie Helikoptern mit SARAusstattung (Search, Aid & Rescue) werden dringend bentigt.

DFPS untersttzt die Einsatzleitung nun bei der Formulierung von Einsatzzielen, bei der Zuweisung von Aufgaben an Organisationseinheiten durch Task Catalogues, anhand derer die am besten geeigneten Einheiten ausgewhlt werden knnen. Darber hinaus erleichtert die Verwendung von generischen Katalogisierungen wie dem Reportable Item Code (RIC) internationalen Organisationen die Kommunikation von Angebot und Bedarfen an Transportkapazitt ber Lnder- und Systemgrenzen hinweg. Damit lassen sich Trucks, Kanister, Container etc. durch einen hierarchischen Code darstellen. Aber nicht nur dies es knnte auch die Versorgung auf dem Landweg wieder aufgenommen werden, wenn es gelnge, Maultiere in ausreichender Anzahl zu bekommen, denn auch fr diese gibt es einen RIC. Vorbereitung, Durchfhrung und Nachbereitung der Hilfsflge werden ebenfalls durch DFPS untersttzt. Die Luftfahrzeuge werden als technische Objektstruktur in SAP abgebildet. Fr jeden Flug wird ein entsprechender Auftrag angelegt, alle zusammen werden automatisch aktualisiert in einer Flugbersicht dargestellt. Die bentigte Konfiguration der angeforderten Luftfahrzeuge kann dort eingetragen und mit der Konfiguration verfgbarer Hubschrauber verglichen werden, die in einem ebenfalls automatisch aktualisierten Statusboard aufgelistet werden knnen. Anhand vielfltiger Kriterien wird ein passendes Fluggert ausgewhlt und dem Flug zugeordnet. Spezielle Statusinformationen helfen bei der berwachung der Flugvorbereitung und der Gewhrleistung der Flugsicherheit, auch und gerade in Einsatzszenarien. Smtliche vorbereitenden und abschlieenden Manahmen knnen vorgeplant und dokumentiert werden. Darber hinaus helfen Qualifikationen, Trainingsprogramme und Kataloge, die geeignete Besatzung fr einen geplanten Hilfsflug auszuwhlen. Smtliche Aktivitten und die Betriebswerte werden auch im Einsatzfall dokumentiert,

63

Fallstudie Tsunami-Hilfsoperation

um die Logbcher stets aktuell zu halten. Saubere Aufzeichnungen knnen spter dazu genutzt werden, bei der Abrechnung der Einsatzkosten zwischen den beteiligten Nationen zu einem belastbaren Ergebnis zu kommen.

2.4

Fazit

Nach der Lektre dieses Kapitels sind Sie mit der Ausgangslage fr unsere Fallstudie vertraut. Sie kennen den Zusammenhang zwischen geografischen Gegebenheiten und einsatzrelevanten Bedingungen, z.B. die Abhngigkeit der Vorwarnzeit von der Laufzeit der Flutwelle oder die Auswirkungen blockierter Transportwege auf die Planung von Hilfslieferungen. Vorbereitend auf die Folgekapitel haben Sie darber hinaus erfahren, wie Sie die DFPSSoftware bei der Abbildung der Einsatzkrfte und bei der Abwicklung logistischer Prozesse untersttzen kann.

64

Gesamtstammdatenmodell von DFPS

3.3

3.3

Gesamtstammdatenmodell von DFPS

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

SE

Dokumente Projekte PSP-Elemente

Personalwesen
S P C LA SE

Rechnungswesen

Logistik
VPA MC

Infrastruktur
AO

Kostenstelle

Profit Center
MPO

QB Q
S P Q QB C GP LA AO = = = = = = = =

GP
Lagerort

Finanzstelle
Planstelle Person Qualifikation Qualifikationsblock Stelle Geschftspartner Logistischer Arbeitsplatz Architekturobjekt

M Technischer Platz Master Equipment

VPA MC MPO M

= = = =

Vorratspaket Container Material Materialplanungsobjekt Material

Instandhaltung

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 Verknpfungen die verschiedenen Komponenten der Branchenlsung miteinander verbindet.
Symbole im Gesamtstammdatenmodell Diese verschiedenen Komponenten werden anhand der Formen unterschieden. So stehen Quadrate fr das Personalwesen, Dreiecke fr die Materialwirtschaft, Achtecke fr das Rechnungswesen, Kreise fr Projektstrukturen und Haushaltsmanagement, Fnfecke fr die Instandhaltung und Drachen fr die Infrastruktur (siehe Abbildung 3.8).

Allein daraus lsst sich die starke Integration mit Komponenten von SAP ERP erkennen. Grundstzlich knnen wir wie auch bereits durchgefhrt mithilfe der SAP-Terminologie zwischen der Integration in SAP ERP und der Integration mit anderen Komponenten und Lsungen unterscheiden.

83

Stammdaten und Organisationsstruktur

In Abbildung 3.8 handelt es sich um den ersten Aspekt. So stellt das Strukturelement die Integration der Personalwirtschaft, der Logistik und des Rechnungswesens auf Basis von SAP NetWeaver sicher. Darber hinaus lsst es sich sowohl in C2-Systemen (Command and Control-Systemen) als auch in mobilen Anwendungen einsetzen. Mehr Informationen dazu erhalten Sie in Kapitel 17, Mobile Anwendungen. Personalwesen (Quadrate) Das Quadrat (SE) entspricht einem Strukturelement, das in diesem Fall mit einem weiteren Strukturelement zu einer Struktur nach oben verknpft ist. Die weiteren Vierecke entsprechen den bekannten Stammdaten des Personalwesens. Darunter finden Sie u.a. die Planstellen (S) und die Stellen (C), die die Planstellen beschreiben. Personen (P) besetzen Planstellen und erfllen diese Qualifikationen (Q). Einzig und allein die Qualifikationsblcke (QB), die die Anforderungen an den Halter von Planstellen beschreiben, stellen ein DFPS-Spezifikum dar. Darber hinaus knnen Personen (P) auch mit Geschftspartnern (GP), die der Einfachheit halber ebenso als Viereck dargestellt werden, verknpft werden. Diese Verknpfung wird vor allem fr den Infrastrukturprozess der Belegplanung und der Ableitung von Qualifikationen aus der Instandhaltung bentigt.
Materialwirtschaft (Dreiecke) Unter dem Bereich der Dreiecke befinden sich die materiellen Anteile: Materialcontainer (MC) und Materialplanungsobjekte (MPO). Vorratspakete (VPA) drcken das materielle Soll eines Strukturelements aus, dem das tatschliche Material (M) gegenbersteht. Dieses Material wird, sobald es vorhanden ist, in dem dem Strukturelement zugeordneten Lagerort angezeigt. Instandhaltung (Fnfecke) Die Fnfecke beschreiben die Instandhaltungsanteile, die hier aus dem technischen Platz und den zugeordneten Master-Equipments bestehen, Letztere wurden eigens fr DFPS entwickelt. Die Instandhaltungsanteile werden ber den logistischen Arbeitsplatz mit den personellen Anteilen (konkret dem HR-Arbeitsplatz) verknpft. Dies ist in Abbildung 3.8 mit der Verknpfung LA und S skizziert. Rechnungswesen (Achtecke) Die integrativen Aspekte des Rechnungswesens bestehen aus den Achtecken Kostenstelle und Profit-Center und der daraus abgeleiteten Finanzstelle des Haushaltsmanagements der Infrastruktur (Drachen) und der Projektstruktur (Kreise).

84

Gesamtstammdatenmodell von DFPS

3.3

Umgangssprachlich werden allerdings sehr oft nur die Kostenstelle und das Profit-Center (die Achtecke in Abbildung 3.8) als Rechnungswesen bezeichnet. Diese beiden bilden die Basis fr die weitere Integration mit dem Haushaltsmanagement (hier die Finanzstelle, als Sechseck dargestellt) und stellen weiterfhrende Rechnungswesenprozesse sicher.
Infrastruktur (Drache) Die Einbindung des Immobilienmanagements erfolgt mit der Verknpfung des Architekturobjekts mit dem Strukturelement. Dies ist erst mit dem Erweiterungspaket 3 (EHP3) mglich. Projektstrukturen und Haushaltsmanagement (Kreise) Eine nicht zu unterschtzende Bedeutung hat das Projektsystem, das ber das Objekt Projektstrukturplan an das Strukturelement geknpft werden kann.

Zusammenfassend lsst sich bezglich des Gesamtstammdatenmodells Folgendes noch einmal besttigen: DFPS verfgt ber zwei Integrationsaspekte: die Integration ins ERP-System und die Integration mit anderen Komponenten und Systemen. DFPS stellt mithilfe des Strukturelements die Verknpfung des Personalwesens, der Logistik und des Rechnungswesens sicher. Im Folgenden werden wir die hier dargestellten Stammdaten anhand ihrer DFPS-Besonderheiten detailliert betrachten.

3.3.1

Das Strukturelement technischer Fokus

Der Nukleus unserer Lsung ist Ihnen ja schon eindrcklich vorgefhrt worden, nun soll seine technische Sicht nher betrachtet werden. Die aus dem Organisationsmanagement der Personalwirtschaft bekannte Organisationseinheit wurde zum sogenannten Strukturelement erweitert. Das Ziel dieser Erweiterung ist eine integrierte Abbildung organisatorischer Strukturen zur Planung und Steuerung administrativer, personalwirtschaftlicher und logistischer Prozesse. Technisch betrachtet, wird diese Erweiterung des Objekts Organisationseinheit mithilfe einer einzigen Tabelle der Tabelle /ISDFPS/FORCE umgesetzt.

85

Stammdaten und Organisationsstruktur

Tabelle /ISDFPS/FORCE Die Tabelle /ISDFPS/FORCE besteht aus zwei Abschnitten, der Objektidentifizierung sowie den Objektzuordnungen und Eigenschaften. In Tabelle 3.2 erfolgt die Zuordnung von der Objekt-ID einer Organisationseinheit zu der FORCE-ID eines Strukturelements (Objektidentifizierung).
Feld FORCE_ID FORCE_CNT PLVAR OTYPE OBJID Bedeutung interner Schlssel des Strukturelements interner Versionszhler Planvariante Objekttyp Objekt-ID Zuordnung des Strukturelements zu einer Organisationseinheit Verwendung Identifizierung des Strukturelements

Tabelle 3.2 Tabelle /ISDFPS/FORCE Objektidentifizierung

So wird nicht nur die Zuordnung zwischen Organisationseinheit und Strukturelement in der Tabelle /ISDFPS/FORCE festgehalten, sondern ebenso die Verschrnkung mit der Logistik (siehe Tabelle 3.3).
Feld WERKS_S BERID_S ACNTABLE_S LGORTACNT WERKS_P BERID_P ACNTABLE_P WERKS_RE BERID_RE ACNTABLE_RE LGORT_RE PSPNR Bedeutung Werk (Bestand) Dispositionsbereich (Bestand) nachweispflichtig (Bestand) Lagerort (Bestand) Werk (Vorrat) Dispositionsbereich (Vorrat) vorratsfhrend (Vorrat) Werk (Infrastruktur) Dispositionsbereich (Infrastruktur) nachweispflichtig (Infrastruktur) Lagerort (Infrastruktur) PSP-Element PSP-Element Reiter Bestand/Vorrat

Tabelle 3.3 Tabelle /ISDFPS/FORCE Zuordnungen und Eigenschaften

86

Gesamtstammdatenmodell von DFPS

3.3

Feld READINESS_MAT READINESS_PERS READINESS_TRAI EKORG EKGRP LOGLEV PRIO MATSTAT

Bedeutung Materialbereitschaftsgrad Personalbereitschaftsgrad Ausbildungsbereitschaftsgrad Einkaufsorganisation Einkufergruppe logistische Ebene organisatorische Prioritt Status der Erstversorgung

Reiter Bereitschaft

Logistikdaten

Vorratspakete

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

Sie sehen in der rechten Spalte in Tabelle 3.3, auf welchen Reitern innerhalb der Struktur-Workbench die Daten angezeigt werden. Wie Sie anhand von Tabelle 3.3 erkennen knnen, ist die Tabelle /ISDFPS/FORCE die Basis fr jegliche Integration mit der Logistik. Alle Strukturelemente verfgen ber einen Tabelleneintrag in dieser Tabelle, Organisationseinheiten ohne einen entsprechenden Eintrag werden in der Struktur-Workbench nicht angezeigt. Verfgen Sie in Ihren Systemen ber eine existierende Aufbaustruktur, lsst sich diese mithilfe des Reports /ISDFPS/CREATE_FORCE_FROM_ORGU in die Tabelle /ISDFPS/FORCE bernehmen. Jetzt wissen Sie, worin der Unterschied zwischen einer Organisationseinheit und dem Strukturelement liegt, betrachten wir nun also das Strukturelement etwas nher.

Das Strukturelement im Detail Zunchst mchten wir Ihnen die Details nherbringen, die das Strukturelement bentigt, um zu existieren. Wie jedes Objekt des Organisationsmanagements, muss auch das Strukturelement ber eine einzigartige Objekt-ID (Identifikationsnummer), einen Namen (technisch: Lang- und Kurzbezeichnung), einen Start- und Endezeitraum und ber einen Planungsstatus verfgen. Mit diesen Attributen wird allerdings nur das Strukturelement an sich beschrieben, damit es aber seinen Zweck erfllen kann, bentigt es Verknpfungen mit anderen Objekten.

87

Stammdaten und Organisationsstruktur

Alle diese Informationen werden im Objektkopf der Struktur-Workbench angezeigt (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 vor Fehlern sein muss, mchten wir Ihnen diese nun nher erlutern.
Objekt-Identifikationsnummer (Objekt-ID) eines Strukturelements Die Objekt-ID der Organisationseinheit wird verwendet, um ein Strukturelement eindeutig zu beschreiben. (Die in der Tabelle /ISDFPS/FORCE existente Force-ID ist zwar auch einzigartig, aber kommt aufgrund ihrer Lnge nicht zur Anwendung.) Auch wenn sprechende Objekt-IDs wie H fr Heer, M fr Marine und L fr Luftwaffe mglicherweise als praktikabel erscheinen, empfehlen wir Ihnen, auf die SAP-interne Nummernvergabe zurckzugreifen.
Nummernkreise nicht zu eng fassen Insbesondere gilt es, darauf zu achten, dass die etwaigen Nummernkreise (der Identifizierungsnummern) nicht zu eng gefasst werden, um das problemlose Planen und Arbeiten ber Jahre hinweg zu gewhrleisten. Bitte beachten Sie, dass allein bei der Kopie einer einzigen Kompanie bereits mehrere Hundert neuer HR-Objekte erzeugt werden und somit auch das Nummernintervall entsprechend nach oben gesetzt wird.

Lang- und Kurzbezeichnung Die Eingabe der Lang- und Kurzbezeichnung erfolgt direkt beim Anlegen des Strukturelements. Beide Felder werden in weiterer Folge ber den Reiter Benennung angezeigt und lassen sich auch ber diesen abndern. Die Speicherung dieser Information erfolgt im Infotyp 1000.

Eine hufige Frage, gerade im Bereich der Abbildung von multinationalen Stben, ist die nach der Mehrsprachigkeit. Diese Mglichkeit ist ebenfalls auf dem Reiter Benennung ber das Icon bersetzung pflegen gegeben (siehe Abbildung 3.10).

88

Gesamtstammdatenmodell von DFPS

3.3

Abbildung 3.10 Icon bersetzung pflegen

Suchmglichkeiten bedenken Bei geplanter Verwendung der Suchfunktionalitt sollte man sich bereits beim Anlegen der Stammdaten darber Gedanken machen, ob eine einfache Verwendung der Lang- oder Kurzbezeichnung ausreicht. Sucht man beispielsweise nach der Einsatzbereitschaft von Strukturelementen und hat man diese zuvor z.B. auch auf Zugsebene angelegt, erhlt man bei einfacher Verwendung wahrscheinlich zwanzig verschiedene Eintrge I. Zug als Ergebnis. Zielfhrender wre es, bereits bei Lang- oder Kurzbezeichnungen die Einheiten einzigartig zu kennzeichnen, wie z.B. I.Zug/1.Kp/3 Bn oder krzer I./1./3.

Start- und Endezeitraum Der Startzeitraum des Strukturelements beginnt in der Regel mit dem Tag seines Anlegens. Verwenden Sie jedoch die Komponente Case Management und darin die Organisationsmanahmen, gibt das Datum des Wirksamwerdens der Manahme den Startzeitraum vor. Bei der bernahme von historischen Daten wird natrlich der tatschliche Start- und Endezeitpunkt bernommen.
Endezeitpunkt Generell empfehlen wir Ihnen in diesem Zusammenhang, den Endezeitpunkt des Strukturelements gegen unendlich (High Date) laufen zu lassen, also den 31.12.9999 als vorgeschlagenen Endezeitpunkt nicht abzundern.

Planungsstatus Der/die Planungsstatus des Strukturelements folgt bzw. folgen dem Statusnetz von Organisationsmanagementobjekten. Ein Strukturelement befindet sich nach dem Anlegen im Status Geplant und wird im Rahmen des Genehmigungsprozesses in Beantragt, Genehmigt bzw. Aktiv gewandelt.

89

Stammdaten und Organisationsstruktur

Diese Aktivierung kann sowohl manuell ber die Strukturarbeitsoberflche als auch ber die Organisationsmanahmen durchgefhrt werden. Dabei werden Statuschecks und Folgeaktionen durchgefhrt (siehe Abschnitt 3.4, Strukturen der Branchenlsung DFPS).
Verknpfungen Verknpfungen stellen nicht nur die Verbindung zu vorgesetzten und nachgeordneten Strukturelementen dar, sondern werden auch gemeinsam zu sogenannten Verwendungstypen (Grundstruktur, Einsatzstruktur, bung etc.) zusammengefasst, um dann damit Strukturen abzubilden (siehe Abschnitt ,3.4 Strukturen der Branchenlsung DFPS).

Beschreibende Infotypen des Strukturelements Alle weiteren bentigten Attribute/Aufgaben des Strukturelements werden auf Reitern des Detailbereichs abgebildet. Generell wurde bereits bei der Entwicklung versucht, auf bereits in SAP ERP HCM vorhandene Infotypen zurckzugreifen und z.B. die folgenden Infotypen des Organisationsmanagements zu nutzen: Infotyp 1000 Objekt Infotyp 1001 Verknpfungen Infotyp 1002 Verbale Beschreibung Infotyp 1008 Kontierungsmerkmale Infotyp 1018 Kostenverteilung Infotyp 1019 Kontingentplanung Diese Standard-Infotypen reichen jedoch nicht aus, um z.B. das Strukturelement restlos zu beschreiben, daher wurden branchenspezifische Infotypen (im Namensraum von 1950 bis 1990) geschaffen, die vor allem militrspezifische Attribute abdecken. Die folgende Aufzhlung zeigt diese branchenspezifischen 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

90

Gesamtstammdatenmodell von DFPS

3.3

Infotyp 1980 Verlegung Infotyp 1981 Verlegung Material Infotyp 1982 Verlegung Personal Infotyp 1984 Logisches System Infotyp 1985 Einsatz-/bungsverknpfungen Infotyp 1986 Strukturinformation Infotyp 1988 Operative Gewichtung Wir mchten Ihnen nun im weiteren Verlauf die wichtigsten Infotypen exemplarisch vorstellen.
Infotyp 1950 Eigenschaften

Dieser Infotyp wird bereits beim Anlegen eines regulren Strukturelements ausgefllt, daher ist er bei jedem Strukturelement vorhanden, auer bei Einstzen und bungen.
Auswirkungen auf Rechnungswesen und Logistik Das Customizing dieses Infotyps im IMG stellt die Basis fr einige Prozesse des Rechnungswesens (z.B. der automatischen Generierung der CO-Stammdaten) und der Logistik dar.

Der Infotyp 1950 definiert die grundlegenden organisatorischen Eigenschaften eines Strukturelements. Dazu gehren z.B. die folgenden: Das Land, zu dem das Strukturelement gehrt Die Angabe des Landes hat neben dieser rein informativen Betrachtung und einem eventuellen Nutzen in multinationalen Stben und Einheiten auch eine Auswirkung auf das dahinter liegende Controlling. Organisationsbereich Der Organisationsbereich spiegelt in den meisten Fllen die Teilstreitkrfte wider, allerdings knnen auch Bereiche wie Militrmedizin und Seelsorge als eigener Organisationsbereich angesehen werden.
Organisationsbereich Steuerungselement fr die Stammdatenorganisation Gerade der Organisationsbereich ist ein wesentliches Steuerungselement fr das weitere Anlegen von Stammdaten. So knnen damit Waffengattungen, die automatische Kostenstellengenerierung sowie im Bereich des MPO die Anzahl der planbaren Objekte auseinandergesteuert werden.

91

Stammdaten und Organisationsstruktur

Organisationsbereichstyp Der Organisationsbereichstyp ist eine Gruppierung der Organisationsbereiche; die Standardauslieferung Militr- (M), Zivil- (Z), Hilfsorganisation (A fr Aid Organization) und Polizeiorganisation (P) liefern eine bloe Vorlage fr Organisationsbereichstypen und knnen natrlich nach Bedarf abgendert oder ergnzt werden. Dabei gilt es, zu beachten, dass pro Organisationsbereichstyp eine Struktur durch Strukturebenen festgelegt wird. Strukturebene Die Strukturebene entspricht der militrischen Grenordnung ausgehend vom Organisationsbereichstyp werden Strukturebenen definiert. So verfgt M ber eine andere Struktur als C (Armee, Korps, Division, Brigade, Regiment etc.). Dahinter lsst sich zustzlich der Symbol Modifier d.h. die dem NATO-Standard 2525B entsprechende Grenordnung festmachen. Gliederungsform Die Gliederungsform spezifiziert die Strukturebene. Die Strukturebene Kompanie weist z.B. folgende Gliederungsformen auf: Kompanie, Batterie, Staffel.
Strukturebene Bei der Auseinandersteuerung von Gliederungsformen bleibt das taktische Zeichen der Strukturebene erhalten. Diese Information ist bei der Verwendung geografischer Informationssysteme (GIS) entscheidend, denn mit ihrer Hilfe kann die jeweilige militrische Einheit im Kartenwerk dargestellt werden.

Truppengattung, -zusatz und -art Diese drei Eigenschaften beschreiben die jeweilige Waffengattung ihres Strukturelements. Angenommen, Sie whlen die Waffengattung Infanterie, dann knnten Sie im Zusatz zwischen leichter, motorisierter, mechanisierter Infanterie sowie zwischen Gebirgs- und Fallschirmjgern unterscheiden. Die Art wrde in diesem Fall Kampftruppe sein. Generell gilt auch hier, dass das ausgelieferte Customizing eine bloe Vorlage darstellt und natrlich bei Bedarf an Ihre Vorgaben angepasst werden kann. Dienststelle Die Checkbox Dienststelle hat rein informativen Charakter und dient der Kennzeichnung, dass es sich bei Ihrem Strukturelement um eine Dienststelle handelt.

92

Gesamtstammdatenmodell von DFPS

3.3

Taktisches Zeichen zuordnen Auch bei der Truppengattung lsst sich ber den Symbolcode des NATO-Standards 2525B das entsprechende taktische Zeichen zuordnen. Es empfiehlt sich, dies gleich beim erstmaligen Anlegen im IMG durchzufhren. Dann knnen Sie sich mit einem entsprechend gekoppelten geografischen Informationssystem (GIS) das Strukturelement auf der Landkarte darstellen lassen.

Symbolcode Dieser 15-stellige Symbolcode entspricht dem NATO-Standard MIL-STD2525B Common Warfighting Symbology und wird aus der Waffengattung und Grenordnung zusammengestellt. Dies ermglicht die Abbildung auf geografischen Informationssystemen (GIS). Unit Identifier Code Dies ist ein auf NATO STANG 5500 basierender Code, der Einheiten eindeutig beschreibt. Er besteht aus dem Lnderschlssel wie DE, dem Organisationsbereich wie 1 fr Armee und einem sechsstelligen Code. Referenzstrukturelement Dieses Feld erlaubt das Speichern der Objekt-Identifikationsnummer (Objekt-ID) eines Referenzstrukturelements.
Infotyp 1956 Einsatz/bung

Dieser Infotyp wird verwendet, um Strukturelemente vom Subtyp Einsatz und bung zu beschreiben. Diese stellen immer das oberste Strukturelement einer Einsatz- oder bungsstruktur dar, und somit wird der Infotyp 1956 bereits beim Anlegen eines neuen Einsatzes oder einer bung befllt. Mehr ber dessen direkte Verwendung erfahren sie in Kapitel 4, Operational Planning.
Strukturelement mit Infotyp 1956 Ein mit dem Infotyp 1956 versehenes Strukturelement sollte nur als Klammer fr die Rahmenbedingungen der darunter liegenden Struktur wahrgenommen werden. Vermeiden Sie Zuordnungen von Personal und Material, diese sind zwar technisch mglich, erfllen allerdings realen keinen Zweck, da es sich ausschlielich um ein Sammel-Strukturelement handelt.

Im Folgenden beschreiben wir Ihnen die wichtigsten Felder des Infotyps 1956: Objektzeitraum Dieses Feld stellt die technische Lebenslinie des Strukturelements dar und hngt nicht mit dem Einsatzzeitraum zusammen.

93

Stammdaten und Organisationsstruktur

Endezeitpunkt des Objektzeitraums Verwenden Sie auch hier den 31.12.9999 als Endezeitpunkt fr Ihr Strukturelement und nicht das voraussichtliche Ende Ihres Einsatzes.

Operativer Zeitraum Dieser Zeitraum definiert den tatschlichen Start- und Endezeitpunkt des Einsatzes und auch die Vorschlagswerte fr die Kontingente. Kontingente Kontingente definieren die Zeitrume der Rotationen/Ablsungen sowohl von Personal als auch von Material. Intensitt Dieses Feld beschreibt die Intensitt von Einstzen oder bungen; es hat meist einen indirekten Einfluss auf die Lohn- und Gehaltsabrechnung von Soldaten.
Infotypen 1953 und 1954 Leistungsangebot und Leistungsbezug

Diese beiden Infotypen gilt es, gemeinsam zu betrachten, da sie in einem Anbieter-Verbraucher-Verhltnis stehen. Untersttzungsbeziehungen des Nachschubs und der Instandhaltung, die minutengenau als Verknpfungen abgebildet werden, um das Weiterleiten von Anforderungen und Auftrgen sicherzustellen, bentigen sehr viele Tabelleneintrge. Daher entschied man sich, fr Untersttzungsbeziehungen mit eher informativem Charakter zwei Infotypen zu verwenden. Diese Infotypen 1953 und 1954 dienen in erster Linie dem Abbilden von Serviceverhltnissen, bei denen es ausreicht, tagesgenau zu agieren. In den meisten Fllen werden sowohl Wirtschaftsservices (Welche Einheit bezahlt die Rekruten?) als auch medizinische Services (Welches Militrspital ist fr welche Einheiten zustndig?) abgebildet. Infotyp 1953 bietet den im IMG vordefinierten Service an (siehe Abbildung 3.11), und Infotyp 1954 stellt den Bezug eines Services dar. In diesem Fall sehen Sie eine Sanittskompanie einer Brigade, die die geplante Zuordnung der medizinischen Grundversorgung Role 2 hat. Das heit, sie stellt bereits hochwertige medizinische Versorgung sicher. Als hervorhebenswerte Funktionalitten lassen sich folgende nennen: Eigennutzung alle angebotenen Services knnen auch vom eigenen SE konsumiert werden. Where-used-Button (Verwendungsnachweis-Button) er ermglicht den raschen berblick ber die Bezieher des jeweiligen Services.
94

Gesamtstammdatenmodell von DFPS

3.3

Mglichkeit zur Massennderung diese besteht im Popup-Screen des Verwendungsnachweises, dadurch knnen Sie z.B. auf einmal den medizinischen Versorger mehrerer Einheiten wechseln.

Abbildung 3.11 Infotyp 1953 hier als medizinische Grundversorgung

Folgeaktionen definieren Etwaige Folgeaktionen, die durch die Aktivierung der Serviceverknpfungen gestartet werden sollen, lassen sich im IMG durch ein Business Add-In Folgeaktivitten und Filter fr Infotypen 1953/1954 definieren.

Infotyp 1952 Stationierung

Dieser Infotyp speichert alle Adress- und weiteren Standortinformationen, die fr Folgeprozesse der Logistik, z.B. fr die Mobilmachung, bentigt werden.

Abbildung 3.12 Infotyp 1952 Stationierung und seine Subtypen

95

Stammdaten und Organisationsstruktur

Dabei stehen, wie in Abbildung 3.12 zu erkennen, folgende Subtypen zur Verfgung: Post- und Lieferanschrift MOB-Adresse Personal und Material Nchster Bahnhof, Flughafen oder Seehafen Geolokation (gem WGS84) Es lassen sich ber die rein informatorische Beziehung automatisch Adressinformationen von der Wirtschaftseinheit auf die Strukturelemente vererben. Des Weiteren lassen sich Adressen auch innerhalb der Struktur ber die Buttons und finden und vererben. Massennderungen von Adressen an ganzen Strukturen sind mit der Transaktion Stationierung bearbeiten (/isdfps/CDD_DEPLYMNT) mglich.
Infotyp 1988 Operative Gewichtung

Dieser Infotyp entspringt einer Anforderung der Defense Interest Group (DEIG). Um die Einsatzbereitschaft oder Readiness der eigenen Krfte einschtzen zu knnen, ist es notwendig, diese zuvor zu gewichten. ber vordefinierte Gewichtungen von Struktur, personellem und materiellem Soll wird die Kalkulation der Einsatzbereitschaft durch den Vergleich mit dem Ist und dem Personal und Material ermglicht. Die Definition dieser Gewichtungen erfolgt nach grundlegenden Einstellungen im IMG ber den Infotyp 1988. Damit lassen sich standardmig die Gewichtung der Verknpfungen zwischen SE SE; SE S; SE MPO; S QB, Q und S MPO abbilden. Vor dem Anlegen dieser Gewichtungen (siehe Abbildung 3.13), mssen Sie bereits Klarheit ber folgende Fragen haben: Welchen Wert hat z.B. die Planstelle Bataillonskommandeur fr ein Bataillon? Wie wichtig ist ein Nachtsichtfernglas fr die Planstelle? Wie entscheidend sind die vorhandenen Qualifikationen? Kurz und gut, Sie mssen zuvor wissen, wie Sie Ihre TOE gewichten wollen, um danach auch tatschlich eine realistische Gewichtung zu erlangen. Das Anlegen dieser Gewichtungsstrukturen ber den Infotyp 1988 stellt jedoch nicht den Hauptteil dieser Kalkulation der operativen Gewichtung dar, denn dieser findet mithilfe von BW statt.

96

Gesamtstammdatenmodell von DFPS

3.3

Sie haben nun einen berblick ber die gebruchlichsten Infotypen des Strukturelements erhalten. All diese sind in der standardmigen Auslieferung enthalten. Natrlich knnen Sie auch kundenspezifische Infotypen zur zustzlichen Beschreibung des Strukturelements in die Struktur-Workbench mit aufnehmen. Die DFPS-spezifischen Infotypen wurden im Namensraum 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 Objekttyps Organisationseinheit dar. Diese Erweiterung erfolgt mithilfe der Tabelle /ISDFPS/FORCE, die vor allem die Integration mit der Logistik ermglicht. Neben den Kernattributen eines Objekts verfgt das Strukturelement bereits standardmig ber beschreibende Infotypen.

3.3.2

Planstelle

Fr den Aufbau eines Organisationsplans ist die Planstelle von entscheidender Bedeutung. Sie reprsentiert das personelle Soll eines Strukturelements. Im Gegensatz zum vorher sehr ausfhrlich behandelten Strukturelement gibt es fr die Planstelle keine DFPS-spezifischen Tabellen, wie die zuvor beschriebene Tabelle /ISDFPS/FORCE. Die Planstelle entspricht der Planstelle S aus dem Organisationsmanagement, wird allerdings ber die Struktur-Workbench angelegt.

97

12

IT-Architektur

Gibt es klare und vollstndige Dokumentationen fr die Systeme, aus denen insbesondere ersichtlich ist, welche besonderen Anforderungen der jeweilige Organisationsbereich stellt? Gibt es Architekturstandards fr die einzelnen Systeme? Gibt es klar definierte Governance-Modelle fr die Systeme und notwendige Vernderungen? Gibt es bergreifende Datenmodelle fr mehrere Systeme? Existieren Schnittstellenvereinbarungen zwischen den einzelnen Systemen fr den Datenaustausch?

12.1.5

Extrem hohe Sicherheitsanforderungen

Der gesamte Bereich, der von der Lsung DFPS untersttzt wird, unterliegt extrem hohen Sicherheitsanforderungen. Gehrt in SAP-Projekten in der Industrie das Thema Berechtigungskonzept zu den untersttzenden Funktionen im Projekt, so verstehen viele Sicherheitsorganisationen und Armeen diesen Bereich als Kernprozess. Bei dieser Ausgangsposition ergeben sich wichtige Fragen fr Ihr Projekt, die Sie klren sollten, um eine effiziente Arbeit an der Architektur sicherzustellen: Welche Vorgaben existieren fr den Geheimschutz der Daten? Welche Vorgaben sind zu beachten (z.B. Datenschutzgesetze)? Gibt es eine klare Festlegung in der Organisation, welche Personenkreise auf welche Daten zugreifen knnen? Gibt es Einheiten in Ihrer Organisation, deren Daten ber den normalen Geheimschutz hinaus einem besonderen Schutz unterliegen mssen (z.B. Spezialkrfte)? Gibt es Personen in Ihrer Organisation, deren Daten nicht im System zugnglich sein drfen? Welche Netzstruktur gibt es? Welche Vorgaben gibt es fr die Weiterverwendung der Daten (z.B. Drucken nur in gesicherten Druckerrumen)?

12.2

Referenzarchitektur

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

422

Referenzarchitektur

12.2

Standorte mit dem System zu versorgen. Vielmehr muss eine verteilte Systemlandschaft geschaffen werden, die ein Einsatzszenario untersttzt und den autarken Betrieb der dezentralen Komponenten sicherstellt. Um Ihnen einen sicheren Ausgangspunkt fr Ihr Projekt zu geben, werden wir Ihnen zunchst die Referenzarchitektur mit ihren verschiedenen Bestandteilen vorstellen. Diese Referenzarchitektur besteht aus zwei Stufen: den Zentralsystemen am Heimatstandort (siehe Abschnitt 12.2.1, Zentrale Systemebene am Heimatstandort) und den dezentralen Systemen mit den mobilen Anwendungen (siehe Abschnitt 12.2.2, Dezentrale Systeme). Die verschiedenen Ebenen werden durch speziell fr DFPS entwickelte Schnittstellenkomponenten verbunden, die auf den Komponenten Application Link Enabling (ALE) und Product Data Replication (PDR) aufsetzen. Kurz gesagt, stellen diese Erweiterungen sicher, dass die Autarkiefhigkeit der dezentralen Systeme optimal untersttzt werden kann, indem zusammengehrige Stamm-, Bewegungs- und Benutzerdaten zwischen den beteiligten Systemen verteilt werden. Auf diese Komponenten werden wir im Verlauf des Kapitels noch genauer eingehen, ihre Erwhnung ist jedoch schon jetzt wichtig, um den Zusammenhang zwischen den verschiedenen Systemebenen verstehen zu knnen. Abbildung 12.1 zeigt den schematischen Aufbau der Referenzarchitektur.

Zentralsystem Heimatbasis

Dezentrale Systeme SAP ERP

Dezentrale Systeme SAP ERP

Dezentrale Systeme SAP ERP

ALE

SAP Mobile Infrastructure

MI Client

MI Client

MI Client

Logistics Execution System

Abbildung 12.1 Referenzarchitektur DFPS im berblick

423

12

IT-Architektur

Die Referenzarchitektur wird dabei im Kern vom ERP-System mit der DFPSLsung gebildet. In den vorangegangenen Kapiteln wurde Ihnen sicherlich schon die Bedeutung der Logistik fr die Einsatzuntersttzung klar. Aus diesem Grund ist das Logistics Execution System (LES) Bestandteil der Systemarchitektur. LES besteht aus verschiedenen Komponenten, z.B. Warehouse Management (WM Mit LES knnen die Prozesse in den Bereichen Beschaffung, Lagerung, Distribution, Transport, Verkauf und Service flexibel verknpft werden. Um die mobilen Szenarien abbilden zu knnen, die in Kapitel 17, Mobile Anwendungen, genauer dargestellt werden, sind die Komponenten Mobile Infrastructure und Mobile Client notwendig. Diese ermglichen mobile Szenarien, sodass etwa erste Einheiten, die nach Lhamosa verlegt werden, arbeiten knnen, ohne dass eine permanente Netzverbindung bereits vorhanden ist. Dabei bilden die zentrale und die dezentrale Ebene den prinzipiellen Aufbau der Architektur ab. Innerhalb einer Ebene kann es durchaus noch die Verteilung von Funktionalitten auf verschiedene Systeme z.B. aus Sicherheitsgrnden geben. Aus Grnden der bersichtlichkeit werden wir diese Themen jedoch erst nach dem berblick betrachten.
Dezentrale Systeme rumliche Trennung nicht zwingend erforderlich Hervorzuheben ist dabei jedoch, dass sich die Unterscheidung zwischen den verschiedenen Ebenen nicht zwangslufig auf den physischen Standort der Systeme bezieht. So knnen etwa dezentrale Systeme durchaus im gleichen Rechenzentrum stehen wie die Systeme der zentralen Ebene.

12.2.1

Zentrale Systemebene am Heimatstandort

Die zentralen Systeme in der Heimatbasis verfgen ber die kompletten Funktionalitten, um den Grundbetrieb mit den dazu notwendigen Prozessen in Ihrer Organisation zu untersttzen. Darber hinaus kommt dieser Ebene jedoch eine zentrale Bedeutung fr die gesamte Landschaft zu: So werden hier auch die Systeme fr bungen und Einstze zentral aufgebaut. Darber hinaus wird von hier auch die Administration der gesamten Systemlandschaft ber die Ebenen hinweg sichergestellt. Fr den Grundbetrieb der betriebswirtschaftlichen Prozesse umfasst diese Ebene damit mindestens ein ERP-System als Produktivsystem sowie SAP NetWeaver als Technologieplattform mit den verschiedenen Komponenten.

424

Referenzarchitektur

12.2

Welche Elemente der Technologieplattform verwendet werden (Portal, Business Intelligence/BW, Master Data Management etc.), ist abhngig von den konkreten Einsatzszenarien. Darber hinaus kann zur zentralen Ebene der Referenzarchitektur auch SAP Supply Chain Management mit der Komponente SAP Advanced Planning & Optimization (APO) gehren.
ERP und DFPS Das Herzstck Ihres IT-Systems Lassen Sie sich nicht von der Vielzahl der Komponenten verwirren. Das SAP ERPSystem mit der Branchenlsung SAP for Defense & Security (DFPS) ist das absolut zentrale Element Ihrer Landschaft. Dieses System muss das fhrende System Ihrer Landschaft sein, wenn Sie nicht zahlreiche Probleme erzeugen mchten. Dies gilt insbesondere fr die Verbindung mit bereits existierenden HR-Systemen ein Bereich, auf den wir in Kapitel 15, DFPS und die Prozesse des Personalwesens, noch ausfhrlich eingehen werden. Gehen Sie bei all Ihren Architekturberlegungen immer von diesem ERP-System aus, sodass Sie es als stabile Grundlage fr Ihre gesamte Systemlandschaft verwenden knnen.

In den meisten Fllen wird darber hinaus ein System mit der Zentralen Benutzerverwaltung (ZBV) fr die Systemlandschaft aufgebaut. In Zukunft wird hier sicherlich anstelle der ZBV vermehrt SAP NetWeaver Identity Management zum Einsatz kommen. Um die Funktionen fr den Aufbau der dezentralen Systeme sicherzustellen und die Systemlandschaft insgesamt zu administrieren, werden Sie darber hinaus weitere Systeme einsetzen: Template-System fr den Aufbau der dezentralen Systeme In der Praxis hat es sich bewhrt, fr den Aufbau der dezentralen Systeme eine Kopie des produktiven ERP-Systems mit den notwendigen Daten bereitzustellen. Die dezentralen Systeme werden durch eine Kopie aus diesem System heraus erzeugt. Die hierfr notwendigen Ressourcen werden durch die Vorteile, insbesondere die Betriebssicherheit, aufgewogen. Template-System fr Middleware-Systeme Wie im Fall des produktiven ERP-Systems werden auch fr die Middleware-Komponenten entsprechende Systeme als Vorlagen fr die Erzeugung der dezentralen Systeme bereitgestellt. Solution Manager Der Solution Manager im zentralen Systembereich ist das System, das alle notwendigen Funktionalitten fr alle Systeme der drei Ebenen enthlt, um diese aufzubauen, zu verwalten, aber auch (z.B. nach der Rckfhrung eines Einsatzverbandes) wieder abzubauen.

425

12

IT-Architektur

12.2.2

Dezentrale Systeme

Der Aufbau mehrerer Systemebenen ist in vielen SAP-Landschaften eine Option, die nicht zwingend genutzt werden muss. In DFPS-Landschaften ist dies jedoch die Regel und versetzt Sie eben in die Lage, eine verteilte Systemlandschaft aufzubauen, die den besonderen Anforderungen hinsichtlich der Autarkie gengt. Die zweite Ebene der DFPS-Landschaft wird von den dezentralen Systemen gebildet. Diese Systeme untersttzen die Prozesse, die bei einem Offlinebetrieb ohne Verbindung mit dem Zentralsystem von Bedeutung sind.
Beispiele fr dezentrale Systeme Organisatorisch betrachtet, sind dies etwa im militrischen Bereich Systeme auf Brigadeebene, auf Schiffen, auf vorgeschobenen Flugpltzen etc. Im Bereich des Katastrophenschutzes sind dies Systeme aus dem Bereich der Einsatzabschnitte, z.B. einem Flchtlingslager bei einem humanitren Einsatz im Ausland. Denken Sie hierbei etwa wieder an unsere Fallstudie mit der Hilfsoperation nach dem Tsunami in Lhamosa.

Ziel dieser Systeme ist es, die Autarkiefhigkeit des jeweiligen Verbandes auch unter den besonderen Einsatzbedingungen (insbesondere ohne aktive Netzverbindung) sicherzustellen. Ebenso wie die zentrale Systemebene besteht auch die Ebene der dezentralen Systeme aus mehreren Systemen: Dezentrale Produktivsysteme Die dezentralen Produktivsysteme werden von den Einheiten zumeist direkt in das Einsatzgebiet mitgefhrt. Sie enthalten nur den Ausschnitt der Daten, der fr das jeweilige Einsatzgeschehen notwendig ist. Dezentrale Middleware-Systeme Auf dieser Ebene wird ein Middleware-System mit einem InstallationsToolkit-Server installiert, sodass auch die mobilen Anwendungen auf mobilen Endgerten betrieben werden knnen. Mobile Endgerte Mobile Endgerte kommen etwa in vorgeschobenen Kommandoposten zum Einsatz. Sie enthalten nicht vollstndige Datenstze, sondern nur die Ausschnitte, die fr die Prozesse, die dort ausgefhrt werden mssen, von Bedeutung sind. Dabei ist nicht nur ein Offlinebetrieb mglich. Vielmehr knnen die Endgerte auch direkt mit dem produktiven ERP-System der dezentralen Ebene interagieren.

426

Referenzarchitektur

12.2

Externe Systeme (GIS, C2) Fr den Bereich der Einstze ist die Verbindung mit Fhrungssystemen (Command and Control, C2 etwa bei multinationalen Verbnden) von besonderer Wichtigkeit. Dies ermglicht DFPS dadurch, dass die entsprechenden Standards fr den Datenaustausch (z.B. Allied Data Publication No. 3, ADatP-3) untersttzt werden. Darber hinaus bietet DFPS auch die Mglichkeit, geographische Informationssysteme (GIS) anzuschlieen. Spiegelsysteme Bei der Darstellung der Anforderungen an die Systemarchitektur haben wir bereits deutlich gemacht, dass fr die Verbnde im Einsatz Betriebssicherheit, kombiniert mit einem geringen Aufwand fr die Administration, von hchster Bedeutung ist. Aus diesem Grund werden fr die dezentralen Systeme Spiegelsysteme aufgebaut. Diese dienen dazu, Transporte einspielen zu knnen, um sie testen und jegliche Strungen in den dezentralen produktiven Systemen ausschlieen zu knnen. Aus diesem Grund ist es wichtig, dass fr jeden Softwarestand der Systeme ein eigenes Spiegelsystem vorgehalten wird.

12.2.3

Beispiel 1 Systemlandschaft fr eine Luftlandeeinheit

Lassen Sie uns das Verfahren fr den Aufbau einer Systemlandschaft fr einen Einsatz am Beispiel einer Luftlandeeinheit illustrieren, die etwa zur Sicherung einer Hilfsoperation wie der in Lhamosa in ein Einsatzgebiet verlegt wird. Aus dem Zentralsystem heraus wird ein Template-System aufgebaut. Ebenso wird ein Template-System fr die Middleware aufgebaut. Aus diesem System heraus werden sowohl das dezentrale Produktivsystem als auch das dezentrale Middleware-System mit den fr den Einsatz notwendigen Daten erzeugt. Da es sich um eine Luftlandeeinheit handelt, wird ein mobiler Kommandoposten zustzlich noch ber mobile Anwendungen angebunden. Auch bei einem lnger andauernden Einsatz garantieren die Spiegelsysteme in der Heimat, dass die im Einsatzraum verwendeten Systeme der Luftlandeeinheit strungsfrei verwendet werden knnen, da hier alle nderungen an der Systemkonfiguration getestet werden knnen. Abbildung 12.2 illustriert noch einmal diesen Aufbau. Aus Grnden der bersichtlichkeit sind die externen Systeme, die auf der dezentralen Ebene integriert werden (GIS, C2), nicht eingezeichnet:

427

Index
A
ABC-Stoffe (Anschlag) 629 abgeleitete Rolle 526 Abrechnung der Einstze 563 Abweichung 343 Abweichungsursache 344 ADatP 427, 517 ADatP-3 420, 614, 615 Adobe-Formular 384, 569 Agilitt 36, 417 Air Task Order 333, 647 Aktivierung mit Organisationsmanahme 131 ohne Organisationsmanahme 126 Alarm- und Ausrckeordnung 571 Alarmplan 566 ALE-Verteilung von Organisationsdaten 569 alternative Kennzeichnung 295 ALV 392 Analyse 430 Analyse und Berichtswesen 371 Anforderung Armee 34 IT 38 Sicherheitsorganisationen 36 Application Link Enabling (ALE) 423 Architektur 417, 418, 436, 461 Anforderung 417 Muster 434 Referenzarchitektur 422, 423 Risiken und Probleme 437 Standards 422 Architektur-Board 431 Armee Anforderung 34 Besonderheit 37 Prozessmodell 41 ASD Spec 1000 D/2000 M 294 ASD Spec 2000 M 292 ATA-100 294 Aufbauorganisation 56, 118 Allgemeine Aufbauorganisation (AAO) 38, 626 Besondere Aufbauorganisation (BAO) 38, 561, 626 Aufgabenkatalog 493 Aufwuchsfhigkeit 420 Auslandseinsatz Polizei 629 Auslieferung 267 Ausstattungspaket 112, 221 Austauschbarkeit 242 Auswertewege 117 Autarkie der Systeme 629 Autarkiefhigkeit 418, 426, 487, 530

B
Backoffice 602 Balanced Scorecard (BSC) 373, 375 Dimensionen BSC 376 Bedarfsdringlichkeit 253 Bedarfsdringlichkeitsgruppe 253, 258 Bedarfsprioritt 253, 254, 259 Benutzerverwaltung 520 Berechtigung 507 Berechtigungskonzept 511 Berechtigungsmanagement mobile Systeme 528 Berechtigungsverwaltung 520 Bereitschaftsgrad 590 Analysieren 595 Bereitschaftsstand 594, 596 Berichtsaufbereitung 374 Besetzungsvorschlag 155, 497, 499 Best Practices 195 Bestandselement 209, 211, 222 Bestandslagerort 329 Bestandssituation 250 Bestellanforderung Anlegen 234, 271 Umsetzen 263 Betriebsteile 220 Betriebswerte 344 BEx Query Designer 409 BI Content DFPS 401 Bottleneck-Qualifikation 182, 198 Bottleneck-Ressource 195 Bundesamt fr Sicherheit in der Informationstechnik (BSI) 509

655

Index

Bundeswehr 47, 377 Hauptprozesse 48 Prozessmodell 40 Reporting 49 Bundeswehr Balanced Scorecard 49 Business Process Owner 501 BusinessObjects-Plattform 385 Business-Rollen 521 Business-Silo 485, 608 Business-Szenario 610

C
C2IS 614, 616 C2-Systeme 427, 488 Capabilities 496 Case Management 169 Charge 268, 270 Checkbox Abneigungen 197 Coalition Warrior Interoperability Demonstration (CWID) 431, 614 Cockpit 597 Composite Application 608 Controller 377 Core2Defense 467

DFPS-Implementierung Ansatz 463 bestehende Erweitern 466 Krisenmanagementlsung einer Region 468 Prozessmodul 454 vollstndige (Streitkrfte eines Landes) 464 Dienstvorschrift 509 Digitalfunk 572 Disponenten-Workbench 234, 261 DOE 528 DV 100 576

E
EA-DIMP 240 Earned Value Reports 594, 596 Eigenschaft Adaptieren 162 Einbauort 295, 299 Einsatz Abrechnung 564 Aktivieren 171 Beenden 173 Nachbereitung 564 Einsatz- und Blaulichtorganisationen 65 Bedingung 46 Bereitschaft 489 Durchfhrung 564 Gert 328 Intensitt 151 Kontingent 54 Einsatzlebenszyklus 139 Phase 1 141 Phase 2 146 Phase 3 170 Phasen 4 und 5 172 Einsatzleitrechner 573 Einsatzleitsoftware 44 Einsatzleitsystem 573 Einsatzorganisation 137, 177, 481, 482 Einsatzplan 633 Einsatzplanung 194, 495, 498, 564 Einsatzstruktur 121, 561, 633 Einsatzstrukturelement 278 Anlegen 150

D
Data Enrichment 538 Data Provisioning 614 Daten-Cube 399 Datenherkunft verndern 297 Datenmodell 45 Datenqualitt 457, 463 Defense & Security Hub 513 Defense User Interest Group (DEIG) 47 Demonstration 629 Design 430 dezentrales Qualifikationsmanagement 195 dezentrales System 315, 423, 426, 537, 539, 540 DFPS 65 Einsatz 39 Funktionalitten 46 Grundanforderung 33 Struktur 78, 90, 116

656

Index

Einsatzstrukturplanung 153 Einsatztaktik Polizei 626 Einsatztyp 151, 634, 635, 636 Einsparung 593 Einzelnderung 131 Einzelverbrauchsgter (EVG) 209, 245 Emergency Data Exchange Language (EDXL) 420 Enterprise Service Interface 612 Enterprise Services 611, 612, 613 Epizentrum 55 Equipment 299 Einbauort 299 Nummerierung 301 Erstausstattung 171 erste logistische Ebene 535, 538 Erstversorger Material 252 Erstversorgung 251 Ertragsperspektive 596 erweiterte Historie 301 Erweiterungspaket 613 ESR 613 ES-Workplace 589, 609 EU-Mechanismen 561 Eventualfallplanung 144

Flugstunde 594 garantierte Verfgbarkeit 584 Flugbersicht 63, 336 Folgeaktion 170 Folgeversorgung 252 Force Multiplier 38, 39 Force Provider 483 Formulare offline 579 Fremdsystem 462 Friedensstruktur 118 Frost & Sullivan 582 Fhrungsinformationssystem 39, 487, 616 funktionale Blcke (Katastrophenschutz) 561 funktionaler Ansatz 465 Fuball-Europameisterschaft 2008 52

G
garantierte Verfgbarkeit 584 Gegenstromprinzip 378 Geheimhaltungsbedarf 512, 637 Geheimhaltungsvorschrift 636 Geheimschutz 634 Geiselnahme 629 Genehmigungsprozess 497 Geoinformationssystem (GIS) 427, 570, 633 Geolokationen 57 geplante Kosten 594 Geschftsmodell neues 585 Geschftsprozesse 605 GIS 57 Golden Hour 51 Governance-Modell 422 Governmental Organization 347 GRC 524 grenzberschreitende Kriminalitt 631 Groschadensereignis 44 Groschadenslagen 572 Grundprozesse von Sicherheitsorganisationen 560 Grundschulung DFPS 442 Gltigkeit 195 Gltigkeitszeitraum 185

F
Fachinformationssystem 40, 487, 616 Katastrophenschutz 44 Factory-to-Foxhole-Prozess 536 Fhigkeit 483 Suchen 154 fhigkeitsorientierte Planung 142 Fall-ID 635 Fallstudie 53, 306 Ausgangslage 53 Planungsphase 147 First Mission 138 Flexibilitt 287 Flug 63, 331 Flugauftrag 331, 335 Flugbetrieb 317 Fluggerteinstandsetzung 586 Flugplan 343 Flugsicherheit 239 Flugstatus 343, 586

657

Index

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

I
ICM 623, 633, 638 ICM-System 632 iCOD 616 Identity Center 522 Identity Store 522 IH-Planungswerk 302 Implementierungsstudie 429 Individualausbildung 408, 433 Individualmanahme 131 InfoProvider 411 Information und Einsatz im Sanittsdienst (IES) 51 informationsgetriebene Bereiche 623 Informationsberlegenheit 601 Infotyp 0024 192 0806 201 1055 187 1950 504 1953/1954 505 1956 503 1988 205 783 500 806 200, 203 Infrastruktur 77 Infrastrukturplanungsobjekt 115 Instandhaltung 543, 552 Dimensionen 284 militrische 284 Instandhaltungsauftrag 253 Instandhaltungsbeziehung 303, 310 spezialisierte 307

Instandhaltungsbezogene Unternehmensstruktur 286 Instandhaltungsstrategie 582 Instandhaltungstiefe 285 Instandsetzungsbeziehungen 304 Instandsetzungskosten 594 Integration 168, 462 ICM und DFPS 633 Organisation und Logistik 212 integriertes Produkt- und Prozess-Engineering (iPPE) 107, 214 Interaction Center 566 interaktive Formulare 631 Intervallbeleg 327 iPPE-Objekt 494 IS-A&D EA-DIMP Ist-Bestand 62 Ist-Rstcode 336 itelligence AG 51 Item Unique Identification 238

K
Katalog 492, 494, 503 Katastrophenschutz 559 Charakteristika 625 Kalender 566 Krisenstab 518 Ressourcenmanagement 560 Kennzahlen 49 Kommunikation unterschiedliche Schutzstufen 515 Kommunikation im Stab 564 Kontingent 278 Definieren 152 Kontingentgre 158 Kontingentplanung 152, 157, 159, 161, 483, 503 kontrolliertes Abfliegen 336, 337 Koordinierter Sanittsdienst in der Schweiz 51, 561, 628 Kopierfunktion 496 Planstellen 161 Kopiermglichkeit 165 Kosten geplante 594 ungeplante 594 Kosteneinsparung 37 Kostenstellenstruktur 593

658

Index

Krisenmanagement 565 Krisenstab 45 Katastrophenschutz 518 Kursangebot DFPS 440

L
Lagefeststellung 564 Lager 37 Lagerort 255, 270 Laufbahnplanung 196 Lebenszyklusmodell 139 Leih-Banf 276 Leihe 276 Leitstelle 44, 563, 566, 572 Leitstelle auf Basis von SAP ICM 571 Leitstellenarbeit 565 Leitverband 252, 484 Lessons Learned 177 letzte taktische Meile 534 Lhamosa 372, 373, 418, 420, 516, 519, 629, 631 Lieferantencharge 268 Lieferprioritt 260 Liegeplatz 342 Logistic Assessment 604, 613, 618 Logistics Execution System (LES) 424 logistische Ebene 275 logistische Unternehmensstruktur 248 Luftfahrtgesellschaft 584 Luftfahrtindustrie 598 Luftfahrzeug 584

M
mangelhafte IT-Untersttzung 563 Master Parts List 244, 343 Master-Equipment 327, 329, 338 Material Planen 164 Materialbewirtschaftung 544 Materialcontainer 110, 219 Materiallage 223 Materialnummer 236 Materialplanungsobjekt 60, 106, 213, 214 Modelle 215

Materialstamm Materialstamm anlegen 250 Materialstammsatz 214 Materialverantwortlicher 217 materielle Planung 227, 257 Ablaufsbersicht 230 materielles Ist 222 materielles Soll 60, 245 Maximalprinizp 345 mehrere DFPS-Leitstellen 574 Meldebestand 247 Mengenverbrauchsgter (MVG) 209, 245 Microsoft Office-Produkte 563 Middleware 537, 539, 540 Military Data Exchange 603 Milizarmee 286 MilStd 2525B 488 Minimalprinzip 346 Mission 329 mobile Anwendung 533, 536 Mobile Client 424, 538 Benutzer anlegen 529 Mobile Defense & Security (MDS) 315, 534 Mobile Infrastructure 424 mobile Instandhaltung 315 mobile Systemlandschaft 528 mobiles Reporting 548 mobiles System Berechtigungsmanagement 528 Model Identification Code 292 Model Identifier Model Identification Code 338 Modell 217 MPO-Organisationseinheit 218 MPO-Workbench 107, 214 MPO-Zuordnung 218 MRO 313 MRO-Services 584

N
Nachbereitung des Einsatzes 564 Nachrichtendienst 623 Lsung 632 Musterprozesse 637 Prozesse 625

659

Index

NATO 420, 431, 603 NATO Architecture Framework (NAF) 428 NATO Stock Number 236 NATO-Standard 45 Network Centric Warfare 599 Netze 515 Trennung (rot und schwarz) 515 Netzwerk 514 netzwerkzentrierte Kriegsfhrung 419, 599 netzwerkzentriertes Unternehmen 601 neue Geschftsmodelle 585 Nichtverbrauchsgter 209 niedrigere Schutzstufe 517 Nutzer 276

P
parallele Struktur 118 PBL 286, 581, 582 PBL-Anbieter 588, 591 PBL-Architekturvarianten 588 PBL-Prozess 586 Flugzeuginstandhaltung 587 PBL-Systemuntersttzung 588 PBL-Szenario 585, 589 PBL-Untersttzung Bereiche 590 Pegelstand 382 Performance-Based Logistics PBL Person 100 Personal Planen 156 Personalmanahme 499, 500 Personalplanung 171 Personalwesenprozess 192 personelles Ist 187 personelles Soll 187, 192 Persnliche und funktionelle Ausrstung 100 phasenorientiertes Vorgehen 456 Planstelle 97 Planstellenkontingent 159 Planung Eventualfallplanung 145 fhigkeitsorientierte 142 Herausforderung 145 politische Einflsse 455 Polizei 560, 566, 623 Auslandseinsatz 629 Charakteristika 625 Einsatztaktik 626 Operationsplaner 634 Prozesse 625 Polizeiorganisation Auslandseinsatz 624 Plattform 632 Power by the hour 584 Praxisbericht 47 Pressluftatmer 585 priorisierte Disposition 262 Prioritt 253 Privatindustrie 48 Process Maturity 501

O
oberster Technischer Platz 322 OF-Transaktionen 68 Olympische Spiele 624, 627 On-going Mission 138 Operational Planning 137, 488, 491 Operationalisierung Backoffice 602 Operationsplaner Polizei 634 operative Gewichtung 204 operativer Beginn 151 operatives Berichtswesen 387 operatives Ende 151 Organisation und Personal 546 organisationsbezogene Stammdaten 302 Organisationsebenenfeld 527 Organisationsmanahme 131, 149, 157, 185, 193, 498, 504 Statuswechsel 150 Organisationsplan 482, 486, 495 Organisationsstruktur 38, 55 organisatorische Flexibilitt 46, 53, 65, 250, 305, 308, 461 organisatorische Prioritt 253, 254, 255 organisierte Kriminalitt 631 Outsourcing 285

660

Index

Process Performance Indicators 346 Product Data Replication (PDR) 423 Programmmanagement 589 Programmmanager 597 Projekt 1. Phase 463 Bereitschaftsstand 458 Bestandteil 461 grundstzliches Vorgehen 460 Komplexitt 454 Phasen 456 Rahmenbedingung 459 Zielvorgaben 460 Projekt- und Risikomanagement 453 Projektmanagement 456, 457, 461 Projektrisiken 471, 472 fachliche 477 Top 9 472 Projektrollen Architekt 445 Basisberater 448 Change-Management-Berater 449 DFPS-Berater 447 Programmmanager 444 Projektleiter/Teilprojektleiter 444 Sicherheitsexperte 449 Stellenanzeige 446, 448 Projektteam Anforderung 439 Checkliste 451 Rollen 439 Rollenverteilung 443 Schlsselrollen 442 Projektvorgehen 458, 464 Core2Defense 467 Krisenmanagement 470 Provisioning Framework 522 Provisions 246 Prozessbereich 40 Prozesse Nachrichtendienst 637 Polizei 625 Sicherheitsorganisationen 559, 624 Prozessmodell Armee 41 Bundeswehr 40 Sicherheitsorganisationen 43 prozessuale Festlegung 462

Q
Qualification Management 177 Qualifikation 180, 184 Qualifikationsblock 180, 185, 192, 491, 501 Qualifikationsgruppe 182, 183 Anlegen 183 Qualifikationskatalog 180, 185, 194 Qualifikationsmanagement 178, 488 dezentrales 195 Qualifikationsstammdaten Verwalten 180

R
Rahmenbedingung 34 Raumfahrtindustrie 581, 598 Rechnungswesen 168, 345 Referenzarchitektur 422, 423 Referenzmesspunkt 297, 326 Anlegen 297 Referenzplatz 325 Referenzrolle 526 Regelbetrieb 561 Reorder Point 247 Reportable Item Code 63, 111 Reporting 593, 596 Mittlere Fhrungsebene 373 mobiles 548 Operative Ebene 373 Reporting Materialwirtschaft 389 Reporting Politische Ebene/Obere Fhrungsebene 372 Reportingpyramide 372, 385 Rolle 511 Rollen- und Berechtigungskonzept 511 Rollenmanager 526 rotes Netz 508, 515 Routinebetrieb 44 Rckfhrungscode 275 Rckgabedatum 276 Rcklieferung 61, 273 Rcklieferungs-Bestellanforderung 276, 649 Rckverlegung 172 Rstungs- und Raumfahrtindustrie 581 Rstzustand 332

661

Index

S
Sandbox-System 503 Sanittsdienst Schweiz Koordinierter Sanittsdienst SAP BusinessObjects Access Control 522 SAP BusinessObjects Explorer 379, 381 SAP BusinessObjects governance, risk, and compliance (GRC) 520 SAP BusinessObjects Strategy Management 376 SAP BusinessObjects-Portfolio 596 SAP Developer Network (SDN) 589, 613 SAP Enterprise Architecture Framework 428 SAP for Aerospace & Defense 82 SAP Interactive Forms by Adobe 569, 575, 630 SAP Investigative Case Management (SAP ICM) 565, 570 SAP NetWeaver BW 397, 400, 594 SAP NetWeaver Identity Management 425, 520, 521, 523 SAP-Lsungsbestandteile (Polizei) 632 Schadensart 306 schadensbedingte Instandhaltung 308 Schadensbehebung 538, 550 Schichtenmodell S4-Krisenstab im Katastrophenschutz 518 Schnittstelle 630 Schulungskatalog 441 Schulungsplan 450 Schutzaufgaben 547, 550 Schutzstufe niedrige 517 schwarze Netze 515 Schweiz 572 Serialisierungsinformation 292 Serialnummernprofil 238 Service Operations 612 Servicebetrieb 582 serviceorientierte Architektur 599, 604, 613 Services 612 Sicherheit 507 dezentrales System 514 DFPS-Checkliste 531 Sicherheitsanforderung 422

Sicherheitsgateway 517 Sicherheitskonzept 507, 509, 511 Sicherheitsorganisation Anforderung 36 Besonderheiten 37 Prozesse 42, 624 Prozessmodell 43 Sicherheitsstufe 515 Sicherheitsberprfung 637 Singapur Armed Forces 51 Site-Equipment 329 Skala 184 Vererben 184 Smong 59 SOA-Definition 605 Sofortlage 626 Softwarearchitektur 533 Soll-Ist-Vergleich 215, 224, 227 Struktur-Workbench 224 Soll-Rstcode 336 Solution Map 609 Spezialeinheit 626 Spezialkrfte 512, 513, 514 Spiegelsystem 427 staatliche Einsatzorganisaton 347 Stab 147 Kommunikation 564 Stabsarbeit 565, 579 Stabslsung 576 Stammdaten 54, 287, 492, 494 organisationsbezogene 302 Standard-Anwendungs-Software-Produkt-Familien (SASPF) 48 Standardversorger 231 Standortwerk 302 Statusboard 63, 318, 337 Statuscode 271 Statusnetz 125 Statusprfung 170 Stelle 105, 198 Strategie-Dashboard 596, 597 Streitkrfte Singapurs 50 Streitkraft-zentrierter Ansatz 465 Struktur 118 parallele 118 technischer Hintergrund 148 Struktur DFPS-Struktur Strukturebene 143

662

Index

Strukturelement 75, 85, 209, 303 Berechtigungen 526 Integration in die Logistik 209 Strukturelement Logistic Unit 160 Strukturelemente integrieren 209 Strukturkennzeichen 295, 323 Strukturlcke 343 Struktur-Workbench 71, 487 Stcklisten 301 Suche 231 Sustainability 267, 273 Synchronisation 538, 542, 552 System dezentrales 423, 426, 537, 539, 540 rotes 508 Spiegelsystem 427 Template-System 425 zentrales 423, 539 Systemarchitektur 535 Spezialkrfte 513 Systemebene zentrale 423, 424 Systemlandschaft heterogene 421 Luftlandeeinheit 428 mobile 528 Szenario Polizei 625

T
Tabelle /ISDFPS/FORCE 496 Tabelleneintrag /ISDFPS/FORCE 505 Table of Organization and Equipment 68 Tail Number 324, 341 Tail Number taktisches Kennzeichen Takeover/Handover 313 taktisches Kennzeichen 324 TDv/B007 294 Technische Objekte 288 organisatorische Flexibilitt 290 Stammdaten 288 Technische Referenzpltze 297 Technischer Platz 289, 296 Kennzeichnung 295 Nummerierung 291 Serialisierungsinformation 292

Technischer Referenzplatz 291 Technologieebenen SAP BusinessObjects 412 Teilekennzeichen 240 Teilflugstrecke 333 Teilstreitkraft 433, 455 Telekommunikationsberwachung (TK) 633 Template-System 425, 539 The Open Group Architecture Framework (TOGAF) 428 THW 383 Time Change Item 335, 649 Train as you fight-Grundsatz 486 Trainingsdaten 200 Trainingsprogramm 199 Transaktion 67 /isdfps/MAT_COMP 226 /isdfps/TOEM 1 392 /isdfps/TOEM 2 392 /ISDFPS/TOEP1 188 /isdfps/TOEP1 193 PPPM 188 Transport- und Logistikbranche 584 TREX 383 truppendienstliche Unterstellung 120 trusted RFC-Verbindung 634 Tsunami 57 Einsatzplaner 510 Fallstudie 394, 562 Hilfsoperation 388 turn-over-time 285 Twitter 601

U
bungsstruktur 122 Umlagerungsbestellung 228 Unfallmeldebericht 550 ungeplante Kosten 594 Unique Item Identifier 238 Unternehmensstruktur 207 Untersttzungsbeziehungen 209 User Interface 615

663

Index

V
Value Chain 609 Verbrauchsgter 593 Vereinte Nationen 629 Verfeinerung 431 Verfgbarkeit (Luftfahrzeuge) Berichte 594 Verknpfung Planstellen 157 Speichern 182 Verlegeplanung 278 Verlegung 279 Vermisstenauskunft 565 Verschlsselung 509 Versorger 61 Versorgungsartikelkonzept 236, 243 Versorgungsbeziehung 61, 231 Versorgungsnummer 236 Verteidigungsstruktur 119 verteilte Instandhaltung 315 Verwendungstyp 56, 74 Vierfachvordruck 576 Vierfachvordruck als interaktives Formular 577 Virtual Directory Servers 522 Virtual Private Networks (VPN) 516 Vorgehensmodell Architektur 428, 429 Vorratselement 209, 211, 246 Vorratslagerort 246, 249 Vorratspaket 62, 114, 245

Weiterleitungsfunktion 307 Weltwirtschaftsforum Davos 52 Weltwirtschaftsgipfel 624 Werk 255 Workbench Qualifikationen pflegen 190 Workflow 306, 578 Workitem 155 WSDL 612

X
Xcelsius 385, 413 XML 517

Y
Yowie 601

Z
ZBV-Anbindung ndern 530 ZBV-Verbindung ndern 531 Zeitlage 626, 627 zentrale Benutzerverwaltung (ZBV) 425, 524, 539 zentrale Systemebene 423, 424 zentraler Personalwesenprozess 192 zentraler Qualifikationskatalog 180, 185 zentrales System 423, 539 Zielvereinbarung 197 Zulu-Zeit 334 Zuordnungszeitraum 194 Zustandscode 267, 275 Zustandsverwaltung 269 Zwischenstopp 334

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

664