SAP Sizing Tool erklärt

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

Wenn ihr ein SAP-Produkt in eure Systemlandschaft integrieren und aufsetzen wollt, empfiehlt es sich grundsätzlich nicht, blind darauf los zu installieren. SAP-Berater sind deshalb als professionelle ITler beworben, weil Sie professionelle Planungsschritte unternehmen, bevor Sie ein SAP-Produkt aufsetzen.

Zunächst einmal müsst Ihr die Softwareabhängigkeiten planen. Dazu gehört, auf welchem betriebssystem und auf welchem Datenbankmanagementsystem ihr das SAP-Produkt laufen lassen wollt, mit welcher Sprache ihr das produkt installieren wollt, und mit welchen Browsern ihr auf das Frontend des SAP-Produkts zugreifen wollt.

Zunächst einmal sind dieses Fragen der persönlichen Vorlieben. Will man ein SAP-Produkt auf einem windows-Serverbetriebssystem haben, empfiehlt es sich z. B., einen micrsooft SQL Server zu verwenden. Vielleicht hat man aber bereits eine Lizenz für Oracle Database erworben, die man weiternutzen möchte. Grundsätzlich ist der aktuelle Trend, SAP-Produkte auf unix-basierten Betriebssystemen mit SAP-HANA als DBMS zu bringen, aber Ausnahmen bestätigen die Regel.

Unabhäöngig von den persönlichen Präferenzen muss man aber prüfen, ob gewünschtes DBMS, Betriebssystem, Sprache und Browser für das gewünschte SAP-Produkt verfügbar sind.

Diese Frage beantwortet die Product Availability Matrix, die ich in meinem Post Die Product Availability Matrix erklärt genau beschrieben habe.

Nur weil man jetzt weiß, mit welchem Datenbankmanagementsystem beiuspielsweise das Produtk lauffähig ist, weiß man noch lange nicht die exakte Version des DBMS, auf dem das Produtk lauffähig ist. Fragen zur exakten Version von DBMS, Betriebssystem und Browser werden nicht immer und manchmal nur eingeschränkt von der PAM beantwortet. Die detaillierten Antworten findet man im Master Guide zur Installation des SAP-Produkts. Wie man zum master Guide kommt und was er einem erzählt, habe ich in meinem Post Die PDF-Guides erklärt aufgeführt. In einem solchen Master Guide gibt es in der Regel ein Kapitel Major Planning Steps, in denen dann ein Schritt Hardware & Software REquirements beschrieben ist. Dort wird man in der Regel auf SAP Notes weitergeleitet, die einem dann die Versionen und Abhängigkeiten für das gewünshcte OS/DBMS aufzeigen.

So weit so gut, die Softwareabhängigkeiten sind geplant. Jetzt müssen Sie, abhängig von der Systemlandschaft und der voraussichtlichen Last des Systems, die Hardwareabhängigkeiten planen.

das wiederum geht mit dem SAP sizing Tool, welches Sie unter http://service.sap.com/sizing erreichen können. Sizing ist ein allgemeiner Begriffe aus dem IT Management, bei welchem es um das Planen von IT-Ressourcen zur Erbringung von IT-Dienstleistungen geht. Sizing bedeutet das Ermitteln der Hardwareanforderungen für diese Dienstleistung im hinblick auf Netzwerkbandbreite, Arbeitsspeicher, Speicherplatz, CPU Power in SAPS und die Eingabe/Ausgabe-Kapazität des Systems. Diese ressourcen sind abhängig von der Beschaffenheit der dienstleistung an sich, in unserem Fall also beispielsweise von den Mindestanforderungen des SAP Produkts, und dem Lastaufkommen in Abhängigkeit von den Businessanforderungen des Unternehmens,a slo beispielsweise, wie viele User zu Spitzenzeiten gleichzeitig auf die Dienstleistung zugreifen werden.

Erst nach der Ermittlung des Sizings wird eine IT-Landschaftsarchitektur aufgesetzt. Hat man im Sizing etwa ermittelt, dass man viele Daten auf Festplatten speichern, lesen und verarbeiten muss, setzt man erst ein Storage Attached Network auf, um diese Daten schnell übertragen zu können. Oder erst wenn man merkt, dass man mit einem der im Serverraum stehenden SErveranlagen die ermittelten Hardwareanforderungen nicht erfüllt, schafft man sich entweder eine neue Anlage an oder schaltet mehrere Server in einen Lastverbund, also in einen Cluster. Ausnahmen bilden natürlich die Regel: Bestimmte LAndschaftsentscheidungen hat man evtl. bereits vor dem Sizing getroffen, beispielsweise, dass man ein hochverfügbares System haben will, also Server, die einspringen, wenn ein anderer server ausfällt, usw. Das berücksichtigt man im Sizing, indem beispielsweise auch die Ersatzserver die Hardrwareanforderungen erfüllen müssen.

SAP hat zur bewertung von IT-Systemen, auf denen SAP Produkte laufen sollen, eine Maßeinheit eingeführt – SAP Application Performance Standard (SAPS). 100 SAPS ist die (Hardware-)Power eines IT-Systems,d ie bneötigt wird, um im SAP-Modul Sales and Distribution (SD) 2000 vollständig geschäftsprozessablaufende  Bestellvorgänge zu verarbeiten – also die Bestellung erstellen, eine Lieferbestätiogung erstellen, die Bestellung anzeigen, die Lieferung zu bearbeiten, eine Rechnung zu erstellen usw. Diese Leistung, die ein SAP-System vollbringt, wird in diesem Benchmark simuliert und getestet. Dieselbe Leistung wird beispielsweise gebraucht, wenn SAP-Anwender  6 000 Dialogschritte durchführen (Bildschirmwechsel afu dem Frontend), 2 000 Postings pro Stunde im SD-Modul tätigen, oder 2 400 SAP Transkationen ausführen. Diese Maßeinheit ist sozusagen ein indikator dafür, wie leistungsfähig ein SAP-Produkt auf diesem IT-System laufen wird. Die SAPS-Zahl für ein System kann man mit einem Benchmark, der von SAP zur verfügung gestellt wird, ermitteln.

Desweiteren gibt es noch andere Maßzahlen, mit denen man IT-Systeme bewerten kann. die Maßzahlen werden, wie aus der betriebswirtschaftslehre auch bekannt, Key Performance indicators (KPI) genannt. In der Disziplin der IT-Architektur kennt man KPIs wie beispielsweise Throughput oder Server REsponse Time für Single Processes. SAP misst Systeme gerne mit der KPI Single Computing Unit Performance (SCU performance), die von SAP selbst eingeführt wurde.  Die SCU spricht die für Verarbeitungsleistung einer einzigen rechnereinheit in einem System. Eine solche Einheit kann sein: ein einziger Thread in einer Multithread-CPU, ein Kern in einem Mehrkernprozessor, oder irgendeine andere Individualeinheit, die in Summe eine CPU ausmacht. Bis ins Jahr ~2006 hinein wurde eine einzelne SCU eines Prozessors immer leistungsfähiger – wir erinnern uns: damals stiegen die Taktraten der CPUs immer weiter an. seit etwa 5-8 Jahren stagnieren aber die MÖglichketien einer Taktraterhöhung der einzenen SCUs, weshalb sich Prozesshorsteller darauf spezialsiieren, mehrere SCUs parallel betreiben zu können – weswegen zunehmend Multihreading- und Multicore-Prozessoren hergestellt werden.

Abhängig vom eingesetzten SAP-Produkt, skaliert dieses sehr gut mit zunehmender Anzahl von SCUs, oder weniger gut. Je weniger gut das Produkt skaliert, desto wichtiger sit die Leistung einer einzelnen SCU. Es gibt durchaus Prozesse, die nicht gut von Mehrkern-Architektur bewältigt werden können, vielmehr kommt es hier ebena uf die Leistungsfähigkeit einer SCU an. Ansonsten könnte man ja einfach die SAPS, die eine einzelne SCU schafft (aktuelle Systeme schaffen über 2 000 SAPS pro SCU), zusammenzählen und schauen, ob man die Gesamt-SAPS-Zahl, die für das System notwendig sind, erfüllt. So einfach ist es aber leider nicht.

In Abhängigkeit von der SCU Performance, werdne die SAP-Produkte in Klassen eingeteilt:

  • A – das SAP-produkt profitiert von guteri SCU Performance
  • AA  -das SAP-produkt profitiert von sehr guter SCU Performance
  • AAA – das SAP-produkt profitiert von exzellenter SCU Performance.

In der Übersicht sehen Sie bereits einige Quick Links, die oft von Besuchern angeklickt werden.

2015-01-09_11h12_26

Der Sizing Decision Tree dient als Einstiegspunkt für Besucher, die noch nicht genau wissen, was sie wollen. Hier habt Ihr bestimmte Links, die euch näher an euer Ziel heranführen sollen.

2015-01-09_11h13_56

Der SAP quick Sizer

Kann erreicht werden über http://service.sap.com/quicksizing.

Der SAP Quick Sizer dient dazu, festzustellen, welche SAPS-Werte für das Produkt insgeasmt inklusive Datenbank und Produkt, SAPS-Werte für die Datenbank, SAPS-Werte für das produkt und welche SCU-klasse für das Produkt empfohlen wird. Damit diese produkte ermittelt werden können, muss der Anwender bestimmte Fragen zur künftigen Nutzung des Produkts – also beispielswiese Useraufkommen – beantworten. Diese Fragen  beantwortet in der Regel kein technischer Berater, sondern ein unternehmerischer Berater, der anhand d er Bedürfniusse des Unternehmens feststellen kann, wie hoch sein Useraufkommen zu Spitzenzeiten sein wird.

Der Anwender erstellt dazu ein Quick Sizing Projekt. Mit diesem Quick Sizing Projekt ist es SAP möglich, dem Kunden mit seinen Tools, demn quick Sizer und den Standard Application Benchmarks, Empfehlungen für seine Ansprüche auszusprehcen. Desweiteren muss der Anwender später den Namen des Sizing Projekts an einen SAP-Hardware-Partner weitergeben, wenn er die Hardware von diesem beziehen will.

Der SAP Quick sizer ist also immer der erste Schritt zur Feststellung von SAP hrdwreparametern. Sehen wir uns mal ein Beispiel an.

2015-01-09_11h33_24

Im beispeil sehen wir, dass wir für SAP CRM insgesamt 9200 SAPS brauchen würden. Würden wir ide Datenbank getrennt vom Produkt selbst betreiben wollen, bräuchten wir für die DB 1 300 SAPS und für das Produkt selbst 7 900 SAPS. desweiteren rbauchen wir eine SCU klasse von AAA.

Im Sizing Tool können Sie dann ein Sizing Projekt erstellen. Die Kundennummer, die ihnen als Berater vorgeschlagen wird, sind Sie selber – wenn Sie für den Kunden das Sizing erstellen, können Sie diese Nummer dort stehen lassen. Vergeben Sie dann nur noch einen Namen für das Sizing projekt und schon können Sie lsolegen.

Angekommen finden Sie folgende Übersicht

2015-03-10_16h40_05

Im Baum links wählen Sie nun das SAP Produkt, das am ehesten auf Ihr zu sizendes produkt zutrifft. Im Zweifel, wenn Sie gar keine Ahnung haben, wählen Sie wie im Bild gezeigt SAP ERP.

Als erstes sagt ihnen der Kunde, wie viele Nuzter zur Lastzeit auf seinem System gleichzeitig arbeiten. Dabei sollte man dei Nutzer in drei Kategorien einteilen.

  • Low-Activity User: Benutzer, die nur alle 300 Sekunden oder später eine Aktivität (z. B. einen Klick) in SAPGUI durchführen
  • Medium-activity User: Benutzer, die alle 30 Sekunden eine neue Aktivität in SAPGUI durchführen
  • High-Activity User: Benutzer,die alle 10 Sekudnen eine neue Aktivität in SAPGUI durchführen.

Wenn Sie diese drei Zahlen haben, erstellen Sei in dem zu sizenden produkt diese Userzahlen. DA FI-User ein ziemlich guter Ausgangswert sind, erstellen wir einfach mal ein Sizing für ein System mit 5 Usern.

 

für den nächsten Punkt des Throughput-Sizings habe ich mich an den Principles of User and Troughput Sizing, Qucik Sizer for Beginners, Quick Sizer Best Practices orientiert.

Demnach sind Object die Anzahl der druch die benutzer erstellten Objekte wie beispielsweise Bestellungen, Projekte, gedruckte Dokumente im spooler, Reisekostenabrechnungen etc. und Datensätze, die über transaktionsschritte in SAPGUI eingetragen und bearbeitet werden. In einer fiktiven Lastübersicht des Kunden in einem Zeitraum von 9 Stunden haben wir etwa 92 Dialogschritte – und die meisten Transaktionen werden schon nach jedem 1. oder 2. Bildschirm einen Datensatz bearbeiten oder erzeugen, wechsle ich die Zeitperiode unter TI auf Peak (P) im Troughpout des FIN Banking Moduls, gebe eine Zeitperiode von 0-9 ein und gebe estaml 70 Objekte ein. Nun muss man einberechnen, dass der Aufwand mit der neuen Umstellung im Planungshorizont vom ersten Jahr nach der Umstellung etwas steigen wird, deswegen erhöhen die Anzahl der Objekte auf 90. Da wir das Zeitintervall auf Peak gestellt haben, müssen wir keine Residence-Time eingeben, die bei der Zeitperiode Year (Y) aussagen würde, wie lange die verarbeiteten Objekte in der datenbank liegen, bis sie archiviert werden (in monaten). Beachten Sei, dass es auch objekte gibt, die nur sehr kurz im System verweilen, etwa Idocs, WORKFLOWS, SPOOL Jobs, batch input jobs, jb logs etc.

In der nächsten Spalte sollen wir die Anzahl an Subobjekten wie beispielsweise Einzelposten, Schlüsselwerte etc. eingeben, die pro bearbeitetes Objekt auftreten. Da sich hierbei die transaktionen im System wiederum unterscheiden, muss ma sich einer Schätzung behelfen. In unserem Beispiel stehen eigentlich immer zwei Objekte miteinander in Wechselwirkung – User und Profile, RFC-Verbindungen und Logische Systeme usw. In Verbindung mit eventuellen Schlüsselreferenzen auf andere Objekte bewerte ich deshalb vier als angemessene Zahl.

Es hätte natürlich auch die Möglichkeit gegeben, im Bereich weiter unten das Sizing für Transaktionen ohne Subobjekte anzugeben. Stattdessen löschen wir hier alle Zeilen, genau so wie wir die übrigen Default-Zeilen im throughput-Sizing löschen.

als Ergebnis erhalten wir

2015-03-11_08h01_21

Wir haben als Ergebnis die infromationen über

  • die erforderliche herstellerunabhängige CPU-Power in SAPS
  • den erforderlichen Plattenspeicherpaltz in MB
  • die Arbeitsspeicherkaapazität in MB
  • und eine klassifizierung der IOPS (eingabe-ausgabe-Operationen pro Sekunde)

Es gibt Produkte im Sizing Tool, die wie das obige Beispiel sowohl User- als auch Troughput-basiertes Sizing anbieten. Andere lösungen wie beispielsweise SAP PI / XI bietet kein user-basiertes Sizing an, da es als Middleware-komponente keine Dialogschritte verarbeitet, deswegen ist hier lediglcih das throughput-sizing interessant.

Das initiale Sizing ist dabei immer ein sehr grober Ansatz. Mans ollte sich nicht alleine auf ein user Sizing veralssen, wenn das Ergebnis höher als 5 000 SAPS ausfällt. Denn das User Sizing alleine bezieht keine Hintergrundprozesse, interfaces usw. in Betracht.

Wie bereits oben ersichtlich gewesen, haben wir beim Throughput-Sizing die möglichkeit, anhand des gewählten Zeitintervalls (TI) ein Average-Sizing zu machen (A) oder ein Peak-sizing (P). Wenn man nur ein System zur Verfügung hat, macht man immer ein Peak-sizing – denn dann muss das System dazu in der Lage sein, nicht nur die niedriger ausfallende Last im Durchschnitt, sondern auch die Spitzenlastzeiten – zum Beispiel im weihnachtsgeschäft – zu tragen.

Wenn man hingegen eine hochverfügbare Serverlandschaft hat, macht man in der Regel einmal ein Averga Sizing, um den Bedarf bei Durchschnittsbelastung zu ermitteln – und einmal ein Peak Sizing, um den Bedarf zu Spitzenlastzeiten zu ermitteln. Dann kann man beispielsweise unterm Jahr die Hardware betreiben, die zur Erfüllung der Average-Kriterien nowtendig ist, und kann dann variabel zu Lastzeiten Cluster-Knoten hinzuschalten, die dann zur Erfüllung der Peak-Anforderungen notwendig sind.

Manchmal macht es Sinn, das Throughput sizing auf mehrere Zeilen aufzuteilen. Es ist ja schließlich in der Eingabemaske möglich, Zeilen hinzuzufügen, um weitere Einträge vorzunehmen. Somit könnte man beispielsweise den Load durch erstellte Objekte über zwei Zeilen auf einen Average- und einen Peak-Wert – der täglich zu einer bestimmten Uhrzeit auftritt – aufteilen. Man köntne aber auch beispielsweise die Anzahl der Objekte afuteilen nach objekte, die über SAPGUI rerstellt werden, die über TAblets / mobile Devices erstellt werden, poder man köntne die Objekte aufteilen nach Bestellungen, Rechnungen, Reiseabrechnungen usw. Über das Feld Short Text kann man dann entsprechende Beschreibungen eingeben,n um die einzelnen Zeilen unterscheiden zu können.

Mit diesem Wissen ausgestattet macht es sinn, über die Spalte ID zu reden. Wenn wir vom Kunden beispielsweise Zahlen für den Durchschnittswert und für den Peak-Wert in Lastzeiten haben, können wir für den A-wert und den P-Wert jeweils zwei Zeieln eröffnen. Dabei kann es durchaus sein, dass auf lange Sicht der A-wert in einigen Bereichen höhere Systemanforderungen verursacht (beispielsweise beim I/O-Wert) als der Lastwert. Damit wir in das Endresultat immer den höchsten der beiden Werte mit einrechnen, können wir den Peak-Wert und den Average-Wert miteinander vergleichen lassen, indem wir den beidne Zahlen eine gleiche ID geben. Wenn beispielsweise der CPU-SAPS Wert zu Spitzenzeiten am höchsten ist, aber der I/O-Wert im Durchschnitt höher sit als zur Spitzenzeit, fließen in das Endresultat der SAPS-Wert vom Peak und der I/O-Wert vom Average mit ein. So erfüllt unser System am Ende zuverlässig die Anforderungen für beide Szenarien.

Desweiteren gibt es die Daumenregel, dass man bei Objekten, die eine RFC-transaktion verursachen, 10% Load drauf rechnen soll, da diese eine entsprechend höhere Belastung verursachen als Transaktionen ohne Kommunikation zwischen Systemen. das kann amn einfach lösen, indem man eien weitere Zeile aufmacht und dort als Anzahl 10% zu den RFC-auslösenden Objekten aufschlägt. In unserem Beispiel oben, in welchem wir 90 Objekte eingetragen haben, würden wir 9 Objekte eintragen und als Short Text eingeben: Additional RFC Load, wenn alle Objekte jedes mal eine RFC-verbindung auslösen, wenn sie bearbeitet oder erstellt werden.

Nun gibt es noch einige Dauemnregeln, die man für das Sizing-Resultat in Betracht ziehen sollte. Zum einen sollte man 10% auf die Endresultatswerte draufschlagen, wenn der Kunde das zu sizende System virtualisiert – beispielsweise mit VMware vSphere.

Wie bewertet man jetzt selbst die Resultate dees quick Sizer tests? Nun, als erstes sollten Sie ermitteln, ob ihr Sysem auf die angegebenen SAPS-Werte kommt. Dazu können Sie sich unter www.sap.com/benchmark Systeme ansehen, die ihrem ähneln, und die dort angegebenen SAPS-Werte auslesen.

 

Der QuickSizer bietet außerdem den GoingLive Check (GLC), dabei hierbei werden die Einträge in dem Quick Sizer Tool gegen die Leistungsfähigkeit des Kundensystems, welches dieser erworben hat, abgewogen. Wenn man den Status Going Live setzt, dann prüft der SAP Support die Einträge im Quick Sizer gegen dei eingetragene Partner-Hardware des Kunden. Nach der Prüfung setzt der Support den Status des sizing Proejktes auf in process after GL. Das bedeutet, der SAP Support hat bestätigt, dass er mit dem Kunden auf Basis der Hardware im plausibilitätscheck zusammen arbeiten kann. Wenn wir nun den Projektstatus auf Final setzen, kann niemand mehr Änderungen am Projekt vornehmen.

die SAP Standard Application Benchmarks

Sie sind erreichbar unter http://www.sap.com/benchmark. Die Benchmarks werden in der Regel aufgerufen, nachdem man die Anforderungen eines SAP-produkts über den SAP Quick Sizer ermittelt hat. Die Benchamrks werden auf verschiedenen hardwarekonfigurationen von SAP-Harwarepartnern durchgeführt. Die ERgebnisse dieser bebchmarks zertifizieren für diese Hardwarekonfiguration, was sie leisten kann.

Die Benchmarks liefern aber nicht die Ergebnisse des KPI SCU Performance, sondern sie liefern nur einen Aussage über den troughput-KPI eines Systems.

Um sicherzustellen, dass die SCU-Kriterin erfüllt werden, tritt man als Mitglied in einem Sizting-Projekt in der Regel direkt an den ausgewählten Hardware-Partner heran und fragt ihn nach der SCU-Klassifizierung seines systems. Aktuell können Hardwarepartner über die URL https://service.sap.com/~sapidb/011000358700000485442012E erreicht werden. Die aktuelle URL steht immer in der SAP Note 1501701. Dort müssen Sie dann auch den Namen des Sizing Projektes angeben, den Sie im Quick Sizing Tool vergeben haben.

Wichtig ist außerdem, dass man bei virtualisierten Serversystemen weiterhin berücksihtigen muss, dass die Ressourcen dem virtualsiierten SErver immer zur Verfügung gestellt werden müssen – ihm dürfen von seinen Nachbarsystemen also diese Ressourcen nicht geklaut werden. Und: Bei Virtualisierung braucht man durchschnittlich 10% zusätzliche Leistung.

 sizing Methoden

Das Sizing findet in verschiedenen Phasen eines SAP-Einführungsprojektes statt. Einmal sehr früh, um unnötige hardwareausgaben zu vermeiden, und ein paar m onate vor dem Start um die Entscheidungen zu verifizieren.

Desweiteren wird ein Sizing bei jeder wichtigen änderung des Systems durchgeführt, etwa bei einem Upgrade der Datenabnk, des Betriebssystems, oder der SAP anwendung selbst, der REkonfiguration der Sstemalndschaft, der änderung von Geschäftsprozessen oder nach Rollouts, wenn mehr Benutzer einen Arbeitsplatz bekommen haben und nun mehr Benutzer im System bespaßt werden müssen.

Grundsätzlich unterscheidet man zwischen Initial Sizings und Production Sizings. Initial Sizings werden sehr früh beim Start eines SAP-Einführungspürojektes vorgenommen, um die Hardwareabnforderungen abzuschätzen und unnötige HArdwareausgaben zu vermeiden. Production Sizings werden während des produktivbetriebes des SAP-Produkts durchgeführt

Die einzelnen Unterarten sind:

  • Initial Sizing
    • Hardware Budget Sizing. Wird durchgeführt für kleine Unternehmen. Die IT-Dienstleistungen nutzen hier nur simple Algorithmen. Die berechnungen werden hier zunehmend aufgrund von Mutmaßungen und groben Schätzungfen der hardwarelast durchgeführt. Als Abschluss werden Risiken wie HArdwareausfall, Leistungseinbrüche, Naturkatastrozphen im Serverraum, Hackernagriffe usw. abgeschätzt.
    • Advanced Sizing. Wird bie mittelgroßen unternehemn durchgeführt. Hierbei werden Schätzungen über den Troughput-KPI gemacht und Frageformulare ähnlich biem Quick Sizing Tool von SAP beantwortet sowie allgemein gängliche mathematishce Formeln zur Berechnung von netzwerklast, Arbeitsspeicherkapazität usw. angewendet.
    • Expert Sizing. Für große Enterprise-Unternehmen. Hier werden möglichst genaue Berechnungen durchgefüht und eine Analyse von selbstgeschriebenen Applikatinen (Custom Code) durchgeführt. Außerdem gibt es eigens erstellte Guidelines für das Sizing aufgrund von Erfahrungsberichten, wenn beispielsweise ein Datenbankupgrade ansteht oder neue User dazugenommen werden sollen. Meistens nötgi für Kunden die die 80/20 Regel erfüllen (80% der Last wird durch 20% der Transaktionen verursacht) durch große Datenwuchtaktionen beispielsweise bei Datenaustausch zwiscehn Systemen, Customizing usw.
  • Production Sizing
    • Re-Sizing. Wird durchgeführt, wenn ein System mit zusätzlicher Belastung fertigw erden soll, beispielsweise mehr User oder mehr zu verarbeitende Geschäftsprozesse und somit Daten
    • Delta sizing. wird durchgeführt, wenn ein System mit zusätzlichen Funktionen fertig werden soll, also beispielsweise wenn ein SAP-produkt hinzugefügt wird, der Netzwerkverkehr nun SSL-verschlüsselt werden soll usw.
    • Upgrade Sizing. Wird druchgeführt, wenn ein System geupgradet wird, also beispielsweise die Datenbank, das Betriebssystem oder das Produkt selbst.

Je nach Sizing-Art, die durchgeführt werden soll, wendet man zur Durchführung des Sizings eine oder mehrere Sizing-Methoden an. Die Methoden sind:

  • Initial Calculation Method – eine erste grobe berechnung und Abschätzung der Hardwareanforderungen auf Basis von Erfahrungsberichten
  • T-Shirt-Sizing: simple mathematische Algorithemn und weitere Schätzungen auf Basis von Erfahrungsberichten werden  werden angewnadt
  • Komplexe Formeln: es werden komplexere mathematische Algorithmen zur Lastberechnung angewandt
  • formulare. Es werden Fragen beantwortet wie beispielsweise die zu erwartende Nutzerzahl, die Anzahl der geschäftsprozesse in den einzelnen Abteilungen – wie es beispielsweise im Quick Sizing Tool geschieht.

Genauere Infos über Sizing Methoden unter https://websmp201.sap-ag.de/~sapidb/011000358700000723482010E

Der SAP-quick-Sizer kombinierte mehrere Methoden.

Es gibt bestimmte Faktoren, die das Sizing beeinflussen, abnhängig vom

  • Hardware Partner
    • bereitgestellte Hardware-PLattform
      • Prozessortehcnologie
      • Festplattentechnologie (Magnet / SSD)
      • Netzwerktechnologie
      • Systeminfrastruktur
  • SAP
    • SAP-Produkt
      • Release / Version
      • OLTP oder OLAP-Software?
      • Spezielle Industrielösungen?
  • dem Kunden selbst, der das Produkt betreibt
    • Systemkonfiguration
      • Parametrisierung
      • genutzte interfaces und Schnittstelle
      • Unicode oder nicht?
      • A2A oder B2B Scenario?
    • Customizing
      • Art und Afubau der geschäftsprozesse
      • Organisationsstruktur Unternehemen
    • Custom Coding, Drittanbietersoftware
      • Einfluss auf die Performance
      • Skalierbarkeit
      • Geschüftsprozessdesign
    • Datenvolumen der Produktnutzung
      • akzeptiertbare Zeit für das Verarbeiten von Daten (etwa Bildschirmwechsel im Frontend)
      • Hintergrundprozesse, parallel ausgeführte Jobs
      • Umfang des Reportings der verarbeiteten Daten
    • Datenwachstum
      • überflüssige Daten vermeiden
      • Archivierungsstrategien
      • Information Lifecycle Management
    • Anwenderverhalten
      • gleichzeitige Anwender
      • LAN oder WAN Verbindung
      • internet / Intranet
      • Aktivitäten, etwa Suche

Expert Sizing mit dem SAP quick Sizer

 

Sizing Guidelines

Für jedes große SAP-Produkt gibt es spezielle Sizing-Guidelines, die ihr unter http://service.sap.com/sizing – Sizing / Sizing Guidelines erhaltet. Dort könnt ihr euch die einzlenen Guides für die gewünschten SAP-Produkte abholen.

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.