“Unravel Everything. Bring the future to us”. Questa è la missione di Speee, un’azienda di trasformazione digitale (DX) con sede a Tokyo che si occupa di collegamenti guidati dai dati nello sviluppo del business. Speee sta ampliando le proprie attività commerciali, come il servizio di vendita e valutazione immobiliare Ie-Uru e il servizio di presentazione di imprese di ristrutturazione domestica Nurikae, oltre a una serie di altre attività di marketing DX.
Istantanea
- Settore: Trasformazione digitale (marketing e immobiliare)
- Numero di dipendenti: Circa 400 (a gennaio 2022)
Il problema
Speee ha iniziato a utilizzare un CMS sviluppato internamente, ma ha riscontrato problemi in tre aree: costi, usabilità e stabilità.
Nel 2018 abbiamo sviluppato un CMS headless interno per la creazione di contenuti e la gestione degli articoli. Tuttavia, quando abbiamo iniziato a utilizzare il sistema, abbiamo scoperto diversi problemi che ci hanno spinto a considerare la possibilità di sostituirlo. All’epoca i problemi erano tre.
Il primo problema era l’aumento dei costi di sviluppo e di gestione.
Sviluppare e gestire un CMS internamente costa molto. Tuttavia, poiché il suo scopo è limitato all’uso interno dell’azienda, non ci si può aspettare un grande ritorno. Questa inevitabilità rende difficile investire nello sviluppo e nella gestione.
Il secondo problema era l’usabilità.
Anche se si trattava di un CMS per uso interno, era essenziale avere un sistema facile da usare per creare rapidamente contenuti di alta qualità. Tuttavia, non abbiamo investito molto nello sviluppo dopo il rilascio iniziale a causa dei costi elevati e del basso ritorno sugli investimenti, come già detto.
Di conseguenza, non sono stati apportati miglioramenti al sistema dopo il rilascio iniziale e i creatori di contenuti hanno continuato a utilizzare un’interfaccia utente e un’infrastruttura molto scomode. Senza dubbio, questo ha portato a contenuti di qualità inferiore.
Infine, il terzo problema è che il vecchio CMS era diventato un fattore che aveva ridotto la stabilità degli altri sistemi.
Poiché il CMS che abbiamo sviluppato internamente era un CMS headless, l’effettiva visualizzazione dei contenuti era affidata a un’altra applicazione web. Questa applicazione web doveva chiamare l’API del CMS headless, ma quando questa API andava in tilt, l’intera applicazione web spesso andava in tilt come danno collaterale.
La soluzione
Era arrivato il momento di adottare misure drastiche per porre fine all’esplosione dei costi. Il team si è orientato verso una soluzione SaaS, con Kinsta in cima alla lista dei possibili candidati.
L’aumento dei costi di sviluppo era diventato un collo di bottiglia e quindi abbiamo deciso di passare al SaaS. Il problema era quale SaaS adottare. Dalla nostra ricerca, abbiamo ristretto il campo a un paio di candidati, tra cui Kinsta, e in particolare ci siamo soffermati su tre aspetti positivi di Kinsta.
Innanzitutto, su Kinsta possiamo utilizzare WordPress, il CMS più diffuso al mondo.
Nella nostra azienda avevamo già un reparto che utilizzava WordPress, quindi c’era già una certa familiarità. Inoltre, dato che molte persone lo utilizzano per un’ampia varietà di scopi, abbiamo capito che le sue funzionalità e la sua scalabilità sono molto interessanti.
In secondo luogo, il servizio gestito di Kinsta ha un’ampia portata.
Sebbene sia facile iniziare a lavorare con WordPress, mantenere PHP e WordPress correttamente aggiornati è un problema. Con Kinsta, gli aggiornamenti di PHP e WordPress possono essere effettuati con pochi clic e la gestione del CDN e del dominio può essere effettuata dall’interfaccia utente. Queste erano le caratteristiche che cercavamo, poiché volevamo concentrarci sulla creazione di contenuti e sullo sviluppo di servizi.
In terzo luogo, il prezzo di Kinsta è ragionevole per le sue caratteristiche.
Con tutte le funzionalità di Kinsta di cui sopra, il prezzo era relativamente basso rispetto ai servizi che stavamo considerando.
Abbiamo scelto Kinsta per la sua superiorità sui tre punti precedenti rispetto alla concorrenza.
Il risultato
Grazie alla combinazione di WordPress e Kinsta, il flusso di lavoro è diventato incredibilmente fluido. Inoltre, la stabilità del sistema è migliorata immediatamente.
Innanzitutto, grazie al passaggio dal nostro CMS a WordPress, ora siamo in grado di creare contenuti di alta qualità più velocemente. Questo grazie soprattutto all’interfaccia utente di alta qualità e al design del sistema di Kinsta, oltre che all’assistenza fornita dalla sua ampia gamma di potenti funzioni.
Inoltre, dal momento che WordPress è così diffuso, molti creatori di contenuti hanno già esperienza nell’utilizzarlo. Anche in caso di problemi, le soluzioni sono facilmente reperibili online, il che riduce i costi di esposizione e ricerca.
L’aspetto più rilevante per noi è la stabilità del sistema di Kinsta. Prima di passare a Kinsta, ogni anno si verificavano diversi malfunzionamenti che interessavano i nostri utenti, ma da quando siamo passati a Kinsta questi problemi sono completamente scomparsi. Questo non solo perché Kinsta è di per sé molto stabile, ma anche perché la probabilità di guasti si è ridotta non avendo più bisogno di collegare più sistemi attraverso un’API.
Un altro motivo è che ora il middleware e i plugin vengono aggiornati correttamente. In passato, con il nostro CMS proprietario, gli aggiornamenti del middleware e delle librerie tendevano a essere trascurati. Ora utilizziamo le funzioni di Kinsta per aggiornare le versioni di PHP e WordPress e abbiamo creato un meccanismo per l’aggiornamento automatico dei plugin, mantenendo il CI/CD in modo semi-automatico.
Kinsta è la soluzione ai limiti del personale; essere preparati al futuro è fondamentale.
speee.jp
