SAP: Usage Types und Processes erklärt

(Last Updated On: 27. März 2015)

SAP vertreibt verschiedene Produkte wie etwa den SAP NetWeaver, SAP Solution Manager etc. online über sein Software Download Center (http://service.sap.com/SWDC). Dort kann man sich die Installationsmedien für dieses Produkt herunterladen.

In diesen Installationsmedien sind alle Softwarekomponenten (software units) dieses SAP-produkts enthalten – ganz gleich, ob man diese später in seinem speziellen System braucht, oder nicht.

 

Es wäre natürlich kontraproduktiv, alle Softwarekomponenten zu installieren, ganz gleich ob man sie braucht oder nicht. Denn das würde zu unnötigen Performanceeinbußen durch Hardwarebelastung sowie durch unvorhergesehene Komplikationen zu Fehlern im System führen. Das wollen wir vermeiden.

Weil SAP-Berater Experten in ihrem Fach sind, installieren sie SAP-Produkte nicht einfach so drauf los. Sondern sie gehen mit einem Plan vor (erklärt in meinem Post SAP: Die PDf-Guides erklärt). Für jedes SAP-Produkt gibt es einen sogenannten Master Guide, der den SAP-Berater beim Planen der Implementierung eines SAP-Produkts unterstützen soll.

In diesen Master Guides geht es also darum, die Implementierung eines SAP-produktes zu planen – also sowohl in betriebswirtschaftlicher, als auch in informationstechnischer Sicht. Dabei stößt man auf die Frage, welche Softwarekomponenten man denn nun installieren soll, und welche nicht.

Um diese Entscheidung einfacher zu machen, hat SAP die Definition der sogenannten USage Types erstellt. Usage Types beschreiben einen ganz speziellen Zweck, den man mit diesem SAP-Produkt abbilden kann, etwa einen Service Desk, ein Central-SLD, oder ähnliches. SAP bindet an diese Usage Types, also an diese Nutzungsszenarien, einen Umfang an Softwarekomponenten (Installable Sotware Units), der installiert werden muss, um dieses Nutzungsszenario leisten zu können.

Das bedeutet: der SAP Systemadministrator plant seine Installation nur nach anhand von Usage Types, also daran, wie er das SAP-Produkt später nutzen will – und erfährt dadurch die zu installierenden Softwarekomponenten.

Die Usage Types, die der Administrator im Master Guide geplant hat, findet er später beim Installieren des SAP-.Produkts auch in der Installationsroutine wieder. hier kann er einfach die Usage Types auswählen, das Setup erkennt dann automatisch, welche Softwarekomponenten für diesen Usage Type installiert werden müssen.

Das, kurz gesagt, ist der Sinn von Usage Types. sie sind in jedem Master Guide in der Regel im Kapitel 4 beschrieben.

Neben den Usage Types spricht man im Master Guide auch von Processes – Prozessen. hier ist nicht von den Prozessen die Rede, die im Hintergrund auf einem Betriebssystem ablaufen, sondern sozusagen von Geschäftsprozessen, die betriebswirtschaftlich gesehen immer wieder im Unternehmen auftauchen.

diese Prozesse können beispielsweise das Rechnungsmanagement, die Materialverwaltung oder die Kundenbetreuung in einem Unternehmen sein, oder etwa der Service-Desk, der sich um die Probleme von Anwendern unserer SAP-Produkte kümmert und als Hotline zur Verfügung gestellt wird.

Diese Prozesse wiederum sind mit Usage Types verknüpft. Es kann sein, dass man für einen bestimmten Prozess mehrere Usage Types einplanen muss. Wenn man weiß, für welchen Prozess man welche Usage Types vorsehen muss, weiß der Administrator später, welche Usage Types er bei der installation eines Systems auswählen muss. Wählt er diese aus, werden dann automatisch die richtigen Softwarekomponenten installiert, um diesen Prozess abzubilden.

Bei der installation von Enhancement Packages in einem SAP-System begegnet man noch einer anderen Begrifflichkeit: Business Functions (BFs). im Endeffekt sind Business Functions neue, mit einem Enhancement Package hinzugekommene Funktionen in einem SAP-System. Diese Business Functions updaten bestimmte Softwarekomponenten eines SAP-Systems, um diese mit neuen Funtkionen zu bereichern.

So, wie bei der installation eines SAP-Systems Usage Types zu Prozessen zusammengefasst werden, werden Business Functions beim Update eines SAP-Systems zu sogenannten Technical Usages zusammengefasst.

Ein Technical Usage ist eine Zusammenfassung von Business Functions für eine bestimmte Produktinstanz.

So kann es etwa sein, dass man für eine bestimmtes technisches Nutzungsszenario verschiedene Business Functions installieren muss, die in der Regel zusammen in einem Erweiterungspaket ausgeliefert werden. Die einzelnen Business Functions werden dann auf diejeweiligen Softwarekomponenten anghewandt, die durch diese upgedatet werden.

 

Was sind Produkte und Softwarekomponenten?

ein produkt ist eine Applikation die bestimmte Geschäftsanforderungen eines Unternehmens erfüllt. Solche Produkte sind beispielsweise SAP ERP, SAP CRM usw. Produkte werden dabei unterteilt in Softwarekomponenten. So hat SAP ERP beispielsweise eine Softwarekomponente für sein HR-Modul, für sein FIN-Modul, aber auch Basismodule, die für den Netweaver zuständig sind – der sich wiederum darum kümmert, dass das produkt überhaupt läuft.

Zunächst einmal muss man verstehen, dass ein SAP-System aus verschiedenen Komponenten besteht. Es gibt sogenannte Basis-Komponenten, die für den Betrieb der Grundplattform, auf welcher alle SAP-Produkte laufen, zuständig sind. Das sind also die Softwarekomponenten für den Betrieb der netWeaver-plattform. Und es gibt Application-based Softwarekomponenten, die sich je nach installiertem SAP-produkt und -Release unterscheiden und für die Bereitstellung der Funktionen dieser Applikationen zuständig sind.

2015-03-16_08h14_36

eine Softawrekomponente ist die kleinste verwaltbare Einheit im SAP-Softwaremodell. Sie sind deshalb auch die Basis für die anwendung von Support Packages. Eine Softwarekomponente wird dabei einer oder mehreren Produktinstanzen zugeordnet.

Was ist eine Produktinstanz?

Eine Produktinstanz ist ein Bündel aus Softwarekomponenten die sich gegenseitig brauchen, um auf einem System lauffähig zu sein. Sie müssen auf einem einzigen technischen System installiert werden. Ein technisches System ist dabei sozusagen SAP-Software, die sich auf einem einzigen Host befindet (die Datenbank darf heirbei noch auf einem anderen Host liegen). Das gesamte Produkt / SAP-System an sich kann auf mehrere Hosts verteilt sein, es können auch mehrere produkte auf einem einzigen physikalischen Host installiert sein. Aber die Softwarekomponenten in einer Produktinstanz müssen zusammen auf einem einzige tecnischen System installiert sein, damit sie laufen.

Produktinstanzen sind beispielsweise die TREX-Suchengine, die beim Suchen von Begriffen in einem SAP-System zum Einsatz kommen, oder einer der jeweiligen Applikationssofwtarekomponetnen wie beispielsweise SAP_HR, die wiederum abhängig davon sind, dass auf dem selben technischen System die Komponente SAP_APPL läuft. Dann machen SAP_HR und SAP_APPL zusammen eien Produktinstanz aus. Dabei wird auch ersichtlich, dass eine einzige Softwarekomponente bestandteil mehrerer Produktinstanzen sein kann. SAP_APPL wäre beispielsweise Bestandteil sowohl von der Produktinstanz Human REsources – zu welcher SAP_HR und SAP_APPL gehören, als auch der Produktinstanz Retail, zu der SAP_Retail und SAP_APPL gehören.

Heutzutage werden produktinstanzen dazu genutzt, um Usage Types und Technical Usages zu ersetzen (siehe unten). Eine Produktinstanz ist also ein neuerer Begriff für diese beiden älteren Definitionen.

Wenn man im Maintenance Optimizers updates für ein System durchführt, dann kann man diese Produktinstanzen auswählen, um diese getrennt voneinander zu updaten.

Was sind technical systems und product systems?

Wie bereits angeschnitten, kann eine bestimmte  Produktinstanz eines SAP-produkts auf verschiedenen Systemen installiert sein. Man muss nicht ein SAP-produkta uf einem einzigen physikalischen Host installieren. Man aknn beispielsweise die Produktinstanz TREX, also die Suchengine für die Suchfunktion, auf einem anderen Host haben. Ein Technical System enthält also eine oder mehrere Produktinstanzen eines SAP-produkts, welches der SAP-Kunde in seiner Systemalandschaft einsetzt. Dabei können auf einem physikalischen Host mehrere technische Systeme sein – soll heißen: auf eniem physikalsichen Host können die Produktinstanzen verschiedener SAP-Produkte installiert sein. So kann man auf einem Server beispeilsweise sowohl produktinstanzen für SAP ERP, als auch für SAP CRM installieren.

Unter dem Begriff Product Systems fasst man nun alle technischen Systeme zusammen, die zusammengenommen ein installiertes SAP-Produkt formen. So kann man ein SAP ERP Product System beispielsweise aus einem technischen Ssytem für die Scuhengine TREX, einem Technischen Sytem für Human Resources und einem technischen System für Retail bestehen. Auf jedem technischen System läuft dabei die entsprechende Produktinstanz.

Was ist eine Produktversion?

Wie wir bereits gelernt haben, macht ein Product System ein bestimmtes installiertes SAP-Gesamtprodukt aus, welches ein SAP-Kunde einsetzt. Dieses product System als ganzes amcht also ein installiertes SAP-produkt aus, welches wiederum eine bestimmte Version hat. Bei der Version gibt man in der Regel den Release des SAP-rpodukts an, also beispielsweise SAP R/3, SAP ERP 2005, SAP ERP 6.0 – das sind jeweils aufeinanderfolgende Releaseversionen.

Releases sind sogenannte standalone Versions. Diese Produkte laufen ohne irgendwelche Zusatzprodukte von sich aus. Zu diese standalone produktversionen gibt es noch Add-on Produktversionen. :Das heißt, man kann bestimmte Erweiterungspakete (Enhancement Packages) installieren, die ein bestimmtes Release nochmal um einige funktionen erweitern. Die aktuelle Add-on-Version von SAP ERP 6.0 beispielsweise wäre

SAP ERP 6.0 and SAP EHP 7 for SAP ERP 6.0 – und sagt aus, dass auf den Release SAP ERP 6.0 das Erweiterungspakete EHP 7 aufgespielt wurde.

eien kleine besonderheit hierbei ist, dass EHP-Versionen des SAP Netweaver als standalone-Produktversion gelten. Die Produktversion SAP EHP1 for SAP NetWeaver 7.3 beispielsweise wäre eine standalone Produktversion.

Was ist eine Technical usage und was ist eien Business Function (BF) / Business Scenarios?

eine Business Function ist eine geschäftsbezogene Funktion in einem SAP-Produkt, die durch ein Bündel aus produktinstanzen oder einzelnen Softwarekomponenten bereitgestellt werden. Dabei kann eine Business Function auch einfach nur von einer einzigen Softwarekomponente oder von einer einzigen Produktinstanz bereitgestellt werden. Business Functions können auch neu dazu gekommen, wenn man ein Enhancement Package in eine Produktversio einspielt. Dann werden eine oder mehrere bestehende Softwarekomponenten so geupdatet, dass die entsprechende Business Function bereitgestellt werden kann. Wenn eine Business Function durch eine Transaktion im SAP-System abgebildet werden kann, bezeichnet man sie auch als Business Scenario. In der Regel ist es Aufgabe des sogeannnten Business project experts, die benötigten Business Functions und Business Scenarios, die innerhalb des SAP-Systems für das jeweilige Unternehmen gebraucht werden, zusammenzuführen. Der SAP-Systemadministrator muss dann auf der technischen Setie dafür sorgen, dass den Usern später diese Business Functions oder Business Scenarios zur Verfügung stehen.

Eine Technical Usage ist eine Art und Weise, verschiedene Produktinstanzen eines SAP-produkts auf technische Art und Weise zu verwenden. Alle für idese Technical Usage notwendigen produktinstanzen müssen installiert sein, damit diese angewandt werden aknn Jede Business Function ist einer technical usage zugeordnet – eine technical usage kanna us mehreren Business Functions bestehen. Eine Technical Usage muss installiert werden, um diese mit ihr verbundenen Business Functions bereitstellen zu können. Man kann dann beispielsweise im Solution Manager auswählen, welche Technical Usages man in seinem System haben möchte, um bestimmte Business Functions nutzen zu können – wenn man ein System updatet. Der soMan schlägt dann vor, welche Erweiterungspakete und Support Packages eingespielt werden müssen, damit diese technical usages bereitgestellt werden können. Aber auch bei der Neuinstallation eines SAP-Systems kann der Systemadministrator diese Technical Usages auswählen.

In der folgenden Abbildung sehen wir, dass mit dem SAP EHP7 eine neue Business Function namnes GEneral Ledger Account hinzugekommen ist. damit wir diese BF nutzen können, müssen wir die Technical Usage Central Application auswählen, wodurch dann der MOPZ des Solution Managers für uns die benötigten Updates (darunter das EHP7) auswählt. Dadurch werden die benötigten Softwarekomponenten wie beispielsweise SAP_APPL aktualsiiert, so dass im Endeffekt die gewünschte Business Function genutzt werden kann.

2015-03-16_08h23_00

zunächst einmal muss man natürlich immer wissen, welche Business Functions man braucht. Dazu liefert SAP unter service.sap.com/erp-ehp / Business Functions in detail eine Liste aller Business Functions von EHP 1 zu EHP 7. Wenn man nur die Business Functions wissen möchte, die in einem bestimmten EHP dazu gekommen sind, dann guckt man am besten in die Release notes unter services.sap.com/erp-ehp / Release notes. Das ist jedoch in der Regel Aufgabe des Business Process Experts – es schadet jedoch nicht, grundsätzlich einen Einblick in die thematik zu haben.

Damit wir dann wissen, welche Technical Usages wir für diese Business Functions installieren müssen, können wir ebenfalls in services.sap.com/erp-ehp / Business Functions nachsehen oder uns die SAP Note 1818596 durchlesen.

Was sind Enterprise Services?

Na, raucht der Kopf schon? Das ganze geht noch komplizierter.

Mit der einführung der serviceorientierten Architektur (SOA) hat SAP begonnen, mit seinen Produkten sogeannnte Enterprise-Services auszuliefern. Enterprise-SErvices sind sozusagen Dienste, die mit Hilfe von SAP-Produkten angeboten werden. Die Diente sind in der ES-Wiki aufgezeichnet. Für jeden Dienst braucht man verschiedene Softwarekomponenten in einer bestimmten Version und bestimmte Business Functions, die aktiviert werden müssen.

Was wir zu diesem Zeitpunkt haben ist, welche Softwarekomponenten in welcher Version und welche Business Functions wird brauchen, um einen bestimmten Enterprise Service nutzen zu können. Aber wie wir ja wissen, brauchen wir zum updaten eines Systems über MOPZ die sogenannten TEchnical Usages. Deswegen muss man in einer SAP-note, aktuell die SAP Note 1818596 schauen, welche technical usages für diese sofwtarekompoennten / business functions notwendig sind.

Was sind Usage TypeS?

Usage Types definieren wie bestimmte Installationen einer SAP produktversion genutzt werden sollen und welche Möglichkeiten welcher Usage Type der IT-Systemlandschaft bietet. Sie sind daher im wesentlichen vergleichbar mit Business Functions. softwarekomponenten werden mit Usage Types verbunden, ähnlich wie sie andernorts auch mit bestimmten Business Functions und somit mit Technical Usages verbunden werden. Usage Types können auch mit produktinstanzen verbunden sein, die für diesen Usage Type installiert werden müssen.

Was sind installable software units?

installable software units sind produktinstanzen, die beim upgrade oder bei der installation einer SAP-produktversion mitinstalliert werden müssen, damit bestimmte Usage Types durch das System realisiert werden können. Usage Types sind also im Wesentlichen vergleichbar mit Technical Usages. Aber auch Standalone-Engines, die ohne ein übergeordnetes SAP-produkt lauffähig sind, also nicht von einem anderen SAP-produkt abhängig sind (etwa die Suchengine TREX), sind installable Software Units. Diese können (oder müssen) zusätzlich zum eigentlichen SAP-produkt installiert und eigenständig betrieben werden.

Installable Software Units können also sowohl Produktinstanzen sein, die von einem bestehenden SAP Produkt abhängig sind und in einer extra Instanz dieses Produkts betribeen werden, aber auch Standalone Engines, die keine Instanznummer bekommen und daher nicht vom System des Hauptprodukts abhängig sind.

Andreas Loibl ist SAP-Berater, Ethical Hacker und Online Marketing Manager und schreibt auf seinem Blog DaFRK Blog über verschiedene Themen in den Sektoren Projektmanagement, Informationstechnik, Persönlichkeitsentwicklung, Finanzen und Zeitmanagement.

DaFRK

Andreas Loibl ist SAP-Berater, Ethical Hacker und Online Marketing Manager und schreibt auf seinem Blog DaFRK Blog über verschiedene Themen in den Sektoren Projektmanagement, Informationstechnik, Persönlichkeitsentwicklung, Finanzen und Zeitmanagement.

Das könnte Dich auch interessieren …

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.