Detta är inte en retorisk fråga. Det finns absolut situationer eller användningsområden där kommersiell GIS är mer eller mindre nödvändig för att svara upp på behov och de förutsättningar som råder. Detta i sig säger ingenting om kommersiell GIS är ”bättre” eller ”sämre” än GIS med öppen källkod. Vad som är bäst i varje situation varierar och beror helt och hållet på just behov och förutsättningar.
Rubrikens frågeställning handlar om man för det första vet vilket faktiskt behov man har, samt i vilken omfattning olika GIS lösningar motsvarar dessa behov. I den analysen så väger man sedan in andra förutsättningar som ekonomi, kunskaper och färdigeter eller behov av stöd.
Utan att ha koll på behovet så går det inte att kritisera någon i vilket val de gör. När man enbart ser ”produkter” från exempelvis myndigheter och offentlig förvaltning så är det sällan som man kan dra paralleller till den enda eller den andra GIS lösningens unika egenskaper. Bakom kulisserna så kan det däremot finnas både randiga och rutiga skäl som gör att man valt som man gjort.
När man sedan har koll på behovet så är valet ändå sällan självklart. Numera så är det i praktiken ganska små skillnader mellan olika lösningar i slutändan. Vägen till resultatet är däremot mer eller mindre krokig. Förutsättningar som exempelvis ekonomi kan sedan vara hinder som måste hanteras, och det är inte säkert att den allt igenom ”bästa” lösningen kan väljas av helt andra skäl.
Tyvärr så tror jag att många val görs på bristfälliga grunder, och i många fall görs de mest avgörande valen av personer som antingen föredrar en eller annan lösning personligen (av olika skäl) eller helt enkelt har bristande kunskaper om de olika alternativens möjligheter.
Många som inser att de har brister i de egna kunskaperna vänder sig klokt nog till extern kompetens. Men jag undrar hur många som ställer krav på att det ska presenteras olika lösningar med för- och nackdelar med alternativen. Jag misstänker att det ofta blir ”en” lösning som i relativt stor utsträckning motsvarar behoven, men där den som i slutändan ska fatta beslutet inte har något annat val än att säga ja eller nej till den presenterade lösningen.
Om man vill ha öppen källkod som ett alternativ så är det inte säkert att det är så enkelt. Många upphandlingar handlar om att begära in offerter, som man sedan tar ställning till. Men om det saknas leverantör av lösningar som bygger på öppen källkod, vilket inte är ovanligt, så får man så klart inga sådana alternativ att ta ställning till.
Ett sätt att balansera externa offerter är att försöka ta fram ett eget alternativ som ska vara möjligt att utveckla och hantera internt. Det kan innebära kostnader för nyanställningar, eller investeringar i hårdvara, men framför allt en satsning på kunskap. Att sedan jämföra olika alternativ blir antagligen inte helt trivialt, men ATT ha val gör resultatet potentiellt mycket bättre.
Har man sedan en gång gjort ett val, så kommer nästa fråga. När är det dags att ompröva det valet? Och varför? Är det behoven som ändrats, och i så fall, vet man att behoven ändrats? Har tidigare ratade lösningar förbättrats på viktiga punkter, som gör att de nu är tänkbara. Ska man sedan ”byta” lösning så är det inte sällan extra kostnader förknippade med detta. Det brukar framför allt vara så om man tidigare valt en lösning där ”inlåsning” i proprietära format är vanligt förekommande. Det är viktigt att man ser till hela systemets livslängd när man försöker bedöma eventuella konsekvenser på längre sikt.
Det är sedan säkert inte ovanligt att beslut i en del av verksamheten får konsekvenser i andra delar. Hur mycket av detta är möjligt att förutse? Före beslut så bör alla olika delar ges möjlighet att ha synpunkter baserat på underlag som är relevanta för deras specifika verksamheter. Ett tekniskt kopplingsschema är ganska värdelöst för en avdelning inriktad mot personliga relationer eller ekonomi att ta ställning till…
Sammanfattningsvis
Ska du upphandla eller etablera en GIS funktionalitet i organisationen eller företaget. Då bör du:
- Analysera behovet så noga du kan. Ta vid behov hjälp, men var noga med att behovet inte utesluter specifika produkter eller i sig förordar en leverantör eller produkt.
- Efter behovsanalys så kan man ta in offerter, eller på annat sätt göra alternativgenereringar. Säkerställ att alternativen skiljer sig åt, och att öppen källkod finns med som ett alternativ. Om ingen offert bygger på öppen källkod så bör ett internt alternativ tas fram.
- Alternativjämförelsen bör göras ur flera perspektiv. Det ska vara hållbart under överskådlig tid. Ekonomi, kompetens, infrastruktur, säkerhet och sårbarhet är saker som ska beaktas. Men framför allt så är det såklart det analyserade behovet som ska uppfyllas.
- I samband med beslut så bör man även göra en konsekvensanalys. När ska man göra en översyn av lösningen? kommer det att vara möjligt att göra förändringar? Finns det en plan för att hantera en eventuell avveckling? Kommer valet att leda till förutsägbara konsekvenser inom andra områden? Analysen bör täcka in systemets hela livslängd, även om denna inte är tidsmässigt preciserad.