Jede Woche: was die Software jetzt kann.

KW 41 · 2026

Zehn neue Funktionen für Akquise und Kundenbetreuung — und ein Leistungsnachweis, der nachgerechnet ist

5. Oktober 2026 · Lesezeit 5 Minuten · wird bis Freitag fortgeschrieben

Das Modul für Akquise und Kundenbetreuung hat zehn Funktionen dazubekommen. Die nützlichste ist die unscheinbarste: eine Liste der Kunden, mit denen seit einem halben Jahr niemand gesprochen hat. Sie füllt sich von selbst. Ein Kunde, der so lange nichts hört, bereitet seine nächste Ausschreibung ohne Sie vor.

Dazu: Eine Reklamation gilt erst als erledigt, wenn jemand hinschreibt, wie. Ein Haken allein ist kein Erledigungsstand. Und doppelte Kontakte — dieselbe Marktleiterin einmal mit Vornamen und Festnetz, einmal mit Kürzel und Mobilnummer — lassen sich zusammenführen, ohne dass eine Verknüpfung verloren geht.

Ein Leistungsnachweis, auf dem überall dieselbe Zahl steht

Der Leistungsnachweis ist das Papier, das der Auftraggeber unterschreibt und nach dem abgerechnet wird. Ansehen genügt da nicht. Also hat sich die Prüfung einen Tag mit bekannten Zeiten gebaut — eine Schicht von acht bis sechzehn Uhr mit einer halben Stunde Pause, eine zweite von neun bis dreizehn Uhr — und nachgerechnet: 690 Minuten. Auf dem Nachweis, im Monatsabschluss und in der Tabelle für die Buchhaltung muss dieselbe Zahl stehen. Sie steht.

Nachweise gehen nur an Empfänger des eigenen Objekts

Wer einen Nachweis verschickt, wählt auf der Seite den Empfänger, und die Seite bietet nur die Ansprechpartner des richtigen Objekts an. Jetzt prüft das auch der Server: Gehört ein Empfänger nicht zum Objekt, geht an keinen etwas hinaus.

Vorher prüfte der Server das nicht noch einmal. Wer die Anfrage von Hand zusammensetzte, hätte den Nachweis eines Marktes dem Marktleiter eines anderen schicken können — möglich nur aus dem eigenen Betrieb heraus, mit einem Zugang, der zustellen darf. Trotzdem ist es geschlossen. Was eine Seite nicht anbietet, ist damit noch nicht verboten. Verboten ist erst, was der Server ablehnt.

Warum das für Ihren Betrieb zählt

Ein Baustein darf bei uns nur dann fertig heißen, wenn jede seiner Anforderungen einzeln nachgesehen ist — mit einer Prüfung, die ihre Nummer trägt, oder mit einem Eintrag, der sagt, warum sie nicht gebaut ist. Wenn Ihnen ein Anbieter sagt, eine Funktion sei fertig, fragen Sie, woran er das festmacht. „Es läuft“ ist eine Antwort. „Jede Anforderung ist einzeln nachgesehen, und hier steht, welche fehlt“ ist eine bessere.

Wie wir es abgesichert haben

Das Modul stand auf unserer Fortschrittsliste als fertig. Diese Woche haben wir seine 83 Anforderungen einzeln genommen und für jede im Programm nachgesehen, ob sie gebaut ist. Fünfzehn waren es nicht — darunter Anhänge am Vorgang, die Betreuung bestehender Kunden, Reklamationen und änderbare Verkaufsstufen. Geprüft war, was gebaut wurde, nicht, ob alles gebaut wurde, was verlangt war. Zehn der fünfzehn sind inzwischen gebaut.

Was noch offen ist

Vier Bausteine haben durch die härtere Regel ihren Stand verloren und stehen jetzt auf „teilweise“. Das sieht auf der Liste wie ein Rückschritt aus. Es ist der erste Stand, dem man trauen kann.

Stand heute: 5 472 automatische Prüfungen, alle grün. 1759 Regeln, die jede Prüfung absichtlich kaputtmachen und erwarten, dass es auffällt. Von 649 Anforderungen sind 312 einzeln nachgesehen.

KW 40 · 2026

Schon beim Klingeln steht auf dem Gerät, wer anruft — und die Antwort kommt nur aus dem eigenen Betrieb

2. Oktober 2026 · Lesezeit 5 Minuten

Das Telefon klingelt, und noch bevor jemand abnimmt, steht auf dem Gerät, wer anruft: der Name des Marktleiters, der Kunde, die Kundennummer. Das haben wir diese Woche gebaut. Die Telefonanlage fragt im Moment des Klingelns bei der Anwendung nach, und die Anwendung antwortet in rund einer Millisekunde.

Acht Schreibweisen, ein Kontakt

Dieselbe Nummer steht in jedem Betrieb anders im Adressbuch: mit Ländervorwahl oder ohne, mit Schrägstrich, mit Leerzeichen, mit der berüchtigten „(0)" in der Mitte. Die Telefonanlage liefert sie wieder anders. Verglichen werden deshalb nur die letzten neun Ziffern — roh, ohne jede Deutung. Das klingt grob und ist genau deshalb verlässlich: Acht Schreibweisen derselben Nummer finden denselben Kontakt, auch wenn das Adressbuch sie national führt und die Anlage international fragt.

Die Auskunft bleibt im eigenen Betrieb

Unsere Anwendung führt viele Betriebe nebeneinander. Jede Abfrage nennt deshalb ihren Betrieb, und der kommt aus dem Schlüssel der Telefonanlage, nicht aus der Anfrage. Wer die Anfrage fälscht, kann den Betrieb nicht wechseln.

Die Vorlage für diese Funktion beschrieb ein System mit einem Bestand. Eine Auskunft, die einfach „im Bestand" sucht, hätte über alle Betriebe gesucht — und ein Anrufer bei Betrieb A hätte den Namen eines Kunden von Betrieb B auf dem Display erscheinen lassen. Das wäre die Weitergabe personenbezogener Daten an einen Fremden gewesen.

Warum das für Ihren Betrieb zählt

Eine Funktion ist erst fertig, wenn sie dort funktioniert, wo sie gebraucht wird. Deshalb endet bei uns eine Auslieferung nicht mit „hochgeladen", sondern mit einem Abruf von außen — bis zu der Stelle, an der die Funktion tatsächlich etwas tut.

Wie wir es abgesichert haben

Bei der Auslieferung haben wir drei Dinge nachgesehen, die unsere Prüfungen bis dahin nicht sehen konnten. Ein Wort, das die Datenbank seit einer Version für sich selbst reserviert, stand als Tabellenname im Weg — die Regel dagegen ist jetzt breiter. Die Auskunft suchte ihre Programmdateien dort, wo sie beim Entwickeln liegen, nicht dort, wo sie auf dem Server liegen; gefunden mit einem Anruf auf die frisch ausgelieferte Adresse, behoben am selben Morgen. Und unter der nächsten Fassung der Programmiersprache kostete allein die Prüfung des Zugangsschlüssels fast die ganze erlaubte Antwortzeit.

Stand dieser Woche: 3 764 automatische Prüfungen, alle grün. 591 Regeln, die jede Prüfung absichtlich kaputtmachen und erwarten, dass es auffällt.

KW 39 · 2026

Mit achttausend Betrieben gemessen: zwei Abfragen behoben, die Grenze zwischen den Betrieben ausdrücklich gezogen

25. September 2026 · Lesezeit 4 Minuten

Wenn eine Anwendung viele Betriebe trägt, wächst nicht der einzelne Betrieb, sondern die Zahl der Betriebe. Eine Abfrage, die in einem Betrieb schnell ist, kann langsamer werden, wenn auf derselben Datenbank tausend andere liegen. Das messen wir, bevor es jemand bemerkt.

Mit zweitausend gegen achttausend Betrieben fand der Messlauf zwei Abfragen in der Vertriebssteuerung, die mit der Zahl der Betriebe langsamer wurden. Die Ursache war eine Verbindung zwischen zwei Tabellen, die den Betrieb nicht nannte. Behoben — eine der beiden Abfragen fiel von 11,3 auf 4,5 Millisekunden.

Die Grenze zwischen den Betrieben steht, wo sie hingehört

Es war nicht nur eine Frage der Geschwindigkeit: An dieser Stelle verließ sich die Abfrage darauf, dass Nummern zufällig eindeutig sind, statt die Grenze zwischen den Betrieben ausdrücklich zu ziehen. Jetzt steht sie da, wo sie hingehört.

Warum das für Ihren Betrieb zählt

Ein Prüfgerät, das nie anschlägt, ist entweder auf eine heile Anlage gerichtet — oder kaputt. Von außen sieht man den Unterschied nicht. Man sieht ihn erst, wenn man den Fehler absichtlich einbaut und nachsieht, ob das Gerät ihn meldet.

Wie wir es abgesichert haben

Bevor wir einem Messergebnis trauen, bauen wir den Fehler absichtlich ein, den es finden soll. Der erste Messlauf meldete: alles in Ordnung — und meldete das auch dann noch, als wir der Datenbank ein Suchverzeichnis weggenommen hatten, das genau diese Abfragen schnell macht. Er war zu klein angesetzt: Bei wenigen Betrieben ist eine Abfrage auch ohne Suchverzeichnis schnell. Erst in der richtigen Größe fand er die beiden Stellen.

Stand dieser Woche: 3 390 automatische Prüfungen, alle grün. 468 Regeln, die jede Prüfung absichtlich kaputtmachen und erwarten, dass es auffällt.

KW 38 · 2026

Acht Prüfungen jeden Abend — und jede muss zeigen, dass sie misst, was sie behauptet

18. September 2026 · Lesezeit 6 Minuten

Acht Prüfungen laufen bei uns jeden Abend von allein: Sicherung holen, probeweise einspielen, gegen eine echte Datenbank prüfen, Protokollkette nachrechnen, Geschwindigkeit messen, Serverstand vergleichen und zwei weitere.

Für sie gilt jetzt eine Regel: Bevor ein Wächter in den Abendlauf kommt, muss er zeigen, dass er misst, was er behauptet. Und er muss vorführen, dass er rot wird, wenn man den Fehler absichtlich einbaut.

Warum das für Ihren Betrieb zählt

Ein Alarm, der zweimal in fünf Wochen ohne Ursache kommt, wird nach der dritten Woche weggeklickt. Danach ist er wertlos — und der Tag, an dem er recht hat, geht mit unter. Das gilt für Prüfprogramme genauso wie für die Meldung „Batterie schwach" an einer Alarmanlage, die seit Monaten blinkt.

Ein Befund zählt erst, wenn er sich wiederholt

Eine Prüfung misst, ob die Anwendung mit wachsendem Bestand langsamer wird. Sie entscheidet jetzt durch Wiederholung: Wer zufällig anschlägt, schlägt beim zweiten Mal nicht wieder an; wer wirklich langsamer wird, tut es jedes Mal. Gegengeprüft haben wir das mit einer absichtlich schlecht gebauten Abfrage (bestätigt: 26,4-fach, dann 26,3-fach) und mit einer, die nur im ersten Durchgang trödelt (22,2-fach, dann 0,8-fach — kein Befund).

Der Anlass: In fünf Abenden hatte die Prüfung zweimal angeschlagen, beide Male knapp über der Schwelle. Sechzehn Wiederholungen auf demselben Stand, davon drei unter künstlicher Rechenlast und drei unter Plattenlast, ergaben keinen einzigen Befund. Eine höhere Schwelle wäre nicht die Lösung gewesen — die verdeckt echte Fälle.

Die Fortschrittsseite richtet sich nach der Versionsverwaltung

Ein anderer Wächter passt auf, dass unsere Fortschrittsseite nicht hinter der Wirklichkeit zurückbleibt. Er fragt jetzt die Versionsverwaltung statt die Dateiuhr. Und er sagt in seiner Meldung dazu, woher seine Zahl stammt.

Vorher verglich er das Datum der Seite mit dem Änderungsdatum der Programmdateien — und meldete Alarm für eine Datei, die der Datei-Synchronisierungsdienst nur übertragen hatte. Nachgemessen: 23 von 225 Dateien trugen ein Datum, das mehr als eine Stunde hinter ihrer letzten inhaltlichen Änderung lag — die größte Abweichung 14,5 Tage.

Wie wir es abgesichert haben

Wir haben alle acht der Frage unterworfen, die man einem Wächter zu selten stellt: Misst er eigentlich das, was er behauptet? Bei vier von acht lautete die Antwort nein. Keiner davon war ein Programmierfehler. Alle vier maßen etwas, das mit ihrer Frage nur lose zusammenhing — und meldeten deshalb mal zu viel, mal zu wenig.

Stand dieser Woche: 2 705 automatische Prüfungen, alle grün. 257 Regeln, die jede Prüfung absichtlich kaputtmachen und erwarten, dass es auffällt.

KW 37 · 2026

Ein verkettetes Protokoll, das jeden Abend nachgerechnet wird

13. September 2026 · Lesezeit 5 Minuten

Unser Protokoll ist verkettet: Jeder Eintrag trägt die Prüfsumme des vorherigen. Wer einen Eintrag nachträglich ändert oder löscht, bricht die Kette, und das fällt auf. So steht es auf dieser Website — und seit dieser Woche rechnen wir jeden Abend nach, ob es auch stimmt.

Lesen und Anfügen eines Eintrags sind jetzt ein einziger, gesperrter Schritt — nachgestellt mit zwei Programmen, die absichtlich gleichzeitig schreiben, auf beiden Datenbanksystemen geprüft.

Was Sie daraus mitnehmen können

Wenn Ihnen jemand ein „revisionssicheres" Protokoll verkauft, sind zwei Fragen nützlich: Wer rechnet die Kette nach, und wie oft? Und: Was passiert, wenn zwei Vorgänge gleichzeitig schreiben? Ein Protokoll, das nur bei Verdacht geprüft wird, schützt die Zeit nach dem Verdacht — nicht die davor.

Wie wir es abgesichert haben

Am ersten Abend war die Kette nicht heil. Nicht, weil jemand etwas verändert hätte, sondern weil zwei Programmläufe in derselben Sekunde geschrieben hatten: Lesen und Anfügen waren zwei Schritte, dazwischen passt ein anderer Lauf. Das Ergebnis ist eine Gabelung — zwei Einträge, die auf denselben Vorgänger zeigen. Jeder Eintrag war unversehrt, nur ihre Reihenfolge ist nicht mehr entscheidbar.

Was wir offen benennen

Wir schreiben es nicht schön. Wer mit Datenbankzugriff einen Eintrag daneben schreibt und richtig verkettet, erzeugt dasselbe Bild. Die Aussagekraft der Kette ist an dieser Stelle geschwächt, und das gehört gesagt — besonders dann, wenn ein Protokoll später vor Gericht eine Rolle spielen soll.

Die entstandene Stelle selbst bleibt. Sie nachträglich zu „heilen" hieße, Prüfsummen neu zu schreiben — also genau das zu tun, wovor die Kette schützen soll. Wir haben sie stattdessen benannt: mit beiden Kennungen, allen Prüfsummen, Zeitpunkt und Ursache, in der Verfahrensdokumentation. Der Abendlauf meldet dort jetzt gelb statt rot — und jede Abweichung davon wieder rot.

Außerdem diese Woche: Der Server sagt jetzt selbst, welchen Stand er fährt. Er war 31 Übergaben zurück — das ist aufgeholt.

KW 36 · 2026

Jeder Weg durch die Anwendung wird wirklich gegangen — beim ersten Durchgang mit 81 Formularen

6. September 2026 · Lesezeit 4 Minuten

Jeder Weg durch die Anwendung wird seit dieser Woche mindestens einmal wirklich gegangen — nicht nur aufgerufen, sondern mit ausgefülltem Formular abgeschickt. Beim ersten Durchgang waren 81 Formulare dabei, die vorher nie jemand abgeschickt hatte.

Der Anlass: Dreimal in derselben Woche zeigte sich etwas, das längst gebaut war und trotzdem niemand benutzen konnte. Was daraus geworden ist, steht hier.

Prüfstand und Server arbeiten mit demselben Datenbankschema

Der Auslieferungslauf führt das Datenbankschema jetzt selbst nach, mit demselben Verfahren wie auf dem Server. Das ist kein Komfort, sondern die Bedingung dafür, dass „geprüft" und „läuft" dasselbe bedeuten.

Vorher hatte die Akquise-Tafel auf dem Server mit einem Fehler geantwortet, während bei uns alles grün war: Unsere Prüfungen bauen die Datenbank jedes Mal frisch auf — auf dem Server arbeitet die Anwendung gegen eine bestehende, der eine Spalte fehlte.

Eine Sperre, die ihren Grund nennt

Die Annahme von Geschäftsbedingungen war gesperrt. Das war richtig: Es gab weder AGB noch einen Auftragsverarbeitungsvertrag, und eine Annahme ohne Gegenstand wäre eine Unterschrift unter ein leeres Blatt. Was fehlte, war die Auskunft darüber. Wer klickte, sah nichts.

Jetzt gibt es die Stelle, den Vertragstext zum Lesen ohne Anmeldung — und einen Knopf, der sagt, woran es liegt, statt es wegzutäuschen. Eine Sperre, die ihren Grund nennt, ist etwas anderes als eine, die einfach nicht reagiert.

Wie wir es abgesichert haben

Aus einer gewonnenen Verkaufschance soll ein Kunde werden. Der Programmteil dafür stand seit Wochen, in jeder Prüfung grün. Er hing an der Frage, ob die Chance einem Objekt zugeordnet ist — und die Spalte, die das festhält, wurde von keiner einzigen Stelle beschrieben. Sie war immer leer, die Bedingung immer falsch.

Das ist die Sorte Fehler, die keine Prüfung findet, die nur Programmteile einzeln ansieht: Jedes Stück für sich war richtig. Erst der Weg von vorne bis hinten zeigt, ob er begehbar ist.

KW 35 · 2026

Jede Regel wird nachweislich geprüft — 155 von 155

24. August 2026 · Lesezeit 5 Minuten

Stand heute: 2 114 fachliche Prüfungen, 384 über die Weboberfläche, 155 von 155 Regeln nachweislich geprüft und zwanzig Wächter, die bei jedem Lauf mitlaufen.

Eine Zahl wie „2 100 Prüfungen" sagt nichts darüber, ob es die richtigen sind — das sagt nur der Versuch, sie zu widerlegen. Diesen Versuch machen wir jetzt für jede Regel.

Wie wir eine Prüfung prüfen

Das Verfahren heißt Mutationsprüfung: Man baut absichtlich einen Fehler ein und sieht nach, ob eine Prüfung rot wird. Wird sie es nicht, ist die Regel nicht geprüft — sie ist nur vorhanden.

Wir tun das inzwischen mit 155 Regeln. Für jede wird der Quelltext an genau einer Stelle verfälscht, der gesamte Prüfstand läuft durch, und danach wird die Verfälschung zurückgenommen. Ein Durchgang dauert rund anderthalb Stunden.

Drei neue Kontrollen

Alle drei folgen derselben Regel: Ein Werkzeug, das nichts angesehen hat, darf nicht „in Ordnung" melden.

• Ein Wächter sieht nach jedem Lauf nach, ob eine absichtliche Verfälschung im Quelltext stehen geblieben ist — und repariert nichts von selbst. Ein Werkzeug, das auf Verdacht zurückschreibt, hat einen der Fehler unten verursacht.
• Die Bestandsaufnahme bricht ab, wenn sie schrumpft, statt eine zu kleine Zahl auszuweisen.
• Die Auslieferung meldet Spalten, die auf dem Server stehen und nicht im Datenmodell. Ein Server, der mehr hat als seine Beschreibung, lässt sich nicht mehr beschreiben.

Wie wir es abgesichert haben

Der Anlass war unbequem: Fünf von acht neu geschriebenen Prüfungen prüften nichts. Sie waren grün, und sie wären grün geblieben, wenn wir die Regel dahinter abgeschaltet hätten.

Ein Beispiel aus der Buchungsstrecke: Eine Ablehnung braucht einen Grund. Die Mutationsprüfung schaltete die Regel ab — und die Prüfung blieb grün. Die Pflicht stand zweimal im Code. Schaltet man die eine Stelle ab, fängt die andere es auf — und niemand merkt, dass die Hälfte der Absicherung weg ist.

Insgesamt sechs Befunde in drei Tagen, alle aus derselben Familie: Etwas meldet Erfolg für Arbeit, die es nicht getan hat.

• Eine Prüfung war grün und prüfte nichts.
• Ein Hilfsskript meldete „erledigt" und hatte nichts geändert.
• Ein abgebrochener Prüflauf hinterließ Schaden und keine Spur.
• Ein Aufräumer meldete „wiederhergestellt" und löschte dabei.
• Eine Bestandsaufnahme verlor Einträge und meldete „alles bestätigt".
• Fehlermeldungen wurden geschrieben, berechnet — und verworfen.

Keiner davon war ein Fehler im Erzeugnis. Alle saßen in den Prüfmitteln.

Ein Fund im Preiskatalog, bevor der erste Preis darin steht

Beim Anlegen einer neuen Tabelle fiel eine Spalte auf, in der ein Preis stehen soll. Auf dem Server war sie so angelegt, dass sie Werte bis 127 aufnimmt — in Cent gerechnet also 1,27 €. Ein Preis von 79 € wäre nicht falsch gerundet, sondern abgewiesen worden. Betroffen waren vier Felder, drei davon im Preiskatalog.

Was noch offen ist

Der Preiskatalog ist leer — die Preisentscheidung steht noch aus. Deshalb war der Fund niemandem aufgefallen: Es gab noch keinen Preis, der hätte scheitern können. Und der Stand oben kann nächste Woche wieder anders aussehen — das ist der Sinn der Sache.

KW 34 · 2026

Bis zu zwölf Monate kostenfrei — für Betriebe, die uns widersprechen

22. August 2026 · Lesezeit 4 Minuten

Sicherheitsdienstleister und Detekteien können PEWELI APP im eigenen Betrieb erproben — bis zu zwölf Monate kostenfrei. Dafür sagen Sie uns, was daran nicht taugt.

Das ist kein Geschenk und keine Verkaufsaktion. Es ist ein Tausch: Sie bekommen die Anwendung, wir bekommen das, was uns am meisten fehlt — Widerspruch aus dem laufenden Betrieb. Eine Software für die Sicherheitsbranche, die nur ihre Erbauer kennen, ist eine Vermutung.

Wie die zwölf Monate zustande kommen

Wer nichts meldet, bekommt drei Monate. Wer mitarbeitet, bis zu zwölf. Die Staffel ist absichtlich schlicht, damit sie niemand nachrechnen muss:

• 3 Monate — für alle, die aufgenommen werden. Ohne Bedingung.
• +3 Monate — für regelmäßige Rückmeldung: einmal im Monat ein kurzer Bericht, was gut lief und was nicht.
• +3 Monate — für gemeldete Fehler oder Änderungswünsche, die wir umsetzen. Nicht für die Menge der Meldungen, sondern für das, was daraus wird.
• +3 Monate — für ein ausführliches Gespräch über den Einsatz im Alltag, aus dem wir zitieren dürfen.

Rückwärts geht es nicht. Wer aufhört, sich zu melden, verliert keine bereits erreichten Monate — es kommen nur keine weiteren dazu.

Was Sie bekommen — und was heute noch nicht

Das gehört an diese Stelle und nicht ins Kleingedruckte: Ein Teil der Anwendung läuft noch nicht, und zwar nicht, weil er fehlt, sondern weil er auf eine Rechtsauskunft wartet.

Verfügbar sind Einsatzplanung und Dienstplan, Zeiterfassung (auch ohne Netz), Arbeitszeit mit Urlaub und Abwesenheit, Prüfung und Abrechnung, Leistungsnachweise und Berichte, Verträge, Kunden und Objekte sowie die Sicherheitstechnik mit Wartung und Störungen.

Noch nicht verfügbar sind Fallakte, Anzeigenunterlage, Beweismittel und die Observation mit echten Zielpersonen. Diese Bereiche sind gebaut und geprüft — sie sind gesperrt, bis eine Rechtsberatung geklärt hat, was dabei zulässig ist. Wir schalten sie frei, wenn die Antworten vorliegen, und nicht vorher.

Wir sagen Ihnen das vor Ihrer Bewerbung, weil Sie es sonst nach der ersten Woche selbst merken würden.

Was wir von Ihnen brauchen

• Einen echten Betrieb — keine Testumgebung. Was im Alltag stört, zeigt sich nur im Alltag.
• Eine Person, die ansprechbar ist. Nicht täglich, aber verlässlich.
• Ehrlichkeit statt Höflichkeit. „Ganz nett" hilft uns nicht. „Das dauert drei Klicks zu lang, und deshalb macht es keiner" hilft.

Was wir nicht tun

• Keine stille Verlängerung. Nach den freien Monaten endet der Zugang. Wenn Sie weitermachen wollen, entscheiden Sie das ausdrücklich — nichts läuft von selbst in einen Vertrag.
• Keine Nutzung Ihrer Daten für uns. Ihre Einsätze, Kunden und Beschäftigten gehören Ihnen. Wir werten sie nicht aus, und kein Sprachmodell verarbeitet sie.
• Keine Werbung mit Ihrem Namen, solange Sie es nicht ausdrücklich erlauben.

So bewerben Sie sich

Eine E-Mail genügt. Schreiben Sie uns, was Sie tun — Warensicherung, Revierdienst, Ermittlung —, wie viele Personen im Einsatz sind und woran es heute am meisten hakt. Der letzte Punkt ist der wichtigste; daran erkennen wir, ob wir Ihnen überhaupt helfen können.

Wir melden uns zurück — auch dann, wenn wir absagen, und mit Begründung.

Als BETA-Tester bewerben Recht und Datenschutz

Die Aufnahme erfolgt in Stufen und in der Reihenfolge des Eingangs. Ein Anspruch auf Teilnahme besteht nicht. Zugang für fremde Betriebe setzt den Abschluss eines Vertrages zur Auftragsverarbeitung voraus — bis dahin sammeln wir Bewerbungen und melden uns, sobald es losgeht.

KW 34 · 2026

Die Trennung zwischen den Betrieben ist jetzt eine Prüfung, keine Zusage

17. August 2026 · Lesezeit 4 Minuten

Eine Kontrolle sieht jede einzelne Abfrage an, bevor sie an die Datenbank geht. Berührt sie eine der 33 unternehmensgebundenen Tabellen, ohne die Unternehmenskennung zu erwähnen, ist das ein Befund — in der Entwicklung ein sofortiger Abbruch, im laufenden Betrieb ein Eintrag im Fehlerprotokoll.

Das ist unsere Antwort auf die Frage, die jeder stellt, der eine Software mietet statt sie zu kaufen: Auf demselben Server arbeiten andere Betriebe. Was hindert die Anwendung daran, mir deren Daten zu zeigen — oder meine ihnen? Vorher war die Trennung eine Zusage. Jetzt ist sie eine Prüfung, die bei jedem Testlauf mitläuft.

Warum eine Prüfung mehr ist als eine Zusage

Jeder Datensatz in unserer Anwendung — jeder Vorfall, jede Person, jedes Lichtbild — trägt die Kennung des Unternehmens, dem er gehört. Bei jeder Abfrage muss danach gefiltert werden. Fehlt dieser Filter an einer einzigen Stelle, sieht ein Betrieb die Daten eines anderen — und solange nur ein Betrieb arbeitet, verhält sich die Anwendung mit und ohne Filter völlig gleich. Es gibt keine Fehlermeldung, jeder Test läuft grün. Genau diesen Fall meldet die Kontrolle, bevor der zweite Kunde dazukommt.

Die Liste der Tabellen pflegt sich aus dem Datenmodell

Die Liste dieser Tabellen wird aus dem Datenmodell abgeleitet, nicht von Hand gepflegt. Eine Liste, die man beim nächsten Modul nachtragen muss, ist eine Liste, die man irgendwann vergisst.

Wie wir es abgesichert haben

Beim Scharfschalten fielen zunächst 60 von 88 Prüfungen. Der weit überwiegende Teil waren berechtigte Ausnahmen im Anmeldeweg — dort wird ja überhaupt erst ermittelt, zu welchem Unternehmen jemand gehört. Diese Ausnahmen sind jetzt einzeln benannt, jede mit Begründung, und sie werden gezählt: vier je Durchlauf. Eine Zahl, die klein bleiben soll und die auffällt, wenn sie wächst.

Zwei Funde blieben übrig, und einer war echt — in Code, den wir am selben Tag geschrieben hatten. Eine Abfrage las die Teilnehmer eines Termins ohne den Filter. Falsch war sie nicht: Die Kennungen stammten aus einer Abfrage zehn Zeilen weiter oben, die korrekt gefiltert hatte. Aber damit lag die Sicherheit in einer anderen Abfrage — wer die obere später ändert, hebt hier eine Grenze auf, ohne es zu merken.

Was die Kontrolle nicht leistet

Das gehört dazu, sonst wäre der ganze Text eine Werbebotschaft. Die Kontrolle erkennt einen vergessenen Filter, nicht einen falschen. Und sie ersetzt keine Trennung auf Ebene der Datenbank selbst — wer die Datenbank in der Hand hält, kommt an alles. Ob wir zusätzlich dorthin gehen, ist eine offene Entscheidung.

KW 33 · 2026

Der Leistungsnachweis entsteht von selbst: Anmeldung am Objekt, Unterschrift auf dem Gerät

16. August 2026 · Lesezeit 3 Minuten

Diese Woche ist der Kern unserer Anwendung in Betrieb gegangen. Kein Prototyp mehr, kein Klickmodell — eine laufende Software, mit der man arbeiten kann.

Der Mitarbeiter meldet sich am Objekt auf dem Handy an und am Ende wieder ab. Dabei hält die Anwendung fest, wann das war und wo — und rechnet aus, wie weit die Position vom Objekt entfernt lag. Am Monatsende entsteht daraus der Leistungsnachweis von selbst. Der Marktverantwortliche unterschreibt direkt auf dem Gerät.

Warum das für Ihren Betrieb zählt

In der Warensicherung arbeitet man nicht im eigenen Haus. Man ist im Markt des Kunden, oft allein, oft an wechselnden Standorten. Am Monatsende steht eine Rechnung, und daneben gehört ein Nachweis: Wer war wann wie lange vor Ort? Bisher entsteht der in vielen Betrieben aus einem handschriftlichen Zettel, der abends abgetippt wird. Das ist mühsam und schwer zu belegen: Wenn drei Wochen später jemand nachfragt, steht Aussage gegen Aussage.

Die Entscheidungen im Einzelnen

Die zweite Entscheidung betrifft die Namen. Auf dem Leistungsnachweis, den der Kunde bekommt, steht die Personalnummer — nicht der Klarname. Der Auftraggeber muss wissen, dass jemand da war und wie lange. Wer genau, geht ihn nichts an. Das ist keine Förmlichkeit, sondern schlicht der richtige Umgang mit den Daten der eigenen Leute.

Die Unterschrift als Strichzug

Sie wird nicht als Foto gespeichert, sondern als Strichzug — also als der Weg, den der Finger genommen hat. Das hat zwei Vorteile: Sie bleibt im Ausdruck in jeder Größe sauber, und sie lässt sich nicht so einfach aus einem anderen Blatt herüberkopieren.

Was noch offen ist

Der eigentliche Kern unseres Fachs — die Fallakte zum einzelnen Vorfall mit Beteiligten, Diebesgut und Beweismitteln — ist noch nicht umgesetzt. Nicht aus Zeitmangel, sondern aus Reihenfolge: Dabei geht es um Daten über Tatvorwürfe, und dafür holen wir zuerst die rechtliche Prüfung ein.

Ein System für solche Daten wird nicht erst gebaut und danach geprüft. Das kostet uns Wochen — und erspart uns vermutlich Jahre.

Nächste Woche: warum ein Betrieb mit drei Niederlassungen andere Software braucht als einer mit einer — und was das mit Sichtbarkeit zu tun hat.