Tilpass gjennomgangen til investeringen
Teknisk due diligence (selskapsgjennomgang) etterprøver det du godtok om produktet i vurderingsfasen. Da konkluderte du med at produktet finnes og fungerer. Denne delen av arbeidet undersøker om det kan støtte veksten og utviklingen som runden skal finansiere. Hvor grundig du går til verks, bør stå i forhold til de økonomiske følgene et mulig funn kan få.
Vurder kostnaden ved gjennomgangen opp mot investeringen din. En gjennomgang med gründerne koster deg en ettermiddag og dem en dag med forberedelser.
En kort vurdering fra en kvalifisert ingeniør koster lite sammenlignet med en investering på størrelse med lead investors, men mye sammenlignet med et mindre beløp som fyller opp runden. En bestilt full revisjon koster så mye at den bare kan forsvares dersom du er lead investor, teknologien er avgjørende for investeringsbeslutningen, eller selve koden utgjør produktets verdi.
| Omfang | Hva gjennomgangen avdekker | Hva den ikke avdekker | Når den passer |
|---|---|---|---|
| Strukturert gjennomgang med gründerne | Om systemskissen stemmer med produktet, om teamet kan sette endringer i drift, om kontoer og kodelagre tilhører selskapet, og om gründerne kjenner egne avhengigheter. | Det gründerne ikke vet eller ikke vil fortelle: skjult teknisk gjeld, en kopiert komponent eller et sikkerhetshull. | Når du bidrar med et mindre beløp som fyller opp runden, eller investerer sammen med en lead investor hvis tekniske funn du har lest. |
| Kort vurdering fra en kvalifisert tredjepart | En systemoppbygning som ikke kan støtte den planlagte utviklingen, en prosess for produksjonssetting som avhenger av én person, en komponentoversikt som aldri er laget, og forskjellen mellom oppgitt og målt testdekning. | Feil inne i koden og uforenlige lisensvilkår som bare avdekkes ved å skanne komponentene. | Når du investerer et beløp på størrelse med lead investors i et programvareselskap, eller en medinvestor med teknisk bakgrunn tar denne delen av arbeidet for syndikatet. |
| Bestilt revisjon med tilgang til koden | Kodekvalitet, sikkerhetsfeil, en skannet oversikt over komponenter og lisenser og en utbedringsplan med kostnadsanslag. | Om produktet er det riktige produktet. Det hører til den kommersielle gjennomgangen. | Når du er lead investor og teknologien er grunnlaget for investeringen, eller når et selskap kombinerer maskinvare og programvare og planen avhenger av en ombygging. |
I et syndikat tar medlemmet med faktisk erfaring fra fagområdet denne delen av arbeidet. Angel Capital Associations veiledning stiller samme krav til en felles selskapsgjennomgang. Minst ett medlem bør kjenne området, og dette medlemmet leder arbeidet på feltet.
Hvis ingen i gruppen kan lese en systemskisse, deler syndikatet kostnaden ved å hente inn noen som kan. Sørg for at noen i gruppen kan tolke vurderingen og forklare hva funnene betyr for investeringen.
Gjør alle fem kontrollene uansett hvor omfattende gjennomgangen er. Tilpass mengden dokumentasjon til omfanget.
Arkitekturen sett opp mot planen
Be gründerne om en systemskisse på én side som viser hvordan systemet kjører i dag: komponentene, datalagrene, alle tredjepartstjenester og hvor kundedataene ligger. Et team som må tegne skissen i møtet, har aldri måttet forklare systemet for noen. Det sier noe om hvordan neste utvikler vil bli satt inn i arbeidet.
Spør hvordan systemet må endres for å støtte planen runden skal finansiere. Ti ganger så mange kunder, et nytt marked, en stor bedriftskunde med sitt eget skjema for sikkerhetskontroll: Hvilken boks på skissen svikter først, og har noen målt hvor grensen går?
Skill mellom det som har vært i produksjon, og det som bare har vært demonstrert. Et system som har betjent faktiske brukere, har en historikk over oppetid, en hendelsesliste og en regning fra driftsleverandøren.
En demonstrasjon har ingen av delene, uansett hvor godt den fungerer på gründerens bærbare PC. Be om alle tre, og vurder på nytt hvor modent produktet er hvis noe mangler.
Teknisk gjeld og hva den koster neste år
Måten teamet leverer endringer på, kan avdekke teknisk gjeld uten at du gjennomgår koden. Be gründerne svare konkret på hvert av punktene.
| Signal | Hva du bør spørre om | Hva svaret forteller |
|---|---|---|
| Hyppighet på produksjonssetting | Når ble den siste endringen satt i drift, og hvor ofte skjer det? | Et team som leverer hver uke, har en fungerende rutine for å sette endringer i drift. Et team som sist leverte for to måneder siden, bygger enten om eller er redd for sitt eget system. |
| Tid fra beslutning til endring | Hvor lang tid går det fra beslutningen om å rette noe til kundene får rettelsen? | Dager er et godt tegn på dette stadiet. Uker betyr at hvert steg er manuelt, eller at hver endring ødelegger noe annet. |
| Hendelsesfrekvens | Hvor mange hendelser var det siste kvartal, og hva forårsaket de tre siste? | Årsaker som gjentar seg, er konkret teknisk gjeld. Et team uten hendelsesliste har ingen måte å vite dette på. |
| Testdekning | Hvordan måles dekningen, og hva omfatter ikke tallet? | En oppgitt prosent uten et måleverktøy bak er et anslag. Spør hva som testes for hånd før hver produksjonssetting. |
| Listen over det som bør skrives om | Hva ville teamet skrevet om i morgen hvis det hadde en ledig måned? | Alle ærlige team har en liste. Omfanget målt i måneder viser hvor mye av neste års utviklingsplan som allerede er bundet opp. |
Anslå hvor mange måneder det tar å skrive om delene på listen, og sammenlign tidsbruken med utviklingsplanen. Hvis planen forutsetter tolv måneder med utvikling av nye funksjoner, mens teamets egen liste krever fire av dem, forskyves milepælen runden skal finansiere, med en tredel. Juster tidsplanen for dette arbeidet, og ta deretter hensyn til forsinkelsen i prisen.
Sikkerhet og personvern i praksis
Vurder sikkerheten ut fra hva selskapet har begynt med, for ingen selskaper i seedfasen er ferdige. Nasjonal sikkerhetsmyndighet publiserer grunnprinsipper for IKT-sikkerhet i fire kategorier: identifisere og kartlegge, beskytte og opprettholde, oppdage, og håndtere og gjenopprette. NSM opplyser at prinsippene gjelder alle virksomheter, og at mindre virksomheter må prioritere mellom dem.
Spør hvilke kategorier selskapet har begynt å arbeide med. Start med identifisering og kartlegging av systemene. Et selskap som ikke kan liste opp egne systemer, enheter og brukerkontoer, har ikke begynt i det hele tatt.
Prinsippene er gratis, kommer fra myndighetene og er skrevet for virksomheter av alle størrelser. Det finnes ingen revisjons- eller sertifiseringsordning for dem. ISO 27 001 er en sertifisering som koster penger, og som store bedriftskunder begynner å etterspørre senere. Kostnaden hører hjemme i planen til ethvert selskap som selger til slike kunder.
| Kontrollpunkt | Hva du bør be om | Faresignal |
|---|---|---|
| Tilgangsstyring | Listen over personer med administratortilgang til produksjonsmiljøet, og datoen tilgangen til den siste som sluttet, ble fjernet. | En felles administratorinnlogging eller en tidligere utvikler som fortsatt står på listen. |
| Håndtering av passord og nøkler | Hvor passord, nøkler og tilgangstokener lagres, og hvem som kan lese dem. | Innloggingsopplysninger i kodelageret eller i en chattråd. |
| Sikkerhetskopier | Datoen for den siste sikkerhetskopien som faktisk ble gjenopprettet, og hvor lang tid det tok. | Sikkerhetskopier som finnes, men aldri er gjenopprettet. |
| Sikkerhetsoppdatering av komponenter | Hvordan teamet får vite at en komponent det bruker, har en offentlig kjent sårbarhet, og hvor lang tid det tar å sette en rettelse i drift. | Ingen har ansvaret. |
| Hendelseshistorikk | Hendelser de siste tre årene, inkludert brudd som er meldt til Datatilsynet eller kundene. | En hendelse gründerne omtaler som «ikke noe alvorlig», uten dokumentasjon av hva som ble besluttet. |
Personvernpliktene gjelder allerede etter loven for ethvert selskap som behandler personopplysninger, uansett størrelse. Etter personopplysningsloven, som innlemmer GDPR i norsk rett, må selskapet føre protokoll over behandlingsaktiviteter. Datatilsynet opplyser at unntaket for små virksomheter svært sjelden vil frita dem helt fra denne plikten.
Selskapet må ha en databehandleravtale med hver databehandler. For et programvareselskap betyr det hver tjeneste for drift, analyse og kundestøtte som behandler kundedata. Ved overføring av personopplysninger ut av EØS må selskapet avklare overføringsgrunnlaget før overføringen. Overføring til et land som omfattes av en beslutning om tilstrekkelig beskyttelsesnivå, krever ikke et eget slikt grunnlag.
Et brudd på personopplysningssikkerheten skal som hovedregel meldes til Datatilsynet innen 72 timer. Meldingen sendes via et skjema i Altinn som krever delegert rettighet og elektronisk ID. Hvis ikke alle fakta er kjent, kan meldingen gis trinnvis.
Spør hvem i selskapet som kunne sendt meldingen i dag. Kontroller Altinn-tilgangen nå. Oppdager selskapet at tilgangen mangler under en hendelse, kan det forsinke meldingen.
Be om de fire dokumentene og gi dem til den som har ansvar for den juridiske gjennomgangen. Den tekniske gjennomgangen avklarer om de stemmer med det produktet faktisk gjør. Om de er tilstrekkelige, må en juridisk rådgiver vurdere.
Avhengighet av tredjeparter og skytjenester
List opp tjenestene produktet ikke klarer seg uten. For de fleste programvareselskaper betyr det drift, betaling, innlogging, e-postutsending og eventuelle eksterne modell- eller dataleverandører. Spør for hver av dem hva som svikter hvis leverandøren endrer vilkår, pris eller retningslinjer, og hva selskapet ville gjort de nitti dagene etter endringen.
Les forretningsvilkårene til de to eller tre viktigste. En leverandør som tar betalt etter bruk uten avtalt fast pris, gir kostnader som øker når selskapet lykkes. Drift i én region innebærer avhengighet av ett datasenter, noe kundeavtalen kanskje ikke tillater.
Se særlig på plattformer der endrede retningslinjer kan true selskapets virksomhet, for eksempel en appbutikk, en markedsplass eller et API der produktet inngår som en funksjon. En gründer som har identifisert risikoen og beregnet kostnaden ved den, har en plan. En gründer som hører om den fra deg for første gang, har det ikke.
Vurder infrastrukturkostnaden per betalende kunde, og spør hvordan den endres hvis bruken blir tidoblet.
Når bare én person kan vedlikeholde systemet
Tell hvor mange som på egen hånd kunne satt en rettelse i produksjon i morgen. Én er et vanlig svar i seedfasen. Det er bare akseptabelt hvis gründerne kjenner situasjonen, har skrevet ned hvordan systemet settes i drift og kan si hva som skjer med utviklingsplanen hvis personen slutter.
Spør hvem som har innloggingsopplysningene og kontoene til kodelageret, skytjenesten, domeneregistratoren, appbutikken og signeringsnøklene. Hver av dem bør eies av selskapet, og mer enn én person bør ha tilgang. Selskapet bør kunne vise en oversikt over hvem som har tilgang til hva. Mangler oversikten, må den lages i møtet.
Forvent at kodelageret og alle kontoer overføres til selskapets navn før investeringen gjennomføres, dersom de ikke allerede står der. Et kodelager på en gründers personlige konto er et funn for den som undersøker eierskapet, og et forhold som må rettes som vilkår for runden.
Kildekodedepot hører hjemme i kundeavtaler, der en kunde beskytter seg mot at leverandøren svikter. Det hører ikke hjemme i en englerunde på dette stadiet.
En gjennomgang i riktig størrelse
Send forespørsler om dokumenter og tilgang før møtet, slik at dere kan bruke tiden på å undersøke dokumentasjonen. Registrer det som ikke leveres, som funn.
| Forespørsel | Hva det må vise |
|---|---|
| Utviklingshistorikk: Hvem skrev hvilke deler av systemet, når og under hvilken avtale? | Selskapets eierskap eller lisens til hvert bidrag følger av arbeidsforholdet, loven eller en avtale. Selve eierskapet vurderes i gjennomgangen av immaterielle rettigheter. |
| Lesetilgang til kodelageret eller en gjennomgang på skjerm | Endringshistorikk som stemmer med utviklingshistorikken, og et kodelager som eies av selskapet. |
| Oversikt over tredjepartskomponenter og komponenter med åpen kildekode, med lisenser | Oversikten finnes, er datert og er generert fra programvarebygget, ikke laget etter hukommelsen. |
| Lisenser selskapet har fått og gitt | Hva selskapet har lisensiert inn, og hvilke rettigheter det har lisensiert ut, inkludert eventuell eksklusivitet. |
| Tredjeparter som bruker programvaren, og eventuell kildekode deponert for en kunde | Hvem andre som har koden, og på hvilke vilkår. |
| Domener, oppføringer i appbutikker og merkevarekontoer, med dokumentasjon av eierskap | Registrert på selskapet, med mer enn én administrator. |
| Personverndokumenter: behandlingsprotokoll, databehandleravtaler og overføringsgrunnlag | De finnes og stemmer med systemskissen. |
| Tilgangsliste for drift og administratorer | Hvem som har tilgang til produksjonsmiljøet, og at selskapet kan trekke tilgangen tilbake. |
| Historikk over personvernbrudd og andre hendelser, tre år | Hendelser er registrert sammen med beslutningene som ble tatt, og eventuelle meldinger som ble sendt. |
| Bekreftelser på rettighetsoverføring fra ansatte og oppdragstakere | Skriftlig dokumentasjon av den aktuelle overføringen eller lisensen, med bekreftelser der det trengs. |
Sett av to timer, og ha med personen som setter systemet i drift. Be gjennomgående om dokumentasjon fremfor forsikringer. «Vis meg» gir et faktum. «Fortell meg» gir en beskrivelse.
- En praktisk demonstrasjon med en testkonto og syntetiske eller forsvarlig anonymiserte data. Bruk bare reelle personopplysninger når det finnes et lovlig behandlingsgrunnlag, bruken er avgrenset til det nødvendige, tillatelsene er på plass og tilgangen er kontrollert.
- Gjennomgang av skissen: først systemet slik det er tegnet, deretter hvordan planen vil påvirke det.
- Gjennomgang av produksjonssettingen: den siste endringen som nådde produksjon, fra beslutning til kunde, vist i verktøyene.
- Gjennomgang av den siste hendelsen: hva som forårsaket den, hva som ble endret etterpå, og hvor dette er skrevet ned.
- Listen over avhengigheter og kontoer: hver leverandør, hva som svikter uten den, og hvem som har innloggingsopplysningene.
Skriv et notat på én side. For hver av de fem kontrollene registrerer du hva som ble vist, hva som ble hevdet uten dokumentasjon, og hva som mangler. Plasser så hvert funn i én av fire kategorier: akseptert, tatt hensyn til i prisen, vilkår for gjennomføring eller grunn til å avslutte investeringsprosessen.
Hvor mye du gjør selv, avhenger av rollen din i runden.
- En medinvestor leser lead investors tekniske funn og kontrollerer de to forholdene som avgjør hvor mye vedkommende risikerer å tape: eierskapet til kontoer og kodelager, og om mer enn én person kan sette systemet i drift.
- En lead investor gjennomfører hele møtet, samler funnene og avgjør om svarene tilsier at en betalt fagperson bør kobles inn. Når investeringen i et programvareselskap er på størrelse med lead investors, er ekspertvurdering utgangspunktet. En gründer som motsetter seg lesetilgang til kodelageret, har gitt deg et funn.
- En engleinvestor med bransjekunnskap tar denne delen av arbeidet for syndikatet, bruker møtet på arkitektur og avhengigheter der faglig skjønn har størst verdi, og stiller spørsmål en generalist ikke kan etterprøve.
Tekniske funn og hva de endrer
De fleste funnene er en del av kostnaden ved å investere i et selskap i tidlig fase: begrensede tester, manuell produksjonssetting, dokumentasjon som bare finnes i hodet til én person, og en komponentliste som først ble laget fordi du ba om den. Registrer og aksepter dette, og legg utbedringene til de første hundre dagene.
Noen funn krever endret pris eller tidsplan. En ombygging planen ikke finansierer, en avhengighet som må erstattes før annet arbeid kan fortsette, og infrastrukturkostnader som vokser raskere enn inntektene, endrer alle hva pengene rekker til. Da må milepælen eller prisen endres.
Andre funn kan bli vilkår for gjennomføring: selskapets kontroll over kontoer og kodelagre, dokumentasjon av immaterielle rettigheter, nødvendige databehandleravtaler og en komponentoversikt. Avklar tiltak, ansvarlig og tidsplan for hvert funn. En manglende signatur eller et samtykke fra en tredjepart kan ta lengre tid enn runden tillater.
Et produkt som ikke kan utføre den påståtte kjernefunksjonen, eller som ikke kan settes i drift uten en person som er på vei ut, kan gjøre at prosessen avsluttes. Også andre funn må kunne rettes på en gjennomførbar måte. Avgjør hva du kan akseptere, prise inn eller sette som vilkår, og hva som gir for stor usikkerhet til å investere.