Proposal Management – Criteri da utilizzare

Questo articolo nasce con l’obiettivo di fornire qualche utile consiglio a chi intende  portare una proposta tecnica in un’azienda indipendentemente se sia un dipendente interno o un fornitore.
Il  principale problema che dovrete gioco forza affrontare è quello di convincere un manager che, il più delle volte parlerà un linguaggio diverso dal vostro. Un ingegnere IT o, più ingenerale un progettista IT, è portato a valutare un investimento sulla base delle sue carateristiche tecniche, della sua affidabilità, dell’esercibilità del prodotto e della modularità della soluzione. Tutto ciò in azienda non vi basterà perché nessuno consentirà di inserire il vostro investimento all’interno del budget basandosi sulle caratteristiche suddette.
Già nella fase di proposta è necessario avere in mente, a grandi linee, quello che sarà il business case che supporterà il vostro progetto.
Non è mia intenzione fornire in questa sede una guida alla compilazione dei business case ma solo di fornire dei concetti chiave che dovrete tener presente già in sede di “proposal management”. In questo tentativo farò delle sempificazioni che non sfuggiranno all’occhio attento di uno specialista del mondo finance ma che sono necessarie per evitare di sconfinare in tematiche non propriamente IT.
Mentre voi farete la vostra presentazione tecnica dimostrando l’assenza dei “Single Point of Failures” e disquisendo della tolleranza ai fault della vostra soluzione il vostro direttore IT si farà queste domande:

• Questa soluzione mi farà ridurre le OPEX?
• Il fatturato della nostra azienda migliorerà?
• Ci sono dei costi che posso evitare il prossimo anno a fronte di questo investimento?
• La produttività degli utenti migliorerà? E di quanto migliorerà?
• La cassa della nostra azienda migliorerà?

Se invece avete di fronte un CSO (Chief Security Officer) o un Compliance Manager si chiederà:

• Quali rischi vado a mitigare o ad evitare con questa soluzione?
• Quali compliance interne metto a posto?
• Assolvo a qualche obbligo di legge?

In realtà un CFO (Chief Financial Officer) o qualcuno che ha qualche rudimento di risk management quest’ultime tre domande se le pone in modo diverso cercando di monetizzare anche gli eventi non certi. Quindi si chiederà:

• Quali sono i rischi, la probabilità che si verifichino e l’impatto del danno?
• Quanto mi costerebbe se qualche autorità scoprisse la mia non compliance?
• Cosa rischio dal punto di vista civile e penale se non lo faccio? Che danno d’immagine avrò?

Questo non vuol dire che la buona progettazione di un sistema o di un’architettura IT non serva ma solo che gli elementi decisionali sono altri e che prima ancora di mettersi a progettare è importante capire i bisogni dell’interlocutore che abbiamo di fronte.
Dopo vent’anni passati dietro una scrivania a vedere presentazioni di fornitori che, dopo la classiche slide di marketing, ti propongono la lista dei prodotti e dei servizi a portafoglio posso dire, senza ombra di dubbio, che le considerazioni fatte valgono anche e soprattutto per chi va da un cliente per proporre le proprie soluzioni o per pubblicizzare i propri skill.
Già da qualche anno i più grandi fornitori di hardware non si limitano a proporre l’acquisto di nuove macchine ma propongono ad esempio un leasing finanziario o un noleggio operativo con rata annua inferiore ai costi di manutenzione delle vecchie mcchine. Il tutto corredato da un “Buy back” del vecchio hardware per aumentare la liquidità in cassa dell’azienda cliente o per eliminare i costi di ammortamento.

A prescindere dalla prospettiva sbagliata di chi non ha una visione d’insieme, il nostro obiettivo è quello di integrare la visione tecnica con informazioni di business rendendo vendibile una soluzione o un prodotto.

Vale la pena concentrasi su qualche  esempio per dare una connotazione più pratica a quanto detto.

Per prima cosa analizziamo un caso semplice come la proposta di acquisto di un apparato hardware per un rinnovo tecnologico. Tale proposta non può prescindere dalla conoscenza dei costi correnti del vecchio hardware da sostituire.

A fronte di alti costi ricorrenti del vecchio hardware e di un altro valore residuo (bene non completamente ammortizzato) e magari con una situazione di bassa liquidità di cassa, potrebbe aver senso un’operazione di buy-back del vecchio hardware con un noleggio del nuovo hardware con rata inferiore alla rata corrente. A fronte di altri costi ricorrenti del vecchio hardware che però risulti completamente ammortizzato, dove l’azienda è più focalizzata su obiettivi di EBITDA piuttosto che di EBIT (vedi oltre per la spiegazione) è il caso di proporre una soluzione basata su di un leasing finanzirio con il bene che verrà capitalizzato anno dopo anno.

Non voglio in questa sede atteggiarmi ad esperto di finanza aziendale perché tale non sono. Ciò nonostante è bene che sappiate che volenti o nolenti chiunque di voi si affacci in azienda dovrà fare i conti con questi due indici di bilancio.

l’EBITDA indica l’utile o le perdite dell’azienda prima delle tasse e dell’ammortamento mentre l’EBIT viene calcolato sotraendo anche i costi dell’ammortamento e delle tasse.

Nelle start-up dove i costi di ammortamento sono molto alti, si tende a valutare la salute dell’azienda verificando anno per anno la crescita dell’EBITDA.

Quindi la regola generale è: “Ricordarsi sempre di valutare l’impatto della vostra soluzione sull’EBIT e sull’EBITDA” e se non si hanno informazioni sulla strategia aziendale presentare più opzioni al vostro interlocutore.

Quanto sopra riporta il caso di benefici tangibili ovvero saving sui costi reali ma non è detto che la vostra soluzione porti dei benefici tangibili.

A tal proposito un altro esempio può chiarire l’approccio da tenere in questi casi.

Come secondo caso consideriamo una proposta di soluzione per mitigare il rischio di un attacco informatico da internet. Questa soluzione porterà all’azienda un costo e non presenta benefici tangibili perché non ci sono asset da dismettere.

 

La “valorizzazione” dei ritorni per i progetti di sicurezza IT è ben descritta in ROSI.

Ciò nonostante già in sede di “proposal management” è opportuno fare una valutazione dell’eventuale danno causato dalla minaccia da cui cerchiamo di proteggerci. In altre parole presentiamoci subito con un “assessment” del rischio indicando la probabilità che si verifici l’evento e l’impatto in termini economici.

Anche in questo caso un esempio può chiarire. Un sistema IT a protezione dal rischio di cyber attacco protegge da un evento che ha una probabilità ad esempio del 10% (10 aziende su 100 sono colpite da questo tipo di attacco) e da un impatto di perdita del 10 % dei clienti (supponendo un furto dei dati poi venduti alla concorrrenza).

Sulla Sicurezza IT e sulla valuatazione del business case relativo verrà a breve pubblicato un articolo per cui non mi dilungo più di tanto.

La deriva secondo il sottoscritto molto pericolosa per le aziende è che l’aspetto tecnico progettuale venga considerato erroneamente un servizio di commodity un qualcosa che deve funzionare a prescindere e che sia solo l’aspetto economico finanziario a determinare una scelta. Basti pensare a quanti e quali disservizi potrebbe portare una soluzione non progettata in modo adeguato e che impatti possa dare sul business di un’azienda oppure ai costi indotti di test d’integrazione non adeguati.

Oltretutto I processi di globalizzazione, il continuo ricorso all’outsourcing, la presenza di numerosi fornitori specializzati in aree verticali e i processi di “merger e acquisition” portano l’ingegnere d’azienda a confrontarsi con realtà molto complesse dove l’integrazione di mondi molto diversificati è un servizio che richiede conoscenze ad ampio spettro (procedurali, linguistiche, culturali etc etc).

Tutto ciò rende decisamente sfidante la progettazione di un sistema IT che sebbene  lontano da potersi considerare una commodity, non può prescindere dai criteri di sostenibilità aziendali.