Digitale transformasie: verwagtinge oor die oplossings wat verkry gaan word

La sagteware seleksie dit is 'n ingewikkelde en geartikuleerde proses:

ons het dit in 'n vorige boodskap genoem oor die keuse van die beste sagteware waarop ons gefokus hetvoorlopige ontleding van u eie korporatiewe besigheid (waarsonder dit nie moontlik is om 'n wyse keuse te maak nie). Ons sal ook sien dat dit nodig is om 'n beperkte aantal verkopers te oorweeg vir 'n goeie keuse. Om dan nie net die oplossings vanuit 'n "tegniese" oogpunt te ontleed nie, maar ook die dienste wat hulle aanbied en die organisering van menslike hulpbronne wat binne ons onderneming nodig sal wees om die beste uit die nuwe sagteware te put. Anders sou ons ons geld sleg bestee het deur nie die gewenste voordele te kry nie.

Kom ons neem 'n tree terug en vra ons af watter funksionele vereistes en watter hoe om te koop sal die ideale oplossing vir ons behoeftes moet bied: in kort, wat is die belangrikste voordele wat ons in die beste sagteware sal vind? Ook in hierdie geval, wat betref die voorlopige ontleding van ons besigheid, ons sal geen spesifieke produk- of tegniese spesifikasies in ag neem nie: dit sal die volgende stap wees. Ons sal nou eers 'n kontrolelys invul met die items om te "merk" wat in die volgende stappe nuttig sal wees.

'Ons vra ons af watter funksionele vereistes en watter hoe om te koop sal die ideale oplossing vir ons behoeftes moet bied: kortliks, wat is die belangrikste voordele wat ons in die beste sagteware sal vind "

En ook in hierdie geval, ons s'n om te doen lys dit is geartikuleerd en behels meer besluitnemers intern vir ons onderneming: beslis nie net die IT-afdeling nie.

1. Lys met funksionele vereistes: is ons almal in lyn?

La seleksie van ondernemingsklas-sagteware dit kan die effek wees van 'n behoefte, gemanifesteer deur 'n interne sektor van ons onderneming, of 'n direkte mandaat van die topbestuur (wat 'n geheelbeeld van die toekomsbelange van die onderneming en die strategie wat volg) het. Die oorsprong van die mandaat self hang grootliks daarvan af of die proses wat oorweeg word, is kern of sekondêr tot die onderneming. Onthou dat die keuse van 'n nuwe sagteware dikwels die sleutel is om die prosesse te verander.

In elk geval, dit wat regtig saak maak, is dit alle betrokke akteurs (insluitend diegene wat die behoefte openbaar, diegene wat op die hoogste vlak besluite neem en diegene wat oor die tegniese en funksionele vaardighede beskik om toekomstige onderhandelinge uit te voer) moet in lyn gebring met die doel van die keuse en die eienskappe van die oplossing verkry word.

Slegs met hierdie aannames kan ons die werklikheid opstel lys van funksionele vereistes. Die ideaal is dat ons drie akteurs (gebruikers, topbestuurders en tegnies-funksionele ontleders) bymekaarkom vir 'n gemeenskaplike onderneming dinkskrum. Ongetwyfeld hang hierdie moontlikheid van die veranderlike af tyd (dit is nodig om die interne koste vir die definisie en bestuur van 'n projek).

En hierdie belyningsaktiwiteit is des te meer belangrik as ons 'n verdere aspek van die keuring oorweeg: soos by almal "Koper se reis", dit is die aankoopproses wat begin uit 'n behoefte en deur die herwinning van inligting oor die markaanbod gaan, kan daar "Grys gebiede". Dit is nie selde dat topbestuur, of die bedryfsfunksie wat voordeel trek uit die oplossing nie, 'n algemene kennis het van die oplossing wat aangewend moet word: hulle weet wat hulle wil, nie hoe om dit duidelik en eksplisiet te vertel nie. Dit is ook nuttige spesialisondersteuning in die IT-sektor, indien beman deur goeie funksionele ontleders wat die regte vaardighede in plek het.

Hier dan 'n paar vrae wat die span sal stel: wat is die gedetailleerde lys van vereistes? Is elke punt duidelik vir die hele span wat die kontrolelys saamgestel het? Het wie ook al die onderhandeling gaan uitvoer sy mandaat in gedagte? En is die mandaat self spesifiek en gedetailleerd of het dit leemtes? 'n Goeie strategie om aan te neem kan die Scrum-metode wees: diegene wat aan die projek deelneem, vertel 'n storie sodat die diskursiewe aanbieding bevoordeel defisie van die konsepte wat vir die werk gebruik moet word.

Lys met funksionele vereistes: 'n prioriteitsskaal

Dikwels is die onderneming oplossings op die mark nie al die nodige funksies het nie deur die koper. Ondernemingsbestuurders weet dit van die begin af. En dit is waarom ons, sodra die kontrolelys opgestel is, voortgaan om 'n indeks van prioriteit: elke onderneming, sodra die doelwitte gestel is, het sy eie.

'Dikwels is die onderneming-oplossings op die marknie al die nodige funksies het nie deur die koper. Ondernemingsbestuurders weet dit van die begin af. En dit is waarom ons, sodra die kontrolelys opgestel is, voortgaan om 'n indeks van prioriteit"

Sommige stel voor om te assosieer vir elke vereiste is daar 'n ander punt van belang: die totale telling van elke ondersoek wat ondersoek word, is die som van die huidige vereistes en die relatiewe belang daarvan. Dit is 'n gesonde verstandadvies, mits u nie te skematies is in die finale evaluering nie; dit is natuurlik dat u gradering daar is ook faktore buite die sagteware, meer as enigiets wat met die verskaffer verband hou. Ons sal hulle in 'n latere pos sien.

3. Die kwaliteit van die sagteware: lys van indekse

Om die intrinsieke te evalueer sagteware kwaliteit dit is nodig om sommige vas te stel objektiewe statistieke (dus buite die funksionele vereistes, suiwer subjektief, wat deur die onderneming vereis word).

As u nie weet watter veranderlikes die produk moet meet nie, moet u nie daarvan bewus raak nie waarde. Ons wil weer 'n lys saamstel 1 om die individuele oplossings te ondersoek: ons sal dit gebruik as 'n meter ten tyde van die werklike seleksie.

Daar is 'n wye literatuur oor die onderwerp: tik eintlik 'n soekenjin in "Sagtewarekwaliteit" om plasings en boeke oor die onderwerp te ontdek. Die stem is 'n nuttige beginpunt Wikipedia, wat 'n lys maak 'n stel parameters eksterne (dws betreffende die kwaliteit wat die gebruiker waarneem) om die kwaliteit van die oplossing wat verkry word te evalueer. Onder hierdie: korrektheid, betroubaarheid, robuustheid, doeltreffendheid. Maar ook binneland, kan bevestig word deur 'n span van ontwikkelaarsonderhoubaarheid, herbruikbaarheid, modulariteit is enkele voorbeelde.

Ook in hierdie geval besluit die span 'n prioriteitsindeks vir die verskillende parameters: byvoorbeeld die ondernemingsbestuur, wat die strategiese visie van die projek het, kan sekondêre belang toeskryf aan die herbruikbaarheid van die sagteware. En natuurlik is dit goed om te weet wat die mening van die sagteware is kwaliteit funksie van die maatskappy (waar teenwoordig).

4. Begroting beskikbaar

Dit is 'n fundamentele veranderlike: voordat u met 'n onderhandeling begin, moet u die volgende in gedagte hou begroting totaal waarvoor u beskikbaar het sagteware verkryging (beide vir die sagteware self sowel as vir die werksure wat nodig is vir die seleksie-aktiwiteit). Om 'n realistiese som te bepaal, het sommige reeds 'n maatstaf van oplossings wat voorheen deur die onderneming bekom is, en ander vertrou op mondeling onder kollegas uit dieselfde sektor (of uit dieselfde industriële groep). Deur te kyk hoeveel daar voorheen aan soortgelyke oplossings bestee is, vergemaklik dit die proses van sagteware-seleksie.

'U moet die totale begroting wat u beskikbaar het, in gedagte hou sagteware verkryging: kyk hoeveel daar voorheen spandeer is vir soortgelyke oplossings, en dit vergemaklik die keuse van sagteware

Uiteraard is die prys van 'n sagteware op ondernemingsvlak 'n direkte gevolg nie net van die intrinsieke kwaliteit daarvan nie, maar ook van die werk wat die verskaffer gedoen het om dit te ontwerp en te ontwikkel: om die koste te amortiseer, is daar buigsame vorme van verkryging (ons sal hulle sien op die punt 6).

5. Datasekuriteit

Daar sal nooit genoeg daaroor gepraat word nie: elke onderneming vind hulself besig 'n toenemende hoeveelheid data met betrekking tot sy besigheid en sy kliënte. Terselfdertyd weet ons dat die aantal mense in die afgelope jaar toegeneem het kuber aanvalle op maatskappydatabasisse. Die beskerming van u inligting is dus 'n direkte en onvermydelike verantwoordelikheid van diegene wat dit bestuur.

Een van die take van diegene wat die onderhandeling voer, is dus om te weet watter beskerming die aanbieder het. Intussen kan 'n basiese kennis van risiko's en oplossings nie skade berokken nie: die IKT-afdelingsbestuurder hy sal in staat wees om sy kontakpersone oor albei aspekte in te lig.

6. Sagteware-administrasie: watter voorkeure?

Besluit of u 'n oplossing verkies in die wolk (op afgeleë infrastruktuur) of op uitgangspunt (geïnstalleer op bedieners se bedieners) is nie bloot 'n vreemdeling nie: die begroting en tipe databestuur het hul direkte impak hoe die sagteware geadministreer word.

Vir baie bestuurders, een oplossing op die perseel dit hou nog steeds verband met 'n persepsie van stabiliteit en beheer: die belangrikste beleggings moet egter oorweeg word. Aan die ander kant, die wolk dit is buigbaarder en goedkoper ten opsigte van prys, maar dit vereis dat die verskaffer groter waarborge gee ten opsigte van datasekuriteit en kanaalprestasie (dit wil sê die snelheid van die transmissie en uitvoering van die program).

Die manier waarop koste aangeneem word, verander ook: die prys op die perseel is gewoonlik gebaseer op 'n betaling van lisensiëring, aanpassingskoste, aanvanklike opstelling, daaropvolgende onderhoudskoste en so aan. Die wolk is 'n model betaal per gebruik: groter vrug, hoër koste. In die wolkmodus word alle koste wat die koste uitmaak, gewoonlik omskep in 'n fooi wat dit opgesom, gewoonlik laer (in vergelyking met 'n meerjarige kontraktuele verbintenis, dikwels van drie tot vyf jaar).

7. As die sagteware verander moet word: punte van swakheid en sterkte

Dit mag 'n paradoks wees, maar dit is blykbaar net: 'n goeie kontrolelys van die verwagtinge wat ons aan die nuwe oplossing stel ... miskyk nie 'n ontleding van die sagteware wat verander moet word. Natuurlik verwys ons nie na die situasie van 'n eerste installasie nie.

'' N Goeie kontrolelys van die verwagtinge wat ons aan die nuwe oplossing stel ... word nie misken nie 'n ontleding van die sagteware wat verander moet word"

Eerstens is die doel om die swakhede: is die eienaardighede wat daartoe gelei het dat ons na 'n ander produk gesoek het. Selfs die sagteware verouder en die aggressiewe behandeling daarop kan 'n verkeerde beweging wees.

Ons sal dit miskien ook moet neerskryf sterkpunte: daar word nie gesê dat die bestuur van die proses met die ou oplossing in alle opsigte onvolledig was nie.

Ook tydens hierdie ontleding is dit nuttig om 'n gedeelde werk te verrig: funksionele kennis e tegniese kennis hulle gaan hand aan hand en dra albei by tot 'n meer konkrete evaluering van die kwaliteit van die sagteware. Selfs die een om te verander!

Persoonlik dink ek dat wanneer die sagteware nie meer voldoende is nie, dit beslis nie die skuld is van diegene wat destyds die keuse gemaak het nie. eenvoudig die mark het verander en dat sagteware nie op nuwe sakebehoeftes reageer nie. Dit is waarom die nuutste oriëntasie toenemend na 'n refactoring deurlopende toepassings.

Autore Paolo Ravalli

Hoof uitvoerende hoof srl