Cum să introducem puncte de control arhitecturale?

O nouă integrare a magazinului online, un terminal de depozit sau un sistem de colectare a datelor de producție rareori reprezintă o singură schimbare. Afectează ERP-ul, permisiunile, rețeaua, rapoartele și adesea pași manuali despre care nimeni nu știa că există. Prin urmare, întrebarea nu este doar cum să introducem puncte de control arhitecturale, ci și: când trebuie să ne oprim înainte de a lua o decizie, cine ar trebui să verifice și pe baza căror dovezi poate fi permisă schimbarea?

Punctul de control arhitectural nu este un cerc de aprobare inutil. Bine conceput, este o verificare scurtă și prestabilită care împiedică o cerință locală să devină ulterior o problemă operațională la nivel de sistem. Este deosebit de valoros acolo unde funcționarea companiei se bazează deja pe mai multe sisteme, furnizori, locații și cunoștințe ale persoanelor cheie.

De ce deraiază schimbările?

Majoritatea erorilor nu apar pentru că un dezvoltator sau un operator nu a înțeles tehnologia. Este mult mai frecvent ca decizia să fie luată dintr-o perspectivă prea îngustă. Departamentul comercial solicită procesare mai rapidă a comenzilor, depozitul ar introduce cititoare de coduri de bare, iar IT-ul dorește să înlocuiască un server vechi. Fiecare cerință poate fi justificată, dar niciuna nu este independentă de celelalte.

Să luăm un exemplu care pare simplu. Datele comenzilor primite din magazinul online trebuie transmise către ERP și apoi către sistemul de depozit. Dacă integrarea verifică doar dacă comanda trece, pot fi ușor omise excepțiile: ce se întâmplă în cazul livrărilor parțiale, anulărilor, lipsei de stoc, adreselor greșite sau atunci când ERP-ul nu este temporar disponibil? Cine observă eroarea, unde este vizibilă și cine o poate corecta?

Fără un punct de control, aceste întrebări apar de obicei după lansarea în producție. În astfel de cazuri, echipa menține afacerea în mișcare cu ajutorul tabelelor, e-mailurilor și corecțiilor manuale. Acest lucru ajută pe termen scurt, dar între timp se dezvoltă un nou proces invizibil, care se bazează ulterior pe cunoștințele unui singur angajat.

Ce ar trebui să verifice un punct de control arhitectural?

Scopul nu este ca fiecare detaliu tehnic să fie discutat de o comisie. Punctul de control trebuie să scoată la suprafață acele decizii care ulterior pot cauza costuri, întreruperi, probleme de date sau dependențe dificil de întreținut.

O verificare bună se construiește în jurul a patru întrebări. În primul rând: ce problemă de afaceri rezolvă schimbarea și este cu adevărat necesar fiecare pas planificat al procesului? În al doilea rând: ce sisteme, date, roluri și conexiuni externe sunt afectate? În al treilea rând: cum funcționează în caz de eroare, încărcare sau întrerupere parțială? În al patrulea rând: cine va opera, supraveghea și dezvolta peste șase luni?

Acestea nu sunt întrebări teoretice. Dacă o nouă aplicație menține un registru separat al clienților, în timp ce în ERP există deja unul, atunci nu este vorba doar de un model de date. Apare întreținerea datelor duplicate, rapoarte diferite și discuția despre care sistem este sursa adevărului. Dacă un proces este legat de încărcarea manuală a fișierelor, soluția tehnică poate părea ieftină, dar costul operațional se va reflecta rapid în administrație.

Cum să introducem puncte de control arhitecturale în practică?

Începeți cu frecările recurente

Nu este necesar să scrieți un regulament complet de arhitectură a întreprinderii în prima zi. Este recomandat să examinați acele schimbări care deja generează multe discuții, corecții manuale sau surprize ulterioare.

Acestea pot include achiziționarea unui nou sistem, modificarea semnificativă a unui sistem existent, parteneriat extern, transfer de date nou, mutarea infrastructurii sau conectarea unei noi locații. De obicei, în câteva luni devine clar unde sunt necesare controale regulate.

Un punct de plecare bun nu este „toate dezvoltările trebuie aprobate”. Mai degrabă, peste un anumit prag, ar trebui să fie obligatorie o verificare scurtă. De exemplu, atunci când schimbarea afectează date personale sau critice din punct de vedere comercial, mută date între mai multe sisteme, poate cauza oprirea funcționării zilnice sau creează o nouă responsabilitate operațională.

Stabiliți câteva porți clare

O organizație de dimensiuni medii are adesea nevoie de trei puncte de control. Primul are loc la inițiere, înainte de alegerea finală a soluției. Aici trebuie clarificat care este scopul operațional, ce proces este afectat de schimbare și dacă există o soluție mai simplă.

Al doilea punct este aprobarea planului de implementare. Aici se discută fluxul de date, integrarea, gestionarea permisiunilor, backup-ul, jurnalizarea, testarea și modul de restaurare. Nu toate proiectele necesită documentație extinsă, dar părțile implicate trebuie să înțeleagă același lucru despre funcționare.

Al treilea punct de control este înainte de lansare. Aici nu se pune problema dacă dezvoltarea este finalizată, ci dacă afacerea poate utiliza în siguranță. Este cunoscută ordinea de implementare, au fost desemnați responsabilii, au fost testate excepțiile critice și există o decizie privind momentul în care trebuie revenit la funcționarea anterioară?

Persoanele potrivite trebuie să fie prezente

Arhitectura nu este doar o temă IT. Pentru o decizie care afectează un proces de depozit, este nevoie de cineva care cunoaște desfășurarea reală a comisionării, excepțiile inventarului și problemele schimbului de tură. O integrare de facturare nu ar trebui decisă doar din punct de vedere tehnic dacă închiderea zilnică a finanțelor impune alte condiții.

Totuși, un cerc prea larg încetinește decizia. Participanții la punctul de control ar trebui să aibă roluri constante, nu invitați ocazionali: responsabil de procesul de afaceri, responsabil tehnic, reprezentant operațional și, după caz, responsabil de date sau securitate. Este important ca cineva să aibă drept de decizie clar, nu doar să se colecteze opinii.

Rezultatul punctului de control trebuie să fie o decizie, nu un proces-verbal

O verificare este utilă dacă la final se obține un statut clar: poate continua, poate continua cu modificări sau este necesară o investigație suplimentară. Întrebările deschise trebuie să aibă un responsabil și un termen limită. Fără acestea, punctul de control va fi doar o discuție formală, despre care toată lumea presupune că va fi rezolvată de altcineva.

Este recomandat să se folosească un formular de decizie scurt și uniform. Acesta să includă scopul de afaceri, sistemele implicate, responsabilul de date, principalele dependențe, riscurile, sarcinile operaționale și aprobarea. O pagină este adesea suficientă. Detaliile pot fi într-un plan tehnic separat, dar pentru decizia managerială, esențialul trebuie să rămână clar.

Scopul documentației nu este de a trage pe cineva la răspundere mai târziu. Este necesară pentru ca, peste un an, să fie clar de ce a fost construită o conexiune, pe ce presupuneri s-a bazat și cine este responsabil pentru întreținerea acesteia.

Nu construiți un sistem de management prea greu

Punctele de control au un cost: cer timp de la experți și încetinesc anumite decizii. Dacă aceeași detaliere este așteptată pentru modificarea unui câmp de raport și pentru înlocuirea unui întreg sistem de depozit, organizația va ocoli procesul mai devreme sau mai târziu.

Soluția este proporționalitatea. Pentru o schimbare cu risc scăzut, poate fi suficientă o verificare scrisă scurtă. Pentru o modificare mai mare, care afectează mai multe sisteme sau operațiuni critice , este justificată o revizuire mai detaliată și un plan de lansare. Esențial este ca regula să se adapteze riscului, nu cantității de documente.

În timpul implementării punctelor de control, examinați regulat și întrebările care se repetă. Dacă în fiecare proiect apare aceeași problemă - de exemplu, lipsește responsabilul de date, nu există un mediu de testare sau gestionarea erorilor este neclară - atunci nu este vorba de o problemă de proiect individuală, ci de o deficiență operațională. Aceasta ar trebui tratată ca o sarcină de dezvoltare separată.

Experiența CGAT arată că un bun control arhitectural nu îndepărtează tehnologia de afaceri. Dimpotrivă: conectează devreme perspectivele responsabililor de procese, operațiunilor și dezvoltării. Scopul nu este de a frâna schimbarea, ci de a asigura că creșterea nu vine cu noi ocoliri manuale și dependențe greu de desfăcut.