HINWEIS: ich hab das als "remote" eingestellt, aber ich glaube, wir müssen am Anfang auch in Präsenz zusammen arbeiten. Ganz unten erkläre ich wieso weshalb warum :)

---

Ausgangslage

Wir nutzen Jira Datacenter on premise, für interne Tickets und für Kundentickets.

Pro Kunde haben wir dort eigene Supportprojekte, die über Jira Service Management erreichbar sind. In der Summe kommen wir auf 150-190 Projekte, die Daten enthalten, die wir migrieren müssen. Im gesamten sind es circa 20.000 Tickets.

In Jira Cloud haben wir erste Gehversuche gemacht, und einige interne Projekte dort aufgesetzt. Das geht so meh, reicht aber aus. Die Frage ist nur: wie bekommen wir die Kundenbetreuung in der Cloud neu modelliert? Denn was wir aktuell on premise haben stellt uns in keiner Weise zufrieden.

Viele Probleme

Unser Jira-Setup-Ansatz ist eventuell suboptimal

• Wir haben heute pro Kunde ein Projekt - aber macht das Sinn? Was ist der Best Practice Ansatz?
  • sollte man ein Projekt für alle Kunden haben, und Daten-Separation über Feldwerte erreichen? Ist das "safe" unter Datenschutzaspekten?
  • oder sollte man pro Kunde ein eigenes Projekt haben?

Unsere Kernprozesse für die wir Jira nutzen sind komplett undefiniert

• Wir haben unsere Business-Prozesse nie aufgezeichnet. Statt dessen haben wir aus der Hüfte “irgendwas” implementiert was “irgendwie” funktioniert. Das sorgt für viele Probleme “down the line”...

Unser Ticketing ist ineffizient, ineffektiv und schmerzhaft

• Wir haben diverse Aufgabentypen - aber die sind sinnlos definiert
• jeder Typ ist im Prinzip der selbe Typ, das unterscheidet sich alles nur über die Benennung und das Icon. Es sind aber überall die selben Felder - und es sind alles Freitextfelder 🙁
• Unsere Tickets enthalten nicht die Infos die sie enthalten müssten um sinnvoll zu sein
  • Beispiel: Kunde wählt Change aus, müsste auswählen für welchen Server der Change gelten soll, dazu müssten wir dynamisch die Server des Kunden aus der CMDB einklinken können
  • Beispiel: Incident-Ticket wird für Kundensystem eröffnet. Dazu sollten wir dynamisch a) Inhalte den Kunden betreffend aus Confluence oder aus der CMDB einklinken können
  • Beispiel: Kontaktdaten im CRM - sollten im Ticket immer sichtbar sein und dynamisch eingeklinkt werden können
• Wir müssten in Abhängigkeit von Ticketparametern in der Lage sein verschiedene Inhalte aus Umfeldsystemen dynamisch einzulinken

Unser Ticketing ist viel zu manuell

• Alle Flows “leben” davon das Menschen Kommentare schreiben - und Menschen hassen das. 
• Wir sollten stattdessen Flows haben die so designed sind das Menschen möglichst wenig manuell eintippen müssen.
• Beispiel: Ein Alarmticket geht auf, ein Bearbeiter nimmt das Ticket, er drückt einen Knopf und beginnt die Bearbeitung, daraufhin steht im Ticket “Mitarbeiter X beginnt die Bearbeitung”. Im nächsten Schritt stellt der Mitarbeiter seine Diagnose. Er muss diese nicht per Hand angeben, sondern kann aus einer Vielzahl von vorhandenen Diagnosen die richtige auswählen. Passt keine kann er eine neue angeben. Nach der Auswahl wird die Diagnose als Feldwert vermerkt und das Ticket aktualisiert. Im nächsten Schritt kann der Mitarbeiter spezifizieren was noch zu tun ist, wenn noch etwas zu tun ist, oder sagen “alles erledigt. Daraufhin präsentiert das Ticketsystem dem Bearbeiter einen Schieberegler, wo dieser via Klick einstellt wieviele Minuten er buchen will. Danach ist das Ticket erledigt und statistisch auswertbar.

Was stellen wir uns vor?

Wir möchten nicht "as is" migrieren, sondern uns die Zeit nehmen, und es richtig machen. Wir glauben das "richtig machen" folgendes bedeutet:

1. Überlege Dir welche Alt-Daten Du hast und wie Du diese zukünftig vorhalten und verfügbar machen kannst (Archiv ohne Veränderungen)
2. Für alles neue, definiere welche Business-Flows Du eigentlich hast (Kundenanfrage, Projektumsetzung, Störungsmeldung...)
3. Pro Flow definiere
   1. wie der Real-World Prozess dazu aussehen soll
   2. welche Nuancen es geben muss um effektives Ticketing zu realisieren
   3. welche Daten von wo Du dafür brauchst
   4. wie du alles zusammen fügen müsstest
4. Schreibe das alles auf und visualisiere es - und stelle in den Schritten 1 bis 3 sicher das jemand dabei ist der weiß was Jira wirklich kann, damit wir nicht für einen Elfenbeinturm planen, den wir aber in der Realität nicht bauen können.
5. Plane konkret wie Du das implementierst
6. Fange an das zu implementieren, in kleinen Schritten (Agil, iterativ)
7. Implementiere, Tune, justiere... ein MVP, und dann so viele Versionen bis wir sagen "das ist gut so"

Wichtig!

• Damit das fliegt, müssen wir insbesondere am Anfang mit jemandem sehr eng zusammen arbeiten. In dieser ersten Phase stellen wir uns eine Quasi-Vollzeit Beschäftigung vor, z.B. mit 33h pro Woche über einen Zeitraum von 4-10 Wochen. Locations hierfür könnten Frankfurt am Main oder 35440 Linden bei Gießen sein (was unser bevorzugter Ort wäre).
• Haben wir uns zusammen gerauft und das Konzept zu größten Teilen fertig, kann man auch gut auf Remote-Arbeit übergehen.
• Bitte bewirb dich daher nur, wenn es für dich möglich ist, in einer Anfangszeit vor Ort zu sein.