Tilpasning av EIC Accelerator Technology Readiness Levels (TRL) til SaaS, maskinvare og industrielle innovasjoner

I denne omfattende utforskningen av EIC Accelerator-programmet, et sentralt initiativ fra EU-kommisjonen (EC) og European Innovation Council (EIC), fordyper vi oss i de bemerkelsesverdige mulighetene det gir for startups og små- og mellomstore bedrifter (SMB) over hele Europa Union (EU). Dette programmet er et fyrtårn av håp for innovative virksomheter, og tilbyr blended financing-alternativer, inkludert opptil €2,5 millioner i tilskuddsfinansiering og opp til €15 millioner i egenkapitalfinansiering, som kulminerer i en potensiell totalfinansiering på €17,5 millioner. EIC Accelerator skiller seg ikke bare ut for sin økonomiske støtte, men også for sin forpliktelse til å heve teknologiberedskapsnivået (TRL) for banebrytende prosjekter.

Det overvåkes av European Innovation Council og SMEs Executive Agency (EISMEA), og sikrer en strømlinjeformet og effektiv søknadsprosess. Potensielle søkere kan dra nytte av veiledningen fra profesjonelle forfattere, frilansere og konsulenter, ved å bruke den offisielle forslagsmalen for å lage overbevisende forslag. I tillegg gir EIC Accelerator Video- og Pitch-dekkkomponentene innovative plattformer for søkere til å vise frem prosjektene sine. En vellykket søknad kulminerer i et intervju, et kritisk skritt mot å sikre et EIC-stipend eller EIC-equity, som markerer en betydelig milepæl på reisen til enhver ambisiøs bedrift som ønsker å markere seg i EU og utenfor.

Teknologiberedskapsnivåer (TRL)

I denne artikkelen legger vi ut på en reise for å skreddersy de tradisjonelle Technology Readiness Levels (TRL) for ulike typer forretningsmodeller, alt fra Software as a Service (SaaS)-selskaper til de som er involvert i utvikling av nye industrielle prosesser og maskinvareprodukter. I erkjennelse av at det originale TRL-rammeverket, primært designet for maskinvareteknologier, ikke passer sømløst til de varierte landskapene i dagens forretningsforetak, tilpasset vi disse stadiene for bedre å tilpasses de spesifikke behovene og egenskapene til hver forretningsmodell. Enten det er et SaaS-selskap som opererer i et B2C-miljø, en bedrift som utvikler en innovativ industriell prosess, eller et firma som lager et nytt maskinvareprodukt, krever hvert scenario en unik tilnærming til TRL-stadiene. Denne tilpasningen demonstrerer ikke bare allsidigheten til TRL-rammeverket, men understreker også viktigheten av å tilpasse utviklingsstandarder for å passe den spesifikke naturen til en bedrifts produkter, tjenester og markedsmiljøer.

TRL-ene i 2024 er:

  1. grunnleggende prinsipper observert
  2. teknologikonsept formulert
  3. eksperimentelt proof of concept
  4. teknologi validert i laboratoriet
  5. teknologi validert i relevant miljø
  6. teknologi demonstrert i relevant miljø
  7. demonstrasjon av systemprototype i driftsmiljø
  8. systemet komplett og kvalifisert
  9. faktisk system utprøvd i driftsmiljø

Tilpasning av teknologiberedskapsnivåer (TRL) for et SaaS-selskap med en B2B-modell

Naviger i de tilpassede teknologiberedskapsnivåene for SaaS B2B-selskaper

Technology Readiness Levels (TRL) er en metode for å estimere modenhet av teknologier under anskaffelsesfasen av et program. Opprinnelig utviklet for maskinvareteknologi, krever disse stadiene tilpasning for Software as a Service (SaaS)-selskaper, spesielt de som opererer i en B2B-modell. De tradisjonelle TRL-stadiene, som begynner i laboratoriemiljøer og går videre til fullskaladrift, trenger modifikasjon for å passe den unike utviklingsveien til SaaS-produkter. Denne artikkelen skisserer de tilpassede TRL-stadiene for et SaaS B2B-selskap og forklarer begrunnelsen bak disse endringene.

1. Konsept og applikasjonsdefinert (tilpasset TRL 1)

  • Original TRL 1: Grunnleggende prinsipper overholdt.
  • Tilpasset for SaaS: Det første konseptet for SaaS-produktet er formulert. Dette inkluderer å identifisere potensielle applikasjoner og den primære bedriftens kundebase.
  • Årsak til endring: SaaS-utvikling starter med en konseptuell fase med fokus på markedsbehov og potensielle anvendelser, snarere enn grunnleggende vitenskapelig forskning.

2. Teknologikonsept formulert (tilpasset TRL 2)

  • Original TRL 2: Teknologikonsept formulert.
  • Tilpasset for SaaS: En mer detaljert oversikt over SaaS-løsningen er utviklet, inkludert foreløpig programvarearkitektur og potensielle brukergrensesnitt.
  • Årsak til endring: Fokus er på å planlegge programvarearkitekturen og brukeropplevelsen tidlig i prosessen.

3. Proof of Concept utviklet (tilpasset TRL 3)

  • Original TRL 3: Eksperimentelt bevis på konsept.
  • Tilpasset for SaaS: Innledende programvareprototyper utvikles. Disse kan være begrenset i funksjonalitet, men demonstrerer kjernekonseptet.
  • Årsak til endring: For SaaS innebærer proof of concept ofte å skape et minimalt levedyktig produkt i stedet for laboratorieeksperimenter.

4. Betaversjon utviklet (tilpasset TRL 4)

  • Original TRL 4: Teknologi validert i lab.
  • Tilpasset for SaaS: Utvikling av en betaversjon av programvaren, som er testet i et simulert eller begrenset driftsmiljø med betabrukere.
  • Årsak til endring: I motsetning til maskinvare går SaaS tidligere inn i driftsmiljøet med betaversjoner testet av ekte brukere.

5. Betatesting med innledende brukere (tilpasset TRL 5)

  • Original TRL 5: Teknologi validert i relevant miljø.
  • Tilpasset for SaaS: Betatesting utvides med en bredere gruppe brukere. Tilbakemeldinger samles inn for å avgrense og optimalisere programvaren.
  • Årsak til endring: Direkte tilbakemeldinger fra brukere er avgjørende for SaaS-utvikling, og programvaren blir ofte testet i sammenheng med det tiltenkte markedet tidlig.

6. Systemmodell demonstrert i driftsmiljø (tilpasset TRL 6)

  • Original TRL 6: Teknologi demonstrert i relevant miljø.
  • Tilpasset for SaaS: En fullt funksjonell versjon av programvaren testes i det faktiske driftsmiljøet med utvalgte bedriftskunder.
  • Årsak til endring: SaaS-produkter når vanligvis operativ testing raskere, med vekt på virkelige applikasjoner i målmarkedet.

7. Systemprototype operativ (tilpasset TRL 7)

  • Original TRL 7: System prototype demonstrasjon i et operativt miljø.
  • Tilpasset for SaaS: Programvaren er raffinert basert på omfattende testing og tilbakemeldinger. Den opererer under virkelige forhold og demonstrerer verdien for forretningsbrukere.
  • Årsak til endring: Vekt på å foredle brukeropplevelse og funksjonalitet basert på dybdegående tilbakemeldinger.

8. System fullført og kvalifisert (tilpasset TRL 8)

  • Original TRL 8: System komplett og kvalifisert.
  • Tilpasset for SaaS: Fullskala distribusjon av SaaS-produktet. Programvaren er nå pålitelig, fullt funksjonell og integrert i forretningsprosessene til sluttbrukerne.
  • Årsak til endring: Fullskala distribusjon er et kritisk stadium, og demonstrerer programvarens evne til å integreres sømløst i bedriftens arbeidsflyter.

9. Faktisk system utprøvd i driftsmiljø (tilpasset TRL 9)

  • Original TRL 9: Faktisk system utprøvd i driftsmiljø.
  • Tilpasset for SaaS: Løpende drift og vedlikehold. Programvaren oppdateres jevnlig basert på tilbakemeldinger fra brukere og endrede forretningsbehov.
  • Årsak til endring: Kontinuerlig forbedring er et kjennetegn på SaaS-produkter, som krever kontinuerlig tilpasning og forbedring basert på bruker

 

Tilpasning av teknologiberedskapsnivåer for SaaS B2C-selskaper: Fokus på brukersentrisk utvikling

Tilpasse TRL-stadier for B2C SaaS: Omfavner betatesting og Freemium-modeller

Konseptet med teknologiberedskapsnivåer (TRL) er sentralt i vurderingen av teknologiens modenhet i utviklingsfasen. Men når det gjelder Software as a Service (SaaS)-selskaper som opererer i en B2C-modell (business-to-consumer), trenger tradisjonelle TRL-trinn, opprinnelig designet for maskinvareteknologier, betydelig tilpasning. De unike egenskapene til SaaS-utvikling, som fraværet av tradisjonelle laboratoriemiljøer, tidlig engasjement i driftsmiljøet gjennom betatester, og overvekt av freemium-modeller, nødvendiggjør en skreddersydd tilnærming til TRL. Her omdefinerer vi TRL-stadiene for et SaaS-selskap med en B2C-modell, med fokus på denne spesifikke dynamikken.

1. Idékonseptualisering (tilpasset TRL 1)

  • Original TRL 1: Grunnleggende prinsipper overholdt.
  • Tilpasset for SaaS B2C: Opprinnelig idé og potensielle forbrukerapplikasjoner identifisert, med fokus på brukerbehov og markedshull.
  • Hvorfor endringen: SaaS B2C begynner med markedsfokuserte ideer i stedet for grunnleggende vitenskapelig forskning.

2. Teknologikonsept skissert (tilpasset TRL 2)

  • Original TRL 2: Teknologikonsept formulert.
  • Tilpasset for SaaS B2C: Konseptuell design av programvaren, inkludert foreløpige brukeropplevelse (UX) betraktninger og grensesnitt ideer.
  • Hvorfor endringen: Tidlige stadier i SaaS involverer konseptualisering av brukergrensesnittet og opplevelsen, noe som er sentralt i B2C-modeller.

3. Proof of Concept via prototype (tilpasset TRL 3)

  • Original TRL 3: Eksperimentelt bevis på konsept.
  • Tilpasset for SaaS B2C: Utvikling av en grunnleggende prototype eller Minimum Viable Product (MVP) for å demonstrere kjernefunksjonalitet.
  • Hvorfor endringen: Proof of concept i SaaS handler mer om funksjonelle prototyper enn laboratoriebaserte eksperimenter.

4. Tidlig betatesting (tilpasset TRL 4)

  • Original TRL 4: Teknologi validert i lab.
  • Tilpasset for SaaS B2C: Tidlig betaversjon av programvaren er utgitt til en begrenset brukergruppe for innledende testing og tilbakemelding.
  • Hvorfor endringen: SaaS-produkter går ofte tidlig i betatesting, og samler tilbakemeldinger fra brukere i virkelige scenarier.

5. Utvidet betatesting (tilpasset TRL 5)

  • Original TRL 5: Teknologi validert i relevant miljø.
  • Tilpasset for SaaS B2C: Betatesting er utvidet, og inkluderer flere brukere for å avgrense brukervennlighet og funksjonalitet basert på ulike tilbakemeldinger.
  • Hvorfor endringen: I en B2C-modell er omfattende brukertesting avgjørende for å foredle produktet for å møte ulike forbrukerbehov.

6. Driftsmiljøtesting (tilpasset TRL 6)

  • Original TRL 6: Teknologi demonstrert i relevant miljø.
  • Tilpasset for SaaS B2C: Programvare testet i et fullt operativt miljø, simulerer virkelige brukertilfeller.
  • Hvorfor endringen: For SaaS B2C er det viktig å teste produktet i miljøer som ligner mye på hvor forbrukerne vil bruke det.

7. Fullskala produktimplementering (tilpasset TRL 7)

  • Original TRL 7: System prototype demonstrasjon i et operativt miljø.
  • Tilpasset for SaaS B2C: Utgivelse av det fullt funksjonelle produktet, integrert i en effektiv salgstrakt, ofte under en freemium-modell.
  • Hvorfor endringen: B2C SaaS-modeller legger vekt på tilgjengelige produktlanseringsstrategier, som freemium-modeller, for å tiltrekke seg en bred brukerbase.

8. Markedsvalidering og skalering (tilpasset TRL 8)

  • Original TRL 8: System komplett og kvalifisert.
  • Tilpasset for SaaS B2C: Utbredt markedsaksept, med kontinuerlig tilbakemelding fra brukere som fører til inkrementelle forbedringer og skalering.
  • Hvorfor endringen: Markedsvalidering er avgjørende i B2C SaaS, med fokus på brukertilfredshet, oppbevaring og skalering basert på etterspørsel.

9. Modnet og utviklende produkt (tilpasset TRL 9)

  • Original TRL 9: Faktisk system utprøvd i driftsmiljø.
  • Tilpasset for SaaS B2C: Kontinuerlig produktutvikling basert på tilbakemeldinger fra brukere, markedstrender og teknologiske fremskritt.
  • Hvorfor endringen: SaaS B2C-produkter må kontinuerlig utvikles for å forbli relevante og møte endrede forbrukerforventninger.

Avslutningsvis innebærer tilpasning av TRL-stadiene for SaaS B2C-selskaper et skifte fra tradisjonell laboratoriebasert utvikling til en brukersentrisk, markedsdrevet tilnærming. Denne tilpasningen reflekterer den unike dynamikken i programvareutvikling og den avgjørende rollen til brukerengasjement og tilbakemelding i å skape vellykkede B2C SaaS-produkter.

 

Tilpasning av teknologiberedskapsnivåer for selskaper som utvikler nye industrielle prosesser

Skreddersy TRL-stadier for industriell prosessinnovasjon: En veiledning for resirkulerings- og behandlingsteknologier

Innenfor industrielle prosesser som resirkulering, prosessering, belegg, forbedring eller behandling, krever de konvensjonelle teknologiberedskapsnivåene (TRL) som hovedsakelig brukes for maskinvare- og programvareteknologier betydelig tilpasning. Dette gjelder spesielt med tanke på de ulike forretningsmodellene som brukes i denne sektoren, for eksempel salg av prosesseringsmaskinvare, lisensieringsteknologi, bruksavgiftsmodeller eller intern tjenesteyting. I tillegg er skillet mellom operasjonelle og relevante miljøer ofte uskarpt i disse sektorene, da prosessene vanligvis brukes internt og ikke er integrert i eksterne systemer. Nedenfor er TRL-stadiene tilpasset for å reflektere de unike aspektene ved bedrifter som utvikler nye industrielle prosesser.

1. Grunnleggende prinsipp observert (tilpasset TRL 1)

  • Original TRL 1: Grunnleggende prinsipper overholdt.
  • Tilpasset industrielle prosesser: Identifisering og første observasjon av et grunnleggende prinsipp eller konsept som kan føre til en ny industriell prosess.
  • Hvorfor endringen: Vekten skifter til å erkjenne potensialet i grunnleggende prinsipper som kan brukes på industrielle prosesser.

2. Teknologikonseptformulering (tilpasset TRL 2)

  • Original TRL 2: Teknologikonsept formulert.
  • Tilpasset industrielle prosesser: Konseptualisering av hvordan grunnprinsippet kan utvikles til en levedyktig industriell prosess.
  • Hvorfor endringen: Fokus er på å se for seg praktiske anvendelser av det grunnleggende prinsippet i en industriell setting.

3. Eksperimentelt bevis på konsept (tilpasset TRL 3)

  • Original TRL 3: Eksperimentelt bevis på konsept.
  • Tilpasset industrielle prosesser: Innledende eksperimentell oppsett eller demonstrasjon i laboratorieskala for å validere konseptet.
  • Hvorfor endringen: Eksperimentering i tidlig stadium er avgjørende for å etablere gjennomførbarheten av prosessen.

4. Laboratorieskalavalidering (tilpasset TRL 4)

  • Original TRL 4: Teknologi validert i lab.
  • Tilpasset industrielle prosesser: Utvikling og testing av prosessen i liten skala i et kontrollert laboratoriemiljø.
  • Hvorfor endringen: Laboratorievalidering er et kritisk skritt for å forstå prosessens tekniske levedyktighet og potensielle utfordringer.

5. Oppskalert prototypeutvikling (tilpasset TRL 5)

  • Original TRL 5: Teknologi validert i relevant miljø.
  • Tilpasset industrielle prosesser: Oppskalering av prosessen til en prototype som kan operere i et mer realistisk industrimiljø.
  • Hvorfor endringen: Skalering er avgjørende for å demonstrere prosessen under forhold som i større grad etterligner industrielle omgivelser i den virkelige verden.

6. Prototypedemonstrasjon i industrimiljø (tilpasset TRL 6)

  • Original TRL 6: Teknologi demonstrert i relevant miljø.
  • Tilpasset industrielle prosesser: Prototypen er testet i et faktisk industrielt miljø, enten internt eller i en relevant ekstern setting.
  • Hvorfor endringen: Testing i et industrielt miljø gir kritiske data om prosessens effektivitet og gjennomførbarhet under virkelige forhold.

7. Prosessoptimalisering og pre-kommersiell testing (tilpasset TRL 7)

  • Original TRL 7: System prototype demonstrasjon i et operativt miljø.
  • Tilpasset industrielle prosesser: Foredling og optimalisering av prosessen basert på tilbakemeldinger og resultater fra innledende industriell testing, beveger seg mot et pre-kommersielt stadium.
  • Hvorfor endringen: Fokus skifter til å finjustere prosessen for effektivitet, pålitelighet og skalerbarhet, forberedelse til kommersialisering.

8. Kommersiell modellutvikling (tilpasset TRL 8)

  • Original TRL 8: System komplett og kvalifisert.
  • Tilpasset industrielle prosesser: Utvikling av en forretningsmodell (som maskinvaresalg, lisensiering, bruksavgift eller intern service) og forberedelse for markedsinntreden.
  • Hvorfor endringen: På dette stadiet er det lagt vekt på hvordan prosessen skal kommersialiseres og tilbys markedet.

9. Full kommersiell distribusjon (tilpasset TRL 9)

  • Original TRL 9: Faktisk system utprøvd i driftsmiljø.
  • Tilpasset industrielle prosesser: Fullskala kommersiell distribusjon av prosessen, med løpende optimalisering og tilpasning basert på tilbakemeldinger fra markedet.
  • Hvorfor endringen: Prosessen er nå fullt operativ og kommersielt tilgjengelig, med pågående forbedringer basert på virkelig bruk og markedskrav.

Å tilpasse TRL-stadiene for bedrifter som utvikler nye industrielle prosesser, anerkjenner de unike utfordringene og mulighetene i denne sektoren. Disse tilpasningene gir et mer relevant rammeverk for å vurdere modenhet og beredskap for innovative industrielle prosesser, fra første konsept til full kommersiell distribusjon.

 

Tilpasse teknologiberedskapsnivåer for maskinvareproduktutvikling

Reframing TRL-stadier for maskinvareinnovasjoner: Fra konsept til samsvar

Å utvikle et nytt maskinvareprodukt, for eksempel en maskin, enhet eller materiale, krever en skreddersydd tilnærming til rammeverket for teknologiberedskapsnivåer (TRL). I motsetning til programvare eller industrielle prosesser, involverer maskinvareutvikling spesifikke hensyn som produksjonskompleksitet, leverandørvalg og nødvendigheten av sertifiseringer som CE-merker eller ISO-samsvar. Denne artikkelen omdefinerer TRL-stadiene for et selskap som utvikler et nytt maskinvareprodukt, med fokus på disse aspektene.

1. Prinsippidentifikasjon (tilpasset TRL 1)

  • Original TRL 1: Grunnleggende prinsipper overholdt.
  • Tilpasset maskinvare: Konseptualisering av maskinvareproduktet basert på identifiserte prinsipper eller teknologiske behov.
  • Hvorfor endringen: Fokuserer på det første konseptet og gjennomførbarheten i forbindelse med maskinvareutvikling.

2. Teknologikonseptformulering (tilpasset TRL 2)

  • Original TRL 2: Teknologikonsept formulert.
  • Tilpasset maskinvare: Utvikling av innledende maskinvaredesign og utforskning av potensielle applikasjoner.
  • Hvorfor endringen: Tidlig design og applikasjonshensyn er avgjørende for maskinvareutvikling.

3. Proof of Concept Creation (tilpasset TRL 3)

  • Original TRL 3: Eksperimentelt bevis på konsept.
  • Tilpasset maskinvare: Bygge en grunnleggende prototype for å demonstrere gjennomførbarheten til kjernekonseptet.
  • Hvorfor endringen: Prototypeoppretting er et viktig skritt i å validere det grunnleggende konseptet for maskinvareprodukter.

4. Prototypeutvikling (tilpasset TRL 4)

  • Original TRL 4: Teknologi validert i lab.
  • Tilpasset maskinvare: Utvikle en mer avansert prototype for å teste spesifikke funksjoner i en kontrollert setting.
  • Hvorfor endringen: Forbedret prototyping er nødvendig for å avgrense maskinvarens funksjonelle egenskaper.

5. Validering i relevant miljø (tilpasset TRL 5)

  • Original TRL 5: Teknologi validert i relevant miljø.
  • Tilpasset maskinvare: Testing av prototypen i et relevant miljø, simulering av virkelige forhold.
  • Hvorfor endringen: Testing i den virkelige verden er avgjørende for å sikre at maskinvaren fungerer effektivt utenfor laboratoriet.

6. Prototypeoptimalisering (tilpasset TRL 6)

  • Original TRL 6: Teknologi demonstrert i relevant miljø.
  • Tilpasset maskinvare: Foredling og optimalisering av prototypen basert på testing av tilbakemeldinger, med fokus på ytelse og pålitelighet.
  • Hvorfor endringen: Optimalisering er nøkkelen til å forberede maskinvaren for virkelige applikasjoner og produksjon.

7. Produksjonsprosessutvikling (tilpasset TRL 7)

  • Original TRL 7: System prototype demonstrasjon i et operativt miljø.
  • Tilpasset maskinvare: Utvikling av produksjonsprosessen, inkludert valg av partnere eller leverandører.
  • Hvorfor endringen: Produksjon er en betydelig fase i maskinvareutvikling, som krever nøye planlegging og partnervalg.

8. Pre-kommersiell testing og sertifisering (tilpasset TRL 8)

  • Original TRL 8: System komplett og kvalifisert.
  • Tilpasset maskinvare: Gjennomføre omfattende tester for sertifisering (f.eks. CE-merke, forskriftsgodkjenning) og sikre samsvar med standarder (f.eks. ISO).
  • Hvorfor endringen: Å oppnå sertifiseringer og samsvar er avgjørende for markedsberedskapen til maskinvareprodukter.

9. Kommersiell distribusjon (tilpasset TRL 9)

  • Original TRL 9: Faktisk system utprøvd i driftsmiljø.
  • Tilpasset maskinvare: Fullskala produksjon og kommersialisering av maskinvareproduktet.
  • Hvorfor endringen: Fokuset er på vellykket produksjon og markedsintroduksjon av det ferdige maskinvareproduktet.

Tilpasning av TRL-stadier for utvikling av maskinvareprodukt erkjenner den unike veien fra konsept til kommersialisering på dette feltet. Disse stadiene fremhever de avgjørende trinnene som er involvert i å bringe et maskinvareprodukt til markedet, inkludert design, prototyping, produksjon og overholdelse av regulatoriske standarder.


Artiklene funnet på Rasph.com reflekterer meningene til Rasph eller dets respektive forfattere og reflekterer på ingen måte meningene fra EU-kommisjonen (EC) eller European Innovation Council (EIC). Den oppgitte informasjonen tar sikte på å dele perspektiver som er verdifulle og potensielt kan informere søkere om tilskuddsordninger som EIC Accelerator, EIC Pathfinder, EIC Transition eller relaterte programmer som Innovate UK i Storbritannia eller Small Business Innovation and Research Grant (SBIR) i de forente stater.

Artiklene kan også være en nyttig ressurs for andre konsulentvirksomhet i tilskuddsplassen samt profesjonelle stipendforfattere som er ansatt som frilansere eller er en del av en liten og mellomstor bedrift (SME). EIC Accelerator er en del av Horizon Europe (2021-2027) som nylig har erstattet det tidligere rammeprogrammet Horizon 2020.

Denne artikkelen er skrevet av ChatEIC. ChatEIC er en EIC Accelerator-assistent som kan gi råd om skriving av forslag, diskutere aktuelle trender og lage innsiktsfulle artikler om en rekke emner. Artiklene skrevet av ChatEIC kan inneholde unøyaktig eller utdatert informasjon.

Er du interessert i å ansette en forfatter til å søke om stipend i EU?

Ta gjerne kontakt her: Kontakt

Ser du etter et treningsprogram for å lære hvordan du søker på EIC Accelerator?

Finn den her: Opplæring

 

Rasph - EIC Accelerator Rådgivning
nb_NO