Unternehmen brauchen in hierarchischen Strukturen verdichtete Informationen, um effizient arbeiten zu können.
Auch wenn heute mehrere Jira-Systeme parallel und unabhängig voneinander arbeiten, müssen die Informationen – häufig manuell – zusammengetragen, verdichtet und nach „Oben“ übermittelt werden. Anderenfalls ist keine mittelfristige Planung oder prozessual effektive Arbeitsweise möglich.
Die Ressourcen, also die Mitarbeiter, sind die wertvollsten und teuersten Erfolgsfaktoren eines Unternehmens. Hier darf nichts verschenkt und es dürfen keine Fehler gemacht werden.
Das Management muss jederzeit einen vollständigen Überblick über alle Projekte und die gesamten Kapazitäten sowie alle vorhandenen und in der Zukunft benötigten Fähigkeiten/Skills haben68. Andernfalls werden taktische und strategische Fehlentscheidungen getroffen, die im negativen Fall die Wettbewerbs und damit Überlebensfähigkeit der gesamten Firma gefährden.
Das manuelle „Zusammentragen“ der Daten und die Transformation dieser Daten in Informationen, die das Management versteht, um Entscheidungen zu treffen (häufig in Excel) sind aufwendig und fehleranfällig.
Im schlimmsten Fall arbeitet ein Mitarbeiter parallel in mehreren Systemen und muss die Daten abgleichen, ein schlimmeres Szenario gibt es nicht.
Das Can Do-Jira-Interface löst diese Problemstellung sehr einfach und elegant.
Es können beliebig viele Jira-Systeme in Can Do konfiguriert und parallel betrieben werden.
Bei der Verkettung von Epics zu Phasen muss der Anwender erst den entsprechenden Server wählen (er muss in jedem Jira-Server, den er braucht, einen Account haben).
Danach kann er wie gewohnt den Epic mit der Phase verbinden. Die technische Identifizierung des Epics wurde in der Schnittstelle nicht nur über die in einem JiraServer eindeutige Epic-ID realisiert, sondern zusätzlich durch eine eigene Server-ID, die Can Do intern im Server generiert. Selbst wenn das Projekt und der Epic in zwei Jira-Systemen den gleichen Titel haben, verwechselt der Can Do-Server die beiden nie.
Der Effekt in der gesamtheitlichen Darstellung aller Projekte, Phasen und Kapazitäten in Can Do ist beeindruckend. Erstmalig können Firmen in Can Do einen vollständigen Überblick über alle Projekte und alle Ressourcen erhalten. In Portfolios in Can Do können global Projekte unabhängig vom entsprechenden Jira-Server zusammengestellt werden.
Die Auslastung und die Verfügbarkeit aller Teams können weltweit analysiert und dargestellt werden.
Die Künstliche Intelligenz von Can Do zur Ermittlung von Projektrisiken, gepaart mit entsprechenden Handlungsvorschlägen, arbeitet auch für diese Planungselemente.
Selbst Teams von unterschiedlichen Jira-Servern, die aber in einem Projekt arbeiten, sind so möglich.
Einfach gesagt, kann es dem Projektmanager völlig egal sein, wie sich die technische Architektur aus Jira-Servern zusammensetzt: er kann sich voll auf das Projekt und die Teams konzentrieren.
Der Can Do-Server ist äußerst leistungsfähig. Auch wenn viele Jira-Server parallel mit ihm verbunden sind, kann er die Daten mühelos aufnehmen und in Echtzeit verarbeiten. Die Daten von Jira sind nämlich alle akkurat. Die Termine von Sprints sind nicht ungenau, die Story Points, also die Aufwände, auch nicht. Daher müssen keine exponentiellen Iterationen berechnet werden.
Typische Dienstleister, die eigenes Personal an Kunden „vermieten“ oder Teilprojekte übernehmen, arbeiten oft jahrelang mit Kunden-Jira-Systemen. Dort haben sie auf die Daten des Jira-Servers nur begrenzten Zugriff. Es fehlt dem Dienstleister also die technische Möglichkeit, die Auslastung und Verwendung seiner Mitarbeiter digital zu verfolgen.
Das Jira-Interface arbeitet aber mit einem Account, der für den Dienstleister zur Verfügung gestellt wurde. Dieser Account hat nur Zugriff auf die Daten, die der Dienstleister braucht und somit auch der Can Do-Server.
