Bewertungsverfahren

Quellenverweis

Kon96, Schw04, Wil75, Wan02, PD99, LMTC01, AF02

Sinn und Zweck

Im Rahmen von IT-Projekten ergibt sich immer öfter der Bedarf nach Verfahren, mit denen Vorgaben wie die Anforderungen (Lastenheft), die Evaluierung von Fertigprodukten oder die Gesamtsystemspezifikation (Pflichtenheft) nach möglichst transparenten und nachvollziehbaren Kriterien qualitativ wie quantitativ bewertet werden können. Im Laufe der letzten 10 Jahre haben sich hierfür einige Standardbausteine herauskristallisiert.

Weighted Scoring Model (WSM)

Einer dieser Standardbausteine ist das gewichtende Bewertungsmodell (WSM) [Schw04]. In einem ersten Schritt werden hierbei Bewertungskriterien definiert, die dann nach Bedeutung für das Gesamtsystem gewichtet werden (z.B. essentiell, sehr wichtig, wichtig, nice-to-have, oder 10, 7, 5 oder 3 Punkte). In der Evaluierung wird der Erfüllungsgrad der einzelnen Kriterien festgehalten, z.B. 70%. Durch die Multiplikation des Erfüllungsgrades mit der Punktzahl pro Kriterium ergibt sich das Bewertungsresultat, z.B. 70% * 7 Punkte = 4,9 Punkte. Die Summe aller bewerteten Kriterien ergibt die Bewertung des Bewertungsgegenstands, die dann mit den Ergebnissen der anderen Punkte verglichen werden kann. Zusätzlich können noch Mindestpunktzahlen definiert werden, bei deren Unterschreiten durch sämtliche Teilaspekte entsprechende Folgerungen für das Gesamtprojekt eintreten (wenn dies etwa für Fertigprodukte ergibt, dass ein Zukauf keine realistische Möglichkeit mehr darstellt, sondern nur noch die Individualentwicklung als gangbarer Weg bleibt).

Analytic Hierarchy Process (AHP)

Ähnlich ist das AHP-Verfahren, dass ebenfalls auf einer Entscheidungsmatrix beruht. Die Kriterien werden in Hierarchieebenen der Relevanz entsprechend angeordnet und paarweise miteinander verglichen und ausgewertet (s.u.a. Kon96).

Beiden Methoden, aber insbesondere dem AHP, ist das Risiko gemein, dass das Gesamtmodell durch falsche Gewichtungen in sich inkonsistent wird und somit seine Aussagekraft verliert. Auch in Hinsicht auf den mit der Evaluierung verbundenen Aufwand sollte also immer darauf geachtet werden, dass sich die Komplexität des Modells in Grenzen hält.

Sonderfall COTS-Software

Ziel der Evaluierung von Standardsoftware bzw. Softwarekomponenten ist es, Vergleichsmethoden und -kriterien zu finden und anzuwenden, die die Bewertung und Auswahl von Fertigprodukten ermöglichen. Dies ist ein Thema, das seit etwa 1990 international diskutiert wird, seitdem zunehmend nicht mehr die individuellen Systementwicklungen, sondern der Einsatz und die Integration von Standardapplikationen im Vordergrund des kommerziellen IT-Einsatzes stehen.

Transaktionskostenanalyse

Generell wurde das Thema zunächst im Bereich der Industrieproduktion akut, aber bald auch für den IT-Bereich übernommen: ist es kostengünstiger und effektiver, ein Teil- oder Endprodukt selbst zu fertigen oder zuzukaufen? Hierzu wurde die Transaktionskostentheorie (TCT) [Wil75, Wan02] entwickelt, die die einzelnen Komponenten zunächst danach bemisst, wie spezifisch sie für den fraglichen Prozess sind: je spezifischer, desto eher empfiehlt sich die Eigenproduktion und je weniger spezifisch, umso sinnvoller ist der Zukauf. Zum zweiten werden die Unwägbarkeiten, die Risiken, bewertet, gefolgt von der Häufigkeit des Einsatzes und der Reputation des Anbieters als Kriterien für die Eigen- oder Fremdproduktion.

Zwischenzeitlich entstand eine Vielzahl von Modellen, die Kombinationen unterschiedlicher Bewertungsverfahren propagieren [als kleine Auswahl s. Kon96 , PD99, LMTC01 , AF02].