Balanced Scorecard in der Informationstechnologie

Verfasser:
Mag. Erich Kaltenböck, Senior Consultant TEMA-Unternehmensberatung G.m.b.H.

In den Postings zur „Balanced Strategy“ sind wir auf die Ableitung der BSC-Ziele aus den Strategischen Erfolgspositionen (siehe dazu Dr. Cuno Pümpin, „Strategische Erfolgspositionen – Methodik der dynamischen strategischen Unternehmensführung“) bis hin zur Maßnahmendefinition und Verifizierung des resultierenden Businessplans eingegangen. Heute geht es vor allem darum, die Tauglichkeit des Modells für die IT unter Beweis zu stellen und die Wichtigkeit der Strategischen Erfolgspositionen für die Konsistenz der BSC-Ziele zu zeigen. Der Artikel richtet sich somit an Unternehmen, die eine Balanced Scorecard (vgl. Robert S. Kaplan und David P. Norton)  im Einsatz haben und / oder eine entsprechend komplexe IT – Landschaft betreiben.

Grundlegende strategische Aufgabe der IT ist es, sich an den strategischen Anforderungen des Unternehmens auszurichten und – im Bedarfsfall – neue Entwicklungen des Marktes in das Unternehmen einzubringen. Demnach leiten sich die Strategischen Erfolgspositionen der IT aus jenen des Unternehmens ab und berücksichtigen Marktentwicklungen der IT ebenso wie allfällige interne Potenziale der IT, welche etwa im Rahmen einer Potenzialanalyse erhoben wurden.  Dies zeigt u.a Abb 1.

Abb1:

Die Strategischen Erfolgspositionen der IT bilden die Grundlage für die Definition der IT-Scorecard-Ziele. Zur Erreichung dieser Ziele sind Maßnahmen zu definieren, deren Wirksamkeit und Umsetzungsgrad anhand von KPIs (Key Performance Indikatoren) gemonitort wird. Für eine abteilungsübergreifende (zB. Entwicklung,  Betrieb, Infrastruktur, Prozesskoordination..) und nach BSC Perspektiven konsistente Definition von Zielen und Maßnahmen ist es wichtig zu verstehen, dass zwischen den einzelnen BSC Perspektiven ein Wirkungszusammenhang besteht: Beispielsweise hat die strategische Erfolgsposition „Qualitätsführerschaft (der Produkte)“ völlig andere Konsequenzen auf die Prozesse, diese wiederum an die Mitarbeiter und Kosten als es umgekehrt etwa eine Position „Kostenführerschaft“ haben würde.  Die BSC-Perspektive Markt- und Produkte spiegelt aus IT Sicht die Applikationen und Infrastruktur wider, ebenso Serviceprovider und Kunden. IT – Prozesse sind vorwiegend Steuerung - Sourcing -  Entwicklung – Betrieb – Support (bzw. jede ITIL- oder auch andere Prozessstruktur der IT).

Für unser Beispiel nehmen wir ein Produktionsunternehmen an, das aufgrund eines hohen Integrationsgrades mit Kunden einen hohen Anspruch an die Systemverfügbarkeit und Betriebsqualität hat, das mehrere Auslandsstandorte betreibt und das zur Reduktion der Durchlaufzeiten und Fehlerquoten der Abwicklung in Automatisierung der Geschäftsprozesse investieren möchte. Als strategische Erfolgsfaktoren der IT kommen demnach u.a. in Frage:

• Sicherstellen eines hohen Verfügbarkeitsgrades (für „Schlüsselapplikationen“)  
• Bereitstellen von Geschäftsprozesstechnologien und Prozess-Knowhow
• Integration von Standorten (zB. für standortübergreifende Abwicklung u. Corporate Services)

(Anmerkung: Bitte beachten Sie, dass dies eine beispielhafte Annahme ist, nach der Erfahrung in unseren Projekten wird man i.d.R. etwa 8-10 Strategische Erfolgspositionen der IT definieren, um eine qualitativ bedarfsgerechte  Aussagekraft zu erzielen).
Die Ableitung der BSC-Ziele nach BSC-Bereichen ergibt dann auszugsweise folgendes Bild (Abb. 2):
(Zur vereinfachten grafischen Darstellung sind die BSC-Ziele nicht ausformuliert)
Abb.2:

Für die Prüfung der Konsistenz der BSC-Ziele empfehlen wir die Analyse des Wirkungszusammenhangs über die IT-Abteilungen (zB. Entwicklung & Support – Betrieb – Infrastruktur – Prozesskoordination) hinweg – sofern man nicht ohnehin die BSC auf diese Struktur herunterbrechen will. So lassen sich ggf. Zielkonflikte zwischen den einzelnen IT-Abteilungen erkennen und in weiterer Folge bereinigen. Der „klassische“ Konflikt tritt im Regelfall dort auf, wo Flexibilität gegenüber Kundenanforderungen und Anforderungen an  Standardisierung und Konsolidierung (Kosten und Betriebssicherheit) aufeinander treffen. Der Wirkungszusammenhang in unserem Beispiel zeigt hohe Konsistenz:

Abb 3:

Kein BSC-Ziel ohne messbaren Key-Performance-Indikator (!!):

Nach Prüfen der BSC-Ziele auf Homogenität der BSC-Perspektiven und abteilungsübergreifende Zielkonsistenz, gilt es schließlich „taugliche“ Key Performance Indikatoren (KPIs) für die BSC-Ziele zu definieren. „Tauglich“ bedeutet dabei sowohl „quantitativ messbar“ als auch „mit geringem Aufwand zu erstellen“. Oft beobachtet man die Tendenz bei schwierig zu quantifizierbaren KPIs eine Art „Phasenbewertung“ nach Erledigungsgrad zu definieren (zB: Erheben der Technologiesets zur Integration ….bis zur Implementierung). Dies hat sich in der Praxis als wenig erfolgversprechend herausgestellt, weil am Anfang die KPIs im „grünen Bereich“ scheinen und mit fortschreitenden Schwierigkeitsgrad / Dauer in den roten Bereich „kippen“. Es lohnt sich über quantifizierbare KPIs nachzudenken und immer am „fertigen Zustand“ zu messen. Dieser kann in seiner Zielausprägung natürlich je nach Berichtsperiode variieren.

Einige Beispiele aus o.a. Übung siehe in u.a. Abb 4. Das Reporting des Erfüllungsgrades nach möglichst homogenen %-Sätzen hat sich ebenso bewährt, wie der Einsatz von „Ampelfarben“. In unserem Beispiel würde etwa ein Erfüllungsgrad von 90% der geforderten Verfügbarkeit keinen Sinn machen, daher ist dort ein Erfüllungsgrad von 100% (also 99% Verfügbarkeit) gefordert. Das KPI-Reporting wird im Regelfall sowohl nach BSC-Segmenten als auch nach Abteilungen darzustellen sein. Wichtig ist es auch zu verstehen, dass die genannten Zielgrößen für eine definierte Zielperiode (i.d.R. ein Kalenderjahr oder Geschäftsjahr) gelten. Damit wird sich verändernden strategischen Zielsetzungen ebenso Rechnung getragen wie der Forderung nach kontinuierlicher Verbesserung.

Abb 4:

BSC-Review als kontinuierlicher Prozess:

Die Definition der IT Strategie und resultierender BSC-Ziele ist ein zyklischer Prozess, der – je nach Dynamik des Unternehmensumfeldes – alle 3 bis 5 Jahre ausgeführt wird. Unabhängig davon, ist es zur Adaption der BSC – Zielgrößen aber auch zur „einfachen“ Integration neuer Anforderungen der Unternehmensführung erforderlich, die BSC-Ziele einem jährlichen Review zu unterziehen. Damit der Prozess und die daraus resultierenden Maßnahmen und Projekte in der Budgetplanung für das Folgejahr berücksichtigt werden können, empfiehlt sich daher die Durchführung von BSC-Reviews jeweils vor der Budgeterstellung.

Realoptionen und Risikozinssatz

Im Post: „Realoptionen müssen abgenabelt werden“ vom 26. Oktober 2010 habe ich mich mit den Unterschieden zwischen Finanz- und Realoptionen beschäftigt und argumentiert, weshalb der Rückgriff auf Modelle der Finanzmathematik unnötig, ja sogar falsch ist.

Ein zentrales Element in der Diskussion über die Bewertungsmethode ist die Frage nach dem risikogerechten Zinssatz für eine Option. Von den Finanzmathematikern wird angeführt, dass die Option ein von der Basisinvestition (dem underlying)  abweichendes Risiko aufweise und daher eine Bewertung mit dem gleichen Zinssatz nicht korrekt sei. Zur Lösung des „Zinsproblems“ sei der Kunstgriff der Replikation und der risikoneutralen Wahrscheinlichkeit notwendig.
 
Wie wird die Basisinvestition bewertet?

State of the Art ist die Diskontierung mit dem WACC (Weighted Average Cost of Capital), einem gewichtete Mittelwert aus Fremdkapital- und  Eigenkapitalzinssatz. Der Eigenkapitalzinssatz seinerseits wird nach der CAPM-Methode (Capital Asset Pricing Model) ermittelt, die auf die individuelle Risikopositionierung des eigenen Unternehmens relativ zum Gesamtmarkt zum einem definierten Zeitpunkt (!) abstellt.

Die Methode unterstellt implizit

• dass sich die Finanzierungsstruktur des Unternehmens durch die Investition nicht ändert und
• dass sich das Gesamtrisiko des Unternehmens durch die Investition nicht ändert (-> der Eigenkapitalzinssatz wird aus dem Jetzt abgeleitet).

Bei Großinvestitionen müsste aber die durch die Investition induzierte Veränderung der Risiko- und Finanzierungsstruktur berücksichtigt werde. Dies bedeutet, es müsste ein dynamischer Erwartungswert des Eigenkapitalzinssatzes und des WACC ermittelt werden.

Wenn aber (in Abweichung zur üblichen Praxis) als WACC ein erwarteter Zukunftswert verwendet wird, basiert er ebenso auf reinen Annahmen betreffen Risiko und Finanzierungsstruktur.

Es ist vor diesem Hintergrund absurd, für die Option, die nur eine Veränderung des Basisprojektes darstellt (Erweiterung, Reduktion etc.), die Zinssatzermittlung abzulehnen die für das underlying akzeptiert wird und daraus die Notwendigkeit des oben angeführten Kunstgriffes abzuleiten, dessen Konsequenzen eine erheblicher Komplexität und eine reine Scheingenauigkeit sind.

Leitfaden zur professionellen Software-Evaluierung

Verfasser: Mag. Erich Kaltenböck, Senior Consultant TEMA

Die Auswahl von Software – Produkten zählt zu den häufigsten IT - Entscheidungen für Unternehmen. Ein standardisiertes Evaluierungsverfahren hilft, derartige Entscheidungen effizient zu bewältigen und die damit verbundenen Herausforderungen methodisch zu lösen:

• Die Quantifizierung von Bewertungsergebnissen
• Das Lösen von Interessenskonflikten zwischen IT und Fachabteilungen
• Die ausreichende Berücksichtigung strategischer Aspekte im Auswahlverfahren

Der gegenständliche Leitfaden stellt eine praxiserprobte Hilfestellung für all jene dar, die aktuell oder wiederkehrend mit Software – Evaluierungen beschäftigt sind. Die Gewichtung der einzelnen Kriterien ist von der Unternehmensstrategie und der individuellen Situation des Unternehmens abhängig und wird daher von Unternehmen zu Unternehmen unterschiedlich sein. Beispielsweise haben Kosten – relevante Kriterien in Unternehmen die nach Kostenführerschaft streben eine andere Bedeutung als in Betrieben mit vorrangiger Serviceorientierung etc. Auf die Gewichtung wird daher im gegenständlichen Posting nicht eingegangen.

Abbildung 1 zeigt die Hauptkriterien („Kriterienkategorien“) im Überblick:

Kriterien im Detail:

Die Kategorie „Hersteller“ dient vor allem der Absicherung der Nachhaltigkeit. Bei Produkten mit hoher Customizierbarkeit und erforderlicher Implementierungsunterstützung durch den Hersteller sind die Expertise und Ressourcenverfügbarkeit von zusätzlicher Bedeutung. Ähnliches gilt in diesem Fall für die Supportorganisation und die als „Company fit“ bezeichnete Kompatibilität des Partners mit dem eigenen Unternehmen. Damit sollte auch klar sein, dass die Bewertung der Kriterien je nach Anlassfall und Unternehmens- bzw. IT Strategie unterschiedlich sein wird. Im Extremfall kann es auch zusätzliche „maßgeschneiderte“ Kriterien geben.

Die Kategorie „Produkt“ bildet inhaltlich gesehen den Hauptbestandteil der Evaluierung. Ähnlich wie beim Hersteller ist die „Zukunftssicherheit“ des Produktes unverzichtbar, vor allem aber natürlich die geforderte Funktionalität und Technologie des Produktes. Letztere hat auch engen Bezug zur „Serviceability“, also den resultierenden Anforderungen an die Serviceorganisation. Mit der Funktionalität sind ALLE funktionalen Anforderungen an das Produkt gemeint (Pflichtenheft), beginnend von der Mandantenfähigkeit, Mehrsprachigkeit über Berechtigungsmanagement, Datenmanagement  bis hin zu Reporting. Mehrere hundert Anforderungen sind da keine Seltenheit. Bei der Definition der funktionalen Anforderungen empfiehlt es sich, nach Prioritäten zu unterscheiden: Die Identifikation „unverzichtbarer Anforderungen“ (Priorität 1) im Vergleich zu „unterstützenden Anforderungen“ (Priorität 2) oder „kosmetischen Anforderungen“ (Priorität 3) erleichtert den Produktvergleich enorm. Ebenso empfiehlt es sich eine Erläuterung  einzufordern, wie die jeweilige Anforderung erfüllt wird. Dies fördert das gemeinsame Verständnis und legt „work arounds“ offen.

Für den Vergleich von Kosten bzw. Aufwand (intern wie extern) ist es ratsam, eine Kosten- bzw. Aufwandsstruktur verbindlich für den für den Anbietervergleich vorzugeben, da andernfalls ein Vergleich oft sehr schwierig zu bewerkstelligen ist. Die wichtigsten Kostenpositionen:

• Anschaffungskosten der Lizenzen (für eine zu definierende Useranzahl inkl. Wachstumsprognose)
• Anschaffungskosten für die erforderliche Hardware – Infrastruktur (wird üblicherweise nicht durch den Softwarehersteller geliefert)
• Laufende Lizenzkosten für Hard- und Softwarewartung
• Implementierungskosten durch Hersteller oder Implementierungspartner (nach Profilen und Projektphasen)
• Implementierungsaufwand des Herstellers oder Implementierungspartners (um Plausibilitätsvergleiche der Angebote durchführen zu können)
• Aufwendungen für Anwenderschulung und Dokumentation
• Implementierungsaufwand der durch die eigene Organisation zu tragen ist (nach Anforderungsprofilen und Projektphasen strukturiert)
• Dasselbe für Migrationsaufwendungen
• Externe Kosten für lfd. Support nach zu definierenden Service Levels
• Interner Aufwand für den laufenden Betrieb / Support
• Payback unter Bedachtnahme der Kosten und der aus der Funktionalität des Produktes hervorgehenden Einsparungen

Einen essenziellen Teil an Aufmerksamkeit verlangt die Bewertung der Strategiekonformität. Konsequenterweise sind Lösungen, welche die Unternehmensstrategie nicht unterstützen, abzulehnen. Ist ein Unternehmen gut in der Lage, seine strategischen und resultierenden IT – strategischen Anforderungen zu definieren, kann dies daher den Evaluierungsprozess von Softwareprodukten entscheidend beschleunigen. Die Identifikation der Strategiekonformität ist maßgeblich entscheidend für den Evaluierungserfolg! Die Ausprägung der relevanten Kriterien ist von der jeweiligen Strategie des Unternehmens abhängig. Die u.a. Tabelle enthält somit nur Beispiele.

Zur Erläuterung der SRQs („Strategic functional requirements“): Strategische Anforderungen an die Funktionalität sind jene, die aufgrund von Änderungen der Unternehmensstrategie, Änderungen am Markt, oder der Unternehmensstruktur eine neue Funktionalität erfordern und so einen wesentlichen Grund der Software-Neuanschaffung darstellen. Beispiele dafür: zB. Nutzung neuer Märkte und Bepreisungsverfahren (etwa in der Energiewirtschaft Bepreisung auf Stundenebene), Einführung von standortübergreifenden Funktionen (zB. Produktionsplanung) bei Internationalisierung, oder Automatisierung eines bisher überwiegend manuell ausgeführten Geschäftsprozesses.

Die Applikationsstrategie definiert die im Rahmen derselben definierten Ansprüche an Konsolidierung, Standardisierung, Integration etc. Die aus der Infrastrukturstrategie abgeleiteten Kriterien beschäftigen sich vor allem mit der Entsprechung mit definierten Zieltechnologien sowie Hardware- und Softwarestandards.

Ähnliches gilt für den Support (inklusive Change Management): Je nach  Eigen- vs. Fremdsupport leiten sich unterschiedliche strategische Kriterien ab. Eine spannende Diskussion konnte der Verfasser in einem Projekt führen, in welchem Applikationsstrategie und Infrastrukturstrategie zu unterschiedlichen Präferenzen führten: Was ist nun „leading“: die bessere funktionale, integrative und konsolidierende Aspekt der Applikationsstrategie oder die technologische Entsprechung mit den vorgegebenen Softwarestandards – vor allem der Entwicklungsumgebung (mit Optionen der Eigenbetreuung). Die Meinung des Verfassers: Bei Standardsoftware hat die Entwicklungsumgebung (es ging um .net vs. java..) eine geringere Bedeutung, weil ja an sich der source code nicht verändert werden kann. Es zeichnet jedoch die Qualität der Standardsoftware aus, wenn sie entsprechende Tools für das Customizing und auch „user exits“ für Zusatzprogrammierung zur Verfügung stellt. Hier ist die Applikationsstrategie „leading“: Man stelle sich vor wie viel Unternehmen wohl SAP implementiert hätten, wenn Voraussetzung dafür gewesen wäre, ABAP als strategisches Entwicklungstool bereits im Haus zu haben…Ein strategiekonformes Betriebssystem und eine ebensolche Datenbank ist dagegen für den Betrieb aus Kostengründen unverzichtbar.

Ergänzung bei projekthafter Implementierung

Da der Anspruch des Modells insbesondere darauf abzielt, Software mit komplexer Funktionalität und auch „Customizierbarkeit“ zu bewerten, hat der Verfasser – wie in Abbildung 2 dargestellt – auch den Aspekt einer Implementierungsunterstützung durch den Hersteller / Implementierungspartner ergänzend im Auswahlverfahren berücksichtigt.

Interessant mag für den Leser vor allem das angesprochene risk assessment sein und die mit den Subkategorien des risk assessments verbundenen Kriterien. Das Risk Assessment definiert als solches keine neuen Kriterien, sondern ist de facto eine Auswahl genannter Kriterien in Hinblick auf Risikorelevanz.

Risiken zur Gefährdung des Ergebnisses (Beispiele):

• Antwortzeitverhalten unter Volllast (Performance)
• Ungenügende Skalierbarkeit (Performance)
• Bandbreitenanforderungen (Performance)
• Menufolgen nicht workflow gerecht (Usability)
• Reporting Flexibilität ungenügend (Usability)
• Falsch verstandene Anforderungen (Funktionalität)
• Nicht umsetzbare Anforderungen (Funktionalität)
• Etc.

Risiken zur Gefährdung des Produktivstarts (Beispiele):

• Unterschätzung des Aufwands (intern / extern)
• Zu wenig Reservekapazitäten (intern / extern)
• Abhängigkeit von Einzelpersonen
• Projektmanagement – Defizite
• Etc.

Risiken zur Gefährdung des Budgets:

• Unterschätzung des Aufwands (siehe oben)
• Mangelhafte Spezifikation
• Hohe Anzahl von Änderungsanforderungen
• Projektvertrag mit geringem Fixkostenanteil
• Fehlende Risk Sharing Vereinbarungen
• Etc.

Für das Risk Assessment ist vor allem entscheidend Kriterien zu wählen, die a.) ein Unterscheidungsmerkmal darstellen und b.) im Rahmen der Risikovorsorge auch mit entsprechenden Maßnahmen belegt werden können.

Die zehn häufigsten Hindernisse für effiziente Geschäftsprozesse..

..und Ansätze zu deren Beseitigung

Verfasser: Mag. Erich Kaltenböck, Senior Consultant TEMA

In den Ausführungen über Balanced Strategy und SRPI (Strategiebasierte Rentabilitätsorientierte Performance Indikatoren) wird deutlich gemacht, dass sich die Anforderungen an die Geschäftsprozesse aus der Unternehmensstrategie ableiten. Grund dafür ist der bestehende Wirkungszusammenhang zwischen Anforderungen an das Produkt und den daraus resultierenden Ansprüchen an die Geschäftsprozesse. Darüber hinaus zeigt die ROCE (Return On Capital Employed) - Matrix, dass es einen funktionalen Zusammenhang zwischen Prozesszielen und Rentabilitätsänderungen (Ziele betreffend Veränderungen von Kapital und/oder Ergebnis) gibt. Auf den Punkt gebracht bedeutet dies, dass man die Analyse von Geschäftsprozessfallen im Kontext definierter Zielsetzungen sehen muss. Da es in diesem Artikel aber vorrangig um die Abstraktion von „Kardinalfehlern“ geht, und nicht um spezielle Geschäftsprozesse wie etwa Beschaffung, Verkaufsabwicklung, Instandhaltung etc., ist dies hier ausnahmsweise nicht von Belang. Die Projektion des Gesagten in das eigene Arbeitsumfeld verbleibt als Herausforderung beim Leser. Das in der Einleitung Gesagte wird als Punkt 1 angeführt.

1.) Geschäftsprozessziele sind nicht formuliert oder in ihrem Wirkungszusammenhang unklar:

Geschäftsprozesse können auf 2 Ebenen gestaltet werden: Einerseits durch Umgestaltung des Prozesses selbst, indem man einzelne Prozessschritte weglässt, verändert, neu ordnet oder automatisiert, andererseits durch Reduktion der Kostentreibermengen, etwa durch Erhöhung der Anzahl von Abrufbestellungen in der Beschaffung bei Forcierung von Rahmenverträgen, oder durch Reduktion der „Eilaufträge“ (die i.d.R. einen hohen Manipulations- und oft sogar Improvisationsaufwand) bedeuten) in der Verkaufsabwicklung etc. Wollen wir die Durchlaufzeit der Auftragsabwicklung erhöhen um die Liefertermine  zu verkürzen? Wie sieht das Gesamtmaßnahmenpaket aus? Was bedeutet dies für Produktion, Logistik, oder das Qualitätsmanagement?
Durch strategiekonforme (Prozess-) Zieldefinition und Analyse des funktionalen und wertmäßigen Zusammenhangs lassen sich logisch durchgängige Ziele formulieren und „punktgenaue“ Maßnahmen ableiten. TEMA hat dafür das Toolset „Balanced Strategy – SRPI und ROCE Matrix“ entwickelt (siehe diesbezügliche Postings) und unterstützt mit einem Referenzgeschäftsprozessmodell die effiziente Vorgehensweise.

2.) Geschäftsprozesse werden fragmentiert aus Abteilungssicht gesehen und nicht übergreifend gemanagt:

Wir finden in unseren Projekten immer wieder die Situation vor, dass Geschäftsprozesse sehr fragmentiert abgewickelt werden und die Kommunikation von möglichen Verzögerungen nicht durchgängig und rechtzeitig an alle im Prozess beteiligten Instanzen stattfindet. Als Resultat werden Probleme sehr spät erkannt und verspätet eskaliert oder an den Kunden berichtet und man „verliert“ sich in permanenter Improvisation.

Wie die u.a. Abbildung 1 veranschaulicht:  Den „ALARM“ zu erkennen, heißt an den gesamten Prozess zu denken. Aus der Abteilungssicht allein (außer man ist der letzte im Prozess) wird dies nicht gelingen.

Abbildung 1:

Die zwei wichtigsten – einander ergänzenden – Ansätze zur Bewältigung dieser Herausforderung liegen einerseits in der Umgestaltung der Organisation, andererseits in der Einführung von Geschäftsprozessmanagement – Tools.

Mit Umgestaltung der Organisation meint der Verfasser vor allem die Einführung eines übergreifenden Demand & Supply Chain Managements mit integrierter Produktionsplanung und einem Service Center, das die Koordinationsrolle für den gesamten Auftrag übernimmt und somit nicht nur als „Kundenauftragsabwicklung“ agiert. Die Einführung einer „Prozessorganisation“ (Geschäftsprozess – Owner etc.) hat im Vergleich dazu eher Relevanz in Bezug auf die Gestaltung der Geschäftsprozesse.

Die Möglichkeiten einen Geschäftsprozess oder gar mehrere Geschäftsprozesse übergreifend zu managen, sind in den ERP Systemen deutlich limitiert. Durch Nutzung von Web Services u.a. ist die IT Technologie mittlerweile so weit, Prozessschritte aus mehreren System über Geschäftsprozessportale abzuwickeln, zu steuern und übergreifend zu monitoren. Die Einführung von Geschäftsprozessmanagement Tools – wie zB. der Business Process Management Suite der Software AG – gewinnt auch in Hinblick auf Automatisierung an Bedeutung.

3.) Durchlaufzeiten (und damit Lieferzeiten) werden falsch interpretiert und an den Kunden kommuniziert:

Wenn man sich vergegenwärtigt, welche Interpretationsvarianten allein schon der Begriff „Lieferdatum“ zulässt, wird man Pkt 3.) leicht verstehen: Ist es das Datum an dem die Ware fertig produziert oder ausgelagert wurde, nach Manipulation (Überverpackung etc.) zur Abholung „auf der Rampe“ bereitsteht, vom Spediteur abgeholt wurde oder beim Kunden eingetroffen ist? Unterschiedliche Interpretationen wie auch Meinungen über die Auftragsdurchlaufzeit bei Erstellen der Auftragsbestätigung führen zu Missverständnissen und Ärger mit den Kunden:

Unserer Erfahrung nach ist es weniger schlimm, eine um einen Tag (oder ggf. mehrere Tage) längere Lieferzeit zu haben, als den zugesagten Termin nicht zu halten!! Die Empfehlung muss daher lauten:

• Klarstellung der relevanten Terminologie
• Identifikation der (vom Produkt und diversen Parametern der Verfügbarkeitsprüfung abhängigen) Lieferzeiten
• Reduktion der „Eilaufträge“ (und damit Einhalten der Standard – Durchlaufzeiten in der Kommunikation mit dem Kunden)

4.) Häufige Verantwortungswechsel und Systembrüche im Geschäftsprozess führen zu „Liegezeiten“:

Verantwortungswechsel sind in der Geschäftsprozesstheorie die am häufigsten genannte Ursache für Prozessverzögerungen. Der Grund dafür ist einfach: durch Verantwortungswechsel entstehen Liegezeiten, die umso problematischer werden, wenn in der Verfügbarkeit eingeschränkte Personen involviert sind. Zudem sind sie Ursache für Fehler (etwa bei Informationsdefiziten) und Doppelarbeit. Was für Schnittstellen zwischen Personen / Abteilungen gilt, gilt auch für IT Systeme: Systembrüche bedingen Redundanz, manuelle Intervention und bedeuten Aufwand im Schnittstellenmanagement etc.

Ziel  muss daher eine möglichst durchgängige, unterbrechungsfreie Prozessgestaltung sein. Voraussetzungen dafür sind:

• Eine möglichst prozesskonforme Organisation
• Eine Automatisierung aller Freigabe- und sonstigen Entscheidungsmechanismen (Auftragsfreigabe, Preisfindung, ..siehe Pkt. 5.)
• Die Schaffung vollständiger Auftrags- bzw. Prozessklarheit am Beginn des Prozesses
• Auf Systemseite nach wie vor Integration und / oder Nutzung von SOA / Web Web Services etc.

5.) Fehlende Stammdaten, Dispositions- und Entscheidungsparameter verhindern eine Automatisierung der Geschäftsprozesse:

Das Schwierige an der Automatisierung von Abläufen ist nicht die Technologie, sondern die Definition von und Einigung auf Entscheidungsalgorithmen sowie die Akzeptanz der scheinbaren „Mehrarbeit“ außerhalb des operativen Prozesses, also insbesondere die Wartung der erforderlichen Stammdaten und Steuerungstabellen. Dabei vergisst man gerne, dass dieser Initialaufwand ja vorwiegend vor Erstaufträgen (eines Kunden), vor Erstproduktionen (einer neuen Produktvariante), oder vor Erstbestellungen (neuer Lieferant) besteht und als Gegenleistung dafür bei den Folgeaufträgen der „Turbo gezündet“ werden kann. Automatisierte Verfügbarkeitsprüfung, Bestelldisposition, Stellplatzauswahl (für Ein- Auslagerung), Preisfindung (innerhalb erlaubter Limits), automatisierte Zuordnung von Zahlungskonditionen, Spediteursauswahl, Frachtkostenermittlung etc. sind das Resultat!

Voraussetzungen für automatisierte Prozesse sind damit insbesondere:

• Ein funktionierendes Stammdatenmanagement
• Transparente Entscheidungsalgorithmen von „akzeptabler“ Komplexität auf Basis strategischer Vorgaben

6.) Der Ausnahmefall wird zum Standard:

Ein paar Beispiele für die vom Verfasser angesprochen Ausnahmen (aus dem Prozess der Kundenauftragsabwicklung):

• Eilaufträge (= Aufträge, deren Erfüllung eine Unterschreitung der Standarddurchlaufzeit bedeutet)
• Auftragsänderungen (je knapper vor Auslieferung, umso schlimmer)
• Sonderverpackungen
• Sonderkonditionen
• Teillieferungen
• Kleinstaufträge
• u.V.m.

Der Kunde wird ihnen diese Flexibilität – solange sie unbeaufschlagt bleibt – in jedem Fall danken, die Frage ist aber, ob sie sich das bei jedem Kunden – vor allem wenn es ein Kunde ist, der ohnehin nur im Ausnahmefall bei Ihnen kauft -  leisten wollen und können?

Mittel zur Reduktion derartiger Sonderfälle ist die Definition von Generic Supply Conditions und Customer Service Levels. Anhand der Kundenkategorie (zB. Segmentierung nach A / B / C) sind mit den Customer Service Levels entsprechende Konsequenzen (insbesondere Beaufschlagungen) verbunden. Voraussetzung ist eine entsprechende partnerschaftliche Kommunikation mit Kunden (und Lieferanten). Im Regelfall ist das Resultat eine Reduktion der Sonderfälle, als Konsequenz des Kostenbewußtseins ihrer Kunden.

7.) Improvisation statt systemische Bereinigung:

Unternehmen haben eine geradezu erstaunliche Fähigkeit durch Improvisation und Work Arounds Geschäftsprozesshindernisse immer wiederkehrend im Anlassfall zu lösen. Eine projekthafte Bereinigung eines Missstands würde ja zu viel Aufwand bedeuten und die Ressourcen – weil ja man ja operativ ausgelastet ist – seien dafür nicht vorhanden.

Wie auch immer man dazu (und zu den resultierenden Gefahren wie steigender Fehleranzahl, Überlastung der Organisation etc.) steht: „Prozess excellence“ ist ohne dedizierte Aufmerksamkeit und projekthafte Implementierung nicht möglich.

Übrigens ist Punkt 7.) auch typisch für stark wachsende Unternehmen, etwa die vom Kleinbetrieb zum Mittel- oder Großbetrieb werden, ohne dafür rechtzeitig die strukturellen Voraussetzungen zu schaffen.

8.) Keine saubere Trennung der Prozesse Entwicklung und Produktion:

Im Entwicklungsstadium von Produkten, bei Pilotserien etc. gelten andere Regeln: sprich die Änderungswahrscheinlichkeit ist hier sehr hoch. Überträgt man dieses Verhaltensmuster auf die reguläre Fertigung, ist man mit permanenten Änderungen von Stücklisten, Materialspezifikationen, QM – Verfahren etc. befasst, sodass sowohl der Prozessdurchlauf als auch die Prozessqualität extrem darunter leiden und ein angestrebter Automatisierungsgrad nicht erreicht werden kann.

Konsequenz dessen muss eine klare Trennung von Entwicklung und Produktion sein, ebenso eine transparente Produkterneuerungsstrategie.

9.) Geschäftsprozesse erzeugen unnötige – historisch gewachsene – Outputs:

Als Berater ist man manchmal bei Bestandsaufnahme von Geschäftsprozessen mit einer im ersten Ansatz oft undurchschaubaren Menge an In- und Outputs einzelner Prozessschritte konfrontiert. Eine konsequente I/O – Analyse legt deren Notwendigkeit ebenso offen, wie den benötigten Inhalt und die Form (manuell vs. automatisch) der Erstellung.

10.) Information steht nicht zur Verfügung:

Es stehen zwar alle Daten zur Verfügung, aber nicht in der für den Geschäftsprozess erforderlich „Informationsstruktur“ und Geschwindigkeit: Auskunft während eines Telefonats geben zu können, ist der Performanceanspruch. Geschäftsprozesskonforme, vorkonfigurierte Reports sind daher als essenzieller Teil der Geschäftsprozessoptimierung zu berücksichtigen.

Übrigens: das Monitoring der Geschäftsprozess – Performance („nur was man messen kann, kann auch nachvollziehbar besser gemacht werden“) ist eine an anderer Stelle relevante Herausforderung.

Erfolgsmodell für ein konzernweites Facility Management

Verfasser: Mag. Erich Kaltenböck, Senior Consultant TEMA

Missverhältnis von Kosten und Leistung, Unzufriedenheit über Beauftragung und Organisation der Leistungserbringung, sowie mangelnde Beeinflussbarkeit des Instandhaltungsbudgets aus Sicht der Gebäudenutzer sind im Regelfall die Hauptkritikpunkte, denen sich ein konzernweites Facility Management zu stellen hat. Ein klar strukturiertes FM Konzept hilft aus dem Dilemma und bringt eine deutliche Verbesserung der Performance:

Die Säulen eines leistungsstarken Corporate Facility Managements sind:

• Abwicklungsrelevante Leistungscluster
• Objektsegmentierung und Service Level Management
• Trennung von Strategie, Beauftragung und Ausführung in der Servicemanagement – Organisation

Die von TEMA vorgeschlagene Leistungsstruktur besteht aus 4 Leistungsclustern mit jeweils unterschiedlichen Konsequenzen hinsichtlich Beauftragung, Ausführung sowie Verrechnung und Kosten.

Den ersten Leistungscluster bilden jene Leistungen, die wir als de facto „hoheitlich“ dem Facility Management zurechnen, wie etwa die Anmietung von Gebäuden, die Objektverwaltung, und Leistungen mit Bezug auf gesetzliche Verpflichtungen. In einem überwiegend  Performance orientierten Modell wird dieser Bereich möglichst gering gehalten und repräsentiert vorwiegend die Eigentümer – Sicht bzw. -Verantwortung.

Für Service Level abhängige Leistungen sind durch den Gebäudenutzer bzw. den verantwortlichen FM – Koordinator des Geschäftsbereichs mit dem Zentralen Facility Management die erforderlichen Service Levels vereinbart (und mit dem Leistungserbringer vertraglich vereinbart). Bei Bedarf können diese entsprechend adaptiert werden. Voraussetzung dafür ist eine Objektsegmentierung nach geeigneten Kriterien. In einem unserer Projekte haben wir zB. die Objektkategorien „repräsentativ“, „werterhaltend“ und „wertverbrauchend“ unterschieden. Kriterien dafür sind zB. Miete vs. Eigentum, die strategische Bedeutung (wie wird das Gebäude genutzt), oder auch die Nutzungszeit. Typische SLA gesteuerte Dienstleistungen sind die Reinigung, der Stördienst, Portierdienste etc.  Eine besondere Herausforderung ist im Regelfall, wenn Geschäftsbereiche fallweise Eigenleistungen in dieses Modell einbringen wollen. Generell bedürfen SLA gesteuerte Leistungen keiner gesonderten „Einzelbeauftragung“ sondern starten bzw. enden mit Gültigkeit des Service Level Agreements. Für die operative Anpassung – etwa während der Urlaubszeit – haben professionelle Dienstleister entsprechende Kommunikationstools zur Verfügung. Budgetierung wie Abrechnung erfolgt anhand der SLA – Tarife und der zugehörigen Mengenbezugsgrößen.

Den dritten Leistungscluster bilden jene Leistungen die nach einem Instandhaltungs- oder Wartungsplan abzuwickeln sind, das gilt insbesondere für technische Anlagen. Die Budgetierung erfolgt dabei nach einem mit dem Facility Management abgestimmten Instandhaltungsplan, der Leistungsabruf selbst kann – sofern gewünscht - durch den Nutzer innerhalb vorgegebener Zeitfenster erfolgen.

Der Block der Einzelbeauftragung bleibt damit auf wirkliche Einzelaufträge beschränkt und ist in seiner Ursächlichkeit immer Benutzer dominiert. Übersiedlungen, Gebäudeadaptierungen oder auch Reparaturen sind typische Beispiele dafür.

Was wird durch dieses Modell bewirkt:

• Objektverwaltung sowie sämtliche gesetzlich oder gewerberechtlich relevanten Aktivitäten verbleiben in der Obhut des zentralen Facility Managements, ebenso die übergreifende Qualitätsprüfung, Reporting und FM – Kostenmanagement.
• Das objektgesteuerte Service Level Management erlaubt eine der Gebäudenutzung und strategischen Positionierung adäquate Leistungserbringung, bei gleichzeitiger Nutzung der scale of economy in der Bepreisung.
• SLA gesteuerte Leistungen wie Abrufbeauftragungen nach Instandhaltungsplänen reduzieren den Beauftragungsaufwand und flexibilisieren (ebenso wie die Einzelaufträge) das FM – Volumen aus Sicht der Nutzer. Zudem wird durch die mögliche  Einbindung der Nutzer in den Beauftragungsprozess die Koordination der Durchführung optimiert (und gleichzeitig das zentrale Facility Management schlank gehalten).
• Mögliche Beeinflussung von Budget und Kosten durch die Nutzer wird erzielt (und das Kostenbewusstsein verbessert)

Verbleibt noch die Frage, wie man dieses Konzept – allen voran die strategischen Vereinbarungen wie Leistungsstruktur, Objektkategorien, Service Levels – organisatorisch auf ein festes Fundament stellt. Nach Erfahrung des Verfassers hat sich dabei die Trennung von Strategie, Beauftragung und Ausführung als unverzichtbar erwiesen. Es empfiehlt sich,  dem operativen Facility Management auf Konzernebene eine Steuerungsgremium „FM Board“ zur Ausgestaltung der FM Strategie etc. voranzustellen. Für Detailplanung, Beauftragung, Performance- Monitoring wiederum ist eine zu etablierende taktische FM Organisation zuständig. In beiden Gremien sind die Geschäftsbereiche des Unternehmens vertreten.

IT-Services: Tarifbildung und interne Verrechnung

Verfasser: Mag. Erich Kaltenböck, Senior Consultant TEMA

IT-Kosten sind nach wie vor ein Thema, an dem man als „IT-Berater“ kaum vorbeikommt. Die Frage nach der Wettbewerbsfähigkeit des IT-Budgets ist dabei ebenso unausweichlich wie jene nach Benchmarks und Optimierungspotenzial. Fundament für Aussagen über Kosten und Tarife ist in jedem Fall eine transparente, gut strukturierte und bedarfsgerechte  Planungs- und Verrechnungsmethode.

Nutzen und Voraussetzungen

Der betriebswirtschaftliche Nutzen einer Tarifbildung und internen Verrechnung der IT Services ist vielfältig:

• Eine korrekte, über Mengenverbräuche variabilisierte Verrechnung der IT-Kosten führt zu korrekten Tarifen bzw. Kosten der empfangenden Kostenstellen (und letztlich der Produkte oder Dienstleistungen des Unternehmens).
• Die Bildung produktbezogener IT-Tarife ist Voraussetzung für Benchmarking.
• Eine transparente Tarifkalkulation ermöglicht die Identifikation und Beeinflussung der Kostentreiber.
• Tarifkalkulationen sind Voraussetzung für „make or buy“ Entscheidungen.
• Mengenkorrelative Tarife beeinflussen das Konsumverhalten der Leistungsempfänger.
• Service-Level-bezogene Tarifbildung ist Voraussetzung für Service Level Management.

Voraussetzungen dafür sind:

• Eine unternehmensgerechte und marktkonforme Struktur der IT Dienstleistungen
• Eine möglichst weit gehende Anwendung des Verfahrens der internen Leistungsverrechnung (im Gegensatz zum Umlageverfahren)
• Eine Abbildung in Plan und Ist (auch in ihrem ERP (CO) System)
• Eine primäre Erfassung aller IT-Kosten in der IT
• Ein strategische Positionierung bezüglich der Abgrenzung von Standardtarifen und Einzelverrechnungen

Mit unternehmensgerechter Struktur der Dienstleistungen ist insbesondere gemeint, dass es pro Unternehmen unterschiedlich sein kann, welche Dienstleistungen man mit einem eigenem Tarif bepreist und welche man im Gegensatz dazu „verdichtet“ (zB. über einen Topf „Kleinapplikationen“) abrechnet. Die „Wichtigkeit“ (wir unterscheiden in unseren Projekten gerne zwischen „vital“ und „supportive“) und das Volumen der Applikation (zB. Anzahl User)  bzw. Dienstleistung liefert im Regelfall ein gutes Indiz dafür. Die Marktkonformität der IT Dienstleistungen bezieht sich dagegen auf die Kostenstruktur der einzelnen IT Services: So zB. sind in der Dienstleistung „IT Standardarbeitsplatz“ neben der Anschaffung von Hard- und Software auch die Kosten der Software-Wartung, Personalkostenanteile des Service-Desks, die AfA der Infrastruktur für Software-Distribution, der Active Directory (bzw. Domain-) Controller etc. enthalten. Die Anwendung des betriebswirtschaftlichen Verfahrens der internen Leistungsverrechnung ist Voraussetzung um Mengen- und Preisabweichungen im Soll-Ist-Vergleich zu erkennen (beim Umlageverfahren würde im Gegensatz dazu der Umlageschlüssel in Plan und Ist gleich sein und keine Mengenabweichungen offenlegen). Die wichtigste Konsequenz daraus ist die Stundenerfassung der Mitarbeiter auf „Produkt-„ bzw. Dienstleistungsebene. In Unternehmen mit geringer Controlling-Affinität ist dies eine nennenswerte Herausforderung. Eine durchgängige Abbildung in ihrem CO-System ermöglicht die Nutzung der systemimmanenten Verfahren wie etwa jenes der iterativen Ermittlung von Kostensätzen, stellt die über die IT hinausgehende Durchgängigkeit sicher und unterstützt die automatisierte Handhabung der Leistungserfassung und Analyse. Ein primäre Erfassung aller IT Kosten in der IT (also zB. keine Lizenzanschaffungen in den Fachabteilungen) stellt die Tarifwahrheit ebenso sicher wie die Vollständigkeit und Transparenz der IT Gesamtkosten. Rege Diskussion verursacht im Regelfall die strategische Positionierung von Standardtarifen vs. Einzelverrechnung. Beispiele: IMACs (Install-Move-Add-Changes) wie zB. die Übersiedlung eines PCs, das Anlegen eines Users, das Ändern von Berechtigungen könnte man separat verrechnen oder einfach mit einem „all inclusive“ Standardtarif abdecken. Der verursachergerechten Kostenwahrheit und dem resultierenden Kostenbewußtsein steht hier der Aufwand entgegen und - vor allem bei outgesourcten Dienstleistungen - die Gefahr eines Multiplikatoreffekts (wenn die Mengen unterschätzt wurden). Tendenziell neigt man dazu, unternehmensintern eher „all inclusive Tarife“ zu verwenden. Der Idee, die IT-Kosten zur Gänze „als Fixkostenblock“ zu betrachten, kann der Verfasser wegen des o.a. Nutzenpotenzials nichts abgewinnen (Ausnahme: kleine Unternehmen).

Ein Beispielmodell im Überblick

Das in der Grafik dargestellte Beispiel zeigt das generische Verrechnungsmodell beispielhaft anhand von 4 Verrechnungsebenen. Nur die auf Ebene der IT Leitung anfallenden und

damit nicht den anderen Ebenen direkt zuordenbaren Kosten werden über einen Verteilungsschlüssel (zB. nach Personal- oder Gesamtkostenanteil) auf die Abteilungen der IT umgelegt. Dort werden jene Kosten erfasst die wiederum nicht direkt auf Ebene der Produkte / Dienstleistungen erfasst werden können. Typischerweise sind das die Gehaltskosten inkl. der Gehaltsnebenkosten, Ausbildungskosten, Umlagen und interne Leistungsverrechnung aus anderen Bereichen, die Raumkosten, das Büromaterial, AfA, aber auch externe Dienstleistungen. Die Gesamtkosten der Abteilungskostenstellen ergeben bei Division durch die verrechenbare Planstundenanzahl den Plantarif (Stundensatz) der Kostenstelle. Der jeweilige Abteilungsleiter wird im Regelfall nicht selbst Stunden verrechnen, er ist damit kostenseitig berücksichtigt, nicht aber in der Anzahl der verrechenbaren Stunden, sodass er im Tarif der Abteilung „enthalten“ ist. Die von den Mitarbeitern der jeweiligen IT-Abteilung geleisteten Stunden werden in Plan (=Plantarif mal Planmenge) und Ist (=Plantarif mal Istmenge) auf die einzelnen Standard-Dienstleistungen verteilt. Zusammen mit den auf Produktebene direkt zugeordneten Kosten ergibt dies die Gesamtkosten pro Produkt und dividiert durch die Bezugsgröße (zB. Anzahl User oder Anzahl Gigabyte etc.) den Tarif pro Produkteinheit. Mit diesem Tarif werden die Leistungsempfänger belastet bzw. bildet dieser Tarif die Grundlage für einen allfälligen „Gewinnaufschlag“ bei externen Leistungen und für die Vergleichbarkeit mit Benchmarks oder externen Tarifen als Teil von „Make or Buy“-Entscheidungen. Natürlich können die IT-Abteilungen auch Leistungen außerhalb der Standardservices erbringen. Diese werden dann zB. auf einen Einzelverrechnungsauftrag gebucht der entweder 1:1 weiterverrechnet wird oder über separate Tarife entlastet (dann vermeidet man die Diskussion dass zB. die Installation eines PCs einmal mit 0,5h ein anderes mal mit 1,0h gebucht wurde).

Bei Umstellung von Umlageverfahren auf IT-Leistungsverrechnung wird man auch sehen, dass durch die Analyse der Preis- Mengenabweichungen im Plan / Ist - Vergleich sich ein sehr großer Lerneffekt in den ersten beiden Jahren ergibt und die Plantarife sich nach diesem Zeitraum als sehr „stabil“ erweisen - sofern man nicht sehr groben Veränderungen des Mengengerüstes unterlegen ist. In diesem Fall ist die quantity of scale deutlich spürbar.

Fahrplan zum automatischen Auftragsdurchlauf

Verfasser: Mag. Erich Kaltenböck, Senior Consultant TEMA

Operational excellence in den administrativen Prozessen wird heute mehr denn je zur „sine qua non“ – Bedingung wettbewerbsfähiger Unternehmen. Der Auftragsabwicklung als Schnittstelle zum Kunden kommt dabei besondere Bedeutung zu, denn dass die Ware auch nur eine Stunde zu spät kommt, können wir uns heute nicht mehr leisten. Anders formuliert: mit einer 100% -igen Auftragserfüllungsquote gewinnen Sie Kunden!

Schlüsselprozesse zur Auftragserfüllung sind einerseits ein funktionierendes Demand & Supply Chain Management bis hin zum operativen Sales Plan (wenn Sie Dinge versprechen die Sie nicht halten können, oder Ihre Lieferfristen nicht wettbewerbsfähig sind, wird die beste Auftragsabwicklung scheitern), andererseits ein gut strukturierter, stabiler und performanter Auftragsdurchlauf (Order To Cash Prozess). Welche Voraussetzungen es erfordert, um einen über das Customer Service Center eingelasteten Terminauftrag automatisch abzuwickeln, zeigt das aktuelle Posting. Vorweg sei festgehalten: Die Voraussetzungen liegen vorwiegend im organisatorischen Bereich. Sowohl die benötigte Funktionalität (Anmerkung: Der Verfasser bezieht sich auf seine Erfahrung mit SAP R/3) als auch die Technologie zur Integration von Systemen ist in Zeiten von SOA, EAI und Web Services kein Thema mehr. 

Als Leitfaden für den Prozessdurchlauf bedienen wir uns des TEMA Referenzgeschäftsprozessmodells

Das Grundproblem: Ein automatischer Auftragsdurchlauf benötigt im System hinterlegte Entscheidungsregeln, EIN einziger Standard für alle Kunden funktioniert nicht, weder in der Produktspezifikation, der Transportabwicklung etc. und schon gar nicht in der Preisfindung. Zudem sind Auftragsänderungen – oft in letzter Minute – ein häufig auftretender „Showstopper“ für Effizienz in der Abwicklung.

Voraussetzung 1 ist eine geeignete Kundensegmentierung, die wiederum ihren Eingang in die aus den Generic Supply Conditions resultierenden Customer Service Levels findet. Diese enthalten somit nicht nur Dinge wie Incoterms, Zahlungskonditionen etc. sondern vor allem auch prozessrelevante Parameter wie etwa interne / externe Vorlaufzeiten, „Rush-order“- Fristen, Änderungsgebühren, minimale Auftragsgrößen, Anzahl Chargen je Lieferung etc., die je Kundensegment unterschiedlich gestaltet sind. Ein „strategischer Kunde“ wird demnach anders zu behandeln sein, als ein Gelegenheitskäufer oder zB. ein Distributor, eine konzerneigene Vertriebsgesellschaft wiederum anders als eine externe Vertriebskette. Ein Beispiel: Für strategische Kunden kann man einen „eisernen Bestand“ reservieren, um für diese immer Ware verfügbar zu haben, für Gelegenheitskäufer wäre dies natürlich aufgrund der Kapitalbindung (Produkt und Lagerkosten!) Unsinn. Ein anderes Beispiel: Wenn es Ihnen gelingt, Auftragsänderungen für die nicht-strategischen Kunden mit einer Änderungsgebühr zu belegen, werden Sie nicht nur die Anzahl der Änderungen senken, sondern auch die daraus resultierende Prozesskosten „erlösen“.

Voraussetzung 2 ist vollständiges und akkurates Stammdatenmanagement unter Berücksichtigung aller für eine plangesteuerte Materialbedarfsposition erforderlichen Dispositionsparameter auf Material- und Kundenseite.

Voraussetzung 3 ist die Definition kundenabhängiger Kreditlimits, die im Rahmen der automatischen Kreditwürdigkeitsprüfung gegen Auftragsvolumina und Außenstände geprüft werden. 

Voraussetzung 4 ist eine funktionierende, die Customer Service Levels berücksichtigende dynamische Verfügbarkeitsprüfung über alle Fertigungsstufen (mit dahinter liegenden Stücklisten, Arbeitsplänen etc.) Bei Nicht – Verfügbarkeit des Produktes erfolgt eine Einlastung in den (kundenübergreifenden) Produktionsplan und Terminierung der Verfügbarkeit für den Kunden entsprechend seines Segmentes. Qualitätsauswahl (etwa bei Chargenproduktion wie in der chemischen Industrie) und Reservierungsverfahren (Sicherheitsbestände, Reservierungen in Abgleich mit Absatzplanung etc.) sind integraler Bestandteil.

Der „Available to promise“ – Check ist schon bei der Kundenanfrage erfolgsrelevant, da wir davon ausgehen, dass Aussagen über die Verfügbarkeit während der telefonischen Kundenanfrage im Service Center beantwortet werden müssen.

Voraussetzung 5: Definition von Regeln zur automatischen Preisermittlung unabhängig von manueller Intervention durch Key Account Manager oder Business Management! Neben der Berücksichtigung des Kundensegmentes sind kundenindividuelle Rabattstaffeln etc. erforderlich und zu pflegen.

Voraussetzung 6: Auswahl eines Vorzugsfrächters je Frachtweg (Straße / Bahn / Schiff / Luft) und eventuell Region. Vertraglich verbindliche und mit den Customers Service Levels korrelierende Service Level Agreements ermöglichen die Definition und Hinterlegung von Preistabellen (Service Level zB. Lieferzeit, Strecke, Gewicht, etc.) zur automatischen Frachtpreisermittlung und Frachtbestellung.

Voraussetzung 7: Definition der Auslagerungsstrategie (wie etwa FIFO, angebrochene Paletten zuerst,…) und sofern automatisierte Fördertechnik im Einsatz: Integration des ERP Systems mit der Lagerlogistik bzw. Fördertechnik zur automatischen Generierung der Auslagerungsaufträge und Quittierung der entnommenen Menge.

Voraussetzung 8: Definition von Freigaberegeln und Toleranzgrenzen zur interventionsfreien Auftragsabwicklung. Klären aller Auftragsdetails schon bei Auftragseinlastung durch den Service Desk.

Zweifelsfrei lassen sich im Detail noch viele Voraussetzungen definieren, auch ist Lagerfertiger nicht gleich Lagerfertiger oder loses Produkt nicht gleich verpacktes Produkt etc. Vorrangig geht es hier um das Effizienzpotenzial einer Kundensegmentierung bei deren konsequenter Anwendung bis hin zur Preisfindung und den Effekt von Customer Service Levels zur Reduktion der Anzahl von Auftragsänderungen und des Prozessaufwands für nicht – profitable Kunden.

Schlussfolgerung: der interne Auftragsdurchlauf kann soweit automatisiert werden, dass er – im Standardfall bei verfügbarer Ware -  seine Limits nur in der physischen Auslagerung der Ware hat und damit innerhalb kürzester Zeit abgewickelt werden kann. Gleichzeitig wird die Anzahl der „Standardaufträge“ drastisch erhöht:

Mit vollständiger Auftragserfassung wird automatisch die Kreditwürdigkeitsprüfung und Verfügbarkeitsprüfung angestoßen und der Auftrag im positiven Fall freigegeben. Die Bepreisung erfolgt (schon bei Angebotslegung) automatisiert, der Liefertermin (=Kundenwunschtermin) wird in der Verfügbarkeitsprüfung dann akzeptiert, wenn er aufgrund der internen und externen (Frächter) lead times und den relevanten Customer Service Levels eingehalten werden kann. Die Freigabe generiert eine Auftragsbestätigung per Email an den Kunden und legt automatisch den Lieferschein an, der wiederum in Abhängigkeit der Auslagerungszeiten etc. des Lagers zum geeigneten Zeitpunkt einen „Auslagerungsauftrag“ ans Lager generiert. Gleiches gilt für das Erzeugen einer Frachtbestellung an den Frächter. Entsprechend der Auslagerungsstrategie wird bei stellplatzverwalteten Lägern die auszulagernde Ware / der Stellplatz vom Lagerverwaltungssystem identifiziert und die Ware ausgelagert. Bei Verwendung automatisierter Fördertechnik wird mit Quittierung der Auslagerung die Warenausgangsmenge automatisch in den Lieferschein übernommen, das Drucken der Frachtpapiere und das Buchen des Warenausgangs angestoßen, was wiederum die Faktura generiert. Mittels des ebenso automatisierten Mahnvorschlags überwachen Sie den Zahlungseingang. Durch Anwendung des Gutschriftenverfahrens mit Ihrem Vertragsfrächter können Sie auch noch den Aufwand für die Prüfung der Frachtrechnungen eliminieren.