Schlagwort-Archive: Prozessmanagement

Schneller zur besseren Webseite mit einer Business Analyse

Für unseren größten Kunden die heco gmbh haben wir eine Business Analyse durchgeführt, um vor der anstehenden Neuentwicklung die richtigen Entscheidungen treffen zu können. Wie wichtig die Informationen über Markt, Mitbewerber, Anwender und Kunden sind und welche Schlussfolgerungen sich daraus ziehen lassen, zeige ich in diesem Video:

Während dies bei „normalen“ (im Sinne von offline bzw. intern) Software-Projekten schon eher Usus ist, kann man davon bei Web-Projekten  noch lange nicht sprechen. Meiner Erfahrung nach spielen hier Aussehen und „etwas auf die Leinwand bringen“ die erste Geige. Eine schier riesige Zahl an Feature-Wünschen, die man auf anderen Seiten gesehen hat, lässt die Stakeholder träumen.
 

Der Langsamste, der sein Ziel nicht aus den Augen verliert, geht noch immer geschwinder, als jener, der ohne Ziel umherirrt. – Lessing

 

Aus unserer Sicht ist es elementar sich die Zeit zu nehmen, um sich als Dienstleister in die Domäne des Kunden einzuarbeiten. Denn viele hoch priorisierte Wünsche sind eher nice-to-have Anforderungen. Oder schlimmer: Das „Warum“ ist gar nicht geklärt und das Produkt bzw. die Webseite wird am eigentlichen Zweck vorbei entwickelt. Da wird dann auch mal der Wunsch nach einem News-System laut, obwohl im Jahr nur 1-2 Neuigkeiten auf der Webseite eingepflegt werden sollen. Dabei wäre es unter Umständen geradezu eine Revolution in der Branche, würde man im Gegensatz zu den Mitbewerbern Echtzeitbestände und -preise auf der Webseite anbieten.

Um richtig priorisieren und die Technologie auswählen zu können, ist deshalb ein solides Know How der Domäne des Kunden notwendig, denn sonst verbaut man sich schnell Möglichkeiten, die dann teuer und langwierig umgebaut werden müssen. Setze ich beispielsweise auf SignalR, so kann ich jedem Besucher, der ein bestimmtes Produkt geöffnet hat, Änderungen am Bestand aktiv mitteilen. Auf der anderen Seite muss ich mir nicht unnötig Komplexität ins Projekt holen, wenn der Bestand von vor 2 Stunden völlig ausreichend ist. Oder wenn der Besucher gar nicht in der Lage ist bestimmt Funktionen zu bedienen (ja, das gibt es durchaus => kenne deine Anwender).

Viel Spaß mit dem Video, auch wenn es etwas lang wurde. Daran merkt man aber schon wie weitreichend das Thema ist. Schreibt mir in die Kommentare, ob ihr auch schon zu solchen Projekten gestoßen seid, bei denen das fehlende Domänenwissen zu Entwicklungsproblemen führte.

Anwender durch zielgerichtete Release Notes in die Produktentwicklung integrieren

In diesem Video zeige ich eine von vielen maßgeschneiderten Funktionen unseres Release Prozesses. Das Ziel dabei war es die Anwender noch mehr in die Produktentwicklung einzubinden.

Die langfristige Vision: Anwender bringen selbst die Anforderungen ein. Wie das genau gemeint ist und wie wir das umgesetzt haben, seht ihr im Video. Unter anderem kommen YouTrack und TeamCity zum Einsatz.

 

Über ein Rake-Skript, welches auf ein bereits existierendes YouTrack-Gem zurückgreift, sprechen wir die Rest-API an. Vielen Dank an Alexander Groß von GROSSWEBER für die Hilfe bei der Umsetzung unserer Vision.

Wer weitere Einblicke in unseren Prozess bekommen möchte, der kann mir dazu einen Kommentar hinterlassen.

Product Owner optimiert eure Engpässe

Das ist Teil 2 meiner Serie: 3 einfache Tricks für Product Owner mit großer Wirkung.

flask-304943_1280Wenn wir Software entwickeln, dann erstellen wir – wenn auch virtuell – ein Produkt. Produktentwicklung respektive der dafür eingesetzte Prozess wird immer einen oder mehrere Engpässe haben. Besonders Lean Management bzw. das darauf basierende Kanban zielen auf die Optimierung solcher Durchsatzprobleme ab (vgl. Theory of Constraints).

An allen Softwareprodukten, an denen ich mitentwickelt habe, war ein Engpass im Bereich der Entwicklung. Ideen und Wünsche haben die Kunden, Projektmanager und Product Owner viele. Natürlich können sie diese schneller formulieren als die Entwickler sie implementieren können.

Deshalb ist es wichtig genau diesen Abschnitt des Entwicklungsprozesses optimal auszulasten. Alternativ könnte der Engpass durch massive Aufstockung der Mitarbeiter vollständig aufgelöst werden, aber das ist allein aus Kostengründen unrealistisch.

 

Vorbereitung ist alles

Deshalb gilt: Je besser die Vorarbeitet ist, d.h. Wunsch-Features durchdacht, formuliert und präpariert werden, desto weniger Zeit muss der Entwickler dafür aufwenden. Unternehmen sprechen typischerweise auch vom Anforderungsmanagement. In einem späteren Beitrag werde ich die Einzelschritte und die Rollen in einem Softwareentwicklungsprozess beleuchten. Es gilt das Gleiche wie beim Essen: Je besser die Nahrung im Mund vorgekaut wird, desto einfach kann der Magen sie verdauen. Das heißt nicht, dass nicht weiter der Entwickler einbezogen werden soll oder dass weniger miteinander geredet werden soll, aber meiner Erfahrung nach werden immer wieder wenig durchdachte Anwendungsszenarien den Entwicklern über den Zaun geworfen. Im Sinne von “die werden dann schon mal machen”. Wird dann seitens der Entwickler nachgefragt, wundert sich der fachliche Verantwortliche gerne mal “was denn daran nicht klar sei”. In dem Zuge sei auf die Wichtigkeit einer gemeinsamen Sprache hingewiesen. Wie gesagt ist die Kommunikation wichtig und die Fachexperten können nicht an alles denken. Manches wissen sie auch nicht. Viele Probleme können aber im Vorfeld durchaus vermieden werden. Statt nach Lösungen zu suchen, kann es oft sinnvoller sein die tatsächliche Ursache des Problems zu untersuchen. Wo genau funktioniert der Geschäftsprozess nicht?

 

Evolvierbarkeit

Darüber hinaus muss jedem Produktverantwortlichen klar sein, dass eine Änderung nachweislich teurer wird, je später selbige erfolgt. Das betrifft die sogenannte Evolvierbarkeit. Obwohl Software nicht wie ein Auto verschleißt oder für Änderungen physikalisch auseinander gebaut werden muss, kosten späte Korrekturen mehr als frühe.

 

Schnelles Feedback

Bei Scrum und Kanban macht es sich ebenfalls bemerkbar, wie schnell erledigte User Stories vom Product Owner abgenommen werden. Ich habe für die Projekte, in denen ich Scrum Master bin, mit dem PO vereinbart, dass spätestens am Vormittag des Folgetages das Feedback kommen muss, ob die User Story korrekt umgesetzt wurde. Mir ist unter anderem von Microsoft bekannt, die nach einer Einführung einer 4-Stunden-Abnahmefrist der Durchsatz der tatsächlich abgeschlossenen Aufgaben signifikant gesteigert wurde.

 

Leerlauf vermeiden

Zu guter Letzt gibt es noch den Fall, dass die Arbeit so gut läuft, dass neue Wünsche schneller umgesetzt werden können als erwartet. Dann sollten die nächsten ToDos vorbereitet sein, damit die Software Ingenieure nicht Leerlauf haben.

 

Fazit

Der Entwicklungsprozess sollte auf die Engpässe zugeschnitten sein. Häufig ist das die Entwicklung. Diesem Engpass muss sich der Rest des Prozesses unterordnen. Das Prinzip ist seit langem bekannt, wissenschaftlich belegt und kann eine erhebliche Beschleunigung der Produktentwicklung bewirken.

Product Owner lasst eure Entwickler den Tunnel

Das ist Teil 1 meiner Serie: 3 einfache Tricks für Product Owner mit großer Wirkung.

 

Ideal zeigt der Firm ‘The Social Network’ welche Umgebung Entwickler benötigen: Den sogenannten “Tunnel”.

 

Gemeint ist damit die Möglichkeit konzentriert ohne Unterbrechung an dem (Software-)Produkt arbeiten zu können. Wenngleich agile Methoden wie Scrum und Kanban sehr stark Interaktion und Kommunikation (vgl. Agiles Manifest) fördern, fällt mir immer wieder auf, dass zwar nicht insgesamt zu viel, dafür aber zu häufig miteinander gesprochen wird. Statt dedizierte Gesprächstermine zu nutzen, ruft der Product Owner teilweise mehrfach am Tag den Entwicklern an, um sich z.B. Feedback zu Ideen oder neuen User Stories zu holen.

Das wirkt dann natürlich sehr flexibel im Sinne von frei von Bürokratie und klingt auf Anhieb sehr “kommunikativ”, jedoch sehe ich auch die Nachteile, die nach meiner Ansicht stark überwiegen: Der Entwickler wird kontinuierlich aus dem Tunnel gerissen. Gerade in kleinen und mittelständischen Unternehmen (KMUs) ist die Begründung die, dass genau die statischen Reglements von Konzernen vermieden werden wollen oder aber dass ohnehin nur wenige Entwickler zur Verfügung stehen, um den PO gedanklich zu unterstützen. Das sind alles nachvollziehbare Gründe, jedoch spricht aus meiner Sicht nichts dagegen zu sagen: Wir reservieren täglich von 16.30-17 Uhr dediziert Zeit für den Product Owner und seine Fragen weg. In Scrum gibt es sogar ein dediziertes Meeting während der Iteration dafür: Das Backlog Grooming. Dieses kann im Übrigen auch mehrfach während eines Sprints angesetzt werden.

Wie viel Zeit kleine Ablenkungen kosten, belegen neben Studien (von denen ich an dieser Stelle keine heraussuchen will) auch die eigenen Erfahrungen. E-Mail Eingang, Messenger Nachricht oder nur schnell im Internet was nachgeschaut und schon ist man aus dem Fokus und dem Gedankengang draußen. Das ist unabhängig vom Entwicklerberuf, das ist einfach menschlich. Je nachdem welche Studie gerade wieder veröffentlicht wird, lese ich Zeitangaben zw. 10 und 30 Minuten, die benötigt werden, um wieder an der gleichen Stelle mit der gleichen Konzentration weiterzuarbeiten.

Der geneigte Product Owner kann das einfach nachvollziehen, indem er sich an seine Schulzeit erinnert. Wenn er als Schüler eine mathematische Aufgabe rechnen muss, deren Lösung durch verschiedene Rechenschritte und Umformungen sich auf über 2 DIN A4 Seiten erstreckt und er Mitten drin von einem Mitschüler 5 Minuten mit einem völlig anderen Thema abgelenkt wird, dann muss er nach dem Gespräch erst nochmal seinen Gedankengang verfolgen, um die Rechnung weiterführen zu können.

Wie hole ich mein Team ab

Innovation bedeutet immer auch Veränderung. Der Mensch als Gewohnheitstier muss deshalb abgeholt werden, sonst bleibt er zurück. Quelle: FotoliaWelche Möglichkeiten hat eine Führungskraft hierfür?

Zunächst einmal gilt es Folgendes zu trennen:

  • Kann ein Mitarbeiter mit der Veränderung nicht Schritt halten?
  • Oder will er sich nicht verändern?

Während ersterem mit den richtigen Werkzeugen gut beizukommen ist, muss letzteres über Prinzipien und Werte gesteuert werden. Ausgenommen von der Regel sind Menschen, die nur deshalb nicht wollen, weil sie nicht können. Kann also beispielsweise jemand nicht tanzen, so wird er auch nicht auf die Tanzfläche wollen, nur um sich zu blamieren.

 

Prinzipien/Werte:

Ich bin der Meinung, dass Menschen ihre Arbeitsweise nur dann gewinnbringend ändern und sich produktiv am Prozess beteiligen, wenn sie von der Änderung selbst überzeugt sind. Demzufolge wird das Ergebnis bei einer typischen Command-and-Control Führung im besten Fall ausbaufähig sein. Eine aus meiner Sicht erfolgsträchtigere Herangehensweise könne diese sein: Bilde zwei Gruppen und lasse jedes Gruppenmitglied frei entscheiden, welcher der beiden Gruppen es beitritt. Die eine Gruppe setzt ein exemplarisches Projekt/Produkt gemäß der bisherigen Vorgehensweise um, die andere implementiert nach der neuen. Ein halber Tag ist dafür natürlich ungeeignet. Ein Monat ist der Geschäftsleitung eventuell zu kostspielig. Aber einen angemessenen Zeitraum benötigt es, um die gravierenden Prozessunterschiede zu Tage zu befördern. Eine unabhängige Instanz, z.B. der Product Owner, ein Externer oder eine Anwendergruppe, beurteilen das Ergebnis. Darüber hinaus sollten die Teams auch ihre Ergebnisse untereinander vergleichen. Einen wesentlichen Punkt würde ich noch aufnehmen: Bei dem Produkt sollten neue Anforderungen hinzu kommen und sich gegebenen Anforderungen ändern, um zu sehen wie anpassungsfähig beide Vorgehen sind. Unter der Prämisse, dass die neue Herangehensweise gewinnt und die Diskussion ernsthaft und konstruktiv geführt wurde, kann das Gros der Gruppe überzeugt werden. Die restlichen Skeptiker kippen eventuell durch Schlüsselfiguren, sogenannte Meinungsmacher, oder bei den ersten Erfolgen. Es ließe sich noch viel dazu sagen, aber ich möchte es an dieser Stelle dabei belassen und mit einem Zitat abschließen, welches meiner persönlichen Einstellung entspricht: “Die Führungskraft führt nicht über die Inhalte, sondern sie führt über die Emotionen […]” (Boris Gloger, S. 302, Produkte zuverlässig und schnell entwickeln).

 

Werkzeuge:

  • Retrospektive: Für mich das wertvollste Werkzeug überhaupt. Egal ob tägliche Einzelretrospektiven oder wöchentliche Gruppenretrospektive, wichtig ist: So häufig wie möglich, Ergebnisse festhalten und vor allem umsetzen. Mehr dazu hier.
  • Coding Dojos: Alle 1-2 Wochen für 2 Stunden. Erste spürbare Ergebnisse zeigen sich in kürzester Zeit. Ich arbeite gerade an einem Fachartikel dazu. Bis dahin schaut ihr hier.
  • Pair Programming: Super für die Vermeidung von Inselwissen und das Etablieren eines kontinuierlichen Wissenstransfers. Gerade bei Teammitgliedern, die sich schwer tun mit neuen Praktiken (z.B. TDD) geeignet oder mit heterogenen Teams aus Junior und Senior Developer. Für weitere Informationen schaut in den Wikipedia-Artikel.
  • Open Spaces / World Cafe: Interessante Konferenzformate zur Optimierung des Wissensmanagements. Einen Artikel dazu habe ich in der dotnetpro veröffentlicht.
  • Bloggen: Lässt sich vortrefflich mit der Retrospektive bündeln. Kann als Quelle für andere (und einem selbst) Teammitglieder dienen. Das Schreiben und Widerholen begünstigt auch den Lernprozess.
  • Scrum: Eine agile Methode zur Produktentwicklung, die die kontinuierliche Verbesserung fest im Prozess implementiert hat. Alle meine bisherigen Blogbeiträge zum Thema findet hier.
  • Communities: In nahezu jeder größeren Stadt gibt es dedizierte Communities, z.B. Scrum Stammtisch, .NET User Group, SQLPass, etc.. Ein Austausch mit Dritten ist immer hilfreich, v.a. wenn Entwickler in anderen Firmen die neue Vorgehensweise bereits erfolgreich anwenden.
  • Externe Consultants: Empfinde ich als besonders hilfreich um die anfänglichen Klippen zu umschiffen.

Abschließend sei noch gesagt, dass es eine Vielzahl an Werkzeugen gibt, jedoch muss das Tool auch zur Person bzw. der Gruppe passen. Pair Programming ist z.B. etwas, das nicht jeder Entwickler möchte.

Mich würde interessieren, wie bei euch Änderungen eingeführt wurden? Gab es Kollegen, die sich schwer damit taten? Wie hat die Führungskraft diejenigen abgeholt? Gibt es ein besonders hilfreiches Werkzeug, das bei euch Wunder bewirkt hat? Würde euch ein längerer Artikel mit konkreten Beispielen interessieren?

 

Edit 16.05.2014: Daniel Marbach hat mir ein interessantes Buch zu dem Thema empfohlen. Eine Rezension darüber wird folgen, da ich es inzwischen auf meinem Kindle habe.

4 Akronyme für Scrum

Diese 4 Akronyme sind hilfreiche Eselbrücken in Scrum.

 

MoSCoW

  • M – Must have this requirement to meet the business needs
  • S –  Should have this requirement if possible, but project success does not rely on it
  • C –  Could have this requirement if it does not affect anything else in the project
  • W – Would like to have this requirement later, but it won’t be delivered this time

 

130619 144705 DSCI2561Mit der MoSCoW Methode werden die Stories im Product Backlog in 4 grobe Priorisierungen aufgeteilt. Das ist v.a. bei der Initialisierung des Product Backlog und bei der Release Planung hilfreich.

Sind beispielsweise alle Product Backlog Items aus dem Bereich Must Have implementiert, könnte ggf. das Produkt einen so hohen Business Value haben, dass ein öffentlicher Release möglich ist.

Bedenkt aber, dass es sich nur um eine erste grobe Einteilung handelt und trotzdem jedes Item früher oder später eine eindeutige Priorisierung erhalten muss.

 

 

 

Deep130619 132854 DSCI2549

  • D – Detailed Appropriately
  • E – Estimated
  • E – Emergent
  • P – Prioritized

 

Das Deep Akronym ist im Kontext des Product Backlog und welche Merkmale dieses aufweisen sollte hilfreich. Die Begriffe sprechen für sich.

 

 

 

130619 141014 DSCI2552Invest

  • I – Independent
  • N – Negotiable and Negotiated
  • V – Valuable
  • E – Estimable
  • S – Small
  • T – Testable

 

Mit dem Invest Akronym wird festgehalten, wann User Stories “wohlgeformt” sind. Denkt daran, dass eine User Story ein “Versprechen für eine Konversation” darstellen soll.

 

SMART

  • S –  Specific
  • M – Measurable
  • A – Achievable
  • R – Relevant
  • T – Time-boxed

SMART als Akronym gibt es in vielen Kontexten, unter anderem bei Mitarbeitergesprächen. Dabei macht es immer eine Aussage darüber, wie Ziele formuliert sein sollen. Wenn es bei Scrum also um Ziele geht, z.B. dem Sprint Goal, dann findet man in diesem Akronym Hilfe.

 

Fallbeispiel: Verantwortungsbereiche definieren

 

Ich habe den Artikel ‘Deutsche Chefs informieren Mitarbeiter ungenügend’ als Anlass genommen, um an einem Fallbeispiel für eine IT Abteilung in einem mittelständischen Betrieb (rein fiktiv natürlich) eine mögliche Definition der Verantwortungsbereiche zu erstellen. Natürlich ist das hier sehr reduziert und weniger formell, aber es soll nur als Anregung dienen.

Unternehmensziele:

Innovationsgetriebene Prozessentwicklung und –optimierung zur Steigerung des Marktanteils und der Kostenreduzierung, um die Wirtschaftlichkeit in der aktuellen Marktlage zu gewährleisten.

Admin1:

Der erste und wichtigste Schwerpunkt ist das Business Service Management (BSM). Also die Schnittstelle zw. IT und Fachabteilung bzw. das Ausrichten der IT Dienste an den Geschäftsprozessen. Hier arbeitet er vor allem dem Geschäftsführer (Product Owner) und den Entwicklern zu, indem er Prozesse dokumentiert und modelliert. Deshalb muss er bei allen Gesprächen mit der Fachabteilung anwesend sein. Das ermöglicht eine schnellere und bessere Implementierung der Prozesse als Programm-Features; der Business Value der Anwendung steigt.

Der zweite Bereich betrifft die die strategische Ausrichtung der Administration samt Innovationsmanagement. Ziel ist es das IT Service Management damit weiter zu verbessern.

Beispiele:

Beispiel 1: Pflege eines Wikis zur Dokumentation, sowie Modellierung in Form von erweiterten Ereignisgesteuerten Prozessketten (eEPK). Concept Maps dienen zur Erfassung der Problemdomäne.

Beispiel 2: Wechsel von den klassischen Terminaldiensten zu Remote-App, sodass das Arbeiten in den Verkaufsbüros (v.a. mit mehreren Bildschirmen) annähernd an die Qualität heran kommt, wie sie intern vorzufinden ist.

Admin2:

Primär im Support angesiedelt, handelt er das komplette Tagesgeschäft ab, sodass Admin1 sich auf seine Aufgaben konzentrieren kann. Darüber hinaus dokumentiert er die täglichen Aufgaben (Tickets) und führt Listen zur Qualitätskontrolle (Qualitätsmanagement), sodass Admin1 ggf. Adaptionen in die Wege leiten kann, die den IT Betrieb für die Anwender optimieren.

Beispiele:

Beispiel 1: In einer Liste mit Ausfällen werden ausnahmslos alle Systemausfälle dokumentiert. Neben dem betroffenen System und dem jeweiligen Server (ein Server kann mehrere Systeme zur Verfügung stellen), sind auch Ausfalldauer, -grund und daraus resultierende Konsequenzen festzuhalten.

Beispiel 2: In einer Liste mit den regelmäßigen Aufgaben, die am Ende/Anfang jeden Monats anfallen, wird dokumentiert, was genau zu tun ist und wann die Aufgabe das letzte Mal bearbeitet wurde. Neben Ausfalltests und Backup-Prüfungen, kann dies auch kleinere Aufgaben umfassen, wie beispielsweise die manuelle Aktualisierung der Infoterminals oder das Aushängen der neuen Dokumentationen in den Serverräumen (beispielsweise Notfallpläne).

 

Web-Developer:

Sein Aufgabengebiet ist zweigeteilt; neben der eigentlichen Weiterentwicklung der Webseite übernimmt er zum großen Teil die strategische Planung. Übertragen auf die eingangs erwähnte Administration übernimmt er demzufolge beide Funktionen. Mit den Möglichkeiten und v.a. der Wichtigkeit des Webs, steigt auch die Notwendigkeit den Kunden eine hochwertige Plattform für ihre Einkäufe zur Verfügung zu stellen. De facto kann sich heute niemand mehr leisten auf das Web ab Absatzmarkt zu verzichten.

Beispiele:

Beispiel 1: Er evaluiert die eingesetzte Plattform Typo3, d.h. inwieweit trifft diese Plattform die Bedürfnisse des Business. Bietet sie entsprechende Möglichkeiten zur Qualitätssteigerung anhand von Unit Tests (JavaScript und PHP). Stehen Werkzeuge zur Verfügung für das Application Lifecycle Management. Gibt es schnellere und sicherere Datenbanken als MySQL.

Beispiel 2: Er migriert die Extensions einer alten Typo3 Version auf die Basis der neuen Version.

 

ERP-Developer1:

Seine Tätigkeit ist vorwiegend die Entwicklung, d.h. sonstige Aufgaben werden so weit als möglich von ihm abgeschottet, damit das ERP kontinuierlich mit den Anforderungen der Fachabteilung Schritt halten kann. Allerdings ist wie bei allen gewachsenen Systemen auch bestehender Code zu migrieren, d.h. parallel zur Neuentwicklung muss auch Legacy Code angepackt werden. In dem Kontext gilt es zu eruieren, welche neue Technologie hierfür am besten geeignet ist. Geeignet bedeutet hierbei v.a. skalierbar, erweiterbar und mit möglichst langläufiger Herstellerunterstützung. Außerdem ist eine enge Kooperation mit der Fachabteilung notwendig und ein betriebswirtschaftliches Verständnis, sodass vom Entwickler selbst auch Verbesserungsvorschläge kommen können.

Beispiele:

Beispiel 1: Das alte CRM Modul soll neu aufgelegt werden. Die Fachabteilung denkt primär an eine neu Oberfläche und die Optimierung der vorhandenen Daten, z.B. Bildung von Kundengruppen und Validierung der Personendaten. Darüber hinaus können aber von Entwicklerseite Social CRM Funktionen vorgeschlagen werden. Außerdem ist zu klären, ob und wo das Modul in den restlichen Geschäftsprozessen (z.B. Auftragsverwaltung) zu integrieren ist.

Beispiel 2: Zur Optimierung der Lagerhaltung und somit zum Einsparen der Kosten soll ein Bestellvorschlagswesen programmiert werden, sodass die EK-Abteilung auf der einen Seite Deckungslücken und auf der anderen Seite zu hohe Bestände vermeiden kann. Alternativ kann auch der Aufwand bei gleichbleibendem Umsatz anhand des Pareto-Prinzips optimiert werden.

%d Bloggern gefällt das: