Jā, daudzos gadījumos pieslēgumu var izdarīt bez programmētāja. Taču tas nenozīmē, ka nekas nav jādara pašam uzņēmumam. Parasti bez izstrādes var tikt galā tad, ja izmantojam jau gatavu integrāciju, datu lauki abās sistēmās sakrīt vai ir viegli salāgojami, un ieviešanas procesā pietiek ar iestatījumiem, testiem un lietotāju tiesību sakārtošanu.
Savukārt brīdī, kad vajag nestandarta loģiku, vairākas sistēmas vienā ķēdē, specifisku datu apmaiņu vai paaugstinātas drošības prasības, jautājums vairs nav tikai par to, vai var pieslēgt bez programmētāja. Jautājums ir, cik dārgi izmaksās kļūdas, ja mēģināsim ietaupīt nepareizajā vietā.
Ko praksē nozīmē pieslēgt bez programmētāja
Kad uzņēmumi saka, ka vēlas pieslēgt sistēmu bez programmētāja, viņi parasti ar to domā vienu no trim lietām.
Pirmā, ir gatavs savienojums starp divām platformām. Piemēram, e-komercijas sistēma jau atbalsta pasūtījumu nodošanu loģistikai, noliktavai vai rēķinu izrakstīšanai, un mums atliek tikai ievadīt piekļuves datus, izvēlēties statusus, aktivizēt notikumus un pārbaudīt, vai dati plūst pareizā secībā.
Otrā, savienojums notiek ar importa un eksporta failiem. Tas var būt CSV, XML vai Excel formāts, ko viena sistēma eksportē, bet otra importē pēc noteikta šablona. Te programmēšana bieži nav vajadzīga, bet ir vajadzīga disciplīna. Jāvienojas par kolonnu secību, datumu formātu, obligātajiem laukiem, kodējumu, valstu kodiem, PVN laukiem, preču identifikatoriem un kļūdu apstrādi.
Trešā, tiek izmantota integrācijas platforma vai iestatāms savienotājs ar gatavām darbībām. Tas joprojām skaitās bez klasiskas izstrādes, taču pilnīgi bez tehniskas domāšanas tas nenotiek. Kādam ir jāsaprot, no kurienes dati nāk, kur tie nonāk, kas notiek, ja ieraksts netiek pieņemts, un kā atjaunot procesu pēc kļūdas.
Svarīgi saprast, ka bez programmētāja nenozīmē bez darba. Lietotāja pusē gandrīz vienmēr paliek šādi uzdevumi:
- procesu aprakstīšana pirms ieviešanas,
- lauku salīdzināšana starp sistēmām,
- lietotāju lomu un piekļuves tiesību sakārtošana,
- testa datu sagatavošana,
- kļūdu scenāriju pārbaude,
- atbildīgā cilvēka nozīmēšana uzturēšanai.
Praksē tieši šajā vietā rodas lielākā daļa pārpratumu. Uzņēmums sagaida, ka “pieslēgt bez izstrādes” nozīmēs vienu klikšķi. Patiesībā tas biežāk nozīmē, ka nav jāraksta individuāls kods, bet ieviešana tik un tā prasa strukturētu darbu. Ja tas nav izdarīts, arī gatava integrācija var dot nepareizus statusus, dublētus ierakstus vai nepilnīgus dokumentus.
Ja runa ir par loģistikas, piegādes vai noliktavas procesiem, īpaši svarīgi ir jau sākumā saprast, kuri dokumenti un statusi ir galvenie. Vai primārais ieraksts ir pasūtījums, pavadzīme, sūtījums vai klienta kartīte. Vai sistēmas apmainās ar pilnu ierakstu, vai tikai ar statusa izmaiņām. Vai kļūdas gadījumā dati tiek apturēti, pārsūtīti atkārtoti vai atzīmēti manuālai pārbaudei. Tie nav programmētāja jautājumi vien, tie ir biznesa procesa jautājumi.
Kad to tiešām var izdarīt pašu spēkiem
Pašu spēkiem to parasti var izdarīt tad, ja ieviešanas situācija ir standartizēta. Tas nozīmē, ka mums nav jāizgudro jauns process, bet jāaktivizē jau paredzēts scenārijs.
Labs piemērs ir gatava integrācija starp pasūtījumu sistēmu un piegādes risinājumu, kur jānodod saņēmēja dati, piegādes adrese, sūtījuma svars, pakalpojuma veids un atgriezeniski jāsaņem izsekošanas numurs vai piegādes statuss. Ja abas puses jau atbalsta šādu plūsmu, ieviešana parasti sastāv no iestatījumiem, testēšanas un lietotāju apmācības.
Tas pats attiecas uz situācijām, kur mūsu klients vai partneris jau strādā ar noteiktu datu struktūru, un mums tikai jāpielāgo savi lauki. Ja nav vajadzīgas sarežģītas transformācijas, pietiek ar skaidru ieviešanas plānu:
- definēt, kādi dati tiks nodoti,
- vienoties par obligātajiem laukiem,
- pārbaudīt identifikatorus un kodus,
- palaist testu ar nelielu datu apjomu,
- salīdzināt rezultātu abās sistēmās,
- tikai tad aktivizēt pilnu apmaiņu.
Pašu spēkiem bieži pietiek arī tad, ja sistēmai ir laba administrēšanas vide. Piemēram, varam paši iestatīt statusu kartējumu, dokumentu šablonus, paziņojumus, lietotāju grupas un importu bez piekļuves API līmenim. Šādā gadījumā svarīgākais nav programmēšana, bet kārtība ieviešanā.
Ļoti palīdz arī tas, ja uzņēmumā ir viens procesa īpašnieks. Nevis pieci cilvēki no dažādām nodaļām, kuri katrs redz tikai savu daļu, bet viens atbildīgais, kurš saprot pilno plūsmu no pasūtījuma līdz izpildei. Tad lēmumi par lauku nozīmi, statusiem un izņēmumiem tiek pieņemti ātrāk, un ieviešana neiestrēgst.
Ja vēlamies samazināt risku, labs ceļš ir sākt ar šaurāku scenāriju. Piemēram, vispirms pieslēgt tikai vienu klientu, vienu datu plūsmu vai vienu dokumentu tipu. Tikai pēc tam pievienot papildu loģiku. Tieši tāpēc mēs bieži iesakām sākt ar procesu, kur rezultātu var viegli pārbaudīt, piemēram, ar sūtījumu izsekošanas risinājumu vai ar pavadzīmju un piegādes dokumentu pārvaldību.
Bez programmētāja ieviešana ir īpaši reāla, ja ir izpildīti četri nosacījumi:
- ir gatava integrācija vai skaidri aprakstīts importa formāts,
- nav vajadzīga individuāla biznesa loģika,
- datu apjoms sākumā ir kontrolējams,
- uzņēmumā ir cilvēks, kurš var vadīt testēšanu un pieņemt lēmumus.
Ja šie nosacījumi ir spēkā, mēs parasti varam ieviest risinājumu ātri un bez liekas sarežģīšanas.
Kad bez programmētāja risks kļūst pārāk liels
Brīdī, kad sistēmas vairs nesarunājas vienkārši, risks strauji pieaug. Tas notiek nevis tāpēc, ka bez programmētāja nekas nav iespējams, bet tāpēc, ka kļūdu cena kļūst pārāk augsta.
Pirmais tipiskais gadījums ir pielāgota loģika. Piemēram, viena veida klientiem jāpiemēro viens piegādes process, citiem cits. Vai arī piegādes metode jāizvēlas pēc vairākiem nosacījumiem vienlaikus, preču grupas, temperatūras režīma, piegādes zonas, līguma nosacījumiem un diennakts laika. Šādu loģiku reti var droši salikt tikai ar ķeksīšiem iestatījumos.
Otrais gadījums ir sarežģīta datu kartēšana. Ja vienā sistēmā klients ir viens ieraksts, bet otrā klients, piegādes adrese un norēķinu adrese ir atsevišķi objekti, ar vienkāršu importu nepietiks. Tas pats attiecas uz precēm, vienībām, iepakojuma līmeņiem, maršrutiem un statusiem. Ja kartēšana nav precīza, kļūdas ne vienmēr ir redzamas uzreiz. Tās parādās vēlāk kā nepareizi dokumenti, pazuduši statusi vai nekorekti pārskati.
Trešais gadījums ir vairāku sistēmu savienošana vienā ķēdē. Piemēram, e-veikals, ERP, noliktavas sistēma, kurjeru platforma un grāmatvedība. Katrai sistēmai ir savs datu modelis, savs atjaunošanas biežums un savi kļūdu paziņojumi. Šādā scenārijā ar vienu gatavu savienojumu nepietiek. Kādam ir jāuzrauga visa plūsma, jāparedz atkārtota nosūtīšana, jānovērš dublikāti un jānodrošina, ka viena sistēma nesabojā datus pārējās.
Ceturtais gadījums ir drošība un atbilstība. Ja tiek apstrādāti personas dati, jāskatās ne tikai uz tehnisku pieslēgumu, bet arī uz piekļuves tiesībām, datu minimizāciju, glabāšanas termiņiem un audita pēdām. Latvijā šeit piemērojams Vispārīgās datu aizsardzības regulas jeb GDPR ietvars, un tas ir vienots visā ES. Taču praksē Latvijā uzņēmumiem bieži jāņem vērā arī iekšējās dokumentu aprites prasības, pilnvarojumi un tas, kā konkrētajā nozarē tiek glabāti pamatojošie dokumenti. Ja integrācija ietekmē elektroniskus apliecinājumus, piegādes pierādījumus vai dokumentu arhivēšanu, ieviešana jāvērtē kopā ar atbildīgajiem par datu aizsardzību un procesu kontroli.
Piektais gadījums ir situācijas, kur kļūdas ietekmē rēķinus, krājumu atlikumus vai juridiski nozīmīgus dokumentus. Ja nepareizi dati nonāk rēķinā, pavadzīmē vai piegādes apliecinājumā, sekas nav tikai neērts labojums. Tas var ietekmēt norēķinus, klientu pretenzijas un iekšējo uzskaiti. Šeit ietaupījums uz speciālista iesaisti parasti ir īstermiņa.
Ja redzam kaut vienu no šīm pazīmēm, ieviešanu labāk plānot ar tehnisku speciālistu vai vismaz ar cilvēku, kurš prot vadīt integrācijas projektu profesionāli. Tas ir īpaši svarīgi, ja paredzēta integrācija ar esošajām biznesa sistēmām, nevis izolēts atsevišķs rīks.
Bez programmētāja vai ar speciālistu?
Salīdzinājums nav tikai par to, kurš variants ir lētāks. Jāskatās uz kopējām izmaksām, ieviešanas ātrumu, kontroles līmeni, kļūdu risku un uzturēšanu.
Bez programmētāja priekšrocība ir ātrums. Ja process ir standarta, gatava integrācija ļauj sākt salīdzinoši ātri. Nav jāgaida izstrādes uzdevumi, nav jātestē individuāls kods vairākās versijās, un izmaiņas bieži var veikt administrēšanas līmenī. Tas ir labs risinājums, ja gribam ātri palaist procesu un uzņēmumā ir skaidrs atbildīgais.
Otrs ieguvums ir zemāka sākotnējā sarežģītība. Mazāk iesaistīto pušu, mazāk tehnisko lēmumu, mazāk atkarības no viena izstrādātāja. Uzturēšanā tas nozīmē, ka ikdienas izmaiņas biežāk varam veikt paši.
Taču mīnuss ir robežas. Tiklīdz vajag kaut ko ārpus standarta scenārija, bez programmētāja pieeja sāk balstīties uz apkārtceļiem. Parādās manuāli eksporta faili, papildu pārbaudes Excel tabulās, statusu pārlabošana ar roku, dubulta datu ievade. Formāli sistēma ir pieslēgta, bet process kļūst trausls.
Ar speciālistu ieviešana sākumā parasti ir lēnāka. Jāapraksta prasības, jāizveido tehniskais risinājums, jātestē izņēmuma scenāriji. Taču sarežģītākos gadījumos tas bieži ir ātrākais ceļš līdz stabilam rezultātam. Mēs nevis pielāgojamies sistēmas ierobežojumiem, bet izveidojam loģiku, kas atbilst mūsu reālajam darbam.
Kontroles ziņā speciālists dod lielāku precizitāti. Var definēt validācijas, kļūdu paziņojumus, žurnālfailus, atkārtotas nosūtīšanas noteikumus un datu transformācijas. Tas ir svarīgi, ja jāspēj pierādīt, kas ar datiem noticis, kurā brīdī un kāpēc.
Kļūdu risks bez programmētāja parasti ir mazāks tikai vienkāršos scenārijos. Sarežģītos procesos tas kļūst lielāks tieši tāpēc, ka sistēma sāk darboties “gandrīz pareizi”. Un “gandrīz pareizi” integrācijās ir bīstamāk nekā acīmredzama kļūda, jo problēmu pamana vēlu.
Uzturēšanā jāskatās uz to, kas notiks pēc palaišanas. Vai mums būs jāmaina lauki, jāpievieno jauni klienti, jāmaina dokumentu plūsma, jāievieš jauns pārvadātājs, jāpielāgo statusi. Ja jā, tad svarīgi, lai izvēlētais risinājums būtu ne tikai iedarbināms, bet arī pārvaldāms. Dažreiz to labāk nodrošina gatava integrācija. Citreiz tieši speciālista izveidota arhitektūra ir vieglāk uzturama ilgtermiņā.
Tāpēc pareizais jautājums nav tikai “vai var”. Pareizais jautājums ir, vai konkrēto procesu var pieslēgt bez programmētāja tā, lai tas būtu droši, pārskatāmi un uzturami arī pēc trīs, sešiem un divpadsmit mēnešiem.
Kā pieņemt lēmumu pirms ieviešanas
Pirms sākam, ir vērts iziet cauri īsam, bet praktiskam izvērtēšanas sarakstam. Tas palīdz saprast, vai drošāks būs ceļš bez izstrādes, vai tomēr jāiesaista speciālists jau no sākuma.
Pirmais jautājums, vai mums ir gatava integrācija vai dokumentēts importa formāts. Ja atbilde ir jā, iespēja iztikt bez programmētāja būtiski pieaug. Ja atbilde ir nē, jāvērtē, cik daudz loģikas būs jāizveido no nulles.
Otrais jautājums, vai mūsu process ir standarta. Ja dati vienkārši pāriet no vienas sistēmas uz otru bez īpašiem nosacījumiem, varam iet vienkāršāku ceļu. Ja ir atzarojumi, izņēmumi, klientu specifika un vairāki lēmumu punkti, labāk to atzīt uzreiz.
Trešais jautājums, cik sistēmas ir iesaistītas. Viena pret vienu savienojums parasti ir daudz drošāks nekā ķēde no četrām vai piecām platformām. Jo vairāk posmu, jo vairāk jādomā par kļūdu apstrādi.
Ceturtais jautājums, vai dati ir juridiski vai finansiāli jutīgi. Ja tie ietekmē rēķinus, pavadzīmes, piegādes pierādījumus, personas datus vai noliktavas atlikumus, mums vajag stingrāku kontroli un skaidrāku atbildību.
Piektais jautājums, vai uzņēmumā ir procesa īpašnieks. Ja nav cilvēka, kurš spēj pieņemt lēmumus par laukiem, statusiem un testēšanas rezultātiem, pat vienkārša integrācija ievilksies.
Sestais jautājums, vai mums ir testa vide vai vismaz drošs testēšanas scenārijs. Nekad nevajadzētu pirmo reizi pārbaudīt datu apmaiņu uz pilna dzīva apjoma. Vajag testa pasūtījumus, testa klientus un skaidru plānu, kā atcelt vai izlabot kļūdainus ierakstus.
Septītais jautājums, kas uzturēs risinājumu pēc palaišanas. Ja atbilde ir “redzēsim vēlāk”, tad lēmums vēl nav gatavs. Integrācija nav vienreizējs notikums. Tā ir daļa no ikdienas procesa.
Mēs parasti iesakām pieņemt lēmumu šādā secībā:
- vispirms aprakstīt procesu no sākuma līdz beigām,
- pēc tam identificēt obligātos datus un dokumentus,
- tad pārbaudīt, vai ir gatava integrācija,
- palaist testu ar ierobežotu apjomu,
- tikai pēc testa izlemt, vai pietiek ar iestatījumiem vai vajadzīgs speciālists.
Ja pēc šī izvērtējuma joprojām ir šaubas, tas pats par sevi ir signāls. Vienkārši projekti parasti kļūst skaidrāki jau pirmajā analīzē. Sarežģīti projekti kļūst vēl sarežģītāki, kad sākam tos godīgi izzīmēt. Un tieši tad ir vērts izvēlēties drošāku ceļu.
Secinājums ir vienkāršs. Pieslēgt bez programmētāja var, ja process ir standarta, ir gatavi savienojumi un mums ir skaidrs ieviešanas īpašnieks. Ja nepieciešama pielāgota loģika, vairākas sistēmas, precīza datu kartēšana vai paaugstināta drošība, speciālista iesaiste nav lieka greznība. Tā ir veids, kā pasargāt ieviešanu no dārgām kļūdām.