De ce nu mai putem trata IT-ul ca pe o problemă secundară

În multe companii, infrastructura IT este observată cu adevărat abia atunci când ceva nu mai funcționează: nu se mai poate accesa aplicația de gestiune, nu se mai trimit facturi, nu mai funcționează emailul, serverul nu mai pornește, datele nu mai sunt disponibile sau cineva constată că ultimul backup valid este de acum câteva luni.

Până în acel moment, totul pare „în regulă”.

Realitatea este însă diferită: pentru majoritatea companiilor, serviciile electronice nu mai sunt doar un ajutor administrativ. Ele sunt coloana vertebrală a activității zilnice. Comenzi, contracte, facturi, documente, evidențe de stoc, relații cu clienții, programări, dosare de achiziții, rapoarte, semnături electronice, comunicări interne — toate depind de sisteme digitale.

Dacă aceste sisteme se opresc, compania nu are doar o problemă tehnică. Are o problemă operațională, financiară, juridică și de imagine.

Ce înseamnă, concret, să nu mai ai acces la date

Pierderea accesului la date nu înseamnă întotdeauna că datele au fost șterse definitiv. Uneori înseamnă că:

  • serverul există, dar nu mai pornește;
  • aplicația funcționează, dar baza de date este coruptă;
  • backupul există, dar nu a fost testat niciodată;
  • parola administratorului nu mai este cunoscută;
  • furnizorul nu mai răspunde;
  • licența a expirat;
  • domeniul sau certificatul SSL nu a fost reînnoit;
  • un atac ransomware a criptat fișierele;
  • datele sunt în cloud, dar nimeni nu știe cum se exportă;
  • există copii, dar nu se știe care este ultima versiune corectă.

Pentru o companie, efectele pot fi rapide și dureroase: facturile nu se emit, comenzile nu se procesează, angajații nu pot lucra, clienții nu primesc răspuns, termenele contractuale sunt ratate, documentele nu pot fi prezentate la control, iar deciziile se iau „pe ghicite”, fără informații actualizate.

În cazuri mai grave, pierderea datelor poate însemna pierderea istoricului comercial, a documentelor justificative, a trasabilității operaționale sau a încrederii clienților.

De ce nu este suficient să „sunăm pe cineva” când apare problema

O reacție frecventă în companii este: „Dacă se întâmplă ceva, sunăm un prieten care se pricepe la IT” sau „Chemăm atunci o firmă să rezolve”.

Această abordare poate funcționa pentru probleme simple: o imprimantă blocată, un calculator care merge greu, o configurare minoră. Dar nu funcționează atunci când vorbim despre sisteme critice, date importante sau întreruperi majore.

Când apare o criză IT, timpul pierdut pentru a înțelege situația este adesea mai costisitor decât intervenția tehnică propriu-zisă. Persoana chemată trebuie să afle:

  • ce sisteme există;
  • unde sunt găzduite;
  • cine are acces;
  • unde sunt parolele;
  • ce backupuri există;
  • ce servicii sunt critice;
  • ce trebuie repornit primul;
  • ce date pot fi restaurate;
  • cine ia decizia de oprire, restaurare sau migrare;
  • ce furnizori trebuie contactați.

Dacă aceste informații nu sunt documentate, intervenția începe în ceață. În loc să stingem incendiul, pierdem timp căutând hidrantul.

În IT, improvizația este scumpă. Iar în situații de criză, improvizația poate transforma o problemă rezolvabilă într-o întrerupere de zile sau într-o pierdere reală de date.

Ce sunt procedurile IT și de ce trebuie testate

O procedură IT nu este un document făcut doar „ca să existe”. O procedură bună răspunde la întrebări foarte practice:

  • Ce facem dacă nu mai funcționează internetul?
  • Ce facem dacă serverul principal cade?
  • Ce facem dacă aplicația de gestiune nu mai pornește?
  • Cine are voie să restaureze un backup?
  • Unde sunt salvate copiile de siguranță?
  • Cât timp putem funcționa fără acel sistem?
  • Care sunt datele pe care nu ne permitem să le pierdem?
  • Cum verificăm dacă backupul este utilizabil?
  • Cine anunță conducerea, angajații, clienții sau furnizorii?
  • Care este ordinea de recuperare a serviciilor?

Dar o procedură netestată este doar o presupunere frumos redactată.

De exemplu, multe companii cred că au backup. Dar nu au testat niciodată restaurarea. Diferența este enormă. Backupul înseamnă că undeva există o copie. Restaurarea testată înseamnă că știm sigur că acea copie poate fi folosită, în cât timp, de către cine și cu ce pierdere de date.

În practică, nu contează doar dacă avem backup. Contează:

  • cât de des se face;
  • unde se salvează;
  • cine îl verifică;
  • dacă este protejat împotriva ștergerii sau criptării;
  • cât durează restaurarea;
  • ce date se pierd între ultimul backup și momentul incidentului;
  • dacă aplicația poate fi repornită pe alt server;
  • dacă există documentație pentru recuperare.

Evaluarea de risc: primul pas înainte de a cumpăra soluții

Multe companii încep invers: cumpără un antivirus, un NAS, un server, un abonament cloud sau o soluție de backup, fără să știe exact ce risc vor să reducă.

O abordare sănătoasă începe cu evaluarea de risc.

Evaluarea de risc nu trebuie privită ca un exercițiu birocratic. Este o discuție structurată despre ce se poate întâmpla, cât de probabil este, cât de grav ar fi impactul și ce măsuri merită luate.

Întrebările de bază sunt simple:

  • Ce sisteme folosim zilnic?
  • Care dintre ele sunt critice?
  • Ce se întâmplă dacă nu funcționează o oră?
  • Ce se întâmplă dacă nu funcționează o zi?
  • Ce se întâmplă dacă pierdem datele din ultimele 24 de ore?
  • Ce se întâmplă dacă pierdem toate datele?
  • Cine are acces administrativ?
  • Avem parolele documentate și securizate?
  • Există backup?
  • Backupul a fost restaurat vreodată?
  • Avem furnizori de care depindem complet?
  • Avem contracte clare cu acești furnizori?
  • Avem o persoană responsabilă intern?

Răspunsurile la aceste întrebări arată unde sunt vulnerabilitățile reale. Uneori soluția nu este o investiție mare, ci o procedură clară, o copie de siguranță verificată, o listă de acces actualizată sau un contract mai bine definit cu furnizorul IT.

Cum poate face o companie o autoevaluare fără să fie specialist IT

Nu trebuie să fii IT-ist ca să înțelegi dacă firma ta este expusă. Trebuie doar să privești IT-ul din perspectiva activității zilnice.

Un exercițiu simplu este să faci o listă cu toate serviciile electronice folosite în companie:

  • email;
  • website;
  • domeniu;
  • aplicație de facturare;
  • ERP sau CRM;
  • aplicație de gestiune;
  • sistem de pontaj;
  • server de fișiere;
  • Google Workspace sau Microsoft 365;
  • semnătură electronică;
  • aplicații bancare;
  • platforme de ofertare sau achiziții;
  • sisteme de backup;
  • echipamente de rețea;
  • camere video;
  • soluții cloud.

Apoi, pentru fiecare serviciu, notează câteva lucruri:

  1. Cine îl administrează?
  2. Cine are parola principală?
  3. Unde sunt datele?
  4. Există backup?
  5. Cine poate restaura datele?
  6. Cât timp putem lucra fără acel serviciu?
  7. Ce pierdere maximă de date este acceptabilă?
  8. Ce se întâmplă dacă furnizorul nu răspunde?
  9. Există o alternativă temporară?
  10. Când a fost testată ultima dată recuperarea?

Dacă la multe dintre aceste întrebări răspunsul este „nu știm”, atunci compania nu are doar o problemă IT. Are o problemă de management al riscului.

Când ar trebui să apelezi la un consultant

Un consultant IT bun nu ar trebui să vină direct cu o listă de produse de cumpărat. Ar trebui să înceapă prin a înțelege activitatea companiei, dependențele operaționale și nivelul de risc acceptabil.

Rolul consultantului este să ghideze compania prin întrebările corecte:

  • ce servicii sunt critice;
  • ce trebuie protejat prioritar;
  • ce proceduri lipsesc;
  • ce furnizori trebuie implicați;
  • ce trebuie documentat;
  • ce trebuie testat;
  • ce poate fi rezolvat intern;
  • ce trebuie externalizat;
  • ce investiții sunt justificate;
  • ce poate fi amânat fără risc major.

Un consultant nu înlocuiește echipa internă și nici furnizorii existenți. În mod ideal, îi ajută să lucreze mai clar, mai organizat și mai eficient.

În multe situații, valoarea consultantului nu este că „repară serverul”, ci că ajută compania să nu ajungă în situația în care totul depinde de o singură persoană, o singură parolă, un singur calculator sau un backup neverificat.

De ce procedurile IT sunt și o problemă de management, nu doar de tehnologie

Continuitatea serviciilor electronice nu este responsabilitatea exclusivă a departamentului IT. Conducerea companiei trebuie să știe care sunt riscurile și să decidă ce nivel de protecție este acceptabil.

Nu orice sistem are nevoie de aceeași protecție. Un website de prezentare poate tolera câteva ore de indisponibilitate. O aplicație de facturare, un sistem de gestiune, un portal pentru clienți sau o bază de date contractuală poate avea nevoie de recuperare rapidă.

De aceea, procedurile IT trebuie corelate cu realitatea businessului. Nu protejăm servere de dragul serverelor. Protejăm activitatea companiei, relația cu clienții, capacitatea de facturare, documentele, reputația și continuitatea operațională.

Un exemplu simplu: diferența dintre reacție și pregătire

Să presupunem că aplicația de gestiune nu mai funcționează luni dimineața.

Într-o companie fără proceduri, începe haosul:

  • cineva sună administratorul;
  • altcineva caută parola;
  • nu se știe unde este serverul;
  • furnizorul nu răspunde imediat;
  • nu se știe dacă există backup;
  • angajații așteaptă;
  • clienții nu primesc răspuns;
  • conducerea cere estimări pe care nimeni nu le poate da.

Într-o companie pregătită, pașii sunt clari:

  • se identifică incidentul;
  • se verifică impactul;
  • se contactează persoanele responsabile;
  • se consultă procedura de recuperare;
  • se verifică ultimul backup;
  • se decide restaurarea sau trecerea pe o soluție temporară;
  • se comunică intern;
  • se documentează incidentul;
  • după rezolvare, se actualizează procedura.

Diferența nu este doar tehnică. Diferența este de maturitate organizațională.

Ce ar trebui să conțină minim un set de proceduri IT

Pentru o companie care depinde de servicii electronice, un set minim de proceduri ar trebui să includă:

  1. Inventarul serviciilor și aplicațiilor critice
  2. Lista furnizorilor IT și a responsabililor interni
  3. Politica de backup și restaurare
  4. Procedura de testare periodică a backupurilor
  5. Procedura de acces administrativ și gestiune parole
  6. Procedura de răspuns la incidente
  7. Planul de continuitate pentru serviciile critice
  8. Procedura de onboarding și offboarding pentru angajați
  9. Reguli minime de securitate pentru echipamente și conturi
  10. Calendar de verificări periodice

Aceste documente nu trebuie să fie complicate. Mai bine o procedură simplă, clară și folosită, decât un dosar perfect pe care nu îl citește nimeni.

Concluzie

Procedurile IT bine definite și testate nu sunt un lux pentru companii mari. Sunt o formă de igienă operațională pentru orice organizație care depinde de date și servicii electronice.

Adevărata întrebare nu este dacă va apărea vreodată o problemă IT. Întrebarea este ce se întâmplă când apare: compania reacționează organizat sau improvizează sub presiune?

La ProcessIQ Consulting, abordăm IT-ul din perspectiva continuității activității, a riscului și a proceselor clare. Ajutăm companiile să identifice serviciile critice, să documenteze proceduri, să evalueze riscurile și să decidă ce trebuie făcut intern, ce trebuie externalizat și unde este nevoie de suport specializat.

Pentru companiile care nu își permit blocaje, pierderi de date sau intervenții improvizate, primul pas nu este să cumpere încă o soluție. Primul pas este să înțeleagă riscul și să aibă un plan testat.

Taguri
#proceduri IT#continuitate operațională#backup#risk assessment#securitate IT#ProcessIQ
CH
Csaba Hitter
Consultant IT · ProcessIQ Consulting