Der entscheidende Punkt vorab: awork ist kein universelles Arbeitsbetriebssystem. Es will weder Dokumentenmanagement noch Wissensdatenbank noch Chat-Plattform noch CRM sein. Es ist ein fokussiertes Werkzeug für Organisationen, deren Wertschöpfung in abgegrenzten Projekten und in bezahlter Arbeitszeit stattfindet. Genau diese Fokussierung ist sein Profil: Sie macht die Einführung schneller und die Oberfläche verständlicher, sie bedeutet aber auch, dass benachbarte Systeme weiterhin gebraucht und sauber angebunden werden müssen.
Drei Eigenschaften prägen awork als Plattform:
awork ist aus dem Agenturumfeld heraus entstanden, und das merkt man dem Produkt an. Wer selbst Projekte für Kunden abgewickelt hat, kennt die typischen Schmerzpunkte: Aufwände, die im Angebot kalkuliert wurden und im Projekt still davonlaufen. Mitarbeitende, die auf dem Papier zu 80 Prozent verplant sind und in Wahrheit drei Wochen im Rückstand liegen. Zeiterfassung, die niemand pflegt, weil sie in einem separaten Werkzeug stattfindet, das mit der eigentlichen Arbeit nichts zu tun hat. Am Monatsende dann der Versuch, aus Kalendereinträgen und Erinnerungen eine Rechnung zu rekonstruieren.
Die Antwort des Produkts auf diese Probleme ist Nähe: Die Zeit wird dort erfasst, wo die Aufgabe liegt. Der Plan wird dort sichtbar, wo die Kapazität steht. Das klingt selbstverständlich, ist es im Markt aber nicht – viele etablierte Werkzeuge trennen diese Welten und verbinden sie erst über Schnittstellen oder Exporte. Die zweite Antwort ist Zurückhaltung im Funktionsumfang. awork verzichtet bewusst auf viele Möglichkeiten, die breitere Plattformen anbieten, und gewinnt dadurch an Verständlichkeit. In Einführungsprojekten ist das ein realer Vorteil: Ein Werkzeug, das nach einer Stunde beherrschbar ist, wird benutzt; eines, das eine Schulungsreihe braucht, wird umgangen.
Wer awork verstehen will, sollte sich das zugrunde liegende Modell ansehen, denn es bestimmt später jede Auswertung. Im Zentrum stehen Projekte, die einem Kunden oder einer internen Organisationseinheit zugeordnet werden und einen Typ tragen – etwa Kundenprojekt, internes Vorhaben oder Wartungsvertrag. Innerhalb eines Projekts liegen Aufgaben, gegliedert in Listen oder Phasen, versehen mit Verantwortlichen, Terminen, geschätztem Aufwand und Status. An den Aufgaben hängen Zeitbuchungen, die Personen im Alltag erzeugen. Und über allem steht die Team- und Personensicht, die aus Terminen und geschätzten Aufwänden eine Auslastungskurve berechnet.
Diese Struktur hat eine praktische Konsequenz, die in Auswahlprojekten häufig unterschätzt wird: Die Qualität der Auswertungen hängt vollständig an der Disziplin bei der Schätzung und Erfassung. Ein Werkzeug kann keinen Soll-Ist-Vergleich liefern, wenn niemand ein Soll hinterlegt. Es kann keine Auslastung berechnen, wenn Aufgaben ohne Aufwand und ohne Termin angelegt werden. Wer awork einführt, führt deshalb nicht nur Software ein, sondern eine Arbeitsweise – und genau dort liegt der eigentliche Projektaufwand.
Aus unserer Beratungspraxis passt awork besonders gut zu drei Profilen. Erstens zu Agenturen und Kreativdienstleistern, die mehrere Kundenprojekte parallel führen, nach Aufwand oder Pauschale abrechnen und ein belastbares Bild ihrer Projektmargen brauchen. Zweitens zu technischen Dienstleistern – Ingenieur- und Planungsbüros, IT-Häuser, Beratungen –, deren Personalkapazität die knappe Ressource ist und deren Angebotsqualität davon abhängt, wie gut vergangene Projekte ausgewertet wurden. Drittens zu internen Projektteams im Mittelstand, die eine leichtgewichtige, deutschsprachige Alternative zu den großen US-Suiten suchen und dabei Wert auf europäische Datenverarbeitung legen.
Weniger zwingend ist awork dort, wo Projekte eine untergeordnete Rolle spielen und die eigentliche Arbeit in wiederkehrenden Prozessen stattfindet, wo eine sehr große Zahl von Nutzenden mit stark unterschiedlichen Rollen abgebildet werden muss oder wo eine tiefe Verzahnung mit Entwicklungswerkzeugen und Ticketsystemen im Vordergrund steht. In diesen Fällen sollten Sie den Zusatznutzen sorgfältig gegen die Kosten einer weiteren Werkzeugwelt abwägen.
Klarheit über die Grenzen verhindert Enttäuschung. awork ersetzt kein Dokumentenmanagement und keine Dateiablage im eigentlichen Sinn – Anhänge an Aufgaben sind kein Ersatz für eine strukturierte Ablage mit Versionierung und Aufbewahrungsfristen. Es ersetzt keinen Team-Messenger: Kommentare an Aufgaben sind projektbezogen und asynchron gedacht, nicht als Ersatz für die tägliche Abstimmung. Es ist kein CRM, auch wenn Kunden als Objekte existieren; Vertriebsprozesse, Angebotshistorie und Kontaktpflege gehören in ein anderes System. Und es ist keine Buchhaltung: Aus erfassten Zeiten entstehen Abrechnungsgrundlagen, nicht Rechnungen mit steuerlicher Wirkung.
Diese Abgrenzung sollten Sie vor der Einführung schriftlich festhalten. Eine kurze Tool-Governance, die auf einer Seite festlegt, welche Information wo lebt, verhindert die häufigste Folgeerscheinung von Werkzeugeinführungen: dass Wissen sich auf drei Systeme verteilt und niemand mehr weiß, welches die verbindliche Quelle ist.
Die Grundlogik der Lizenzierung folgt einem im Markt verbreiteten Muster: Bezahlt wird pro aktiver Person und Monat, wobei die Stufen sich vor allem in vier Dimensionen unterscheiden – im Umfang der Planungs- und Auswertungsfunktionen, in den Möglichkeiten der Automatisierung, in der Tiefe von Rechte- und Sicherheitseinstellungen sowie im Support- und Serviceniveau. Externe Beteiligte wie Kundinnen und Kunden lassen sich in der Regel eingeschränkt einbinden, ohne dass für sie eine vollwertige Lizenz nötig wird; die genauen Bedingungen dafür gehören in jedes Angebot.
Der wichtigste Unterschied zwischen den Ausbaustufen ist selten eine spektakuläre Einzelfunktion, sondern die Frage, ob das Werkzeug im Alltag steuerungsfähig wird. In der kleinsten Stufe erhält man eine ordentliche Aufgabenverwaltung mit angehängter Zeiterfassung – nützlich, aber im Kern austauschbar. Was awork von einer Aufgabenliste unterscheidet, sind die Auswertungen und die Vorausschau: der Vergleich von geplantem und erfasstem Aufwand, die Sicht auf die Auslastung der kommenden Wochen, die Zusammenfassung mehrerer Projekte in einem Portfolio. Genau diese Funktionen liegen typischerweise in den mittleren und oberen Stufen.
Zweiter relevanter Unterschied ist die Verwaltbarkeit. Rechtekonzepte, Anmeldung über den zentralen Identitätsdienst, Protokollierung administrativer Vorgänge und erweiterte Sicherheitseinstellungen sind für ein Team von acht Personen verzichtbar und für eine Organisation mit achtzig Personen eine Betriebsvoraussetzung. Prüfen Sie deshalb nicht die heutige Teamgröße, sondern die realistisch erwartbare Größe in zwei bis drei Jahren – ein Stufenwechsel mitten im laufenden Betrieb ist möglich, aber er kostet Aufmerksamkeit an einer Stelle, an der Sie sie nicht brauchen.
awork positioniert sich nicht als Konkurrent zu den breitesten Plattformen des Marktes, sondern als fokussiertes Werkzeug für projektbasierte Dienstleistung mit europäischer Herkunft. Die Argumentation ruht auf vier Säulen: die integrierte Verbindung von Aufgaben, Zeit und Kapazität; eine Oberfläche, die ohne Einarbeitungsprogramm bedienbar ist; deutschsprachige Produktoberfläche, Dokumentation und Support; sowie Datenverarbeitung im europäischen Rechtsraum. Das ist eine kohärente Positionierung, die eine klar umrissene Zielgruppe anspricht.
In der Praxis konkurriert das Produkt daher weniger mit den ganz großen Suiten als mit zwei anderen Optionen: mit der gewachsenen Eigenlösung aus Tabellen, Kalendern und einem separaten Zeiterfassungswerkzeug – und mit spezialisierten Branchenlösungen für Agentursteuerung oder Projektcontrolling, die tiefer in Richtung Abrechnung, Angebotswesen und Buchhaltung reichen, dafür aber schwerer, teurer und deutlich erklärungsbedürftiger sind. awork sitzt bewusst dazwischen: mehr Steuerung als eine Aufgabenliste, weniger Komplexität als eine ERP-nahe Branchenlösung.
Wenn Sie eine Auswahlentscheidung vorbereiten, sollten Sie awork nicht in einem generischen Funktionsvergleich gegen breite Plattformen antreten lassen. Ein solcher Vergleich fällt zwangsläufig zuungunsten des Spezialisten aus, weil er Kriterien enthält, die außerhalb des Produktumfangs liegen – Dokumentenverwaltung, Wissensdatenbanken, Formulare, Whiteboards, Chat. Sinnvoller ist ein Vergleich entlang der Fragen, die Ihr Geschäft tatsächlich belasten: Wissen wir am Monatsende, welche Projekte profitabel waren? Erkennen wir Überlastung, bevor Termine reißen? Können wir ein neues Angebot auf Erfahrungswerte stützen statt auf Bauchgefühl? Wer so vergleicht, erhält ein realistisches Bild – und trifft eine Entscheidung, die auch zwei Jahre später noch nachvollziehbar ist.
Diese Zurückhaltung ist Absicht. Jede zusätzliche Funktion erzeugt Erklärungsbedarf, Konfigurationsentscheidungen und potenzielle Wildwuchsquellen. In Organisationen, in denen Projektwerkzeuge bisher gescheitert sind, ist eine schlanke Oberfläche kein Mangel, sondern die Voraussetzung dafür, dass überhaupt jemand mitmacht. Die folgenden Bausteine machen den praktischen Alltag aus.
Die Mehrsichtigkeit ist ein Punkt, an dem Projektwerkzeuge im Alltag entweder überzeugen oder scheitern. Unterschiedliche Rollen brauchen unterschiedliche Darstellungen derselben Wirklichkeit: Eine Sachbearbeiterin will wissen, was heute zu tun ist, und braucht eine gefilterte Liste. Eine Projektleitung will Abhängigkeiten und Termine sehen und braucht einen Zeitstrahl. Die Geschäftsführung will wissen, ob das Portfolio in Schieflage gerät, und braucht eine Aggregation. Wenn ein Werkzeug diese Sichten nicht aus denselben Daten erzeugt, entstehen Parallelwelten – die berühmte Projektübersicht in der Tabellenkalkulation, die neben dem eigentlichen System gepflegt wird und ihm regelmäßig widerspricht.
Der zweite wichtige Baustein sind Vorlagen. In den meisten Dienstleistungsunternehmen ähneln sich Projekte stärker, als die Beteiligten glauben: Ein Website-Relaunch, eine Anlagenplanung, eine Systemeinführung folgt jeweils einem erkennbaren Muster. Wer dieses Muster einmal sauber als Vorlage abbildet, gewinnt dreifach. Die Projektanlage wird schneller. Die Struktur wird vergleichbar, was Auswertungen über Projekte hinweg erst ermöglicht. Und das implizite Erfahrungswissen erfahrener Kolleginnen und Kollegen wird explizit – neue Mitarbeitende erhalten mit der Vorlage eine Anleitung, wie ein Projekt in diesem Haus abläuft. Aus unserer Erfahrung ist die Vorlagenarbeit der Schritt mit dem besten Verhältnis von Aufwand zu Wirkung.
Die integrierte Zeiterfassung ist das stärkste funktionale Argument für awork und gleichzeitig der Punkt mit dem größten Widerstandspotenzial. Funktional ist die Sache klar: Zeiten lassen sich per Stoppuhr während der Arbeit erfassen oder nachträglich eintragen, sie hängen an einer konkreten Aufgabe in einem konkreten Projekt und tragen die Information, ob sie abrechenbar sind. Aus dieser Kette entsteht ohne Zusatzaufwand ein Soll-Ist-Vergleich je Aufgabe, je Phase, je Projekt und je Kunde.
Der wirtschaftliche Nutzen ist erheblich. Viele Dienstleister wissen erst nach der Schlussrechnung, ob ein Projekt profitabel war – und dann ist es für Gegenmaßnahmen zu spät. Mit laufender Erfassung verschiebt sich dieser Erkenntniszeitpunkt nach vorn: Wenn nach 40 Prozent der Projektlaufzeit bereits 70 Prozent des kalkulierten Aufwands verbraucht sind, lässt sich noch handeln – durch Nachverhandlung, Umpriorisierung oder eine Anpassung des Leistungsumfangs. Diese Frühwarnfunktion ist der eigentliche Wert, nicht die Rechnungsstellung.
Gleichzeitig gilt: Zeiterfassung ist in vielen Teams emotional besetzt. Sie wird als Kontrollinstrument wahrgenommen, und diese Sorge ist nicht unbegründet, weil sich die Daten grundsätzlich auch so verwenden ließen. Wer die Einführung ausschließlich technisch behandelt, erhält lückenhafte oder pauschal geschätzte Buchungen – also Zahlen, die schlechter sind als gar keine, weil sie Sicherheit vortäuschen. Wie sich das adressieren lässt, behandeln wir im Kapitel zur Einführung und im Kapitel zu Datenschutz und Mitbestimmung.
Die Auslastungssicht ist der Teil des Produkts, der in Vorführungen am wenigsten spektakulär wirkt und im Betrieb am meisten verändert. Sie beantwortet eine Frage, die in vielen mittelständischen Dienstleistern bis heute im Kopf einzelner Personen beantwortet wird: Können wir das neue Projekt im Mai überhaupt annehmen? Solange diese Frage auf Erfahrung und Bauchgefühl beruht, ist sie fehleranfällig – besonders dann, wenn mehrere Projektleitungen unabhängig voneinander dieselben Fachkräfte verplanen.
Damit die Kapazitätssicht trägt, braucht sie drei Zutaten: hinterlegte Arbeitszeiten und Abwesenheiten je Person, geschätzte Aufwände an den Aufgaben und realistische Termine. Fehlt eine davon, entsteht ein hübsches, aber wertloses Diagramm. Der pragmatische Weg in Projekten ist deshalb, nicht mit einer perfekten Schätzung zu starten, sondern mit einer groben Größenordnung je Aufgabe und einer klaren Verabredung, sie im Wochenrhythmus zu korrigieren. Nach wenigen Wochen ist die Kurve belastbar genug, um Entscheidungen zu tragen – und deutlich besser als die Alternative, gar nicht vorauszuschauen.
Auswertungen entfalten ihren Wert erst, wenn sie in einen Entscheidungsrhythmus eingebettet sind. Ein Dashboard, das niemand regelmäßig ansieht, ist reine Dekoration. Bewährt hat sich ein einfaches Muster: ein wöchentlicher Blick der Projektleitungen auf Fortschritt und Budgetverbrauch, ein monatlicher Blick der Geschäftsführung auf Portfolio und Auslastung, und ein Abschlussgespräch nach jedem größeren Projekt, in dem geplante und tatsächliche Aufwände nebeneinandergelegt werden.
Dieser dritte Punkt ist der wirtschaftlich wertvollste und wird am häufigsten ausgelassen. Die Nachkalkulation ist die einzige Quelle, aus der bessere Angebote entstehen. Wer nach drei Projekten derselben Art weiß, dass eine bestimmte Phase regelmäßig ein Drittel mehr Zeit kostet als kalkuliert, kann das im nächsten Angebot einpreisen – und muss die Differenz nicht länger aus der eigenen Marge bezahlen. Ein Werkzeug wie awork liefert dafür die Datenbasis; den Rhythmus müssen Sie organisieren.
Wichtig ist eine realistische Erwartung. KI in Projektwerkzeugen leistet heute vor allem Textarbeit auf strukturierten Daten: Sie zerlegt eine Beschreibung in Aufgaben, formuliert Zusammenfassungen, schlägt Zuordnungen vor, beantwortet Fragen zum Projektstand aus vorhandenen Einträgen. Was sie nicht leistet, ist eine belastbare Aufwandsschätzung aus dem Nichts oder eine Priorisierung, die Ihre geschäftlichen Abwägungen kennt. Wer das erwartet, wird enttäuscht – und wer es nicht erwartet, gewinnt an vielen kleinen Stellen Zeit.
Der praktisch relevanteste Beitrag liegt am Projektbeginn. Ein neues Vorhaben startet typischerweise mit einem Angebot, einem Protokoll oder einer Anforderungsliste in Textform. Aus diesem Text eine erste Projektstruktur mit Phasen und Aufgaben zu erzeugen, ist eine Aufgabe, die Sprachmodelle gut beherrschen. Das Ergebnis ist kein fertiger Projektplan, aber ein brauchbarer Entwurf, der von einer erfahrenen Person in zehn Minuten geschärft wird – statt dass diese Person eine Stunde lang eine leere Liste befüllt. Der Zeitgewinn ist real, der eigentliche Vorteil ist jedoch ein anderer: Es wird überhaupt strukturiert, weil die Einstiegshürde niedriger liegt.
Der zweite Bereich ist die Verdichtung. In einem Projekt mit hundert Aufgaben und laufenden Kommentaren ist es aufwendig, den aktuellen Stand für ein Kundengespräch zusammenzufassen. Eine automatisch erzeugte Zusammenfassung liefert dafür einen Ausgangspunkt. Behandeln Sie diese Ergebnisse jedoch konsequent als Entwurf: Zusammenfassungen können Wesentliches auslassen oder Zusammenhänge herstellen, die so nicht bestehen. Bevor eine solche Zusammenfassung an Kunden geht, gehört sie durch die Hände einer Person, die das Projekt kennt. Diese Regel sollte in Ihrer internen KI-Richtlinie stehen und nicht dem Einzelfall überlassen bleiben.
Ein dritter, weniger sichtbarer Bereich sind Vorschläge bei der Erfassung – etwa Hinweise auf passende Zuordnungen, das Ergänzen fehlender Angaben oder das Auffinden ähnlicher Vorgänge. Diese Funktionen sind unspektakulär und wirken genau deshalb: Sie senken die Reibung im Alltag, ohne dass jemand darüber nachdenken muss.
Deutlich unterschätzt gegenüber der KI-Diskussion sind klassische, regelbasierte Automationen. Sie folgen einem einfachen Muster aus Auslöser, Bedingung und Aktion und decken einen großen Teil der wiederkehrenden Handgriffe ab. Typische Beispiele aus Projekten im Mittelstand:
Ein Rat aus der Praxis: Automatisieren Sie erst, wenn der Prozess manuell einige Wochen stabil gelaufen ist. Wer eine Regel für einen Ablauf baut, den das Team noch verhandelt, zementiert einen Zwischenstand und muss ihn kurz darauf wieder abbauen. Und dokumentieren Sie jede Automation an einer zentralen Stelle mit Zweck und verantwortlicher Person – nichts irritiert neue Mitarbeitende mehr als ein System, das ohne erkennbaren Grund Dinge tut.
Der wirksamste Automatisierungshebel ist am wenigsten technisch. Eine gut gebaute Projektvorlage erspart bei jedem neuen Projekt Dutzende von Entscheidungen und Handgriffen, und sie tut es zuverlässiger als jede Regel, weil sie am Anfang steht und nicht auf einen Auslöser wartet. Wer regelmäßig ähnliche Projekte abwickelt, sollte deshalb einen halben Tag in die Vorlagenarbeit investieren, bevor er über KI-Funktionen nachdenkt.
Kombinieren lassen sich beide Ebenen sinnvoll: Die Vorlage liefert die stabile Struktur, die KI ergänzt sie um die projektspezifischen Besonderheiten aus dem Angebotstext, die Automationen halten den Ablauf danach in Bewegung. In dieser Reihenfolge – Struktur, Ergänzung, Bewegung – entsteht ein System, das trägt. In der umgekehrten Reihenfolge entsteht ein System, das beeindruckt und nach drei Monaten niemand mehr versteht.
Das Ökosystem ist erwartungsgemäß kleiner als das eines globalen Plattformanbieters mit eigenem App-Marktplatz. Dafür sind die vorhandenen Anbindungen diejenigen, die im mittelständischen Alltag tatsächlich zählen. Die folgende Einordnung beschreibt die Kategorien; die konkrete Verfügbarkeit und Tiefe einzelner Anbindungen sollten Sie für Ihre Ausbaustufe beim Anbieter verifizieren und im Testzugang praktisch prüfen.
Die Anbindung an die Kommunikationsplattform ist der wichtigste Integrationspunkt, weil sie über die Akzeptanz entscheidet. Wenn Benachrichtigungen dort ankommen, wo das Team ohnehin den ganzen Tag arbeitet, wird das Projektwerkzeug Teil des Alltags. Wenn sie in einem weiteren Postfach landen, entsteht ein zusätzlicher Ort, den man prüfen muss – und der schnell ignoriert wird.
Typischerweise umfasst eine solche Anbindung drei Richtungen: Benachrichtigungen aus Projekten in einen Kanal, das Anlegen von Aufgaben direkt aus einer Nachricht heraus und eine Vorschau, wenn ein Aufgabenlink geteilt wird. Besonders wertvoll ist die zweite Richtung. Der klassische Verlust im Projektalltag entsteht, wenn eine Anforderung im Chat besprochen wird, alle nicken und niemand sie in ein System überträgt. Ein Werkzeug, das die Übertragung auf zwei Klicks reduziert, verhindert genau diesen Verlust. Wie tief die Integration in Ihrem Fall reicht und ob sie an eine Ausbaustufe gebunden ist, klären Sie am besten praktisch in der Pilotphase. Zur Rolle der Kommunikationsplattform selbst finden Sie in dieser Kategorie eigene Artikel.
Die Kalenderanbindung sorgt dafür, dass Termine und Abwesenheiten aus dem persönlichen Kalender in der Planung sichtbar werden – und umgekehrt geplante Aufgaben im Kalender erscheinen. Das ist für die Auslastungssicht mehr als Komfort: Eine Kapazitätsrechnung, die den ganztägigen Workshop und den Urlaub nicht kennt, ist systematisch falsch. Prüfen Sie deshalb, in welche Richtung die Synchronisation läuft, wie häufig sie erfolgt und ob sie für Ihre Kalenderumgebung vollständig unterstützt wird.
Die E-Mail-Anbindung dient meist dem gleichen Zweck wie die Chat-Integration: aus einer eingehenden Nachricht eine Aufgabe machen, ohne den Inhalt manuell zu übertragen. Für Teams, deren Kundenkommunikation überwiegend per E-Mail läuft – im Mittelstand nach wie vor die Mehrheit –, ist das ein spürbarer Hebel. Bei der Dateiablage empfehlen wir eine klare Linie: Das Projektwerkzeug ist nicht die führende Ablage. Verlinken Sie Dokumente aus Ihrem Dateidienst oder Dokumentenmanagement, statt Dateien zu duplizieren. Sonst entstehen zwei Versionen desselben Dokuments, und die Frage, welche gilt, wird zum Dauerthema – mit Folgen für Aufbewahrungsfristen und Auskunftsfähigkeit.
Für Dienstleister ist dies der wirtschaftlich interessanteste Integrationspfad. Erfasste Zeiten sind die Grundlage für Rechnungen; Projektbudgets und Stundensätze bestimmen die Marge. In der Praxis sehen wir drei Muster, wie der Übergang in die kaufmännische Welt organisiert wird.
Zur häufig gestellten Frage nach DATEV: Der übliche Weg führt nicht direkt vom Projektwerkzeug in die Finanzbuchhaltung, sondern über das Rechnungs- oder Warenwirtschaftssystem, das die Belege erzeugt und an die Steuerberatung übergibt. awork liefert in dieser Kette die Leistungsgrundlage – also die abrechenbaren Zeiten und die Projektzuordnung. Klären Sie im Auswahlprozess ausdrücklich, welches System in Ihrer Kette die Rechnung erzeugt und welches Format Ihre Steuerberatung erwartet. Diese Frage früh zu stellen erspart eine unangenehme Entdeckung im ersten Monatsabschluss.
Für alles, wofür es keine fertige Anbindung gibt, bleiben zwei Wege. Der erste sind generische Automatisierungsdienste, die Ereignisse aus einem System in Aktionen in einem anderen übersetzen – ohne Programmierung, konfiguriert in einer Oberfläche. Typische Verkettungen im Mittelstand: Ein gewonnenes Angebot im CRM erzeugt automatisch ein Projekt aus der passenden Vorlage. Ein neuer Auftrag im Warenwirtschaftssystem legt die zugehörigen Aufgaben an. Ein abgeschlossenes Projekt löst eine Kundenzufriedenheitsabfrage aus.
Der zweite Weg ist die programmierbare Schnittstelle für Fälle, in denen die Standardbausteine nicht ausreichen – etwa bei der Anbindung einer Branchensoftware oder beim Aufbau eigener Auswertungen in einem Berichtswerkzeug. Prüfen Sie hier drei Dinge: den Funktionsumfang der Schnittstelle, die Qualität der Dokumentation und die Frage, ob der Zugriff an eine bestimmte Ausbaustufe gebunden ist. Und beachten Sie den gleichen Rat wie bei den Automationen: Erst die Struktur stabilisieren, dann programmieren. Eine Schnittstelle, die auf ein noch wanderndes Datenmodell zugreift, wird zum Wartungsfall.
Diese Mächtigkeit hat einen Preis, und er wird in Auswahlprojekten regelmäßig unterschätzt: Konfigurationsaufwand und Erklärungsbedarf. Eine breite Plattform verlangt Entscheidungen – über Strukturen, Felder, Sichten, Berechtigungen, Automatisierungen. Werden diese Entscheidungen nicht bewusst getroffen, entsteht innerhalb weniger Monate ein Flickenteppich, in dem jedes Team anders arbeitet und übergreifende Auswertungen unmöglich werden. awork bietet weniger Freiheitsgrade und nimmt Ihnen damit Entscheidungen ab. Für Organisationen ohne dedizierte Rolle für Werkzeugpflege ist das eher Vorteil als Nachteil.
Der zweite Unterschied betrifft die Zeit- und Kapazitätslogik. Bei den großen Plattformen sind Zeiterfassung und Auslastungsplanung meist an höhere Stufen gebunden oder werden über Zusatzprodukte gelöst. Wer sie braucht, landet damit häufig in einer teureren Stufe, als der reine Aufgabenbedarf rechtfertigen würde – ein Punkt, der beim Preisvergleich sorgfältig geprüft werden sollte, weil der Listenpreis der Einstiegsstufe irreführend sein kann.
awork unterscheidet sich von diesen Optionen vor allem durch die konsequente Ausrichtung auf den Dienstleistungsfall: Kunde, Projekt, abrechenbare Zeit, Auslastung. Wer diese Kette braucht, findet sie hier in einer ungewöhnlich geradlinigen Umsetzung. Wer sie nicht braucht, zahlt für Funktionen, die er nicht nutzt – und sollte eine der schlankeren Alternativen prüfen.
Zusammengefasst spricht für awork, wenn mindestens drei der folgenden Punkte auf Sie zutreffen: Ihre Wertschöpfung findet in abgegrenzten Projekten für Kunden oder interne Auftraggeber statt. Arbeitszeit ist Ihre zentrale Ressource, und Sie wollen wissen, wohin sie fließt. Personalkapazität ist Ihr Engpass, und Sie brauchen eine Vorausschau. Europäische Datenverarbeitung ist ein hartes Kriterium. Und Sie haben keine Rolle im Haus, die eine hochkonfigurierbare Plattform dauerhaft pflegen kann.
Gegen awork spricht, wenn Ihre Arbeit überwiegend in wiederkehrenden Prozessen statt in Projekten stattfindet, wenn Sie eine breite Plattform für sehr unterschiedliche Fachbereiche suchen, wenn eine tiefe Verzahnung mit Entwicklungs- oder Ticketsystemen erforderlich ist oder wenn Ihre Prozesse so speziell sind, dass sie hohe Anpassbarkeit verlangen. Diese Abwägung sollte dokumentiert werden – sie ist die beste Grundlage, um die Entscheidung später gegenüber Geschäftsführung und Belegschaft zu erklären.
Das folgende Vorgehen hat sich in Mittelstandsprojekten bewährt. Es beginnt bewusst nicht mit dem Werkzeug, sondern mit der Struktur, weil eine falsch aufgesetzte Projekt- und Kundenlogik später deutlich teurer zu korrigieren ist als eine Einstellung im System.
Die meisten mittelständischen Dienstleister kommen nicht von einem anderen Projektwerkzeug, sondern von einer gewachsenen Kombination: eine Tabellenkalkulation für die Projektübersicht, ein Board-Werkzeug für Aufgaben, ein separates System oder eine weitere Tabelle für Zeiten, dazu E-Mail und Kalender. Diese Ausgangslage hat einen Vorteil – es gibt wenig strukturierte Altdaten, die migriert werden müssen – und einen Nachteil: Es gibt auch wenig gemeinsame Begriffe.
Genau darin liegt die eigentliche Arbeit. Bevor Daten übertragen werden, muss geklärt sein, was ein Projekt ist, wann es beginnt und endet, was ein abgeschlossener Status bedeutet und welche Aufwände als abrechenbar gelten. In Organisationen, in denen jede Projektleitung ihre eigene Systematik entwickelt hat, ist diese Klärung ein Kraftakt – und der wertvollste Teil des gesamten Projekts, weil sie unabhängig vom Werkzeug wirkt.
Für die Migration selbst gilt ein pragmatischer Grundsatz: So wenig wie möglich mitnehmen. Laufende Projekte werden übertragen, abgeschlossene bleiben im Altsystem oder werden als Export archiviert. Historische Zeitbuchungen zu migrieren lohnt sich fast nie, weil ihre Struktur meist nicht zur neuen Systematik passt und sie damit ohnehin nicht auswertbar wären. Wer die Altwelt sauber einfriert und ein Enddatum für den Parallelbetrieb setzt, ist nach wenigen Wochen fertig. Wer beides dauerhaft nebeneinander betreibt, hat am Ende zwei unvollständige Systeme.
Das Rechtekonzept verdient mehr Aufmerksamkeit, als es üblicherweise bekommt – gerade weil es in einem Projektwerkzeug mit Zeitdaten sensible Fragen berührt. Vier Rollen decken den Alltag in den meisten mittelständischen Organisationen ab: Administration für Grundeinstellungen und Nutzerverwaltung, Projektleitung mit Planungs- und Auswertungsrechten im eigenen Projekt, Mitarbeitende mit Bearbeitungs- und Erfassungsrechten, sowie eine lesende Rolle für Geschäftsführung oder Controlling.
Zwei Fragen sollten Sie explizit entscheiden. Erstens: Wer darf Zeitdaten anderer Personen sehen? Die Antwort ist selten technisch, sondern eine Frage der Unternehmenskultur und der Mitbestimmung – und sie sollte vor dem Rollout getroffen und kommuniziert werden, nicht danach. Zweitens: Wie werden Kunden und freie Mitarbeitende eingebunden? Ein Kundenzugang auf ein Projekt kann Abstimmung erheblich vereinfachen, verlangt aber ein sauberes Rechtekonzept, damit keine internen Aufwände, Kalkulationen oder Kommentare zu anderen Kunden sichtbar werden. Prüfen Sie diesen Fall im Testzugang praktisch durch, statt sich auf die Beschreibung zu verlassen.
Der häufigste Grund, warum Projektwerkzeuge im Mittelstand scheitern, ist nicht die Software, sondern eine unbeantwortete Frage: Was habe ich davon? Für die Geschäftsführung ist der Nutzen offensichtlich – Transparenz, Steuerbarkeit, bessere Angebote. Für die Mitarbeitenden bedeutet die Einführung zunächst zusätzlichen Aufwand und ein Gefühl von Überwachung. Wer diese Asymmetrie nicht adressiert, erhält eine formale Nutzung ohne Substanz: Zeiten werden freitags pauschal nachgetragen, Aufgaben nicht gepflegt, Schätzungen nicht hinterlegt.
Drei Maßnahmen helfen erfahrungsgemäß. Erstens Transparenz über den Zweck: klar sagen, wofür die Daten verwendet werden und wofür ausdrücklich nicht – und diese Zusage schriftlich festhalten, idealerweise in einer Betriebsvereinbarung. Zweitens Nutzen für die Erfassenden sichtbar machen: Wenn erfasste Zeiten dazu führen, dass unrealistische Aufwandsvorgaben korrigiert und Überlastungen erkannt werden, ändert sich die Wahrnehmung vom Kontrollinstrument zum Schutzinstrument. Drittens Reibung minimieren: Erfassung dort, wo gearbeitet wird, mit wenigen Klicks und ohne Pflichtfelder, deren Sinn niemand erklären kann. Jedes zusätzliche Pflichtfeld kostet Datenqualität an anderer Stelle.
Ein letzter Punkt zum Betrieb: Benennen Sie eine verantwortliche Person für das Werkzeug – nicht in Vollzeit, aber mit klarem Auftrag. Sie pflegt Vorlagen, beantwortet Fragen, hält die Struktur sauber und schärft nach. Ohne diese Rolle driftet jedes Projektwerkzeug innerhalb eines Jahres auseinander, weil jedes Team beginnt, eigene Konventionen zu entwickeln.
Das klassische Szenario und zugleich der Ursprung des Produkts. Eine Agentur mit fünfzehn bis fünfzig Personen führt typischerweise dreißig bis achtzig aktive Projekte, verteilt auf wechselnde Teams aus Beratung, Konzeption, Gestaltung und Technik. Die Steuerungsprobleme ähneln sich unabhängig von der Größe: Projekte laufen über Budget, ohne dass es jemand rechtzeitig bemerkt; einzelne Personen sind chronisch überlastet, während andere Luft haben; und die Frage, ob ein Kunde langfristig profitabel ist, wird eher gefühlt als gerechnet.
Der Nutzen ist hier unmittelbar. Wenn jede Zeitbuchung einem Projekt und einem Kunden zugeordnet ist, entsteht nach wenigen Monaten ein Bild, das Gespräche verändert: Welche Kunden binden überproportional viel Beratungszeit, die nie in Rechnung gestellt wird? Welche Leistungsarten werden systematisch zu niedrig kalkuliert? Welche Projektart lohnt sich, welche nicht? Das sind unbequeme Fragen, und sie sind der eigentliche Ertrag der Einführung.
Wichtig ist dabei eine saubere Unterscheidung zwischen abrechenbarer und nicht abrechenbarer Zeit. Ohne diese Unterscheidung entsteht ein verzerrtes Bild, weil interne Arbeit, Vertrieb und Kulanzleistungen mit Kundenarbeit vermischt werden. Definieren Sie diese Kategorien früh und knapp – zwei bis drei Ausprägungen reichen. Wer ein fein verästeltes Kategoriensystem baut, erhält Buchungen, die nach dem Zufallsprinzip zugeordnet werden.
Planungsbüros arbeiten in längeren Zeiträumen und mit stärker formalisierten Phasen. Die Herausforderungen liegen anders: Projekte laufen über Monate oder Jahre, Fachkapazitäten sind knapp und nicht kurzfristig ersetzbar, und die Nachweisführung gegenüber Auftraggebern hat einen anderen Stellenwert. Die Phasenlogik von awork lässt sich hier gut auf die üblichen Leistungsphasen abbilden, sodass Aufwände phasenscharf ausgewertet werden können.
Der größte Hebel liegt in der Kapazitätsvorschau. Wenn drei Projektleitungen unabhängig voneinander dieselben Fachplanerinnen einplanen, entsteht ein Konflikt, der erst sichtbar wird, wenn Termine bereits zugesagt sind. Eine gemeinsame Auslastungssicht verhindert das – vorausgesetzt, alle Projekte laufen tatsächlich im System und nicht teilweise noch in Einzeltabellen. Genau hier scheitern Einführungen in Planungsbüros am häufigsten: an dem einen erfahrenen Kollegen, der bei seiner bewährten Tabelle bleibt und damit die Gesamtsicht unbrauchbar macht.
Ein zweiter Punkt betrifft Nachträge. Wenn Zusatzleistungen erfasst, aber nicht als solche gekennzeichnet werden, verschwinden sie in der allgemeinen Projektzeit und werden nicht abgerechnet. Ein eigener Projektbereich oder eine eigene Kennzeichnung für Nachträge ist deshalb kein Verwaltungsdetail, sondern unmittelbar erlösrelevant.
IT-Dienstleister haben eine Besonderheit: Sie führen Projektgeschäft und laufende Betreuung nebeneinander. Beides folgt unterschiedlicher Logik – das Projekt hat Anfang, Ende und Budget, die Betreuung läuft dauerhaft, oft mit einem monatlichen Kontingent. Beides in einem System zu führen ist möglich und sinnvoll, verlangt aber eine bewusste Modellierung: Wartungsverträge als eigener Projekttyp mit wiederkehrenden Aufgaben und einer klaren Kontingentbetrachtung, Projekte als klassische Vorhaben mit Phasen und Budget. Wer beides gleich behandelt, erhält Auswertungen, die keine der beiden Fragen sauber beantworten.
Bei internen Projektteams in produzierenden Unternehmen entfällt die Abrechnung, nicht aber der Nutzen. Digitalisierungsvorhaben, Zertifizierungsprojekte, Bau- und Umzugsvorhaben oder Organisationsveränderungen binden erhebliche Kapazität, die in keiner Kalkulation auftaucht, weil Personalkosten ohnehin anfallen. Die Erfassung macht sichtbar, was ein Vorhaben tatsächlich kostet – und liefert damit eine belastbare Grundlage für die Frage, ob ein weiteres Projekt parallel gestartet werden kann. Erfahrungsgemäß ist diese Erkenntnis für Geschäftsführungen die überraschendste: Der Engpass ist selten das Budget, fast immer die Aufmerksamkeit derselben zehn Personen.
Fünf Muster sehen wir immer wieder. Erstens zu viele Pflichtfelder: Jedes Feld, dessen Zweck nicht in einem Satz erklärbar ist, kostet Datenqualität. Zweitens zu feine Projektstrukturen: Wer jede Kleinigkeit als eigene Aufgabe führt, erzeugt Pflegeaufwand ohne Erkenntnisgewinn – eine Aufgabe sollte grob dem entsprechen, was eine Person an einem halben bis ganzen Tag erledigt. Drittens Parallelbetrieb ohne Enddatum: Solange die alte Tabelle noch existiert, wird sie genutzt. Viertens Auswertungen ohne Rhythmus: Ein Dashboard, das niemand regelmäßig ansieht, verändert nichts. Fünftens fehlende Kommunikation zum Zweck der Zeiterfassung – der sicherste Weg, Misstrauen zu erzeugen und die Datenqualität zu ruinieren.
Zunächst zu den Kosten. Die Gesamtkosten setzen sich aus vier Blöcken zusammen, von denen nur der erste auf dem Angebot steht:
Diesen Kosten steht ein Nutzen gegenüber, der sich benennen und nach zwölf Monaten überprüfen lässt: weniger unbemerkte Budgetüberschreitungen, vollständigere Abrechnung tatsächlich erbrachter Leistungen, bessere Angebotsschätzungen durch Nachkalkulation, weniger Überlastung durch frühzeitig erkannte Engpässe und ein deutlich geringerer Aufwand für die monatliche Rechnungsvorbereitung. Wir empfehlen, zwei oder drei dieser Erwartungen vor der Einführung schriftlich zu fixieren – das macht die Investition später belegbar.
Der Kern der Debatte um US-Anbieter ist die Frage möglicher behördlicher Zugriffe nach US-Recht, die auch dann greifen können, wenn Daten physisch in Europa liegen. Diese Diskussion ist bei allen großen US-Cloud-Anbietern strukturell gleich und wird über Vertragsklauseln, technische Maßnahmen und Transferfolgenabschätzungen adressiert – möglich, aber aufwendig, und im Ergebnis nie vollständig frei von Restrisiko.
Bei einem deutschen Anbieter mit europäischer Verarbeitung entfällt dieser Prüfstrang weitgehend. Es gibt keine Drittlandübermittlung zu bewerten, kein Bedürfnis nach zusätzlichen Garantien für einen Transfer und eine deutlich einfachere Argumentation gegenüber Datenschutzbeauftragten, Betriebsrat und Auftraggebern. Der letzte Punkt ist im Dienstleistungsgeschäft nicht zu unterschätzen: Wer für öffentliche Auftraggeber, Banken, Versicherungen oder Gesundheitseinrichtungen arbeitet, wird regelmäßig danach gefragt, in welchen Systemen Projektdaten des Auftraggebers verarbeitet werden. Eine kurze, saubere Antwort ist hier ein Vertriebsargument.
Wichtig ist die richtige Erwartung: Ein deutscher Anbieter macht die Nutzung nicht automatisch datenschutzkonform. Er beseitigt einen schwierigen Prüfpunkt, nicht die Pflicht zur ordentlichen Umsetzung. Die Verantwortung für Zwecke, Rechtsgrundlagen, Löschfristen, Berechtigungen und Transparenz bleibt vollständig bei Ihnen als verantwortlicher Stelle. Und mit KI-Funktionen kommt ein neuer Prüfpunkt hinzu, der ausdrücklich zu klären ist – auch dann, wenn das Grundprodukt europäisch verarbeitet wird.
Bei einem Werkzeug mit integrierter Zeiterfassung ist die Datenschutzfrage nicht die schwierigste – die schwierigere ist die arbeitsrechtliche. Systeme, die geeignet sind, Verhalten und Leistung von Beschäftigten zu überwachen, berühren in Betrieben mit Betriebsrat regelmäßig mitbestimmungspflichtige Tatbestände. Das gilt unabhängig davon, ob Sie eine Überwachung beabsichtigen; maßgeblich ist die Eignung des Systems.
Der pragmatische Weg ist, den Betriebsrat früh einzubinden – nicht als Genehmigungsinstanz am Ende, sondern als Beteiligten bei der Ausgestaltung. Eine Betriebsvereinbarung sollte mindestens vier Punkte regeln: welche Daten erfasst werden, wer sie in welcher Aggregationsstufe einsehen darf, wofür sie ausdrücklich nicht verwendet werden – insbesondere nicht für individuelle Leistungsbewertung – und wie lange sie aufbewahrt werden. Unsere Erfahrung ist eindeutig: Projekte mit früher Beteiligung sind schneller und ruhiger als solche, in denen die Beteiligung nachgeholt wird. Auch in Betrieben ohne Betriebsrat lohnt sich eine schriftliche, kommunizierte Selbstverpflichtung mit denselben Inhalten.
Fünf Punkte gehören in jede Einführung. Erstens der Auftragsverarbeitungsvertrag, abgeschlossen und im Verarbeitungsverzeichnis dokumentiert, einschließlich der Unterauftragsverarbeiter. Zweitens ein Berechtigungskonzept: Wer darf welche Projekte sehen, wer Zeitdaten anderer einsehen, wer auswerten, wer administrieren? Drittens Löschfristen: Wie lange bleiben Projektdaten und Zeitbuchungen erhalten, und was passiert mit den Daten ausgeschiedener Mitarbeitender? Viertens die Regelung für externe Zugänge: Welche Daten sehen Kunden oder freie Mitarbeitende, und wie werden Zugänge wieder entzogen? Fünftens eine kurze Richtlinie zu KI-Funktionen: welche Inhalte eingegeben werden dürfen und dass Ergebnisse vor externer Verwendung geprüft werden.
Ein besonderer Blick gilt der Frage, welche Kundendaten überhaupt im Projektwerkzeug landen. In Aufgabenbeschreibungen und Kommentaren sammeln sich mit der Zeit personenbezogene Daten von Kundenmitarbeitenden, gelegentlich auch vertrauliche Inhalte. Halten Sie in Ihrer Tool-Governance fest, welche Kategorien von Informationen dort nichts zu suchen haben – insbesondere besondere Datenkategorien, Zugangsdaten und Inhalte, die vertraglichen Geheimhaltungspflichten unterliegen.
