WINGbusiness Heft 03 2008 by WING

ISSN 0256-7830; 41. Jahrgang, Verlagspostamt A-8010 Graz; P.b.b. 02Z033720M

3/08

WING

business

Systems Engineering

Systems Engineering: Interview mit Haberfellner, Nagel Seite 6

Systems Engineering: Interview mit Igenbergs Seite 9

Systems Engineering: neu 端berdacht Seite 18

Editorial

Systems Engineering

o.Univ. Prof. DI Dr. Siegfried Vössner Liebe Leserin, lieber Leser, zu Ehren und ganz im Sinne eines sehr geschätzten Kollegen, der nebenbei einer der Begründer und geistigen Väter des Systems Engineering ist, möchte ich dieses Editorial mit einem hintergründigen Witz beginnen: Drei Studenten fahren gemeinsam auf der Autobahn nach Graz. Einer ist Maschinenbauer, einer ist Elektrotechniker und einer Informatiker. Auf einmal gibt es einen lauten, dumpfen Knall und der Motor ist aus. „Das war sicher ein Kolbenschaden! Das war‘s dann wohl!“, meint der Maschinenbauer, der am Steuer sitzt und das Auto geistesgegenwärtig am Pannenstreifen zum Stehen bringt. „Nein, lieber Freund, das hat sich für mich eher wie ein geplatzter Kondensator in der Zündanlage angehört! Aber ich gebe Dir recht, dass wir nicht mehr weiterfahren können!“, meint der Elektrotechniker. Der Informatiker ist von dem Vorfall anscheinend völlig unbeeindruckt und meint zu den beiden anderen: „Kein Grund zur Panik Freunde! Steigen wir einfach aus und dann wieder ein und versuchen ob der Fehler damit behoben ist.“ Dieser Witz ist ein sogenannter Generationen-Witz: vor 20 Jahren hätte man ihn nicht verstanden, vor 10 Jahren hätte man schallend darüber gelacht und heute ist einem dabei eher zum Weinen zu Mute. Längst haben sich Dinge, die uns im Alltag umgeben, in komplexe Systeme verwandelt. Sie denken sicher sogleich an Computer, doch soweit muss man gar nicht gehen: Denken Sie an intelligente Drucker-Tintenpatronen, die sich mittels eingebautem Chip gegen eine Wiederbefüllung wehren. Oder das Glühlampen-„System“ Ihres Beamers, welches nach 2500 Betriebsstunden Ihnen mitteilt, dass es sich aus „Sicherheitsgründen“ jetzt für immer abschaltet und Sie doch eine neue Glühlampe kaufen sollen. Schlimmer noch: diese Systeme bilden wieder Systeme: „System(s) of Systems“, um einen wissenschaftlichen Anglizismus einzuführen. Ein naheliegendes Beispiel dafür ist sicher ein modernes Automobil der Mittel- und Oberklasse. Dort arbeitet eine zwei- bis dreistellige Anzahl an Mikrocontrollern im Verbund als Steuerzentrale eines Autos. Schöne neue Welt? Es hat sich gezeigt, dass es trotz des großen technologischen Fortschritts noch ein weiter Weg ist, um funktionierende, komplexe Systeme dieser Art zu entwerfen. In Ergänzung zum klassischen, modularen In-

WINGbusiness 3/2008

genieuransatz sind hier Entwurfsmethoden notwendig, die es erlauben, die Wechselwirkungen der Systemkomponenten zu berücksichtigen und zu testen. In den 1960er-Jahren entwickelte sich Systems Engineering als ein äußerst erfolgreiches technoökonomisches Denk- und Vorgehensmodell damals mit dem primären Fokus auf betriebswirtschaftliche und auch betriebliche Informationssysteme. Heute hat sich der Handlungsbedarf im Bereich komplexer Systeme aber eindeutig verschoben: Automobile, Raumfähren, Satellitensysteme, um nur einige Beispiele zu nennen, stellen an die Systemgestaltung große Anforderungen. Mit den immer komplexer werdenden technischen Geräten und Maschinen findet Systems Engineering besonders im Bereich der Mechatronik größer werdendes Interesse. Einem Trend, dem wir an der TU-Graz durch die Einführung einer interdisziplinären Vorlesung „Mechatronik-Sytems Engineering“ Rechnung tragen. Zudem freut es mich ganz besonders, dass wir mit Univ. Prof. Dr. Reinhard Haberfellner einen, wenn nicht den Systems Engineering Papst an der TU Graz haben. Zwei triftige Gründe, das dritte WINGbusiness-Heft unter das Motto „Systems Engineering“ zu stellen. Im Rahmen von zwei Interviews stellen die Systems Engineering Experten Univ. Prof. Dr. Haberfellner, PD Dr. Nagel, ETH Zürich und Univ. Prof Dr. Igenbergs, TU München, die Grundlagen und das breite Anwendungsspektrum von Systems Engineering vor. Den Abschluss des Heftschwerpunktes und Blick nach vorne bildet ein WINGpaper, in dem Reinhard Haberfellner mit seinem Doktoranden, Dipl.Ing. Ernst Stelzmann, das Systems Engineering Konzept auf Agile Systeme und Methoden erweitert. Weiters freut es mich, Ihnen ein weiteres interessantes und praxisrelevantes WINGpaper von Ass. Prof Dr. Minovski und MS Jovanoski, Universität von Skopje, Mazedonien, vorzustellen, die eine Modellierungs- und Simulations-methode zur Unternehmensrestrukturierung vorstellen. Ich hoffe, dass Ihnen die Artikel, die wir in diesem Heft für Sie zusammengestellt haben, interessante Anregungen geben und verbleibe im Namen des Redaktionsteams mit freundlichen Grüßen, Ihr Sieg fried Vössner

Missglückter Jungfernflug der Ariane 5 im Juni 1996. Ursache war ein systemischer Software-Fehler

Top-Thema: Systems Engineering Interview mit Reinhard Haberfellner und Peter Nagel

Systems Engineering

Interview mit Eduard Igenbergs

Systems Engineering

Reinhard Haberfellner und Ernst Stelzmann

Systems Engineering: neu 端berdacht

WINGbusiness 3/2008

Inhaltsverzeichnis EDITORIAL

Systems Engineerig

LEUTE/KÖPFE

Dipl.-Ing. Dr.techn. Rupert Hasenöhrl

Dipl.-Ing. Dr.techn. Peter Steinbauer

WING-PAPER

Robert N. Minovski, Bojan D. Jovanovski

FACHARTIKEL

Methodology for overall company restructuring and the simulation as added value Stefan Grünwald

Software auf Knopfdruck

Service orientierte Architekturen versprechen viel, aber was bleibt beim Anwender übrig?

WING-Organisation

WING-Regionalkreisleiter

WING-REGIONAL

Firmenbesuch bei der Firma MIBA Bearing Group

Wing-Organisation

Florian Rathner

Laakirchen, 08.07.2008

MEDIENCORNER

Buchrezensionen

UNINACHRICHTEN

Sonja Embst

Fachbereichsausflug 2008

Zotter Schokoladenmanufaktur

PRESSE-INFO

Presse-Info

IMPRESSUM

Impressum

WINGbusiness 3/2008

Top-thema

Interview mit Reinhard Haberfellner und Peter Nagel

Systems Engineering Kurzlebenslauf Reinhard Haberfellner, Prof. Dipl.-Ing. Dr.sc.techn. 1959–1965 Maschinenbau- und Wirtschaftsingenieur-Studium an den Technischen Hochschulen Wien und Graz. Graduierung 1965 an der TH Graz. 1973 Promotion an der ETH Zürich. 1965 bis 1979 Mitarbeiter in der Beratungsabteilung des Betriebswirtschaftlichen Instituts der ETH Zürich (BWI). Seit 1979 ordentlicher Professor für Unternehmungsführung und Organisation an der TU Graz. 1995 bis 1999 Generaldirektor des Medienhauses Styria, Graz. Ab 2000 wieder Professor an der TU Graz. Kurzlebenslauf Peter Nagel, Dr. rer.pol., Privatdozent ETH Studium an den Universitäten Mainz (Diplom-Volkswirt) und Graz (Doktorat). Habilitation an der ETH Zürich. 1960–1963 Mitarbeit in einer Unternehmensberatungsfirma. 1963–1970 Aufbau und Leitung des Bereiches Systems Engineering in einem Großkonzern. 1970–1980 Mitarbeiter in der Beratungsabteilung des Betriebswirtschaftlichen Instituts der ETH Zürich. Seit 1977 Privatdozent an der ETH Zürich. Seit 1980 selbständiger Unternehmensberater.

Sie sind die beiden Hauptverfasser des sehr erfolgreichen SE-Buchs (11. Auflage). Was verstehen Sie unter Systems Engineering (SE)? Nagel: Ein Denk- und Vorgehensansatz, wie man ein Problem systematisch lösen kann. Ergebnis kann ein neues oder ein verändertes System sein. SE ist dabei nichts Sensationelles bzw. grundsätzlich Neues. Es kann auch als ein in Modelle gegossener gesunder Menschenverstand verstanden werden Haberfellner: Dabei ist es hilfreich, zwei Hauptkomponenten des SE zu unterscheiden: Das Systemdenken im

Sinne eines ganzheitlichen Ansatzes. Es geht darum, dass man nicht willkürlich Details herausgreift, bevor man die Gesamtzusammenhänge einigermaßen verstanden hat, also die Umgebung, in die das Problem eingebettet ist bzw. seine spätere Lösung einzubetten ist, die Beziehungen, die Nahtstellen, die verschiedenen Brillen, die man bei der Betrachtung eines Systems aufsetzen kann etc. Und als zweite Komponente das Vorgehensmodell, das wir in 4 Modulen gegliedert haben, die je nach Problem, einzeln oder kombiniert angewendet werden können.

Worin sehen Sie den Nutzen von SE? Nagel: Ich kann mir selbst besser darüber klar werden, was ich eigentlich will. Personen, die in einem Projekt zusammenarbeiten, können ihre Überlegungen besser kommunizieren, wenn sie gemeinsame Begriffe, eine gemeinsame Sprache haben. Eine Projektgruppe kann dem Auftraggeber leichter ihren Vorgehensansatz erklären. Und schließlich: wenn ich einem Problem gegenüberstehe, das neu für mich ist, bei dem ich keine oder wenig Erfahrung habe, kann mir SE helfen, leichter den Faden zu finden.

WINGbusiness 3/2008

Top-Thema Haberfellner: Ich möchte noch ein paar zusätzliche Argumente ergänzen: Das Projektrisiko wird durch das phasenweise Vorgehen reduziert. Es gibt planmäßig vorgesehene Haltepunkte, die der Bewusstmachung des derzeitigen Status sowie der Möglichkeiten des weiteren Vorgehens dienen. An diesen Haltepunkten ist der Auftraggeber gefordert, er muss Stellung beziehen und sich dabei seiner Ziel- und Wertvorstellungen bewusst werden Der Abbruch eines Projekts kann dabei, z.B. nach einer Vorstudie, eine durchaus sinnvolle Option sein. Glauben Sie, dass man durch Anwendung von SE Projekte erfolgreicher durchführen kann? Beide: Da sind wir sicher und haben es in einer Vielzahl von Projekten, häufig mit Auftraggebern, die diese Methodik nicht gekannt haben, auch erlebt. Wie sind Sie auf das Thema SE gekommen? Was waren die SE-Ursprünge? Was war der Auslöser/Anstoß, dass Sie sich mit SE beschäftigen? Haberfellner: Die auslösende Aktion hat sicherlich unser gemeinsamer Chef am BWI gesetzt: Alfred Büchel, der später auch Professor an der ETH war, ist auf ein Buch von Arthur D. Hall von den Bell Labs gestoßen, „A Methodology of Systems Engineering“, das 1963 veröffentlicht wurde. Er hat 1969 einen Artikel in der Management-Zeitschrift des BWI „Industrielle Organisation io“ veröffentlicht, der sowohl innerhalb, als auch außerhalb des BWI sofort auf großes Interesse gestoßen ist. Die Zeit war reif für eine derartige Vorgehensmethodik, niemand hatte eine, wir am BWI auch nicht. Es hat sich spontan eine Arbeitsgruppe am BWI gebildet, der wir beide angehörten und die von Peter Nagel geleitet wurde. Wir haben zunächst Anpassungen der Hall-Methodik an unsere Aufgabenstellungen vorgenommen – A.D. Hall hatte vor allem technische Projekte vor Augen (Telekommunikation), wir waren generell an betriebswissenschaftlichen Aufgabenstellungen interessiert (heute könnte man sie als techno-ökonomische bezeichnen): Planungssysteme, Organisation, EDV-Projekte etc. Die Arbeitsgruppe hat zwei Ordner

WINGbusiness 3/2008

mit Arbeitsunterlagen für unsere internen Ausbildungsseminare erarbeitet, aus denen später das erwähnte SE-Buch (Herausgegeben von Prof. W. Daenzer) wurde, dessen Erarbeitung ich geleitet habe. Die Ausbildung wurde rasch für externe Interessenten zugänglich gemacht und bis heute haben wohl mehrere Tausend Teilnehmer die öffentlich zugänglichen und firmeninternen Ausbildungsveranstaltungen besucht. Sie beide wurden verschiedentlich auch als „SE-Päpste“ bezeichnet. Nagel (lacht): Das stimmt und hat seine Ursache wohl darin, dass wir so viele Teilnehmer ausgebildet haben. Ein interessantes Detail: Viele Teilnehmer haben – auf der Basis unserer Kursunterlagen – begonnen, eigene Seminare in ihren Firmen zu veranstalten. Diese „Schüler“ waren in der Interpretation der Methodik aber vielfach zu strikt – im Sinne eines konsequent abzuarbeitenden Reihenfolge bzw. eines Kochrezepts, sodass wir (als „Päpste“) geholt wurden, um das Ganze nachzubessern bzw. realistischer zu interpretieren. Daher stammt wohl auch die von Ihnen erwähnte Bezeichnung. Sehen Sie verschiedene SE-Schulen? Wo sehen Sie Ihren SE-Ansatz im Vergleich zu anderen Ansätzen? Haberfellner: Da ist sicherlich zunächst INCOSE (International Council on Systems Engineering) zu nennen. Dabei handelt es sich um eine weltweite Vereinigung von mehr als 6.000 System Engineers, überwiegend aus der Luft- und Raumfahrt, der IT-Branche, zunehmend auch aus der Automobilindustrie u. ä. INCOSE veranstaltet jährlich Konferenzen mit bis zu 1.000 Teilnehmern ich habe bisher an dreien teilgenommen, jeweils auch als Vortragender: Toulouse 2004, Rochester 2005 und Utrecht 2008. Als wesentliches Merkmal der INCOSE-Schule halte ich die Integration von Techniken und Werkzeugen, wie z. B. Risiko-Management, Verification & Valididation etc. in die SE-Methodik. Das haben wir zum Glück nicht gemacht, weil wir meinen, dass die Anwendung derartiger Techniken wohl sehr stark vom Projektgegenstand abhängig ist. Wir deponieren diese

Werkzeuge vielmehr in einem Werkzeugkoffer und sagen „bedient Euch, wenn Ihr meint, dass dieses Werkzeug hier sinnvoll angewendet werden kann bzw. wenn die Anwendung seitens des Auftraggebers vorgeschrieben wird“. Das ist die eine Charakteristik, die das SE „abschlankt“. Die andere ist, dass wir am BWI den unschätzbaren Vorteil hatten, eine relativ kleine Gruppe von 5 bzw. 7 Personen zu sein, während bei INCOSE ca. 100 Personen beteiligt waren. Damit wird ein Konzept notgedrungen aufgeblasen. Allein aus gruppendynamischen Gründen, um Mitglieder der Gruppe bei der Stange zu halten, mussten Inhalte aufgenommen werden. Oder nehmen Sie die Aussagen von Prof. Igenbergs im Interview in diesem Heft: er ist ein prononcierter Vertreter von mathematischen Modellen und Optimierungsmethoden (Operations Research), sowie von Computermodellen. Man kann nicht sagen, dass die eine Schule richtig und die andere falsch ist. Es ist viel eher eine Frage, welche Arten von Aufgabenstellungen ich bearbeiten will. Durch unser Konzept meinen wir, uns die größte Anwendungsbreite offen halten zu können: Bau eines Hauses, Entwicklung eines Produkts, Beschaffung einer Anlage etc. Nagel: Erzähle das mit der US-Ausgabe. Haberfellner: Ich habe 2004 an der INCOSE-Konferenz in Toulouse einen Kollegen kennen gelernt, der sein Diplom an der ETH gemacht hat und heute Professor am MIT ist. Er ist daran, ca. 60 % unseres SE-Buchs ins Englische zu übersetzen und neue Teile hinzuzufügen. Wesentlicher Grund, warum er unser BWI-Konzept gewählt hat ist, dass er es für einfacher und damit leichter vermittelbar hält. Nagel: Ein Satz zum Operations Research: Ich habe zwar mit einem ORThema dissertiert und kenne mich ein wenig aus dabei, würde aber niemals darauf bestehen, OR als Bestandteil des SE zu interpretieren, sondern so wie Reinhard es gesagt hat, als Bestandteil des Werkzeugkoffers.

Top-Thema Nagel: Für mich wären es alle Themen, wo es ungelöste Probleme gibt, die aus einer umfassenden Sicht (und nicht isoliert) Univ.-Prof. zu bearbeiten wäDipl.-Ing. Dr.sc. techn. ren: Umweltverschmutzung, KliReinhard Haberfellner m a e r wä r mu n g , TU Graz Energie, Ressourcen jeder Art. Die Was sind momentan die größten HerausFrage ist nur: Wer forderungen für SE? Wohin sollte die zu- könnte Auftraggeber eines derartigen künftige Forschung gehen? Projekts sein, wer bezahlt es und wer trifft wesentliche ZwischenentscheiNagel: In dieser Ausgabe Ihrer Zeit- dungen? schrift gibt es einen Artikel über „agiles“ SE. Diese Stossrichtung finde ich Warum sollen sich sehr interessant und zukunftsgerich- junge Ingenieure tet. Ich finde auch, dass es interessant mit Systems Engiwäre, sich mit agilen, d.h. nachträglich neering beschäftianpassungsfähigen bzw. wenigstens an- gen? passbaren Systemen zu befassen. Haberfellner: Die Haberfellner: Unser UFO-Mitarbeiter Grundidee des Ernst Stelzmann bearbeitet das Thema Systems Enginee„Agiles SE“ im Rahmen seiner Disser- ring sollte jeder tation. Das Thema „Agile Systeme“ ist Ingenieur vermitnoch nicht ganz auf Schiene. telt bekommen. Ich bin froh, dass Systems EngineeSehen Sie in der Welt Probleme, die schnel- ring/Projekt-Management an der TU ler/besser mit SE gelöst werden können? Graz als Pflichtfach für jeden Maschi-

nenbau- und Wirtschaftsingenieur-Studenten etabliert werden konnte. Ab kommendem WS wird es außerdem für den Studienzweig Mechatronik eine LV „SE-Mechatronik“ geben. Darin werden Vortragende, die aus verschiedenen Fakultäten kommen (Maschinenbau, Elektrotechnik, Informatik) zusammen mit einem Industrievertreter am Beispiel eines automatisierten Lagers die Vorgehensweisen des SE und die laufende Integration verschiedener Disziplinen zeigen. Wir danken für dieses Gespräch!

Dr. rer.pol. Peter Nagel Privatdozent ETH Zürich Das Interview führten Herr Dipl.-Ing. Markus Kohlbacher und Herr Dipl.-Ing Ernst Stelzmann

LEUTE/KÖPFE

Dipl.-Ing. Dr.techn. Rupert Hasenöhrl Dipl.-Ing. Dr. Rupert Hasenöhrl übernahm mit 01. September 2008 die Geschäftsführung des Solarthermiespezialisten SONNENKRAFT Österreich mit Sitz in St. Veit /Glan. Die Firma SONNENKRAFT hat sich auf den Vertrieb von innovativen Produkten und Systemen zur ökologisch erneuerbaren Energiegewinnung im Bereich Solarenergie spezialisiert. Seit seiner Gründung 1993 etablierte sich SONNENKRAFT in der Solarenergie-Branche als führende europäische Marke für Solarthermie. „Das Ziel von SONNENKRAFT, Sonnenergie für jedermann bequem, einfach und möglichst kostengünstig nutzbar zu machen, werden mein Team und ich mit der Entwicklung von weiteren innovativen Produkten nachhaltig verfolgen,“ beschreibt Dipl.-Ing. Dr. Hasenöhrl seine zukünftige Aufgabe. Herr Hasenöhrl war bisher Vorstand in der GriffnerHaus AG, die er in den letzten 12 Jahren sehr erfolgreich zur führenden Qualitäts-Fertighausmarke geführt hat. Rupert Hasenöhrl ist gemeinsam mit Hans Persoglia langjähriger Leiter des WING-Regionalkreises Kärnten.

WINGbusiness 3/2008

Top-Thema

Interview mit Eduard Igenbergs

Systems Engineering Kurzlebenslauf von Prof. Dr.-Ing. Eduard Igenbergs, TU München Eduard Igenbergs studierte und promovierte an der Fakultät für Maschinenbau der TU München. Anschließend war er in einem Forschungslabor in den USA tätig. Nach seiner Rückkehr wurde er Professor am Lehrstuhl für Raumfahrtechnik an der TU München. Prof. Igenbergs ist mittlerweile seit 7 Jahren in Pension, aber noch täglich am Institut. Dieses Interview kam in Graz anlässlich eines Promotionsverfahrens zustande, bei dem Prof. Igenbergs Zweitbegutachter war.

Herr Prof. Igenbergs, könnten Sie kurz erläutern, was Sie unter Systems Engineering verstehen? Prof. Igenbergs: Systems Engineering ist für mich der reproduzierbare Teil der Ingenieurtätigkeit. Der nicht reproduzierbare Teil ist inder Ingenieurkunst, analog zur ärztlichen Kunst, der kreative Mensch. Systems Engineering oder „Systemtechnik“ ist die Anwendung systemischen Denken auf technische Fragestellungen. Ein Ingenieur muss ja immer reproduzierbar handeln. Aus einer Quelle muss die Information zur Senke in einer Art kommen, dass die Information dort reproduziert werden kann. Worin sehen Sie den Nutzen des Systems Engineering? In erster Linie darin, dass die Anwendung systemischen Denkens auf Ingeni-

WINGbusiness 3/2008

eurprobleme Informationen brauchbar d.h. verarbeitbar macht. Am Anfang haben Sie die Informationen meistens in Form von Worten, in der menschlichen Sprache. Dann wird der Systemingenieur sich bemühen, aus der menschlichen Sprache eine Darstellung zu machen. Diese technischen Zeichnungen werden von uns Ingenieuren „gelesen“. Wir lesen also hinter den bildhaften Darstellungen auch eine Grammatik, wie auch in einem Buch hinter den Wörtern eine Grammatik hinterlegt ist. Schließlich muss das Wissen auch noch in mathematischer Form ausgedrückt werden. Dann versteht es der Rechner und dann ist es reproduzierbar. Das heißt, das systemische Denken oder die System-Sprache ist ein Hilfsmittel für den Menschen, um eine für die Technik besonders geeignete reproduzierbare Kommunikation herzustellen.

Wie sind Sie auf das Thema Systems Engineering gekommen? Das war ganz einfach: Ich war schon Professor an der TU München, als mir mein Institutsvorstand eine Doktorarbeit zum Thema Systemtechnik zur Betreuung übergab. Die Thematik ist mir sozusagen in den Schoss gefallen. Und als ich das systemtechnische Denken und Ordnen damals erlernte, hatte ich auch die Vorstellung (lacht), dass dies auch für Ordnung in meinem Büro sorgen würde. Das ist aber bis heute leider nicht eingetreten. Wie wird Systems Engineering an Ihrem ehemaligen Institut an der TU München gehandhabt? Unserer Ansicht nach kann die Lösung von Ingenieursfragen mit Hilfe der Systemtechnik auf zwei verschiedene Arten erfolgen, die interessanterweise den

Top-Thema juristischen Systemen der jeweiligen Länder entsprechen. In den angelsächsischen Ländern versucht man, für jedes auftretende Problem gleich eine Lösung zu finden. Mit der Zeit entsteht für den ganzen Bereich eine Art „Fleckerlteppich“ von Lösungen. Wenn man irgendwo eine Lösung braucht, ist schon irgendeine da. Als Parallele denken Sie an das Case Law des angelsächsischen Rechtssys-

tems. Ist ein Rechtsfall vor Gericht, wird einfach nach alten gelösten Fällen gesucht und es gewinnt derjenige, der einen ähnlichen, bereits entschiedenen Fall gefunden hat und das Gericht davon überzeugen kann. Wir in Europa haben hingegen ein kodifiziertes Recht. Bei uns gibt es ein Grundgesetz und ein Gesetzbuch, das einen Kodex beinhaltet, auf den unser Rechtssystem aufbaut. Wir leiten unsere gesamte Entscheidung bzw. Lösung von Problemen aus diesem Kodex ab. So betrachten wir auch das Vorgehen bei Lösungen von technischen Aufgaben mit Hilfe des Systems Engineering als ein kodifiziertes Vorgehen. D. h. wir definieren, was ein System ist und was seine Funktionen sind und zwar so, dass sie in die Formelsprache der Mathematik übersetzt werden können. Wir sagen, dass ein System aus Elementen besteht und dass zwischen den Elementen Relationen bestehen. Wenn man die Elemente und die Relationen hat, hat man auch die Struktur des Systems. Zusätzlich haben Elemente Attribute und schließlich kann ein Element selbst wieder ein System sein. Letzthin entsprechen diese Regeln der Definition der objektorientierten Programmierung. Was wir Element nennen, nennt die objektorientierte Programmierung

Instanz. Deswegen ist auch die Art und Weise, wie wir bei uns das machen, sehr leicht in einen C++ Code überführbar. Gibt es neben der angelsächsischen und der mitteleuropäischen auch noch andere Schulen? Natürlich gibt es nicht nur diese Schulen. Jedes Institut vertritt, bewusst oder unbewusst, eine Schule. Die vorangegangene Erläuterung ist nur eine Beobachtung von uns. Sie können alles immer beliebig einteilen, andere machen andere Einteilungen. Das gemeinsame ist: das Systemische Denken ist ein modellbasiertes Denken. Indem Sie in menschlicher Sprache sprechen, beschreiben Sie gewissermaßen auch Ihr Denkmodell. Aber Denkmodelle können Sie nicht abstrakt übermitteln, sie müssen Informationen in eine Sprache bringen, die der Empfänger kennt bzw. gelernt hat – ob dieser Empfänger nun ein Mensch oder ein Computer ist. Wenn man Systems Engineering als Disziplin betrachtet mit einer Gesamtmethodik, die verschiedene einzelne Methoden, Normen und Lebenszyklus-Modelle beinhaltet, wo würden Sie sich dann positionieren? Mich interessiert immer der Zusammenhang zwischen den Axiomen – also den Grundregeln – und der Realität. Dieser Zusammenhang entscheidet über die Brauchbarkeit dessen, was wir machen. Ein Beispiel: Zu Beginn des Zweiten Weltkrieges führte das Erforschen von militärischen Operationen zum Begriff „Operations Research“. Probleme, die sehr umfangreich waren, konnten mathematisch gelöst werden. Die Mathematik war also sehr brauchbar und heutzutage ist Systems Enginee-

ring nur ein Weg, um solche Verfahren zu nutzen. 50 oder 60 Prozent aller Systems Engineering Probleme werden durch Operation Research gelöst. Die Amerikaner gaben dem Operation Research einen neuen Namen: „Management Science“ – seitdem ist es elegant geworden. Kann man Operations Research als eine Methode betrachten, die man innerhalb des Systems Engineering anwenden kann? Also es ist der Teil der Mathematik, der für die Anwendung einfach da ist. Sobald Systems Engineering das Problem in mathematischer Form dargestellt hat, können wir es lösen. Wenn Sie aber eine Systems Engineering Tagung besuchen, werden Sie dort das Wort Operations Research kaum hören, weil jeder natürlich der große „Zampano“ sein möchte. Was sehen Sie momentan und in Zukunft als größte Herausforderungen für Systems Engineering Forschung? Die größte Herausforderung besteht momentan darin, für eine bestimmte Aufgabe eine vernünftige Verbindung zur Informatik zu finden. Wie ich schon sagte, die Voraussetzung für die Lösung einer Systemaufgabe oder einer mathematischen Aufgabe ist immer, dass man ein Modell der realen Aufgabenstellung hat. Um mit einem Modell arbeiten zu können, muss es aber auf dem Rechner laufen. Wenn sie irgendeinen Bauteil herstellen, müssen Sie verschiedene Tätigkeiten durchführen, wie z.B. gießen, dann fräsen, dann schleifen usw. Es gibt sehr wenige Modelle, die den gesamten Lebenszyklus so abbilden, dass man auch feststellen kann, wie sich

Prof. Dr.-Ing. Eduard Igenbergs TU München

WINGbusiness 3/2008

Top-Thema verschiedene Ereignisse bzw. Vorgänge später auswirken. Man möchte also Fehler auf Ursachen zurückführen. Bislang gibt es nur einen Rechner, der dies kann – und der heißt Mensch. Was würde der Welt fehlen wenn es kein Systems Engineering gebe? Systems Engineering gibt es ja schon seit fast 1000 Jahren. Im Grunde genommen ist ein Versuch, zwischen Menschen, Methoden und Technologien besser zu kommunizieren. Und Kommunizieren ist bei der Lösung von technischen Aufgaben heutzutage unabdingbar. Sehen Sie in der Welt Probleme, die durch einen verstärkten Einsatz von Systems Engineering – oder dessen Einsatz über-

haupt – besser oder schneller gelöst werden könnten? Ja, aber nicht durch den alleinigen Einsatz von Systems Engineering, sondern auch zum Beispiel durch den Einsatz von Operations Research. In der nächsten Zeit wird das Gebiet der Logistik immer wichtiger, das heißt die Verteilung von Gütern und Energie. Systemisches Denken ist dabei sehr wichtig. Systemisches Denken bedeutet ja, dass wir alle Fachrichtungen und alles was es gibt, in Betracht ziehen. Herr Prof. Igenbergs, sagen Sie uns doch zum Abschluss dieses Interviews, wieso Sie meinen, dass sich Forscher und Ingenieure mit dem Thema Systems Engineering beschäftigen sollen.

Die wichtigste Aufgabe für jeden Ingenieur ist es, Probleme lösen zu können. Und da die Probleme immer komplexer werden, ist es wichtig, den Systemblick anzuwenden, um damit den Überblick zu behalten. Die Anwendung des systemischen Denkens ist es auch, was man behält, wenn man die Firma oder das Fachgebiet wechselt. Man kann sich damit in neuen Gebieten viel schneller zurechtfinden und hat große Vorteile beim Finden oder Wechseln einer Berufstätigkeit. Herzlichen Dank für das interessante Gespräch! Das Interview führten Herr Dipl.-Ing. Markus Kohlbacher und Herr Dipl.Ing. Ernst Stelzmann

LEUTE/KÖPFE

Dipl.-Ing. Dr. Peter Steinbauer Nach dem Abschluss des Studiums „Wirtschaftsingenieurwesen-Maschinenbau“ an der TU Graz im Jahre 2001 nahm Peter Steinbauer seine Tätigkeit als wissenschaftlicher Assistent am Institut für Betriebswirtschaftslehre und Betriebssoziologie der TU Graz auf. Dort schloss er 2006 seine Dissertation zum Thema „Anforderungen an den F&E-Controller und ein F&E-Controlling in technologieorientierten Unternehmen in Österreich“ ab. Nach Beendigung seiner wissenschaftlichen Tätigkeit trat Dr. Steinbauer als Controller in den Finanzkonzern Hypo Group Alpe Adria in Klagenfurt ein. Zunächst arbeitete er bei der österreichischen Leasing-Tochter des Konzerns. Ab 2007 wechselte Dr. Steinbauer als Senior Controller zur Hypo Alpe-Adria-Bank AG (österreichische Bank-Tochter des Konzerns), wo er unter anderem an der Entwicklung eines auf risikoadjustierten Kennzahlen basierenden Steuerungssystems mitwirkte. Seit 2008 arbeitet Peter Steinbauer als Senior Consultant bei Capgemini Consulting Österreich AG im Bereich Finance & Employee Transformation. Sein Aufgabengebiet umfasst in erster Linie die Beratungstätigkeit auf CFO-Ebene in Mittelund Osteuropa. Das Themenspektrum reicht von der Vorbereitung strategischer Entscheidungen über Lösungsentwicklung für operative Fragestellungen bis hin zur aktiven Unterstützung von Systemimplementierungen. Peter Steinbauer ist 34 Jahre alt und lebt in Wien.

WINGbusiness 3/2008

WING-Paper

Methodology for overall company restructuring and the simulation as added value Robert N. Minovski, Bojan D. Jovanoski Abstract— How do you improve one’s enterprise performance? What is the best time for the management team to appoint more efforts and resources in restructuring? How, when and what needs to be taken care of? Answers to these questions and similar issues are treated in this paper, where the methodology of creating a model for selecting an optimal solution for enterprise restructuring will be described. For better understanding of this kind of model, brief introduction to the performance measurement and a short overview of the performance measurement methodology COMPASS (COmpany’s Management Purpose ASSistance) are presented. COMPASS is based on its performance measurement system which is consisted of numerous Key Elements of Success - KEs (like, Time, Quality, etc.). The basic idea is to measure those KEs from the importance point of view (outer stand) and the performance point of view (inner stand). The KEs where inconsistency between importance and performance is detected are Critical Elements (CEs) that should be treated further in order to improve the actual situation in the enterprise. In general situation there are numerous actions (here called Success Factors - SFs) that can be taken into consideration for every CEs. In order to cope with these combinations, scenario technique and simulation are utilized. The outcomes of the simulation are further processed, presented in scenarios of possible solutions that are basis for future analysis and creating a decision for the measures that need to be taken. Index Terms— COMPASS, enterprise restructuring, model, scenario, simulation.

among other purposes (dissemination of the knowledge about method approaches for enterprise management in actual situation), had one main goal: to create a methodology for overall enterprise restructuring. The name of the methodology is COMPASS (COmpany’s Management Purpose ASSistance), which clearly shows its main intention - to offer aid in the key decision making points in the complex process of enterprise restructuring. This model should generate actions for improvement of the current situation in the enterprise. The model should take into consideration the specifics of the country, as a country in transition, but it is still general approach and it is aimed to be implemented in every situation. The definition of the basic idea of this model is following: The basic idea of the model is to utilise a (sub)model of performance measurement, which will enable determination of the inconsistency of the importance and performance of all segments of the enterprise and on that basis to generate quantified alternative and then optimal actions for partial or overall (depending on the defined task) improvement of the situation ( fig. 1). Different segments of the enterprise are described through 18 variables called subkey elements of success (subKEs) provided by the (sub)model for performance measurement. The PMS (sub)model tries to trace the logic of one profitoriented enterprise, summarised like: finding out optimal Customer d emands

I. INTRODUCTION OF COMPASS In the late 90s, a research project was conducted, titled as “Methods repertoire for determination of the industry capabilities on the example of chosen enterprises of the metal - working industry in Macedonia”. The research institutions were Fraunhofer Institute of Production and Automation (Fraunhofer Institut fuer Produktionstechnik und Automatisierung), Stuttgart, Germany and Faculty of Mechanical Engineering, University of Ss. Cyril and Methodius, Skopje, R. Macedonia. This research project, Manuscript received June 30, 2008, and accepted August 30, 2006, by Prof. Siegfried Vössner. Associate professor Robert N. Minovski is working at the Faculty of Mechanical Engineering, University Ss. Cyril and Methodius, Skopje, Macedonia and you can contact him at mrobert@mf.edu.mk.

Top management

Strategy

Goals of the strategy

GAP ANALYSIS I/P MATRIXES consistency of the strategy goals and the performance measures

Insight in the enterprise doing Analysis

Benchmarking

Performance Measurement

Actions for improvement of the situation PERFORMANCE MEASUREMENT SYSTEM

Fig. 1. The basic idea/mission of the model

WINGbusiness 3/2008

WING-Paper Main mission of the enterprise

Maximising the profit

Customer satisfaction demands

Responds to the demands

Constraints

Wide product mix xspecific demands xstandard demands Quality xproduct quality xquality xservice quality xdelivery quality financial xproduct price Time xtime for delivery Ecology xre-cycling

Economical constraints x profitability x cash flow x capital growth x ROI x market share Legislative S ocial constraints

...

Purchasing Marketing R&D Design Manufacturing Quality management Logistics Maintenance PPC Assembly Sales

...

KEs and subK Es Time x duration x reliability x compressibility Quality x capability x performance x accuracy Flexibility x product mix x quantity x innovation Costs x material x labour x equipment x overhead Productivity x material x labour x equipment x facilities x energy

...

Fig. 2. The PMS (sub)model

<=>

ways for putting in practice customer demands in order to maximise the profit by considering the constraints of the environment in the same time. Namely, the stand presented here is that fulfilment of the main goal of the enterprise

(maximising the profit) should be accomplished through customer satisfaction, as a driving force of all actions of the enterprise. The enterprise should undertake appropriate actions to respond to those customer demands, respecting the actual constraints of the environment. So, when analysing the various segments of the enterprise, we are analysing these responds to the customer demands. Here they are called Key Elements of Success - KEs. In this research five KEs are determined - time, quality, flexibility, costs and productivity. The problem with these KEs is that they are not focused enough. There are several aspects of every KE which provokes several measures for determination of every aspect. That is why they are additionally decomposed to their elements, subkey elements of success - subKEs. Examples of subKEs, fig. 2, are: Time-Reliability, Quality-Capability, Flexibility-Product mix, ... These subKEs have the needed broadness in the view - to represent one aspect for the whole enterprise and they are concrete enough - they can be measured even with a single measure for the whole enterprise and are able to show the directions for further improvement. In such way, the PMS (sub)model is making the straight connection between the main goal of the enterprise and the operative measures. It should be stressed that these variables are describing the enterprise from the beginning to the end of the analysis - they are analyzing the enterprise from three main aspects: the strategic importance, actual performance and generated actions for improvement of the situation. They are the framework of the analysis, which is dictating the analysis of the enterprise.

Content of the phases in the model 1. Elucidation of the present situation of the enterprise in a measurable form from strategic importance point of view. The measurement of this issue is done through subKEs. AHP method is implemented [Saaty 80]. 2. Explanation of the present situation of the enterprise in a measurable form from actual performance point of view. The measurement of this issue is done through subKEs. Specific methodology for auditing is created - SAudit [Minovski 98], which is followed by a specially created procedure for evaluation. 3. In order to determine the inconsistency of the subKEs from strategic and actual performance point of view I/P matrixes are employed. The result of this phase is the list of Critical Elements - subKEs which have unbalance between their importance and performance. 4. The beginning of the action generation is in the fourth phase. For every Critical Element (CE), appropriate Success Factor (SF) is induced. Examples for Success Factors are: shortening the cycle time, smaller lots, layout optimization, more intensive education and training in some/all departments, standardization, automation ... So, SFs can be defined as various kinds of actions which should lead to improved situation in the enterprise. The generation of the SFs is done heuristically. 5. This phase should structure the bunch of SFs. The idea is to simulate the situation after the implementation of every possible set of SFs through the implementation of the particular procedure for scenarios generation and analysis.

Some of the utilized method approaches x AHP method x Team work (Workshop with the top management) x SAudit x SWOT x Interview x I/P matrixes (Gap analysis) x Team work (Workshop with the top management) x Structured knowledge about method approaches x Forms for performance measures x Matrixes KE -functional areas x Scenario technique x Qualitative MICMAC method x Simulation

6. Selection of the optimal solution is determined in the sixth step. Previous phase gives the situation where certain scenario leads, concerning only subKEs. In this phase, the financial effect of every action is estimated.

x Team work x Pay-back method x Costs/Gain diagram

7. The seventh phase covers the implementation of the optimal action - no specific methods or procedures, but team work are foreseen for this phase in the present stage of development of the model.

x Team work

Fig. 3. Phases of the model for enterprise restructuring (Minovski et al. 2000)

WINGbusiness 3/2008

WING-Paper A. Phases of the model implementation and some utilised methods The phases of the model are practically representation of the basic idea of the model - first two steps should measure the strategic importance and actual performance through subKEs, than in the third phase the inconsistency between strategic importance and actual performance should be measured. After that, the actions should be generated (fourth step), quantified (fifth step) and optimal solution should be determined (step 6). At the end, in the seventh phase, the optimal action should be implemented. Those phases are presented in fig. 3, together with the implemented methods in every phase (Jovanoski et al. 2000). The first phase should determine the importance of the KEs and subKEs. This importance is from the strategic point of enterprise view, taking into consideration the customer demands. For this purpose the AHP- Analytical Hierarchy Process, (Saaty 1980) is utilised. It is a method for multicriteria optimisation. Participation of the top management of the enterprise is dominant in this phase, as a source for the enterprise strategic goals. The reasons why this method is implemented are following: x included consistency control - for every comparison matrix consistency ratio is calculated, which gives bigger reliability to the decision making x structured evaluation process - complex multi-criteria decision making process is decomposed, with clearly defined goals, criteria and alternatives x instead cumulative decision making, this method first compares separately the criteria, and after that alternatives concerning every criterion, on the basis of the aforementioned structure of the problem x specifically for this area - implementation procedure insists on active participation of the top-management, which gives extra value to the results The goal of the second phase is to determine the technical and economical capabilities of the company. For that purpose, a specially structured questionnaire, called SAudit is used to audit the company. It contains 98 questions. Example R&D.2. Introduction of the improvements New Date of improvement initialisation of introduction in the production (short info) improvement

of one question is shown in the fig. 4. Those questions should gather necessary qualitative and especially quantitative data for determination of over 200 measures. Interesting feature of the approach is the structure of those measures, organised as R-, I- and B- measures. R-measures are representing the situation of certain subKE in certain structural/functional area. I-measures are influencing the situation of certain subKE in certain structural/functional area. B-measures are being influenced by the situation in the certain subKE. For example, for the subKE Time-Duration in the structural/functional area Manufacturing, measure “Manufacturing Cycle Time” is R-measure, “Delays Due to the Part Shortage” is I-measure and Delivery Cycle time is Bmeasure. It is obvious that R-measures are used to evaluate the importance of certain subKE, I-measures are used for generation of the actions for improvement of the situation in concrete subKE (phase 4) and B-measures are showing the impact of the current condition of the subKE. After the data have been obtained, the special procedure for evaluation is employed in order to quantify the performance of every subKE. The main tool of this procedure is the “subKEs-structural/functional areas” matrixes, fig. 5, filled in with R-measures. Namely, the idea behind is that the value of one subKE is derived from its values through all structural/functional areas. The output of this phase is quantified list of ranked subKEs. The only difference with the list generated in the phase 1 is that that now these subKEs are ranked according their performance in the enterprise. Phase three of the methodology tries to translate the market demands on the enterprise. In order to determine the inconsistency of the subKEs from strategic importance and actual performance point of view I/P matrixes are employed, fig. 6. The output of this phase is the list of Critical Elements - subKEs which have unbalance between their importance and performance (here the accent is on the gaps, although and false alarms has a great potential for improvement of the enterprise situation). This analysis, although simple, gives an overall picture of the enterprise performance and the possibilities for

Level of improvement 1)

small

medium

great

Source of improvement

employee suggestion

customer suggestion

engineering

Total 1)

- The main criterion is whether they leads to a new product or not, which can be described as the change in the shape and functions in the Key Constructive Groups (KCG) of the product. So: Small improvements - they don’t lead to new product (small improvements in the shape or functions of the KCGs OR improvements in less than 20% of the KCGs) Medium improvements - they lead to new/variant product (medium improvements in the shape or functions of the KCGs OR improvements in less than 60% of the KCGs) Great improvements - they lead to new product (great improvements in the shape or functions of the KCGs OR improvements in more than 60% of the KCGs) Fig. 4. Example of one question in SAudit (Minovski et al. 1998)

WINGbusiness 3/2008

WING-Paper

Structuralfunctional area

Sub-area

Duration W

Value

TIME Reliability / Dependability W Value

Value

Flexibility

R&D

R&D of new technologies R&D of new products

0,1 0,2

0,6 0,2

0,1 0,1

0,4 0,1

0,1 0,1

0,8 0,3

DESIGN

Technical documentation - new products Technical documentation – adaptations

0,2

1,2

0,2

0,9

0,1

1,4

SALES AND DISTRIBUTION

Packing Distribution Making order for production Customer management Servicing and technical support to the customer Making an offer TOTAL VALUE of the subKEi

0,1 0,1 0 0 0 1 0,2

VALUE of the KE

0,8 1,1

4,8 0,8

0,1 0,2 0 0 0 1 0,35

0 0,6 1,2

0,5

0,2 0,1 0 0 0 1 0,45

1,1 1,5

1,2

0,875

Fig. 5. Example of “subKEs-structural/functional areas” matrixes (Minovski et al. 2002)

improvement. Theoretically, it can be even done in 5 minutes by the managers who are working for some time in the enterprise and it would still help them in gaining a good picture of where the company is and what is “lacking”. From there, they can generate list of actions for improvement. Of course, usage of methodologies and techniques can improve the analysis, and this is highly suggested. The beginning of the action generation is in the fourth phase. For every Critical Element (CE), appropriate Success Factor (SF) is induced. Examples for SFs are: shortening the cycle time, smaller lots, layout optimisation, more intensive education and training in some/all departments, standardisation, automation ... So, SFs can be defined as various kinds of actions which should lead to improved situation in the enterprise. The generation of the SFs is done C-m

T-r

Q-po

False alarms

P-eq

OK2

Q -a T-d Q-pe

F -q P-l

C -o

P-f

OK1

P-en

T-c

Gaps C-l F-i

F- p

C -e

P-m

I Fig. 6. Importance/Performance (I/P) matrixes (Minovski et al. 2000)

WINGbusiness 3/2008

heuristically. Previous phases determined the domain of the process of restructuring, by determining the Success Factors which should improve the situation in certain Critical Elements. The fifth phase should structure that bunch of SFs. For this purpose, scenario technique is employed. The idea is to simulate the situation after implementation of every possible set of located Success Factors (if there are 3 Success Factors and they have only one way to be improved, number of possible sets is equal to the combinations without repeating 7: SF1; SF2; SF3; SF1+SF2; ...; SF1+SF2+SF3). The need to examine every set of Success Factors brought to the utilisation of the simulation technique. The situation is pictured with the CSM (Comprehensive Situation Mapping), (Georgantzas et al. 1995). In that order the relationships between Success Factors, between Success Factors and Critical Factors and between Critical Factors should be established. It is clear that is very difficult, but necessary task, because those kind of analysis are contributing with deeper understanding of the situation, both the present and the future one. Additional to this thesis it may be added that CSM attributes the relationships with: coefficients of influence which one element is transferring to another one and needed time for the transfer of influence. In the utilisation of CSM, we are adding also the costs needed for this transfer. After the simulation, the basis for the analysis performed in the next phase (sixth) is established. Namely, the frame for monitoring the impact of every set is fixed. This frame

WING-Paper practically determines the scenarios for the future situation (Minovski et al. 1999). II. SIMULATION MODEL In order to create a successful implementation and for everyone to be “sure” that the best possible solution is going to be implemented, a series of simulation test-runs have to be undertaken. From the whole list of subKEs, three were selected to be included in the simulation model (Qualityperformance, Productivity-equipment and Costs-overhead) in order to operate much easier in the model itself. It would have been much relevant simulation model if ALL subKEs are taken in consideration, but the chances of errors would have been greater, as well as the number of scenarios and simulation runs. In fig. 7, a basic scheme of relationships between the selected subKEs and the designated SFs is shown. As it can be seen, all possible relationships exist. The selected set of SFs is the one that can influence most under the given conditions and the selected subKEs. The influence (the quantity) between each of the six elements is shown in the fig. 8. These numbers are taken heuristically and used in the formulas when creating the simulation model. They are indicated as percentages how much the improvement of one will effect the other. The negative expression by the relation Productivity-equipment to Quality-performance means that it has a negative influence on it (it decreases the Quality-performance value). The final version of the simulation model, with its elements and connections can be seen at fig. 9. As it can be seen, not only the subKEs and SFs are presented here; additional elements have to be inserted in order the simulation to function properly and to better represent the real situation. All together 8 different simulation runs were done (one with the current situation and seven with the proposed implemented SFs). There are differences and improvements as soon as a SF is included in the possible improvement scheme. The values can be compared in the following table as normalised values (tab. 1). Of course, even the novice can see that the best performance of the enterprise will be achieved if all SFs are implemented (in this version – all three). But, would that implementation (speaking about the

Fig. 7. Relationships between the subKEs and SFs

Fig. 8. Influence of the elements in the model, in percentages

costs of course) be reasonable, cost-effective? That is why the prism with all possible scenarios is done at the end (Minovski et al. 1999) – to give the managers, and the people who decide with which scenario to continue, a better overview of the possible solutions. This means that at this stage of development COMPASS does not select optimal scenario. It only offers the most prospect scenarios with the caused improvements and the needed costs for implementation of each scenario. In ideal situation, the improvements should determine the improved customer satisfaction and at the end the increased profit. Than the ROI can be determined and all scenarios be compared. Although there are some research activities for establishing the relations between customer satisfaction and profit of the enterprise, we have decided that establishment of

Fig. 9. Final version of the simulation model

WINGbusiness 3/2008

WING-Paper Table 1. Compared values of all scenarios after the 24 month simulation run QUALITYperformance current state with new machine training for quality with new layout new machine + training new machine + layout training + layout machine+training+layout

PRODUCITVITY- COSTSequipment overhead

0 5,2 19,2 -5,3 39 3 15,9 33,3

0 -3,1 2,9 16,9 12,9 26,9 32,9 42,9

0 5 5 10 10 15 15 20

such relations is very difficult at the moment. One of the biggest problems of this simulation (but with all simulations in general) is the verification that needs to be done. In this case, big restructuring changes are foreseen in the enterprise and it needs time for those to have a full effect. That is why the simulation run is configured as 24 months, an optimal time to have effect from the changes, but also not to fade too much. In order to validate the simulation model, the parameters need to be benchmarked before the implementation of the SF and after 24 months. III. CONCLUSION The idea of using the simulation arises when the help of the computer is needed in generating number of scenarios there are for a given situation, in a shorter time span. This simulation model only consists of three subKEs, which surely cannot represent the enterprise as it is. Even with that small number of subKEs, a lot of additional elements needed to be included in order the simulation model to be as realistic as possible. The goal is to make one general simulation model that can be used in the enterprises and tweaked for a given situation. However, in order to do so, a decreased in the number of subKEs would be very helpful (maybe combining two in one etc.). ACKNOWLEDGMENT Material presented in this article is a part of the GermanMacedonian project titled as “Methods repertoire for determination of the industry capabilities on the example of chosen enterprises of the metal - working industry in Macedonia”, financed by the Ministry of Science in R. Macedonia and DLR office in Köln. REFERENCES 1. 2. 3. 4.

Björkman M. 1995: A structured methodology for systematic evaluation of manufacturing systems, 6th International Conference on manufacturing engineering, Melbourne. pp. 665-670. Georgantzas N. C., Acar W. 1995. Scenario-Driven Planning: Learning to Manage Strategic Uncertainty, Quorum Books. Jovanoski D., Minovski R. 2000. Implementation of some management tools in a model for enterprise restructuring, 26th JUPITER Conference, Belgrade. Minovski R., Jovanoski D., Muthsam H. 1998. Audit - Tool For Determination of the Techno-Economical Capabilities of the Enterprise, Invited paper at the Second International Conference on Industrial Engineering, pp. 19-24, Belgrade.

WINGbusiness 3/2008

5. 6.

7. 8.

Minovski R., Jovanoski D., Muthsam H. 1999. MORE – a Methodology for Overall Restructuring of the Enterprises, Journal of “Industrial Engineering & Management”, Vol. 4, No. 4, Shanghai. Minovski R., Jovanoski D. 2000. Utilisation of the Importance/Performance (I/P) Matrixes in a Model for Enterprise Restructuring, Proceedings of the 44th European Quality Congress, Volume 1, pp 79-86, Budapest. Minovski R., Jovanoski D. and Zeh K-P. 2002. COMPASS – ein universelles Modell zur Unternehmensstrukturierung, Refa – Nachrichten, Heft 5/Oktober, pp.53-58. Saaty T. 1980. The Analytic Hierarchy Process, McGraw-Hill

Robert N. Minovski, was born on 20.11.1964 in Bitola, R. Macedonia. He gained his B.Sc. degree in Mechanical Engineering at the Faculty of Mechanical Engineering, University Ss. Cyril and Methodius, Skopje, R. Macedonia in 1989. At the same university he gained his M.Sc. degree in Mechanical Engineering in the field of Computer Aided Process Planning in 1994 and Ph.D. degree in Technical Sciences in the field of Enterprise Restructuring in 1999. From 1989 he is working on different positions at the Faculty of Mechanical Engineering. From 2004 he is acting as an Associated Professor in the same institution in the field of Industrial Engineering and Management and is a Head of the Laboratory of the Industrial Engineering and Management. His main research areas are the enterprise restructuring, quality management, management information systems, modelling and simulation, etc. He had publications in Journal of Eastern European Economy – New York, Journal of Industrial Engineering and Management - Shanghai, Refa – Nachrichten, European Quality Congress, etc. He had several visits abroad: Institut fuer Produktions Technik und Automatisirung - FhG Stuttgart, UMIST University - Manchester, Helsinki University of Technology, Northern Advancement Center for Science & Technology, Sapporo, Vienna University of Technology, etc. Assoc. Professor Minovski is a member of several associations, like Association of the Production Engineers in Macedonia, Association of the Quality Managers and Auditors of Macedonia, member of the Steering Committee of the Human Resource Development Fund of Macedonia, etc. Bojan D. Jovanoski, was born on 13.12.1982 in Skopje, Macedonia, where he lives and works. He gained his BSc. degree in Industrial Engineering and Management at the Faculty of Mechanical Engineering, University Ss Cyril and Methodius, Skopje, Macedonia in 2006. The same year he became a master degree student at the same department (Industrial Engineering and Management), and he is in the end of his studies. His research is with the topic “Optimizing the process of restructuring of the enterprise with application of simulation”. After he graduated he got employed at the University Business Start-up centre, and since May 2008, he is working as junior assistant at the Faculty of Mechanical Engineering. During his studies and research, he had several visits abroad; several months in the period (2000-2003) at the IPA-FhG Stuttgart, Germany and one month in 2007 at TU Graz, Austria. All were in the field of Information systems, databases, simulation, digital factory and similar fields. Ass. Jovanoski was very active during his student years and now he is an ESTIEM Alumni. He has received the national award for outstanding student and an Engineering ring for the best student at the Faculty of Mechanical Engineering for the 2007 generation.

Wing-Paper

Systems Engineering: neu überdacht Reinhard Haberfellner und Ernst Stelzmann Abstract— Das Systems Engineering-Konzept als systematischer Leitfaden zur Gestaltung von Systemen bzw. Abwicklung von Projekten ist nun in seiner Reifephase. Ausgehend von den Arbeiten von A.D. Hall in den BellLaboratories wurde es von Mitarbeitern des Betriebswissenschaftlichen Instituts der ETH Zürich aufgegriffen, erweitert, konkretisiert und auch regelmässig neuen Anforderungen angepasst. Reinhard Haberfellner war Mitglied des ETH-Kernteams. Eine englische Version, die ca. 60 Prozent des ursprünglichen Konzepts beinhaltet, wird dzt. vom MIT-Professor Olivier de Weck bearbeitet. Wir an der TU Graz betrachten es als eine Herausforderung, an diesem Prozess aktiv teilzuhaben und insbes. neuere Entwicklungen, die unter dem Begriff „Agile Methods“ publik werden, sorgsam zu verfolgen und wenn möglich in das bestehende Konzept zu integrieren. Das vorliegende Papier gibt Einblick in diese Überlegungen. Index Terms — Agile Methods, Problemlösungszyklus, Projektmanagement, Systems Engineering

I. DAS SE-KONZEPT

AS SE-Konzept kann kurz wie folgt charakterisiert werden (Haberfellner et al. 2002): SE ist ein Denkmodell und eine Vorgehensmethodik zur Lösung komplexer Probleme. Diese Methodik soll eine

systematische und transparente Gestaltung des Problemlösungsprozesses sowie eine effiziente Führung und Abwicklung des Problemlösungsprozesses ermöglichen. Sie soll die Suche nach kostengünstigen, effizienten, sozial verträglichen, termingerechten Lösungen unterstützen. Die Anwendung dieser Methodik ist grundsätzlich vielfältiger Art. Trotz unterschiedlicher Begriffe in verschiedenen Disziplinen bzw. Anwendungsgebieten ist die Grundidee vielfältig einsetzbar. Die Methodik ist aufgeschlossen für die Nutzung verschiedenster Methoden und Techniken, im Sinne eines Werkzeugkastens. Das SE-Konzept besteht aus folgenden Komponenten (siehe Abb. 1): Dem Systemdenken als Werkzeug zur Darstellung von Wirkungszusammenhängen, zur Strukturierung und Abgrenzung der Ausgangssituation und der Lösungen. Dem Vorgehensmodell als modular aufgebautes Konzept, das auf einfache Art den praktischen Bedürfnissen und der Grösse eines Projektes angepasst werden kann. Der inhaltlichen Gestaltung eines Systems (Systemgestaltung) und den entsprechenden Methoden und Techniken der Systemgestaltung, insbesondere jenen der Situationsanalyse und Zielformulierung, der Lösungssuche und der Bewertung bzw. Auswahl von Lösungen.

SE-PHILOSPHIE SYSTEMDENKEN

PROBLEM

VORGEHENSMODELL

PROBLEMLÖSUNGSPROZESS SYSTEMGESTALTUNG

TECHNIKEN der SYSTEMGESTALTUNG

PROJEKTMANAGEMENT

LÖSUNG

TECHNIKEN des PROJEKT-MANAGEMENT

Abb. 1. Das Systems Engineering Konzept

Manuscript received May x, 200y, and accepted August z, 200y, by Prof. Siegfried Vössner.

WINGbusiness 3/2008

Wing-Paper Dem Projektmanagement als Summe von organisatorischen Überlegungen und Massnahmen zur Abwicklung von Projekten und den verschiedenen Methoden und Techniken, die deren Einsatz unterstützen sollen, wie z.B. Ressourcenplanung und Budgetierung, die Konfiguration der Projektgruppe, die Kompetenzen des Projektleiters, die Steuerungsgremien, Zeitplanung, Ablaufplanung, Teamarbeit, Konfliktlösung u.a.m.. A. Der Systemansatz Das Denken in Systembegriffen soll dazu anregen, die Elemente eines Problems und wichtige Einflussfaktoren herauszuarbeiten, zueinander in Beziehung zu setzen und sinnvolle Grenzen für Problemfelder und Lösungen zu finden. Probleme sollen dabei - vor allem zu Beginn - nicht zu eng gesehen werden, sondern als Bestandteile eines umfassenderen Systems, im Sinne eines ganzheitlichen Denkens. Deshalb ist es sinnvoll, zu Beginn eines Projektes den Horizont zunächst bewusst auszuweiten, um ihn dann aber rasch auf ein bewältigbares Ausmass einzuschränken. Die Blackbox-Betrachtung ermöglicht dabei eine Grobstrukturierung (Überblick wahren), die Unterscheidung verschiedener Betrachtungsaspekte („Brillen“) ermöglicht es, differenzierte Standpunkte gegenüber einem Sachverhalt einzunehmen. Die Idee des ganzheitlichen Denkens ist sowohl auf Probleme, wie auch auf Lösungen anwendbar und lenkt das Augenmerk auch auf Voraussetzungen und Konsequenzen,

PROBLEM

die erwartet werden können bzw. müssen. Zusammenfassend und vereinfacht gesagt, sollen folgende Fragen geklärt werden: - Was ist das System, das wir anschauen? Wie definieren wir es? - Was sind die Bausteine, Elemente dieses Systems? - Wie stehen sie zueinander bzw. mit anderen Elementen (Umwelt) in Beziehung? - Welche(r) Aspekt(e) des Systems sind für uns von Bedeutung? Welche Brille(n) sollten wir benützen? - Wie grenzen wir unser System von der Umwelt ab? (System: der von uns gestaltete, veränderte Bereich. Umwelt: Jener Bereich, den wir zur Kenntnis nehmen, aber nicht direkt beeinflussen können oder wollen). - Welche Umwelt ist bzw. Teile der Umwelt sind von Bedeutung? - Wie sind sie definiert und wie stehen Sie in Beziehung? - Welchen Teil können/dürfen wir verändern? - Welche Teile, die Beziehungen aufweisen, haben wir zu beachten? Ergebnis sollte ein gemeinsames Verständnis darüber sein, worüber wir sprechen, was wir neu gestalten bzw. verändern sollen bzw. dürfen - und was wir als (derzeit?) unveränderbar betrachten. B. Das Vorgehensmodell Das SE-Vorgehensmodell besteht aus 4 Komponenten, die sinnvoll miteinender verbunden werden können (siehe Abb. 2): Modul 3: PROJEKTPHASEN (PP)

Modul 4: PROBLEMLÖSUNGSZYKLUS (PLZ)

Anstoss Vorstudie (E)

Varianten von Lösungs prinzipien

Hauptstudie (E)

Varianten von Gesamtkonzepten

Lösungssuche

Zielformg Lö.Synthese Lös. Analyse Bewertung

Detailstudien (E)

Varianten von Detailkonzepten

ausgewählte u. weiter bearbeitete Variante

Sit.-Analyse

Zielsuche

Modul 1: TOP DOWN

Systembau (R)

Modul 2: VARIANTENBILDUNG (VB)

S.-Einführung (R)

Auswahl

Entscheidg

E = Entwicklungsphase R = Realisierungsphase

Abschluss d. Projekts

Abb. 2. Das SE-Vorgehensmodell und seine 4 Module

WINGbusiness 3/2008

Wing-Paper Das Vorgehensprinzip „Vom Groben zum Detail“ (Modul 1: top down), womit gemeint ist: Gesamtübersicht vor Detailuntersuchung, Gesamtkonzept vor Detailkonzepten. Das Prinzip des Denkens in Varianten (Modul 2): Grundsätzlich nicht mit einer einzigen (der "erstbesten") Lösung zufrieden zu geben, sondern nach Alternativen suchen. Das Prinzip der Gliederung eines Projektes in Projektphasen (Modul 3), demzufolge der Prozess der Systementwicklung und Realisierung nach zeitlichen Gesichtspunkten zu gliedern ist. Damit werden klare Marschhalte, Besinnungs- und Entscheidungspunkte ermöglicht, deren Beachtung für Projektteam und Auftraggeberschaft gleichermassen wichtig ist. Der Problemlösungszyklus (Modul 4): als sich wiederholende Logik innerhalb der Entwicklungsphasen mit den Schwerpunkten: Zielsuche (Wo stehen wir? Was wollen wir?), Lösungssuche (Welche Möglichkeiten gibt es, dorthin zu kommen?) und Auswahl (welches ist die beste, zweckmässigste?) C. Zuordnung und Kritik Das SE-Konzept gehört, wie eine Reihe anderer Methodiken der Gruppe der sog. „plan-driven“-Methods (p) an. Die Unterscheidung zwischen “plan-driven” und “agile” erfolgt in Anlehnung an Boehm et al. (2004). Mit „plandriven“ ist gemeint, dass diese ein hohes Mass an Struktur vorgeben und mit der Erwartung verbinden, dass damit auf effizientere Art qualitativ hochstehende Lösungen erarbeitet werden können. Andere Vertreter dieser Gruppe sind z.B. das sog. „Wasserfall“-Modell, das V-Modell, die INCOSEMethodology oder die IEEE-15288. Der Gedanke des Simultaneous (Concurrent) Engineering ermöglicht es bereits, gewisse agile Eigenschaften in die plan-drivenmethods einzuführen. Diese plan-driven-Methods werden – trotz des unbestrittenen Vorteils, dass sie eine logische Ablaufstruktur in Projekte bringen können – durchaus und zum Teil vehement kritisiert. Insbesondere wirft man ihnen vor, dass sie den (Software)Entwicklungsprozess unnötig schwerfällig machen, lange Entwicklungszeiten erfordern und im Ergebnis meist doch nicht befriedigen können, weil sie zu einem sehr restriktiven Verhalten gegenüber durchaus berechtigten nachträglichen Änderungen der Spezifikationen führen. Aus diesem Bedürfnis heraus haben sich – beginnend in der Softwareentwicklung - die sog. „agile methods“ (a) entwickelt. II. AGILE METHODS (A) ALS ALTERNATIVEN ZU DEN PLANDRIVEN METHODS (P)? Eine wesentliche Rolle im Zusammenhang mit der Entstehung der Agilen Methoden spielt das sog. Agile Manifesto (bzw. genauer “Manifesto for Agile Software

Development”), das in der Folge auszugsweise wiedergegeben werden soll (Beck et al. 2001): (Anm.: Übersetzung durch die Verfasser): „Wir bieten bessere Wege zur Entwicklung von Software an und wollen andere anregen, uns zu folgen. Dabei sind wir zur Auffassung gekommen, dass: - Personen und deren wechselseitige Beziehungen wichtiger sind als (vorgeschriebene) Prozesse und Werkzeuge - Funktionstüchtige Software wichtiger ist als umfangreiche Dokumentationen - Konstruktive Zusammenarbeit mit den Kunden wichtiger ist als langwierige und mühsame Vertragsverhandlungen - Reagieren auf wechselnde Anforderungen wichtiger ist als das konsequente Verfolgen eines Plans (der eigentlich schon überholt ist) Obwohl wir den Wert der in obiger Aufzählung jeweils rechts angeführten Aussagen durchaus anerkennen, ordnen wir ihn dem der Aussagen unter, die jeweils links stehen. Diese generellen Aussagen werden nachstehend präzisiert. Höchste Priorität hat die Zufriedenheit der Kunden. Wir können diese leichter erreichen, wenn - wir schon sehr bald und kontinuierlich Software abliefern, die der Kunde beurteilen kann und die für ihn brauchbar sind (Prototyping-Ansatz) - Änderungswünsche nicht als unangenehme Störungen betrachtet werden, sondern gemeinsam besprochen und ggf. akzeptiert werden, auch wenn sie in einem späten Stadium der Entwicklung vorgebracht werden. Durch diese Flexibilität tragen wir dazu bei, unseren Kunden Systeme zur Verfügung zu stellen, die ihre Wettbewerbsfähigkeit fördern - wir darauf bestehen, dass unsere Kunden mit uns täglich und während der gesamten Dauer des Projekts aktiv zusammenarbeiten. Dabei sollten Sponsoren, Entwickler und Anwender imstande sein, ein konstantes Tempo lange Zeit durchzuhalten - wir in Projekten motivierte Menschen antreffen und ihnen ein Umfeld und jene Unterstützung geben, die sie für eine erfolgreiche Arbeit benötigen - wir unseren Teams zutrauen, dass sie ihre Aufgaben schaffen werden und sie dabei nach Kräften unterstützen. Die beste Architektur, die besten Requirements und Designs entstehen in sich selbst organisierenden Teams - wir uns immer vor Augen halten, dass die effizienteste und effektivste Methode, Information zu übermitteln die persönliche Kommunikation ist (face-to-face) - uns dessen bewusst sind, dass Einfachheit wichtig und eine Kunst ist, die darin besteht, den Umfang jener Arbeit zu maximieren, die nicht getan werden muss. - die Teams lernen indem sie sich in regelmässigen Intervallen damit beschäftigen, wie sie noch effektiver werden können – und ihr Verhalten entsprechend anpassen …“ Dieses Agile Manifesto ist im Klima eines generellen Unbehagens gegenüber den bestehenden, als starr

WINGbusiness 3/2008

Wing-Paper empfundenen Vorgehenskonzepten entstanden. Gleichzeitig wurde damit die Hoffnung auf raschere Verfügbarkeit von Ergebnissen verbunden, auf Möglichkeiten einer evolutionären Anpassung von Arbeit und Ergebnissen an veränderte Gegebenheiten und Möglichkeiten und nicht zuletzt auf zufriedene Kunden. Ausserdem ist in diesem Umfeld eine Reihe von sog. Agile Methods entstanden, mit denen versucht wird, die im Agile Manifesto enthaltenen Vorstellungen in die konkrete Projektarbeit zu übertragen. Aus der Vielzahl der Agile Methods sollen einige in der Folge kurz skizziert werden (Wikipedia 17.1.2008): - eXtreme Programming (XP) akzeptiert die Ungewissheit, mit der die Softwareentwicklung verbunden ist. Es folgt einem klaren, strukturierten Vorgehen und stellt Teamarbeit, Offenheit und stetige Kommunikation zwischen allen Beteiligten in den Vordergrund. Kommunikation ist eine Grundsäule dieses Vorgehensmodells. Die Methode berücksichtigt, dass der Kunde die wirklichen Anforderungen an die zu erstellende Software zu Projektbeginn meist selbst noch nicht genau kennt. Damit kann das mit der Realisierung betraute Entwickler-Team gar nicht über alle (technischen) Informationen verfügen, um eine verlässliche Aufwands- und Zeitschätzung zu machen. Im Laufe eines Projektes ändern sich darüber hinaus nicht selten Prioritäten. Zu Beginn geforderte Funktionen der Software werden evtl. in einer anderen Form benötigt oder im Laufe der Zeit sogar hinfällig. Angefangen mit einer ersten kleinen Version der Software, vergrößert sich der Umfang zusehends. Neue Funktionalitäten werden laufend entwickelt, in die bestehenden Versionen eingefügt und gemeinsam getestet. Um zu der zu entwickelnden Funktionalität zu gelangen, werden gewöhnlich jeweils die Schritte Risikoanalyse, Nutzenanalyse, die Bereitstellung einer ersten ausführbaren Version (exploratives Prototyping) und ein Akzeptanztest durchgeführt. Das Modell lässt sich als agil, iterativ und inkrementell bezeichnen. Sog. User-Stories (use cases) sind wichtiger Bestandteil der Methodik. Sie beschreiben die Funktionsanforderungen an ein System aus Sicht eines Akteurs und müssen aus deren Köpfen auf Papier gebracht werden. Zu allen User-Stories gibt es ausführliche Tests. Eine User Story ist erst abgeschlossen, wenn alle Tests erfolgreich abgelaufen sind. Der tägliche, kurze Austausch zwischen Entwicklern und Anwendern ist für die agile Methodik üblich. XP definiert fünf zentrale Werte, die von grosser Bedeutung sind: Kommunikation, Einfachheit, Feedback, Mut und Respekt. Interessant sind einige der vorgeschlagenen Praktiken des XP: Pair-Programming (2 Programmierer arbeiten gemeinsam, mit verteilten Rollen, die regelmässig getauscht werden: einer ist Driver, der andere Partner); Laufende Integration der einzelnen Komponenten zu einem lauffähigen Gesamtsystem in kurzen Zeitabständen; Testgetriebene Entwicklung bzw. Permanentes Testen; Kurze Iterationen

WINGbusiness 3/2008

und laufendes Einbeziehen der Kunden; Einfaches Design: die einfachste Lösung, die genau das Gewünschte erreicht, soll angestrebt werden (KISS 1 , YAGNI 2 ); gemeinsam akzeptierte Standards zur Erleichterung der Teamarbeit u.a.m.. - Feature Driven Development (FDD) ist eine Sammlung von Arbeitstechniken, Strukturen, Rollen und Methoden für das Projektmanagement im Rahmen agiler Softwareentwicklung. FDD stellt den Feature-Begriff in den Mittelpunkt der Entwicklung. Jedes Feature stellt einen Mehrwert für den Kunden dar. Die Entwicklung wird anhand eines Feature-Plans organisiert. Eine wichtige Rolle spielt der Chefarchitekt (engl. Chief Architect), der ständig den Überblick über die Gesamtarchitektur und die fachlichen Kernmodelle behält. FDD-Projekte durchlaufen fünf Prozess-Schritte: 1) Gesamtmodell entwickeln mit dem Ziel, einen Konsens über Inhalt und Umfang des zu entwickelnden Systems sowie das fachliche Kernmodell zu erreichen. 2) Feature-Liste erstellen und Features nach dem Schema Aktion, Ergebnis, Objekt beschreiben, 3) Features planen hins. der Reihenfolge, in der sie realisiert werden sollen. Diese richtet sie sich nach den gegenseitigen Abhängigkeiten der Features, ihrer Komplexität und der Auslastung der Programmierteams. Die Features werden zur weiteren Bearbeitung einzelnen Entwicklerteams zugeteilt. 4) Features entwerfen: Die Entwicklerteams erstellen Sequenzdiagramme für die Features und die Chefprogrammierer verfeinern die Klassenmodelle auf Basis der Sequenzdiagramme. Die Entwickler schreiben dann erste Klassen- und Methodenrümpfe. Schließlich werden die erstellten Ergebnisse inspiziert. Bei fachlichen Unklarheiten können die Fachexperten hinzugezogen werden. 5) Features konstruieren: die Entwickler programmieren die vorbereiteten Features. Dabei werden Komponententests und Code-Inspektionen zur Qualitätssicherung eingesetzt. Die ersten drei Schritte werden innerhalb weniger Tage durchlaufen. Die Schritte 4 und 5 werden in ständigem Wechsel durchgeführt, weil jedes Feature in maximal zwei Wochen realisiert werden soll. - Scrum (engl. das Gedränge) ist eine Sammlung von Arbeitstechniken, Strukturen, Rollen und Methoden für das Projektmanagement im Rahmen einer agilen Softwareentwicklung. Es enthält wenige Festlegungen. Teams bzw. Entwickler organisieren sich weitgehend selbst und wählen auch die eingesetzten Methoden. Das Vorgehen und die Methoden werden fortlaufend aktuellen Erfordernissen angepasst. Scrum knüpft an viele Grundannahmen der sog. Schlanken Produktion (engl. lean production) an und überträgt 1

KISS = Keep it simple and smart (Variante statt smart: stupid) YAGNI = You Ain't Gonna Need It, d.h. konsequenter Verzicht auf Funktionalitäten die derzeit nicht verlangt werden, aber möglicherweise in Zukunft 2

Wing-Paper Erfahrungen aus der Automobilbranche (Toyota) auf die Softwareentwicklung. Zentraler Aspekt ist bei beiden die ständige Weiterentwicklung der am Prozess Beteiligten, auch der Kunden und Partner, der Herstellungsprozesse, der Arbeitsmittel und Methoden, mit gleichzeitig konstantem Beibehalten der Grundannahmen, die dahinter stehen: die Produktion ständig zu verbessern, um höchste Qualität bei niedrigstem Aufwand zu erreichen. Zentrales Element von Scrum ist der Sprint, der die Umsetzung einer Iteration bezeichnet. Scrum sieht ca. 30 Tage als Iterationslänge vor. Vor dem Sprint werden die Produkt-Anforderungen des Kunden in einem Product Backlog gesammelt, wobei darunter die Features des zu entwickelnden Produkts zu verstehen sind. Es beinhaltet alle Funktionalitäten, die der Kunde wünscht, zuzüglich technischer Abhängigkeiten. Es gibt drei klar getrennte Rollen für die Mitarbeiter eines Projekts, die die gleichen Ziele verfolgen sollen: Der Product Owner legt das gemeinsame Ziel fest, das er und das Team zu erreichen hat bzw. sanktioniert es. Er stellt das Budget zur Verfügung und setzt regelmäßig die Prioritäten für die einzelnen Product-Backlog-Elemente. Damit entscheidet er auch, welche die wichtigsten Features sind, aus denen das Entwicklungsteam eine Auswahl für den

nächsten Sprint trifft. Das Team schätzt die Aufwände für die Entwicklung der einzelnen Backlog Elemente ab und beginnt mit der Implementierung der für den nächsten Sprint machbaren Elemente. Das Team arbeitet selbstorganisiert im Rahmen einer Time Box (dem Sprint), und hat das Recht (und die Pflicht), selbst zu entscheiden, wieviele Elemente des Backlogs nach dem nächsten Sprint erreicht werden müssen, man spricht dabei von sog. commitments. Der Scrum Master hat die Aufgabe, die Prozesse der Entwicklung und Planung durchzuführen und die Aufteilung der Rollen und Rechte zu überwachen. Er hält die Transparenz während der gesamten Entwicklung aufrecht, und fördert das Zu-Tage-Treten der bestehenden Verbesserungspotentiale. Er ist nicht für die Kommunikation zwischen Team und Product Owner verantwortlich, da diese direkt miteinander kommunizieren sollen. Er steht dem Team zur Seite und soll dafür sorgen, dass das Team produktiv arbeiten kann. - Crystal ist eine ganze Familie von Methoden, die eine Differenzierung hins. der Anzahl der beteiligten Personen und der Höhe der Risiken (sog. Kritikalität) ermöglicht. Die Methoden werden mit Farben benannt: Crystal Clear, Crystal Yellow, Crystal Orange, Crystal Red, Crystal Magenta,

Tabelle 1. Potentielle Eignung von Vorgehensmethoden (Boehm et al. 2004)

Kriterium Grösse des Projekts

Kritikalität (Sicherheit etc.)

Dynamik des Umfeldes

Personal

Kultur

Eignung von Agile Methods Gut geeignet für eher kleine Projekte und Teams. Stützt sich auf sogen. tacit knowledge (in den Köpfen gespeichertes Wissen, nicht explizit dargestellt). Skalierung nach oben damit begrenzt Keine Erfahrungen bei Sicherheitskritischen Produkten vorhanden. Schwierigkeiten zu erwarten bei einfachem design und mangelhafter Dokumentation. Dynamisches Umfeld und einfaches Design, verbunden mit kontinuierlicher Strukturanpassung (refactoring) passen ausgezeichnet zueinander. Erfordert die ständige Anwesenheit von qualifiziertem Personal. Wegen der o.a. Dynamik riskant, wenn nicht verfügbar Gedeiht in einer Kultur, in der Menschen Freude an grossem Gestaltungsfreiraum und Handlungsfreiheit (empowerment) haben.

Eignung von Plan-Driven Methods Grosse Projekte und Teams. Downsizing auf kleine Projekte schwierig

Entwicklung von hoch kritischen Produkten

Stabile Umwelt gestattet grosse Entwürfe, die dann detailliert ausgeführt werden.

Qualifiziertes Personal besonders für die Projekt-Definition erforderlich. Ausarbeitung auch von nicht ganz so hoch qualifiziertem Personal durchzuführen – sofern die Anforderungen stabil bleiben. Gedeiht in einer Kultur, in der Menschen sich gut fühlen, wenn ihre Rollen durch klare Prozeduren und Verhaltensweisen definiert sind.

WINGbusiness 3/2008

Wing-Paper Crystal Blue. Die einfachste Variante, "Crystal Clear" wird für Teamgrössen von zwei bis sechs Personen empfohlen. Im Vergleich zu anderen Agilen Methoden wird Crystal von seinen Befürwortern als weniger dogmatisch und formalisiert angesehen. Bei Crystal Clear werden z.B. weder Paarprogrammierung noch customer on site gefordert. Crystal sieht nicht dauerhafte Methoden für das Team vor, sondern legt sie für jedes Projekt neu fest. Bei einfacheren Projekten kann dies dazu führen, dass viele der auch in XP eingesetzten Agilen Methoden zum Einsatz kommen; bei komplexeren Projekten würden eher komplexere Methoden gewählt. III. EIGNUNGSBEREICHE DER PLAN-DRIVEN BZW. AGILE METHODS

In der Folge soll versucht werden, die „Claims“ für die in ihrem Charakter doch recht unterschiedlichen Methoden abzustecken. Dies erfolgt unter der Voraussetzung, dass ein Ansatz nicht ausschliesslich richtig und der andere nicht auschliesslich falsch sein muss, sondern dass es auf den konkreten Zusammenhang ankommt3. In Tabelle 1 werden die dominanten Einsatzbereiche der beiden Methodengruppen stichwortartig beschrieben. IV. GEGENSEITIGE ANNÄHERUNG MÖGLICH? Im Allgemeinen bestehen zwischen den plan-driven und den agile methods also teilweise grosse Unterschiede, sodass sie auf den ersten Blick miteinander unvereinbar zu sein scheinen. Speziell im Hinblick auf das SE-Konzept soll deshalb der Frage nachgegangen werden, inwieweit dieses tatsächlich im Widerspruch zu agilen Prinzipien steht. Dabei soll identifiziert werden - wo das SE-Konzept bereits Ansätze zu einer gewissen Agility aufweist bzw. agile Prinzipien unterstützt (A) - welchen agilen Prinzipien gegenüber sich das SEKonzept neutral verhält bzw. welche agilen Prinzipien innerhalb des SE-Konzept problemlos möglich sind, auch wenn sie nicht aktiv unterstützt werden (B) - und wo eine gewisse Unvereinbarkeit zwischen agilen Prinzipien und dem SE-Konzept besteht bzw. wo eine Einbeziehung agiler Prinzipien in das SE-Konzept noch eines Forschungsaufwandes bedarf (C) A. Bereits bestehende Agility im SE-Modell Fähigkeit zur Agility ist vor allem in folgenden Eigenschaften des SE-Vorgehensmodells zu erkennen (siehe Abb. 2): - Die gedankliche Trennung der 4 Module, insbes. des PP- und des PLZ-Moduls ermöglichen eine Anpassung der Methodik an unterschiedliche Projektgrössen: Kleine Projekte brauchen nicht in mehrere Entwicklungsphasen mit 3

sog. Situativer Ansatz in der Organisationslehre

WINGbusiness 3/2008

zunehmender Konkretisierung (TD) untergliedert werden. Es genügt ein 1-maliges Durchlaufen des PLZ mit unmittelbarem Übergang zur Realisierung (Systembau) - Wie bei den agile methods gefordert, liegt die ProzessVerantwortung beim Team. Je nach den Erfordernissen des Projektes, kann der Prozess vom Team selbst angepasst werden, z.B. für unterschiedliche Projektgrößen, wie soeben beschrieben. - Stetiges Lernen und die Verwendung von Erfahrungen sind im SE-Konzept ebenso wichtig, wie in den agile methods. Das SE-Konzept ist kein stur abzuarbeitender Prozess sondern eine Methodik, die eine Richtschnur darstellen soll, wie Fachwissen, Erfahrung, Methodenwissen, etc. am besten miteinander kombiniert werden können. - Das Prinzip der Variantenbildung auf 3 Ebenen (links im Bild), verbunden mit Entscheidungen am Ende der jeweiligen Entwicklungsphasen (Vor-, Haupt-, Detailstudien, Bildmitte) liefern Entscheidungssituationen, die eine Korrektur der Marschrichtung gestatten. - Die rückläufigen Pfeile im PLZ (rechts im Bild) stellen Rückgriffe auf frühere Schritte dar und können als Iterationen verstanden werden. - Besonders deutlich geht eine gewisse Fähigkeit zur Agility aus der Darstellung in Abb. 3 hervor: Jedes im Detail ausgearbeitet Detailkonzept wird gedanklich in das übergeordnete Gesamtkonzept integriert (nach oben gehende Pfeile). Nicht zufriedenstellende Situationen können und müssen bearbeitet werden auf der Gesamtkonzept- oder Detailkonzept-Ebene. Auch externe Einflüsse, die gar nichts mit dem Projekt zu tun haben, können eine Anpassung des Gesamtkonzepts erforderlich machen (Blitze in Abb. 3). B. Im SE-Modell problemlos anwendbare Agility Folgende agile Prinzipien werden vom SE-Modell zwar nicht explizit gefordert oder unterstützt. Sie können aber problemlos angewandt werden, ohne mit dem SE-Konzept in Widerspruch zu geraten.4: - Die personenbezogenen Ansätze, wie z.B. die starke Einbindung der Anwender in die Entwicklungsteams (customer on site), regelmässige Besprechungen in kurzen Zeitintervallen u.a. - Die Übernahme der Idee der Backlog-Elemente und Sprints (von Scrum) - Übernahme der Idee der User Stories und des explorativen Prototypings für ausgewählte und besonders diffizil zu gestaltende Module eines Systems - Übernahme der Gedanken der Einfachheit und Schlankheit von Prozessen: Simplicity (KISS, YAGNI,..), Toyota Lean Production System (Spear et al. 1999)

4 Die Integration dieser Prinzipien in das SE-Modell wird Ernst Stelzmann, der Ko-Autor dieses Aufsatzes, im Rahmen seiner gerade laufenden Forschungsarbeit aufzeigen.

Wing-Paper = reduziert Flexibilität

= erhöht Flexibilität

Status Projekt Phase

LösungsPrinzip

Vorstudie

Hauptstudie

Gesamt konzept

Detailkonzept 1

DetailStudien

Detailkonzept 2

Systembau, etc.

Detailkonzept 3

Detailkonzept N

= Externe Einflüsse

= Check, Modifikation, Anpassung = Unterschiedlicher Realisierungsstand

Abb. 3. Dynamik der Gesamtkonzeption mit schrittweiser Integration von Teilergebnissen und der Möglichkeit externer Einflüsse

C. Agility die schwer mit dem SE-Modell zu vereinbaren ist Bei einigen Prinzipien gibt es grössere Widersprüche zum SE-Modell. Weitere Forschung muss hier nicht nur ergründen, wie diese Prinzipien im SE-Modell angewendet werden können, sondern auch, ob dies überhaupt sinnvoll ist 5 : - Entwicklung in kurzen Iterationen die immer Kundennutzen liefern müssen: Als einer der wesentlichsten Punkte der agile methods, ist hier zu überprüfen, wie weit es möglich ist, die Systementwicklung iterativ zu gestalten. Die Grundvoraussetzung lautet ja, dass jede Iteration einen gewissen, ständig steigenden Kundennutzen liefern muss, d.h. funktionstüchtig sein muss. Für Software alleine ist dies natürlich viel leichter zu realisieren, als für Systeme (komplexe Produkte, wie z.B. Fahrzeuge). Vor allem in frühen Entwicklungsphasen wird Kundennutzen kaum realisierbar sein. Hier kann aber z.B. mit Simulationsmethoden (HIL) sinnvoll iterativ entwickelt werden, auch wenn die „System-Gesamt-Funktion“ und damit der Kundennutzen nicht dargestellt werden kann. In späteren Projektphasen, ist eine iterative Entwicklung mit Kundennutzen in gewisser Weise doch machbar und sinnvoll,

vor allem für Projekte in denen Prototypen des Systems entwickelt werden. - Neutralität gegenüber Änderungen: Hier gibt es umgekehrt Vorteile in frühen und Nachteile in späten Projektphasen. Das SE-Konzept wurde ja entwickelt, um nach einer anfänglichen Aufnahme aller System-Anforderungen und einer möglichst frühzeitigen Ermittlung aller weiteren Umstände, die das System betreffen können, in der Vorstudie ein Lösungsprinzip zu ermitteln und festzulegen. In der Hauptstudie soll dann ein Lösungskonzept ermittelt und festgelegt werden, um sich dann in den Detailstudien auf die Details zu konzentrieren. Es ist also sinngemäß ein Problem, wenn während der Hauptstudie noch eine Änderung des Lösungsprinzips verlangt wird oder während den Detailstudien eine solche des Gesamtkonzepts. Eine möglichst späte Festlegung des Lösungskonzeptes ist nicht immer möglich und zielführend. Welche Strategien hier erfolgversprechend sind oder auf welcher Ebene hier einzugreifen ist (z.B. Modularität in der Systemarchitektur oder verstärkte Anwendung von Software, weil diese ja per Update leicht verändert werden kann) muss erst genauer untersucht werden.

5 Mit diesen Fragen wird sich Ernst Stelzmann der Ko-Autor dieses Aufsatzes im Rahmen seiner gerade laufenden Forschungsarbeit beschäftigen. Die obige Aufzählung ist deshalb nur beispielhaft zu verstehen und ist noch nicht zu Ende gedacht

WINGbusiness 3/2008

Wing-Paper V. CONCLUSION Das Systems Engineering Konzept hat sich bisher als Methodik verstanden, mit der Projekte ganzheitlich strukturiert, geplant und abgewickelt werden konnten. Es ist dabei ein Rahmenwerk, innerhalb dessen, alle herkömmlichen Projektmanagement- Methoden erfolgreich angewandt werden können. Aufgrund der Unterschiede in der Charakteristik der „Agile Methods“ zu den herkömmlichen Methoden erscheint es aber nun fragwürdig, ob auch diese innerhalb eines nach SE strukturierten Projektes erfolgreich angewandt werden können. Dieser Artikel versteht sich als Aufforderung diesen Sachverhalt zu überprüfen. Weiters stellt er auch die Frage, ob das SE-Konzept selbst, als Methodik, zu starr ist und zuwenig Agilität für die Lösung der Probleme in der heutigen Welt bietet. Hierzu zeigt der Artikel bereits konkret einige Charakteristika des SEKonzepts auf, die durchaus agile Wesenszüge zeigen und solche, die eine agile Verhaltensweise zulassen, sie also zumindest nicht verhindern. Es wurden aber auch Widersprüche erkannt, die zwischen den Erfordernissen, welche die SE-Methodik an die Strukturierung eines Projektes stellt und den Erfordernissen der Agility stehen. Weitere Forschung soll hier zuerst klären, ob und wie weit es sinnvoll ist, das SE-Konzept an agile Erfordernisse anzupassen. Danach kann schrittweise überprüft werden, welche agilen Vorgehensweisen sich in der praktischen Anwendung als durchgängig erfolgreich erwiesen haben, um das SE-Konzept dahingehend anzupassen.

Reinhard Haberfellner, Dipl.-Ing. Dr.sc.techn. oUProf., Vorstand des Instituts für Unternehmungsführung und Organisation an der TU Graz Email: reinhard.haberfellner@tugraz.at Jahrgang 1942, Studium WirtschaftsingenieurwesenMaschinenbau an der TU Graz, Promotion an der ETH-Zürich. 1966 - 79 Unternehmensberater am Betriebswissenschaftliches Institut der ETH-Zürich.. Seit 1979 Prof. für Unternehmungsführung und Organisation an der TU-Graz. 1984 - 86 Dekan der Fakultät für Maschinenbau, 1987 - 89 Rektor der TU-Graz. 1995 für 5 Jahre beurlaubt und Vorstandsvorsitzender der STYRIA Medien AG. Ab 2000 zurück an der TU Graz. Autor von 5 Büchern und ca. 50 Fachartikeln. Forschungsinteresse: Unternehmungsstrategien, Erfolgsmerkmale, Systems Engineering.

Ernst Stelzmann, Dipl.-Ing., wissenschaftlicher Assistent am Institut für Unternehmensführung und Organisation an der TU Graz Email: ernst.stelzmann@tugraz.at Jahrgang 1979, Studium WirtschaftsingenieurwesenMaschinenbau an der TU Graz von 1999 – 2005 2006-2007: entwicklungsbegleitendes Qualitätsmanagement bei der Fa. Magna Powertrain in Lannach Seit März 2007: wissenschaftlicher Assistent, Forschungsschwerpunkt und Themengebiet für die Dissertation: „Agile Systems Engineering“

REFERENCES 1. Beck K. et al. 2001: Manifesto for Agile Software Development http://agilemanifesto.org/ 2. Boehm B. and Turner R. 2004: Balancing Agility and Discipline. A Guide for the Perplexed. Addison-Wesley, Boston 3. Haberfellner R. et al. 2002: Systems Engineering. Methodik und Praxis. Industrielle Organisation, 11. Auflage, Zürich 4. Haberfellner R. and de Weck O. 2005: Agile SYSTEMS ENGINEERING versus AGILE SYSTEMS engineering. Paper, presented at the INCOSE 2005 World Conference at Rochester NY 5. Spear and Bowen 1999: rigidly specified and highly adaptable. Harvard Business Review, 77(5) 97-106

WINGbusiness 3/2008

FACHARTIKEL

Stefan Grünwald

Software auf Knopfdruck Service orientierte Architekturen versprechen viel, aber was bleibt beim Anwender übrig?

1. Situation Service Orientierte Architekturen (SOA) sind in den letzten Jahren ein Trend im Entwickeln von (betrieblichen) Anwendungssystemen. SOA wird primär als Managementkonzept angesehen und erst sekundär als Methode zur Softwareentwicklung. Aus technischem Blickwinkel bietet SOA nichts neues, die Art der Softwareentwicklung ist von komponentenbasierter Entwicklung bekannt. Aus Managementsicht steht das Versprechen, Unternehmensstrategie, Geschäftsprozesse und IT-Systeme näher aneinander zu führen. Die Umsetzung der Strategie in Prozesse und letztlich in Anwendungssysteme ist ein komplexer Vorgang mit vielen organisatorischen Herausforderungen, weil unterschiedliche (Unternehmens-)Welten beteiligt sind: Top-Management, Fachbereiche, Organisation und Prozessmanagement sowie Informations- und Kommunikationstechnologie. SOA ist in diesem Kontext angesiedelt, aus bestehenden

Prozessen effizient ein betriebliches Anwendungssystem abzuleiten und Bedarf dynamisch Änderungen vorzunehmen (Abbildung 1). Ausgehend von den in einer Prozessmanagementsoftware modellierten Prozessen werden IT-gestützt technische Modelle (z. B. BPEL – Business Process Execution Language) abgeleitet, zusätzliche Modelle integriert (UML – Unified Modeling Language, Business Rules, etc.) und mit Services verknüpft (Abbildung 2). Services sind im Idealfall atomare, gekapselte Softwaremodule, die eine spezifische Aufgabe erfüllen (z. B. User Login). Nachdem die Geschäftsprozesse in technische Modelle übergeführt wurden, können die Prozesse als Workflows auf einem Applikationsserver veröffentlicht werden. 2. Vision Die Hersteller von Prozessmanagement- und Softwareentwicklungswerkzeugen schüren die Erwartungen der

Anwender und zeigen die Vorteile von Service Orientierten Architekturen in Idealtypischen Umgebungen auf. Die Vision dabei ist, dass nach dem modellieren der Prozesse und der Einbindung von standardisierten (Web-)Services die betriebliche Software auf Knopfdruck zur Verfügung steht. Ein wesentlicher Vorteil wird auch in der mehrfachen Verwendung von Services gesehen, also dass fachliche Funktionalität in Services implementiert wird und von verschiedenen Anwendungssystemen genutzt werden kann. SOA kann auch zu einer flexibleren ITLandschaft führen, wenn es gelingt ein Pool von Webservices aufzubauen und neue Anwendungen daraus zusammenzubauen. Die Zusammenstellung von Webservices geschieht in der Entwicklungsumgebung, d.h. es wird der technische Prozess (BPEL) mit Webservices verknüpft bzw. orchestriert. Damit wäre es möglich, auf dynamische Rahmenbedingungen, die eine Anpassung von Prozessen notwendig macht zu reagieren und die IT-Systeme effi-

WINGbusiness 3/2008

FACHARTIKEL zient nachzuziehen. Bei bestehenden heterogenen IT-Infrastrukturen kann durch SOA eine verbesserte Integration von Anwendungssystemen erreicht werden. Durch die Wiederverwendung von Code wird auch ein besserer Investitionsschutz gewährleistet. 3. Realität Neben den erwarteten Vorteilen gilt es im Praxiseinsatz jedoch einige Hürden zu überwinden. Auch wenn es in absehbarer Zeit möglich sein wird, Änderungen an Prozessmodellen automatisch in das Softwaredesign und auf die Anwendung überzuführen, ist es notwendig Gestaltungsrichtlinien für Prozesse zu entwickeln, die auch den Anforderungen hinsichtlich Detailierungsgrad und Verwendbarkeit für die technischen Prozessmodelle genügen. Dazu müsste ein Prozessdesigner auch Basiswissen über Softwareentwicklung haben bzw. Softwareentwickler Prozessmodellierungswissen aufbauen. Ein gangbarer Weg wird die Modellierung in Teams sein.

und brauchbare Geschäftsmodelle dazu fehlen noch. Es gibt zwar freie Webservices von Anbietern im Web (z. B. Amazon u. a.), jedoch spielen diese für Unternehmenssoftware keine große Rolle. Eine Welt mit global standardisierten Services ist für die nähere Zukunft unrealistisch.

Der Vorteil der Wiederverwendbarkeit von (Web-)Services wird in der Praxis dadurch eingeschränkt, dass es für betriebliche Anwendungen keine standardisierten Services gibt. Softwarehersteller haben wahrscheinlich kein Interesse daran, ihre Webservices zur freien Verfügung zu stellen

Aus technischer Sicht gibt es heute noch einige Schnittstellenbrüche im Entwicklungsprozess. Einige Anbieter von Prozessmanagementsoftware arbeiten zwar mit Softwareanbietern an Lösungen bei denen die Prozessmodelle und Softwaremodelle in einem gemeinsamen Datenbestand

Abbildung 1: Service Orientierte Architekturen im Business Systems Engineering Kontext abgelegt werden, jedoch gibt es noch kein praktikables Produkt, das einen offenen Entwicklungsprozess ohne Medienbrüche zulässt. Eine weitere Herausforderung an Technik und Design von SOA basierten Anwendungssystemen ist die Performance, die je nach eingesetzten Technologien und Ausmaß des Einsatzes von Services stark verbesserungswürdig ist. Ebenfalls gibt es noch einige Fragestellungen im Bereich der Sicherheit bei verteilten Softwaresystemen zu beantworten. Einerseits organisatorische Fragen, wie der Umgang mit unterschiedlichen User Identitäten, wenn ein Anwender von mehreren Applikationen Services bezieht, aber auch technische Sicherheitsfragen die bei global verteilten eventuell webbasierten Systemen auftreten. 4. Ausblick

Abbildung 2: Vom Prozessmodell zum Anwendungssystem

WINGbusiness 3/2008

Mit fortschreitenden Praxiseinsatz werden die Herausforderungen von Service Orientierten Architekturen weitgehend gelöst werden, ob jedoch zukünftige betriebliche Anwendungssysteme aus global zur Verfügung gestellten und standardisierten Services zusammengestellt werden können ist fraglich, weil wirtschaftliche Interessen von Softwareherstellern damit in Konflikt stehen. Vielleicht entwickeln sich neue Geschäftsmodelle, die gegen Entgelt Webservices für betriebliche Funktionen anbieten.

Fachartikel Autor Stefan Grünwald, DI Dr. techn. Studium Wirtschaftsingenieurwesen Maschinenbau TU Graz (1999). Er ist seit August 2006 an der Fachhochschule CAMPUS 02 am Studiengang Informationstechnologien und IT-Marketing als stv. Studiengangsleiter, Verantwortlicher für den Fachbereich Wirtschaftsinformatik sowie als Lektor tätig. Ab Jänner 2004 Leitung des Business Solutions Lab am Institut für Maschinenbau- und Betriebsinformatik. Von 2000 bis 2003 war er Universitätsassistent am Institut für Unternehmungsführung und Organisation an der TU Graz. Er verfasste seine Dissertation

über Internettechnik und Open Source Software und deren Einfluss auf die Strategie und das Geschäftsmodell von Unternehmen. Davor war er bei der Fa. UTA Telekom AG von 1998 bis 1999 in E-Business Projekten tätig. Dr. Grünwald ist Mitglied im Verband der österreichischen Wirtschaftsingenieure (WING), von 2000 bis 2002 als Geschäftsführer des Verbandes, wei-

Dipl.-Ing. Dr. techn. Stefan Grünwald FH CAMPUS 02

ters ist er Mitglied der Association for Computing Machinery (ACM) und der Arbeitsgemeinschaft für Datenverarbeitung (ADV).

WING-Organisation

ufgrund zahlreicher organisatorischer und personeller Änderungen beim WING, möchten wir

die Gelegenheit nutzen, Ihnen die WING-Regionalkreisleiter vorzustellen. Weitere Kontaktdaten erhalten

Sie unter www.wing-online.at, unter office@wing-online.at oder unter der Tel. Nr.: +43(0)316-873-7795

WING-Regionalkreisleiter

Titel Dipl.-Ing. Dr.

Vorname Rupert

Familienname Hasenöhrl

Funktion WING Kärnten

Dipl.-Ing. Dr.

Johann

Persoglia

WING Kärnten

Dipl.-Ing.

Florian

Rathner

WING Oberösterreich

Dipl.-Ing. Dr.

Gerhard

Wierer

WING Oberösterreich

Dipl.-Ing.

Franz

Schätz

WING Salzburg

Dipl.-Ing.

Thomas

Reuter

WING Salzburg

Dipl.-Ing.

Georg

Holzer

WING Steiermark

Dipl.-Ing. Dr.

Erich

Hartlieb

WING Steiermark

Dipl.-Ing. Dr.

Robert

Lackner

WING Tirol

Dipl.-Ing. Dr.

Johann

Hintner

WING Tirol

Dipl.-Ing.

Michael

Geiger

WING Vorarlberg

Dipl.-Ing.

Rudolf

Mayerhofer

WING Vorarlberg

Dipl.-Ing.

Alexander

Kainer

WING Wien

Dipl.-Ing.

Johann

Wappis

WING Niederösterreich

Dipl.-Ing. Dr.

Berndt

Jung

WING Niederösterreich

WINGbusiness 3/2008

Wingregional

Florian Rathner

Firmenbesuch bei der Firma MIBA Bearing Group Laakirchen, 08.07.2008

nfang 2008 haben Dipl.-Ing. Florian Rathner (Viessmann GesmbH) und Dipl.-Ing. Gerhard Wierer (Rosenbauer AG) die Geschicke des WING Regionalkreises in Oberösterreich von Dipl.-Ing. Harald Hagenauer (Post AG) und Dr. Clemens Honeder (MIBA AG) übernommen. Den ersten Höhepunkt ihrer Aktivitäten verdankten sie dann auch gleich ihrem Vorgänger Dr. Honeder, der zu einem Firmenbesuch bei der MIBA Bearing Group in Laakirchen einlud. In der modernen MIBA Academy berichtete Dr. Wolfgang Litzlbauer, CEO der MIBA Bearing Group über die Geschichte und die Erfolge des Unternehmens, dessen Geburtsstunde 1921 durch den Vater des heutigen Vor-

standsvorsitzenden Dr. Peter Mitterbauer schlug, und das sich bis heute zu einem weltweit tätigen Konzern entwickelt hat, der mit ca. 3000 Mitarbeitern 400 Mio. € umsetzt. Dr. Honeder, der als COO unter anderem den Standort Laakirchen verantwortet, führte die 15 Teilnehmer in die Welt der Gleitlager, insbesondere ihrer Produktion, ein.

Regionalkreises Oberösterreich einbrachten. Dieses Treffen wird vermutlich im November stattfinden, nähere Informationen werden rechtzeitig über den Newsletter bekanntgegeben.

Nach dem ausführlichen Produktionsrundgang rundete ein tolles Buffet die Veranstaltung ab, bei dem sich die Teilnehmer näher kennenlernten und Ideen für das nächste Treffen des Dipl.-Ing. G. Wierer, Dipl.-Ing. F. Rathner, RK-Leiter Oberösterreich

WINGbusiness 3/2008

Mediencorner Bauer-Wolf, St.; Payer, H.; Scheer, G.:

Erfolgreich durch Netzwerkkompetenz – Handbuch für Regionalentwicklung Springer Verlag, Wien 2008, 189 Seiten, € 59,95 ISBN: 978-3-211-73126-0

Netzwerke als soziale Systeme sind für die Steuerung regionaler Entwicklung unverzichtbar geworden. Regionale Netzwerke verbinden Personen, Projekte und Organisationen. Sie unterstützen den Erfahrungsaustausch zwischen Wirtschaft, Politik, Verwaltung, Interessensverbänden und BürgerInnnen und tragen wesentlich zur Lernfähigkeit und Innovationskraft von Regionen bei. Die Autoren berichten aus ihrer jahrelangen (inter)nationalen Erfahrungen und zeigen, wie man Entwicklungsprozesse und das gemeinsame Lernen in Netzwerken wirksam gestalten kann. Viele praxisnahe Beispiele helfen bei der Umsetzung. Eignung/Leserschaft Theorie Anwendung

1 (Anfänger) ooþoo 5(Experten) 1 (nicht behandelt) oþooo 5 (intensiv) 1 (nicht behandelt) oooþo 5 (intensiv)

Empfehlung: gute Arbeit, empfehlenswert

Caroline Riemer

Granig, P.:

Innovationsbewertung

Gabler Verlag Edition Wissenschaft VIII, Wiesbaden 2007, 238 Seiten, € 51,30 ISBN: 978-3-8350-0779-6 Die vorliegende Schrift zeigt auf, wie Erfolgspotentiale von Innovationsideen in einen nachhaltigen Unternehmenserfolg umgesetzt werden können. Dazu wird das Potential der Innovation in frühen Phasen bewertet und eine Selektion derjenigen Projekte geboten, die den Unternehmenserfolg maximieren. Es werden Methoden und Verfahren evaluiert, aber auch die Grenzen der Innovationsbewertung aufgezeigt. Granig liefert damit eine Entscheidungsgrundlage für den Abbruch von wenig Erfolg versprechenden bzw. für die Realisierung von Erfolg versprechenden Innovationsprojekten. Eignung/Leserschaft Theorie Anwendung

1 (Anfänger) oooþo 5(Experten) 1 (nicht behandelt) ooooþ 5 (intensiv) 1 (nicht behandelt) oooþo 5 (intensiv)

Empfehlung: gute Arbeit, empfehlenswert

Sonja Embst

Kremin-Buch, B.:

Internationale Rechnungslegung

Gabler Verlag, Wiesbaden 2002, 3. Auflage, 273 Seiten, € 24,90 ISBN: 3-409-31496-2 Wissen in internationaler Rechnungslegung ist für fast jede Kapitalgesellschaft heutzutage unumgänglich. Die Autorin geht Schritt für Schritt Bilanz und GuV durch und zeigt die wesentlichen Unterschiede, die sich von deutschem HGB zu IFRS und US-GAAP ergeben. Dieses Lehrbuch ist, obwohl auf deutsches Recht bezogen, trotzdem für Studierende aus Österreich geeignet, die sich intensiver mit internationalen Rechnungslegungsvorschriften beschäftigen wollen. Eignung/Leserschaft Theorie Anwendung

1 (Anfänger) ooþoo 5(Experten) 1 (nicht behandelt) ooooþ 5 (intensiv) 1 (nicht behandelt) ooþoo 5 (intensiv)

Empfehlung: erstklassig, sehr empfehlenswert

Bertram Gangl

WINGbusiness 3/2008

Mediencorner Matschke, M.J.; Brösel, G.:

Unternehmensbewertung

Gabler Verlag, Wiesbaden 2005, 713 Seiten, € 44,90 ISBN: 3-8349-0012-5 Dem Titel des Buches entsprechend ist es für Einkäufer in Unternehmungen gedacht. Werkzeuge, die den Alltag in einer Einkaufsabteilung erleichtern werden erläutert und mit Formularen bzw. Arbeitsblättern ergänzt. Der Autor gibt damit seine langjährige Erfahrung im Einkauf weiter. Theoretischer Hintergrund zu Strategie und Beschaffung werden leider nicht behandelt, was sich in der häufigen Vermischung von Einkauf und Beschaffung widerspiegelt. Alles in allem – ein Buch für Praktiker. Eignung/Leserschaft Theorie Anwendung

1 (Anfänger) oooþo 5(Experten) 1 (nicht behandelt) ooooþ 5 (intensiv) 1 (nicht behandelt) ooþoo 5 (intensiv)

Empfehlung: gute Arbeit, empfehlenswert

Bernd Zunk

Oldenburg, J.:

Lebensstrategien

DUV Verlag, Wiesbaden 2007, 209 Seiten, € 49,90 ISBN: 978-3-8350-6091-3 Der Autor zeigt in dieser Dissertation, wie sich das multikausale Phänomen Suizid, mit Hilfe des Sensitivitätsmodell Prof. Vester, einer systemischen Analyse unterziehen lässt. Mit dem dabei erstellten Simulationsmodell wurde ein Instrument geschaffen, das es Fachleuten erlaubt, verschiedenste Suizidszenarien zu simulieren und daraus gezielte Überlebensstrategien für Suizidgefährdete abzuleiten, um erstmals präventive Schritte ergreifen zu können. Neben einer detaillierten Abgrenzung des Untersuchungsgebietes werden auch die verwendeten Systemelemente und deren Beziehungen dargestellt. Auf eine exakte Erklärung der „qualitativen Quantifizierung“ der Systemelementbeziehungen wird dabei verzichtet. Eignung/Leserschaft 1 (Anfänger) ooþoo 5(Experten) Theorie 1 (nicht behandelt) oooþo 5 (intensiv) Anwendung 1 (nicht behandelt) oooþo 5 (intensiv) Empfehlung: gute Arbeit, empfehlenswert

Andreas Martischnig

Stock-Homburg, R.:

Personalmanagement

Gabler Verlag, Wiesbaden 2008, 737 Seiten, € 39,90 ISBN: 978-3-8349-0520-8 Die Autorin greift mit vorliegendem Buch die aktuellen Herausforderungen im Personalmanagement bedingt durch die Wandlung von einer rein administrativen Unterstützungsfunktion hin zum strategisch relevanten Unternehmensbereich auf und vermittelt in überaus anschaulicher und kompakter Weise die zentralen Grundlagen, Konzepte und Instrumente eines zeitgemäßen Personalmanagements. Eignung/Leserschaft Theorie Anwendung

1 (Anfänger) oþooo 5(Experten) 1 (nicht behandelt) oooþo 5 (intensiv) 1 (nicht behandelt) oooþo 5 (intensiv)

Empfehlung: gute Arbeit, empfehlenswert

WINGbusiness 3/2008

Bernd Zunk

Uninachrichten

Sonja Embst

Fachbereichsausflug 2008 Zotter Schokoladenmanufaktur

as Institut für Industriebetriebslehre und Innovationsforschung organisierte unter der Leitung von Frau Dipl.-Ing. Sonja Embst am 26. Juni 2008 eine Exkursion für die wirtschaftswissenschaftlichen Institute der TU Graz. Ziel des Ausflugs war die Süd-Oststeiermark.

das transparente Schokolade-Werk und begleiten den Herstellungsprozess von Schokolade. Die Einkaufsmöglichkeit im Zotter-Shop, die auch rege genutzt wurde, wurde durch persönliche Worte von

Josef Zotter zum Erlebnis. Es gab somit eine Möglichkeit, mit ihm persönlich zu plaudern. Seine vielfältigen Inspirationen gepaart mit unkonventionellen Innovationsideen beeindruckte eine große Zahl von Hörern.

Der Gründer des Unternehmens Zotter Schokoladen Manufaktur, Josef Zotter, hat sich seit den 90er Jahren der Produktion von Schokolade gewidmet. Mit Erfahrung, Kreativität und Geschmacksvision erfindet Zotter Schokolade in verschiedensten Geschmacksrichtungen. Im Schokolade-Theater bietet sich Gelegenheit, in die Schokoladewelt von Zotter einzutauchen und zu verkosten. Im Kakao-Kino werden erste Eindrücke über die Herkunft und lange Reise der Kakaobohnen vermittelt. Die anschließende Tour entlang der Produktionsstraße bietet Wissenswertes über die Schokoladeproduktion und vor allem viele Naschstationen. Die Teilnehmer wanderten auf gläsernen Pfaden durch

WINGbusiness 3/2008

Uninachrichten Die Fahrt führte weiter auf den nahegelegenen Felsen eines Vulkanberges, die Riegersburg. In nur 90 Sekunden beförderte uns der Schrägaufzug auf der Nordseite der Burg hinauf und wir konnten an diesem sonnigen Tage einen herrlichen Ausblick über die sanften Hügel mit den Weingärten der Süd-Oststeiermark genießen. Prof. Wohinz rundete mit einem geschichtlichen Überblick über die 850 Jahre alte Burg den interessanten Besuch ab. Bei einem herrlichen Blick auf die Riegersburg lud ein Buschenschank zum kulinarischen Genuss ein. Das üppige Buffet gespickt mit oststeirischen Köstlichkeiten hat neben der boden-

WINGbusiness 3/2008

ständigen steirischen kalten Jause auch warme Speisen geboten. Die gelungene

Exkursion fand ihren Ausklang mit einem Gläschen Wein.

presse-Info PRESSEINFORMATION Wien, am 12. September 2008 A1 bringt das Multimedia DVB-H Handy Nokia N96 A1 bringt das Nokia N96 auf den österreichischen Markt. Der multimediale Alleskönner vereint Mobile TV, schnelles Internet über HSDPA, eine 5 Megapixel Kamera und GPSNavigation in einem Gerät. Das Nokia N96 gibt es bereits in den nächsten Tagen mit dem neuen Tarif A1 TV PLUS ab 299 Euro. A1 TV PLUS bietet A1 Kunden 24 Fernseh- und fünf Radio-Kanäle um nur 9 Euro im Monat. In Kürze gibt es bei A1 sämtliche DVB-H Sender auch via UMTS-Streaming landesweit im besten Netz Österreichs. „Das Nokia N96 ist ein mobiler Alleskönner, der sämtliche Multimedia-Funktionen in hochwertiger Qualität vereint“, so Dr. Hannes Ametsreiter, Marketing-Vorstand mobilkom austria und Telekom Austria. Das Nokia N96 ist nicht nur TV-Gerät, sondern auch Kamera, Musikplayer, Minicomputer und Navigator. Es bietet über 16 GB Speicherplatz für beispielsweise 12.000 Musiktitel. Die hochwertige 5-Megapixel Kamera ist mit einer Optik von Carl Zeiss versehen und verfügt über Autofokus und automatische Belichtungssteuerung. Informationen zum Aufnahmestandort sind ganz einfach mit der Bilddatei zu speichern. Die Internetverbindung über HSDPA ermöglicht schnelles Suchen und Surfen im Web. Dank integriertem GPS-Empfänger ist das Nokia N96 auch A1 Navi-tauglich. Der multimediale Alleskönner ist in den nächsten Tagen in allen A1 Shops für Neu- und Bestandskunden ab 299 Euro erhältlich. Nur bei A1 kann das Nokia N96 bereits jetzt im A1 Online Shop bestellt werden. Fernsehen – immer und überall Mit dem neuen Nokia N96 steht A1 Kunden ab sofort ein Handy zur Verfügung, das mobiles Fernsehen sowohl über DVB-H als auch UMTS zum echten Vergnügen macht. Und das in herausragender Tonqualität und gestochen scharfem Bild am 2,8 Zoll großen Display. In Kürze sind für A1 Kunden sämtliche DVB-H Sender, also auch die deutschen Privatsender RTL, Pro7 und Sat1, über UMTS Streaming verfügbar. Damit ist nur bei A1 das gesamte DVB-H Fernsehangebot auch außerhalb des DVB-H Sendegebietes in HD Qualität in ganz Österreich abrufbar. Dank A1 TV Player noch bequemer am Nokia N96 fernsehen Die verbesserte Benutzeroberfläche des A1 TV Players steht auch am Nokia N96 kostenlos zur Verfügung. Mit dem A1 TV Player können A1 Kunden mit nur einem Tastendruck bequem am Handy fernsehen und zappen wie auf herkömmlichen TV Geräten. Um den kostenlosen A1 TV Player auf das Handy zu laden, muss lediglich das A1 TV Player Icon direkt im Hauptmenü angeklickt werden.

WINGbusiness Impressum Medieninhaber (Verleger) Österreichischer Verband der Wirtschaftsingenieure Kopernikusgasse 24/3, 8010 Graz ZVR-Zahl: 026865239 Editor Prof. Dr. Siegfried Vössner E-Mail: voessner@tugraz.at Redaktion/Layout Chefin vom Dienst & Marketingleiterin: Mag. Beatrice Freund Tel. +43 (0)316 873-7795, E-Mail: office@wing-online.at Redakteure Dipl.-Ing. Andreas Martischnig, E-Mail: andreas.martischnig@tugraz.at Dipl.-Ing. Iris Uitz E-Mail: iris.uitz@tugraz.at Dipl.-Ing. Markus Kohlbacher E-Mail: markus.kohlbacher@tugraz.at Dipl.-Ing. Hannes Fuchs E-Mail: hannes.fuchs@tugraz.at Dipl.-Ing. Sonja Embst E-Mail: sonja.embst@tugraz.at Dipl.-Ing. Dipl.-Ing. Thomas Reiter E-Mail: reiter@tugraz.at Anzeigenleitung/Anzeigenkontakt Mag. Beatrice Freund Tel. +43 (0)316 873-7795,E-Mail: office@wing-online.at Druck Medienfabrik Graz,Steierm. Landesdruckerei GmbH, 8020 Graz, Dreihackengasse 20 Auflage: 2.500 Stk. WING-Sekretariat Kopernikusgasse 24/3, 8010 Graz, Tel. (0316) 873-7795, E-Mail: office@wing-online.at WING-Homepage: www.wing-online.at Erscheinungsweise 4 mal jährlich, jeweils März, Juni, Oktober sowie Dezember. Nachdruck oder Textauszug nach Rücksprache mit dem Editor des „WINGbusiness“. Erscheint in wissenschaftlicher Zusammenarbeit mit den einschlägigen Instituten an den Universitäten und Fachhochschulen Österreichs. Der Wirtschaftsingenieur (Dipl.Wirtschaftsingenieur): Wirtschaftsingenieure sind wirtschaftswissenschaftlich ausgebildete Ingenieure mit akademischem Studienabschluss, die in ihrer beruflichen Tätigkeit ihre technische und ökonomische Kompetenz ganzheitlich verknüpfen. WING - Österreichischer Verband der Wirtschaftsingenieure ist die Netzwerkplattform der Wirtschaftsingenieure. ISSN 0256-7830

WINGbusiness 3/2008

B@E;<I G8K<EJ:?8=K<E Ohne Ihre Hilfe sind wir hilflos.

N<I;<E J@< G8K<#

jlggfik\[ Yp

;8D@K J@:? B@E;<I <@E< J:?{E< QLBLE=K 8LJD8C<E B{EE<E% NNN%G8K<EJ:?8=K<E%8K

@E=F ?FKC@E<1

'/'' //' )/'