Lars Hansen

Softship AG

Agenda

2

• Softwareauswahl

• Genutzte Softwarepakete

• Issue Typen

• Workflows – Support & Consulting

– Softwareentwicklung

• Releasemanagement

• Abrechnung & Controlling

• JIRA Service Desk zur Kundenkommunikation

• Confluence – Dokumentation

– Integration in Release und Dokumentationsmanagement

• Future steps

• Tops & Flops

© 2015 Softship AG

Softwareauswahl

3

• Ablösung einer selbstentwickelten Software (AS/400, über 20 Jahre)

– Flexible Bearbeitung, mit wenigen Rechten

– Vollintegrierte Rechnungserstellung

– Automatisches Erzeugen von Dokumenten und Auslieferung per Knopfdruck

– Controlling mit Hilfe Excel und Pivottabellen

– Stabil, kaum Probleme

• Mehrstufiger Prozess mit folgenschwerer Fehlentscheidung

• Bug-Reportingsysteme existieren wie Sand am Meer

• Problemstellung– Produktionsunterstützung (inkl. Entwicklung und Test und diversen

Workflowsteps)

– Rechnungen & finanzielle Daten inkl. Zeiterfassung (Controlling & Billing)

– Customer Frontend

– Dokumentation

© 2015 Softship AG

Genutzte Softwarepakete

4

Hauptapplikationen:

• JIRA (100 User)

• Confluence (100 User)

• JIRA Service Desk (100 ! User)

Auswahl Add-Ons:

• Tempo (für Zeiterfassung)

• Bob Swift “Create in Transition” (für automatischesErstellen von Sub-Tasks)

• E-Mail this issue (E-Mail Versand aus Issues heraus)

• N-Feed (Zugriff auf externe DB Tabellen für Projektund kundenbezogene Stammdaten)

© 2015 Softship AG

Issue Typen

5

In Anlehnung an ITIL nutzen wir im JIRA Service Desk Issue Typen:

• Incident

• RfC (Request for Change)

• RfS (Request for Service)

Weitere Issue Typen:

• Consulting

• Systemmangement

• Support (paid)

• Fixed Price

• Development

• Test

• Developer Analyse

• Developer Estimate

© 2015 Softship AG

Standardworkflows: Incidents

6

• Erfassung von Issues durch Kunden in einem Kundenportal bzw. per E-Mail

• Kategorisierung durch Support

• Analyse durch den Support (+Zeiterfassung)

• Übergabe an die Entwicklung + Test (evtl. mehrstufig) mit Sub-Tasks

• Evtl. Developer Analysis Sub-Tasks

© 2015 Softship AG

Standardworkflows: RFCs

7

• Erfassung von Issues – durch Kunden per Kundenportal oder E-Mail

– Projektleiter / Consultant

• Kategorisierung durch Support

• Pricing inkl. automatische Kalkulation (Developers-Estimate / Sub-Task)

• Erstellung eines Angebots und Versand per E-Mail

• Akzeptanz / Ablehung des Kundens

• Übergabe an die Entwicklung + Test (evtl. mehrstufig und parallel)

• Abrechnung der ausgelieferten RFCs

© 2015 Softship AG

Releasemanagement

8

• Nutzung der “affected” und “fixed” Version

– Alte Version = Hotfix

– “Not released” Version = reguläre Auslieferung

• Nutzung diverser “dates” – Planned Delivery Date � Zur Darstellung der

geplanten Auslieferung

– Requested Delivery Date � Wunsch des Kundenbzw. Consultants

– Due date � Geplantes Datum bzgl. Erledigungeines Main bzw. Subtasks

© 2015 Softship AG

Abrechnung & Controlling

9

• Diese erfolgt für die Issue Typen

– Consulting, Systemmanagement & Support (paid) nach Aufwand

– RFC’s nach Fixed Price

• Im Status “Resolved” werden die Issues ggfls. mit einer internen Rechnungsnummer

versehen (Inter-Company-Billing)

• Dannach werden alle Issues auf Closed gesetzt mit Hilfe einer Bulk Operation

(Revisionssicherheit!)

• Alle geschlossenen Issues der entsprechenden Typen werden mit einer

selbstentwickelten Applikation per Kunde mit Hilfe der Tempo API dargestellt

• Vor dort wird per Tempo API das Feld “Billing information” mit der

Rechnungsnummer beschrieben

• Die Rechnungen werden mit Hilfe von Crystal Report erstellt

• Controlling stellt sich problematisch dar:

– Tempo Schnittstelle ist zu langsam

– Accounts Funktionalität ist nicht ausreichend

– Ansatz einer Lösung: View auf die Datenbank und Kostenstellen per Issuetype bzw. durch

manuelle Zurordnung

© 2015 Softship AG

JIRA Service Desk

10

• Weichen für den JIRA Service Desk gestellt, weil– nur eine IT-Lösung zu betreiben ist (Updatability, Verträge, Stabilität)

– Schnittstelle zu den Kunden auch Confluence umfassen soll, Integration möglich

– Begrenzung der Sichtbarkeiten (auf ausgewählte Issue Types (Incident, RfC, RfS) und Felder)

• Gravierende Nachteile– Keine brauchbare Übersicht für Kunden

– Keine Suche z.B. nach Ticketnummern oder anderen Feldern, Attributen

– Sicht auf die Tickts nicht nach Kunden / Projekten möglich

– Lizenzkosten extrem hoch (80% Lizenzvolumen),

Wenn ein Projekt einen Service Desk hat, können normale User nur noch

Kommentare hinterlassen und nicht mehr am Workflow teilnehmen.

Es sind dann zwingend ausschließlich “Service Desk Agents” notwendig.

© 2015 Softship AG

Confluence

11

• Softship nutzt Confluence zur internen Dokumentation– Projekte

– Techische Dokumentation

• In der Zukunft soll die Produktdokumentation ebenfallskomplett über Confluence erfolgen

– Direkte Erzeugung einer Confluence Page per Issue (imKundenspace)

– Darstellung aller Issues als Wiki und von außen errreichbar(gespiegelte Confluence Instanz)

– Automatische Erstellung von Release Notes

• Vorteile– Durchsuchbare Dokumentation für Kunden und Intern

– Volle Integration in die Workflows

© 2015 Softship AG

Future steps

12

• Service Desk auf ein von unseren Kundennutzbaren Level bringen oder Drittprodukteinführen

• Controlling implementieren

• Confluence / JIRA Service Desk Link

• Evaluierung von– TFS (Team Foundation Server integration)

– Enterprise Tester integration (wird fürRegressionstests genutzt)

– SLA Feature (Servicedesk)

– Weitere Dev-Tools

© 2015 Softship AG

Tops & Flops

13

TOP• Standardleistungsumfang von Confluence

• JIRA Workflowdesign & Features

• Gute Anpassungsmöglichkeiten (Felder, Prozesse, Plug-Ins)

• Hohe Stabilität

• Kosten von JIRA, Confluence & Plug-Ins sind eher moderat

FLOP• Service Desk ist überproportinal teuer bei ausgesprochenem

geringem Leistungsumfang

• Tempo API und Übersichten sind zu langsam und in vielenBereichen nicht nutzbar

• Zeiterfassung von Tempo ermöglicht keine“Echtzeiterfassung”

• Berechtigungsverwaltung nur sehr eingeschränkt nutzbar

• Dokumentationen sind häufig nicht ausreichend

© 2015 Softship AG