Der Anbieter kommt aus Cork in Irland und ist damit ein Unternehmen mit Sitz in der Europäischen Union — ein Punkt, der in DACH-Ausschreibungen regelmäßig eine Rolle spielt und den wir in Kapitel 09 nüchtern einordnen. Fachlich wichtiger ist die Positionierung: Der Anbieter beschreibt sein Produkt seit einigen Jahren konsequent als Plattform für „Client Work Management“, also für die Steuerung von Arbeit, die für externe Auftraggeber erbracht wird. Das ist keine Marketingnuance, sondern eine Entwurfsentscheidung, die sich in Datenmodell, Berechtigungen, Auswertungen und Preislogik durchzieht.
Für eine ehrliche Einordnung gehört der Umkehrschluss dazu: Wer keine Kundenprojekte abrechnet, nutzt einen erheblichen Teil der Plattform nicht. Eine interne IT-Abteilung ohne Verrechnung, ein Produktteam mit Festangestellten und ohne Stundenlogik oder eine Verwaltungseinheit, die Vorgänge lediglich sichtbar machen will, bekommt hier ein solides, aber überdimensioniertes Werkzeug. Umgekehrt gilt: Für Organisationen, deren zentrale Frage lautet, ob ein Auftrag noch im Rahmen läuft, gehört Teamwork.com zu den wenigen Plattformen, die diese Frage ohne Zusatzsysteme beantworten.
Der Softwaremarkt für Projektarbeit hat sich in den letzten Jahren aufgefächert. Auf der einen Seite stehen breite Work-Management-Plattformen, die beliebige Arbeit in Teams organisieren. Auf der anderen Seite stehen spezialisierte Systeme für professionelle Dienstleistung, die von der Wirtschaftlichkeit des einzelnen Auftrags her denken. Teamwork.com sitzt bewusst auf der zweiten Seite, verzichtet aber auf die Schwere klassischer Systeme für Professional Services Automation, die häufig eine eigene Einführungsdisziplin darstellen.
Praktisch bedeutet das eine bestimmte Reihenfolge der Fragen. Ein Auftrag entsteht, er erhält ein Budget in Geld oder in Stunden, er wird in Aufgaben zerlegt, Personen buchen Zeit darauf, diese Zeit ist abrechenbar oder nicht, das Budget wird verbraucht, und am Ende steht eine Auswertung, die den erbrachten Aufwand gegen den vereinbarten Preis stellt. Alle anderen Funktionen — Ansichten, Kommentare, Dateien, Automatisierung — sind Beiwerk zu dieser Kette. Wer die Plattform so liest, versteht schnell, welche Konfigurationsentscheidungen wirklich zählen.
Das Datenmodell ist bewusst flacher als bei manchen Wettbewerbern, und diese Schlichtheit ist ein Vorteil. Oberhalb der operativen Ebene steht der Kunde beziehungsweise das Unternehmen, dem ein Projekt zugeordnet ist — eine Ebene, die viele generische Werkzeuge erst durch Zusatzfelder nachbauen müssen. Darunter liegt das Projekt als betriebswirtschaftliche Einheit mit Verantwortlichen, Terminen, Stundensätzen und Budget. Projekte lassen sich zu Portfolios oder Kategorien gruppieren, um mehrere Aufträge desselben Kunden gemeinsam zu betrachten.
Innerhalb eines Projekts strukturieren Aufgabenlisten die Arbeit in Phasen, Gewerke oder Leistungsblöcke. Darin liegen Aufgaben mit Unteraufgaben, Verantwortlichen, Terminen, Schätzwerten, Abhängigkeiten, benutzerdefinierten Feldern und Anhängen. Die entscheidende Zusatzebene ist die Zeitbuchung: Jeder Eintrag hängt an einer Aufgabe oder mindestens an einem Projekt, trägt Dauer, Person, Datum, Beschreibung und die Kennzeichnung, ob er abrechenbar ist. Weil diese Buchung nicht nachträglich aus einem Fremdsystem zugeordnet werden muss, sondern direkt am Vorgang entsteht, sind Auswertungen von Anfang an belastbar.
Ergänzt wird das Modell durch Meilensteine für vereinbarte Fixpunkte, Notizen und Dokumente für projektbegleitendes Wissen sowie Nachrichten für strukturierte Abstimmungen jenseits kurzer Kommentare. Für den Alltag ist die Unterscheidung zwischen Kommentar am Vorgang und projektweiter Nachricht wichtiger, als sie klingt: Sie entscheidet darüber, ob eine Information später gefunden wird oder in einer langen Kommentarspur verschwindet.
In unseren Projekten begegnet uns die Plattform in vier typischen Konstellationen. Die erste ist die Agentur — Werbung, Digital, PR, Kommunikation — die viele parallele Kundenaufträge mit begrenztem Team abwickelt und Retainer neben Projektpauschalen führt. Die zweite ist der IT-Dienstleister, der Entwicklungs-, Betriebs- und Beratungsleistungen mischt und Stunden gegen Kontingente verrechnet. Die dritte ist das Ingenieur- oder Planungsbüro, das Leistungsphasen abrechnet und Nachträge belegen muss. Die vierte ist die Beratung, die Auslastung und Tagessätze im Blick behalten muss, weil beides unmittelbar auf das Ergebnis wirkt.
Gemeinsam ist diesen vier Fällen ein Muster: Der Engpass ist nicht die Übersicht, sondern die Wirtschaftlichkeit pro Auftrag. Es ist typischerweise bekannt, was zu tun ist. Unbekannt ist, ob der dritte Änderungswunsch noch im Budget liegt, ob ein Retainer ausgeschöpft ist und welcher Kunde in der Summe eines Jahres Geld gekostet statt gebracht hat. Wer diese Fragen bisher in einer Tabelle beantwortet, die einmal im Monat von einer Person gepflegt wird, findet in Teamwork.com genau die Kette, die diese Tabelle ersetzt.
Die Einstiegsstufen decken ab, was ein kleines Team zum gemeinsamen Arbeiten braucht: Projekte, Aufgabenlisten, Aufgaben, die gängigen Ansichten, Kommentare, Dateien und eine Basiszeiterfassung. Wer die Plattform auf dieser Höhe einsetzt, nutzt sie als übersichtliches Projekt- und Aufgabensystem und wird sie kaum von Wettbewerbern unterscheiden können. Der Charakter des Produkts zeigt sich hier noch nicht, weil die kaufmännische Seite fehlt oder nur angedeutet ist.
Der eigentliche Sprung erfolgt auf der mittleren Kern-Stufe. Hier kommen typischerweise die Funktionen hinzu, die den Zuschnitt der Plattform ausmachen: Projektbudgets in Geld und Stunden, differenzierte Stundensätze, die saubere Trennung von abrechenbarer und nicht abrechenbarer Zeit, Auswertungen zu Auslastung und Wirtschaftlichkeit, benutzerdefinierte Felder, Anfrageformulare als geregelter Eingangskanal, Automatisierungsregeln und die Ressourcen- beziehungsweise Kapazitätssicht. Für den typischen mittelständischen Dienstleister ist erst diese Stufe realistisch tragfähig. Diese Einordnung ist für die Budgetplanung wichtiger als jeder Listenpreis, weil sie darüber entscheidet, ob das Vorhaben sein Ziel erreicht.
Die oberen Stufen adressieren zwei verschiedene Bedürfnisse, die man auseinanderhalten sollte. Das erste ist Steuerungstiefe: feinere Ressourcen- und Kapazitätsplanung, mehrdimensionale Auswertungen über viele Projekte hinweg, Portfoliobetrachtungen, differenzierte Abrechnungs- und Retainer-Logiken sowie erweiterte Prognosefunktionen. Diese Fähigkeiten lohnen sich, wenn eine Organisation ihre Kapazitätssteuerung tatsächlich datengetrieben betreiben will — und die dafür nötige Datendisziplin aufbringt.
Das zweite Bedürfnis ist Governance: Anbindung an die Identitätsverwaltung und Single Sign-on, feingranulare Rollen- und Rechtekonzepte, Protokollierung administrativer Vorgänge, erweiterte Sicherheitsrichtlinien, Vorgaben für Datenaufbewahrung und je nach Ausbaustufe zusätzliche Betriebs- und Supportzusagen. In Organisationen ab mittlerer Größe ist diese Stufe häufig nicht Wunsch, sondern Voraussetzung dafür, dass die IT den Dienst überhaupt freigibt. Welche einzelne Fähigkeit in welcher Stufe liegt, wandert im Markt regelmäßig und gehört als Prüfliste zum Anbieter — schriftlich, nicht mündlich in einer Präsentation.
Historisch hat der Anbieter neben der Projektplattform weitere Bausteine geführt — unter anderem einen Helpdesk für Kundenanfragen per Mail, eine Dokumentenumgebung für Wissen und Handbücher sowie zeitweise Chat- und Vertriebsmodule. Der strategische Kurs der letzten Jahre führte zu einer deutlichen Konzentration auf die Projektplattform als Kern, mit begleitenden Modulen dort, wo sie den Ablauf im Kundengeschäft direkt stützen. Für die Beschaffung heißt das: Welche Module aktuell verfügbar, gebündelt oder separat lizenziert sind, ist zum Entscheidungszeitpunkt beim Anbieter zu erfragen, statt aus älteren Vergleichen übernommen zu werden.
Strategisch relevanter ist die Frage, ob eine „Suite“ überhaupt das Ziel sein soll. In mittelständischen Dienstleistungsbetrieben ist der Nutzen eines gemeinsamen Datenraums für Support-Tickets und Projektaufgaben real: Eine Kundenanfrage, aus der ein beauftragter Aufwand wird, muss nicht mühsam übertragen werden. Gleichzeitig gilt die nüchterne Beobachtung, dass Suiten selten in jeder Disziplin die beste Lösung stellen. Wer bereits ein etabliertes Ticketsystem oder ein gepflegtes Wiki betreibt, sollte den Wechsel nicht aus Bequemlichkeit vollziehen, sondern nur, wenn die Übergabe zwischen den Systemen nachweislich Reibung erzeugt.
Die Aufgabe trägt Verantwortliche, Start- und Endtermin, Priorität, Status, Beschreibung, Anhänge, Kommentare mit Erwähnungen, Checklisten in Form von Unteraufgaben, benutzerdefinierte Felder und — für diese Plattform charakteristisch — einen geschätzten Aufwand. Dieser Schätzwert ist kein Beiwerk, sondern die Grundlage für Budgetverbrauch, Kapazitätsrechnung und die Frage, ob eine Zusage realistisch war. Ohne gepflegte Schätzwerte bleibt ein erheblicher Teil der Plattform stumm.
Abhängigkeiten verbinden Vorgänge in Vorgänger-Nachfolger-Beziehungen und verschieben nachgelagerte Schritte mit, wenn sich ein Termin ändert. In der Gantt-Ansicht werden Vorgänge als Balken auf der Zeitachse dargestellt, Abhängigkeiten als Verbindungslinien, Verschiebungen sind per Maus möglich, und Meilensteine markieren vereinbarte Fixpunkte. Für Dienstleister ist gerade diese Sicht wertvoll, weil Kundentermine harte Außengrenzen sind: Wenn ein Freigabetermin beim Auftraggeber kippt, muss sichtbar werden, welche eigenen Schritte dadurch in Bedrängnis geraten.
Auf denselben Datenbestand bieten die weiteren Ansichten unterschiedliche Blickwinkel: die Listenansicht für Struktur und Massenpflege, die Board-Ansicht für die operative Steuerung im Wochenrhythmus, die Tabellenansicht für Filtern und Sortieren nach Feldern, der Kalender für die zeitliche Verteilung. Ergänzend erlauben Projektvorlagen die Wiederverwendung ganzer Strukturen samt Aufgabenlisten, Rollen, Schätzwerten und relativen Terminabständen. Der Wert liegt weniger in der Zeitersparnis als in der Vergleichbarkeit: Nur wenn ähnliche Aufträge gleich aufgebaut sind, lassen sich Aufwände zwischen Kunden und Jahren überhaupt sinnvoll gegenüberstellen.
Die Zeiterfassung ist das Herzstück. Zeit wird per Timer während der Arbeit oder als nachträglicher Eintrag gebucht, immer mit Bezug zu Projekt und möglichst zur Aufgabe, mit Datum, Dauer, Beschreibung und der Kennzeichnung „abrechenbar“ oder „nicht abrechenbar“. Diese eine Kennzeichnung trägt betriebswirtschaftlich mehr Gewicht als viele Funktionen zusammen: Sie trennt die Leistung, die in eine Rechnung eingeht, von der Leistung, die das Unternehmen selbst trägt — Nacharbeit, Akquise, interne Abstimmung, Kulanz. Erst diese Trennung macht die Diskussion über Produktivität konkret.
Darauf setzen Stundensätze auf. Sätze lassen sich je Person, je Rolle und je Projekt hinterlegen, sodass unterschiedliche Konditionen pro Kunde und unterschiedliche Kostensätze pro Qualifikation abbildbar sind. Wo Verkaufs- und Kostensätze getrennt gepflegt werden, entsteht aus der Zeitbuchung nicht nur ein Erlös, sondern ein Deckungsbeitrag. Genau das ist die Größe, an der ein Dienstleistungsbetrieb geführt wird, und die Grundlage der Betrachtung in Kapitel 08.
Budgets gibt es typischerweise in zwei Formen: als Geldbetrag und als Stundenkontingent. Ergänzend lassen sich wiederkehrende Kontingente für Retainer abbilden, also für monatlich vereinbarte Leistungspakete, die sich turnusmäßig zurücksetzen. Der praktische Nutzen liegt in der Frühwarnung: Ist ein definierter Anteil verbraucht, wird gewarnt — nicht erst, wenn das Budget überschritten ist. Wer diese Schwelle bewusst niedrig setzt, verschafft sich Zeit für das wichtigste Gespräch im Dienstleistungsgeschäft, nämlich die Frage, ob nachverhandelt oder der Leistungsumfang angepasst wird. Für die Abrechnung lassen sich erfasste Zeiten und Auslagen zu Rechnungsentwürfen bündeln und an die Buchhaltung übergeben; Umfang und Grenzen dieser Funktion sind vor der Entscheidung zu prüfen, weil hier das Zusammenspiel mit dem vorhandenen Rechnungswesen entscheidet.
Die Ressourcen- und Kapazitätsplanung stellt zugewiesene und geschätzte Arbeit gegen verfügbare Arbeitszeit und zeigt, wer über- und wer unterbucht ist. In der Praxis dient sie zwei Zwecken. Kurzfristig beantwortet sie die Frage, wer diese Woche noch etwas übernehmen kann. Mittelfristig beantwortet sie die weit wichtigere Frage, ob ein neuer Auftrag überhaupt angenommen werden sollte — und zwar mit Daten statt mit Optimismus. Sie ist damit die Funktion mit dem höchsten Führungsnutzen, gleichzeitig aber diejenige mit der höchsten Anforderung an Datenpflege: Ohne Schätzwerte, aktuelle Termine und hinterlegte Arbeitszeiten zeigt sie nichts Verlässliches.
Ein charakteristisches Merkmal sind die Client Users, also eigene Zugänge für Auftraggeber. Kunden erhalten damit Einblick in genau die Projekte, die sie betreffen, können Aufgaben kommentieren, Dateien liefern und Freigaben erteilen, ohne interne Kalkulationen, Stundensätze, Auslastungen oder andere Kunden zu sehen. Der Nutzen ist doppelt: Der Auftraggeber sieht Fortschritt ohne Nachfrage, und die Abstimmung findet dokumentiert am Vorgang statt statt in verstreuten Mailverläufen. Vor dem Einsatz gehören zwei Punkte geklärt: welche Felder für Externe tatsächlich unsichtbar sind, und wie diese Zugänge lizenzrechtlich gezählt werden. Beides ist beim Anbieter zu bestätigen, weil hier Modelle im Markt variieren.
Für die Abstimmung an Ergebnissen stehen Proofs zur Verfügung: Dateien werden in der Plattform betrachtet und mit punktgenauen Anmerkungen versehen, Versionen liegen übereinander, und ein definierter Freigabeschritt hält fest, wer wann zugestimmt hat. In kreativen und gestalterischen Abläufen ersetzt das den Freigabesumpf aus Mailanhängen und schafft eine belegbare Historie — im Streitfall über nicht beauftragte Änderungen der wertvollste Datensatz überhaupt. Umfang und unterstützte Dateitypen unterscheiden sich je Edition und Produktstand und sind vorab zu prüfen; in der Tiefe spezialisierter Proofing-Werkzeuge spielt diese Funktion nicht, für den Regelfall im Mittelstand genügt sie meist.
Die Automatisierung folgt dem im Markt verbreiteten Muster: Ein Ereignis löst aus, eine Bedingung schränkt ein, eine oder mehrere Aktionen folgen. Typische Auslöser sind der Wechsel eines Aufgabenstatus, das Erreichen oder Überschreiten eines Termins, das Anlegen eines Vorgangs, das Eintreffen einer Formulareinsendung, das Erreichen einer Budgetschwelle oder das Hinzufügen einer Datei. Aktionen reichen von Zuweisung, Statuswechsel und Terminsetzung über das Ergänzen von Unteraufgaben und Vorlagenteilen bis zu Benachrichtigungen und Freigabeanforderungen. Zusammengestellt wird das in einer geführten Oberfläche ohne Programmierkenntnisse.
Der Nutzen liegt nicht in spektakulären Einzelfällen, sondern in der Summe kleiner Entlastungen. Bewährte Muster aus mittelständischen Dienstleistungsbetrieben:
Diese Regeln ersetzen keine Prozessdisziplin, sie senken aber die Zahl der Stellen, an denen Disziplin nötig ist. Und sie wirken erzieherisch: Ein System, das selbst auf Vollständigkeit achtet, gewöhnt das Team daran, ohne dass jemand mahnen muss.
Auf der KI-Seite lassen sich drei Felder unterscheiden, die sich in Nutzen und Risiko deutlich unterscheiden. Das erste ist die Erzeugung von Struktur aus Text: Aus einem Briefing, einer Besprechungsnotiz oder einer knappen Absicht werden Vorschläge für Aufgaben, Unteraufgaben und Zwischenschritte abgeleitet. Für Personen, die selten planen und deshalb Schritte übersehen, ist das ein echter Gewinn. Die Vorschläge sind plausibel, nicht zwingend richtig — in technisch anspruchsvollen oder regulierten Leistungen ist dieser Unterschied erheblich und die fachliche Prüfung unverzichtbar.
Das zweite Feld ist die Verdichtung von Inhalten: Zusammenfassungen langer Kommentarverläufe, Aufbereitung von Projektstandsberichten, Formulierungshilfen für Kundenkommunikation. Für Dienstleister, die regelmäßig Statusberichte schreiben, ist das der spürbarste Alltagsnutzen. Gleichzeitig ist es der datenschutzrechtlich sensibelste Punkt, weil Kundeninhalte zur Verarbeitung an einen Dienst gegeben werden. Vor der Freigabe gehört geklärt, welche Verarbeitung genau stattfindet, wo sie erfolgt, ob Inhalte zum Training genutzt werden und ob die Funktion abschaltbar oder auf bestimmte Bereiche begrenzbar ist.
Das dritte Feld ist die Assistenz bei Planung und Auswertung: Hinweise auf gefährdete Projekte aus Termin-, Fortschritts- und Zeitdaten, Vorschläge für Aufwandsschätzungen auf Basis vergleichbarer vergangener Aufträge, Hilfen beim Erstellen von Auswertungen. Der Wert liegt in der Vorwarnzeit. Die Einschränkung liegt in der Datengrundlage: Eine Prognose auf Basis lückenhaft gebuchter Zeiten ist nicht besser als das Bauchgefühl einer erfahrenen Projektleitung — nur schwerer zu widersprechen, weil sie technisch wirkt.
Automatisierung hat eine Schattenseite, die sich erst nach Monaten zeigt: Unsichtbarkeit. Wenn zwanzig Regeln wirken, wundern sich neue Teammitglieder, warum Vorgänge sich scheinbar von selbst bewegen. Die Gegenmaßnahme ist banal und wirksam — Regeln nachvollziehbar benennen, in einer schlanken Dokumentation im System erklären und halbjährlich prüfen, ob sie noch dem gelebten Prozess entsprechen. Regeln, die niemand mehr erklären kann, gehören abgeschaltet, nicht vorsichtshalber behalten.
Zweitens gilt eine sinnvolle Reihenfolge der Mittel: erst prüfen, ob eine sauberere Struktur oder eine Vorlage das Problem löst; dann die eingebaute Automatisierung nutzen; erst danach eine Integrationsplattform in Betracht ziehen. Jede zusätzliche Station erhöht Kosten, Abhängigkeit und Prüfaufwand. Drittens berühren Automatisierungen und Auswertungen, die Bearbeitungszeiten protokollieren, Auslastung berechnen und Vorgänge Personen zuordnen, unmittelbar Leistungs- und Verhaltensdaten. Bei einer Plattform, deren Kern die Zeiterfassung ist, gilt das in besonderem Maße — dieser Punkt gehört ausdrücklich in die Abstimmung mit der Arbeitnehmervertretung, und zwar bevor das erste Auswertungsdiagramm in einer Leitungsrunde gezeigt wird.
Für Dienstleister ist die Anbindung an das Rechnungswesen die wertvollste Integration überhaupt, weil sie die häufigste manuelle Doppelarbeit beseitigt. Teamwork.com bietet Verbindungen zu verbreiteten Buchhaltungslösungen — im internationalen Umfeld typischerweise Systeme wie Xero, QuickBooks oder FreshBooks — mit denen abrechenbare Zeiten und Auslagen in Rechnungsentwürfe überführt werden, statt in einer Tabelle zusammengesucht zu werden.
Für den DACH-Mittelstand ist an dieser Stelle eine nüchterne Erwartungshaltung angebracht: Die im deutschsprachigen Raum verbreiteten Finanzbuchhaltungs- und ERP-Systeme sind in solchen Standardlisten häufig nicht fertig enthalten. Der realistische Weg führt dann über einen Export der abrechenbaren Leistungen, über die Programmierschnittstelle oder über eine Integrationsplattform. Diese Lücke gehört vor der Entscheidung geprüft, nicht danach, weil sie über den tatsächlichen Nutzen mitentscheidet. Für viele Betriebe ist ein monatlicher, strukturierter Export ausreichend — vorausgesetzt, dieser Ablauf wird bewusst definiert und nicht improvisiert. Zusätzlich sind die formalen Anforderungen des deutschen Rechnungswesens zu beachten: Wer aus der Plattform heraus fakturieren möchte, sollte Format, Pflichtangaben, Nummernkreise und Aufbewahrung mit der Steuerberatung abstimmen, statt sich auf eine Vorlage zu verlassen.
Die zweite wichtige Richtung ist der Weg vom Vertrieb ins Projekt. Über Verbindungen zu CRM-Systemen — im Markt verbreitet etwa HubSpot, Salesforce oder Pipedrive — lässt sich aus einem gewonnenen Angebot ein Projekt erzeugen, das Kunde, Leistungsumfang, Budget und Ansprechpartner bereits mitbringt. Der Gewinn ist weniger die gesparte Tipparbeit als die Übereinstimmung von verkauftem und geplantem Umfang. Wo diese Übergabe mündlich erfolgt, entsteht die klassische Lücke zwischen dem, was der Vertrieb versprochen hat, und dem, was das Projektteam eingeplant hat — der häufigste Ursprung von Budgetüberschreitungen im Dienstleistungsgeschäft.
Umgekehrt profitiert der Vertrieb davon, den Bearbeitungsstand zu sehen, ohne nachzufragen. Zwei Entwurfsentscheidungen sind hier wichtiger als die technische Machbarkeit. Erstens: Welches System führt den Kundenstamm? Wenn Kundendaten in beiden Systemen gepflegt werden, driften sie auseinander; eine Richtung muss führend sein. Zweitens: Wann wird ein Projekt erzeugt? Bei jedem Angebot entstehen Projektleichen, erst bei Auftragserteilung fehlt Vorlaufzeit für die Planung. Bewährt hat sich eine Zwischenstufe für wahrscheinliche Aufträge, die die Kapazitätsplanung informiert, ohne die Auswertung zu verzerren.
Auf der Kommunikationsseite existieren Anbindungen an Slack und Microsoft Teams, mit denen Ereignisse in Kanäle gemeldet und Vorgänge aus dem Chat heraus angelegt werden können, sowie an Mailprogramme, damit aus einer Kundenmail ein Vorgang wird. Dazu eine Warnung aus der Praxis: Wer sämtliche Systemereignisse in einen Kanal spiegelt, erzeugt Rauschen und trainiert das Team darauf, Benachrichtigungen zu ignorieren. Wirksam ist die selektive Variante — Eskalationen, ausstehende Freigaben, Budgetwarnungen und Fertigstellungen. Alles andere gehört ins System, wo es bei Bedarf abgerufen wird.
Bei Dateien stehen Verbindungen zu den verbreiteten Ablagediensten wie OneDrive, SharePoint, Google Drive, Dropbox oder Box zur Verfügung. Die wichtige Entwurfsentscheidung lautet auch hier: „verknüpfen“ oder „hochladen“. Verknüpfen hält die bestehende Ablage als führendes System und vermeidet Versionschaos; Hochladen macht Versionierung und Freigaben innerhalb der Plattform komfortabler. Beides ist vertretbar, aber die Entscheidung muss einheitlich getroffen und dokumentiert werden — Mischformen sind die Hauptursache dafür, dass später niemand weiß, welche Datei gilt.
Für alles Übrige stehen eine offene Programmierschnittstelle und ereignisbasierte Benachrichtigungen bereit, mit denen Projekte, Aufgaben und Zeitbuchungen angelegt, geändert und ausgelesen werden können — für Dienstleister mit eigener Entwicklungskompetenz oft der pragmatischste Weg zu Sonderauswertungen. Wer keine Entwicklung betreiben will, greift zu iPaaS-Diensten wie Zapier oder Make. Jeder dieser Wege bringt einen weiteren Verarbeiter in die Kette und damit einen eigenen datenschutzrechtlichen Prüfpunkt. Die Reihenfolge bleibt: erst prüfen, ob eine fertige Integration genügt, dann die Standardschnittstelle, erst danach eine zusätzliche Plattform.
Wrike ist als Work-Management-Plattform breiter aufgestellt und in Ressourcensteuerung, Freigabeprozessen für Dateien, eigenen Elementtypen und Portfolioauswertung tiefer. Es ist die stärkere Wahl, wenn viele Anfragen aus dem eigenen Haus auf knappe interne Kapazität treffen und Freigaben formalisiert werden müssen. Teamwork.com ist enger geführt und dort überzeugender, wo die Abrechnungslogik im Zentrum steht: Budget je Auftrag, abrechenbare Stunden, Retainer, Kundenzugang. Wer beide Bedürfnisse hat, sollte ehrlich abwägen, welches das größere ist, statt Funktionslisten zu addieren.
Asana gilt als besonders klar und angenehm bedienbar und ist stark bei Zielsystemen, Aufgabenklarheit und bereichsübergreifender Koordination. In Organisationen, in denen Akzeptanz das größte Risiko ist, ist das ein gewichtiges Argument. Die kaufmännische Ebene — Stundensätze, Budgets, Abrechenbarkeit, Wirtschaftlichkeit je Auftrag — ist dort jedoch nicht der Kern und wird häufig über Zusatzwerkzeuge für Zeiterfassung ergänzt. Damit entsteht genau die Schnittstelle, die Teamwork.com von Haus aus vermeidet.
monday überzeugt durch visuelle Zugänglichkeit und große Gestaltungsfreiheit: Boards lassen sich weitgehend frei aus Spalten zusammensetzen, was den Einstieg erleichtert und viele Anwendungsfälle bedient. Der Preis dieser Freiheit ist, dass fachliche Struktur selbst entworfen wird und Auswertungen nur so gut sind wie die selbst gebaute Ordnung. ClickUp setzt auf maximale Funktionsbreite in einem Produkt, oft zu attraktiven Konditionen, verlangt dafür aber hohen Konfigurations- und Entscheidungsaufwand: Weil fast alles möglich ist, muss fast alles festgelegt werden. Teamwork.com gibt mit Kunde, Projekt, Budget, Satz und Zeitbuchung mehr Modell vor — weniger flexibel, dafür schneller in der einen Disziplin, für die es gebaut ist.
Für Organisationen, denen deutschsprachiger Support, europäische Anbieterstruktur und schlanke Bedienung wichtiger sind als maximale Funktionstiefe, gehören awork und factro in die Betrachtung. Beide kommen aus Deutschland und betreiben ihre Dienste in europäischen Rechenzentren. awork ist besonders in agenturnahen und dienstleistenden Teams verbreitet und verbindet Aufgaben, Zeiterfassung und Auslastung in einer angenehm reduzierten Oberfläche — der funktional nächste Nachbar zu Teamwork.com im DACH-Raum. factro setzt stärker auf Projektstrukturbäume und klassische Projektlogik und ist in mittelständischen Fachabteilungen verbreitet.
Die ehrliche Abgrenzung: In der Tiefe von Budget- und Retainer-Logik, Abrechenbarkeit, Kundenzugängen und Auswertung über viele Aufträge hinweg ist Teamwork.com in der Regel weiter. In Einstiegsgeschwindigkeit, deutschsprachiger Oberfläche und Dokumentation, Support in der eigenen Zeitzone und Passung zu deutschen Abrechnungsgewohnheiten haben die DACH-Anbieter Vorteile. Wichtig ist, das Argument der Datenhoheit nicht überzudehnen: Teamwork.com ist selbst ein Anbieter mit Sitz in der EU, sodass der klassische Drittlandkonflikt in dieser Form nicht auftritt. Der Unterschied liegt eher in Sprache, Support, Abrechnungsnähe und Vertragspraxis als in der Grundfrage des Anbietersitzes.
Wir führen die Auswahl entlang von vier Fragen. Erstens: Wird abgerechnet? Wo Stunden zu Erlös werden, gehört Teamwork.com auf die engere Liste; wo nicht, meist nicht. Zweitens: Wo liegt der Engpass? Fehlt Übersicht, genügt ein schlankes Werkzeug. Fehlt Kapazitätsübersicht, spricht viel für Wrike oder die oberen Stufen von Teamwork.com. Fehlt Margentransparenz, ist die kaufmännische Kette entscheidend. Drittens: Wie sieht der bestehende Stack aus? Ein bereits lizenzierter, geprüfter Dienst und eine funktionierende Buchhaltungsschnittstelle haben realen Vorsprung. Viertens: Wie viel Buchungsdisziplin ist durchsetzbar? Diese Frage entscheidet mehr als jede Funktionsliste.
Bemerkenswert häufig führt diese Prüfung zu einer gemischten Antwort: eine kaufmännisch starke Plattform für die Bereiche mit Kundenabrechnung, ein schlankes Werkzeug für interne Vorhaben. Das ist kein Scheitern der Standardisierung, sondern eine bewusste Entscheidung — solange die Zuständigkeitsgrenzen dokumentiert sind und niemand dieselbe Arbeit doppelt führt.
Die erste und wichtigste Festlegung betrifft die Frage, was ein Projekt ist. In Dienstleistungsbetrieben konkurrieren drei Muster. Das Auftragsprojekt entspricht einem beauftragten Vorhaben mit eigenem Budget und ist das robusteste Muster, weil es der kaufmännischen Realität folgt. Das Kundenprojekt bündelt alle Arbeit eines Kunden dauerhaft und passt für Retainer und laufende Betreuung, macht aber Auswertungen je Auftrag schwieriger. Das Phasenprojekt schneidet größere Vorhaben in abrechenbare Abschnitte und ist in Ingenieur- und Planungsleistungen naheliegend. Wichtig ist nicht, welches Muster gewählt wird, sondern dass die Wahl bewusst, einheitlich und schriftlich erfolgt.
Daran hängen die weiteren Festlegungen: die Struktur der Aufgabenlisten als wiederkehrendes Raster für Leistungsblöcke, die Namenskonvention für Projekte samt Kunden- und Auftragskennung, die benutzerdefinierten Felder und die Stundensatzlogik. Bei Feldern gilt der Grundsatz der Sparsamkeit: nur anlegen, was für eine Entscheidung oder eine Auswertung gebraucht wird, und je Feld festlegen, wer es pflegt. Ein Pflichtfeld ohne verantwortliche Rolle bleibt leer oder wird mit Platzhaltern gefüllt — beides ist schlechter als kein Feld. Bei den Sätzen ist früh zu klären, ob nur Verkaufs- oder auch Kostensätze geführt werden, weil davon abhängt, ob später Erlöse oder Deckungsbeiträge ausgewertet werden können.
Die Plattform unterscheidet Zugriffsarten, die sich betriebswirtschaftlich erheblich unterscheiden: vollwertige Nutzer, eingeschränkte interne Rollen für Personen, die nur mitarbeiten oder mitlesen, sowie die Client Users für Auftraggeber. Diese Abstufung sauber zu nutzen, ist der wirksamste Hebel für Kostenkontrolle und Datenschutz gleichzeitig. Zwei Grundsätze haben sich bewährt. Erstens: Wer nur freigeben soll, braucht keinen Vollzugriff. Zweitens: Kundenzugänge werden vor der Freigabe mit einem Testkonto geprüft — nicht anhand der Dokumentation, sondern durch den Blick von außen auf ein echtes Projekt. Die Frage lautet konkret, ob Stundensätze, Schätzwerte, interne Kommentare, Auslastungen und andere Kunden tatsächlich unsichtbar sind.
Für interne Rechte gilt eine besondere Sensibilität, weil Zeitdaten personenbezogen sind. Wer keine Personenauswertung sehen muss, sollte sie nicht sehen können — technisch, nicht nur per Vereinbarung. Bewährt hat sich eine schlanke Rollenmatrix mit vier Stufen: Projektleitung mit Budget- und Zeitsicht für die eigenen Projekte, Bearbeitende mit Sicht auf die eigene Zeit, kaufmännische Rolle mit übergreifender Auswertung und Administration mit Strukturhoheit. Diese Matrix gehört dokumentiert und turnusmäßig geprüft, weil Rechte in der Praxis wachsen und nie von selbst schrumpfen.
Bei der Migration aus einem Vorsystem oder aus Tabellen ist die wichtigste Entscheidung, wie viel Vergangenheit mitkommt. Die pragmatische und in unseren Projekten bewährte Antwort: „laufende Aufträge vollständig, abgeschlossene gar nicht“. Abgeschlossene Projekte werden im Altsystem oder als Export archiviert, historische Zeitdaten nur dann übernommen, wenn sie für eine konkrete Auswertung oder eine offene Abrechnung wirklich gebraucht werden. Wer alles mitnimmt, importiert zusammen mit den Daten auch die Uneinheitlichkeit der Vergangenheit und beschädigt damit die Auswertbarkeit des neuen Systems von Tag eins an.
Technisch stehen Importwege über Dateien und über die Programmierschnittstelle zur Verfügung; Umfang und Grenzen je Objektart sind vorab zu prüfen, besonders bei Zeitbuchungen, Anhängen und Kommentaren. Organisatorisch entscheidend ist ein Stichtag: Ab einem festen Datum wird nur noch im neuen System gebucht, ohne Übergangsphase mit Doppelpflege. Parallelbetrieb über Wochen ist der zuverlässigste Weg, eine Einführung scheitern zu lassen, weil beide Systeme unvollständig bleiben und niemand mehr weiß, welche Zahl gilt.
Im laufenden Betrieb braucht die Plattform wenig, aber regelmäßige Pflege: eine benannte verantwortliche Person für Struktur, Felder, Vorlagen und Sätze; eine Freigaberegel für neue Automatisierungen und Integrationen; ein monatlicher Blick auf Projekte ohne Budget, Zeitbuchungen ohne Aufgabenbezug und Aufträge ohne Verantwortliche; ein halbjährliches Aufräumen mit Archivierung abgeschlossener Projekte, Entzug von Zugängen ausgeschiedener Personen und Prüfung der Kundenzugänge. Ein System, das gepflegt wird, bleibt glaubwürdig — und Glaubwürdigkeit ist die Voraussetzung dafür, dass Auswertungen Entscheidungen beeinflussen.
Das erste und häufigste Szenario ist die Agentur mit gemischtem Geschäftsmodell. Typisch ist ein Betrieb mit fünfzehn bis achtzig Mitarbeitenden, der Projektpauschalen, Retainer und Zeitaufwand nebeneinander abrechnet und dessen Geschäftsführung die eine Frage nicht sauber beantworten kann: Welcher Kunde bringt tatsächlich Geld? Die Kombination aus Projektbudget, Retainer-Kontingent, abrechenbarer Zeit und Auswertung liefert diese Antwort — regelmäßig mit unangenehmen Überraschungen bei genau den Kunden, die als „angenehm“ gelten, weil sie viel Aufmerksamkeit erhalten und selten reklamieren.
Das zweite Szenario ist der IT-Dienstleister mit Wartungs- und Projektgeschäft. Hier liegt der Nutzen in der Trennung zweier Welten, die im Alltag verschwimmen: vertraglich vereinbarte Wartungskontingente und beauftragte Projektleistungen. Wenn Zeit auf beides gebucht wird und Kontingente sichtbar sind, endet die dauerhafte Kulanzfalle, in der Zusatzleistungen im Wartungsvertrag verschwinden. Das dritte Szenario ist das Ingenieur- oder Planungsbüro, das Leistungsphasen kalkuliert und Nachträge belegen muss. Die dokumentierte Verbindung von Änderungswunsch, geleisteter Zeit und Freigabe ist dort weniger Verwaltung als Voraussetzung dafür, Nachträge überhaupt durchzusetzen.
Das vierte Szenario ist die Beratung mit Tagessatzlogik. Hier interessiert weniger die einzelne Aufgabe als die Auslastung der Beratenden und die Frage, ob ein Mandat im vereinbarten Volumen bleibt. Die Kapazitätssicht in Verbindung mit Budgets liefert beides und ersetzt die verbreitete Tabelle, die eine Person pflegt und deren Aktualität niemand prüfen kann.
Der wirtschaftlich größte Nutzen liegt in einer Betrachtung, die in vielen mittelständischen Dienstleistungsbetrieben nur grob oder gar nicht existiert: der Deckungsbeitragsrechnung je Auftrag. Die Logik ist schlicht. Auf der Erlösseite steht, was für den Auftrag vereinbart wurde — Pauschale, Kontingent oder Zeitverrechnung. Auf der Kostenseite stehen die geleisteten Stunden, bewertet mit Kostensätzen je Rolle oder Person, zuzüglich direkt zurechenbarer Fremdleistungen und Auslagen. Die Differenz ist der Deckungsbeitrag des Auftrags: der Betrag, mit dem dieser Auftrag zur Deckung der Gemeinkosten und zum Ergebnis beiträgt.
Der Wert dieser Rechnung liegt nicht in der Genauigkeit auf den Euro, sondern in der Rangfolge. Sobald Aufträge, Kunden und Leistungsarten nach Deckungsbeitrag sortiert vorliegen, werden Muster sichtbar, die dem Bauchgefühl regelmäßig widersprechen: der prestigeträchtige Großkunde mit vielen unbezahlten Abstimmungsrunden, die unscheinbare Leistungsart mit hervorragender Marge, der Retainer, der seit zwei Jahren stillschweigend um dreißig Prozent überzogen wird. Für diese Erkenntnisse braucht es keine perfekte Kostenrechnung, sondern gebuchte Zeit, hinterlegte Sätze und eine ehrliche Kennzeichnung der Abrechenbarkeit.
Drei Hinweise aus der Praxis. Erstens: Nicht abrechenbare Zeit ist die wichtigste Zahl. Sie zeigt, wie viel Leistung unbemerkt verschenkt wird, und ist der stärkste Ansatzpunkt für Verbesserung. Zweitens: Kostensätze müssen nicht exakt sein, aber einheitlich. Ein grober Satz je Rolle, jährlich überprüft, liefert brauchbare Vergleiche; personenindividuelle Sätze wirken präziser, sind aber im Betriebsrat und in der Pflege deutlich aufwendiger. Drittens: Die Auswertung braucht einen Adressaten und einen Rhythmus. Eine monatliche halbe Stunde, in der Geschäftsführung und Projektleitung dieselbe Liste ansehen und drei Entscheidungen treffen, erzeugt mehr Wirkung als das schönste Dashboard ohne Termin.
Es gibt Situationen, in denen wir ausdrücklich abraten. Die erste ist die Organisation ohne Abrechnungslogik: Wo keine Kundenprojekte verrechnet werden, bleibt die Hälfte der Plattform unbenutzt, und ein schlankeres Werkzeug liefert denselben Nutzen bei geringerem Aufwand. Die zweite ist die fehlende Bereitschaft zur Zeiterfassung. Ohne tägliche, vollständige Buchung fallen Budgetverbrauch, Auslastung und Marge aus — also genau die Funktionen, für die die Plattform gewählt wurde. Wer Zeiterfassung kulturell oder mitbestimmungsseitig nicht durchsetzen will oder kann, sollte diese Erwartung vorab streichen und die Entscheidung neu bewerten.
Die dritte Situation ist die Anforderung an Eigenbetrieb: Wo aus regulatorischen oder strategischen Gründen eine Installation im eigenen Rechenzentrum gefordert ist, kommt die Plattform nicht in Frage. Die vierte ist die Fehlbesetzung des Anwendungsfalls. Teamwork.com ist kein ERP, keine Software für Fertigungssteuerung, kein Ticketsystem für hohe Fallzahlen im Endkundensupport und kein Dokumentenmanagementsystem mit Aufbewahrungspflichten. Es lässt sich in all diesen Richtungen ein Stück weit biegen, aber jede Biegung erzeugt Sonderlogik, die niemand mehr wartet, wenn die Person geht, die sie gebaut hat. Diese Erkenntnis kommt meist erst nach zwei Jahren — und ist dann teuer zu korrigieren.
Eine belastbare Kalkulation umfasst deutlich mehr als den Preis je Nutzer und Monat. Der erste zusätzliche Posten ist die Editionswahl: Weil die entscheidenden Funktionen — Budgets, Sätze, Abrechenbarkeit, Auswertungen, Ressourcenplanung — typischerweise erst ab der mittleren Stufe verfügbar sind, ist der Einstiegspreis für die meisten Dienstleister nicht der relevante Preis. Der zweite Posten betrifft die Nutzerzählung: Wie werden gelegentliche Mitarbeitende, Freiberufler, Mitlesende und die Kundenzugänge gezählt? Hier bestehen im Markt erhebliche Modellunterschiede, und in Betrieben mit vielen externen Beteiligten entscheidet dieser Punkt die Rechnung.
Der dritte, regelmäßig unterschätzte Posten ist der Einführungs- und Betreuungsaufwand: Datenmodell, Vorlagen, Satzlogik, Formulare, Auswertungen, Migration, Schulung und laufende Pflege binden interne Kapazität oder externe Beratung. Bei einer Plattform mit kaufmännischer Tiefe ist dieser Anteil höher als bei einem schlanken Board-Werkzeug — kein Nachteil, sondern die Kehrseite des höheren Steuerungsnutzens, aber er sollte im Budget stehen. Der vierte Posten sind Integrationen, insbesondere die Anbindung an das deutsche Rechnungswesen, die häufig nicht als Standardverbindung vorliegt und Entwicklungs- oder iPaaS-Aufwand erzeugt. Und schließlich fällt einmalig der Aufwand für Datenschutzprüfung, Verarbeitungsverzeichnis und Mitbestimmungsabstimmung an — regelmäßig vergessen, aber real.
Die EU-Ansässigkeit des Anbieters ist ein substanzielles Argument und sollte auch so gewürdigt werden: Der Vertragspartner unterliegt europäischem Recht, unterhält keine unmittelbare Bindung an außereuropäische Zugriffsbefugnisse in derselben Weise wie ein Anbieter mit Sitz in einem Drittland, und die Kommunikation über Datenschutzthemen findet in einem gemeinsamen Rechtsverständnis statt. In Ausschreibungen und internen Freigabeprozessen verkürzt das erfahrungsgemäß die Diskussion erheblich.
Gleichzeitig ist der Sitz des Anbieters nicht identisch mit dem Ort der Verarbeitung. Zu prüfen und schriftlich zu bestätigen sind mindestens vier Punkte. Erstens der Serverstandort: In welcher Region werden Kundendaten gespeichert, gibt es eine wählbare Region, gilt diese Wahl für die vorgesehene Edition und für alle Datenarten? Zweitens die Unterauftragsverarbeiter: Welche Dienstleister werden eingesetzt — Infrastruktur, Mailversand, Support-, Analyse- und KI-Dienste — und wo verarbeiten diese? Drittens der Datentransfer: Findet Verarbeitung außerhalb der EU statt, etwa durch Support, Fernwartung oder nachgelagerte Dienste, und auf welcher Grundlage? Viertens die Auftragsverarbeitung selbst: Vertrag abschließen, technische und organisatorische Maßnahmen prüfen, die Liste der Unterauftragsverarbeiter beobachten und Änderungsmitteilungen tatsächlich lesen.
Zu unterscheiden ist außerdem zwischen Inhaltsdaten und Metadaten, Protokollen und Supportzugriffen, die abweichend geregelt sein können. Wer eine EU-Speicherung bestätigt bekommt, hat damit nicht automatisch eine Aussage über Protokolldaten oder über den Zugriff eines Supportteams. Ergänzend gehören Aufbewahrung, Löschung und Export geregelt: wann abgeschlossene Projekte archiviert und gelöscht werden, welche Fristen für Zeitdaten gelten und wie regelmäßig Exporte gezogen werden. Letzteres kostet wenig und rettet im Ernstfall — Anbieterwechsel, Vertragsende, Auskunftsersuchen — Wochen.
Weil die Plattform Zeitbuchungen je Person und Vorgang führt, Bearbeitungsverläufe protokolliert und Auslastung sowie Produktivität auswertbar macht, ist sie in besonderem Maße geeignet, Verhalten und Leistung von Beschäftigten zu überwachen — unabhängig davon, ob das beabsichtigt ist. Diese Eignung genügt: In deutschen Betrieben mit Betriebsrat löst sie die Mitbestimmung nach § 87 BetrVG aus, und bei einer Plattform, deren Kern die Zeiterfassung ist, deutlicher als bei reinen Aufgabenwerkzeugen. Der Umstand, dass Zeiterfassung arbeitsrechtlich ohnehin an Bedeutung gewonnen hat, ersetzt die Abstimmung über Auswertung und Zweckbindung nicht.
Der pragmatische Weg ist, die Arbeitnehmervertretung früh einzubinden — vor der Konfiguration, nicht nach dem Rollout — und in einer Betriebsvereinbarung festzuhalten, welche Auswertungen erstellt werden, auf welcher Aggregationsebene, wer sie einsehen darf, wie lange Daten aufbewahrt werden und was ausdrücklich ausgeschlossen ist. Bewährt hat sich die Zusicherung, dass Zeit-, Auslastungs- und Abrechenbarkeitsdaten für Projekt- und Teamsteuerung genutzt und nicht zur individuellen Leistungsbewertung herangezogen werden. Technisch unterstützen lässt sich das durch ein sparsames Rechtekonzept: Wer keine Personenauswertung sehen muss, sollte sie auch nicht sehen können. Für Österreich und die Schweiz gelten sinngemäß eigene Regelungen, die separat zu prüfen sind.
Zwei weitere Stellschrauben verdienen Aufmerksamkeit. Die erste ist die Datensparsamkeit im Inhalt: keine besonderen Kategorien personenbezogener Daten, keine Gesundheits- oder Bewerberdetails, keine vertraulichen Vertragsinhalte in Beschreibungen und Kommentaren — dafür sind Vorgänge nicht gedacht, und in Projekten mit Kundenzugängen ist das Risiko einer unbeabsichtigten Offenlegung real. Die zweite sind die Kundenzugänge selbst: Was ein Client User sieht, verlässt die eigene Organisation. Der Blick von außen auf ein echtes Projekt vor der Freigabe ist deshalb kein Formalismus, sondern Teil der Datenschutzprüfung.
