Hier die restlichen Kapitel des dritten Teils. Was ich früher als „Auswahlprozess“ bezeichnet habe, heißt jetzt „Interaktion mit Vorschlägen und Abfragen“.
https://marcusmeindel.files.wordpress.com/2020/10/03_swk_konfigurationsprozess.odt
Wenn die Kapitel bestätigt wurden und ich jemanden für die Rechtschreib- und Grammatikkorrektur gefunden habe, können wir das zeitnah veröffentlichen. Und den Entwicklern zukommen lassen, da das doch recht wichtig ist für die bevorstehende Aufgabe.
Interaktion mit Vorschlägen und Abfragen
Durch das ununterbrochenen Commoning können einander unbekannte Menschen miteinander kooperieren, um gemeinsam ihre jeweils eigenen Bedürfnisse zu befriedigen. Im → Konfigurationsprozess werden hierfür von Seiten der Software Tätigkeiten vorgeschlagen und sowohl Mittel als auch Wissen abgefragt. Die Beteiligten ihrerseits können mit diesen Vorschlägen und Abfragen entsprechend interagieren, wodurch schließlich ein Zusammenspiel von Tätigkeiten mit einer hohen Effizienz entstehen kann, die auf die Bedürfnisse der Beteiligten abzielt und sich nach ihren Fähigkeiten und Interessen richtet. Diese Interaktionsmöglichkeiten werden im ersten Unterkapitel vorgestellt und notwendige Funktionen zur Orientierung im zweiten.
Interaktionsmöglichkeiten
Vorgeschlagenen Tätigkeit en können von Beteiligten ignoriert, abgelehnt, gemerkt oder auf einer Skala zwischen Lust und Notwendigkeit angenommen werden . Eine Auswahl, die einem „ich habe große Lust und will der Tätigkeit unbedingt nachgehen“ entspricht, würde etwa eine sofortige Zuordnung nach sich ziehen und falls sich jemand einer ‚idealeren‘ Tätigkeit zuordnen sollte, würde diese Selbstzuordnung nicht einfach ins Leere laufen, sondern es könnte ein Kommunikationsraum zwischen beiden Beteiligten entstehen. Auf diese Weise kann diskutiert werden, ob die Konfiguration sich nach der Lust der Beteiligten richtet oder der spekulativ geringeren Gesamtdauer. Eine Selbstzuordnung zu einer Tätigkeit, die „ich habe keine Lust, aber würde es machen, wenn es nicht anders geht“ entspricht, würde nach sich ziehen, dass das entsprechende Tätigkeitsmuster zur Selbstzuordnung weiter offen bleibt. Falls es dann wirklich keine andere Möglichkeit gibt – also Alternativen etwa sehr viel zeitintensiver wären und sich auch niemand anderes mit mehr Lust dafür findet – kann die Selbstzuordnung bestätigt werden und der Konfigurationsprozess an dieser Stelle weiterlaufen. Eine Selbstzuordnung zu Tätigkeiten, denen sich nicht aus Lust angenommen wird, zieht dabei eine höhere → zugeschriebene Anerkennung nach sich.
Nachdem sich einer Tätigkeit angenommen wurde und bevor die darauf folgenden Tätigkeiten vorgeschlagen werden, muss geklärt werden, welche Mittel zur Ausführung der Tätigkeit tatsächlich verfügbar sind. Zwar richtet sich der Konfigurationsprozess selbst danach, welche Mittel im lokalen Kontext und den jeweiligen konkreten Personen zur Verfügung stehen und baut sich demnach auf, allerdings ist das beschränkt auf die Informationen, auf welche die Software zurückgreift. Vielleicht wird ein Werkzeug benötigt, das zwar in keiner Mitteldatenbank eingespeist ist, aber die Person, welche sich der Tätigkeit annimmt, hat private Kontakte oder kennt andere Strukturen, wie sie das Werkzeug besorgen kann. Oder die Person hat Werkzeug angegeben, das ihr zur privaten Verfügung steht, allerdings stellt sich heraus, dass es erst repariert werden müsste usw. usf. Wichtig ist nur: Die Informationen der Software müssen mit der tatsächlichen Verfügbarkeit abgeglichen werden, bevor der Konfigurationsprozess weiterläuft.
Bei der Mittel-Abfrage gibt es zwei Kategorien von Interaktionsmöglichkeiten. Innerhalb der ersten Kategorie wird abgefragt, ob die entsprechende Person über das Mittel verfügt („habe ich bzw. kann ich drauf zugreifen“) bzw. über das Mittel nicht verfügt („habe ich nicht bzw. kann ich nicht drauf zugreifen“). Falls die Person darüber verfügt muss entschieden werden, ob das Mittel commonifiziert, also aus dem privaten Eigentum als Gemeingut in die Commons-Struktur überführt werden soll oder ob es privates Eigentum bleibt, aber für das Commoning verwendet werden kann. Die erste Option, die Überführung von privaten Eigentum, kann eine höhere → zugeschriebene Anerkennung bringen als das reine zur-Verfügung-stellen . Bleibt das Mittel privates Eigentum müssen außerdem → Nutzungsbedingungen mit angegeben werden, also ob etwa andere es ebenfalls verwenden dürfen, in welchem Zeitraum dafür nachgefragt werden soll etc. pp.
Bei der zweiten Kategorie der Mittel-Abfrage wird versucht herauszustellen, wie selbstverständlich es ist, im jeweiligen lokalen Umfeld über das Mittel zu verfügen („hat man“) oder ob es sehr unwahrscheinlich ist, dass irgendjemand über so ein Mittel verfügt („hat man nicht“). Diese Abfrage ist äußerst wichtig zur Abstimmung der Software, die ohne diese Funktion gleichermaßen abfragen würde, ob Beteiligte über einen ‚Hammer ‘ oder etwa einen ‚mit Kette bespannten Webstuhl‘ verfügen. Wenn sich dabei etwa herausstellt, dass es üblich ist einen ‚Hammer‘ zuhause zu haben, dann wird vorausgesetzt, dass das Mittel mit hoher Wahrscheinlichkeit verfügbar ist und Tätigkeiten, die diesen Hammer als Bedarf angegeben haben, können im lokalen Umfeld vorgeschlagen werden, auch wenn die Verfügungsmöglichkeit über einen Hammer von Beteiligten nicht vermittelt wurde. Genauso kann sich herausstellen, dass es im lokalen Umfeld sehr unwahrscheinlich ist, dass jemand über einen ‚mit Kette bespannten Webstuhl‘ verfügt und dieses Mittel würde daher nicht länger bei Beteiligten abgefragt werden.
Abgefragtes Wissen ist entweder verfügbar oder nicht-verfügbar , wobei hier relevant ist, ob eigenes Wissen, das verfügbar gemacht werden könnte, schon von einer anderen Person vermittelt wurde. Der wohl einfachste Weg das herauszufinden ist es vor der Beschreibung der Tätigkeit deren Bedarf anzugeben und Bedarf plus Resultat mit bestehenden Tätigkeitsmustern abzugleichen. Damit dieser Prozess sinnvoll funktioniert, müssen Mittel entsprechend kategorisiert sein (→ Mittel-Muster ). Wird ein neues Tätigkeitsmuster hinzugefügt, das von vielleicht noch keinem oder wenigen Beteiligten angewendet wurde, kann die Person, welche es eingespeist hat, als Betreuerin* des Tätigkeitsmusters agieren und bei Rückfragen zur Verfügung stehen, wenn etwa etwas unscharf beschrieben ist oder sich Probleme bei der Ausführung ergeben. Tätigkeitsmuster müssen daher auch entsprechend bewertet werden können, wie hoch die Qualität ihrer Beschreibung ist.
Persönliche Vorauswahl und Transparenz
Werden Tätigkeiten vorgeschlagen bzw. werden Mittel und Wissen abgefragt, dann sind diese Vorschläge bzw. Abfragen immer allgemein und an alle Beteiligten gerichtet. Die Vorschläge und Abfragen haben eine ihnen zugeschriebene Lokalität und sollten unabhängig von der persönlichen Vorauswahl durchsucht werden können; was etwa über Listen, Karten oder Diagramme möglich sein sollte. Viele dieser Vorschläge und Abfragen werden allerdings für konkrete Personen nicht relevant sein, da Tätigkeiten etwa Qualifikationen voraussetzen, die sie nicht besitzen oder Mittel abgefragt werden, bei denen sie bereits angegeben haben, nicht darüber zu verfügen. Die ‚persönliche Vorauswahl‘ ist daher ein Werkzeug, dass eine Auswahl nach eigenen Fähigkeiten und Interessen unterstützt.
Warum Tätigkeiten und Abfragen die in die persönliche Vorauswahl aufgenommen werden kann verschiedene Gründe haben. Die meisten davon sind durch die Beteiligten selbst definierbar: Ein Grund kann sein, dass es sich um Tätigkeiten handelt, die sich auf Tätigkeitsmuster beziehen, welche in der Bibliothek (→individueller Musterspeicher) der beteiligten Person auf eine Weise markiert wurde, die ausdrückt, dass die Person sich der Tätigkeit wieder annehmen würde. Dann spielt selbstverständlich der Standort der Person eine Rolle und in welchem Umkreis bzw. Gebiet sie tätig werden möchte. Weiter haben Vorschläge und Abfragen eine → Wichtigkeit und Beteiligte sollten einen Schwellwert einstellen können, ab welcher Wichtigkeit eine Tätigkeit oder Abfrage in der persönlichen Vorauswahl erscheint. Ebenfalls eine Schwelle ist die notwendige Qualifikation zur Ausführung einer Tätigkeit – ist diese nicht vorhanden, sollte die Tätigkeit nicht in der persönlichen Vorauswahl erscheinen. Nur teilweise von den Beteiligten regulierbar sind ihre Verfügungsmöglichkeiten über Mittel. In der persönlichen Vorauswahl erscheinen Vorschläge teilweise nur, weil über bestimmte Mittel verfügt wird und es sinnvoll wäre, wenn diese konkrete Person sich der Tätigkeit annimmt (→ Konfigurationsprozess: Vorschlag von Tätigkeiten: Bedarfsdeckung) .
Die Tätigkeiten sollten den Beteiligten dabei anhand ihrer → Fähigkeiten angezeigt werden. Fähigkeiten, zur kurzen Erinnerung, sind in der Bibliothek gespeicherte Tätigkeitsmuster, die als verinnerlicht markiert wurden. Wenn mehrere Tätigkeitsmuster ineinander verschachtelt sind, wird von einem komplexen Tätigkeitsmuster gesprochen, dessen Aufwand gleich dem gesamten Aufwand der einzelnen Tätigkeitsmuster ist, die es enthält. Würde sich im Konfigurationsprozess herausstellen, dass bestimmte einfache Tätigkeiten nacheinander die aktuell geringste spekulative Gesamtdauer haben und gäbe es für diesen Teil der Konfiguration auch ein komplexes Tätigkeitsmuster, welches diese Tätigkeiten umfasst, dann sollte den Beteiligten mit entsprechenden Fähigkeiten das entsprechende komplexe Tätigkeitsmuster angezeigt werden. Beteiligte können sich so größeren zusammenhängenden Teilen der Konfiguration am Stück zuordnen.
Anders, aber damit zusammenhängend, sollten auch nachfolgende Tätigkeiten denjenigen angezeigt werden, die sich den Tätigkeiten angenommen haben, die sie notwendig machen. Falls die entsprechende Person sich auch dort zuordnen würde, entfällt der Aufwand von Kommunikation und ggf. Ortsveränderung. Außerdem kann abgefragt werden , ob es sinnvoll ist ein komplexes Tätigkeitsmuster zu erstellen, welches die beiden Tätigkeitsmuster umfasst, welche durch den Konfigurationsprozess bzw. die Plankonfiguration zusammengeführt wurden.
Bei jedem Vorschlag und bei jeder Abfrage soll dabei auch der jeweilige Kontext sichtbar werden – also: „Welchen Zweck hat die Tätigkeit bzw. warum wird dieses Mittel oder Wissen benötigt“? Wenn die Möglichkeit auch nicht wahrgenommen wird, so muss es doch unbedingt möglich sein, diesen Zweck herauszufinden. Nur so kann das Vertrauen entstehen, dass jede einzelne Tätigkeit im ununterbrochenen Commoning direkt auf die Befriedigung von Bedürfnissen abzielt . Die Angabe der Wichtigkeit muss überprüft werden können. Die Antwort auf die Frage, warum ‚Tätigkeit [ x ] als wichtiger angegeben wurde als Tätigkeit [y]‘ muss im Sinne der allgemeinen Bedürfnisbefriedigung klar erkennbar und nachvollziehbar sein. Und falls es zwar erkennbar, aber nicht nachvollziehbar ist – etwa, weil bestimmten Faktoren ein höheres Gewicht zugeschrieben wird, als es für einen selbst richtig erscheint – dann muss der → soziale Prozess von dort aus leicht erreichbar sein, in welchem die Gewichtung dieser Faktoren festgelegt wurde.
Weiter braucht es eine Transparenz über die Beteiligten der Kooperation insofern die jeweilig gewünschte Privatsphäre nicht überschritten wird. Es sollte daraus hervorgehen, 1. welche Personen sich ebenfalls derselben Tätigkeit zugeordnet haben und mit denen sich schließlich zur Ausführung abgesprochen werden muss. 2. Mit wem kooperiert wird, also wer die Mittel verfügbar macht, die für die eigene Tätigkeit benötigt werden, wer die verwendeten oder betroffenen Mittel wieder in ihren Erhaltungszustand zurückführt und wer das Resultat der eigenen Tätigkeit braucht. Und 3. wen die Tätigkeit betrifft , was etwa bei der gemeinsamen Nutzung von Gemeingut der Fall sein kann oder bei der Verwendung von privaten Mitteln anderer Personen. Diese Transparenz sollte bereits vor einer Zuordnung da sein, während die entsprechenden → Kommunikationsräume besonders nach der Zuordnung wichtig werden.
Nach der Selbstzuordnung oder der Verfügbarmachung von Mitteln und Wissen muss der Fortschritt des Konfigurationsprozesses für die daran beteiligten Personen transparent sein. Es soll dadurch abschätzbar werden, ob die eigene Tätigkeit, die eigenen Mittel oder das eigene Wissen benötigt werden und es soll die verbleibende Zeitdauer bis zur → Festsetzung der Konfiguration ebenfalls abschätzbar werden, indem ersichtlich ist, welche Mittel noch nicht verfügbar sind bzw. noch Tätigkeiten zur Verfügbarmachung nach sich ziehen werden.
Festsetzen einer Konfiguration
Nach dem Festsetzen einer Konfiguration beginnt die Kooperation . Und eine Konfiguration kann erst dann festgesetzt werden, wenn der Konfigurationsprozess – zumindest in dem Strang, welcher festgesetzt werden soll – abgeschlossen ist, wenn also jeder Bedarf einer jeden Tätigkeit in dieser Konfiguration entweder verfügbar ist oder verfügbar gemacht werden kann und sich auch zu jeder unaufschiebbaren Tätigkeit zur (Wieder-)Herstellung des Erhaltungszustandes verwendeter und betroffener Mittel jemand zugeordnet hat.
Ist ein Konfigurationsprozess abgeschlossen, werden alle beteiligten Personen, die sich Tätigkeiten zugeordnet haben, benachrichtigt, ob sie für den Prozess benötigt werden oder nicht, oder anders herum ausgedrückt, ob ihre Selbstzuordnung ins Leere lief oder nicht. Nachdem die Beteiligten bestätigt haben, dass sie an der nachfolgenden Kooperation mitwirken werden, werden die Werkzeuge zur Kommunikation mit den Beteiligten und Betroffenen, zur Absprache und Transparenz von (Übergabe-)Zeiten oder auch zur gemeinsamen Raumfindung relevant. Ein weiteres Softwarewerkzeug kann dabei helfen, private freie Zeit der Beteiligten mit der Verfügbarkeit gesellschaftlicher Mittel abzugleichen und Vorschläge zum Ablauf möglicher Prozesse bereitstellen.
Es gibt dabei drei Sonderfälle zum Thema Selbstzuordnung und Abschluss des Konfigurationsprozesses:
Selbstzuordnung zu tendenziell unproblematischen Tätigkeiten: Die Dauer eines Konfigurationsprozesses ist unbestimmt, genauso wie der anschließende zeitliche Ablauf der Kooperation. Und über jede Person und jede neue Tätigkeit in der Konfiguration wird die Planung komplizierter. Es kann daher sinnvoll sein, Tätigkeiten erst nach der Festsetzung der Konfiguration und damit während der Kooperation vorzuschlagen, wenn sich erfahrungsgemäß/statistisch leicht jemand dafür findet.
Selbstzuordnung zu Ortsveränderungen zwischen Tätigkeiten in lokaler Nähe: Ein ähnlicher Punkt als wie zuvor, allerdings ein struktureller Unterschied. Erst nachdem der Raum der Ausführung feststeht kann ersichtlich werden, ob es noch jemanden zusätzlich braucht, der oder die das Resultat der einen Tätigkeit zum Ausführungsort der nächsten Tätigkeit ortsverändert, sprich: transportieren muss. Bei Ausführungsorten in lokaler Nähe könnte das auch zwischen denen geklärt werden, die die Tätigkeit ausführen und es muss keine zusätzliche Tätigkeit als Vorschlag an andere vermittelt werden. Falls eine solche Tätigkeit in den Konfigurationsprozess gespeist wird und es nicht tendenziell unproblematisch ist, dass sich jemand dafür findet, kann die Konfiguration erst festgesetzt werden, wenn sich hierzu jemand zugeordnet hat. Es braucht also eine zeitnahe Absprache zwischen den Beteiligten nach der Selbstzuordnung und noch während des laufenden Konfigurationsprozesses.
Selbstzuordnung zu aufschiebbaren Tätigkeiten zur (Wieder-)Herstellung von Erhaltungszuständen: An sich ist eine Konfiguration erst abgeschlossen, wenn sich zu sämtlichen Tätigkeiten, welche die Bedürfnisbefriedigung nach sich zieht, Personen zugeordnet haben. Tätigkeiten allerdings, die durch Nebenresultate notwendig werden, beziehen sich eben nicht direkt auf das vermittelte Bedürfnis und sind zur Bedürfnisbefriedigung auch nicht notwendig. Falls die entsprechenden Tätigkeiten also aufschiebbar sind oder das Nebenresultat die Tätigkeit nur anteilig notwendig macht, kann die Konfiguration festgesetzt werden, bevor sich dort jemand zugeordnet hat.
Von den Tätigkeiten ausgehend, bei denen jeder Bedarf zur Verfügung steht, wird kooperiert bis der Zweck des Commonings sich erfüllt hat, das vermittelte Bedürfnis also befriedigt wurde, und die Konfiguration sich damit wieder auflöst. Im Fall von → Kontinuität können einzelne Tätigkeiten dabei natürlich weiterbestehen, da sie gleichzeitig Teil anderer Konfigurationen sind.
Es ist dabei durchaus möglich, dass sich in er praktischen Anwendung der Software dynamischere und effizientere Möglichkeiten zur Festsetzung von Konfigurationen finden.
Reparaturprozess
Während über den Konfigurationsprozess (Plankonfigurationen eingeschlossen) neue Konfigurationen entstehen, werden im Reparaturprozess bestehende Konfigurationen verändert. Der Reparaturprozess ist die ständige Möglichkeit bestehende Konfigurationen an die realen, sich stetig verändernden Umstände anzupassen.
Warum braucht es einen Reparaturprozess?
Der Reparaturprozess ist aus mehreren Gründen zentral, von denen nur einige folgend ausgeführt werden:
Ausgleich der Zufälligkeiten im Konfigurationsprozess: Da zusätzliche Tätigkeiten vorgeschlagen werden, wenn sich zu den bereits vorgeschlagenen Tätigkeiten in einem bestimmten zeitlichen Abstand niemand zuordnet hat, haben die entstehenden Konfigurationen immer auch einen zufälligen Charakter. Ganze Stränge zur Bedarfsdeckung können entstehen, nur weil eine Person zu einem bestimmten Moment nicht die Möglichkeiten ihrer Beteiligung geprüft und somit eine Tätigkeit verpasst hat, an der sie eigentlich interessiert gewesen wäre. Eine solche Tätigkeit könnte einen ganzen (eventuell sehr aufwendigen) Strang zur Bedarfsdeckung unnötig gemacht haben.
Lösungsfindung bei Unzuverlässigkeit oder Verhinderung: Jemand kann sich einer Tätigkeit zugeordnet und diese auch nach dem Konfigurationsprozess bestätigt haben, geht anschließend der Tätigkeit aber entweder nicht oder nur auf problematischer Weise nach. Problematisch kann hier eine nicht abgesprochene Zeitverzögerung bedeuten oder auch eine mangelnde (sinnlich-funktionale) Qualität des Resultates. Der Reparaturprozess soll helfen Lösungen für solchen Situationen zu finden. Im Falle von Unzuverlässigkeiten können →Sanktionen notwendig werden, um solche Störungen abzumildern.
Lokale Verdichtung zusammenhängender kontinuierlicher Tätigkeiten: Es kann sich herausstellten, dass einige Tätigkeiten im immer gleichen Zusammenhang kontinuierlichen bestehen bleiben und so Stabilität gewährleisten. Da sowohl die Auswahl der Tätigkeiten sowie die Auswahl der Lokalitäten tendenziell unabhängig voneinander stattfinden, kann es sinnvoll werden, solche Tätigkeiten „zusammenzuziehen“. Es geht also darum, möglichst dauerhafte Orte zu schaffen, in denen Tätigkeiten, deren dauerhafter Zusammenhang sich durch die Vermittlung von Bedürfnissen und dem Prozess der Selbstzuordnung ergibt, möglichst nahe zusammengehalten werden, um lange (und damit entsprechend aufwändige) Transportwege zu vermeiden und spontane Absprachen zu erleichtern.
Effizientere gemeinsame Nutzung von Mitteln: Es kann sich etwa herausstellen, dass dasselbe Mittel von unterschiedlichen Personen an unterschiedlichen Orten verwendet wird und es, wenn es sich zum Beispiel um eine schwerere Maschine handelt, sinnvoll wäre, die Lokalität einer Tätigkeit statt die Lokalität des Mittels zu verändern. Oder es stellt sich heraus, dass zwei Tätigkeiten auf zwei gleiche Mittel zurückgreifen und eines von beiden gemeinsam verwendet werden kann, wodurch das zweite weiter für andere Tätigkeiten (falls es sich um ein gesellschaftliches Mittel handelt) offen ist.
Ä nderung bei den Verfügungsmöglichkeiten : Das kann bedeuten, dass entweder eingeplante Mittel doch nicht verwendet werden können (weil sie anderweitig benötigt werden oder ihr Zustand unerwartet problematisch ist) oder dass neue Mittel zur Verfügung stehen und damit auch neue Konfigurationen zur Bedürfnisbefriedigung möglich werden. Ein besonderer, aber wesentlicher Fall hierbei ist die Diskrepanz zwischen Software-vermittelter und nicht-Software-vermittelter Zwecksetzung von Mitteln . Ein → sozialer Prozess zur Verwendung von Gemeingütern kann nicht die am Commoning Beteiligten ausschließen, die diese Software nicht verwenden. Nicht an der Software-Vermittlung Beteiligte müssen in diesen sozialen Prozess mit einbezogen werden und es braucht Kommunikationsmöglichkeit der über die Software getroffenen Absprachen nach außen. Und genauso können Gemeingüter außerhalb der Software-Vermittlung eingeplant worden sein, was den an der Software-Vermittlung Beteiligten unbekannt ist in der anschließend Kooperation wieder zu Störungen führt. Einerseits braucht es Funktionen, wie solche nicht-Software-vermittelten Absprachen möglichst einfach zur Software „durchdringen“ können, anderseits – und das ist an dieser Stelle alleine relevant – muss es über den Reparaturprozess möglich werden mit solchen Situationen umzugehen und eventuell alternative Möglichkeiten zu finden, vermittelte Bedürfnisse trotzdem zu befriedigen.
Werkzeuge des Reparaturprozesses
Sehr wichtig zum Verständnis des Reparaturprozesses ist: Der Reparaturprozess ist nicht ein Werkzeug bzw. eine Methode, wie es etwa der Konfigurationsprozess ist. Der Reparaturprozess ist die Anwendung einer Vielzahl von Werkzeugen, um bestehende Konfigurationen den Bedürfnissen von Beteiligten und Betroffenen anzupassen. Wie die Auflistung an Situationen, in welchen ein Reparaturprozess notwendig sein kann, nicht vollständig sein kann, ist es auch die folgende Auflistung an möglichen Werkzeugen nicht.
Sehr relevant dabei sind diverse automatisch ablaufende Analysen , durch welche die Struktur selbst immer wieder aufs Neue danach überprüft wird, wie sie effizienter gemacht werden könnte. Das heißt, es muss automatisch geprüft werden, welche neuen Konfigurationen möglich werden, wenn neue Mittel zur Verfügung stehen und wie die bestehenden Konfigurationen dahingehend verändert werden müssen. Weiter muss überprüft werden, welche kontinuierlichen Transportwege (gleiche Ortsveränderungen immer gleicher Mittel) es gibt, um Konfigurationen lokal zu verdichten. Es muss automatisch überprüft werden, inwiefern sich geänderte →Nutzungsbedingungen von Mitteln auf kontinuierliche Tätigkeiten auswirken. Es muss die lokale Umgebung überprüft werden, wo derselbe Bedarf durch unterschiedliche Tätigkeiten gedeckt wird und sich unterschiedliche Konfigurationen also (früher) vereinigen lassen, womit der Gesamtprozess dichter und damit auch stabiler werden kann. Und selbstverständlich muss immer wieder geprüft werden: Welche Selbstzuordnungen zu welchen Tätigkeiten wären notwendig, damit Konfigurationen effizienter werden könnten?
Neben den automatischen Prozessen, muss der Reparaturprozess aber auch bewusst angestoßen werden können. Alles was die Software an Vorschlägen hervorbringen kann, ist effizient innerhalb der Kategorien, in denen die Software arbeiten kann. Was ihr vollständig verborgen bleibt ist alles menschliche. Wer lernt sich vielleicht über die Kooperation im ununterbrochenen Commoning kennen und möchte lokal nahe zusammen tätig sein? Welche Tätigkeiten fühlen sich gut an , auch wenn sie den verarbeitbaren Informationen nach vielleicht nicht effizient sind? Wo entsteht vielleicht Lärm und damit die Notwendigkeit, entweder die ganze Konfiguration oder die Lokalität bestimmter Tätigkeiten zu verändern? Wie der Planungsprozess ist auch der Reparaturprozess ein Werkzeug, um gegen die vorgegebene Richtung des Konfigurationsprozesses arbeiten zu können.
Wichtig dabei ist, dass bei Änderungen der Struktur alle davon Betroffenen mitreden können1 und es entsprechende Strukturen zur Klärung gibt (→ Kommunikationsstruktur ). Grundlegend dabei ist es als beteiligte Person einstellen zu können, bei welcher Art von Änderung eine Benachrichtigung erfolgen soll bzw. die eigene Meinung unbedingt gehört werden soll bzw. welcher Art von Änderungen sich schlicht gefügt wird. Ob es schließlich zu Änderungen kommt, wie diese aussehen und wie vorgegangen wird, um diese zu erreichen, ist schließlich wieder eine Frage des → sozialen Prozesses. Durch die Werkzeuge des Reparaturprozesses sollen lediglich mögliche Änderungen zur Effizienzsteigerung herausgestellt und getroffene Entscheidungen umgesetzt werden können. Die Umsetzung der Änderung kann teils über →Konfigurationsprozess vonstatten gehen.