Service Desk – Wer ist zu motivieren?

In einem gewöhnlichen IT Betrieb, der sich nie sonderlich auf Dokumentation konzentriert hat, sind die Dinge genau so entstanden wie sie nützlich waren. Es wird in allen Teams unterschiedlich dokumentiert. Meist zu wenig, selten komisch, aber nie gar nichts.

Der Junior-Administrator hat auf jeden Fall auf die Finger bekommen, nachdem er einen Server gepatched hat und keinen Eintrag im changelog.txt gemacht hat. Sein älterer Kollege hat bei der Fehlersuche den Patch gar nicht im Blick gehabt und erst woanders gesucht. Nun bekommt der Junior Admin einen Anschiss und das Administratoren-Handbuch auf den Tisch geknallt. Das Administratoren-Handbuch ist eine E-Mail aus dem Jahr 2003. Entschuldigung nicht 2003, es wurde 2012 ergänzt und mit größerem Verteiler versehen.

Was ich sagen will, egal wie schlecht es um Dokumentation steht, es gibt einen Anfang, gefühlte Verantwortlichkeiten sowie hie und da Mitarbeiter die sich schon gekümmert haben. Aber lasst uns mit den Verantwortlichen beginnen.

Control heißt Steuern

Im ersten Teil dieser Serie bin ich kurz auf die Dokumenthierarchie eingegangen, wie sie im Service Delivery Management benannt bzw. aus der Governance heraus definiert wird. Hieraus ergeben sich die Verantwortlichkeiten für einzelne Dokumentklassen. Das funktioniert auch ganz prima, eine entsprechende RACI-Matrix ist schnell gebaut.

In der Praxis finden sich hier zwei Extreme: Die Verantwortung wird entweder so hoch wie möglich geschoben oder fällt flach auf die unterste Ebene. Das heißt das rechenschaftspflichtige „Accountable“ bekommen Personen, deren alltägliche Praxis weit weg von dem eigentlichen Geschehen ist. Selbst wenn das richtige Team durchführungsverantwortlich „Responsible“ ist, findet keine wertsteigernde Überwachung statt. Oder eben im anderen extrem bekommen Mitarbeiter ein „Accountable“ zugewiesen, die eine solche Verantwortung gar nicht übernehmen (können).

Ein sinnvolles Steuerungssystem muss alle Akteure einbinden und die Steuerung auf zwei unterschiedliche direkt involvierte Parteien aufteilen. Am Besten wechselseitig, damit kooperativ gearbeitet und nicht nur einseitig Kritik geübt wird. Beispiel:

  • Das Fachteam prüft und lektoriert bestimmte Workinstructions des Service Desks
  • Der Service Desk prüft und lektoriert die Workinstructions eines Fachteams

Es mag eingewandt werden, dass in obigem Beispiel der Service Desk eventuell gar nicht die Fachlichkeit hat, die Arbeitsanweisung des Fachteams bis in die letzte Schraube zu prüfen. Bei einem Lektorat geht es gar nicht darum dem Fachmann auf gleicher Höhe zu begegnen. Vermutlich kann ein langjähriger Service Desk Mitarbeiter sehr gut fachlich prüfen. Wichtig sind Vollständigkeit, Richtigkeit, einheitliche Ebene und andere Dokumenteigenschaften, aber vor allem auch die Gesamtheit der Dokumente zu einem Bereich.

Für die Leitung des Service Managements ist übrigens die qualitative Steuerung dieser Kooperation und die quantitative Steuerung der Resultate ein „A/R“ in der RACI-Matrix sinnvoll. Das gilt übrigens insbesondere in einer Organisation auf niedrigem Reifegrad. Wenn Teams dazu neigen sich zu beschimpfen, sind hierarchische Kontrollsysteme kontraproduktiv.

Shift to the Left

Oft auftretende Fälle sollen im Support möglichst von der Einheit gelöst werden die dem Endanwender am Nächsten ist, wenn nicht gar via Portal und Automatismus von dem Endanwender selbst. Ein sehr gesundes Verhältnis ist, wenn jede Support-Einheit 70% der Vorfälle, von all dem was rein kommt, lösen kann.

Nehmen wir 4.000 aufgenommene Tickets im Monat, so sollte der Service Desk davon 2.800 davon lösen und somit 1.200 an 2nd-Line-Einheiten weitergeben, 2nd-Line sollte 360 Tickets an 3rd-Linie weitergeben. Dieser Daumenwert passt eigentlich sehr gut. Wenn dem nicht so ist, liegt es meist an fehlendem „Shift to the Left“ und nur sehr selten an speziellen Konstellationen, wie z.B. hohem Automatisierungsgrad oder vielen Business Transaktionen am IT Service Desk.

Eine funktionierende Abgabe von Wissen an eine niedrigere Support Einheit ist ein Geben und Nehmen. Diese Zusammenarbeit muss etabliert werden und ist gerade am Anfang von Projektleitung und Management zu hegen und zu pflegen. Fangen wir mal mit dem Nehmen an. Ein guter Service Desk fordert regelmäßig Wissen an.

  • Nur häufige Fälle lohnen sich weit vorne abgearbeitet zu werden. Komplexität ist hierbei nicht relevant
  • Störungen mit schweren Auswirkungen werden oftmals nicht rechtzeitig erkannt, hier fehlen ggf. Analyseregeln oder -mittel
  • Tickets mit häufigen Nachfragen der Endanwender sind Kandidaten die weit vorne gelöst werden sollten
  • Tickets, die zwischen den Support Einheiten hin- und hergeschoben werden, sollen bessere Templates und Vorgaben bekommen

Werden diese Fälle von den Fachteams oder beim Service Management gefordert

  • Muss das Fachteam eine grobe aber vollständige Anleitung entwerfen ggf. komplexe Abläufe verschlanken oder automatisieren. Zusammen mit dem Service Desk wird diese dann vervollständigt, getestet und beidseitig genehmigt.
  • Falls möglich kann das Fachteam dem Service Desk Analysemittel oder Skripte zur Verfügung stellen. So ein Skript muss nicht vollständig sein, sondern kann auch geregelte Kommunikation sein „Prüfe A, B, C und dann ruf uns an“.
  • Häufige Nachfragen von Anwendern kosten der IT und dem Unternehmen bares Geld. Oft müssen problematische Konstellationen wie langatmige Workflows oder sinnlos hoch angesiedelte Genehmiger angegangen werden.
  • Ping-Pong-Tickets fehlt es oft an Information, zusammen mit allen Fachteams sollte ein Konzept von Incident-Templates erarbeitet werden. So können dem Endanwender zu der Störung (einer Kategorie) 2-5 Fragen gestellt werden, die den Fall systematisch eingrenzen. Fehlt eine zusätzliche Information muss sich ein Fachteam verantwortlich kümmern und nicht einfach so weiterleiten.

Selbstverständlich können auch Fachteams Wissen aktiv nach Links schieben. Wichtig ist immer gegenseitig die Rolle und Leistungsfähigkeit zu verstehen. Service Desk Agenten sind keine Administratoren und Administratoren sind keine Ausputzer für einen überlasteten Service Desk. Genauso wie der Service Desk die Operations vor Banalitäten schützt und die Operations diesen Schutzschirm ausbauen hilft.

Abholen, Bitten, Charisma, Druck

Nun kommen wir zu einem Teil, der nur schwer in einem Blog-Artikel erklärt werden kann: Wie sind Individuen zu fördern, zu nutzen oder simpel in den Hintern zu treten? Wichtige Erkenntnis: die Motivation der Mannschaft ist aktive Arbeit.  Ein aufklärendes PowerPoint, eine strenge Mail und Delegation an Teamleiter haben noch nie geholfen.

Haben alle verstanden worum es geht? Was ist an dem jetzigen Zustand nicht optimal? War die Zusammenarbeit in der Vergangenheit falsch? Warum reicht das was die Teams heute liefern nicht aus? Ist das neue System eine Art Bürokratie für die ISO 9001?

Selbstläufer sind diese Projekte nie. Es geht darum Teamgrenzen zu überbrücken, Menschen eine bestimmte Art von Kommunikation beizubringen und auch bisheriges Handeln in Frage zu stellen. Ein solches Projekt benötigt hochrangige Aufmerksamkeit und Projektarbeiter die etwas davon verstehen.

  • Es wird Mitarbeiter geben, die nicht gern ihr Wissen teilen, z.B. weil sie um Verlust von Anerkennung bzw. Job fürchten. Aber auch hier finden sich Beispiele aus der Vergangenheit in denen lästige Aufgaben abgegeben wurden. Vielleicht ist das ein Anküpfungspunkt für einen positiven Aspekt.
  • Es wird Mitarbeiter geben, die in der Vergangenheit länglich und ausführlich zu Störungen Stellung genommen haben, sei es in der Kaffeeküche oder im Ticket-Tool. Hier könnte sich ein Tandem anbieten, ein Service Desk Mitarbeiter versucht im Dialog daraus mehrere Wissensartikel zu produzieren, der technische Mitarbeiter Anleitungen für sein Team oder gar Automatisierungsskripte.
  • Es gibt Mitarbeiter, die tun genau das was man ihnen sagt und das gar nicht mal schlecht. Damit das Thema Dokumentation nicht von Teammitgliedern verdrängt wird, vereinbart man z.B. eine bestimmte Zeit oder eine bestimmte Quote an (überarbeiteten) Artikeln pro Woche.
  • Nörgler und „Früher war alles Besser“ kann man eventuell mit einem Bewertungssystem begegnen, dass frühzeitig Entstörungen mit Fakten belegt oder gar die Qualität der Wissensartikel bewertet.

Auf jeden Fall braucht so ein Projekt eine Ist-Analyse, wie die Teams, ihre Mitarbeiter und ihre Führungskräfte ticken. Intelligente Führungskräfte, die nichts von dem Projekt halten, werden das Projekt um Monate aufhalten. Hier hilft Überzeugungsarbeit, Messen und Vergleichen. Wenn all dies nicht hilft, muss ein Projektleiter mindestens dieses Team anleiten.

Vergiftende Ideen

Gerade um schnell vorzeigbare Verbesserungen zu erzielen hilft es erfahrene Berater mit ins Boot zu holen, die wie eine technische Redaktion nach 80:20-Methode technische Artikel aus den Teams abluchsen und diese schnell auf professionellen Stand bringen. Die Idee einer Fachredaktion führt jedoch dazu, dass die technischen Fachteams sich in der Rolle als Zuträger von Information wohlfühlen und alle Aktivitäten rund um die Erstellung von Wissensartikeln gar nicht im Detail kennenlernen möchten.

Die hohe Geschwindigkeit der externen Fachredaktion wird ihr übriges dazu beitragen, dass die Fachteams allerlei Gründe finden für schnödes Wissensmanagment keine Zeit zu haben.

Gegenmaßnahme ist, dass die Berater ihr Wissen frühzeitig weitergeben und die Fachteams ausbilden. Es muss sichergestellt sein:

  1. Das die Fachteams die Arbeitsweise lernen
  2. Selbstständig üben
  3. Durch Korrektur der Fachredaktion im Prozess und Ergebnis vollständig und in der gewünschten Qualität liefern
  4. Den Prozess und die Anforderungen selber an weitere Kollegen weitergeben

Insbesondere der letzte Schritt ist wichtig, um die Qualität langfristig zu erhalten. Die Berater können hierzu gegebenenfalls nach 3-4 Monaten wiederkommen.

Eine weitere Art von Gift ist Bereiche die Kooperation benötigen, hierarchisch lenken zu wollen. Erfahrene neu eingestellte Mitarbeiter im Service Desk, kennen sich bei der Wissenserstellung prima aus. Dies und ähnliche Gründe verleiten dazu, die Verantwortung zur Wissenerstellung dort einem Kernteam zu übertragen.

Typischerweise versiegt die Zulieferung von technisch höherrangigen Fachteams sehr schnell. Beziehungsweise diese liefern zu abstrakte, unmotivierte Informationen wie Hinweise auf Wissensdatenbanken von Herstellern. In Summe sind sie sind nicht verantwortlich für das erarbeiten von Wissen und haben ihre Pflicht getan.

Das Kernteam ist nun mit einer unlösbaren Aufgabe betraut. Während sich ein Fachmann auf das Niveau eines Agenten einstellen kann, da er selbst mal Anfänger war, ist es andersherum nahezu unmöglich. Ein Agent muss sich erst einiges an Fachwissen aneignen um dann einen relativ simplen Fall zu dokumentieren. Das ist verschwendete Zeit und Dilettantismus.

So ein Konzept funktioniert nur, wenn beide Teams für die Kooperation verantwortlich sind . Beide müssen die selben Auf- und Abbauziele für Wissensartikel haben, beide müssen gemeinsam zu Readaktionssitzungen erscheinen. Je nach sozialer Ausgangslage empfehlen sich Management-Paten die Fachwissen mitbringen. In der IT Operations findet sich der ein oder andere kürzlich beförderte Abteilungsleiter mit einem soliden Fachwissen, der in Streitfragen vermitteln kann, insbesondere wenn darum gestritten wird welches Wissensniveau von jeder Partei verlangt wird.

Falls sich kein interner Vermittler findet, sollte auch hier ein externer Berater hinzugezogen werden. Dokumentation ist ein pragmatischer Prozess, der nicht mal eben so zum laufen kommt.

Knowledge Management ist kein Prozess

Recht häufig finde sich in dem Konvolut der IT Service Management Dokumentation auch ein Knowledge Management Prozess Diagramm. Wenn es gut gemacht ist, sogar gefolgt von Prozedur-Diagrammen, das sich um Detailabläufe kümmert. Der Knowledge Management Prozess ist dann meist so eine Art Anforderung-Lektorat-Freigabe-Ablauf. So etwas hat aber gar nichts mit Wissensmanagement zu tun. Knowledge Management ist kein Prozess.

Während das auslösende Ereignis bei Incident Management in 95% der Fälle eine Störung ist, fällt es bei Knowledge Management schon schwieriger was denn das Hauptereignis ist, das den Prozess startet. Es muss irgendwas mit fehlendem Wissen zu tun haben.

Gehen wir mal von der Annahme aus, dass eine IT Organisation funktioniert, egal wie viel Verbesserungspotential Knowledge Management heben kann. Dann gab es in der Vergangenheit keine (oder viel zu wenige) Anlässe sich um Wissensverbesserung zu kümmern.

Der erste Ansatz bei Knowledge Management ist diese Anlässe zu schaffen. Ohne diese Anlässe wird auch die beste Dokumentation nicht weiterentwickelt.

Bei einem sehr gut etablierten Knowledge Management werden, die wenigsten Anlässe zur Nachpflege reaktiv erfolgen. Diese gibt es: Wie etwa eine Überprüfung eines Artikels nach Ablauf seiner Gültigkeit oder ein Mitarbeiter stellt fest, dass ein Artikel nicht mehr korrekt den Ablauf beschreibt. Viel wichtiger ist es jedoch nach und nach eine Organisation zu schaffen, die Freude am lernen und kontinuierlicher Verbesserung hat.

Bei dem finden und festlegen von auslösenden Ereignissen für das Knowledge Management, sollte eher experimentiert als festgeschrieben werden. Ganz simpel: Auch die deutlichste Vermutungen in einem Bereich massiv Wissen steigern zu können, sollte eine Zeitlang ausprobiert und analysiert werden. Unterschätzte Gebiete durchaus auch mal in das System eingebunden werden. Nur bei Erfolg werden diese Auslöser nachhaltig verfolgt. Bei Interesse widme ich diesem Aspekt gerne mal einen eigenen Artikel.

Blog abonnieren: http://wernerroth.de/index.php/feed/

„dm-Fotowelt“ Software unter Ubuntu 16.04 installieren

Damit ihr Euch das suchen vereinfachen könnt, kurz und knapp einige Hinweise um die dm-Foto-Software (CEWE) unter Kubuntu 16.04 Xenial Xerus in Betrieb zu nehmen.

  1. Folgende Anleitung passt noch ganz gut: https://wiki.ubuntuusers.de/dm_DIGI_Foto/
  2. Die Download-Seite ist nicht ganz leicht zu finden http://www.fotoparadies.de/bestellsoftware/download-linux.html
  3. Beim Start der Applikation /opt/dm/dm-Fotowelt/dm-Fotowelt meckert diese, dass libgstreamer0.10-0 fehlt. Dies kann mit
    sudo apt-get install libgstreamer-plugins-base0.10-0
    behoben werden.
  4. Leider werden die Tooltipps als helle Schrift auf gelben Grund dargestellt, diese Farbkombination ist in der Datei general_b_default.css festgelegt.
    QToolTip {
               border-radius: 0px;
               border: 1px solid #e5e5e5;
               background-color: #fafac4;
               padding: 2px;
    Die Hintergrundfarbe background-color kann auf eine dunkle Farbe geändert werden (z.B. Schwarz #000000 oder Dunkelblau #00008B).
    sudo vim /opt/dm/dm-Fotowelt/Resources/guiwidgets/css/general_b_default.css

Hoffe das hat Euch zwei Minuten Sucharbeit erspart.

Kubuntu 16.04 ist da!

Kubuntu heißt jetzt Xenial Xerus. Das gastfreundliche Borstenhörnchen ist wie immer am besten über ein Peer-to-Peer-Netzwerk herunterzuladen. Nutzt die untenstehenden Torrent-Links:

Die erhaltenen .ISO-Images sollten per md5-Prüfsumme auf Korrektheit überprüft werden:

Die obigen Images (ca. 1.4 GB) können via UNetbootin auf einen USB-Strick transferiert werden oder auf eine DVD gebrannt werden. Ein bestehendes System lässt sich z. B. mit der Softwareverwaltung auf 16.04 bringen.

Viel Spaß!

200 Jahre Augusta Ada Lovelace

200 Jahre Augusta Ada Lovelace – wobei meine Beziehung zu Ada 20 Jahre alt ist, zumindest ungefähr 20 Jahre, wenn Ihr mir diese Geschichtsglättung erlaubt. Vor 20 Jahren habe ich mich mit den ersten Rechenmaschinen und deren Erfindern befasst. Neben Frau Lovelace waren dies Persönlichkeiten wie Wilhelm Schickard, Gottfried Wilhelm Leibniz, Charles Babbage und viele mehr.

Bei einigen meist älteren Geschichtsbüchern war es mir immer ein Graus, wenn Historiker ihren Helden monumentalistisch dargestellt haben. Jede kleine Skizze, Notiz oder Idee wurde größtmöglich interpretiert, um die historische Person über alle Maße glänzen zu lassen. Am Ende blieb ein unerreichbarer Superheld, der zumindest für mich keinerlei Vorbild mehr bot.

Viel angenehmer fand ich kritische Auseinandersetzungen, die die historische Person in ihrem Kontext zeigen. Wissenschaftliche Helden, die Ideen aufnehmen und entscheidend weiterentwickeln, Teamarbeiter sind oder einen Tross Mitarbeiter befehligen und vieles mehr, dass einem verstehen hilft wie die Person in ihrer Zeit war. Vorbilder mit Ecken und Kanten sind mir näher, realer und meist stellt sich deren Leistung, als noch bewunderswerter heraus.

Im Rahmen einer Lesung zu Frauen in der Informatik befasse ich mich nach Jahren wieder mit Ada Lovelace und muss feststellen, dass Ada ganz schön gewachsen ist. Auch vor 20 Jahren war Ada Lovelace schon eine Ikone für Frauen in der Informatik. Nun kommt Sie mir ganz oft sehr extrem dargestellt vor: Superheldin oder dummes aristrokratisches Menschlein, Ada polarisiert. Im Facebook-Zeitalter gibt es kurze Artikel und deren erste Ableitung nämlich Kommentare. Ada Artikel im Netz werden mit und vielfach ohne Wissen kommentiert. Dabei geht es eher um Debatte und Frontenbildung. Diskussion, historischer Kontext und Hinweise auf alternative Sekundärliteratur sind spärlich gesät.

Ich fürchte es geht auch gar nicht um Ada in ihrer Zeit, sondern um die Ikone Ada in unserer Zeit. Auf den Punkt bringt es die Frage „Was würde Ada heute tun?“ Auch wenn von konkreten Antworten nur so wimmelt, im eigentlichen Sinne ist diese Frage nicht ernsthaft zu beantworten. Ada Lovelace entstammt einer aristrokratischen Familie im viktorianischen Zeitalter.

Ein paar Rahmenbedingungen aus Adas Zeit mit heutigem Maßstab gemessen: Nur ein Bruchteil der Bevölkerung hat ein Wahlrecht, es gibt keine Gleichberechtigung, Arbeiterfamilien leben meist unter prekären Bedingungen, Kinderarbeit ist Gang und Gäbe. Dampfmaschine und Kohle treiben eine frühkapitalistische Gesellschaft voran, es herrscht Aufbruchstimmung, Luftverschmutzung und Arbeiter haben keine Sozialversicherung. Es ist noch ein weiter Weg in unsere Gesellschaft und deshalb aus einigen Betrachtungswinkeln spannend.

Dampfkraft ermöglicht Produktion ungebunden von Wasserläufen oder Windmühlen an jedem Ort. Charles Babbage und Ada Lovelace sind getrieben von der Idee mathematische Funktionen mit Dampf zu berechnen. Seine Differenzmaschinen sollten mathematische Tabellen fehlerfrei berechnen. Differenzmaschinen berechnen Polynome, das heißt die berechneten mathematischen Funktionen, wurden nur angenähert genau berechnet. Das funktioniert für viele Anwendungen ganz wunderbar, schränkt aber die berechenbaren Funktionen ein.

Um universeller rechnen zu können erfindet Charles Babbage die Analytical Engine, eine Maschine die Grundrechenarten gesteuert mit Lochkarten kombinieren kann und so ähnlich wie ein Computer rechnen kann. Zu dieser nur auf dem Papier existierenden Maschine werden verschiedene Programmabläufe entwickelt. Den Ablauf zur Berechnung von bernoullischen Zahlen veröffentlicht Ada Lovelace. Dies ist sozusagen das Epizentrum aller Interpretation.

Die Analytical Engine ist die Geschichte einer sehr Visionären Erfindung, absolut spannend und eine geistige Leistung die ihrer Zeit weit voraus ist. Die Analytical Engine als theoretischer Computer wird jedoch weder gebaut noch weiter verfolgt, die Idee gerät in Vergessenheit.

Hätte die Maschine funktionieren können? In wie weit haben die Beteiligten einen Computer in ihr gesehen? Gab es Ideen zu einer Programmiersprache? Welchen Anteil hatten Ada Lovelace und Federico Luigi Menabrea?

Die Analytical Engine wird aktuell in einem Forschungsprojekt gebaut. Die restlichen Fragen sind nicht mehr zu beantworten, sondern nur zu interpretieren. Dazu dienen die wenigen wissenschaftlichen Dokumentationen und der Briefwechsel zwischen den Beteiligten und ihren Familien.

Wenn Ihr Euch mit Literatur zu Ada Lovelace und Charles Babbage beschäftigt, werdet ihr herausfinden, wo die Goldwaage angesetzt wurde, Dinge weggelassen sind oder der gesunde Menschenverstand ausgeschaltet wurde.

Am besten lest Ihr ein Buch Pro und eines Contra Ada Lovelace als erste Programmiererin. Neben einer fundierten Meinung werdet Ihr schöne Dinge finden: Charles Babbage soll ein grummeliger Zeitgenosse gewesen sein. Ada Lovelace wollte mit Dampfkraft fliegen und beide sollen schlechter gekleidet gewesen sein, als ihre Dienerschaft.

Eine Frage bin ich Euch noch schuldig. Was würden Ada und Charles heute tun? Als Mitglied der Aristrokratie vielleicht Parties in Südfrankreich schmeißen, sich bei Castingshows musikalisch erproben oder den ganzen Tag twittern. Vielleicht sitzen sie aber auch neben Euch in einer Mathematikvorlesung, im Großraumbüro einer Versicherung, entwickeln Cloud-Anwendungen und sind ganz normale Menschen.

Espresso Experience – Silvia Gruppenverkleidung verchromt ersetzen

Um die Brühgruppe trägt die Miss Silvia eine Abdeckung die metallen verchromt scheint, jedoch sich bei näherer Betrachtung als schnöder Kunststoff herausstellt. Nach einigen Jahren der Benutzung hatte ich diese Ummantelung (Teile Nr. 38123549) in der Hand, da die beiden Kunststoffzapfen unten ausgebrochen waren. Ersatz aus Metall gibt es auch hier anscheinend nicht.

Die Explosionszeichnung lies Böses ahnen, ich muss aber sagen der Austausch ist mit wenig Aufwand gemacht. Die vier Kreuzschlitzschrauben des Gehäusedeckels entfernen, Deckel abnehmen, rechts und links neben den Kessel schauen und unten die Schrauben für die Abdeckung entdecken. Die linke Schraube ist unter dem Schlauch für die Wasserzuführung verdeckt. Auf die neue die Plastikabdeckung müssen zwei Metallkronen für die Schrauben aufgesteckt und mit einem Hammer eingepasst werden.

Foto Metallblech

Die Gruppenverkleidung wird hinten von zwei Schrauben und vorne von einem Metallblech (roter Pfeil) gehalten. Die Verkleidung grob unter der Brühgruppe platzieren und von oben die beiden Schrauben mit nur wenigen Umdrehungen befestigen. Das Metallblech mit einem dünnen Schraubendreher unten halten und die Abdeckung darüber rutschen lassen. Nun beide Schrauben fest anziehen, Maschine wieder verschließen, fertig.

Foto Schraubendreher

Die Schrauben für die Abdeckung sind recht weit unten in der Maschine. Ihr benötigt einen langen magnetisierten Schraubenzieher. Alternativ kann man die Schraube auch mit einem Stück Klebeband auf dem Schraubenzieher halten.

Es ist ja sehr schön, dass die Rancilio Silvia so leicht zu reparieren ist, schade ist jedoch, dass die Spannklammern unter der Gehäuseabdeckung aus rostendem Material sind. Der Rost schleicht hier unter die Schraube und von da aus auf die Oberseite der Edelstahlabdeckung. Vier Kleckse Rostschutzfarbe auf die Klammern sollten nicht fehlen, um die Maschine auch die nächsten Jahre optisch schön zu halten.