SharePoint aģenti un praktiski veidi ātrākai dokumentu atrašanai

Ievads

SharePoint aģenti bieži tiek ieviesti tieši tajos uzņēmumos, kur dokumenti ir sadalīti pa projektiem, nodaļām un sistēmām, bet lietotāji joprojām meklē “to vienu failu” pēc atmiņas. IT vadītājam problēma nav tikai meklēšanas rezultāti. Problēma sākas brīdī, kad dokumentu dzīves cikls ir sarežģīts: faili nonāk SharePoint bibliotēkās, daļa no tiem tiek papildināta ar meta datiem, daļa tiek glabāta citur, bet lietotājiem vajadzīgs ātrs, vienots veids, kā atrast vajadzīgo dokumentu un saprast, kurš ir aktuālais variants. Tieši šeit nozīme ir aģentiem un dokumentu pārvaldības mehānismiem, kas ļauj sakārtot piekļuvi, veidlapas un darbību secību tā, lai meklēšana nav balstīta tikai uz faila nosaukumu. Ja vidi savieno ar SharePoint Online dokumentu pārvaldību no Dataverse, dokumentu pievienošana, apskate un dzēšana notiek caur Power Pages formām, bet piekļuve tiek kontrolēta ar tabulu atļaujām un dokumentu pārvaldības iestatījumiem [1]. Savukārt darbplūsmas pievieno procesuālu kārtību — tās nosaka, kā dokuments nonāk pārskatīšanā, apstiprināšanā vai publicēšanā [2].

Kā SharePoint aģenti saīsina ceļu līdz vajadzīgajam dokumentam

SharePoint aģenti saīsina ceļu līdz vajadzīgajam dokumentam tad, ja lietotājs sāk no jautājuma, nevis no mapes: “Kur ir aktuālā līguma versija?”, “Kas apstiprināja šo specifikāciju?” vai “Kurš fails ir gatavs nosūtīšanai klientam?”. Problēma parasti nav pašā failā, bet meklēšanas ceļā: bibliotēkā ir pārāk daudz apakšmapju, failu nosaukumi atkārtojas un lietotājs pārlūko struktūru manuāli. Rezultāts ir lēna orientēšanās, jo cilvēks meklē pēc vizuālas atmiņas, nevis pēc dokumenta nozīmes. SharePoint aģenti šo modeli maina ar sakārtotu dokumentu pārvaldību, kur dokuments ir atrodams pēc satura, statusa un atrašanās vietas, nevis pēc nejaušas mapes. Ja organizācijā ir ieslēgta dokumentu pārvaldība un dokumenti ir sasaistīti ar pareizo bibliotēku, aģents strādā ar skaidru avotu, nevis ar haotisku failu kopu [1].

Cēlonis, kāpēc meklēšana bieži kļūst smagnēja, ir tas, ka bibliotēka tiek būvēta glabāšanai, nevis atrašanai. Cilvēks izveido jaunas mapes katram projektam, bet neiedod dokumentiem vienotu marķējumu. Tad meklēšana atrod tikai to, kas ierakstīts faila nosaukumā. Praktiska pieeja sākas ar bibliotēkas pārbūvi: dokumenti tiek grupēti pēc biznesa jēgas, piemēram, “Aktīvi projekti”, “Apstiprināšanai”, “Arhīvs”, nevis tikai pēc nodaļas vai personas vārda. Tālāk jāizdara trīs tehniski soļi. Pirmkārt, katrai bibliotēkai jābūt skaidram mērķim. Otrkārt, jāpielāgo kolonnas tā, lai meklēšana balstās uz dokumenta stāvokli, nevis tikai nosaukumu. Treškārt, jāizskaidro lietotājiem, ka dokuments tiek atrasts no bibliotēkas loģikas, nevis no mapju koka. Ja dokumentu pārvaldība tiek organizēta no Dataverse, tai jābūt ieslēgtai vidē, un SharePoint integrācija jāiestata Power Platform administrēšanas centrā [1].

1. Atver dokumentu bibliotēku un pārskati mapju dziļumu: ja lietotājs, lai atrastu aktuālo failu, spiests klikšķināt vairākas reizes, bibliotēkas struktūra nav meklēšanai draudzīga.
2. Nomaini fokusu no mapēm uz skaidriem statusiem: “Draft”, “Review”, “Approved”, “Archived”.
3. Pārliecinies, ka bibliotēkai ir vienots nosaukumu standarts un ka dokumenti tiek glabāti vienā loģiskā vietā, nevis dublēti vairākās mapēs.
4. Ja izmanto SharePoint aģenti kopā ar dokumentu pārvaldību no Dataverse, konfigurē veidlapu un tabulas atļaujas tā, lai aģents redz dokumentu tajā pašā vietā, kur to meklē lietotājs [1].

Pārbaude ir vienkārša: atver vietni, ievadi vaicājumu pēc dokumenta tēmas vai statusa un skaties, vai lietotājam nav jāpārlūko visa bibliotēka. Ja atbildes ceļš ved uz pareizo dokumentu vietu, nevis uz nejaušu mapes atzaru, meklēšanas loģika jau strādā. Praktiskā nozīme ir tāda, ka komanda vairs nemet laiku uz struktūras minēšanu; viņi meklē pēc dokumenta uzdevuma, pārskatīšanas stadijas vai izmantošanas konteksta. Tālāk šī loģika kļūst vēl spēcīgāka, kad bibliotēkā ieliek metadatus, kas ļauj atšķirt saturu un statusu vienā skatā.

1. SharePoint aģenti: Sakārto bibliotēkas pēc meklēšanas loģikas, nevis tikai pēc mapēm

Tipiska kļūda praksē ir bibliotēkas veidošana kā failu noliktava, kur mapes seko organizācijas shēmai, nevis meklēšanas uzdevumam. Dokumenti tiek sadalīti pa nodaļām, projektiem un klientiem, bet lietotājam nekad nav skaidrs, kurā mapē atrodas pēdējā versija. Tieši tāpēc SharePoint aģenti sāk strādāt slikti: aģents apstrādā to pašu nekārtīgo karti, ko ir radījis cilvēks. Ja dokumentu vidē nav konsekventas struktūras, tad meklēšanas rezultātos parādās pārāk daudz līdzīgu failu, un cilvēks atkal sāk šķirot manuāli. Tas ir arī biežākais iemesls, kāpēc lietotāji uzticas kolēģa mutiskai norādei vairāk nekā pašai bibliotēkai. SharePoint dokumentu pārvaldība no Dataverse darbojas tikai ar SharePoint Online, tāpēc konfigurācija balstās uz tieši šo vidi, nevis uz lokālu SharePoint modeli [1].

Kāpēc šī kļūda rodas? Tāpēc, ka mapes šķiet intuitīvas. Pēc pirmā projekta tās dod ātru kārtības sajūtu, bet pēc dažiem mēnešiem mapju hierarhija kļūst par šķērsli. Cilvēks zina, ka dokuments pieder “finanšu procesam”, bet nezina, vai tas glabājas pēc gada, klienta vai uzdevuma. Pareizā konfigurācija sākas ar mērķtiecīgu bibliotēkas pārprojektēšanu. Atver konkrēto dokumentu bibliotēku un izvērtē, vai mapa atbild uz jautājumu “kur meklēt?” vai tikai “kur nolikt?”. Ja atbilde ir otrais variants, mapa nav meklēšanas mehānisms, tā ir glabāšanas mehānisms. Tāpēc galvenā sakārtošana notiek šādi:

• izveido bibliotēku pēc dokumentu veida vai procesa, nevis pēc cilvēkiem;
• ierobežo mapju dziļumu līdz minimumam, ko komanda tiešām lieto;
• izmanto vienotus failu nosaukumus, kuros nav jāieliek viss saturs;
• iedzīvini skatījumus, kas rāda dokumentus pēc statusa, projekta vai termiņa;
• pie bibliotēkas pievieno skaidru aprakstu, lai lietotājs saprot, ko tur meklēt.

Ja to neizlabo, seko vienāds efekts gandrīz katrā organizācijā: lietotāji turpina glabāt failus “savā mapē”, koplieto tos ārpus sistēmas vai sūta pa e-pastu jaunākās versijas. Tad SharePoint aģenti nespēj dot uzticamu atbildi, jo dokumentu avots pats ir nekonsekvents. Kad bibliotēka ir sakārtota pēc meklēšanas loģikas, nākamais solis ir dokumentu metadati: tie ļauj vienā un tajā pašā bibliotēkā atšķirt saturu, stāvokli un pielietojumu.

2. SharePoint aģenti: Lieto meta datus, lai meklēšana balstās uz saturu un statusu

Metadati ir atšķirība starp “es zinu, kurā mapē tas ir” un “es zinu, kāds tas ir dokuments”. Ja bibliotēkā ir tikai mapes un failu nosaukumi, meklēšana balstās uz cilvēka atmiņu. Ja bibliotēkai ir metadati, tad iespējams šķirot pēc statusa, projekta, dokumenta tipa, atbildīgā vai apstiprināšanas stadijas. Tieši šeit SharePoint aģenti kļūst praktiski: viņi atrod dokumentu nevis pēc nejaušas virsraksta sakritības, bet pēc konteksta, ko komanda ir ielikusi laukos. Power Pages dokumentu augšupielāde un rādīšana SharePoint darbojas tieši tīmekļa vietnes pamata veidlapā vai vairāku darbību veidlapā, kas nozīmē, ka dokumenta ievade un tā norādes ievēro vienu un to pašu modeļa loģiku [1].

Divas pieejas ir jāsalīdzina tieši. Pirmā pieeja ir faila nosaukuma meklēšana. Tā der ļoti mazās komandās, kur visi pazīst dokumentu autorus un statusu no galvas. Otrā pieeja ir metadatu balstīta meklēšana. Tā der brīdī, kad dokumentu apgrozība ir lielāka par vienas personas atmiņu un dokumentam ir vairāk nekā viens dzīves posms. Metadati īpaši noder, ja viens fails piedalās vairākos procesos: piemēram, līgums tiek gatavots, saskaņots un arhivēts. Tad lietotājs filtrē pēc statusa un atrod tieši to versiju, ko drīkst izmantot. Dokumentu pārvaldības no Dataverse gadījumā veidlapā jāiestata Atjaunināt esošu ierakstu, lai failu varētu augšupielādēt, jo, ja data setting ir Izveido jaunu ierakstu, dokuments netiek augšupielādēts [1].

Ieteikums ir vienkāršs: neuztver metadatus kā papildu administrēšanu. Uztver tos kā meklēšanas indeksu, ko cilvēki iedod sistēmai. Lai tas strādātu, jāizdara šādi:

• izveido dažus obligātos laukus, kas tieši palīdz atrast dokumentu;
• izmanto statusu kā vienu no galvenajiem filtriem;
• pievieno skatījumus, kuros statusa lauki ir redzami pirmajā ekrānā;
• māci komandai aizpildīt laukus dokumenta ievades brīdī, nevis pēc nedēļas;
• saisti metadatus ar biznesa procesu, lai tie nav dekorācija, bet meklēšanas pamats.

Praksē tas maina dokumentu atrašanu no “atveru piecas mapes un skatos nosaukumus” uz “filtrēju pēc statusa un uzreiz redzu pareizo failu”. Meklēšana kļūst mazāk atkarīga no personas atmiņas un vairāk no dokumenta apraksta. Kad metadati ir sakārtoti, nākamais līmenis ir tehniskā integrācija ar Dataverse, lai dokumentu pārvaldība, veidlapas un piekļuves režīmi strādā vienā plūsmā ar SharePoint aģenti.

3. SharePoint aģenti: Pieslēdz SharePoint aģenti pie dokumentu pārvaldības no Dataverse

Ja dokumentu pārvaldība ir jāiznes ārpus vienkāršas bibliotēkas un jāsaista ar biznesa vienumiem, tad integrācija ar Dataverse kļūst par pamatu. Šeit SharePoint aģenti nav atsevišķs “papildinājums”; tie izmanto to pašu dokumentu atrašanās vietu, to pašu veidlapu un to pašu atļauju modeli. Lai strādātu ar SharePoint dokumentu pārvaldības iespējām no Dataverse, vispirms jāieslēdz dokumentu pārvaldības funkcionalitāte vidē, pēc tam jāiestata SharePoint integrācija Power Platform administrēšanas centrā, jāiespējo dokumentu pārvaldība tabulām, jākonfigurē veidlapa un jāizveido atbilstoša tabulas atļauja [1].

Praktiskā instrukcija sākas ar vidi, nevis ar pašu bibliotēku. Pirmais solis ir pārbaudīt, vai dokumentu pārvaldība ir aktīva konkrētajā vidē. Otrais solis ir Power Platform administrēšanas centrā iestatīt SharePoint integrāciju, jo bez tā dokumenti nesaslēdzas ar biznesa ierakstiem. Trešais solis ir atvērt tabulu un ieslēgt dokumentu pārvaldību tieši tai entītijai, kurai pievieno veidlapu. Ceturtais solis ir pārskatīt veidlapu: tai jābūt konfigurētai tā, lai failu augšupielāde notiek ieraksta atjaunināšanas scenārijā, nevis jauna ieraksta scenārijā. Piektais solis ir izveidot atbilstošu tabulas atļauju, jo bez tās lietotājs neredzēs un nepievienos dokumentus tā, kā to paredz process [1].

Biežākā kļūme katrā solī ir skaidri paredzama. Ja vide nav sagatavota, integrācijas poga nepalīdz. Ja SharePoint integrāciju iestata bez globālā administratora tiesībām, to nepabeidz [1]. Ja lietotājs nepiekrīt Microsoft Entra izmaiņām, integrācijas iespējošana vai atspējošana netiek pabeigta un parādās kļūdas ziņojums [1]. Ja entītijai nav ieslēgta dokumentu pārvaldība, veidlapa neko neizdara. Ja datu iestatījums ir Izveido jaunu ierakstu, dokuments netiek augšupielādēts [1]. Lai piekļuve darbotos korekti, nepieciešami divi entītijas atļaujas ieraksti [1].

Tehniski tas nozīmē vienu: dokumenta atrašana un dokumenta ievietošana nonāk vienā kontrolētā procesā. Lietotājs atver ierakstu, piesaista dokumentu, un SharePoint aģenti strādā ar vienotu kontekstu, nevis ar nošķirtām kartēm. Tāda konfigurācija ir īpaši svarīga, ja dokumentu dzīves cikls ir saistīts ar biznesa objektu, piemēram, klientu, līgumu vai projektu. Nākamajā solī šo procesu papildina darbplūsmas un dokumentu apmaiņas noteikumi, lai dokumentu meklēšana nebeidzas tikai ar atrašanu, bet turpinās ar konsekventu apstrādi.

4. Ievieto apstiprināšanas darbplūsmas, lai atrod aktuālo versiju

Apstiprināšanas darbplūsma dod dokumentam skaidru ceļu no “melnraksts” līdz “aktuāla versija”. SharePoint vidē tas nozīmē, ka lietotājs vairs nemeklē svarīgāko failu pēc pēdējā saglabāšanas datuma vai autora vārda, bet seko procesam, kurā dokumentu pārskata un apstiprina noteiktas personas. Tieši šeit SharePoint aģenti strādā labi: tie atrod dokumentu pēc tā darba stāvokļa, nevis tikai pēc faila nosaukuma. Microsoft dokumentācija par darbplūsmām skaidro, ka darbplūsma ir automatizēta dokumentu vai vienumu kustība, kas saistīta ar biznesa procesu, un vietnes lietotāji to sāk no dokumenta vai vienuma SharePoint sarakstā vai bibliotēkā [2].

Ikdienā problēma parādās vienkārši: vienā bibliotēkā ir līguma projekts, otrā — komentēta versija, trešajā — failu kopija ar labojumiem no e-pasta. Ja nav apstiprināšanas soļa, cilvēks atver vairākus failus, lai saprastu, kurš ir pēdējais un kurš drīkst tikt nosūtīts tālāk. Apstiprināšanas darbplūsma šo ķēdi saliek secībā: dokuments tiek iesniegts pārskatīšanai, apstiprinātājs pieņem lēmumu, un īpašnieks redz statusu līdz brīdim, kad process beidzas un viņš saņem paziņojumu par pabeigšanu [2].

Praktiska konfigurācija SharePoint vietnē sākas bibliotēkas līmenī:

1. Atver dokumentu bibliotēku un bibliotēkas iestatījumos ieslēdz versiju kontroli.
2. Pievieno apstiprināšanas procesu dokumentu satura tipam vai izmanto iebūvēto Apstiprināšana darbplūsmu, kas bibliotēkās ir pieejama pēc noklusējuma [2].
3. Nosaki, kam pienākas pārskatīšana, un sakārto paziņojumu soli tā, lai īpašnieks saņem statusu pēc uzdevuma pabeigšanas [2].
4. Ja dokumenti tiek iesniegti no veidlapas, pārbaudi, ka veidlapa strādā ar esoša ieraksta atjaunināšanu, jo jauna ieraksta režīmā fails netiek augšupielādēts [1].

Rezultātā lietotājs redz vienu skaidru dokumenta ceļu, nevis vairākas konkurējošas versijas. SharePoint aģenti šādā vidē atrod tieši to failu, kuram statuss un apstiprinājums atbilst darba situācijai, tāpēc meklēšana kļūst drošāka un mazāk atkarīga no manuālas minēšanas. Nākamais solis ir ierobežot redzamību tā, lai katrs lietotājs atver tikai tos dokumentus, kas viņam tiešām nepieciešami.

5. Konfigurē piekļuvi, lai lietotājs redz tikai sev vajadzīgos dokumentus

Tipiska situācija uzņēmumā ir vienkārša: viena bibliotēka kalpo visai nodaļai, bet tajā ir līgumi, iekšējie projekti un sensitīvi pielikumi. Lietotājs atver SharePoint un redz par daudz, tāpēc sāk meklēt mapēs, filtrēt pēc nejaušiem nosaukumiem vai jautāt kolēģiem. Praktiska piekļuves konfigurācija šo situāciju pārtaisa par kontrolētu dokumentu plūsmu, kur redzamība seko lomai, nevis “koplietojuma paradumam”. SharePoint dokumentu pārvaldība no Dataverse balstās uz dokumentu pārvaldības iestatījumiem, tabulu atļaujām un dokumentu pārvaldības iespējošanu vidē, un šī funkcionalitāte darbojas tikai ar SharePoint Online [1].

Ko šeit izmaina praksē? Pirmkārt, dokumentu skatīšana, augšupielāde un dzēšana tiek piesaistīta konkrētām atļaujām, nevis visiem lietotājiem pēc noklusējuma. Microsoft dokumentācija norāda, ka piekļuve dokumentu skatīšanai un augšupielādei tiek veidota ar diviem entītijas atļauju ierakstiem, un lasīšana, pievienošana, rakstīšana vai dzēšana tiek piešķirta caur precīziem tiesību komplektiem [1]. Otrkārt, pakārtotajās atļaujās dokumenta atrašanās vieta jāizvēlas kā entītija, lai redzamība sekotu konkrētai dokumenta vietai, nevis visai sistēmai [1].

Rīcības secība SharePoint un Power Platform vidē izskatās šādi:

• Power Platform administrēšanas centrā ieslēdz SharePoint integrāciju.
• Pārbaudi, ka to izdara globālais administrators, jo tieši šī loma ir nepieciešama integrācijas iespējošanai [1].
• Ja integrācija tiek ieslēgta vai atspējota, ņem vērā, ka tiek atjaunināta Microsoft Entra vietnes lietojumprogramma un mainās SharePoint atļaujas [1].
• Tabulām ieslēdz dokumentu pārvaldību un izveido tabulas atļauju, kas piešķir tikai nepieciešamo lasīšanu, pievienošanu vai rakstīšanu [1].
• Veidlapā kā datu režīmu iestati Atjaunināt esošu ierakstu, jo Izveido jaunu ierakstu režīmā dokuments netiek augšupielādēts [1].

Rezultātā lietotājs redz tikai sev paredzēto dokumentu kopu, bet pārējais saturs paliek aiz piekļuves robežas. Tas samazina situācijas, kur dokumenti tiek atrasti nejauši vai pa e-pastu, nevis sistēmā. SharePoint aģenti šeit kļūst precīzāki, jo tiem nav jāfiltrē vizuāls troksnis no dokumentiem, kuri konkrētajam cilvēkam nav domāti. Nākamajā sadaļā šo pašu kontroli savienosim ar struktūru, lai dokumentu ievade notiktu bez haotiskas failu iemešanas vienā mapē.

6. Lieto apakšmapes un vietnes veidlapas strukturētai dokumentu ievadei

Problēma sākas brīdī, kad visi dokumenti nonāk vienā bibliotēkā bez skaidras ievades kārtības. Tad lietotājs nezina, vai failu glabāt klienta mapē, projekta apakšmapē vai vispār pievienot kā pielikumu ierakstam. Rezultāts ir dubulti dokumenti, nepareiza ievietošana un ilga meklēšana. SharePoint dokumentu pārvaldība no Power Pages dokumentāciju skatā ir tieši paredzēta tam, lai dokumentus augšupielādētu un rādītu lietotnē tieši tīmekļa vietnes pamata veidlapā vai vairāku darbību veidlapā, un vietnes lietotāji turpat var apskatīt, lejupielādēt, pievienot un dzēst dokumentus, kā arī izveidot apakšmapes savas dokumentu organizēšanai [1].

Cēlonis parasti ir nepareizs ievades punkts. Ja veidlapa ir piesaistīta jaunam ierakstam, dokuments netiek augšupielādēts; ja entītijai nav iespējota dokumentu pārvaldība, formai nav, kur failu piesaistīt; ja nav sakārtota mapju struktūra, lietotāji dokumentus novieto pēc instinkta. Tāpēc strukturēta ievade sākas ar veidlapas un bibliotēkas saskaņošanu, nevis ar “vēl vienas mapes” izveidi.

Praktiskais ieviešanas plāns ir šāds:

1. Power Platform vidē ieslēdz dokumentu pārvaldību attiecīgajai tabulai.
2. Veidlapā izvēlies režīmu Atjaunināt esošu ierakstu, lai failu augšupielāde notiktu pareizajā vietā [1].
3. Power Pages pamata veidlapā vai vairāku darbību veidlapā pieslēdz SharePoint dokumentu sadaļu, lai lietotājs redz augšupielādi tieši darba procesā [1].
4. Nosaki, ka apakšmapes tiek veidotas pēc projekta, klienta vai dokumenta statusa, nevis pēc nejaušas lietotāja izvēles [1].
5. Testē gan pievienošanu, gan dzēšanu, jo vietnes lietotājam abas darbības ir pieejamas, ja atļaujas to paredz [1].

Šādi ievadīti dokumenti tiek saglabāti loģiskā vietā jau no pirmā soļa. Tas nozīmē, ka SharePoint aģenti dokumentu atrod pēc ieraksta, mapes un statusa kombinācijas, nevis pēc brīža, kad kāds to nejauši pārsauca. Ja šī struktūra netiek ieviesta, nākamais risks ir vecas darbplūsmas, kas procesu sarežģī vēl vairāk, nevis sakārto.

7. Noņem vecās darbplūsmas un aizstāj tās ar mūsdienīgu procesu vadību SharePoint aģenti

Tipiska kļūda praksē ir turpināt balstīties uz vecām SharePoint darbplūsmām tikai tāpēc, ka tās “vēl darbojas”. Tas rada apjukumu: vieni procesi notiek dokumentā, citi — sarakstā, bet trešie vairs nav uzturami. Šāda vide ir īpaši slikta dokumentu meklēšanai, jo lietotājs nezina, vai aktuālais statuss slēpjas failā, e-pastā vai novecojušā darbplūsmas solī. Microsoft dokumentācija skaidri norāda, ka SharePoint 2010 darbplūsmas jaunajiem nomniekiem ir pārtrauktas kopš 2020. gada 1. augusta un no esošajiem nomniekiem noņemtas 2020. gada 1. novembrī, savukārt SharePoint 2013 darbplūsma ir novecojusi kopš 2023. gada aprīļa un no 2026. gada 2. aprīļa tiek pilnībā pensionēta [2].

Kāpēc šī problēma rodas? Tāpēc, ka darbplūsmas savulaik tika izmantotas, lai konsekventi pārvaldītu bieži izmantotus biznesa procesus, un dokumentu pārskatīšana, apstiprināšana un uzdevumu sadale tajās tiešām bija ērta [2]. Taču vecs process ar laiku sāk dzīvot pats savu dzīvi: tas sūta sistēmas e-pastus, kurus lietotājs vairs neatpazīst, rada statusus, kas nav sasaistīti ar pašreizējo dokumentu loģiku, un uztur paralēlu pārvaldību blakus jaunākām platformām. Darbplūsmas sistēmas ziņojumi nāk no no-reply@sharepointonline.com ar nosaukumu SharePoint Online, un tas vien jau rāda, ka process notiek fonā, nevis lietotājam saprotamā darba vietā [2].

Pareizā konfigurācija nozīmē pāriet uz mūsdienīgu, skaidri vadāmu procesu:

• Pārskati, kurās bibliotēkās vēl darbojas 2010. vai 2013. gada darbplūsmas.
• Izņem procesus, kas vairs netiek uzturēti, un aizstāj tos ar aktuālu apstiprināšanas loģiku bibliotēkā vai ar Power Platform balstītu procesu.
• Atstāj tikai vienu dokumenta ceļu: ievade, pārskatīšana, apstiprināšana, gala versija.
• Pārbaudi, vai lietotāji darbplūsmas statusu redz vienā vietā, nevis vairākos savstarpēji konfliktējošos kanālos [2].

Ja šo soli neizdara, dokumentu meklēšana kļūst lēnāka, jo cilvēki sāk uzticēties veciem statusiem un novecojušiem e-pastiem. Ja pāreja tiek veikta savlaicīgi, SharePoint aģenti strādā pretī vienotam, skaidram procesam un atrod tieši to dokumentu, kas atbilst pašreizējam darba stāvoklim. Tālāk loģiski ir apkopot, kā visi šie paņēmieni kopā veido vienu meklēšanas modeli, kur dokuments atrodas ātrāk un bez liekas minēšanas.

Avoti

Kā KSJ var palīdzēt