Oslo, 26. september 2021
Visma Business Cloud
Så har det skjedd, det som måtte komme. Visma Business (VBus) i skyen. Det lå for så vidt i kortene da WebExtensions kom i fjor. Men nå snakker vi altså om Visma Business med hud og hår som en skybasert løsning. Og det ser bra ut. Grensesnittet ser ved første øyekast annerledes ut enn vi er vant med, men når jeg ser etter så er det lett å kjenne seg igjen.
Og for dere som tenker at oppgradering av VBus er et mareritt med hensyn til nedetid, kostnad og hva som ikke virker etter oppgradering – så er Visma Business Cloud (VBC) løsningen. Torsdag var jeg med på «VBC Happy Hour» i regi av Visma. Jeg forbinder «Happy Hour» med tidlig fredag kveld i befalsmessa (eller for så vidt baren) på rekruttskolen i marinen, hvor det hang et skipsratt på veggen med åtte håndtak; ett av dem dekorert slik at det fungerte som pil. Så kl. 18:00 (eller kanskje var det 19:00) snurret barkeeperen på rattet. På veggen bak rattet var det skrevet opp priser med 50 øres intervall fra 0 til 3,50 og pila på rattet bestemte prisen på en halvliter pils den neste timen. Det høres usunt rimelig ut – og det var for så vidt hensikten (at det skulle være rimelig), men vi må huske på at dette var noen generasjoner siden med et annet prisnivå enn vi har i dag. Det var noen av legene som mente at ordningen var usunn også; de ble lyttet til og deretter nedstemt. Nok om det.
Visma har hatt et antall kunder i pilot på VBC i en periode. Det har blitt implementert rettelser og ny funksjonalitet løpende; i snitt én gang hver uke – i arbeidstiden uten nedetid. For alle som har oppdaget og varslet om feil i VBus; som må vente til ny versjon dukker opp – og så gjennomføre ny oppgradering – blir VBC en velsignelse. Jeg har meldt noen feil til Visma i løpet av de snart 20 årene jeg jobbet med VBus, sist i juni i år. Den feilen ble rettet i versjon 16.01, som kom i september. Det tok altså tre måneder og er noe av det raskeste jeg har opplevd av feilretting. Og slik må det gå når det slippes 4 – 6 versjoner i løpet av et år.
Ikke alt er på plass i VBC enda. Støtte for DME er planlagt neste år. Men det kommer. Det samme gjelder støtte for mange språk, jobbplanlegger, IA og maskinlæring.
Visma forteller at å flytte en kunde fra den VBus vi kjenner (som på stammespråket er en OnPrem-løsning – altså installert On Premises dvs. lokalt installert) til VBC typisk går på mindre enn en dag.
En liten utfordring er om man har laget mange vinduer i VBus. Disse kan ikke flyttes til VBC. På den andre siden er det gode standard vinduer å ta utgangspunkt i – på samme måte som det er i VBus, de ligger i en egen mappe. Og det er forbløffende enkelt å designe nye vinduer i VBC om man kan det i VBus. På demonstrasjonen torsdag viste Marko hvordan han meget raskt designet et vindu og hvor VBC har funksjonalitet som ikke finnes i VBus som jeg har savnet lenge – mulighet til å fryse de første kolonnene på venstre side slik vi er vant med fra Excel:
Og skalering er langt enklere i et web-grensesnitt enn i standard VBus. Her er det riktignok knapper for endring av fontstørrelse for en enkelt tabell, men enkel skalering av hele vinduet er det ikke. Noen har brukt skaleringen i Windows, men det fungerer ikke egentlig godt. I verste fall får du opp en dialogboks hvor valgknappene (slike som OK og Avbryt) ligger utenfor boksen og dermed ikke synlig. VBus har kort og godt ikke støtte for skjerm-skalering. I en nettleser kan du bruke [Ctrl]+ for å øke skriftstørrelsen eller [Ctrl]- for å redusere den, eventuelt [Ctrl]0 for å bruke standard. Prøv her og nå om du ikke har gjort det før.
En litt større utfordring er nok spesialløsninger. Det er ikke støtte for BIG i VBC og det står heller ikke på planen. De som har VBS må skrive om disse fordi VBC har et annet API enn VBus. De som har sett på det er henrykt. Spesielt interesserte kan se her. Personlig er jeg mest bekymret for alle de som har triggere og prosedyrer på SQL-server. Eller de som har en VBS-kode som skriver direkte til databasen. For det ligger i sakens natur at man ikke kan herje direkte med databasen i en skybasert løsning. Det er ikke vanskelig å tenke seg en trigger eller prosedyre som gjør noe som fungerer i en versjon av VBus, men som må skrives om for ikke å komme i konflikt med ny funksjonalitet som introduseres i en neste versjon. Og siden den enkelte kunde ikke velger når ny funksjonalitet blir introdusert i VBC – det skjer nærmest kontinuerlig, så blir det ingen mulighet for den enkelte kunde å kontrollere på forhånd om triggerne kommer i veien etter hvert som standardløsningen utvikles og settes drift.
Rent teknisk vil det antagelig være mulig. Hver kunde må ha sin egen VBys-database og antagelig egen instans på SQL-server. Så kunne man kanskje tenke to løp; kunder som ikke tukler med databasene og som får ny funksjonalitet introdusert uten nedetid eller oppgraderingskostnader. Og de om mener at tukling må til. Og som selv må ta stilling til når ny versjon skal introduseres. Med nedetid, oppgraderingskostnader og mulighet for feil. Det blir en fin måte å synliggjøre kostnadene med slike spesialløsninger; vi som lager dem forteller gjerne hvor lang tid det tar å lage dem, men ikke stort om hva følgekostnadene er: Hvordan de kan skape usikkerhet om de er i veien for ny funksjonalitet, om de må skrives om eller kompileres om (slik BIG og VBS) ved oppgradering, ekstra arbeid ved flytting fra et miljø til et annet (f.eks. ved bytte av ASP-leverandør), etc.
Samtidig er det ikke noe tvil om at mange trenger spesialløsninger fordi deres behov går utenfor det som standard VBus har støtte for. Noen spesialløsninger er nok slik at man kan løse det via det nye API’et, men mange vil ikke være mulig å løse uten direkte adgang til databasen. Så blir dette en gylden anledning til å stille seg spørsmålet: Må vi ha denne spesialløsningen eller kan vi leve med standard VBus og dermed kunne flyttet til VBC? De siste årene har jeg brukt mer enn halvparten at tiden til å lage spesialløsninger for kunder. Heretter skal jeg være mer forsiktig med å si «Dette kan vi løse med en trigger eller en prosedyre». Jeg kommer i alle fall til å legge til «Hvis du ønsker deg opp i skyen, er det ikke sikkert at vi skal tenke i retning av å manipulere direkte med databasen». De kundene vi har tuklet mest med, har en lang vei å gå før de er klare for take-off til VBC. Dem skal jeg hjelpe. Gjøre dem reiseklare. Når siste kunde har reist, kan jeg slukke lyset, lukke og låse. Og nyte mitt otium.
Og du kan jobbe i skyen med VBC.
Resten av min blogg kan du lese her: frode.antun.no/VBus/blogg