Meklēšana SharePoint: kāpēc neatrod tieši to, kas vajadzīgs

Ievads

Dokuments ir augšupielādēts, bet komanda to joprojām neatrod. Tā ir tipiska situācija uzņēmumos, kur SharePoint vietnes aug ātrāk nekā to nosaukumi, struktūra un meklēšanas ieradumi. Meklēšana SharePoint sākas nevis ar vienu “pareizo” triku, bet ar skaidru vietņu arhitektūru, konsekventu satura izvietojumu un saprotamu navigāciju. Microsoft Q&A ieteikumos uzsvērts, ka vidi veido, balstoties uz uzņēmuma vajadzībām un intraneta struktūru, nevis pēc nejauša failu sadalījuma [1]. Tas nozīmē praktisku pieeju: nošķirt nodaļas un funkcijas vietņu kolekcijās, izvēlēties Team site vai Communication site pēc uzdevuma un glabāt kopīgo saturu vienā centrālā Hub site [1][2]. Tieši šī arhitektūra nosaka, cik ātri lietotājs nonāk līdz informācijai, ko viņš meklē. Raksta plāns balstās uz konsultanta ikdienā redzētām situācijām: kur meklēšana strādā labi, kur tā salūst pie struktūras kļūdām un kādi praktiski soļi palīdz ieviest kārtību bez liekas sarežģīšanas.

1. Kāpēc Meklēšana SharePoint sākas ar vietnes arhitektūru, nevis ar meklētāja pogām

Problēma parasti nav meklētāja laukā, bet tajā, ka saturs ir sadalīts vietnēs bez skaidra lietošanas principa. Ja dokumenti dzīvo dažādās vietnēs, kurām nosaukumi, mērķis un tiesības nav konsekventi, lietotājs ievada pareizu vaicājumu un tomēr nonāk pie nepareiza rezultātu kopuma. Tieši tāpēc Meklēšana SharePoint sākas ar arhitektūru: vispirms jāzina, kurai komandai, funkcijai vai procesam katra vietne kalpo, un tikai tad jādomā par meklēšanas paradumiem.

Cēlonis praksē ir ļoti vienkāršs. Ja organizācija veido vidi, balstoties uz savām vajadzībām un intraneta struktūru, meklēšana strādā pret sakārtotu modeli, nevis pret nejaušu vietņu klāstu [1]. Microsoft Q&A arī norāda, ka vietņu kolekcija atšķiras no apakšvietnes, tāpēc jau sākotnējā struktūrā jāzina, ko ar ko savieno un ko no kā nodala [1].

Praktiskais darba plāns šeit izskatās šādi:

1. Atver SharePoint admin center un izveido sarakstu ar galvenajām biznesa funkcijām: nodaļām, procesiem, projektiem, īpašumiem vai portfeļiem.
2. Pārskati, kur šis saturs šobrīd atrodas: vienā vietnē, vairākās vietnēs vai kā apakšvietnēs.
3. Pārbaudi, vai vietņu nosaukumos lietots viens un tas pats princips, nevis dažādi improvizēti nosaukumi.
4. Salīdzini, vai lietotāji meklē pēc satura, pēc projekta koda vai pēc nodaļas nosaukuma, un pielāgo vietnes struktūru tam, kā cilvēki domā.
5. Ja saturs ir kritisks konkrētai komandai, nodali to atsevišķā vietnē, nevis atstāj vienā lielā kopējā krātuvē.

Lai pārbaudītu, ka virziens strādā, atver vietni un veic meklēšanu ar trim biežāk lietotiem terminiem no ikdienas darba. Ja rezultāti atgriež pareizo satura grupu un lietotājam nav jāmin, kurā vietnē dokuments glabājas, arhitektūra ir saprotama. Ja meklēšanā visu laiku parādās nepareizi rezultāti, tad problēma nav vaicājumā, bet vietņu sadalījumā un satura loģikā. No konsultanta skatu punkta tieši šeit sākas arī labākais laiks sakārtot informācijas īpašumtiesības, jo vēlāk meklēšana tikai atspoguļo jau esošo jucekli. Nākamajā sadaļā šo pašu problēmu paskatīšu no lēmuma starp Team site un Communication site.

2. Kā izvēlēties starp Team site un Communication site, lai saturu vēlāk atrastu ātrāk

Tipiskā kļūda praksē ir vienkārša: jebkuram jaunam saturam tiek izveidota vietne pēc viena un tā paša parauga, lai gan satura lietojums ir atšķirīgs. Rezultātā darba faili, iekšējās instrukcijas un uzņēmuma paziņojumi nonāk vienā līmenī, bet lietotājs pēc tam meklē nevis vietnē, bet pa visu vidi. Meklēšana SharePoint šādā situācijā nestrādā slikti tehniski; tā vienkārši tiek piespiesta kompensēt nepareizu izvēli sākumā.

Šī kļūda rodas tāpēc, ka Team site un Communication site tiek uztverti kā vizuāla izvēle, nevis funkcionāls lēmums. Microsoft Q&A iesaka Team site izmantot sadarbībai un katrai nodaļai, jo tajos darbojas iebūvētās Microsoft 365 grupas [2]. Savukārt Communication site ir piemērots saturam, ko uzņēmums publicē plašākai auditorijai, un Q&A piemērs to saista ar centrālo Hub site un uzņēmuma kopīgo saturu [2].

Praktiski izvēles soļi:

• Ja komanda kopā rediģē dokumentus, pievieno uzdevumus un ikdienā strādā vienā darba telpā, izvēlies Team site.
• Ja saturs ir jāpublicē plašākam lietotāju lokam un galvenais uzdevums ir informācijas izplatīšana, izvēlies Communication site.
• Ja vietne pārstāv nodaļu, izmanto nodaļas principu, nevis projekta nejaušu nosaukumu.
• Ja vietne pārstāv īpašumu vai portfeli, standartizē nosaukumu, lai lietotāji pēc tam atpazīst struktūru arī meklēšanā [2].

Ja šo robežu neizlabo, sekas parādās meklēšanā ļoti ātri. Vienā vietnē lietotājs sastop rediģējamu darba saturu, citā — publicētu informāciju, bet meklēšana rāda abus kopā bez skaidras semantikas. Tad cilvēks sāk atvērt vairāk vietņu, nevis atrast vienu pareizo. Tāpēc izvēle starp Team site un Communication site nav dizaina nianses jautājums; tā ir informācijas atrašanas loģika. Kad šis pamats ir skaidrs, nākamais jautājums ir robeža starp vietņu kolekciju un apakšvietnēm.

3. Kad vietņu kolekcija kļūst par robežu meklēšanā un kā to pamanīt darbā

Salīdzinot abas pieejas, vietņu kolekcija un apakšvietne atšķiras ne tikai pēc struktūras, bet arī pēc tā, kā cilvēki vēlāk meklē saturu. Microsoft Q&A skaidri norāda, ka vietņu kolekcija ir citāda vienība nekā apakšvietne, un ka domain.sharepoint.com/sites/site1 nozīmē vietņu kolekciju, bet domain.sharepoint.com/site2 nozīmē apakšvietni [1]. Tas nozīmē, ka meklēšanas robeža praksē sākas tur, kur vairs nepietiek ar vienu loģisku vietnes nosaukumu un satura grupa kļūst pārāk atšķirīga, lai to turētu vienā hierarhijā.

Pirmais variants ir lietot vienu vietņu kolekciju ar apakšvietnēm. Šī pieeja der, ja saturs ir cieši saistīts, dzīvo vienā pārvaldības modelī un lietotājam ir jēga pārvietoties vienas struktūras ietvaros. Microsoft Q&A arī norāda, ka katrā vietņu kolekcijā var izveidot apakšvietnes, lai pievienotu vairāk satura [1]. Otrs variants ir atsevišķas vietņu kolekcijas dažādiem lietojumiem, piemēram, nodaļām un funkcijām [1]. Tas der, ja organizācijā ir skaidri nodalāmas biznesa zonas un tām nav vajadzīga viena kopīga dokumentu dzīvesvieta.

Darba vidē robežu pamani pēc šādām pazīmēm:

• lietotāji meklē vienu un to pašu terminu vairākās vietnēs un atrod dažādas dokumentu versijas;
• nodaļas sāk sūdzēties, ka redz pārāk daudz sveša satura;
• vienā vietnē pieaug tēmu un dokumentu dažādība, līdz tās nosaukums vairs nepasaka saturu;
• meklēšanā rezultāti ir pareizi tehniski, bet lietotājam tie joprojām šķiet nejauši, jo vietnes robeža nesakrīt ar darba procesu.

Šeit ieteikums ir izmantot noklusēto augšējā līmeņa vietņu kolekciju domain.sharepoint.com kā sākuma punktu un tikai pēc tam sadalīt vidi pa skaidriem biznesa lietojumiem [1]. Ja saturs pieder atsevišķai funkcijai, kurai jābūt izolētai, vietņu kolekcija kļūst par pareizo robežu. Ja saturs ir tikai papildu slānis esošam darbam, apakšvietne ir loģiskāka. Praktiski tas nozīmē, ka meklēšanas kvalitāti nosaka nevis vietņu skaits, bet tas, cik precīzi struktūra sakrīt ar organizācijas darbu. Nākamajā sadaļā šo pašu loģiku savienošu ar Hub site, jo tieši tur lietotājs bieži nonāk pirms dokumenta atrašanas.

4. Kā Hub site sakārto navigāciju, kopīgo saturu un lietotāju ceļu līdz dokumentam

Hub site visbiežāk kļūst par vietu, kur lietotājs sāk orientēties, pat ja galamērķis ir pavisam cita vietne. Microsoft Q&A apraksta centrālo Hub site kā Communication site, kas glabā visai uzņēmumam kopīgo saturu, kā arī nodrošina navigāciju uz nodaļu un īpašumu vietnēm [2]. Tieši tāpēc Hub site nav dekoratīva lapa; tas ir maršrutētājs starp saturu, kur meklēšana iegūst kontekstu no navigācijas, zīmolvedības un vienotas pieejas [2].

Praktiskā ieviešana notiek pa soļiem.

1. Izveido vai atver galveno Communication site, kas pilda Hub site lomu [2].
2. Augšējā navigācijā pievieno saites uz nodaļu vietnēm un īpašumu vietnēm, lai lietotājs ātri pārvietojas uz pareizo darba zonu [2].
3. Team sites izmanto katrai nodaļai, jo Microsoft Q&A tos iesaka nodaļu sadarbībai un darbam ar iebūvētajām Microsoft 365 grupām [2].
4. Ja uzņēmumā ir privātas nodaļas, piemēram, HR un Accounting, nodali tās no publiskākām sadaļām, piemēram, Marketing un Operations [2].
5. Īpašumu vai portfeļu vietnēm izmanto standartizētu nosaukumu, lai lietotājs no Hub site uzreiz atpazīst, kurš saturs pieder kurai vienībai [2].

Biežākā kļūme ir nesakārtota navigācija. Ja Hub site rāda saites, kuras neatbilst reālajām darba vietnēm, lietotājs atgriežas meklēšanā un sāk no jauna. Otrā kļūme ir pārlieku plašs Hub site saturs: ja tur saliek visu uzņēmuma informāciju bez skaidrām saitēm uz darba vietām, tas kļūst par garu ziņu plūsmu, nevis par ceļu līdz dokumentam. Trešā kļūme ir nekonsekventi nosaukumi, jo tie izjauc atpazīšanu brīdī, kad cilvēks pārslēdzas no Hub site uz konkrētu vietni. Praksē labi sakārtots Hub site samazina to brīžu skaitu, kad lietotājs min, kurā vietnē dokuments atrodas, un padara meklēšanas procesu paredzamāku. Ja arhitektūra, vietņu tipi un Hub site ir saskaņoti, nākamais solis jau ir detalizēta meklēšanas pārvaldība un satura dzīves cikls.

5. Meklēšana SharePoint ikdienā: ko darīt ar nodaļu vietnēm, lai meklēšana neizkliedējas

Ikdienā meklēšana izkliedējas tad, ja katrai nodaļai ir sava loģika, bet nav vienota lietošanas principa. Praksē tas nozīmē, ka lietotājs atceras dokumenta tēmu, bet nezina, kurai vietnei tā pieder. Meklēšana SharePoint šādā situācijā strādā tikai tad, ja nodaļu vietnes nav veidotas haotiski, bet pēc skaidra sadalījuma: ko ievieto nodaļas komandai, ko publicē visam uzņēmumam un ko tur tikai konkrēts darba process. Microsoft Q&A ieteikums būvēt vidi pēc savām vajadzībām un intraneta struktūras tieši šeit kļūst praktisks [1].

No konsultanta skatpunkta vispirms sakārto nevis vaicājumus, bet vietņu lomu. Ja HR, Finance vai Operations saturs dzīvo dažādās vietnēs bez vienota principa, lietotājs meklē vienu dokumentu vairākās vietās un rezultātos redz dublikātus vai līdzīgus failus. Tāpēc nodaļu vietnēm uzreiz nosaki, vai tās ir darba vietnes vai publicēšanas vietnes. Microsoft Q&A arī iesaka Team site izvēlēties vispārīgām vietnēm un izmantot Team sites katrai nodaļai [1][2].

Praktiskais solis ir vienkāršs:

• atver SharePoint start page un pārskati, kuras vietnes lietotāji redz visbiežāk;
• katrai nodaļai definē vienu primāro vietni, nevis vairākas paralēlas;
• Site contents sadaļā pārbaudi, vai dokumentu bibliotēkas nosaukumi atspoguļo darba saturu, nevis iekšējo žargonu;
• ja vietnē jau ir vairākas tēmas, sadali tās pēc funkcijas, nevis pēc konkrēta lietotāja ērtuma.

Rezultātā meklēšana kļūst paredzamāka: lietotājs sāk ar nodaļas vietni, atrod saturu pēc bibliotēkas un pēc tam pēc dokumenta nosaukuma vai satura. Ja šķiet, ka lietotāji tomēr maldās starp vietnēm, nākamais pārbaudes punkts ir nosaukumi un to konsekvence, jo tie tieši ietekmē, kur cilvēks vispār sāk meklēt.

6. Praktisks nosaukumu standarts vietnēm, bibliotēkām un īpašumu portfeļiem

Praksē vislabāk atmiņā paliek nevis abstrakta teorija, bet situācija, kur vienā uzņēmumā īpašumu vietnes bija nosauktas dažādos veidos: vienā vietā pēc objekta koda, citā pēc projekta, citā pēc personīgā ieraduma. Rezultāts bija paredzams — meklēšana rādīja līdzīgas vietnes, bet nepareizais nosaukums lika lietotājam izvēlēties pirmo, kas izskatās pazīstams. Microsoft Q&A ieteikums standartizēt īpašumu vietņu nosaukumus tieši šo problēmu novērš [2].

Nosaukumu standarts sākas nevis ar estētiku, bet ar orientieri. Vietnes nosaukumam jāpasaka, kam tā kalpo, bibliotēkas nosaukumam — kāda tipa saturs tur dzīvo, bet īpašumu portfeļiem — kāds ir vienots identifikators visā uzņēmumā. Ja šie trīs slāņi atšķiras pēc nejaušības principa, cilvēks meklēšanas rezultātos redz nepazīstamus vārdus un kavējas pie katra klikšķa. Tāpēc nosaukumu standartu ievies vienādi visā SharePoint vidē, nevis katrā nodaļā atsevišķi.

Praktiskā konfigurācija:

1. atver Settings uz vietnes sākumlapas un pārskati vietnes nosaukumu;
2. dodies uz Document Library → Settings → Library settings un salīdzini bibliotēkas nosaukumu ar saturu tajā;
3. katram īpašumam lieto vienu konsekventu nosaukuma formulu, kas atšķir objektu no projekta vai departamenta;
4. ja vietne paredzēta portfolio līmenim, pievieno skaidru marķieri, lai to nejauktu ar konkrēta objekta darba vietni.

Kad nosaukumi ir konsekventi, meklēšanas rezultātos samazinās interpretācijas darbs: lietotājs uzreiz redz, kurš ieraksts pieder vietnei, bibliotēkai vai portfelim. Tas pārliecinoši noder nākamajā solī — kad jānoskaidro, vai problēma ir dokumenta saturā, vietnes struktūrā vai īpašuma līmenī.

7. Kā pārbaudīt, vai saturs jāmeklē pēc satura, pēc vietnes vai pēc īpašuma

Šī ir tipiska ikdienas problēma: lietotājs saka, ka “meklēšana nestrādā”, bet patiesībā viņš nezina, ko tieši viņš meklē — dokumenta tekstu, vietnes nosaukumu vai īpašuma identifikatoru. Cēlonis parasti ir tas, ka saturs vienā sistēmas daļā dzīvo kā dokuments, citā kā vietnes vienums un vēl citur kā portfeļa objekts. Ja pārbaude notiek bez secības, cilvēks testē tikai sākuma frāzi meklēšanas laukā un secina nepareizi.

Risinājumu sāc ar trīs jautājumiem: ko lietotājs zina, kur saturs atrodas un kuram biznesa objektam tas pieder. Ja lietotājs zina tikai frāzi no dokumenta, pārbaudi meklēšanu pēc satura. Ja viņš zina nodaļu vai vietni, pārbaudi vietnes nosaukumu un navigāciju. Ja viņš zina īpašuma kodu, pārbaudi portfeļa nosaukumu un konsekventu marķējumu. Microsoft Q&A ieteikums izmantot Team sites nodaļām un standartizēt īpašumu vietņu nosaukumus palīdz šos trīs slāņus atdalīt [2].

Veic šādus soļus:

• SharePoint vietnē atver Search un ievadi dokumentā esošu frāzi, nevis faila nosaukumu;
• pēc tam ievadi vietnes nosaukumu vai tā daļu, lai pārbaudītu, vai lietotāji lieto pareizo orientieri;
• ja saturs pieder īpašumam, pārskati, vai nosaukumā ir vienots identifikators, nevis brīva teksta variants;
• salīdzini rezultātus starp nodaļas vietni un centrālo vietņu struktūru, lai redzētu, kur meklēšana kļūst neskaidra.

Pārbaude ir veiksmīga tad, ja tu vari paredzēt, kurš vaicājums rāda kuru rezultātu tipu. Ja meklēšana atgriež dokumentu pēc satura, vietni pēc nosaukuma un portfeli pēc identifikatora, struktūra ir saprotama. Ja šī atšķirība nav redzama, tad nākamā kļūda parasti slēpjas navigācijā un pārmērīgā struktūras dziļumā.

8. Biežākās kļūdas, ko konsultants redz: pārmērīgas apakšvietnes, neskaidra navigācija un nekonsekvents saturs

Tipiskākā kļūda ir mēģinājums visu salikt zem vienas vietnes ar daudzām apakšvietnēm, jo sākumā tas šķiet kārtīgi. Taču praksē tas rada pretēju efektu: navigācija kļūst dziļa, atšķirības starp vietni un apakšvietni lietotājiem nav skaidras, un meklēšana sāk atgriezt pārāk plašu vai pārāk šauru rezultātu kopu. Microsoft Q&A skaidri nošķir vietņu kolekciju no apakšvietnes, kā arī norāda, ka domain.sharepoint.com/sites/site1 nozīmē vietņu kolekciju, bet domain.sharepoint.com/site2 nozīmē apakšvietni [1].

Kāpēc tas rodas? Parasti tāpēc, ka organizācija vēlas “vienu vietu visam” un vienlaikus baidās no pārāk daudz vietnēm. Tāpēc tiek pievienotas apakšvietnes, kurām pēc tam nav vienotas navigācijas vai nosaukumu principa. Rezultāts ir saraksts ar vietnēm, kuras lietotājs atver pēc minējuma. Ja saturs ir publicēts dažādām auditorijām, Microsoft Q&A piemērs ar Hub site, Team sites un nodaļu sadalījumu parāda drošāku modeli: centrālā vietne kopīgai orientācijai, Team sites nodaļām un skaidrs lomu sadalījums [2].

Pareizā konfigurācija praksē izskatās šādi:

• izmanto vienu centrālo Hub site kā orientācijas punktu;
• nodaļu darbam veido atsevišķas Team sites, nevis jaunas apakšvietnes bez plāna;
• Site navigation sadaļā piesaisti tikai tās saites, kuras lietotājam reāli vajag;
• vienādi nosauc bibliotēkas un saistītos portfeļus, lai meklēšana nesāktu ar tulkošanu cilvēka galvā.

Ja šo neizlabo, lietotāji turpina meklēt saturu pēc atmiņas, nevis pēc struktūras. Kad struktūra ir sakārtota, Meklēšana SharePoint kļūst par pēdējo soli, nevis par vienīgo glābšanas mehānismu. Tālāk loģisks turpinājums ir pārbaudīt, kā šī struktūra uzturēta dokumentu bibliotēkās un versiju darbā.

Avoti

Kā KSJ var palīdzēt