Wiki Lighthouse MCS - Benutzerbeiträge [de]

Stammdatenaufbau Modul A - Trainings- und Ressourcenmanagement

2026-06-17T14:27:52Z

Lighthouse1:

Bowline ist objekt-orientiert designt. Dem Bowline [[Grundmodul A - Trainings- und Ressourcenmanagement]] liegt nachstehendes [[Datenmodell]] zugrunde:
[[Datei:Datenmodell Trainingskontext.png|mini|695x695px|links]]

Empfohlende Reihenenfolge:

# [[Aufbau Trainingsorte]] [[Objekttypen 8F-F|(8F-F)]]
# Aufbau Ressourcenkatalog [[Objekttypen 9A-R-G/H/P|(9A-R-G/H/P)]]
# Aufbau Trainingskatlog [[Objekttypen L-D-E|(L-D-E)]]

Region

2026-06-17T14:20:56Z

Lighthouse1: Die Seite wurde neu angelegt: „Der Objekttyp 8F - Region gehört zu den Bowline-Objekttypen und bündelt / gruppiert mehrere Orte: z.B. Kiel, Lübeck und Husum werden der Region 8F "Schleswig-Holstein" zugeordnet. Informationen eines 8F, z.B. 8F - Schleswig-Holstein- können von allen zugeordneten F (hier: Kiel, Lübeck und Husum) genutzt werden. Beispiel: nur 1 Kalendereintrag für alle untergeordneten F.“

Der Objekttyp 8F - Region gehört zu den Bowline-Objekttypen und bündelt / gruppiert mehrere Orte: z.B. Kiel, Lübeck und Husum werden der Region 8F "Schleswig-Holstein" zugeordnet.

Informationen eines 8F, z.B. 8F - Schleswig-Holstein- können von allen zugeordneten F (hier: Kiel, Lübeck und Husum) genutzt werden. Beispiel: nur 1 Kalendereintrag für alle untergeordneten F.

Trainingsorte

2026-06-17T14:14:32Z

Lighthouse1:

Im SAP-Organisationsmanagement (OM) sind „Orte“ der Objekttyp F.

Kurz erklärt:

* Objekttyp F = Ort Ein Ort ist - grundsätzlich - ein organisatorischer Platz, an dem Aktivitäten stattfinden können, z. B. eine Stadt, ein Gebäude, ein bestimmtes Gelände oder auch ein übergreifender Standort. Orte können z. B. generell genutzt, um:
** Arbeitsplätze / Stellen / Organisationseinheiten einem bestimmten Standort zuzuordnen und
** Trainings oder andere Weiterbildungsmaßnahmen einem Ort zuzuordnen
* Orte können vielfältige Beziehungen (sprich: Verknüpfungen) haben:
** Zu Organisationseinheiten (O) – z. B. „O ist an Ort F“
** Zu Personen (P) – z. B. „P ist tätig an Ort F“ und im Bowlione-Sinne zu
** Trainings - z.B. " E findet an einem bestimmten Ort" statt

* Was noch?
** Mehrere Orte (F) können zu einer [[Region]] (8F) gehören.

Trainingsorte

2026-06-17T14:14:02Z

Lighthouse1: Die Seite wurde neu angelegt: „Im SAP-Organisationsmanagement (OM) sind „Orte“ der Objekttyp F. Kurz erklärt: * Objekttyp F = Ort Ein Ort ist - grundsätzlich - ein organisatorischer Platz, an dem Aktivitäten stattfinden können, z. B. eine Stadt, ein Gebäude, ein bestimmtes Gelände oder auch ein übergreifender Standort. Orte können z. B. generell genutzt, um: ** Arbeitsplätze / Stellen / Organisationseinheiten einem bestimmten Standort zuzuordnen und ** Trainings o…“

Stammdatenaufbau Modul A - Trainings- und Ressourcenmanagement

2026-06-17T14:02:58Z

Lighthouse1:

Bowline ist objekt-orientiert designt. Dem Bowline [[Grundmodul A - Trainings- und Ressourcenmanagement]] liegt nachstehendes [[Datenmodell]] zugrunde:
[[Datei:Datenmodell Trainingskontext.png|mini|695x695px|links]]

Empfohlende Aufbaureighenfolge:

# [[Trainingsorte]] (8F-F)
# [[Ressourcenkatalog]] (9A-R-G/H/P)
# [[Trainingskatalog]] (L-D-E)

Stammdatenaufbau Modul A - Trainings- und Ressourcenmanagement

2026-06-17T14:01:35Z

Lighthouse1:

Bowline ist objekt-orientiert designt. Dem Bowline [[Grundmodul A - Trainings- und Ressourcenmanagement]] liegt nachstehendes [[Datenmodell]] zugrunde:
[[Datei:Datenmodell Trainingskontext.png|mini|695x695px|links]]

Empfohlende Aufbaureighenfolge:

# [[Traningsorte]] (8F-F)
# [[Ressourcenkatalog]] (9A-R-G/H/P)
# [[Trainingskatalog]] (L-D-E)

Stammdatenaufbau Modul A - Trainings- und Ressourcenmanagement

2026-06-17T14:00:16Z

Lighthouse1:

Bowline ist objekt-orientiert designt. Dem Bowline [[Grundmodul A - Trainings- und Ressourcenmanagement]] liegt nachstehendes [[Datenmodell]] zugrunde:
[[Datei:Datenmodell Trainingskontext.png|mini|695x695px|links]]

Empfohlende Aufbaureighenfolge:

# Traningsorte (8F-F)
# Ressourcenkatalog (9A-R-G/H/P)
# Trainingskatalog (L-D-E)

Stammdatenaufbau Modul A - Trainings- und Ressourcenmanagement

2026-06-17T13:52:10Z

Lighthouse1:

Stammdatenaufbau Modul A - Trainings- und Ressourcenmanagement

2026-06-17T13:48:44Z

Lighthouse1:

Datei:Datenmodell Trainingskontext.png

2026-06-17T13:46:10Z

Lighthouse1:

Kontext der für das Trainingsmanagement benötigten Objekttypen

Stammdatenaufbau Modul A - Trainings- und Ressourcenmanagement

2026-06-17T13:42:37Z

Lighthouse1:

Bowline ist objekt-orientiert designt. Dem Bowline [[Grundmodul A - Trainings- und Ressourcenmanagement]] liegt nachstehendes [[Datenmodell]] zugrunde:

Der Stammdatenaufbau kann umfänglich über den [[Strukturmanager]] vorgenommen werden.

Objekt-orientiert

2026-05-29T11:49:20Z

Lighthouse1:

Das Datenmodell des SAP HCM-Moduls '''Personalplanung und -entwicklung (PD)''' bildet die strukturelle Grundlage für alle Prozesse des Organisationsmanagements, des Veranstaltungsmanagement (inkl. LSO) und damit '''auch von Bowline'''.

Dieses Datendesign basiert '''nicht''' auf dem klassischen t'''abellarischen Datenbankmodell der Personaladministration''' (PA), sondern auf einem '''objekt- und beziehungsbasierten Ansatz''':

''Reale Entitäten wie '''Trainings, Ressourcen,''' etc. werden als '''Objekte abgebildet''' und über typisierte '''Verknüpfungen miteinander in Beziehung gesetzt.'''''

Konkret:

* [[Objekttyp]]<nowiki/>en - realisiert über den IT 1000 Objekt
* [[Relationen]] - realisiert über den IT 1001 Verknüpfung mit A (aktiv) und B (passiv) Richtung und Subtypen
* [[Attribute]] - realisiert über die Infotypen > 1001

Relationen

2026-05-29T11:47:49Z

Lighthouse1:

= Relation (Verknüpfung) in der objektorientierten Programmierung =
In der objektorientierten Programmierung (OOP) beschreibt Relation die Beziehung zwischen Objekten. Diese Relationen definieren, wie Objekte miteinander interagieren und welche strukturellen Verbindungen zwischen ihnen bestehen.

== Die drei Haupttypen von Relationen ==

=== 1. Zuordnung (Association) ===
"Wir verwenden einander"

* Eine lockere Verbindung zwischen zwei unabhängigen Klassen
* Keine Lebenszyklusabhängigkeit
* Beispiel: Ein <code>Professor</code> hält Vorlesungen für <code>Student</code>en

----

=== 2. Aggregation (Teil-von) ===
"Wir gehören zusammen, aber getrennt lebensfähig"

* Eine "Hat-ein"-Beziehung mit schwacher Eigentumsbindung
* Die Teile können auch ohne das Ganze existieren
* Beispiel: Eine <code>Universität</code> hat <code>Fakultät</code>en – diese können aber theoretisch eigenständig bestehen

----

=== 3. Komposition (Composition) ===
"Wir leben und sterben zusammen"

* Eine starke "Teil-von"-Beziehung mit gemeinsamem Lebenszyklus
* Die Teile können nicht ohne das Ganze existieren
* Beispiel: Ein <code>Auto</code> besteht aus einem <code>Motor</code> – wenn das Auto verschwindet, gehört der Motor nicht mehr dazu

In Bowline, wie auch im SAP Organisationsmanagement, wird der Charakter semantisch ausgedrückt und über die [[Zeitbindungen]] konkretisiert.

'''Die korrekte Modellierung dieser Relationen ist essenziell für eine saubere Softwarearchitektur und beeinflusst direkt Wartbarkeit und Erweiterbarkeit des Codes.'''

Relationen

2026-05-29T11:42:09Z

Lighthouse1:

= Relation (Verknüpfung) in der objektorientierten Programmierung =
In der objektorientierten Programmierung (OOP) beschreibt Relation die Beziehung zwischen Objekten. Diese Relationen definieren, wie Objekte miteinander interagieren und welche strukturellen Verbindungen zwischen ihnen bestehen.

== Die drei Haupttypen von Relationen ==

=== 1. Zuordnung (Association) ===
"Wir verwenden einander"

* Eine lockere Verbindung zwischen zwei unabhängigen Klassen
* Keine Lebenszyklusabhängigkeit
* Beispiel: Ein <code>Professor</code> hält Vorlesungen für <code>Student</code>en

----

=== 2. Aggregation (Teil-von) ===
"Wir gehören zusammen, aber getrennt lebensfähig"

* Eine "Hat-ein"-Beziehung mit schwacher Eigentumsbindung
* Die Teile können auch ohne das Ganze existieren
* Beispiel: Eine <code>Universität</code> hat <code>Fakultät</code>en – diese können aber theoretisch eigenständig bestehen

----

=== 3. Komposition (Composition) ===
"Wir leben und sterben zusammen"

* Eine starke "Teil-von"-Beziehung mit gemeinsamem Lebenszyklus
* Die Teile können nicht ohne das Ganze existieren
* Beispiel: Ein <code>Auto</code> besteht aus einem <code>Motor</code> – wenn das Auto verschwindet, gehört der Motor nicht mehr dazu

In Bowline, wie auch im SAP Organisationsmanagement wird der Charakter semantisch ausgedrückt und über die [[Zeitbindungen]] konkretisiert.

'''Die korrekte Modellierung dieser Relationen ist essenziell für eine saubere Softwarearchitektur und beeinflusst direkt Wartbarkeit und Erweiterbarkeit des Codes.'''

Relationen

2026-05-29T11:40:17Z

Lighthouse1:

= Relation (Verknüpfung) in der objektorientierten Programmierung =
In der objektorientierten Programmierung (OOP) beschreibt Relation die Beziehung zwischen Objekten. Diese Relationen definieren, wie Objekte miteinander interagieren und welche strukturellen Verbindungen zwischen ihnen bestehen.

== Die drei Haupttypen von Relationen ==

=== 1. Zuordnung (Association) ===
"Wir verwenden einander"

* Eine lockere Verbindung zwischen zwei unabhängigen Klassen
* Keine Lebenszyklusabhängigkeit
* Beispiel: Ein <code>Professor</code> hält Vorlesungen für <code>Student</code>en

----

=== 2. Aggregation (Teil-von) ===
"Wir gehören zusammen, aber getrennt lebensfähig"

* Eine "Hat-ein"-Beziehung mit schwacher Eigentumsbindung
* Die Teile können auch ohne das Ganze existieren
* Beispiel: Eine <code>Universität</code> hat <code>Fakultät</code>en – diese können aber theoretisch eigenständig bestehen

----

=== 3. Komposition (Composition) ===
"Wir leben und sterben zusammen"

* Eine starke "Teil-von"-Beziehung mit gemeinsamem Lebenszyklus
* Die Teile können nicht ohne das Ganze existieren
* Beispiel: Ein <code>Auto</code> besteht aus einem <code>Motor</code> – wenn das Auto verschwindet, gehört der Motor nicht mehr dazu

In Bowline, wie auch im SAP Organisationsmanagement wird der Charakter semantisch ausgedrückt und über die der verwendeten Verknüpfung über die

Die korrekte Modellierung dieser Relationen ist essenziell für eine saubere Softwarearchitektur und beeinflusst direkt Wartbarkeit und Erweiterbarkeit des Codes.

Relationen

2026-05-29T11:37:31Z

Lighthouse1: Die Seite wurde neu angelegt: „ = Relation (Verknüpfung) in der objektorientierten Programmierung = In der objektorientierten Programmierung (OOP) beschreibt Relation die Beziehung zwischen Objekten. Diese Relationen definieren, wie Objekte miteinander interagieren und welche strukturellen Verbindungen zwischen ihnen bestehen. == Die drei Haupttypen von Relationen == === 1. Zuordnung (Association) === "Wir verwenden einander" * Eine lockere Verbindung zwischen zwei unabhängigen Kl…“

= Relation (Verknüpfung) in der objektorientierten Programmierung =
In der objektorientierten Programmierung (OOP) beschreibt Relation die Beziehung zwischen Objekten. Diese Relationen definieren, wie Objekte miteinander interagieren und welche strukturellen Verbindungen zwischen ihnen bestehen.

== Die drei Haupttypen von Relationen ==

=== 1. Zuordnung (Association) ===
"Wir verwenden einander"

* Eine lockere Verbindung zwischen zwei unabhängigen Klassen
* Keine Lebenszyklusabhängigkeit
* Beispiel: Ein <code>Professor</code> hält Vorlesungen für <code>Student</code>en

----

=== 2. Aggregation (Teil-von) ===
"Wir gehören zusammen, aber getrennt lebensfähig"

* Eine "Hat-ein"-Beziehung mit schwacher Eigentumsbindung
* Die Teile können auch ohne das Ganze existieren
* Beispiel: Eine <code>Universität</code> hat <code>Fakultät</code>en – diese können aber theoretisch eigenständig bestehen

----

=== 3. Komposition (Composition) ===
"Wir leben und sterben zusammen"

* Eine starke "Teil-von"-Beziehung mit gemeinsamem Lebenszyklus
* Die Teile können nicht ohne das Ganze existieren
* Beispiel: Ein <code>Auto</code> besteht aus einem <code>Motor</code> – wenn das Auto verschwindet, gehört der Motor nicht mehr dazu

Die korrekte Modellierung dieser Relationen ist essenziell für eine saubere Softwarearchitektur und beeinflusst direkt Wartbarkeit und Erweiterbarkeit des Codes.

Objekt-orientiert

2026-05-29T11:34:16Z

Lighthouse1:

Objekttyp

2026-05-29T11:31:46Z

Lighthouse1: Die Seite wurde neu angelegt: „== Objekttyp in der objektorientierten Programmierung == Ein Objekttyp (oder auch ''Klasse''/''Class'') ist in der Objektorientierung die Blaupause oder Schablone, nach der Objekte erstellt werden. === Kernidee === {| class="wikitable" !Begriff !Bedeutung |- |Objekttyp / Klasse |Definiert ''was'' ein Objekt ist und ''was'' es kann (Eigenschaften + Verhalten) |- |Objekt / Instanz |Ein konkretes Exemplar dieses Typs |} === Beispiel === <code>KLASSE: Fahr…“

== Objekttyp in der objektorientierten Programmierung ==
Ein Objekttyp (oder auch ''Klasse''/''Class'') ist in der Objektorientierung die Blaupause oder Schablone, nach der Objekte erstellt werden.

=== Kernidee ===
{| class="wikitable"
!Begriff
!Bedeutung
|-
|Objekttyp / Klasse
|Definiert ''was'' ein Objekt ist und ''was'' es kann (Eigenschaften + Verhalten)
|-
|Objekt / Instanz
|Ein konkretes Exemplar dieses Typs
|}

=== Beispiel ===
<code>KLASSE: Fahrzeug
├── Eigenschaften (Attribute)
│ ├── farbe
│ ├── geschwindigkeit
│ └── kennzeichen
│
└── Verhalten (Methoden)
├── beschleunigen()
├── bremsen()
└── hupen()

INSTANZEN (konkrete Objekte):
├── meinAuto: Fahrzeug → farbe: "rot", kennzeichen: "B-XY 123"
├── deinAuto: Fahrzeug → farbe: "blau", kennzeichen: "M-AB 456"</code>

<code>KLASSE: Fahrzeug
├── Eigenschaften (Attribute)
│ ├── farbe
│ ├── geschwindigkeit
│ └── kennzeichen
│
└── Verhalten (Methoden)
├── beschleunigen()
├── bremsen()
└── hupen()

INSTANZEN (konkrete Objekte):
├── meinAuto: Fahrzeug → farbe: "rot", kennzeichen: "B-XY 123"
├── deinAuto: Fahrzeug → farbe: "blau", kennzeichen: "M-AB 456"</code>

=== Wichtige Eigenschaften ===

* Abstraktion: Der Objekttyp fasst relevante Daten und Funktionen zusammen
* Wiederverwendbarkeit: Ein Typ kann beliebig viele Objekte erzeugen
* Kapselung: Interne Details werden verborgen, öffentliche Schnittstelle definiert
* Vererbung: Typen können von anderen Typen abgeleitet werden (z. B. <code>Auto</code> erbt von <code>Fahrzeug</code>)

=== Unterscheidung: Typ vs. Klasse ===
In manchen Sprachen (z. B. Java, C#, Python) spricht man meist von Klassen. Der Begriff Objekttyp betont eher die abstrakte Konzeptebene – also ''der Typ von Dingen'', die im Programm vorkommen.

Objekt-orientiert

2026-05-29T11:30:03Z

Lighthouse1:

Das Datenmodell des SAP HCM-Moduls '''Personalplanung und -entwicklung (PD)''' bildet die strukturelle Grundlage für alle Prozesse des Organisationsmanagements, des Veranstaltungsmanagement (inkl. LSO) und damit '''auch von Bowline'''.

Dieses Datendesign basiert '''nicht''' auf dem klassischen t'''abellarischen Datenbankmodell der Personaladministration''' (PA), sondern auf einem '''objekt- und beziehungsbasierten Ansatz''':

''Reale Entitäten wie '''Trainings, Ressourcen,''' etc. werden als '''Objekte abgebildet''' und über typisierte '''Verknüpfungen miteinander in Beziehung gesetzt.'''''

Konkret:

* [[Objekttyp]]<nowiki/>en - realisiert über den IT 1000 Objekt
* Relationen - realisiert über den IT 1001 Verknüpfung mit A (aktiv) und B (passiv) Richtung und Subtypen
* Attribute - realisiert über die Infotypen > 1001

Stammdaten

2026-05-29T11:27:40Z

Lighthouse1:

Stammdaten im Bowline-Sinne sind alle strukturgebenden Daten, die zeitlich (grundsätzlich) stabil sind und aus denen sich die Strkturen und Kataloge bilden lassen.

Bowline definiert im Rahmen der [[Objektorientierung|Objekttypen]]

* [[Trainingstyp|Trainingstypen]]
* [[Ressourcentyp]]<nowiki/>en und
* [[Ort]]<nowiki/>e
zum Kern der Stammdaten sowie

* Trainingsgruppen
* Ressourcenarten
* Regionen

Stammdaten mit ausschließlich sortierenden Eigenschaften.

Diese Kern-Stammdaten werden aktionsbezogen erweitert um

* Organisationseinheiten
* Firma
* externe Person
* Arbeits- resp. Ausbildungsplätze
* Tätigkeiten
* Qualifikationen (mit Sortierstammdatum Qualifikationsprofil und ggf. Qualifikationskatalog)
* Berufsbilder (Entwicklungspläne mit Entwicklungsplangruppe)

Eine spezielle Bedeutung haben die sog. externen Stammdaten, wie z.B.

* Mitarbeiter /Person / Centrale Person und
* Kostenstelle

Stammdaten

2026-05-29T11:25:42Z

Lighthouse1:

Stammdaten im Bowline-Sinne sind alle strukturgebenden Daten, die zeitlich (grundsätzlich) stabil sind und aus denen sich die Strkturen und Kataloge bilden lassen.

Bowline definiert im Rahmen der Objekttypen

* Trainingstypen
* Ressourcentypen und
* Orte
zum Kern der Stammdaten sowie

* Trainingsgruppen
* Ressourcenarten
* Regionen

Stammdaten mit ausschließlich sortierenden Eigenschaften.

Diese Kern-Stammdaten werden aktionsbezogen erweitert um

* Organisationseinheiten
* Firma
* externe Person
* Arbeits- resp. Ausbildungsplätze
* Tätigkeiten
* Qualifikationen (mit Sortierstammdatum Qualifikationsprofil und ggf. Qualifikationskatalog)
* Berufsbilder (Entwicklungspläne mit Entwicklungsplangruppe)

Eine spezielle Bedeutung haben die sog. externen Stammdaten, wie z.B.

* Mitarbeiter /Person / Centrale Person und
* Kostenstelle

Stammdaten

2026-05-29T11:15:58Z

Lighthouse1:

Stammdaten

2026-05-29T11:11:42Z

Lighthouse1: Die Seite wurde neu angelegt: „Stammdaten im Bowline-Sinne sind alle strukturgebenden Daten, die“

Stammdaten im Bowline-Sinne sind alle strukturgebenden Daten, die

Stammdatenaufbau

2026-05-29T11:10:30Z

Lighthouse1:

Grundlegend ist zu wissen und zu berücksichtigen, das Bowline '''[[objekt-orientiert]]''' aufgebaut ist.

Die Stammdaten bilden das Fundament und das digitale Rückgrat Ihrer Anwendungen. Sie sind die zentralen, über lange Zeit konstanten Daten, auf die die Bowline-Prozesse zugreifen – zum Beispiel Trainingsdaten, Trainingsort, Ressourceninformationen.

Eine saubere und von Anfang an '''''gut durchdacht angelegte Stammdatenbasis''''' ist der entscheidende '''''Schlüssel für effiziente Abläufe''''', fehlerfreie Transaktionen und aussagekräftige Analysen.

In den folgenden Abschnitten führen wir Sie Schritt für Schritt an die Aufgabe heran:

'''Vorab - einige grundlegende Regeln:'''

* [[Statusmerkmale]]: Stammdaten befinden sich '''immer''' - Ausnahme Trainingsentwicklung Modul G1 - im '''[[Statusmerkmale|Status]] 1 ''aktiv'' .'''

* Alle Datentypen unterliegen der Zeit und haben eine '''[[Gültigkeitsinformation]]'''!
* Sie sind (grundsätzlich, insbesondere beim ersten Aufbau) mit einem einheitlichen '''Beginndatum''' (Vorschlag 01.01.2000) und in der Regel auch mit unbegrenzter Gültigkeit (Endedatum: 31.12.9999) anzulegen.

* Bowline verwendet '''nur''' die [[Planvariante]] '''01 ''aktive Planvariante'''''.
* Stammdaten können '''per [[Stammdaten-Transaktion|Transaktion]] oder [[Stammdaten-Grafik|Grafik]]''' angelegt werden
* Die '''[[Anlegetransaktionen]]''' befindensich im generel'''<nowiki/>'''len [[Strukturmanager]], konkret im [[Stammdatenmanager]] des generellen [[Genereller Strukturmanagers|Strukturmanagers]] (zu erreichen über das '''[[Cockpit]]''')
'''Aufbau der [[Stammdaten]]:'''

* [[Stammdatenaufbau Modul A - Trainings- und Ressourcenmanagement]]
''Das Bowline Modul A ist das Basismodul. Alle anderen Module setzen auf den Datenobjekten dieses Moduls auf.''
* Aufbauergänzung - Trainingsentwicklung (Modul G1)
* Stammdatenaufbau Modul B - Stundenplanung
* Stammdatenaufbau Modul C - Benotung
* Stammdatenaufbau Modul D - Unterkunftsmanagement
* Stammdatenaufbau Modul E - Ausbildungsmanagement
* Stammdatenergänzung für Modul K - Kostenplanung
* Aufbauergänzung Szenarioplanung (Modul G bis einschl. 4.0)

Allgemeinen Strukturmanager

2026-05-29T11:07:56Z

Lighthouse1:

Der allgemeine Strukturmanager gliedert sich in

* den [[Stammdaten]]
* den [[Bewegungsdaten]]
* [[Meetings /Tagungen]] und
* [[Arbeitshilfen]]

Der [[Auskunftsmanager]] über die gesamte Anwendung findet sich direkt im [[Cockpit]].

Allgemeinen Strukturmanager

2026-05-29T10:57:35Z

Lighthouse1: Die Seite wurde neu angelegt: „Der allgemeine Strukturmanager gliedert sich in * den Stammdaten * den Bewegungsdaten * Meetings /Tagungen und * Arbeitshilfen Der Auskunftsmanager über die gesamte Anwendung findet sich direkt im Cockpit.“

Der allgemeine Strukturmanager gliedert sich in

* den [[Stammdaten]]
* den [[Bewegungsdaten]]
* [[Meetings /Tagungen]] und
* Arbeitshilfen

Der [[Auskunftsmanager]] über die gesamte Anwendung findet sich direkt im [[Cockpit]].

Stammdatenaufbau

2026-05-29T10:49:42Z

Lighthouse1:

Grundlegend ist zu wissen und zu berücksichtigen, das Bowline '''[[objekt-orientiert]]''' aufgebaut ist.

Die Stammdaten bilden das Fundament und das digitale Rückgrat Ihrer Anwendungen. Sie sind die zentralen, über lange Zeit konstanten Daten, auf die die Bowline-Prozesse zugreifen – zum Beispiel Trainingsdaten, Trainingsort, Ressourceninformationen.

Eine saubere und von Anfang an '''''gut durchdacht angelegte Stammdatenbasis''''' ist der entscheidende '''''Schlüssel für effiziente Abläufe''''', fehlerfreie Transaktionen und aussagekräftige Analysen.

In den folgenden Abschnitten führen wir Sie Schritt für Schritt an die Aufgabe heran:

'''Vorab - einige grundlegende Regeln:'''

* [[Statusmerkmale]]: Stammdaten befinden sich '''immer''' - Ausnahme Trainingsentwicklung Modul G1 - im '''[[Statusmerkmale|Status]] 1 ''aktiv'' .'''

* Alle Datentypen unterliegen der Zeit und haben eine '''[[Gültigkeitsinformation]]'''!
* Sie sind (grundsätzlich, insbesondere beim ersten Aufbau) mit einem einheitlichen '''Beginndatum''' (Vorschlag 01.01.2000) und in der Regel auch mit unbegrenzter Gültigkeit (Endedatum: 31.12.9999) anzulegen.

* Bowline verwendet '''nur''' die [[Planvariante]] '''01 ''aktive Planvariante'''''.
* Stammdaten können '''per [[Stammdaten-Transaktion|Transaktion]] oder [[Stammdaten-Grafik|Grafik]]''' angelegt werden
* Die '''[[Anlegetransaktionen]]''' befindensich im generel'''<nowiki/>'''len [[Strukturmanager]], konkret im [[Stammdatenmanager]] des generellen [[Genereller Strukturmanagers|Strukturmanagers]] (zu erreichen über das '''[[Cockpit]]''')
'''Aufbau der Stammdaten:'''

* [[Stammdatenaufbau Modul A - Trainings- und Ressourcenmanagement]]
''Das Bowline Modul A ist das Basismodul. Alle anderen Module setzen auf den Datenobjekten dieses Moduls auf.''
* Aufbauergänzung - Trainingsentwicklung (Modul G1)
* Stammdatenaufbau Modul B - Stundenplanung
* Stammdatenaufbau Modul C - Benotung
* Stammdatenaufbau Modul D - Unterkunftsmanagement
* Stammdatenaufbau Modul E - Ausbildungsmanagement
* Stammdatenergänzung für Modul K - Kostenplanung
* Aufbauergänzung Szenarioplanung (Modul G bis einschl. 4.0)

Unterkunftsmanager

2026-05-29T10:25:11Z

Lighthouse1:

Der Unterkunftsmanager ist analog dem generellen Strukturmanager und dem [[Teilnahmemanager]] gestalten, aufgebaut und wird ebenso gehandhabt.

Die Strukturen und Aktionen des Unterkunftsmanagers sind Kunden des [[Bowline Moduls D - Unterkunftsmanagement]] vorbehalten und beschäftigen sich mit der Unterbringung von [[Trainingsteilnehmer]]<nowiki/>n und [[Referenten]], aber auch von sonstigen [[Gäste]]<nowiki/>n in [[Hotel]]<nowiki/>s und insbesondere unternehmseigene [[Unterkünfte]].

Unterkunftsmanager

2026-05-29T10:23:26Z

Lighthouse1:

Der Unterkunftsmanager ist analog dem generellen Strukturmanager und dem [[Teilnahmemanager]] gestalten, aufgebaut und wird ebenso gehandhabt.

Die Strukturen und Aktionen des Unterkunftsmanagers sind Kunden des Bowline Moduls D - Unterkunftsmanagement vorbehalten und beschäftigen sich mit der Unterbringung von Trainingsteilnehmern und Referenten, aber auch von sonstigen Gästen in Hotels und insbesondere unternehmseigene Unterkünfte.

Unterkunftsmanager

2026-05-29T10:19:34Z

Lighthouse1: Die Seite wurde neu angelegt: „Der Unterkunftsmanager ist analog dem generellen Strukturmanager und dem Teilnahmemanager gestalten, aufgebaut und wird ebenso gehandhabt.“

Der Unterkunftsmanager ist analog dem generellen Strukturmanager und dem [[Teilnahmemanager]] gestalten, aufgebaut und wird ebenso gehandhabt.

Teilnahmemanager

2026-05-29T10:17:04Z

Lighthouse1:

Der Teilnahmemanager unterscheidet sich von den anderen Strukturmanagern nur durch das generelle Thema. Der Teilnahmemanager beschäftigt sich ausschließlich mit der Duchführungs von Trainings aus sicht der [[Teilnehmer]].

Teilnahmemanager

2026-05-29T10:14:30Z

Lighthouse1: Die Seite wurde neu angelegt: „Der Teilnahmemanager unterscheidet sich von den anderen Strukturman“

Der Teilnahmemanager unterscheidet sich von den anderen Strukturman

Strukturmananger

2026-05-29T10:13:09Z

Lighthouse1:

Die über [[Cockpit]] zur Verfügung gestellten Strukturmanager werden voreingestellt ausgeliefert. D.h. alle für das Arbeiten mit Bowline erforderlichen Strukturen, werden in den Strukturmanagers angeboten.

Aktuell unterscheiden wir 3 verschiedene Strukturmanager:

* den [[allgemeinen Strukturmanager]]
* den [[Teilnahmemanager]] und
* den [[Unterkunftsmanager]]

In jedem dieser Strukturmanager befinden sich spezifische Informationen und Aktionen zum jeweiligen Thema.

Der [[Aufbau Strukturmanager|Aufbau]] und die [[Handhabung Strukturmanager|Handhabung]] unterscheidet sich nur sehr wenig.

Zudem arbeiten alle Strukturmanager für das Einrichten der Stammdaten mit der sog. [[Strukturgrafik]].

Strukturmananger

2026-05-29T10:05:47Z

Lighthouse1: Die Seite wurde neu angelegt: „Die über Cockpit zur Verfügung gestellten Strukturmanager werden voreingestellt ausgeliefert. D.h. alle für das Arbeiten mit Bowline erforderlichen Strukturen, werden in den Strukturmanagers angeboten. Aktuell unterscheiden wir 3 verschiedene Strukturmanager: * den allgemeinen Strukturmanager * den Teilnahmemanager und * den Unterkunftsmanager In jedem dieser Strukturmanager befinden sich spezifische Informationen und Aktionen zum je…“

Planvariante

2026-05-22T12:23:16Z

Lighthouse1: Die Seite wurde neu angelegt: „Planvarianten sind im Rahmen des SAP Organisationsmanagement ein essenzielles Konzept für die Planung und Simulation von Organisationsstrukturen. Da Bowline auf der Grundstruktur des SAP Organisationsmanagements beruht und mit der selbsen Datenbank (PLOG) arbeitet, wird auch hier eine Planvariante (allerdings nur eine - Planvariante 01) im Hintergrund verwendet. == Was ist eine Planvariante - Grundkonzept == Eine Planvariante ist eine gesonderte, para…“

Planvarianten sind im Rahmen des SAP Organisationsmanagement ein essenzielles Konzept für die Planung und Simulation von Organisationsstrukturen.

Da Bowline auf der Grundstruktur des SAP Organisationsmanagements beruht und mit der selbsen Datenbank (PLOG) arbeitet, wird auch hier eine Planvariante (allerdings nur eine - Planvariante 01) im Hintergrund verwendet.

== Was ist eine Planvariante - Grundkonzept ==
Eine Planvariante ist eine gesonderte, parallel verfügbare Version einer (z.B.) Organisationsstruktur. Sie erlaubt es, Änderungen vorausschauend zu modellieren und zu simulieren, ohne die aktive Struktur zu beeinflussen.

== Zentrale Eigenschaften ==
{| class="wikitable"
!Aspekt
!Beschreibung
|-
|Verfügbarkeit
|Mehrere Planvarianten können parallel existieren
|-
|Verwendung
|Simulation, Planung, Konzernabgleich, Migration
|-
|Abgrenzung
|Jede Planvariante ist eigenständig und isoliert
|-
|Aktivierung
|Eine Variante wird zur "echten" Organisationsstruktur, wenn sie aktiviert wird
|}

== Typische Szenarien ==

* Restrukturierungen: Testen von Umstrukturierungen
* Konzernplanung: Abbildung verschiedener Konzernstrukturen
* Zeitliche Planung: Vorbereitung zukünftiger Trainingsplanungen oder Organisationsänderungen
* Übernahmegestaltung: Integration neuer Unternehmensteile oder auch Wissensgebiete

== Technische Details ==

* Die aktive Planvariante wird über das Planungsdatum bestimmt
* SAP-Standard - und auch Bowline-Standard ist die Planvariante 01 (aktive Version)
* Jede Planvariante hat ein eigenes Gültigkeitsdatum
* Objekte und Beziehungen können variantenspezifisch gepflegt werden

== Vorteile ==

# Risikofreie Planung – keine Auswirkungen auf laufenden Betrieb
# Friktionlose Tests – Simulation verschiedener Szenarien möglich
# Kontrolle – Freigabe-Workflows vor Aktivierung einsetzbar
# Flexibilität – Rückkehr zur Ursprungsstruktur jederzeit möglich

Stammdatenaufbau

2026-05-22T12:17:08Z

Lighthouse1:

Grundlegend ist zu wissen und zu berücksichtigen, das Bowline '''[[objekt-orientiert]]''' aufgebaut ist.

Die Stammdaten bilden das Fundament und das digitale Rückgrat Ihrer Anwendungen. Sie sind die zentralen, über lange Zeit konstanten Daten, auf die die Bowline-Prozesse zugreifen – zum Beispiel Trainingsdaten, Trainingsort, Ressourceninformationen.

Eine saubere und von Anfang an '''''gut durchdacht angelegte Stammdatenbasis''''' ist der entscheidende '''''Schlüssel für effiziente Abläufe''''', fehlerfreie Transaktionen und aussagekräftige Analysen.

In den folgenden Abschnitten führen wir Sie Schritt für Schritt an die Aufgabe heran:

'''Vorab - einige grundlegende Regeln:'''

* [[Statusmerkmale]]: Stammdaten befinden sich '''immer''' - Ausnahme Trainingsentwicklung Modul G1 - im '''[[Statusmerkmale|Status]] 1 ''aktiv'' .'''

* Alle Datentypen unterliegen der Zeit und haben eine '''[[Gültigkeitsinformation]]'''!
* Sie sind (grundsätzlich, insbesondere beim ersten Aufbau) mit einem einheitlichen '''Beginndatum''' (Vorschlag 01.01.2000) und in der Regel auch mit unbegrenzter Gültigkeit (Endedatum: 31.12.9999) anzulegen.

* Bowline verwendet '''nur''' die [[Planvariante]] '''01 ''aktive Planvariante'''''.
* Stammdaten können '''per [[Stammdaten-Transaktion|Transaktion]] oder [[Stammdaten-Grafik|Grafik]]''' angelegt werden
* Die '''[[Anlegetransaktionen]]''' befindensich im generel'''<nowiki/>'''len [[Strukturmanager]], konkret im [[Stammdatenmanager]] (zu erreichen über das '''[[Cockpit]]''')
'''Aufbau der Stammdaten:'''

* [[Stammdatenaufbau Modul A - Trainings- und Ressourcenmanagement]]
''Das Bowline Modul A ist das Basismodul. Alle anderen Module setzen auf den Datenobjekten dieses Moduls auf.''
* Aufbauergänzung - Trainingsentwicklung (Modul G1)
* Stammdatenaufbau Modul B - Stundenplanung
* Stammdatenaufbau Modul C - Benotung
* Stammdatenaufbau Modul D - Unterkunftsmanagement
* Stammdatenaufbau Modul E - Ausbildungsmanagement
* Stammdatenergänzung für Modul K - Kostenplanung
* Aufbauergänzung Szenarioplanung (Modul G bis einschl. 4.0)

Stammdatenaufbau

2026-05-22T12:15:01Z

Lighthouse1:

Grundlegend ist zu wissen und zu berücksichtigen, das Bowline '''[[objekt-orientiert]]''' aufgebaut ist.

Die Stammdaten bilden das Fundament und das digitale Rückgrat Ihrer Anwendungen. Sie sind die zentralen, über lange Zeit konstanten Daten, auf die die Bowline-Prozesse zugreifen – zum Beispiel Trainingsdaten, Trainingsort, Ressourceninformationen.

Eine saubere und von Anfang an '''''gut durchdacht angelegte Stammdatenbasis''''' ist der entscheidende '''''Schlüssel für effiziente Abläufe''''', fehlerfreie Transaktionen und aussagekräftige Analysen.

In den folgenden Abschnitten führen wir Sie Schritt für Schritt an die Aufgabe heran:

'''Vorab - einige grundlegende Regeln:'''

* [[Statusmerkmale]]: Stammdaten befinden sich '''immer''' - Ausnahme Trainingsentwicklung Modul G1 - im '''[[Statusmerkmale|Status]] 1 ''aktiv'' .'''

* Alle Datentypen unterliegen der Zeit und haben eine '''[[Gültigkeitsinformation]]'''!
* Sie sind (grundsätzlich, insbesondere beim ersten Aufbau) mit einem einheitlichen '''Beginndatum''' (Vorschlag 01.01.2000) und in der Regel auch mit unbegrenzter Gültigkeit (Endedatum: 31.12.9999) anzulegen.

* Bowline verwendet '''nur''' die Planvariante '''01 ''aktive Planvariante'''''.
* Stammdaten können '''per [[Stammdaten-Transaktion|Transaktion]] oder [[Stammdaten-Grafik|Grafik]]''' angelegt werden
* Die '''[[Anlegetransaktionen]]''' befindensich im generel'''<nowiki/>'''len [[Strukturmanager]], konkret im [[Stammdatenmanager]] (zu erreichen über das '''[[Cockpit]]''')
'''Aufbau der Stammdaten:'''

* [[Stammdatenaufbau Modul A - Trainings- und Ressourcenmanagement]]
''Das Bowline Modul A ist das Basismodul. Alle anderen Module setzen auf den Datenobjekten dieses Moduls auf.''
* Aufbauergänzung - Trainingsentwicklung (Modul G1)
* Stammdatenaufbau Modul B - Stundenplanung
* Stammdatenaufbau Modul C - Benotung
* Stammdatenaufbau Modul D - Unterkunftsmanagement
* Stammdatenaufbau Modul E - Ausbildungsmanagement
* Stammdatenergänzung für Modul K - Kostenplanung
* Aufbauergänzung Szenarioplanung (Modul G bis einschl. 4.0)

Stammdatenaufbau

2026-05-22T12:14:22Z

Lighthouse1:

Grundlegend ist zu wissen und zu berücksichtigen, das Bowline '''[[objekt-orientiert]]''' aufgebaut ist.

Die Stammdaten bilden das Fundament und das digitale Rückgrat Ihrer Anwendungen. Sie sind die zentralen, über lange Zeit konstanten Daten, auf die die Bowline-Prozesse zugreifen – zum Beispiel Trainingsdaten, Trainingsort, Ressourceninformationen.

Eine saubere und von Anfang an '''''gut durchdacht angelegte Stammdatenbasis''''' ist der entscheidende '''''Schlüssel für effiziente Abläufe''''', fehlerfreie Transaktionen und aussagekräftige Analysen.

In den folgenden Abschnitten führen wir Sie Schritt für Schritt an die Aufgabe heran:

'''Vorab - einige grundlegende Regeln:'''

* [[Statusmerkmale]]: Stammdaten befinden sich '''immer''' - Ausnahme Trainingsentwicklung Modul G1 - im '''[[Statusmerkmale|Status]] 1 ''aktiv'' .'''

* Alle Datentypen unterliegen der Zeit und haben eine '''[[Gültigkeitsinformation]]'''!
* Sie sind (grundsätzlich, insbesondere beim ersten Aufbau) mit einem einheitlichen '''Beginndatum''' (Vorschlag 01.01.2000) und in der Regel auch mit unbegrenzter Gültigkeit (Endedatum: 31.12.9999) anzulegen.

* Bowline verwendet '''nur''' die Planvariante '''01 ''aktive Planvariante'''''.
* Stammdaten können '''per [[Stammdaten-Transaktion|Transaktion]] oder [[Stammdaten-Grafik|Grafik]]''' angelegt werden
* Die '''[[Anlegetransaktionen]]''' befindensich im generel'''<nowiki/>'''len [[Strukturmanager]], konkret im [[Stammdatenmanager]] (zu erreichen über das '''[[Cockpit]]''')
'''Aufbau der Stammdaten:'''

* [[Stammdatenaufbau Modul A - Trainings- und Ressourcenmanagement]]
Das Bowline Modul A ist das Basismodul. Alle anderen Module setzen auf den Datenobjekten dieses Moduls auf.
* Aufbauergänzung - Trainingsentwicklung (Modul G1)
* Stammdatenaufbau Modul B - Stundenplanung
* Stammdatenaufbau Modul C - Benotung
* Stammdatenaufbau Modul D - Unterkunftsmanagement
* Stammdatenaufbau Modul E - Ausbildungsmanagement
* Stammdatenergänzung für Modul K - Kostenplanung
* Aufbauergänzung Szenarioplanung (Modul G bis einschl. 4.0)

Stammdatenaufbau

2026-05-22T12:13:22Z

Lighthouse1:

Grundlegend ist zu wissen und zu berücksichtigen, das Bowline '''[[objekt-orientiert]]''' aufgebaut ist.

Die Stammdaten bilden das Fundament und das digitale Rückgrat Ihrer Anwendungen. Sie sind die zentralen, über lange Zeit konstanten Daten, auf die die Bowline-Prozesse zugreifen – zum Beispiel Trainingsdaten, Trainingsort, Ressourceninformationen.

Eine saubere und von Anfang an '''''gut durchdacht angelegte Stammdatenbasis''''' ist der entscheidende '''''Schlüssel für effiziente Abläufe''''', fehlerfreie Transaktionen und aussagekräftige Analysen.

In den folgenden Abschnitten führen wir Sie Schritt für Schritt an die Aufgabe heran:

'''Vorab - einige grundlegende Regeln:'''

* [[Statusmerkmale]]: Stammdaten befinden sich '''immer''' - Ausnahme Trainingsentwicklung Modul G1 - im '''[[Statusmerkmale|Status]] 1 ''aktiv'' .'''

* Alle Datentypen unterliegen der Zeit und haben eine '''[[Gültigkeitsinformation]]'''!
* Sie sind (grundsätzlich, insbesondere beim ersten Aufbau) mit einem einheitlichen '''Beginndatum''' (Vorschlag 01.01.2000) und in der Regel auch mit unbegrenzter Gültigkeit (Endedatum: 31.12.9999) anzulegen.

* Bowline verwendet '''nur''' die Planvariante '''01 ''aktive Planvariante'''''.
* Stammdaten können '''per [[Stammdaten-Transaktion|Transaktion]] oder [[Stammdaten-Grafik|Grafik]]''' angelegt werden
* Die '''[[Anlegetransaktionen]]''' befindensich im generel'''<nowiki/>'''len [[Strukturmanager]], konkret im [[Stammdatenmanager]] (zu erreichen über das '''[[Cockpit]]''')
'''Aufbau der Stammdaten:'''

* [[Stammdatenaufbau Modul A - Trainings- und Ressourcenmanagement]]
Das Bowline Modul A ist das Basismodul. Alle anderen Module setzen auf den Datenobjekten dieses Moduls auf.
* Aufbauergänzung - Trainingsentwicklung (Modul G1)
* Stammdatenaufbau Modul B - Stundenplanung
* Stammdatenaufbau Modul C - Benotung
* Stammdatenaufbau Modul D - Unterkunftsmanagement
* Stammdatenaufbau Modul E - Ausbildungsmanagement
* Stammdatenergänzung für Modul K - Kostenplanung
* Aufbauergänzung Szenarioplanung (bis 4.0)

Stammdatenaufbau

2026-05-22T12:11:18Z

Lighthouse1:

Grundlegend ist zu wissen und zu berücksichtigen, das Bowline '''[[objekt-orientiert]]''' aufgebaut ist.

Die Stammdaten bilden das Fundament und das digitale Rückgrat Ihrer Anwendungen. Sie sind die zentralen, über lange Zeit konstanten Daten, auf die die Bowline-Prozesse zugreifen – zum Beispiel Trainingsdaten, Trainingsort, Ressourceninformationen.

Eine saubere und von Anfang an '''''gut durchdacht angelegte Stammdatenbasis''''' ist der entscheidende '''''Schlüssel für effiziente Abläufe''''', fehlerfreie Transaktionen und aussagekräftige Analysen.

In den folgenden Abschnitten führen wir Sie Schritt für Schritt an die Aufgabe heran:

'''Vorab - einige grundlegende Regeln:'''

* [[Statusmerkmale]]: Stammdaten befinden sich '''immer''' - Ausnahme Trainingsentwicklung Modul G1 - im '''[[Statusmerkmale|Status]] 1 ''aktiv'' .'''

* Alle Datentypen unterliegen der Zeit und haben eine '''[[Gültigkeitsinformation]]'''!
* Sie sind (grundsätzlich, insbesondere beim ersten Aufbau) mit einem einheitlichen '''Beginndatum''' (Vorschlag 01.01.2000) und in der Regel auch mit unbegrenzter Gültigkeit (Endedatum: 31.12.9999) anzulegen.

* Bowline verwendet '''nur''' die Planvariante '''01 ''aktive Planvariante'''''.
* Stammdaten können '''per [[Stammdaten-Transaktion|Transaktion]] oder [[Stammdaten-Grafik|Grafik]]''' angelegt werden
* Die '''[[Anlegetransaktionen]]''' befindensich im generel'''<nowiki/>'''len [[Strukturmanager]], konkret im [[Stammdatenmanager]] (zu erreichen über das '''[[Cockpit]]''')
'''Aufbau der Stammdaten:'''

* [[Stammdatenaufbau Modul A - Trainings- und Ressourcenmanagement]]
Das Bowline Modul A ist das Basismodul. Alle anderen Module setzen auf den Datenobjekten dieses Moduls auf.
* Aufbauergänzung - Trainingsentwicklung
* Muster / Transaktion und Modul G1
* Stammdatenaufbau Modul B - Stundenplanung
* Stammdatenaufbau Modul C - Benotung
* Stammdatenaufbau Modul D - Unterkunftsmanagement
* Stammdatenaufbau Modul E - Ausbildungsmanagement
* Stammdatenergänzung für Modul K - Kostenplanung
* Aufbauergänzung Szenarioplanung (bis 4.0)

Stammdatenaufbau

2026-05-22T12:08:49Z

Lighthouse1:

Grundlegend ist zu wissen und zu berücksichtigen, das Bowline '''[[objekt-orientiert]]''' aufgebaut ist.

Die Stammdaten bilden das Fundament und das digitale Rückgrat Ihrer Anwendungen. Sie sind die zentralen, über lange Zeit konstanten Daten, auf die die Bowline-Prozesse zugreifen – zum Beispiel Trainingsdaten, Trainingsort, Ressourceninformationen.

Eine saubere und von Anfang an '''''gut durchdacht angelegte Stammdatenbasis''''' ist der entscheidende '''''Schlüssel für effiziente Abläufe''''', fehlerfreie Transaktionen und aussagekräftige Analysen.

In den folgenden Abschnitten führen wir Sie Schritt für Schritt an die Aufgabe heran:

'''Vorab - einige grundlegende Regeln:'''

* [[Statusmerkmale]]: Stammdaten befinden sich '''immer''' - Ausnahme Trainingsentwicklung Modul G1 - im '''[[Statusmerkmale|Status]] 1 ''aktiv'' .'''

* Alle Datentypen unterliegen der Zeit und haben eine '''[[Gültigkeitsinformation]]'''!
* Sie sind (grundsätzlich, insbesondere beim ersten Aufbau) mit einem einheitlichen '''Beginndatum''' (Vorschlag 01.01.2000) und in der Regel auch mit unbegrenzter Gültigkeit (Endedatum: 31.12.9999) anzulegen.

* Bowline verwendet '''nur''' die Planvariante '''01 ''aktive Planvariante'''''.
* Stammdaten können '''per [[Stammdaten-Transaktion|Transaktion]] oder [[Stammdaten-Grafik|Grafik]]''' angelegt werden
* Die '''[[Anlegetransaktionen]]''' befindensich im generel'''<nowiki/>'''len Strukturmanager, konkret im Stammdatenmanager (zu erreichen über das '''[[Cockpit]]''')
'''Aufbau der Stammdaten:'''

* [[Stammdatenaufbau Modul A - Trainings- und Ressourcenmanagement]]
Das Bowline Modul A ist das Basismodul. Alle anderen Module setzen auf den Datenobjekten dieses Moduls auf.
* Aufbauergänzung - Trainingsentwicklung
* Muster / Transaktion und Modul G1
* Stammdatenaufbau Modul B - Stundenplanung
* Stammdatenaufbau Modul C - Benotung
* Stammdatenaufbau Modul D - Unterkunftsmanagement
* Stammdatenaufbau Modul E - Ausbildungsmanagement
* Stammdatenergänzung für Modul K - Kostenplanung
* Aufbauergänzung Szenarioplanung (bis 4.0)

Auskunftsmanager

2026-05-22T12:06:12Z

Lighthouse1: Die Seite wurde neu angelegt: „Der '''''Auskunftsmanager''''' ist ab 4.0 der zentrale Zugang für alle Bowline®-Reports, Auswertungen, Listen und Statistiken. Auswertungen werden (mit wenigen Ausnahmen) immer für '''''Vergangenheitszeiträume''''' angeboten. Endedatum ist somit das Tagesdatum, das Beginndatum liegt in der Vergangenheit. 902x902px“

Der '''''Auskunftsmanager''''' ist ab 4.0 der zentrale Zugang für alle Bowline®-Reports, Auswertungen, Listen und Statistiken.

Auswertungen werden (mit wenigen Ausnahmen) immer für '''''Vergangenheitszeiträume''''' angeboten. Endedatum ist somit das Tagesdatum, das Beginndatum liegt in der Vergangenheit.
[[Datei:Auskunftsmanager.png|mini|902x902px]]

Datei:Auskunftsmanager.png

2026-05-22T12:05:49Z

Lighthouse1:

Screen

Akuter Ressourcenausfall

2026-05-22T12:04:29Z

Lighthouse1: Die Seite wurde neu angelegt: „Über den Punkt '''''Akuter Ressourcenausfall''''' wird auf solche Trainingstermine aufmerksam gemacht, die bereits stattfinden (ausgehend vom Tagesdatum) und bei denen sogenannte Hauptressourcen, also Räume oder Referenten, ausgefallen oder noch nicht vorhanden sind und dringend bearbeitet werden sollten. 902x902px“

Über den Punkt '''''Akuter Ressourcenausfall''''' wird auf solche Trainingstermine aufmerksam gemacht, die bereits stattfinden (ausgehend vom Tagesdatum) und bei denen sogenannte Hauptressourcen, also Räume oder Referenten, ausgefallen oder noch nicht vorhanden sind und dringend bearbeitet werden sollten.
[[Datei:Ressourcenausfall.png|mini|902x902px]]

Datei:Ressourcenausfall.png

2026-05-22T12:04:03Z

Lighthouse1:

Screen

Aktionen und Termine

2026-05-22T12:02:55Z

Lighthouse1: Die Seite wurde neu angelegt: „Hier finden sich Arbeitsvorfälle, die der Aufmerksamkeit des Sachbearbeiters (im Zeitraum) bedürfen, immer ausgehend vom Tagesdatum. Wird dieser Menüpunkt in ROT dargestellt, liegt ein Handlungsbedarf vor. 905x905px“

Hier finden sich Arbeitsvorfälle, die der Aufmerksamkeit des Sachbearbeiters (im Zeitraum) bedürfen, immer ausgehend vom Tagesdatum.

Wird dieser Menüpunkt in ROT dargestellt, liegt ein Handlungsbedarf vor.
[[Datei:Aktionen.png|mini|905x905px]]

Datei:Aktionen.png

2026-05-22T12:01:18Z

Lighthouse1:

Screen

Cockpit

2026-05-22T12:00:01Z

Lighthouse1:

== Cockpit – Planen und Verwalten ==
Zentraler Einstieg für Bowline ist ab Release 4.0 das '''''Cockpit.''''' Diese neue Transaktion führt alle themenspezifischen und allgemeinen [[Strukturmanager]] zusammen.
[[Datei:Cockpit-Screen.png|mini|925x925px]]

Im oberen Teil finden sich die Absprünge in die einzelnen Strukturmanager, z.Zt. sind dies

* der generelle Strukturmananger, sowie
* der [[Teilnahmemanager]] mit [[Benotung]], und
* der [[Unterkunftsmanager]] mit Verpflegung.

Im mittleren Teil finden sich

* [[Aktionen und Termine]] und
* [[Akuter Ressourcenausfall]]

Und im unteren Teil findet sich der

* [[Auskunftsmanager]]

Cockpit

2026-05-22T11:58:41Z

Lighthouse1: Die Seite wurde neu angelegt: „== Cockpit – Planen und Verwalten == Zentraler Einstieg für Bowline ist ab Release 4.0 das '''''Cockpit.''''' Diese neue Transaktion führt alle themenspezifischen und allgemeinen Strukturmanager zusammen. 925x925px Im oberen Teil finden sich die Absprünge in die einzelnen Strukturmanager, z.Zt. sind dies * der generelle Strukturmananger, sowie * der Teilnahmemanager mit Benotung, und * der Unterkunf…“

== Cockpit – Planen und Verwalten ==
Zentraler Einstieg für Bowline ist ab Release 4.0 das '''''Cockpit.''''' Diese neue Transaktion führt alle themenspezifischen und allgemeinen [[Strukturmanager]] zusammen.
[[Datei:Cockpit-Screen.png|mini|925x925px]]

Im oberen Teil finden sich die Absprünge in die einzelnen Strukturmanager, z.Zt. sind dies

* der generelle Strukturmananger, sowie
* der [[Teilnahmemanager]] mit [[Benotung]], und
* der [[Unterkunftsmanager]] mit Verpflegung.

Im mittleren Teil finden sich

* [[Aktionen und Termine]] und
* Akuter Ressourcenausfall

Und im unteren Teil findet sich der

* [[Auskunftsmanager]]

Datei:Cockpit-Screen.png

2026-05-22T11:51:39Z

Lighthouse1:

Bildschirmbild