Der wichtigste Unterschied zu den meisten bekannten Projektwerkzeugen liegt genau hier. Die Software ist kein Aufgabenmanager mit angeflanschter Zeiterfassung, sondern eine Projektabwicklungsplattform mit kaufmännischem Kern. Wer eine schlanke Oberfläche für Teamaufgaben sucht, wird sie überdimensioniert finden. Wer dagegen wissen muss, ob ein Projekt nach dreiundzwanzig Wochen noch im Budget liegt, welche Stunden abrechenbar sind, welche Mitarbeitenden im übernächsten Quartal überbucht sind und welche Rechnung offen ist, findet ein System, das genau diese Fragen ohne Datenexport beantwortet.
Vier Eigenschaften prägen Projektron BCS als Produkt:
Die Software ist in einem Umfeld entstanden, in dem Projekte das Geschäftsmodell sind und nicht dessen Beiwerk: bei Dienstleistern, deren Umsatz aus abrechenbaren Stunden besteht. In solchen Häusern ist die zentrale betriebswirtschaftliche Frage nicht, ob eine Aufgabe erledigt ist, sondern was sie gekostet hat, was sie erlösen wird und wie viel Kapazität sie in den kommenden Wochen bindet. Aus dieser Perspektive erklärt sich die gesamte Designlogik: Projekte sind Kostenträger, Arbeitspakete tragen Aufwände und Preise, Mitarbeitende haben Stundensätze und Kapazitäten, und jede Buchung wirkt sofort auf mehrere Auswertungen.
Diese Prägung erklärt auch, warum die Software in der ersten Begegnung nüchtern wirkt. Sie ist nicht für den Effekt gebaut, sondern für die tägliche Erfassung durch Menschen, die eigentlich etwas anderes tun wollen. In Projekten hören wir selten das Lob „das sieht großartig aus“, dafür regelmäßig den Satz, dass zum ersten Mal alle Zahlen zusammenpassen. Für eine Geschäftsführung, die Projektergebnisse bislang aus drei Quellen zusammenrechnen musste, ist das ein größerer Fortschritt als jede Oberflächenpolitur.
Der typische Zustand im projektorientierten Mittelstand sieht so aus: Angebote entstehen in der Textverarbeitung, die Planung lebt in einer Tabellenkalkulation, Aufgaben laufen in einem Board-Werkzeug, Stunden werden in einem separaten Zeiterfassungssystem oder auf Papier festgehalten, Rechnungen schreibt die Buchhaltung, und einmal im Monat versucht jemand, daraus eine Projektauswertung zu bauen. Jeder dieser Schritte funktioniert für sich. Zusammen erzeugen sie einen Medienbruch je Übergang, und an jedem Bruch entstehen Verzug, Übertragungsfehler und Diskussionen darüber, welche Zahl nun stimmt.
Eine durchgängige Lösung beseitigt nicht die Arbeit, aber sie beseitigt die Übergänge. Der geplante Aufwand eines Arbeitspakets stammt aus der Kalkulation des Angebots. Die erfasste Stunde bucht direkt auf dieses Arbeitspaket. Der Fertigstellungsgrad speist sich aus Ist-Aufwand und Restschätzung. Die Rechnungsposition entsteht aus abrechenbaren Stunden oder aus dem vereinbarten Festpreisanteil. Und die Nachkalkulation nach Projektende ist kein Rekonstruktionsprojekt, sondern eine Abfrage. Genau diese Kette ist der Grund, warum Organisationen sich für ein System dieser Klasse entscheiden – und der Maßstab, an dem eine Einführung gemessen werden sollte.
Aus unserer Beratungspraxis passt Projektron BCS besonders gut zu drei Profilen. Erstens zu Dienstleistern mit abrechenbaren Stunden – IT-Häuser, Ingenieur- und Planungsbüros, Beratungen, Agenturen mit hohem Projektanteil –, weil hier Zeiterfassung, Abrechnung und Controlling denselben Datenstrom nutzen. Zweitens zu Organisationen mit Nachweispflichten gegenüber Dritten: Fördermittelgeber, öffentliche Auftraggeber und Forschungsträger verlangen belastbare Stundennachweise, und ein System, das diese aus dem laufenden Betrieb erzeugt, spart erhebliche Nacharbeit. Drittens zu Häusern, die aus regulatorischen oder strategischen Gründen den Betrieb im eigenen Rechenzentrum behalten wollen.
Weniger zwingend ist die Software dort, wo Projekte klein, kurz und wenig kaufmännisch geprägt sind, wo ein Team von acht Personen vor allem Transparenz über Aufgaben braucht, oder wo eine sehr niedrige Einstiegshürde und ein spielerisches Bedienerlebnis den Ausschlag geben. In diesen Fällen sind schlankere Werkzeuge schneller produktiv und günstiger im Betrieb – der Vergleich mit factro, awork oder MeisterTask lohnt sich dann ausdrücklich.
Klarheit über die Grenzen verhindert Enttäuschung. Die Software ist kein ERP-System: Sie führt keine Finanzbuchhaltung, kein Anlagevermögen, keine Lagerhaltung und keine Produktionsplanung. Sie ist kein Dokumentenmanagementsystem mit revisionssicherer Archivierung, auch wenn Dokumente an Projekten hängen können. Sie ist kein Team-Messenger und kein Intranet – Kommunikation im Sinne von Chat und Wissensmanagement gehört in andere Werkzeuge. Und sie ist keine Software, die man am Freitagnachmittag einführt: Ihre Stärke, die Anpassbarkeit an gewachsene Prozesse, bedeutet zwangsläufig, dass diese Prozesse vorher benannt werden müssen.
Die Grundlogik der Lizenzierung folgt einem im Markt verbreiteten Muster: Bezahlt wird pro Nutzendem, wahlweise als Kauflizenz mit laufender Wartung oder als Mietmodell mit monatlicher beziehungsweise jährlicher Zahlung. Hinzu kommen Zusatzmodule, die einzelne Fachbereiche abdecken, sowie Dienstleistungen für Einführung, Anpassung und Schulung. Für die Kalkulation ist wichtig zu verstehen, dass Lizenz und Einführungsdienstleistung zwei getrennte Blöcke sind und dass der zweite bei einem System dieser Klasse regelmäßig in der Größenordnung des ersten liegt.
Der Unterschied zwischen den Ausbaustufen ist selten eine einzelne spektakuläre Funktion, sondern die Reichweite der Prozesskette. In der Einstiegsvariante endet die Kette meist bei der erfassten Stunde: Sie haben eine Projektstruktur, Aufgaben und saubere Zeitdaten, aber die kaufmännische Auswertung findet weiterhin außerhalb statt. In den mittleren Stufen kommt das Controlling hinzu – Soll-Ist-Vergleiche, Auslastung, Fortschrittsbewertung –, und ab der oberen Stufe schließt sich der Kreis mit Angebot, Ticket und Rechnung.
Für die Auswahl bedeutet das eine unbequeme, aber nützliche Frage: Welchen Teil der Kette wollen Sie tatsächlich im System abbilden? Es ist völlig legitim, mit Projekten und Zeiterfassung zu beginnen und die Fakturierung zunächst in der bestehenden Umgebung zu lassen. Nicht legitim ist es, die volle Durchgängigkeit zu bezahlen und dann nur Stunden zu erfassen – das ist der teuerste Weg, ein Zeiterfassungssystem zu betreiben. Klären Sie deshalb vor dem Angebot, welche Prozesse in Stufe eins wirklich umgestellt werden und welche bewusst später folgen.
Beide Modelle haben ihre Berechtigung, und die Wahl hängt weniger vom Preis als von der Bilanzlogik und der Betriebsstrategie ab. Eine Kauflizenz mit laufender Wartung passt zu Organisationen, die langfristig planen, das System im eigenen Rechenzentrum betreiben und Investitionen aktivieren wollen. Ein Mietmodell passt zu Häusern, die Aufwände als laufende Kosten führen, Flexibilität bei der Nutzerzahl brauchen oder das Hosting ohnehin an den Anbieter geben.
Wichtig ist der Blick über den ersten Vertragszeitraum hinaus. Rechnen Sie beide Modelle über fünf Jahre durch, inklusive Wartung, absehbarem Nutzerwachstum, Zusatzmodulen und dem Aufwand für Versionswechsel. Bei Kaufmodellen ist zusätzlich zu klären, welche Leistungen die Wartung genau umfasst – Versionsupdates, Support, Fehlerbehebung – und was als kostenpflichtige Dienstleistung gilt. Diese Abgrenzung ist der häufigste Grund für Überraschungen im zweiten Jahr.
Projektron BCS positioniert sich nicht als möglichst einfaches Werkzeug für möglichst viele, sondern als fachlich tiefes System für projektorientierte Organisationen mit kaufmännischem Steuerungsbedarf. Der Anbieter argumentiert entlang von drei Linien: fachliche Breite über den gesamten Projektlebenszyklus, Anpassbarkeit an gewachsene Prozesse und deutsche Herkunft mit der Möglichkeit des Eigenbetriebs. Das ist eine kohärente Positionierung, die eine klar umrissene Zielgruppe anspricht und andere bewusst nicht.
In Ausschreibungen tritt die Software daher weniger gegen Board-Werkzeuge an als gegen zwei andere Kategorien: gegen die Projektmodule von ERP-Systemen, die kaufmännisch stark, aber im operativen Projektalltag oft sperrig sind, und gegen Kombinationen aus mehreren Spezialwerkzeugen, die einzeln besser bedienbar sind, in Summe aber Integrationsaufwand und Datenbrüche erzeugen. Wer diese drei Optionen sauber gegeneinander stellt, trifft eine belastbarere Entscheidung als jemand, der eine Funktionsmatrix mit hundert Zeilen ausfüllt.
Ein generischer Funktionsvergleich fällt bei einem System dieser Klasse fast zwangsläufig zugunsten von Projektron BCS aus, weil es fachlich fast alles kann, was in einer Matrix abgefragt wird. Genau darin liegt die Gefahr: Funktionsbreite ist kein Nutzen, solange sie nicht genutzt wird. Sinnvoller ist ein Vergleich entlang der Prozesse, die Sie tatsächlich belasten – der Monatsabschluss, die Fördermittelabrechnung, die Kapazitätsplanung über zwölf Wochen, die Nachkalkulation eines Festpreisprojekts. Lassen Sie diese Prozesse im Auswahlverfahren an Ihren eigenen Daten vorführen, nicht an einem Demobestand. Wer so vergleicht, erkennt schnell, ob die fachliche Tiefe für ihn ein Wert oder nur ein Kostenfaktor ist.
Die folgenden Bausteine bilden den Kern. Welche davon in Ihrer Ausbaustufe enthalten sind und in welcher Ausprägung, sollten Sie für Ihr konkretes Paket beim Anbieter bestätigen lassen, da sich der Zuschnitt zwischen Versionen unterscheiden kann.
Die Zeiterfassung ist funktional der unscheinbarste und organisatorisch der heikelste Baustein. Funktional, weil sie schlicht die Erfassung von Stunden auf Arbeitspakete leistet – über ein Wochenblatt, eine laufende Stoppuhr, die mobile Erfassung unterwegs oder die Nacherfassung durch eine berechtigte Person. Sensibel, weil an dieser Stelle Arbeitsrecht, Mitbestimmung und Unternehmenskultur zusammentreffen.
Fachlich wichtig ist die Unterscheidung zweier Zwecke, die in der Praxis gern vermischt werden. Die gesetzliche Arbeitszeiterfassung dokumentiert Beginn, Ende und Pausen und dient der Einhaltung des Arbeitszeitrechts. Die projektbezogene Aufwandserfassung ordnet geleistete Arbeit einem Kostenträger zu und dient Kalkulation und Abrechnung. Beides kann dieselbe Eingabe speisen, ist aber rechtlich und organisatorisch nicht dasselbe. Ein System, das beide Zwecke sauber trennt, erspart Ihnen später eine schwierige Diskussion mit Betriebsrat und Datenschutz.
Praktisch entscheidend ist die Erfassungsdisziplin. Eine Auswertung ist nur so gut wie die Daten, aus denen sie entsteht, und Stunden, die freitags für die ganze Woche aus dem Gedächtnis gebucht werden, sind für die Nachkalkulation von begrenztem Wert. Investieren Sie deshalb in eine Erfassung, die nicht länger als zwei Minuten pro Tag dauert – über Vorlagen, Favoriten für häufige Buchungen und eine Struktur, die nicht dreißig Ebenen tief ist. Die Akzeptanz der Zeiterfassung entscheidet über den Erfolg des gesamten Systems.
Der kaufmännische Strang beginnt vor dem Projekt. Kontakte, Firmen, Verkaufschancen, Angebote und Kalkulationen lassen sich im System führen, sodass aus einem gewonnenen Angebot direkt ein Projekt mit vorbelegter Struktur und kalkuliertem Aufwand entsteht. Das ist kein vollwertiges CRM im Sinne einer Vertriebssteuerung mit Kampagnen und Lead-Scoring, aber es deckt den projektnahen Teil des Vertriebs ab – und genau der ist der wertvolle, weil er die Kalkulationsgrundlage liefert.
Am anderen Ende steht die Fakturierung. Rechnungen entstehen aus abrechenbaren Stunden, aus Meilensteinen, aus Festpreisanteilen oder aus einer Kombination, je nach Vertragsform. Der eigentliche Gewinn liegt im Nebeneffekt: Weil Abrechenbarkeit bereits bei der Erfassung entschieden wird, macht das System sichtbar, wie viel geleistete Arbeit nicht in Rechnung geht. In vielen Projekten ist diese Zahl die unangenehmste und zugleich lehrreichste Erkenntnis der ersten Monate. Ob die Rechnungsstellung im System selbst erfolgt oder ob die Daten an die Finanzbuchhaltung übergeben werden, ist eine Architekturentscheidung, die früh getroffen werden sollte.
Sobald mehrere Dutzend Projekte parallel laufen, verschiebt sich die Steuerungsfrage von der Einzelprojekt- auf die Portfolioebene: Welche Projekte binden die knappste Ressource? Welche stehen auf Rot und warum? Welche Vorhaben sollten wir verschieben, um ein kritisches Projekt zu retten? Die Software bietet dafür verdichtete Sichten über Projektgruppen, Auslastungsübersichten und Statusberichte, die sich auf gleicher Datenbasis bis zum einzelnen Arbeitspaket herunterbrechen lassen.
Ergänzend lassen sich Risiken mit Eintrittswahrscheinlichkeit und Auswirkung führen, Änderungsanträge dokumentieren und Qualitätsprüfungen an Meilensteine binden. In der Praxis werden diese Bereiche seltener genutzt als die Kernfunktionen – und das ist meist richtig so. Beginnen Sie mit Struktur, Zeit und Controlling. Risiko- und Qualitätsmanagement sind sinnvolle Erweiterungen für das zweite Jahr, nicht Bestandteil eines gelungenen Erststarts.
Das ist keine Schwäche im technischen Sinne, sondern eine Folge der Zielgruppe. Ein System, dessen Daten Stundennachweise, Kalkulationen, Personalauslastung und Kundenprojekte umfassen, kann Inhalte nicht ohne Weiteres an externe Sprachmodelle geben. Wo Kunden ausdrücklich On-Premise betreiben, um Daten im Haus zu halten, wäre eine KI-Funktion, die genau diese Daten nach außen sendet, ein Widerspruch zum Produktversprechen. Anbieter in diesem Segment gehen den Weg deshalb vorsichtiger – und das ist konsistent.
Der praktische Automatisierungsgewinn liegt in der Beseitigung wiederkehrender Handgriffe, und dort ist erstaunlich viel möglich. Die wichtigsten Hebel im Alltag sind:
Wenn über KI in Systemen dieser Art gesprochen wird, sind drei Anwendungsfelder realistisch und drei eher Wunschdenken. Realistisch sind erstens Formulierungshilfen für Texte, die ohnehin im System entstehen – Statusberichte, Ticketantworten, Angebotsbeschreibungen. Zweitens Vorschläge bei der Erfassung, etwa die Zuordnung einer Buchung zu einem wahrscheinlichen Arbeitspaket auf Basis früherer Muster. Drittens Auffälligkeitsanalysen im Bestand: Projekte, deren Aufwandsverlauf vom Muster vergleichbarer Projekte abweicht, oder Schätzungen, die systematisch zu niedrig ausfallen.
Wunschdenken ist dagegen die Vorstellung, ein Modell könne Projektpläne belastbar erzeugen, Termine verlässlich prognostizieren oder Kapazitätskonflikte selbständig auflösen. Diese Aufgaben scheitern nicht an der Technik, sondern an der Datenlage: Sie hängen von Zusagen, Verträgen, Personen und Prioritäten ab, die im System nicht vollständig abgebildet sind. Wer KI-Funktionen bewertet, sollte deshalb prüfen, ob sie einen Menschen bei einer Routine entlasten – oder ob sie eine Entscheidung übernehmen sollen, deren Grundlage das System gar nicht kennt.
Es klingt unmodern, ist aber die belastbarste Erkenntnis aus Einführungsprojekten: Der größte Automatisierungsgewinn entsteht nicht durch zusätzliche Funktionen, sondern durch konsistente Stammdaten. Eine einheitliche Projektnummernlogik, ein durchdachter Katalog von Tätigkeitsarten, gepflegte Kunden- und Vertragsdaten, verlässliche Stundensätze und ein Rollenmodell, das der Realität entspricht – erst auf dieser Grundlage funktionieren Vorlagen, Auswertungen und Regeln zuverlässig.
Umgekehrt gilt: Wer Automatisierung auf unsauberen Stammdaten aufsetzt, automatisiert Fehler und skaliert sie. Ein falscher Stundensatz erzeugt dann nicht mehr eine falsche Rechnung, sondern zwölf. Planen Sie deshalb im Einführungsprojekt ausdrücklich Zeit für Stammdatenarbeit ein, benennen Sie eine verantwortliche Person dafür und wiederholen Sie die Prüfung nach sechs Monaten. Das ist die unspektakulärste und wirksamste Investition in einem solchen Projekt.
Das Ökosystem ist erwartungsgemäß anders aufgebaut als bei internationalen Cloud-Plattformen: kein großer App-Marktplatz mit hunderten Ein-Klick-Verbindungen, dafür belastbare Schnittstellen zu den Systemen, die im deutschen Mittelstand tatsächlich stehen. Für die Praxis ist das meist die nützlichere Variante, weil die relevanten Integrationen ohnehin nicht die exotischen sind, sondern Mail, Verzeichnisdienst und Buchhaltung.
Der wichtigste Alltagsübergang ist der zwischen E-Mail-Programm und Projektsystem. Typischerweise geht es um drei Vorgänge: Termine aus dem Projektsystem sollen im persönlichen Kalender erscheinen, Besprechungen sollen als Aufwand erfasst werden können, und projektrelevante E-Mails sollen samt Anhang beim richtigen Projekt oder Ticket landen, statt im persönlichen Postfach zu verschwinden. Für alle drei Vorgänge existieren in Systemen dieser Klasse Anbindungen, häufig als Erweiterung im Mailprogramm oder über Kalenderprotokolle.
Der Nutzen dieser Integration wird regelmäßig unterschätzt. Sie entscheidet darüber, ob Mitarbeitende das System als Teil ihres Arbeitsflusses erleben oder als zusätzliches Fenster, das sie einmal am Tag widerwillig öffnen. Prüfen Sie in der Pilotphase deshalb ausdrücklich, wie viele Klicks es kostet, eine Kunden-E-Mail einem Projekt zuzuordnen – diese Zahl sagt mehr über die spätere Akzeptanz aus als jede Funktionsbeschreibung. Klären Sie zugleich, ob Ihre Mailumgebung als lokale Installation oder als Cloud-Dienst betrieben wird, weil sich die Anbindungswege unterscheiden.
Für den Unternehmenseinsatz ist die Anbindung an vorhandene Identitäten der entscheidende Verwaltungsaspekt. Ohne sie entsteht eine zweite Benutzerdatenbank mit den bekannten Folgen: Ausgeschiedene behalten Zugänge, neue Mitarbeitende warten auf Freischaltung, Passwörter werden mehrfach vergeben. Systeme dieser Klasse unterstützen daher üblicherweise die Anbindung an Verzeichnisdienste sowie Anmeldeverfahren für einmalige Anmeldung; die in Ihrer Umgebung unterstützten Verfahren sollten Sie schriftlich bestätigen lassen.
Klären Sie in der Auswahlphase drei Fragen konkret: Werden Nutzende automatisch angelegt und deaktiviert? Lassen sich Gruppenzugehörigkeiten aus dem Verzeichnis in Rollen und Berechtigungen übersetzen? Ist die Anmeldung mit dem gewohnten Unternehmenskonto möglich, auch von unterwegs? Diese drei Punkte bestimmen den späteren Administrationsaufwand stärker als jede Funktionsliste – und sie sind bei einem System mit sensiblen Personal- und Kalkulationsdaten zugleich eine Sicherheitsfrage.
Der kaufmännische Übergang ist der wirtschaftlich wichtigste. Zwei Datenströme verlassen das Projektsystem regelmäßig: Rechnungsdaten in Richtung Finanzbuchhaltung und Zeitdaten in Richtung Lohnabrechnung oder Kostenrechnung. Für den deutschen Markt sind Übergaben in Formaten üblich, die von den verbreiteten Buchhaltungslösungen und Steuerberatungen verarbeitet werden können; ebenso Exporte, die sich in eine vorhandene Kostenrechnung einlesen lassen. Welche Formate und Schnittstellen konkret unterstützt werden, ist eine der ersten Fragen, die Sie mit Ihrer Buchhaltung und gegebenenfalls Ihrer Steuerberatung klären sollten.
Ein praktischer Hinweis aus Projekten: Beziehen Sie die Buchhaltung nicht erst zur Rechnungsstellung ein, sondern bereits bei der Definition der Projektstruktur. Ob Projekte als Kostenträger geführt werden, wie Nummernkreise aufgebaut sind, wie Anzahlungen und Teilrechnungen behandelt werden und wie mit projektübergreifenden Gemeinkosten umgegangen wird – all das entscheidet darüber, ob die Übergabe später automatisch funktioniert oder ob jemand jeden Monat manuell nacharbeitet. Eine halbe Stunde Abstimmung zu Beginn erspart Jahre kleiner Reibungen.
In vielen Organisationen existiert bereits ein Werkzeug für die operative Entwicklungsarbeit – häufig Jira in Softwareteams – und die Frage lautet, ob es abgelöst oder angebunden wird. Unsere Empfehlung ist in der Regel: anbinden. Entwicklungsteams arbeiten in einem Rhythmus aus Sprints, Backlogs und kleinteiligen Vorgängen, für den ein Projektsteuerungssystem nicht gebaut ist. Umgekehrt braucht die Geschäftsführung eine kaufmännische Sicht, die ein Entwicklungswerkzeug nicht liefert. Eine Kopplung, bei der Aufwände oder Fortschritte aus dem Entwicklungssystem in die Projektstruktur zurückfließen, verbindet beide Welten, ohne dass eine Seite ihre Arbeitsweise aufgeben muss.
Ähnlich verhält es sich mit Microsoft Project: Import und Export von Plänen sind vor allem in Übergangsphasen und in der Zusammenarbeit mit externen Planungspartnern wertvoll, die ihre Pläne in diesem Format liefern. Als Dauerlösung ist ein paralleler Planungsbestand dagegen problematisch, weil zwei Wahrheiten entstehen. Legen Sie deshalb früh fest, welches System die führende Planung hält – und halten Sie diese Festlegung schriftlich fest.
Für alles, was keine fertige Anbindung hat, ist eine Webservice-Schnittstelle der entscheidende Hebel. Typische Automatisierungen im Mittelstand sind: die Übernahme von Aufträgen aus einem Vertriebssystem in eine Projektstruktur, die Übergabe von Zeitdaten an ein Zeitwirtschaftssystem, die Synchronisation von Kundendaten aus einem führenden CRM, die Belieferung eines Berichtswesens oder Datenlagers mit Projektkennzahlen sowie Anbindungen an Zeiterfassungsterminals in der Produktion.
Ein Rat aus der Praxis: Beginnen Sie nicht mit der Schnittstelle, sondern mit einem sauberen manuellen Prozess, der einige Wochen gelaufen ist. Erst wenn klar ist, welche Felder wirklich gebraucht werden und wie mit Sonderfällen umgegangen wird, lohnt sich die Automatisierung. Wer zu früh integriert, zementiert eine Datenstruktur, die er kurz darauf ohnehin ändern muss – und bezahlt die Änderung dann zweimal.
Diese drei Werkzeuge stammen ebenfalls aus dem deutschsprachigen Raum und teilen einen wesentlichen Vorzug: eine niedrige Einstiegshürde. InLoox punktet mit seiner engen Verbindung zur Microsoft-Welt und ist besonders dort stark, wo Outlook der zentrale Arbeitsplatz ist. factro überzeugt durch eine sehr zugängliche Aufgaben- und Strukturdarstellung und ist in kleinen und mittleren Teams schnell produktiv. awork setzt auf ein modernes Bedienerlebnis mit gutem Gefühl für Auslastung und Wochenplanung.
Der Unterschied liegt in der Tiefe der kaufmännischen Kette. Alle drei bieten Zeiterfassung, alle drei bieten Auswertungen – aber die durchgängige Verbindung aus Angebotskalkulation, Ressourcenmodell, Fortschrittsbewertung, Fakturierung und Nachkalkulation auf einem Datenmodell ist bei Projektron BCS ausgeprägter. Umgekehrt ist dieser Vorsprung nur dann ein Wert, wenn Sie ihn nutzen. Ein Team von fünfzehn Personen mit überschaubaren Projekten und einfacher Abrechnung fährt mit einem schlankeren Werkzeug schneller und günstiger. Die Grenze verläuft dort, wo Projektwirtschaftlichkeit zur Führungsfrage wird.
Microsoft Project ist ein Planungswerkzeug im engeren Sinne: stark in Terminlogik, Abhängigkeiten und Ressourcenausgleich, aber ohne integrierte Erfassung, Abrechnung und Kundensicht. Es beantwortet die Frage, wann etwas fertig sein kann – nicht, was es gekostet hat und was davon abrechenbar war. In der Praxis begegnet es uns häufig als Planungsinsel einzelner Projektleitungen, deren Pläne niemand außerhalb pflegt. Für Organisationen, die Projektsteuerung als gemeinsamen Prozess betreiben wollen, ist das eine strukturelle Schwäche.
Jira wiederum ist im Softwareumfeld eine sehr gute Wahl für die operative Arbeit: Backlogs, Sprints, Boards, Verknüpfung mit Entwicklungsprozessen. Was es nicht ist, ist ein kaufmännisches Steuerungssystem. Auslastungsplanung über Abteilungen hinweg, Angebotskalkulation, Fakturierung, Nachkalkulation und Fördermittelnachweise gehören nicht zu seinem Zweck und lassen sich nur über Erweiterungen und Eigenbau annähern. Die pragmatischste Konstellation, die wir sehen, ist deshalb selten ein Entweder-oder, sondern eine klare Rollenteilung mit definierter Schnittstelle. Zu Jira und zu awork finden Sie in unserer Wissensdatenbank eigene Einordnungen.
Der ernsthafteste Wettbewerber ist häufig das bereits vorhandene ERP-System. Das Argument klingt zwingend: Die Stammdaten sind da, die Buchhaltung ist angeschlossen, eine zusätzliche Lizenz erscheint überflüssig. In der kaufmännischen Auswertung sind ERP-Projektmodule oft tatsächlich stark, weil sie unmittelbar am Rechnungswesen hängen.
Die Schwäche liegt regelmäßig im operativen Alltag. Projektleitungen brauchen eine Planungssicht, Teams brauchen eine Aufgabensicht, und alle brauchen eine Erfassung, die in zwei Minuten erledigt ist. Wo ERP-Oberflächen für Sachbearbeitung im Rechnungswesen entworfen wurden, entsteht genau hier Reibung – und Reibung an der Erfassung ist tödlich, weil sie die Datengrundlage zerstört. Prüfen Sie deshalb nicht die Modulliste des ERP, sondern lassen Sie sich den Tagesablauf einer Projektleitung und einer erfassenden Person vorführen. Diese zwanzig Minuten sind aussagekräftiger als jedes Datenblatt.
Zusammengefasst spricht für das System, wenn mindestens drei der folgenden Punkte zutreffen: Projekte sind Ihr Geschäftsmodell und nicht dessen Beiwerk. Abrechenbare Stunden bestimmen Ihren Umsatz. Sie müssen Aufwände gegenüber Dritten nachweisen. Sie planen Kapazitäten über mehrere Monate und mehrere Projekte hinweg. Sie wollen oder müssen das System im eigenen Rechenzentrum betreiben. Und Sie sind bereit, Einführungsaufwand als Investition zu behandeln statt als Störung.
Gegen das System spricht, wenn Ihre Projekte klein und gleichförmig sind, wenn die Organisation kurzfristig produktiv werden muss, wenn niemand die Rolle einer fachlichen Systemverantwortung übernehmen kann oder wenn die Erwartung besteht, dass Software Prozessklärung ersetzt. Diese Abwägung sollten Sie schriftlich 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 Technik, weil eine falsch geschnittene Projektstruktur später erheblich teurer zu korrigieren ist als eine Servereinstellung.
Die Wahl des Betriebsmodells ist strategischer, als sie technisch wirkt. Der Betrieb im eigenen Rechenzentrum gibt maximale Kontrolle: Die Daten verlassen das Haus nicht, Wartungsfenster liegen in Ihrer Hand, Anbindungen an interne Systeme sind unmittelbar möglich, und die datenschutzrechtliche Argumentation ist denkbar kurz. Der Preis dafür ist Verantwortung – für Server, Datenbank, Sicherung, Wiederanlauf, Sicherheitsaktualisierungen und Versionswechsel. Diese Verantwortung braucht benannte Personen und Zeitbudget, nicht guten Willen.
Das Hosting beim Anbieter in Deutschland nimmt Ihnen diesen Betrieb ab und verlagert ihn zu jemandem, der das System kennt. Verfügbarkeit, Sicherung und Aktualisierung sind vertraglich zugesichert, die Daten bleiben im deutschen Rechtsraum, und Ihre IT kann sich auf Anbindungen und Anwenderunterstützung konzentrieren. Dafür geben Sie Kontrolle über Wartungszeitpunkte ab und benötigen einen Auftragsverarbeitungsvertrag. Für die meisten Mittelständler ohne eigenes Rechenzentrumsteam ist das Hosting die wirtschaftlichere Wahl; für Organisationen mit strengen internen Vorgaben oder besonderen Sicherheitsanforderungen bleibt der Eigenbetrieb attraktiv.
Wichtig ist, die Entscheidung nicht allein an der Datenschutzfrage aufzuhängen. Beide Modelle sind datenschutzkonform gestaltbar. Entscheidend sind eher: verfügbare IT-Kapazität, Erwartungen an Verfügbarkeit, Anzahl interner Anbindungen und die Frage, wer im Störungsfall nachts erreichbar sein muss.
Die hohe Anpassbarkeit ist ein Hauptargument für das System und zugleich die größte Projektfalle. Die Versuchung ist groß, jede gewachsene Eigenheit abzubilden – jedes Sonderfeld, jede Ausnahmeregel, jeden hausinternen Sonderweg. Das Ergebnis ist ein System, das die Vergangenheit perfekt konserviert, bei jedem Versionswechsel Aufwand erzeugt und nach zwei Jahren niemand mehr vollständig versteht.
Bewährt hat sich eine einfache Regel: Jede Anpassung braucht eine benannte fachliche Begründung und eine Person, die sie verantwortet. Alles, was nur „so haben wir das immer gemacht“ als Begründung hat, wird zunächst zurückgestellt und nach sechs Monaten Betrieb erneut geprüft. Erfahrungsgemäß verschwindet ein erheblicher Teil dieser Anforderungen von selbst, weil sich die Arbeitsweise ohnehin verändert hat. Prüfen Sie außerdem, welche Anpassungen als Konfiguration gelten und welche als individuelle Erweiterung – Letztere haben Auswirkungen auf Wartung und Versionsfähigkeit und sollten vertraglich sauber eingeordnet sein.
Ein Projektsystem enthält sensible Informationen: Stundensätze, Deckungsbeiträge, Auslastung einzelner Personen, Kundenkonditionen. Ein durchdachtes Rechtekonzept ist deshalb keine Verwaltungsformalie, sondern Voraussetzung für Akzeptanz. Als Leitlinie hat sich bewährt, entlang von vier Ebenen zu denken: Was sieht eine erfassende Person von den eigenen Daten? Was sieht eine Projektleitung über ihr Projekt? Was sieht eine Führungskraft über ihre Abteilung? Und was ist der Geschäftsführung und dem Controlling vorbehalten?
Besondere Sorgfalt verdient die Frage, wer die Zeitbuchungen einzelner Personen einsehen darf. Hier berühren sich Datenschutz, Mitbestimmung und Vertrauenskultur unmittelbar. Ein System, das jeder Führungskraft die Minutenbuchungen aller Mitarbeitenden zeigt, erzeugt Widerstand, den keine Schulung auffängt. Legen Sie die Sichtbarkeiten deshalb gemeinsam mit Datenschutz und Interessenvertretung fest, dokumentieren Sie sie und kommunizieren Sie sie offen – das ist wirksamer als jede nachträgliche Beruhigung.
Die Frage nach den Altdaten kommt in jedem Projekt und wird meist zu großzügig beantwortet. Übernommen werden sollten Stammdaten – Kunden, Mitarbeitende, Verträge, aktive Projekte mit ihrer Struktur – sowie die Zeitdaten des laufenden Geschäftsjahres, soweit sie für Abrechnung und Auswertung gebraucht werden. Alles Weitere gehört in ein Archiv, nicht in das neue System.
Der Grund ist praktischer Natur: Historische Daten aus Tabellen und Vorgängersystemen entsprechen selten der neuen Struktur. Sie müssen aufwendig zugeordnet werden, verwässern anschließend die Auswertungen und erzeugen Diskussionen über Zahlen, die niemand mehr rekonstruieren kann. Ein sauberer Schnitt zum Geschäftsjahres- oder Quartalsbeginn, kombiniert mit einem lesbaren Archiv der Altsysteme, ist in fast allen Fällen die bessere Lösung – und sie verkürzt das Einführungsprojekt spürbar.
Das klassische Systemhaus lebt von drei Erlösarten gleichzeitig: Projektgeschäft, Wartungs- und Serviceverträge sowie Zeit- und Materialabrechnung im laufenden Support. Ohne integriertes System liegen diese drei in getrennten Welten – Projekte in einer Tabelle, Support im Ticketwerkzeug, Verträge in der Buchhaltung. Die Folge ist eine bekannte Blindstelle: Niemand weiß zuverlässig, ob ein Wartungskunde mit seinem Kontingent auskommt oder ob monatlich stillschweigend Zusatzleistung erbracht wird.
Genau hier liegt der Hebel. Wenn Tickets auf Verträge und Projekte buchen, wird der Verbrauch eines Kontingents laufend sichtbar, Überschreitungen können rechtzeitig angesprochen und Verträge fundiert nachverhandelt werden. In Einführungsprojekten ist dies regelmäßig die Erkenntnis, die den Business Case trägt: nicht die eingesparte Verwaltungszeit, sondern die zuvor unsichtbare, unentgeltlich erbrachte Leistung. Wichtig ist, diese Transparenz konstruktiv zu nutzen – als Grundlage für Gespräche mit Kunden, nicht als Vorwurf an die eigenen Teams.
In Planungsbüros ist die Abrechnung eng an Leistungsphasen, vereinbarte Honorare und dokumentierte Nachträge geknüpft. Die entscheidende Frage lautet selten, ob ein Projekt fertig wird, sondern ob es innerhalb des kalkulierten Honorars fertig wird – und ob Zusatzleistungen, die im Projektverlauf entstehen, dokumentiert und beauftragt sind. Beide Fragen setzen eine Projektstruktur voraus, die Phasen und Nachträge sauber trennt, sowie eine Zeiterfassung, die phasengenau bucht.
Aus der Praxis kommen zwei Hinweise. Erstens: Die Gliederungstiefe muss zur Erfassungsrealität passen. Wer vierzig Buchungspositionen je Projekt anlegt, bekommt keine bessere Auswertung, sondern schlechtere Daten, weil Mitarbeitende irgendwo buchen. Zweitens: Nachträge gehören von Anfang an als eigenständige Struktur ins System, nicht als Kommentar. Nur so lässt sich später belegen, welcher Aufwand auf welche Beauftragung entfällt – und das ist im Streitfall die einzige belastbare Grundlage.
Für Forschungseinrichtungen, Institute und forschungsnahe Unternehmen ist die Nachweisführung der eigentliche Treiber. Fördermittelgeber verlangen personenbezogene Stundennachweise, die Zuordnung von Aufwänden zu Vorhaben und Arbeitspaketen sowie die Abgrenzung geförderter von nicht geförderter Tätigkeit. Wer das im Nachhinein aus Kalendern und Erinnerungen rekonstruiert, produziert Aufwand und Risiko zugleich.
Ein System, das Stunden im Alltag auf Vorhabensstrukturen bucht, dreht diese Logik um: Der Verwendungsnachweis wird zur Auswertung eines ohnehin gepflegten Bestands. Wichtig sind dabei drei Punkte, die früh geklärt werden sollten. Erstens, ob die geforderte Nachweisform aus dem System heraus erzeugt werden kann – lassen Sie sich das mit einem echten Nachweisformular zeigen. Zweitens, wie mit Korrekturen umgegangen wird, denn nachträgliche Änderungen an Zeitbuchungen müssen nachvollziehbar bleiben. Drittens, wie Personalkostensätze hinterlegt und aktualisiert werden. Diese drei Fragen entscheiden über die Prüffähigkeit stärker als jede Funktionsliste.
Organisationen, die für die öffentliche Hand arbeiten oder selbst Teil davon sind, stehen unter besonderem Dokumentationsdruck. Entscheidungen müssen nachvollziehbar, Aufwände belegbar und Auswertungen reproduzierbar sein – auch Jahre später und auch dann, wenn die beteiligten Personen nicht mehr im Haus sind. Ein System mit lückenloser Änderungshistorie, klaren Berechtigungen und stabilen Auswertungsdefinitionen ist dafür deutlich besser geeignet als eine Sammlung gewachsener Tabellen.
Hinzu kommt die Betriebsfrage. In diesem Umfeld ist der Betrieb im eigenen Rechenzentrum oder in einem klar benannten deutschen Rechenzentrum oft nicht nur Wunsch, sondern Vorgabe. Dass beide Modelle zur Verfügung stehen, ist deshalb ein wesentliches Argument – und einer der Gründe, warum Systeme deutscher Herkunft in solchen Vergabeverfahren regelmäßig gut abschneiden. Klären Sie dennoch früh, welche konkreten Nachweise Ihre Vergabestelle oder Aufsicht verlangt, und lassen Sie sich die entsprechenden Unterlagen vor der Entscheidung vorlegen.
Zunächst zu den Kosten, weil sie in der Praxis eng mit der Betriebs- und Datenschutzfrage zusammenhängen. Die Gesamtkosten setzen sich aus fünf Blöcken zusammen, von denen nur der erste vollständig auf dem Angebot steht:
Diesen Kosten steht ein Nutzen gegenüber, der sich benennen und später überprüfen lässt: eine belastbare Projektnachkalkulation statt Schätzungen, ein sichtbarer Abrechnungsgrad, weniger unentgeltlich erbrachte Leistung, kürzere Monatsabschlüsse, prüffähige Nachweise ohne Nacharbeit und eine Kapazitätsplanung, die Zusagen absichert. Wir empfehlen, zwei oder drei dieser Erwartungen vor der Einführung schriftlich zu fixieren und nach zwölf Monaten zu prüfen, ob sie eingetreten sind.
Der Kern der Debatte um internationale Cloud-Anbieter ist die Frage möglicher behördlicher Zugriffe nach ausländischem Recht, die auch dann relevant sein können, wenn Daten physisch in Europa liegen. Diese Diskussion wird über Vertragsklauseln, technische Maßnahmen und Transferfolgenabschätzungen adressiert – möglich, aber aufwendig, und im Ergebnis selten vollständig frei von Restrisiko.
Bei einem deutschen Anbieter mit Betrieb im eigenen Rechenzentrum oder Hosting in Deutschland entfällt dieser Prüfstrang weitgehend. Es gibt keine Drittlandübermittlung zu bewerten und eine deutlich kürzere Argumentationskette gegenüber Datenschutzbeauftragten, Betriebsrat und – im öffentlichen oder geförderten Umfeld – gegenüber Aufsichtsstellen. Beim Betrieb im eigenen Rechenzentrum entfällt zusätzlich die Auftragsverarbeitung, weil kein Dienstleister die Daten verarbeitet. 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. Zwecke, Rechtsgrundlagen, Löschfristen, Berechtigungen und Transparenz bleiben vollständig in Ihrer Verantwortung als verantwortliche Stelle.
Der sensibelste Punkt der gesamten Einführung ist die Zeiterfassung. Systeme, die geeignet sind, Verhalten oder Leistung von Beschäftigten zu überwachen, berühren in Betrieben mit Betriebsrat regelmäßig mitbestimmungspflichtige Tatbestände – unabhängig davon, ob eine Überwachung tatsächlich beabsichtigt ist. Maßgeblich ist die objektive Eignung, nicht die Absicht. Eine Betriebsvereinbarung ist deshalb in aller Regel nicht optional, sondern der reguläre Weg.
Aus Projekterfahrung ist die frühe Einbindung der Interessenvertretung nicht nur rechtlich geboten, sondern praktisch der schnellere Weg. Wer den Betriebsrat erst kurz vor dem Rollout einbezieht, riskiert Verzögerungen von Monaten. Wer ihn von Beginn an beteiligt, kann gemeinsam sinnvolle Grenzen definieren: welche Auswertungen zulässig sind, welche Sichtbarkeiten gelten, wie mit Korrekturen umgegangen wird, wie lange Daten aufbewahrt werden und ausdrücklich, wofür die Daten nicht verwendet werden. Diese letzte Zusage ist für die Akzeptanz oft die wichtigste.
Ergänzend ist die Abgrenzung zur gesetzlichen Arbeitszeiterfassung zu klären. Die Pflicht zur Erfassung von Arbeitszeiten und die betriebswirtschaftliche Erfassung von Projektaufwänden verfolgen unterschiedliche Zwecke und unterliegen unterschiedlichen Regeln. Beide können dieselbe Eingabe nutzen, sollten aber konzeptionell und in der Auswertung getrennt bleiben. Wie diese Trennung in Ihrem Fall auszugestalten ist, klären Sie mit Ihrer Datenschutz- und Rechtsberatung.
Fünf Punkte gehören in jede Einführung. Erstens die Aufnahme der Verarbeitung in das Verarbeitungsverzeichnis, mit klar benannten Zwecken und Rechtsgrundlagen. Zweitens ein dokumentiertes Berechtigungskonzept, das regelt, wer welche Zeit-, Leistungs- und Kalkulationsdaten sieht. Drittens Aufbewahrungs- und Löschfristen, abgestimmt mit handels- und steuerrechtlichen Aufbewahrungspflichten sowie mit den Anforderungen von Fördermittelgebern. Viertens die Mitbestimmung, idealerweise als Betriebsvereinbarung mit klaren Auswertungsgrenzen. Fünftens Transparenz gegenüber den Beschäftigten: eine verständliche Information darüber, welche Daten erhoben werden, wer sie sieht und wozu sie dienen.
Beim Hosting kommt der Auftragsverarbeitungsvertrag hinzu, inklusive einer aktuellen Liste der Unterauftragsverarbeiter und der technischen und organisatorischen Maßnahmen. Beim Eigenbetrieb tragen Sie diese Verantwortung selbst – was die vertragliche Seite vereinfacht, die technische aber anspruchsvoller macht: Sicherungskonzept, Wiederanlauf, Zugriffsprotokollierung und Aktualisierungsdisziplin liegen dann vollständig bei Ihnen und sollten ebenso dokumentiert sein.
