mēs to pieminējām iepriekšējā ierakstā par labākās programmatūras izvēli, kurā mēs koncentrējāmiessākotnējā analīze par savu korporatīvais bizness (bez kura nav iespējams izdarīt gudru izvēli). Mēs arī redzēsim, ka labai izvēlei ir jāņem vērā ierobežots pārdevēju skaits. Pēc tam analizēt ne tikai risinājumus no "tehniskā" viedokļa, bet arī piedāvātos pakalpojumus un cilvēkresursu organizāciju, kas mūsu uzņēmumā būs nepieciešami, lai maksimāli izmantotu jauno programmatūru. Pretējā gadījumā mēs būsim tērējuši savu naudu slikti, nesaņemot vēlamos labumus.
Tagad spersim soli atpakaļ un pajautāsim sev, kuri no tiem funkcionālās prasības un kuri no tiem kā iegādāties mums būs jāiesniedz ideāls risinājums mūsu vajadzībām: īsumā - kādi ir galvenie ieguvumi, ko mēs sagaidām vislabākajā programmatūrā. Arī šajā gadījumā, tāpat kā mūsu biznesa provizoriskajā analīzē, mēs neņemsim vērā nevienu konkrētu produktu vai tehniskās specifikācijas: tas būs nākamais solis. Pagaidām mēs vienkārši aizpildīsim kontrolsarakstu ar “atzīmējamiem” vienumiem, kas noderēs nākamajās darbībās.
"Mēs sev jautājam, kuri no tiem funkcionālās prasības un kuri no tiem kā iegādāties būs jāiesniedz ideāls risinājums mūsu vajadzībām: īsumā, kādi ir galvenie ieguvumi, kurus mēs sagaidām vislabākajā programmatūrā "
Un arī šajā gadījumā mūsējais darāmo lietu saraksts tas ir artikulēts un saistīts vairāk lēmumu pieņēmēju iekšējs mūsu uzņēmumam: noteikti ne tikai IT departaments.
La uzņēmuma klases programmatūras atlase tas var būt nepieciešamības efekts, kas izpaužas ar mūsu uzņēmuma iekšējo sektoru, vai tieša uzņēmuma mandāts augstākā vadība (kuram ir vispārējs priekšstats par uzņēmuma nākotnes interesēm un ievērojamā stratēģija). Pats pilnvarojuma izcelsme lielā mērā ir atkarīga no tā, vai notiek attiecīgais process kodols vai sekundārs biznesam. Atceroties, ka procesa maiņas atslēga bieži ir jaunas programmatūras izvēle.
Jebkurā gadījumā tas ir svarīgi visiem iesaistītie aktieri (ieskaitot tos, kuri pauž vajadzību, tiem, kuri pieņem lēmumus augstākajā līmenī, un tiem, kuriem ir tehniskās un funkcionālās prasmes turpmākām sarunām) saskaņots ar izvēles mērķi un risinājuma īpašībām jāiegūst.
Tikai ar šiem pieņēmumiem mēs faktiski varam izstrādāt funkcionālo prasību saraksts. Ideālā gadījumā mūsu trīs dalībnieki (lietotāji, augstākie vadītāji un tehniski funkcionālie analītiķi) sanāk kopā kopējam biznesam Prāta vētras. Neapšaubāmi, šī iespēja ir atkarīga no mainīgā laiks (jāņem vērā iekšējās izmaksas par defia projekts).
Un šī izlīdzināšanas darbība ir vēl jo svarīgāka, ja ņemam vērā vēl vienu atlases aspektu: kā katrā "Pircēja ceļojums", tas ir, pirkšanas process, kas sākas no vajadzības un iet caur tirgus piedāvājuma informācijas iegūšanu, iespējams, "Pelēkās zonas". Tas nav reti, ja augstākā vadība vai uzņēmuma funkcija, kas gūs labumu no risinājuma, saņem vispārīgas zināšanas par pieņemamo risinājumu: tā zina, ko vēlas, nevis to, kā to skaidri un nepārprotami pateikt. Arī tas ir utile speciālistu atbalsts IT nozarē, ja to vada labi funkcionālie analītiķi, kuri ievieš pareizās prasmes.
Tad šeit daži jautājumi, ko komanda uzdos: kāds ir detalizēts prasību saraksts? Vai katrs punkts ir skaidrs visai komandai, kas sastādīja kontrolsarakstu? Vai tas, kurš veiks sarunas, patur prātā savas pilnvaras? Un vai pašas pilnvaras ir konkrētas un detalizētas, vai arī tajā ir nepilnības? Laba stratēģija, ko izmantot, varētu būt Scrum metode: tie, kas piedalās projektā, stāsta stāstu, lai diskursīvā prezentācija būtu labvēlīga defidarbā izmantojamo jēdzienu definīcija.
Bieži vien uzņēmuma risinājumi tirgū nav visu nepieciešamo funkciju pircējam. Uzņēmuma vadītāji to zina jau no paša sākuma. Un tāpēc, tiklīdz ir sastādīts kontrolsaraksts, mēs sākam izveidot a indekss prioritāte: katram uzņēmumam, kad mērķi ir izvirzīti, ir savs.
"Bieži vien uzņēmuma risinājumi tirgūnav visu nepieciešamo funkciju pircējam. Uzņēmuma vadītāji to zina jau no paša sākuma. Un tāpēc, tiklīdz ir sastādīts kontrolsaraksts, mēs sākam izveidot a indekss prioritāte"
Daži iesaka apvienoties katrai prasībai - atšķirīgs nozīmīguma rādītājs: katra pārbaudītā risinājuma kopējais punktu skaits būs pašreizējo prasību summa un to relatīvā nozīme. Tas ir vesela saprāta padoms, ja vien gala novērtējumā jūs neesat pārāk shematisks: ir dabiski, ka, piešķirot reitings ir arī faktori, kas ir ārpus programmatūras, vairāk nekā jebkas, kas saistīts ar piegādātāju. Mēs tos redzēsim vēlāk.
Novērtēt iekšējo programmatūras kvalitāte ir jāizveido daži objektīvie rādītāji (tāpēc pārsniedz funkcionālas prasības, kas ir tīri subjektīvas, un ko pieprasa uzņēmums).
Nezināt, kuri mainīgie lielumi mēra produktu, nozīmē nespēju uzzināt par savu vērtība. Atkal mēs vēlamies sastādīt sarakstu pirmais izpētīt individuālos risinājumus: mēs to izmantosim kā skaitītāju faktiskās izvēles laikā.
Par šo tēmu ir plaša literatūra: patiesībā vienkārši ierakstiet meklētājprogrammā "Programmatūras kvalitāte" atklāt ziņas un grāmatas par šo tēmu. Noderīgs sākumpunkts ir balss Wikipedia, kurā uzskaitīti parametru kopums ārējs (ti, attiecībā uz kvalitāti, ko uztver lietotājs), lai novērtētu iegūstamā risinājuma kvalitāti. Starp tiem: pareizība, uzticamība, izturība, efektivitāte. Bet arī Interjers, kuru var pārbaudīt izstrādātāji: daži no uzskaitītajiem piemēriem ir apkope, atkārtota izmantojamība, modulārums.
Arī šajā gadījumā komanda izlemj dažādu parametru prioritātes indekss: piemēram, uzņēmuma vadība, kurai ir projekta stratēģiskais redzējums, var piešķirt sekundāru nozīmi programmatūras atkārtotai izmantošanai. Un, protams, šajā programmatūras izvēles posmā ir labi zināt kvalitātes funkcija uzņēmuma (ja tāds ir).
Tas ir būtisks mainīgais: pirms sarunu uzsākšanas jums jāpatur prātā budžets kopējais, kas jums ir pieejams programmatūras iegāde (gan par pašu programmatūru, gan par cilvēka stundas izmaksām, kas vajadzīgas atlases darbībai). Lai noteiktu reālistisku summu, dažiem jau ir uzņēmuma iepriekš iegādāto risinājumu etalons, citi paļaujas uz mutiski izteiktiem kolēģiem no tās pašas nozares (vai no tās pašas rūpniecības grupas). Pārbaudot, cik daudz iepriekš ir iztērēts līdzīgiem risinājumiem, tiek atvieglots programmatūras izvēles process.
"Jums jāpatur prātā kopējais budžets, kas jums pieejams programmatūras iegāde: pārbaudiet, cik daudz iepriekš ir iztērēts līdzīgiem risinājumiem, kas faktiski atvieglo programmatūras izvēles procesu "
Protams, uzņēmuma līmeņa programmatūras cena ir tiešas sekas ne tikai tai raksturīgajai kvalitātei, bet arī piegādātāja ieguldītajam darbam, lai to izstrādātu un attīstītu: lai amortizētu izmaksas, ir elastīgas apguves formas (mēs tos redzēsim vietā 6).
Par to nekad nebūs pietiekami daudz runāts: katrs uzņēmums pats nodarbojas pieaugošs datu apjoms kas saistīti ar tā biznesu un klientiem. Tajā pašā laikā mēs zinām, ka pēdējos gados cilvēku skaits ir palielinājies kiberuzbrukumiem uzņēmumu datu bāzēs. Tādēļ savas informācijas aizsargāšana ir tieša un neizbēgama atbildība tiem, kas to pārvalda.
Tāpēc viens no sarunu vedēju uzdevumiem būs zināt pakalpojumu sniedzēja ieviesto aizsardzību. Tikmēr pamata zināšanas par riskiem un risinājumiem nevar kaitēt: IKT nodaļas vadītājs viņš varēs informēt sava uzņēmuma kontaktinformāciju par abiem aspektiem.
Izlemiet, vai dodat priekšroku risinājumam mākonī (uz attālo infrastruktūru) vai uz priekšu (instalēta uzņēmuma serveros) nav tikai ķeksis: budžetam un datu pārvaldības veidam ir tieša ietekme kā tiek administrēta programmatūra.
Daudziem vadītājiem viens risinājums uz vietas tas joprojām ir saistīts ar stabilitātes un kontroles uztveri, tomēr jāņem vērā visnozīmīgākie ieguldījumi. No otras puses, mākonis tā ir elastīgāka un lētāka cenas ziņā, taču tai ir nepieciešams, lai piegādātājs sniegtu lielākas garantijas attiecībā uz datu drošību un kanālu darbību (ti, programmas pārraides un izpildes ātrumu).
Mainās arī izmaksu pieņemšanas veids: cena uz vietas parasti balstās uz samaksu licencēšana, pielāgošanas izmaksas, sākotnējā iestatīšana, turpmākās uzturēšanas izmaksas utt. Mākonis ir paraugs maksā par lietošanu: lielāka produktivitāte, augstākas izmaksas. Parasti mākoņa režīmā visas maksas, kas veido izmaksas, tiek pārveidotas par maksu, kas tos summē, parasti zemāku (salīdzinot ar vairāku gadu līgumsaistībām, bieži no trim līdz pieciem gadiem).
Tas var šķist paradokss, bet tas ir tikai acīmredzami: labs pārbaudījumu saraksts ar cerībām, ko mēs uzliekam uz jauno risinājumu ... neignorē jāmaina programmatūras analīze. Protams, mēs nerunājam par pirmās instalācijas situāciju.
"Labs kontrolsaraksts ar cerībām, kuras mēs uzliekam uz jauno risinājumu ... neignorē jāmaina programmatūras analīze"
Pirmkārt, mērķis ir norādīt vājās puses: ir īpatnības, kas lika mums meklēt citu produktu. Pat programmatūras vecums un agresīva izturēšanās ar to pašu var izrādīties nepareiza rīcība.
Tomēr mums var nākties arī dažus pierakstīt punti di forza: faktiski nav teikts, ka procesa vadība ar veco risinājumu visos aspektos bija nepilnīga.
Arī šīs analīzes laikā ir lietderīgi veikt kopīgu darbu: funkcionālās zināšanas e tehniskās zināšanas tie iet roku rokā un abi veicina programmatūras kvalitātes konkrētāku novērtēšanu. Pat to, kas jāmaina!
Personīgi es domāju, ka tad, kad programmatūra vairs nav piemērota, tā noteikti nav to personu vaina, kas toreiz izdarīja izvēli. vienkārši tirgus ir mainījies un šī programmatūra nereaģē uz jaunām biznesa vajadzībām. Tāpēc jaunākā orientācija arvien vairāk tiek vērsta uz a refactoring nepārtrauktas lietojumprogrammas.
Autore Paolo Ravalli
Jūras flotes nozare ir patiess globāls ekonomikas spēks, kas ir virzījies uz 150 miljardu tirgu...
Pagājušajā pirmdienā Financial Times paziņoja par darījumu ar OpenAI. FT licencē savu pasaules līmeņa žurnālistiku…
Miljoniem cilvēku maksā par straumēšanas pakalpojumiem, maksājot ikmēneša abonēšanas maksu. Ir izplatīts uzskats, ka jūs…
Veeam Coveware turpinās nodrošināt reaģēšanas pakalpojumus uz kiberizspiešanas incidentiem. Coveware piedāvās kriminālistikas un sanācijas iespējas…
