Procesu automatizācija: no kura procesa sākt

Ievads

Procesu automatizācija uzņēmumos parasti sākas nevis ar tehnoloģiju, bet ar sāpīgu ikdienas situāciju: pieprasījumi ienāk e-pastā, dokumenti pazūd mapēs, apstiprinājumi ievelkas un neviens precīzi nezina, kurā solī process apstājas. Tieši šeit SharePoint un Power Automate dod praktisku ieguvumu: SharePoint kļūst par strukturētu datu un dokumentu vidi, bet Power Automate izpilda darbplūsmas starp lietotnēm un pakalpojumiem, lai sinhronizētu failus, nosūtītu paziņojumus un savāktu datus [1]. Konsultanta praksē svarīgākais nav “automatizēt visu”, bet izvēlēties procesu, kurš atkārtojas, ir skaidri aprakstāms un nesadalās desmit izņēmumos. Ja process balstās uz viena dokumenta statusu, viena saraksta ierakstu vai vienkāršu apstiprinājumu ķēdi, to var pārcelt uz Power Automate bez smagas sistēmas ieviešanas. Savukārt, ja procesā jau sāk dominēt sarežģīti noteikumi, daudz paralēlu zaru vai apjomīgas datu kopas, tieši tur parādās platformas robežas, kas jāņem vērā jau projektēšanas brīdī [2][3].

Kā noteikt, kurš process ir gatavs automatizācijai

Procesu automatizācija sākas ar vienu ļoti praktisku pārbaudi: vai process atkārtojas, vai tajā ir skaidrs sākumpunkts, un vai rezultāts vienmēr ir tāds pats. Ja viens un tas pats pieprasījums ik nedēļu nonāk pie dažādiem cilvēkiem, ja informācija tiek pārrakstīta no e-pasta uz Excel un pēc tam vēlreiz uz citu sistēmu, tad process jau šobrīd dzīvo starp vairākiem rīkiem, nevis vienā kontrolētā plūsmā. Power Automate tieši šādus atkārtotus uzdevumus arī paredz automatizēt un savienot darbplūsmas starp lietotnēm un pakalpojumiem [1].

Cēlonis, ko konsultanta darbā redzu visbiežāk, ir mēģinājums automatizēt izņēmumus, nevis rutīnu. Ja katram pieprasījumam vajadzīgs individuāls lēmums, procesam nav stabilas struktūras. Ja lēmuma kritēriji ir skaidri, bet cilvēks ikdienā tikai pārbauda, vai ir visi pielikumi, tad automatizācijai ir labs pamats. Praktiski tas nozīmē: vispirms uzzīmē procesa soļus, atzīmē, kur ienāk dati, kur notiek pārbaude, kur notiek apstiprinājums un kur tiek glabāts rezultāts.

Risinājuma soļi darbā ar klientu parasti ir šādi:

1. Nosauc vienu procesu, kas atkārtojas bez būtiskām variācijām.
2. Uzskaiti ievades avotus: e-pasts, forma, SharePoint saraksts, Teams ziņa vai cita sistēma.
3. Definē vienu skaidru iznākumu: statusa maiņa, paziņojums, uzdevuma piešķiršana vai dokumenta pārvietošana.
4. Atzīmē, kur šobrīd notiek manuāla kopēšana vai pārrakstīšana.
5. Pārbaudi, vai process nav atkarīgs no viena cilvēka pieredzes, ko nav iespējams aprakstīt noteikumos.

Ka process tiešām ir gatavs automatizācijai, redz, kad viens tests nostrādā bez cilvēka iejaukšanās: ienākošais notikums izveido ierakstu, tiek nosūtīts paziņojums, un statusa lauks tiek atjaunināts pēc konkrēta noteikuma. Tad vairs nav jautājuma “vai kāds to izdarīja?”, jo darbības ķēde ir redzama plūsmas vēsturē. Tālāk svarīgākais ir pareizi izvēlēties datu glabāšanas vietu, jo tieši tur sākas robežas starp SharePoint sarakstu un citām platformas iespējām.

Procesu automatizācija SharePoint vidē: kad saraksts ir pareizā datu bāze

Tipiska kļūda praksē ir mēģināt SharePoint sarakstā ielikt visu uzņēmuma procesu, arī tā daļu, kurai vajadzīga stingra relāciju loģika, sarežģītas piekļuves shēmas vai liels datu apjoms. Tas notiek tāpēc, ka saraksts šķiet ērts: to ātri izveido, tam viegli pievienot kolonnas, un Power Automate ar to strādā tieši. Taču ērtums nav tas pats, kas pareiza datu struktūra. SharePoint saraksti atbalsta līdz 15 kopējām sarakstu vienībām un līdz 35,000 rindām visos šajos 15 sarakstos, ja kopējais apjoms nepārsniedz 120,000 rindas, bet vaicājumi atgriež datus tikai no pirmajām 2,048 rindām [3].

Kāpēc šī kļūda rodas? Parasti tāpēc, ka risinājums tiek būvēts no dokumentu pārvaldības vajadzības, nevis no datu modeļa. SharePoint saraksts labi strādā kā vienkāršs procesu reģistrs: viens ieraksts, viens statuss, daži kontrolēti lauki, viens īpašnieks vai atbildīgais. Ja katram ierakstam jābūt saistītam ar daudziem bērnelementiem, sarežģītu aprēķinu ķēdi vai lielu transakciju loģiku, tad saraksts sāk kļūt par kompromisu, nevis par datu bāzi.

Pareizā konfigurācija praksē sākas ar skaidru kolonu sadalījumu un minimālu lieko informāciju. SharePoint modernajā vietnē atver Site contents → New → List, pēc tam izveido kolonnas tikai tiem datiem, ko plūsma patiešām lasa vai raksta. Statusam lieto atsevišķu Choice kolonnu, atbildīgajam — Person kolonnu, datumam — Date and Time kolonnu. Ja procesam vajadzīga dokumentu glabāšana, dokumentu ievieto library, bet statusus glabā sarakstā. Tas ļauj Power Automate darboties paredzami: tas nolasa ierakstu, maina statusu, nosūta paziņojumu un nerisina failu glabāšanas loģiku tajā pašā vietā.

Ja šo robežu neizlabo, sekas parādās ātri: filtrēšana kļūst neuzticama, saraksts sāk grūst zem pārāk daudz kolonnu un ierakstu, un lietotāji vairs nesaprot, kur ir “patiesais” statuss. Tad procesa automatizācija pārvēršas par papildus manuālu labošanas slāni. Nākamajā solī jēga ir nevis izveidot vienu universālu plūsmu, bet atlasīt reālos scenārijus, kas uzņēmumos atkārtojas visbiežāk.

9 praktiski scenāriji, ko uzņēmumos ievieš visbiežāk

Ikdienas darbā redzu divas pieejas. Pirmā ir “automatizējam visu uzreiz”: komanda grib vienu plūsmu, kas apkalpo pieteikumus, dokumentus, apstiprinājumus un atskaites. Otrā ir “automatizējam tikai vienu skaidru soli”: piemēram, ienākoša pieprasījuma reģistrāciju vai statusa maiņu pēc apstiprinājuma. Otrā pieeja parasti izdodas, jo tā balstās uz konkrētu notikumu, vienu datu avotu un vienu rezultātu. Power Automate jau pēc savas būtības savieno lietotnes un pakalpojumus, lai sinhronizētu failus, saņemtu paziņojumus un vāktu datus [1].

Uzņēmumos visbiežāk ievieš šādus scenārijus:

• pieteikuma saņemšana no formas un ieraksta izveide SharePoint sarakstā;
• apstiprinājuma paziņojums Teams vai e-pastā ar vienu atbildi no lēmuma pieņēmēja;
• dokumenta statusa maiņa pēc tam, kad nospiests apstiprināt vai noraidīt;
• faila pārvietošana starp mapēm pēc noteikta nosacījuma;
• atgādinājums, ja uzdevums nav pabeigts līdz konkrētam datumam;
• datu kopēšana starp SharePoint sarakstu un citu biznesa lietotni;
• jauna pieprasījuma piešķiršana konkrētam atbildīgajam pēc nodaļas vai tipa;
• reģistrācijas numura vai statusa atjaunošana pēc notikuma;
• vienkāršs auditēšanas ieraksts, kas fiksē, kurš un kad apstiprināja darbību.

Kad katra pieeja der? Ja process sākas ar vienu notikumu un tam ir viens kontrolēts rezultāts, tad pietiek ar vienkāršu cloud flow. Ja procesā ir daudz paralēlu nosacījumu, sarežģīti datu apjomi vai atkarības no lietotāja licences, jau sāk parādīties plūsmas dizaina un licencēšanas robežas. Power Automate Free licence ļauj veidot un palaist cloud flows bez koplietošanas un lokāli veidot un palaist desktop flows, bet Premium licence ļauj veidot, palaist un koplietot neierobežoti daudz cloud flows un veidot desktop flows [4].

Praktiskais ieteikums ir vienkāršs: vispirms izveido vienu procesu, kurā datus ievada tikai vienā vietā, un tikai tad pievieno nākamo soli. Tas ļauj redzēt, kur process tiešām sniedz labumu, un kur tas tikai pārvieto darbus no vienas darbinieka iesūtnes uz citu. No turienes loģiski pāriet uz vienu no biežākajiem ieviešanas modeļiem — apstiprināšanu ar dokumentu versijām un statusiem.

Apstiprināšanas process ar dokumentu versijām un statusiem

Apstiprināšanas process kļūst caurspīdīgs tikai tad, ja dokumentam ir viena glabāšanas vieta, versiju kontrole un statuss, kas precīzi ataino procesa posmu. Bez tā uzņēmumā sākas zināmā situācija: viens cilvēks redz “final_v3”, otrs strādā ar vecāku pielikumu, bet trešais apstiprina failu no e-pasta pielikuma. Praktiskā konfigurācija sākas SharePoint dokumentu bibliotēkā. Atver Library settings → Versioning settings un ieslēdz versiju kontroli, lai katra izmaiņa būtu redzama kā atsevišķa dokumenta versija. Power Automate plūsma pēc tam nolasa failu, pārbauda statusu un nosūta apstiprināšanu tikai tad, ja dokuments ir pareizajā stadijā [2].

Soļu instrukcija darbam ar šo modeli izskatās šādi:

1. Izveido dokumentu bibliotēku un pievieno kolonnu Status ar skaidrām vērtībām, piemēram, Draft, In review un Approved.
2. Ieslēdz Versioning settings, lai labojumi nekļūtu par neredzamu pārrakstīšanu.
3. Izveido Power Automate cloud flow ar trigeri When a file is created or modified (properties only).
4. Pievieno nosacījumu, kas pārbauda statusu un dokumenta tipu pirms apstiprināšanas.
5. Izmanto Start and wait for an approval, lai lēmums ienāk vienā kontrolētā solī.
6. Pēc rezultāta atjauno statusu SharePoint sarakstā vai dokumentu bibliotēkas kolonnā.
7. Pievieno paziņojumu Teams vai e-pastā, lai lietotājs redz nākamo darbību bez manuālas meklēšanas.

Biežākās kļūmes parādās katrā solī. Ja statusu neizolē atsevišķā kolonnā, plūsma nespēj droši saprast, vai dokuments jau ir pārskatīts. Ja nav ieslēgta versiju kontrole, nav iespējams korekti izsekot, kurš labojums izraisījis kļūdu. Ja trigeris reaģē uz jebkuru izmaiņu, plūsma sāk pati sevi atkārtoti aktivizēt. Power Automate flow definīcijai ir arī tehniskas robežas: darbību skaits ir 500, iekšējo ligzdojumu dziļums ir 8, un vienā plūsmā mainīgo skaits ir līdz 250 [2].

Rezultātā apstiprināšana vairs nenotiek pa e-pasta pavedienu, bet caur vienu ierakstu, vienu statusu un vienu versiju ķēdi. Tieši šeit procesi kļūst auditējami un atkārtojami, un nākamais jautājums ir par to, kuras licences un plūsmas robežas ļauj šo modeli uzturēt ilgtermiņā [4][5].

Procesu automatizācija pie iepirkumiem, atvaļinājumiem un iekšējiem pieteikumiem

Procesu automatizācija šādos scenārijos nozīmē vienu skaidru lietu: pieprasījums ienāk vienā vietā, tiek papildināts ar nepieciešamajiem datiem, iziet cauri apstiprināšanai un beidzas ar darbību, ko komanda redz un pārbauda. Iepirkumos tas parasti nozīmē, ka darbinieks iesniedz pirkuma vajadzību, vadītājs apstiprina budžetu, iepirkumu speciālists saņem pilnu informāciju un dokumenti netiek meklēti pa e-pastiem. Atvaļinājumos process sākas ar formu, nevis ar saraksti čatā: iesniegums nonāk vadītājam, pēc tam HR, un kalendārs tiek papildināts tikai tad, kad apstiprinājums ir pabeigts. Iekšējos pieteikumos, piemēram, piekļuves pieprasījumos vai iekārtu rezervācijās, tā pati loģika samazina manuālu pārrakstīšanu starp sistēmām, jo Power Automate veido automatizētas darbplūsmas starp lietotnēm un pakalpojumiem, lai sinhronizētu failus, saņemtu paziņojumus un vāktu datus [1].

Ikdienā šāds process sākas SharePoint list vai Microsoft List formā, kur katram pieteikumam ir statuss, atbildīgais un termiņš. Praktiskais darba scenārijs izskatās šādi:

1. SharePoint augšējā joslā atveriet New un izveidojiet pieteikuma ierakstu vai izmantojiet esošu formu.
2. Kolonnās definējiet laukus, ko lēmuma pieņēmējs tiešām izmanto: pieteikuma tips, summa, pamatojums, termiņš, pievienotie dokumenti.
3. Power Automate Designer izveidojiet plūsmu ar trigeri When an item is created vai atbilstošu izmaiņu trigeri.
4. Pievienojiet apstiprināšanas soli un nākamo darbību tikai pēc statusa maiņas.
5. Ja process skar vairākas komandas, ieviesiet atsevišķu statusu katram posmam, nevis vienu vispārīgu “In progress”.

Rezultātā biznesa lietotājs redz, kur pieteikums apstājas, bet administrators redz, kurš solis rada aizkavi. Tieši tāpēc šie procesi ir labs sākumpunkts: datu struktūra ir skaidra, atbildība ir redzama un katrs solis atstāj pēdu SharePoint sarakstā vai dokumentā. Nākamais jautājums ir tehniskāks: cik tālu šo loģiku drīkst stiept, pirms plūsma sāk traucēt pati sev.

Kad Power Automate sasniedz robežas: darbību skaits, paralēlie skrējieni un izpildes ilgums

Praksē robežas parasti atklājas tad, kad vienkāršs apstiprināšanas process pēkšņi pārvēršas par lielu izņēmumu ķēdi. Vienā projektā sākumā pietika ar pieteikuma izveidi, vienu apstiprinājumu un paziņojumu. Pēc tam parādījās papildsoļi: dokumentu saglabāšana, datu bagātināšana, papildu apstiprinājums, atgādinājums, dublēšanās pārbaude un arhivēšana. Tieši šeit Power Automate limits kļūst par dizaina daļu, nevis par tehnisku piezīmi. Microsoft dokumentācijā par automātisko, plānoto un tūlītējo plūsmu limitiem ir noteikts, ka flow definīcijā darbību skaita limits ir 500, iekšējo ligzdojumu dziļums ir 8, vienā plūsmā mainīgo skaits ir līdz 250 un vienas plūsmas darbības ilgums ir 30 days [2].

Ko konsultants dara, kad process tuvojas šiem griestiem:

• sadala vienu garu plūsmu divās vai vairākās plūsmās, lai atdalītu ievades apstrādi no gala darbībām;
• iznes atkārtoti izmantojamus soļus uz atsevišķu child flow vai atsevišķu automatizācijas posmu;
• samazina liekas Condition un Scope ligzdas, jo dziļums ātri kļūst grūti uzturams;
• pārbauda, vai Apply to each nav nevajadzīgi iekšā citā ciklā, jo katrs papildu līmenis palielina slodzi;
• novērtē, vai ilgstošs gaidīšanas solis nepārvēršas par procesu, kas stiepjas līdz robežai.

Rezultātā mainās pats dizaina princips: plūsma vairs nav jābūvē kā “viss vienā”, bet kā vairāku skaidru posmu kopums ar pārbaudāmiem starprezultātiem. Tas samazina pārsteigumus testēšanā un palīdz atšķirt biznesa loģiku no tehniskiem ierobežojumiem. Kad šī robeža ir saprotama, nākamais jautājums ir licences un tas, kurš tieši nes izmaksas un limitus konkrētam flow.

Licences un limiti, kas ietekmē scenārija dizainu

Licencēšana ietekmē plūsmas arhitektūru tikpat tieši kā tehniskie limiti. Ja scenārijs tiek būvēts bez skaidras izpratnes par licenci, rodas tipiska problēma: tas darbojas testā, bet produkcijā sāk trūkt tiesību pie premium konektoriem vai pazūd kapacitāte lielākai noslodzei. Microsoft dokumentācijā par Power Automate licenču veidiem norādīts, ka Premium licence ļauj lietotājiem veidot, palaist un koplietot neierobežoti daudz cloud flows, kā arī veidot desktop flows [4]. Tajā pašā avotā norādīts, ka Process licence, ja tā ir piešķirta cloud flow, piešķir augstākus action limitus un ļauj izmantot premium un custom connectors neatkarīgi no īpašnieka vai aktivizētāja licences [4].

Praktiskais dizains sākas ar jautājumu: kurš ir plūsmas īpašnieks, kurš to aktivizē un vai scenārijs izmanto premium konektorus. Pēc tam seko konfigurācijas soļi:

1. Power Automate portālā atveriet konkrēto flow un pārbaudiet owner informāciju.
2. Ja scenārijā ir premium konektori, piešķiriet atbilstošu licenci pašam flow vai tā īpašniekam.
3. Ja viena plūsma apstrādā lielu apjomu, izvērtējiet Process licenci ar darbību budžetu, kas Microsoft dokumentācijā noteikts kā 250,000 actions per day [4].
4. Ja viens process jāizmanto vairākām plūsmām, piešķiriet Process licenci flow grupai, lai koplietotu 250,000 actions dienā starp līdz 25 cloud flows [4].
5. Testējiet, vai konkrētais flow neizmanto funkcijas, kurām faktiski nepieciešama cita licence, nekā bija plānots sākumā.

Pārbaude notiek praktiski: palaidiet reālu pieteikumu, izsekojiet, vai izpilde notiek ar pareizo savienojumu un vai premium darbības nepārtrūkst pie pirmā gala punkta. Ja licence nav salāgota ar arhitektūru, sākas “strādā tikai manā kontā” situācija. Kad licence ir saskaņota ar dizainu, nākamā problēma ir uzticamība: plūsma nedrīkst būt trausla pat tad, ja dati ienāk netīri vai nevienmērīgi.

Kā izvairīties no trauslas automatizācijas un ko pārbaudīt pirms nodošanas biznesam

Trausla automatizācija parasti rodas no vienas kļūdas: plūsma tiek testēta ar ideāliem datiem, bet biznesā ienāk ieraksti ar tukšiem laukiem, dubultiem pielikumiem, garām piezīmēm vai negaidītu statusu. Tad tiek meklēts “labojums” pašā plūsmā, nevis datu kvalitātē un robežpārbaudēs. Praktiski tas nozīmē, ka pirms nodošanas biznesam jāiziet pārbaudes saraksts, kas sākas SharePoint pusē un beidzas Power Automate pusē. SharePoint list queries only return data from the first 2,048 rows of data [3], tāpēc filtrēšanas loģika jāveido tā, lai kritiskie ieraksti netiktu meklēti tikai pēc neierobežotas tabulas skenēšanas. Tāpat Microsoft Copilot Studio limitu materiālā norādīts, ka SharePoint lists support up to 15 total lists un līdz 35,000 rows across all 15 lists, as long as the total rows don’t exceed 120,000 rows [3].

Ko pārbaudīt pirms nodošanas:

• vai SharePoint sarakstā ir atsevišķas kolonnas statusam, īpašniekam un kļūdas ziņojumam;
• vai plūsmā ir Condition pārbaudes tukšiem laukiem pirms apstiprināšanas vai rakstīšanas atpakaļ SharePoint;
• vai Apply to each netiek palaists bez vajadzības uz lieliem masīviem, jo limits un uzvedība mainās atkarībā no konteksta [2];
• vai paziņojums biznesa lietotājam satur tikai to informāciju, kas nepieciešama lēmumam, nevis visu tehnisko detalizāciju;
• vai kļūdas ceļš nosūta ierakstu uz atsevišķu “Failed” statusu, nevis atstāj to bez skaidra rezultāta.

Ja šo posmu izlaiž, rodas situācija, kur procesā katrs nākamais izņēmums prasa manuālu iejaukšanos, un automatizācija pārvēršas par pusautomātisku darbu. Pareizi sagatavota plūsma, savukārt, noslēdzas ar skaidru statusu, pārbaudāmu datu pēdu un prognozējamu uzvedību. Tālāk loģiskais solis ir saprast, kā šie principi darbojas, ja procesā iesaista arī sarunu aģentus vai zināšanu avotus, ne tikai klasisku SharePoint un Power Automate savienojumu.

Avoti

Kā KSJ var palīdzēt