Предности одређене инсталације за компаније

Popodnevno ažuriranje sistema u petak u mnogim kompanijama još uvek živi u glavama nekoliko iskusnih kolega, u starim dokumentima i u više ručno pokrenutih komandi. Ako proces uspe, u ponedeljak niko ne priča o tome. Ako ne uspe, korisnička podrška, skladište, proizvodnja ili prodaja odmah osećaju posledice. Prednosti determinističkog postavljanja za kompanije razumljive su iz ove situacije: isto odobreno izdanje pod istim uslovima svaki put vodi do istog rezultata.

Ovo nije samo pitanje udobnosti za programere. Način postavljanja određuje koliko su promene poslovnog sistema sledljive, kontrolisane i obnovljive. Posebno kada ERP, webshop, skladišni procesi, prikupljanje proizvodnih podataka i izveštaji već zavise od više sistema.

Šta znači determinističko postavljanje u praksi?

Determinističko postavljanje se odnosi na proces izdavanja sistema koji je unapred definisan, verzionisan i ponovljiv. Rezultat ne zavisi od toga ko vrši postavljanje, koji ručni korak je izostavljen ili koja postavka je ostala na serveru iz prethodnih meseci.

Neophodan aplikativni kod, konfiguracija, zavisnosti i koraci postavljanja su jasno definisani. Proces se odvija u kontrolisanom okruženju, može se beležiti i isti paket se može prvo izdati u test, a zatim u produkciono okruženje. Ovo može uključivati upravljanje konfiguracijom infrastrukture, kontrolu izmena šeme baze podataka, kao i tačno koja verzija sistema radi u određenom trenutku.

Cilj nije da svaka promena postane složenija. Naprotiv: često ponavljane, mehanički izvršive korake treba izvući iz ljudske memorije i usmenog prenosa. Operateru tako ostaje više vremena za ono što zaista zahteva razmatranje: na primer, procenu poslovnog rizika ili proveru neobičnog rezultata.

Prednosti determinističkog postavljanja za kompanije

Manje razlika između okruženja

Mnoge greške ne nastaju u novoj funkciji, već zbog toga što su se testno okruženje i produkcioni sistem već dugo udaljili jedno od drugog. Druga verzija komponente, ručno izmenjena postavka ili nedostajuća dozvola dovoljni su da testirani proces ipak ne uspe u produkcionom okruženju.

Kod determinističkog postavljanja, struktura okruženja i izdani paket su bolje dokumentovani. Ovo ne eliminiše sve probleme, ali značajno smanjuje one nesigurne faktore na koje se kasnije može odgovoriti samo sa: „na testu je radilo“. U logističkom sistemu ovo može biti posebno važno ako obrada narudžbina, štampanje etiketa i povezanost s prevoznicima se sastoje od više komponenti.

Sledljiva odgovornost i bolja osnova za donošenje odluka

Ako se nakon izdavanja pojavi nepravilnost, prva pitanja su obično vrlo jednostavna: šta se promenilo, kada, ko je odobrio i koje sisteme je to zahvatilo? Kod ručnog postavljanja, na ova pitanja se često mora odgovoriti na osnovu e-mailova, chat poruka, ličnih sećanja i nepotpunih beleški.

U disciplinovanom procesu postavljanja, izdanje je identifikovano, izvršenje zabeleženo, a kontrolne tačke unapred definisane. Ovo nije birokratija radi birokratije. U slučaju prekida rada, skraćuje vreme nesigurnosti i na nivou rukovodstva čini jasnijim da li greška zaista potiče iz nove promene, problema sa kvalitetom podataka ili već postojećeg operativnog odstupanja.

Brže i sigurnije obnavljanje

Plan vraćanja mnoge organizacije počinju tražiti tek kada kritična usluga već padne. Međutim, pitanje se mora pojaviti pre svakog značajnijeg izdanja: ako postoji problem s novom verzijom, pod kojim uslovima i koliko brzo se vraćamo u poznato, funkcionalno stanje?

Determinističko postavljanje ne daje automatsku garanciju za ovo. Kod izmena baze podataka, na primer, vraćanje može biti složeno, posebno ako su u međuvremenu nastale nove transakcije. Međutim, stvara tehničku osnovu za obnavljanje: poznata prethodna verzija, kontrolisani koraci postavljanja, dokumentovane zavisnosti i jasne tačke odlučivanja su dostupne.

Ovo je vrednije za kontinuitet poslovanja nego naizgled brzo rešenje koje može izvršiti samo jedan ključni čovek. Ako je ta osoba na odmoru, bolesna ili se jednostavno ne seća ručne korekcije primenjene pre pola godine, izloženost kompanije odmah postaje vidljiva.

Predvidljivije upravljanje promenama

U rastućim kompanijama, razvoj sistema često se gomila pod operativnim pritiskom. Novi zahtev klijenta, izuzetak u skladištu, pravilo fakturisanja ili proizvodni izveštaj ulazi u red, a zatim se promena mora što brže implementirati. Problem nije brzina, već brzina bez kontrole.

Ako je izdanje ponovljivo, tada se promena može podeliti na manje jedinice, testirati i odobriti. Rukovodilac ne mora da se upušta u tehničke detalje, ali može videti šta se izdaje, koji poslovni proces je zahvaćen, ko je proverio i koja je mogućnost povratka. Ovo je posebno korisno u okruženju gde sistemska greška može istovremeno usporiti prijem narudžbina, komisioniranje i finansijsku administraciju.

Nije potrebno sve procese ponovo izgraditi odjednom

Uvođenje determinističkog postavljanja ne mora nužno značiti kompletnu zamenu platforme ili dugotrajan infrastrukturni projekat. Često je prvi koristan korak otkriti kako se trenutno promena implementira u produkciju.

Koji korak je manuelan? Gde se nalazi stvarna konfiguracija? Postoji li razlika između testnog i produkcionog sistema? Ko je ovlašćen za postavljanje? Šta se dešava ako izdanje ne uspe na pola puta? Postoji li operacija koju samo jedna osoba zna?

Ova pitanja često otkrivaju više o operativnom riziku nego opšti tehnološki audit. Može se desiti da najveći rezultat ne donosi novi alat, već odobrena kontrolna tačka postavljanja, centralizovano upravljanje konfiguracijama ili disciplinovanije verzionisanje izmena baze podataka.

Gde je potrebna posebna pažnja?

Automatizacija postavljanja sama po sebi ne čini loše definisan proces boljim. Ako nije jasno šta znači status narudžbine, ko poseduje podatke o klijentima ili u kojim slučajevima integracija može prepisati podatke, brže izdanje samo brže prenosi pogrešan rad.

Posebnu pažnju zahtevaju promene baze podataka, veze sa spoljnim sistemima i integracije koje rade po rasporedu ili asinhrono. Na primer, kod sinhronizacije zaliha između webshopa i ERP-a , nije dovoljno proveriti da li je postavljanje bilo uspešno. Takođe treba videti da li narudžbine, zalihe i rukovanje greškama funkcionišu prema očekivanjima nakon promene.

Previše krut proces takođe nije cilj. Manja interna izmena izveštaja ne bi trebalo da zahteva isti nivo odobrenja kao promena u fakturisanju ili upravljanju proizvodnjom. Odgovarajući nivo kontrole treba uspostaviti na osnovu poslovnog uticaja, težine vraćanja i broja zahvaćenih sistema.

Kako započeti?

Prvo odaberite sistem ili integraciju gde su izdanja redovna, broj ručnih koraka visok ili greška direktno utiče na operaciju. Ne mora biti najveći sistem, ali treba biti dovoljno značajan da poboljšanje bude merljivo.

Zatim je korisno zabeležiti trenutni put izdavanja prema stvarnom radu, a ne prema pretpostavljenom procesu. Razlika je obično poučna. U mnogim organizacijama tada se otkriva da konfiguracija nije verzionisana, dozvole su preširoke ili nema odgovorne osobe za poslovnu proveru nakon implementacije.

Sledeći korak može biti uspostavljanje ponovljivog procesa postavljanja, sa jasnim kontrolama i dokumentovanim procedurama vraćanja. CGAT u ovakvim situacijama ne ispituje samo alate za postavljanje, već i koji poslovni proces sistem podržava i gde je tehničku kontrolu zaista potrebno ojačati.

Dobra instalacija nije dobra zato što je spektakularno automatizovana. Dobra je zato što nakon promene kompanija tačno zna šta radi u njenim sistemima, zašto tako radi i šta može sigurno promeniti kada operacija zahteva sledeći korak.