Sisuhaldustarkvara valiku juures on olulisem mõista äri vajadusi kui tehnoloogiat

Intervjuu ADM Interactive’i juhi Riho Pihelpuuga: Mis on veebilehtede sisuhaldussüsteemide osas viimastel aastatel muutunud? Millised on trendid? Kui tähtsat rolli mängib see, kuhu on koduleht majutatud? Miks ikkagi kasutajad ka parimatel ja suurimatel veebilehtedel ära eksivad? Kui tihti tuleks veebilehte uuendada?

 

Riho on digivaldkonnas aktiivselt tegev olnud üle 18 aasta ning selle ajaga on ta seda maastikku läbi ja lõhki tundma õppinud –  alustades koodi kirjutamisest kuni rahvusvaheliste digiprojektide juhtimiseni.

1. – 2. novembril 2018 Tallinnas toimunud konverentsil Best Internet, rääkis ADM’i juht Riho Pihelpuu sisuhaldustarkvarast, miks on see oluline ja kuidas seda valida. 

Mis on veebilehtede sisuhaldussüsteemide (content management system ehk CMS) osas viimastel aastatel muutunud? Millised on trendid?

Siin on mitu olulist trendi. Kõigepealt on toimunud spetsialiseerumine ja leitud on ka kindlaid nišše – näiteks Drupal CMSi rakendatakse rohkem keerulisemate ja mahukamate sisuhaldusnõuetega projektides. WordPress on samuti edasi arenenud – peamiselt kombinatsioonis, kus WordPress vastutab sisuhalduse eest ja erilahendused arendatakse eraldiseisvalt juurde. Ning viimasena – kõige lihtsamate veebide jaoks, kus piisab standardlahendustest, kasutatakse rohkem SaaS lahendusi.

Kuidas see kõik täpselt toimunud on, räägin pikemalt konverentsil Best Internet.

Eesti käib muu maailmaga üsna ühes taktis ja muutused on sarnased. Võiksin ehk välja tuua, et Joomla on kadumas ja uusi projekte selle peale praktiliselt enam ei tehta.

Mis on kõige olulisemad asjad, mis tuleb läbi mõelda, kui ettevõte on valimas CMSi?

Kõigepealt tuleks alustada kasutajate vajaduste ja enda äriprotsesside analüüsist ning mõelda, kus tahetakse selle lahendusega näiteks kolme aasta pärast olla. Seda peab tegema perspektiivitundega ja mõistma, et organisatsiooni veebikodu suurem ümbertegemine peaks toimuma keskmiselt iga 3-5 aasta järel. Kui see on paigas, siis saab aru, millist funktsionaalsust on tegelikult vaja ja milline CMS võiks vajadustele kõige paremini vastata. Kindlasti ei ole mõtet valimist alustada erinevate CMS-ide funktsionaalsuse kõrvutamisest nii, et võetakse kaks CMSi, pannakse kõik nende funktsionaalsused, viled ja kellad ritta ning vaadatakse, kummal rohkem on ja siis selle põhjal valitakse.

Milliseid inimesi on oluline sellesse valikuprotsessi kaasata?

Kaasama peaks kõiki neid, kes edaspidi CMSiga tööd teevad. Olenevalt organisatsiooni suurusest ja ülesehitusest on need inimesed näiteks sisuloome ja lahenduste arenduse või nende tellimise eest vastutavad, kuid ka süsteemiadministraatorid või teised, kes vastutavad IT-lahenduste eest. Kindlasti on oluline kaasata ka klienditeeninduse-, turundus- või tootejuht ehk see inimene, kes vastutab kliendikogemuse ja kasutajate vaate eest.

Kui oluline on CMSi valimisel eelarve ja mida selle planeerimisel arvestada?

Eelarve on alati oluline, kuid CMSi valimisel tuleb kulusid vaadata laiemalt kui ainult tarkvaraga seotult. Ka sisuloome, veebi haldamine ning integreerimine olemasoleva lahendusega on olulised aspektid. Alati tuleks arenduse hetkemaksumuse asemel vaadata pikemat perspektiivi ja kalkuleerida, milline on TCO (total cost of ownership) ehk kogukulu 3-5 aasta perspektiivis – arendus, juurutus, haldamine, uuendamine, sisu sisestamine, inframuudatused jne. Selle järgi saab arvutada ka potentsiaalse tasuvuse.

 

Eelarvet mõjutab ka see, kas kasutatakse mõnda olemasolevat template’i või tellitakse UX optimeerituna täpselt spetsiifilistele äri- või kliendinõuetele või saab kasutada standardseid lahendusi. Ja lõpuks mõjutab kulusid ka see, kui kiiresti on vaja lahendusega välja tulla.

Kui on vaja leida soodsam lahendus, siis soovitan valida standardse CMSi ja teha seda perspektiivitundega. Kasulik on arvestada, et üldiselt kipuvad võimalused ja vajadused ajapikku suurenema ning siis peaks saama CMSi alati täiendada.

Olenemata eelarve suurusest tuleks aga alati püüda aru saada, mis tüüpi projekti ja investeeringuga on tegu, st kas veebi halduse investeering teenib ennast tagasi otseselt või hoitakse tänu sellele rohkem raha mingite protsesside pealt kokku.

Mainisid enne kogukulu olulisust eelarve planeerimisel. Kuidas soovitad seda arvestada?

Kodulehe puhul tuleks eelarvestada kuni 3-5-aastase perioodi peale kokku analüüsi, algse arenduse, vajaliku IT-taristu, infrastruktuuri hoolduse, sisuloome, sisuhalduse, sisestuse ja toimetamise ning kodulehe uuendamisega seotud kulud.

Kui tähtsat rolli mängib see, kuhu on koduleht majutatud ehk hosting?

Kui spetsiifilised eripärad välja jätta, siis ei mängi hosting CMSi seisukohast otseselt suurt rolli. Natuke teisiti on  SaaS (Software as a Service) CMSidega, kus enamasti on platvorm juba hostinguga seotud, kuid üldiselt saab kõiki hostingu lahendusi, kas seadistada või valida vastavalt CMSi vajadustele.

Kas ja kuidas on CMS seotud SEOga (search engine optimization ehk kodulehe otsimootoritele optimeerimine)?

Muidugi peaks CMS toetama neid SEO-lahendusi, mida soovitakse kasutada, kuid üldiselt on kõikidel enamlevinud sisuhaldusplatvormidel vajalikud lahendused olemas. Kui need pole ka standardpaketis, siis saab üldjuhul lisada mooduleid või teha vajalikud seadistused CMSi konfigureerides.

Erinevaid sisuhaldusplatvorme on väga palju. Kas nende hulgas on üks, mida oma kogemuse põhjal soovitad kõige rohkem?

Sellist soovitust ei saa anda, sest kõik oleneb äri vajadustest ja võimalustest ja otstarbekusest.

Kui eelarve on paigas ja CMS valitud, siis mille põhjal otsustada, kas CMSiga peaks tegelema ettevõte ise või peaks selleks palkama teise osapoole?

Eks see sõltub jällegi majasisestest protsessidest, olemasolevast arendustiimist, otstarbekusest ja mahtudest.

Isetegemist tasub kaaluda siis, kui loodav veebikeskkond on äri üks tuumiklahendustest ning mahud piisavad selleks, et ära katta pidevalt 5-10 inimese töö.

Saab ka nii, et suuremad arendused ostetakse sisse ja hooldus ning täiendused tehakse ära majas sees. Outsourcing sobib näiteks siis, kui on kindlate etappidega arendustsükkel, kus oma tiimiga ei jõua asjad piisavalt kiiresti valmis, kuid samas ei oleks suuremale meeskonnale aastaringselt tööd.

Mis olukorras soovitad rätsepatööd CMS-i ostmise asemel?

Üldjuhul siis, kui on väga spetsiifilised funktsionaalsuse nõuded ning kui CMSi osa kogu veebilahenduses on marginaalse tähtsusega. See on aga iga kliendi puhul erinev, sest ärispetsiifika ja kliendi vajadused on erinevad.

Aga miks ikkagi kasutajad ka parimatel ja suurimatel veebilehtedel ära eksivad? Miks ei tehta veebilehte nii, et inimesed lihtsalt saavad kirjutada otsingusse, mida nad tahavad, ja siis see tuleb? Ühesõnaga – kas pole võimalik teha päriselt mugavat veebilehte?

Veebilehe loomisel on alati erinevad piirangud ja erinevad muutujad, millega peab arvestama. Nii näiteks ei saa osa asju teisiti või paremini lahendada, sest veebi arendamiseks mõeldud eelarve on liiga väike või siis pole parema lahenduse loomiseks lihtsalt aega. Ja siis on veel ka kasutajate soovid ja eelistused, mis on pigem erinevad kui ühesugused. Kõik need aspektid peavad omavahel koostööd tegema ja parima kasutajakogemuse looma.

Optimaalse kesktee leidmine võib mõnikord päris keeruline olla.

Ja muide, tihti ei olegi küsimus üldse veebilehe disainis või sisuhaldusplatvormis, vaid pigem selles, kuid kodulehel üritatakse peegeldada ettevõtte sisest struktuuri ja teenuseid üks ühele, mis aga tihti ei vasta kasutajate, ootustele ja arusaamadele antud toodete ja/või teenuste osas

Kui tihti tuleks veebilehte uuendada?

Rusikareeglina võib öelda, et veebilehte peaks uuendama iga 3-5 aasta tagant. Samas tuleb muidugi pidevalt teha väiksemaid arendusi, et veebileht käiks kaasas ettevõtte, turu ning klientide arenguga.

ADM Interactive’i tegevjuhi Riho Pihelpuu 1. novembril Eesti digitaalturunduse aastakonverentsil Best Internet 2018 esitluse teemal, millist CMS-i (sisuhaldusplatvormi) valida, leiad siit

WordPress, Drupal, Joomla, Voog? Luua rätsepatööna unikaalne platvorm? Millised on lihtsaimad veebi haldamise seisukohast (selleks et edaspidi saaks organisatsiooni seest keegi ise infot lisada mitte ei peaks iga kord arendaja poole pöörduma)? Erinevate variantide võrdlused.