Artikler

Digital transformasjon: Forventninger til løsningene som skal anskaffes

La programvarevalg det er en kompleks og artikulert prosess:

vi nevnte det i et tidligere innlegg om valget av den beste programvaren, der vi fokuserte påforeløpig analyse av ens egen bedriftsvirksomhet (uten det er det ikke mulig å ta et lurt valg). Vi vil også se at det for et godt utvalg er nødvendig å vurdere et begrenset antall leverandører. For deretter å analysere ikke bare løsningene fra et "teknisk" synspunkt, men også tjenestene de tilbyr og organisering av menneskelige ressurser som i vårt selskap vil være nødvendige for å få mest mulig ut av den nye programvaren. Ellers vil vi ha brukt pengene våre dårlig ved ikke å få de ønskede fordelene.

La oss nå ta et skritt tilbake og spør oss selv hvilke funksjonelle krav og hvilke hvordan kjøpe må presentere den ideelle løsningen for våre behov: kort sagt, hva er de viktigste fordelene vi forventer å finne i den beste programvaren. Også i dette tilfellet, som for den foreløpige analysen av vår virksomhet, vi vil ikke ta hensyn til noen spesielle produkt eller tekniske spesifikasjoner: dette vil være neste trinn. Foreløpig vil vi bare fylle ut en sjekkliste med elementene for å "krysse av" som vil være nyttige i de neste trinnene.

"Vi spør oss selv hvilke funksjonelle krav og hvilke hvordan kjøpe må presentere den ideelle løsningen for våre behov: kort sagt, hva er de viktigste fordelene vi forventer å finne i den beste programvaren "

Og også i dette tilfellet vårt oppgaveliste det er artikulert og involverer flere beslutningstakere internt i selskapet vårt: absolutt ikke bare IT-avdelingen.

1. Liste over funksjonelle krav: er vi alle på linje?

La utvalg av enterprise-klasse programvare det kan være effekten av et behov, manifestert av en intern sektor i selskapet vårt, eller et direkte mandat til toppledelse (som har et overordnet syn på selskapets fremtidige interesser og strategien som skal følges). Opprinnelsen til selve mandatet avhenger i stor grad av om den behandlede prosessen er kjerne eller sekundær for virksomheten. Husk at ofte valget av en ny programvare er nøkkelen til å endre prosessene.

Uansett er det det som virkelig betyr noe alt aktører involvert (inkludert de som viser behovet, de som tar beslutninger på høyeste nivå og de som har tekniske og funksjonelle ferdigheter til å gjennomføre fremtidige forhandlinger) justert etter formålet med utvalget og egenskapene til løsningen å bli anskaffet.

Bare med disse forutsetningene kan vi faktisk utarbeide liste over funksjonskrav. Ideelt sett vil våre tre aktører (brukere, toppledere og teknisk-funksjonelle analytikere) komme sammen for en felles virksomhet brainstorming. Utvilsomt avhenger denne muligheten av variabelen tempo (det er nødvendig å ta hensyn til de interne kostnadene for definisjon og ledelse av en prosjekt).

Og denne justeringsaktiviteten er desto viktigere hvis vi vurderer et ytterligere aspekt av utvalget: som i alle "Kjøpers reise", det er kjøpsprosessen som starter fra et behov og går gjennom innhenting av informasjon om markedstilbudet, kan det være "Grå områder". Det er faktisk ikke sjelden at toppledelsen, eller firmafunksjonen som vil dra nytte av løsningen, finner seg i å ha en generisk kunnskap om løsningen som skal vedtas: den vet hva den vil, ikke hvordan de kan fortelle den tydelig og eksplisitt. Dette er det også Nyttig spesialiststøtte i IT-sektoren, hvis bemannet av gode funksjonelle analytikere som får på plass de rette ferdighetene.

Her da noen spørsmål teamet vil stille: hva er den detaljerte listen over krav? Er hvert punkt klart for hele teamet som har satt sammen sjekklisten? Har den som skal gjennomføre forhandlingen sitt mandat i tankene? Og er selve mandatet spesifikt og detaljert eller har det hull? En god strategi å ta i bruk kan være Scrum-metoden: den som deltar i prosjektet forteller en historie slik at den diskursive presentasjonen favoriserer defisjon av begrepene som skal brukes i arbeidet.

Liste over funksjonelle krav: en prioritert skala

Ofte foretaksløsningene på markedet ikke har alle nødvendige funksjoner av kjøper. Bedriftsledere vet dette fra begynnelsen. Og dette er grunnen til at når vi har utarbeidet sjekklisten, fortsetter vi å etablere en indeks av prioritet: hvert selskap, når målene er satt, har sine egne.

"Ofte foretaksløsningene på markedetikke har alle nødvendige funksjoner av kjøper. Bedriftsledere vet dette fra begynnelsen. Og dette er grunnen til at når vi har utarbeidet sjekklisten, fortsetter vi å etablere en indeks av prioritet"

Noen foreslår å omgås for hvert krav en annen poengsum av betydning: den totale poengsummen for hver undersøkte løsning vil være summen av dagens krav og deres relative betydning. Det er et råd for sunn fornuft, forutsatt at du ikke er for skjematisk i den endelige evalueringen: det er naturlig at i attribusjonen til en vurdering det er også faktorer utenfor programvaren, mer enn noe relatert til leverandøren. Vi får se dem i et senere innlegg.

3. Kvaliteten på programvaren: liste over indekser

For å evaluere det iboende programvarekvalitet det er nødvendig å etablere noen objektive beregninger (derfor utover de funksjonelle kravene, rent subjektive, kreves av selskapet).

Å ikke vite hvilke variabler som skal måle produktet, betyr ikke å kunne bli klar over hans verdi. Igjen, vi ønsker å sette sammen en liste første å undersøke de individuelle løsningene: vi vil bruke den som en måler på tidspunktet for selve utvelgelsen.

Det er en bred litteratur om emnet: skriv bare inn en søkemotor "Programvarekvalitet" å oppdage innlegg og bøker om emnet. Et nyttig utgangspunkt er stemmen Wikipedia, som lister et sett med parametere ekstern (dvs. angående kvaliteten som brukeren oppfatter), for å evaluere kvaliteten på løsningen som skal anskaffes. Blant disse: korrekthet, pålitelighet, robusthet, effektivitet. Men også interiør, verifiserbar av et team av utviklere: vedlikeholdbarhet, gjenbrukbarhet, modularitet er noen av eksemplene som er listet opp.

Også i dette tilfellet bestemmer teamet en prioritetsindeks for de forskjellige parametrene: for eksempel bedriftsledelsen, som har den strategiske visjonen om prosjektet, kan tilskrive sekundær betydning for gjenbrukbarheten til programvaren. Og selvfølgelig, i denne fasen av programvarevalget, er det bra å vite hvilken mening den har kvalitetsfunksjon av selskapet (der det er til stede).

Nyhetsbrev for innovasjon
Ikke gå glipp av de viktigste nyhetene om innovasjon. Registrer deg for å motta dem på e-post.

4. Budsjett tilgjengelig

Det er en grunnleggende variabel: før du starter en forhandling, må du huske på budsjett totalt du har tilgjengelig for programvareinnsamling (både for selve programvaren og for timekostnadene som er nødvendige for utvelgelsesaktiviteten). For å etablere en realistisk sum har noen allerede et målestokk for løsninger som selskapet tidligere har anskaffet, andre stoler på jungeltelegrafen blant kolleger fra samme sektor (eller fra samme industrikonsern). Å sjekke hvor mye som har blitt brukt tidligere til lignende løsninger letter programvarevalgsprosessen.

"Du må huske på det samlede budsjettet du har tilgjengelig for programvareinnsamling: sjekk hvor mye som er brukt tidligere til lignende løsninger, som faktisk letter programvarevalgsprosessen. "

Selvfølgelig er prisen på et programvarenivå en direkte konsekvens ikke bare av dens egen kvalitet, men også av arbeidet som leverandøren gjør for å designe og utvikle den: for å amortisere kostnadene, er det fleksible anskaffelsesformer (vi vil se dem på punktet 6).

5. Datasikkerhet

Det vil aldri være nok snakk om det: hvert selskap finner seg selv i å gjøre en økende datamengde relatert til virksomheten og kundene. Samtidig vet vi at de siste årene har antallet mennesker økt cyberangrep på firmadatabaser. Å beskytte informasjonen din er derfor et direkte og uunngåelig ansvar for dem som administrerer den.

En av oppgavene til de som gjennomfører forhandlingene vil derfor være å kjenne til beskyttelsen som tilbys. I mellomtiden kan en grunnleggende kunnskap om risikoer og løsninger ikke skade: IKT-avdelingsleder han vil kunne informere selskapskontaktene om begge aspektene.

6. Programvareadministrasjon: hvilke preferanser?

Bestem deg for om du foretrekker en løsning i skyen (på ekstern infrastruktur) eller på premisset (installert på bedriftsservere) er ikke bare et skjellsord: budsjett og type datastyring har direkte innvirkning på hvordan programvaren administreres.

For mange ledere, en lokal løsning det er fremdeles forbundet med en oppfatning av stabilitet og kontroll: de viktigste investeringene må imidlertid vurderes. På den annen side skyen det er mer fleksibelt og rimeligere med tanke på pris, men det krever at leverandøren gir større garantier når det gjelder datasikkerhet og kanalytelse (dvs. hastighet på overføring og utførelse av programmet).

Måten kostnadene antas på, endres også: prisen på stedet er vanligvis basert på en betaling av lisensiering, tilpasningskostnader, første oppsett, påfølgende vedlikeholdskostnader og så videre. Skyen er en modell betale per bruk: større fruktighet, høyere kostnad. I skymodus blir vanligvis alle kostnadene som utgjør kostnadene omgjort til et gebyr som oppsummerer dem, vanligvis lavere (sammenlignet med et flerårig kontraktsforpliktelse, ofte fra tre til fem år).

7. Hvis programvaren må endres: poeng med svakhet og styrke

Det kan virke som et paradoks, men det er bare tilsynelatende: en god sjekkliste over forventningene vi stiller til den nye løsningen ... ser ikke bort fra en analyse av programvaren som må endres. Vi viser selvfølgelig ikke til situasjonen for en første installasjon.

"En god sjekkliste over forventningene vi stiller til den nye løsningen ... ser ikke bort fra en analyse av programvaren som må endres"

For det første er formålet å indikere svakheter: er særegenhetene som førte til at vi lette etter et annet produkt. Selv programvaren eldes og den aggressive behandlingen på det samme kan vise seg å være et galt trekk.

Imidlertid kan det hende vi også må skrive ned noen styrker: det sies ikke faktisk at styringen av prosessen med den gamle løsningen var ufullstendig i alle ledd.

Også under denne analysen er det nyttig å gjøre en delt jobb: funksjonell kunnskap e teknisk kunnskap de går hånd i hånd og begge bidrar til en mer konkret evaluering av programvarens kvalitet. Selv den som skal endre seg!

Personlig tror jeg at når programvaren ikke lenger er tilstrekkelig, så er det absolutt ikke feilen til de som valgte valget den gangen. rett og slett markedet har endret seg og at programvaren ikke svarer til nye forretningsbehov. Dette er grunnen til at den siste orienteringen i økende grad går mot a refactoring kontinuerlige applikasjoner.

Forfatter Paolo Ravalli

Administrerende direktør Mainline srl

Nyhetsbrev for innovasjon
Ikke gå glipp av de viktigste nyhetene om innovasjon. Registrer deg for å motta dem på e-post.

Siste artikler

Innovativ intervensjon i Augmented Reality, med en Apple-seer på Catania Polyclinic

En oftalmoplastikkoperasjon ved bruk av Apple Vision Pro kommersielle seer ble utført på Catania polyklinikk ...

3 mai 2024

Fordelene med fargeleggingssider for barn - en verden av magi for alle aldre

Å utvikle finmotorikk gjennom fargelegging forbereder barna på mer komplekse ferdigheter som å skrive. Å farge…

2 mai 2024

Fremtiden er her: Hvordan shippingindustrien revolusjonerer den globale økonomien

Marinesektoren er en ekte global økonomisk makt, som har navigert mot et 150 milliarder marked...

1 mai 2024

Utgivere og OpenAI signerer avtaler for å regulere flyten av informasjon som behandles av kunstig intelligens

Sist mandag kunngjorde Financial Times en avtale med OpenAI. FT lisensierer sin journalistikk i verdensklasse...

30 april 2024