26 WISSEN 27 1 Einleitung Die Arbeitsteilung in unserer Wirtschaft wird immer stärker und die Wertschöpfungskette des einzelnen Unternehmens damit immer kürzer. Dies führt dazu, dass in vielen Fällen zur Softwareentwicklung externe Auftragnehmer eingesetzt werden. Nicht vorhandenes oder nicht verfügbares Fachpersonal, kurze Projekt-Umsetzungszeiten und ein rasanter Technologiewechsel tragen ebenfalls dazu bei, ein komplettes Projekt an einen externen Dienstleister zu vergeben. Fachliche Anforderungen, Vorgaben zur IT-Technik und Rahmenbedingungen für das Projekt In diesem Beitrag soll für IT-gestützte Vorhaben ein Vorgehen zum Requirements Engineering vorgestellt werden, das die systematische Erfassung der Anforderungen zur Umsetzung des Systems und die Auswahl eines geeigneten Realisierers ermöglicht. Insbesondere werden Projekte im Forschungs- und Entwicklungsbereich betrachtet, die kundenspezifische Entwicklungen und keine Anpassung/ Weiterentwicklung von Standard-Software zum Inhalt haben. Requirements Engineering ist hier sehr weit gefasst und enthält nicht nur die technischen Anforderungen an das System, sondern auch die Anforderungen an den Auftragnehmer (AN), die Integration in die betrieblichen Abläufe, die Qualitätssicherung sowie die Bewertung der Anbieter. Requirements Engineering Wie findet man einen Auftragnehmer für die Umsetzung eines IT-gestützten Vorhabens? Thomas Batz, Kym Watson Thema dieses Beitrages ist, wie ein Unternehmen für eine kundenspezifische Software- Entwicklung in geeigneter Weise eine Ausschreibung durchführt und dabei einen Auftragnehmer auswählt. Wesentlichen Einfluss auf den Inhalt des Projekts haben auch die im Projekt eingesetzten Technologien, die Bedeutung des Projekts für das Unternehmen, die zur Verfügung stehende Entwicklungszeit sowie die Betriebsdauer des Systems. Neben den fachlichen, anwendungsorientierten Anforderungen an das System spielen auch die nichtfachlichen Anforderungen z. B. aus der IT-Technik (Einbindung des Projekts in die vorhandene IT-Landschaft, bestehend u.a. aus Netzen, verfügbaren Daten, bereits eingesetzten Systemen und Entwicklungsumgebung) eine wesentliche Rolle für den Erfolg des Projekts. Die Qualität des Auftragnehmers (Nachweis durch erfolgreiche Referenzprojekte und verfügbares, qualifiziertes Personal) ist bei den immer komplexer und interdisziplinärer werdenden Projekten ebenfalls von großer Bedeutung. Als standardisierte Methode zur Beschreibung und Bewertung von Anforderungen wird UfAB (Unterlagen für Ausschreibung von IT-Leistungen) verwendet, welche sehr häufig von öffentlichen Auftraggebern eingesetzt wird, aber durchaus auch für den Einsatz in Unternehmen geeignet ist. UfAB und deren Bewertungsschema werden kurz vorgestellt und anhand eines Beispiels erläutert. 2 Art des Projekts Neben der Umsetzung einer konkreten Fachaufgabe werden häufig auch Nebenziele wie das Kennenlernen neuer Techniken verfolgt. Diese sowie die vorhandenen Rahmenbedingungen haben Auswirkungen auf die Gestaltung und den Leistungsumfang des Projekts. Bezüglich der einzusetzenden Technologie ist es wichtig, ob diese bereits im Unternehmen weit verbreitet ist und die im Unternehmen getroffenen Festlegungen zu Werkzeugen, Programmierrichtlinien etc. berücksichtigt werden müssen. In der Regel muss auch eine Integration mit existierenden Systemen erfolgen, da z. B. vorhandene Daten benötigt oder die Infrastruktur wie Directory- Services, User-Verwaltung oder Authentifizierungsmechanismen genutzt werden sollen. Die zeitliche Dimension des Projekts (Entwicklungs- und Betriebszeit) und der Systemlebenszyklus haben ebenfalls erhebliche Auswirkungen auf notwendige Festlegungen. Bei langen Entwicklungszeiten sind verschiedene Ausbaustufen sinnvoll, ebenso sollte auf Veränderungen der Anforderungen reagiert werden können. Bei langen Betriebszeiten ist ebenfalls auf Anpassbarkeit gegenüber veränderten Anforderungen und den eingesetzten Technologien zu achten. Außerdem ist festzulegen, wer den Betrieb und die Weiterführung des Projekts nach Abschluss des Entwicklungsauftrags übernimmt. 3 Voraussetzungen zur Projektdurchführung Bevor ein Projekt ausgeschrieben werden kann, müssen aktuell projekt M A N A G E M E NT 4/ 20 0 4 projekt M A N A G E M E NT 4/ 20 0 4 aktuell 28 WISSEN 29 eine Reihe von Festlegungen getroffen werden, die über die offensichtlich notwendige Beschreibung des Leistungsumfangs hinausgehen. Sie betreffen insbesondere die derzeitig oder zukünftig vorhandene IT-Infrastruktur (sowohl Vernetzung, Hardwie auch Software) sowie die Integration mit vorhandenen Verwaltungs- und Fachdaten. Die Integration der neu geschaffenen organisatorischen Abläufe mit den vorhandenen ist ebenfalls zu berücksichtigen. 3.1 Festlegung des Leistungsumfangs Insbesondere ist vor Beginn eines Projekts festzulegen, welche Leistungen vom AN durchzuführen sind. Dies betrifft neben den fachlichen Anforderungen insbesondere die Beteiligung des AN innerhalb des Software- Lebenszyklus (bei QS-Maßnahmen, Tests, Inbetriebnahme, Wartung, Erstellung des Pflichtenhefts oder des Systemkonzepts). 3.2 Anforderungen an den Anbieter Viele Probleme bei der Durchführung von Projekten entstehen dadurch, dass Auftraggeber und Auftragnehmer einen unterschiedlichen fachlichen Hintergrund haben und nicht die gleiche (Fach-)Sprache sprechen. Daher sollte ein potenzieller Anbieter seine Fachkenntnis mittels erfolgreich durchgeführter Projekte in diesem oder einem vergleichbaren Anwendungsgebiet nachweisen. Für den AG ist es ebenfalls wichtig, dass insbesondere bei kritischen oder fachlich anspruchvollen Projekten Nachweise über das vom AN in diesem Projekt einzusetzende Personal vorliegen. 3.3 Anforderungen an das System Die Anforderungen an das System lassen sich im Wesentlichen in die drei Bereiche fachliche Anforderungen, Vorgaben bzgl. IT-Technik und Rahmenbedingungen für das Projekt unterteilen. Je nach Projekttyp (Neuentwicklung oder Erweiterung/ Veränderung eines bestehenden Systems) sind unterschiedliche Dokumente zu erstellen. Bei der Neuentwicklung sind die Festlegungen aus der Projektart zu berücksichtigen. Ergebnis ist ein Pflichtenheft mit einer systematischen Erfassung und Klassifikation der fachlichen Anforderungen sowie häufig auch eine Beschreibung der Systemarchitektur. Bei der Erweiterung/ Veränderung müssen meist nur die Unterschiede zum bereits eingesetzten System beschrieben werden. Dies kann in einem Textdokument oder einer Tabelle erfolgen, in der die geplanten Änderungen/ Erweiterungen priorisiert werden. In der Regel müssen verschiedene Personen aus unterschiedlichen Organisationseinheiten mit unterschiedlichem technischem Hintergrund zusammenarbeiten, um gemeinsam ein konsistentes Ergebnis zu erreichen. Ein Glossar, Abkürzungsverzeichnis und eine Festlegung auf häufig verwendete grafische Symbole sind dazu sehr sinnvoll. Während die Fachvorgaben und die Vorgaben bzgl. IT- Technik für die Beteiligten meist einfach zu erfassen sind, werden die Rahmenbedingungen für das Projekt häufig nicht genau genug betrachtet. Sie sind aber für den Projekterfolg von wesentlicher Bedeutung. In den meisten Fällen sind die einzelnen Aspekte des zu realisierenden Systems, die im Pflichtenheft zusammengefasst werden, in unterschiedlichen, zum Teil bereits existierenden Dokumenten beschrieben, die von den verschiedenen beteiligten Gruppen (Fachabteilung, IT-Abteilung) erstellt wurden. Innerhalb des Pflichtenhefts muss daraus eine einheitliche, konsistente und im Rahmen der Abnahme überprüfbare Darstellung erzeugt werden, z. B. in Form von einer thematisch gruppierten Liste, die Aussagen in der Form „… muss … erfüllen“, „… soll …“ oder „… darf nicht …“ enthält. Wenn möglich sollte dabei ein Bezug zu der Stelle und dem Dokument angegeben werden, die Quelle für diese Pflicht ist. Im Pflichtenheft zu behandeln sind u. a. Bedienoberflächen, Ablaufmodellierung, Datentypen bzw. -kategorien. Bei größeren Projekten sollte das Risiko bewertet werden Wenn das neu zu entwickelnde System Schnittstellen zu existierenden Systemen hat oder auf einer vorhandenen Infrastruktur aufsetzt, wird mit der Ausschreibung auch eine Systemarchitektur vorgegeben, in der die bisherige Systemlandschaft (z. B. Legacy-Systeme, [unternehmensweite] Datenbanken, Verzeichnisdienste, interne und externe Schnittstellen sowie zugrunde liegendes Netz) sowie die Voraussetzung für die Benutzerumgebungen (Kenntnisse, Rechnerausstattung sowie Netzwerkanbindung) beschrieben werden. Dies hat zum Teil erhebliche Auswirkungen auf die Auslegung, die Benutzbarkeit (generelle Verfügbarkeit, Antwortzeit, Stabilität) und damit auch auf die Akzeptanz des Systems. Insbesondere sind auch Leistungsmerkmale des Systems wie Systemleistung/ Mengengerüst (Anzahl der Nutzer, Zahl parallel arbeitender Nutzer, Zahl und Art der parallel durchgeführten Aktionen, Menge der übertragenen Daten, Gesamtmenge der Daten und tolerierbare Antwortzeiten), Verfügbarkeit (Betriebszeit, tolerierbare Ausfallzeit, Festlegung von maximaler Wiederherstellungszeit) und System- und Datensicherheit festzulegen. 3.4 Nutzer Die Nutzerverwaltung ist meist eine anspruchsvolle Aufgabe, deren Konsequenzen sich häufig erst beim Echtbetrieb des Systems herausstellen. Z. B. kann der Pflegeaufwand zum Einrichten neuer Benutzer, zur Änderung der für einen Nutzer verfügbaren Rechte und zum Löschen eines Nutzers, zum Entzug seiner Rechte sowie zur Behandlung der ihm zugeordneten Daten (z. B. Löschen oder Übertragen auf andere Benutzer) sehr hoch sein. Eine Integration mit der in der Regel bereits vorhandenen Nutzerverwaltung könnte sinnvoll sein (z. B. im Sinne von Single-Sign-On). Eingesetzte Techniken sind Rollen, Benutzergruppen mit zugeordneten Rechten und Verzeichnisdienste. 3.5 Projektrisiken Zumindest bei größeren und/ oder für den Unternehmenserfolg kritischen Projekten, insbesondere wenn sie eine längere Einsatzzeit haben und/ oder die Basis aktuell projekt M A N A G E M E NT 4/ 20 0 4 projekt M A N A G E M E NT 4/ 20 0 4 aktuell 28 WISSEN 29 Anzeige für mehrere Entwicklungen bilden, sollte das Risiko bewertet werden. Dies geschieht am besten auf mehreren Ebenen, zum einem im Zusammenhang mit der Erstellung der Anforderungen an das zu realisierende System, zum anderen bei der Bewertung der Angebote und zum Dritten regelmäßig während der Durchführung des Projekts. Die vier Submodelle des Vorgehensmodells Während bei der Risikobewertung der Anforderung insbesondere die Systemarchitektur und die vorgeschlagenen Techniken im Mittelpunkt stehen, sind es bei der Risikobewertung der Angebote der Projektplan, die Projektstruktur, die einzusetzenden Software-Werkzeuge und Komponenten, das eingeplante Personal (und die Verteilung bestimmten kritischen Wissens auf einzelne Personen) sowie die verfeinerte Systemarchitektur. Während der Projektdurchführung sind insbesondere Abweichungen von der Planung, nicht oder nicht rechtzeitig verfügbares Personal, unvorhergesehene Störungen sowie fehlerhafte oder unvollständige Annahmen und ihre Auswirkungen auf das Projekt zu bewerten. 4 Planung der Projektdurchführung Eine wesentliche Aufgabe zwischen AG und AN ist die gemeinsame Festlegung der Form der Projektdurchführung (siehe Abb. 1). Dabei ist zu klären, in welchen Schritten (Aktivitäten) das Projekt durchgeführt wird (Vorgehensmodell), welche Ergebnisse und Zwischenergebnisse geplant sind, welche Stellen (Rollenmodell) beteiligt sind, welche Methoden und Werkzeuge eingesetzt werden und wie die Zusammenarbeit (bei der normalen Projektarbeit wie auch bei Unstimmigkeiten) geregelt ist. Beim Vorgehensmodell ist eine Orientierung an gängigen Verfahren sinnvoll. Im Idealfall kann man auf ein beim AG verfügbares, häufig eingesetztes und an das konkrete Projekt anpassbares Modell zurückgreifen. Wesentlich für diese Auswahl sollte auch sein, dass die für die Projektarbeit (inkl. Management und Controlling) notwendige Information mit angemessenem Aufwand in übersichtlicher und konsistenter Art erstellt und gepflegt wird und das Vorgehensmodell keinen „Papiertiger“, d. h. eine Vielzahl von wenig aussagekräftigen, Inkonsistenzen fördenden und schwer wartbaren Dokumenten erzwingt. Häufig, insbesondere bei Projekten von öffentlichen Auftraggebern, wird das V-Modell [3, 4] vorgeschrieben. Dabei ist zu überprüfen, ob die Vorgehensweise (Wasserfallmodell) für das jeweilige Projekt passend ist, ein geeignetes Tayloring (durch qualifizierte Mitarbeiter von AG und AN) durchgeführt werden kann und ob die nach dem V-Modell zwingend notwendigen Dokumente die wesentlichen Aspekte des Projekts und seines Verlaufs widerspiegeln. Im Vorgehensmodell werden üblicherweise für die Themen Softwareentwicklung (SE), Qualitätssicherung (QS), Projektmanagement (PM) und Konfigurationsma- ������� ������ ���������� ������ ������������������ ������������������ ����������� ���������� �������� ���������� ��������������� ���������� ���������� ���������� ������� ����������� ������������ ��������� ��������� �������������� �������������������� ������������� ������������ �������� Abb. 1: Tätigkeitsbereiche [2] aktuell projekt M A N A G E M E NT 4/ 20 0 4 projekt M A N A G E M E NT 4/ 20 0 4 aktuell 30 WISSEN 31 nagement (KM) (siehe generell Abb. 1) spezifische Regelungen getroffen, wobei jeweils die Akteure, Aktivitäten und Ergebnisse beschrieben werden. Auf alle Fälle sollte ein nicht zu unterschätzender Aufwand in die Erstellung geeigneter Dokumentvorlagen fließen, da die Festlegung der notwendigen Dokumente sowie die Qualität der Dokumentvorlagen den Erfolg oder Misserfolg des Projekts erheblich beeinflussen werden. 4.1 Zusammenarbeit Auftraggeber  Auftragnehmer Auch während der Durchführung eines Projekts sind zwischen AG und AN vielfältige Dinge zu klären. Teilergebnisse müssen abgestimmt werden, der aktuelle Status kommuniziert, auftauchende Probleme oder Veränderungen des Umfeldes sowie der Projektaufgabe berücksichtigt werden. Dazu ist die Zusammenarbeit zwischen AG und AN festzulegen. Dies geschieht meist mittels regelmäßig stattfindender Sitzungen, deren Zusammensetzung, Tagungshäufigkeit, Tagungsort und Vorgehensweise (Tagesordnung, Protokoll) festgelegt werden müssen. Zusätzlich können bestimmte Sitzungen zu definierten wesentlichen Ereignissen (z. B. Meilensteinpräsentationen, Reviews) vorgesehen sein. Für die Klärung größerer Probleme sollte ebenfalls eine Vorgehensweise z. B. mittels eines übergeordneten Steuergremiums festgelegt werden. Dies alles geschieht in der Regel im Projekthandbuch, das wegen der Auswirkungen auf die Kosten in groben Zügen bereits zum Ausschreibungszeitpunkt vorliegen sollte. Der aktuelle Projektstatus sollte in regelmäßigen Abständen (ein Monatsrhythmus hat sich in den bisherigen Projekten als sehr sinnvoll erwiesen) in einem Statusbericht dokumentiert und kommuniziert werden. 4.2 Qualitätssicherung Da Qualitätssicherung nur funktioniert, wenn bereits zur Projektdurchführung (und nicht erst bei der Abnahme) die notwendigen Maßnahmen ergriffen werden, müssen die als notwendig angesehenen Maßnahmen vorab definiert werden. Dies beginnt bei einzuhaltenden Richtlinien (Programmierung, Dokumentation, Namenskonvention etc.) und führt hin bis zu Code- Inspektion und Tests. Festzulegen ist insbesondere, wer welche Teile davon übernimmt, wie die Dokumentation der durchgeführten Maßnahmen und ihrer Ergebnisse erfolgt, wem berichtet wird und welche Konsequenzen die Nichteinhaltung der Richtlinien sowie die Nichterfüllung von Tests hat. 4.3 Abnahme und Tests Um die Qualität des Projektergebnisses oder etwaiger Zwischenergebnisse zu bewerten, sollten zwischen AG und AN eindeutige Regelungen festgeschrieben werden. Für Dokumente wird häufig ein Review vereinbart, für Software sind Abnahmetests ein übliches Mittel. Das Verfahren sollte im Vorhinein (z. B. im Projekthandbuch) festgelegt werden. Gängiges Verfahren ist der Nachweis der erfolgreichen Testdurchführung beim AN als Voraussetzung für eine Installation der Software auf dem Testsystem beim AG. Dort wird üblicherweise die Funktionsfähigkeit des Systems z. B. anhand einiger relevanter Testfälle gezeigt, bevor die eigentlichen Tests durch den AG beginnen. Die durchzuführenden Tests werden in der Regel in einem eigenständigen Testhandbuch beschrieben. Dabei ist besonderer Wert darauf zu legen, dass die Tests nachvollziehbar und ausreichend dokumentiert sind und die Erfüllung des Tests anhand objektiver Kriterien bewertet werden kann. Häufig werden die Testfälle in Szenarien beschrieben. 4.4 Projekthandbuch Um die hier angedeuteten Themenbereiche und insbesondere die durchzuführenden Aktivitäten für ein konkretes Projekt zwischen AG und AN festzulegen, wird in der Regel ein projektspezifisches Projekthandbuch erstellt. 5 Methode zur Erstellung einer Ausschreibung Die Anforderungen an ein zu realisierendes System sollten in einer standardisierten Art und Weise erfasst werden, die für verschiedene Ausschreibungen verwendet werden sollte und am besten bereits im Unternehmen eingeführt ist. Anforderungen müssen standardisiert und strukturiert werden Sinnvoll ist es, die Anforderungen klar zu strukturieren und z. B. in drei Gliederungsebenen einzuteilen. Dies erleichtert den Überblick und bietet die Chance, möglichst wenig zu vergessen. Die einzelnen Einträge sollten im Verhältnis zu den anderen Einträgen dieser Ebene gewichtet werden (z. B. durch Punkte). Des Weiteren sollten einige wenige Ausschlusskriterien (bei Nichterfüllung eines dieser Kriterien wird das Angebot ausgeschlossen) definiert werden, die Art der Antworten sowie ein Bewertungsschema und ein Verfahren zur Bewertung von Leistung und Kosten festgelegt und am besten öffentlich gemacht werden. Dies wird anhand der Methode UfAB (Erläuterung siehe Kapitel 6) für ein kleines Beispiel in Abschnitt 7 dargestellt. Wenn es vom Verfahren her möglich ist, sollten zu erstellende Dokumente (mindestens zusätzlich) elektronisch eingereicht werden. Auch für ausschließlich papierbasierte Angebote sollten wegen der Vergleichbarkeit Vorgaben für die Dokumentstruktur gemacht werden. Ein ausfüllbares Formblatt über die entstehenden verschiedenen Kosten in einem gegebenen Zeitraum und ihre Zusammensetzung ist für die Vergleichbarkeit der verschiedenen Angebote sehr empfehlenswert. 5.1 Erstellung eines mehrstufigen Pflichtenheftes Das dreiteilige Pflichtenheft sollte umfassen:  einen kurzen Überblick über das Gesamtsystem: Was soll das Gesamtsystem leisten, welche Benutzungs- Szenarien sollen mit dem System durchgeführt werden können?  eine ausführliche Beschreibung der Software-Architektur: Wie sieht die zu realisierende Software-Architektur aus, welche detailliert beschriebenen Aufgaben aktuell projekt M A N A G E M E NT 4/ 20 0 4 projekt M A N A G E M E NT 4/ 20 0 4 aktuell 30 WISSEN 31 haben die Komponenten und deren Subkomponenten, wie ist das Zusammenspiel? Auch die anderen im bisherigen Text erwähnten Themenbereiche wie Performance, Nutzerverwaltung, einzusetzende Technologien müssen hier abgehandelt werden;  die Beschreibung der Pflichten: detaillierte Beschreibung der einzelnen Pflichten (Systemaufgaben), Basis für die Überprüfbarkeit im Systemtest, exakt formuliert und nachprüfbar. Sinnvoll ist es, bereits für den Systemüberblick eine tragfähige Struktur zu finden und diese im zweiten Teil zu verfeinern. Da der dritte Teil eine exaktere und nachprüfbare Beschreibung des 2. Teils darstellt, kann und sollte die Gliederung ohne weitere Veränderung übernommen werden. 5.2 Ausschreibung Ein wesentlicher Schritt im Hinblick auf die Vergabe eines Projekts ist die Ausschreibung und die daraus resultierenden Angebote. Die Ausschreibung muss alles enthalten, damit ein aussagekräftiges und ein einfach und möglichst objektiv vergleichbares Angebot erstellt werden kann. Pflichtenheft und Systemarchitektur sind meist eigenständige Dokumente, die Teil der Ausschreibung sind. UfAB ermöglicht eine rasche, eindeutige und vollständige Ausschreibung Die Gliederung (Abb. 2) stellt ein Muster für die Ausschreibung dar, bei dem insbesondere auf die Erfahrung des Anbieters mit fachrelevanten Themen sehr großer Wert gelegt wurde. Antworten zu den Einzelpunkten können „Ja“ bzw. „Nein“ auf eine Frage, Daten/ Werte, Beschreibungen für komplexere Sachverhalte, Unterlagen als Nachweise für bestimmte Aussagen oder eine Kombination sein.  Bieterdarstellung, bestehend aus  Erfahrungen (Projekte ähnlicher Komplexität, einzusetzende Technologien, einzusetzende Software- Werkzeuge, Fachgebiet)  Erfahrungen des für das Projekt vorgesehenen Personals in oben genannten Gebieten  Verfügbarkeit dieses Personals für die vorgesehenen Einsatzzeiten im Projekt  Fähigkeit des Unternehmens, ein derartiges Projekt durchzuführen, im Hinblick auf  Größe des Unternehmens  Personalausstattung/ -verfügbarkeit in den Kernbereichen des Projekts  Unternehmensstruktur (u. a. Standorte), auch in der Wartungsphase  verfügbare Hard- und Softwareausstattung für die Entwicklungsarbeiten und notwendigen Tests  Anzahl und Aufgabenbereich von Unterauftragnehmern bzw. Projektpartnern (z. B. bei Bietergemeinschaften)  Bereitschaft zum Abschluss eines Vertrages, der den Gepflogenheiten des Auftraggebers entspricht (z. B. bei öffentlichen Auftraggebern BVB*-Verträge)  Darstellung der zu lösenden Aufgabe  IT-System und dessen Randbedingungen (Software- Architektur, Quellcode-Verwaltung, Dokumentation)  Projektablauf (Zeitplan)  Dokumentation  Wartung  Schulung  Rechte an der Software  Weiterentwicklung * Besondere Vertragsbedingungen für die Beschaffung von DV-Leistungen (BVB) Abb. 2: Muster für die Gliederung einer Ausschreibung Anzeige aktuell projekt M A N A G E M E NT 4/ 20 0 4 projekt M A N A G E M E NT 4/ 20 0 4 aktuell 32 WISSEN 33 6 UfAB III Die hier gewählte Bewertungsmethode ist den Unterlagen für Ausschreibung und Bewertung von IT-Leistungen (UfAB) [1] entnommen, welche vom Bundesministerium des Innern herausgegeben wurden (OI3-195 257-1/ 15, Stand: Version 1.0 vom Dezember 2003) und für viele IT- Projekte im öffentlichen Bereich verbindlich sind. Ziel von UfAB ist es, dass Informationstechnik (IT) nach einheitlichen Grundsätzen beschafft wird. Dazu wurden die in UfAB vorliegenden Unterlagen für die Erstellung von Ausschreibungen sowie für die Bewertung von Angeboten zur Beschaffung von IT-Leistungen entwickelt. UfAB soll es ermöglichen, auf der Grundlage der Verdingungsordnung für Leistungen eine Ausschreibung über IT-Leistungen rasch, eindeutig und vollständig zu erstellen, die IT-Ausschreibungen in Form, Aufbau und Inhalt einheitlich zu gestalten, die Auswertung der Angebote einfach, rationell und objektiv vorzunehmen sowie dazu beitragen, die Formulierung der Angebote durch die Bieter, die Kommunikation zwischen Bieter und ausschreibender Stelle sowie die Entscheidungsvorbereitung zu erleichtern. Das Konzept der UfAB geht von der Grundidee aus, dass Ausschreibungen nicht produktorientiert, sondern grundsätzlich anwendungsbezogen (aufgabenbezogen) durchgeführt werden (in der VOL/ A, der Verdingungsverordnung für Leistungen, ausgenommen Bauleistungen (VOL), Teil A: Allgemeine Bestimmungen für die Vergabe von Leistungen, als „Ausschreibung mit funktionaler Leistungsbeschreibung“ bezeichnet). Diese Art der Ausschreibung hat sowohl für den Bieter als auch für die ausschreibende Stelle Vorteile:  Die ausschreibende Stelle ist aufgrund der genauen Kenntnis der zu erfüllenden Aufgabe am besten in der Lage, die für eine optionale Aufgabenerfüllung wichtigen Fragen und Forderungen zu erkennen und in der Ausschreibung zu formulieren. Die Bieter wiederum können aus der Fülle ihrer Produkte, die sie besser als die ausschreibende Stelle kennen, diejenigen auswählen und anbieten, die nach ihrer Meinung für die Erfüllung der Forderungen am besten geeignet sind.  Die in diesen Unterlagen vorgeschlagenen Verfahren zur Bewertung der Angebote sollen dem Entscheidungsträger dabei helfen, das wirtschaftlichste Angebot festzustellen. Die Ausschreibungen lassen sich grob in drei Kategorien unterteilen, wobei sich Art und Umfang der zu erstellenden Leistungsbeschreibungen und der zu beschaffenden IT-Leistung an dem Wissensstand der ausschreibenden Stelle orientieren.  Funktionale anwendungsbezogene Leistungsbeschreibung: Die Leistungsbeschreibung hält sich streng an den Grundsatz, dass Ausschreibungen über IT- Leistungen anwendungsbezogen (aufgabenbezogen) durchgeführt werden sollen.  Funktionale anwendungsneutrale Leistungsbeschreibung: Die Beschaffung von Betriebssystemen, systemnaher Software wie Dienstprogramme, Anwendungs- Entwicklungs-Werkzeuge (Tools) und Compiler sowie Standardsoftware zur Tabellenkalkulation, Grafikerstellung, Textverarbeitung, Datenverwaltung u. Ä. erfolgt im Allgemeinen über eine anwendungsneutrale Leistungsbeschreibung. D. h. anstelle der Anwendungsbeschreibung gibt die ausschreibende Stelle eine Übersicht der geforderten Funktionen vor.  Konstruktive Leistungsbeschreibung: Unter der Voraussetzung, dass die ausschreibende Stelle dazu in der Lage ist, bietet sich u. U. auch diese Art der Leistungsbeschreibung bei der Beschaffung von Arbeitsplatzcomputern an. UfAB basiert auf der Nutzwertanalyse und gewichtet die einzelnen Anforderungen UfAB liefert für eine derartige Ausschreibung einen Gliederungsvorschlag, einzelne generische Textbausteine sowie ein Verfahren zur Strukturierung und Gewichtung der Anforderungen an das zu realisierende System. Vorschläge zur Bewertung des Ergebnisses sind ebenfalls Bestandteil der Methode. 6.1 Bewertung Die angebotene Leistung wird unter Zuhilfenahme von gewichteten Kriterien bewertet. Die Kriterien werden in die drei Gruppen Kriterienhauptgruppe, Kriteriengruppe und Einzelkriterium hierarchisch gegliedert. Die Beschränkung auf drei Stufen dient der Übersichtlichkeit und verhindert stark unterschiedliche Detaillierungsgrade. UfAB sieht zwei Möglichkeiten (Variante A und B) zur Festlegung der Gewichte vor: In Varianten A gilt:  Die Summe sämtlicher Kriterienhauptgruppengewichte beträgt 10.  Die Summe sämtlicher Gewichte der Kriteriengruppen innerhalb der gleichen Kriterienhauptgruppe beträgt 10.  Die Summe sämtlicher Gewichte der Einzelkriterien innerhalb der gleichen Kriteriengruppe beträgt 10.  Für ein Einzelkriterium sind maximal 10 Punkte zu vergeben. Bei Variante B dürfen die Gewichtssummen von obigen Vorgaben abweichen, die Gesamtpunktzahl muss 10.000 betragen. Die Gesamtpunktzahl eines Angebotes wird mit einem Bottom-up-Berechnungsverfahren ermittelt. Die Grundlage für die Vergabe von Punkten sollte für alle Einzelkriterien objektiv und nachvollziehbar sein. Sie wird intern bei der ausschreibenden Stelle dokumentiert, den Anbietern nicht offen gelegt. Ja-nein-Kriterien bekommen 10 Punkte für ja und 0 Punkte für nein. Daneben sollte man Ausschlusskriterien sowie Mindesterfüllungsgrade (Mindestpunktzahlen) für das Gesamtangebot sowie für bestimmte kritische Teilbereiche definieren. Damit kann man sicherstellen, dass der Realisierer gerade in den für zentral erachteten Bereichen Stärken hat. Ausschlusskriterien sind Bedingungen, die jeder Anbieter uneingeschränkt erfüllen muss. Ausschlusskriterien und Mindesterfüllungsgrade müssen den Anbietern bereits in der Ausschreibung bekannt gemacht werden. Bei einem Vorgehen nach den UfAB sind die Preise bzw. Kosten nicht Bestandteil der eigentlichen Punktebewertung. Sie werden über eine Leistungs-Kostenaktuell projekt M A N A G E M E NT 4/ 20 0 4 projekt M A N A G E M E NT 4/ 20 0 4 aktuell 32 WISSEN 33 Matrix in den Auswahlprozess einbezogen. Für die Kostenermittlung sollten nicht nur die Realisierungskosten, sondern auch die Folgekosten wie Schulung, Wartung, Lizenzgebühren betrachtet werden (Empfehlung: Die Gesamtkosten für eine Periode von drei Jahren gelten als Kostenrahmen). Da bei den unterschiedlichen Angeboten in der Regel sich sowohl Leistungen als auch Kosten voneinander unterscheiden und sich eine Rangfolge daher nicht auf einfache und offensichtliche Weise erstellen lässt, müssen Leistung und Kosten der noch zugelassenen Angebote zueinander ins Verhältnis gesetzt werden. Das beste Angebot nach der Leistungs-Kosten-Bewertung nach UfAB errechnet sich nach folgender Formel: LKB gew = G L × L + G K × (L max × K min )/ K Dabei sind: G L = Gewicht der Leistung G K = Gewicht der Kosten L = Leistungswert des zu bewertenden Angebots K = Kosten des zu bewertenden Angebots L max = Leistungswert des leistungsstärksten noch in die Auswahl einbezogenen Angebots K min = Kosten des kostengünstigsten noch in die Auswahl einbezogenen Angebots Die Reihenfolge der Angebote muss robust sein Ein üblicher Wert für G L ist 2 und für G K 1. Damit wird die Leistung doppelt so stark gewichtet wie die Kosten. Eine Veränderung dieser Werte kann u. U. eine erhebliche Änderung der Bewertungsreihenfolge nach sich ziehen. 6.2 Auswahl des günstigsten Bieters Nach der Angebotseröffnung sind folgende Schritte durchzuführen: 1. Aussondern der Angebote, die formale Kriterien oder Ausschlusskriterien nicht erfüllen, 2. Bewertung der einzelnen Kriterien pro Angebot, dabei Aussondern der Angebote, die die Mindestpunktzahl in einem Teilbereich nicht erfüllen, 3. Ermittlung des Gesamtergebnisses pro verbleibenden Bieter, 4. Aussondern der Angebote, die die Mindestpunktzahl für das Gesamtangebot nicht erfüllen, 5. Leistungs-Kosten-Bewertung pro Bieter, 6. Gegenüberstellung der Leistungs-Kosten-Bewertung, 7. Identifizierung des günstigsten Anbieters und Validierung des Ergebnisses. Falls alle Angebote auf hohem Leistungs- und niedrigem Preis-Niveau liegen, muss man prüfen, ob die Leistungsbewertung nicht zu großzügig durchgeführt wurde oder die Bewertungskriterien keine differenzierte Bewertung gestatten. Bei der Validierung der Reihenfolge der Angebote sollte geprüft werden, ob die Reihenfolge gleich bleibt, wenn bestimmte nicht ganz objektiv messbare Einschätzungen zwischen den verschiedenen in Frage kommenden Realisierern leicht verschoben werden, insbesondere, wenn mehrere eine nahe beieinander liegende Leistungs-Kosten-Bewertung aufweisen. Sofern dabei das Ergebnis robust ist, spricht dies für eine weitgehende Objektivität der durchgeführten Bewertung. Ferner sollte auch geprüft werden, ob das Angebot auskömmlich ist, d. h. ob die geforderte Leistung mit den im Angebot spezifizierten Kosten überhaupt realisierbar ist. Andernfalls darf das Angebot ebenfalls nicht berücksichtigt werden. Dies soll sicherstellen, dass ein Unternehmen in der Lage ist, den Auftrag abzuwickeln, ohne während der Bearbeitung dieses Projekts zwingend in existenzielle finanzielle Schwierigkeiten zu geraten und möglicherweise den Geschäftsbetrieb einstellen zu müssen. Dies könnte für den AG zu finanziellen Verlusten oder gravierenden Folgen führen, wenn z. B. das IT-System nicht rechtzeitig in Betrieb genommen werden kann. 7 Beispiel Zur Veranschaulichung wird ein fiktives Beispiel gewählt, bei dem zur Vereinfachung nur wenige für die Ausschreibung relevante Kategorien dargestellt werden. Berücksichtigung finden nur die Anforderungen an den Bieter, an das zu realisierende IT-System, an die zum System notwendige Schulung und an die Projektdurchführung. Auch in diesen Bereichen werden (willkürlich) nur einige wenige Aspekte herausgegriffen. Außerdem wird die dreistufige UfAB-Leistungsbewertungsmatrix auf zwei Stufen reduziert, d. h. in diesem Beispiel wird nicht mehr ausgeführt, wie die Anforderungen der Ebene 2 im Detail überprüft werden. Die Ausschlusskriterien (z. B. bzgl. Vertragsart, Antwortzeitverhalten, Support) sind ebenfalls weggelassen worden. Tabelle 1 enthält neben den Gewichtungen für die Hauptgruppen (HG) und Gruppen (G) auch eine Festlegung für die geforderten Mindestpunktzahlen. Für die Hauptgruppe Bieterdarstellung werden von den maximal erreichbaren 3.000 Punkten mindestens 2.000 gefordert, in der Hauptgruppe IT-System von 4.000 mindestens 2.750 und in der Hauptgruppe Projektdurchführung von 2.000 mindestens 1.500. Insgesamt müssen von den 10.000 möglichen Punkten mindestens 7.500 erreicht werden. Für die Hauptgruppe Schulung ist keine Mindestpunktzahl gefordert. In Tabelle 2 sind die Angebote von vier fiktiven Bewerbern bewertet worden, die die formalen Bedingungen und die Ausschlusskriterien erfüllt haben. In Abb. 3 sind diese Werte auf Hauptgruppenebene kumuliert und der Minimal- und Maximalpunktzahl gegenübergestellt worden. Bieter_2 kann bereits nach Bewertung der ersten Hauptgruppe aus dem weiteren Verfahren ausgeschlossen werden, da er die Minimalpunktzahl nicht erfüllt. Bieter_3 muss ebenfalls ausgeschlossen werden, da er - obwohl er die Mindestgesamtpunktzahl erreicht - in der Hauptgruppe Projektdurchführung unterhalb der Mindestpunktzahl liegt. Die beiden verbleibenden Anbieter Bieter_1 mit 8.470 Punkten und Bieter_4 mit 8.840 Punkten müssen, da beide in allen Kategorien die Mindestpunktzahl erreichen, in eine Rangfolge gebracht werden. Dies kann im einfachsten Fall über den Preis (Erstellungspreis oder Gesamtpreis über drei Jahre) oder über das Preis-Leistungs-Verhältnis erfolgen. Damit ist zusätzlich erreicht, dass das Ergebnis und die Durchführung des Ausschreibungsverfahrens nachvollziehbar dokumentiert sind. aktuell projekt M A N A G E M E NT 4/ 20 0 4 projekt M A N A G E M E NT 4/ 20 0 4 aktuell 34 WISSEN 35 8 Fazit Die bisherigen Ausführungen haben gezeigt, dass im Rahmen des Requirements Engineerings - der Suche nach einem geeigneten Auftragnehmer für die Umsetzung eines IT-gestützten Vorhabens - neben den fachlichen Anforderungen viele weitere Punkte zu bedenken und festzulegen sind. Diese nicht fachlichen Aspekte spielen für den Erfolg des Projekts häufig eine wesentliche, wenn nicht gar die wesentliche Rolle, werden aber häufig stark unterbewertet. UfAB hat sich bei mehreren Projekten bewährt Wesentlich für den Projekterfolg sind auch die Qualifikation des Anbieters sowie des von ihm eingesetzten Personals. Aufgrund der teilweise hohen Investitionskosten oder wegen der strategischen Bedeutung des Systems für den Geschäftsbetrieb müssen Vorkehrungen für den Zugriff auf die Quellen des eigentlichen Systems sowie der verwendeten Bibliotheken geschaffen werden, damit Dritte die Arbeiten fortsetzen können. Weitere behandelte Themen waren die notwendigen Festlegungen zur Zusammenarbeit zwischen AG und AN, damit die notwendigen Maßnahmen rechtzeitig ergriffen werden können, wenn das Projekt nicht wie geplant abläuft, sowie Festlegungen zum Test und zur Abnahme von Software. Des Weiteren wurde anhand des Verfahrens UfAB eine Methode vorgestellt, um die Anforderungen zu erfassen und standardisiert zu bewerten. Dies wurde auch mit Hilfe eines Beispiels illustriert. Die hier vorgestellten Vorgehensweisen wurden von den Autoren als projektbegleitendes Consulting in mehreren Projekten in verschiedenen Anwendungsgebieten mit Erfolg eingesetzt.  Literatur [1] Bundesministerium des Innern: UfAB III: Unterlagen für Ausschreibung und Bewertung von IT-Leistungen. Schriftenreihe der KBSt (Koordinierungs- und Beratungsstelle der Bundesregierung für Informationstechnik in der Bundesverwaltung im Bundesministerium des Innern), Version 1.0, Band 60, Dezember 2003 [2] Fischer, Th.; Biskup, H.; Müller-Luschat, G.: Begriffliche Grundlagen für Vorgehensmodelle. In: Kneuper, R.; Müller-Luschat, G.; Oberweis, A.: Vorgehensmodelle für die Betriebliche Anwendungsentwicklung. B. G. Teubner, Reihe Wirtschaftsinformatik, Wiesbaden 1998, S. 15-31 [3] IABG: Vorgehensmodell (V-Modell), Teil 1: Regelungsteil. Entwicklungsstandard für IT-Systeme des Bundes. Allgemeiner Umdruck Nr. 250/ 1. Juni 1997 [4] IABG: Vorgehensmodell (V-Modell), Teil 2: Methodenzuordnung Entwicklungsstandard für IT-Systeme des Bundes. Allgemeiner Umdruck Nr. 251. Juni 1997 Schlagwörter Anforderungen, Angebotsbewertung, Ausschreibung, IT-Projekt, Pflichtenheft, Requirements Engineering, Vorgehensmodell Gliederung Anforderung HG-Gewicht G-Gewicht Max.- Punktzahl Mindestanforderungen 1 Bieterdarstellung 3 3.000 2.000 1.1 Nachweis der Fachkunde 3 900 1.2 Nachweis von qualifiziertem Personal 3 900 1.3 Nachweis der Vertrautheit mit für das IT- System vorgesehenen Komponenten 2 600 1.4 Nachweis über QS- und KM-Methoden 2 600 2 IT-System 4 4.000 2.750 2.1 Kontextsensitive Hilfe 1 400 2.2 Beschreibung des Konzepts zur Datensicherung 2 800 2.3 Beschreibung der Systemarchitektur 3 1.200 2.4 Wie erfüllen Sie das Mengengerüst (bis zu 1.000.000 Entitäten in der DB, bis zu 30 schreibende parallele User gleichzeitig)? 3 1.200 2.5 Wie stellen Sie sicher, dass nur Berechtigte die Daten lesen/ verändern? 1 400 3 Schulung 1 1.000 3.1 Welche Schulungsinhalte haben Sie für Systemadministratoren vorgesehen? 3 300 3.2 Welche Schulungsinhalte haben Sie für Endanwender vorgesehen? 2 200 3.3 Ist für Nutzer eine Möglichkeit vorgesehen, das System zu testen? Stellen Sie Ihr Konzept vor! 5 500 4 Projektdurchführung 2 2.000 1.500 4.1 Wie stellen Sie sicher, dass eine ausreichende Kommunikation mit dem Auftraggeber erfolgt? 2 400 4.2 Welche Qualitätssicherungsmaßnahmen haben Sie für das Projekt vorgesehen? 3 600 4.3 Welche Statusberichte sind vorgesehen? 1 200 4.4 Geben Sie einen groben Projektplan (inkl. Meilensteinen und Auslieferungsterminen) an! 4 800 Summe 10.000 7.500 ���� ���� ���� ���� ���� ���� � ���� ���� ���� ��� ���� ���� ��� ���� ���� ��� ��� ���� ���� ��� ���� � ���� ���� ���� ���� ���� ���� ���� ���� ���� ����� ������ ������������� ������������������ �������� �������� �������� �������� �������� ������������������������������� ����������������� ��������� �������� ������������������� Tabelle 1: Leistungsbewertungsmatrix Abb. 3: Übersicht über die Leistungsbewertung der Angebote aktuell projekt M A N A G E M E NT 4/ 20 0 4 projekt M A N A G E M E NT 4/ 20 0 4 aktuell 34 WISSEN 35 Autor Dipl.-Inform. Thomas Batz hat an der Technischen Hochschule Darmstadt Informatik studiert und arbeitet seit 1986 als wissenschaftlicher Mitarbeiter und Projektmanager im Fraunhofer-Institut für Informations- und Datenverarbeitung (IITB). Schwerpunkte seiner Arbeit in den letzten Jahren waren Projektmanagement, Qualitätssicherung, Erstellung von Systemkonzepten und Beratung zur IT-Sicherheit. Diese Tätigkeiten wurden insbesondere für externe Auftraggeber durchgeführt, deren Projekte durch Erfassung der Anforderungen, Erstellung der Systemkonzepte und Ausschreibungsunterlagen, Bewertung von Angeboten, Qualitätssicherung von Dokumenten und Software von der Konzeption über die Entwicklung bis zum Betrieb des Systems wesentlich unterstützt wurden. Autor Dr. Kym Watson ist promovierter Mathematiker und seit 1982 als wissenschaftlicher Mitarbeiter und Projektmanager im Fraunhofer-Institut für Informations- und Datenverarbeitung (IITB) tätig. Schwerpunkte der von ihm geleiteten Gruppe „I&K-Consulting, Projektmanagement“ sind Management von Projekten und Verbundforschungsvorhaben im IT-Bereich, Vorgehensmodelle und Projektstrukturierung, IT-Unterstützung und Werkzeuge für Projektmanagement sowie IT-Architekturen und Entscheidungsunterstützung für die Auswahl von IT-Lösungen. Anschrift Fraunhofer-Institut Informations- und Datenverarbeitung IITB Fraunhoferstr. 1 D-76131 Karlsruhe Tel.: 07 21/ 60 91-4 55, -4 86 Fax: 07 21/ 60 91-4 13 E-Mail: batz@iitb.fraunhofer.de, watson@iitb.fraunhofer.de http: www.iitb.fraunhofer.de Anforderung HG- Gew. G-Gew. Max.- Punkte Min.- Punkte Bieter_1 Punkte Bieter_1 Bieter_2 Punkte Bieter_2 Bieter_3 Punkte Bieter_3 Bieter_4 Punkte Bieter_4 Bieterdarstellung 3 3.000 2.000 2.430 1.440 2.520 2.580 Nachweis der Fachkunde 3 900 1 900 0,3 270 0,8 720 1 900 Nachweis von qualifiziertem Personal 3 900 0,7 630 0,5 450 1 900 1 900 Nachweis der Vertrautheit mit den für das IT-System vorgesehenen Komponenten 2 600 1 600 1 600 1 600 0,5 300 Nachweis über QS- und KM-Methoden 2 600 0,5 300 0,2 120 0,5 300 0,8 480 IT-System 4 4.000 2.750 3.320 0 3.400 3.480 Kontextsensitive Hilfe 1 400 1 400 0 0 1 400 1 400 Beschreibung des Konzepts zur Datensicherung 2 800 0,7 560 0 0 0,8 640 1 800 Beschreibung der Systemarchitektur 3 1.200 0,7 840 0 0 0,7 840 0,7 840 Wie erfüllen Sie das Mengengerüst (bis zu 1.000.000 Entitäten in der DB, bis zu 30 schreibende parallele User gleichzeitig)? 3 1.200 1 1.200 0 0 1 1.200 1 1.200 Wie stellen Sie sicher, dass nur Berechtigte die Daten lesen/ verändern? 1 400 0,8 320 0 0 0,8 320 0,6 240 Schulung 1 1.000 840 0 900 900 Welche Schulungsinhalte haben Sie für Systemadministratoren vorgesehen? 3 300 0,8 240 0 0 1 300 0,8 240 Welche Schulungsinhalte haben Sie für Endanwender vorgesehen? 2 200 1 200 0 0 1 200 0,8 160 Ist für Nutzer eine Möglichkeit vorgesehen, das System zu testen? Stellen Sie Ihr Konzept vor! 5 500 0,8 400 0 0 0,8 400 1 500 Projektdurchführung 2 2.000 1.500 1.880 0 980 1.880 Wie stellen Sie sicher, dass eine ausreichende Kommunikation mit dem Auftraggeber erfolgt? 2 400 0,8 320 0 0 0,5 200 0,7 280 Welche Qualitätssicherungsmaßnahmen haben Sie für das Projekt vorgesehen? 3 600 1 600 0 0 0,5 300 1 600 Welche Statusberichte sind vorgesehen? 1 200 0,8 160 0 0 0,4 80 1 200 Geben Sie einen groben Projektplan (inkl. Meilensteinen und Auslieferungsterminen) an! 4 800 1 800 0 0 0,5 400 1 800 Summe 10.000 7.500 8.470 — 7.800 8.840 Tabelle 2: Bewertung der einzelnen Anbieter aktuell projekt M A N A G E M E NT 4/ 20 0 4 projekt M A N A G E M E NT 4/ 20 0 4 aktuell