Milliseid protsesse tasub automatiseerida ja kuidas neid ära tunda

Neli küsimust, millega saate ise oma igapäevase töö läbi sõeluda: kas tegu on ahelaga, millel on tulemus, kas masin saab andmed või pildi, kas samm otsustab midagi inimese kohta, ja kas protsessil on juba väline tähtaeg.

Küsimus „mida meil tuleks automatiseerida“ esitatakse tavaliselt liiga hilja, sest see eeldab, et vastus on tööriistade nimekiri. Praktikas on suurem osa ebaõnnestunud automatiseerimisprojekte alanud õige tööriistaga, mis pandi vale töö peale, ja tulemuse otsustas valik, mitte tööriist.

See artikkel ei püüa määratleda, mis on äriprotsesside automatiseerimine, sest määratlus ei otsusta midagi; selle asemel annab see neli küsimust, millega saate ise oma igapäevase töö läbi sõeluda, ja pärast iga küsimust näitab, milline juhtum selle läbib ja milline mitte. Sõelumine ei maksa midagi ja võtab ühe pärastlõuna, aga säästab tublisti rohkem kui ükski tööriistade võrdlus, sest see vastab ahela varasemale küsimusele.

Esimene küsimus: kas tegu on ahelaga, millel on tulemus, või klõpsude jadaga

See on piir, mis eristab kõige rohkem, ja see tasub tõmmata täpselt: protsess on toimingute ahel, millel on sisendandmed, väljund ja omanik: arve koostamine tellimusest, uue töötaja töölevõtmine, kliendi taotluse tee vormist vastuseni. Protseduur ehk eraldi toiming on see, kuidas konkreetne samm tehakse: kuhu tuleb klõpsata, mida kleepida, millisesse lahtrisse number panna.

Automatiseerida saab mõlemat, aga tulu erineb kordades, ja just seepärast on järjekord tähtis: kui te automatiseerite ahela, muudate tulemust — dokument jõuab raamatupidamisse ise ja keegi ei kirjuta seda enam ümber. Kui te automatiseerite klõpsude jada, kiirendate üht sammu ahelas, mille ülejäänud osa jääb samaks, ja kasu on täpselt nii suur, kui suur oli tolle ühe sammu osa.

Praktiline äratundmise viis on lihtsalt küsida, mis tulemusega pärast juhtub, ja vastus ütleb tavaliselt kõik: kui see on „siis keegi võtab selle faili ja paneb teise süsteemi“, jätkub ahel ja ühe sammu automatiseerimine tähendab kitsaskoha ümbertõstmist, mitte selle kõrvaldamist. Kui vastus on „siis on töö valmis ja tulemus on süsteemis“, on teil protsess selge lõpuga, ja just need tasub võtta esimesena.

Võtame ühe tüüpilise ahela ja jälgime selle lõpuni, sest just jälgimine näitab, kus kasu tegelikult peitub: klient täidab vormi veebilehel, taotlus tuleb postkasti, keegi kirjutab selle kliendihaldussüsteemi ümber, keegi teine koostab pakkumise ja pärast kinnitust kirjutab veel keegi arve raamatupidamisprogrammis. Siin on üks protsess selge tulemusega (taotlusest arveni) ja selles on vähemalt kolm kohta, kus ühed ja samad andmed kirjutatakse uuesti, iga kord veavõimalusega.

Kui sellest ahelast automatiseerida ainult taotluse ümberkirjutamine haldussüsteemi, on kasu reaalne, aga väike, sest ülejäänud kaks ümberkirjutamist jäävad. Kui automatiseerida kogu ahel, muutub töö iseloom: inimene ei kirjuta enam ümber, vaid kontrollib ja teeb otsuseid seal, kus neid päriselt vaja on. Just seepärast tasub ahela piirid joonistada enne mis tahes tööriistajuttu, sest need määravad, kui suur võimalik kasu üldse on.

Ahelal on ka omanik, ja see on küsimus, mis kipub esitamata jääma. Kui ükski konkreetne inimene ei oska öelda, kuidas protsess algusest lõpuni käib, saab automatiseerimisest oletuste jada selle kohta, kuidas see ilmselt käib, ja esimene päris juhtum need oletused murrab. Omaniku leidmine võtab tavaliselt ühe vestluse, aga säästab mitu nädalat, seega on see projekti odavaim osa.

Teine küsimus: kas masin saab andmed või pildi

See on kogu automatiseerimise tähtsaim tehniline vahe, ja Eestis on sellel nüüd ka õiguslik külg. Kui süsteem saab struktureeritud andmeid (XML, JSON, kirje andmebaasis), saab ta neid töödelda ilma arvamata. Kui ta saab pildi, see tähendab PDF-faili või skannitud lehe, peab keegi enne töötlemist arvama, mis sinna on kirjutatud, ja just see arvamine tekitab vead, mida keegi hiljem käsitsi parandab.

Arvete näide näitab seda kõige paremini, sest seal elavad mõlemad võimalused kõrvuti ja neid kutsutakse peaaegu ühtemoodi. Struktureeritud e-arve, igapäevaselt ka lihtsalt e-arve, on masinloetav dokument kindlas vormingus — Eestis loetakse see nõuetekohaseks, kui see vastab e-arveldamise Euroopa standardile EN 16931-1, ja profiil on PEPPOL BIS Billing 3.0. Saaja süsteem suudab selle raamatupidamisse kanda ilma inimese osaluseta, seega just selle vormingu kohta käivad õiguslikud tähtajad.

PDF-arve, mille saaja on nõustunud elektrooniliselt vastu võtma, on samuti kehtiv dokument: käibemaksuseaduse § 37 lõige 6 lubab arve väljastada elektrooniliselt tingimusel, et kauba soetaja või teenuse saaja on sellega nõus. Kehtiv on see aga käibemaksuarvena, mitte e-arvena, ja masina jaoks on see endiselt pilt.

Sellest tuleb järeldus, mis säästab palju raha: PDF-arvete tuvastamine OCR-iga (optiline tähemärgituvastus) ei ole e-arvete kasutuselevõtt. See on eraldi toiming, mida inimesed põhjendatult automatiseerivad, sest see vähendab ümberkirjutamist, ent see ei loo struktureeritud dokumenti ega täida kohustust sellist esitada. Ettevõte, kes peab OCR-i vastuseks õiguslikule nõudele, avastab paari aasta pärast, et on automatiseerinud vale otsa, ja siis tuleb projekt alustada uuesti süsteemiga, mis arveid väljastab, mitte sellega, mis neid vastu võtab.

Praktiline kontroll on siin lihtne: küsige, millises vormingus süsteem andmeid väljastada ja vastu võtta suudab. Kui vastus on „saab eksportida CSV-d“, on tegu juba struktureeritud andmetega, ainult puudulikult automatiseeritutega. Kui vastus on „saab printida“ või „saab salvestada PDF-iks“, on pilt ainus väljund ja edasine töö kas nõuab liidest või jääb arvamiseks.

Tasub ka teada, et vastus on sageli parem, kui ettevõttes arvatakse, sest paljudel raamatupidamise ja lao programmidel liides on, ainult et keegi pole seda kunagi küsinud, sest igapäevane töö saab hakkama ekspordiga. Üks küsimus tarnijale selle kohta, kas süsteemil on rakendusliides ja mida sellega teha saab, otsustab sageli, kas projekti üldse tasub alustada.

Kolmas küsimus: kas samm otsustab midagi inimese kohta

Suurem osa automatiseerimisest on arvude liigutamine süsteemide vahel ja seal ei ole erilisi õigusküsimusi. On siiski üks sammude rühm, mis tuleb ära tunda eraldi: need sammud, mis otsustavad midagi konkreetse inimese kohta — kas ta tööle võtta, kas anda krediiti, kas vallandada, kas määrata toetust.

Isikuandmete kaitse üldmääruse artikkel 22 (automatiseeritud töötlusel põhinevate üksikotsuste tegemine, sealhulgas profiilianalüüs) sätestab, et andmesubjektil on õigus, et tema kohta ei võetaks otsust, mis põhineb üksnes automatiseeritud töötlusel ja toob kaasa õiguslikke tagajärgi või avaldab talle samamoodi märkimisväärset mõju. Erandid on olemas (lepingu sõlmimise või täitmise vajadus, seadus kaitsemeetmetega, selgesõnaline nõusolek), aga ka siis jääb õigus inimese osalusele, seisukoha avaldamisele ja otsuse vaidlustamisele. Järelevalveasutuste suunised lisavad olulise nüansi: inimese osalus peab olema sisuline, ja formaalne kinnitusnupp, mida keegi vajutab sisusse vaatamata, ei võta protsessi artikli 22 alt välja.

See ei ole keeld automatiseerida, vaid osutus sellele, mis sellises protsessis on automatiseeritav: automatiseerida saab ettevalmistustöö (andmete kogumise, kontrolli, ettepaneku koostamise), aga otsus ise jääb inimesele, kes selle päriselt teeb. Praktikas muudab see projekti mahtu, seega tasub see märgata enne arendust, mitte pärast.

Selle kõrval tasub teada üht tähtaega, mis ei ole veel kätte jõudnud, aga mõjutab pikaajalisi plaane: tehisintellekti määruse nõuded kõrge riskiga süsteemidele tööhõive valdkonnas, see tähendab valikule ja personaliotsustele, hakkavad kehtima 2. detsembril 2027. See tähendab, et tänane valik on vabam, aga süsteemil, mida ehitatakse pikaks ajaks, tuleb see kuupäev plaani panna.

Neljas küsimus: kas protsessil on juba väline tähtaeg

Osal protsessidel ei määra tähtaega ettevõtte prioriteedid, vaid väline kohustus, ja need tõusevad nimekirja etteotsa ise, sest nende kohta ei ole enam tarvis otsustada, kas teha, vaid ainult millal ja kuidas. Eestis on selgeim näide jälle arved, ja seal on kolm eri kuupäeva, mida aetakse segi.

Esiteks tuli ettevõttel, kes esitab arve avaliku sektori asutusele, kasutada e-arvet juba alates 1. juulist 2019. Teiseks võib alates 1. juulist 2025 raamatupidamise seaduse § 7¹ lõike 7 järgi iga äriregistris e-arve vastuvõtjaks märgitud raamatupidamiskohustuslane nõuda müüjalt EN 16931-1 e-arvet, ka erasektoris. Kolmandaks ei ole kohustus esitada struktureeritud arve teisele ettevõttele ilma ostja nõudmiseta veel jõus: 2027. aasta on rahandusministeeriumi ettepanek käibemaksukohustuslaste vaheliseks e-arvete kohustuseks, mitte kehtiv tähtaeg.

Just see kolmas kuupäev on avalikus käibes kõige sagedamini vale, ja põhjus on lihtne: teisestes artiklites kirjutatakse 2027 sageli nii, nagu see juba kehtiks, kuigi raamatupidamise seadus räägib ostja õigusest e-arvet nõuda, mitte üldisest B2B-esitamise kohustusest. Ettevõttele, kes planeerib eelarvet, on vahe kehtiva õiguse ja ettepaneku vahel suur, seega tasub kuupäev kontrollida esmaallikast, mitte ümberjutustusest.

Väliseid tähtaegu on ka mujal: tööaja arvestus peab olema objektiivne ja kättesaadav, raamatupidamisdokumentidel on säilitamistähtajad ja lepingutes kipuvad olema aruandekuupäevad. Ühine on see, et neid tähtaegu ei saa läbi rääkida, ja protsess, millel niisugune on, annab tööle selge põhjenduse — erinevalt protsessist, mida automatiseeritakse sellepärast, et see tundub moodne.

Milline näeb välja protsess, mida tasub võtta esimesena

Kui neli küsimust kokku panna, tuleb üsna konkreetne portree, mida saab panna mis tahes nimekirja kõrvale: väärtuslikem esimene kandidaat on ahel selge tulemusega, milles andmed on juba struktureeritud või võivad selleks saada, milles ükski samm ei otsusta midagi inimese kohta, ja millel on väline tähtaeg või vähemalt mõõdetav maht.

Praktikas näeb see tavaliselt välja nii: tellimus poest jõuab raamatupidamissüsteemi ilma ümberkirjutamiseta; kooskõlastusahel, milles taotlus läheb õigele inimesele ja tuleb tagasi märkega; andmete sünkroonimine lao ja veebilehe vahel, kus inimene ekspordib praegu faili kaks korda päevas. Kõigil kolmel on üks ühine tunnus — kahe süsteemi vahel käib täna inimene failiga.

Just seda tunnust on kõige kergem märgata ja kõige raskem unustada, seega tasub inventuuriga sealt alustada. Kirjutage üles, kus teie ettevõttes keegi ekspordib, kleepib või kirjutab ümber, kui sageli ja kui kaua. See nimekiri on tavaliselt lühem, kui oodati, ja selles on peaaegu alati üks kirje, mis paistab silma.

Teine tunnus, mis kandidaadi esile tõstab, on vea hind, ja see jäetakse arvestustes tavaliselt kõrvale: kui ümberkirjutamise viga selles ahelas tähendab vale arvet kliendile, vale jääki laos või möödalastud tähtaega, ei ole automatiseerimise kasu ainult säästetud tunnid, vaid ka ära hoitud vead, ja see on tavaliselt kahest arvust suurem. Protsess, milles viga on märkamatu ja kahjutu, on selles mõttes vähem väärtuslik kandidaat, isegi kui see võtab sama palju aega.

Kolmas tunnus on see, kuidas maht ettevõttega koos muutub, ja see on kolmest tähtsaim: töö, mis kasvab ettevõttega kaasa, sest rohkem tellimusi tähendab rohkem ümberkirjutamist, läheb ajaga üha kallimaks, ja just seal tasub automatiseerimine kahekordselt: see vabastab aega täna ja võtab ära kulu, mis muidu kasvaks. Töö püsiva mahuga, sõltumata käibest, seda teist kasu ei anna.

Portree juurde tasub panna üks asi järjekorra kohta, sest selles eksivad ettevõtted sagedamini kui tööriista valikus: esimest automatiseeritud protsessi ei tule valida selle järgi, milline on kõige suurem või kõige valusam, vaid selle järgi, milline on kõige paremini mõistetav ja kõige kiiremini lõpetatav, sest esimene projekt õpetab ettevõttele, kuidas niisugused projektid üldse käivad — kuidas kirjeldada erandeid, kuidas testida ja kuidas vigadega toimida. Seda õppetundi on palju odavam saada lihtsa töö peal kui selle peal, millest sõltub rahavoog.

Milline näeb välja protsess, mida ei tasu võtta esimesena

Sama kasulik kui hea kandidaadi äratundmine on äratunda see, mis paistab ahvatlev, aga tasub halvasti, ja niisuguseid juhte on neli. Esimene on töö, mis toimub harva (kord kvartalis või kord aastas), sest arendusekulu jääb samaks, aga kokkuhoid jagatakse neljaga või ühega.

Teine on protsess, mille kord veel muutub, ja see on juht, milles kiirustamine maksab kõige kallimalt: kui korda on viimase poole aasta jooksul muudetud kolm korda, kinnitab automatiseerimine selle versiooni, mis niikuinii varsti muutub, ja hooldus sööb kasu ära. Siin on õige järjekord kõigepealt kord kokku leppida ja alles siis see automatiseerida, kuigi praktikas kipub olema vastupidi.

Kolmas on töö, milles iga juhtum on erand, ja seal on piir ülesande enese loomuses, sest automatiseerimine saab hästi hakkama sagedase ja etteaimatavaga, aga halvasti olukorraga, milles kümnel juhul on kümme eri teed; seal on inimese otsustus ise töö, ja selle asendamine reeglipuuga tekitab tavaliselt rohkem erandeid, kui kõrvaldab.

Neid kolme juhtu ühendab üks tunnus: neis kinnitab automatiseerimine midagi, mis ei ole veel valmis kinnitatud saama. Harv töö ei ole piisavalt läbi töötatud, et seda tasuks talletada; muutuv protsess otsib alles oma kuju; erandite töö on olemuselt otsustus. Kõigis kolmes on õige tegu oodata või kõigepealt korda seada, mitte automatiseerida kiiremini.

Neljas on juht, milles ekraani imiteeritakse sellepärast, et süsteemil ei ole liidest. See on mõnikord ainus võimalik tee, aga see on ka kõige hapram: piisab muudatusest ekraanil ja töö peatub. Kui süsteemil liides on või seda saab nõuda, on see peaaegu alati soodsam valik kui ekraani imiteerimine.

Mis saab inimestest, kelle tööd automatiseeritakse

Seda küsimust automatiseerimispakkumustes tavaliselt välditakse, kuigi ettevõttes küsitakse seda juba esimesel päeval, ja vastamata muutub see vaikivaks vastupanuks, mis võib projekti peatada kindlamalt kui ükski tehniline probleem. Aus vastus enamikus väikestes ja keskmistes ettevõtetes on see, et automatiseerimine vabastab aega, mitte inimest: ümberkirjutamine on see töö osa, mida keegi ei taha, ja selle kadumine tähendab tavaliselt, et sama inimene jõuab lõpuks teha seda, milleks varem aega ei jätkunud.

Sellest järeldub praktiline soovitus, mis kõlab pehme, aga on puhas projektijuhtimise küsimus: inimene, kes tööd täna teeb, tuleb projekti kaasata teadlikema allikana, mitte teda tulemusest teavitada. Tema teab erandeid, mida keegi ei ole kirja pannud, ja just erandid on need, mis automatiseerimise murravad. Projekt, milles see vestlus toimub alguses, maksab vähem kui selline, milles see toimub pärast esimest viga.

On ka aus öelda teine pool, sest vastupidine oleks teesklemine: kui ettevõttes koosneb kellegi töö täielikult andmete ülekandmisest kahe süsteemi vahel, asendab automatiseerimine selle töö tõesti, ja see on vestlus rolli muutmisest, mida juhib ettevõtte juhtkond, mitte tarnija. Pakkumus, mis seda küsimust üldse ei esita, ei ole delikaatne — see lihtsalt ei ole lõpuni läbi mõeldud.

Kuidas oma arv välja arvutada

Arvutus, mida otsuseks vaja on, mahub ühele lehele ega nõua ei konsultanti ega uuringut. Vaja on neli arvu: mitu korda nädalas see töö toimub, mitu minutit see iga kord võtab, kui palju maksab tund inimesele, kes seda teeb, ja kui sageli tekib selles viga, mida keegi pärast parandab.

Esimesed kolm annavad otsese ajakulu aastas, ja see arv on tavaliselt väiksem, kui oodati — just seepärast ei õnnestu projektile ainult sellega sageli põhjendust leida. Neljas arv on see, mis enamasti otsustab, sest vea hind on harva ainult selle parandamise aeg: vale arve tähendab kirjavahetust kliendiga, vale jääk tähendab kas kaupa, mis jääb müümata, või tellimust kaubale, mida laos enam ei ole, ja möödalastud tähtaeg tähendab mõnikord trahvi.

Nende arvude vastu pannakse arendusekulu ja hooldus, ja just hooldus on see, mis ununeb. Automatiseerimine, mis ühendab kaks süsteemi, elab nii kaua, kui elavad mõlemad liidesed, seega peab plaanis olema koht muudatustele, mida nõuab keegi teine. Kui arvutus tasub ainult siis, kui hoolduskulu sisse ei arvestata, ei tasu see tegelikult üldse.

Veel üks asi, mis tasub enne vestlust selgeks teha, on see, kui sageli süsteemid muutuvad. Pilveteenus, mis uueneb ise, võib liidest muuta ilma hoiatuseta, kohapeal paigaldatud programm jääb aga aastateks samaks, aga selle uuendamine nõuab kunagi kogu kontrolli otsast peale. Kumbki variant ei ole halvem, ent need nõuavad eri hooldusplaani, ja pakkumus, mis seda ei peegelda, on odav just selles kohas, kuhu kulu hiljem tekib.

Miks uuringute protsentidesse ei maksa uskuda

Automatiseerimispakkumustes ilmub peaaegu alati arv: et automatiseerida saab poole tööst, et projektid kukuvad kolmandikus juhtudest läbi, et keegi säästis kümneid tuhandeid tunde. Need arvud on olemas ja tsiteeritavad, ent need ei kirjelda peaaegu kunagi seda ettevõtet, kellele neid näidatakse, ja just see teeb neist halva otsuse aluse.

Laialt tsiteeritud näitaja selle kohta, et suur osa tegevusi on automatiseeritav, on arvutus tegevuste kohta palgafondis konkreetses riigis ja konkreetsel aastal, tolle aasta tehnoloogiatega, ja selle avaldas konsultatsioonifirma, kes müüb sama teenust. Näitaja projektide ebaõnnestumiste kohta tuleb konsultandi kogemusest klientidega, kes ta pärast esimesi ebaõnnestumisi välja kutsusid, seega on valim juba määratluse järgi moonutatud. Arv säästetud tundide kohta kirjeldab konkreetset neljakümne inimese raamatupidamisosakonda teises riigis mitu aastat tagasi.

Sellest ei järeldu, et automatiseerimine ei tasu, vaid see, et õige arv on teie enda oma: mitu korda nädalas see töö toimub, kui kaua see võtab ja kui palju maksab tund. Selle arvutuse saab teha ühel lehel, see kirjeldab täpselt teie ettevõtet ja see on ainus, mille põhjal tasub otsus teha.

Mida süsteemide kohta teada, enne kui pakkumust küsida

Kui kandidaat on valitud, ei ole järgmine samm pakkumuse küsimine, vaid viie minuti uurimine süsteemide endi kohta, sest just see otsustab, kas jutt täitjaga tuleb lahendusest või võimalikkusest. Selgitage, kas igal asjaomasel süsteemil on rakendusliides, kas see on teie litsentsitasemel kättesaadav ja kas tarnija küsib selle eest eraldi tasu, sest kõik kolm vastust kipuvad erinema.

Teine küsimus on selle kohta, kes andmeid hoiab ja kes tohib neid muuta. Kui kaks süsteemi sisaldavad üht ja sama teavet, näiteks kliendi rekvisiite või kauba jääki, tuleb enne ühendamist otsustada, kumb on peamine, sest muidu hakkab automatiseerimine mõlemat vastastikku üle kirjutama ja tulemus on halvem kui enne. See otsus on tasuta, kui see tehakse alguses, ja kallis, kui see avastatakse testimise ajal.

Kolmas on küsimus selle kohta, mis juhtub, kui miski ei õnnestu. Igas automatiseerimises on juhte, mis ei lähe läbi (väli puudub, süsteem ei vasta, andmed on vastuolulised), ja neil on vaja kohta, kuhu jõuda, ning inimest, kes need üle vaatab. Automatiseerimine ilma veatöötluseta töötab nii kaua, kui kõik on korras, ja see ei ole kunagi kaua.

Tasub ka ette otsustada, mille järgi hindate, kas õnnestus, sest ilma selleta ei lõpe projekt kunagi, vaid lihtsalt katkeb. Mõõt võib olla päris lihtne: mitu korda kuus keegi veel kannab andmeid käsitsi üle, mitu viga parandati eelmisel kuul ja kui kaua taotlus läheb vormist vastuseni. Seda arvu on mõtet mõõta üks kord enne töö algust, et hiljem oleks millega võrrelda. Ettevõtted, kes seda mõõtmist ei tee, vaidlevad poole aasta pärast selle üle, kas üldse midagi muutus.

Lõpuks tasub meeles pidada, et automatiseerimine ei ole ühekordne töö, vaid miski, mis jääb ettevõttesse ja nõuab omanikku nagu iga teine süsteem. Kui protsess on ühendatud, peab keegi teadma, kuhu vaadata, kui see peatub, ja kellelgi peab olema õigus see peatada, kui tulemus paistab vale. Ettevõtetes, kus see roll ei ole nimetatud, lakkab automatiseerimine vaikselt töötamast ja seda märgatakse alles kuu pärast, kui keegi otsib kadunud dokumenti.

Millega praktiliselt alustada

Algus ei ole tööriista valik ega pakkumuse küsimine, vaid üks nädal, milles pannakse kirja, mis toimub: milline töö kordub, kui sageli, kui kaua ja kus inimene kannab selles andmeid süsteemide vahel. Pärast esitage igale kirjele neli selle artikli küsimust, ja suurem osa nimekirjast langeb ära juba pärast kahte esimest.

Tulemusena jääb tavaliselt järele üks või kaks kandidaati, ja see on hea, sest just nii paljut korraga tasubki alustada: kaks lõpetatud tööd annavad rohkem kui kuus alustatut. Kui kandidaat on valitud, on järgmine samm selgitada, kas asjaomastel süsteemidel on liidesed, sest see otsustab nii hinna kui lahenduse vastupidavuse.

Kui sel hetkel on selge, milline protsess on teie, aga ei ole selge, kuidas see ühendada, saab seda meiega arutada: äriprotsesside automatiseerimine meie teostuses on liidestused ja töövood süsteemide vahel, mis teil juba on. Kui tahate kõigepealt aru saada, millega eri lähenemised ja tööriistarühmad erinevad, kirjutage meile või saatke oma nimekiri — sageli on vastus, et piisab ühest ühendusest, mitte platvormist.