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:
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:
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):
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
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
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.
- Unterschätzung des Aufwands (intern / extern)
- Zu wenig Reservekapazitäten (intern / extern)
- Abhängigkeit von Einzelpersonen
- Projektmanagement – Defizite
- Etc.
- Unterschätzung des Aufwands (siehe oben)
- Mangelhafte Spezifikation
- Hohe Anzahl von Änderungsanforderungen
- Projektvertrag mit geringem Fixkostenanteil
- Fehlende Risk Sharing Vereinbarungen
- Etc.
