Newsgroup: it.lavoro.informatica
Titolo: Meglio fornire un prodotto come SaaS o in vendita?

Un saluto a tutti,
 
vorrei un vostro consiglio in merito alla situazione, comunque positiva e 
stimolante in cui mi sto trovando.
Dopo aver realizzato un prodotto software (principalmente web based) che 
potr� essere piazzato in ambito in ambito ufficio/piccola-media azienda, mi 
stavo chiedendo se puntare maggiormente su un'offerta SaaS, oppure 
un'offerta con vendita del prodotto ed installazione presso il cliente (con 
eventuale pacchetto di supporto a parte).
 
Si tratta di una situazione concreta in quanto a breve ci saranno alcune 
prime installazioni pilota, per cui entro al massimo un paio di mesi sar� 
necessario prendere decisioni chiare su quale tipo di offerta spingere.
 
Credo che una soluzione SaaS basata su un sistema di licenze per utente, sia 
pi� remunerativa, in quanto sul medio/lungo periodo si ha un rendimento 
stabile, piuttosto che avere solo l'incasso dell'acquisto, oltre magari un 
contratto di supporto.
Per� indubbiamente una versione di prodotto di tipo SaaS, comporta la 
necessit� di dotarsi di un'infrastruttura che va oltre il sito web, comporta 
dover pensare ai backup, al disaster recovery e comunque si porta dietro 
tutti i problemi di dover garantire un sistema di produzione.
 
Secondo voi nel rapporto tra benefici economici e complessit� di gestione, 
vendere il servizio come SaaS � vantaggioso o meno?
O quantomeno, quali sono i parametri principali da valutare per potersi dare 
una risposta.
L'installazione non � complessa in quanto si tratta di un "normale" ambiente 
Web Linux + Apache + Mysql +PHP.
 
Sarei interessato a conoscere la vostra opinione o, meglio ancora, le vostre 
esperienze.
 
Grazie,
Michele
 
 

 ambiente Web Linux + Apache + Mysql +PHP.
 
 
Come spesso accade, stai guardando la problematica solo dal punto di
vista tecnico.
Guardala anche dal punto di vista del cliente, dal punto di vista
markettaro: ai potenziali clienti piacerebbe di pi� avere il prodotto in
casa o un SaaS? Si fidano a usare un "ciaffo" online, mettendo i loro
dati personali "preziosi" in un server SaaS che non sta sotto il loro
naso? E cos� via...
 
E poi... perch� non percorrere entrambe le strade ?
Fai un'indagine di mercato e valuta...
 
M.

 gestione, vendere il servizio come SaaS è vantaggioso o meno?
 
Tendenzialmente la soluzione saas e' secondo me migliore, anche se si
dovrebbe conoscere meglio il sistema ed il target di cliente per dare una
risposta piu' precisa.
Da un punto di vista tecnico avere teoricamente un solo server (e non 100
diverse installazioni) riduce molto la complessita' a scapito, forse, di
qualche limite sulle personalizzazioni.
C'e' solo da vincere la resistenza di molti clienti che chiederanno subito:
"ma se non funziona la connessione come faccio?", "ma i miei dati dove
sono?". Oltre ad eventuali e corretti dubbi sul lock-in ed al fatto che
molti clienti preferiscono "il cd in mano" piuttosto che una specie di
affitto mensile.

Io punterei tutto sul software as a service.
Magari ti tagli una fetta di utenza ma il resto ti adorerà.
 

 esperienze.
 
posto che per rispondere bisogna valutare sia il tipo di servizio che il tipo di cliente, come considerazione generale ritengo il saas una soluzione migliore sia dal punto di vista del cliente che di quello del fornitore. 
dal punto di vista del cliente una volta superato il tabu di avere un servizio esterno diventa una strada in discesa, specie se gli viene prospettata l'assenza di un investimento iniziale e la possibilità di avere i costi dilazionati nel tempo.
dal punto di vista del fornitore ci sono ovviamente maggiori problematiche tecniche rispetto a prendere un server, piazzarlo dal cliente e tanti saluti. però direi che il ritorno è di gran lunga superiore sia in termini monetari che di livello di servizio, per cui personalmente avrei pochi dubbi.

Fai un'indagine di mercato e valuta...
 
Beh non facile, magari le installazioni pilota potranno dare indicazioni 
interessanti.
 
Michele 
 

affitto mensile.
 
Si, questo è vero, anche se per i servizi offerti dalla mia azienda vedo che 
certe soluzioni SaaS vengono prese per buone senza troppe storie. Posto che 
invece c'è sempre il cliente super scrupoloso che vuole il server nel 
proprio rack attaccato al suo UPS e con il suoi sistemi di monitoraggio 
collegati.
 
Michele 
 

Magari ti tagli una fetta di utenza ma il resto ti adorerà.
 
Ciao anonimo :)
 
Beh, tutto tutto no, perchè vi sono clienti che certamente vogliono la 
soluzione in house e perchè non dargliela!
A meno che non vi sia una convenienza economica nel rifiutare espressamente 
installazioni presso cliente così da dover gestire unicamente un SaaS, il 
che non lo escludo non essendo un esperto del settore.
 
Potrebbe davvero essere meglio rinunciare mettiamo al 30%-35% del mercato e 
scavarsi tutti i problemi dati dal gestire licenze utente, attivazioni, etc 
etc?
 
Michele 
 

 esperienze.
 
come puoi ben immaginarti non c'e' una risposta netta. In linea di
massima una soluzione SaaS è preferibile per quanto riguarda la
fidelizzazione del cliente e per assicurarsi regolarità di pagamenti,
e può essere anche un modo di acquisire più facilmente nuovi clienti
in quanto dilazionando il pagamento su un canone l'investimento da
parte dell'acquirente risulta meno oneroso.
Il lato negativo è che è necessaria una certa massa critica di utenti
per giustificare il maggior costo di infrastrutture e della loro
manutenzione. In parte questo può essere attenuato usando servizi
cloud, ma non eliminato, specie se si vogliono rispettare SLA un
minimo decenti.
Altro lato negativo può essere se nella logica di business del
venditore rientra, come spesso accade nelle realtà italiane, anche la
fornitura di HW e di servizi sistemistici "bundled" con il SW (in
poche parole, se il server da mettersi in casa glielo vendi te e poi
magari gli fai anche uscire un sistemista a chiamata quando capita,
non ti conviene passare a SaaS :^)).
 
bye!

 ci sono limitazioni di questo tipo, non so se sia il caso.
 
E' una limitazione di prestazioni che avrebbe senso solo in alcuni casi (ad
esempio un database relazionale su qui vengono eseguite molte query). In
rete si trovano alcuni benchmark su ebs vs hard disk tradizionali.
 
Per il resto sono piu' i vantaggi che gli svantaggi secondo me.

rete si trovano alcuni benchmark su ebs vs hard disk tradizionali.
 
eh ma infatti sarebbe questo il mio caso, quindi non posso partire con tali 
limitazioni.
Magari le query in scrittura non sono un numero elevato ma quelle in lettura 
sono abbastanza frequenti e comunque il tempo di risposta deve essere 
abbastanza basso.
 
Michele
 

non ti conviene passare a SaaS :^)).
 
In questo caso servizio puro, quindi comunque l ferro se lo procurerebbe il 
cliente.
 
Michele 
 

dubbi.
 
Eh si, diciamo che sicuramente come ritorno economico � maggiore.
 
M 
 

 [cut]
 
Non ho letto tutto, rispondo solo a questo poi più avanti farò un post più elaborato.
Sostanzialmente, devi offrire un servizio imbattibile sotto tot aspetto.
 
In pieno stile Gmail, o Zendesk.
Ti sogneresti mai di installare sui tuoi server servizi del genere?
Certo che no, sono perfetti dove stanno: "nella nuvola" (per quanto critichi il cloud, certe cose sono sensate).
 
Questa è la mia visione. Se ti spaventa la gestione sistematica di anche solo un singolo server, magari con failover/HA, allora magari la cosa non fa al tuo caso.
Ma se ti piace l'idea di utenti che ti pagano mensilmente per usufruire del tuo servizio, in cambio di un'applicazione sempre aggiornata, funzionale ed agibile, beh, secondo me non c'è che da "leccarsi le dita".
 
Uno dei modi migliori per far soldi secondo me :)
 
Ah, e la pirateria non esiste in questo mondo :) (poi probabilmente lavorando con aziende non è il tuo problema, però...)
 

 farm e su un server riesci ad ospitare un buon numero di clienti.
 
Dipende ovviamente dall'applicazione ma 150E al mese sono tantini eh...
 
Considera che salesforce con circa 60-100E ti da tutto il CRM senza limiti
di licenze e la licenza solitamente usata dalle medio-piccole (5-10 utenti)
va dai 5 ai 15E al mese.
E' ovvio che non puoi competere coi loro prezzi, pero' se hai molti clienti
disposti a pagare quelle cifre mensili sei fortunato :-)
A meno che non sia un applicazione molto di nicchia ma, in quel caso, cala
il numero di clienti e calano un po i vantaggi del saas.

il numero di clienti e calano un po i vantaggi del saas.
 
Il concetto di nicchia o meno è relativo per i nostri scopi, nel senso che 
con una possibilità di applicazione globale, anche interessare ad una 
piccola percentuale di realtà può essere più che sufficiente.
 
Michele
 
 
 

 all'intallazione onsite che al SaaS.
 
fammi capire hai progettato un applicazione con tutti i criteri del SaaS 
(multi tenant, gestione pagamenti mensili (fatture, e gestione CC), 
restore dati per singolo tenant, metriche varie quali customer retention 
e churn rate, scalabilit� orizzontale, ecc..) e si adatta ad entrambe le 
soluzioni???
 
Entrando in merito se sia meglio il SaaS o OnSite, molto dipende dal 
modello di business che hai in mente e da quali obbiettivi ti sei 
prefisso, anche perch� il CAC � diverso per le diverse soluzioni. ti 
suggerisco questa lettura
 
http://www.forentrepreneurs.com/startup-killer/
 
 
spiega in maniera esaustiva se il tuo modello di business sia 
vantaggioso per il SaaS, oppure no.
 
 
 
Ciao
 
 
 

 Beh, sono ottimista, ma facciamo anche la metà!
 
 
Non fissarti solo su un prezzo. Cerca di differenziare l'offerta con
diverse fasce di prezzo e altrettanti servizi. Es:
 
Low (Lite) : servizi e funzionalità minimali. Prezzo x € / mese (o
anno). Ad esempio non gli dai la versione stampabile / PDF delle pagine.
SLA a bassa priorità.
 
Basic : servizi base. Prezzo y €
 
Full  : tutti i servizi full-optional. Prezzo z €.
 
con ovviamente x < y < z.
 
M.

per il SaaS, oppure no.
 
Lettura molto interessante, avevo trovato un documento simile ma legger� 
attentamente anche questo.
 
Ciao 
 

Procurati forti contratti.
 
E un buon avvocato :) 
 

diritto internazionale.
 
Grazie dei tantissimi spunti molto interessanti.
Essendo un po' digiuno in materia cercher� di informarmi!
 
Michele 
 


Posso chiedere come � stata realizzata, l'applicazione, sono curioso 
dato che sto svilupppando una piattaforma SaaS, e ho optato per un 
database e applicazione condivisa per tutti i tenant, quindi il modello 
share.
Ho notato che questo tipo di approccio � quello che permette una 
scalabilit� maggiore, ma anche un livello di Customizzazione pressocche 
nullo.
 
Ciao

applicazione condivisa per tutti i tenant, quindi il modello share.
 
Ciao,
 
premetto doverosamente che non ho fatto studi sullo stato dell'arte in 
merito alle best practise in ambito SaaS.
Mi sono basato sulla mia esperienza lavorativa che comunque ha il pregio di 
essersi maturata sul campo, con clienti e prodotti "veri".
 
L'obbiettivo è che l'installazione onsite dal cliente sia unicamente un caso 
particolare di una installazione in ambito SaaS, così da minimizzare i costi 
di mantenimento e lo sbattimento.
Io mi sono regolato così, più o meno:
-Sorgenti delle pagine condivisi, trattasi di applicazione php
-Database separati, uno per cliente, strutturalmente identici tra loro (la 
scelta a mio avviso mi da molti più vantaggi che svantaggi)
-Eventuali personalizzazioni dello stile con file .css ed immagini uplodate 
dall'utente, vengono poste in cartelle separate in maniera naturale 
dall'applicativo, quindi la funzione è a costo zero.
-Ad ogni utente viene assegnato un proprio dominio di terzo livello. 
cliente1.example.com
, 
cliente2.example.com
 e così via.
 
Tutti i nomi di dominio puntano alla stessa cartella del web server ma in 
base al dominio la connessione avviene verso il db giusto ed il problema è 
risolto. Nell'installazione onsite semplicemente la connessione avviene 
sempre sullo stesso db e non cambia altro.
Nell'ipotesi che nel SaaS un cliente importante chieda qualche 
personalizzazione, cosa che è preferibile evitare se possibile, si fa una 
diversa cartella con le modifiche del caso e si gira il nome di dominio 
sulla nuova cartella.
Se magari un altro cliente avesse la necessità delle stesse modifiche, 
basterebbe girarlo su quella cartella.
 
Per fare scalabilità orizzontale, mettiamo che una macchina può servire 10 
clienti, l'undicesimo lo installo nella seconda macchina che sarà identica 
alla prima ed il suo nome di dominio punterà sulla seconda macchina.
Se per qualche motivo dovessi voler migrare un cliente, magari perchè è 
cresciuto molto, basta migrare il db fuori orario lavorativo nella macchina 
nuova e girare il dns.
 
Se poi per ipotesi il Db fosse in un cluster esterno condiviso, migrare un 
utente significherebbe semplicemente girare il DNS.
Se muore il cluster, beh allora chiudi baracca e scappi con i pochi soldi 
che hai racimolato :)
 
Questi sono i miei 2 cent.
 
Michele