Vendere on line senza e-commerce. La strategia perfetta per non rischiare capitali

A cosa serve fare prodotti di qualità, soddisfare i clienti, avere un’organizzazione certificata ISO 9001 se poi non abbiamo un grande commerciale che tira le vendite e ci fa crescere rapidamente il fatturato?

Sento spesso imprenditori lamentarsi delle scarse vendite, ma, a parte casi concreti di interi mercati in declino, molti non hanno voglia di innovare i prodotti, i processi o le modalità di vendita.

e-commerce vs. marketplace

E non sto parlando di metter su un e-commerce, cosa che è alquanto rischiosa, lunga e costosa, perché necessita di investimenti importanti dai ritorni incerti. Anzi, direi che sia invece una certezza che un cliente decida di comprare su Amazon o su AliBaba per tempi e costi di spedizione invece che direttamente dal nostro e-commerce.

Però per fortuna le cattive notizie finiscono qua. I due maggiori marketplace (Amazon e AliBaba) possono essere nostri alleati quando si parla di vendite. E sto pensando in particolare ai grandi mercati esteri, mercati accessibili di solito solo grazie a grandi investimenti commerciali. In particolare USA, Gran Bretagna, Cina e molte alte aree geografiche dove i volumi del commercio elettronico sono giganteschi e l’immagine del Made in Italy è fortissima.

Non solo vendite ai clienti retail (consumatori)

Un altro mito da sfatare è che sui marketplace possano vendere solo aziende che fabbricano prodotti di tipo retail, pensati cioè per il consumatore finale. Il mio amico Lodovico Marenco, uno dei massimi esperti in Italia di e-commerce e marketplace, ha sicuramente qualcosa da dirti in merito. Ascolta questi 7 minuti di intervista, oppure clicca qui se non hai mai venduto su Amazon e vuoi scoprire come fare

SCOPRI COME INIZIARE A VENDERE SU AMAZON, ANCHE SE NON SAI DA DOVE COMINCIARE

/0 Commenti/da

Le 6C per creare procedure efficaci

Se la tua impresa sta crescendo e ti trovi in difficoltà nella gestione del personale oppure se la vuoi far crescere, hai bisogno di creare delle procedure organizzative efficaci. Delle procedure operative standard.

In questo articolo ti mostrerò come creare delle procedure veramente utili per la crescita della tua organizzazione, quindi non quella paccottaglia formale che si trova nella maggior parte delle aziende certificate ISO9001 e che la maggior parte di consulenti spaccia ancora oggi per valide.

Ti sto parlando di documenti di vario genere e formato che raccolgono il know-how aziendale su un argomento e lo mettono a disposizione del tuo personale in modo che ognuno abbia una guida operativa e che tutti i processi funzionino in maniera automatica.

Ci sono dei piccoli segreti che rendono delle procedure operative degli strumenti realmente efficaci per la conduzione della tua azienda rendendola un meccanismo automatico al tuo servizio. Infatti fra poco ti parlerò  del metodo delle 6C per creare delle procedure veramente efficaci, ma prima devi conoscere quali modalità si usano abitualmente per documentare le procedure.

Tipi di procedure

le procedure possono essere descritte in tanti modi, usando testo, diagrammi, matrici, immagini e video. Ma vediamo vantaggi e svantaggi di ciascuna rappresentazione.

Procedure di testo

La procedura testuale è il vecchio modo di documentare le procedure. Si usa semplicemente del testo per descrivere in maniera più o meno dettagliata le singole operazioni in sequenza logica. Questo modello di rappresentazione delle procedure è frequente incontrarlo nelle aziende che hanno iniziato la loro attività nei primi anni della qualità ma purtroppo è facile imbattersi ancora in consulenti che usano ancora questi metodi ancora oggi. La procedura testuale ha ereditato l’imprinting della grande industria di vecchio stampo e ha alcuni aspetti negativi fra cui la scarsa leggibilità e la scarsa immediatezza; talvolta è scritta con approccio formale e teorico, rimanendo spesso lettera morta all’interno di qualche cassetto o scaffale anziché essere utilizzati per aiutare le persone a lavorare. Il vantaggio è la possibilità di descrivere dettagliatamente una singola attività, per cui spesso la si usa per le cosiddette “Istruzioni di lavoro” (singola lavorazione).

  • PRO: molto dettagliate
  • CONTRO: verbosità, scarsa leggibilità, basso “appeal”

Procedure a diagramma di flusso

Scrivere le procedure con un diagramma a blocchi o con un diagramma di flusso di solito è molto efficace e il principale vantaggio è che è immediato e permette una vista di insieme, ma non è sempre comprensibile da parte di tutti, richiede un occhio allenato e c’è bisogno di un di un certo grado di competenza per leggerlo e comprenderlo. E poi il suo grande limite è nel descrivere le attività complesse, con un elevato grado di dettaglio. Usavo molto questo metodo negli anni 2000 quando le aziende sono passate ad una organizzazione per processi, mentre oggi le uso soltanto in casi particolari.

  • PRO: immediatezza, vista di insieme
  • CONTRO: poco dettaglio

Procedure a matrice

La rappresentazione a matrice si presta bene a svariati tipi di applicazione e presenta alcuni vantaggi rispetto ad entrambe le soluzioni precedenti. Di solito la procedura è schematizzata secondo una matrice, una tabella che riporta sulle righe la sequenza logica delle attività, mentre in colonna sono rappresentati:

  • un codice progressivo dell’attività
  • una descrizione sintetica dell’attività
  • la descrizione approfondita dell’attività
  • un responsabile
  • i documenti che utilizza
  • i documenti che produce
  • altri campi a piacere, dalla quantificazione del rischio alla strumentazione a disposizione, eventuali archivi, ecc.

Questo tipo di rappresentazione presenta  notevoli vantaggi perché permette facilmente la lettura e le revisioni (di solito con normalissimi fogli di calcolo) e risulta estremamente flessibile e modulare.

Questo tipo di procedura viene usato per documentare i processi sia di piccole imprese o di imprese grandi (i processi dei mutui e dei fidi di MEDIOLANUM li ho progettati in questo modo)

PRO: sintesi, revisioni, ottime per progettare un processo, modularità, scalabilità

CONTRO: non sono il massimo nella comunicazione, sono strumenti di lavoro

Procedure Video

Un’altra modalità di documentare i processi in maniera veramente efficace è tramite video. Alcune aziende preferiscono questa modalità per l’immediatezza. Ad esempio in un’azienda che crea composti chimici, abbiamo utilizzato i video per mostrare agli operatori come riempire dei silos in sicurezza con i giusti DPI. Cosa c’è di meglio che mostrarlo in video? e poi l’abbiamo messo a disposizione del personale in maniera molto snella tramite smartphone, intranet e whatsapp. Sarebbe meglio avere una infrastruttura multimediale che permetta di metterle a disposizione facilmente e di tracciarne la lettura, ma i mezzi tecnologici certamente non mancano. Anche un gruppo chiuso di Facebook andrebbe bene per una piccola impresa, oppure strumenti a pagamento, più professionali e strutturati.

PRO: immediatezza, comunicazione, facilità nell’esporre, rapidità

CONTRO: non si possono stampare, non si possono correggere, necessitano di una infrastruttura multimediale

Tecnica mista

È importante poi arricchire ogni tipo di  procedura, se serve, con dettagli chiari ed inequivocabili come ad esempio con della documentazione fotografica. In certi casi possiamo utilizzare testo e immagini per spiegare alcuni passaggi critici, in altri casi video, in altri diagrammi e via dicendo, mescolando i vari media per avere veramente ZERO ostacoli nel ricorrere a queste procedure.

il metodo delle 6C

Ogni procedura per essere chiara ed efficace deve avere le 6 componenti caratteristiche:

  • CHI
  • COSA
  • COME
  • CON CHI/COSA
  • CONFRONTO
  • CONDIVIDI

CHI: il responsabile dell’attività

COSA: la descrizione sintetica dell’attività, il titolo del paragrafo, lo scopo.

COME: descrizione dettagliata di come deve essere eseguita l’attività

CON CHI/COSA: quali figure collaborano o eseguono l’attività, con quali strumenti?

CONFRONTO: una volta che la procedura è in bozza, è bene confrontarsi con il personale interessato, per limare le inevitabili differenze fra la prima versione e la pratica applicativa. Correggere le procedure prima di renderle ufficiali è una fase molto importante.

CONDIVIDI: Ultimo passo, dopo che si è concluso il processo di revisione e approvazione, la procedura deve essere messa a disposizione delle persone che la dovranno applicare, con i mezzi giusti e i formati giusti, che si tratti di una procedura stampata, di un PDF in rete, di un filmato, non ci sono regole ferree, nemmeno la ISO 9001 prevede firme, stampe o formati vari, con buona pace dei consulenti e auditor formali.

In questo modo ti garantisco che non avrai difficoltà a ottenere il meglio dalla tua organizzazione e a farla volare verso un livello superiore rendendo l’azienda un meccanismo automatico al tuo servizio.

Se vuoi vedere dei modelli, degli esempi o semplicemente fare domande, scrivi qui sotto, sarò contento di mandarti gratuitamente quello che ti serve.

Per restare in contatto ti invito a registrarti su www.ISO9001facile.com o a cercarmi sul mio profilo linkedin.

Se il video e l’articolo ti sono stati utili, condividi, metti LIKE e dillo agli amici, te ne saranno grati.

/5 Commenti/da

Kanban, Scrum e produttività dello sviluppo software

la lavagna Kanban di 3F Consulting

Oggi non abbiamo un video. Oggi ti racconto una storia.

Siamo alla 3F Consulting, azienda di Firenze che sviluppa soluzioni, applicazioni web e framework java based (Liferay, Wicket, Vaadim), fornendo consulenza su architetture applicative per la Pubblica Amministrazione e le Grandi Imprese.

Quando ci siamo conosciuti avevano una identità aziendale ancora incerta ma avevano intenzione di trovare la loro strada. Era il 2010 e da allora molte cose si sono evolute.

La reingegnerizzazione dei processi, culminata poi con la certificazione ISO 9001, ha portato a comprendere che il problema non era organizzativo, ma di strategia.

Francesco Fondelli, fondatore della 3F ha guidato i soci attraverso una trasformazione di mentalità e di visione che non è stata indolore, ma molto, molto efficace. 

Il lavoro più impegnativo non è stato creare qualcosa in più, ma togliere. Eliminare le business unit non fruttuose, eliminare le piccole commesse alla portata di tutti, eliminare i clienti che non sai mai se e quando pagano. E tutto questo per concentrarsi infine su quello che conta veramente, su quello che oggi distingue 3F nel mercato internazionale, dopo avere vinto diversi contest in ambito Liferay.

Attraverso un cammino di accurata selezione delle tecnologie vincenti/performanti, fatto con coerenza e concretezza, seguendo principi di lealtà verso la clientela e di puntualità negli impegni presi, 3F ha chiuso ogni esercizio in crescita con l’ultimo incremento del giro d’affari del 65%. , cosa ancora più mirabile, ha portato il suo Ebitda dal 7 al 30%. 

Il percorso che stiamo facendo adesso di ulteriore affinamento dei processi e in particolare l’introduzione delle tecniche Scrum per la progettazione e lo sviluppo ha l’obiettivo di migliorare ulteriormente queste prestazioni.

Il kanban

Ma il Kanban è solo una moda o ha degli effetti positivi? 

Il primo effetto, immediato, dell’introduzione della “gestione a vista” è il miglior coordinamento del corpo tecnico. Gli incontri di pianificazione si tengono ogni mattina alle 9:15 per 15 minuti, massimo 20.

Davanti alla lavagna Kanban ogni Project Manager e sviluppatore racconta cosa andrà a fare durante il giorno o i giorni seguenti condividendolo con il resto del team di sviluppo a partire dal primo incontro precontrattuale fino alla delivery completa e alla validazione.

Il principio che guida il gruppo è l’avere il minor numero di progetti possibile nelle lanes DOING e VERIFY e questo sta trasformando degli sviluppatori solitari in giocatori di squadra con effetti tangibili su Focalizzazione, Visione di progetto ed entusiasmo!

I progetti sono suddivisi in “user stories” e caratterizzati da “impediments” “priorità/urgenze” “due dates”, “FTE effort” e questa chiarezza rende più semplici i compiti di tutti.

Conclusione

Rispondendo alla domanda fatta all’inizio del paragrafo precedente, posso tranquillamente affermare che l’approccio “lean” è vincente anche in ambito software, ma ci sono dei presupporti che devono essere messi in evidenza:

Alla base di tutto: la LEADERSHIP. Quando la barra è dritta, qualsiasi strumento ha effetti positivi.

Il Team: il sentirsi parte di un gruppo ti porta ad amplificare l’effetto delle tecniche, proprio per il famoso detto:

“singolarmente siamo forti, ma insieme siamo invincibili. E se il destino è contro di noi, peggio per lui!”

Lucio Insinga, mio caro amico 🙂

L’analisi Organizzativa: non stancatevi mai di migliorare continuativamente i processi alla base dei risultati della vostra impresa. Con umiltà e lavoro a testa bassa: una correzione di millimetri può fare la differenza fra il giorno e la notte anche in termini di redditività.

Ma del resto lo scopo di un ‘impresa non è proprio produrre utili?

Alla prossima, Andrea Aulisi.

/0 Commenti/da

Il tabù della qualità nel software. Parte 1, il modello di gestione

Se sviluppi software, se la tua azienda sviluppa software o lo commissiona, saprai benissimo che predire la qualità di un software è davvero difficile.

Sì perché la qualità del software è un tabù. Nessuno ne parla o fornisce dati oggettivi, anche se molti sono in grado di capire se un software funziona bene oppure no. Mi spiego meglio, fare un buon prodotto software dipende da moltissime variabili e il più delle volte non è verificabile ai primi utilizzi.

Inoltre non dipende dal talento dello sviluppatore, o dal talento di alcuni sviluppatori di una squadra. Forse questo può essere vero in una fase di start up di una piccola impresa, ma raramente questo risultato è ripetibile quando il team di sviluppo comincia ad allargarsi.

Il risultato finale dello sviluppo è difficilmente quantificabile in maniera preventiva. A volte è difficile individuare il livello di qualità di un software anche durante i test.

Le dimensioni della qualità del software

Quindi quand’è che si capisce se un software e di qualità oppure no?

Innanzitutto la qualità di un software dipende principalmente da queste 6 caratteristiche.

  • Funzionabilità
  • Affidabilità
  • Efficienza
  • Usabilità
  • Manutenibilità
  • Portabilità

Ma svilupperemo questi concetti nel secondo video dedicato alle metriche del software.

Qui mi interessa invece un altro aspetto, quello dell’organizzazione che deve avere una software house per garantire i punti suddetti.

Qualità esterna e qualità interna

Nella maggior parte dei casi, la qualità di un software, non si può valutare neanche dopo le prime release. E cioè, a meno che non si manifestino problemi grossolani nella prima release si tende ad accettare il software come buono. Questo è quello che va sotto il nome solitamente di qualità esterna. Cioè la qualità percepita dal cliente.

E poi c’è la qualità interna, quella che viene invece percepita da chi ha sviluppato e deve manutenere il software. È da questo lato che solitamente si manifestano i problemi più critici e pesanti da risolvere. E si manifestano anche dopo molto tempo, quando il software ha già qualche anno di sviluppi, modifiche, aggiornamenti vari. Ogni singola modifica ulteriore, rallenta le prestazioni del software, ne rende quasi impossibile la manutenzione, allungando i tempi di risposta delle change request, i costi della manutenzione e via dicendo.

Insomma, un software fatto male, è una bomba ad orologeria per tutti: per il cliente che l’ha pagato e che non ha risolto il suo problema in maniera efficiente, per il produttore che deve rimetterci le mani in continuazione spendendo soldi e tempo all’infinito e poi anche per chi lo ha commissionato, perché ovviamente perde il cliente e la reputazione.

Ora, questo problema non ce l’ha tanto lo sviluppatore singolo, ma riguarda tutte le aziende che commissionano software oppure che lo producono. Sì perché non hanno quasi mai il controllo del prodotto finale, a parte i primi incontri di analisi.

Anche la micro azienda di sviluppo software può avere questo problema, magari sulle prime può sembrare di no, perché gli sviluppatori lavorano tutti a stretto contatto, ma ci sono delle cose (come ad esempio la mancanza di un semplicissimo standard di sviluppo condiviso) che rappresentano un grandissimo rischio per la qualità del prodotto finale.

Anche chi lavora nell’ambito delle certificazioni di qualità, non affronta quasi mai l’argomento della qualità del software. Prima di tutto perché sono in pochi a capirci davvero qualcosa. Gli specialisti di qualità software spesso non sono dei bravi consulenti di strategia. E viceversa.

Ma per fortuna ci sono almeno un paio di strategie che possono ridurre e prevenire i rischi di un software fatto male.

Quindi quali sono le prime due strategie che un produttore di software deve almeno prendere in considerazione per assicurarsi di non perdere soldi, tempo e reputazione?

La prima strategia: il modello di gestione interno

la prima è sicuramente dotarsi di un modello di gestione interno. Uno strumento organizzativo, un sistema, che lo aiuti a far sì che ogni punto critico della sua delivery sia presidiato da un controllo o da dalle prassi. Si, mi riferisco a delle procedure, scritte e condivise (leggi qui il metodo delle 6C per creare delle procedure efficaci).

Oggi ci sono tanti modi per dotarsi di un modello di gestione. A cominciare dalle tecniche di sviluppo agili (che, attenzione, non significa che se si sviluppa il software in maniera agile o “agiàil”, si può fare che cavolo ci pare, ci sono dei paletti anche lì) fino alle tecniche scrum e alle più classiche metodologie waterfall. Non mi sento di consigliare un modello di gestione piuttosto che un altro a priori, le scelte a priori vanno lasciate agli Evangelisti di una o dell’altra dottrina, ai pasionari della moda del momento. Ogni azienda deve scegliere il suo modello di gestione in funzione della maturità aziendale, della rapidità del mercato in cui si muove, delle dimensioni dei suoi progetti, sulle tipologia dei suoi lavori se a commessa o a mercato, in funzione delle tipologie di clienti o degli utenti finali che serve.

Però ci sono dei capisaldi che ogni azienda deve considerare. Quindi, a meno che tu non abbia già un modello di gestione, tieni bene in mente questi punti.

Punto primo, il team di sviluppo deve essere definito a priori, in base alle competenze e alle capacità personali di ciascuno, ognuno dovrà avere dei singoli ruoli all’interno del team. Mi raccomando, non ti sto dicendo questo per fare un bell’esercizio e prendere un bel voto a scuola, ti sto chiedendo di scrivere nero su bianco chi è lo Sviluppatore, chi l’Analista, chi è il Capo Progetto, chi è il Project Manager. Anche se alla fine il team è composto da 3 persone soltanto. È importante scriverlo nero su bianco, le persone hanno la memoria corta. E nascono i casini.

Tipico GAP di progettazione! 🙂

Punto secondo. Il tempo dedicato all’analisi non è mai abbastanza. È chiaro che alla fine dovremo trovare un compromesso fra la fase iniziale di analisi e l’inizio dell’implementazione, però questo è lo snodo nevralgico su cui combattono sempre il cliente, gli sviluppatori, e l’imprenditore. È risaputo che “cannare” l’analisi porta sempre a dei risultati deprimenti per tutti, ma anche fare un’ottima analisi non è sufficiente per ottenere un prodotto eccellente. Sì, è una condizione necessaria, ma non sufficiente. Fare una buona analisi permette chiaramente anche di quantificare bene il progetto a livello economico.

la qualità, o la paghi prima o la paghi dopo (e di solito dopo è molto più cara)

Punto terzo, la pianificazione. Anche in questo caso, è necessario scrivere nero su bianco con qualsiasi mezzo, che sia una lavagna nell’area di sviluppo, che sia un documento condiviso, che sia un tool web, l’importante è che siano scritte nero su bianco le fasi del progetto, gli step di verifica e test, le date di rilascio del prototipo, mockup, versione finale, eccetera. Anche in questo caso non ti sto chiedendo di fare un esercizio di stile, è proprio fondamentale scriverlo nero su bianco e condividerlo con il team di sviluppo.

Punto quarto. Il test del software è un’attività che ti può davvero salvare la faccia di fronte ai clienti. Ho visto così tante volte aziende committenti e produttrici arrivare ai ferri corti solo perché era stata trascurata la fase di test. Fino a qualche anno fa c’era il tempo da dedicare quasi la metà del budget di progetto alla fase di test. Oggi non c’è più. Il mercato è troppo veloce per consentire di fare dei test approfonditi, ma una buona pianificazione dei test o degli sprint, con strumenti e metodologie adatte, rende possibile farlo in maniera economica e sostenibile. La valenza dei test è doppia:

  1. I test del codice hanno lo scopo di verificare se il codice fa quello che si è detto che deve fare.
  2. I test del progetto hanno lo scopo di verificare se il prodotto sviluppato sia effettivamente quello che vuole il cliente, il committente, o l’utente finale! Sono dei test più allargati, con una visione più ampia e che spesso possono essere estesi anche al cliente, in un’ottica di collaborazione.
il processo di sviluppo software senza interazioni con il cliente contro il processo con frequenti test/sprint

Quindi, ricapitolando, nella prima strategia del modello di gestione, i punti essenziali sono:

  1. definire bene i team di sviluppo NERO SU BIANCO
  2. ANALISI fatta bene
  3. PIANIFICAZIONE “intelligente”
  4. TEST, verifiche e interazione con il cliente/utente

La seconda strategia: controllo delle dimensioni della qualità del software

La seconda strategia che ogni produttore di software deve assolutamente fare, è dotarsi di uno strumento per controllare le 6 dimensioni principali della qualità del software di cui ho parlato prima. Ti sto parlando adesso della qualità del prodotto software. Quando un’azienda ha dei prodotti propri, o quando il prodotto sviluppato per un cliente ha una certa complessità, è importante essere consapevoli di che cosa stanno facendo i propri sviluppatori. E questo lo puoi fare soltanto usando delle metriche, dei KPI, degli indicatori pensati per capire se il tuo prodotto è di qualità oppure no. Sto parlando di dati oggettivi, linee di codice, lunghezza delle linee di codice, usabilità del prodotto, manutenibilità, portabilità. Tutte metriche che possono fare una differenza abissale fra un software mediocre destinato a durare pochi anni, ed un software eccellente destinato a vincere sul mercato.

Un esempio di rappresentazione grafica delle metriche di un software di qualità

Parlerò del tema delle metriche del software in un prossimo video (sopra un esempio di indicatori di qualità), in cui sviscereremo ciascuna delle 6 dimensioni per cui un software può essere ritenuto di qualità oppure no.

I modelli di gestione e le norme di riferimento

Tornando al modello di gestione, solitamente si fa riferimento allo standard di qualità del processo più diffuso al mondo. La norma ISO 9001.

La ISO 9001 da sola non garantisce che i prodotti sviluppati siano di qualità. Ma effettivamente garantisce l’applicazione di un ottimo modello di gestione della qualità anche alle aziende che sviluppano software, e se il sistema di gestione ISO 9001 è architettato bene da qualcuno che conosce bene il software, effettivamente reca un beneficio straordinario all’azienda che lo implementa.

Attenzione, ti sto parlando di uno dei più collaudati standard di miglioramento della qualità, diffuso in 180 paesi in tutto il mondo che definisce come un’azienda dovrebbe organizzare i propri processi. Il limite della ISO 9001 è che non è uno standard pensato esclusivamente per le aziende di sviluppo software, ma un buon consulente, insieme ad un buon imprenditore o manager, può implementare un modello di gestione veramente eccellente anche soltanto riferendosi ai requisiti della ISO 9001.

Altro standard più avanzato è la ISO 20000 che è proprio specifico per il settore del software. È uno standard molto impegnativo per cui consiglio alle piccole aziende di tenerlo presente solo come riferimento e non come standard di certificazione. Come standard di certificazione invece consiglio l’eccellente modello di gestione della ISO 9001.

Ok. Fine della prima parte. Nella seconda entreremo nel merito della qualità del prodotto software (vedi la seconda parte).

Se l’articolo ti è piaciuto metti un commento e condividi sul tuo social preferito.

Se vuoi farmi delle domande su questo tema scrivi qui sotto nei commenti o cerca i miei contatti sul sito o sul mio profilo linkedin per restare in contatto.

/0 Commenti/da