Kuu: märts 2019

Kuidas rajatakse e-poode tulevikus?

KUIDAS RAJATAKSE VEEBIPOODE TULEVIKUS?

Viimati väitsin, et tulevikus ei saa enam rääkida veebipoest, vaid kauplemine toimub igal pool digitaalselt. See tekitab muidugi küsimuse, kuidas veebipoode peaks arendama, mis saab veebipoe platvormidest ja kas tasub üldse veel oma veebipoodi rajada.

Rakendusliideste tähtsus suureneb ka e-poe platvormidel

Eelistatud veebipoe platvormid, nagu Magento, WooCommerce ja Shopify, peavad veel kaua vastu. Nende arendamisel muutub senisest olulisemaks hea rakendusliides, mis lubab ühendada mitmesugused kasutajaliidesed, SaaS-teenused ja taustsüsteemid üheks tervikuks. Rakendusliidesepõhisus ehk mõtteviis „API first” on kõigi tulevaste veebipoe platvormide eeldus. Konkurentsis püsimiseks on mõned platvormid oma arendustöös sammud selles suunas juba seadnud.

Lisandub ka täiesti uusi platvorme, mis on loodud toimima spetsiaalselt rakendusliideste kaudu. Platvormid ei ole enam niivõrd kliendi, kuivõrd kaupmehe jaoks. See tähendab, et platvormide roll hakkab seonduma rohkem taustategevusega, samas kui klientidele nähtavad kasutajaliidesed on senisest enam tehtud eritellimusel.

Veebipood tasub rajada platvormile juhul, kui platvormil on piisavalt valmis omadusi, mida ei ole vaja oma tarbeks kohandada, vaid mis sobivad sellisel kujul. Enne veebipoe rajamist kontrollige alati platvormi kohta järgmist.

  • Kõik veebipoe kasutusmallid saab teha rakendusliidese kutsetega välisest, brauseripõhisest rakendusest.
  • Kõik muude süsteemide jaoks vajalikud andmed saab rakendusliideste kaudu kasutusele võtta.
  • Platvormilt saab võtta kasutusele vaid need osad, mida vaja.
  • Platvormil on sellised omadused, mida teie äri vajab. Platvormi omaduste muutmine ei ole väga keeruline (alati pole see võimalikki). Veenduge, et omadus vastab sellisel kujul teie nõudmistele.
  • Platvormi omadusi on võimalik laiendada kohandatud mikroteenuste abil.
  • Platvormil on oskuslik tarnija, kes toetab teie äri.
veebipoe platvormide võrdlus

veebipoe platvormide võrdlus

Foto: veebipoe platvormide võrdlus Allikas: Magic Quadrant for Digital Commerce / Gartner (suvi 2018)

Eritellimus ei ole nii kallis, kui arvatakse

Eritellimuse kasuks võiks otsustada juhul, kui ükski platvorm ei too poele piisavalt lisaväärtust. Alati ei ole eritellimuse arenduskulud suuremad kui traditsiooniliste veebipoe platvormide omad. Tavapäraste platvormide arendamisel tekivad kulud sellest, et nende omadusi tuleb sageli oma vajadustega sobitada. Lõpptulemus ei pruugi sel juhul alati kõige parem olla. Lisaks on platvormidel palju liigseid omadusi, millest on pigem kahju kui kasu.

Eritellimuse omadused on läbi mõeldud ja platvorm luuakse algusest peale nii, et lõpptulemus oleks täpselt selline nagu vaja. Mõiste „eritellimus” viib pisut eksiteele, sest tänapäeval ei tähenda eritellimus arendustöö alustamist puhtalt lehelt. Uue süsteemi ehitamisel kasutatakse ära programmeerimise raamistikke ja teeke ning nende ökosüsteemide pakutavaid valmiskomponente, mille ühendamisel oma koodiga saadakse soovitud lõpptulemus.

Mikroteenuste arhitektuur all, kasutajapõhine kasutajaliides peal

Nii nagu platvormipoe korral, tuleks ka eritellimuse puhul alustada kliendipõhisest planeerimisest. Esmalt veendutakse kasutajaliidese prototüüpide ja testimise abil, et rõhutakse äri seisukohalt õigetele omadustele ning jõutakse õiges kohas õigete klientideni. Selle alusel kavandatakse rakendusliidesed, mis lubavad luua lõpliku kasutajaliidese.

Üks kindel moodus on kasutada mikroteenuste arhitektuuri. Iga mikroteenus vastutab ühe terviku eest ning pakub rakendusliidest teistele teenustele ja kasutajaliidestele. Üks mikroteenus võib vastutada näiteks ostukorvi funktsiooni eest ja teine tellimuse andmete edastamise eest ERP-süsteemi, kolmas jällegi laohalduse eest. Lisaks kohandatud mikroteenustele võib kasutada ka SaaS-teenustena saadaolevaid omadusi, nagu veebipoe otsifunktsioon või isikustatud sisu.

Ükskõik, kas valite platvormipõhise või üksikutest komponentidest üles ehitatud veebipoe, peamine on kanda hoolt rakendusliideste eest. Nii ei jää arendus pidama selle taha, et õige teave ei jõua kasutusele sel ajal ja selles kohas, kus seda vaja on.

Kas Confluence’il põhinevat siseveebi saab kasutada ka mobiilis?

Confluence mobiil

Meilt on palju kordi küsitud – ja viimasel ajal üha rohkem –, kas Confluence’i saab kohandada mobiilseadmele. Jah, Confluence’i saab kasutada mobiilseadmes, ja tegelikult ilma suuremate ponnistusteta. Confluence’il on olemas tugi mobiilides kasutamiseks. Kui selline variant ei meeldi, saab valida lisaosi, mis loovad mobiililehe otse Confluence’i salvestatud andmete alusel, ning vähemalt kaks rakendust, millest üks võtab ühendust teenusega otse ja teine väikese vahelüli kaudu.

Kõik need variandid nõuavad siiski teatud eelnevat määratlemist, kuidas Confluence’i mobiilseadmes kasutatakse. Ning see ei taga, et Confluence intraneti puhul oma eesmärgi täidaks, kui eesmärk ei ole läbi mõeldud. Mobiilseadmetes võib asju teha ja kuvada mitmel moel.

Seepärast tuleb küsida: Milliseid Confluence’i põhifunktsioone kasutada soovitakse? Mida soovitakse näha avakuval? Kuidas tuleks mobiiliversioonis navigeerida? Kui palju ja millist sisu näidata tahetakse? Mobiiliversioon võib olla struktuurilt ja sisult identne arvutiversiooniga, kuid selle saab luua ka täiesti erineval moel. See omakorda mõjutab seda, kuidas mobiiliversiooni tehniliselt teostada tasub.

Responsiivne leht, mobiilileht või rakendus?

Esimene variant on muuta toimiv siseveeb responsiivseks, misjuhul see kohandub automaatselt väiksema ekraaniga. Sellisel juhul on siseveebi sisu ja struktuur arvutiversiooniga identsed, sisu vaid sobitatakse väiksemale ekraanile.

Teine variant on teha mobiilile täiesti uus leht ehk eraldi mobiiliversioon. See luuakse arvutis kasutatavast siseveebist eraldi. Nii on võimalik paremini arvestada mobiilse kasutamise soove ja nõudmisi. Eraldi mobiiliversiooni loomine nõuab rohkem tööd kui responsiivne siseveeb, kuid pakub ka rohkem võimalusi.

Kolmas variant on teha siseveebist täielikult eraldiseisev rakendus. Ka rakenduse võib luua täiesti selle põhjal, millist intraneti mobiilselt kasutada soovitakse, ning rakendusena töötab siseveeb telefonis paindlikumalt. Rakenduse hea pool on lisaks see, et sisu saab kasutada ka offline-olekus ja sisselogimine jääb aktiivseks.

Võimalusi on – mida soovid sina?

Tehnilise teostuse planeerijana mõistan, et peaaegu kõik asjad on tänapäeval võimalikud, kuid samas pole kõike kasutada otstarbekas. Seepärast on kõige olulisem seada piirid, mida tehakse ja miks. Seejärel on võimalike variantide hulgast terviku tehnilist lahendust juba lihtsam valida.

Esimene küsimus on seega, kas Confluence’i saab kasutada mobiilselt, ja vastus on, et saab. Kohe pärast seda tuleb teine küsimus: millist töötamist mobiilne siseveeb teenindama peaks. Sellele küsimusele saate kindlasti vastuse, kui hakkate intraneti koos meie spetsialistidega kavandama.

Täiuslikkuseni lihvitud kasutajaliidesest üksi ei piisa

Kasutajakogemus

Tänapäeval, kui kliendikogemuse ja digiteerimise mõisted kõikjal kõneaineks on, pole üldjuhul vaja palju selgitada, kus neid vaja on. Muutunud tegevuskeskkond nõuab uudseid mõttemudeleid ja viise, kuidas arendada väärtusi tootvaid teenuseid.

Teenusedisain on äritegevuse kliendikeskne kasumlik arendamine. Selle eesmärk on hea ja katkematu kogemuse loomine kliendile. Hea kliendikogemus avaldab otsest mõju ka ettevõtte kassavoole. Kui aga kogemus on halb, peab arvestama, et klientide hääl ulatub kaugele, näiteks tagasiside andmiseks kasutatavates foorumites.

Kasutajaliides on sellise kogemuse osa, kuid see on vaid üks kliendi teel olev kohtumispunkt. Kliendikogemuse kujunemist mõjutab kõik teel kogetu.

Tihtipeale kipub ununema asjaolu, et teenusedisain ei tähenda vaid kasutajaliidese loomist. Kui kõik muu selle ümber tegemata ununeb, ei suuda ka viimase peale lihvitud kasutajaliides kliendikogemust päästa. Halvimal juhul tekitab kasutajaliides kasutajas sellised ootused, mida ülejäänud protsessi täita ei suuda.

Näiteid kliendikogemusest

Oletame, et meil hakkab hammas ootamatult valutama. Teeme Google’i lahti ja otsime lähimat hambaarsti. Üks veebiteenus tundub teistest parem, on selge ja kasutab lihtsat inimlikku keelt. Ja mis kõige parem, aja broneerimine käib lihtsalt. Veebiteenuse kasutajaliidese loomine on seega õnnestunud ja see osa protsessist viimase peale lihvitud.

Kuid juba mõne hetke pärast potsatab postkasti kinnitus, mis eelnevale veebiteenuse kasutajakogemusele sugugi ei vasta. Kujundus ja kõneviis on muutunud, kinnitusmeil kubiseb raviprotseduuride lühenditest ja muudest erialaterminitest. Taustsüsteemis on protseduurid nimetatud organisatsiooni oma keeles ja broneerimissüsteem otsib teksti automaatselt süsteemi põhjatutest soppidest, mida keegi ei ole kliendile mõistetavasse keelde pannud.

Ühtäkki hakkab klienditeenindusest saadud kogemus murenema. Aga ei tohiks. Kliendi hammas valutab ja ta soovib vaid ravi saada. Samalaadseid mõrasid tekitavad kliendikogemusse näiteks ka hambaarsti vastuvõtu blanketid, kasutatud juhendavad sildid ja hambaarsti tegevusviisid. Veebiteenus on loonud teatud ootused, mis pannakse proovile juba kohtumispunktis.

Seda juba küsiti minult!

Kasutajaliidese ja kohtumispunktide vahelist ebajärjekindlust esineb ka juhul, kui sisemisi protsesse ei ole tervikuna arvesse võetud. Kui korraga uuendatakse küll veebileht, taustsüsteemide terminoloogia, blankettide ja siltide sisu ning koolitatakse arste, siis kuidas on nende sisemiste süsteemidega? Kas kliendi üleminek protsessi ühest faasist teise on sujuv?

Näiteks kui veebilehel on broneerimise käigus juba kõik andmed ära küsitud, kuid kui klient arsti juurde jõuab, antakse talle vastuvõtus kätte tuttav paberblankett, kus jälle samu asju üle küsitakse. Väga häiriv moment hambavalust vaevatud ajusegmendile.

Või kui arvesse on lipsanud viga või hambaarstil käies on toimunud mingi eksitus, siis vaevalt võiks miski juba enne tigedat klienti sedavõrd vihastada, kui pendeldamine klienditeeninduse eri kanalite vahel. Või see, et klienditeenindus ei oska rakendada piisavalt vahendeid ärritunud kliendi teenindamiseks. Ja lõpuks imestab sisseostetud chat-teenuse klienditeenindaja, kui klient „karjub“, Caps Lock all, et MA JU KÄISIN TEIE JUURES EILE!

Klient ei hooli võrdluskõlblikkusest

Kõigele sellele lisab omapoolse nüansi asjaolu, et kliendid esitavad teenustele üha suuremaid nõudmisi. Klient võrdleb teenuse kasutuskogemust alati oma viimase parima kogemusega, olgu see võrdluskõlblik või mitte. See tähendab, et hambaarsti veebilehele jõudes võib kliendil meeles olla näiteks hiljutine kogemus mingi suure rahvusvahelise veebipoe kasutamisest. Või aja broneerimise blanketti täites tekib võrdluspilt nutitelefoni rakenduse lihtsa kasutatavusega.

Ega see nüüd päris aus ei ole, kui täiesti erinevatest lähtekohtadest ja reaalsustest loodud teenuseid omavahel võrreldakse. Kuid nii me kõik teeme. Klientide ootused on suured ja ettevõte peab püüdma neid igas kohtumispunktis täita. Seepärast vaatab teenusedisain alati tervikut ning keskendub just kohtumispunktidele ja nendevaheliste üleminekute lihvimisele.

Kui organisatsiooni muud osad ja taustaprotsessid kliendikeskselt kavandatud teenust toetavad ja täiendavad, saab kogu teenuse läbimise muuta ühtseks tervikuks, kus füüsiline ja digitaalne maailm on sujuvalt ühendatud.

Personialijuhtimise automatiseerimine algab töö põhjalikust mõistmisest

HR protsessid JIRA

Personalijuhtimises on palju rutiinseid ülesandeid, mille keegi peab lihtsalt ära tegema. Kahetsusväärselt tihti on need ülesanded korduvad, peaaegu ühesugused, igavad ja veel ka kohustuslikud. Väikeses mahus nüri rutiinset tööd kannatab veel ära, kuid kui see võtab juba olulise osa tööajast, tuleks tõsiselt mõtlema hakata.

Kas tööülesanne on tõesti selline, mille jaoks on vaja mind ja minu teadmisi? Kui ei, siis tuleks mõelda, kas võiks olla olemas keegi, kes on parem (kiirem, täpsem, vähem koormatud) ja selle töö ära teha võiks. Kui selline isik leidub, tuleb küsida, kas tööülesanne on loomult selline, et seda võib teha vaid inimene, või oleks seda võimalik automatiseerida.

Kui päevad mööduvad vorme täites

Ambientias juhitakse töid Atlassiani Jira abil ja ka personalijuhtimine kasutab oma töös Jirat. Jira abil toimub töölevärbamine, samuti täidetakse selle abil õppepuhkusele minemisega seotud personalijuhtimise ülesandeid. Varem kasutasime Jirasse tehtud põhju, mille alusel loodi meie süsteemis näiteks ülesanded uute töötajate tunnuste loomise, instrueerimiskava ning süsteemide kasutajaõiguste kohta.

Olles mõnda aega hambad ristis neid vorme käsitsi kopeerinud ning pealkirju ja sisu ükshaaval täitnud, näitasin oma tööd meie Jira spetsialistile. Ta hüüatas selle peale spontaanselt: „Hilla, sa kuritarvitad Jirat!“ Selliseid tuhandeid kordi korduvaid rutiinseid töid saab automatiseerida. Nüüd algas hoogne töö, tehnilised probleemid said seljatatud, süsteemid uuendatud ning Insighti abil saigi automatiseerimine võimalikuks. Juhhei! Tänu automatiseerimisele vabanes peatselt suurel määral tööaega!

Ega see nüüd nii lihtne ka ei olnud

Automatiseerimine sunnib mõtlema mustvalgelt: millised andmed on tegelikult vajalikud ja vältimatud? Kui palju infot on just parasjagu – mitte liiga palju ega ka liiga vähe? Kuidas tagada, et kogu teave oleks siiski vajaduse korral kättesaadav? Kas on mingeid andmeid, mida ei või kasutada? Milliseid erandeid üldreeglist esineb, kuidas teha võimalikult ühesuguse vormi abil praktikandile või allhankijale vajalikud tunnused? Kas neid on üldse vaja?

Loogika kaasamine põhjustas seega tõsiseid arutelusid nii ülesannete tasandil kui ka suuremas mõõtkavas: valikute kaudu saadav variantide arv on meeletu! Samas tuli pidevalt olla kriitiline. Kas me vaatame asja üldse õigest vaatenurgast?

Näiteks läbib iga uus töötaja teatud instrueerimised. Varem haldas neid instrueerimiste broneerija ehk mina, kuid olles asja põhjalikult vaaginud, jõudsime järeldusele, et on parem, kui töötaja ise kinnitab instrueerimise läbimist, sest nii saab ta ise kanda hoolt selle eest, et instrueerimisetapp on läbitud. Kinnitust ei nõuta ka instrueerijalt, vaid just selles osalenud isikult. Sellisel moel saab uus töötaja juba instrueerimise käigus praktilisel tasandil Jiraga tuttavaks. Seda on kindlasti tulevaste projektide puhul vaja ja on parem, kui kasutamist on juba pisut harjutatud.

Aegamööda võtavad automatiseerimise võimalused ilmet

Asju kriitilise pilguga analüüsides hakkasime märkama, kus on võimalik asjatut ja korduvat tööd vähendada. Selgus näiteks, et uue töötaja blanketil oli palju eraldi seisvaid ülesandeid, mis määrati alati samale tegijale ja mis puudutasid sama teemat. Need oli võimalik koondada. See tähendas, et 11 punktiga loendist sai lõpuks neljapunktiline, sest osaliselt kattuvad ja samu asju puudutavad punktid ühendati.

Praeguseks toimib Jiras tehtud ja automatiseeritud HRMi protsess alusplatvormina väga hästi. Mõningaid parandusi on küll tulnud teha ja ka automatiseerimist puudutavas mõtlemises oli esialgu hulgaliselt vigu. Kuid blankettide täitmisele kuluv aeg on varasemaga võrreldes vähenenud kümnendikule. Ja veelgi olulisem on see, et töö otstarbekus on suurenenud!

Kuigi ülesannete arv töötajate arvu kasvamisel suureneb, ei kulu neile siiski sama palju aega kui varem. Automatiseerimise kaudu on ka ülesannete eesmärk selgem ning nendega kaasnenud ajaloo ballast kaob: kõik asjatud instrueerimisteemad, vanad lingid, valed juhendid ja juhised on kadunud.

Miks me küll sellele juba varem ei mõelnud

Tagantjärele võib vaid mõelda, miks me seda juba varem ei teinud. Kui otsene automatiseerimise osa välja jätta, oleks ka pelgalt sellele eelnenud mustvalge poolt ja vastu mõtlemine meie tegemisi palju konkreetsemaks, selgemaks ja kiiremaks muutnud.

Mul on hulk tööülesandeid ning nendega seotud pidevas kiirustamises keskendusin liiga palju lõpptulemusele ja asjade valmis saamisele, selle asemel et mõelda tööprotsessi arendamisele. Samas on see täiesti mõistetav ja igati inimlik! Kuid ka nüri tööd tuleb põhjalikult mõista, et sellest jagu saada ning luua asemele sujuvad automatiseeritud lahendused!

73% klientides soovib küsimusele ise lahenduse leida

Jira iseteenindus

Klientide ootused klienditeenindusele on aastate jooksul üldjoones samaks jäänud. Kõige olulisemaks peetakse klienditeeninduse puhul selle kiirust. Mida kiiremini klient oma probleemile lahenduse või küsimusele vastuse leiab, seda rahulolevam ta on. Võib tunduda pisut üllatav, et kliendi seisukohast ei olegi tähtis, kas ta leiab lahendusi iseteenindusportaalis või klienditeenindajaga suheldes. Kiirus on esikohal suhtluskanalist olenemata.

Millised on iseteenindusportaalide probleemid?

Iseteenindusportaalides saab abi üldjuhul kiiresti ja igal ajal. Ometigi iseteenindust tihti suisa vihatakse, sest selliste portaalide mainet on rikkunud ebaõnnestunud lahendused.

Kujutage endale ette näiteks ristluslaeva, mis paistab kaugelt kaunis välja, kuid millel ei ole meeskonda, viitasid, lifte, söögikohti, ööklubisid, tax-free-kauplusi ja – mis kõige hullem – laevabändi. Selline võib olla ühe iseteenindusportaali teostus kõige hullemal juhul. Keskmist inimest ei huvita tegelikult karvavõrdki laev ise, vaid hoopis teenused, mida seal pakutakse.

Kuigi teoreetiliselt võiks iseteenindusportaalist vastuse saada üsna kiiresti, siis tegelikkuses ei saa mitmesuguste juhiste rägastikku takerdumisel kiirusest juttugi olla. Kui ka õige vastus lõpuks leida õnnestub, sisaldab see kümneid etappe, asjatut erialasõnavara ja tehnilisi termineid ning enamasti liiga palju teksti, mille sisu ei pruugi olla enam ajakohane. Sel hetkel saab kliendil lõpuks mõõt täis ja ta haarab telefoni järele. Ja klienditeenindaja on sunnitud suhtlema vihase kliendiga.

Präänikud ja muud suured lubadused

Mitme uuringu kohaselt sooviks keskmiselt kaks kolmest kliendist probleemile ennekõike ise lahenduse leida, kuigi samas suurele osale inimestest iseteenindus ei meeldi. Hea iseteenindusportaal peaks seega suutma välistada klienditeenindajatele mõeldud korduvad ja lihtsad küsimused, millele vastamine võtab asjatult aega klientide tõelise teenindamise arvelt. Kuid sellistele küsimustele vastamine ei lõpe enne, kui kliendid hakkavad kasutama iseteenindusportaale.

Klient võtab uue teeninduskanali omaks vaid juhul, kui selleks on mingi hea põhjus. Inimesed ei suuda innustuda uutest kanalitest vaid nende uudsuse tõttu. Kui tegemist on iseteenindusega, huvitab inimesi vaid see, kas nad saavad oma asjad aetud.

Klientide meelitamiseks iseteeninduse juurde tuleb neile anda präänikut ehk mingit konkreetset kasu, mida neile teenuse kasutajana lubatakse ja mille nad teenuse kasutajana saavad. Olgu selleks kiirus, lihtsus, soodsus või kasvõi mingi füüsiline stiimul, sest inimmasse saab tegelikkuses liigutada väikeste asjade ja žestide abil. Kuid see lubadus peab olema inimestele tähtis ja seda peab suutma täita.

Mida saaksid sina lubada oma klientidele, et nad pöörduks iseteeninduse poole, ning kuidas kannad hoolt selle eest, et see lubadus ka täidetakse?

 

Allikad ja soovituslik kirjandus

Iga kahe aasta tagant avaldatav ülevaatlik aruanne toekeskuste olukorrast ja arengust.

Jonathan Steimani seisukohad klienditeeninduse suundumuste kohta.

Sisutihe ja hästi mõistetav aruanne klienditeeninduse olukorrast.

Salesforce’i aruanne klienditeeninduse olukorrast.

Uus siseveeb? Jah, palun!

uus Altassian siseveeb

Käsi püsti, kellel on värskelt meeles, kuidas õhinaga kasutusele võetud teabepõhine siseveeb vähehaaval tuhandeid sisulehti sisaldavaks ja kõigile õudust tekitavaks dokumendirägastikuks muutus. Mitte seda, öeldi, mitte seda. Samal ajal raputas organisatsiooni sotsiaalmeedia kultuurile üleminek. Ülevalt allapoole liikuva teavitamise tõrjus kõrvale sotsiaalne ja interaktiivne siseveeb, mille abil oli võimalik teadmisi ja oskusi jagada organisatsioonist väljapoole.

Sotsiaalne siseveeb on endiselt elujõuline, kuid see ei suuda sellisel moel pakkuda lahendusi uutele töö hajutatusega seotud probleemidele. Töötajakogemuse parandamiseks ja töö organiseerimiseks on vaja uusi vahendeid. On vaja midagi, mis hõlmab siseveebi need omadused, mis on eri aegadel menukad olnud, sest põhimõtteliselt on nende järele endiselt nõudlust.

On vaja muuta vaid vormi ja mõned asjad lisada. On vaja süsteemi, mis suudaks teenindada nii andmepanga kui ka suhtlusplatvormina – samas ka kõike ühendava digitaalse töökeskkonnana. siseveeb on murrangu teel, ja seda positiivsel moel.

Siseveebi tegelik vajadus või alati on olnud ja teistel on?

Personalijuhtimissüsteemid, koolitusplatvormid, tooteteave, kliendihaldus ja projektijuhtimine. Kiirsuhtluse vahend ja organisatsioonisisene sotsiaalmeedia. Need on vaid mõned näited igapäevatöös kasutatavatest süsteemidest, mille arv on kasvanud ja kasvab kiiresti veelgi. Süsteemid on kiirendanud töö kulgu, kuid samas kindlasti suurendanud töö hajutatust.

Siseveeb puudutab tihti kogu organisatsiooni. Alati kui siseveebi arendatakse või uuendatakse, tuleks vaadata ka laiemat pilti töötamise ja teabeliikumise sujuvuse vaatevinklist.

Võib näiteks küsida:

  • Milliseid süsteeme me tegelikult kasutame ja kas nende kasutamiseks peab tegema toplet tööd?
  • Kas süsteem sobib tegelikult meie vajadustega või on see kasutusel vaid seepärast, et nii on alati olnud?
  • Kas informatsioon kuulub siseveebi  või personalijuhtimissüsteemi või hoopis partnerivõrku?
  • Kas tasub hallata mitut eraldi süsteemi või viia kõik ühele siseveebi platvormile?

Eri süsteemide lõimimine on võimalik ning seda on ka palju kasutatud, kuid selle elluviimine ja haldamine nõuab alati ressursse. Kas siseveeb võiks toimida tõhusamalt organisatsiooni digitaalse töölauana, mis koondaks viited andmete ja süsteemide juurde, ilma et need oleks ise siseveebi ehitatud?

Kui siseveeb on kasutajatele hästi planeeritud, on juba üle poole tööst tehtud.

Praktiline näide: mis on ühist kapitaalremondil ja siseveebi uuendamisel? Üllatavalt palju, ning mitte ainult hea planeerimine, kvaliteetne teostamise ja sujuv kasutuskogemus. Kodus veedetakse palju aega ning seepärast pööratakse remondi puhul erilist tähelepanu tõhusale ruumikasutusele, asjade leitavusele ja hubasusele. Ei ole ju ükskõik, kui külmiku uks korralikult lahti ei tule või kapiruumist jääb pool kasutamata, sest riiuliteni jõudmiseks tuleb ronida redelil.

Kui kavandatakse töötajate kasutuskogemust parandavat siseveebi, on sarnaselt koduga eesmärk see, et keskkond võimaldaks teha igapäevatööd paremini ja sujuvamalt. Probleemiks on siinkohal see, et kõigil organisatsiooni üksustel on intraneti suhtes erinevaid ootusi ning iga üksus otsib teavet eri moel ja eri kohtadest. Seepärast kerkib esile kasutajapõhine planeerimine.

Iga organisatsiooni vajadustest oleneb, kuidas luua navigeerimine, milliseid osinguviise on vaja, kui olulised on otseteed ja lemmikud või millisel moel kasutatakse märksõnu, teateid ja silte. Kõigil andmetel ja funktsioonidel peaks olema üks ja ainuke kodu, kust need on kergesti leitavad kasvõi eri viiteid kasutades. Aga kuidas?

Küsimusi tekib palju ja neid tuleb pidevalt juurde. Valmis vastuseid ei ole, kuid häid näiteid ja kogemuste kaudu kogunenud oskusi küll. Kõige olulisem küsimus ongi see, kuidas sinu organisatsioonis neile küsimustele vastataks?

Lisateavet sisevõrgu kohta:

Kuidas luua siseveeb, mis avatakse hommikul enne meilide vaatamist?

Kas Confluence’il põhinevat siseveebi saab kasutada mobiilseadmetes?

Töötajate kasutuskogemus ja ettevõttesisesed digiteenused – seminari järelmõtteid