Artiklar

Digital transformation: Förväntningar på de lösningar som ska förvärvas

La val av programvara det är en komplex och artikulerad process:

vi nämnde det i ett tidigare inlägg om valet av den bästa programvaran, där vi fokuserade påpreliminär analys av ens egen företag (utan vilken det inte är möjligt att göra ett klokt val). Vi ser också att för ett bra urval är det nödvändigt att överväga ett begränsat antal leverantörer. För att sedan analysera inte bara lösningarna ur en "teknisk" synvinkel, utan också de tjänster de erbjuder och organisering av mänskliga resurser som inom vårt företag kommer att vara nödvändiga för att få ut det mesta av den nya programvaran. Annars har vi använt våra pengar dåligt genom att inte få de önskade fördelarna.

Låt oss nu ta ett steg tillbaka och fråga oss vilka funktionella krav och vilka hur man köper måste presentera den idealiska lösningen för våra behov: kort sagt, vilka är de viktigaste fördelarna vi förväntar oss att hitta den bästa programvaran. Också i det här fallet, när det gäller den preliminära analysen av vår verksamhet, vi tar inte hänsyn till någon specifik produkt eller tekniska specifikationer: detta kommer att vara nästa steg. För tillfället kommer vi bara att fylla i en checklista med de objekt som ska "kryssa för" som kommer att vara praktiska i nästa steg.

"Vi frågar oss vilka funktionella krav och vilka hur man köper måste presentera den idealiska lösningen för våra behov: kort sagt, vilka är de viktigaste fördelarna som vi förväntar oss att hitta den bästa programvaran "

Och även i det här fallet vårt att göra-lista det är artikulerat och involverar fler beslutsfattare internt för vårt företag: verkligen inte bara IT-avdelningen.

1. Lista över funktionella krav: är vi alla anpassade?

La urval av företagsklass mjukvara Det kan vara effekten av ett behov, manifesterat av en intern sektor i vårt företag, eller ett direkt mandat från högsta ledningen (som har en övergripande bild av företagets framtida intressen och strategin att följa). Ursprunget på själva mandatet beror till stor del på om den process som behandlas är kärna eller sekundär till verksamheten. Kom ihåg att ofta valet av en ny programvara är nyckeln till att ändra processerna.

Hur som helst, det som verkligen betyder är det allt aktörer involverade (inklusive de som visar på behovet, de som fattar beslut på högsta nivåer och de som har tekniska och funktionella färdigheter för att genomföra framtida förhandlingar) måste vara anpassade till syftet med urvalet och efter lösningens egenskaper att förvärvas.

Endast med dessa antaganden kan vi faktiskt utarbeta lista över funktionskrav. Helst kommer våra tre aktörer (användare, toppchefer och teknisk-funktionella analytiker) att träffas för ett gemensamt företag brainstorming. Utan tvekan beror denna möjlighet på variabeln tempo (det är nödvändigt att ta hänsyn till de interna kostnaderna för defination och förvaltning av en projekt).

Och denna anpassningsaktivitet är desto viktigare om vi överväger en ytterligare aspekt av urvalet: som i alla "Köparens resa", det är köpprocessen som börjar från ett behov och passerar genom att hämta information om marknadserbjudandet, det kan vara "Grå områden". Det är i själva verket inte sällsynt att toppledningen, eller företagets funktion som kommer att dra nytta av lösningen, befinner sig ha en generisk kunskap om lösningen som ska antas: den vet vad den vill, inte hur man säger den tydligt och tydligt. Detta är också utile specialstöd inom IT-sektorn, om bemannad av goda funktionella analytiker som sätter på rätt kompetens.

Här då några frågor teamet ställer: vad är den detaljerade listan över krav? Är varje punkt tydlig för hela teamet som sammanställt checklistan? Har den som ska genomföra förhandlingen sitt mandat i åtanke? Och är själva mandatet specifikt och detaljerat eller har det luckor? En bra strategi att anamma kan vara Scrum-metoden: de som deltar i projektet berättar en historia så att den diskursiva presentationen gynnar defibegreppen som ska användas för arbetet.

Lista över funktionella krav: en prioriterad skala

Ofta företagslösningar på marknaden har inte alla nödvändiga funktioner av köparen. Företagets chefer vet detta från början. Och det är därför vi kontrollerar att när kontrolllistan har upprättats fortsätter vi index för prioritet: varje företag, när målen har fastställts, har sina egna.

"Ofta företagslösningar på marknadenhar inte alla nödvändiga funktioner av köparen. Företagets chefer vet detta från början. Och det är därför vi kontrollerar att när kontrolllistan har upprättats fortsätter vi index för prioritet"

Vissa föreslår att man associerar för varje krav en annan poäng av vikt: den totala poängen för varje undersökt lösning är summan av de nuvarande kraven och deras relativa betydelse. Det är ett sunt förnuft råd, förutsatt att du inte är för schematisk i den slutliga utvärderingen: det är naturligt att i attributen av en betyg det finns också faktorer utanför mjukvaran, mer än något som är relaterat till leverantören. Vi kommer att se dem i ett senare inlägg.

3. Kvaliteten på programvaran: lista över index

För att utvärdera det inneboende mjukvarukvalitet det är nödvändigt att upprätta några objektiv statistik (därför utöver funktionella krav, rent subjektiva, krävs av företaget).

Att inte veta vilka variabler att mäta produkten innebär att man inte kan bli medveten om hans värde. Återigen vill vi sammanställa en lista först för att undersöka de enskilda lösningarna: vi kommer att använda den som en mätare vid det faktiska valet.

Det finns en bred litteratur om ämnet: skriv bara i sökmotorn "Programvarukvalitet" att upptäcka inlägg och böcker om ämnet. En användbar utgångspunkt är rösten wikipedia, som listar en uppsättning parametrar extern (dvs. när det gäller den kvalitet som användaren upplever) för att utvärdera kvaliteten på den lösning som ska förvärvas. Bland dessa: korrekthet, tillförlitlighet, robusthet, effektivitet. Men också interiör, verifierbar av ett team av utvecklare: underhåll, återanvändbarhet, modularitet är några av de exempel som anges.

Även i detta fall beslutar laget ett prioriterat index för de olika parametrarna: till exempel företagsledningen, som har projektets strategiska vision, kan tillskriva programvarans återanvändbarhet sekundär betydelse. Och naturligtvis, i den här fasen av programvaruvalet, är det bra att veta yttrandet från kvalitetsfunktion av företaget (när det finns).

Nyhetsbrev för innovation
Missa inte de viktigaste nyheterna om innovation. Registrera dig för att få dem via e-post.

4. Budget tillgänglig

Det är en grundläggande variabel: innan du startar en förhandling måste du ha i åtanke budget totalt som du har tillgängligt för mjukvaruförvärv (både för själva programvaran och för arbetstidskostnaderna som krävs för urvalsaktiviteten). För att fastställa en realistisk summa har vissa redan ett riktmärke för lösningar som tidigare förvärvats av företaget, andra förlitar sig på word of mouth bland kollegor från samma sektor (eller från samma industrikoncern). Att kontrollera hur mycket som har använts tidigare för liknande lösningar underlättar valet av programvara.

"Du måste ha i åtanke den totala budgeten du har tillgängligt för mjukvaruförvärv: kontrollera hur mycket som har använts tidigare för liknande lösningar som underlättar faktiskt programvalsprocessen "

Naturligtvis är priset på en mjukvaror på företagsnivå en direkt följd inte bara av dess inre kvalitet, utan också av det arbete som utförts av leverantören för att designa och utveckla den: för att amortera kostnaderna finns det flexibla förvärvsformer (vi kommer att se dem vid punkten 6).

5. Datasäkerhet

Det kommer aldrig att finnas tillräckligt med prat om det: varje företag finner sig själv en ökande mängd data avser dess verksamhet och sina kunder. Samtidigt vet vi att de senaste åren har antalet människor ökat cyberattacker på företagsdatabaser. Att skydda din information är därför ett direkt och oundvikligt ansvar för dem som hanterar den.

En av uppgifterna för dem som genomför förhandlingarna är därför att känna till skyddet som tillhandahålls av leverantören. Under tiden kan en grundläggande kunskap om risker och lösningar inte skada: IKT-avdelningschef han kommer att kunna informera sina företagskontakter om båda aspekterna.

6. Programadministration: vilka preferenser?

Bestäm om du föredrar en lösning i molnet (på fjärrinfrastruktur) eller på plats (installerat på företagsservrar) är inte bara en fråga: budget och typ av datahantering har sina direkta effekter på hur programvaran administreras.

För många chefer, en lokal lösning det är fortfarande förknippat med en uppfattning om stabilitet och kontroll: de viktigaste investeringarna måste dock beaktas. Å andra sidan molnet det är mer flexibelt och billigare vad gäller pris, men det kräver att leverantören ger större garantier när det gäller datasäkerhet och kanalprestanda (dvs. överföringshastighet och genomförande av programmet).

Det sätt på vilket kostnader antas förändras också: priset på plats baseras i allmänhet på en betalning av licensiering, anpassningskostnader, initial installation, efterföljande underhållskostnader och så vidare. Molnet är en modell betala per användning: större frukt, högre kostnad. I molnläget förvandlas vanligtvis alla avgifter som utgör kostnaden till en avgift som summerar dem, vanligtvis lägre (jämfört med ett flerårigt avtalsenligt åtagande, ofta från tre till fem år).

7. Om programvaran måste ändras: punkter på svaghet och styrka

Det kan verka som en paradox, men det är bara tydligen: en bra checklista över förväntningarna vi ställer på den nya lösningen ... bortser inte från en analys av programvaran som måste ändras. Naturligtvis hänvisar vi inte till situationen för en första installation.

"En bra checklista över de förväntningar vi ställer på den nya lösningen ... bortser inte från en analys av programvaran som måste ändras"

Först är syftet att indikera svagheter: är de särdrag som fick oss att leta efter en annan produkt. Även mjukvaran åldras och den aggressiva behandlingen på samma kan visa sig vara ett fel drag.

Men vi kanske också måste skriva ner några styrkor: det sägs inte att hanteringen av processen med den gamla lösningen var ofullständig i alla aspekter.

Också under denna analys är det användbart att göra ett delat jobb: funktionell kunskap e teknisk kunskap de går hand i hand och båda bidrar till en mer konkret utvärdering av programvarans kvalitet. Till och med den som ska förändras!

Personligen tror jag att när programvaran inte längre är tillräcklig är det verkligen inte felet för dem som gjorde valet vid den tiden. helt enkelt marknaden har förändrats och att programvaran inte svarar på nya affärsbehov. Det är därför den senaste orienteringen i allt högre grad riktar sig mot a refacto kontinuerliga applikationer.

Autore Paolo Ravalli

VD Mainline srl

Nyhetsbrev för innovation
Missa inte de viktigaste nyheterna om innovation. Registrera dig för att få dem via e-post.

Articoli recenti

Onlinebetalningar: Här är hur streamingtjänster får dig att betala för alltid

Miljontals människor betalar för streamingtjänster och betalar månatliga prenumerationsavgifter. Det är en allmän uppfattning att du...

29 April 2024

Veeam har det mest omfattande stödet för ransomware, från skydd till svar och återställning

Coveware by Veeam kommer att fortsätta att tillhandahålla svarstjänster för cyberutpressning. Coveware kommer att erbjuda kriminaltekniska och saneringsmöjligheter...

23 April 2024

Grön och digital revolution: Hur prediktivt underhåll förändrar olje- och gasindustrin

Förutsägande underhåll revolutionerar olje- och gassektorn, med ett innovativt och proaktivt förhållningssätt till anläggningsförvaltning.…

22 April 2024

Brittisk antitrustregulator väcker larm över BigTech över GenAI

UK CMA har utfärdat en varning om Big Techs beteende på marknaden för artificiell intelligens. Där…

18 April 2024