Make or Buy?

Wenn sich Speditionsunternehmen für eine neue Software entscheiden, stehen sie oft vor der Frage, ein Standardpaket zu kaufen und die eigenen Prozesse daran anzupassen oder ein leistungsfähiges Softwarehaus zu engagieren und sich eine Software auf den Leib und die eigenen Prozesse schneidern zu lassen. Was ist besser? Make or Buy?

Für kleine und mittelständische Speditionen, die über eine übersichtliche Organisation, auch im Ausland, verfügen, ist die Beauftragung einer Eigenentwicklung mit Sicherheit nicht lohnenswert und die Anpassung der Prozesse eher hilfreich als schädlich.

Standardsoftware oder Eigenentwicklung?

Besondere Funktionalitäten die nicht im Softwarestandard des Lieferanten enthalten sind, lassen sich bei modernen Systemen meist mit überschaubarem Aufwand parametrisieren, sodass am Ende ein Softwarepaket eingeführt wird, mit dem alle wesentlichen Geschäftsprozesse abgebildet und sogar optimiert werden können. Gleichzeitig ist hierdurch sichergestellt, dass man als Kunde auch von Ideen und Erweiterungen anderer Kunden profitiert, weil diese in den “Standard” übernommen werden.

Unternehmen die sich für den Weg der Eigenentwicklung entscheiden, sind meist multinational auf allen Kontinenten zuhause. Diese „Global Player“ entscheiden sich in der Regel für eine “maßgeschneiderte” Individuallösung, weil Standardsoftwarepakete oft nicht zu deren strategischen Ansatz der globalen Prozesseffizienz passen oder die Lösungsanbieter nicht groß genug sind, um eine globale Organisation und deren Anforderungen an Support und Pflege zu unterstützen.

Softwareeinführung erfordert Prozessveränderungen

Nun ist es für jedes Unternehmen, egal wie groß, an sich schon eine große Herausforderung, ein neues Softwarepaket in der Organisation auszurollen und Prozesse zu verändern. Ungleich grösser sind diese jedoch, wenn man den steinigen Weg einer Eigenentwicklung einschlägt.

Natürlich sind Eigenentwicklungsprojekte langfristig angelegt und verlangen einer globalen Organisation einiges ab. Nicht nur die Größe der Investition, was die Entwicklung angeht, auch das Definieren der Prozesse und das Requirement Engineering sind Herausforderungen, die nicht zu unterschätzen sind. Denn Softwarehäuser, die globale Projekte stemmen können, verfügen nur sehr selten über ausreichend Fachkenntnis der Speditionsbranche und deren Prozesse. Beim Besteller wiederum, seien wir ehrlich, gibt es kaum Leute, die sich mit Software Requirement Engineering auskennen und wissen wie ein Prozess darzustellen ist, damit es der Programmierer am Ende auch versteht. Eine vertrackte Situation.

Gutes Anforderungsmanagement ist das A und O

Zusätzlich verkompliziert sich das gesamte Projekt, wenn sich die Unternehmen nicht genug Zeit nehmen, vorher ihre Organisation zu analysieren und Anforderungen aus den einzelnen Ländern mit einzuplanen. Obwohl die globale Organisation nach standardisierten Richtlinien arbeitet, heißt das noch lange nicht, dass die Unternehmen ihr Netzwerk und deren Anforderungen auch wirklich kennen. In den Konzernzentralen werden landestypische Besonderheiten mitunter negiert oder bagatellisiert. Das wird dann aber leider oft erst bemerkt, wenn es schon an den Rollout geht und man nicht daran gedacht hat, dass man in chinesischen Schriftzeichen drucken können muss oder in Lateinamerika noch immer gerne mit Scheck bezahlt wird und daher eine Scheckerfassung im System vorhanden sein muss. Solche Dinge verzögern dann den Rollout, da derlei Dinge nun mal für die lokale operative Einheit kritisch sind und enden in einem nicht kalkulierbaren Aufwand für das Projekt an Change Requests und zusätzlichen Aufwänden.

Risiken durch professionelles Projekt- und Change Management vermindern

Natürlich kommt es immer auch auf die Größe der Organisation an. Bei den ganz Großen wurde – wie zahlreiche Beispiele von “Langläufer-Projekten” zeigen – in der Vergangenheit vielfach unterschätzt, wie schwer sich Veränderungen in einem globalen Netzwerk umsetzen lassen. Die weit verbreiteten Matrix Organisationen lassen es nur schwer zu, par ordre de mufti ein System zu implementieren, wenn nicht alle Risiken minimiert und Spezialitäten berücksichtigt sind.

Für alle Herausforderungen, die solche Projekte mit sich bringen, gibt es kein Patentrezept, da jedes Unternehmen für sich ein eigener Mikrokosmos mit eigenen Gesetzmäßigkeiten ist. Ein professionelles Anforderungs-, Projekt- und Change-Management sind aber in jedem Fall ein guter Anfang, um Risiken zu minimieren und mit dem Softwareeinführungsprojekt am Ende vielleicht doch nicht 5 Jahre hinter dem Zeitplan zu enden.