Der entscheidende Punkt vorab: factro ist kein Task-Board mit Projektfunktionen, sondern ein Projektwerkzeug mit Board-Ansicht. Dieser Unterschied klingt akademisch, entscheidet in der Praxis aber darüber, ob ein Werkzeug zu einer Organisation passt. Wer aus der Welt einfacher Kanban-Tafeln kommt, erlebt factro als strukturierter und zunächst anspruchsvoller. Wer aus der Welt klassischer Projektplanung kommt, erlebt es als deutlich zugänglicher und schneller einsetzbar als eine ausgewachsene Planungssoftware. Genau in dieser Mitte liegt die Positionierung.
Drei Eigenschaften prägen die Software als Ganzes:
factro ist nicht als Produkt eines Software-Start-ups entstanden, sondern aus der Beratungspraxis heraus. Die Schuchert Managementberatung begleitet Organisationen bei Führungs-, Projekt- und Veränderungsthemen – und aus dieser Arbeit stammt die Erfahrung, woran Projekte im Mittelstand tatsächlich scheitern. Selten an fehlender Software. Häufig daran, dass niemand verbindlich weiß, wer bis wann was liefert, und dass der Stand eines Vorhabens erst im Statusmeeting mühsam rekonstruiert wird.
Diese Prägung ist im Produkt sichtbar. Die Software drängt zu Klarheit: Jede Aufgabe hat genau eine verantwortliche Person, Termine sind explizit, der Fortschritt wird gepflegt und rollt in der Struktur nach oben. Das ist kein technisches Detail, sondern eine methodische Haltung. Wer ein Werkzeug sucht, das jede Arbeitsweise gleichermaßen unterstützt, wird diese Haltung als Einschränkung empfinden. Wer ein Werkzeug sucht, das eine gute Arbeitsweise unterstützt und eine schlechte sichtbar macht, wird sie als Vorteil erleben.
In unseren Projekten war das oft der eigentliche Nutzen: Nicht die Software hat die Projektarbeit verbessert, sondern die Notwendigkeit, vor der Nutzung zu klären, wie ein Projekt eigentlich strukturiert ist. Ein Werkzeug, das diese Klärung erzwingt, wirkt anders als eines, das jede Unschärfe geduldig abbildet.
Der Projektstrukturbaum – in der Fachliteratur auch als Projektstrukturplan bekannt – ist eines der ältesten und robustesten Werkzeuge der Projektarbeit. Die Idee ist einfach: Ein großes Vorhaben wird so lange in kleinere Bestandteile zerlegt, bis jeder Bestandteil überschaubar, schätzbar und einer Person zuordenbar ist. Was dabei entsteht, ist eine Landkarte des Projekts, die zwei Fragen gleichzeitig beantwortet: Was gehört alles dazu? Und wer kümmert sich darum?
In vielen digitalen Werkzeugen ist diese Hierarchie nur schwach ausgeprägt. Es gibt Listen, Boards, vielleicht Unteraufgaben – aber die Struktur bleibt flach und die Übersicht geht mit wachsender Aufgabenzahl verloren. factro dreht die Priorität um: Die Hierarchie ist das Primäre, Board und Zeitstrahl sind Ableitungen. Für Projekte mit dreißig, hundert oder mehreren hundert Aufgaben ist das ein spürbarer Unterschied, weil sich die Menge auf den jeweils relevanten Zweig eingrenzen lässt.
Die Kehrseite ist Ehrlichkeit wert: Diese Struktur muss jemand anlegen und pflegen. Ein Team, das gewohnt ist, Aufgaben einfach in eine Spalte zu werfen, empfindet den Baum zunächst als Mehraufwand. Dieser Aufwand zahlt sich erst aus, wenn Projekte eine gewisse Größe erreichen oder wenn mehrere Projekte gleichzeitig gesteuert werden müssen. Bei drei Aufgaben ist jede Struktur überflüssig – bei dreihundert ist sie überlebenswichtig.
Aus unserer Beratungspraxis passt factro besonders gut zu drei Profilen. Erstens zu mittelständischen Organisationen, die Projekte mit klarem Anfang, Ende und Lieferergebnis führen – Bauvorhaben, Anlagenprojekte, Produktentwicklungen, Beratungsmandate, Einführungsprojekte. Zweitens zu Organisationen, die von Excel-Listen und Mail-Abstimmung auf ein gemeinsames Werkzeug wechseln wollen, ohne gleich eine schwergewichtige Planungssoftware einzuführen. Drittens zu Bereichen, in denen Datenhoheit ein hartes Kriterium ist und ein deutscher Anbieter die interne Abstimmung erheblich verkürzt.
Weniger zwingend ist factro dort, wo Arbeit überwiegend als kontinuierlicher Fluss ohne Projektcharakter anfällt, wo agile Produktentwicklung mit Backlogs, Sprints und Entwicklerwerkzeugen im Vordergrund steht, oder wo bereits eine umfassende Plattform genutzt wird, in der Projekte lediglich ein Modul unter vielen sind. 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. factro ist kein ERP-System, keine Finanzbuchhaltung, kein CRM und keine Dokumentenmanagement-Lösung. Es ersetzt weder die Zeitwirtschaft der Personalabteilung noch eine Fachanwendung für Kalkulation oder Angebotswesen. Auch ein vollwertiges Multiprojekt-Portfoliomanagement mit Szenariorechnung, Kapazitätsoptimierung und tiefer kaufmännischer Verrechnung, wie es spezialisierte Produkte bieten, sollten Sie nicht voraussetzen, sondern für Ihren Bedarf konkret prüfen.
Was factro sein will, ist der Ort, an dem Projektarbeit sichtbar wird: Struktur, Aufgaben, Termine, Verantwortung, Fortschritt, Aufwand. Wer das als Aufgabe des Werkzeugs akzeptiert und die angrenzenden Systeme dort belässt, wo sie hingehören, kommt in Einführungsprojekten deutlich schneller voran als jemand, der eine einzige Plattform für alles sucht.
Die Lizenzlogik folgt einem im Markt verbreiteten Muster: Bezahlt wird pro Nutzerin und Nutzer und Monat, abgestuft nach Funktionsumfang. Zwischen den Stufen unterscheiden sich vor allem die verfügbaren Sichten und Auswertungen, die Tiefe des Rollen- und Rechtemodells, der Umfang von Zeiterfassung und Reporting sowie Schnittstellen und Supportzusagen. Die konkreten Grenzen sollten Sie in einem aktuellen, schriftlichen Angebot verbindlich klären – insbesondere, welche Funktionen Ihre Anwendergruppen tatsächlich benötigen und ob unterschiedliche Stufen innerhalb einer Organisation kombinierbar sind.
Der wichtigste Unterschied zwischen den Ausbaustufen ist selten eine spektakuläre Einzelfunktion, sondern die Frage, ab wann Steuerung möglich wird. Für ein einzelnes Team reicht oft eine kleine Stufe: Aufgaben verteilen, Termine halten, Fortschritt sehen. Sobald jedoch eine Geschäftsführung oder Projektleitung wissen will, wie es über mehrere Projekte hinweg aussieht, wer überlastet ist und wo geplante und tatsächliche Aufwände auseinanderlaufen, verschiebt sich der Bedarf zu Auswertungen, Zeiterfassung und einem belastbaren Rechtemodell.
Zweiter relevanter Unterschied ist die Differenzierung der Rechte. In kleinen Stufen genügt häufig die Unterscheidung zwischen Mitarbeitenden und Administration. In größeren Organisationen wird es feiner: Wer darf Projekte anlegen, wer nur Aufgaben bearbeiten, wer Aufwände sehen, wer Auswertungen über fremde Bereiche ziehen? Diese Fragen wirken bürokratisch, entscheiden aber darüber, ob eine Software unternehmensweit akzeptiert wird. Klären Sie sie vor der Wahl der Stufe, nicht danach.
Ein praktischer Hinweis aus Projekten: Prüfen Sie früh, ob innerhalb Ihrer Organisation unterschiedliche Nutzerarten sinnvoll sind. Nicht jede Person, die eine Aufgabe erledigt, braucht Planungsrechte. Wenn eine Software eine schlanke Nutzerrolle für reine Bearbeitende anbietet, verändert das die Gesamtkalkulation spürbar. Ob und in welcher Form das für Ihr Paket gilt, lassen Sie sich schriftlich bestätigen.
factro positioniert sich in einer Lücke, die im DACH-Markt tatsächlich existiert: zwischen den leichtgewichtigen internationalen Aufgabenwerkzeugen und der schwergewichtigen klassischen Projektplanung. Auf der einen Seite stehen Produkte, die schnell eingeführt sind, aber bei komplexeren Vorhaben an Struktur verlieren. Auf der anderen Seite stehen Planungswerkzeuge mit großer methodischer Tiefe, deren Einführung jedoch Zeit, Schulung und häufig eine eigene Rolle im Unternehmen erfordert.
Dazwischen liegt der Bedarf vieler mittelständischer Organisationen: mehr Struktur als eine Aufgabenliste, weniger Komplexität als eine Planungssuite, dazu deutsche Sprache, deutscher Support und deutsches Hosting. Genau diese Kombination adressiert factro. Sie ist damit weniger ein direkter Wettbewerber zu internationalen Plattformen mit riesigem App-Ökosystem als vielmehr eine Antwort auf die Frage, wie ein Mittelständler ohne Projektbüro zu belastbarer Projektarbeit kommt.
Wenn Sie eine Auswahlentscheidung vorbereiten, sollten Sie factro nicht in einem generischen Funktionsvergleich gegen große internationale Plattformen antreten lassen. Ein solcher Vergleich enthält zwangsläufig Kriterien wie Marktplatzgröße, Anzahl der Automatisierungsvorlagen oder Umfang der Assistenzfunktionen, bei denen ein spezialisierter europäischer Anbieter naturgemäß nicht führt.
Sinnvoller ist ein Vergleich entlang der Szenarien, die Sie tatsächlich belasten: das komplexeste laufende Projekt, die schwierigste Abstimmung zwischen zwei Abteilungen, die Frage der Geschäftsführung, die heute niemand ohne halbtägige Auswertung beantworten kann. Wer so vergleicht, erhält ein realistisches Bild und trifft eine Entscheidung, die auch zwei Jahre später noch nachvollziehbar begründet werden kann.
Die Bausteine greifen bewusst ineinander. Eine Aufgabe, die im Strukturbaum entsteht, taucht im Gantt-Diagramm mit ihrem Termin auf, erscheint auf dem Board in der zuständigen Spalte, liegt in der persönlichen Aufgabenliste der verantwortlichen Person und fließt mit ihrem erfassten Aufwand in die Auswertung. Es gibt keine Übertragung, keine Synchronisation, keine doppelte Pflege. Genau diese Durchgängigkeit ist der eigentliche Produktkern.
Viele Organisationen arbeiten heute mit einer Mischung aus Tabellenkalkulation für den Plan, Mail für die Abstimmung und einem Board für die operative Arbeit. Das funktioniert erstaunlich lange – bis zu dem Punkt, an dem die drei Quellen auseinanderlaufen. Dann ist der Plan veraltet, das Board unvollständig, und der wahre Stand liegt in einem Postfach. Der Aufwand, diese Quellen manuell zusammenzuführen, ist der versteckte Preis dieser Arbeitsweise.
Der Wert eines integrierten Werkzeugs liegt genau hier: Es gibt nur eine Aufgabe, aber mehrere Perspektiven darauf. Die Projektleitung schaut auf den Zeitstrahl, das Team auf das Board, die einzelne Person auf ihre Liste, die Geschäftsführung auf die Auswertung – und alle sehen denselben Stand. Diese Einheitlichkeit ist wichtiger als jede einzelne Zusatzfunktion, weil sie die häufigste Fehlerquelle beseitigt: die abweichende Wirklichkeit in verschiedenen Dokumenten.
Wichtig ist dabei eine realistische Erwartung. Die Sichten sind nur so gut wie die Pflege. Ein Gantt-Diagramm, in dem seit sechs Wochen niemand einen Fortschritt aktualisiert hat, ist kein Steuerungsinstrument, sondern eine Illustration. Die eigentliche Einführungsarbeit liegt deshalb nicht in der Konfiguration, sondern in der Vereinbarung, wer wann was pflegt – und in einer Führungskraft, die diese Vereinbarung sichtbar ernst nimmt.
Die Aufgabe ist die kleinste Einheit und gleichzeitig die wichtigste. In factro trägt sie neben Titel und Beschreibung typischerweise eine verantwortliche Person, einen Zeitraum, einen Status, eine Priorität, geplanten Aufwand, Checklistenpunkte, Kommentare und Anhänge. Diese Verdichtung hat einen konkreten Effekt auf die Zusammenarbeit: Die Diskussion über eine Aufgabe findet an der Aufgabe statt und nicht in einem Mail-Verlauf, den nur ein Teil des Teams kennt.
Besonders relevant ist die Regel, dass Verantwortung eindeutig ist. In vielen Werkzeugen lassen sich beliebig viele Personen einer Aufgabe zuordnen – was in der Praxis regelmäßig dazu führt, dass sich niemand zuständig fühlt. Eine Struktur, die eine hauptverantwortliche Person verlangt und weitere Beteiligte als Mitwirkende führt, ist methodisch klarer. Sie erzeugt anfangs Diskussionen, beseitigt aber die häufigste Ursache für liegengebliebene Aufgaben.
Für die tägliche Arbeit ist außerdem die persönliche Aufgabensicht entscheidend. Wer morgens die Software öffnet, will nicht das Projekt sehen, sondern die eigene Liste: Was ist heute fällig, was ist überfällig, was kommt diese Woche? Erst diese Sicht macht ein Projektwerkzeug zu einem Alltagswerkzeug. Wenn sie fehlt oder unübersichtlich ist, weichen Mitarbeitende auf eigene Notizzettel aus – und das Werkzeug verliert seinen Zweck.
Die Erfassung von Aufwänden an der Aufgabe ist einer der wertvollsten und zugleich heikelsten Bausteine. Wertvoll, weil sie Nachkalkulation ermöglicht: Erst wenn Sie wissen, was ein vergleichbares Projekt tatsächlich gekostet hat, werden Ihre Angebote und Planungen besser. Heikel, weil erfasste Zeiten immer auch personenbezogene Daten sind und in vielen Organisationen mitbestimmungsrelevant. Dieser Punkt gehört an den Anfang eines Einführungsprojekts, nicht ans Ende.
Für die Auswertung gilt ein Grundsatz aus der Praxis: Weniger Kennzahlen, dafür verlässliche. Drei Auswertungen, die jede Woche angeschaut und besprochen werden, wirken stärker als zwanzig Berichte, die niemand öffnet. Bewährt haben sich eine Statusübersicht über alle laufenden Projekte, eine Sicht auf überfällige Aufgaben und eine Auslastungssicht für die Ressourcenplanung. Alles Weitere kann folgen, wenn diese drei etabliert sind.
Und eine Warnung: Auswertungen aus einem Projektwerkzeug sind nur so belastbar wie die Datenpflege. Wenn Aufwände nachträglich pauschal eingetragen werden oder Aufgaben erst beim Abschluss angelegt werden, entsteht eine Scheingenauigkeit, die schlechtere Entscheidungen produziert als gar keine Zahlen. Sprechen Sie diesen Punkt in der Einführung offen an – er ist wichtiger als jede Berichtsfunktion.
Die großen internationalen Plattformen haben in den vergangenen Jahren eine Assistenzschicht über ihre Produkte gelegt: Aufgaben aus Fließtext erzeugen, Statusberichte formulieren, Projektpläne vorschlagen, Zusammenfassungen aus Kommentaren ziehen. Diese Funktionen sind attraktiv, werfen aber Fragen auf, die in einer Datenschutzbewertung beantwortet werden müssen – vor allem, wo die Verarbeitung stattfindet und welche Inhalte dabei übertragen werden. Ein Anbieter, dessen zentrales Versprechen Datenhoheit ist, geht diesen Weg naturgemäß vorsichtiger.
Realistisch einzuordnen ist der Nutzen bei factro vor allem auf der Ebene struktureller Automatisierung. Die wirksamsten Hebel sind unspektakulär, sparen im Alltag aber erhebliche Zeit:
Unabhängig vom konkreten Funktionsstand einer Software lohnt eine nüchterne Einordnung, wo generative KI im Projektmanagement überhaupt Nutzen stiftet. Aus unserer Beratungserfahrung sind es drei Stellen. Erstens die Zerlegung: Aus einer groben Beschreibung eines Vorhabens einen ersten Strukturvorschlag zu erzeugen, spart Zeit – nicht weil der Vorschlag richtig wäre, sondern weil das Team schneller an einem konkreten Entwurf arbeiten kann als am leeren Blatt.
Zweitens die Verdichtung: Aus vielen Kommentaren, Statusmeldungen und Änderungen einen lesbaren Bericht zu formulieren, ist eine Fleißaufgabe, die Maschinen gut erledigen. Drittens die Suche: In gewachsenen Projektbeständen die Stelle zu finden, an der eine ähnliche Frage schon einmal entschieden wurde, ist ein unterschätzter Nutzen.
Nicht hilfreich ist generative KI dort, wo Verbindlichkeit gefragt ist. Eine Schätzung, die eine Maschine erzeugt hat, ist keine Zusage. Ein automatisch erzeugter Termin ersetzt keine Abstimmung mit der Person, die liefern soll. Wer diese Grenze nicht zieht, produziert Pläne, die gut aussehen und niemanden verpflichten – das gefährlichste Ergebnis, das ein Projektwerkzeug liefern kann.
Der zweite Automatisierungspfad verläuft über Schnittstellen. Wenn eine Software eine programmierbare Schnittstelle bereitstellt und über Workflow-Dienste ansprechbar ist, lassen sich Projektwerkzeug und Umsysteme koppeln. Typische Muster im Mittelstand: Ein gewonnenes Angebot im Vertriebssystem erzeugt automatisch das zugehörige Projekt aus einer Vorlage. Ein neuer Auftrag im Warenwirtschaftssystem legt die Arbeitspakete für die Abwicklung an. Ein abgeschlossenes Projekt stößt die Nachkalkulation an.
Solche Automatisierungen sind kein Selbstzweck. Ihr Wert liegt darin, dass sie genau die manuellen Übertragungsschritte beseitigen, die im Alltag regelmäßig vergessen werden und dann zu unvollständigen Daten führen. Der praktische Rat aus Projekten lautet dennoch: Beginnen Sie nicht mit der Automatisierung. Bauen Sie zuerst eine saubere manuelle Struktur, die sich einige Wochen bewährt hat. Erst wenn diese Struktur stabil ist, lohnt es sich, sie in Workflows abzubilden. Wer zu früh automatisiert, zementiert eine Ordnung, die er kurz darauf ohnehin ändern muss.
Das Ökosystem eines spezialisierten europäischen Anbieters ist erwartungsgemäß kleiner als der App-Marktplatz einer globalen Plattform. Das ist weniger dramatisch, als es klingt: In mittelständischen Projekten werden selten mehr als eine Handvoll Anbindungen wirklich genutzt. Entscheidend ist nicht die Zahl der verfügbaren Integrationen, sondern ob die vier oder fünf, die Sie brauchen, sauber funktionieren.
Der wichtigste Integrationspunkt im deutschen Mittelstand ist nach wie vor Outlook. Zwei Richtungen sind relevant. Erstens der Weg von der Mail in die Aufgabe: Eine Kundenanfrage, eine Mängelmeldung oder eine Zulieferung wird nicht als Mail im Postfach abgelegt, sondern als Aufgabe im richtigen Projekt erzeugt – mit Verantwortlicher und Termin. Das ist der einzelne Schritt, mit dem viele Organisationen den größten Sprung machen, weil er die Schattenorganisation im Postfach auflöst.
Zweitens der Weg von der Aufgabe in den Kalender: Fällige Aufgaben und Termine erscheinen dort, wo Menschen ohnehin auf ihren Tag schauen. Ob dies über ein Add-in, einen Kalender-Abonnementpfad oder eine Synchronisation gelöst ist und welche Richtungen unterstützt werden, unterscheidet sich je nach Produkt und Ausbaustufe – klären Sie das in der Pilotphase mit echten Terminen und nicht anhand einer Funktionsliste.
Viele mittelständische Organisationen kommunizieren heute in Microsoft Teams. Die naheliegende Frage lautet daher: Wie verhält sich ein separates Projektwerkzeug dazu? Die pragmatische Antwort aus Projekten ist eine klare Rollenverteilung. Die Kommunikationsplattform trägt Gespräche, Dateien und Besprechungen. Das Projektwerkzeug trägt Struktur, Verantwortung und Termine. Wenn beide Welten sauber getrennt sind und die wichtigsten Übergänge – Benachrichtigungen in einen Kanal, ein Link vom Kanal ins Projekt – eingerichtet werden, funktioniert die Kombination gut.
Was nicht funktioniert, ist Unklarheit. Wenn Aufgaben teils als Nachricht im Chat, teils als Aufgabe im Werkzeug und teils als Mail existieren, entsteht genau der Zustand, den die Einführung beseitigen sollte. Eine kurze, schriftliche Tool-Governance – zwei Seiten genügen – ist an dieser Stelle wirksamer als jede technische Integration. Sie beantwortet die Frage, was wohin gehört, und macht das Werkzeug damit erst benutzbar.
Projektwerkzeuge erlauben in der Regel das Anhängen von Dateien an Aufgaben. Das ist praktisch für kleine Artefakte – ein Foto von der Baustelle, ein Protokollauszug, eine Freigabe. Für die Dokumentenhaltung insgesamt empfehlen wir ausdrücklich, die vorhandene Ablage zu behalten und im Projektwerkzeug mit Verweisen zu arbeiten. Zwei parallele Dateiwelten sind eine der zuverlässigsten Ursachen für veraltete Dokumente und Versionskonflikte.
Anspruchsvoller ist die Verbindung zur kaufmännischen Seite. Fragen wie die Übernahme erfasster Zeiten in die Abrechnung, die Verknüpfung von Projekten mit Aufträgen oder Kostenstellen oder die Bereitstellung von Auswertungen für das Controlling entscheiden darüber, ob die Projektarbeit betriebswirtschaftlich anschlussfähig wird. Prüfen Sie hier konkret, welche Exportformate, Schnittstellen und Datenfelder zur Verfügung stehen, und beziehen Sie die Buchhaltung früh ein – nicht erst, wenn das System bereits läuft.
Für alles, was nicht als fertige Integration existiert, ist eine programmierbare Schnittstelle der entscheidende Hebel. Über sie lassen sich Projekte und Aufgaben anlegen, Daten auslesen und Auswertungen in eigene Berichtssysteme übernehmen. Ergänzend erlauben Workflow-Dienste wie Zapier oder Make die Verkettung mit anderen Anwendungen, ohne dass eigene Programmierung nötig wäre – vorausgesetzt, die entsprechenden Bausteine sind für Ihr Werkzeug verfügbar.
Aus Datenschutzsicht verdient dieser Punkt Aufmerksamkeit. Workflow-Dienste sind häufig außereuropäisch betrieben und sehen dabei genau die Daten, die durch sie hindurchlaufen. Wenn Sie einen deutschen Anbieter unter anderem wegen der Datenhaltung wählen, sollten Sie prüfen, ob die Automatisierungskette diesen Vorteil an anderer Stelle wieder aufgibt. In sensiblen Fällen ist eine schlanke eigene Integration gegen die Schnittstelle sauberer als ein bequemer Zwischendienst.
Microsoft Project ist der Klassiker der Projektplanung und in methodischer Tiefe kaum zu schlagen: Vorgangsbeziehungen, Ressourcenkalender, kritischer Pfad, Basisplanvergleiche, umfangreiche Kostenlogik. Wer diese Tiefe braucht – etwa bei komplexen Bau- oder Anlagenvorhaben mit vertraglich fixierten Terminplänen –, findet dort das mächtigere Werkzeug.
Der Preis dieser Mächtigkeit ist die Einarbeitung. In der Praxis führt das häufig dazu, dass ein einzelner Planer die Datei pflegt und das Team gar nicht im Werkzeug arbeitet. Das ist keine Zusammenarbeit, sondern Planung im stillen Kämmerlein mit anschließender Verteilung. factro setzt anders an: weniger Planungstiefe, dafür ein Werkzeug, in dem auch die Ausführenden tatsächlich arbeiten. Wenn Ihr Problem nicht die Planungsgenauigkeit, sondern die gemeinsame Nutzung ist, ist das der entscheidende Unterschied.
InLoox ist der naheliegende Vergleich für Organisationen mit starker Outlook-Prägung, weil es Projektarbeit eng an die Microsoft-Welt anlehnt. Wer seine gesamte Arbeitswelt in Outlook denkt, empfindet diese Nähe als Vorteil. Wer eine eigenständige Projektumgebung möchte, in der Projekte unabhängig von Mail-Gewohnheiten leben, findet in factro den klareren Schnitt. Beide Anbieter kommen aus dem deutschsprachigen Raum, sodass sich die Datenschutzfrage in ähnlicher Weise stellt.
Projektron BCS spielt in einer anderen Liga der Vollständigkeit: Es verbindet Projektmanagement mit Aufwandserfassung, Abrechnung, Controlling und teils weitergehenden kaufmännischen Prozessen und richtet sich an Organisationen, die Projekte als Geschäftsmodell betreiben – etwa IT-Dienstleister oder Ingenieurbüros mit Stundenabrechnung. Wo diese Durchgängigkeit gebraucht wird, ist ein reines Projektwerkzeug zu schmal. Wo sie nicht gebraucht wird, ist die zusätzliche Komplexität ein Einführungsrisiko. Unsere Einordnung zu InLoox und Projektron finden Sie in eigenen Artikeln.
Diese Gruppe ist der interessantere Vergleich, weil sie dieselben Nutzenden anspricht: Teams, die schnell starten wollen. Die Stärken liegen in Bedienbarkeit, moderner Oberfläche, breiten Integrationen und einem großen Angebot an Vorlagen und Automatisierungen. Die Einführung ist niedrigschwellig, der erste Erfolg stellt sich schnell ein.
Zwei Unterschiede sind für den DACH-Mittelstand relevant. Erstens die Struktur: Wo diese Werkzeuge auf flache Listen und Boards setzen, verliert man bei umfangreichen Vorhaben mit vielen Arbeitspaketen schneller den Überblick als in einer echten Hierarchie. Zweitens der Datenschutz: Bei überwiegend US-amerikanischen Anbietern ist die Bewertung aufwendiger – lösbar, aber mit Aufwand verbunden. awork nimmt hier eine Zwischenstellung ein, da es aus Deutschland stammt und die Datenschutzfrage entsprechend einfacher zu beantworten ist, methodisch aber leichter aufgestellt ist als factro.
Als Faustregel aus unseren Projekten: Je stärker Ihre Arbeit Projektcharakter mit Anfang, Ende und Abhängigkeiten hat, desto eher gewinnt ein strukturorientiertes Werkzeug. Je stärker sie kontinuierlicher Fluss mit wechselnden Prioritäten ist, desto eher gewinnt ein board-orientiertes Werkzeug.
Zusammengefasst spricht für factro, wenn mindestens zwei der folgenden Punkte auf Sie zutreffen: Ihre Projekte haben eine Struktur, die sich sinnvoll zerlegen lässt. Sie brauchen Gantt und Board gleichermaßen, weil Planung und operative Arbeit beide stattfinden. Datenhoheit und deutschsprachiger Support sind harte Kriterien. Sie wollen weg von Excel und Mail, aber ohne die Einführungslast einer klassischen Planungssuite. Und Sie sind bereit, Struktur zu pflegen, statt sie nur zu wünschen.
Gegen factro spricht, wenn Sie ein reines Aufgabenwerkzeug für lockere Zusammenarbeit suchen, wenn agile Produktentwicklung mit tiefer Entwicklerwerkzeug-Integration im Zentrum steht, wenn Sie eine durchgängige kaufmännische Projektabwicklung inklusive Abrechnung benötigen oder wenn eine breite generative Assistenzschicht eine nicht verhandelbare Anforderung ist. Diese Abwägung sollten Sie dokumentieren – 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 der Software, sondern mit der Projektlandschaft, weil eine falsch aufgesetzte Struktur später deutlich teurer zu korrigieren ist als eine Einstellung im System.
Das Rechtemodell ist in Projektwerkzeugen der unterschätzteste Erfolgsfaktor. Zu offen konfiguriert, entstehen Unruhe und das Gefühl der Überwachung, weil jede Person die Aufgaben und Aufwände aller anderen sieht. Zu eng konfiguriert, entsteht wieder das alte Problem: Niemand weiß, was die Nachbarabteilung tut, und die Projektleitung sammelt Informationen erneut per Mail ein.
Bewährt hat sich eine mittlere Linie: Projektbeteiligte sehen ihr Projekt vollständig, Führungskräfte sehen ihre Bereiche, personenbezogene Aufwandsdaten sind auf einen definierten Kreis beschränkt, und es gibt eine bewusst kleine Zahl von Personen, die Projekte anlegen dürfen. Die letzte Regel klingt restriktiv, verhindert aber den häufigsten Wildwuchs – zwanzig halbleere Projekte, die niemand aufräumt und die jede Auswertung unbrauchbar machen.
Die meisten Einführungen im Mittelstand sind Ablösungen: Excel-Terminlisten, Outlook-Aufgaben, ein gewachsenes Netzlaufwerk mit Projektordnern, gelegentlich ein Altsystem. Die zentrale Entscheidung lautet, wie viel Vergangenheit mitgenommen wird. Unsere Empfehlung ist konsequent: so wenig wie möglich. Übertragen Sie laufende Vorhaben mit ihrem aktuellen Stand, nicht mit ihrer vollständigen Historie. Abgeschlossene Projekte bleiben im Archiv, wo sie sind.
Der Grund ist praktischer Natur. Eine Migration historischer Daten kostet viel Zeit, erzeugt unvollständige Datensätze und liefert selten Nutzen, weil in alte Projekte ohnehin niemand mehr schaut. Wertvoller ist die Zeit, die Sie stattdessen in eine saubere Struktur der laufenden Projekte investieren. Wichtig ist dabei ein klarer Stichtag: Ab diesem Datum werden neue Aufgaben ausschließlich im neuen Werkzeug angelegt. Ohne diesen Schnitt laufen alte und neue Welt monatelang parallel – der zuverlässigste Weg, eine Einführung scheitern zu lassen.
Für Outlook-Aufgaben und Mail-Postfächer gilt ein besonderer Hinweis. Die Gewohnheit, Arbeit im Postfach zu verwalten, ist tief verankert und lässt sich nicht durch eine Ankündigung ändern. Wirksam ist, den Weg von der Mail in die Aufgabe so einfach wie möglich zu machen und in den ersten Wochen konsequent daran zu erinnern. Nach etwa sechs bis acht Wochen entscheidet sich erfahrungsgemäß, ob die neue Gewohnheit trägt.
Schulung im klassischen Sinn wirkt bei Projektwerkzeugen nur begrenzt. Wirksamer sind kurze, rollenbezogene Einheiten: dreißig Minuten für Bearbeitende, in denen es ausschließlich um die eigene Aufgabenliste und das Erfassen von Fortschritt geht. Eine längere Einheit für Projektleitungen, in der Struktur, Planung und Auswertung geübt werden. Und eine kurze Runde für die Geschäftsführung, damit die Berichte auch gelesen und genutzt werden.
Für den laufenden Betrieb empfehlen wir, eine benannte Person als fachliche Verantwortliche zu bestimmen. Diese Rolle pflegt Vorlagen, prüft die Struktur, hilft bei Fragen und schärft die Konventionen nach. Der Aufwand ist überschaubar, aber ohne diese Rolle verwahrlost jedes Projektwerkzeug innerhalb eines Jahres – nicht weil die Software schlechter wird, sondern weil niemand mehr die Ordnung verantwortet.
Ein letzter, oft entscheidender Punkt: Führungskräfte müssen im Werkzeug arbeiten. Wenn eine Projektleitung den Status weiterhin per Mail abfragt, hat das Team gelernt, dass die Pflege im System optional ist. Umgekehrt genügt oft die schlichte Praxis, jede Statusbesprechung ausschließlich anhand der Ansicht im Werkzeug zu führen – nichts fördert die Datenpflege wirksamer.
In bauhnahen Branchen ist die Struktur ohnehin vorhanden – sie steht nur meist auf Papier, in Terminlisten und in den Köpfen der Bauleitung. Ein Projektstrukturbaum bildet Bauabschnitte, Gewerke und Abnahmen ohne Übersetzungsverlust ab. Der Zeitstrahl macht Abhängigkeiten sichtbar, etwa dass der Estrich erst nach der Rohinstallation kommt und jede Verschiebung nach hinten durchschlägt.
Der größte praktische Nutzen liegt jedoch bei den kleinen Dingen: Mängel, Nachträge, Rückfragen an Planer, offene Freigaben. Genau diese Punkte gehen im Alltag unter, weil sie per Telefon oder Mail entstehen und nirgends verbindlich landen. Wenn sie als Aufgaben mit verantwortlicher Person und Termin erfasst werden, verändert sich die Nachweisbarkeit erheblich – ein Argument, das bei Streitfällen über Verzögerungen unmittelbar wirtschaftlich wird.
Zu bedenken ist die Nutzung auf der Baustelle. Mobile Erfassung mit Foto und kurzer Beschreibung ist realistisch, ausführliche Planung auf dem Telefon nicht. Prüfen Sie die mobilen Funktionen deshalb im Pilot unter echten Bedingungen, inklusive schwacher Netzabdeckung, und legen Sie fest, was mobil und was am Schreibtisch erfasst wird.
In der Fertigung liegt der Nutzen weniger in der Produktion selbst – dort arbeiten Fachsysteme – als in der Abwicklung um sie herum. Ein Kundenauftrag durchläuft Angebot, Konstruktion, Beschaffung, Fertigung, Montage, Inbetriebnahme und Abnahme. Diese Kette überspannt mehrere Abteilungen, und genau an den Übergängen entstehen die Verzögerungen: Die Konstruktion ist fertig, aber niemand hat die Beschaffung informiert.
Ein gemeinsamer Strukturbaum je Auftrag macht diese Übergaben explizit. Jede Abteilung sieht, was von ihr erwartet wird und wovon sie abhängt. Wichtig ist dabei ein realistischer Detaillierungsgrad: Ein Projektwerkzeug soll den Auftragsdurchlauf steuern, nicht jeden Arbeitsgang der Fertigung abbilden. Wer versucht, damit die Feinplanung der Produktion zu ersetzen, überfrachtet das Werkzeug und verliert die Akzeptanz derer, die es eigentlich nutzen sollen.
Wo Projekte das Geschäftsmodell sind, wird die Aufwandserfassung zum Kernthema. Der Zyklus ist immer derselbe: kalkulieren, durchführen, erfassen, nachkalkulieren, aus dem Ergebnis lernen. Viele mittelständische Dienstleister schließen diesen Kreis nie, weil die erfassten Zeiten in der Abrechnung landen, aber nie zurück in die Kalkulation fließen. Ein Werkzeug, das geplante und tatsächliche Aufwände auf derselben Struktur zeigt, macht diesen Rückfluss erst möglich.
Der zweite Nutzen ist die Auslastungssicht. Die typische Frage – können wir das neue Mandat annehmen oder nicht? – wird in vielen Häusern nach Gefühl beantwortet. Eine Sicht auf zugesagte Aufgaben und verfügbare Kapazität ersetzt dieses Gefühl nicht vollständig, verbessert die Entscheidung aber deutlich. Voraussetzung ist allerdings eine ehrliche Pflege: Eine Auslastungssicht, die nur die Hälfte der Arbeit kennt, ist gefährlicher als keine.
Das vierte Szenario ist das unterschätzteste. Digitalisierungsvorhaben, Zertifizierungen nach Normen, Einführungen neuer Systeme, der Aufbau eines Standorts oder die Umstellung eines Prozesses laufen im Mittelstand fast immer neben dem Tagesgeschäft. Sie haben keinen zahlenden Kunden, der Druck erzeugt, und deshalb die höchste Wahrscheinlichkeit, liegenzubleiben.
Gerade hier wirkt Sichtbarkeit stark. Wenn ein internes Vorhaben denselben Strukturbaum, dieselben Termine und dieselbe Statussicht hat wie ein Kundenprojekt, wird es zu einem Vorhaben mit Anspruch statt zu einer guten Absicht. In unseren Projekten ist das häufig der Einstieg: Das erste Vorhaben, das im neuen Werkzeug geführt wird, ist die Einführung des Werkzeugs selbst – ein Vorgehen, das nebenbei alle Beteiligten mit der Software vertraut macht.
Zunächst zu den Kosten, weil sie in der Praxis eng mit der Datenschutzfrage verbunden sind: Wer aus Gründen der Datenhoheit einen spezialisierten Anbieter wählt, muss die Entscheidung wirtschaftlich begründen können. 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 lässt: weniger Zeit für die Statusrecherche, weniger vergessene Zusagen, belastbarere Kalkulationen durch Nachkalkulation, früher erkannte Terminrisiken und ein kürzerer Abstimmungsprozess mit Datenschutz und Mitbestimmung. Wir empfehlen, diese Nutzenerwartung vor der Einführung schriftlich zu fixieren, damit nach zwölf Monaten überprüfbar ist, ob sie eingetreten ist.
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 Hosting in Deutschland 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 – im öffentlich geförderten oder aufsichtsnahen Umfeld – gegenüber Aufsichtsstellen. In Organisationen, in denen solche Abstimmungen sonst Monate kosten, ist das nicht nur ein rechtlicher, sondern ein spürbarer wirtschaftlicher Vorteil.
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.
Bei einem Projektwerkzeug mit Aufwandserfassung verdient ein Punkt besondere Aufmerksamkeit: Erfasste Zeiten sind personenbezogene Daten, aus denen sich Rückschlüsse auf Leistung und Verhalten ziehen lassen. Damit ist der Einsatz regelmäßig mitbestimmungsrelevant, und die Frage, wer welche Aufwandsdaten sehen darf, ist keine technische Einstellung, sondern eine Vereinbarung.
Unsere Empfehlung aus Projekten: Klären Sie diesen Punkt früh, offen und schriftlich. Legen Sie fest, zu welchem Zweck Aufwände erfasst werden – Nachkalkulation und Projektsteuerung, nicht individuelle Leistungsbewertung –, wer die Daten in welcher Verdichtung sieht und wie lange sie aufbewahrt werden. Eine frühzeitige Betriebsvereinbarung ist deutlich einfacher als eine nachträgliche Auseinandersetzung, und sie nimmt der Einführung die Spannung, die sonst über Monate mitläuft.
Fünf Punkte gehören in jede Einführung. Erstens der Auftragsverarbeitungsvertrag, abgeschlossen und im Verzeichnis der Verarbeitungstätigkeiten dokumentiert. Zweitens ein Berechtigungskonzept: Wer sieht welche Projekte, wer darf Aufwände auswerten, wer Projekte anlegen und löschen? Drittens Löschkonzepte und Aufbewahrungsfristen – Projektdaten sammeln sich an, und ein Werkzeug ohne Löschregel wird über Jahre zum Datenspeicher ohne Zweckbindung. Viertens die Einbindung der Mitbestimmung, insbesondere bei Zeiterfassung und Auslastungssichten. Fünftens Transparenz gegenüber Beschäftigten: eine verständliche Information darüber, welche Daten anfallen und wofür sie verwendet werden.
Ein besonderer Blick gilt Kunden- und Lieferantendaten. Wenn externe Beteiligte Zugang erhalten oder ihre Daten in Aufgaben und Kommentaren erscheinen, gelten dieselben Grundsätze. Regeln Sie deshalb ausdrücklich, welche Informationen in einem Projektwerkzeug erfasst werden dürfen – und welche, etwa besondere Kategorien personenbezogener Daten, dort nichts zu suchen haben.
