Tool-Audit für Unternehmen — In 5 Schritten vom Chaos zur klaren Systemlandschaft

Warum du wahrscheinlich für Tools bezahlst, die niemand nutzt

Die durchschnittliche Agentur mit 20 Mitarbeitern zahlt für 12-15 SaaS-Tools. Vier bis fünf davon nutzt niemand regelmäßig. Eine davon kennt nicht mal die Geschäftsführung.

Das ist keine böse Absicht. Es ist Normalzustand. Jemand hat ein Problem. Er sucht eine Lösung. Findet einen Tool. Die Lizenz läuft. Ein Jahr später vergisst man, dass man sie hat. Ein anderer Mensch hatte das gleiche Problem und hat einen anderen Tool gekauft. Jetzt habt ihr zwei Tools für ein Problem.

Bei eins+null hatten wir diese Situation: 18 Mitarbeiter, 13 Lizenzen, davon 3 die keiner nutzte. Das ist nicht dramatisch. Aber es ist dumm. Die Kosten waren moderat — aber psychologisch war es ein Signal: Wir verwalten unsere Ressourcen nicht bewusst.

Die typische Situation ist so: Ihr habt Jira für Task-Management. Dann brauchte Marketing auch ein Tool für ihre Workflows. Sie kauften Asana. Der Entwickler brauchte Linear weil das schneller ist als Jira. Jetzt habt ihr drei Task-Management-Tools. Keiner reden mit dem anderen. Die Wahrheit ist verteilt über drei Systeme.

Das kostet nicht nur Geld. Das kostet Prozesse. Wer ist responsible? Wer sieht den vollständigen Status? Wer weiß überhaupt was alle Kunden brauchen?

Schritt 1: Bestandsaufnahme — alle Tools, alle Kosten, alle Nutzer

Pack alles auf einen Tisch. Keine Relativierungen. Keine "ja aber". Nur Fakten.

Wie du das machst:

Erstelle eine Tabelle mit diesen Spalten:

Tool-Name
Kategorie (Projekt-Management, CRM, Kommunikation, Finance, etc.)
Kosten/Monat
Kosten/Jahr
Anzahl Lizenzen
Anzahl aktive Nutzer (nicht "sollte" nutzen, sondern "nutzt es tatsächlich")
Wer hat das Tool bestellt?
Wann wurde es bestellt?
Login letzte Woche genutzt? (ja/nein)

Bei eins+null haben wir das mit den Geschäftsführern und dem Ops-Manager gemacht. Es hat ein Tag gedauert. Das Ergebnis war überraschend: Einige Tools hatten wir vollständig vergessen. Andere nutzten nur zwei Personen obwohl wir für zehn zahlten.

Die ehrliche Frage, die du dann stellen musst: "Wenn wir diesen Tool morgen streichen würden — wer würde sich beschweren?"

Wenn die Antwort "keiner" ist: Das Tool ist weg.

Wenn die Antwort "aber wir brauchen das für Feature XYZ" ist: Notier dir das. Das brauchen wir für Schritt zwei.

Schritt 2: Funktions-Mapping — was muss bleiben, was kann weg?

Jetzt wird es strategisch. Nicht: "Was für Tools haben wir?" Sondern: "Welche Funktionen brauchen wir wirklich?"

Das ist der klassische Fehler: Unternehmen optimieren auf Tools statt auf Funktionen. Dein Ziel ist nicht "Asana" zu haben. Dein Ziel ist "Aufgaben tracken und Stakeholder informieren" zu haben.

Funktions-Kategorien für Agenturen:

Projekt-Management: Wer arbeitet woran? Was ist der Status? Was sind die nächsten Schritte?
Zeiterfassung: Wie viel Zeit zahlt der Kunde? Wie effizient arbeiten wir?
Kommunikation: Slack, Teams, oder Email — wie spricht das Team miteinander?
Client-Verwaltung: Wer sind die Ansprechpartner? Was haben wir zugesagt?
Finance: Invoicing. Budgets. Gewinn und Verlust.
Knowledge-Management: Wo liegen die Dokumentation? Wer weiß was?
Entwicklung: Git, CI/CD, Testing — wie wird Code gebaut und deployed?

Das ist deine Matrix. Für jede Funktion fragst du: Brauchen wir das? Ja oder nein? Keine Grauzone.

Wenn "Ja": Welches Tool macht das am besten für unser Budget? Welches Tool kennt unser Team?

Wenn "Nein": Finger weg.

Bei eins+null haben wir für Projekt-Management gehört: "Aber wir haben vier Jahre Daten in Jira!"

Das ist nicht relevant. Historische Daten sind schön. Aber wenn Jira heute nicht den Anforderungen genügt, dann bist du beim Falsch-Tool.

Schritt 3: Konsolidierung — welche Tools können zusammengelegt werden?

Drei verbundene Tools schlagen fünfzehn isolierte. Immer. Die Integrations-Fähigkeit ist unterschätzt.

Ein Beispiel: Ihr habt Slack, Google Calendar, Asana, und Figma. Alle vier sind gute Tools. Aber wenn Figma mit Asana spricht, und Asana mit Slack, und Slack mit Calendar — dann entstehen Workflows die sonst nicht möglich wären. Ein Design-Handoff ist automatisiert. Ein Meeting ist automatisch gebucht wenn eine Deadline kommt. Das ist Systemkraft.

Ein anderes Beispiel aus der Praxis: CRM + Invoicing. Zwei getrennte Tools. Der Kontakt sitzt doppelt. Eine Änderung in einem Tool wird nicht reflektiert im anderen. Das ist inkohärent.

Was sollte zusammen sein:

Project-Management + Zeiterfassung: Die beste Lösung ist eins. Asana hat das. Linear hat das nicht. Das ist ein Argument für Asana für euch.
CRM + Finance: Die beste Lösung ist eins. HubSpot + Invoicing, oder Pipedrive + Invoicing. Nicht zwei Tools.
Knowledge-Management + Dokumentation: Notion oder Confluence. Nicht Notion für Wissen und Google Docs für Dokumentation.
Kommunikation + Notifications: Slack mit Integrationen schlägt "Slack + Benachrichtigungen aus fünf Tools".

Die Regel: Wenn zwei Tools die gleiche Person beschreiben — zusammenlegen.

Der Kontakt sitzt zweimal (CRM und Invoicing). Die Task sitzt zweimal (Asana und Slack). Die Rechnung sitzt zweimal (Invoicing und Email). Das ist technische Schuld.

Schritt 4: Migration planen — ohne den Betrieb zu stören

Die beste Architektur nützt nichts, wenn die Migration dein Team lahmlegt.

Die typische Situation: Wir wollen weg von Jira. Aber wir haben vier Jahre Daten. Wie exportieren wir das? Was tun mit den historischen Issues? Und der Wechsel — da geht ja zwei Wochen Arbeit verloren, weil keiner Linear kann.

Das ist schiefgegangen, wenn ihr es so macht: "Migration-Wochenende. Alle zu Hause. Der Ops-Manager migriert alles. Montag früh nutzen wir nur noch Linear." Das ist ein Disaster.

Besser so:

Parallelbetrieb: Neue Tool läuft parallel zur alten. Vier Wochen Parallelbetrieb. Alles Neue geht in den neuen Tool. Der alte Tool wird nur noch gelesen.
Training: Alle Nutzer haben zwei Stunden Training. Nicht "hier ist der neue Tool", sondern "wie arbeiten wir konkret damit?" Mit Workflows die sie kennen.
Historische Daten: Die vier Jahre Jira-Daten bleiben in Jira. Du brauchst sie nicht in Linear. Wenn jemand historisches brauchst, kennt er wo er guckt.
Cutover: Nach vier Wochen: Der alte Tool wird read-only. Alle neuen Projekte und Tasks sind im neuen Tool.

Die Kosten sind eine Woche Ops-Zeit plus zwei Stunden Training pro Person. Das ist überschaubar.

Migrations-Reihenfolge: Nicht alles gleichzeitig.

Einfache Tools zuerst (Kommunikation, Knowledge). Das ist niedrig-risiko.
Danach project-management oder CRM. Das ist medium-risiko.
Finance-Tools zuletzt. Das ist high-risk, braucht Compliance, braucht Audit-Trail.

Bei eins+null haben wir so gemacht: Erst Slack (einfach), dann Linear (mittel), dann HubSpot+Invoicing (risiko). Das hat funktioniert weil das Team nicht überlastet war.

Schritt 5: Review-Rhythmus etablieren (nie wieder Tool-Wildwuchs)

Einmal aufräumen reicht nicht. Du brauchst einen Rhythmus, sonst befindest du dich in einem Jahr wieder in der gleichen Situation.

Der Quartals-Review:

Jeden März, Juni, September, Dezember — eine Stunde mit den Key Usern:

Welche Tools haben wir?
Nutzt jemand sie nicht?
Gibt es Duplikationen?
Sind wir überzufrieden oder Schmerz mit einem Tool?

Das ist eine Routine. Nicht als Einmaßnahme.

Genehmigungsprozess für neue Tools:

Das ist wichtig: Wenn jemand einen neuen Tool kaufen möchte, braucht es Genehmigung. Keine Genehmigung der GmbH. Genehmigung der Funktion: "Wir haben schon ein Tool der die Funktion macht. Warum der neuen?"

Wenn kein existierendes Tool die Funktion macht, dann gibt es einen Proof-of-Concept: 30 Tage Trial. Wenn es nach 30 Tagen nicht besser ist als die Alternative, dann kommt es in die Ablage.

Das spart euch echtes Geld.

Bei eins+null haben wir mit diesem Review-Rhythmus 5-6 tote Tools pro Jahr identifiziert. Das sind 400-500 Euro pro Monat. Im Jahr 5.000-6.000 Euro. Nicht dramatisch. Aber es ist auch nicht nichts. Und mehr noch: Es ist psychologisch sauberer. Das Team arbeitet mit Werkzeugen die sie tatsächlich nutzen.

Die Kosten-Realität: Was es wirklich kostet

Das Tool-Audit selbst kostet dich 1-2 Tage interne Zeit. Wenn du extern jemanden holst (wie unseren Service) dann 2.000-3.000 Euro.

Der ROI:

Durchschnittliche Ersparnisse im ersten Jahr: 3.000-8.000 Euro (abhängig von Größe und Tool-Wildwuchs).
Ersparnisse laufend: 200-400 Euro/Monat weil du die Routine hast.
Nicht-monetär: Bessere Workflows. Weniger Friction. Team-Produktivität steigt weil es nicht fünf verschiedene Systeme jongliert.

Das ist ein Low-Risk-Projekt mit garantiertem ROI.

Fazit: Das nächste Quartal beginnt jetzt

Dein nächster Schritt: Schreib auf — alle Tools, alle Kosten. Schau dir die Liste an. Frag dich: "Wenn wir drei Tools streichen müssten — welche würden es sein?"

Wenn die Antwort nicht augenblicklich klar ist — dann hast du zu viele Tools.

Fang mit Schritt Eins an. Eine Stunde. Das ist alles was du brauchst um zu sehen, wo die Ineffizienz sitzt.