Blockierende und nicht-blockierende Zuständigkeit

Zur Erläuterung von Zuständigkeiten und somit der Teilnahmeberechtigung und Sichtbarkeit von processes.name_pluraln im productNameAbbr werden im Folgenden zunächst die Grundbegriffe erneut kurz erklärt, um anschließend die zugrundeliegenden Mechaniken der Zuständigkeiten zu erläutern.

Grundlegendes und Hintergrundinformationen

Prozesse / processes.abbren

Das productNameAbbr bildet verschiedene Prozesse des Bedarfsmanagement standardmäßig über folgende processes.abbren ab:

Abfragen:

• Erhebung/Ermittlung von konsolidierten Bedarfen (als Beschaffungsstelle/Beschaffer) und gesammelten Antworten zu Fragenkatalogen von Bedarfsträgern
• Beispiel: Bedarfserhebung (BE)

Sub-Abfragen:

• Durchführung einer Abfrage zu einer übergeordneten (Sub-) Abfrage in einem kleineren Kontext (innerhalb einer Organisation und ggf. unter Einbeziehung untergeordneter/nachgelagerter Organisationen)
• Sub-Abfragen basieren stets auf einer bestehenden (Sub-)Abfrage. Sub-Abfragen können von anderen, bereits erstellten Sub-Abfragen abgeleitet werden.
• Der Inhalt der Sub-Abfrage wird durch die übergeordnete (Sub-)Abfrage bestimmt und kann nicht verändert werden, damit die erhobenen Bedarfe auch über alle Ebene hinweg zusammengefasst/aggregiert und konsolidiert werden können
• Beispiel: Teilbedarfserhebung (TBE)

Teilnahmen:

• Teilnahme an Abfragen bzw. Sub-Abfragen (als Bedarfsträger/Bedarfsmelder) zur Meldung von Mengen zu abgefragten Bedarfen bzw. Beantwortung von Fragen aus Fragenkatalogen an Beschaffungsstellen im Kontext von deren Abfragen
• Beispiel: Bedarfsrückmeldung (BRM)

Meldungen:

• (pro-)aktive Eigenmeldung (als Bedarfsträger/Bedarfsmelder) von Bedarfen an Beschaffungsstellen ohne den Kontext einer Abfrage einer Beschaffungsstelle
• Beispiel: processes.BM.label (processes.BM.abbr)

processes.VV.plural:

• Vorbereitung einer Vergabe/Ausschreibung von aufbereiteten Bedarfen (erhoben/konsolidiert/gemeldet/abgeleitet) durch Beschaffungsstellen/Beschaffer
• Die aufbereiteten Bedarfe werden dabei im Rahmen processes.VV.label_genitivevorbereitung bzw. des darin vorbereiteten Leistungsverzeichnisse gebündelt
• Beispiel: Vergabevorbereitung/processes.VV.label (processes.VV.abbr)

Hierarchische Organisationsstruktur (Orga-Baum)

Organisationsstrukturen der Zusammenarbeit lassen sich im productNameAbbr durch nachfolgend beschriebene Organisationsknoten als Teil einer Organisations-Hierarchie („Baumstruktur“) abbilden. Eine Organisationsstruktur (OSr) nutzt verschiedene Instanzen, die in festen Abhängigkeiten voneinander stehen. Diese Organisationsstruktur bildet die Basis für die Bearbeitung von Prozessen im productNameAbbr bis Version 8.0. Eine Organisationsstruktur hat folgende Bestandteile:

Organisationsgruppe (OGr):

• dienen lediglich der Gruppierung von Organisationen und werden aktuell verwendet für das Setzen übergreifender Zuständigkeiten bzw. das Deaktivieren/Aktivieren ganzer Teilbäume der OSr
• Wird eine OGr deaktiviert, so werden alle untergeordneten Organisationen deaktiviert.
• sind direkt dem Wurzelknoten zugeordnet und können nicht weiter in untergeordnete OGrs verschachtelt werden.
• der übergeordnete Wurzelknoten der OSr ist eine spezielle Gruppe, die immer da ist und das System bzw. den globalen Kontext (z. B. für Zuständigkeiten) repräsentiert
• Beispiele: orgGroup_plural, Ministerien, Verbände, Regionen

Organisation (Org):

• können beliebig tief in weitere Orgs verschachtelt werden, um über- und untergeordnete bzw. vor- und nachgelagerte Organisationen in hierarchischen Organisationsstrukturen und zugehörigen Prozessen zu repräsentieren (z. B. mehrstufige Abfragen oder Meldeketten)
• enthalten bzw. dienen der Gruppierung von oeen (OE)
• Nutzer müssen genau einer Org zugeordnet und können nur für diese und deren OE (1..n) aktiv werden
• explizit für eine Org selbst können nur Nutzer mit der Rolle Admin aktiv werden (Nutzer hinzufügen/anpassen, Zuständigkeiten setzen, OE pflegen, u. ä.)
• Beispiele: org_plural, Niederlassungen, Ämter, Firmen

oe (OE):

• können nicht weiter verschachtelt werden und gehören zu genau einer Org
• OE bilden die eigentlich durchführenden Instanzen der OSr. Sie führen Prozesse und processes.name_plural aktiv aus. OE stellen somit die verantwortlichen Instanzen dar, durch welche processes.name_plural bearbeitet werden.
• Prozesse/processes.name_plural laufen immer „für“ bzw. „im Namen“ eine(r) OE ab
• processes.name_plural müssen dabei auf Beschaffer- und/oder Bedarfsträgerseite immer einer OE zugewiesen sein, die für den processes.name auf der jeweiligen Seite verantwortlich ist.
• Ausnahmen:
  • Bei Abfragen und processes.VV.plural gibt es keine verantwortliche OE auf Bedarfsträgerseite. Hier liegt der processes.name allein auf der Beschafferseite.
  • Bei Teilnahmen gibt es keine verantwortliche OE auf Beschaffungsstellenseite, sondern nur auf der Bedarfsträgerseite.
• processes.name_plural können nur durch den aktuellen Bearbeiter, also ein konkreter zugeordneter Nutzer, auf Beschaffungsstellen- bzw. Bedarfsträgerseite bearbeitet (d. h. inhaltlich verändert oder im processes.namesstatus verändert) werden, sofern dies im jeweils aktuellen Status des processes.names möglich ist.
• Abfragen und processes.VV.plural können nur durch Beschaffer bearbeitet werden.
• Teilnahmen können direkt nur durch Bedarfsmelder bearbeitet werden. Es gibt allerdings eine indirekte Bearbeitungsmöglichkeit durch Beschaffer über den Kontext der Abfrage, zu der die Teilnahme gehört.
• Beispiele für OE: form.contactPersonDepartmente, Abteilungen, Teams, (zentrale/dezentrale) Beschaffungsstellen, Torwächter/Gatekeeper/Prüfstellen

Zuständigkeiten: (Sub-)Abfrage anlegen/veröffentlichen, Meldung empfangen/bearbeiten

Zuständigkeiten basieren auf Produktgruppen/-kategorien (PK) und beziehen sich immer auf die verschiedenen Prozesse/processes.abbren. Produktkategorien werden im productNameAbbr als Zahlen bzw. Zahlenfolgen abgebildet. Als ausführende Instanz sind stets OE für Prozesse und processes.name_plural zuständig. Zuständig ist eine OE dabei zudem für einen bestimmten Teil der Organisationsstruktur (repräsentiert durch den Organisationsknoten der OSr für den / auf dem die Zuständigkeit der OE gesetzt ist). Die Zuständigkeit gilt dabei immer ab dem Knoten/der Ebene der OSr, auf dem sie gesetzt ist und für alle nachgelagerten/untergeordneten Bereiche der hierarchischen OSr (vgl. Hierarchische Organisationsstruktur (Orga-Baum)).

Sobald eine OE eine Zuständigkeit in der OSr übernimmt, wird sie im productNameAbbr automatisch als „Beschaffungsstelle“ gekennzeichnet. Eine Zuständigkeit definiert sich demnach aus dem Zusammenspiel von insgesamt vier Faktoren: B x V x PK x K

B: der zuständigen OE (also „Beschaffungsstelle“)

• Zuständigkeiten können für alle OE, auf die ein Admin schreibenden Zugriff hat, eingestellt werden.

V: dem processes.abbr, für die die OE dabei zuständig sein soll

• Zuständigkeiten können nicht für alle processes.abbren eingestellt werden. (Erläuterung zum processes.abbr werden nachfolgend beschrieben.)

PK: die Produktkategorie, für die die OE zuständig sein soll

• Eine OE kann im Rahmen einer Zuständigkeit für mehrere PK gleichzeitig zuständig sein.
• Auf einer Ebene der OSr können ebenso mehrere OE für dieselbe PK zuständig sein (also Mehrfachzuständigkeiten). Die Zuständigkeiten werden dabei nicht überschrieben, sondern gelten gleichzeitig.

K: dem Knoten bzw. der Ebene der OSr, für die die OE dabei zuständig sein soll

• Zuständigkeiten können grundsätzlich auf jedem/r Knoten/Ebene der Organisationsstruktur eingestellt werden (bis productNameAbbr 8.0 wird die Ebene der OE noch nicht unterstützt, d. h. Zuständigkeiten können als max. bis auf Ebene von Org eingestellt werden).
• Abhängig vom processes.abbr gelten noch weitere fachliche Einschränkungen (insbesondere für blockierende Zuständigkeiten), auf welchen Ebenen welche Zuständigkeiten eingestellt werden können (vgl. nachfolgend).

Zuständigkeiten können nur für folgende processes.abbren (V) eingestellt werden:

Abfragen: ermöglicht der zuständigen OE

• das Durchführen eigener Abfragen in den Teilen der gesamten OSr, in denen sie zuständig ist und
• das Blockieren übergeordneter Abfragen in ihrem Teilbaum der OSr (um für ihren Teilbaum zu entscheiden, ob und wie dieser an einer übergeordneten Abfrage teilnehmen soll).

Sub-Abfragen: ermöglicht der zuständigen OE

• das Durchführen von eigenen Sub-Abfragen in ihrem Teilbaum der OSr und
• das Blockieren übergeordneter Sub-Abfragen in ihrem Teilbaum der OSr (um für ihren Teilbaum zu entscheiden, ob und wie dieser an einer übergeordneten Sub-Abfrage teilnehmen soll).

Meldungen: ermöglicht der zuständigen OE

• das Empfangen von Meldungen aus den Teilen der gesamten OSr, wo sie zuständig ist und
• das Blockieren von Meldungen aus ihrem Teilbaum (um zu entscheiden, ob und an welche nächste zuständige OE die Meldung weitergegeben wird).

Für Teilnahmen und processes.VV.plural gibt es keine expliziten Zuständigkeiten in der OSr:

processes.VV.plural:

• können durch jede OE und Nutzer darin mit der Rolle „Beschaffer“ im productNameAbbr vorbereitet/durchgeführt werden.

Teilnahmen:

• die Möglichkeit zur Teilnahme („Teilnahmeberechtigung“) ergibt sich ausschließlich aus den Zuständigkeiten innerhalb der OSr von OE für Abfragen und Sub-Abfragen im “Einzugsbereich der teilnehmenden OE“.
• Erreicht eine Abfrage oder Sub-Abfrage einen bestimmten Bereich der OSr, sind grundsätzlich alle OE dieses Bereichs auch zur Teilnahme an der Abfrage bzw. Sub-Abfrage berechtigt (vgl. nachfolgend)
• Einschränkung 1: bei blockierenden Zuständigkeiten sind nur die blockierenden OE selbst zur Teilnahme und Durchführung einer zugehörigen Sub-Abfrage berechtigt
• Einschränkung 2: bei beschränkten Abfragen und Sub-Abfragen sind nur die eingeladenen OE teilnahmeberechtigt – welche OE dabei eingeladen werden können, ergibt sich wiederum aus der innerhalb der OSr gesetzten Zuständigkeiten für den Abfrage- bzw. Sub-Abfrage-processes.targetProcess.filterIndicatorLabel (auf die gleiche Weise wie für unbeschränkte (Sub-)Abfragen).

Bzgl. der Ebene der OSr für die eine Zuständigkeit gilt, gibt es weiterhin noch folgende Einschränkungen:

Abfragen:

• blockierend zuständig kann eine OE nur für ihre eigene Org sein (da sie dann stellvertretend für ihre eigene Org bzw. den Teilbaum ihrer Org innerhalb der OSr an Abfragen teilnehmen kann – vgl. nachfolgend)

Sub-Abfragen

• blockierend zuständig kann eine OE nur für ihre eigene Org sein (da sie dadurch für ihre eigene Org bzw. den Teilbaum ihrer Org innerhalb der OSr eine Sub-Abfrage zu einer übergeordneten (Sub-)Abfrage durchführen kann – vgl. nachfolgend)

Aus Zuständigkeiten abgeleitete Teilnahmeberechtigungen für (Sub-)Abfragen | Meldeberechtigungen für Meldungen

Die Berechtigung zur Teilnahme an (Sub-)Abfragen („Teilnahmeberechtigung“) und die Berechtigung zur Abgabe von Meldungen („Meldeberechtigung“) werden nicht explizit konfiguriert, sondern ergeben sich implizit aus den Zuständigkeiten innerhalb der OSr wie folgt:

Teilnahmen:

• Die Teilnahmeberechtigung bzgl. (Sub-)Abfrage-processes.targetProcess.filterIndicatorLabelen bezieht sich immer auf OE und nicht auf einzelne Bedarfsmelder oder ganze Org.
• Ein Bedarfsmelder kann für mehrere OE eine Teilnahme zu ein- und derselben (Sub-)Abfrage anlegen/abgeben, solange er aktiv für diese OE als Bedarfsmelder agieren kann.
• Pro OE ist max. eine Teilnahme pro (Sub-)Abfrage erlaubt.
• Die Möglichkeit zur Teilnahme einer OE an einer (Sub-)Abfrage leitet sich aus den gesetzten Zuständigkeiten innerhalb der OSr ab und dabei, ob die (Sub-)Abfrage auf deren Grundlage, die OE “erreicht“ oder nicht (Details vgl. nachfolgend).

Meldungen:

• Die Meldeberechtigung bzgl. Meldetypen bezieht sich immer auf OE und nicht auf einzelne Bedarfsmelder oder ganze Org.

• Ein Bedarfsmelder kann für alle OE eine Meldung abgeben, für die er aktiv für diese OE als Bedarfsmelder agieren kann.

• Pro OE ist sind beliebig viele Einzelmeldungen erlaubt (da es keinen einschränkenden Kontext einer Abfrage gibt).

• Die Möglichkeit der Abgabe einer Meldung durch eine OE leitet sich aus den gesetzten Zuständigkeiten innerhalb der OSr ab.

• Gibt es eine zuständige OE innerhalb der OSr in einer übergeordneten Ebene der meldenden OE (beginnend bei deren Org), ist die meldende OE damit implizit zum initialen „Abgeben“ einer Meldung an diese zuständige OE berechtigt.

• Ausgehend von der OE, bei der die Meldung dann auf Grund ihrer Zuständigkeit eingegangen ist, kann diese die Meldung dann nach demselben Prinzip an eine weitere zuständige OE in übergeordneten Ebenen der OSr „weiterleiten“.

Blockierende und nicht-blockierende Zuständigkeiten

Zuständigkeiten entscheiden darüber welche Prozesse von Nutzern gesehen und durchgeführt werden können. Im productNameAbbr werden Zuständigkeiten über Produktkategorien (PK) und die Organisationsstruktur (OSr) abgebildet (vgl. oben). Die Zuständigkeiten werden dabei als Zahlen in der Organisationsstruktur angezeigt und verweisen jeweils auf die durch die Zuständigkeiten bzgl. Produkte und Dienstleistung aus den über die Zuständigkeiten betreuten Produktgruppen. Jedem processes.name ist im productNameAbbr dafür stets eine betreuende OE und eine Produktkategorie zugeordnet. Diese Zuordnung entscheidet darüber welche OE(n) mit dem processes.name und der zugehörigen Zuständigkeit erreicht werden. Um einen processes.name im productNameAbbr zu veröffentlichen, muss diesem daher sowohl eine betreuende OE als auch die maßgebliche Produktgruppe des processes.names, die den Inhalt des processes.names repräsentiert, zugeordnet sein. Zudem muss es für die gesetzte Kombination aus OE und PK eine zugehörige Zuständigkeit geben (vgl. oben), so dass die betroffenen Ziel-OE(n) des processes.names vom System ermittelt werden können.

Abfragen

Beim Veröffentlichen von Abfragen besteht die Möglichkeit, offene oder beschränkte Abfragen zu unterscheiden. Beschränkte Abfragen ermöglichen ein zielgenaues Anspreche bestimmter, zuständiger OE(n). Diese werden ausgewählt und anschließend wird die Abfrage nur an diese OE(n) veröffentlicht. Offene Abfragen hingegen funktionieren nach dem zugrundeliegenden Prinzip der Zuständigkeiten (vgl. oben) in Kombination mit blockierenden und nicht-blockierenden Varianten. Im Folgenden wird mit einer exemplarischen OSr das Grundprinzip hinter blockierenden und nicht-blockierenden Zuständigkeiten erläutert. Zur nachfolgenden Erläuterung der Grundprinzipien wird eine vereinfachte Abstraktion des Orga-Baums genutzt. In den lila-farben Hexagons finden sich die Produktkategorien der jeweiligen Zuständigkeiten auf den unterschiedlichen Ebenen/Knoten der Organisationsstruktur. Ein weiß hinterlegtes Hexagon bedeutet „nicht-blockierend“ während ein schwarz-gefülltes Hexagon eine blockierende Zuständigkeit darstellt. Die OSr wird an den zu erläuternden Fall angepasst, um das Verhalten im productNameAbbr bestmöglich zu illustrieren. Es wird immer stets nur ein Ausschnitt der kompletten OSr gezeigt, um einen konkreten Fall zu beleuchten und zu fokussieren. Es wird stets davon ausgegangen, dass die veröffentlichende OE im Bereich des Beispiels liegt und so die Beispiel Orgs und OEn potenziell erreichen kann.

Wie funktionieren offene Abfragen?

Offene Abfragen werden nicht explizit an einzelne, bestimmte OE(n) veröffentlicht. Die Sichtbarkeit der Abfragen für teilnahmeberechtigte/adressierte OE(n) (inkl. der Möglichkeit zur Teilnahme oder Durchführung von Sub-Abfragen) werden über die Organisationsstruktur und darin gesetzten Zuständigkeiten entschieden. Grundsätzlich kann man den Prozess der offenen Abfrage von oben nach unten visualisieren. Die Prüfung von Zuständigkeiten funktioniert dabei vom jeweiligen Organisationsknoten ausgehend nach unten (d. h. vererbend). An jeder Aufsplittung innerhalb der OSr, also immer dann, wenn sich die OSr in weitere untergeordnete Organisationknoten (Org oder OE(n)) aufspaltet, wird anhand der gesetzten blockierenden und nicht-blockierenden Zuständigkeiten ermittelt, welche OE(n) Zugang zu einer Abfrage erhalten und im Rahmen dieser Entscheidungen treffen darf (z. B. ob an der Abfrage teilgenommen werden soll oder vorher eine Teil-Abfrage im Kontext der teilnehmende Org erfolgen soll), bevor die nächste Instanz nach dem gleichen Prinzip weiter agieren kann.

Nicht-Blockierende Zuständigkeiten bei Abfragen

Wir gehen für ein fiktives Beispiel von gesetzten nicht-blockierenden Zuständigkeiten in der Organisationsstruktur für Abfragen aus (vgl. Abb. weiß hinterlegtes Hexagon). Im System wäre dies durch weiße Produktkategorien angezeigt. Die jeweilige Zahl bedeutet eine nicht-blockierende Zuständigkeit in genau dieser Produktkategorie. Wir befinden uns innerhalb einer Organisation, die durch die Zuständigkeit einer erhebenden OE für ihre Abfrage erreicht wird. processes.VV.new Abfragen starten ab Veröffentlichung bei den Organisationsknoten der OSr, auf denen die erhebende OE eine direkte Zuständigkeit für die PK der Abfrage hat. Als Org besitzen wir mehrere OEn, die uns zugeordnet sind. Ob und welche OEn nun auf die Abfrage antworten können, hängt davon ab, welche Zuständigkeiten für uns als Organisation wirksam sind (in dem sie direkt auf der Org oder einem der übergeordneten Organistionsknoten gesetzt sind).

Offene Abfragen

Alle bzgl. der teilnehmenden Org so wirksamen Zuständigkeiten (direkt oder veerbend) gelten auch für deren enthaltene OE(n) (auch für neu eingeführte), d. h. all unsere OE(n) können die Abfrage sehen und an ihr teilnehmen (d. h. haben eine Teilnahmeberechtigung). Diese Übersetzung der Zuständigkeiten erhebender OE(n) (also Beschaffungsstellen) auf die Möglichkeit von OE(n) die Abfrage zu sehen und an ihr (als Bedarfsträger) teilzunehmen, wird im Folgenden Teilnahmeberechtigung genannt.

Beschränkte Abfragen

Beim Veröffentlichen von Abfragen kann der erhebende Beschaffer einer OE noch entscheiden, ob die Abfrage nicht offen (d. h. beschränkt) innerhalb der OSr über die gesetzten Zuständigkeiten der abfragenden OE für die gesetzte PK der Abfrage “gestreut“ werden soll oder ob die Abfrage dabei nur einem beschränkten Empfängerkreis von OE(n) zur Verfügung gestellt werden soll. Welche OE(n) für eine beschränkte Abfrage hierbei zur Verfügung stehen, ergeben sich aus der PK für die Abfrage sowie den entsprechenden Zuständigkeiten in der OSr. Nur diese teilnahmeberechtigten OE(n) können dann die Abfrage sehen und an ihr teilnehmen. OE(n), die nicht explizit eingeladen wurden, sehen die Abfrage also nicht und können deshalb auch nicht an ihr teilnehmen.

Auswertung von Abfragen

Innerhalb einer Abfrage werden alle Teilnahmen gesammelt, die enthaltenen Antworten zu Fragen des abgefragten Fragenkatalogs gesammelt und die gemeldeten Mengen zu abgefragten Bedarfen zusammengefasst (Summen) und dem Beschaffer in der Auswertung zusätzlich noch die Möglichkeit gegeben, diese Summen noch weiter durch Pauschalen (Aufschläge/Abschläge) zu „konsolidieren“.

Beispiel offene Abfrage

Eine zuständige OE veröffentlicht in der OSr eine offene Abfrage in der PK 2. Da eine offene Abfrage vorliegt, werden damit alle Org erreicht, die eine Zuständigkeit für PK 2 besitzen. Die enthaltenen OE(n) der jeweiligen Org müssen für die Teilnahme an Abfragen berechtigt sein. Org Ahorn und Org Linde sind im Beispiel beide Teil der OSr, für die die abfragende OE Zuständigkeit besitzt.

1. Org Ahorn wird von der Abfrage-OE über ihre entsprechenden Zuständigkeiten für PK 2 innerhalb der OSr nicht erreicht und alle ihre enthalten OEn haben damit implizit keine Teilnahmeberechtigung für die Abfrage (nur Abfragen mit der PK 1 erreichen diese Org bzw. ihre enthaltenen OE(n)). Durch die fehlende Teilnahmeberechtigung ist die Abfrage damit für keine OE der Org Ahorn sichtbar. Ebenso ist keine der OE(n) berechtigt eine Teilnahme für die Abfrage anzulegen und abzugeben.

2. Für die Org Linde gibt es eine Zuständigkeit für die PK 2. Dadurch wird diese Org und ihre beiden enthaltenen OEn Linde A und Linde B auch von der Abfrage-OE mit ihrer Abfrage erreicht. Da es keine blockierenden Zuständigkeiten für die Org Linde gibt, sind auch beide OEn teilnahmeberechtigt und können die Abfrage sowohl sehen als auch an ihr teilnehmen. Damit es keine aufzuklärenden/aufzulösenden Doppelmeldungen im Kontext von offenen bzw. nicht-beschränkten Abfragen gibt, wird nur eine Teilnahme pro Org erlaubt. Das System verhindert dementsprechend das Anlegen von mehreren Teilnahmen zu offenen Abfragen innerhalb einer Org und verweist ggf. das Vorhandensein einer bereits angelegten oder schon abgegebenen Teilnahme für Nutzer teilnahmeberechtigter OEn (inkl. Hinweis auf die processes.number und die OE der Teilnahme). Im Falle einer beschränkten Abfrage wären alle eingeladenen OEn teilnahmeberechtigt und es findet keine Einschränkung bzgl. der Anzahl an Teilnahmen pro Org systemseitig statt. Ausnahme: pro OE darf es immer nur maximal eine Teilnahme geben, die an die abfragende Stelle abgegeben werden kann. In diesem konkreten Fall bedeutet das, falls OE Linde A bereits teilgenommen hat, kann OE Linde B nicht mehr teilnehmen und erhält nur den eben erwähnten Hinweis.

Dieses grundlegende Prinzip wird für jeden Orga-Knoten in der OSr angewendet. Startpunkt für Abfragen sind die Orga-Knoten in der OSr, auf denen die abfragende OE eine Zuständigkeit für den Abfragetyp und die Produktkategorie der Abfrage hat. Für alle diese und ihnen nachgelagerte Orga-Knoten ist die Abfrage dann sichtbar, sodass alle aktiven Nutzer von OEn, die auf diese Weise durch die abfragende OE über ihre Zuständigkeiten innerhalb der OSr erreicht werden, (unabhängig davon wie tief sich die OSr verschachtelt) die Abfrage sehen und an ihr teilnehmen können.

Ohne Beteiligung von blockierenden Zuständigkeiten werden die Abfragen dabei wie eben beschrieben von oben nach unten bis zur letzten teilnahmeberechtigten OE gleichzeitig sichtbar gemacht. Jede dadurch erreichte OE ist dabei auch gleichwertig zur Teilnahme an der Abfrage berechtigt. Für offene Abfragen wird dabei wie oben beschrieben sichergestellt, dass es pro Org nur eine OE mit einer Teilnahme zu der Abfrage gibt.

Für beschränkte Abfragen kann der veröffentlichende Beschaffer entscheiden, die Abfrage ausgehend von den erreichbaren teilnahmeberechtigten OEn (potenzielle Teilnehmer-OE(n)) auf eine bestimmte Untermenge von potenziellen Teilnehmer-OEn zu beschränken. Nur diese OEn sind dann nach Veröffentlichung der Abfrage an dieser teilnahmeberechtigt (d. h. können die Abfrage sehen und an ihr teilnehmen). Im Kontext beschränkter Abfragen darf es mehrere Teilnahmen pro Org geben (da es hier keine Gefahr der versehentlichen Doppelmeldung gibt, da die OEn explizit durch den Beschaffer adressiert wurden). Hier findet also keine systemseitige Prüfung und Beschränkung der Anzahl von Teilnahmen pro Org statt. Es gilt aber weiterhin die grundsätzliche Beschränkung von max. einer Teilnahme pro OE und Abfrage. Dieses Prinzip der aus Zuständigkeiten übersetzten Teilnahmeberechtigungen (Berechtigung zur Ansicht und Teilnahme bzgl. Abfragen) ändert sich im Fall der Existenz von blockierenden Zuständigkeiten.

Blockierende Zuständigkeiten

Der oben beschriebene Abfrageprozess (offen und beschränkt) ohne Involvierung blockierender Zuständigkeiten (d. h. nur unter Beteiligung von nicht-blockierenden Zuständigkeiten) arbeitet komplett ohne Entscheidungen auf einer der betroffenen Ebenen der OSr, da allein nach der Zuordnung der Zuständigkeiten entschieden wird, wer Zugriff auf die Abfrage erhält. Befinden sich in dieser Abfrage-Hierarchie jeodoch blockierende Zuständigkeiten, ändert sich dies.

Blockierende Zuständigkeiten kann man sich wie Checkpoints vorstellen, an denen manuell entschieden wird, wie mit der Abfrage weiter verfahren werden soll. Dieser processes.name läuft also nicht voll-automatisch ab, sondern erfordert das manuelle Eingreifen von Nutzern (Beschaffer und Bedarfsmelder).

Wir kehren kurz zum letzten Beispiel von nicht-blockierenden Zuständigkeiten zurück. Wir befinden uns in einer Org, die mehrere untergeordnete OEn hat. Für unsere Org gibt es die relevante Zuständigkeit bzgl. Abfragetyp und PK einer Abfrage (direkt auf unserer Org oder veerbt über einen übergeordneten Knoten). Wir haben somit eine Teilnahmeberechtigung (Recht zur Einsicht und Teilnahme) für die Abfrage für alle enthaltenen OEn unserer Org. In unserem neuen Fall-Beispiel gibt es jedoch für den Abfragetyp und die PK der Abfrage eine blockierende Zuständigkeit einer oder mehrerer OEn aus unserer Org. Durch diesen Umstand haben nicht mehr alle OEn unserer Org eine Teilnahmeberechtigung für die Abfrage (d. h. können diese sehen und an ihr teilnehmen), sondern nur noch die OE(n) die eine blockierende Zuständigkeit für Abfrage besitzen.

Diese OE(n) müssen nun stellvertretend für ihre Org Entscheidung bzgl. der Abfrage folgende Entscheidungen treffen (diese Entscheidungen können durch jede der blockierend zuständigen OEn der Org gleichberechtigt getroffen werden):

A: Wir geben die Abfrage nicht weiter innerhalb unserer Org oder nachgelagerter Org, sondern beantworten die Abfrage stellvertretend für unsere gesamten Teilbaum der OSr im Rahmen einer Teilnahme an der Abfrage (wenn eine unserer OEn eine blockierende Zuständigkeit für den Abfrage- oder Sub-Abfragetyp und die PK der Abfrage hat)

• In diesem Fall erhält keine der enthaltenen blockierten OEn der Org die Abfrage und wir als blockierende OE beantworten die Abfrage stattdessen stellvertretend für diese.

B: Wir möchten die OEn unserer Org (und optional die nachgelagerter Org) bzgl. der Abfrage involvieren und erstellen dafür eine Sub-Abfrage (wenn eine unserer OEn eine blockierende Zuständigkeit für den Abfrage- oder Sub-Abfragetyp und die PK der Abfrage hat)

• Basierend auf der Abfrage erstellen wir eine Sub-Abfrage für die OEn unserer Org und optional nachgelagerter Org (Level 1..n) und veröffentlichen die Sub-Abfrage für/an diese OEn. Die Sub-Abfrage ist nur für die dabei adressierten OEn (hierfür wird das gleiche Prinzip der Übersetzung von Zuständigkeiten findet hier bzgl. der Zuständigkeiten der abfragende OE der Sub-Abfrage im ab dem Orga-Knoten der Sub-Abfrage angewendet).
• Nach der Rückmeldung der potentiellen Teilnehmer-OEn der Sub-Abfrage in Form abgegebener Teilnahmen zu der Sub-Abfrage, werden die zurück gemeldeten Antworten auf Fragen des Fragenkatalogs gesammelt und die Mengen zu abgefragten Bedarfen aggregiert (d.h. aufsummiert). Die summierten Mengen bzgl. der abgefragten Bedarfe können dann im Rahmen der Konsolidierung der Sub-Abfrage noch nach oben oder unten angepasst werden.
• Nach der abgeschlossenen Bearbeitung der Ergebnisse der Sub-Abfrage wird das Gesamtergebnis der Sub-Abfrage in eine neue Teilnahme übernommen, die zur Übermittlung der Ergebnisse bzgl. der Haupt-Abfrage aus dem Teilbaum der OSr an die übergeordnete Abfrage (die Abfrage, in deren Kontext die Sub-Abfrage durchgeführt wurde) dient.
• Diese Prozess kann innerhalb eines Teilbaums der OSr beleibige Male (einmal pro Ebene) wiederholt werden, solange es auf der jeweiligen Ebene der OSr (d.h. dem Orga-Knoten) eine Zuständigkeit für den Sub-Abfragetyp und die PK der Abfrage gibt.

Beispiel offene Abfrage (blockierende Zuständigkeit)

Szenario 1:

In Szenario 1 betrachten wir einen Ausschnitt der Organisationsstruktur. Die erhebende Abfrage-OE veröffentlicht eine Abfrage vom processes.targetProcess.filterIndicatorLabel A in der Produktkategorie (PK) 2 und erreicht damit alle Org bzw. deren enthaltenen OEn, für die sie eine entsprechende Zuständigkeit für Abfragen vom processes.targetProcess.filterIndicatorLabel A und die PK 2 hat, zudem gibt es in Org Ahorn eine blockierende Zuständigkeit einer ihrer enthaltenen OEn für Abfragen vom processes.targetProcess.filterIndicatorLabel A in der PK 2.

1. Für die Org Ahorn gibt es zwar die passende Zuständigkeit (processes.targetProcess.filterIndicatorLabel A & PK 2), aber dies ist eine blockierende Zuständigkeit – somit besitzen nicht alle OEn der Org Ahorn eine Teilnahmeberechtigung oder Berechtigung zur Durchführung einer Sub-Abfrage zu der Abfrage, sondern nur die OEn mit dieser entsprechenden blockierenden Zuständigkeit, in diesem Fall OE Ahorn A. Die Entscheidung zur stellvertretenden Teilnahme der blockierenden OE für den gesamten Teilbaum der Org Ahorn oder zur Einbeziehung aller OEn der Org Ahorn (und ggf. nachgelagerter Org) steht zu diesem Zeitpunkt aber noch aus und nur die blockierend zuständige OE der Org Ahorn können die Abfrage sehen.

2. Org Linde besitzt die passende Zuständigkeit und keine OE besitzt eine blockierende Zuständigkeit. In diesem Fall läuft der Prozess wie bereits im ersten Beispiel beschrieben ab. Beide OEn sehen die Abfrage, aber nur eine kann pro Org teilnehmen. Ein manuelles Eingreifen ist in diesem Fall bei der Org Linde nicht erforderlich.

Szenario 2a:

In diesem Fall entscheidet die blockierende OE der Org Ahorn die Abfrage als unbeschränkte Sub-Abfrage an alle beiden OEn der Org Ahorn (also Ahorn A und Ahorn B) zu veröffentlichen. Alle beiden adressierten OEn können unabhängig voneinander an der Sub-Abfrage teilnehmen (d. h. inkl. der blockierenden OE aus der Org Ahorn selbst, damit auch ihre Mengen bzgl. Bedarfen und Antworten bzgl. Fragen berücksichtigt werden). Die Beschränkung aus offenen Abfragen, dass es nur eine Teilnahme pro Org geben darf, gilt nicht für Sub-Abfragen (diese sind ein Hilfsmittel, um konsolidierte Gesamtmengen aus einem Teilbaum der OSr an übergeordnete Abfrage zu melden). Die Ergebnisse der Sub-Abfrage innerhalb der Org Ahorn (und ggf. nachgelagerten Org) wird über eine neue Ergebnis-Teilnahme der blockierend zuständigen OE, die die Sub-Abfrage durchgeführt hat, an die übergeordnete Abfrage weitergegeben, damit die Mengen dort in die weitere Konsolidierung einfließen können.

Szenario 2b:

Für diesen Fall wurde die Org Ahorn etwas erweitert. Sie besitzt nur drei OEn und zwei davon besitzen eine für das Beispiel relevante blockierende Zuständigkeit. In diesem Fall entscheidet eine der blockierenden OEn der Org Ahorn die Abfrage direkt stellvertretend für die gesamte Org Ahorn zu beantworten, ohne alle anderen OEn der Org einzubinden. Die nicht-blockierende OE der Org Ahorn (also OE Ahorn B) sieht die Abfrage und die Teilnahme der blockierend zuständigen OE aus Org Ahorn entsprechend überhaupt nicht. Die andere blockierend zuständigen OE aus Org Ahorn (also OE Ahorn C) kann allerdings sowohl die Abfrage als auch die dazugehörige Teilnahme der anderen blockierend zuständigen OE sehen. Bzgl. der übergeordneten Abfrage gilt weiterhin die Standard-Regel, dass es bei offenen Abfragen nur eine Teilnahme pro Org geben darf und bei beschränkten Abfragen eine Teilnahme pro eingeladenem Teilnehmer.

Zu beschränkten Abfragen können in übergeordneten Abfragen in erreichbaren Org mit blockierend zuständigen OEn nur diese eingeladen werden und keine weiteren nicht-blockierenden OEn der gleichen Org oder OEn aus weiter nachgelagerten Org (unabhängig ob blockierend oder nicht), da eine blockierend zuständige OE alle processes.name_plural des processes.targetProcess.filterIndicatorLabels mit der PK für ab der Org-Ebene der blockierend zuständige OE blockieren.

Beispiel Org-Verschachtelung

Szenario 3

Für dieses Beispiel wurde die Organisationsstruktur leicht verändert. Die Organisation Eiche ist nun der Organisation Linde nachgeordnet. Innerhalb der Org Linde gibt es eine blockierende Zuständigkeit einer ihrer enthaltenen OEn für A/2 und diese hat entschieden, per Sub-Abfrage die OEn der eigenen Org als auch der nachgelagerten Org Eiche zu befragen.

OE Linde A erhält direkt die Sub-Abfrage der blockierend zuständigen OE aus der Org Linde und kann diese in Form einer Teilnahme beantworten. Innerhalb der Org Eiche gibt es ebenfalls eine blockierende Zuständigkeit einer ihrer enthaltenen OEn für den Sub-Abfragetyp von A und die PK 2. An diesem Punkt ist also erneut eine Entscheidung dieser blockierend zuständigen OE Eiche B erforderlich, bevor mit der Sub-Abfrage der blockierend zuständigen OE aus Org Linde fortgefahren werden kann.

Diese blockierend zuständige OE Eiche B aus der Org Eiche hat nun die gleichen Optionen wie zuvor beschrieben bzgl. der Sub-Abfrage aus dem Kontext der Org Linde:

Sie kann die Sub-Abfrage selbst beantworten.

• In diesem Fall wird die Sub-Abfrage nicht für die anderen nicht-blockierend zuständige OE Eiche A der Org Eiche sichtbar gemacht und diese kann auch nicht an dieser teilnehmen (gleiches gilt auch für die ursprüngliche, übergeordnete Hauptabfrage).

Entschließt sie sich, eine eigene Sub-Abfrage zu erstellen, wird diese dann für alle OEn der Org Eiche (und ggf. nachgeordneter Org) sichtbar gemacht und für Teilnahmen zur Verfügung gestellt.

• Achtung: Entschließt sich die blockierend zuständige OE Eiche B aus der Org Eiche in diesem Fall eine Sub-Abfrage durchzuführen, so basiert diese Sub-Abfrage auf Sub-Abfrage, die vorher von Org Linde für sichtbar für Teilnahmen gemacht wurde. Es handelt sich somit um eine Sub-Sub-Abfrage (bzw. eine Sub-Abfrage mit Level 2, die erste übergeordnete Sub-Abfrage hat das Level 1 und Haupabfrage das Level 0).

Dieses grundlegende Prinzip der blockierenden Zuständigkeit würde auch wie im vorherigen Beispiel in beliebig vielen Verschachtelungen greifen. Sprich wenn einer Org mit blockierender Zuständigkeit weitere Organisationen mit blockierenden Zuständigkeiten untergeordnet wären, würde auf jeder Org-Ebene eine Entscheidung notwendig werden, wie mit der Abfrage bzw. Sub-Abfrage für die enthaltenen und OEn und OEn nachgelagerter Org verfahren werden soll.

Die bisherigen theoretischen Erklärungen können in der Praxis in beliebigen Kombinationen auftreten (im Kontext von Organisationen mit blockierenden und/oder nicht-blockierenden Zuständigkeit oder nur vererbten Zuständigkeiten aus übergeordneten Ebene; im Kontext von beschränkten und nicht beschränkten Abfragen; im Kontext von Abfrage-Kaskaden, bei denen die Sub-Abfragen auf den unterschiedlichen Level erst zu unterschiedlichen Zeitpunkten durchgeführt – wenn keine blockierenden Zuständigkeiten involviert sind, könnten die unterschiedlichen Level sogar in anderen Sequenzen ihre Sub-Abfragen durchführen, da sie dann unabhängig voneinander durchgeführt werden können), was mitunter zu einer sehr hohen Komplexität führen kann (v. a. aus Beschaffersicht – insbesondere der höheren Ebenen).

Zudem können sich OEn die zuständigen PK bzgl. der Abfragetypen auf den verschiedenen Orga-Knoten/Ebenen auch aufteilen oder gemeinsam teilen. Zum einfacheren Verständnis können aber immer kontextuell an jedem Knotenpunkt der OSr (Orga-Knoten) die dortigen explizit gesetzten und bis dorthin vererbten, gesetzten Zuständigkeiten (blockierend und nicht-blockierend) betrachtet werden.

Zusätzlich ist über die OSr leicht ersichtlich, welche OE für welchen Teilbereich der OSr für welchen Abfragetyp und welche PK zuständig ist – insbesondere bei übergreifenden Zuständigkeiten, die auf Organisationsgruppen-Knoten (inkl. dem globalen Wurzel-Gruppenknoten) oder Organisation mit nachgelagerten Organisationen gesetzt sind. Durch die Vererbung der Zuständigkeit ist damit ein leichter Überblick der verteilten Zuständigkeiten, sowie eine differenzierte Aussteuerung der Zuständigkeiten möglich.

Abgabe von Meldungen

Die Teilnahme an Abfragen funktioniert, wie beschrieben, von oben nach unten im OSr. An jedem Knotenpunkt wird hierbei geprüft, ob eine relevante blockierende Zuständigkeit vorliegt und somit eine Entscheidung notwendig ist. Meldungen funktionieren im Gegensatz dazu quasi „von unten nach oben“. Aber auch hier greifen prinzipiell die gleichen Mechanismen.

Um eine Meldung abzugeben, muss mindestens eine zuständige Beschaffungsstelle im Bereich der abgebenden OE existieren. Ist dies gegeben, kann ein Bedarfsträger einer OE eine Meldung and die zuständige OE abgeben.

In diesem Kontext funktionieren blockierende Zuständigkeiten ähnlich wie bei Abfragen. Auf jeder Org-Ebene, für die Zuständigkeit für Meldungstyp und PK gegeben sind, wird geprüft, ob eine blockierende Zuständigkeit vorliegt. Ist dies der Fall fungiert die blockierende OE als Torwächter für die Meldung und muss eine Entscheidung treffen:

• Die blockierende OE kann die Meldung final bearbeiten und abschließen. Dies schließt beispielsweise das Anlegen einer Vergabe ein. Andere blockierende OEn weiter „oben“ in der OSr können die Meldung in diesem Fall nicht bearbeiten.
• Die blockierende OE kann die Meldung an die nächsthöhere blockierende OE weiterleiten, sofern eine derartige OE existiert. Für diese nächsthöhere OE muss auch wieder die Zuständigkeit für Meldetyp und PK gegeben sein.

Je nach Komplexität der OSr kann eine Meldung so verschiedene, blockierende OEn auf den verschiedenen Org-Ebenen durchlaufen.

Empfängerauswahl Wie in Szenario 2b bereits betrachtet, kann es Situationen geben, in denen mehrere OEn auf einer Org-Ebene die gleiche blockierende Zuständigkeit (Meldetyp und PK) besitzen. Im Kontext der Abgabe einer Meldung bedeutet dies, dass eine Empfängerauswahl vorgenommen werden muss. Dies gilt sowohl für die initiale Abgabe der Meldung als auch jede Weiterleitung von einer blockierenden OE an die nächsthöhere Ebene. Diese Empfängerauswahl ist somit jedes Mal verpflichtend, wenn es an einem Punkt in der Bearbeitung der Meldung potenziell mehr als einen blockierenden, nächsten Empfänger gibt. Die Empfänger OE wird explizit ausgewählt und die Meldung genau an diese weitergeleitet.