Der entscheidende Punkt vorab: InLoox ist kein Werkzeug für lockeres Aufgabenmanagement, sondern eine Planungssoftware. Es geht nicht nur darum, To-dos zu sammeln und abzuhaken, sondern darum, ein Projekt vollständig abzubilden: mit Struktur, Terminlogik, verantwortlichen Personen, geplantem und tatsächlichem Aufwand, Kosten und Auswertung. Wer nur eine digitale Aufgabenliste sucht, wird die Software als zu schwer empfinden. Wer Projekte plant, steuert und nachkalkuliert, findet genau die Tiefe, die einfache Kanban-Werkzeuge nicht bieten.
Drei Eigenschaften prägen InLoox als Produkt:
InLoox ist nicht als Cloud-Startup entstanden, sondern als Erweiterung einer bereits vorhandenen Arbeitsumgebung. Diese Herkunft ist bis heute sichtbar und erklärt viele Designentscheidungen. Das Produkt geht davon aus, dass in der Organisation ein E-Mail-Postfach, ein Kalender und eine Dateiablage bereits existieren – und dass Projektmanagement nicht daneben, sondern darin stattfinden sollte. Statt eine neue Insel zu bauen, legt die Software eine Struktur über das, was ohnehin läuft.
Für den Mittelstand ist das ein ausgesprochen pragmatischer Ansatz. In vielen Unternehmen scheitert die Einführung von Projektsoftware nicht an der Software, sondern an der Frage, ob Menschen bereit sind, ein zusätzliches Fenster zu öffnen. Wenn die Projektübersicht dort erscheint, wo ohnehin täglich gearbeitet wird, sinkt diese Hürde erheblich. In unseren Projekten war das regelmäßig das stärkste Argument für InLoox – deutlich stärker als jede einzelne Funktion.
Der zweite prägende Zug ist die Planungstiefe. InLoox denkt in Projekten mit Anfang, Ende, Struktur und Verantwortung. Ein Vorgang hat eine Dauer, kann von einem anderen abhängen, verschiebt sich bei Verzögerungen mit und wirkt sich auf einen Endtermin aus. Ressourcen werden Vorgängen zugeordnet, Aufwände geplant und später mit erfassten Zeiten verglichen. Budgets werden hinterlegt und gegen tatsächliche Kosten gestellt. Diese Kette – planen, ausführen, erfassen, auswerten – ist das eigentliche Produkt.
Damit unterscheidet sich InLoox grundlegend von Werkzeugen, die primär Zusammenarbeit organisieren. In einem reinen Board-Werkzeug ist ein Projekt eine Sammlung von Karten. In einer Planungssoftware ist ein Projekt ein Modell, das Auskunft darüber geben soll, ob ein Termin noch zu halten und ein Budget noch einzuhalten ist. Wer diesen Unterschied vor der Auswahl klärt, vermeidet die häufigste Fehlentscheidung: ein zu schweres Werkzeug für ein leichtes Problem oder umgekehrt.
Aus unserer Beratungspraxis passt InLoox besonders gut zu drei Profilen. Erstens zu Organisationen, die stark Microsoft-geprägt sind und in denen Outlook das zentrale Arbeitswerkzeug ist – das trifft auf einen großen Teil des deutschen Mittelstands zu. Zweitens zu Unternehmen mit auftrags- oder projektbezogener Wertschöpfung, in denen Aufwände und Kosten je Projekt nachgehalten werden müssen, etwa in Ingenieurbüros, im Anlagenbau oder in der Beratung. Drittens zu Organisationen, die aus Datenschutz- oder Compliance-Gründen einen europäischen Anbieter oder einen Betrieb im eigenen Haus bevorzugen.
Die Grundlogik der Lizenzierung folgt einem im Markt verbreiteten Muster: Bezahlt wird je benannter Nutzerin oder je Nutzer, gestaffelt nach Ausbaustufe. Die Stufen unterscheiden sich vor allem in Planungstiefe, Auswertungsmöglichkeiten, Portfoliofunktionen, Rechteverwaltung und Schnittstellenumfang. Wer nur Aufgaben sieht und Zeiten erfasst, benötigt in der Regel eine schlankere Lizenz als eine Projektleitung, die Strukturpläne baut, Ressourcen einplant und Budgets führt. Diese Differenzierung ist wichtig für die Kalkulation – und sie ist der Hebel, mit dem sich Gesamtkosten realistisch steuern lassen.
Die wichtigste Weichenstellung bei InLoox ist nicht die Wahl der Ausbaustufe, sondern die Wahl der Betriebsform. In der Cloud übernimmt der Anbieter Betrieb, Aktualisierung, Sicherung und Verfügbarkeit. Neue Funktionen kommen in der Regel dort zuerst an, der interne Aufwand bleibt gering, und die Einstiegshürde ist niedrig. Für die meisten mittelständischen Organisationen ist das der wirtschaftlich sinnvollere Weg – schlicht, weil Betrieb Personal bindet, das anderswo fehlt.
On-Premise ist demgegenüber kein Rückschritt, sondern eine bewusste Entscheidung für Kontrolle. Die Daten liegen in einer Datenbank, die Ihrer Organisation gehört, in einem Netz, das Sie verantworten. Für Bereiche mit besonderen Anforderungen – etwa sicherheitsrelevante Entwicklung, bestimmte öffentliche Aufgaben oder vertragliche Zusagen gegenüber Auftraggebern – kann das den Ausschlag geben. Der Preis dafür ist realer Aufwand: Serverbetrieb, Datenbankpflege, Sicherung, Aktualisierungen, Testzyklen. Diesen Aufwand sollten Sie vor der Entscheidung ehrlich beziffern, statt ihn als selbstverständlich zu behandeln.
Der praktische Unterschied zwischen den Ausbaustufen liegt weniger in spektakulären Einzelfunktionen als in der Frage, wer gestalten darf und wer konsumiert. Eine schlanke Lizenz reicht, wenn jemand eigene Aufgaben sieht, Zeiten bucht und Dokumente findet. Sobald jemand Projektstrukturen anlegt, Abhängigkeiten setzt, Ressourcen plant, Budgets führt oder Auswertungen erstellt, braucht es die größere Stufe. Ein zweiter Unterschied betrifft die Auswertung: Portfolio- und Mehrprojektsichten, die für Bereichsleitungen interessant sind, gehören typischerweise in die oberen Stufen.
Für die Planung heißt das: Erstellen Sie vor der Angebotsanfrage eine ehrliche Rollenverteilung. Wie viele echte Projektleitungen gibt es? Wie viele Personen erfassen nur Zeiten? Wer braucht Auswertungen? Diese Aufteilung ist der wichtigste Hebel für die Gesamtkosten – wichtiger als jeder Rabatt, den Sie verhandeln.
InLoox positioniert sich als Projektmanagement für Organisationen, die planen wollen, ohne ein schwergewichtiges Projektsystem einzuführen. Damit liegt das Produkt zwischen zwei Polen: unterhalb der klassischen Großprojektsysteme mit hohem Methodenanspruch und oberhalb der leichten Aufgabenwerkzeuge, die keine Terminlogik und keine Kostenführung kennen. Die Argumentation ruht auf drei Säulen: Nähe zur Microsoft-Umgebung, deutsche Herkunft mit europäischem Rechtsrahmen und die Wahlfreiheit zwischen Cloud und eigenem Betrieb.
Diese Geschlossenheit ist die eigentliche Stärke. Eine geplante Stunde, eine erfasste Stunde und ein Kostensatz gehören zusammen; ein verschobener Vorgang wirkt auf den Endtermin; ein überzogenes Budget wird sichtbar, ohne dass jemand eine Tabelle pflegen muss. Die folgenden Bausteine machen den praktischen Alltag aus.
Das Herzstück von InLoox ist die Projektstruktur. Ein Projekt zerfällt in Phasen, Arbeitspakete und Vorgänge, die zueinander in Beziehung stehen. Diese Struktur ist mehr als eine Gliederung: Sie ist der Anker, an dem Aufgaben, Zeiten, Dokumente, Kosten und Auswertungen hängen. Wer sie sauber aufbaut, bekommt ohne Zusatzaufwand belastbare Berichte. Wer sie schlampig aufbaut, bekommt eine Software, die viel verlangt und wenig liefert.
Genau hier liegt der häufigste Einführungsfehler. Organisationen übernehmen bestehende Ordnerstrukturen oder bilden ihr Organigramm ab, statt Projekte nach ihrer inneren Logik zu strukturieren. Die Folge sind Strukturpläne mit dutzenden Ebenen, die niemand pflegt. Unsere Empfehlung aus der Praxis: Beginnen Sie mit einer bewusst flachen Vorlage, die für achtzig Prozent Ihrer Projekte reicht, und vertiefen Sie erst, wenn ein konkreter Bedarf entsteht. Vorlagen sind in InLoox ein zentrales Mittel, um diese Disziplin dauerhaft abzusichern.
Die Zeiterfassung ist funktional unspektakulär und praktisch entscheidend. Sie ist das Bindeglied zwischen Planung und Wirklichkeit: Ohne erfasste Zeiten bleiben Plan-Ist-Vergleiche leer, bleiben Nachkalkulationen Schätzungen und bleibt Ressourcenplanung Wunschdenken. Deshalb ist die Frage, wie leicht Zeiten gebucht werden können, wichtiger als viele Planungsdetails. In der Praxis entscheidet sie darüber, ob die Software nach sechs Monaten noch verlässliche Daten enthält.
InLoox setzt hier auf Nähe zum Arbeitsalltag: Buchung aus Outlook heraus, aus dem Kalender, aus der Web App oder mobil. Für die Einführung heißt das trotzdem: Definieren Sie eine klare, einfache Buchungsregel, kommunizieren Sie den Zweck offen und binden Sie – sofern vorhanden – die Mitbestimmung früh ein. Zeiterfassung ist ein mitbestimmungsrelevantes Thema und sollte nie als technische Nebensache behandelt werden. Dies ist eine fachliche Einordnung und keine Rechtsberatung.
InLoox bietet eine projektbezogene Dokumentenablage und die Möglichkeit, E-Mails aus Outlook einem Projekt zuzuordnen. Damit lässt sich ein Problem entschärfen, das in vielen Mittelständlern täglich Geld kostet: Projektwissen liegt in individuellen Postfächern und ist für Vertretungen unauffindbar. Wenn relevante Korrespondenz am Projekt hängt, überlebt sie Urlaube, Krankheit und Personalwechsel.
Wichtig ist dabei die Erwartungssteuerung. Die Software ersetzt kein revisionssicheres Dokumentenmanagement und keine vollständige Ablagestrategie. Sinnvoll ist eine klare Regel: Was gehört ins Projekt, was bleibt in der zentralen Dateiablage, was wird archiviert? Diese Regel gehört in die Einführung – nicht in eine spätere Aufräumaktion, wenn die Struktur bereits gewachsen ist.
Für die Bewertung ist eine Unterscheidung hilfreich, die in Verkaufsgesprächen häufig verschwimmt. Regelbasierte Automatisierung folgt festen Wenn-dann-Beziehungen und liefert reproduzierbare Ergebnisse. Generative Assistenz erzeugt Texte, Vorschläge oder Strukturen und liefert Ergebnisse, die geprüft werden müssen. Beides ist nützlich, aber die Erwartungen, der Nutzen und die datenschutzrechtliche Bewertung sind grundverschieden.
Der praktisch wertvollste Automatisierungsbaustein im Projektmanagement ist unspektakulär: die Vorlage. Ein wiederkehrender Projekttyp – eine Inbetriebnahme, ein Gutachten, ein Umbau, ein Beratungsmandat – wird einmal sauber strukturiert und danach per Klick erzeugt, inklusive Phasen, Standardvorgängen, typischen Dauern und Verantwortlichkeiten. Was danach bleibt, ist Anpassung statt Neuaufbau. In unseren Projekten ist das der Hebel, der Planungsaufwand am deutlichsten senkt und gleichzeitig die Datenqualität verbessert, weil alle Projekte vergleichbar strukturiert sind.
Darüber hinaus lassen sich wiederkehrende Abläufe automatisieren: Statuswechsel, Benachrichtigungen, Fälligkeitserinnerungen, Übergaben zwischen Rollen. Der Nutzen liegt weniger in eingesparter Zeit als in reduzierter Vergesslichkeit. Beginnen Sie mit wenigen, klar begründeten Regeln. Automatisierungslandschaften, die niemand mehr überblickt, erzeugen im zweiten Jahr mehr Aufwand als sie im ersten gespart haben.
Generative Assistenz kann im Projektmanagement an mehreren Stellen helfen: beim Formulieren von Projektbeschreibungen, beim Vorschlagen einer ersten Struktur für einen neuen Projekttyp, beim Zusammenfassen von Statusinformationen oder beim Aufbereiten von Text für Berichte. Wo solche Funktionen verfügbar sind, gilt eine einfache Regel: Sie liefern einen Entwurf, keine Entscheidung. Ein KI-Vorschlag für einen Strukturplan ersetzt keine fachliche Planung, sondern spart das leere Blatt.
Für die Bewertung empfehlen wir drei Fragen. Erstens: Welche Daten verlassen für die Funktion das System, und wohin gehen sie? Zweitens: Werden Eingaben zur Verbesserung von Modellen verwendet, und lässt sich das abschalten? Drittens: Lässt sich die Funktion für einzelne Bereiche oder Projekte deaktivieren, etwa bei besonders schutzbedürftigen Vorhaben? Lassen Sie sich die Antworten schriftlich geben und nehmen Sie sie in Ihre Datenschutzdokumentation auf. Dies ist eine fachliche Einordnung und ersetzt keine Rechtsberatung.
Eine Warnung aus der Praxis: Automatisierung verstärkt die vorhandene Ordnung – im Guten wie im Schlechten. Wenn Ihre Projektstruktur uneinheitlich ist, erzeugt Automatisierung uneinheitliche Ergebnisse schneller. Wenn Zuständigkeiten unklar sind, verteilt sie Aufgaben an Unklarheit. Wer erwartet, dass ein Assistent ein Organisationsproblem löst, wird enttäuscht. Klären Sie zuerst Rollen, Struktur und Regeln – und automatisieren Sie danach genau das, was dann noch mechanisch ist.
Ein zweiter Punkt betrifft die Akzeptanz. Automatische Statusmeldungen und Erinnerungen wirken schnell wie Kontrolle, wenn sie nicht erklärt werden. Kommunizieren Sie deshalb offen, was automatisiert wird und warum. In mitbestimmten Betrieben gehört dieses Thema ohnehin auf den Tisch, bevor die erste Regel scharf geschaltet wird.
Die Integrationsstrategie folgt einem klaren Muster: sehr tiefe Verzahnung mit Microsoft, solide Schnittstellen für den Rest. Wer eine breite Sammlung fertiger Anbindungen an hunderte Cloud-Dienste erwartet, wie sie große internationale Plattformen bieten, wird enttäuscht. Wer eine Microsoft-Umgebung betreibt und daneben ein ERP oder ein Buchhaltungssystem anbinden möchte, findet passende Wege.
Die Outlook-Integration ist das Kernstück und der eigentliche Grund, warum viele Organisationen InLoox überhaupt in Betracht ziehen. Das Add-in bringt Projekte, Aufgaben, Zeiterfassung und Dokumente in die Oberfläche, in der die Belegschaft ohnehin arbeitet. E-Mails lassen sich einem Projekt zuordnen und in Aufgaben überführen, Termine mit Vorgängen verknüpfen, Kontakte als Beteiligte hinterlegen. Was technisch nach einer Bequemlichkeit klingt, ist organisatorisch ein Akzeptanzhebel: Der Weg vom Impuls zur Aufgabe wird kürzer, und genau an dieser Stelle brechen Projektwerkzeuge sonst ein.
Für Organisationen, die Projektdaten in eine übergreifende Berichtslandschaft bringen wollen, ist die Anbindung an Auswertungswerkzeuge wie Power BI der interessanteste Punkt. Damit lassen sich Projektkennzahlen mit anderen Unternehmensdaten verbinden – etwa mit Umsatz, Auftragsbestand oder Kapazitätsplanung. Der Nutzen entsteht dabei weniger durch schönere Diagramme als durch die Möglichkeit, Fragen zu beantworten, die aus einer einzelnen Software heraus nicht beantwortbar sind.
Für individuelle Anbindungen steht eine Programmierschnittstelle zur Verfügung. Damit lassen sich Projekte automatisiert anlegen, Stammdaten synchronisieren oder Zeitbuchungen an ein Abrechnungssystem übergeben. Klären Sie hier drei Dinge früh: Welche Objekte sind über die Schnittstelle erreichbar? Wie wird authentifiziert? Und gilt derselbe Umfang in Cloud und On-Premise? Die Antworten bestimmen, ob eine geplante Integration eine Woche oder ein Quartal kostet.
Die ehrliche Einordnung lautet: InLoox ist kein Integrationsknoten. Wer ein Werkzeug sucht, das dutzende Cloud-Dienste per Klick verbindet und als zentrale Automatisierungsdrehscheibe dient, ist mit einer der großen internationalen Plattformen besser bedient. InLoox ist auf Tiefe in einer Umgebung ausgelegt, nicht auf Breite über viele Umgebungen hinweg.
Für die Praxis heißt das: Listen Sie vor der Auswahl die Systeme auf, die wirklich angebunden werden müssen – nicht die, die schön wären. In den meisten Mittelständlern sind das zwei bis vier: die Microsoft-Umgebung, ein ERP oder eine Buchhaltung, gelegentlich ein CRM und ein Auswertungswerkzeug. Wenn diese vier Wege sauber funktionieren, ist die Integrationsfrage beantwortet.
Der wichtigste Wettbewerber von InLoox ist nicht ein anderes Produkt, sondern die Frage: Reicht nicht das, was wir schon haben? Microsoft Planner und Listen sind in vielen Paketen enthalten und decken einfaches Aufgabenmanagement ordentlich ab. Sie kennen jedoch keine echte Terminlogik mit Abhängigkeiten, keine projektbezogene Kostenführung und keine belastbare Nachkalkulation. Microsoft Project wiederum kann Planung sehr gut, ist aber methodisch anspruchsvoll und im Alltag für gemischte Teams oft zu schwer.
InLoox besetzt genau die Lücke dazwischen: mehr Planung als Planner, weniger Methodenlast als Project, und dazu die Zeiterfassung, die beiden fehlt. Wenn Ihre Organisation an genau diesen Punkten leidet – Termine ohne Abhängigkeiten, Kosten in Tabellen, Zeiten in einem dritten System –, ist der Zusatznutzen greifbar. Wenn nicht, sollten Sie die Bordmittel ernsthaft prüfen, bevor Sie eine weitere Software beschaffen.
InLoox unterscheidet sich von allen dreien vor allem durch die Outlook-Verankerung und die On-Premise-Option. Wo diese beiden Punkte keine Rolle spielen, wird der Vergleich offen und sollte entlang Ihrer konkreten Szenarien entschieden werden. Wo sie eine Rolle spielen, ist die Auswahl deutlich enger.
Ein generischer Funktionsvergleich führt bei Projektsoftware fast immer in die Irre, weil jede Software Funktionen hat, die niemand nutzt. Vergleichen Sie stattdessen entlang von drei bis fünf realen Szenarien: das komplexeste laufende Projekt, die monatliche Nachkalkulation, die Kapazitätsplanung für das nächste Quartal, die Übergabe eines Projekts bei Krankheit. Lassen Sie sich diese Szenarien in einer Testumgebung mit Ihren eigenen Daten zeigen – nicht mit den Demodaten des Anbieters. Wer so vergleicht, trifft eine Entscheidung, die auch zwei Jahre später noch nachvollziehbar ist.
Ein realistischer Zeitrahmen für eine mittelständische Einführung liegt bei mehreren Wochen bis wenigen Monaten – abhängig von Betriebsform, Zahl der Projekttypen und dem Ausmaß der Schnittstellen. Wer schneller sein will, sollte den Umfang reduzieren, nicht die Sorgfalt.
In den meisten Mittelständlern ist der Vorgänger von InLoox keine Software, sondern eine Sammlung von Tabellen. Das ist gute Nachricht und Risiko zugleich. Gute Nachricht, weil keine komplexe Systemmigration ansteht. Risiko, weil die Versuchung groß ist, die gewachsene Tabellenlogik eins zu eins nachzubauen – inklusive aller Sonderfälle, die sich über Jahre angesammelt haben.
Unsere Empfehlung: Nutzen Sie die Einführung als Anlass zum Aufräumen. Übernehmen Sie Stammdaten und laufende Projekte, aber nicht jede historische Besonderheit. Legen Sie fest, ab welchem Stichtag die neue Software führend ist, und halten Sie das konsequent durch. Parallelbetrieb über Monate ist der zuverlässigste Weg, eine Einführung scheitern zu lassen, weil die Daten in beiden Welten unvollständig bleiben.
Ein Punkt verdient besondere Aufmerksamkeit: die Sichtbarkeit von Kosten- und Aufwandsdaten. Projektsoftware macht sichtbar, wer wie lange woran gearbeitet hat. Das ist fachlich notwendig und sozial heikel. Ein durchdachtes Rechtekonzept, das Auswertungen auf Projektebene erlaubt und personenbezogene Detailauswertungen bewusst einschränkt, nimmt einen großen Teil der Vorbehalte vorweg.
Klären Sie deshalb früh: Wer sieht welche Zeiten? Werden individuelle Auswertungen erstellt, und wenn ja, wofür? Wie lange werden Daten aufbewahrt? In mitbestimmten Betrieben gehören diese Fragen ohnehin in eine Vereinbarung. Auch ohne Betriebsrat lohnt es sich, die Antworten schriftlich zu fixieren und offen zu kommunizieren. Dies ist eine fachliche Einordnung und ersetzt keine Rechtsberatung.
In allen vier Profilen entsteht der spürbare Nutzen selten dort, wo man ihn zuerst vermutet. Nicht der schöne Balkenplan verändert den Alltag, sondern die Tatsache, dass eine Projektleitung montags in fünf Minuten sieht, welche Vorgänge überfällig sind, wer überlastet ist und welches Projekt sein Budget reißt. Diese fünf Minuten ersetzen typischerweise mehrere Nachfragerunden per E-Mail und ein Sammeln von Zahlen aus verschiedenen Tabellen.
Der zweite Effekt ist mittelfristig und wirtschaftlich relevanter: Wenn Plan und Ist über zwei, drei Jahre systematisch erfasst werden, entsteht eine Erfahrungsbasis. Angebote werden realistischer kalkuliert, weil man weiß, was ein vergleichbares Projekt tatsächlich gekostet hat. In auftragsgetriebenen Unternehmen ist dieser Lerneffekt oft der größte Hebel – größer als jede Effizienzsteigerung im Tagesgeschäft.
Drei Muster begegnen uns immer wieder. Erstens die Überstrukturierung: Vorlagen mit fünfzig Vorgängen, die niemand vollständig pflegt, wodurch der Fortschrittsgrad unbrauchbar wird. Zweitens die halbe Zeiterfassung: Ein Teil der Belegschaft bucht, ein Teil nicht, und alle Auswertungen werden dadurch wertlos. Drittens der Parallelbetrieb: Die alte Tabelle bleibt bestehen, weil sie vertraut ist, und die Software wird zur Zweitschrift mit doppeltem Aufwand.
Alle drei Muster sind vermeidbar, aber nicht durch Technik. Sie brauchen eine Entscheidung der Geschäftsführung, eine klare Regel und jemanden, der ihre Einhaltung freundlich, aber beharrlich einfordert. Wenn diese drei Elemente fehlen, hilft auch die beste Konfiguration nicht.
Zur Kostenseite: Lizenzkosten sind in den meisten Einführungen nicht der größte Posten. Rechnen Sie mindestens vier Blöcke zusammen. Erstens die Lizenzen, gestaffelt nach Rollen. Zweitens den Einführungsaufwand: Strukturentwurf, Konfiguration, Migration, Schulung, Begleitung. Drittens den laufenden Betrieb, der bei On-Premise deutlich höher ausfällt als in der Cloud. Viertens die interne Zeit, die Ihre eigenen Leute investieren – der Posten, der am häufigsten vergessen und am zuverlässigsten unterschätzt wird.
Eine belastbare Kalkulation entsteht erst, wenn diese vier Blöcke auf drei Jahre gerechnet nebeneinanderstehen. Erst dann wird sichtbar, dass eine scheinbar günstige On-Premise-Lizenz durch Betriebsaufwand teurer sein kann als ein Cloud-Abonnement – oder dass genau das Gegenteil zutrifft, wenn ohnehin ein leistungsfähiger Serverbetrieb besteht.
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. In der On-Premise-Variante verschiebt sich die Bewertung noch weiter: Dann verlassen die Projektdaten Ihre Infrastruktur gar nicht, und die Frage der Auftragsverarbeitung stellt sich für den Kernbetrieb nicht in derselben Form. Für Organisationen, in denen solche Abstimmungen sonst Monate kosten, ist das nicht nur ein rechtlicher, sondern ein spürbarer wirtschaftlicher Vorteil. Achten Sie allerdings darauf, ob einzelne Zusatzfunktionen – etwa Assistenzdienste – dennoch externe Verarbeitung erfordern.
Projektsoftware mit Zeiterfassung verarbeitet Beschäftigtendaten. Das ist ein eigener Prüfstrang, der von der Anbieterfrage unabhängig ist und auch bei einem On-Premise-Betrieb vollständig besteht. Relevant sind vor allem: die Festlegung des Zwecks, die Begrenzung der Auswertungen auf das Erforderliche, die Transparenz gegenüber den Beschäftigten, Löschfristen und – wo ein Betriebsrat besteht – die Mitbestimmung.
Unsere Erfahrung: Wer diese Punkte vor dem Rollout klärt und offen kommuniziert, hat deutlich weniger Widerstand. Wer sie nachträglich klären muss, verliert Zeit und Vertrauen. Eine kurze, verständliche Information an alle Beschäftigten, was erfasst wird, wozu und wer es sieht, ist eine der wirksamsten Maßnahmen überhaupt. Dies ist eine fachliche Einordnung und ersetzt keine Rechtsberatung – für eine verbindliche Bewertung ziehen Sie Ihre Datenschutzbeauftragten und gegebenenfalls anwaltliche Beratung hinzu.
