Projekte

DataTool 2: ein Werkzeug für 238.000 Artikel.

Festanstellung29. Juli 2026

Bereich

B2B-Handel

Umsetzung

laufend seit 2023

Kompetenz

Prozessautomatisierung · Data Engineering

Stack

Python · Streamlit · MySQL · SAP Business ByDesign · pandas · Excel · Git

In drei Sätzen: Ein Fachhändler führt 238.000 Artikel in SAP, das Preise, Einheiten und Status widerspruchslos annimmt, ohne sie zu prüfen — Auswertungen über den ganzen Katalog gibt es dort nicht. Dagegen ist ein Werkzeug mit rund vierzig Arbeitsseiten entstanden: ein nächtlicher Datenspiegel trägt alle Auswertungen in Sekunden, jede Änderung geht kontrolliert über die SAP-API und wird danach zurückgeprüft. Das Muster darunter — Zahlen, die das ERP nicht hergibt, Massenänderungen von Hand, unbemerkte Datenfehler — sieht in einem Zehn-Personen-Betrieb genauso aus, nur kleiner.

Hinweis zu diesem Text: Dieses Werkzeug ist im Rahmen meiner Festanstellung entstanden, nicht als Freelance-Auftrag — ich baue und betreibe es dort seit 2023. Auftraggeber, Produktname und Herstellernamen sind anonymisiert; die Kennzahlen, Abläufe und technischen Entscheidungen sind unverändert. Sämtliche Screenshots stammen aus einer vollständig synthetischen Demo-Umgebung — Artikel, Lieferanten, Kunden, Preise und Namen sind erfunden; aus der Produktivdatenbank wurde ausschließlich die Tabellenstruktur geklont, keine einzige Datenzeile.

Die Ausgangslage

Ein mittelständischer technischer Fachhandel führt rund 238.000 Artikel in SAP Business ByDesign — Verbrauchsmaterial, Glas- und Kunststoffwaren, Chemikalien, Geräte, von etwa 135 Herstellern über rund 900 Lieferantenbeziehungen. Jeder dieser Artikel hat einen Verkaufspreis, einen Einkaufspreis, einen Bewertungspreis, eine Mengeneinheit mit Umrechnung, einen Lagerstatus, eine Rabattgruppe, eine Produktkategorie, oft eine GTIN, manchmal Gefahrgutkennzeichen.

Das Problem war nie fehlende Software. SAP war da. Das Problem war, dass SAP Business ByDesign in dieser Konstellation faktisch ein passiver Speicher ist: Es nimmt an, was man einträgt, und prüft nicht, ob es zusammenpasst. Kein Systemzwang verhindert, dass ein Artikel als „aktiv im Verkauf“ geführt wird, obwohl er archiviert ist. Kein Feld protestiert, wenn der Bewertungspreis über dem Verkaufspreis liegt und jede Bestellung damit Verlust macht.

Die Arbeit dazwischen lief so, wie sie in vielen Betrieben läuft. Der Vertrieb fragte im Chat: „Kannst du den EK von Artikel X prüfen?“ Die Preisliste eines Lieferanten kam als Excel-Datei mit eigenem Spaltenchaos und musste manuell gegen SAP abgeglichen werden. Ein neuer Artikel wurde in eine geteilte Excel-Tabelle eingetragen, von dort abgetippt und irgendwann angelegt — mit allen Fehlern, die beim Abtippen entstehen. Und die Frage „welche Artikel haben gar keinen gültigen Preis?“ konnte niemand beantworten, weil sie eine Auswertung über den gesamten Katalog erfordert hätte.

Daraus wurde ein Werkzeug. Nicht auf einmal, sondern Seite für Seite, immer dann, wenn eine Frage zum dritten Mal per Hand beantwortet werden musste.

Was daraus wurde

Ein Werkzeug mit acht Themengruppen: Material (Rundumblick, Massenreport, Massenupload, Lieferantenwechsel, Datenqualität), Neuanlage (Formular, Tabelle, Journal, Excel-Import), Price History (Herstellerübersicht, EK-/VK-/BewP-Historien, Umsatz), Sperren/Entsperren (inklusive GTIN-Vergabe und Verkaufsnotizen), SupplierCat (Importe und Preisübernahmen aus dem externen Lieferantenkatalog), KondProfil (Konditionsprofile), Kunden (Beziehungen, Zuständigkeiten, X-Rechnung) und Other (Betrieb).

Wichtig ist dabei nicht die Zahl der Seiten, sondern was sie gemeinsam haben: Sie arbeiten alle auf demselben Datenmodell, mit denselben Regeln, über dieselben Schreibwege in SAP. Es gibt nicht vierzig Skripte, die sich ähneln — es gibt eine gemeinsame Bibliothek und vierzig Oberflächen darauf.

Die Architektur: zwei Geschwindigkeiten

Die zentrale Entscheidung war, nicht live gegen SAP zu arbeiten.

SAP Business ByDesign ist über zwei Schnittstellen erreichbar: OData für Massenabfragen und SOAP für alles Schreibende. Beide sind langsam, wenn man sie für Auswertungen benutzt, und beide gehen in die Knie, wenn man sie parallel befeuert. Eine Frage wie „wie viele aktive Artikel haben keinen gültigen Verkaufspreis?“ ist über die API kaum beantwortbar.

Deshalb liegt unter allem ein nächtlich synchronisierter MySQL-Spiegel der relevanten SAP-Tabellen. Auswertungen, Historien und Zählungen laufen gegen diesen Spiegel — in Sekunden, ohne API-Last. Der Spiegel ist strikt read-only: Ein UPDATE darauf fließt nicht nach SAP zurück und wäre beim nächsten Sync verschwunden. Jede echte Änderung geht über einen SOAP-Aufruf, wird per Rückabfrage verifiziert und ist im Spiegel erst am Folgetag sichtbar.

Das erzeugt ein Problem, das man dem Benutzer nicht verschweigen darf: Manche Zahlen auf dem Bildschirm sind von heute Nacht, manche von jetzt. Die Lösung ist ein Herkunftspunkt an jeder Zeile — blau für den nächtlichen Spiegel, grün für live aus SAP geholt.

Dieselbe Seite lädt in zwei Phasen. Phase eins zieht Stammdaten, Preise, Bestand und Auftragshistorie aus dem Spiegel und zeigt sie sofort. Phase zwei holt parallel nach, was aktuell sein muss: Materialeigenschaften und Verkaufs-Lebenszyklus über SOAP, Lieferantenteilenummern, Preise und freigegebene Zugänge über OData. Der Benutzer sieht nach einem Augenblick etwas Brauchbares und wenige Sekunden später das vollständige Bild.

Eine Regel gilt im ganzen Werkzeug: kein stiller Fallback. Fehlt eine Datenquelle, bricht die Verarbeitung mit einer sichtbaren Meldung ab, statt still auf einen älteren Stand auszuweichen. Das klingt unfreundlich und ist die wichtigste Eigenschaft des Systems: Ein Preisimport, der halb funktioniert und nichts sagt, kostet mehr als einer, der laut abbricht.

Der Artikel-Rundumblick

Die am häufigsten benutzte Seite beantwortet eine Frage, für die man in SAP sechs Masken hintereinander öffnen muss: Was ist mit diesem Artikel?

Man gibt eine Artikelnummer, eine Lieferantenteilenummer oder ein Suchmuster mit Platzhalter ein. Findet der Spiegel nichts, wird genau ein Live-Versuch gegen SAP gemacht — weil ein Artikel, der heute angelegt wurde, im nächtlichen Spiegel noch nicht existiert. Er ist dann grün markiert, mit dem Hinweis, dass die Historie erst nach dem nächsten Sync verfügbar ist.

Der Bericht selbst ist in Karten organisiert, und die interessanteste ist die erste: die Validierung. Sie prüft den Artikel gegen einen Katalog atomarer Regeln und zeigt nur, was auffällt — Basis-Mengeneinheit ist nicht die kleinste vorhandene, Einkaufspreis weicht vom Lieferantenkatalog ab, Verkaufspreis abgelaufen, Bewertungspreis fehlt trotz Bestand. Jeder Befund nennt die Ursache und den nächsten Schritt.

Direkt darunter steht die Rechnung, um die es im Handel eigentlich geht: der Deckungsbeitrag, dreifach berechnet — gegen den Einkaufspreis, gegen den Bewertungspreis und gegen den tatsächlich in den letzten Aufträgen erzielten Preis. Diese drei Zahlen weichen im Alltag voneinander ab, und die Abweichung selbst ist die Information.

Wenn es weh tut: die Problemdiagnose

Der eigentliche Wert zeigt sich an den Artikeln, bei denen etwas schiefläuft.

Die Auftragsansicht zeigt die letzten Positionen mit dem Preis, der damals tatsächlich galt, dem damaligen Bewertungspreis und dem von SAP gerechneten Deckungsbeitrag — je Zeile mit Ampel. Rot heißt: unter null. Daneben der Jahrestrend, der aus einem Einzelfall ein Muster macht. Hier ist auf einen Blick erkennbar, dass nicht ein Kunde zu billig eingekauft hat, sondern dass die Kalkulation des Artikels seit Jahresbeginn nicht mehr stimmt.

Ein zweiter Fehlertyp ist subtiler und deshalb gefährlicher: ein Artikel mit 100 % Deckungsbeitrag. Das ist kein Traumgeschäft, sondern ein Bewertungspreis von null — meist ein vergessener Platzhalter. In SAP fällt das nie auf, weil dort niemand fragt. Hier steht es als Signal in der Karte.

Die Preisseite

Preise sind der Teil, bei dem Fehler direkt Geld kosten, und deshalb der Teil mit den meisten Sicherungen. Die Preisseite zeigt links den aktuellen SAP-Stand schreibgeschützt und rechts die Eingabespalten — „war → wird“ in einer Tabelle statt in zwei Fenstern.

Der Grund für diese Umständlichkeit ist eine ganze Klasse von Fehlern, die im Fachhandel teuer ist: Mengeneinheiten. Derselbe Artikel kostet 12,75 € pro Beutel mit 1.000 Stück oder 0,01275 € pro Stück. Wer die falsche Einheit erwischt, liegt um Faktor 1.000 daneben — und SAP nimmt das widerspruchslos an. Deshalb darf man hier in jeder Einheit tippen, und das Werkzeug rechnet um und zeigt vorher, was das in Prozent bedeutet.

Die Historie darunter macht sichtbar, was SAP nur mühsam hergibt: Verkaufs-, Einkaufs- und Bewertungspreise als Zeitreihe, inklusive Staffelpreisen.

Preispflege im Bestand: vom Lieferanten-Excel bis in SAP

Die aufwendigste Daueraufgabe im Handel ist die Pflege fremder Preise. Ein Lieferant schickt eine neue Preisliste — als Excel-Datei, mit eigenen Spaltennamen, eigener Dezimaltrennung, eigenem Verständnis davon, ob ein Preis pro Stück oder pro Packung gilt. Für 135 Hersteller ist das kein Sonderfall, sondern der Normalbetrieb.

Die Antwort darauf ist eine Rezeptschicht: pro Lieferant eine kleine Python-Datei, die genau eine Aufgabe hat — aus der Rohdatei einen normierten Datenrahmen mit festen Spalten machen. Was in dieser Datei stehen darf, ist vertraglich festgelegt: keine Dateizugriffe, kein globaler Zustand, alles idempotent, Rohwerte immer als Text gelesen (sonst wird aus der Artikelnummer 001234 die Zahl 1234). Mengeneinheiten laufen über eine gemeinsame Abbildung, Fremdwährungen über einen zentralen Umrechner mit Tageskurs — und ein ungültiger Kurs bricht ab, statt zu raten.

Danach greift überall dieselbe Kette: normieren → gegen SAP vergleichen → Paket bilden → validieren → senden → verifizieren. Ein „Paket“ ist dabei nicht eine Datei, sondern ein Datensatz in der Datenbank, mit einer Zeile je Artikel und Preisart und einem eigenen Status pro Zeile.

Dieser Zeilenstatus ist der Grund, warum das Verfahren im Alltag trägt. Ein realer Lauf über 1.783 Preiszeilen endete mit 1.781 Erfolgen und zwei Zeitüberschreitungen. Weil jede Zeile ihren eigenen Zustand hat, waren anschließend genau diese zwei nachzusenden — nicht der ganze Lauf. Zeilen im Zustand „erfolgreich“ gehen nie ein zweites Mal raus.

Auf der Schreibseite steckt der Aufwand in Details, die man erst nach dem ersten Schaden kennt. Verkaufspreislisten werden in Blöcken von 100 Positionen gesendet, weil ein zu großes XML-Paket abgewiesen wird; eine Liste mit 18.000 Positionen sind also rund 180 Aufrufe. Das Zeitlimit liegt bei mindestens 180 Sekunden, weil ein großer Hersteller allein 17.968 Artikel hat — und weil eine Zeitüberschreitung kein Misserfolg ist: Die Liste kann in SAP trotzdem entstanden sein. Ein Startdatum in der Vergangenheit führt zu HTTP 200, leerem Protokoll und keiner angelegten Liste. Solche stillen Ablehnungen sind der Grund, warum nach jedem Schreibvorgang eine Rückabfrage läuft, die Preis, Menge und Einheit vergleicht.

Für die Übernahme von Preisen aus dem externen Lieferantenkatalog gibt es denselben Weg als Ein-Klick-Variante — mit harten Sperren: Fehlt die Einkaufszeile, werden Einkaufs- und Bewertungspreis mit Warnung übersprungen, statt still auf eine andere Quelle auszuweichen. Gibt es keine gültige herstellerspezifische Verkaufspreisliste, bricht der Verkaufspreis ab. Und bei vorhandenem Bestand ist der Bewertungspreis gesperrt, weil eine Änderung dort die Bestandsbewertung verschiebt.

Neuanlage: aus der Excel-Liste wird ein Vorgang mit Zustand

Neue Artikel entstanden früher in einer geteilten Excel-Datei. Das hatte drei Folgen: Niemand wusste, welcher Antrag schon in SAP war; Tippfehler wanderten ungeprüft ins System; und parallele Zugriffe verschoben Zeilen, sodass Markierungen auf dem falschen Artikel landeten.

Jetzt ist ein Antrag ein Datensatz mit Lebenszyklus: eingereicht → Paket erstellt → gesendet → fertig, mit fehlgeschlagen und abgebrochen als Abzweigungen. Der Status wechselt nur nach echten Ereignissen — bricht die Validierung ab, bleibt er unverändert, weil in SAP nichts passiert ist und der Antrag ohne Zurücksetzen erneut sendbar bleibt.

Das Formular nimmt dem Bearbeiter die Ableitungen ab: Marke wählen, und Hersteller, Nummernkreis und die nächste freie Artikelnummer stehen fest. Die Lieferantenteilenummer wird gegen den Spiegel geprüft — Artikelnummer schon vorhanden oder Nummer-Lieferant-Paar bereits belegt blockiert, dieselbe Nummer bei einem anderen Lieferanten warnt nur. Die englische Bezeichnung entsteht auf Knopfdruck per Übersetzung, gekürzt auf die 120 Zeichen, die SAP zulässt. Auf Lager- und Durchlaufartikel wird beim Paketbau automatisch eine GTIN aus den eigenen GS1-Nummernblöcken gezogen und gleich mit dem Material angelegt — die Nummer wird zuerst im Pool beansprucht und dann verwendet, damit ein Abbruch keine Lücke hinterlässt.

Alle Anträge stehen im Journal mit ihrem Zustand, dem Paket und dem Fehlertext, falls das Senden schiefging.

Für Sammelanlagen aus dem Vertrieb gibt es denselben Weg als Excel-Strecke: Vorlage herunterladen, ausgefüllt hochladen, Prüfung und automatisches Befüllen laufen sofort, danach Vorbereiten und Senden. Aus dieser Strecke stammt eine Lehre, die ins Design eingegangen ist: Eine Zeile ohne Artikelnummer lief einmal durch alle Prüfungen, weil eine leere Nummer die Bedingung „existiert noch nicht in SAP“ formal erfüllt. Der Fix liegt heute auf drei Ebenen — sichtbar als eigene Prüfspalte, hart als Abbruch vor jedem Schreibvorgang und als blockierende Regel in der Ausgangsvalidierung. Eine Prüfung, die nur an einer Stelle sitzt, ist keine Prüfung.

Datenqualität als Dauerlauf statt Feuerwehr

Wenn das System selbst nicht auf Konsistenz achtet, muss jemand anders es tun — täglich, über den gesamten Katalog, und nur mit Meldung, wenn etwas auffällt.

Die Regeln sind bewusst atomar und deklarativ: eine Bedingung, eine Meldung, ein Vorschlag, eine Schwere. Ausnahmen werden mit Begründung, Person und Datum quittiert und tauchen danach nicht mehr auf. Und weil eine Liste mit tausenden Zeilen niemand liest, gibt es täglich einen Vergleich: neu, weiterhin offen, erledigt.

Der erste Vollauf über 237.775 Artikel brachte 8.373 Befunde. Ein paar Beispiele aus dieser Liste, weil sie zeigen, worum es geht: 4.331 archivierte Artikel standen im Verkauf noch auf aktiv. 1.517 Auslaufartikel waren gleichzeitig in Einkauf und Verkauf gesperrt. 688 Artikel hatten überhaupt keinen Verkaufsstatus.

Eine Regel wurde nach der Messung wieder abgeschaltet: „aktiv, aber ohne Verkaufspreis“ traf 22.829 Artikel — rund 37 % des aktiven Sortiments. Eine Regel, die ein Drittel des Katalogs anmeckert, ist kein Befund, sondern Lärm; sie gehört in eine Auswertung, nicht in eine Tagesliste. Genauso wurde eine plausibel klingende Preis-Packungsgrößen-Regel verworfen, nachdem sie basisweit einen Treffer hatte. Regeln werden hier gemessen, bevor sie scharfgestellt werden.

Massenauswertung: 89 Spalten und ein Herstellerprofil

Zwei Berichte tragen die Auswertungsseite.

Der Standard-Materialbericht ist die Grundlage für fast alles andere: eine Zeile je Artikel, 89 Spalten, aus Stammdaten, Preisen, Einkauf, Bestand, GTIN und externem Katalog zusammengeführt und mit aufgelösten Codelisten. Für den ganzen Katalog läuft er in etwa sieben Minuten; für eine Artikelliste in Sekunden. Er lässt sich gegen den Spiegel, gegen eine optimierte Spiegelvariante oder gegen Live-SAP fahren — dieselben Spalten, unterschiedliche Aktualität und Kosten.

Ausgeliefert wird als Excel, formatiert nach einem festen Hausstil: gedrehte Kopfzeile, Blockfarben je Themenbereich, eingefrorene erste Zeile und Spalte, Autofilter. Das ist keine Kosmetik — bei 89 Spalten entscheidet die Farbgruppierung darüber, ob die Datei benutzbar ist.

Der zweite Bericht dreht die Perspektive: eine Zeile je Hersteller, mit Kennzahlen zu Sortiment, Preisdeckung, Lücken und Katalogabdeckung. Für 135 Hersteller über 238.000 Artikel läuft er in gut zweieinhalb Minuten.

An diesem Bericht hängen drei Entscheidungen, die ich für übertragbar halte.

Erstens: die Bezugsmenge. „40 % der Artikel haben keinen Verkaufspreis“ klingt alarmierend und ist wertlos, solange 160.000 der 238.000 Artikel archiviert sind. Verkaufsfähig sind nur rund 75.000 — und erst gegen diese Menge gerechnet wird der Wert zur Aussage. Ein Hersteller mit 9.269 Artikeln, von denen drei verkaufsfähig sind, ist ein totes Sortiment und kein Problem. Ein anderer mit 2.888 Artikeln, davon 2.879 verkaufsfähig und 2.876 ohne Preis, ist ein echtes.

Zweitens: zwei Achsen statt einer Ampel. „Preis fehlt“ und „Preis läuft bald ab“ sind verschiedene Probleme mit verschiedenen Maßnahmen. Deshalb gibt es je Preisart eine Deckungs- und eine Ablaufbewertung — und zusätzlich die Information, ob für den Ablauf schon eine Folgezeile vorbereitet ist. Bei einer Messung Ende Juli lagen 3.438 Verkaufspreise mit Startdatum 1. August bereit; von fünf Herstellern mit Ablauf zum 31. Juli hatten drei vorgesorgt und zwei nicht. Das sind zwei konkrete Anrufe, nicht ein rotes Feld.

Drittens: Negativwissen ist Wissen. Um den aktuellen Stand der Preislisten zu bestimmen, muss man live gegen SAP fragen; der Spiegel ist dafür zu alt. Ein Vollauf brauchte 437 Sekunden — und von 353 Abfragen brachten nur 19 ein Ergebnis. 334 Aufrufe fragten jedes Mal erneut nach etwas, das es nicht gibt. Seit die Fehlschläge mit einer Verfallszeit von 30 Tagen gemerkt werden, dauert derselbe Lauf 5 Sekunden, bei identischem Ergebnis. Fehlgeschlagene Aufrufe werden dabei bewusst nicht gemerkt — ein Netzwerkfehler ist keine Aussage über die Daten.

Betrieb: was nach dem Feature-Bauen übrig bleibt

Ein Werkzeug, das im Tagesgeschäft benutzt wird, hat Anforderungen, die auf keiner Feature-Liste stehen.

Lange Läufe dürfen nicht am Browser hängen. Ein Bericht, der zweieinhalb Minuten rechnet, lief früher im Web-Prozess — und war weg, sobald jemand den Tab wechselte. Heute startet die Seite einen abgekoppelten Hintergrundprozess, der seinen Zustand in die Datenbank schreibt und alle zehn Sekunden ein Lebenszeichen setzt. Die Oberfläche pollt nur noch. Reißt die Verbindung, läuft der Bericht weiter.

Zeitstempel kommen vom Server, nicht vom Arbeitsplatz. Die Serveruhr lief bei einer Messung neun Minuten hinter der lokalen — genug, damit eine Lebenszeichen-Prüfung einen gesunden Lauf für abgestürzt hält.

Und es gibt eine Betriebsseite, die den Spiegel selbst überwacht: je Tabelle Zeilenzahl, Veränderung, Größe, letzter Schreibzugriff, Alter und eine dreistufige Frischeampel. Bewusst dreistufig, weil „rot“ nur für die Tabellen gerechtfertigt ist, die wirklich nächtlich synchronisiert werden — für Codelisten oder Archive wäre eine Altersampel eine Falschaussage.

Betrieben wird das Ganze auf einem internen Server hinter einem Reverse Proxy mit automatisch erneuertem Zertifikat, erreichbar für die Fachabteilungen im Firmennetz. Kein externer Dienst, keine Cloud-Abhängigkeit, keine Lizenz, die sich nächstes Jahr verdoppelt.

Was ich daraus mitnehme

Ein Werkzeug entsteht aus wiederholten Fragen, nicht aus einem Konzept. Fast jede Seite existiert, weil dieselbe Frage zum dritten Mal per Hand beantwortet werden musste. Wer versucht, ein solches System vorab vollständig zu entwerfen, baut Seiten, die niemand aufruft.

Laut scheitern ist eine Funktion. Der teuerste Fehler ist nicht der, der abbricht, sondern der, der halb durchläuft und nichts sagt. Jede Sperre in diesem System hat einen konkreten Vorfall als Ursache.

Regeln muss man messen, bevor man sie einschaltet. Eine Regel, die ein Drittel des Katalogs anmeckert, ist Lärm. Eine, die basisweit einen Treffer hat, ist Aufwand ohne Nutzen. Beide klangen vorher plausibel.

Aktualität ist eine Entscheidung pro Feld, nicht pro System. „Alles live“ ist unbenutzbar langsam, „alles vom Spiegel“ ist stellenweise falsch. Die brauchbare Antwort ist eine Mischung — und die Pflicht, dem Benutzer zu zeigen, welche Zahl aus welcher Quelle kommt.

Was davon für kleine Betriebe übrig bleibt

238.000 Artikel und SAP klingen nach einer anderen Welt als ein Betrieb mit zehn Leuten. Das Muster darunter ist aber dasselbe, und es hängt nicht an der Betriebsgröße, sondern daran, dass Daten an mehreren Stellen liegen und niemand Zeit hat, sie zusammenzutragen.

Drei Probleme kommen in jedem Betrieb vor, der ein ERP oder Rechnungstool, ein paar Lieferanten mit Excel-Preislisten und eine Handvoll Leute für Stammdaten hat:

• Auswertungen, die das System nicht hergibt. „Welche Artikel haben keinen gültigen Preis?“, „welche Kunden haben seit einem Jahr nichts gekauft?” — die Daten sind da, die Frage ist nur nicht abfragbar.
• Massenänderungen, die von Hand nicht zu schaffen sind. Eine neue Preisliste mit 300 Positionen ist kein Tagesgeschäft mehr, sondern ein Projekt — und wird deshalb verschoben.
• Datenfehler, die niemand bemerkt, weil niemand danach sucht. Der Artikel, bei dem der Einkaufspreis über dem Verkaufspreis liegt, fällt erst auf, wenn jemand zufällig hinsieht.

Der Unterschied zum Fall hier ist der Aufwand, nicht der Ansatz. Für zehn Leute braucht es keine vierzig Arbeitsseiten — meist reichen zwei oder drei: eine Übersicht, die morgens fertig ist, ein geprüfter Weg für Massenänderungen und eine tägliche Kontrolle, die nur meldet, wenn etwas auffällt. Das ist genau der Umfang, den ich als Automatisierungspaket für kleine Betriebe anbiete.

Wenn Ihnen beim Lesen ein Ablauf aus dem eigenen Betrieb eingefallen ist: Offen für eine Festanstellung in Data Analytics und Automatisierung? Kontakt aufnehmen.

← Alle Projekte