Bausoftware auswählen: fünf Fälle für einen ehrlichen Demotest
Eine Demo sieht schnell überzeugend aus, wenn alle Daten vorbereitet sind und die vorführende Person jeden Klick kennt. Für deinen Betrieb zählt, ob Mitarbeitende ihre Aufgaben selbst erledigen können und die Ergebnisse im Büro brauchbar ankommen.
Bereite deshalb fünf typische Fälle vor, bevor du Bausoftware vergleichst. Nimm eine Person von der Baustelle, eine aus der Projektleitung und eine aus dem Büro dazu. Nutzt dieselben Fälle bei jedem Anbieter. So bekommt ihr eine gemeinsame Entscheidungsgrundlage, die mehr aussagt als eine lange Liste mit Häkchen.
Vor der Demo: die fünf Fälle aus eurem Alltag sammeln
Schaut euch eine gewöhnliche Arbeitswoche an. Wo wird doppelt erfasst? Welche Unterlagen fehlen beim Abrechnen? Welche Information muss jemand telefonisch nachfragen? Wähle wiederkehrende Abläufe, bei denen eine Verbesserung für euch spürbar wäre.
Schreibe für jeden Fall den heutigen Ablauf und das gewünschte Ergebnis auf. «Rapporte digitalisieren» ist zu breit. «Der Vorarbeiter erfasst eine Zusatzleistung; die Projektleitung prüft sie und das Büro findet die geprüfte Fassung mit Stunden und Belegen» lässt sich vorführen und bewerten. Dieser Einstieg über Ist-Prozesse und Ziele entspricht auch dem Vorgehen im Digitalisierungsleitfaden des SECO-KMU-Portals.
Für die Demo reichen erfundene oder anonymisierte Daten. Bereite eine kleine Projektliste, zwei Teams, einige Stunden und einen Beispielrapport vor. Notiere bei jedem Fall, was zwingend funktionieren muss und wo ein einfacher manueller Schritt vertretbar ist.
Fünf Aufgaben, die ihr selbst durchspielt
1. Ein Team am Morgen umplanen
Im fiktiven Gerüstbaubetrieb fällt eine Person aus. Die Projektleitung verschiebt eine zweite Person auf eine andere Baustelle und passt die Einteilung an. Ein Mitarbeiter öffnet danach seine eigene Ansicht auf dem Handy.
Das prüft ihr: Erkennt er die gültige Einteilung, den Arbeitsort und die nötigen Informationen? Ist klar, wann die Änderung für das Team sichtbar wird? Kann die Projektleitung erkennen, ob eine Person doppelt eingeplant ist? Lasst euch den Ablauf mit den tatsächlichen Berechtigungen zeigen, nicht nur in einem Administratorkonto.
2. Stunden bei schlechter Verbindung erfassen
Eine Mitarbeiterin soll ihre Arbeitszeit dem richtigen Projekt zuordnen. Unterbrecht während des Tests die Internetverbindung und versucht genau diesen Ablauf. Schliesst die App danach und öffnet sie erneut, bevor ihr wieder online geht.
Das prüft ihr: Bleibt die Eingabe erhalten? Zeigt das System, was lokal gespeichert und was bereits übertragen ist? Was passiert nach der erneuten Verbindung? Falls diese Funktion Internet braucht, muss der vereinbarte Ersatzweg funktionieren. «Offline verfügbar» sollte sich immer auf eine konkrete Aufgabe beziehen; eine lesbare Projektliste beweist noch keine Offline-Zeiterfassung.
3. Eine Zusatzleistung bis ins Büro verfolgen
Im fiktiven Gartenbaubetrieb wurde eine zusätzliche Pflanzfläche bestellt. Das Team erfasst die ausgeführte Arbeit mit Stunden, Material und Foto. Die Projektleitung prüft den Rapport, das Büro sucht ihn anschliessend für die weitere Bearbeitung.
Das prüft ihr: Bleiben Projekt, Leistungsbeschreibung und Belege zusammen? Sind offene Punkte sichtbar? Welche Angaben müssen nochmals eingetippt werden? Ein digitaler Rapport belegt nicht automatisch eine Bestellung oder die Vergütungsgrundlage. Prüft deshalb auch, wo die zugehörige Vereinbarung abgelegt und wie sie gefunden wird.
4. Einen Fehler nach der Prüfung korrigieren
Im Test wurde ein Rapport dem falschen Projekt zugeordnet oder eine Stunde zu viel erfasst. Lasst eine berechtigte Person die Korrektur durchführen und öffnet danach die Unterlagen erneut aus Sicht des Büros.
Das prüft ihr: Ist nachvollziehbar, was korrigiert wurde? Welche Fassung ist gültig? Was geschieht mit einem bereits exportierten PDF oder einer schon übernommenen Abrechnungsposition? Eine gute Antwort beschreibt auch die nötige Kontrolle durch Menschen. Ein stilles Überschreiben ist für euren Ablauf möglicherweise unzureichend.
5. Ein Projekt vollständig herausgeben
Zum Abschluss wollt ihr das Testprojekt ausserhalb der Software weiterverwenden. Fordert den Export der von euch benötigten Daten und Dokumente an und öffnet die Dateien tatsächlich.
Das prüft ihr: Sind Rapporte, Fotos, Anhänge und Zuordnungen enthalten? Gibt es strukturierte Daten, falls ihr diese für ein anderes System braucht? Ein PDF ist gut lesbar, ersetzt aber nicht jeden Datenexport. Falls eine Buchhaltungsschnittstelle wichtig ist, prüft die konkret eingesetzte Lösung und einen Beispielbeleg mit eurem Büro oder Treuhänder. «Schnittstelle vorhanden» sagt noch nicht, welche Informationen in welcher Richtung übertragen werden.
Schweizer Anforderungen gezielt ergänzen
Arbeitet ihr mit NPK-Leistungsverzeichnissen, nehmt einen passenden Testfall aus eurem Betrieb dazu. Lasst einen geeigneten CRBX-Datensatz importieren und wieder exportieren und prüft die benötigten Inhalte. Klärt dabei separat, welche NPK-Datenlizenzen ihr benötigt und welche Datenformate und Funktionen die konkrete Software unterstützt. Die NPK-Wegleitung des CRB unterscheidet Datenlizenzen und Softwarewerkzeuge. Ein Häkchen bei «NPK» beantwortet diese Fragen nicht.
Wenn ihr keine NPK-Ausschreibungen bearbeitet, muss daraus kein zusätzliches Auswahlkriterium werden. Dasselbe gilt für selten gebrauchte Spezialfunktionen: Entscheidend ist euer tatsächlicher Bedarf.
Export, Datenschutz und Einführung schriftlich klären
Neben den Testfällen braucht es einige konkrete Antworten. Wer richtet Stammdaten und Rechte ein? Wer schult das Team, und wie viel Zeit plant ihr intern dafür ein? Welche Unterstützung ist enthalten? Welche Kosten entstehen für Einrichtung, Lizenzen, Zusatzmodule, Geräte und laufenden Support? Vergleicht dieselbe Nutzungsdauer und dieselbe Anzahl Personen.
Für Personendaten gehören auch Bearbeitungsländer, Unterauftragnehmer sowie Rückgabe und Löschung beim Vertragsende auf die Prüfliste. Der EDÖB erläutert diese Punkte für Cloud-Dienste. Die datenschutzrechtliche Rückgabe ist dabei nicht gleichbedeutend mit einem vollständigen, praktisch nutzbaren Export aller Geschäftsdaten. Lasst euch beides erklären und die für euren Wechsel wichtigen Dateien zeigen.
Eine Bewertung, die offene Fragen sichtbar lässt
Verwendet für jeden der fünf Fälle dieselbe kleine Tabelle:
- [Aufgabe]
Von uns selbst getestet?: [Ja / nur vorgeführt / offen]
Ergebnis und Beleg: [Ergebnis, Datei oder Screenshot]
Offener Punkt / verantwortlich: [Frage, Name, Termin]
Bewertet einen Fall als «erfüllt», «mit akzeptiertem Zusatzschritt erfüllt» oder «nicht erfüllt». Markiert zwingende Anforderungen vor den Demos. Eine solche Anforderung wird nicht dadurch unwichtig, dass ein Anbieter bei zehn Nebenfunktionen überzeugt.
Notiert auch, wie oft jemand Hilfe brauchte. Die Dauer einer ersten Übung ist noch keine belastbare Zeitersparnis. Für die engere Auswahl folgt ein begrenzter Pilot im eigenen Betrieb, bei dem ihr Aufwand und Rückfragen über mehrere vergleichbare Vorgänge erfasst.
Nachricht an den Anbieter zum Kopieren
Wir prüfen eine Bausoftware für [Gewerk / Teamgrösse]. In der Demo möchten wir fünf eigene Fälle durchspielen: [Fälle einfügen]. Dabei testen Mitarbeitende aus Baustelle, Projektleitung und Büro selbst. Bitte zeigt uns auch den Umgang mit fehlender Internetverbindung, Korrekturen und einen nutzbaren Projektexport. Funktionen, die erst geplant sind, halten wir separat fest. Für die Entscheidung benötigen wir zudem den Einführungsaufwand und ein Angebot mit allen für diese Fälle nötigen Bestandteilen.
Du möchtest diesen Test mit Caturix durchführen? Schicke deine fünf Fälle über die Kontaktseite für Beratung und Demo. Damit beginnt das Gespräch bei euren Aufgaben und einem überprüfbaren Ergebnis.