Die Anschaffung neuer Software-Systeme sowie die integrale Vernetzung dieser mit vorhanden Komponenten sind Aufgaben, die in der Vergangenheit meistens von den
IT-/Organisationsabteilungen initiiert und federführend umgesetzt wurden. Heutzutage erfolgen die Anschaffung und die Integration dieser Software-Produkte weitgehend durch die Fachabteilungen. Damit die neu angeschafften Software-Produkte auch den betrieblichen Anforderungen gerecht werden, bedarf es im Vorfeld einer genauen Spezifikation der betrieblichen Vorstellungen.
Welche Einflussgrößen und Rahmenbedingungen liegen vor?
Es ist notwendig, vor der Projekt-Initiierung die organisatorischen Einflussgrößen und Rahmenbedingungen zu ermitteln, abzustimmen und aufzunehmen.
Hierzu zählen nicht nur die technischen und funktionellen Anforderungen an die Software, sondern auch die Unternehmensziele, die Wünsche und Vorstellungen der betroffenen und eingebundenen Fachbereiche, die betrieblichen Voraussetzungen und nicht zuletzt die Bereitschaft der Mitarbeiter, sich den neuen Strukturen anzupassen. Diese Faktoren sind bei der Projekt-Initiierung mit der Formulierung der Projektorganisation und der Arbeitspakete zu berücksichtigen. Dabei ist darauf zu achten, dass auch bei der Projektorganisation alle eingebundenen Fachbereiche in der Umsetzung mit involviert werden. Denn nur mit einer fachübergreifenden Projektorganisation ist die integrale Vernetzung der Software-Systeme umsetzbar.
Sind die Anforderungen ausreichend spezifiziert?
Es ist natürlich unabdingbar, die technischen und funktionalen Anforderungen an eine Software (natürlich unter Berücksichtigung der Einflussgrößen und Rahmenbedingungen) aufzunehmen und zu formulieren. Hier bedarf es im Vorfeld einer detaillierten Analyse der Prozesse und die Aufnahme und die Formulierung der Anforderungen anhand von repräsentativen Beispielen aus der Praxis. Hier sind vor allem die unternehmens-spezifischen Besonderheiten in den Fokus zu stellen und zu beschreiben, da die software-technische Abbildung dieser Workflows meistens mit individuellen Software-Anpassungen verbunden sind. Auch ist es unabdingbar, sich mit der funktionalen Struktur bzw. der Architektur der am Markt angebotenen Softwareprodukte zu befassen, und die Anforderungen entsprechend zu gruppieren. Diese Vorgehensweise erleichtert und häufig ermöglicht es erst einen späteren Produktvergleich.
Erfüllt die gewünschte Software die technischen und funktionalen Anforderungen?
Natürlich ist die Erfüllung der technischen und funktionalen Anforderungen durch die Software eine Grundvoraussetzung.
Allerdings machen fehlende Detailkenntnisse in der Software-Architektur einen Vergleich der verschiedenen Produkte fast unmöglich.
Wir haben häufig erlebt, dass Kunden auf unseren Messestand kamen und sagten: „Ich habe mir verschiedene Software-Produkte angeschaut, aber ich weiß gar nicht, welche tatsächlich unsere Anforderungen erfüllt.“
Hier bedarf es im Vorfeld, d. h. bei der Auswahl der infrage-kommenden Softwareprodukte, einen detaillierten Abgleich des Funktionsumfangs mit den formulierten Anforderungen, insbesondere die beispielhafte Umsetzung verschiedener praxisbezogener Fallbeispiele. Denn anhand dieser Fallbeispiele werden erst die unterschiedlichen Funktionsweisen der Software-Produkte sichtbar. Auch die Abbildung eines Prototyps sind für die Entscheidungsfindung unterstützende Mittel.
Auf diese Art und Weise erhält man zumindest ein ungefähres Bild über das, was die ausgewählten Softwareprodukte im Standard abbilden können.
Leider wird dieser Punkt in der Praxis – häufig auch aus Kostengründen – nicht in der Tiefe behandelt. Daher erfüllen nicht immer die angeschafften Software-Systeme später die Erwartungen der Fachabteilungen.
Ist der Integrationsaufwand richtig kalkuliert?
Ein weiterer wichtiger Aspekt ist der Integrationsaufwand bei der Software-Einführung.
Dieser Aufwand wird in der Praxis völlig unterschätzt. Gerade der Aufwand für die Harmonisierung und die Erfassung der Stammdaten binden enorme personelle Kapazitäten. Hinzu kommt, dass die Stammdaten nicht in den erforderlichen, digitalen Strukturen vorliegen, sondern in „gewachsenem Wildwuchs“ in unterschiedlichen Systemen im IST verwaltet werden.
Ferner werden die mit der Integration verbundenen Kosten im Vorfeld nicht ausreichend budgetiert, bzw. berücksichtigt: Z. B. Kosten, die entstehen durch nicht voraussehbare Software-Anpassungen oder Software-Erweiterungen und Schnittstellen.
Manchmal ändern sich im Laufe des Projekts die Rahmenbedingungen oder sogar die Prozesse. Die Notwendigkeit einer software-technischen Anpassung kommt dann erst bei der Integration zum Vorschein.
Nicht umgesetzte, aber notwendige Anpassungen und Schnittstellen haben zur Folge, dass die Integration der Software in den betrieblichen Prozess entweder ins Stocken gerät oder gar nicht mehr stattfindet. Auf diese Weise entstehen in den Fachabteilungen sogenannte „Insellösungen“.
Häufig sind in den Unternehmen eine ganze Reihe von diesen „Insellösungen“ vorzufinden; teils sogar mit gleicher oder ähnlicher Funktionalität („Parallel-Welten“) und natürlich auch teils mit „Input/-Output-Schnittstellen“ zu MS-Office-Produkten.
Eine spätere Verknüpfung dieser autarken Systeme gestaltet sich in der Praxis recht schwierig. Gerade bei „Parallel-Welten“ existieren häufig für gleiche Funktionen unterschiedliche gewachsene Standards (Normierung, Vorgangsbearbeitung, u. a.). Dieses führt wiederum zu Interessenkonflikten und zu Widerständen bei einer digitalen Vernetzung der Systeme und bei Mitarbeitern.
Damit die Wahl der „passenden“ Software keine Insellösung wird, ist es für die Fachabteilungen eine enorme Herausforderung, diese technischen und organisatorischen Einflussfaktoren zu ermitteln, zu formulieren und bei der
Entscheidungsfindung zu berücksichtigen.
IMS Engineers, mit seiner jahrelangen Erfahrung bei der Einführung solcher Systeme, unterstützt Sie bei allen konzeptionellen, organisatorischen und fachlichen Fragestellungen.
