Gestire in maniera corretta i sistemi SAP per ridurre gli incident non vuol dire riuscire a minimizzare solo i fermi propriamente detti. Al contrario di quanto si tende a pensare, infatti, gli incident sono forse ancora più temibili nel momento in cui generano eventi che non si riducono semplicemente allo shutdown di un programma o di un'applicazione. Specialmente nel mondo del business, e in particolar modo nell'era digitale, in cui la capacità di restituire feedback immediati agli utenti è fondamentale per mantenere il proprio vantaggio competitivo, il termine “fermo” può assumere svariati significati: può per esempio manifestarsi anche con la lentezza dei sistemi nel rispondere, che all'atto pratico si traduce in mancanza di fruibilità, in quanto percepita dall'utente finale come indisponibilità della macchina.
In altre parole, un fenomeno che osservato dal punto di vista del responsabile IT o del CTO e parte dell'ordinaria amministrazione può essere considerato trascurabile, può invece rappresentare un problema anche rilevante per i collaboratori o – peggio ancora – per i clienti. E a prescindere dalla definizione che gli si dà, deve essere per quanto possibile arginato.
Perché a volte incident di poco conto sono percepiti come fermi veri e propri
Calare il concetto sul piano pratico con un esempio reale rende l'idea meglio di qualsiasi descrizione teorica. In un'azienda di progettazione meccanica, molti utenti avevano cominciato a sperimentare diversi problemi nel momento in cui utilizzavano una postazione CAD che era stata collegata a SAP. Ogni volta che veniva aggiunto un elemento al disegno e si effettuava il salvataggio, il sistema si bloccava completamente. O almeno, questa era la percezione dell'utente finale, che sperimentava un fermo che poteva durare anche svariati minuti. Una situazione che gli utenti coinvolti dal disservizio non esitavano a definire “snervante”. Trovare il bandolo della matassa in questa specifica situazione ha voluto dire superare l'idea che per l'appunto si trattasse di un fermo in senso stretto, ma che potesse essere un evento generato dal concatenarsi di più incidenti o errori di varia natura. Per evitare questi problemi con SAP esiste solo un metodo, basato su due azioni: prevenzione e test.
Nel caso specifico, in effetti, era mancata una vera e propria sessione di verifica propedeutica al roll out di un prodotto aggiuntivo, recentemente implementato nella piattaforma CAD. Non erano state testate – o non erano state testate nel modo giusto – le nuove funzionalità connesse a SAP e per questo, su disegni complessi, la concomitanza di piccoli incident tendeva a produrre un problema che, almeno dagli utenti, veniva percepito come serio, mentre lato IT non generava alcun tipo di alert.
Cosa fare per ridurre al minimo gli incident nei sistemi SAP
Ma come fare a prevenire situazioni del genere? Esiste una roadmap precisa che consente a qualsiasi impresa di affrontare con maggiore serenità il tema degli incident nei sistemi SAP, e consiste fondamentalmente in sei mosse:
- Identificare i problemi ricorrenti e indirizzarne la risoluzione;
- Testare le modifiche in modo esaustivo secondo delle procedure di verifica documentate;
- Schedulare le change evolutive in modo sistematico e programmato;
- Monitorare i parametri vitali del sistema in termini di capacità (CPU, memoria, Disco);
- Distribuire il carico di lavoro su più macchine e diluirlo in termini di collocazione temporale, nei limiti delle esigenze del business;
- Mantenere basso, nei limiti del possibile, il numero di personalizzazioni e sviluppi custom.
L'importanza di effettuare test esaustivi sulle modifiche apportate ai sistemi
L'abitudine di chiedere nuove funzionalità senza testare le modifiche in modo esaustivo è purtroppo assai diffusa. La pratica spesso può risultare non efficiente anche perché i test effettuati non sono documentati adeguatamente. Poche aziende in effetti hanno elaborato procedure di test rigorose, che comprendano cioè un set di azioni ben definite da mettere in atto nel momento in cui si decide di apportare al sistema SAP modifiche di natura tecnica. Un'altra buona pratica troppo disattesa è quella di schedulare l'import delle modifiche in determinati orari e giorni alla settimana, tipicamente quando i sistemi sono scarichi, in modo da limitare le eventuali correzioni da fare quando la piattaforma è a regime ai soli interventi di massima urgenza.
Il valore della collaborazione con i colleghi del business
Va detto che anche effettuando test accurati e pianificando con intelligenza le attività di roll out e verifica delle soluzioni, quando si parla di riduzione degli incident non sempre è facile trovare l’origine del problema. Per individuare l'assetto migliore, il più delle volte per un CTO è imprescindibile la collaborazione dei colleghi del business, che devono rispondere a una serie di domande utili a identificare possibili colli di bottiglia. Quali job, per esempio, sono davvero indispensabili allo svolgimento sicuro, efficiente ed efficace di ciascuna attività? Riuscire a eliminare le operazioni superflue non è cosa da poco: aiuta a ridurre sensibilmente gli errori sistematici, che sono poi quelli che possono dare più fastidio.
Personalizzare troppo il sistema SAP non conviene
L'ultima avvertenza riguarda le personalizzazioni. SAP ha da sempre messo in chiaro che il suo ecosistema offre alle imprese determinate prestazioni e livelli di qualità se le imprese adeguano la propria modalità operativa alla logica del vendor. Scegliere SAP per stravolgere l'architettura, peggiorandola e appesantendola, è il modo migliore per incorrere in incident e disservizi: si può dire che il 99% dei problemi derivi da questo approccio. È come mettere mano in un motore e cambiarne le caratteristiche.
