Verbesserungen ● Kürzere Bereitstell- und Durchlaufzeiten ● Qualitätssteigerung, stets eindeutige „Originale“ ● Time to Market ● Transparente und kostengünstigere Prozesse ● Effektivere weltweite Produktionsvorbereitung (Logistik) und Entwicklung, weniger Manpower ● Unterstützung der Standardisierung in der HW/ SW ● Entscheidungshilfe für Planung, Entwicklung … ● Basis für Innovationen Kostenreduktion ● Kaum noch Papiertransfer, d. h. nur noch minimale zusätzliche Kopie-/ Verteilungskosten ● Rechtzeitige und komplette Bereitstellung aller Produktunterlagen für die Fabrik, minimierte Wartezeiten, Recherchierzeiten ● Logistik ist jetzt frühzeitiger involviert und basiert auf verlässlichen Werten, dadurch wesentlich verbessertes Time-to-Market-Verhalten ● Qualitätsverbesserungen durch exakte Bestimmung der Produktunterlagen, dadurch erheblich verminderte Fehlerschleifenanzahl ● Vermeidung von Produktionsengpässen, da im Bedarfsfall jeder Produktionsstandort sofort auf alle notwendigen Produktunterlagen zugreifen kann, keine teuren Überstunden und Einhaltung der Liefervereinbarungen ● Verteilungsaufwand von Teil-/ Endergebnissen an arbeitsteilende Entwicklungsstandorte entfällt, dadurch verminderte Entwicklungskosten 7. ERFAHRUNGEN UND AUSBLICK Wichtig für die Bereitstellung eines neuen KM-Systems ist der richtige Zeitpunkt, nicht zu früh und nicht zu spät. Die Definitionsphase sollte nicht zu lange dauern, sie ist zeit- und kostenintensiv und birgt die Gefahr in sich, immer neue Anforderungen zu finden. Bei einer komplexen Toolentwicklung wie der eines KM-Systems ist ein Mittelweg zwischen einer konservativen Entwicklung (ausgehend von einer präzisen Spezifizierung aller Details mit den künftigen Anwendervertretern) und einem reinen Rapid Prototyping ein guter Lösungsweg mit kürzerer Entwicklungszeit. Es sollte mit den heute am Markt angebotenen KM-Systemen möglich sein, mit einem geringen Customizing auszukommen. Darüber hinaus ist zu versuchen, dieses vom Hersteller realisieren zu Abb. 7: KM-Entwicklungs-Erfahrungen 36 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ P R O J E K T M A N A G E M E N T 1 / 2 0 0 0 Abb. 8: Konzept des neuen KM-Systems lassen und sukzessive in die Kern- Software zu integrieren. Dies spart künftige Probleme beim Versionswechsel (Upgrades, Schnittstellenänderungen) usw. (Abb. 7 und 8). Wir setzen unser Projekt unter den geänderten Rahmenbedingungen fort, um ein neues KM-System zu realisieren. Die bisherigen Erfahrungen sind hierbei von großem Nutzen. Um eine breitere Akzeptanz, d. h. über den bisherigen Organisationsbereich hinaus, zu erreichen, führt dies zum Wechsel des Herstellers. Aufgrund der umfangreichen Zusammenarbeit zwischen der Siemens AG und der Eigner & Partner AG bezüglich des Produkts CADIM ist dies als eine neue Ausgangsbasis unter Nutzung bisheriger Realisierungsergebnisse geplant. Ein wesentliches Argument für die Wahl dieses Produkts war neben der Leistungsfähigkeit, der Funktionalität und dem hohen Abdeckungsgrad der benötigten Anforderungen der Einsatz/ die Zusammenarbeit in ca. 30 Projekten. Wir sind zuversichtlich, damit eine gute Ausgangslage für die Akzeptanz im Breiteneinsatz zu schaffen. Für die FW/ LW werden wir weiterhin ClearCase nutzen, und für Dokumente werden wir NetInfo mit dem Produkt Hyperwave einsetzen. Ausblick Von der Idee bis zur Produktion eines neuen Produkts benötigen wir künftig noch kürzere Durchlaufzeiten auf allen Ebenen. Anforderungen für ein zukünftiges integriertes KM: ● 100%ige Digitalisierung ● eine Vervielfachung der Netzwerk-Leistungsfähigkeit ● mehr Standardisierung für einen transnationalen Einsatz; aber ausreichende Flexibilität ● direkte Einbindung in den Workflow ● Zugang über das Intranet ● virtuelle Entwicklungsunterstützung ■ Autor Dipl.-Wirtsch.-Ing. Udo Lemke, Manager für Toolstrategy in der Siemens AG in München, im Geschäftsbereich Information & Communication Networks (ICN CM) für Telekommunikation im Geschäftszweig Manufacturing Center. Zuständig im Hardware-/ Firmware-/ Loadware-Entwicklungsbereich für EDM/ PDM inklusive der tangierenden Tools und Verfahren. Anschrift Siemens AG Abt. ICN WN ES HW 410 Hofmannstraße 51 D-81359 München Tel.: 089/ 7 22-3 70 95 Fax: 089/ 7 22-3 29 77 37 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ P M - M E T H O D E N / I N S T R U M E N T E ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ KM im Hause Siemens Der Beitrag in diesem Heft von Dipl.- Wirtsch.-Ing. Udo Lemke „Einsatz des Konfigurationsmanagements bei der HW-/ SW-Entwicklung und Produktion für Produkte der Telekommunikation“ basiert auf seinem Vortrag, den er bei der 3. Fachtagung zum Konfigurationsmanagement „Änderungsmanagement mit System - Schlüsselfaktor Konfigurationsmanagement“ gehalten hat. Er schildert die ausgefeilten Konzepte und breiten Erfahrungen, die mit Konfigurationsmanagement (KM) bei der Siemens AG gemacht wurden. Dabei konnte er auf einer langen Tradition im Hause Siemens zum Thema KM aufbauen. In Interaktion mit den Arbeiten an meinem ersten Buch über KM in 1984 [1] erstellte der damalige Datenverarbeitungsbereich bei Siemens das IT-Tool für Software-KM „KMS-Konfigurationsmanagement-System“ auf BS2000. Dieses wurde bei der ersten Fachtagung über KM im Jahre 1985 vorgestellt [2], [3]. Aufbauend auf diesen Arbeiten vertiefte der damalige Zentralbereich Technik das Thema [4]. Diese Erfahrungen wurden nun in den Bereich der Kommunikationstechniken übertragen, aus dem Herr Lemke den neuesten Stand wiedergibt. KM in der Zeitschrift PROJEKT- MANAGEMENT Aufgrund der Aktualität des KM erschienen ausgewählte Beiträge von KM- Tagungen wie auch originale Fachbeiträge: Saynisch, M.: Änderungen im Griff. Bericht 2. Fachtagung 1997. PROJEKT- MANAGEMENT 2/ 98, S. 45-48 Schuppert, G.: Projektänderungen in einer virtuellen, globalisierten Welt. PRO- JEKTMANAGEMENT 4/ 98, S. 22-27 Saynisch, M.: Was ist Konfigurationsmanagement? PROJEKTMANAGE- MENT 2/ 99, S. 12-25 Neemann, C.: Konfigurationsmanagement und Änderungsmanagement - Ein Interview mit M. Saynisch. PRO- JEKTMANAGEMENT 2/ 99, S. 42-46 Schreiber, W.: Konfigurationsstruktur - Grundlage des Konfigurationsmanagements. PROJEKTMANAGEMENT 4/ 99, S. 38-41 Dokumentations-Band zur 3. Fachtagung zum Konfigurationsmanagement Die dritte Fachtagung zum Konfigurationsmanagement fand am 22. und 23.6.99 in Stuttgart mit über 100 Teilnehmern statt. Die Grundsatz- und Anwenderreferate mit konkreten Lösungsansätzen kamen aus der Automobilindustrie (AUDI, BEHR, BMW), Softwarebranche (CRISTAL, EIGNER, it- Research, SAP, sd&m), Telekommunikation (Bosch-Telecom, Siemens) und System- und Anlagenbau (DASA, LFK, LURGI). Weitere Literatur zum KM [1] Saynisch, M.: Konfigurationsmanagement - Entwurfssteuerung, Dokumentation, Änderungswesen. Verlag TÜV Rheinland, Köln 1984 [2] Tomahogh, D.: Konfigurationsmanagement bei Softwareprojekten. In: Schelle, H., Saynisch, M. (Hrsg.): Symposium Konfigurationsmanagement. GPM, München 1985, S. 61-78 [3] Faltenbacher, P./ Mittermaier, P.: Rechnergestütztes Konfigurationsmanagement mit KMS. In: Schelle, H./ Saynisch, M. (Hrsg.): Symposium Konfigurationsmanagement. GPM, München 1985, S. 79-90 [4] Platz, J./ Schmelzer, A.: F+E-Management. Springer-Verlag, Berlin 1986 Manfred Saynisch ■ 412 S., DM 54,- (für Mitglieder DM 42,-) bei GPM Region Stuttgart/ Karlsruhe, Fax 07 11/ 6 87 39 69 38 P R O J E K T M A N A G E M E N T 1 / 2 0 0 0 Konfigurationsmanagement Kommentare, Fakten, Literatur Deutsche Gesellschaft für Projektmanagement e.V. Manfred Saynisch Dietmar Lange (Herausg.) Änderungsmanagement mit System - Schlüsselfaktor Konfigurationsmanagement Dokumentationsband der Tagung Zusammenfassung Dieser Artikel spiegelt die Einführung von Projektmanagement in unserem Unternehmen wider und setzt sich mit dem Problem eines klassischen Entwicklungsprojektes auseinander, in dem zwar die Vorstellungen aller Beteiligten definiert, aber konkrete Ergebnisziele noch nicht greifbar sind. Der hier geschilderte Fall zeigt auf, dass auch während des laufenden Projektes Ziele in fortgeschrittenen Projektphasen immer wieder umdefiniert werden können. Abstract Here we try to explain the introduction of project management in our company dealing with problems of classical development projects. In this case very often ideas of team members are defined but concrete goals concerning the results are not available yet. We want to point out that project goals could also be (re-)defined in progressing project states as shown here. Schlagwörter Entwicklung, Lotus-Notes-Datenbank, Projektmanagement, Prozessorientierung, Software, Zieldefinition 1. EINLEITUNG Viele zertifizierte Unternehmen stehen vor der Herausforderung, die resultierenden Qualitätsdokumente zu verwalten und dabei ein größtmögliches Maß an Informationen für alle Mitarbeiter bereitzustellen. Diese Aufgabe ist nicht immer leicht zu bewältigen, denn endet sie nicht allzu oft als ungelesener und nicht verstandener Papiertiger? Zudem setzen immer mehr Unternehmen auf breite Information und tiefe Einblicke in das Unternehmensgeschehen, um die Mitarbeiter zu motivieren und sie über deren wichtige Rolle beim Unternehmenserfolg aufzuklären. Es gibt viele Softwareangebote, die eine Verarbeitung und Bereitstellung dieser Informationen über lokale Netzwerke in den einzelnen Unternehmen ermöglichen, doch aufgrund der allgemeinen Übertragbarkeit auf viele Arten von Unternehmen sind diese Angebote oft nicht spezifisch oder müssen mit einem hohen Kostenaufwand an vorhandene Unternehmensstrukturen angepasst werden. 42 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ P R O J E K T M A N A G E M E N T 1 / 2 0 0 0 Projektmanagement in der Lotus-Notes-Datenbankentwicklung S U S A N N E K L E I B Ö M E R „Projektmanagement-Fachmann/ -frau“ ist ein Ausbildungsgang, dessen Absolvent(in) „über ● gute Schulbildung und Berufserfahrung verfügt, ● umfassendes Wissen in allen Bereichen des Projektmanagements und die Fähigkeit besitzt, die Kenntnisse anzuwenden, ● fähig ist, als Mitglied im Projektleitungsteam eines komplexen Projekts in irgendeinem Projektmanagement-Bereich zu arbeiten, ● Leitungsfunktionen in einem Projekt übernehmen kann“. In der Ausbildung wird daher nicht nur der Wissensspeicher genutzt, der auf über 1.200 Seiten der inzwischen 5. Auflage des Buches „Projektmanagement-Fachmann“ niedergelegt ist, sondern weitere Methoden und Medien werden in der Vermittlung und vor allem in der Umsetzung des erworbenen Wissens eingesetzt. So hat jede angehende Projektmanagement-Fachfrau und jeder angehende Projektmanagement-Fachmann während der Ausbildungsdauer ein „Arbeitsprojekt“, in dem die erworbenen Kenntnisse anzuwenden und die damit gemachten Erfahrungen zu reflektieren sind. Die Beschreibung ihres Arbeitsprojekts hat Frau Kleibömer für diese Veröffentlichung überarbeitet und zur „Fallstudie“ weiter entwickelt. 2. VON DER IDEE MIT PM ZUM NICHT VORHERSEHBAREN ZIEL Aus dieser Situation heraus haben wir in unserem Unternehmen ein Projekt ins Leben gerufen, das eine „all round“-Datenbank entwickeln sollte, die Information und Dokumentenlenkung gleichermaßen bereitstellt und dabei auch noch gerne und mit viel Freude von den Mitarbeitern angenommen wird und nicht teurer sein darf als ein Produkt von „der Stange“. Man könnte sagen, dass diese Anforderung gleichzeitig eines der wichtigsten Ziele für unseren Geschäftsführer war und für das Projektteam selbst der einzige Hinweis auf das, was nun zu tun sei. 3. EIN PROJEKT WIRD ZUM PROJEKT Das Projektteam setzte sich aus den Mitarbeitern zusammen, die hauptsächlich an der Dokumentenlenkung, sprich Dokumentenverwaltung, im Unternehmen beteiligt waren und somit alle Stärken und Schwächen eines papiergelenkten Dokumentensystems nach DIN EN ISO 9000 ff. kannten. Diese Mitarbeiter kamen sowohl aus den Produktionsbetrieben als auch aus dem Verwaltungsbereich. Als Projektleiterin befand ich mich zum Zeitpunkt des Projektstartes selbst in der Ausbildung zur Projektmanagement-Fachfrau und konnte die Systematik eines geregelten Projektmanagements aufzeigen. Die Erfahrung hat gezeigt, dass gerade in Organisationsprojekten nicht nur die fachliche Qualifikation, sondern vielmehr auch das organisatorische Geschick und die Kenntnis der Unternehmensstrukturen von besonderer Bedeutung sind. Ich wusste daher, wenn sowohl die „DIN-ISO-Pessimisten“ als auch deren „Fahnenweher“ im Projektteam sind, dann wird das System am Ende dem Anspruch des Geschäftsführers wohl gerecht werden. Also fragte ich die potentiellen Projektmitglieder, ob sie gerne im Projekt mitarbeiten möchten, und erhielt fast ausschließlich eine positive Resonanz. 3.1 Definition der Datenbasis und Plattform Da im Unternehmen bereits ein Notes Server mit entsprechender Anbindung an alle vorhandenen PCs installiert war und auf jedem PC eine Lotus-Notes-Datenbank zwecks E-Mailing installiert ist, beschloss das Projektteam während der zweiten Projektsitzung eine Lotus- Notes-Datenbank zu entwickeln und zu programmieren. Wir kannten aus verschiedenen Vorführungen Lotus-Notes-Datenbanken zur Dokumentenlenkung und konnten durch diese Entscheidung die Kosten für zusätzliche Hard- oder Softwareankäufe vermeiden. Außerdem waren die Mitarbeiter durch die Lotus-Notes-E-Mail- Komponente bereits zum Teil mit Notes-Anwendungen vertraut. All diese guten Voraussetzungen wollten wir nutzen, um die spätere Akzeptanz unserer Datenbank zu erhöhen. Zu diesem Zeitpunkt hatte ein Teil der Projektmitglieder aus anderen betrieblichen Gründen bereits eine Inhouse-Schulung zur Lotus-Notes-Datenbankentwicklung, die alle notwendigen Basiskenntnisse vermittelte, bekommen. 3.2 Zielgestaltung Viele Ideen zur Gestaltung dieser Datenbank waren bereits vorhanden, da wir im Bereich Qualitätsmanagement einmal damit begonnen hatten, einen ähnlichen Ansatz in HTML zu programmieren. Doch die Möglichkeiten einer echten Datenbank sind viel umfassender und lassen den Ideen freien Lauf. Wir verwendeten daher zur Zieldefinition das klassische Brainstorming und die Metaplantechnik. Wir visualisierten sämtliche genannten Ziele zu Aussehen, Gestaltung, Inhalt und Möglichkeiten der Datenbank und prüften, ob diese Ziele erreichbar, d. h. unter den vom Auftraggeber vorgegebenen Kriterien für uns umsetzbar waren. Dann überlegten wir, ob die gesetzten Ziele auch den Vorstellungen und Ansprüchen der späteren Anwender genügen würden, denn gerade bei Entwicklungsprojekten sind oftmals die eigenen Ideen und Vorstellungen nicht gleichzusetzen mit den Erwartungen der späteren „Adressaten“ oder „Kunden“. Hierzu führten wir eine Befragung in einem repräsentativen Kreis durch, in dem wir unsere Ziele als offene Fragen gestalteten. Hierdurch war es möglich, die wesentlichen Ziele herauszufiltern und gleichzeitig den einzelnen Zielen eine entsprechende Gewichtung zu geben. Einige Ziele waren zu diesem Zeitpunkt noch nicht bekannt, da sie erst später, mit dem wachsenden Verständnis um die Möglichkeiten der Datenbankprogrammierung, hinzukommen sollten. Die Ziele, die im weiteren Verlauf aufgeführt werden, stellen das dokumentierte Endergebnis dar. 43 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ P M - F A L L B E I S P I E L / F A L L S T U D I E 3.2.1 Ergebnisziele Ein wesentliches betriebliches Ziel war die Bereitstellung aller QM-Dokumente und Informationen des TQM-Systems für alle Notes- Anwender in attraktiver Art und Weise zur Erhöhung des Informationsgrades aller Mitarbeiter. Die Lenkung von QM-Dokumenten bis zu deren Archivierung muss rechnergestützt erfolgen. Die Kosten und der Aufwand der Mitarbeiter zur Aufrechterhaltung des QM-Systems nach DIN ISO 9001 sollen um mindestens 50 % von bisher ca. 15.000 DM/ Jahr auf 7.500 DM/ Jahr reduziert werden. Die Entwicklungskosten dürfen einen Rahmen von 20.000 DM nicht überschreiten, da sonst eine extern gekaufte Anwendung billiger gewesen wäre. Die Mitarbeiter der Dokumentenlenkung sollen mit geringem Aufwand Dokumente selbst erstellen, lenken, revidieren und verteilen können. Der Betriebsrat soll die Möglichkeit der Veröffentlichung seiner Informationen erhalten. Eine Hauszeitung soll integriert werden. Bezugsdokumente, Anlagen und Formblätter müssen untereinander über „Hot-Spots“ verknüpft sein und in ihrer Darstellung an das Internet erinnern, um den Bezug zu modernen Kommunikationstechniken herzustellen. Ein Diskussionsforum innerhalb der Datenbank soll zur Verfügung stehen. 3.2.2 Verfahrensziele Die Datenbank muss soweit möglich allein mit Notes entwickelt werden. Wenn es notwendig ist, bei den Formblättern und Anlagen auch auf MS-Office-Anwendungen zurückzugreifen, müssen diese als Anlagen eingebunden werden können. Die Entwicklung, Administration und Weiterentwicklung der Datenbank müssen innerhalb des Unternehmens erfolgen. 4. PROJEKTPHASEN UND TERMINPLANUNG Die Projektphasen konnten zunächst nur grob definiert werden. Das als Abb. 1 gezeigte Phasenmodell entstand erst, nachdem wir bereits die Phase 3 erreicht hatten. Bis zu diesem Zeitpunkt musste der Projektstrukturplan und auch der Terminplan immer wieder angeglichen werden, da aus dem Projektteam heraus, mit der wachsenden Einsicht in die Möglichkeiten des Systems, immer mehr Ideen geboren wurden, die wir in das System integrieren wollten. Wir erstellten daher eine Liste aller anfallenden Aufgaben und Arbeitspakete und ordneten sie nach Bereich und Ablauffolge innerhalb der Projektabwicklung ein. Der sich daraus gleichzeitig ergebende Projektstrukturplan lässt sich in einem entsprechenden Softwareprogramm zusammen mit der Terminplanung sehr gut abbilden. Die Dauer für die einzelnen Aufgaben haben wir geschätzt, da wir hierzu noch keine Erfahrungen sammeln konnten. Zusammen mit den immer wieder neu hinzukommenden Ideen und den „geschätzten Terminen“ verschob sich dann auch im Laufe der Zeit das für Mai geplante Projektende auf den 30. Juni 1999. Wir hätten aber keine Kosten gespart, indem wir z. B. die Ressourcen erhöhten; auch wollten wir nicht auf die Integration der Ideen verzichten. Somit konnten wir den Auftraggeber nur damit überzeugen, dass unser Fertigstellungswert am Ende höher liegen würde als geplant. Aus dieser Art des Vorgehens haben wir allerdings viel gelernt. Es ist durchaus legitim, Termine und Aufwände zu schätzen, wenn keine Erfahrungswerte vorliegen, doch erlauben dies nur Projekte, deren Fertigstellungstermine kostenunabhängig sind. In unserem Fall entstanden zwar Mehrkosten durch eine längere Entwicklungszeit, doch hatten wir am Ende auch einen höheren Fertigstellungswert und somit eine gewisse Kostenneutralität. Wäre der Endtermin aber ohne höheren Fertigstellungswert überschritten worden oder gar mit einer Pönale belegt, hätten wir das Projektbudget deutlich überschritten. Wenn man wie in unserem Fall auf Schätzungen in der Terminplanung angewiesen ist, dann sollte man immer darauf achten, nicht nur die aufeinander folgenden Arbeitspakete möglichst mit Pufferzeiten zu belegen, sondern auch mit Abb. 1: Projektphasen 44 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ P R O J E K T M A N A G E M E N T 1 / 2 0 0 0 dem Auftraggeber über das späteste Projektende zu verhandeln. Auf jeden Fall sollte man bei notwendigen Terminkürzungen nur die Arbeitspakete kürzen, deren Dauern bekannt sind. Geschätzte Dauern in Arbeitspaketen sollten gekennzeichnet sein und hier außen vor bleiben, denn „Schätzungen“ zu kürzen macht wenig Sinn. 5. DATENBANKENTWICKLUNG Zunächst entwickelten wir eine Auflistung der bisherigen Anforderungen an die Dokumentenlenkung und deren Funktionalitäten und ermittelten die Funktionen, die künftig automatisch, halbautomatisch oder manuell bei Bedarf, durchgeführt werden sollten. Des Weiteren ergaben sich aus diversen „Brainstorming-Sitzungen“ die Arten der Dokumentenauswahlmöglichkeiten, die verschiedenen Kriterien für Ansichten von Dokumenten, die Gestaltung der Navigatoren als Menü-Oberfläche und routinemäßig ablaufenden Agenten sowie die Dokumentenmasken, in die viele Funktionen integriert wurden. In diesem Stadium der Ideenfindung und Prüfung der „Programmierbarkeit“ war es äußert wichtig, die definierten Ziele immer wieder zu prüfen und zu konsolidieren. Bei allen Entscheidungen galten die Fragen: Ist es komfortabel und logisch für den Anwender? Erleichtert es die Arbeit? Findet man ein Dokument schnell und ohne Aufwand? Hat man einen guten Überblick über alle Dokumente? Und sehen die Ansichten und Masken ansprechend aus? Während der Phase der Datenbankentwicklung wurden viele zusätzliche Ideen geboren, die in die Funktionalität der Dokumentenlenkung, sprich Funktionsleisten der Dokumentenmasken, eingebettet werden sollten. An dieser Stelle war es von besonderer Bedeutung abzuschätzen, inwieweit die Verwirklichung der Ideen in den Terminplan integriert werden können, wie sie sich dort auswirken und wie sich das Informationsmanagement über etwaige Änderungen des Plans gestaltet. Wir hielten es daher für angebracht, über Änderungen und Ideen immer gemeinsam während der Projektbesprechungen abzustimmen. Bei von uns program- Abb. 2: Datenbankeinstieg Abb. 3: Hauptnavigator 45 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ P M - F A L L B E I S P I E L / F A L L S T U D I E