Architektur der Beschaffungsautomatisierung

Was bedeutet die Automatisierung im Einkauf eigentlich?

"Beschaffungsautomatisierung" umfasst eine Reihe von Ansätzen: von regelbasierten Workflow-Automatisierungen, die eine Bestellanforderung durch eine feste Genehmigungskette leiten, über Robotic Process Automation (RPA), die bestehende Bildschirmmasken wie ein Mensch bedient, bis hin zu intelligentem Automatisieren, das Dokumentenverständnis oder Abgleichslogik hinzufügt. Peer-Review-Forschung beschreibt RPA als die Nutzung von Low-Code-Softwareprogrammen zur Automatisierung repetitiver, routinemäßiger Geschäftsprozesse und bezeichnet dies als die am schnellsten wachsende Technologie in der Kategorie der Unternehmenssoftware. Keiner dieser Ansätze ersetzt den Procure-to-Pay-Prozess; sie sind darin eingebettet, wobei jeder einzelne einen spezifischen, klar definierten Schritt übernimmt. Aus diesem Grund lautet die sinnvolle Frage, welche Schritte in diesem Procure-to-Pay-Architektur routiniert genug sind, um sie an Software zu übergeben, und welche noch das Urteilsvermögen einer Person erfordern.

Welche Workflow-Schritte werden zuerst automatisiert, und warum?

Vier Schritte tauchen wiederholt als frühe Automatisierungskandidaten auf, da jeder von ihnen ein hohes Volumen aufweist, regelbasiert ist und ein klares Ergebnis (Bestanden/Nicht bestanden) liefert: Bestellanforderungsweiterleitung und -genehmigung, der Drei-Wege-Abgleich zwischen Bestellung, Wareneingang und Rechnung, die Ausstellung der Bestellung nach Freigabe der Bestellanforderung sowie die Bearbeitung von Rechnungsausnahmen für die durch den Drei-Wege-Abgleich markierten Abweichungen. Aktuelle Beschaffungs-Benchmarks zeigen, dass Automatisierung verbessert die Fähigkeit, Mengenrabatte zu nutzen, den Einkauf zu konsolidieren und Kosten sowie Fehler durch manuelle Prozesse zu reduzieren, was dafür spricht, diese Schritte als Ausgangspunkt und nicht als den gesamten Anspruch zu betrachten. Dieselbe Benchmarking-Arbeit bringt eine Bedingung mit sich, die man ernst nehmen sollte: Prozessstandardisierung trägt dazu bei sicherzustellen, dass das Streben nach Geschwindigkeit nicht zu mehr Fehlern führt., weshalb die Automatisierung eines Bestellungs-Workflow was noch nicht standardisiert ist, beschleunigt lediglich die Inkonsistenz, da die Standardisierung vor oder parallel zur Entwicklung erfolgen muss.

Welche Kontrollen muss der automatisierte Pfad beibehalten?

Zwei Kontrollprinzipien werden unverändert aus der manuellen Beschaffung übernommen, und ein automatisierter Workflow muss sie in Software abbilden, anstatt anzunehmen, dass sie die Migration einfach überstehen. Das erste ist die Funktionstrennung: Die maßgeblichen behördlichen Richtlinien zur Kontrolle definieren sie als Aufteilung der wichtigsten Aufgaben und Verantwortlichkeiten auf verschiedene Personen, um das Risiko von Fehlern, Missbrauch oder Betrug zu verringern; Trennung der Zuständigkeiten für die Genehmigung von Transaktionen, deren Bearbeitung und Erfassung, die Überprüfung der Transaktionen sowie die Handhabung zugehöriger Vermögenswerte, sodass keine einzelne Person alle wesentlichen Aspekte einer Transaktion oder eines Ereignisses kontrolliert. Das zweite ist die Autorisierung: Transaktionen werden nur von Personen autorisiert und ausgeführt, die innerhalb ihres Befugnisbereichs handeln. Bei einem manuellen Prozess zeigt sich dies darin, dass verschiedene Personen an verschiedenen Schreibtischen eine Bestellung bearbeiten. Bei einem automatisierten Prozess muss sich dies in einem Rollenmodell, einer Konfiguration von Genehmigungsschwellen und einer Berechtigungslandkarte widerspiegeln, die ein Bot oder eine Workflow-Engine nicht einfach deshalb im Stillen umgehen kann, weil er bzw. sie technisch in jedes Feld schreiben kann, das er bzw. sie erreichen kann.

Wie strukturiert man eine Governance-fokussierte Einführung?

Wo scheitern Legacy-ERP-Integrationen tatsächlich, und woher stammen die Datensilos?

Der Punkt, an dem eine Beschaffungsautomatisierungsplattform eine Verbindung zum ERP herstellt, ist in der Praxis der Ort, an dem sich Governance-Risiken konzentrieren. Gleichzeitig entsteht dort ein Datensilo, wenn die Automatisierung eine eigene, separate Kopie von Lieferanten-, Budget- oder Freigabedaten vorhält, anstatt das ERP als einziges System of Record zu behandeln. Der Integrationsleitfaden eines Automatisierungsanbieters benennt das Zugriffsrisiko unmissverständlich: ein Connector, dem weitergehende Zugriffsrechte als für seine Funktion erforderlich gewährt wurden, kann Daten lesen, die er niemals sehen sollte, und in Felder schreiben, die er niemals berühren sollte. Umfassender Zugriff wird in der Regel aus Gründen der Bequemlichkeit bei der Einrichtung gewährt und nicht etwa, weil der Workflow ihn benötigt. Es lohnt sich, dies als vom Anbieter stammenden Prüfpunkt zu behandeln, der getestet werden sollte, anstatt sich auf die Zusicherung eines bestimmten Anbieterprodukts zu verlassen. Derselbe Leitfaden nennt einen zweiten, leiseren Fehlermodus: Ein Prüfpfad, der menschliche Handlungen erfasst, aber automatisierte Entscheidungen unaufgezeichnet lässt, ist unvollständig und führt bei jeder ernsthaften Prüfung zu Beanstandungen.. Wenn ein Bot eine Rechnung genehmigt, benötigt diese Entscheidung denselben Datensatz wie die Genehmigung durch eine Person: welche Logik angewendet wurde, welche Daten verwendet wurden und wie das Ergebnis aussah.

Warum kostet eine unüberprüfte Automatisierung mehr, als sie einspart?

Die Versuchung besteht darin, Automatisierung als ein reines Implementierungsproblem zu betrachten: das Tool konfigurieren, auf den Prozess anwenden, freigeben. Die grundlegende Forschung zur Workflow-Verifizierung warnt davor, den Zwischenschritt zu überspringen. Bei der Untersuchung von Workflow-Managementsystemen im Allgemeinen stellten die Forscher fest, dass Die Konsequenzen sind jedoch, dass nur wenige Workflows vor ihrer praktischen Einführung gründlich überprüft werden, was häufig dazu führt, dass Fehler ad hoc und oft zu unvertretbaren Kosten korrigiert werden müssen.. Diese Erkenntnis geht den heutigen Low-Code-Automatisierungsplattformen um zwei Jahrzehnte voraus, und das zugrundeliegende Problem ist nicht verschwunden: Eine Workflow-Spezifikation ist ein Stück Logik, und Logik, die nicht auf die tatsächlich zu bewältigenden Entscheidungen, Abläufe und Ausnahmen überprüft wurde, versagt auf dieselbe Weise, unabhängig davon, ob eine Person oder ein Bot sie ausführt – nur dass der Bot schneller und in größerem Volumen versagt. Workflow-Spezifikationssprachen müssen die Spezifikation von Entscheidungspunkten, sequenzieller Ausführung, Parallelität, Synchronisation und Iteration unterstützen genau deshalb, weil reale Prozesse all dies erfordern, und ein Pilotprojekt, das nur den Idealfall abdeckt, den Workflow überhaupt nicht verifiziert hat.