Hvorfor innkjøpsforespørselen blir en flaskehals
I en produksjonsbedrift starter innkjøp sjelden med ett pent utfylt dokument. Behovet oppstår hos arbeidslederen, teknologen, ingeniøren, driftsavdelingen eller planleggeren. Noen sender en e-post, noen skriver i bedriftschatten, og noen gir informasjonen personlig til lederen. Resultatet er at samme oppgave kan dukke opp i flere kanaler, mens enkelte forespørsler ikke registreres i det hele tatt.
Ved første øyekast ser problemet ut som en vanlig forsinkelse i godkjenningen. I praksis påvirker det imidlertid hele leveransesyklusen. Så lenge forespørselen er til kontroll, kan innkjøperen ikke innhente priser på en korrekt måte, leverandøren mottar ingen bestilling, lageret vet ikke når materialet forventes, og produksjonen må endre planen. Jo mer kritisk posisjonen er, desto høyere blir kostnaden ved uklarhet.
Det er spesielt krevende å håndtere forespørsler når selskapet har flere anlegg, avdelinger og ansvarsnivåer. For én kategori er lederens godkjenning tilstrekkelig, mens en annen krever budsjettkontroll, teknisk vurdering, bekreftelse fra sikkerhetsavdelingen eller en avgjørelse fra flere godkjennere. Hvis reglene ikke er forankret i prosessen, handler hver deltaker etter sin egen logikk.
Hva som vanligvis forsinker behovsprosessen
- det finnes ikke ett felles skjema med obligatoriske opplysninger om posisjon, antall, frist og formål;
- det er uklart hvem som har ansvar for neste trinn og hvor forespørselen befinner seg;
- godkjennerne mottar varsler i forskjellige kanaler og ser ikke konteksten;
- endringer i forespørselen ledsages ikke av en tydelig historikk;
- akutte behov blandes med planlagte behov;
- lederne får vite om risikoen for en forsinket levering først etter at problemet har oppstått.
I et slikt miljø kompenserer medarbeiderne ofte for manglende transparens med manuell oppfølging: de ringer kolleger, videresender e-poster, fører lokale regneark og minner hverandre på oppgaver i chatter. Dette skaper en følelse av aktivitet, men etablerer ikke en reproduserbar prosess. Når en medarbeider slutter, en leder byttes ut eller innkjøpsvolumet øker, mister systemet raskt stabiliteten.
Hvilke konsekvenser oppstår for produksjonen
En langvarig godkjenningsprosess fører ikke alltid umiddelbart til at produksjonslinjen stanser. Langt oftere oppstår først mindre synlige symptomer: hastebestillinger i stedet for planlagte bestillinger, delleveranser, gjentatte forespørsler til leverandører, innkjøp på mindre gunstige vilkår og en opphopning av uferdige forespørsler. Disse tapene kan fordeles mellom flere avdelinger og derfor lenge forbli uten én tydelig eier.
Produksjonsplanleggingen bygger på tilgjengeligheten av materialer, reservedeler, verktøy og tjenester. Hvis informasjonen om innkjøpet ikke er oppdatert, må planleggeren basere seg på antakelser. Noen posisjoner bestilles for sent, andre med et overdrevent lager. I begge tilfeller mister selskapet kontrollen over arbeidskapitalen.
Det finnes også en organisatorisk effekt. Godkjennerne begynner å oppfatte forespørslene som en strøm av enkeltstående forespørsler, mens innkjøpsavdelingen blir et ekspedisjonssenter som manuelt leter etter manglende opplysninger. Samtidig erstatter diskusjonen om hvem som forsinket prosessen analysen av hvor prosessen faktisk er dårlig utformet.
Hvordan prosessen endres i OpenBox
Løsningen «Forespørselsstyring» i OpenBox hjelper med å flytte innkjøpsbehovet fra spredte kanaler til ett felles arbeidsområde. Forespørselen opprettes i et tydelig skjema, går gjennom definerte trinn, sendes til ansvarlige medarbeidere og beholder historikken over handlingene. Det viktige er ikke selve automatiseringen, men muligheten til å beskrive reglene for hvordan selskapet ønsker å arbeide på forhånd.
I stedet for spørsmålet «hvem har e-posten nå?» får man konkret informasjon: hvem som opprettet forespørselen, hvilken avdeling den tilhører, hva som kreves, innen hvilken frist, hvilket trinn som er fullført, hvem som skal utføre neste trinn og hvilke kommentarer som allerede er lagt inn. Dette reduserer antallet avklaringer og gjør det enklere å skille komplette forespørsler fra dem som mangler grunnleggende opplysninger.
Felles registrering av behovet
I første trinn fastsetter selskapet hvilke felt som skal inngå. Vanligvis registreres initiativtaker, avdeling, kostnadspost eller kostnadsområde, varelinje, antall, ønsket frist, leveringssted, begrunnelse og vedlegg i forespørselen. Innholdet avhenger av produksjonens egenart: For en teknisk posisjon kan det være nødvendig med spesifikasjoner, tegning eller krav til kompatibilitet, mens en tjeneste kan kreve en kravspesifikasjon og et forventet resultat.
Obligatoriske felt gjør det umulig å sende inn en forespørsel der innkjøperen må innhente grunnleggende opplysninger på nytt. Samtidig er det viktig å ikke overbelaste skjemaet. Hvis brukeren ser dusinvis av felt som ikke gjelder oppgaven, begynner vedkommende å lete etter omveier. Derfor er det bedre å dele opplysningene inn i generelle og betingede felt: Ekstra felt vises bare for bestemte kategorier eller innkjøpstyper.
Ruting etter tydelige regler
Etter registrering kan forespørselen rutes basert på avdeling, kategori, beløp, hast eller valgt kostnadspost. For eksempel går tekniske materialer gjennom kontroll hos en fagspesialist, mens forespørsler med økonomiske begrensninger får en ekstra budsjettgodkjenning. For standardiserte innkjøp kan ruten være kortere, mens ustandardiserte innkjøp kan omfatte en ekspertvurdering.
Ruten bør ikke fastsettes én gang og deretter bli stående uten gjennomgang. I produksjonen endres avdelingsstrukturen, nye kategorier oppstår og fullmakter omfordeles. Derfor er det viktig ved implementeringen å bli enige ikke bare om rekkefølgen på trinnene, men også om en prosesseier som har ansvar for at den er oppdatert.
Oppfølging av frister og statuser
Hver forespørsel får en tydelig status, for eksempel «opprettet», «til kontroll», «til godkjenning», «overført til innkjøp», «venter på avklaring», «gjennomført» eller «avslått». Navnene bør gjenspeile de faktiske handlingene, og ikke interne formuleringer som bare forstås av én avdeling.
Medarbeiderne ser gjeldende trinn uten å måtte sende forespørsler til innkjøpsavdelingen. De ansvarlige mottar varsler om nye oppgaver og endringer. Lederen kan rette oppmerksomheten mot forespørsler som har ligget lenge på samme trinn, mens innkjøperen kan konsentrere seg om forespørsler som er klare for videre behandling. Denne tilnærmingen fjerner ikke behovet for å ta beslutninger, men eliminerer unødvendig venting og manuell leting.
Implementeringsscenario for en produksjonsbedrift
Det er mer praktisk å begynne med å automatisere ett styrbart scenario enn å forsøke å automatisere alle typer innkjøp samtidig. Man kan for eksempel velge forespørsler om produksjonsmaterialer, reservedeler eller reparasjonstjenester. På dette området er det enklere å identifisere deltakerne, samle inn reelle eksempler og kontrollere hvilke opplysninger som faktisk trengs for å ta en beslutning.
- Gjennomgang av dagens prosess. Teamet dokumenterer hvordan behovet oppstår i dag, hvor det registreres, hvem som kontrollerer opplysningene, hvilke godkjenninger som er obligatoriske og på hvilke trinn det oftest oppstår returer.
- Definering av roller. Initiativtaker, avdelingsleder, teknisk ekspert, økonomisk godkjenner, innkjøpsspesialist og andre deltakere identifiseres. For hver rolle beskrives ikke stillingen generelt, men den konkrete handlingen i forespørselen.
- Utforming av skjemaet. Feltene grupperes etter innhold, og det legges til hjelpetekster og regler for obligatoriske felt. Det avklares separat hvilke dokumenter som skal legges ved med en gang, og hvilke som bare kreves for bestemte typer behov.
- Konfigurering av ruten. Betingelser for overgang mellom trinn, rekkefølge på godkjenninger, regler for retur til bearbeiding og handlinger ved avslag fastsettes. Dette gjør det mulig å fjerne uformelle «parallelle» godkjenninger.
- Pilot i en begrenset gruppe. Den nye prosessen testes på reelle forespørsler fra én avdeling eller kategori. Brukerne peker på uklare felt, unødvendige trinn og situasjoner som ikke var tatt høyde for i den opprinnelige modellen.
- Utvide og etablere rutiner. Etter justeringer utvides scenariet til andre avdelinger. Rutinen beskriver reglene for opprettelse av forespørsler, responstider, behandling av hasteforespørsler og ansvaret for at ruten er oppdatert.
Denne fremgangsmåten bidrar til å unngå at implementeringen blir et abstrakt IT-prosjekt. Det konkrete målet står i sentrum: å gjøre behovsprosessen synlig og forutsigbar for dem som deltar i innkjøpet hver dag.
Hvordan man vurderer resultatet uten formelle rapporter
Effekten av automatiseringen bør vurderes ut fra observerbare tegn, ikke bare antallet opprettede forespørsler. Før lansering er det nyttig å dokumentere utgangspunktet: hvor mange kanaler som brukes, hvilke opplysninger som oftest må avklares, hvor mange forespørsler som returneres for bearbeiding, hvor det mangler en ansvarlig og hvilke årsaker til forsinkelser som går igjen.
Etter overgangen til en enhetlig prosess kan man følge med på følgende indikatorer:
- andelen forespørsler som opprettes ved hjelp av det godkjente skjemaet;
- tiden som brukes på hvert trinn;
- antallet returer på grunn av ufullstendige eller motstridende opplysninger;
- antallet forespørsler uten tildelt ansvarlig;
- andelen hasteforespørsler og årsakene til at de oppstår;
- antallet forfalte oppgaver fordelt på avdelinger og roller;
- hyppigheten av endringer i ruten og gjentatte unntak.
Disse dataene er ikke et mål i seg selv. De hjelper med å forstå hvor problemet er knyttet til skjemaet, hvor det handler om fullmakter, og hvor det skyldes behovsplanlegging. Mange returer kan for eksempel tyde på ikke at initiativtakerne er uoppmerksomme, men at kravene til beskrivelsen av posisjonen er formulert for generelt. Regelmessige hasteforespørsler kan på sin side tyde på et avvik mellom produksjonsplanen og innkjøpskalenderen.
Hva som er viktig å ta hensyn til før lansering
Automatisering erstatter ikke avklaringer mellom avdelingene. Hvis selskapet ikke har bestemt hvem som har rett til å godkjenne et materialbytte, hvem som er ansvarlig for den tekniske vurderingen og hva som skal regnes som en begrunnet hastesak, vil programmet bare flytte uklarheten over i et digitalt grensesnitt. Derfor bør konfigureringen av OpenBox starte med arbeidsreglene, ikke med en liste over knapper.
Det er også viktig å diskutere unntak på forhånd. Produksjonen trenger egne scenarier for akutte reparasjoner, driftsstans, sikkerhetskrav og leveranser med en fast frist. Samtidig bør «haster» ikke bli en universell omvei rundt standardruten. Det er bedre å opprette en egen forespørselstype, kreve en begrunnelse og analysere årsakene i etterkant.
For brukerne er det avgjørende at det er enkelt å komme i gang. Initiativtakeren må forstå hvor vedkommende skal logge inn, hvilket skjema som skal velges og hva som skjer etter innsending. Godkjenneren trenger en oppgavekø med prioriteringer og kontekst. Innkjøperen trenger filtre og mulighet til raskt å se forespørsler som er klare for behandling. Lederen trenger oversikt over belastning og problematiske trinn. Når hver person bare får relevant informasjon, reduseres motstanden mot endringer.
Når det er grunn til å diskutere implementering
En beslutning om automatisering er spesielt aktuell hvis forespørsler regelmessig letes frem i korrespondanse, lederne ikke raskt kan få en oppdatert oversikt over utestående behov, innkjøperne bruker betydelig tid på å avklare grunnleggende opplysninger, og produksjonen får vite om risikoen for en forsinkelse for sent. Et annet signal er at prosessen er avhengig av én koordinator som manuelt husker hvem som må minnes på hva.
OpenBox kan bli grunnlaget for en trinnvis overgang til en styrbar prosess: først felles registrering, deretter ruter og fristkontroll, og etter dette analyse av årsaker til avvik og videreutvikling av scenarier. Det konkrete konfigurasjonsomfanget avhenger av selskapets struktur, innkjøpskategoriene og gjeldende godkjenningsregler.
Hvis dere ønsker å forstå nøyaktig hvor tiden forsvinner i prosessen, kan dere begynne med å beskrive dagens rute og noen reelle forespørsler. I en konsultasjon om OpenBox kan disse scenariene gjennomgås, de obligatoriske rollene defineres og et fornuftig omfang for første trinn velges. En rolig pilot vil gi større nytte enn et forsøk på å overføre alle unntak og interne avklaringer til systemet med én gang.