Es atrodu procesus, kas maksā laiku, izmēru tos naudā un uzbūvēju risinājumu, kas laiku atdod atpakaļ.
Pirmo reizi to izdarīju bez mākslīgā intelekta: pārbūvēju ražošanas piegādes ķēdi un nogriezu izmaksas uz pusi nepilnā pusgadā. Pēdējos gados tos pašus uzdevumus risinu ar MI un automatizācijas platformām. Grūtākā daļa abos gadījumos ir nevis tehnoloģija, bet cilvēki, kuriem jāsāk strādāt citādi.
25 gadiprocesu vadības un sistēmu ieviešanas pieredzes organizācijās
11 sistēmasizstrādātas patstāvīgi — no procesa analīzes līdz strādājošam rīkam
60–80 %laika ietaupījums lielākajā no tām, mērīts pa atsevišķiem darba posmiem
Pirms mākslīgā intelekta
Pirmais process, ko pārbūvēju
Mākslīgais intelekts nav tas, kas mani padarīja par procesu cilvēku. Šis ir gadījums, ar kuru tas sākās — desmit gadus pirms tam, kad MI vispār kļuva par darba rīku.
Piegādes ķēde · institucionālie iepirkumi
Ražošanas ķēde bez starpniekiem
Uzņēmums, kurā strādāju, skaitījās metālapstrādes un reklāmdrukas ražotājs, bet faktiski pats neko neražoja — ražošana gāja caur virkni citu uzņēmumu, kuri paši vairumā gadījumu bija starpnieki īstajiem ražotājiem.
Kāpēc tas kļuva steidzami
Nacionāla mēroga publiskās ēkas aprīkošanas projektā izmaksas projekta gaitā pieauga virs plānotā.
Katrs starpnieks ķēdē pievienoja savu uzcenojumu, un gala cena vairs neiekļāvās tāmē.
Reorganizācija uzņēmuma iekšienē nebija reāla — akcionāri no dažādām valstīm, un lēmumu ceļš pārāk garš situācijai, kas prasīja rīcību tagad.
Ko izdarīju
Izjaucu ķēdi un saliku procesu no jauna — katru ražošanas soli pie tā faktiskā izpildītāja, nevis pie starpnieka.
Speciālistus piesaistīju tieši, nevis caur uzņēmumiem.
Rezultāts turējās arī pēc projekta: uzņēmums kļuva konkurētspējīgs institucionālajos iepirkumos, kuros iepriekš cenas dēļ nespēja konkurēt.
Desmit gadus vēlāk tas pats process atkārtojās ar citu instrumentu. Nozares šaurais kakls ir maketēšana — maketētāju trūkst, pie viņiem ir rinda, un pasūtītājam nav nekādas ietekmes. Pēdējā gadījumā es trīs nedēļas nogaidīju uz ražotāju, līdz izrādījās, ka ražošana nav sākta, jo maketētājs netiek galā. Pēc tās atbildes MI aģents pēc darba uzdevuma apraksta sagatavoja visus maketus vektorgrafikā 15 minūtēs. Rinda pazuda, ne tikai darbs kļuva ātrāks.
Rezultāts
uz pusimetālapstrādes izmaksas pēc ķēdes pārbūves
< 6 mēn.no problēmas konstatēšanas līdz rezultātam — termiņu noteica projekts, ne plāns
2 ražotājiapsteigti Rīgas namu pārvaldnieka iepirkumā par adresācijas plāksnēm; abi ar pilnu pašu ražošanas ciklu
2 + 2divu gadu līgums, ko pasūtītājs pēc tam pagarināja divas reizes
Uzbūvētie risinājumi
Vienpadsmit sistēmas, kas darbojas
Katrai norādīts, kāda problēma risināta, ar ko tā uzbūvēta un kas ir izmērāmais ieguvums. Tur, kur ir „pirms" un „pēc" skaitlis, tas ir redzams; tur, kur tā nav, es to arī neizdomāju.
MI sistēma · publiskie iepirkumi
IepirkumuAI
Publisko iepirkumu dokumentācijas sagatavošana un pārbaude atbilstoši Publisko iepirkumu likumam un Sabiedrisko pakalpojumu sniedzēju iepirkumu likumam.
Problēma
Viens vidējas sarežģītības iepirkums prasa 40–64 darba stundas dokumentācijai un vērtēšanai.
Dokumenti top manuāli, kopējot no iepriekšējiem; pantu atsauces jāpārbauda katru reizi no jauna.
Kļūda dokumentos noved pie sūdzības Iepirkumu uzraudzības birojā un procedūras apturēšanas.
Kā tas uzbūvēts
Četri darba moduļi un 11 soļu darba kārtība, kas aptver pilnu iepirkuma ciklu; 40+ veidņu bibliotēka.
Normatīvie akti ir sistēmā kā avotu faili — pantu atsauces tiek ņemtas tikai no tiem, nevis no modeļa atmiņas.
Automātiski kvalitātes kontroles vārti: ja pārbaude neiztur, dokuments netiek nodots.
Trūkstošie lauki tiek marķēti un uzskaitīti cilvēka apstiprināšanai, nevis aizpildīti ar pieņēmumiem.
Darbojas iestādes pašas vidē vai uz AWS Bedrock / Google Vertex — dati nenonāk pie trešās puses.
Claudeaģentiskās darba kārtībasDOCX / XLSX ģenerēšanaQC skriptiNetlify
40–64 h → 8–12 h no tā tīrais speciālista darbs — 3–4 h
Viena pretendenta pārbaude reģistros
pirms
pēc
1–2 h → 10–20 min
Pa posmiem
Nolikums 16–24 h → 3–5 h Pielikumi 8–12 h → 1–2 h Vērtēšanas kritēriji 4–8 h → 1 h Vērtēšana un protokoli 12–20 h → 3–4 h
Reģistru pārbaudes modulis strādā ar 15+ avotiem: Uzņēmumu reģistrs, VID, Maksātnespējas reģistrs, Būvniecības informācijas sistēma, sankciju saraksti, ES BRIS, VIES, GLEIF un ārvalstu reģistri.
Darba paraugs · viens iepirkums no gala līdz galam
Lai parādītu, ko šī sistēma tiešām izdod, es uzrakstīju izdomātu iepirkuma uzdevumu — skolas energoefektivitātes būvdarbi, 1 240 000 EUR — un apzināti iestrādāju tajā piecas tipiskas kļūdas, kādas reāli sastopamas nolikumos. Tālāk ir tas, ko IepirkumuAI no tā uzbūvēja un ko tas pateica par pašu uzdevumu.
7dokumenti pilnā komplektā — nolikums ar pielikumu formām, tehniskā specifikācija, līguma projekts, tāme, pieredzes un speciālistu saraksti, darbu grafiks
50lappuses teksta, no kurām nolikums vien ir 30 — plus tāme Excel formātā ar trim lapām
Nolikums — 12 sadaļas un astoņas pielikumu formas, 30 lappusesTehniskā specifikācija — ēkas raksturojums un mērķis: 162 → 68 kWh/m² gadāLīguma projekts — 16 sadaļas; dzeltenie lauki ir tie, ko aizpilda cilvēks
Finanšu piedāvājums — 45 pozīcijas sešās sadaļās. Pretendents aizpilda tikai dzeltenās šūnas: darba algu, materiālus un mehānismus. Vienības cena, pozīcijas summa, sadaļu starpsummas, virsizdevumi, peļņa un PVN rēķinās paši, un tie ir aizsargāti pret pārrakstīšanu.
Ko sistēma pateica par uzdevumu
Nesamērīga apgrozījuma prasība
uzdevumā
Vidējais gada apgrozījums ne mazāks par 5 000 000 EUR — aptuveni četras paredzamās līgumcenas.
dokumentos
2 480 000 EUR, ar atsauci uz Publisko iepirkumu likuma 45. panta otro daļu: ne vairāk kā divas līgumcenas.
Pamatojums analīzē: PIL 45.(2); Eiropas Savienības Tiesas spriedums lietā C-218/11 Édukövízig un Hochtief. Riska līmenis — augsts: nesamērīgas finanšu prasības ir viens no biežākajiem pamatiem iesniegumam Iepirkumu uzraudzības birojā.
Pārējie četri tika atrasti tāpat: teritoriālā pieredzes prasība izslēgta (PIL 2., 41.(2); Senāta SKA-1315/2016), prasība pēc Latvijā izdotiem sertifikātiem aizstāta ar reģistra pārbaudi un ārvalstu kvalifikācijas atzīšanu (PIL 44.(1)), subjektīvais kritērijs „pretendenta reputācija" aizstāts ar izmērāmu kritēriju ar punktu skalu un formulu (PIL 51.(2) 3.p.), 18 dienu iesniegšanas termiņš pagarināts virs likuma minimuma (MK noteikumi Nr. 107; PIL 35.).
Sistēma pamanīja arī to, ko es neiestrādāju: nodokļu parādu pārbaude bija ielikta nepareizā nolikuma sadaļā, izmantotajā paraugnolikumā bija palikušas atsauces uz pantiem, kas grozīti vai izslēgti, izpildes termiņa vērtēšanas kritērijam trūka apakšējās robežas, un vienādu piedāvājumu šķiršanas kārtība nebija noteikta iepriekš. Visi četri ir izlaboti dokumentos un pamatoti analīzē.
Iepirkums, pasūtītājs, objekts un visi skaitļi ir izdomāti. Komplekts sagatavots demonstrācijai — reālu klientu dokumentus es publiski nerādu, arī anonimizētus.
MI rīks · dokumentu kontrole
Iepirkumu dokumentācijas MI pirmspārbaude
Viena augšupielāde — un visa projekta iepirkumu dokumentācija ir pārbaudīta pret pilnu kritēriju komplektu, ar norādi, kas jāizvērtē ekspertam un kas jāpārbauda reģistros.
Problēma
Projekta iepirkumu dokumenti nonāk vienā kaudzē; tie jāsašķiro pa iepirkumiem un katrs jāpārbauda pret garu kritēriju sarakstu.
Manuāli tas ir vienveidīgs darbs, kurā uzmanība paslīd garām tieši tur, kur kļūda maksā visdārgāk.
Riskus, kas redzami tikai skatoties uz visiem projekta iepirkumiem kopā — piemēram, iepirkuma sadalīšanu, lai nepārsniegtu slieksni — manuālā pārbaudē pa vienam neatrod nemaz.
Kā tas uzbūvēts
Lietotājs augšupielādē visa projekta dokumentus vienā ZIP failā vai kā vairākus Word failus; sistēma tos sagrupē pa iepirkumiem, cilvēks sadalījumu apstiprina.
Katrs iepirkums tiek pārbaudīts pret 157 jautājumu komplektu ar likumu izvilkumiem; pārbaude notiek vairākos līmeņos, kur nākamais sākas tikai tad, ja iepriekšējais ir izturēts.
Katra atbilde tiek šķirota trīs plūsmās: atbildēts automātiski, jāizvērtē ekspertam, jāpārbauda reģistros.
Agregators skatās uz visiem projekta iepirkumiem kopā un rēķina kopsummu pret Publisko iepirkumu likuma sliekšņiem — sadalīšanas riska konstatēšanai.
Rezultāts lejupielādējams kā Word ziņojums; dati tiek dzēsti, aizverot pārlūka cilni.
157jautājumi katram iepirkumam, ar likumu izvilkumiem
0 datunekas netiek saglabāts pēc sesijas beigām
Demonstrācija · 1 min 11 sNo ZIP augšupielādes līdz gatavam ziņojumam: automātiskā sagrupēšana, pārbaude pret 157 jautājumiem, agregatora sadalīšanas riska analīze un atbilžu šķirošana ekspertam.
MI rīks · līgumu dati
Līgumu datu izvilkšana
No līguma PDF izvelk puses, summas, termiņus un īpašos nosacījumus vienā ierakstā, ko var ielasīt jebkurā uzskaites sistēmā. Katrai vērtībai blakus ir citāts no dokumenta, un katru citātu pārbauda kods, nevis modelis.
Problēma
Līgumu dati uzskaites sistēmā tiek pārrakstīti ar roku — puses, reģistrācijas numuri, summas, termiņi, uzteikuma nosacījumi.
MI to paveic ātri, bet kļūda, kas izskatās pēc pareizas vērtības, ir sliktāka par tukšu lauku, jo to neviens nepamana.
Katrs, kurš pēc tam datus lieto, vēlreiz atver līgumu, lai pārliecinātos, no kurienes skaitlis nāk.
Kā tas uzbūvēts
Modelis aizpilda stingru shēmu: katram laukam vērtība, burtisks citāts, lappuse un pārliecība. Bez citāta vērtību ierakstīt nedrīkst, un rēķināt nedrīkst — kopsumma, kas līgumā nav nosaukta, paliek tukša ar piezīmi.
Tad deterministisks kods pārbauda katru lauku: vai citāts tiešām ir dokumentā, vai vērtības cipari ir citātā, vai datumi ir loģiskā secībā, vai reģistrācijas numurs ir tekstā.
Otrais viedoklis: regulārās izteiksmes neatkarīgi no modeļa atrod tekstā visas summas, datumus un numurus un salīdzina tos ar modeļa vērtībām — abos virzienos.
Katram līgumam statuss OK / PĀRSKATĪT / KĻŪDA un konkrēts saraksts, ko cilvēkam pārbaudīt. Uzskaites sistēmā automātiski nonāk tikai OK rindas.
Viens ieraksta formāts (23 kolonnas) visiem eksportiem: e-pasts, kopējā Excel tabula, Google Sheets, Notion, CSV un JSON. Personas kodi tiek maskēti jau izvilkšanas brīdī.
Izmaksu kontrole: tēriņu žurnāls, budžets un failu limits vienā palaišanā; klients var pārslēgties uz savu API atslēgu.
Claude APIstrukturēta izvadePythonStreamlitGoogle Sheets APINotion APISMTPpytest
Piemēros izmantoti divi izdomāti līgumi — telpu noma biznesa parkā un cirsmas pirkums no fiziskas personas; visas puses, numuri un summas ir izdomāti. Lietotne ir aiz paroles, jo tā darbojas uz manas API atslēgas; labprāt to parādu sarunā.
Izmērīts, ne apgalvots
Dažas sekundesdivi līgumi vienā palaišanā — no PDF līdz aizpildītai tabulai
0citātu, ko validācija neatrastu tekstā — reālās palaišanās ar diviem modeļiem
20 / 20„cietie" lauki — puses, numuri, summas, datumi, termiņi, PVN — Opus un Sonnet izvilkumos sakrīt viens pret vienu
23 laukino katra līguma vienā ierakstā: puses, summas, termiņi un īpašie nosacījumi, gatavi ielasīšanai uzskaites sistēmā
30+automātiskie testi bez API: katrs apzināti sabojātas vērtības veids dod gaidīto ziņojumu
Rezultāts · divi izdomāti līgumiViens skats no augšas uz leju: apstrādes žurnāls, izvilktie dati (viena rinda — viens līgums), pierādījumi un „ko pārbaudīt" katram līgumam, eksports uz Excel, CSV un JSON, cilnes e-pastam, kopējai Excel tabulai, Google Sheets un Notion — un e-pasts, ko saņem vadītājs. Abi līgumi pareizi saņem PĀRSKATĪT: tajos trūkst pielikumu, un nomas līgumā kopsumma nav nosaukta.
Deterministiska automatizācija · mežsaimniecība
Cirsmas vērtības aprēķins
No Meža valsts reģistra inventarizācijas izdrukas nosaka kailcirtei atbilstošos nogabalus, aprēķina cērtamo apjomu, sadala to pa sugām un sortimentiem un izrēķina maksimālo cirsmas iegādes summu — katram nogabalam pievienojot pamatojumu.
Problēma
Speciālists cirsmas vērtību rēķina ar roku: katram nogabalam valdošā suga, bonitāte, vecums un caurmērs jāsalīdzina ar normatīvajām tabulām, tad jāaprēķina apjoms un jāsadala pa sugām un sortimentiem.
Viena kļūda vienā nogabalā — nepareizi nolasīta formula vai slieksnis — maina visa objekta cenu, un to pamana tikai tad, ja kāds pārrēķina.
Normatīvās tabulas un cenas mainās, tāpēc aprēķinam jābūt tādam, ko speciālists var pielāgot pats, bez programmētāja.
Kā tas uzbūvēts
Aprēķinā nav valodas modeļa. Viss ir deterministisks kods: vienam PDF vienmēr viens rezultāts, pārbaudāms pret speciālista aprēķinu. Šeit MI būtu nevietā, tāpēc es to apzināti neizmantoju.
Claude vision ir tikai rezerves ceļš skenētiem PDF, un arī tur modelis tikai pārraksta lapas rindas. Tālāk iet tas pats parsētājs un tie paši noteikumi, un rezultāts nāk ar brīdinājumu un pārrakstīto tekstu blakus cilvēka pārbaudei.
Noteikumi ir dati, ne kods. Cirtes vecuma un caurmēra tabulas, sugu kodi, sortimentu iznākums, cenas un izmaksas ir konfigurācijas failā un cenu lapā, ko speciālists labo pats.
Pie katra nogabala ir pamatojums, piemēram, „Bērzs, bonitāte I: vecums 73 ≥ 71; caurmērs 33 ≥ 27 → atbilst". Speciālists drīkst lēmumu pārrakstīt, un apjoms un summa pārrēķinās.
Excel izvade ar dzīvām formulām piecās lapās: katru aprēķina soli var izsekot līdz šūnai.
Brīdinājumi, nevis klusa apstrāde: aizsargjoslas pazīme, neatpazīta suga, formula, kas nesummējas uz 10, platību kontrolsumma, kas nesakrīt ar izdruku.
Pythonpdfplumberdeterministiski noteikumiYAML konfigurācijaExcel ar formulāmClaude visionStreamlitpytest
Ekrānuzņēmumos ir sintētiska inventarizācijas izdruka ar izdomātiem datiem un noklusētajām demo cenām. Pieņemšanas testa objekts ir reāls, tāpēc tā kadastra numuru un aprēķināto cenu publiski nerādu. Lietotne ir aiz pieteikšanās.
Pārbaude
Sakrītar speciālista manuālo aprēķinu pieņemšanas testā uz reālas inventarizācijas izdrukas: tie paši seši kailcirtes nogabali, tas pats apjoms, tā pati maksimālā summa
17 centivienīgā atšķirība ieņēmumos — rīks starprezultātus nenoapaļo, cilvēks noapaļoja
0valodas modeļa lēmumu aprēķinā
50+automātiskie testi, tostarp sintētiski PDF ar sarežģītiem gadījumiem: divas zemes vienības vienā izdrukā, formula divās rindās, purvs, lauce un pļava
Nogabalu izvērtējums · sintētisks piemērsPamatojums pie katra nogabala. 4. nogabals ir purvs, tāpēc nav mežaudze; 8. nogabala valdošajai sugai blīgznai normatīvos nav noteikts cirtes vecums, tāpēc rīks nelemj pats, bet nodod to speciālistam.Gala atskaite · apjoms pa nogabaliem un sugāmExcel izvades pirmā lapa: cērtamais apjoms (krāja × platība) katram kailcirtes nogabalam, sadalījums pa sugu grupām ar ieņēmumiem un vidējo cenu, un rezultāts — ieņēmumi, izdevumi, peļņa un maksimālā iegādes summa. Rezultāts un sadalījums pa sugām ir formulas, kas atsaucas uz pārējām lapām: mainot cenu vai nogabala lēmumu, viss pārrēķinās.Sortimentu matrica · iznākums un cenasKatras sugu grupas apjoms sadalīts pa sortimentiem pēc iznākuma procentiem un reizināts ar cenu. Zilās šūnas — procentus un cenas — speciālists maina pats, un viss pārrēķinās; kontrolrinda pārbauda, ka grupu summa sakrīt ar ieņēmumiem. Attēlu var atvērt pilnā izmērā.
Operatīvā plānošana · darbs pēc grafika
Maču grafiks translāciju komandai
Izstrādāta reāla uzņēmuma problēmas risināšanai: operatīvi ieviest izmaiņas iepriekš sastādītos darbu grafikos, apziņot par tām iesaistītos darbiniekus un saskaņot tās ar katru no viņiem. Koordinators uzreiz redz, kurš izmaiņu vēl nav apstiprinājis un kam jāzvana.
Problēma
Sporta translāciju komandas koordinators nedēļas grafiku izsūta Excel failā. Kad mainās mača laiks vai vieta, jaunā versija nonāk ne pie visiem.
Sekas: viena mēneša laikā operatori divas reizes ieradās nepareizā vietā vai nepareizā laikā.
Faila dati ir nevienādi: datumi vairākos formātos, laiks gan „19:00”, gan „7:30 PM”, tas pats cilvēks gan „Jānis Bērziņš”, gan „J. Berzins”, ir arī dublikāti un tukšas vietas.
Kā tas uzbūvēts
Viena izmaiņu plūsma. Gan labojums ekrānā, gan atkārtots faila imports iet caur vienu funkciju: mača versija palielinās, izmaiņa ierakstās žurnālā, un katrs nozīmētais operators saņem ziņu „bija → ir”. Apstiprinājums ir derīgs tikai konkrētai versijai, tāpēc pēc jaunas izmaiņas visi atkal ir „Nav redzējis”.
Imports divos soļos: CSV vai XLSX → priekšskatījums ar problēmu tabulu → ieraksts tikai pēc koordinatora apstiprinājuma. Esošs mačs netiek dublēts; atšķirības kļūst par izmaiņām ar paziņojumu.
Normalizācija ir tīras, testētas funkcijas: datumi, laiki, lomas (CAM / Kamera / Camera) un vārdi bez garumzīmēm vai ar iniciāļiem. Nedrošu sakritību apstiprina cilvēks, un tā saglabājas kā aizstājvārds.
Konflikti: ja operators vienā dienā ir divos mačos ar mazāk nekā 4 h starpību, imports un saglabāšana apstājas, līdz koordinators to apzināti pieņem vai noņem cilvēku no mača.
Operatoram nav jāpieslēdzas: personīga saite telefonā vai Telegram bots ar pogu „Esmu redzējis”, un kalendāra abonements, kurā neapstiprinātie mači ir ar atzīmi [JĀAPSTIPRINA].
Eskalācija bez cilvēka: pēc 2 h bez apstiprinājuma ziņa atkārtojas; mazāk nekā 6 h pirms sākuma — steidzams atgādinājums un sarkans „Jāzvana” koordinatora skatā; 18:00 — rītdienas kopsavilkums.
Sistēmā nav valodas modeļa. Problēma bija informācijas plūsma, nevis teksts, ko ģenerēt. MI bija izstrādes rīks: uzbūvēju ar Claude Code pa fāzēm, katru fāzi noslēdzot ar testiem.
No viena koda četri darbināšanas veidi: Node serveris, Docker ar automātisku HTTPS, Windows autostarts un Windows programma (Tauri), kuras instalators neprasa administratora tiesības.
Pielāgojama jebkurai nozarei
Sistēmas pamatā nav sports, bet vispārīga loģika: darbinieks, uzdevums, laiks, vieta, loma, izmaiņas versija un apstiprinājums.
Tā der visur, kur darbs notiek pēc iepriekš sastādīta grafika un izmaiņas jānodod konkrētiem cilvēkiem: maiņu darbā ražošanā un loģistikā, apsardzē, veselības un sociālajā aprūpē, pasākumu un būvdarbu brigādēs, servisa un uzkopšanas komandās.
Pielāgošana nozīmē nomainīt lomas, nosaukumus un atgādinājumu termiņus; izmaiņu plūsma, apstiprināšana un eskalācija paliek tās pašas.
Uzņēmumu nenosaucu. Ekrānuzņēmumos ir demo dati — izdomāti operatori un mači 2026. gada martā, tāpēc pie izmaiņas redzams „Mazāk nekā 24 h!”. Labprāt sistēmu parādu sarunā.
Pārbaude
56 → 53rindas koordinatora failā → nozīmes grafikā: tukšās rindas un dublikāts izmesti, „J. Berzins” atpazīts kā Jānis Bērziņš
2 / 2konflikti parauga failā atrasti un apturēti pirms ieraksta datubāzē
2 dienasno pirmā koda līdz Windows programmai ar instalatoru
Koordinatora skats · pēc laika maiņas 19:00 → 19:30Augšā — konflikti ar pogu „Noņemt no šī mača” un neapstiprinātās izmaiņas. Anna izmaiņu apstiprināja savā telefonā, pārējie četri vēl „Nav redzējis”, un pie katra ir poga „Atgādināt”. Konflikts redzams arī pie katra cilvēka.
Imports · problēmas pirms ierakstaKoordinatora fails pirms ieraksta: abi konflikti ir kļūdas un bloķē importu, izmaiņa esošam mačam aizies kā paziņojums, bet tukšās vietas un dublikāts ir paskaidroti ar rindu numuriem.Operatora telefonāPersonīga saite bez pieslēgšanās: kas mainījies, kā bija un kā ir, un viena poga apstiprināšanai.
Projektu vadība · ES fondu projekts
ES fondu projekta vadības rīks
Izstrādāts nodibinājumam, kas īsteno SIF līdzfinansētu (ESF+) sociālās rehabilitācijas projektu personām ar demenci agrīnajā stadijā. Viena sistēma visam projekta ciklam: plāns un termiņi, novirzes un līguma grozījumi, izdevumi, dalībnieku un vizīšu uzskaite, rādītāji un starpposma pārskati SIF.
Problēma
Līgumā ir 18 termiņu noteikumi, daudzi no tiem darbdienās: atbilde uz SIF precizējumiem 5 darbdienās, grozījumu pieprasījums 20 darbdienas pirms izmaiņu spēkā stāšanās. Nokavējums vai nesasniegts rādītājs var samazināt finansējumu.
Apstiprinātais pieteikuma plāns un faktiskais darba plāns atšķiras jau pirms pakalpojuma sākuma. Katra atšķirība jāreģistrē, jāizvērtē un, ja vajag, jāsaskaņo ar SIF kā līguma grozījums.
Ik trīs mēnešus jāiesniedz pārskats ar pierādījumiem: izdevumi, dokumenti, vizītes, rādītāji. Bez vienas sistēmas tas tiek vākts no Excel tabulām, e-pastiem un mapēm.
Dalībnieku personas un veselības dati prasa šauru piekļuvi un audita pēdas, bet organizācijai nav Microsoft 365 vai citas korporatīvās vides.
Kā tas uzbūvēts
Termiņi ir dati, ne kods. Līguma noteikumi kļūst par termiņu notikumiem ar ārējo un iekšējo termiņu, rēķinot pēc Latvijas darbdienu kalendāra ar svētku un pārceltajām dienām. Katru darbdienu rītā atbildīgās lomas saņem e-pastu ar tuvākajiem un nokavētajiem termiņiem.
Bāzes līnija pret darba plānu. Apstiprinātā plāna versija ir nemaināma. Atšķirība kļūst par novirzi ar statusu plūsmu līdz SIF lēmumam, un jauna bāzes līnija rodas tikai no piemērotas grozījumu pakotnes ar pievienotu dokumentu.
Laika grafiks (Ganta diagramma) ar atkarībām, kritisko ceļu un resursu slodzi. Ja darba plāns pārkāpj atkarību, rīks brīdina, bet datumus nemaina pats — lēmumu pieņem cilvēks.
Starpposma pārskata pakotne katram periodam: pilnīguma pārbaude ar trūkumu sarakstu, DOCX pārskats un XLSX pielikumi vienā ZIP. Teksta melnrakstus raksta Claude, bet tikai no anonimizēta kopsavilkuma — bez vārdiem un veselības datiem.
Piekļuve 11 lomām tiek pārbaudīta servera pusē. Dalībnieku personas dati ir atsevišķā tabulā, citur redzams tikai kods (R-01), un visas izmaiņas ieraksta audita žurnālā. Pēc glabāšanas termiņa — anonimizācija pēc dokumentētas procedūras.
Vizīšu reģistrs telefonā tieši pie dalībnieka. Noteikumi strādā paši: divas secīgas neierašanās izveido uzdevumu mentoram, apmeklējums zem 70 % nonāk riska sarakstā, un rādītāju panelis rāda faktu pret mērķi.
Izdevumu reģistrs ar 8 punktu attiecināmības kontrolsarakstu strādā arī pirms budžeta saņemšanas; budžetu var ielādēt vēlāk, un tad parādās plāns pret faktu un naudas plūsma.
Uzbūvēju ar Claude Code no specifikācijas septiņos posmos. Klāt nāk lietošanas instrukcija iesācējiem un demo datubāze ar izdomātiem datiem, uz kuru var pārslēgties lietošanas laikā.
Der arī citiem projektiem
Aktivitātes, termiņu noteikumi, riski, lomas, mērījumu instrumenti un pārskata formas kartējums ir konfigurācija. Rīks to izgūst kā pārneses paketi bez datiem, tāpēc to var pielāgot citam ES fondu vai valsts finansētam projektam.
Klientu nenosaucu. Ekrānuzņēmumos ir demo datubāze — visi dalībnieki un darbinieki tajā ir izdomāti.
Apjoms un pārbaude
22 moduļino darba plāna un termiņiem līdz dalībnieku uzskaitei, pārskatiem SIF un datu dzēšanai
18līguma termiņu noteikumi, ko termiņu dzinējs pārvērš konkrētos datumos un atgādinājumos
182automātiskie testi: 163 vienībtesti (darbdienu kalendārs, termiņu dzinējs, noviržu noteikumi, kritiskais ceļš, datu glabāšana) un 19 pārlūka scenāriji, tostarp piekļuves tiesības
4 dienasno specifikācijas līdz pilnai sistēmai ar demo datiem un lietošanas instrukciju
Laika grafiks · darba plāns pret bāzes līnijuAugšā — moduļi sešās grupās pēc lomas. Diagrammā: darba plāns (zils) pret apstiprināto bāzes līniju (pelēks), pārskata periodi, atskaites punkti un atkarības; sarkanais ir kritiskais ceļš. Brīdinājums rāda, ka 9. aktivitāte darba plānā sākas mēnesi par agru attiecībā pret atkarību.
Novirzes un grozījumiBāzes līniju versijas, noviržu reģistrs ar avotu (automātisks noteikums vai cilvēks) un grozījumu pakotne ar SIF izskatīšanas termiņu.Vizīte telefonāSpeciālists reģistrē vizīti tajā pašā dienā; dalībnieks redzams pēc koda.
Datorredze · MI aģents
Skaitītāju nolasīšana ar datorredzi
MI aģents pats nolasa mēneša skaitītāju fotogrāfijas — elektrība, apkure, aukstais un divi karstā ūdens skaitītāji —, pārbauda rādījumus pret vēsturi, ieraksta tos Excel tabulā un sagatavo ziņu izīrētājai. Arī tad, ja skaitītāja stikls ir tik bojāts, ka cilvēka acij cipari vairs nav salasāmi.
Problēma
Rādījumi katru mēnesi jānolasa, jāpieraksta un jānosūta izīrētājai. Pierakstot ar roku, rodas kļūdas — vēsturē ir vairāki rādījumi ar atzīmi „pārbaudīt”.
Viena karstā ūdens skaitītāja stikls ir sabojājies: melnie kubikmetru cipari zem tā gandrīz nav redzami, skaidri saskatāmi tikai sarkanie litru cipari. Cilvēks no šāda foto rādījumu droši nolasīt nevar.
Kā tas uzbūvēts
Datorredze tur, kur acs vairs neredz. Claude vision nolasa ciparus arī tad, ja kontrasts ir tik zems, ka tie saplūst ar fonu. Nolasījums nekad netiek pieņemts akli: vērtība nedrīkst būt mazāka par iepriekšējo, un pieaugumam jāatbilst šī skaitītāja ierastajam patēriņam.
Ja kāds cipars nav drošs vai pieaugums neatbilst normai, vērtība tiek ierakstīta ar atzīmi „pārbaudīt” un par to tiek pateikts e-pastā. Trūkstošu rādījumu aģents neizdomā.
Divus vienāda modeļa karstā ūdens skaitītājus aģents atšķir pēc tā, kurš rādījums ir tuvāks katra skaitītāja iepriekšējam.
Darba plūsma bez cilvēka: no katra mēneša 24. datuma aģents katru vakaru pārbauda Google Drive mapi; ja foto nav, nāk atgādinājums. Google Apps Script iepriekš samazina pārāk lielus foto.
Python skripts ieraksta rindu Excel tabulā ar formulām, patēriņa aprēķinu un grafikiem. Ja tabula tobrīd atvērta, dati saglabājas rezerves failā un tiek apvienoti nākamajā reizē.
Beigās e-pasts ar rādījumiem, patēriņu un pogu, kas atver gatavu WhatsApp ziņu izīrētājai ar rādījumiem un saiti uz mēneša foto.
Kur vēl der datorredze
Visur, kur dati ir tikai attēlā un tos šobrīd pārraksta cilvēks: analogās mērierīces ražotnē un noliktavā, nolietotas datu plāksnītes un sērijas numuri, rokraksta veidlapas un akti. Tā pati pieeja — nolasīt, pārbaudīt pret vēsturi un noteikumiem, nedrošo atzīmēt cilvēkam.
Claude visionMI aģentsGoogle DriveGoogle Apps ScriptPythonopenpyxlGmailWhatsApp saite
Attēlos ir mana dzīvokļa skaitītājs un uzskaites tabula; skaitītāja sērijas numurs aizmiglots.
Rezultāts
432,45 m³nolasīts no skaitītāja ar bojātu stiklu; iepriekšējais 432,09 m³, pieaugums atbilst šī skaitītāja ierastajiem 0,2–0,5 m³ mēnesī
5skaitītāji vienā mēneša ciklā: no foto līdz tabulai, e-pastam un ziņai izīrētājai
26 mēneširādījumu vēsture vienā tabulā ar patēriņa aprēķinu un grafikiem — arī agrākie ieraksti no burtnīcas
Datorredze · bojāts skaitītāja stiklsReālais foto, no kura aģents nolasīja septembra rādījumu. Cilvēka acij skaidri redzami tikai sarkanie litru cipari un vāji — viens melnais; datorredze nolasa visu rādījumu, un pārbaude pret vēsturi apstiprina, ka tas ir ticams.Uzskaites tabula · ExcelZilie skaitļi ir nolasītie rādījumi, zaļā daļa aprēķinās pati. Oranžs fons un piezīme „pārbaudīt” — tur, kur cipars nebija drošs. Attēlu var atvērt pilnā izmērā.
Telegram bots · finanšu tirgi
Investīciju signālu sistēma
Sistēma visu diennakti skenē kriptovalūtas, akcijas, indeksus un izejvielas un, kad tirgus situācija atbilst izvēlētajai stratēģijai, Telegram atsūta signālu ar ieejas, stopa un mērķa līmeņiem, risku un pamatojumu. Tā ir pielāgojama jebkurai individuālai investīciju stratēģijai un izvēlētajiem instrumentiem.
Pielāgojama jebkurai stratēģijai
Stratēģija ir noteikumi, nevis melnā kaste. Katrs nosacījums dod punktus, un signāls rodas tikai tad, kad punktu summa sasniedz slieksni. Noteikumus, to svaru un slieksni var aizstāt ar jebkuras individuālas stratēģijas noteikumiem.
Instrumenti ir konfigurācija. Jebkurš Binance pāris vai Yahoo Finance tikeris — kriptovalūtas, akcijas, ETF, indeksi, izejvielas — ar savu laika intervālu un grupēšanu, lai viens un tas pats aktīvs divos tirgos nedotu dubultu signālu.
Riska parametri ir investora. Risks uz darījumu, minimālā peļņas un riska attiecība, nedēļas nogales filtrs, depozīta lielums pozīcijas aprēķinam un drošības slēdžu sliekšņi.
Klientam sistēma tiek uzbūvēta uz viņa izvēlētajiem instrumentiem un viņa noteiktās stratēģijas, tāpēc lēmumi un atbildība par investīciju rezultātu paliek pie klienta.
Kā tas uzbūvēts
Pašreizējā konfigurācija seko vienai likviditātes jeb „smart money” metodikai: kodols ir likviditātes noņemšana ar atgriešanos, papildus — vienādi maksimumi un minimumi, diapazona robežas, FVG, Order Block, RSI un diverģence, dienas grafika tendence.
Katram signālam: ieeja, stops aiz ekstrēma ar svārstīguma buferi, pirmais mērķis ar daļēju fiksāciju un otrais mērķis, risks procentos no cenas.
Virtuālais portfelis: katrs signāls tiek izspēlēts bez reālas naudas, lai stratēģiju pārbaudītu dzīvā tirgū, pirms tai uzticas.
Pašuzraudzība: pēc četriem zaudējumiem pēc kārtas aktīvs uz trim dienām tiek apturēts, pēc 5 % krituma risks samazinās uz pusi, un nedēļas pārskatā ir ieteikumi ar pierādījumiem. Stratēģiju sistēma pati nemaina — to apstiprina cilvēks.
Sistēma darījumus biržā neveic: tā atrod situācijas un pamato tās, lēmumu pieņem investors. Palaišana ar failiem dubultklikšķim — programmēt nav jāprot.
Pēc tam, kad stratēģija pārbaudīta virtuālajā portfelī, sistēmu var papildināt ar automātisku orderu izpildi caur biržas vai brokera API — ar pozīcijas un dienas zaudējumu limitiem, avārijas slēdzi un pakāpenisku ieslēgšanu no testa vides līdz reālam kontam.
Ekrānuzņēmumi ir no mana Telegram; virtuālā portfeļa bilance un summas izgrieztas vai aizmiglotas. Tas nav finanšu padoms.
Apjoms
13instrumenti trīs tirgos: kriptovalūtas, akcijas un indeksi, izejvielas
24/7skenēšana — signāls tiek vērtēts pēc katras slēgtās sveces 4 stundu vai dienas grafikā
1 failskonfigurācija: instrumenti, stratēģijas slieksnis, risks un drošības slēdži
0reālu darījumu bez cilvēka — sistēma iesaka, lēmumu pieņem investors
Stratēģija un instrumenti · konfigurācijaViss, kas atšķir vienu investoru no cita — slieksnis, risks, drošības slēdži un instrumentu saraksts —, ir konfigurācijā, nevis kodā.
Signāls → TP1 → TP2Īsts signāls SOLUSDT: pirmais mērķis — puse pozīcijas nofiksēta, stops pārcelts uz ieeju; tad otrais mērķis un rezultāts +2,50R (risku vienībās). Summas aizmiglotas.Signāls → stopsĪsts signāls zeltam, kas beidzās ar stopu. Sistēma ziņo arī par neveiksmēm, ne tikai par veiksmēm.
Web lietotne · finanses
InvoiceAI
Rēķinu aprites sistēma savam uzņēmumam: izejošie rēķini, ienākošo rēķinu atpazīšana tieši no e-pasta un maksājumu sasaiste ar bankas izrakstu.
Problēma
Ienākošie rēķini pienāk e-pastā dažādos formātos, un dati no tiem tiek pārrakstīti ar roku.
Apmaksas fakts jāsalīdzina ar bankas izrakstu manuāli, rindiņu pa rindiņai.
Klienti, produkti, izejošie rēķini un atskaites dzīvo atsevišķos failos, kas nesarunājas savā starpā.
Kā tas uzbūvēts
React priekšpuse, Node/Express API un PostgreSQL; JWT autentifikācija ar datu nodalīšanu pa uzņēmumiem — viens lietotājs var strādāt vairākos.
IMAP savienojums ar pastkasti: sistēma pati ievāc rēķinus no e-pasta un atpazīst tos ar MI, saglabājot pārliecības rādītāju katram atpazītajam laukam.
Bankas konta izraksta apstrāde un automātiska maksājumu sasaiste ar rēķiniem pēc konta numura un summas; maksājumu faila sagatavošana bankai.
PDF rēķinu ģenerēšana un izsūtīšana, atskaites, kā arī balss vadība ātrai ievadei.
Demo vidē visi piegādātāji, klienti un summas ir izdomāti. Rēķinu veidošana, bankas izraksta imports un maksājumu sasaiste strādā pilnībā; pastkastes lasīšana un rēķinu atpazīšana ar MI ir apzināti izslēgtas, lai publiska piekļuve neradītu izmaksas. Strādājošā versija ar reāliem uzņēmuma finanšu datiem netiek rādīta.
Būtība
E-pasts → rēķinssistēma pati ievāc un atpazīst rēķinus no pastkastes; ievade ar roku atkrīt
Automātiska sasaistemaksājumi no bankas izraksta paši atrod savu rēķinu
Lietošanānav prototips plauktā — sistēma strādā uzņēmuma ikdienā
No-code automatizācija · pakalpojumu pārvaldība
Sociālo pakalpojumu pārvaldības sistēma
Klienti, nodarbības, individuālie plāni un izvērtējumi vienā saistītā struktūrā, ar automātiskiem atgādinājumiem — uzbūvēts uz gatavām platformām, bez izstrādes.
Problēma
Klientu dati, nodarbību grafiks, individuālie plāni un izvērtējumi dzīvo atsevišķi un nesarunājas savā starpā.
Atgādinājumi klientiem un paziņojumi par grafika izmaiņām jāsūta ar roku, tāpēc tie mēdz aizmirsties.
Lai sagatavotu atskaiti, informācija katru reizi jāsavāc no jauna.
Kā tas uzbūvēts
Piecas savstarpēji saistītas datubāzes: klienti, nodarbības, individuālie plāni, izvērtējumi un darbinieki — katrs ieraksts redzams no visām pusēm.
Jauna klienta pieteikuma forma, nodarbību kalendāra skats un filtrēšana pēc statusa atskaišu vietā.
Zapier un Make automatizācijas: e-pasta atgādinājumi klientiem par nodarbībām un paziņojumi par izmaiņām grafikā.
Darbinieku lomas ar atšķirīgiem piekļuves līmeņiem — koordinators, speciālists, administrators.
Demo versijā visi klienti, darbinieki un ieraksti ir izdomāti. Reālā sistēma ar klientu datiem netiek rādīta publiski.
Būtība
5 datubāzesklienti, nodarbības, plāni, izvērtējumi un darbinieki vienā saistītā struktūrā
Dienasnevis mēneši — pareizi izvēlēts rīks problēmas mērogam
0 €izstrādes budžets; tikai platformu abonementi
MI aģents · publicitāte
Publikācijas vizuālis
No pabeigta darba — mapes, dokumentiem vai čata rezultāta — izveido publicējamu vizuāli Figma failā trīs formātos. Palaižams no jebkura projekta, arī no citas MI sistēmas izvades.
Problēma
Kad darbs ir pabeigts, par to vēl jāpastāsta — un tas nozīmē atsevišķu uzdevumu dizainerim, ar aprakstu, zīmola prasībām un gaidīšanu rindā.
Trim kanāliem vajag trīs formātus, un katrā saturam jābūt citam, ne tikai mērogotam.
Publicējot iepirkuma vai projekta rezultātus, daļa informācijas ārā nedrīkst nonākt — un to parasti pamana pēdējā brīdī vai nepamana vispār.
Kā tas uzbūvēts
Pats izlasa kontekstu un izvelk virsrakstu, kopsavilkumu un divus līdz četrus atslēgas faktus.
Pats nosaka stilu: atrod organizācijas zīmola krāsas tās mājaslapā, izvēlas paleti un pārbauda kontrastu. Dizaina uzdevumu neviens neraksta.
Konfidencialitātes vārti: publicē tikai to, kas ir publiskojams — gala lēmumu, uzvarētāju, līgumcenu, termiņus. Iekšējā vērtēšanas gaita, citu pretendentu piedāvājumi un personas dati paliek ārā, un aģents pasaka, ko tieši izlaida un kāpēc.
Beigās paņem sava darba ekrānuzņēmumu un pārbauda, vai teksts salasāms un nekas nepārklājas; ja nav — labo pirms nodošanas.
Strādā caur MCP savienojumu ar Figma; iepakots kā atkārtoti lietojams skill, ne vienreizēja saruna.
Izvade ir vektorgrafika, tāpēc A4 formāts ir domāts drukai un izdales materiāliem, ne ekrānam — mērogojams bez kvalitātes zuduma. Formāti ir uzstādījums, ne ierobežojums: aģentu var pārbūvēt uz jebkuru izmēru.
Publicē cilvēks, ne aģents. Gala akceptu — faktu precizitāti, konfidencialitāti un vizuālo kvalitāti — apstiprina speciālists. Juridiskā atbildība paliek viņa rokās.
ClaudeMCPFigmaskill iepakojumszīmola izpēte
Šis aģents ir uzbūvēts, lai strādātu uz citu sistēmu izvades. Iepirkums, ko sagatavojusi IepirkumuAI, kļūst par ievadi šeit: no lēmuma dokumenta iznāk publicējams paziņojums bez neviena starpposma. Tas ir arī iemesls, kāpēc konfidencialitātes filtrs ir aģentā, ne cilvēka galvā — iepirkuma dokumentos publiskojamais un nepubliskojamais stāv blakus.
Pirms un pēc
Viens publicitātes vizuālis
pirms
pēc
4 h manuālas maketēšanas → dažas minūtes
2 → 0speciālisti, kas jāgaida: jurists satura pārbaudei un dizaineris maketēšanai
3 formāti1080×1080 sociālajiem tīkliem, 1200×630 banneriem un A4 drukai — vienā failā, saturs katram pielāgots atsevišķi, ne mērogots
Piezīme par datiem
Neviena no šeit pieejamajām saitēm neved uz sistēmu ar reāliem datiem. Kur sistēma darbojas ar uzņēmuma finanšu vai klientu personas datiem, publiski pieejama ir atsevišķa demo versija ar izdomātu saturu. Tas ir apzināti: automatizācijas speciālists redz vairāk uzņēmuma iekšienes nekā gandrīz jebkurš cits, un portfolio nav vieta, kur to demonstrēt.
Darba pieeja
Kā es strādāju
01 — Sākums
Sāku ar procesu, ne ar rīku
Vispirms noskaidroju, kur tiek tērēts laiks un cik tas maksā. Tikai tad izlemju, vai risinājums ir Zapier scenārijs, MI darba kārtība vai atsevišķa lietotne. Otrādi tas parasti beidzas ar iespaidīgu rīku, ko neviens nelieto.
02 — Mērīšana
Mēru rezultātu stundās
Katram risinājumam ir „pirms" un „pēc" skaitlis. Tas ir vienīgais veids, kā pierādīt, ka automatizācija ir atmaksājusies, un vienīgais veids, kā izlemt, ko automatizēt nākamo.
03 — Uzticamība
Neuzticos MI aklā veidā
Kritiskās vietās avoti ir faili sistēmā, izvade tiek pārbaudīta ar skriptu, un tas, ko sistēma nezina, tiek marķēts, nevis izdomāts. Automatizācija dod ieguvumu tikai tad, ja rezultātu nav jāpārbauda no jauna — pretējā gadījumā ietaupītais laiks atgriežas atpakaļ.
04 — Nobeigums
Pabeidzu līdz lietošanai
Lielākā daļa manas darba pieredzes ir sistēmu ieviešana organizācijās, kur cilvēkiem jāsāk strādāt citādi. Prototipu uzbūvēt ir ātri; panākt, ka to lieto arī pēc trešās nedēļas, ir īstais darbs.
Pieredze
Divdesmit pieci gadi procesos
Pirms MI risinājumiem bija ERP un POS sistēmu ieviešana, projektu vadība un pārdošana. Tā ir daļa, kas paskaidro, kāpēc uzbūvētās sistēmas nonāk līdz lietošanai.
2020 — pašlaik
SIA „Kasway" · Dibinātājs, MI risinājumu izstrādātājs
MI un automatizācijas risinājumi dokumentu un procesu jomā — no procesa analīzes un prototipa līdz strādājošai sistēmai un lietotāju apmācībai.
2023 — pašlaik
Rīgas Austrumu klīniskā universitātes slimnīca · Konsultants klientu vadības procesos
Apmeklētāju plūsmas koncepcijas izstrāde un tās ieviešanas uzraudzība vienā no lielākajām Latvijas slimnīcām.
2012 — 2023
SIA „LATSIGN" · Pašvaldību un lielo klientu projektu vadītājs
Infrastruktūras projektu vadība: budžets, resursi, izmaksu kontrole, risku un izmaiņu vadība; komandas līdz 10 cilvēkiem. Publisko iepirkumu piedāvājumi EIS sistēmā.
2011 — 2012
SIA „ERP PRO" · Pārdošanas projektu vadītājs
Līgums ar 170 veikalu tirdzniecības tīklu un tam izstrādāta pārdošanas kontroles un analīzes sistēma. MS Dynamics AX/NAV, QlikView.
2008 — 2010
SIA „Biznesa Pamati" · Dibinātājs un direktors
Grāmatvedības pakalpojumu uzņēmums, izveidots no nulles: iekšējie procesi, līgumu izpildes kontrole, komanda. Uzņēmums vēlāk pārdots un darbojas līdz šai dienai.
2002 — 2007
SIA „Ankravs" · Projektu vadītājs
ERP un POS kases sistēmu izstrādes un ieviešanas projekti. Nordic ID noliktavu uzskaites risinājumu ekskluzīvais pārstāvis Latvijā.
2000 — 2009
Agrākā pieredze
SIA „Transimex" — pārdošanas un klientu vadītājs; AS „VEF Radiotehnika RRR" — pārdošanas vadītājs.
