Bygge en digital anskaffelsesplattform
Start med én målbar arbeidsflyt og bygg den regulatoriske og tekniske grunnmuren før bred funksjonsutvidelse.
Å bygge en digital anskaffelsesplattform er ikke først og fremst et skjermdesignprosjekt. Produktet må håndtere bindende frister, sensitive tilbud, komplekse kunngjøringsdata og beslutninger som skal kunne etterprøves.
Velg første bruker og jobb
«Hele anskaffelsesprosessen» er for bredt som første leveranse. Velg én bruker og ett utfall, for eksempel:
- innkjøper som skal lage en konsistent behovsbeskrivelse
- leverandør som skal finne og kvalifisere relevante kunngjøringer
- konkurranseansvarlig som skal produsere og validere eForms
- kontraktsansvarlig som skal unngå tapte opsjonsfrister
Mål tidsbruk, avvik og fullføringsgrad før og etter. En AI-assistent uten målbar prosessforbedring er en funksjon, ikke et produktbevis.
En trinnvis produktplan
1. Kunnskaps- og markedsflate
Bygg søk på åpne TED-data, kildevisning, lagrede søk og en strukturert arbeidsflate. Dette kan testes uten publiseringsrettigheter. Vær tydelig på datadekningen for norske kunngjøringer.
2. Behov og konkurransegrunnlag
Modeller behov, krav, kriterier, dokumenter, roller og godkjenninger. Bruk testbare krav og versjoner. Arkitekturen bør kunne generere strukturert eForms senere.
3. KGV-kjerne
Implementer eForms, integrert ESPD, leverandørdialog, sikkert tilbudsmottak, åpning og evaluering. Avklar Doffin-onboarding tidlig; ikke vent til produktet ellers er ferdig.
4. KAV og økonomi
Overfør vinnerens forpliktelser, priser, opsjoner og milepæler. Koble til økonomi for forbruk og faktura, men la bokføringen være autoritativ i økonomisystemet.
Grunnmur som må bygges tidlig
- kundeisolasjon og tilgangsstyring
- dokumentversjoner og revisjonsspor
- full eksport og arkivintegrasjon
- hendelser, kø, retry og avstemming
- separate hemmeligheter og autentisering per API
- dataproveniens og lenke til autoritativ kilde
- testmiljø og versjonsstrategi for eForms
Hva bør ikke bygges først?
Unngå en stor generell dokumenteditor, egen videoløsning eller hundre rapporter før kjerneflyten virker. Integrer heller med standardverktøy der differensieringen er liten. Eie de delene der domenekunnskap, sporbarhet og dataflyt gir varig produktverdi.
Kommersiell validering
Intervju både oppdragsgivere og leverandører. Observer faktiske arbeidsøkter, ikke bare ønskelister. Be brukeren vise siste avvik, manuelle kontroll og data som måtte kopieres. Pilotér med begrenset prosedyre og lavere risiko før løsningen håndterer kritiske konkurranser.
Avhengigheter og myndighetskontakt
Lag et avklaringsregister for Doffin-tilgang, eForms-versjoner, ESPD, arkiv, autentisering og offentlige datasett. Hvert punkt bør ha kildeeier, skriftlig svar, dato og teknisk test. Ikke baser veikartet på antakelser om at et offentlig API «sikkert finnes».
Se integrasjonsarkitekturen og krav til KGV/KAV . Byna kan også hjelpe leverandører med anbudsvurdering , som gir innsikt i reelle friksjonspunkter på leverandørsiden.
Offisielle kilder
Start med DFØs veiledning om KGV og KAV , TED Developer Docs og Doffins API-portal .