Alle casesProof of concept
Orderafhandeling voor een IT-hardwareleverancier: proof of concept.
De orderdesk van een IT-hardwareleverancier controleerde bij elke order met de hand voorraad, apparaatcompatibiliteit en beschikbaarheid bij leveranciers. Een proof of concept automatiseerde die controles, stelde conceptorders voor leveranciers op, werd gevalideerd op echte ordercases en legde vast waar een mens moet blijven beslissen.
- Klant
- Een IT-hardwareleverancier
- Sector
- IT-distributie, orderafhandeling
- Opdracht
- Proof of concept
IT-distributie, orderafhandeling
Groeidoel
De orderdesk meer orders laten verwerken zonder extra mensen die voorraad, compatibiliteit en leveranciers met de hand controleren.
Operationele beperking
Elke order betekende voorraad controleren, apparaatcompatibiliteit verifiëren en leveranciers nabellen voor ontbrekende onderdelen.
Gevalideerd resultaat
Gevalideerd op echte ordercases, met vastgelegd waar een mens blijft beslissen.
Samenvatting
- Uitgangssituatie
- Controles liepen over meerdere systemen en mailboxen, en niets legde vast wat al gecontroleerd was of welke leveranciersreacties nog openstonden.
- Wat SIEL bouwde
- Een taalmodel leest klantverzoeken en koppelt ze aan offerte- en productgegevens. Regels controleren voorraad en compatibiliteit in de bestaande systemen, en de workflow stelt conceptorders op voor ontbrekende onderdelen.
- Borging
- Alleen concepten. Een mens beoordeelt en verstuurt elke leveranciersorder, en elke stap legt vast of het systeem of een mens de beslissing nam.
- Impact
- De vastgelegde beoordelingspunten vormen de ontwerpbasis voor een productieversie.
Het volledige verslag
01Dezelfde controles bij elke order
De orderdesk zit tussen sales, klanten en leveranciers. Bij elke bevestigde offerte controleerde iemand de voorraad, verifieerde of apparaten en onderdelen compatibel waren en belde leveranciers na voor wat ontbrak, verspreid over meerdere systemen en mailboxen. Met het volume groeide het werk, en daarmee het risico om een levering toe te zeggen die de desk niet kon waarmaken.
02Wat het taalmodel doet en wat regels doen
De proof of concept verdeelt het werk in tweeën. Een taalmodel interpreteert elk klantverzoek, dat als vrije tekst en in wisselende formaten binnenkomt, en koppelt het aan de juiste offerte en productgegevens. Alles daarna zijn regels. Voorraad wordt uit de bestaande systemen gelezen, compatibiliteit wordt getoetst aan de compatibiliteitsregels van de leverancier, en ontbrekende onderdelen worden opgesomd. Daarna stelt de workflow een conceptorder op met de regels en context die inkoop nodig heeft.
03Alleen concepten, elke stap vastgelegd
De workflow kan de leverancier nergens aan binden. Hij maakt concepten, en een mens beoordeelt en verstuurt elke leveranciersorder. Elke stap legt vast of het systeem of een mens de beslissing nam en op basis van welke gegevens. Zo ziet de desk het pad van klantvraag tot conceptorder en kan elke stap daarin controleren.
04Validatie en vastgelegde beoordelingspunten
De proof of concept draaide op echte ordercases, niet op bedachte voorbeelden. Tijdens de validatie legden we elk punt vast waar nog menselijk oordeel nodig was, zoals onduidelijke compatibiliteitsregels en leveranciersgedrag buiten het gebruikelijke patroon. Die vastlegging is het belangrijkste resultaat. Ze bepaalt welke stappen een productieversie kan automatiseren en welke expliciete goedkeuringen blijven. De workflow draait nog niet in productie.
Bespreek uw operatie met onze engineers.
Beschrijf één proces en de systemen waarop het steunt. Een senior engineer reageert binnen twee werkdagen met een eerste beoordeling: wat we zouden bouwen, wat niet, en waarom.