Warum deine Agentur kein neues Tool braucht — sondern eine Architektur

Das Tool-Chaos-Syndrom: 15 Tools, null Überblick

Asana für Projekte, Harvest für Zeit, Excel für Controlling, HubSpot für Leads, Slack für alles andere. Komplement: Confluence für Wikis, Google Drive für Dokumente, Figma für Design, GitHub für Code, zwei verschiedene Slack-Workspaces weil man die nicht mergen kann. Kommt dir bekannt vor?

Ich sehe das ständig. Eine 20-Person-Agentur mit 15 aktiven Abos. Die jährlichen Kosten liegen irgendwo zwischen €20.000 und €40.000. Niemand weiß genau, weil niemand alle Abos im Blick hat. Der Geschäftsführer bezahlt mit seinem Kreditkarte, die Projektmanagerin bucht über einen anderen Account, der Finance-Typ hat noch andere Dinge in einem dritten Account.

Aber das Geld ist nicht das Hauptproblem. Das Hauptproblem ist: Es gibt keine Single Source of Truth. Ein Projekt in Asana. Die Zeiten in Harvest. Die Rechnung sitzt in Excel. Der Kundenkontext in HubSpot. Wenn etwas nicht stimmt, weiß niemand, wo man schauen soll.

Die Daten sind verteilt. Das Team ist verstreut. Und die Integration ist ein Alptraum. Wenn eine Zeit in Harvest erfasst wird, muss sie irgendwie in Excel landen für das Controlling. Das geht über eine API-Integration, wenn man die bezahlt. Oder manual Copy-Paste. Beides ist fehlerträchtig.

Warum jedes neue Tool das Problem verschlimmert

Das ist das Tückische: Jedes neue Tool wird eingeführt, weil ein bestehendes Problem zu groß wird. Der Projektmanager sagt: "Asana funktioniert nicht, ich brauche bessere Resource-Planung." Also kauft man Monday.com. Jetzt sitzt das Ressourcen-Planung in Monday. Aber die Projekte sind immer noch in Asana. Wer synchronisiert das? Keiner. Zwei Wochen später haben beide Tools unterschiedliche Daten. Welcher stimmt? Keiner.

Das ist nicht ein Problem mit Tools. Das ist ein Problem mit Architektur. Du hast keine Architektur. Du hast eine Sammlung von Einzellösungen.

Echte Systemarchitektur sieht so aus: Es gibt eine Source of Truth. Das ist — für eine Agentur — typischerweise das Projektmanagement-System. Alles andere spricht mit diesem System. Zeit wird erfasst und fliesst automatisch ins PM-System (das ist der Grund für gute Zeiterfassung). Controlling pulls die Daten aus dem PM-System, nicht aus Excel — das ist echtes Projekt-Controlling. CRM-Informationen über den Client sind mit dem Projekt verknüpft, nicht in einer separaten Datenbank.

Das ist nicht kompliziert. Aber es erfordert, dass du nicht einfach Tools kaufst, sondern dass du erst deine Architektur definierst.

Was eine Tool-Architektur von einer Tool-Sammlung unterscheidet

Der Unterschied: Ein System hat eine Datenquelle. Eine Sammlung hat viele.

Konkret: In einem gut strukturierten System hat jede Datenbits genau einen Ort. Kunde XYZ sitzt im CRM. Ein Projekt für Kunde XYZ sitzt im PM-System. Zeiten für dieses Projekt sitzen in der Zeit-Erfassung. Aber alle sind miteinander verknüpft durch eine eindeutige ID. Wenn die Zeit erfasst ist, kann das Controlling-System automatisch sehen: Projekt XYZ hat 20 Stunden zu €75/h = €1.500 Kosten. Budget war €1.200. Wir sind über. Alert.

Das läuft ohne manuellen Eingriff.

In einer Tool-Sammlung: Stunden sind in Harvest. Der Controller exportiert sie als CSV. Importiert in Excel. Tippt die Kosten manuell ein. Vergisst, die neuesten Stunden zu importieren. Die Zahlen sind immer zwei Tage alt. Es ist langsam und fehleranfällig.

Architektur-Denken bedeutet: Du definierst erst, welche Daten wo leben. Dann schaust du, welche Tools das können. Nicht: Du schaust, welche tollen Tools es gibt, und fragst dich dann, wie man die zusammenklebt.

Das ist die umgekehrte Reihenfolge, aber sie ist richtig.

Die 4 Kernfunktionen die jede Agentur in einem System braucht

Es gibt vier Funktionen, die nicht optional sind. Alles andere ist optional.

Eins: Projekte. Ein Projekt hat einen Namen, einen Client, ein Start- und Enddatum, ein Budget. Der PM sieht alle Projekte, welche aktiv sind, welche kurz vor Abschluss. Das ist zentral.

Zwei: Zeit. Jede Stunde wird erfasst und mit einem Projekt verknüpft. Das passiert automatisch im System und es fließt direkt in die Controlling-Zahlen. Keine Manuelle Integration.

Drei: Controlling. Der CFO/Controller sieht: Dieses Projekt kostet X intern, bringt Y rein, Margin ist Z%. Das passiert automatisch aus den Daten von Projekten und Zeit. Keine Excel-Spielerei.

Vier: CRM-Basics. Minimales CRM. Wer ist der Client? Wer ist der Ansprechpartner? Kontaktdaten. Das System weiß, welcher Client welche Projekte hat. Das braucht es.

Alles andere — Marketing Automation, HR, Compliance, Customer Success — sind Zusätze. Schön zu haben. Aber nicht zentral.

Wenn diese vier Funktionen in einem System funktionieren und miteinander sprechen, läuft deine Agentur. Andere Tools können drumherum existieren, aber diese vier sind das Rückgrat. Ein regelmäßiges Tool-Audit hilft dabei, die Architektur sauber zu halten.

Case Study: Von 12 Tools auf 3

Ein IT-Dienstleister, den ich kenne, hatte das klassische Tool-Chaos. Bit.bucket, JIRA, Asana, Harvest, Stripe, HubSpot, Calendly, Notion, Google Drive, Slack, QuickBooks, Expensify. Das war nicht abnormal. Das war Standard.

Wir haben eine Architektur gebaut. Vier Kernfunktionen. Dann geguckt: Welche zwei, drei Tools können das alles? Sie sind bei Leadtime gelandet (ja, unser eigenes System, aber ich wäre nicht ehrlich, wenn ich nicht sagen würde: Es ist gut für diese Aufgabe). Für Code-Verwaltung brauchten sie GitHub. Für Support brauchten sie noch einen Helpdesk (Zendesk). Das war es. Weg von 12 Tools auf 3.

Die Einsparungen: €300/Monat weniger Tool-Kosten. Das ist nicht wild. Das ist aber nicht der Punkt. Der Punkt ist: Der Finance-Typ braucht nicht mehr vier Stunden pro Monat für Datenabstimmung. Die PMs haben einen Single Pane of Glass für ihre Arbeit. Die Sales sehen, welche Kunden in welchen Projekten stecken. Das ist Produktivität.

Das Team-Feedback war interessant. Die erste Woche war frustrierend. Neue Tools sind immer frustrierend. Nach zwei Wochen merkte das Team: Aha, das ist tatsächlich weniger Arbeit. Ich brauche nicht mehr zwischen Systemen zu springern. Nach einem Monat wollten sie nicht mehr zurück.

Brauchst du ein neues Tool oder eine neue Struktur?

Bevor du das nächste Tool evaluierst, beantworte diese Fragen:

Frage 1: Wenn diese Problem in meinem nächsten Team-Meeting erzähle, werden alle nicken oder streiten?

Nicken = echtes Problem
Streiten = einzelnes Problem mit einer Person

Frage 2: Kann das aktuelle Tool nicht das können, oder nutzt das Team es nicht?

Nicht können = Tool-Problem
Nicht nutzen = Prozess-Problem, neues Tool hilft nicht

Frage 3: Welche anderen Tools müssten mit dem neuen Tool sprechen?

0-1 Integrationen = okay, ein neues Tool einführen
2+ Integrationen = Stop, du hast ein Architektur-Problem, nicht ein Tool-Problem

Frage 4: Wer ist der Owner dieses neuen Tools?

Ein klarer Owner = kann funktionieren
Niemand / alle = wird nicht funktionieren

Frage 5: Kostet das neue Tool weniger als 30% der Zeit-Einsparung, die du erwartest?

Ja = wirtschaftlich sinnvoll
Nein = wahrscheinlich Überteuerung

Wenn du mehr als zwei „Architektur-Problem"-Antworten hast, brauchst du keine neuen Tools. Du brauchst eine Architektur-Überholung.

Das ist nicht sexy. Aber es ist billiger und funktioniert besser.