Dienstag, April 29, 2008

Was ist ein System?


In der Informatik bleibt der Begriff des Systems seltsam unbesetzt. Begriffsprägungen aus der Elektrotechnik oder der Kybernetik lassen sich nicht so recht übertragen. Umso überraschender ist es, dass der Systembegriff des Soziologen Niklas Luhmann als Anregungsquelle taugt und sich überraschend gut mit Konzepten aus der Informatik füllen lässt. Hier ein Versuch interdisziplinärer Annäherung.

Niklas Luhmann war ein Sozialwissenschaftler, er hatte 30 Jahre die Professur für Soziologie an der Universität Bielefeld inne und starb 1998 im Alter von 70 Jahren. Er gilt als einer der Begründer der soziologischen Systemtheorie. Sein Lebenswerk galt der Entwicklung einer "Theorie der Gesellschaft", die er über mehrere Veröffentlichungen hinweg entwarf. Sein Werk ist immens und hat einen bleibenden Einfluss zum Verständnis gesellschaftlicher Systeme hinterlassen.

Luhmann interessierten soziale, psychische und biologische Systeme -- Systeme, die der Inbegriff des Lebendigen sind. Er nennt sie autopoietische, sich selbst erschaffende Systeme. Technische Systeme sind keine Systeme, so Luhmann. Eine Abgrenzung, die ich problematisch finde. Ich habe den Eindruck, dass sich Systeme, wie sie die Informatik erschafft, deutlich näher an der Luhmann'schen Systemdefinition orientieren, als man es auf den ersten Blick glauben mag,

Nach Luhmann definieren sich Systeme nicht aus Elementen und ihren Beziehungen. Das ist ein typisch technisches Systemverständnis, wie es besonders bei Ingenieuren sehr verbreitet ist. Systeme bestehen nicht aus Dingen oder Elementen, Systeme bestehen aus Operationen. Luhmann sagt: "Nur ein System kann operieren, und nur Operationen können ein System produzieren." (Zitat nach Berghaus 2004, S. 39). Durch das Operieren entsteht eine Differenz von System und Umwelt -- wir werden noch besprechen, was das meint. Ein System existiert nur, wenn es operiert. Einer Operation müssen weitere Operationen folgen bzw. folgen können. Das ist die Forderung nach der so genannten Anschlussfähigkeit eines Systems. Ein System muss sich also als operativ geschlossen darstellen.

Durch sein Operieren bildet das System eine Differenz aus, es erschafft sich ein Inneres in Abgrenzung zu einem Äußeren. Dieses Äußere nennen wir die Umwelt des Systems. Entscheidend ist, dass es das System selbst ist, das diese Unterscheidung durch sein Operieren macht. Gleichzeitig bildet diese selbst erzeugte Grenzziehung auch die Grundlage des Systems, seine Umwelt beobachten zu können. Jede Beobachtung ist Unterscheidung, und jede Unterscheidung ist Beobachtung. Wer beobachtet, differenziert, grenzt ab, unterscheidet.

Zu guter Letzt fordert Luhmann von Systemen die Fähigkeit zur Selbstreproduktion. Ein System muss selbst wieder etwas Operierendes hervorbringen können. Das ist die Autopoiesis eines Systems. Die Sprachwurzeln des Begriffs kommen aus dem Altgriechischen und sind leicht zu merken: "auto" wie in auto-matisch oder Auto-mobil heißt "selbst"; die "Poesie" ist im griechischem Wortsinne eine "Erschaffung". Autopoiesis ist also die "Selbsterschaffung".

Ich möchte dieses Systemverständnis in Bezug auf soziale, psychische und biologische Systeme hier nicht ausbreiten, das würde zu weit führen. Wer sich genauer dafür interessiert, dem sei das Buch von Margot Berghaus empfohlen: "Luhmann leicht gemacht", Böhlau-Verlag, 2. Auflage, 2004. Von Luhmann selber ist die "Einführung in die Systemtheorie", herausgegeben von Dirk Baecker, Carl-Auer-Verlag, 4. Auflage, 2008, für einen Laien einigermaßen verständlich.

Fassen wir zusammen, was Luhmann als System definiert:

  • Ein System entsteht durch Operationen.

  • Einer Operation müssen Operationen folgen (können); sonst hört das System auf zu operieren, sprich zu existieren.

  • Durch die Operation wird eine Differenz, eine Unterscheidung erzeugt, durch die sich das System von einer Umwelt abgrenzt.

  • Die Differenzbildung begründet und beschränkt die Fähigkeit, die Umwelt beobachten zu können.

  • Systeme sind autopoietisch, d.h. sie können sich mit ihren Operationen selbst reproduzieren.


Das alles scheint schwer verständlich und kryptisch. Dennoch ist die Nähe zu Konzepten aus der Informatik auffällig. Starten wir einen Versuch, die Luhmann'sche Begriffswelt mit Informatik-Konzepten aufzuladen.

Jedem Informatiker ist der Begriff der Operation vertraut. Eine Operation ist ein atomarer Verarbeitungsschritt. Ein Beispiel ist die Ausführung eines Maschinenbefehls.

Um ein System durch Operationen entstehen zu lassen, muss eine Folge von Operationen irgendwann zu einer Operation führen, die bewirkt, dass es einen Rücksprung zu einer bereits ausgeführten Operation gibt. Der Fluss der Operationen muss zu einem Zirkelschluss führen, damit das System operativ bleibt. Denn nur durch andauerndes Operieren entsteht ein System. Wir wollen diesen geschlossenen Kreislauf von Operationen einen aktiven Prozess nennen. Den Begriff des Prozesses kennen sie zum Beispiel aus der Welt der Betriebssysteme.

Die Operationen des aktiven Prozesses greifen notwendigerweise auf Speicherinhalte zu -- ansonsten passiert nichts Spannendes. Mit anderen Worten, ein aktiver Prozess ist mit einem endlichen Satz an Zuständen und Zustandswerten assoziiert. Darüber entsteht die Differenz zur Umwelt. Alles, was nicht zu den Operationen und zu dem Zustandsraum eines Prozesses gehört, ist die Außenwelt des Prozess-Systems. Der Zustandsraum ist sozusagen der verinnerlichte Teil einer Rechenwelt in den Grenzen eines abgeschlossenen Flusses von Operationen.

Das schließt nicht aus, dass ein anderer Prozess ebenso dieselben Speicherinhalte bzw. Zustände verinnerlicht. Vielmehr sind diese geteilten Bereiche die einzige Möglichkeit zur Kommunikation von Prozessen untereinander. Die Veränderung des Werts einer gemeinsamen Speicherzelle ist Mitteilung einerseits und Beobachtung andererseits. Prozesse können auf diese Weise Informationen austauschen. Wir nennen solch eine geteilte Domäne eine Schnittstelle oder ein Interface. Ein Interface ist kein System!

Wie Sie sehen, führt der abgeschlossene Fluss von Operationen zu einer Assoziation mit einem Speicherbereich und damit zu einer Abgrenzung vom Rest des Speichers. Teilen sich abgeschlossene Operationsflüsse Speicherbereiche, dann kann diese Gemeinsamkeit zur Kommunikation genutzt werden. Das alles ist in Einklang mit der Systemdefinition nach Luhmann!

Prozesse können derart angelegt werden, dass sie sich selbst zu kopieren vermögen. Ist ihnen über eine Operation die Fähigkeit gegeben, einen separaten Fluss von Operationen auf der Kopie in Gang zu setzen, dann hat sich das Prozess-System reproduziert! Prozesse können, sofern sie eine Operation zur Initiierung eines eigenständigen Operationsflusses haben, als autopietisch bezeichnet werden.

Das wird einem Luhmann und vielen anderen Systemtheoretikern sicher widerstreben. Denn Autopoiesis wird als auszeichnendes Merkmal lebender Systeme verstanden. Es scheint auch intuitiv nicht einleuchtend, ein Informatik-System als lebendig zu bezeichnen. Andererseits muss eine Definition des Lebendigen eine klare Aussage machen, was genau das Lebendige vom Nicht-Lebendigen unterscheidet, und dies in einer Weise tun, die durchaus auch den Raum lässt, von Menschenhand geschaffene Systeme eines Tages als lebendig zu klassifizieren.

Dienstag, April 15, 2008

Lidl und der Kassen-Bug


Es gibt Fehler, im Informatiker-Jargon "Bugs", die etwas anrühriges haben. Ich bat den Menschen an der Kasse bei Lidl um einen Moment Geduld und meine Kinder um Ruhe, um nicht den wunderbaren Moment zu verpassen, bei dem es passierte. Der Lidl-Mensch fluchte kurz auf -- und ich war entzückt! "Einen Moment, davon muss ich ein Foto machen!" Und dann machte ich noch eines.

Ich bin heute extra für diesen Fehler zu Lidl gepilgert -- ich wollte es mit eigenen Augen sehen. Gestern hat mir ein Student (vielen Dank Herr Breyer) von diesem Fehler in einer EMail berichtet. Ein richtig schöner Fehler, ein Klassiker geradezu. Ein Fehler, den man selten zu Gesicht bekommt, so einer mit Museumswert. Dafür wäre ich sogar noch weiter gereist als bis zum nächsten Lidl.

Der Fehler tritt auf, wenn Sie an der Kasse Waren im Wert von 0 Euro (Null Euro) bezahlen. Dann streikt das System. Die kurze Einkaufsliste dazu: Geben Sie zwei Pfandflaschen zurück und Lidl steht mit 50 Cent bei Ihnen in der Kreide. Zu dem Pfandzettel, den Ihnen der Automat ausspuckt, besorgen Sie sich eine Wasserflasche (19 Cent plus 25 Cent Pfand macht 44 Cent) und begehen die Umweltsünde und greifen nach einer Einkaufstüte für 6 Cent. Ab zur Kasse damit. Minus 50 Cent plus 50 Cent machen 0 Cent bzw. 0 Euro. Rien ne va plus!

Herrlich, die Kasse streikt und ruft nach "Autorisierung". Wie Sie auf dem rechten Bild sehen, hat die Schlange hinter mir gleich das Weite gesucht. "Das kommt so einmal im halben Jahr vor", erfuhr ich vom Kassierer.

Ich habe im Netz einen Blogeintrag gefunden, der belegt, dass der Fehler mindestens seit Mitte November 2007 bekannt ist (Alphawinkel.de: "Der tägliche Blödsinn: Lidl und die Kasse", 13. Nov. 2007). Vermutlich tritt der Fehler zu selten auf, als dass Lidl ein schnelles Bug-Fixing für nötig erachtet.

Das Faszinierende jedoch ist, dass dieser Fehler überhaupt auftritt. Warum hat man bei der Programmierung des Kassensystems diesen einfachen Testfall übersehen? Haben Sie oben beim Lesen kurz gestockt, als ich schrieb

Der Fehler tritt auf, wenn Sie an der Kasse Waren im Wert von 0 Euro (Null Euro) bezahlen.


Haben Sie für einen Moment gedacht "Wie soll das denn gehen"? Dann sind wir der Ursache schon auf der Spur. Wir selbst mit unseren eingefahrenen Denkmustern sind das Problem.

Die Kunst des Testens ist, Grenzfälle möglich zu machen, nicht sie für unmöglich zu halten.

[Nachtrag: Lesen Sie auch auf den Denkspuren: "Ist der Kassen-Bug von Lidl ein Bug?"]

Kleinprojekte und ihre Kosten


Was in Büchern zum Software-Projektmanagement gerne übergangen wird, sind die Kleinprojekte. Vielleicht, weil das Management von Kleinprojekten als trivial angesehen wird. Dabei sind es die Kleinprojekte, von denen es so zahllos viele gibt.

Als Kleinprojekt definiere ich ein Vorhaben, das beim Auftragnehmer von ein bis fünf Personen abgewickelt wird, das wenige Wochen bis einige Monate dauert und in der Regel den Auftraggeber ein paar Tausend bis wenige Zehntausend Euro kostet.

Das Tagesgeschäft von vielen Kleinunternehmen ist geprägt von Kleinprojekten. Freiberufler müssen sich immer wieder auf Kleinprojekte einlassen. Der Schritt in die Selbstständigkeit bedeutet für viele die Abwicklung unzähliger Kleinprojekte -- ein Leben von der Hand in den Mund mit geringen Gewinnspannen. Und viele Informatik-Studierende versuchen, sich mit Kleinprojekten (oder auch Kleinstprojekten) ein Zubrot zu verdienen. Grund genug, sich mit dieser Sorte von Projekten einmal genauer zu befassen.

Diese Woche habe ich in der Projektmanagement-Vorlesung eine Fallstudie besprochen. Ein reales, kleines Softwareprojekt, an dem ich auch beteiligt war bzw. bin -- es steht kurz vor dem Abschluss. Ich habe dazu die Projekthistorie aufgerollt und mich dabei ausschließlich auf die spannende Phase vor der eigentlichen Software-Entwicklung konzentriert, die ich hier Vor-Entwicklungsphase nenne. Es geht also um die Zeit, in der mit dem Kunden diskutiert, überlegt, gebrütet und gelöst wird -- bis man verstanden hat, worum es eigentlich geht und was entwickelt werden soll. Mögliche Resultate sind Anforderungsdokumente, Konzeptpapiere, Prototypen und ein Vertrag bzw. ein Auftrag zur eigentlichen Entwicklung, sprich zur Realisierung der ausgereiften Idee. Diese Phase ist mit Aufwendungen und mit Kosten verbunden. Wissen Sie, wie hoch die Kosten da liegen? Haben Sie eine ungefähre Vorstellung wie der Kostenverlauf über die Zeit aussieht und mit welchem Kostenverhältnis der Kunde rechnen darf?

Zur Fallstudie. Damit Sie eine grobe Vorstellung haben, es geht inhaltlich um eine webbasierte Anwendung mit einer relationalen Datenbank dahinter. Technisch unspektakulär, etwas, was in aller Welt immer wieder entwickelt wird. Am Ende wird sich herausstellen, dass die Softwarekonzeption samt prototypischem Datenbankschema durch ein sechsseitiges Dokument ausreichend dokumentiert ist. Es handelt sich also tatsächlich um ein "richtiges" Kleinprojekt. Dennoch ist erstaunlich, welcher Aufwände es bedarf, um von dem Kundenanliegen zu dieser klaren Dokumentation zu gelangen.

Ich habe Folgendes zur frühen Projektphase aufgelistet: Wann gab es Treffen, was war der Anlass, wer war vom Kunden, wer vom Auftragnehmer dabei? Und: Wann wurde ein Resultat (in der Regel ein Dokument oder ein Prototyp) rausgegeben? Wer war an der Erstellung wie lange beteiligt -- und wen hat es wie viel Zeit zum "konsumieren" (lesen, verstehen, ausprobieren) gekostet? Ich habe dann noch auf der Kunden- wie auf der Auftragnehmerseite zwei Rollen unterschieden: einmal die Personengruppe, deren Zeit mehr kostet (Leitungsfunktionen, Manager, Koordinatoren) und die Gruppe, deren Zeit weniger kostet (Entwickler, Tester, technische Schreiber). Mit der Zuordnung möchte ich niemanden diskriminieren, sie spiegelt nur grob die Kostenverteilung wieder, wie wir sie in der Realität antreffen. So ungenau das ist, es hilft uns, einen Eindruck zu gewinnen.

Übrigens habe ich mit Tiefstpreisen gerechnet: Die "Billigen" kosten 50 Euro die Stunde, die "Teuren" doppelt so viel. Das dürfen Sie gerne im Kopf nach oben korrigieren. (Bevor Sie unglückliche Mutmaßungen anstellen: Ich habe in dem Projekt unentgeltlich gearbeitet, meine Arbeitskraft in der Modellrechnung jedoch monetär berücksichtigt.) Zeitaufwände habe ich aus dem Gedächtnis rekonstruiert, da ich keine zuverlässigen Aufzeichnungen dazu habe, und bin mit meinen Schätzungen sehr sportlich vorgegangen. Sportlich heißt auch hier, dass ich mit Minimalaufwänden gearbeitet habe, die real in den meisten Fällen höher liegen dürften.

Die Ergebnisse: In der Historie der frühen Projektphase habe ich in einem Zeitraum von 5 Monaten (Juli bis Dezember 2007) 13 Termine bzw. Ereignisse erfasst. Davon sind 6 Termine Besprechungen (4 Vis-a-Vis, 2 Telefonkonferenzen) und 7 Termine markieren den Versand eines entscheidenden Dokuments, entweder als Neuerstellung oder als Update. Die mit diesen Terminen bzw. Ereignissen assoziierten Kosten belaufen sich für den Kunden auf etwa 1600 Euro, für den Auftragnehmer auf 4300 Euro.

Ich finde das sehr beachtlich. Der Kunde muss als Auftraggeber etwa 6000 Euro ausgeben, einzig um sein Anliegen in dieser Projektphase zu kommunizieren, zu reflektieren, zu diskutieren, zu revidieren, zu konkretisieren und zu präzisieren. In der Zeit hat der Auftragnehmer noch keinen einzigen Euro verdient! Er hat diesen Prozess lediglich gemeinsam und in Kooperation mit seinem Kunden durchlaufen und zu einem Resultat getrieben, der dann erst den Startpunkt für die konkreten Entwicklungsaktivitäten eines Softwareprodukts bildet.

Ich halte übrigens die Kostenanteile meiner Erfahrung nach für relativ typisch, kann dies allerdings nicht durch Fakten aus anderen Projekten belegen. Das Verhältnis liegt bei etwa 2:5. Von 7 Anteilen, die der Kunde für diese Projektphase ausgeben muss (6000 Euro durch 7 macht ca. 850 Euro), muss der Kunde seine eigenen Kosten etwa mit 2 Anteilen (die 1600 Euro, gleich etwa 2 Mal 850 Euro) veranschlagen, die für den Auftragnehmer mit 5 Anteilen (4300 Euro).

Interessant ist zu beobachten, wie die Kostenentwicklung über die Zeit aussieht. Die Analyse der 13 Termine bzw. Ereignisse zeigt, dass für den Kunden die Aufwände am Anfang liegen. In den ersten Treffen werden viele Mitarbeiter vom Kunden involviert (das kostet viel), was am hohen Diskussions- und Klärungsbedarf liegt. Der Auftragnehmer hingegen hat die ganze Zeit über relativ gleichbleibende Aufwände: er muss am Ball bleiben und seine Arbeit im Hintergrund machen. Die Erstellung etwa eines Prototypen ist nicht unaufwendig. Für die weitere Abstimmung und Klärung beschäftigt der Kunde nun nur noch eine Person, die die Verantwortung für das Projekt trägt.

Ich habe diesen Kostenverlauf etwas überzeichnet in dem Bild oben in rot eingetragen. Die Verteilung der Kosten beim Kunden verläuft über die Zeit wie ein sich zuspitzendes Dreieck; die Aufwände werden zunehmend geringer. Beim Auftragnehmer zeigt das langgezogene Rechteck die Konstanz der Kosten an. Bringt man beide Kostenanteile zusammen, sieht man den Verlauf der Gesamtkosten.

In dem Bild habe ich darüber hinaus in grau den Kostenverlauf für das Projekt eingetragen, wie er sich qualitativ für die sich anschließende Entwicklung des Softwareprodukts und seiner Einführung beim Kunden ergeben hat. Während der Entwicklung entstehen für den Kunden kaum Kosten -- er wartet auf das Produkt. Mit der Fertigstellung nimmt der Aufwand für den Kunden wieder zu: Die Abnahme des Produkts muss durchgeführt werden und die mit der Einführung des Produkts verbundenen Schulungen boosten die Kosten noch einmal.

Der Auftragnehmer hat während der Entwicklungszeit relativ konstante Kosten. Ein, zwei oder drei Entwickler werden in dieser Zeit in Kleinprojekten oft beschäftigt. Ist das Produkt fertig, halten die Aufwände noch kurz an, um eventuelle Korrekturen oder kleinere Änderungen durchzuführen, sie nehmen dann aber ab.

Es ist nicht aus zeichnerischen Gründen so, dass die Vor-Entwicklungsphase so lange dauert und die eigentliche Entwicklungszeit so kurz ist. Ist das Anliegen des Kunden einmal geklärt und erfasst, kann die Entwicklung recht zügig abgewickelt werden. Aber es kann dauern, bis das Anliegen hinreichend gut verstanden und aufgearbeitet ist; in diesem Fall hat sich das auf ganze 5 Monate verteilt.

Wo kann der Auftragnehmer eigentlich seine Gewinne einrechnen? Kaum in der Vor-Entwicklungsphase, denn hier geht es darum, Unsicherheiten abzuarbeiten und Klärung herzustellen. Es ist schwer kalkulierbar, wie viele Termine dazu ausreichen werden, wenn man das Kundenanliegen noch nicht einmal verstanden hat. Das ist ja genau das Merkmal dieser frühen Phase: vieles ist unklar, unscharf, uneindeutig, unausgesprochen. Hier geht es lediglich darum, kostendeckend zu arbeiten. Ein Grund, warum diese Phase gerne aufwandsorientiert abgerechnet wird -- nur wollen das die Auftraggeber für Kleinprojekte meist nicht tun, da ihnen ein Verständnis für die Problematik dieser Vor-Entwicklungsphase fehlt. Denn in ihren Augen geht es ja nur um diese kleine Sache, dieses kleine Projekt, das ja eigentlich klar ist. Außerdem neigt ein Auftraggeber zur Blindheit gegenüber seinen eigenen, internen Kosten in dieser Phase (das Dreieck), da diese für Kleinprojekte selten klar abgerechnet werden. Veranschaulicht man sich noch einmal den Kostenverlauf beim Kunden, scheint es durchaus verständlich, dass Kunden nach dem Initialaufwand wenig interne Kosten "spüren". Das Gefühl des internen Kostenverlaufs wird auf den Auftragnehmer projiziert.

Erst nach der Vor-Entwicklungsphase kann gut kalkuliert werden. Ein gemeinsames Verständnis des Kundenanliegens liegt vor, die Angelegenheit ist planbar geworden. Ergo wird der Auftragnehmer hier beginnen, seine Gewinnmargen einzurechnen. Ich habe das durch die schraffierten Bereiche markiert. Allerdings ist aufgrund der Kürze der Entwicklungszeit die Marge nicht sehr "lange" ausschöpfbar -- auch ein Merkmal von Kleinprojekten. Kommen nur ein, zwei, drei ungeplante Entwicklertage hinzu, weil etwa der Kunde auf einer Nachbesserung besteht oder, viel simpler, ein Entwickler krank ist, dann steht das Kleinprojekt für den Auftragnehmer bereits kurz vor der Verlustzone. Wesentlich ertragreicher und noch besser kalkulierbar sind Schulungsmaßnahmen beim Kunden. Nur bedarf nicht jedes Softwareprodukt einer Schulung.

Wie Sie vielleicht anhand dieser Ausführungen erahnen, sind Kleinprojekte ein taffes Unterfangen, die den Auftragnehmern nicht viel Gewinne schenken. Reich wird damit keiner. Es macht auch klar, warum viele Unternehmungen scheitern, wenn sie nicht den Sprung in die Klasse der mittelgroßen Projekte bis Großprojekte schaffen, dort sind die Gewinnmargen größer.

Wenn Sie Ihre Erfahrungen mit Kleinprojekten teilen möchten, ich freue mich auf Ihre Kommentare. Können Sie meine Fallstudie bestätigen? Oder haben Sie andere Erfahrungen mit Kleinprojekten gemacht?