The initial motivation

Per comprendere il SaaS, iniziamo con un'idea abbastanza semplice di ciò che stiamo cercando di ottenere quando creiamo un'attività SaaS. Il miglior punto di partenza è osservare come il software tradizionale (non SaaS) è stato creato, gestito e gestito.

Il diagramma seguente fornisce una panoramica concettuale di come diversi fornitori hanno confezionato e fornito le proprie soluzioni.

Il modello classico per il confezionamento e la fornitura di soluzioni software

In questo diagramma, abbiamo descritto una serie di ambienti dei clienti. Questi clienti rappresentano le diverse società o entità che hanno acquistato il software di un fornitore. Ciascuno di questi clienti opera essenzialmente in un ambiente autonomo in cui ha installato un prodotto del fornitore di software.

In questa modalità, l'installazione di ogni cliente viene considerata come un ambiente indipendente dedicato a quel cliente. Ciò significa che i clienti si considerano i proprietari di questi ambienti e potenzialmente richiedono personalizzazioni una tantum o configurazioni uniche che soddisfino le loro esigenze.

Un effetto collaterale comune di questa mentalità è che i clienti possono controllare la versione di un prodotto che utilizzano. Questo problema può verificarsi per una serie di motivi. I clienti potrebbero essere preoccupati per le nuove funzionalità o preoccupati per le interruzioni associate all'adozione di una nuova versione.

Potete immaginare come questa dinamica possa influire sull'impronta operativa del fornitore del software. Più consenti ai clienti di avere ambienti unici, più diventa difficile gestire, aggiornare e supportare le diverse configurazioni di ciascun cliente.

Questa esigenza di ambienti unici richiede spesso alle organizzazioni di creare team dedicati che forniscano un'esperienza gestionale e operativa separata per ogni cliente. Sebbene alcune di queste risorse possano essere condivise tra i clienti, questo modello generalmente introduce spese incrementali per ogni nuovo cliente che viene inserito.

Anche il fatto che ogni cliente esegua le proprie soluzioni nel proprio ambiente (nel cloud o in locale) influisce sui costi. Sebbene sia possibile tentare di scalare questi ambienti, la scalabilità sarà limitata all'attività di un singolo cliente. In sostanza, l'ottimizzazione dei costi è limitata a ciò che è possibile ottenere nell'ambito di un singolo ambiente del cliente. Significa anche che potresti aver bisogno di strategie di scalabilità separate per soddisfare le variazioni di attività tra i clienti.

Inizialmente, alcune aziende di software considereranno questo modello un potente costrutto. Utilizzano la capacità di fornire personalizzazioni una tantum come strumento di vendita, consentendo ai nuovi clienti di imporre requisiti unici per il loro ambiente. Sebbene il numero di clienti e la crescita del business rimangano modesti, questo modello sembra perfettamente sostenibile.

Man mano che le aziende iniziano ad avere un successo più ampio, tuttavia, i vincoli di questo modello iniziano a creare sfide reali. Immagina, ad esempio, uno scenario in cui la tua azienda raggiunga un picco di crescita significativo che ti porti ad aggiungere molti nuovi clienti a un ritmo rapido. Questa crescita comincerà ad aumentare il sovraccarico operativo, la complessità della gestione, i costi e una serie di altri problemi.

In definitiva, il sovraccarico e l'impatto collettivi di questo modello possono iniziare a minare radicalmente il successo di un'azienda di software. Il primo punto dolente potrebbe essere l'efficienza operativa. L'aumento del personale e dei costi associati all'acquisizione di clienti iniziano a erodere i margini dell'azienda.

Tuttavia, i problemi operativi sono solo una parte della sfida. Il vero problema è che questo modello, man mano che si espande, inizia a influire direttamente sulla capacità dell'azienda di rilasciare nuove funzionalità e di stare al passo con il mercato. Quando ogni cliente dispone del proprio ambiente, i provider devono bilanciare una serie di requisiti di aggiornamento, migrazione e clienti nel tentativo di introdurre nuove funzionalità nel proprio sistema.

Questo porta in genere a cicli di rilascio più lunghi e complessi, che tendono a ridurre il numero di rilasci che vengono rilasciati ogni anno. Ancora più importante, questa complessità fa sì che i team dedichino più tempo all'analisi di ogni nuova funzionalità molto prima che venga rilasciata a un cliente. I team iniziano a concentrarsi maggiormente sulla convalida di nuove funzionalità e meno sulla velocità di consegna. L'onere derivante dal rilascio di nuove funzionalità diventa così significativo che i team si concentrano maggiormente sulla meccanica dei test e meno sulle nuove funzionalità che guidano l'innovazione della loro offerta.

In questa modalità più lenta e prudente, i team tendono ad avere tempi di ciclo lunghi che creano un divario sempre maggiore tra l'inizio di un'idea e il momento in cui arriva nelle mani di un cliente. Nel complesso, ciò può ostacolare la capacità di reagire alle dinamiche del mercato e alle pressioni concorrenziali.