Hinweis: brandenburg.de hat seine Internet-Seiten auf barrierefreien Zugriff optimiert und verwendet deshalb standardisiertes CSS (Stylesheets). Sollte Ihr Browser dieses nicht korrekt anzeigen, unterstützt er nicht die üblichen Webstandards. Weitere Informationen finden Sie hier.

Brandenburgisches Vorschriftensystem (BRAVORS)

 A | A | A |
Letzte gültige Fassung Änderungshistorie

ARCHIV

Richtlinien des CCC für die Steuerung eines verteilten NFM-Betriebes im Land Brandenburg (nebst Durchführungsbestimmungen)


vom 24. März 2010
(ABl./10, [Nr. 14], S.619)

geändert durch Bekanntmachung des MdF vom 10. Oktober 2012
(ABl./12, [Nr. 46], S.1615)

Außer Kraft getreten am 10. August 2022 durch Richtlinien des MdFE vom 18. März 2022
(ABl./22, [Nr. 31], S.678)

Das im Ministerium der Finanzen, Referat 28 eingegliederte CCC (Customer Competence Center) hat zentrale Regelungen für die Organisation und Steuerung eines verteilten NFM-Betriebes (NFM - Neues Finanzmanagement) erlassen und als Verwaltungsvorschrift veröffentlicht. Diese Richtlinien und dazugehörige Durchführungsbestimmungen ersetzen seit dem 16. Oktober 2009 die bisherigen bestehenden Vorgaben des Referates 28 und werden nachfolgend bekannt gegeben.

Richtlinien des CCC für die Steuerung eines verteilten NFM-Betriebes im Land Brandenburg

Vom 16. Oktober 2009

Inhaltsverzeichnis

Abkürzungen

Definitionen

Präambel

Geltungsbereich der Richtlinie

Vorgaben

1.1 Allgemeines
1.2 Organisation
1.2.1 Lizenzen und Pflegekosten
1.2.2 Supportlevel
1.2.3 Systemerweiterungen und Releasewechsel
1.3 Betrieb
1.3.1 Technische Vorgaben
1.3.2 Organisatorische Vorgaben
1.3.3 Schnittstellen
1.4 Datenschutz und IT-Sicherheit
1.4.1 Rollen und Berechtigungen
1.4.2 Secure Network Communication (SNC)
1.5 Inhaltliche Vorgaben
1.5.1 Fachkonzepte
1.5.2 Modulspezifische Vorgaben

Abkürzungen

ADONIS  Geschäftsprozessmanagementwerkzeug der Firma BOC
BAPI  Business Application Programming Interfaces
BLB Brandenburgischer Landesbetrieb für Liegenschaften und Bauen
CATS  Cross Application Timesheet
CCC   Customer Competence Center
EDV  Elektronische Datenverarbeitung
GUI Graphical User Interface (grafische Benutzeroberfläche)
GWG  Geringwertige Wirtschaftsgüter
IT  Informationstechnologie
ITIL IT Infrastructure Library
KST Kostenstelle
LHO Landeshaushaltsordnung
MdF Ministerium der Finanzen
MV  Modulverantwortlicher
NFM  Neues Finanzmanagement
OSS Online Service System
PSP Projektstrukturelement
Ref. 28 Referat 28 im Ministerium der Finanzen
SNC Secure Network Communication
SolMan Solution-Manager
ZIT-BB Brandenburgischer IT-Dienstleister

SAP Glossar (für dieses Dokument notwendiger Auszug)

BAPI

Mit der BAPI-Technologie hat die SAP AG eine objektorientierte Technologie in die Software eingeführt. Prozesse und Daten werden in Form von sogenannten SAP-Business-Objekten verfügbar gemacht. Auf die SAP-Business-Objekte können externe Anwendungen über standardisierte, plattformunabhängige Schnittstellen, die sogenannten BAPIs, zugreifen. Die SAP-
Business-Objekte und ihre BAPIs bieten eine offene, objektorientierte Sicht der Geschäftsprozesse und Daten eines SAP-Systems. Die Einzelheiten des Prozesses sind für das Client-Programm unsichtbar, da die exportierten Datenstrukturen in Objekten gekapselt sind.

Modifikation

Kundenindividuelle Änderung an R/3-Repository-Objekten (Systembeschreibung wie zum Beispiel Programm im Sinne von Quellcode oder Datenmodell). Modifizierte R/3-Repository-Objekte müssen bei Änderungen seitens SAP überprüft und gegebenenfalls angepasst werden.

Modul

Der modulare Aufbau des SAP-Systems entspricht der in vielen Organisationen üblichen Struktur. Die Module sind nicht im informationstechnischen Sinne unabhängig (modular), vielmehr sind die Funktionen eng miteinander verzahnt (Funktionsintegration). Module im SAP-Sinne sind zum Beispiel das Modul FI (Finanzwesen) oder CO (Controlling) oder PSM (Public Sector Management).

OSS

Online Support System der SAP AG Walldorf. Die SAP-Produktunterstützung im Rahmen eines Vertrags über Software-Wartung wird weitgehend über im Internet zugängliche Systeme abgewickelt, die unter dem Namen SAP Service Marketplace zusammengefasst werden. Dort können bestimmte SAP-Anwender Problemmeldungen an SAP schicken und weiterverfolgen. Im gleichen Rahmen besteht hier die Möglichkeit, zum Beispiel Dokumentationen, Installationsmedien oder Programmkorrekturen zu beziehen.

USER-Exit

Vorgedachte Erweiterungsoption des SAP-Standards. Potenzielle Kundenanforderungen, die nicht als Standard ausgeprägt sind, werden als leere Entwicklungshülse vorgedacht und können beim Anwender des Systems mit eigener Logik (zulässige Eigenentwicklung) ausgestaltet werden.

Definitionen

Zentralkonzept:

Das Zentralkonzept ist ein Ergebnis aus der Arbeit in den zurückliegenden Einführungswellen der NFM-Einführung (Welle 1 & 2). Die Struktur des Zentralkonzeptes ist modular in Kapiteln aufgebaut, das heißt Finanzbuchhaltung (FI), Anlagenbuchhaltung (FI-AA), Kosten- und Leistungsrechnung (CO & CATS), Projektsystem (PS), Instandhaltung (PM), Materialwirtschaft (MM), Immobilienmanagement (RE) sowieAltdaten/Schnittstellen und Berechtigungen.

Das Zentralkonzept enthält Festlegungen mit dem Ziel der Standardisierung. Folgende Aspekte werden genannt:

  • Basisfestlegungen
    Hier handelt es sich um Festlegungen allgemeiner Art, die zwingend für alle Landesbehörden einheitlich zu treffen sind. Beispielhaft sei die Festlegung „Euro“ als Währung genannt.
  • Integrative Sachverhalte
    Zur Abgrenzung der einzelnen Behörden sind Stammdatenstrukturen aufzubauen, die die einzelnen Organisationseinheiten voneinander abgrenzen. Beispielhaft sei hier die Nomenklatur der Kostenstellen genannt. Jede Kostenstelle darf nur einmal im System vorkommen und sollte eindeutig einer Organisationseinheit zugeordnet werden können.
  • Konzeptionelle Sachverhalte
    Konzeptionelle Sachverhalte umfassen Festlegungen, die zur Erlangung konsolidierbarer Ergebnisse notwendig sind. Beispielhaft sei der Umgang mit interner Leistungsverrechnung genannt.
  • Technische Sachverhalte
    Zusätzlich gibt es Sachverhalte, deren Standardisierung aus technischen Gründen unumgänglich ist, wie zum Beispiel die Mandantenstruktur.

Das Zentralkonzept wird den Landesbetrieben, sofern noch nicht vorhanden, auf Anfrage zur Verfügung gestellt.

Fachkonzept:

Fachkonzepte stellen auf Grundlage der einzelnen themenspezifischen Kapitel des Zentralkonzeptes die modulspezifischen Einstellungen in den jeweils doppisch buchenden Landesbetrieben dar. Sie orientieren sich stark am Zentralkonzept und zeigen darüber hinaus die vereinbarten Abweichungen zu diesem.

Im Gegensatz zum Zentralkonzept sind die Fachkonzepte nicht in einem Konzept zusammengefasst, sondern jedes Modul wird in einem in sich abgeschlossenen Konzept beschrieben. Die Fachkonzepte können sich dabei zwischen den einzelnen Landesbetrieben unterscheiden. Die Anzahl der jeweils vorgehaltenen Fachkonzepte richtet sich danach, welche Module im Landesbetrieb genutzt werden.

Masterkonzept:

Masterkonzepte zeigen die in der Welle 3 festgelegten Prozessabläufe und Einstellungen des kameralen SAP-Systems.

Im Gegensatz zum Zentralkonzept sind die Masterkonzepte nicht in einem Konzept zusammengefasst, sondern jedes Themengebiet wird in einem in sich abgeschlossenen Masterkonzept betrachtet. Die Masterkonzepte haben dabei Gültigkeit für alle Ressorts.

SAP-Modullandschaft:

Das SAP ERP hat einen modularen Aufbau. Die Gesamtheit aller - in der ausgeprägten Installation genutzten - Module wird als Modullandschaft bezeichnet.

Die Module der Anwendungsbereiche Rechnungswesen, Logistik und Personalwirtschaft unterteilen sich weiter in Komponenten.

Die Module innerhalb der Modullandschaft sind im informationstechnischen Sinne voneinander abhängig (Funktionsintegration).

Präambel

Diese Richtlinie dient der Organisation und Steuerung eines verteilten NFM-Betriebes (vergleiche Geltungsbereich der Richtlinie).

Hierdurch wird die Zusammenarbeit zwischen den beteiligten Organisationseinheiten des Landes Brandenburg unter der Maßgabe eines verteilten NFM-Betriebes ausgestaltet. Gegenwärtig sind das CCC im MdF und die Landesbetriebe an dieser Zusammenarbeit beteiligt.

Die zentralen Regelungen des Dokumentes sind im Zusammenwirken des CCC mit den Landesbetrieben entstanden.

Durch die Regelungen dieses Dokumentes werden die Landesbetriebe in die Lage versetzt, den Betrieb ihres Rechnungswesens technisch selbstständig, unabhängiger und im Ergebnis flexibler als bisher durchführen zu können. Das nachstehende Regelwerk beschreibt organisatorische, technische und inhaltliche Vorgaben für den NFM-Betrieb in einem verbindlichen Mindestumfang. Diese Vorgaben sind notwendig, um ein standardisiertes Rechnungswesen - im Sinne des Neuen Finanzmanagements - im Land Brandenburg, unter Gewährleistung einer notwendigen Zusammenführungsoption, sicherzustellen.

Diese Richtlinie ersetzt mit Inkrafttreten bisher bestehende Vorgaben des Referats 28. Der durch diese Richtlinie verbindlich definierte Mindestumfang berücksichtigt somit die von allen Beteiligten angestrebten Freiheitsgrade, die sich aus den bewusst ungeregelten Sachverhalten ergeben. Mit diesen Möglichkeiten schafft das Land Brandenburg alle denkbaren Freiräume, um den wachsenden und sich ändernden Bedürfnissen der Landesbetriebe gerecht zu werden und gleichzeitig den zentralen NFM-Standard des Landes Brandenburg weiterhin sichern und entwickeln zu können.

Der Verteilungsgrad des NFM-Betriebes soll den Bedürfnissen der Landesverwaltung gerecht werden und weiterhin anpassungsfähig bleiben. Aus diesem Anspruch resultiert einerseits die Möglichkeit eigenverantwortlichen Handelns und anderseits der Auftrag zur Wahrnehmung zentraler Verantwortung für den NFM-Gesamtbetrieb.

Die Zusammenarbeit zwischen CCC und den Landesbetrieben ist kooperativ zu gestalten und auf eine optimale Aufgabenerfüllung auszurichten, sofern sich nicht aus der Systemverantwortung gegenüber dem Lizenzgeber SAP oder dem Handeln als zentrale Instanz gegenüber der Landesverwaltung des Landes Brandenburg eine zentrale Regelungshoheit für das CCC ergibt. Das CCC und die Landesbetriebe verfolgen im Zuge ihrer Aufgabenerfüllung gemeinsam die Ziele,

  • Aufgaben klar zu definieren und zuzuweisen,
  • Aufgaben und Leistungen gegenseitig zu respektieren sowie
  • voneinander zu lernen und gemeinsam den verteilten NFM-Betrieb zu optimieren.

Das CCC informiert die Landesbetriebe regelmäßig über allgemeine Entwicklungen im SAP und NFM.

Sollten eine oder mehrere Bestimmungen dieses Dokuments nichtig sein, so bleiben die übrigen Bestimmungen hiervon unberührt. Die nichtigen Bestimmungen sind durch eine ihrer Zielsetzung am nächsten kommende Regelung zu ersetzen.

Weitere Ausführungen zu einzelnen Sachverhalten, die der Präzisierung bedürfen, werden in der „Durchführungsbestimmung CCC“ geregelt. Dies schließt Regelungen über mögliche Fristen mit ein. Diese Durchführungsbestimmungen der vorliegenden Richtlinie sollen dem Anspruch gerecht werden, Prozesse für alle Beteiligten nachvollziehbar und verständlich darzustellen.

Geltungsbereich der Richtlinie

Diese Richtlinie gilt für die doppisch buchenden Organisationseinheiten der Landesverwaltung Brandenburg, die technisch nicht im zentralen NFM-Verbund produktiv sind.

Vorgaben

1.1 Allgemeines

  • Das CCC sichert folgende Verträge exklusiv für alle Bereiche der Landesverwaltung des Landes Brandenburg:

    Rahmenverträge:
  • SAP

Zentrale Betriebsverträge:

  • SAP technischer Betrieb
  • SAP Applikationsbetreuung
  • Ende zu Ende Verschlüsselung - Betriebsvertrag.
  • Der Landesbetrieb sichert im Rahmen der zentralen Betriebsverträge durch individuelle Betriebsverträge beziehungsweise Änderungsverträge seinen NFM-Betrieb ab. Die aus diesen Verträgen abzuleitenden Verantwortlichkeiten obliegen dem Landesbetrieb.
  • Das CCC behält sich vor, in Abstimmung mit den obersten Landesbehörden und den ihnen zugeordneten Landesbetrieben die Richtlinie anzupassen (vergleiche Durchführungsbestimmungen CCC).

1.2 Organisation

1.2.1 Lizenzen und Pflegekosten

Der Lizenzbestand des Landes Brandenburg wird durch das CCC verwaltet.

  • Für die Nutzung in den Systemen SAP R/3 und Solution-Manager sowie für zentral einzusetzende Software (zum Beispiel Verschlüsselung) werden Softwarelizenzen benötigt. Diese Lizenzen werden durch das CCC auf Antrag und Genehmigung dem Bedarfsträger zugeteilt. Der Landesbetrieb ist verpflichtet, nicht mehr genutzte Lizenzen dem CCC zurückzugeben. Das CCC behält sich in begründeten Fällen vor, Lizenzen unter Einhaltung von Fristen einzuziehen (vergleiche Durchführungsbestimmungen CCC).
  • Die Systemvermessung wird auf Anforderung des CCC stichtagsbezogen durch den Landesbetrieb durchgeführt. Auf Verlangen des CCC kann die Firma SAP (Vertragspartner Enterprise-Support) im Landesbetrieb Vermessungsarbeiten durchführen. Die Ergebnisse dieser Vermessung sind dem CCC dann im Originalformat vorzulegen (vergleiche Durchführungsbestimmungen CCC).
  • Die Pflegekosten für Softwarelizenzen sind durch den Landesbetrieb zu tragen. Diese orientieren sich an den durch den Landesbetrieb genutzten Lizenzen und werden auf Basis eines landesweit abgestimmten Verteilungsschlüssels ermittelt (vergleiche Durchführungsbestimmungen CCC).

1.2.2 Supportlevel

Abbildung 1: Muster einer Supportstruktur

Abbildung 1: Muster einer Supportstruktur

Die Supportstruktur ist gemäß ITIL in drei Ebenen zu organisieren (1st, 2nd und 3rd Level Support). Nachstehende Struktur wird empfohlen:

Mindestaufgabenstruktur für den 1st Level Support
Betriebsverantwortlicher

  • Namentlich zu benennender Ansprechpartner für das CCC
  • Schnittstelle zwischen Key-User/Modulverantwortlichem und der Haus-IT zum 2nd Level Support einschließlich Budgetverwaltung
  • Bindeglied zum CCC
  • Organisation, Koordination und Leitung von eigenen SAP-Projekten (zum Beispiel Umstrukturierung)
  • Koordinieren der Arbeiten im Betrieb mit den Modulverantwortlichen
  • Koordinierung des Schulungsbedarfs

Key-User/Modulverantwortlicher (MV ist Teilmenge von den Key-Usern)

  • Erster Ansprechpartner für den Endanwender SAP
  • Bearbeitung von Support- und Changeprozessen im Meldungstool (SolMan) für das jeweilige Modul
    • Überprüfung der Änderung auf Vereinbarkeit mit den vom CCC vorgegebenen Richtlinien
    • Überprüfung der Umsetzbarkeit
    • Erarbeiten und Dokumentieren von Lösungsvorschlägen
    • Abstimmung der Modulverantwortlichen untereinander
  • Steuerung von Test- und Entwicklungsprozessen für die Inhalte der jeweiligen Module ; gegebenenfalls Beauftragung 2nd Level Support
  • Überwachung und Steuerung des 2nd und 3rd Level Support, einschließlich Test und Abnahme der Änderungen
  • Einarbeiten von umgesetzten Änderungen in die Fachkonzepte
  • Benutzer/Berechtigungen

Haus-IT/Netzwerk (SAP Basis)

  • Gewährleistung des technischen Supports
  • Planung, Aufbau und Administration des SAP-Systems
  • Administration des Meldungstools (SolMan), einschließlich der Administration des Korrektur- und Transportwesens innerhalb des SAP-Systems
  • Administration der Schnittstellen
  • Administration Frontend Systems (SAP-GUI) und der Druckereinrichtung

1.2.3 Systemerweiterungen und Releasewechsel

  • Genehmigungen für Modifikationen sind durch den Landesbetrieb beim CCC zu beantragen (vergleiche Durchführungsbestimmungen CCC).
  • Genehmigungen für Erweiterungen im Rahmen von User-Exits, BAPIs etc. sind durch den Betriebsverantwortlichen beim CCC zu beantragen (vergleiche Durchführungsbestimmungen CCC). Die Entwicklerrichtlinien SAP des Landes Brandenburg sind zwingend zu beachten.
  • Die Gestaltung der SAP-Modullandschaft der Landesbetriebe ist dem CCC vorbehalten. Die Nutzung der Module
    Finanzwesen (FI), Anlagenbuchhaltung (FI-AA) und Controlling (CO) im Land Brandenburg ist fest vorgeschrieben. Die Einführung von weiteren Modulen ist möglich (vergleiche Durchführungsbestimmungen CCC).
  • Releasewechsel durch den Landesbetrieb sind dem CCC vor Durchführung anzuzeigen (vergleiche Durchführungsbestimmungen CCC).
  • Die derzeit vorhandenen Entwicklungen (USER-Exits , Programme etc.) werden dem Landesbetrieb bei Systemtrennung übergeben.

1.3 Betrieb

1.3.1 Technische Vorgaben

  • Als technisches Administrationswerkzeug ist der Solution-Manager zu verwenden.
  • Für Änderungen und Support ist der Solution-Manager zu verwenden.

1.3.2 Organisatorische Vorgaben

  • Mit Übernahme des eigenen Systems sind im Rahmen des jeweiligen  Betriebsvertrags mit dem Systembetreiber die notwendigen Prozesse zu dokumentieren. Diese Dokumentation beschreibt Prozesse zwischen Systembetreiber und Landesbetrieb. Die internen Prozesse und Verantwortlichkeiten des Landesbetriebes sind unter Berücksichtigung der ressortspezifischen Vorgaben ebenfalls zu dokumentieren. Bezüglich dieser Dokumentationen hat der Landesbetrieb mindestens ein Dokument zu erstellen. Der Landesbetrieb hat ein Notfallhandbuch zu erstellen. Diese Dokumentationen sind aktuell zu halten und auf Anforderung dem CCC vorzulegen (vergleiche Durchführungsbestimmungen CCC).
  • Die Berechtigung zur Vergabe, Verwaltung und zum Entzug von Entwickler- und Objektschlüsseln (SSCR-Schlüsseln) wird durch das CCC personengebunden zugewiesen. Die Zuweisung wird auf die Installationsnummern der SAP-Systeme des Antragstellers beschränkt. (vergleiche Durchführungsbestimmungen CCC).
  • Der Landesbetrieb erhält die Möglichkeit, für seine Installation eigenständig OSS-Meldungen zu erstellen und einzusehen. Diese Möglichkeit, eigene OSS-Meldungen auszugeben, kann durch das CCC beschränkt werden. Diese Beschränkung erfolgt dann, wenn die Qualitätskontrolle der OSS -Meldung durch das CCC ergibt, dass notwendige Standards (vergleiche Durchführungsbestimmungen CCC) nicht eingehalten werden.
  • Der Landesbetrieb und seine ihm vorgesetzte oberste Landesbehörde sind gehalten, alle Aktivitäten, die Einfluss auf das NFM-System haben, mittel- und langfristig zu planen und das CCC darüber zu informieren. Hierzu zählen insbesondere folgende Aktivitäten:
    • die Anforderung des Lizenzerwerbs an das CCC,
    • die Planung von Umstrukturierungsmaßnahmen, wie zum Beispiel:
      • Fusionen,
      • Ausgliederungen,
      • Überführungen in andere Rechtsformen,
      • Rücküberführung in oberste Landesbehörden.

1.3.3 Schnittstellen

  • Der Landesbetrieb ist für die Anbindung und den Betrieb seiner Fach- und Vorverfahren selbst verantwortlich.
  • Veränderung und die Neuentwicklung von Schnittstellen durch den Landesbetrieb ab dem Übergabezeitpunkt sind dem CCC zur Dokumentation in geeigneter - prüfbarer - Form zu übermitteln (vergleiche Durchführungsbestimmungen CCC).

1.4 Datenschutz und IT-Sicherheit

Dem CCC sind der IT-Sicherheitsbeauftragte und der Datenschutzbeauftragte in Bezug auf das NFM namentlich zu benennen (vergleiche Durchführungsbestimmungen CCC).

1.4.1 Rollen und Berechtigungen

  • Unter Berücksichtigung geltender Vorschriften (unter anderem LHO, Brandenburgisches Datenschutzgesetz, Sicherheitsrichtlinien) - vorbehaltlich lizenzrechtlicher Fragestellungen - ist der Landesbetrieb in der Gestaltung seiner Rollen und Berechtigungen frei. Das CCC empfiehlt, das zum Übergabezeitpunkt angewendete Rollen- und Berechtigungskonzept (Fachkonzept) beizubehalten. Für den Fall, dass der Landesbetrieb Daten anderer Landesbetriebe bei der Systemtrennung erhalten hat, ist die Zugriffs- und Berechtigungssteuerung bis zur endgültigen Löschung dieser Daten an den Systembetreiber zu übergeben. Zwischen dem Landesbetrieb und dem Systembetreiber ist vertraglich - gegebenenfalls über das CCC - sicherzustellen, dass der Systembetreiber die Zugriffs- und Berechtigungssteuerung so auszuführen hat, dass der von der Systemtrennung betroffene Landesbetrieb in keiner Form Zugriff oder Einsicht auf Daten anderer Landesbetriebe hat. Näheres wird in den Durchführungsbestimmungen geregelt.
  • Der Landesbetrieb ist verpflichtet, ein Rollen- und Berechtigungskonzept vorzuhalten und fortzuschreiben.
  • Der Landesbetrieb ist verpflichtet, die technischen Umsetzungsstände dieses Rollen- und Berechtigungskonzeptes zu dokumentieren. Die Dokumentation ist dem CCC auf Verlangen vorzulegen (vergleiche Durchführungsbestimmungen CCC).

1.4.2 Secure Network Communication (SNC)

Die technische Kommunikation zwischen den SAP-Clients und den Servern im Rechenzentrum beim Dienstleister ist Ende-zu-Ende zu verschlüsseln. Die Produktvorgabe erfolgt durch das CCC. Der Betrieb erfolgt durch den Landesbetrieb.

1.5 Inhaltliche Vorgaben

1.5.1 Fachkonzepte

Jeder Landesbetrieb ist verpflichtet, ein auf sein spezifisches Bedürfnis zugeschnittenes Fachkonzept für die produktiv eingesetzten SAP-Module zu erstellen, zu pflegen und auf Verlangen dem CCC vorzulegen (vergleiche Durchführungsbestimmungen CCC).

1.5.2 Modulspezifische Vorgaben

1.5.2.1 Doppik/Finanzbuchhaltung (Modul FI)

1.5.2.1.1 Geschäftsjahresvariante

Geschäftsjahresvariante K4 muss beibehalten werden.

1.5.2.1.2 Buchungsschlüssel

Buchungsschlüssel sind gemäß Zentralkonzept zu verwenden. Neudefinitionen müssen beim CCC beantragt werden (vergleiche Durchführungsbestimmungen CCC).

1.5.2.1.3 Sachkonto

  • Die Sachkontenanlage erfordert die Genehmigung durch das CCC. Die Neuanlage von sekundären Kostenarten (9'er Bereich) ist dem CCC gegenüber nur noch anzeigepflichtig. (vergleiche Durchführungsbestimmungen CCC).
  • Bestimmungsmerkmale von Sachkonten erfolgen durch das CCC nach Vorschlag des Landesbetriebes zentral (vergleiche Durchführungsbestimmungen CCC).

1.5.2.1.4 Debitoren/Kreditoren

  • Die bisherige Nomenklatur der Kontengruppen und die gesteuerten Merkmale der Kontengruppen müssen erhalten bleiben.
  • Neue Kontengruppen und ihre gesteuerten Merkmale müssen beim CCC beantragt werden (vergleiche Durchführungsbestimmungen CCC).

1.5.2.1.5 Belegarten

Neue Belegarten oder deren Änderungen sind mit ihren Bestimmungsmerkmalen beim CCC zu beantragen (vergleiche Durchführungsbestimmungen CCC).

1.5.2.1.6 Periodische Arbeiten: Mahnen

Neue Mahnverfahren oder deren Änderungen sind mit ihren Bestimmungsmerkmalen beim CCC zu beantragen (vergleiche Durchführungsbestimmungen CCC).

1.5.2.2 Kosten- und Leistungsrechnung (Modul CO)

1.5.2.2.1 Kostenartenhierarchie

Die Kostenartengruppe KOA_GES darf nicht geändert werden. Auch eine Erweiterung ist nicht zulässig.

1.5.2.2.2 Kostenstellenstandardhierarchie

Der oberste Knoten der KST-Standardhierarchie wird wie folgt benannt:

BB  Land Brandenburg
S Staatskanzlei
F0 Ministerium der Finanzen
I  Ministerium des Innern
J Ministerium der Justiz
A  Ministerium für Arbeit, Soziales, Frauen und Familie
B Ministerium für Bildung, Jugend und Sport
L  Ministerium für Umwelt, Gesundheit und Verbraucherschutz
V  Ministerium für Infrastruktur und Landwirtschaft
T0 Ministerium für Wirtschaft und Europaangelegenheiten
W  Ministerium für Wissenschaft, Forschung und Kultur
P  Landtag
R  Landesrechnungshof
G  Verfassungsgericht

1.5.2.2.3 Nummernkreisintervall Kostenstellen

Vorhandene Nummernkreisintervalle müssen beibehalten werden.

1.5.2.2.4 Nummerierung der Leistungsarten

Der Landesstandard gibt fünf verbindliche Leistungsarten vor:

  • einfacher Dienst
  • mittlerer Dienst
  • gehobener Dienst
  • höherer Dienst A
  • höherer Dienst B

Diese sind mindestens zu berücksichtigen.

1.5.2.2.5 Numerik der Produkte

Vorhandene Nummernkreisintervalle müssen beibehalten werden.

1.5.2.2.6 Numerik für interne Produkte/Querschnittsprodukte/Fachprodukte
Die vorgegebenen statistischen Querschnittsprodukte und der durch das MdF bestätigte Produktkatalog des Bund-Länder-Arbeitskreises in der bestätigten Fassung sind zwingend zu verwenden. Eine Änderung dieser ist nicht zulässig. Ein einheitlicher Wechsel auf die echten und erweiterbaren Querschnittsprodukte des kameralen Systems ist möglich und beim CCC zu beantragen (vergleiche Durchführungsbestimmungen CCC).

1.5.2.3 Cross Application Timesheet (Modul CATS)

1.5.2.3.1 Numerik Personalbereich/Teilbereich/-nummern

Nummernkreisobjekte im Personalbereich sind so beizubehalten, wie sie übergeben wurden. Notwendige Änderungen obliegen dem Vorbehalt durch das CCC (vergleiche Durchführungsbestimmungen CCC).

1.5.2.3.2 Mitarbeitergruppen

Die vorhandenen Mitarbeitergruppen sind zwingend beizubehalten. Eine Anpassung ist nur durch Zentralvorgabe des CCC zulässig (vergleiche Durchführungsbestimmungen CCC).

1.5.2.3.3 Infotypen

Es sind nachfolgende Infotypen zu pflegen:

  • 0000 Maßnahmen
  • 0001 organisatorische Zuordnung
  • 0002 Daten zur Person
  • 0105 Kommunikation
  • 0315 Vorschläge Arbeitszeitblatt

Die vorhandenen Infotypen mit ihren Steuerungsmerkmalen sind beizubehalten. Eine Anpassung ist nur durch Zentralvorgabe des CCC zulässig (vergleiche Durchführungsbestimmungen CCC).

1.5.2.4 Projektsystem (Modul PS)

1.5.2.4.1 Neuanlage und Änderung von Schlüsseln

Änderungen und Neuanlage von Schlüsseln für

  • die Bezeichnung des Verantwortlichen
  • die Bezeichnung des Antragstellers
  • die Benutzerfelder
  • die Projekt-ID
  • die PSP-Elemente-Gruppen
  • die Projektklassen
  • das Projektprofil
  • das Selektionsschema
  • das Abrechnungsprofil

sind durch das CCC zu genehmigen (vergleiche Durchführungsbestimmungen CCC).

1.5.2.4.2 Projektedition

Die bei Übergabe erlaubten Zeichen für die Gliederung der Projektnummer, von Projektdefinition und PSP-Elementen sind nicht zu ändern.

1.5.2.5 Materialwirtschaft (Modul MM)

1.5.2.5.1 Materialarten

Für das Land Brandenburg werden folgende Materialarten verwendet:

  • BB Geschäftsbedarf
  • BB Reparaturmaterial
  • BB Betriebsstoffe
  • BB Ausstattung/Geräte
  • BB Dienstleistungen
  • BB Rechte/Dienste

Die vorhandenen Materialarten sind beizubehalten. Neue Materialarten dürfen nur nach Genehmigung des CCC angelegt werden (vergleiche Durchführungsbestimmungen CCC).

1.5.2.5.2 Warengruppenstrukturen und Bewertungsklassen

Zusammen mit anderen Faktoren bestimmt die Bewertungsklasse die Sachkonten, die bei einem bewertungsrelevanten Vorgang (zum Beispiel Warenbewegung) fortgeschrieben werden. Die vorhandenen Warengruppenstrukturen und Bewertungsklassen - inklusive ihrer Zuordnung - sind beizubehalten. Anpassungen dürfen nach Genehmigung des CCC vorgenommen werden (vergleiche Durchführungsbestimmungen CCC).

1.5.2.5.3 Kontierungstypen

Für das Land Brandenburg sind folgende Kontierungstypen relevant:

  • BB Auftrag
  • BB Kostenstelle
  • BB Anlagenverrechnung
  • BB Anlage
  • BB Produkt/Kostenstelle
  • BB Projekt
  • BB Immobilien
  • Unbekannt

Die vorhandenen Kontierungstypen sind unverändert beizubehalten. Erweiterungen sind genehmigungspflichtig (vergleiche Durchführungsbestimmungen CCC).

1.5.2.5.4 Belegarten

Die mit Übergabe des Systems vorhandenen Belegarten sind unverändert weiter zu verwenden.

Neue Belegarten oder deren Änderungen sind mit ihren Bestimmungsmerkmalen beim CCC zu beantragen (vergleiche Durchführungsbestimmungen CCC)

  • Belegarten für Beschaffungsanträge
  • Belegarten für Anfragen
  • Belegarten für Bestellungen
  • Belegarten für Rahmenverträge
  • Belegarten für Material und Inventur

1.5.2.6 Instandhaltung (Modul PM)

1.5.2.6.1 Typen für technische Plätze

Für das Land Brandenburg sind folgende Typen für technische Plätze relevant:

I RE Immobilien
M Technisches System - Standard
S Kundenplatz
H  Hochbau
Z Zentrale

Typen für technische Plätze sind beizubehalten. Notwendige Änderungen obliegen dem Vorbehalt durch das CCC (vergleiche Durchführungsbestimmungen CCC).

1.5.2.6.2 Equipmenttypen

Für das Land Brandenburg sind folgende Equipmenttypen relevant:

G Geräte - Gerätenachweis mit Wartungsplanung und Fristenverfolgung
K  Kraftfahrzeuge
A  Anhänger
H  Hochbau
B Gruppengeräte (GWG in Gruppen zusammengefasst zur Wartungsplanung)
I Inventar-GWG (Nachweis ohne Wartungsplanung und Fristenverfolgung)
T Technische Anlagen BLB

Typen für Equipment sind beizubehalten. Notwendige Änderungen obliegen dem Vorbehalt durch das CCC (vergleiche Durchführungsbestimmungen CCC).

Durchführungsbestimmungen des CCC für die Steuerung eines verteilten NFM-Betriebes im Land Brandenburg

Inhaltsverzeichnis

Tabellenverzeichnis

Abkürzungen

Durchführungsbestimmungen

Präambel

1.1 Allgemeines
1.2 Organisation
1.2.1 Lizenzen und Pflegekosten
1.2.2 Supportlevel
1.2.3 Systemerweiterungen und Releasewechsel
1.3 Betrieb
1.3.1 Technische Durchführungsbestimmungen
1.3.2 Organisatorische Durchführungsbestimmungen
1.3.3 Schnittstellen
1.4 Datenschutz und IT-Sicherheit
1.4.1 Rollen und Berechtigungen
1.5 Inhaltliche Durchführungsbestimmungen
1.5.1 Fachkonzepte
1.5.2 Modulspezifische Vorgaben

Tabellenverzeichnis

Tabelle 1: Übergabepunkte und Verantwortlichkeiten Anpassung zentrale Regelungen
Tabelle 2: Übersicht Lizenztypen
Tabelle 3: Zuordnung möglicher höherwertiger Lizenztypen
Tabelle 4: Übergabepunkte und Verantwortlichkeiten Lizenzanforderung und Rückgabe
Tabelle 5: Übergabepunkte und Verantwortlichkeiten Systemvermessung
Tabelle 6: Übergabepunkte und Verantwortlichkeiten Zahlungsverkehr
Tabelle 7: Übergabepunkte und Verantwortlichkeiten Systemerweiterungen
Tabelle 8: Übergabepunkte und Verantwortlichkeiten Erweiterung Modullandschaft
Tabelle 9: Übergabepunkte und Verantwortlichkeiten Releasewechsel
Tabelle 10: Übergabepunkte und Verantwortlichkeiten Fachkonzeptanforderung
Tabelle 11: Übergabepunkte und Verantwortlichkeiten Entwicklerschlüssel
Tabelle 12: SAP Hinweis Nummer 67739
Tabelle 13: SAP Hinweis Nummer 16018
Tabelle 14: Übergabepunkte und Verantwortlichkeiten Planungsunterlagen
Tabelle 15: Übergabepunkte und Verantwortlichkeiten Schnittstellen
Tabelle 16: Übergabepunkte und Verantwortlichkeiten Datenschutz und IT-Sicherheit
Tabelle 17: Übergabepunkte und Verantwortlichkeiten im Klärungsfall von Rollen und Berechtigungen
Tabelle 18: Übergabepunkte und Verantwortlichkeiten der Dokumentation der technischen Umsetzungsstände für ein Rollen- und Berechtigungskonzept
Tabelle 19: Übergabepunkte und Verantwortlichkeiten Fachkonzeptanforderung
Tabelle 20: Übergabepunkte und Verantwortlichkeiten Genehmigung modulspezifische Anpassung
Tabelle 21: Übergabepunkte und Verantwortlichkeiten modulspezifische Anpassung durch Zentralvorgabe

Abkürzungen

ADONIS Geschäftsprozessmanagementwerkzeug der Firma BOC
BAPI Business Application Programming Interfaces
BLB Brandenburgischer Landesbetrieb für Liegenschaften und Bauen
CATS Cross Application Timesheet
CCC  Customer Competence Center
EDV Elektronische Datenverarbeitung
GUI Graphical User Interface (grafische Benutzeroberfläche)
GWG  Geringwertige Wirtschaftsgüter
IT  Informationstechnologie
ITIL  IT Infrastructure Library
KST  Kostenstelle
LHO Landeshaushaltsordnung
MdF Ministerium der Finanzen
MV Modulverantwortlicher
NFM  Neues Finanzmanagement
OSS Online Service System
PSP Projektstrukturelement
Ref. 28  Referat 28 im Ministerium der Finanzen
SNC  Secure Network Communication
SolMan  Solution-Manager
tbd.  ist zu definieren (to be defined)
ZIT-BB Brandenburgischer IT-Dienstleister

Durchführungsbestimmungen

Präambel

Die nachfolgenden Durchführungsbestimmungen konkretisieren die in den Richtlinien des CCC für die Steuerung eines verteilten NFM-Betriebes im Land Brandenburg allgemein formulierten Bestimmungen.

Hierbei werden insbesondere die einzuhaltenden Prozesswege zwischen den verschiedenen Beteiligten festgelegt. Die Festlegungen beziehen sich dabei nur auf die Prozesse, bei denen das CCC zwingend involviert ist. Bei den Prozessen zwischen dem Landesbetrieb (LB) und Dritten besteht dagegen Ausgestaltungsfreiheit.

Dieses Dokument folgt der Systematik der Richtlinien des CCC für die Steuerung eines verteilten NFM-Betriebes im Land Brandenburg.

Alle relevanten Auszüge aus diesen Richtlinien werden in diesem Dokument in Form eines grauen Kastens dargestellt. In diesem Feld befindet sich der entsprechende Passus, auf den sich die Durchführungsbestimmungen beziehen.

Im Anschluss daran wird der zugehörige Prozess benannt und beschrieben. In den Beschreibungen befinden sich Verweise auf nachfolgende Tabellen, die in Kurzform die Übergabepunkte und Verantwortlichkeiten der einzelnen Prozesse festhalten.

Wird in diesem Dokument auf Antragsformulare referenziert, so werden diese durch das CCC über das Intranet (BB-intern) zur Verfügung gestellt. Für den Fall fehlender Formulare können diesbezügliche Anträge formlos gestellt werden.

1.1 Allgemeines

Das CCC behält sich vor, in Abstimmung mit den obersten Landesbehörden und den ihnen zugeordneten Landesbetrieben die Richtlinie anzupassen.

Prozess

Das CCC unterbreitet den obersten Landesbehörden und den ihnen zugeordneten Landesbetrieben einen Änderungsvorschlag der Richtlinien. Dieser wird nach Erarbeitung dem LB und der Fachaufsicht zur Prüfung zugesandt (Tabelle 1, Nummer 1).

Der LB und die Fachaufsicht prüfen den Vorschlag und senden bei Bedarf die gegebenenfalls geänderten Bestimmungen mit qualifizierter Stellungnahme an das CCC zur Überarbeitung zurück (Tabelle 1, Nummer 2).

Existiert kein Änderungsbedarf vonseiten des LB beziehungsweise der Fachaufsicht, gilt der Vorschlag des CCC als bestätigt.

Das CCC fasst gegebenenfalls die Änderungswünsche in einer konsolidierten Fassung der zu ändernden Bestimmungen zusammen und sendet diese erneut an den LB und seine Fachaufsicht (Tabelle 1, Nummer 3).

Existiert kein weiterer Änderungsbedarf vonseiten des LB beziehungsweise der Fachaufsicht, gilt der Vorschlag des CCC als bestätigt, andernfalls gilt nach wie vor die letzte Fassung der Richtlinien.

Das CCC teilt die geänderten Bestimmungen gegebenenfalls mit einer Frist zur Umsetzung für alle LB mit (Tabelle 1, Nummer 4).

Übergabepunkte und Verantwortlichkeiten

Nummer Inhalt  Von  An  Form Frist  Anmerkungen
1 Vorschlag geänderte Bestimmungen  CCC  LB/Fachaufsicht  E-Mail mit Anhang ---  ---
2  Geänderte Bestimmungen mit qualifizierter Stellungnahme LB/Fachaufsicht CCC  E-Mail mit Anhang 4 Wochen  Frist beginnt mit Eingang des Vorschlags
3  Konsolidierte Fassung der zu ändernden Bestimmungen  CCC LB/Fachaufsicht  E-Mail  ---  ---
4 Neue Version der Bestimmung (gegebenenfalls mit Frist zur Umsetzung)  CCC  LB/Fachaufsicht E-Mail (gegebenenfalls Papier) --- ---

Tabelle 1: Übergabepunkte und Verantwortlichkeiten Anpassung zentrale Regelungen

Eine Änderung der Richtlinien mit Systemrelevanz führt möglicherweise zu einem Folgeprozess (vergleiche Nummer 1.5.2).

1.2 Organisation

1.2.1 Lizenzen und Pflegekosten

Folgende Lizenztypen werden durch das CCC zentral vorgehalten:

  • Verschlüsselungslizenz
  • Developer
  • Professional
  • Limited professional
  • Sondernutzer 15 Transaktionen
  • Sondernutzer Employe CATS Eigene Zeiterfassung
  • Sondernutzer Employe CATS Sammelerfassung
  • Sondernutzer Elektronisches Warenhaus Eigene Erfassung
  • Sondernutzer Elektronisches Warenhaus Sammelerfassung.

Hier nicht aufgeführte Lizenztypen können durch den Landesbetrieb auf eigene Kosten über das CCC beschafft werden.

Unterscheidung Anschaffungs- und Pflegekosten

Lizenzkosten für die Nutzung des SAP-Systems/der SAP-Systeme werden unterschieden in Anschaffungs- und Pflegekosten:

  • Anschaffungskosten: Die Anschaffung und die dafür notwendige Bereitstellung von Haushaltsmitteln zentral vorgehaltener Lizenzen obliegen dem CCC. Diese Lizenzen werden in einen zentralen Lizenzpool eingestellt und bei Bedarf/bei Anfrage an die Landesbetriebe ausgegeben.
  • Pflegekosten: Durch die Beschaffung von Lizenzen fallen Pflegekosten an. Der Landesbetrieb ist an diesen zu beteiligen. Diese Beteiligung wird für die zentral vorgehaltenen Lizenztypen durch Berechnung einer Umlage und für nicht zentral vorgehaltene Lizenztypen durch unmittelbare Zuordnung ermittelt.

Lizenzen und Lizenzpool

Lizenzen werden nach Auslastungsgrad im Lizenzpool bei Bedarf beziehungsweise Erreichung eines prozentualen Schwellenwerts durch das CCC nachbeschafft.

Folgende Lizenztypen befinden sich derzeit beim Land Brandenburg im Einsatz:

Preisl. Staffelung  Lizenz
1 RE
2 Developer
3 Professional
4 Limited Professional
5 Transaktionen
6 CATS-Sammel
7 SRM
8 CATS-Einzel

Tabelle 2: Übersicht Lizenztypen

Die einzelnen Lizenzen unterscheiden sich im Umfang der Einsatzmöglichkeiten im SAP-System und sind preislich gestaffelt (siehe Tabelle 2; Preistyp 1: wertvollster Lizenztyp - Preistyp 8: preiswertester Lizenztyp).

Jede Aktivität in einem SAP-System ist lizenzpflichtig. Die Wahl des Lizenztyps hängt von der Menge und der Art der Transaktionen und der Nutzungshäufigkeit ab (vergleiche SAP Rahmenvertrag). Die folgende Tabelle gibt eine Übersicht über Lizenzen, die durch höherwertige Lizenztypen ersetzt werden können.

Lizenz  Kann ersetzt werden durch:
CATS-Einzel  Transaktionen, Limited Professional, Professional
SRM  Limited Professional, Professional
CATS-Sammel  Transaktionen, Limited Professional, Professional
Transaktionen   Limited Professional, Professional
Limited Professional Professional

Tabelle 3: Zuordnung möglicher höherwertiger Lizenztypen

Das CCC ist bestrebt vor der Neubeschaffung von Lizenzen zunächst die bestehenden Lizenzen soweit wie möglich an die Landesbetriebe auszugeben. Dies kann zu „Upgrades“ von Lizenzen führen (vergleiche Tabelle 3). Der anfordernde Landesbetrieb bekommt also eine höherwertige Lizenz als beantragt zur Verfügung gestellt, wenn die ursprünglich beantragte Lizenz nicht mehr verfügbar, jedoch eine höherwertige Lizenz die Anforderungen abdeckt und verfügbar ist.

Beantragung Lizenzen aus Lizenzpool

Für die Nutzung in den Systemen SAP R/3 und Solution-Manager sowie für zentral einzusetzende Software (zum Beispiel Verschlüsselung) werden Softwarelizenzen benötigt. Diese
Lizenzen werden durch das CCC auf Antrag und Genehmigung dem Bedarfsträger zugeteilt. Der Landesbetrieb ist verpflichtet, nicht mehr genutzte Lizenzen dem CCC zurückzugeben. Das CCC behält sich in begründeten Fällen vor, Lizenzen unter Einhaltung von Fristen einzuziehen.

Die oben zitierte Bestimmung bezieht sich ausschließlich auf zentral vorgehaltene Lizenzen.

Prozess

Je nach zu erfüllenden Aufgaben des einzelnen Nutzers in SAP ist die passende Lizenz aus dem Lizenzpool (zentral vorgehaltene Lizenzen) des CCC zu beantragen. Hierzu hat der LB einen ausgefüllten Antrag an das CCC zu übersenden (Tabelle 4, Nummer 1).

Nach dem internen Genehmigungsprozess des CCC wird der LB über die Lizenzbereitstellung beziehungsweise durch eine begründete Ablehnung informiert (Tabelle 4, Nummer 2).

Lizenzen, die dem Landesbetrieb aus dem zentral vorgehaltenen Lizenzpool zugeteilt waren und vom LB nicht mehr benötigt werden, sind zurückzugeben (Tabelle 4, Nummer 3).

Übergabepunkte und Verantwortlichkeiten

Nummer Inhalt Von  An  Form  Frist  Anmerkungen
1 Lizenzanforderung nach Bedarf LB CCC Lizenzmanagement Unterschriebener Antrag in Papierform  bis 01.11.  Für das laufende Jahr
2 Information über Lizenzbereitstellung beziehungsweise  begründete Ablehnung CCC Lizenzmanagement  LB
(Antragsteller) 		 E-Mail   3 Wochen  Frist beginnt mit  Eingang des Lizenzantrags im CCC
3 Lizenzrückgabe LB CCC Lizenzmanagement Unterschriebener Antrag in Papierform   bis 01.11.  Für das laufende Jahr

Tabelle 4: Übergabepunkte und Verantwortlichkeiten Lizenzanforderung und Rückgabe

Das CCC behält sich vor, zugewiesene höherwertige Lizenzen (Upgrade-Lizenzen) beim Landesbetrieb bei Verfügbarkeit der tatsächlich beantragten Lizenz wieder einzuziehen und durch die tatsächlich beantragte Lizenz zu ersetzen.

Die Systemvermessung wird auf Anforderung des CCC stichtagsbezogen durch den Landesbetrieb durchgeführt. Auf Verlangen des CCC kann die Firma SAP (Vertragspartner Enterprise-Support) im Landesbetrieb Vermessungsarbeiten durchführen. Die Ergebnisse dieser Vermessung sind dem CCC dann im Originalformat vorzulegen.

Prozess

Für die Ermittlung der Umlage der Lizenz-Pflegekosten ist zyklisch und bei Bedarf eine Systemvermessung durchzuführen1.

Der Stichtag für die Systemvermessung ist der 30. Juni des laufenden Jahres.

Hierzu informiert das CCC den LB über die anstehende Systemvermessung und gibt den Auftrag, die Vermessung durchzuführen (Tabelle 5, Nummer 1).

Der LB führt im Nachgang die Systemvermessung durch und sendet die Vermessungsstatistiken und die Protokolle der Systemvermessungen an das CCC innerhalb der gesetzten Frist zurück (Tabelle 5, Nummer 2).

Übergabepunkte und Verantwortlichkeiten

Nummer Inhalt Von  An  Form Frist Anmerkungen
1 Auftrag zur Systemvermessung CCC  LB E-Mail  1 Woche vor Vermessungstermin  
2 Vermessungsstatistiken und  Protokolle der Systemvermessungen LB   CCC  Papier unverzüglich am Vermessungstermin (Dienstschluss)  

Tabelle 5: Übergabepunkte und Verantwortlichkeiten Systemvermessung

Neben den Vermessungen zur Bestimmung der genutzten Lizenztypen für die Berechnung der Lizenz- und Pflegekosten behält sich das CCC vor, weitere Vermessungen anzufordern. Hierbei kommt der oben genannte Prozess zum Einsatz.

Die Pflegekosten für Softwarelizenzen sind durch den Landesbetrieb zu tragen. Diese orientieren sich an den durch den Landesbetrieb genutzten Lizenzen und werden auf Basis eines landesweit abgestimmten Verteilungsschlüssels ermittelt.

Das CCC hält ein Lizenzportfolio vor, um Bedarfsschwankungen innerhalb des Landes kurzfristig - gegebenenfalls auch durch höherwertige Lizenztypen (Lizenzupgrade) - auszugleichen.

Die Pflegekosten für Softwarelizenzen sind durch Verträge mit der SAP bestimmt.

Der LB beteiligt sich anteilig an diesen Pflegekosten.

Dieser Anteil ergibt sich aus einem Einzel- und Gemeinkostenanteil.

Einzelkosten

Sämtliche direkt zuordenbare Pflegekosten je Lizenztyp sind Einzelkosten.

Gemeinkosten

Sämtliche nicht direkt zuordenbare Pflegekosten sind Gemeinkosten.

Verteilungsschlüssel der Gemeinkosten

Die Gemeinkosten werden über einen Schlüssel landesweit umgelegt. Die Höhe des durch den LB zu tragenden prozentualen Gemeinkostenanteils errechnet sich aus dem Verhältnis der Einzelkosten je durch die Behörde genutzten Lizenzen zu den Pflegekosten der gesamten genutzten Lizenzen im NFM-Verbund.

Nutzerzahl

Maßstab für die Nutzerzahl bei der Berechnung der Pflegekosten ist die Anzahl der genehmigten Einzellizenzanträge. Sollte eine Vermessung zum Ergebnis führen, dass der LB mehr als durch das CCC genehmigte Nutzer im System hat(te), werden als Maßstab für die Nutzeranzahl diese zugrunde gelegt (vergleiche Fußnote 1).

Berechnung der Einzelkosten für jeden Lizenztyp

Die Höhe des Betrags - der durch den LB zu tragenden Pflegekosten pro genutzte Lizenz - ergibt sich aus den Pflegekosten gemäß SAP Rahmenvertrag pro Lizenz, multipliziert mit der Zahl der tatsächlichen Nutzungsdauer des LB in Tagen, geteilt durch 360.

Zahlungsverkehr

Die Pflegekosten sind in drei Abschlagszahlungen (30. März; 30. Juni; 30. September) und einer abschließenden Endabrechnung (15. Dezember) an das MdF zu entrichten.

Die Summe der einzelnen in gleicher Höhe zu leistenden Abschlagszahlungen (30. März; 30. Juni; 30. September) im Folgejahr bestimmt sich aus den tatsächlich dem LB zugeordneten Pflegekosten (Einzel- und Gemeinkosten) des laufenden Jahres.

Die Höhe der Abschlagszahlung des ersten Jahres wird im Einvernehmen mit dem LB abgestimmt.

Unregelmäßigkeiten zwischen den tatsächlich genutzten und den beantragten Lizenzen beim Landesbetrieb können zu Nachzahlungen an SAP führen. Diese Kosten sind durch den verursachenden Landesbetrieb zu tragen.

Übergabepunkte und Verantwortlichkeiten

Nummer Inhalt  Von An Form  Frist  Anmerkungen
1 Mitteilung über die Höhe der Abschlagszahlungen  CCC LB Papier 4 Wochen Vor nächstem Zahlungstermin der Abschlagszahlungen
2 Veranlassung der Zahlbarmachung der Abschlagszahlungen LB/vorgesetzte Behörde MdF  ---  ---  --- 
3 Mitteilung der tatsächlichen Pflegekosten in Form einer Endabrechnung unter Berücksichtigung der geleisteten Abschlagszahlungen CCC  LB/Spiegelreferat Papier bis 15.11.  --- 
4 Veranlassung der Zahlbarmachung  des Endabrechnungsbetrages LB/vorgesetzte Behörde  MdF  ---  bis 15.12.  --- 

Tabelle 6: Übergabepunkte und Verantwortlichkeiten Zahlungsverkehr

Für den Fall, dass dem LB mit Erstellen der Endabrechnung eine Gutschrift zusteht, wird ihm diese mitgeteilt.

1.2.2 Supportlevel

Keine Regelungen in den Durchführungsbestimmungen vorgesehen.

1.2.3 Systemerweiterungen und Releasewechsel

Genehmigungen für Modifikationen sind durch den Landesbetrieb beim CCC zu beantragen.

Genehmigungen für Erweiterungen im Rahmen von User-Exits, BAPIs etc. sind durch den Betriebsverantwortlichen beim CCC zu beantragen.

Prozess

Für beide Sachverhalte existiert kein Unterschied im Prozessablauf, daher wird der Prozess einmal dargestellt.

Der LB hat mit seinem Antrag folgende Nachweise vorzulegen (Tabelle 7, Nummer 1):

  • Änderungsantrag (Change) beim Systembetreiber einschließlich der Bestätigung der generellen Umsetzbarkeit
  • Erforderlichkeit der Modifikation, User-Exits, BAPIs etc. einschließlich der Prüfung von Alternativen (zum Beispiel SAP-Hinweise, OSS etc.).

Nach Prüfung des Antrages erfolgt:

  • die Genehmigung,
  • die Genehmigung unter Auflagen
  • oder die begründete Ablehnung

durch das CCC (Tabelle 7, Nummer 2).

Übergabepunkte und Verantwortlichkeiten

Nummer Inhalt Von  An  Form   Frist Anmerkungen
1 Ausgefüllter Genehmigungsantrag inklusive Anhang LB  CCC  Papierform und digital durchsuchbare(s) Dokument(e) --- ---
2 Mitteilung über Entscheidung zum Genehmigungsantrag CCC LB  Papierform  8 Wochen  ---

Tabelle 7: Übergabepunkte und Verantwortlichkeiten Systemerweiterungen

Die Gestaltung der SAP-Modullandschaft der Landesbetriebe ist dem CCC vorbehalten. Die Nutzung der Module Finanzwesen (FI), Anlagenbuchhaltung (FI-AA) und Controlling (CO) im Land Brandenburg ist fest vorgeschrieben. Die Einführung von weiteren Modulen ist möglich.

Prozess

Der LB hat mit seinem Antrag über die Einführung oder den Wegfall von Modulen folgende Nachweise vorzulegen (Tabelle 8, Nummer 1):

  • Änderungsantrag (Change) beim Systembetreiber einschließlich der Bestätigung der generellen Umsetzbarkeit
  • Erforderlichkeit der Moduleinführung beziehungsweise den Wegfall einschließlich der Prüfung von Alternativen
  • Genehmigung der Fachaufsicht
  • Darstellung erwarteter Lizenzbedarf
  • Wirtschaftlichkeitsbetrachtung

Nach Prüfung des Antrages erfolgt:

  • die Genehmigung,
  • die Genehmigung unter Auflagen
  • oder die begründete Ablehnung

durch das CCC (Tabelle 8, Nummer 2).

Übergabepunkte und Verantwortlichkeiten

Nummer Inhalt    Von   An  Form  Frist  Anmerkungen
1 Antrag über die Einführung oder den Wegfall von Modulen LB   CCC  Papierform und digital  durchsuchbares Dokument ---   ---
2 Entscheidung über die Einführung oder den Wegfall von Modulen CCC LB  Papierform  12 Wochen  ---

Tabelle 8: Übergabepunkte und Verantwortlichkeiten Erweiterung Modullandschaft

Releasewechsel durch den Landesbetrieb sind dem CCC vor Durchführung anzuzeigen.

Prozess

Der LB hat unaufgefordert das CCC über den Releasewechsel (geplantes Produktivsetzungsdatum, neuer Releasestand) zu informieren (Tabelle 9, Nummer 1).

Mit dem Releasewechsel einhergehende außerplanmäßige finanzielle Auswirkungen gehen zulasten des LB.

Übergabepunkte und Verantwortlichkeiten

Nummer Inhalt Von An Form Frist Anmerkungen
1 Information über Releasewechsel   LB CCC  Digital; PDF per Mail unverzüglich ---

Tabelle 9: Übergabepunkte und Verantwortlichkeiten Releasewechsel

1.3 Betrieb

1.3.1 Technische Durchführungsbestimmungen

Keine Regelungen in den Durchführungsbestimmungen vorgesehen.

1.3.2 Organisatorische Durchführungsbestimmungen

Mit Übernahme des eigenen Systems sind im Rahmen des jeweiligen Betriebsvertrags mit dem Systembetreiber die notwendigen Prozesse zu dokumentieren. Diese Dokumentation beschreibt Prozesse zwischen Systembetreiber und Landesbetrieb. Die internen Prozesse und Verantwortlichkeiten des Landesbetriebes sind unter Berücksichtigung der ressortspezifischen Vorgaben ebenfalls zu dokumentieren. Bezüglich dieser Dokumentationen hat der Landesbetrieb mindestens ein Dokument zu erstellen. Der Landesbetrieb hat ein Notfallhandbuch zu erstellen. Diese Dokumentationen sind aktuell zu halten und auf Anforderung dem CCC vorzulegen.

Prozess

Das CCC fordert oben genannte Dokumentation beim LB an (Tabelle 10, Nummer 1).

Der LB hat die angeforderte Dokumentation an das CCC zu senden (Tabelle 10, Nummer 2).

Das CCC teilt dem LB das Prüfungsergebnis mit (Tabelle 10, Nummer 3).

Übergabepunkte und Verantwortlichkeiten

Nummer Inhalt  Von  An Form Frist Anmerkungen
1 Anforderung jeweiliges Dokument CCC   LB E-Mail  ---  ---
2 Angeforderte Dokumente LB  CCC   E-Mail, elektronisches Dokument 6 Wochen  Frist beginnt mit Erhalt der E-Mail
3 Prüfungsergebnis   CCC LB  Papier  ---   ---

Tabelle 10: Übergabepunkte und Verantwortlichkeiten Fachkonzeptanforderung

Die Berechtigung zur Vergabe, Verwaltung und zum Entzug von Entwickler- und Objektschlüsseln (SSCR-Schlüsseln) wird durch das CCC personengebunden zugewiesen. Die Zuweisung wird auf die Installationsnummern der SAP-Systeme des Antragstellers beschränkt. Die Vergabe, die Verwaltung und der Entzug von Entwicklerschlüsseln obliegt den Landesbetrieben.

Jeder Landesbetrieb kann mindestens einen Entwicklerschlüssel vorhalten.

Prozess

Der LB übersendet bei Bedarf einen ausgefüllten personenscharfen OSS-User-Antrag mit der Benennung der genutzten Installationsnummern an das CCC (Tabelle 11, Nummer 1).

Nach dem internen Genehmigungsprozess des CCC wird der LB über die Bereitstellung des OSS-Nutzers beziehungsweise durch eine begründete Ablehnung informiert (Tabelle 11, Nummer 2).

Übergabepunkte und Verantwortlichkeiten

Nummer Inhalt  Von  An  Form  Frist  Anmerkungen
1 Ausgefüllter OSS-Nutzerantrag mit Angabe der Installationsnummern der genutzten SAP-Systeme LB CCC Unterschriebener Antrag in Papierform  ---  ---
2 Information über Bereitstellung des OSS-Nutzers inklusive Nutzername und Initialpasswort beziehungsweise begründete Ablehnung CCC  LB 
(Antragsteller)		 E-Mail  Fallabhängig ---

Tabelle 11: Übergabepunkte und Verantwortlichkeiten Entwicklerschlüssel

Der Landesbetrieb erhält die Möglichkeit, für seine Installation eigenständig OSS-Meldungen zu erstellen und einzusehen. Diese Möglichkeit, eigene OSS-Meldungen auszugeben, kann durch das CCC beschränkt werden. Diese Beschränkung erfolgt dann, wenn die Qualitätskontrolle der OSS-Meldung durch das CCC ergibt, dass notwendige Standards nicht eingehalten werden.

Notwendige Standards für OSS-Meldungen sind wie folgt definiert:

SAP Hinweis Nummer 67739 Definition der Prioritäten

SAP definiert die Prioritäten für Problemmeldungen wie folgt:

1. Sehr hoch:

Eine Meldung der Priorität „sehr hoch“ ist gerechtfertigt, wenn es zu sehr ernsten Beeinträchtigungen des normalen Geschäftsablaufs kommt. Arbeiten, die keinen Aufschub dulden, können nicht ausgeführt werden. Dies wird in der Regel durch folgende Umstände verursacht:

  • Völliger Ausfall eines Produktivsystems.
  • Gefährdung des kurzfristig bevorstehenden Produktivstarts oder Upgrades.
  • Das Kerngeschäft ist ernsthaft beeinträchtigt.
  • Es ist kein Work-Around verfügbar.
  • Die Meldung erfordert eine sofortige Bearbeitung, weil es durch die Störung zu erheblichen Velusten kommen kann.

2. Hoch:

Eine Meldung der Priorität „hoch“ ist gerechtfertigt, wenn es zu starken Beeinträchtigungen des normalen Geschäftsablaufs kommt. Notwendige Arbeiten können nicht durchgeführt werden. Dies wird durch eine fehlerhafte oder ausgefallene Funktionalität des SAP-Systems hervorgerufen, die in der aktuellen Situation dringend benötigt wird. Die Meldung erfordert eine baldige Bearbeitung, weil die andauernde Fehlfunktion zu einer ernsten Störung des gesamten produktiven Geschäftsablaufs führen kann.

3. Mittel:

Eine Meldung der Priorität „mittel“ ist gerechtfertigt, wenn es zu Beeinträchtigungen des normalen Geschäftsablaufs kommt. Dies wird durch eine fehlerhafte oder ausgefallene Funktionalität des SAP-Systems hervorgerufen.

4. Niedrig:

Eine Meldung der Priorität „niedrig“ ist gerechtfertigt, wenn es zu keinen oder geringen Beeinträchtigungen des normalen Geschäftsablaufs kommt. Dies wird durch eine fehlerhafte oder ausgefallene Funktionalität des SAP-Systems hervorgerufen, die nicht täglich benötigt oder nur wenig genutzt wird.

Einstufung von Testsystemen:

Gleiche Problemsituationen in Testsystemen führen in der Regel zu einer um eine Stufe niedrigeren Priorität als in Produktivsystemen.

Notwendige kundenseitige Voraussetzungen zur zeitnahen Bearbeitung von Meldungen der Priorität „sehr hoch“:

  • Der Remotezugriff auf das betreffende System muss gewährleistet sein.
  • Es muss ein Ansprechpartner zur Systemöffnung benannt sein, der
  • erreichbar ist
  • die erforderlichen Anmeldedaten nennen kann.
  • Ein Ansprechpartner für Rückfragen bezüglich des Problems muss erreichbar sein.
  • Die Problembeschreibung sollte möglichst detailliert sein, das heißt, die Meldung sollte/muss eine Beschreibung enthalten, wie das Problem nachvollzogen werden kann.
  • Um eine 7 x 24-Bearbeitung zu gewährleisten, muss die Problembeschreibung in englischer Sprache verfasst sein.

Tabelle 12: SAP Hinweis Nummer 67739

Situationsbeschreibung SAP Hinweis Nummer 16018

  • Wo befinden Sie sich?
    • Bitte geben Sie die System-ID (zum Beispiel ,P30‘), den Mandanten und den vollständigen Menüpfad an.
  • Was haben Sie ausgeführt?
    • Bitte geben Sie die Reihenfolge Ihrer Handlungen vollständig an.
    • Bitte nennen Sie die Werte aller Eingabefelder.
  • Was haben Sie erhalten?
    • Bitte geben Sie die Fehlernummer oder die Werte von Ergebnisfeldern an.
  • Was wollten Sie erhalten?
    • Bitte nennen Sie Ihre Erwartungen an das System in dieser Situation.
  • Ist das Problem reproduzierbar?
    • Wenn ja, so notieren Sie bitte ein vollständiges Beispiel in Ihrer Meldung.
  • Tritt das Problem seit einem besonderen Ereignis auf?
    • Wenn ja, so notieren Sie dieses bitte in Ihrer Meldung. (Zum Beispiel Upgrade, Einspielen eines Patches, Änderung der Hardwarekonfiguration, Mandantencopy, Altdatenübernahme ...)
  • Tritt das Problem bei allen Benutzern auf?
  • Welche Hinweise wurden zu diesem Thema schon berücksichtigt?
  • Gibt es besonderen Zeitdruck für die Lösung des Problems?
    • Bitte legen Sie die Priorität Ihrer Meldung entsprechend fest. Beachten Sie dabei bitte die Definition der Prioritäten. (F1-Hilfe für das Feld ,Priorität‘ oder Hinweis 67739.)
  • Themengebiet
    • Bitte geben Sie bei SAPNet - R/3 Frontend Meldungen die Komponente so präzise wie möglich an (F4-Hilfe), zum Beispiel „BC-DB-ORA“.
  • Ansprechpartner für den Inhalt der Meldung
    • Name, Abteilung, Telefon und Telefaxverbindung
  • Ansprechpartner für das Öffnen der Remoteverbindung
    • Name, Abteilung, Telefon und Telefaxverbindung
  • Gegebenenfalls Berater
    • Name, Firma, Telefon und Telefaxverbindung
  • Systeminformationen
    • Status des Systems Produktiv-, Entwicklungs-, Test- oder Demosystem
    • SAP-Release und Korrekturstand ersichtlich im Menü über „System † Status“, zum Beispiel 3.1I inklusive Hotpackage
    • Falls Sie ein IBU- oder Add-on-Produkt einsetzen, so geben Sie bitte dessen Bezeichnung und Releasestand an.
  • Remoteverbindung
    • Gibt es eine Remoteverbindung zum betroffenen R/3-System?
    • (Wenn nicht, so können Sie sich im Hinweis 35010 über die notwendigen Aktionen zur Einrichtung einer Remoteverbindung informieren.)
  • Relevante Mindestinformationen bei Problemen in den Anwendungen im Detail:
    • Menüpfad
    • Fehlernummer (5-stellig) (durch Doppelklick auf Statuszeile sichtbar)
    • Programminformationen (ersichtlich im Menü über „System † Status“):
      • System-ID
      • Mandant
      • Transaktion (4-stellig)
      • Programm (Dynpro)
        • Wurde das Programm modifiziert oder werden User-Exit verwendet?
        • Wurde das Programm online oder in der Hintergrundverarbeitung ausgeführt?
      • Dynpronummer
  • Bei Programmabbrüchen:
    • Bitte stellen Sie uns die ersten 12 Seiten des Kurzdumps zur Verfügung (zum Beispiel per Fax). (Eine Übersicht aller Abbrüche finden Sie mit der Transaktion ST22.)
    • Bitte stellen Sie uns die zeitlich relevanten Einträge im Syslog zur Verfügung. (Den Syslog können Sie mit der Transaktion SM21 anzeigen lassen.)
  • Gibt es Verbuchungsabbrüche? Wenn ja, welche? (Eine Übersicht aller Abbrüche finden Sie mit der Transaktion SM13.)
  • Gibt es Sperreinträge, die nicht freigegeben werden? Wenn ja, welche?

Tabelle 13: SAP Hinweis Nummer 16018

Der Landesbetrieb und seine ihm vorgesetzte oberste Landesbehörde sind gehalten, alle Aktivitäten, die Einfluss auf das NFM-System haben, mittel- und langfristig zu planen und das CCC darüber zu informieren. Hierzu zählen insbesondere folgende Aktivitäten:

  • die Anforderung des Lizenzerwerbs an das CCC
  • die Planung von Umstrukturierungsmaßnahmen, wie zum Beispiel:
  • Fusionen
  • Ausgliederungen
  • Überführungen in andere Rechtsformen
  • Rücküberführung in oberste Landesbehörden

Prozess

Der LB hat unaufgefordert das CCC über Planungen zu Aktivitäten mit Auswirkungen auf das NFM-System zu informieren (Tabelle 14, Nummer 1).

Mit den geplanten Aktivitäten einhergehende außerplanmäßige finanzielle Auswirkungen gehen zulasten des LB.

Übergabepunkte und Verantwortlichkeiten

Nummer Inhalt Von  An   Form  Frist  Anmerkungen
1 Information über Planungen zu Aktivitäten mit
Auswirkungen auf das NFM-System  		 LB   CCC  Digital; PDF per Mail   unverzüglich bei Fertigstellung der Planungsunterlagen  

Tabelle 14: Übergabepunkte und Verantwortlichkeiten Planungsunterlagen

1.3.3 Schnittstellen

Veränderung und die Neuentwicklung von Schnittstellen durch den Landesbetrieb ab dem Übergabezeitpunkt sind dem CCC zur Dokumentation in geeigneter - prüfbarer - Form vorzulegen.

Es wird empfohlen, vor Beginn der Konzeption von Veränderungen und Neuentwicklungen, das CCC in Kenntnis zu setzen.

Prozess

Der LB hat unaufgefordert die Dokumentation über Veränderung und die Neuentwicklung von Schnittstellen vor Produktivsetzung dem CCC zu übergeben (Tabelle 15, Nummer 1).

Übergabepunkte und Verantwortlichkeiten

Nummer Inhalt Von  An   Form  Frist  Anmerkungen
1 Dokumentation über Veränderung und Neuentwicklung von Schnittstellen  LB CCC Digital; PDF per Mail ---   vor Produktivsetzung

Tabelle 15: Übergabepunkte und Verantwortlichkeiten Schnittstellen

1.4 Datenschutz und IT-Sicherheit

Dem CCC sind der IT-Sicherheitsbeauftragte und der Datenschutzbeauftragte in Bezug auf das NFM namentlich zu benennen.

Prozess

Der LB hat unaufgefordert die Namen der/des IT-Sicherheitsbeauftragten und der/des Datenschutzbeauftragten in Bezug auf das NFM dem CCC mitzuteilen (Tabelle 16, Nummer 1).

Übergabepunkte und Verantwortlichkeiten

Nummer Inhalt Von An Form Frist Anmerkungen
1 Namentliche Nennung IT-Sicherheitsbeauftragte(r) und Datenschutzbeauftragte(r) in Bezug auf das NFM LB CCC Digital; PDF per Mail 1 Woche Bei Änderung der Verantwortlichkeiten ist das CCC gemäß Frist  zu informieren

Tabelle 16: Übergabepunkte und Verantwortlichkeiten Datenschutz und IT-Sicherheit

1.4.1 Rollen und Berechtigungen

Für den Fall, dass der Landesbetrieb Daten anderer Landesbetriebe bei der Systemtrennung erhalten hat, ist die Zugriffs- und Berechtigungssteuerung bis zur endgültigen Löschung dieser
Daten an den Systembetreiber zu übergeben. Zwischen dem Landesbetrieb und dem Systembetreiber ist vertraglich - gegebenenfalls über das CCC - sicherzustellen, dass der Systembetreiber die Zugriffs- und Berechtigungssteuerung so auszuführen hat, dass der von der Systemtrennung betroffene Landesbetrieb in keiner Form Zugriff oder Einsicht auf Daten anderer Landesbetriebe hat. Näheres wird in den Durchführungsbestimmungen geregelt.

Prozess

Bei Versagen der beantragten Rollen und Berechtigungen durch den Systembetreiber wendet sich der Landesbetrieb oder ein vom Landesbetrieb Beauftragter an das CCC (Tabelle 17, Nummer 1). Dort wird endgültig entschieden.

Übergabepunkte und Verantwortlichkeiten

Nummer Inhalt Von An Form Frist Anmerkungen
1 Begründeter Antrag für Zuteilung von Rollen und Berechtigungen  LB beziehungsweise sein Beauftragter  CCC  E-Mail   --- Das CCC ist bemüht, unverzüglich eine Entscheidung herbeizu führen

Tabelle 17: Übergabepunkte und Verantwortlichkeiten im Klärungsfall von Rollen und Berechtigungen

Der Landesbetrieb ist verpflichtet, die technischen Umsetzungsstände dieses Rollen- und Berechtigungskonzeptes zu dokumentieren. Die Dokumentation ist dem CCC auf Verlangen vorzulegen.

Prozess

Das CCC fordert die Dokumentation der technischen Umsetzungsstände vom LB an (Tabelle 18, Nummer 1).

Der LB stellt die notwendigen Unterlagen zusammen und versendet diese an das CCC (Tabelle 18, Nummer 2).

Das CCC prüft die Dokumentation und fordert gegebenenfalls eine Konkretisierung an (Tabelle 18, Nummer 3).

Der LB konkretisiert die Unterlagen und sendet diese erneut an das CCC (Tabelle 18, Nummer 4).

Übergabepunkte und Verantwortlichkeiten

Tabelle 18: Übergabepunkte und Verantwortlichkeiten der Dokumentation der technischen Umsetzungsstände für ein Rollen- und Berechtigungskonzept

Nummer Inhalt Von An Form Frist Anmerkungen
1 Anforderung Dokumentation der technischen Umsetzungsstände CCC  LB E-Mail   ---  ---
2 Dokumentation der technischen Umsetzungsstände   LB   CCC  E-Mail  4 Wochen  ---
3 Rückfrage mit Konkretisierungsbedarf   CCC LB E-Mail ---  ---
4 Dokumentation (konkretisiert)  LB CCC Digital per Mail 4 Wochen ---

1.5 Inhaltliche Durchführungsbestimmungen

1.5.1 Fachkonzepte

Jeder Landesbetrieb ist verpflichtet, ein auf sein spezifisches Bedürfnis zugeschnittenes Fachkonzept für die produktiv eingesetzten SAP-Module zu erstellen, zu pflegen und auf Verlangen dem CCC vorzulegen.

Prozess

Das CCC fordert die jeweiligen Fachkonzepte direkt beim LB an (Tabelle 19, Nummer 1).

Der LB hat die angeforderten Dokumente zusammenzustellen und an das CCC zu senden (Tabelle 19, Nummer 2).

Bei Feststellung nicht genehmigter Systemabweichungen wird das CCC einen entsprechenden Genehmigungsprozess (vergleiche Nummer 1.5.2) initiieren (Tabelle 19, Nummer 3).

Führt dieser initiierte Genehmigungsprozess zu einer Ablehnung, veranlasst das CCC - gegebenenfalls mit einer angemessenen Fristsetzung (Einzelfallentscheidung) - den LB die Rücknahme des Sachverhalts zu seinen Lasten vorzunehmen (Tabelle 19, Nummer 4).

Der LB informiert das CCC über die erfolgte Rücknahme (Tabelle 19, Nummer 5). Führt der LB die Rücknahme - innerhalb der gegebenenfalls gesetzten Frist - nicht durch, veranlasst das CCC den Systembetreiber die Rücknahme zulasten des LB vorzunehmen.

Übergabepunkte und Verantwortlichkeiten

Nummer Inhalt Von An Form Frist Anmerkungen
1 Anforderung jeweiliges Fachkonzept  CCC  LB E-Mail  ---  ---
2 Aktuell angefordertes Fachkonzept LB CCC E-Mail 2 Wochen Frist beginnt mit Erhalt der E-Mail
3 Initiierung des Genehmigungsprozesses CCC LB E-Mail ---  Gegebenenfalls
4 Begründete Ablehnung des Genehmigungsantrages und Veranlassung eines Rücknahmeprozesses CCC LB Papier ---  Gegebenenfalls
5 Bestätigung der erfolgten Rücknahme des Sachverhalts LB CCC Papier Fallabhängig  Gegebenenfalls

Tabelle 19: Übergabepunkte und Verantwortlichkeiten Fachkonzeptanforderung

1.5.2 Modulspezifische Vorgaben

Genehmigung2 von modulspezifischen Anpassungen der Module FI, CO, CATS, PS, MM, PM.

  • Neudefinitionen müssen beim CCC beantragt werden
  • (…) erfordert die Genehmigung durch CCC
  • (…) obliegen dem Vorbehalt durch das CCC
  • usw.

Prozess

Für oben genannte Sachverhalte der einzelnen Module existiert kein Unterschied im Prozessablauf, daher wird der Prozess einmal dargestellt.

Der LB hat mit seinem Antrag folgende Nachweise vorzulegen (Tabelle 7, Nummer 1):

  • Änderungsantrag (Change) beim Systembetreiber einschließlich der Bestätigung der generellen Umsetzbarkeit
  • Erforderlichkeit der modulspezifischen Anpassungen einschließlich der Prüfung von Alternativen.

Nach Prüfung des Antrages erfolgt:

  • die Genehmigung,
  • die Genehmigung unter Auflagen
  • oder die begründete Ablehnung

durch das CCC (Tabelle 7, Nummer 2).

Übergabepunkte und Verantwortlichkeiten

Nummer Inhalt Von An Form Frist Anmerkungen
1 Genehmigungsantrag modulspezifische Anpassung LB CCC  --- ---  ---
2 Mitteilung über Entscheidung zum Genehmigungsantrag CCC  LB  Papierform  8 Wochen ---

Tabelle 20: Übergabepunkte und Verantwortlichkeiten Genehmigung modulspezifische Anpassung

Bestimmungsmerkmale von Sachkonten erfolgen durch das CCC nach Vorschlag des Landesbetriebes zentral.

Die vorhandenen Mitarbeitergruppen sind zwingend beizubehalten. Eine Anpassung ist nur durch Zentralvorgabe des CCC zulässig.

Die vorhandenen Infotypen mit ihren Steuerungsmerkmalen sind beizubehalten. Eine Anpassung ist nur durch Zentralvorgabe des CCC zulässig.

Prozess

Der Prozess der modulspezifischen Zentralvorgabe unterscheidet sich weder je Modul noch im Ablauf; aus diesem Grund wird im Folgenden nur der Standardprozess dargestellt.

Das CCC erstellt ein Dokument mit allen erforderlichen Angaben. Dieses geht dem LB mit einer geplanten Umsetzungsfrist zu (Tabelle 21, Nummer 1).

Sofern der LB einen berechtigten Anpassungsbedarf an der vorgeschlagenen Umsetzungsfrist geltend macht, sendet er einen Terminvorschlag an das CCC zurück (Tabelle 21, Nummer 2).

Existiert kein Änderungsbedarf an der Umsetzungsfrist vonseiten des LB, gilt der Vorschlag des CCC als bestätigt.

Nach der finalen Festlegung der Umsetzungsfrist durch das CCC geht dem LB eine Aufforderung zur Durchführung der modulspezifischen Anpassung durch das CCC zu (Tabelle 21, Nummer 3).

Der LB ist in Abstimmung mit dem Systembetreiber für die fristgerechte Umsetzung der modulspezifischen Anpassung verantwortlich und berichtet über die erfolgte Umsetzung (Tabelle 21, Nummer 4).

Übergabepunkte und Verantwortlichkeiten

Nummer Inhalt Von An Form Frist Anmerkungen
1 Dokument mit allen erforderlichen  Angaben inklusive Umsetzungsfrist CCC  LB E-Mail; digitales  Dokument  --- ---
2 Vorschlag geänderte Umsetzungsfrist  LB CCC   E-Mail; digitales  Dokument 1 Woche Fristdauer gilt für das Senden desVorschlags, nicht für die eigentliche Umsetzung
3 Aufforderung zur Durchführung der modulspezifischen Anpassung mit verbindlicher Umsetzungsfrist CCC  LB Papierform  ---  ---
4  Bestätigung der erfolgten Umsetzung LB  CCC E-Mail  1 Woche Nach Ende Umsetzungsfrist

Tabelle 21: Übergabepunkte und Verantwortlichkeiten modulspezifische Anpassung durch Zentralvorgabe

In Kapitel „1.5.2 Modulspezifische Vorgaben“ der Richtlinien des CCC für die Steuerung eines verteilten NFM-Betriebes im Land Brandenburg wird an verschiedenen Stellen von einer Beantragung, Genehmigung oder dem Vorbehalt durch das CCC im Zusammenhang mit der Anpassung von modulspezifischen Einstellungen gesprochen. Bei diesen Formulierungen ist hierbei stets der nachfolgend skizzierte Prozess anzuwenden.

1 Unregelmäßigkeiten zwischen den tatsächlichen genutzten und den beantragten Lizenzen beim Landesbetrieb können zu Nachzahlungen an SAP führen. Diese Kosten sind duch den verursachenden Landesbetrieb zu tragen.

2 In Kapitel „1.5.2 Modelspezifische Vorgaben” der Richtlinien des CCC für die Steuerung eines verteilten NFM-Betriebes im Land Brandenburg wird an verschiedenen Stellen von einer Beantragung, Genehmigung oder dem Vorbehalt durch das CCC im Zusammenhang mit der Anpassung von modulspezifischen Einstellungen gesprochen. Bei diesen Formulierungen ist hierbei stets der nachfolgend skizzierte Prozess anzuwenden.